Keith, We are talking about requests received from outside a trust domain. John > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@xxxxxxxxxxxxxxxxxx] > Sent: 24 October 2008 14:03 > To: Elwell, John; Dean Willis > Cc: sipping@xxxxxxxx > Subject: RE: Decision needed on final issue with > draft-ietf-sipping-update-pai-07 > > 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
