> -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@xxxxxxxxxxxxxxxxxx] > Sent: 24 October 2008 12:19 > To: Elwell, John; Dean Willis > Cc: sipping@xxxxxxxx > Subject: RE: Decision needed on final issue with > draft-ietf-sipping-update-pai-07 > > To try and put it into words. > > If you have a proxy acting as both inbound proxy and outbound > proxy and > providing authentication of the user (all of which are pretty much a > given for RFC 3325 usage of P-Preferred/Asserted), and if on > authenticating a user on a previous request you create some sort of > security binding for that user (e.g. a TLS session), then any > responses > received over that binding presumably relate to that > authenticated user. > That binding can be created at any time (although at least some > implementations will do it at registration), and I believe TLS session > reuse is not uncommon, indeed preferred. [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? > > I guess there is still one more assumption here in that the > authenticated identity of the user relates to all transactions used > within that binding, but I guess that is the reason why we have > P-Preferred in the first place, so that if there are three valid > identities for that user, the user can indicate which one is > in use. So > if this mechanism is used, the authentication and binding should exist > for all valid identities for that user, and not just for the > one used in > the request that created it. > > As Dean indicated, this would seem to work for both responses, and for > CANCEL/ACK, although personally I am not interested in CANCEL and ACK > carrying an identity. > > Have I missed any other implicit assumptions. > > I would note by the way that even for request authentication, if you > want to use straight digest authentication on requests with nothing > else, then you must do it on every request for which you issue an > identity otherwise it is meaningless. I understand that many digest > implementations do not challenge every request. [JRE] Understood. John > > Regards > > Keith > > > -----Original Message----- > > From: sipping-bounces@xxxxxxxx > > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Elwell, John > > Sent: Friday, October 24, 2008 7:11 AM > > To: Dean Willis > > Cc: sipping@xxxxxxxx > > Subject: Re: Decision needed on final issue with > > draft-ietf-sipping-update-pai-07 > > > > Dean, > > > > It seemed that to get the draft through IESG, it needed to > > cite at least one mechanism by which a response can be > > authenticated (likewise ACK and CANCEL). The mechanism in > > earlier drafts, whereby the response is received over a TLS > > connection over which digest authentication had previously > > taken place, was shown to be flawed. Nobody seemed able to > > offer a robust and standardised alternative. If somebody can > > put forward a robust and standardised alternative that can > > convince those with concerns, I would be happy to re-instate > > the response stuff. > > > > John > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@xxxxxxxxxxxxx] > > > Sent: 23 October 2008 19:46 > > > To: Elwell, John > > > Cc: sipping@xxxxxxxx > > > Subject: Re: Decision needed on final issue with > > > draft-ietf-sipping-update-pai-07 > > > > > > > > > On Oct 23, 2008, at 9:18 AM, Elwell, John wrote: > > > > > > > I need a decision on one outstanding issue. We previously > > > agreed that > > > > PAI could be used in any request. We recently agreed to remove > > > > specification of PAI in responses because there is no > > standardised > > > > means of authenticating a UAS. Brett Tate pointed out that > > > likewise there is > > > > no standardised means of authenticating a UAC when it sends > > > CANCEL or > > > > ACK (these cannot be challenged, and cannot be rejected if > > > > authentication is wrong). I have so far received no further > > > opinions > > > > on > > > > this. To be consistent I believe we have to make exceptions > > > of CANCEL > > > > and ACK and say that PAI cannot be used with these methods. > > > > > > > > If I receive no objections by 26th October I will update > > > the draft on > > > > 27th. > > > > > > The problems is that some network architectures DO allow > > > authentication of both responses and CANCEL/ACK. > > > > > > PAI is quite widely used in those networks. In fact, it > > came to us as > > > a P-header for use specifically in those networks. > > > > > > What is probably needed is an applicability statement > that explains > > > the environment in which PAI is usable in "digest authenticable > > > requests" , and goes on to explain the environment in > which PAI is > > > usable in other requests and responses. > > > > > > -- > > > 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 > > > _______________________________________________ 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
