RE: [Sip] Authentication and ACK

["Shan Lu" <shanlu@sentito.com>]

I don't think hop by hop is a problem. From the perspective of
authentication server/stateless proxy, the ACK is either for an INVITE
that has passed authentication or for an INVITE that has failed
authentication. Any stateful entities that ACK non-2xx final responses
would have no difficulty duplicating the same Authorization header, if
any, from INVITE. 

I agree it is subject to replay attack. But isn't it better than blindly
proxy each and every ACK that is received at stateless server ?

Regards,

Shan Lu

>-----Original Message-----
>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf 
>Of James Undery
>Sent: Thursday, July 25, 2002 3:39 AM
>To: seshashayi@hss.hns.com; Jiri Kuthan
>Cc: Shan Lu; IETF SIP Mailing List
>Subject: RE: [Sip] Authentication and ACK
>
>
>You also have to remember that ACKs for non-2xx final 
>responses are generated hop by hop and so can't contain any 
>"useful" authentication. (Unless everyone in the network can 
>authenticate you ;-)
>
>James
>
>> -----Original Message-----
>> From: seshashayi@hss.hns.com [mailto:seshashayi@hss.hns.com]
>> Sent: 25 July 2002 07:17
>> To: Jiri Kuthan
>> Cc: Shan Lu; IETF SIP Mailing List
>> Subject: Re: [Sip] Authentication and ACK
>> 
>> 
>> 
>> 
>> Hi,
>>      If the Authorization header is duplicated from INVITE to ACK,
>> is it that servers are not supposed to treat such requests
>> as replay attacks even though a previous request arrived with
>> the exact same nonce-count ? This is fine
>> in case of stateful proxies, but are stateless proxies also
>> expected to maintain such state information to determine whether
>> the ACK credentials are valid ?
>> 
>> Rgds
>> Seshu
>> 
>> 
>> 
>> 
>> Jiri Kuthan <kuthan@fokus.gmd.de> on 07/25/2002 11:52:00 AM
>> 
>> To:   "Shan Lu" <shanlu@sentito.com>, "IETF SIP Mailing List"
>>       <sip@ietf.org>
>> cc:    (bcc: Seshashayi T/HSSBLR)
>> 
>> Subject:  Re: [Sip] Authentication and ACK
>> 
>> 
>> 
>> 
>> Actually, there is no security in ACK unless you use secure 
>transport.
>> Resending INVITE credentials in ACK can be easily attacked 
>by a replay
>> attack. Whichever requirement strength you'ld like to put on sending
>> credentials in ACK, don't expect security to improve.
>> 
>> -Jiri
>> 
>> At 12:14 AM 7/25/2002, Shan Lu wrote:
>> >Hi,
>> >
>> >RFC3261 says server must not challenge ACK. It also says that UACs
>> >_will_ duplicate Authorization header of INVITE in ACK. I 
>> believe this
>> >"will" strength is too weak. Think of a stateless proxy 
>that performs
>> >authentication. If it receives an ACK with no credentials, 
>> it knows it
>> >should not challenge the ACK. But what does it do? It has 
>two options
>> >and it will have a hard time figuring out when to do what:
>> >
>> >1. Drop it. But an ACK may be legitimately without 
>> credentials (like ACK
>> >for 200) and should be sent along.
>> >
>> >2. Proxy it. But the INVITE may have been challenged (ACK 
>> for 407) and
>> >the UAS will receive ACK out of the blue. Not detrimental 
>> but certainly
>> >not nice.
>> >
>> >So I think the "will"  requirement on UAC to include same 
>> Authorization
>> >header as INVITE in ACK needs to be strengthened to "MUST" level.
>> >
>> >Regards,
>> >
>> >Shan Lu
>> >
>> >sentitO Networks
>> >
>> >
>> >_______________________________________________
>> >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> >This list is for NEW development of the core SIP Protocol
>> >Use sip-implementors@cs.columbia.edu for questions on current sip
>> >Use sipping@ietf.org for new developments on the application of sip
>> 
>> 
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>> 
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip