Subject: [Sip] Preventing replay in ACK

From: Avshalom Houri <[email-masked]>
Date: Thu, 19 May 2005 03:32:15 +0300

RFC 3261 22.1

While a server can legitimately challenge most SIP requests, there
   are two requests defined by this document that require special
   handling for authentication: ACK and CANCEL.
   Under an authentication scheme that uses responses to carry values
   used to compute nonces (such as Digest), some problems come up for
   any requests that take no response, including ACK.  For this reason,
   any credentials in the INVITE that were accepted by a server MUST be
   accepted by that server for the ACK.  UACs creating an ACK message
   will duplicate all of the Authorization and Proxy-Authorization
   header field values that appeared in the INVITE to which the ACK
   corresponds.  Servers MUST NOT attempt to challenge an ACK.

Logic says the UA should recalculate the authorization headers (using ACK 
as method)
in order to prevent someone to send an ACK using the INVITE credentials.
However text says duplicate.

What is the right interpretation?

Avshalom
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Chadha Retesh-A19894 <[email-masked]>
Date: Thu, 19 May 2005 10:31:08 +0530

I dont think UA should re-calculate the authorization header, for ACK. This
is because ACK can not be challenged. Need of authorization header is only
to make sure, that the ACK is coming from already authenticated UAC.
 
Correct interpretation is to duplicate all of the Authorization and
Proxy-Authorization
  header field values that appeared in the INVITE to which the ACK
  corresponds.
 
Regards
Retesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Avshalom Houri
Sent: Thursday, May 19, 2005 6:02 AM
To: [email-masked]
Subject: [Sip] Preventing replay in ACK

RFC 3261 22.1 

Logic says the UA should recalculate the authorization headers (using ACK as
method) 
in order to prevent someone to send an ACK using the INVITE credentials. 
However text says duplicate. 

Avshalom

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 20 May 2005 14:34:52 -0400

The inability to challenge ACK and CANCEL is, in my mind, a pretty serious defect in the current SIP security situation. CANCEL's predicament is, ultimately, a lot worse than ACK's, though, since CANCEL is consumed hop-by-hop - at least one can have a reasonable expectation that an ACK request will arrive at its destination in roughly the same form that it was sent.
 
ACK's problem is simply that one cannot send a response to ACK. So firstly, this means a UAS or proxy could not challenge a request that does not contain an ACK - of course, ACKs could contain Digest headers even though it was not challenged in the first place (thanks to cached nonces and so on). More seriously, if a UAS receives an ACK that was, for some reason, invalid, they couldn't reject the message in any way that would be intelligbile to the UAC (the UAS could just tear down the dialog, but the UAC wouldn't really know why). So it's not clear that it does a whole lot of good in terms of enabling UAS policies to secure the ACK.
 
That much said, Mr. Worley is quite correct that if Digest 'auth-int' is used, the body of the ACK request will be covered by the Digest signature. It is also worth noting that sip-identity-05 allows the Identity header and surrounding apparatus to appear in ACK, which provides another avenue to body security. If the ACK were sent over a TLS connection that was established at the time that the initial INVITE was sent, then even if no Digest headers appeared in the ACK, the authentication service would be within its rights to apply Identity headers to the ACK request.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Avshalom Houri
Sent: Friday, May 20, 2005 9:03 AM
To: [email-masked]
Subject: Re: [Sip] Preventing replay in ACK

I mean send different ports in the SDP. How we can prevent this? These ports are not part of the digest. 

Avshalom 

"Dale Worley" <[email-masked]> 
Sent by: [email-masked] 

20/05/2005 06:11 PM 

To
<[email-masked]> 

cc

Subject
Re: [Sip] Preventing replay in ACK

> From: Avshalom Houri [[email-masked]]
>
> I may be missing something but how we do prevent someone to listen on the
line
> and send an ACK containing different ports etc. using the INVITE
credentials?

Presumably those port numbers are covered by the digest authentication hash,
and so cannot be forged.

Dale