Subject: [stir] A possible exploit for stir

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 28 May 2014 20:21:58 +0000

Suppose a caller with TN1 is on a call with TN2, and TN2 is served by evil.com.

If evil sends TN1 a REFER to [email-masked], it should create, and sign, an INVITE From TN1, To TN3 and forward it to evil.

Evil can then call TN3, claim it’s from TN1 and exploit.

As a practical matter, TN1’s attempt to address a call to [email-masked] won’t actually work.  The domain will get rewritten, and the call will be routed by TN rules, and not domains.

But strictly speaking, an exploit like this is possible, and we should document it.  Devices should not create random extra calls based on a REFER to domains they don’t trust.

Paul Kyzivat pointed this possibility out in a discussion on how to handle a problem in another domain.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 May 2014 16:57:34 -0400

On 5/28/14 4:21 PM, Rosen, Brian wrote:
> If evil sends TN1 a REFER to [email-masked], it should create, and sign,
> an INVITE From TN1, To TN3 and forward it to evil.
>
> As a practical matter, TN1’s attempt to address a call to [email-masked]
> won’t actually work.  The domain will get rewritten, and the call will
> be routed by TN rules, and not domains.

I don't know if that is true or not. There are *many* ways of handling 
transfer.

In the cases I'm familiar with, some server in the domain of the party 
initiating the transfer wants to remain in the signaling and media 
paths. There are multiple reasons for this. Taking responsibility for 
the cost of the new call is one. Keeping control for "lawful" intercept 
is another.

In those cases, if the domain in control doesn't have signing authority 
for the number of the remaining party in the call, then it won't be able 
to sign the new call that way. It can probably sign on behalf of the 
departing party (transferrer). In some cases that may be acceptable, or 
even a feature. In other cases it might be a change from current 
behavior, for good or bad.

And are we sure that there aren't any practical cases where REFER would 
work without intervention?

> But strictly speaking, an exploit like this is possible, and we should
> document it.  Devices should not create random extra calls based on a
> REFER to domains they don’t trust.
>

Don't sell yourself short. You invented this exploit as a feature. I 
just recognized it as an exploit.

	Thanks,
	Paul

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 28 May 2014 23:38:11 +0000

Yes, there are many ways of implementing and handling transfer, so many
that it's difficult to get too specific about what the threat here might
be. The threats document already notes that "using transfer mechanisms
common in telephone systems, a callee can easily be connected to, or
conferenced with, telephone numbers other than the original calling number
once a call has been established." But evaluating the risks of this type
of transfer will be highly solution-specific, and for the moment we're
deferring solution-specific threats to the solution documents, rather than
the threat document.

Speculating along solution lines for a moment, this specific example begs
questions about replay protection, URL handling, REFER authorization and
many other issues. Any intermediary in a SIP call path can try to act as a
man-in-the-middle, and what this REFER really does is to bait a call to a
specific number so that an intermediary can man-in-the-middle it. We've
set the scope of STIR to explicitly not address man-in-the-middle attacks,
but perhaps the baiting dimension justifies addressing this.

Evil's ability to cut-and-paste the Identity token in the caller's INVITE
depends largely on the solution's scope of protection. It is possible to
create a scope of protection for a signature which is tied to the actual
source and sinks of media employed by the caller - this is the effect of
signing the SDP, for example. Of course the modification of those fields
by SBCs often renders this approach impractical. Maybe though for the case
where the caller receives a REFER like this, they would want to trigger
signing the SDP, and if the signature shows up broken, well, the callee
then would know not to trust the calling party number. Or maybe more
modestly, some other optional indication could be added to the
message/signature just to warn the recipient, "hey, this was a REFER, so
all bets are off."

To the URL handling question, if evil.com forwards a call To
sip:[email-masked] to gateway.com, what is the behavior we expect from
gateway.com? Is it different if "xyz" is a telephone number? Our
expectations is that requests will be routed differently to TNs, but this
is highly implementation-specific, despite our best efforts to standardize
behavior (see RFC3262 vs. RFC3824). But we may have an opportunity in
defining the STIR solution to propose authorization mechanisms for
gateway.com that could allow them to identify abuse more easily.
Ultimately, STIR is creating an Internet service that makes it possible to
figure out who has authority over telephone numbers: while we are
initially using that to answer the question of who should sign requests,
maybe it could also be leveraged to figure out that a call to TN3
shouldn't go to evil.com. That could be part of a REFER authorization
decision at the caller, even.

Jon Peterson
Neustar, Inc.

On 5/28/14, 1:57 PM, "Paul Kyzivat" <[email-masked]> wrote:

>> Evil can then call TN3, claim it¹s from TN1 and exploit.
>>
>> As a practical matter, TN1¹s attempt to address a call to [email-masked]
>> won¹t actually work.  The domain will get rewritten, and the call will
>> REFER to domains they don¹t trust.
>>
>_______________________________________________
>stir mailing list
>[email-masked]
>https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/li
>stinfo/stir&k=lQ50IrZ4n2wmPbDBDzKBYw%3D%3D%0A&r=8DMZR2OPVO0EflFSzDaVn8Q%2B
>31F1WQyjSQmLQXwHuHE%3D%0A&m=dSuvTgTyCXcnEPBvLhXaCRz2UjhIJMH4ckE9L3atntk%3D
>%0A&s=19d2d578965bf7e9937d402cde8b4502528251e7fd46ded654e7dd557fdf43b2

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 29 May 2014 01:04:43 +0000

