Re: [Sipping] Further proceeding with draft-ietf-sipping-update-pai--05

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

 

> -----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...
[JRE] OK, I will try to propose some.

> 
> 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.
[JRE] They are supposed to be. Unless a proxy has authenticated the UA,
it has no right to assert an identity (unless just passing on an
assertion from an upstream entity that is trusted in accordance with
Spec(T)). Now whether this is adhered to in practice is another matter,
but I don't think we should relax this in an RFC.

John



> 
> 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