Subject: RE: [midcom] STUN security showstopper

From: [email-masked]
Date: Fri, 10 May 2002 15:34:30 -0400

This is the 'reasonable address' idea that was dicussed earlier and which
was deprecated in favor of cryptogrphic methods.

"Sanjoy Sen"<[email-masked]>@ietf.org on 05/10/2002 03:26:57 PM

Sent by:  [email-masked]

To:   "'Christian Huitema'" <[email-masked]>, Melinda Shore
       <[email-masked]>
cc:   [email-masked]
Subject:  RE: [midcom] STUN security showstopper

I'm wondering whether its possible to build a profile at the STUN server
based on the received (mapped) addresses over a sufficient period of time
and compare any new arrival against the profile. Similar ideas are used in
Intrusion Detection software.

In a very limiting deployment scenario, the STUN service may be configured
with the possible (expected) IP addresses of all NATs in the serving
domain.

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Friday, May 10, 2002 2:09 PM
> To: Melinda Shore
> Cc: [email-masked]
> Subject: RE: [midcom] STUN security showstopper
>
>
> 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
>

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

---

From: Melinda Shore <[email-masked]>
Date: Fri, 10 May 2002 18:05:43 -0400

>was deprecated in favor of cryptogrphic methods.

Not really.  The "reasonable address" suggestion is easily
defeated, unfortunately, and that's why it hasn't been pursued.

Melinda