Re: [Sipping] Proposed text for update-pai concerning response identity (was RE: Further proceeding with draft-ietf-sipping-update-pai--05)

["Elwell, John" <john.elwell at siemens.com>]

Vijay,

Thanks for your detailed proposals. See below. 

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vkg at alcatel-lucent.com] 
> Sent: 22 September 2008 19:42
> To: Elwell, John
> Cc: sipping
> Subject: Re: [Sipping] Proposed text for update-pai 
> concerning response identity (was RE: Further proceeding with 
> draft-ietf-sipping-update-pai--05)
> 
> Elwell, John wrote:
> > Although there have been very few opinions expressed, those 
> that have
> >  been expressed seem to be roughly along the lines of my earlier
> > option 4 ("Go ahead with the present update-pai draft, leaving it
> > open how to achieve authentication of a response.
> 
> John: I went back and re-read the thread.  By and large, I would
> also put myself in the camp of option 4.  But more inline.
> 
> > The present example of how to do this (towards the end of section
> > 3.3) is broken, so would have to be removed, or at least 
> qualified.")
> > 
> > In draft-05, section 3.3 states: "      <t>Section 5 of RFC 3325
> > requires a proxy to authenticate the originator of a message before
> > adding a P-Asserted-Identity header field to the forwarded message.
> > In practice there is no SIP means to authenticate the 
> sender of a SIP
> > response message. However, authentication may be possible by other
> > means. 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.</t>"
> > 
> > I would propose to change this to: "      <t>Section 5 of RFC 3325
> > requires a proxy to authenticate the originator of a message before
> > adding a P-Asserted-Identity header field to the forwarded message.
> > How this is achieved is outside the scope of this document.</t>"
> 
> S3.3 is about inclusion of PAI and PPI in responses.  With your
> suggested change, it still remains unclear on whether you are
> referring to a request or response when you write "Section 5 of
> RFC3325 requires a proxy to authenticate the originator of
> a message ..."
> 
> You then go on to say that a UAS can insert a PAI/PPI in
> responses, so I assume that the gist of the problem we
> are grappling with whether or not a proxy can insert PAI/PPI?
> 
> To that extent, I think it will be much cleaner if you
> completely took out the paragraph "Section 5 of RFC 3325 ... in
> a SIP response", and instead, defer the discussion of a proxy
> inserting PAI/PPI responses in S4.2.2 where it really belongs.
[JRE] I think 3.3 would be incomplete without saying something about
proxy insertion of PAI in a response, but I agree it could be clearer.

> 
> If you have to insert some text about proxies inserting PAI/PPI
> headers in response in S3.3, say something along these lines:
> 
>    This section explores the inclusion of a PAI/PPI header
>    in a response by a UAS; the analogous discussion on whether
>    or not a proxy can include such headers in a response is
>    in S4.2.2.
[JRE] I would prefer not to do it this way, since section 3 is the
discussion section and section 4 is the normative part. I think it would
be better to substructure 3.3, such that 3.3 itself talks about response
identity in general, 3.3.1 talks about insertion of PAI/PPI by a UAS,
and 3.3.2 talks about insertion of PPI by a proxy.

> 
> > And then in 4.2.2 it states: "        <t>The proxy behaviour
> > specified in RFC 3325 is applicable to responses with the following
> > qualifications. A proxy that receives a response from a node outside
> > the Trust Domain cannot directly authenticate the UAS by SIP means.
> > Therefore it MUST NOT include a P-Asserted-Identity header 
> field when
> > forwarding the response unless it has authenticated the UAS by other
> > means.</t> <t><list> <t>One possible circumstance in which a proxy
> > can include a P-Asserted-Identity header field when forwarding a
> > response from a node outside the Trust Domain is when the proxy has
> > direct TLS connectivity with the UAS and has authenticated the UA by
> > some other means (e.g., SIP digest authentication) during that same
> > TLS session.</t> </list></t>"
> > 
> > I would propose to change this to: "        <t>The proxy behaviour
> > specified in RFC 3325 is applicable to responses with the following
> > qualifications. A proxy MUST NOT include a 
> P-Asserted-Identity header
> > field when forwarding the response unless it has authenticated the
> > UAS by some means. The means to authenticate the UAS is outside the
> > scope of this document.</t>
> 
> I would suggest something along these lines, including Francois'
> comments:
> 
>    <t>Section 5 of RFC 3325 requires a proxy to authenticate the
>    originator of a message before adding a P-Asserted-Identity
>    header field  to the forwarded message.  While this works for
>    requests, it does not for responses since unlike requests,
>    responses are not challenged by a proxy, nor is the authenticity
>    of the sender of the response established.  In practice, there
>    is no authoritative manner by which a SIP proxy can authenticate
>    the originator of the response.  Therefore, a proxy MUST NOT
>    include a P-Asserted-Identity header field when forwarding the
>    response unless it has authenticated the UAS by some means.
>    The means to authenticate the UAS is currently outside the
>    scope of this document; however future documents may further
>    define techniques for response authentication.</t>
[JRE] I think words similar to these would fit better into the new
3.3.2. I am not sure about the word "authoritative" - perhaps
"standardised" would be better.

I will post a new version and take further comments on that.

John
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP