Subject: RE: [midcom] STUN security showstopper

From: "Christian Huitema" <[email-masked]>
Date: Fri, 10 May 2002 12:08:47 -0700

I wonder where we go from here. I believe that the attack scenario
demonstrates that the "protected" version of STUN is not much better
than the nonce-protected version. The attack the nonce protection
requires that the attacker be able to listen to the client's traffic;
the attack against the protected version is enabled if the attacker is
able to listen to the client's traffic. The client will detect the
attack against the nonce because it will receive two responses; the
client will also receive two responses in the attack against the
protected version; in both cases, the attack will only go undetected if
the attacker succeeds in blocking either the direct request, or its
response.

A first possibility is to re-assess the domain of applicability of STUN.
For example, if I use STUN on my home network which is directly
connected to reputable ISP, I may not be too concerned by the attack
scenario. If we follow this logic, we should keep STUN simple by just
removing the cryptographic part, but restrict its application to
"physically secure" attachment networks, such as home networks directly
connected to an ISP, or even shared access networks that use a
"per-client" encryption key, i.e. in which the clients cannot look at
each other traffic. Unprotected open networks, such as for example the
IETF WIFI network, would be left out of the domain of application.

The problem with this "domain of applicability" option is that it is a
bit of a cope-out, since it is very hard for the software in a mobile
device to determine whether the local network is or is not physically
secure -- the safe assumption being that it is never secure. In that
case, the better security is probably to complement STUN with other
solutions, which may or may not use cryptography. We have heard of many
partial solutions, such as:

1) Wait for some time after the first response is received, in order to
detect duplicate responses, possibly contradictory responses.

2) Renew the mapping requests at random, unpredictable intervals, in
order to make interception difficult.

3) Ask mappings from several different servers.

4) Ask for a mapping response over a TLS channel.

Neither of these responses is perfect. The first solution raises an
alarm when a weird event happens, but does not tell which of the
responses is to be believed. The second an third responses make the
attack harder by using time diversity and/or special diversity: the
attacker must catch all the attempts, to diverse servers; OTOH, a
dedicated attacker near the client could do just that. The TLS channel
will provide a reference mapping to a TLS connection, not the UDP
connection that the will be use for VoIP; it can only be used for some
plausibility control, and is a poor defense against an attacker on the
same subnet; in any case, a dedicated attacker could also insert itself
in the middle of a TLS connection. In short, none of that is terribly
appealing.

We may want to consider another line of defense that defends against the
attacks that a false mapping enables, instead of trying to make sure
that the mapping is genuine. For example, we could say that if you use
STUN to set up an RTP connection, you should consider that the network
connection is unsafe, and you should encrypt the RTC traffic, thus
effectively thwarting the man in the middle attack. Or, if we have
received several candidate mappings, we could conduct a continuity test
to check the mapping that are usable, thus thwarting the denial of
service attack.

-- Christian Huitema

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

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 10 May 2002 14:22:26 -0500 (CDT)

On Fri, 10 May 2002, Christian Huitema wrote:

> I wonder where we go from here.

	Hey, I know. Maybe we could go to work to develop a system
by which the signaling infrastructure could securely communicate
directly with the NAT device, and via that secure authenticated
channel, establish and discover NAT bindings?

	This sort of thing may actually be sort of moot, though.
If I can intercept STUN messages, I can probably intercept SIP
or MGCP messages, which are far more interesting. Directly
hammering on signaling is easier and more powerful.

	In fact, I don't even have to be a man in the middle.
I can simply snoop for call setup attempts, and forge rejects
back as fast as I can.

	Fixing STUN, or creating a secure alternative, is a worthy
goal. In the final analysis it may simply not matter.

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 15 May 2002 10:47:01 +0200

How about the "Is it really you?" technique known from generating
email accounts at public servers.

After receiving a request, STUN server would send back a verification
query "is it really you?" to the address. A STUN client would have to send an ack
"yes it is me" with proper credentials. The server would only send
a final reply if the verification ack was proper.

It adds one more RTT, but mitigates the impersonation attack.

-Jiri

>I wonder where we go from here. 
[...]

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 15 May 2002 12:32:48 +0200

Forget it -- that does not help either, I did not understand the 
attack scenario previously.

-Jiri