Subject: Re: [SIP] Request/Responses from other addresses

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 06 Jun 2000 09:24:14 -0400

While verifying CANCEL source address is somewhat useful, I wouldn't put
too much faith in it (or feel too bad about not implementing it). In the
realistic cases where somebody can intercept the original INVITE (and,
thus, know the To, From, CSeq and Call-ID needed to spoof the CANCEL),
the same person can probably also fake the source address. Intercept is
a likely possibility in old-style shared-medium (hubbed) LANs, either at
the source or destination. A rogue proxy server could obviously also do
intercept messages, but there are far easier and less conspicuous ways
to prevent a call from happening for such a server. An ISP could
intercept INVITEs, but once you are in the "middle" of the network,
source address filtering is rather difficult, so I doubt that relying on
source addresses in that environment helps much.

While CANCELs cannot be verified in the same way that INVITEs can, I
don't see why proxies couldn't sign them. At least, that would give you
some way to call in the Feds for illegal interference with
telecommunications services when all your calls are being cancelled. (I
suppose rogue CANCELs offer new ways for ILECs to convince their
departing customers that maybe the CLEC wasn't trustworthy to begin
with...) Also, if you have a signed CANCEL, you could, if sufficiently
paranoid, verify that it comes from a domain in the Via list of the
original INVITE.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "McMurry, Kathleen" <[email-masked]>
Date: Tue, 06 Jun 2000 13:09:43 +0000

So I am assuming that after performing the source address checks, the
correct behavior is to ignore the message that came from a bad source?

--Kathleen McMurry

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, June 05, 2000 5:11 PM
To: McMurry, Kathleen
Cc: Sean Olson; [email-masked]
Subject: Re: [SIP] Request/Responses from other addresses

"McMurry, Kathleen" wrote:
> 
> > > By different address you mean different source IP address, I'm
> assuming(?)
> > > (A different From: of course would not cause a problem -- the proxy
> could return a 481)
> > >
> > > I see no reason to state absolutely that the CANCEL or final response
> MUST come from
> > > the same IP address. There are obvious applications for exactly this
> scenario.
> >
> > For security purposes, actually, you really do need to check that the
> > CANCEL came from the same place as the request being cancelled (see the
> > minutes of the security task force on this). CANCELs cannot usefully be
> > authenticated directly, since they may come from proxies. That aside,
> > CANCEL can come from anywhere.
> >
> > As for responses, I'm really not sure. The spec says nothing about this,
> > as we had not considered it. It clearly requires some out-of-band
> > communications between the entity which received the request, and the
> > one which sent the response. I'm not sure what the application of that
> > would be. That aside, there may be problems. For requests sent over TCP,
> > the response is supposed to go over the same connection. Clearly it
> > cannot if the response is generated somewhere else. I suspect some
> > proxies may be upset if the connection to the server is open, and the
> > response comes on a different connection, opened just to send the
> > response. In the case of UDP, this will probably work, but you never
> > know.
> 
> Wouldn't you have the same security concerns with the response, since it
> would allow an entity to redirect a call that was not sent to it?

Yes, actually. Like CANCEL, a redirect response can be generated by a
proxy and also by a user agent. So, doing source address checks there is
probably a good idea. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 07 Jun 2000 01:55:04 -0400

Henning Schulzrinne wrote:
> telecommunications services when all your calls are being cancelled. 

Right; cancel signatures wouldn't give you any online protection since
you can't easily verify that the entity in the signature is, in fact,
the proxy which sent you the original request.

> Also, if you have a signed CANCEL, you could, if sufficiently

This gets confusing if IP addresses are used in the Via header
instead.... 

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 07 Jun 2000 08:32:37 -0400

> This gets confusing if IP addresses are used in the Via header
But probably still manageable, with somewhat more work (you'd have to
translate the domain of the signer to see if it matches the IP address).
Isn't perfect, but given that the attack requires a fair amount of
sophistication to begin with, I suspect that this will be an issue only
in very limited (high-assurance) situations. A paranoid implementation
could simply say "acme.com (signed) wants to cancel your call from
aol.com". Unless you (or the original destination) are in either the
acme or aol domain, it's very likely that this is a fake, regardless of
the precise IP address.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 07 Jun 2000 13:02:22 -0400

> acme or aol domain, it's very likely that this is a fake, regardless of

True. So, sounds like we have two solutions for CANCEL security:

1. source address validation, marginally useful
2. only accept CANCEL on an SA, and that CANCEL must be for a request
received over the SA
3. proxies sign CANCEL

Like any other security mechanism, there are pros and cons. Probably the
spec should mention all three.

-Jonathan R.

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 7 Jun 2000 13:29:48 -0400 (EDT)

> spec should mention all three.

There's another way to do CANCEL authentication; it's much lighter weight,
and more robust, but it requires some spec extensions.

When a proxy server proxies a request, it adds a hop-by-hop header
"Cancel-Lock:" identifying its domain and containing a secure hash (MD5 or
SHA/1) of some random string.  If that proxy server subsequently wants to
cancel the request, it inserts a "Cancel-Key:" containing the original
string.  A downstream server wanting to validate the CANCEL message simply
verifies that the Cancel-Key does indeed hash to the Cancel-Lock that was in
the original request.

As an example, if a UAS receives the following request:

INVITE sip:[email-masked] SIP/2.0
....
Cancel-Lock: example.com md5 d1a6fb27aa2a3c6ff4a181001dba4a20
....

Then the following CANCEL request should be accepted for this transaction:

CANCEL sip:[email-masked] SIP/2.0
....
Cancel-Key: example.com md5 This-is-my-cancel-key-129781234701924701234
....

This has, I believe, the correct properties for CANCEL: any device which has
been on the proxy chain for the initial request (including the initial UAC)
can cancel it, but no one else can.  No one has to have any security
associations or relationships outside of this particular transaction.

The main problem with this proposal is backward compatibility; it's not
clear what the right thing to do is if some devices on the proxy chain
support Cancel-Locks and others don't.

(The idea for this scheme is taken from a similar proposal for securing the
NNTP cancel cmsg.)

-- 
Jonathan Lennox
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 07 Jun 2000 13:57:48 -0400

> (The idea for this scheme is taken from a similar proposal for securing the

Assuming somebody can modify the INVITE request (or create a copy that
outraces the original to the UAS), this doesn't help much.

Presumably, you'd have to do the same thing with the BYE (assuming you
don't do end system authentication, i.e., you are only concerned about
an uninterrupted call once you've decided to speak to a person). It
would be nice if this worked for re-INVITE, too...

Frankly, given that there are for more "interesting" denial-of-service
attacks that require far less snooping effort, I wonder if this a
first-order problem. News is a bit different since anybody has all of
the information required to cancel anybody else's article, unless you
apply this proof-of-possession mechanism.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 08 Jun 2000 16:48:00 +0300

Henning Schulzrinne wrote:
> the same person can probably also fake the source address.

I agree. Source address validation does not seem that useful. If loose
source routing or strict source routing (provided by IP) are used the
source IP address is not even the last "host" that handled the packet.

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland