Subject: RE: [midcom] STUN over TCP?

From: "Christian Huitema" <[email-masked]>
Date: Wed, 13 Mar 2002 02:46:50 -0800

> However, there are very serious security risks unless STUN responses
are
> well protected. If I could inject a fake stun response, containing my
> own IP address and port in the MAPPED-ADDRESS attribute, I can steal
> peoples phone calls, re-route media, and so on. All sorts of really
bad
> things. It would be an effective back door to break security of any
> application protocols that would use STUN.
> 
> Now, we debated whether or not to use a public key mechanism to sign
the
> responses, or shared secret. The latter would allow us to use a simple
> keyed HMAC, much, much less complicated. However, its not practical. A
> server does not authenticate itself to a user with a shared secret. On
> the web, its with server certificates in TLS/SSL. The simple fact is
> that you will want to use stun servers in domains you don't even have
a
> shared secret with at all.

There are several levels of protection that can be implemented, and
result in various trade-off.

The simplest protection is to insert a "nonce" in the request, and to
check that the "nonce" is copied in the response. This prevents attacks
by parties that are not on the direct path between the STUN client and
server, and is almost free from an implementation point-of-view. The
level of protection is equivalent to the one of clear-text signaling
protocols.

The simpler protection can be complement by a simple test on the
returned mapping. If the clients already obtained mappings in a secure
way, and if the IP address component in the new mappings is the same as
the address in a previous mapping, then the risk of just using the
mapping provided is very limited.

All other protections imply having a form of digital signature, which
makes the STUN server notably more expensive to run. The simplest
cryptographic solution is to assume that the STUN server has a public
key certificate, and uses the private key associated to the public key
certificate to sign the responses.

Melinda correctly points out that certificates can be very large. We
should not require that the full certificate be transmitted in every
response. A better design would be to carry a signature in the response,
and to also provide the URL at which the response can be obtained.

Using any form of cryptography closes one type of attack (forged
responses) but creates another, the possibility to bring the server down
by forcing it to sign a large number of queries. It also open a
distributed denial of service avenue, as responses can be much longer
than queries. Both risks can be mitigated by using a four ways
handshake:

	Request mapping + nonce A -->
		<-- mapping + nonce A + nonce B
	Request signed mapping + nonce B -->
		<-- signed mapping

The idea being to force the client to send back a cookie to the server,
proving that the initial message did not come from a forged address,
before sending a signed mapping. Note that the algorithm also enables
the client to decide whether or not to request the signed mapping.

-- Christian Huitema

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Mar 2002 09:44:20 -0500

> level of protection is equivalent to the one of clear-text signaling

Right. We always had that, in the form of the transaction ID in the
request, which had to be mirrored in the response. 

> mapping provided is very limited.

True; this won't work for nats which are mapping addresses into more
than one public IP address, though.

> certificate to sign the responses.

Right. THis is what we do in stun-01.

> and to also provide the URL at which the response can be obtained.

We do something slightly different, which is to carry only the signature
in the UDP response. But, if you send the request via TCP, you get the
certificates too. All of the other data from the TCP response is not
useful - just the certificates are useful. One you have them, you can
store them, and you won't need to retrieve them again from the same
server (until they expire).

> the client to decide whether or not to request the signed mapping.

Right. We also have this in stun-01 using the cookie. The flow looks
exactly like what you have above, with nonce A = transaction ID, and
nonce B being the cookie attribute.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com