Subject: [Sip] Review of draft-kuthan-sip-derive-00

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Nov 2008 08:51:32 -0600

$Id: draft-kuthan-sip-derive-00-rev.txt,v 1.1 2008/11/15 20:48:48 ekr Exp $

This document is intended to provide caller identification for SIP
dialogs without the use of RFC 4474 Identity. The basic principle is
that when Alice calls Bob, Bob initiates a dialog in the reverse
direction (using the RFC 4235 Event Package). This message is assumed
to be routed correctly in the reverse direction and thus provides
independent confirmation of the call to Bob.

This draft has only a very short security considerations, so it's
not clear what threat models it's intended to defend against.

CUT-AND-PASTE
However, unless I've misunderstood the design, there's at least
one significant attack, namely INVITE forwarding plus cut and
paste attack. This works as follows:

Alice            Attacker             Bob
-----------------------------------------
INVITE ------------->
                    INVITE ------------->
                    
<------------------------------ SUBSCRIBE
NOTIFY --------------------------------->

                    <------------- 200 OK
                    <------- RTP ------->

The attacker somehow convinces Alice to send him an INVITE. The
attacker forwards it to Bob, rewriting the request line and 
the SDP.  As specified by the draft, Bob then sends a
SUBSCRIBE towards Alice. This gets there and Alice responds with the
appropriate NOTIFY--because Alice actually is in-dialog with the
attacker. This NOTIFY looks OK, and Bob accepts the call, with Alice's
identity displayed in caller-id.

I believe this attack actually works as I've described it with the
examples shown in S 7.1, which don't contain any identity values in
the NOTIFY. However, one countermeasure you might try is to try
is to compare identity values, in particular the To line (remember
that you can't compare the URI in the request because those
can get transformed, hence the need for History). Unfortunately,
since call forwarding is a legitimate service, there are reasons
why the To received by Bob might not match what was in Alice's
original INVITE, so if you rely on this check you'll get a lot
of false positives, which seems problematic. 

Note that even cryptographic protection a la DTLS-SRTP doesn't help
here, because the attacker can simply rewrite that part of the SDP to
contain his own cryptographic parameters as well as whatever IP
addresses he wants to put in the SDP.  It's interesting to contrast
this with RFC 4474, which doesn't have this problem because the SDP is
integrity protected.  Of course, it would be possible to modify this
mechanism to provide protection against SDP modification by having
Alice provide the session description in the NOTIFY (S 4.1.6.3 of RFC
4235, I think). However, as I understand this design, it's explicitly
an attempt to avoid RFC 4474 full protection of the message.

Note that there's an even more obvious attack of this flavor from
one of the proxies, where it just modifies the media parameters. 
That's not really discussed in the threat model, but I'm assuming
the authors think they're designing hop-by-hop security here.

ATTACKING THE CONFIRMATION STAGE
The previous attack relied on attacking the INVITE and allowing
the confirmation stage to proceed unmolested. Another form of
attack is to attack the confirmation stage. Again, say that
the attacker wants to impersonate Alice. He sends an ordinary
invite to Bob's proxy with From: [email-masked]. He then
uses DNS cache poisoning to hijack the connection to Atlanta.

Now, if Bob tries to use SIPS, this attack will fail, because
the attacker can't properly execute the TLS handshake with
Biloxi, but Biloxi and Bob have no way of knowing that Atlanta
can actually do TLS, so they can't safely insist on it, and
the attacker can always simulate being TLS-incapable if they
try opportunistic TLS. Note that this case is actually worse
than ordinary call hijacking because the attacker knows exactly
when Bob will do his DNS queries, which makes attacks easier.

HIGH LEVEL
It's probably useful to take a high level view of the matter.
Classically, we talk about two related security services:

1. Data origin authentication.
2. Message integrity.

This mechanism, like RFC 4474, is intended to provide both of these
services to some extent. In order to get DOA, we need the recipient to
be able to get *some* message that they can be sure was from the
sender. Once we have that, message integrity is a matter of tying that
single authentic message to the message to be protected.

