Subject: RE: [Sip] Comments on draft-ietf-sip-identity-06

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 22 Jun 2006 13:43:03 -0400

Regarding the Call-ID issue raised by Lakshminath, we did address this in a response to GEN-ART during the approval process of sip-identity. Unfortunately, that mail thread wasn't captured publicly anywhere.

The properties that the authors believe we derive from the Call-ID are described in sip-identity 13.1. The Call-ID is given in the hash in order to provide a nonce, of sorts, that helps verifiers to identify cut-and-paste attacks. The ability of an attacker to predict this nonce does not degrade the security of the mechanism in any way. The Call-ID alone, of course, would be insufficient to prevent a cut-and-paste attack; it is used in concert with the Date header especially to allow verifiers to record received Call-IDs during a Date interval in order to identify replays.

To your specific points:

> 1) This applies to _all_ the verifiers in a domain. If the verification 
> is done by a domains SIP servers (not the callee's user agent) then 
> they will have to use a distributed database or a single point of 
> failure database to remember the Call-Ids seen by _any_ of the 
> verifiers.

I agree that instantiating the verifier role on an intermediary can be onerus for a number of reasons. It is of course preferable for the Identity header to be verified directly by the UAS. Do note that that draft only requires Call-IDs to be remembered for the duration of the Date interval. I imagine that if multiple verifiers acted on a message, each might have its own repository for storing Call-IDs it has seen. Annoying, though, for intermediaries.

> 2) If the verification is done by the callee's end user agents, I 
> beleive it would be possible for an attacker to capture a request (say 
> a MESSAGE) sent from sip:bob@biloxi to sip:alice@atlanta, and then send 
> an identical MESSAGE with From: sip:bob@biloxi, To: sip:alice@atlanta 
> but Request-URI sip:carol@atlanta.

So, you mean basically forwarding a message to a third party. Yes, you can do that in any messaging system with any sort of message, signed or not, whether you are the intended recipient of the message or an eavesdropper. Only confidentiality properties, which sip-identity does not provide, can help you with this sort of thing. Most messaging systems, including SIP, have some concept that messages can be forwarded by intermediaries, and that the original target address may differ from the destination identified by intermediaries. This is in a nutshell the difference between the To and Request-URI fields.

> I'm not sure there will ever be a value for any attacker in doing this, 
> but it seems possible since Alice and Carol's user agents are very 
> unlikely to share information about previously seen Call-Ids. Even if 
> it seems to be a meaningless attack, it is still an attack, or have I 
> missed something making this impossible?
 
In what sense is forwarding a message an attack? Carol will be able to ascertain that the message was sent To: Alice, and her UA could apply automated policies to messages exhibiting this property. Or Carol the human could react to it if it were merely rendered by her UI. If messages to Alice mean nothing to Carol, they'll be discarded, either way.

It is worth noting that the sip-identity document is focused on preventing impersonation. While it might seem plausible to considering inappropriate forwarding of messages to be a form of impersonation, I wouldn't say that it is, within the scope of the draft. The original sender, destination, and content of the message are integrity-protected. Nothing is being impersonated. It's not like the attacker would be able to receive responses sent by Carol (if her UA responded) or somehow get involved with the media.

In any event, the relevance of this to the Call-ID is questionable. You seem to be arguing that the presence of the Call-ID in the hash was intended to prevent forwarding, and that it isn't working. That certainly was not the stated motivation for the inclusion of the Call-ID in the sip-identity draft. Even if you believe this sort of forwarding does constitute an attack, no properties of the Call-ID especially prevent or enable "attacks" of this sort.

> 3) This IS a problem if the Call-Ids generated by a UA is predictable, 
> although unique. I beleive RFC3261 doesn't say that Call-Ids must not 
> be predictable, even though it says they must be unique. For example, 
> say that Alice has a UA that produces sequential Call-Ids with the IP 
> address as 'what makes these unique'. Alice calls me, so I get her UAs 
> current Call-Id. She tells me that she is going to call 
> sip:[email-masked] right after our call. I want to prevent her 
> from doing that. 
>
> During our call, I send requests to example.org with 
> the Call-Id's I predict Alices UA will use. Alices call to 
> sip:[email-masked] will get rejected 

So, the idea is that you send a seemingly valid, signed request with the predicted Call-ID to sip:someone before Alice can send her request, so that sip:someone will reject Alice's request when it shows up because it has previously accepted a request with the same Call-ID from the same source.

