Document: draft-ietf-sipping-update-pai-01
Reviewer: Paul Kyzivat [pkyzivat@cisco.com]
Review Date: 4/23/2008
Review Due: 5/12/2008
Review Type: Initial WG review

Summary: On the right track

Comments:
----------


I took a look, and have a few comments:

Section 3.1 says:

    This can be
    meaningful if the UAC is in the same Trust Domain as the first proxy.

What is so special about the *first* proxy? And this statement doesn't really say whether the UAC is before or after the first proxy. And there may be *no* proxy. (Just a bunch of B2BUAs. :-( )

Similarly, section 3.6 says:

    It should also be permissible for a UAS to insert a P-Asserted-
    Identity header field into a response if it is within the same Trust
    Domain as the proxy from which the request was received (the last
    proxy).

Why shouldn't *any* element on the signaling path within a trust domain be allowed to assert the identity if it has some way of determining it?

In any case, its less important to document who is allowed to insert it than it is to specify when a recipient should trust the value that was inserted. It is presumably adjacency over a trusted connection that allows the value to be trusted. Perhaps that is what "first" and "last" 
are trying to get at. IIUC its an unbroken sequence of such trusted adjacencies that defines the trust domain.

I will now try to manifest the above comments in the normative text that
  follows:

Section 4.1.1:

s/first proxy/sip server to which it sends the request,/

(three places).

Section 4.1.2 says:

    However, if a UAC receives a response from a previous element outside
    the Trust Domain, it MUST NOT use the P-Asserted-Identity header
    field in any way.

I think this fails to reflect asymmetry in the trust relationships. In particular, a UAC may trust its provider to provide useful assertions of identity even though the provider doesn't trust the UAC to provide assertions of its own identity. I think that means that the UAC is not part of the trust domain, yet the above requirement is seemingly inappropriate. I would suggest somthing more like:

    However, if a UAC receives a response from a previous element it
    does not trust, it MUST NOT use the P-Asserted-Identity header
    field in any way.

I realize that may be insufficient because it doesn't specify how this form of trust is determined. So it needs more work.

Section 4.4.2:

s/last proxy/sip server from which it received the response,/

Section 6 says:

    When receiving a request or response containing a P-Asserted-Identity
    header field directly from a UA (rather than from another proxy), a
    proxy will trust the UA only if it is known to be within the Trust
    Domain and is connected by means of TLS as specified in RFC 3325.

A proxy (or any sip server) in general has no way to know whether the message was received from a UA or a proxy, and so can't base any decisions on knowing. I'm uncertain how to fix the above to reflect this.

It goes on to say:

    Domain and is connected by means of TLS as specified in RFC 3325.
    One example where this might be true is a UA that is a PSTN gateway.
    In this case the UA can assert an identity received from the PSTN,
    the proxy itself having no means to authenticate such an identity.  A
    proxy must not trust an identity asserted by a UA outside the Trust
    Domain.

Same issue. I would propose to change the last sentence to:

    A sip server must not trust an identity asserted by a source outside
    the trust domain.