With that in mind, while this system is completely different from RFC
4474, they occupy two points in a large and largely orthogonal design
space. I.e., the method of providing data origin authentication is
orthogonal to the method of providing message integrity and the data
to be protected. In particular, as noted above, it would be possible
to use a mechanism of this type to protect the entire message instead
of just pieces of it. Similarly, it would be possible to use RFC 4474
to protect only pieces of the message, as has been described in
multiple drafts.

As another example of this, consider a hybrid solution that uses 
S/MIME signatures but DOA via SUBSCRIBE (at least partly):

  Every node has a self-signed S/MIME certificate and signs all
  its messages. When a node receives a message from a node its
  never heard from before, it does a SUBSCRIBE to the sending
  node's certificate. Once it has received it, it can then
  verify all future messages.

It should be apparent that this mechanism has aspects of both the
RFC 4474 designs and this design. Moreover, one could choose to sign
all or only some of the message, further expanding the design space.

>From this perspective, this particular set of points in the design
space has two weaknesses:

1. The DOA mechanism isn't particularly strong (as indicated by
   the DNS spoofing attack described above). The problem here is
   that in order for it to work it requires a TLS path all
   the way to the (putative) sender. Since there's no guarantee
   of this existence, failures are hard to decode. Note that
   by contrast, RFC 4474 only requires the *sender* to have
   a certificate.

2. The message integrity mechanism doesn't cover enough of the
   message, making media hijacking attacks easy. Again, RFC 4474
   covers more of the message, blocking this sort of attack.

None of this is to say that there isn't room for another point
in the design space than RFC 4474. However, rather than randomly
selecting points in the space and trying them on for size, we
should try to figure out what we're trying to achieve on both
of these axes and then design specific mechanisms that achieve
these ends.

-Ekr

_______________________________________________
Sip mailing list  https://www.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: Adam Roach <[email-masked]>
Date: Thu, 20 Nov 2008 09:40:19 -0600

> of these axes and then design specific mechanisms that achieve

I think the greatest appeal of an approach like the one in DERIVE, if it 
can be made to work, is that it requires no explicit support on the 
calling party's side. Ideally, we'd like something that I could go back 
to my office, code up, and begin using without waiting for anyone else 
to catch up. (I am, after all, the beneficiary of this behavior -- not 
the caller -- so I have a far greater interest in deploying something 
like this than they do). This proposal is not the result of picking a 
random point in the solution space and exploring its properties -- it is 
the result of actively seeking a solution with this precise property, 
and then examining what other properties it exhibits.

That said, the DERIVE approach has at least one major shortcoming if 
viewed as a mechanism in isolation: it allows you to ask the question, 
"does the AOR in this call  setup request correspond to the device 
calling me?," but the only answers you can get are "yes" and "maybe."

This does not mean that it is without use; it means that it is one input 
to a larger system at the called party's user agent. Ultimately, I fear 
that fighting unsolicited/unwanted communications in SIP will require a 
multi-pronged approach -- one that does not necessary require support 
for any specific mechanisms on the calling party's UA. That means we 
need an entire box of tools to handle various conditions. I think DERIVE 
is potentially a useful tool in that toolbox.

/a

---

From: Raphael Coeffic <[email-masked]>
Date: Thu, 20 Nov 2008 15:41:56 +0100

First of all, thanks to Eric for this extensive (whereby quite late...) 
review. Please find my questions inline.

-Raphael.

> paste attack. This works as follows:

I believe that the counter measure that you are proposing has already 
been adressed in the draft. Concerning call forwarding, we know that 
this is an issue. But I still don't understand why checking the To in 
the SUBSCRIBE should generate a false positive. In this case, Alice 
would refuse to reply to the SUBSCRIBE, as it does come from any party 
Alice has sent an INVITE to.

> services to some extent. 
Could you please explain why you think that we are trying to provide 
message integrity (apart from the "From")?

> In order to get DOA, we need the recipient to

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Nov 2008 11:19:26 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
> Roach
>
> calling party's side.

That's not totally accurate, methinks.  It requires support for the dialog-event package on the UAC, and requires the UAC to allow some random far-end UA outside its domain that it does not know about to subscribe to it.  [And it requires the path between the UAC and UAS to not contain b2bua's that change call-id or tag, of course]

The set of deployed devices/paths which satisfy those requirements is not the universe, but then again it's not the null set either. ;)

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Nov 2008 10:41:44 -0600

At Thu, 20 Nov 2008 15:41:56 +0100,
> Alice has sent an INVITE to.

The problem here is the notion of "sent an invite to". When you try
to call my cell and it gets forwarded to my landline, you indeed
tried to call me, but you will refuse to confirm the call.

> message integrity (apart from the "From")?

Right. You're providing minimal message integrity for the From 
(and, if you use the above countermeasure, the To).

-Ekr

---

From: Raphael Coeffic <[email-masked]>
Date: Thu, 20 Nov 2008 16:48:54 +0100

> tried to call me, but you will refuse to confirm the call.
Exactly. But that won't prevent you from answering this call. We can 
just make no assumptions on the "From" in this case. This is a "maybe".

> (and, if you use the above countermeasure, the To).
I'm not quite sure this is correct. The From could even have been 
changed on the way. As long as the change is reverted back during the 
check, we do not care.

-Raphael.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Nov 2008 10:57:22 -0600

At Thu, 20 Nov 2008 16:48:54 +0100,
> just make no assumptions on the "From" in this case. This is a "maybe".

I would call that a false positive. 

Pretty much *any* data origin authentication mechanism only gives you
one of two answers: yes or maybe, since it's always possible the 
signature/MAC/whatever was just broken along the way somehow. 

> changed on the way. As long as the change is reverted back during the 

I'm not sure what that means.

-Ekr

---

From: Adam Roach <[email-masked]>
Date: Thu, 20 Nov 2008 11:11:54 -0600

On 11/20/08 10:19 AM, Hadriel Kaplan wrote:
> That's not totally accurate, methinks.  It requires support for the dialog-event package on the UAC, 

We've established that -- "28% and likely to increase" is a good 
starting point.

> and requires the UAC to allow some random far-end UA outside its domain that it does not know about to subscribe to it.

This isn't some random far-end UA that the calling party has no reason 
to trust -- the dialog event package explicitly talks about 
authentication based on knowledge of the dialog identifiers.

> [And it requires the path between the UAC and UAS to not contain b2bua's that change call-id or tag, of course]
>   

Unless they also accommodate DERIVE. That's a known property of B2BUAs: 
you tend to need to update them whenever you want to do something new. 
Presumably, if the market asks for it, B2BUAs will address the issue.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Nov 2008 12:38:26 -0500

> From: Adam Roach [mailto:[email-masked]]
> Sent: Thursday, November 20, 2008 12:12 PM
> >

Riiiight.  First, it was 28% at an earlier sipit and 16% at the most recent one - sounds like a massive decrease to me. ;)  But more seriously, in my experience the time between implementation and testing at sipit, and actual deployment in the field, is often measured in YEARS for anything but trivial features.  Obviously that's just my particular view, but my general point is it's a change on the UAC from TODAY, no matter how we spin it.

> > and requires the UAC to allow some random far-end UA outside its domain
> that it does not know about to subscribe to it.

Ahh, ok.  My mistake.  So you'll only need operators to allow Subscribe's for such a package to get in from other domains. :)

> Presumably, if the market asks for it, B2BUAs will address the issue.

As I've tried to explain, it is not technically possible for B2BUA's to "address the issue" to stop changing call-id's, because it's their customers who want them to change it.  You might as well ask them to stop being b2bua's.  DERIVE will not make that happen.

-hadriel

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 20 Nov 2008 18:57:34 +0100

