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

["Francois Audet" <[e-mail]>]

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