RE: [Sip] Authentication and ACK

["James Undery" <jundery@ubiquity.net>]

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