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@xxxxxxxxxxxxx] > Sent: 24 October 2008 22:46 > To: Elwell, John > Cc: DRAGE, Keith (Keith); sipping@xxxxxxxx > Subject: Re: 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@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
