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

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Feb 2008 11:59:55 +0000

Jonathan,

Thanks for your comments and your support. See my responses below.

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
> 
> 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.
[JRE] Done

> 
> >  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).
[JRE] It sounds reasonable, but I would like to seek other opinions. I
will start a separate thread.

> 
> 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?
[JRE] I am not so sure, because the motivation for mid-dialog requests
so far (UPDATE mainly) has been the fact that the identity has changed.
The concept of conveying it in every mid-dialog request to assert that
authentication has taken place is new. I would like to seek other
opinions. I will start a separate thread.

> 
> > 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
[JRE]Done

> 
> > 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.
[JRE] Perhaps, but then do we limit it to the particular case given as
an example, or are there other cases? I will start a separate thread on
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.
[JRE] I am not sure exactly what you propose here. Wouldn't it require
configuration in order for the UAC to think it is authoritative?

> 
> > 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.
[JRE] Deleted.

> 
> > 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.
[JRE] I agree in principle, but I think some of the other text to do
with PSTN gateways is worth preserving. I have changed to the following
- will this do?
    <t>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. 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.</t>

> 
> Also normative text on proxy behavior has to say that the UAC 
> has to be 
> in the trust domain and verified ala TLS.
[JRE] As far as requests are concerned, the text refers RFC 3325
procedures (and extends to certain other SIP methods). In other words,
no change as far as the conditions for assertion are concerned. I did
not want to reproduce the words of section 3 of RFC 3325. So I have just
added the following - will this do?
        <t>If a proxy receives a request from a UAC within the Trust
Domain it MUST behave as for a request from any other node within the
Trust Domain, in accordance with the rules of RFC 3325 for a proxy.</t>
Similarly for responses received from within the trust domain. 

> 
> 
> -- 
> 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
> 
_______________________________________________
Sipping mailing list  http://www.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