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

From: "Elwell, John" <[email-masked]>
Date: Thu, 02 Oct 2008 17:37:29 +0100

Cullen,

I must admit to being very confused by all this. On 3rd September you
wrote:
"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."
Where option 4 (sent by me earlier that day) stated:
"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."

Whilst the words used in draft-06 might not be exactly what you had in
mind for option 4, in my opinion they do reflect option 4, and if not
can be adjusted to make it clearer. However, now you seem to be saying
that there is no way we will get something along the lines of option 4
through the IESG. So where exactly do we stand? Are there further minor
changes we can do to make the response stuff acceptable (given that
defining a specific mechanism will be a separate task, outside the scope
of this present work)? Or do we have to propose to the group that we
strip out all the response stuff?

John

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 26 September 2008 00:27
> To: Elwell, John
> Cc: Francois Audet; Mary Barnes; sipping
> Subject: Re: [Sipping] Further proceeding with 
> draft-ietf-sipping-update-pai--05
> 
> 
> Just as a note on what I have often seen from security ADs ...
> 
> If the document has a statement like, "Before exploding the 
> phone, the  
> UA MUST authenticate the request", often ADs look for there to be at  
> least one way to authenticate the request that is mandatory to  
> implement.
> 
> Cullen
> 
> On Sep 23, 2008, at 4:44 AM, Elwell, John wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Francois Audet [mailto:[email-masked]]
> >> Sent: 22 September 2008 17:22
> >> To: Elwell, John; Mary Barnes; Cullen Jennings
> >> Cc: sipping
> >> Subject: RE: [Sipping] Further proceeding with
> >> draft-ietf-sipping-update-pai--05
> >>
> >>
> >>>> 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.
> >>
> >> So are we talking about HTTP-digest here?
> > [JRE] Not necessarily.
> >
> > John
> 
> 
_______________________________________________
Sipping mailing list  https://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

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 2 Oct 2008 17:20:48 -0400

My apologies for the confusing email. I hope I was not confusing in  
saying in my view as an individual was that the right path is "where  
we say that PAI is not currently defined for responses but  future  
specifications may do so. " If there is anything I can say to make  
this clearer, please ping me on it and I will do my best. I want to be  
clear.  More below

> removed, or at least qualified."

When I read this, I was imagining that this draft was not going to  
have new work about how to make authenticated response identity work.  
It would not say that future RFC could not do this ... it would "leave  
it open" but it would not say how to do it here. The obvious  
implication of this to me (and I say obvious to me because I realize  
this was not obvious to others) was that this would mean we would not  
have identity in responses. My apologies for taking this the wrong way  
and introducing confusion.

I suspect that the work of  providing Identity in responses would be  
fundamental new security extensions of SIP and need to be done in SIP.  
I also personally believe that IESG is unlikely to pass an documents  
that says to implement the specification you have to authenticate a  
response but there is no defined way to do so. I will point out this  
exact topic of authentication of responses was extensively discussed  
in the work that lead to RFC 4916 where the WG came to consensus to  
not do this.

This is just my rough personal opinion and trying to explain reasons  
why - if you think this is the wrong direction, lets get on a phone  
call and talk about it with appropriate folks and try and sort out  
what makes sense.

Thanks, Cullen

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 03 Oct 2008 07:10:32 +0100

First, thanks Cullen for clarifying a confusing situation.

Second, to the SIPPING WG. Because of the views clearly expressed by
Cullen below (as an individual and as an AD), it seems we should remove
everything on responses in the update-pai draft, except to say that PAI
is not currently defined for responses but future specifications may do
so.

If I hear no objections to this approach by 2008-10-09 (1 week from now)
I will carry out the necessary edits and post an 07 version.

John 

> Sent: 02 October 2008 22:21
> To: Elwell, John