Subject: [Sip] SMIME and active MITM attacks

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Feb 2002 08:35:19 -0800 (PST)

First of all, the comparison of SIP's use of SMIME
and SSH is flat out wrong. SSH is a peer to peer
protocol which does not have intermediaries (or at
least the last time I checked, but regardless when
one thinks of SSH, one does not think of active
proxies). The reason that this is important is
because SIP, unlike SSH is trivially subject to
active MITM attacks. Indeed, the entire raison
d'etre for SMIME is to thwart active MITM attacks
from hostile proxies.

Unfortunately, I think the current text falls
short of the mark, both from a specification
standpoint as well as a practical standpoint. In
particular, there is nothing which prevents a
proxy from removing a SMIME attachment and adding
its own. Assuming the proxy's cert is rooted in
some CA's namespace, it would verify just fine. An
evil proxy is perfect capable of rewriting any
headers it feels like, so the comparison of inner
or outer From: addresses is essentially useless.
It's not enforcing any security policy. That is,
unless there is some ultimate differentiation of
authorization to particular authenticated
identities, nothing is being enforced.

Second, the entire concept of using self-signed
certs in the face of active MITM attacks is bogus.
At least with rooted certs, you can at least show
a user that the identity presented is provably
part of a known CA's namespace. Self-signed certs
have no such insurance, so they provide no
additional authentication benefit in this case.
This is in contrast to SSH-like leap's of faith.
For SSH, the plausibility of an active MITM is
explicitly discounted because of the general
difficultly of mounting such an attack on the
Internet. However, proxy routed SIP makes this
kind of attack trivial for evil proxies -- the
exact thing that we are protect ourselves from.
As such, any form of opportunism with self-signed,
or unknown CA's is extremely suspect, and subject
to simple substitution by a proxy.

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".

In summary, I don't think this section has had
nearly enough review to determine whether it is
actually providing any real security benefits
wrt. authenticating UA's, and I'm dubious how real
UA's will actually do anything useful with the
asserted identities. This is in stark contrast to
UA-proxy authentication which generally involves
an authorization operation after the UA is
authenticated.

		Mike

_______________________________________________
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: Eric Rescorla <[email-masked]>
Date: 20 Feb 2002 09:42:51 -0800

Michael Thomas <[email-masked]> writes:
> Internet.
I'm not sure that I agree with your assessment here, not
so much because I don't think the threat of active attack
is serious in the SIP context, than because I'm not really
that sanguine about it's difficulty in the context of SSH.
It's pretty easy to get code to mount hijacking attacks.

As I see it, SSH's key management is intended to protect
against semi-reactive attacks, where an attacker decides
to impersonate a given party at a given time. Caching keys
protects you from this attack. An attacker must perform
the MITM attack at the time when the peers first communicate.
This means either knowing in advance that you're going to
attack a given party or mounting a global MITM attack so
you can impersonate someone later. Similar comments apply to SIP.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Feb 2002 09:56:01 -0800 (PST)

> you can impersonate someone later. Similar comments apply to SIP.

   The problem is that the path to the UAS is
   likely to always involve the same entities
   which may in fact be compromised. Unlike
   routers which have a pretty strong disincentive
   to track things (if nothing else, volume), it's
   not clear that proxies to a particular UAS
   wouldn't *always* mount active MITM attacks.
   Consider countries with low/non-existent
   civil rights which just as a matter of fact
   capture and/or re-write bodies to prevent
   subversives. In this case -- and I think it's
   probably a case naive users might think that
   a leap of faith might give better security than
   nothing -- it would not only be useless, it
   would be very dangerous since the perceived
   security was, in fact, an illusion.

   Considering that the object of this exercise
   is to thwart these kinds of abuses, I find the
   current text quite frightening, especially when
   you consider that the set of people who
   actually understand these kinds of attacks are
   vanishingly small.

	       Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Feb 2002 10:56:05 -0800 (PST)

Eric Rescorla writes:
 > I agree that this is a serious concern, but I'm not sure what
 > to do about it. It seems to me that we could adopt at least
 > three postures:
 > 
 > (1) We require that all certificates be based on known CAs.
 > This seems unrealistic.
 > (2) Allow use of self-signed certs with SSH-style caching (more or
 > less as described in the text) which, as you point out, has serious
 > security holes.
 > (3) Allow use of self-signed certs with SSH-style caching but forbid
 > implementations to represent the peer as authenticated, while throwing
 > errors if the cert changes.
 > 
 > This seems to be inherent in any certificate-based authentication
 > system. Is there some other option I've missed?

   No, you seem to capture the possibilities
   exactly right. I find the last two pretty scary
   since your average user is very likely to be
   completely gullible. If e2e security is the 
   stated requirement from the IESG, I don't see
   any other alternative to (1) [1].

	     Mike

[1] and yes I agree that it's unrealistic due to the
    "global PKI" problem, but that's why I think the
    utility of this is suspect in the first place...

---

From: Eric Rescorla <[email-masked]>
Date: 20 Feb 2002 11:03:29 -0800

>    any other alternative to (1) [1].
There's always possibility 1(a), where we require PKI but then put in
text explaining the self-signed alternative in excruciating detail.
All in the interest of explaining why you wouldn't want to do it, 
of course. :)

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Feb 2002 11:17:57 -0800 (PST)

> All in the interest of explaining why you wouldn't want to do it, 

   Right now, I doubt that I would trust an implementation
   which did what was recommended in bis to provide me
   authentication or confidentiality, mainly because it
   would be very hard to determine how the developers
   interpreted the spec. Given that the likelihood is
   that it will be SIP developers integrating SMIME
   into their product, I fear the worst because most of
   these considerations are pretty opaque in my
   experience of having to explain this kind of stuff to
   them. :-(

		Mike

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 20 Feb 2002 21:37:00 +0200

> All in the interest of explaining why you wouldn't want to do it, 

no matter how much the text would push for global pki, it simply won't
happen.  realistically the user needs to rely on transitive trust or
communicate e2e in the same way as we do today with ssh.

-- juha

---

From: Eric Rescorla <[email-masked]>
Date: 20 Feb 2002 10:45:53 -0800

-Ekr

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Feb 2002 20:06:29 +0200

I think the leap-of-faith, with its problems, still
makes sense for SIP. It does work in the case where
you train your laptop and your friend's laptop to know
each other at YourSecureDomain.Com and then you move to
BadGovermentOrOperator.Org since the original exchange
was in a secure place.

I do think though that the dangers must be very
clearly described, in the bis rfc, as well as
in product documentation... though I'm not sure much
more can be said that 22.4.2 already says.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Thu, 21 Feb 2002 10:38:42 -0800 (PST)

> BadGovermentOrOperator.Org since the original exchange

  ??? But this isn't a leap of faith, right?
  You've provisioned yourself while not exposing
  yourself to the active MITM attackers, right?

  Leap of faith -- to me at least -- means that
  you're willing to expose yourself once to a
  MITM attack, on the general premise that the
  likelihood of being subject to an active MITM
  attack at any particular time is relatively low.
  (or that you can decide not to do it when you feel
  that it is too risky). In the cases that SMIME
  needs to protect against, I think that is a
  *very* dangerous proposition. 

  I like leap of faith in some cases because I
  think it provides reasonable ease-of-use vs.
  security tradeoff. However, I don't think this
  is one of those cases given the ease to mount
  an active attack. At some point, you just need to
  bite the bullet.

	    Mike