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@xxxxxxxxxxxxxxxxxx]
> Sent: 23 October 2008 15:47
> To: Elwell, John; sipping@xxxxxxxx
> Subject: RE: 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@xxxxxxxx
> > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Elwell, John
> > Sent: Thursday, October 23, 2008 3:18 PM
> > To: sipping@xxxxxxxx
> > Subject: 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@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