Typical use of REFER in managed deployments is between the UE/Enterprise and the Carrier AS, and it does not transverse the NNI

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Wednesday, May 28, 2014 7:38 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [stir] A possible exploit for stir

Jon Peterson
Neustar, Inc.

_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 May 2014 10:32:02 -0400

Martin,

> Typical use of REFER in managed deployments is between the UE/Enterprise and the Carrier AS, and it does not transverse the NNI

Can you explain in a little more detail?
Are you describing the same approach I mentioned earlier in this thread?
(Repeating that:)

> for the number of the remaining party in the call, then it won't be
> able to sign the new call that way. It can probably sign on behalf of
> the departing party (transferrer). In some cases that may be
> acceptable, or even a feature. In other cases it might be a change from
> current behavior, for good or bad.

IMO this is a fine approach, if it provides the semantics that the 
transferring party wants. But it constrains what sort of signing is 
possible.

In particular, is it sufficient that the transferred-to party doesn't 
see the identity of the party to which he will be speaking?

	Thanks,
	Paul

---

From: Stephen Kent <[email-masked]>
Date: Thu, 29 May 2014 11:27:02 -0400

Jon,

You identified the central security issue here.

One should always include the intended target of a signed "thing"
under the signature, to avoid re-direction attacks. This is a common
security design principle and needs to be part of the STIR design, as a 
matter
of good practice. (The source is usually identified anyway, because 
that's needed
to select the right credential to verify the sig.)

Sorry I didn't jump in immediately when Brian posted his message.

Steve

---

From: Brian Rosen <[email-masked]>
Date: Thu, 29 May 2014 12:23:53 -0400

That doesn’t help.

A legitimate transfer has the same signaling, and would work.  If TN1 calls TN2 and TN2 desires to transfer the call to TN3, it sends a REFER to TN1 to do that.  TN1 responds with an INVITE to TN3.  Doesn’t matter if the phone or some B2BUA handles the transfer, it has the same effect.

If evil negotiates the media in that replacement call to replicate what is already in place for TN1 to TN2, neither party will be aware of any change.
But then evil can create a new call from anyone to TN3, claim it’s from TN1 and have the correct signature.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Thu, 29 May 2014 12:36:27 -0400

So, this problem is wrapped up in how domains and telephone numbers interact.  As a practical matter, we usually represent telephone numbers as sip:[email-masked];user=phone.

In some sense, the domain of this SIP URI is usually ignored.  When the origination service provider sees that construction, it treats it as a phone number.  The practical matter for most domains is that if you managed to get a subscriber, or proxy, in example.com’s domain, a uri of sip:[email-masked];user=phone, it is almost a certainty that somewhere in example.com that URI is going to be changed, or just ignored.  example.com will route the call by phone number, using number based routing decisions and not domain based decisions.  If the “user=phone” part wasn’t there, at least in theory, the call would be routed to evil, because the origination domain would assume it’s a normal sip URI with domain based routing that just happened to have a user with that string.  As a practical matter, I think that most service providers would reject such a call, or treat it as a telephone number and apply number based routing.

The way STIR works is that we canonicalize the TN.  We expressly ignore the domain, no matter what it is.  So sip:[email-masked];user=phone, and sip:[email-masked];user=phone will generate the same digest, because we extract the telephone number and ignore the rest.  That is essential to deal with how number based routing really works.

The problem arises only if the origination domain will route the call using domain based routing to evil.  If it doesn’t do that, and instead either rejects the call or ignores/rewrites the domain, then the exploit will fail.

If I were evil, I would try to REFER to sip:[email-masked].  That has the best chance of making it to evil.  If it did, it could rewrite it to sip:[email-masked];user=phone, and have the signature work.

Brian

On May 29, 2014, at 11:27 AM, Stephen Kent <[email-masked]> wrote:

> security design principle and needs to be part of the STIR design, as a matter
> of good practice. (The source is usually identified anyway, because that's needed

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 May 2014 14:25:03 -0400

> In some sense, the domain of this SIP URI is usually ignored.  When the origination service provider sees that construction, it treats it as a phone number.  The practical matter for most domains i…

This describes the perversion of SIP that has taken place.

According to 3261 a request URI of sip:[email-masked];user=phone 
is to be routed to evil.com. The interpretation of the user part as a 
phone number may *then* be done, and user=phone may be taken into 
account when doing that.

Ignoring the domain is an abuse of sip. Unfortunately it is one that is 
so pervasive that it seems impossible to "fix".

This means that we are left to decide what must be supported, and what 
need not be supported, without any written rules for what is correct and 
what is not.

	Thanks,
	Paul

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 31 May 2014 14:37:40 +0000

Paul

Yes. Sorry I missed it

Martin

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, May 29, 2014 10:32 AM
To: DOLLY, MARTIN C; Peterson, Jon; [email-masked]
Subject: Re: [stir] A possible exploit for stir

Martin,

	Thanks,
	Paul