Well, your primary problem with launching an attack like this would be controlling Alice's authentication service. You would have to, in order to be able to send a request with an Identity header posing as her. Guessing her Call-ID doesn't do you any good unless you can somehow construct the signed Identity header that her authentication service would generate for that Call-ID.

If you're considering requests sent without an Identity header, well, sip-identity can't help you with those. 

> Also, what makes subsequent requests in the same dialog as the first one 
> not get rejected? They will have the same Call-Id.

The CSeq, which is also included in the Identity hash. The same way that SIP differentiates individual transactions associated with a dialog.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Fredrik Thulin [mailto:[email-masked]]
> Sent: Wednesday, June 21, 2006 6:44 AM
> To: Drage, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [Sip] Comments on draft-ietf-sip-identity-06
> 
> [snip]
> I would think the Call-Id issues are the most important ones. Most of 
> the others are more opinions that I would not have posted if I had 
> realized the state of the document. This question was apparently also 
> raised by Brian Carpenter, or if it was Lakshminath Dondeti (from 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=pri
nt_ballot&ballot_id=769&filename=draft-ietf-sip-identity
) :

>Normally a hash of the message is stored and compared against for 
>replay protection in addition to things like integrity protected 
>timestamps (Date).  Does the Call-ID provide the same capability 
>(uniqueness)?

I haven't been able to see this question addressed anywhere, but I might 
not know where to look.

Possibly, the text suggesting that only the first request (for a 
specific From:) over a TLS session needs to be Digest-authenticated, 
could also be of the dignity that it needs adressing - since it is 
"merely" a matter of removing a sentence.

I cannot judge whether these issues are serious enough to request 
withdrawal from the RFC-ed queue, others will have to give their view.

/Fredrik

_______________________________________________
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

_______________________________________________
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: Fredrik Thulin <[email-masked]>
Date: Mon, 26 Jun 2006 10:29:41 +0200

My excuses for not being able to trim the response more, the different 
paragraphs seems connected to each other and the context necessary.

We definately seem to talk about two different things. Perhaps I have 
totally misunderstood the use of the Call-ID to prevent cut-and-paste 
attacks - let's hope so. After you read this message, I believe you 
will be able to tell if this is the case, in which case I would be very 
thankful if you could explain it to me. Thanks.

On Thursday 22 June 2006 19:43, Peterson, Jon wrote:
> Regarding the Call-ID issue raised by Lakshminath, we did address
> this in a response to GEN-ART during the approval process of
> sip-identity. Unfortunately, that mail thread wasn't captured
> publicly anywhere.

Ok.

> The properties that the authors believe we derive from the Call-ID
> are described in sip-identity 13.1. The Call-ID is given in the hash
> in order to provide a nonce, of sorts, that helps verifiers to
> identify cut-and-paste attacks. The ability of an attacker to predict
> this nonce does not degrade the security of the mechanism in any way.
> The Call-ID alone, of course, would be insufficient to prevent a
> cut-and-paste attack; it is used in concert with the Date header
> especially to allow verifiers to record received Call-IDs during a
> Date interval in order to identify replays.
>
> To your specific points:
> > 1) This applies to _all_ the verifiers in a domain. If the
> > verification is done by a domains SIP servers (not the callee's
> > user agent) then they will have to use a distributed database or a
> > single point of failure database to remember the Call-Ids seen by
> > _any_ of the verifiers.
>
> I agree that instantiating the verifier role on an intermediary can
> be onerus for a number of reasons. It is of course preferable for the
> Identity header to be verified directly by the UAS. Do note that that
> draft only requires Call-IDs to be remembered for the duration of the
> Date interval. I imagine that if multiple verifiers acted on a
> message, each might have its own repository for storing Call-IDs it
> has seen. Annoying, though, for intermediaries.
>
> > beleive it would be possible for an attacker to capture a request
> > (say a MESSAGE) sent from sip:bob@biloxi to sip:alice@atlanta, and
> > then send an identical MESSAGE with From: sip:bob@biloxi, To:
> > sip:alice@atlanta but Request-URI sip:carol@atlanta.
>
> So, you mean basically forwarding a message to a third party. Yes,
> you can do that in any messaging system with any sort of message,
> signed or not, whether you are the intended recipient of the message
> or an eavesdropper. Only confidentiality properties, which
> sip-identity does not provide, can help you with this sort of thing.
> Most messaging systems, including SIP, have some concept that
> messages can be forwarded by intermediaries, and that the original
> target address may differ from the destination identified by
> intermediaries. This is in a nutshell the difference between the To
> and Request-URI fields.
>
> > I'm not sure there will ever be a value for any attacker in doing
> > this, but it seems possible since Alice and Carol's user agents are
> > very unlikely to share information about previously seen Call-Ids.
> > Even if it seems to be a meaningless attack, it is still an attack,
> > or have I missed something making this impossible?
>
> In what sense is forwarding a message an attack? Carol will be able
> to ascertain that the message was sent To: Alice, and her UA could
> apply automated policies to messages exhibiting this property. Or
> Carol the human could react to it if it were merely rendered by her
> UI. If messages to Alice mean nothing to Carol, they'll be discarded,
> either way.