Raphael Coeffic wrote:

> this is an issue.

There are two such. The caller may have call forwarding setup --> DERIVE
test will fail. There is not much we can do about that. The other is callee
may have call forwarding setup and may wonder if To in INVITE can be used
for DERIVE test even though he is not registered under it. If he is consent
with using it (which he should be able to), the caller will receive
a legitimate DERIVE test. So what I really think may fail here is 
inconsistent
rewriting From/to by middleboxes.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 20 Nov 2008 19:09:04 +0100

Thank you for the extensive review indeed.

Eric Rescorla wrote:
> can get transformed, hence the need for History). 

Agreed. Generally there is no MiTM attack against which DERIVE is safe,
be it mounted on DNS or SIP.

> Unfortunately,

By the SIP standard, the To URI shall remain unchanged, but if Call
Forwarding is deployed, Bob ([email-masked]) may wonder if it makes
sense to launch a DERIVE test with such a URI ([email-masked]).
That would be workable (I do have all my email addresses configured
in my central procmail too....)

What makes me more worried here is the B2BUA traversal. If TO is changed
and is not consistently translated for DERIVE query, we will get a negative
DERIVE test result.

--

This has not been really DERIVE's purpose, but it seems it would be
helpful for the WG to revisit the phenomena of B2BUA. (the kind of
study what they do, why they do it, what they break by doing what
they are doing, and how to fix it.)

> an attempt to avoid RFC 4474 full protection of the message.

yes.

> when Bob will do his DNS queries, which makes attacks easier.

agreed.

> It's probably useful to take a high level view of the matter.

I agree; the "DERIVE question" is primarily about whether we want
to have better-than-nothing security or not, and I think that's the
key question to ask ourselves.

Particularly here we are not really promising determining identity,
but cryptographically unsecured reverse routing check. We cannot
answer "who are you", but we can answer "where are you" (and still
have residual uncertainty because we don't use cryptography to
establish that).

I think this can be still useful provided we document well the
limitations. For some practical purposes, it is "good enough" -- say
if someone is using your URI in a request to me, this type of
check can detect the request as uncertain.

In the non-SIP world, I would compare it to SPF. In fact even SPF
could be a legitimate answer along the better-than-nothing security.
The key difference here is if we are interested in domain-level
or per-call verification granularity.

> 1. Data origin authentication.

in this context, I think that DERIVE and alike can provide a weak
assertion for 1 and none for 2. (unless we combine those with
additional techniques, which would however weaken the promise
of simplicity)

>    the DNS spoofing attack described above). 

agreed.

>    The problem here is

well I think DERIVE is weaker in that does not give any real
integrity at all.

> of these axes and then design specific mechanisms that achieve

I think the key point here is what you call DOA, and at the same time
simplicity. I think if we try to indirectly compare it to RFC4474
this is value small in size compared to RFC4474 (particularly if we
realize the limitations such as MiTM vulnerabilities) but promising
in use (it is easily deployable, has an adoption path, and can help
to sort out some attacks that are now way too easy to mount.)

-jiri

---

From: Adam Roach <[email-masked]>
Date: Thu, 20 Nov 2008 13:16:05 -0600

> Ahh, ok.  My mistake.  So you'll only need operators to allow Subscribe's for such a package to get in from other domains. :)

Yes. One would hope this is something they're compelled to do anyway, as 
it allows the simpler version of the call completion service.

>   
>>> [And it requires the path between the UAC and UAS to not contain b2bua's
>>>       
>> that change call-id or tag, of course]
>>     

I'm not saying "stop changing Call-IDs." It's true that that's what I 
*want* to happen, but it's not the only way this can be made to work.

I'm saying "if you must, for business reasons, change Call-IDs going 
into and out of a network, make sure you perform the same mapping into 
and out of the network when you see the dialog event package." Again, 
this is something with value for the carrier itself, as it allows new 
services (such as call completion).

/a

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 20 Nov 2008 13:40:46 -0600

On Nov 20, 2008, at 11:11 , Adam Roach wrote:

>> and requires the UAC to allow some random far-end UA outside its  
>> domain that it does not know about to subscribe to it.
>
> This isn't some random far-end UA that the calling party has no  
> reason to trust -- the dialog event package explicitly talks about  

Would be really interesting to see how the deployed border security  
devices allowed or disallowed subscribes to the dialog-event.

Cullen <in my individual contributor role>

---

From: Adam Roach <[email-masked]>
Date: Thu, 20 Nov 2008 13:45:34 -0600

> devices allowed or disallowed subscribes to the dialog-event.

Perhaps, but I don't think we can hang on that. If there is market value 
for the work we do, they'll catch up. If there isn't, they won't. They 
serve business purposes -- which is both what makes them so ridiculously 
infuriating as well as what makes them highly likely to accommodate any 
specifications we product which have real-world utility.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Nov 2008 15:40:44 -0500

> services (such as call completion).

Ohhh.  But that's not the problem.  At least I hope that's not what people are talking about.  Most B2BUA's will map them back just fine.  The issue is your message may not go through *that same* B2BUA.
If the message is in-dialog, no problem.
If the message is out-of-dialog but uses the Contact-URI to route to, no problem (because the b2bua's replace that to be themselves). [note: gruu's can screw that up, but oh well]

The problem is if you send it to an *AoR*, such as the From-URI of another message, there's no guarantee it will go through the same sets of b2bua's to get fixed hop-by-hop.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Thu, 20 Nov 2008 14:46:41 -0600

On 11/20/08 2:40 PM, Hadriel Kaplan wrote:
> If the message is out-of-dialog but uses the Contact-URI to route to, no problem (because the b2bua's replace that to be themselves). 

But those B2BUAs are all in the same administrative domain. Given that 
fact, there are solutions to the problem, such as synchronized minimal 
state -- or, preferably, stateless reversible dialog identifier 
transformations. These things are pretty easy to implement at B2BUAs. 
And, if the market finds a use for the dialog event package, you'll need to.

I mean, really. You're smart. If someone offers you enough money to make 
this work in your product, you'll figure it out.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Nov 2008 16:58:32 -0500

> Sent: Thursday, November 20, 2008 3:47 PM
>
> But those B2BUAs are all in the same administrative domain.

Unfortunately they're not.
Alice calls Benny; Alice is in foo.com, Benny is in bar.com; foo.com b2bua sends it to pwned.com, which sends it to bar.com.  Benny then sends an out-of-dialog Subscribe to [email-masked].  There's no guarantee it will go through pwned.com on its way back there.
But anyway even just hitting a different b2bua at pwned.com will make it unlikely to work.  :(

> Given that
> state

Oh yeah that's fun.  We're nuts, not crazy. :)

> -- or, preferably, stateless reversible dialog identifier
> transformations.

We tried that - gets too big. (did I mention many devices appear to have finite header string length limits?)
Since this problem at some level is that the From-URI is being used instead of contact-uri, if you'd prefer we can also just munge the From-URI to identify the specific b2bua. Yuck. And it won't work if there are 2 pwned.com transit domains. And down the rabbit-hole we go...

Or we can go do this little thing like Session-ID. :)

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Thu, 20 Nov 2008 22:45:09 -0600

I'll repeat the most important argument from my previous email, which 
you elided in your response: You're smart. If someone offers you enough 
money to make this work in your product, you'll figure it out.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Nov 2008 01:28:33 -0500

> Sent: Thursday, November 20, 2008 11:45 PM
>

Don't flatter me - if I was smart I'd be retired.

And my marketing brain tells me the features that need a call-id match aren't important enough to make a complicated solution worth the expense, especially if they work most of the time today because the ends aren't many domains apart if any.  Once a deployment works, the guys trying to get a new feature to work or a new box into it have to make their stuff work with the deployed systems, not the other way around.  But I fear when peering grows and calls go across more domains, that stuff won't work across them; and I think we all need voip peering to work to grow voip traffic, for all of our business models.

So I'm proposing a simple solution: Session-ID.  It's trivially simple, cheap to implement, useful for several things, incrementally deployable, and it should work for a majority of cases.  It's not a novel idea: some of us create similar things in proprietary ways/places right now to handle some of the same use-cases.

I know adding yet another header sucks, and adding more matching options for already implemented stuff is even much worse.  It's a big deal. But it would be to all our advantage I think.(?)

-hadriel

---

From: Michael Procter <[email-masked]>
Date: Fri, 21 Nov 2008 12:39:51 +0000

Adam Roach wrote:
> Perhaps, but I don't think we can hang on that. If there is market
> value for the work we do, they'll catch up. If there isn't, they
> won't. They serve business purposes -- which is both what makes them
> so ridiculously infuriating as well as what makes them highly likely
> to accommodate any specifications we product which have real-world
> utility.
>
> /a

I'm not convinced we can paper over that problem so easily. There is a
tradeoff here in terms of business value for implementing the feature
versus increased risk of allowing the subscribes. We are not talking
about some small benign event package specifically designed for this
problem - we are talking about the mighty dialog event package. Once you
start allowing subscribes for this through into your corporate network,
you are only a minor bug or two away from a very embarrassing leak of
information.

Even if your border gateway sees what it considers to be a completely
reasonable and well-formed SUBSCRIBE (by whatever means it chooses), you
still need to trust the terminating UA[1] to correctly act upon the
filter, and not start a long-lived subscription to leak information
about all calls made in the next hour or so.

Not everyone will see the tradeoff the same way, but there is a
reasonably compelling case to say that leaking your CEO's call history
isn't a reasonable price for helping someone else's screening technique
say 'yes' rather than 'maybe'.

I, like Cullen, would be interested to see how deployed border security
devices react to subscribes to the dialog event package.

Best regards,

Michael

[1] This includes your CFO's really old phone that can't be upgraded,
because the last time it was touched, all the speed-dials for the
accountants were lost. It also includes your CTO's phone that is so new
and shiny it hurts. It downloads the latest firmware before the vendor
has even marked it as alpha. Needless to say, both phones take a
somewhat idiosyncratic view of SIP.
_______________________________________________
Sip mailing list  https://www.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: "Elwell, John" <[email-masked]>
Date: Fri, 21 Nov 2008 13:15:11 +0000

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jiri Kuthan
> Sent: 20 November 2008 17:58
> To: Raphael Coeffic
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sip] Review of draft-kuthan-sip-derive-00
> 
> Raphael Coeffic wrote:
> 
> test will fail. 
[JRE] Why will it fail? Call forwarding applies to the handling of
INVITE requests. SUBSCRIBE requests are not necessarily handled the
same, although I imagine that many implementations may do so, and
therefore your deduction is probably correct in many cases, but not
necessarily all cases.

John

>There is not much we can do about that. The 
> other is callee

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Nov 2008 09:34:15 -0500

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Thursday, November 20, 2008 2:41 PM
>

You mean this in the sense of "what their owners configure them to do", right?  Not in the sense of "whether the border devices could or could not pass it through".  I mean most if not all SIP border security devices that I know of that have real SIP control intelligence can be configured to block or allow subscription to the dialog-event package, or have it on their roadmaps if not already. (and by real SIP control intelligence I don't mean firewalls)  But I have no idea how many are configured to block vs. allow it in the field, and would love to know the answer as well.  I bet it's not many, because the package is not used much yet.

-hadriel

---

From: Jiri Kuthan <[email-masked]>
Date: Sat, 22 Nov 2008 01:07:55 +0100

> therefore your deduction is probably correct in many cases, but not

The point is not that it possibly may succeed. The point is that it
possibly may fail because symmetric forwarding is simply not guranteed.
Therefore we know positive DERIVE tests provide us with value, negative
don't.

-jiri