In regard to the example given, I think the restrictions on the authenticator and the end point of the binding being one and the same are inherent in establishing a trust domain for RFC 3325 in the first place. The entity doing the the trust domain must be the first proxy reached and the entity doing the authentication, and is also the endpoint of any TLS session. How is this set up, well there are SIP extensions that allow one to do this, but I don't think we need to go into details of how trust domains are configured and used in this document. If these restructions are not always the case, and I have a hard time evisaging something that is not, then I have no problem in stating that as a condition for use in responses. Regards Keith > -----Original Message----- > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Elwell, John > Sent: Friday, October 24, 2008 1:56 PM > To: DRAGE, Keith (Keith); Dean Willis > Cc: sipping@xxxxxxxx > Subject: Re: Decision needed on final issue with > draft-ietf-sipping-update-pai-07 > > > > > -----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 > _______________________________________________ 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