My problem isn't with the possibility to duplicate a message sent from 
sip:bob@biloxi to sip:alice@atlanta to a third party (like 
sip:carol@atlanta, with To: still being sip:alice@atlanta) - I 
understand that this is how things work in SIP when there are 
forwarding intermediaries. My problem is with sip-identity seemingly 
saying that if you do sip-identity verification, this can be avoided 
since you remember Call-ID's. The proposed cut-and-paste prevention 
mechanism with the Call-ID would indeed work if there was a central 
verification service for the destination domain, but not if the 
verification was done independently by Alice's and then Carol's UA's 
(because they would not likely share Call-ID's-seen state).

...
> In any event, the relevance of this to the Call-ID is questionable.
> You seem to be arguing that the presence of the Call-ID in the hash
> was intended to prevent forwarding, and that it isn't working. That
> certainly was not the stated motivation for the inclusion of the
> Call-ID in the sip-identity draft. Even if you believe this sort of
> forwarding does constitute an attack, no properties of the Call-ID
> especially prevent or enable "attacks" of this sort.

When you say 'hash' I presume you are talking about the signature 
created and put in the Identity header, right? If so, then no - that's 
not at all what I am talking about. My problem with the Call-ID is the 
_other_ use for it, described in sip-identity, namely the verifier 
remembering it for about an hour to detect cut-and-paste attacks.

The part of the draft that I interpret as saying this is the following 
from section 13.1 :

   Implementations MUST also record Call-IDs
   received in valid requests containing an Identity header, and MUST
   remember those Call-IDs for at least the duration of a single Date
   interval (i.e., commonly 3600 seconds).  Because a SIP-compliant UA
   never generates the same Call-ID twice, verifiers can use the Call-ID
   to recognize cut-and-paste attacks; the Call-ID serves as a nonce.
   The result of this is that if an Identity header is replayed within
   the Date interval, verifiers will recognize that it is invalid
   because of a Call-ID duplication;

> > 3) This IS a problem if the Call-Ids generated by a UA is
> > predictable, although unique. I beleive RFC3261 doesn't say that
> > Call-Ids must not be predictable, even though it says they must be
> > unique. For example, say that Alice has a UA that produces
> > sequential Call-Ids with the IP address as 'what makes these
> > unique'. Alice calls me, so I get her UAs current Call-Id. She
> > tells me that she is going to call
> So, the idea is that you send a seemingly valid, signed request with
> the predicted Call-ID to sip:someone before Alice can send her
> request, so that sip:someone will reject Alice's request when it
> shows up because it has previously accepted a request with the same
> Call-ID from the same source.

Yes.

> Well, your primary problem with launching an attack like this would
> be controlling Alice's authentication service. You would have to, in
> order to be able to send a request with an Identity header posing as
> her. Guessing her Call-ID doesn't do you any good unless you can
> somehow construct the signed Identity header that her authentication
> service would generate for that Call-ID.

I don't see why I would have to control Alice's authentication service. 
As I understand the part of 13.1 about remembering Call-ID's to prevent 
cut-and-paste attacks, you are _only_ looking at the Call-ID, not 
sender+Call-ID. I could therefor let my own authentication service sign 
requests with the Call-ID I predict Alice's UA will use from me to 
sip:someone, and send them to sip:someone. sip:someone's verification 
service will verify my signature as valid, and remember the Call-ID as 
previously used for about an hour. When Alice's request reaches the 
validation service of sip:someone it will be rejected because of 
Call-ID duplication, as I read the part of 13.1 that I quoted above 
("Implementations MUST also record Call-IDs...").

> > Also, what makes subsequent requests in the same dialog as the
> > first one not get rejected? They will have the same Call-Id.
>
> The CSeq, which is also included in the Identity hash. The same way
> that SIP differentiates individual transactions associated with a
> dialog.

In the hash, yes (if you mean the signature put in the Identity header), 
but not as a component in the algorithm to detect cut-and-paste 
attacks.

/Fredrik