Subject: [Sipping] comments on draft-elwell-sipping-update-pai-02

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 Dec 2007 21:41:53 -0500

I like this draft. It documents and writes down what is common practice, 
and thats a good thing.

Some comments:

>   INVITE method.  However, RFC 3325 does not specify the insertion of
>    this header field by a trusted UAC, 

its worth clarifying in the intro what you mean by 'trusted UAC' and 
what some examples are. You do so later but I think you need to say 
something here.

>  header field with the SIP UPDATE method (RFC 3311 [3]), the SIP
>    MESSAGE method (RFC 3428 [5]) or the SIP PUBLISH method (RFC 3903
>    [6]),

It also says its n/a for REGISTER, but I think it makes plenty of sense 
there too (consider an edge proxy that has an authentication function 
and then passes the authenticated REGISTER to the registrar).

Also if you think it applies to mid-dialog requests, why not PRACK and 
INFO? Not just for changes but for an assertion that mid-dialog requests 
have been authenticated?

> RFC 3325 does not include procedures for a UAC to include the
>    P-Asserted-Identity header field in a request.  This can be
>    meaningful if the UAC can be trusted by the first proxy, as is often
>    the case for PSTN gateways, for example. 

worth noting other use cases:

   * RLS
   * 3pcc application server

> For example, if the proxy has TLS
>    connectivity with the originator of the response and has previously
>    authenticated the connected entity (e.g., using SIP digest
>    authentication at registration time), then the originator of the
>    response can be considered to be authenticated.  In such
>    circumstances it is permissible for a proxy to insert a P-Asserted-
>    Identity header field in a SIP response.

I think this needs to be more concrete on the conditions on which you 
have sufficient security properties to do this.

> A UAC SHOULD
>    do so only in cases where it can expect to be trusted by the first
>    proxy.  A UAC SHOULD NOT do so in other circumstances and might
>    instead use the P-Preferred-Identity header field.

how does a UAC know? Is this a configuration parameter? I'd rather not 
have it say this, have the UAC assert identity always when it thinks its 
authoritative to do so.

> If a UA is not part of the Trust Domain from which it received a
>    response containing a P-Asserted-Identity header field, then it can
>    assume this information does not need to be kept private.

previous text says it has to ignore the information, so this statement 
seems redundant.

> When receiving a request or response containing a P-Asserted-Identity
>    header field directly from a UA (rather than from another proxy), a
>    proxy may trust the UA in certain circumstances.  This might occur if
>    the UA is a known PSTN gateway and the request or response has been
>    secured by TLS.  The proxy might trust the PSTN gateway to assert an
>    identity received from the PSTN, the proxy itself having no means to
>    authenticate such an identity.  In other circumstances a proxy should
>    not trust an identity asserted by a UA.

no - I think the statement we need to make here is that the UAC has to 
be inside the trust domain as defined and verified by 3325 procedures. 
The real issue is that 3325 really talks about proxies as being part of 
trust domains and not UA. But thats all we're saying here - UA can be in 
your trust domain.

Also normative text on proxy behavior has to say that the UAC has to be 
in the trust domain and verified ala TLS.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 04 Dec 2007 16:05:54 +0000

Jonathan,

Thanks for your comments. Most I can deal with at the next revision.
During this morning's session perhaps worth raising the issue of
extending to other mid-dialog requests and/or REGISTER requests. I am
certainly open to do this if we think there are use cases.

John

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 04 December 2007 02:42
> To: IETF Sipping List
> Subject: [Sipping] comments on draft-elwell-sipping-update-pai-02
>