Re: [Sipping] Decision needed on final issue withdraft-ietf-sipping-update-pai-07

["DRAGE, Keith \(Keith\)" <drage at alcatel-lucent.com>]

Well I am afraid that the text you have included in the existing
version, as detailed below, is not acceptable.

I believe it is usable with constraints in responses, and the text
implies that any RFC 3325 implementation is not allowed to support it.

I do have the discussion, but don't remember a consensus call on this
issue.

Regards

Keith 

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell at siemens.com] 
> Sent: Thursday, October 23, 2008 3:58 PM
> To: DRAGE, Keith (Keith); sipping at ietf.org
> Subject: RE: [Sipping] Decision needed on final issue 
> withdraft-ietf-sipping-update-pai-07
> 
> Keith,
> 
> The change concerning responses is already made in 07, as a 
> result of what seemed to be the consensus in SIPPING a couple 
> of weeks ago, after one of the ADs stated that it would not 
> stand a chance of getting through IESG. Therefore I 
> reluctantly made the change in 07. Nobody seemed to be 
> supporting the retention of the response stuff in there at 
> the time. It doesn't ban PAI in responses, it just does not 
> specify them, leaving it for a possible future update if/when 
> a standardised means of authenticating a UAS is available. 
> The relevant text is:
>     <t>RFC 3325 is unclear on the use of P-Asserted-Identity 
> in responses. In contrast to requests, there is no means in 
> SIP to challenge a UAS to provide SIP digest authentication 
> in a response. As a result, there is currently no 
> standardised mechanism whereby a proxy can authenticate a 
> UAS. Since authenticating the source of a message is a 
> pre-requisite for asserting an identity, this document does 
> not specify the use of the P-Asserted-Identity header field 
> in responses. This may be the subject of a future update to 
> RFC 3325. Also this document does not specify the use of the 
> P-Preferred-Identity header field in responses, as this would 
> serve no purpose in the absence of the ability for a proxy to 
> insert the P-Asserted-Identity header field.</t>
> 
> So now I just want to know what to do about CANCEL and ACK.
> 
> John
>  
> 
> > -----Original Message-----
> > From: DRAGE, Keith (Keith) [mailto:drage at alcatel-lucent.com]
> > Sent: 23 October 2008 15:47
> > To: Elwell, John; sipping at ietf.org
> > Subject: RE: [Sipping] Decision needed on final issue
> > withdraft-ietf-sipping-update-pai-07
> > 
> > > We recently
> > > agreed to remove specification of PAI in responses 
> because there is 
> > > no standardised means of authenticating a UAS. Brett
> > > 
> > 
> > So what exactly is the change you are making here.
> > 
> > As far as I am concerned RFC 3325 allowed PAI in responses. 
> There was 
> > some debate a long while ago on this but that is used by many 
> > implementations.
> > 
> > In the 3GPP case, it is based on the P-Called-ID header transferred 
> > internally, i.e. the request was delivered to this terminal 
> which was 
> > an authenticated user based on the registration, and a security 
> > association created at that time. Note that we are making some 
> > assumptions here, but those assumption are valid in this scenario.
> > 
> > So I do not believe you should be changing the underlying 
> RFC 3325 in 
> > this respect.
> > 
> > Regards
> > 
> > Keith
> > 
> > > -----Original Message-----
> > > From: sipping-bounces at ietf.org
> > > [mailto:sipping-bounces at ietf.org] On Behalf Of Elwell, John
> > > Sent: Thursday, October 23, 2008 3:18 PM
> > > To: sipping at ietf.org
> > > Subject: [Sipping] Decision needed on final issue
> > > withdraft-ietf-sipping-update-pai-07
> > > 
> > > 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.
> > > 
> > > John
> > > _______________________________________________
> > > Sipping mailing list  
> https://www.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP Use 
> > > sip-implementors at cs.columbia.edu for questions on current sip Use 
> > > sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP