Re: [Sipping] Decision needed on final issue with draft-ietf-sipping-update-pai-07

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

Dean,

I am looking for somebody to provide some text that could replace or add
to the text in section 3.3, paragraph beginning "Section 5 of RFC 3325
requires". I spoke to Keith yesterday and I think he will try to do so.
Nobody objected to the consensus call to remove the response stuff, and
therefore as editor I removed it. As much as I personally would like to
include PAI in responses in this draft, I have to go along with the WG
consensus, which, until a couple of days ago was to remove it.

If somebody wants to have it re-instated, they should provide the text
AND convince those who objected to the existing text. I am not going to
take the lead.

John


> -----Original Message-----
> From: Dean Willis [mailto:dean.willis at softarmor.com] 
> Sent: 24 October 2008 22:46
> To: Elwell, John
> Cc: DRAGE, Keith (Keith); sipping at ietf.org
> Subject: Re: [Sipping] Decision needed on final issue with 
> draft-ietf-sipping-update-pai-07
> 
> 
> On Oct 24, 2008, at 7:55 AM, Elwell, John wrote:
> 
> >>
> > [JRE] This was the example given in earlier drafts, and removed  
> > because
> > it is broken. There is nothing to bind together the entity  
> > authenticated
> > by digest and the entity terminating TLS. A request certainly has to
> > come via the entity that terminates TLS, but this need not 
> be the same
> > entity that originates the request. So we could have the following
> > situation:
> >
> > +-----+
> > | UA1 +--------+
> > +-----+        |        +---------+        +---------+
> >               +--------+         |        |         |
> >                        | Proxy 1 +--------+ Proxy 2 |
> >               +--------|         |        |         |
> > +-----+        |        +---------+        +---------+
> > | UA2 +--------+
> > +-----+
> >
> > Proxy 2 accepts an inbound TLS connection and over that 
> receives a SIP
> > request, which it challenges. The next SIP request contain correct
> > credentials for UA1. Proxy 2 then receives a further SIP 
> request. How
> > does it know that it comes from UA1 and not UA2, say? In 
> other words,
> > how does proxy 2 know that there is a proxy 1 (or some 
> other form of  
> > SIP
> > intermediary) between it and UA1?
> 
> This scenario drove the requirement for a "P-Asserted-By" header, so  
> the transitivity could be tracked. We don't have that header  
> defined . . .
> 
> However, there are architectures for which the UA can issue a valid  
> digest in the response, since the "challenge" per se is 
> handled at the  
> SIM level.
> 
> --
> Dean
> 
> 
_______________________________________________
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