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. 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. 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
