Subject: RE: [Sip] SMIME and active MITM attacks

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 21 Feb 2002 03:58:35 -0600

Thanks for your last-minute comments, Mike. Some good points here. To your
whole 'S/MIME self-signed cert key exchange in SIP is hopeless' point, as
we've discussed here many times before, we believe it's better than nothing.
Your message is getting through, but I still think we need this S/MIME
mechanism.

I also speak to one point below that I don't think we've discussed here
before.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2002 8:35 AM
> To: [email-masked]
> Subject: [Sip] SMIME and active MITM attacks
> 
> 
[snip]
> 
> The third thing I notice is that the reverse path
> seems to be completely broken. In it, the text in
> 22.1 says that although the message may signed
> against some certificate, the UAC cannot expect
> that the TO: address and the cert identity will
> will be the same. So, what security property is
> being enforced then? What prevents a hostile proxy
> from changing the contact address? How does the
> UAC know that it actually contacted who they
> expected? The answer seems to be "nothing" and "it
> can't".
> 

This is a general fact about SIP - that you can send a request To: Alice and
it can be legitimately retargeted To: Bob, and since the UAS doesn't
generate the identity in the To header of responses, you'll get a response
from Bob with a To: Alice header. Just like, say, call forwarding in the
PSTN. The caller has no idea whether Alice set up the call-forwarding
herself or if Bob broke into her PBX and hacked it in. In SIP, of course,
the caller can cryptographically authenticate the proxy server that manages
Alice's contacts (to make sure it really is Alice's proxy), and fortunately
thanks to S/MIME the caller can inspect a signature supplied by Bob as well.

Of course, bis does suggest in 22.1 that the UAC should notify the user when
this sort of retargeting happens (when the response comes from an unexpected
user), and that the client's user has to decide whether they trust and/or
want to talk to Bob. Maybe they have seen Bob's identity and credentials
before and they have some reason to trust Bob. Or maybe they feel like
talking to a total stranger.

I think all we can do is report the break in reference integrity to the
client's user and allow them to treat it as they like.

Consider this:  What if rather than proxying the request to Bob directly,
Alice's proxy server instead propagates a 302 back to the client,
redirecting to Bob's AoR? How has this changed the security implications of
this scenario? You would then be sending out a Request-URI to Bob's AoR, and
Bob could answer with reference integrity.

Ultimately this just means that you have to trust the proxy server that
manages Alice's contacts to apply them reliably.

_______________________________________________
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: Ofir Arkin <[email-masked]>
Date: Thu, 21 Feb 2002 10:54:41 +0000

Jon,

Using a self signed cert will give us nothing...
Proving Identity is what we are looking for...

Ofir

-- 
Ofir Arkin
Managing Security Architect
@stake, Limited.
http://www.atstake.com
email: 
[email-masked]
Tel: 
+44 (0) 207 495 7002
Fax: 
+44 (0) 207 495 7062
Mobile: +44 (0) 779 630 8632	

-----------------------------
The information transmitted is intended only for the person or entity to 
which it is addressed and may contain confidential and/or privileged 
material.  Any review, re transmission, dissemination or other use of, 
or taking of any action in reliance upon, this information by persons or 
entities other than the intended recipient is prohibited.  If you 
received this in error, please contact the sender and delete the 
material from any computer.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Feb 2002 07:37:03 -0800 (PST)

> Your message is getting through, but I still think we need this S/MIME

My comment was only focused on the self-signed certs.
In fact, bad security is often worse than no security.
At least with no security, people realize that they
aren't protected instead of being lulled into a false
sense of security. What you propose with self-signed
certs is, in fact, much worse than nothing because it
is so trivially defeated by that which you claim to
be defending against: rogue proxies. Eric thinks it
might be OK so long as enough text is put in to tell
people not to do it, but I find even that potentially
misleading, and in the end harmful if people gloss
over the guidance in a rush to have a "secure"
SIP widget.

 > thanks to S/MIME the caller can inspect a signature supplied by Bob 

In general, the draft goes to some length to
describe how to check identities in a way that
actually causes normative behavior. I believe that
that is generally wrong. If the application does
not differentiate and take action based on
identities, then the identity assertion is just
informational. In either case, I do not see why it
requires normative text beyond a way to reject
calls or bad signatures. The comparisons using
From/To: address in particular are suspect. The
trustable identity is in the DN/SubAltName of the
cert. The proper thing to do say in the spec, I
expect, is just to *ignore* the To/From: addresses
in the fact of SMIME.

	     Mike