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

["Elwell, John" <[e-mail]>]

Francois,

I agree in principle, but see also Vijay's comments and my response. I
will post a new version.

John 

> -----Original Message-----
> From: Francois Audet [mailto:[e-mail]] 
> Sent: 22 September 2008 17:25
> To: Elwell, John; Mary Barnes; Cullen Jennings
> Cc: sipping
> Subject: RE: [Sipping] Proposed text for update-pai 
> concerning response identity (was RE: Further proceeding with 
> draft-ietf-sipping-update-pai--05)
> 
> I think we need to be a little more specific on what we mean by
> authentication.
> 
> I don't believe the reader will get a good feel of why a response
> is different from a request in regards to authentication.
> 
> So if we added something like "Unlike requests, responses are
> not authenticated using bla-bla". And then keep the rest the
> same as per John's text. 
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Elwell, John
> > Sent: Monday, September 22, 2008 08:48
> > To: Audet, Francois (SC100:3055); Barnes, Mary (RICH2:AR00); 
> > Cullen Jennings
> > Cc: sipping
> > Subject: [Sipping] Proposed text for update-pai concerning 
> > response identity (was RE: Further proceeding with 
> > draft-ietf-sipping-update-pai--05)
> > 
> > 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. 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>"
> > 
> > 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>
> > 
> > Comments?
> > 
> > John
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Francois Audet [mailto:[e-mail]]
> > > Sent: 19 September 2008 23:56
> > > To: Mary Barnes; Elwell, John; Cullen Jennings
> > > Cc: sipping
> > > Subject: RE: [Sipping] Further proceeding with
> > > draft-ietf-sipping-update-pai--05
> > > 
> > > I think we really need to see the exact words...
> > > 
> > > This is what we say in RFC 4916 (for connected identity for 
> > RFC 4474):
> > > 
> > >    The provision of the identity of the responder in a response
> > >    (commonly called "response identity") is outside the 
> > scope of this
> > >    document.
> > > 
> > >       Note that even if identity were to be conveyed somehow in a
> > >       response, there would in general be difficulty 
> authenticating 
> > > the
> > >       UAS.  Providing identity in a separate request allows normal
> > >       authentication techniques to be used.
> > > 
> > > Is this statement useful? I don't think so.
> > > 
> > > I am not sure why we believe that response identity IN THIS 
> > CONTEXT is 
> > > any more vulnerable than request indentity. For 
> > RFC4474-style secure 
> > > request identity, sure, but in the case of PAI, requests are not 
> > > authenticated in the first place.
> > > 
> > > I re-read section 2.2 of
> > > http://tools.ietf.org/html/draft-peterson-sipping-retarget-00
> > > which described the problem of response-identity, and they really 
> > > dealt with forking and it's negative impact on 
> > authenticated response 
> > > identity. I hardly see why this is relevant here with P-AID 
> > since it's 
> > > not like we will use P-AID with RFC 4474 in the first place.
> > > 
> > > Or am I missing something?
> > > 
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of Barnes, Mary
> > > > (RICH2:AR00)
> > > > Sent: Friday, September 19, 2008 14:58
> > > > To: Elwell, John; Cullen Jennings
> > > > Cc: sipping
> > > > Subject: Re: [Sipping] Further proceeding with
> > > > draft-ietf-sipping-update-pai--05
> > > > 
> > > > Hi all,
> > > > 
> > > > There was not tremendous response to John's query for 
> > consensus on 
> > > > this document (perhaps due to summer holidays as Cullen 
> > suggested).
> > > > 
> > > > At this point, with two responses (Paul and Cullen), text
> > > > (TBD) around option 4 is the most popular, but we really need 
> > > > feedback from others to move this forward. I will ping 
> the other 
> > > > past reviewers in another email (so that responses to 
> the thread 
> > > > don't get too many addressees) but we would really 
> appreciate if 
> > > > others would respond.
> > > > 
> > > > Thanks,
> > > > Mary.
> > > > 
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of Elwell, John
> > > > Sent: Wednesday, September 03, 2008 11:37 AM
> > > > To: Cullen Jennings
> > > > Cc: sipping
> > > > Subject: Re: [Sipping] Further proceeding with
> > > > draft-ietf-sipping-update-pai--05
> > > > 
> > > > Cullen,
> > > > 
> > > > > -----Original Message-----
> > > > > From: Cullen Jennings [mailto:[e-mail]]
> > > > > Sent: 03 September 2008 17:15
> > > > > To: Elwell, John
> > > > > Cc: sipping
> > > > > Subject: Re: [Sipping] Further proceeding with
> > > > > draft-ietf-sipping-update-pai--05
> > > > > 
> > > > > 
> > > > > On Sep 3, 2008, at 1:35 AM, Elwell, John wrote:
> > > > > 
> > > > > > I received no feedback in the changes made in draft-05
> > > > > concerning the
> > > > > > forward compatibility mechanism, nor on the particular
> > > > > issue I asked
> > > > > > for
> > > > > > comments on:
> > > > > > 
> > > http://www.ietf.org/mail-archive/web/sipping/current/msg16105.html
> > > > > > Therefore I assume these changes are acceptable.
> > > > > >
> > > > > 
> > > > > Uh, be careful with this sort of assumption. Unless you
> > > > have consensus
> > > > 
> > > > > for significant technical changes, you should not be making
> > > > them to WG
> > > > 
> > > > > documents.
> > > > > I'm trying to separating technical changes from editorial
> > > > changes here
> > > > 
> > > > > - obviously I think the editor should just make editorial
> > > > changes and
> > > > > technical changes which either have, or clearly would
> > > have, census.
> > > > > This change is not backwards compatible with some 3325
> > > > implementations
> > > > 
> > > > > and I don't think you have consensus one way or the 
> > other on it. 
> > > > > Silence does not necessarily imply people agree - I suspect
> > > > few people
> > > > 
> > > > > have read this. Perhaps my recollection of how this 
> went in the 
> > > > > meeting is wrong - I have not gone back and looked at 
> the notes.
> > > > [JRE] I hope the changes reflect what we seemed to be reaching 
> > > > consensus on in the meeting. Obviously I wanted to confirm that 
> > > > consensus on the mailing list, as well as confirming that I had 
> > > > implemented it correctly in draft-05.
> > > > However, looking at the minutes, I see it states "Another 
> > draft can 
> > > > address forward-compatibility issues...". I came away with the 
> > > > feeling that people wanted a forward compatibility requirement 
> > > > placed in the document right now, i.e., in the next 
> > draft, draft-05. 
> > > > I see now that the minutes can be interpreted a different 
> > way, i.e., 
> > > > in a completely separate draft. If I had misinterpreted 
> > the mood of 
> > > > the meeting on this aspect, we can certainly go back to 
> > the text of 
> > > > 04. Other opinions?
> > > > Nobody shouted when draft-05 appeared, which is why I sent the 
> > > > reminder today.
> > > > 
> > > > > >
> > > > > >
> > > > > > So we have the one remaining issue concerning response
> > > > > authentication.
> > > > > > We had some list discussion on this, the last one 
> > being on 20th
> > > > > > August:
> > > > > > 
> > > http://www.ietf.org/mail-archive/web/sipping/current/msg16121.html
> > > > > >
> > > > > > The use of PAI in responses is something that needs 
> > clarifying, 
> > > > > > because RFC 3325 is ambiguous (sometimes it talks about SIP 
> > > > > > messages, other times it specifically talks about
> > > > requests). In one
> > > > > > place
> > > > > it actually
> > > > > > states "message (request or response)".
> > > > > >
> > > > > > So I think we have the following options:
> > > > > >
> > > > > > 1. Say nothing about responses at all, thereby leaving us
> > > > with the
> > > > > > ambiguity that exists in RFC 3325. I don't think this is
> > > > a sensible
> > > > > > option. A lot of the value of updating RFC 3325 is lost
> > > > if we don't
> > > > > > tackle the response ambiguity issue.
> > > > > >
> > > > > > 2. Clarify the situation by stating that PAI (and PPI)
> > > > MUST NOT be
> > > > > > used in responses. I would be very reluctant to go down this
> > > > > path, since I
> > > > > > know there is a lot of use of PAI in responses (e.g., 
> > in 3GPP).
> > > > > >
> > > > > >
> > > > > >
> > > > > > 3. Devise a mechanism that exploits TLS to achieve
> > > authenticated
> > > > > > response identity and use this in the update-pai draft. 
> > > As Cullen
> > > > > > pointed out, this needs to be a separate and
> > > non-trivial piece of
> > > > > > work, probably done in the SIP WG. Waiting for this
> > > would hold up
> > > > > update-pai
> > > > > > for a considerable time.
> > > > > >
> > > > > > 4. Go ahead with the present update-pai draft, leaving it
> > > > > open how to
> > > > > > achieve authentication of a response. 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.
> > > > > >
> > > > > > Any other options?
> > > > > >
> > > > > Saying is "MUST NOT be used"  is not the right path since
> > > at least
> > > > > some people want to leave the door open to adding this 
> > in future 
> > > > > specifications. Describing how to do is not something that
> > > > should be
> > > > > done as an update to 3325 because the solution to
> > > response identity
> > > > > have a wider implication than just PAI - if we are going to
> > > > do that,
> > > > > we should do it in some separate draft in SIP. If folks
> > > agree with
> > > > > that, it seems like something along lines of option 4 is
> > > the right
> > > > > path where we say that PAI is not currently defined for
> > > > responses but
> > > > > future specifications may do so. I think it is also
> > > > important for the
> > > > > draft to document some of the reasons around why it is not
> > > > defined for
> > > > 
> > > > > responses.
> > > > [JRE] Your proposal seems to be a toned down version of 
> option 4, 
> > > > but basically I agree - its just a matter of finding the right 
> > > > words. Let's see what other opinions we get.
> > > > 
> > > > John
> > > > _______________________________________________
> > > > Sipping mailing list  
> > https://www.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP Use 
> > > > [e-mail] for questions on 
> current sip Use 
> > > > [e-mail] for new developments of core SIP 
> > > > _______________________________________________
> > > > Sipping mailing list  
> > https://www.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP Use 
> > > > [e-mail] for questions on 
> current sip Use 
> > > > [e-mail] for new developments of core SIP
> > > > 
> > > 
> > _______________________________________________
> > Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP 
> > Use [e-mail] for questions on current 
> > sip Use [e-mail] for new developments of core SIP
> > 
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP