Re: [Sip] Authentication and ACK

[Jiri Kuthan <kuthan@fokus.gmd.de>]

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