Subject: [Ietf-behave] TURN Issue #2: Digest for Allocate directly

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 5 Dec 2005 08:19:06 -0800 (PST)

Currently, TURN security relies on a one-time-password approach. The 
client connects to the TURN server over TLS, and asks for a one time 
username and password. This request is itself authenticated using digest 
-over-TLS (using the same username/password structures as SIP). Then, 
the actual allocate request itself is authenticated using this 
one-time-password. This approach is reasonably secure, and is not 
susceptible to the dictionary attacks that regular digest authentication 
is susceptible too.

The cost, however, is that TURN security is very complicated and 
expensive, processing wise. It will require many TCP/TLS connections to 
be established, and for them to see significant churn over time. I've 
also gotten some feedback that it makes TURN load balancing more 
complicated, since you would need to share these one time passwords 
between a load balancing element and the TURN server that does the 
actual allocations.

I'm increasingly worried these days that complicated security, even when 
good, won't be deployed if the costs are too high. And that will mean 
TURN without any security at all, which is really bad.

So, it has been suggested to me to allow the Allocate request itself to 
be authenticated using a Digest mechanism. The initial Allocate request 
is sent without credentials. Its rejected with a 401 that provides a 
nonce, and the request is retried with message-integrity that has an 
HMAC that includes the NONCE. (I'd likely do this by bringing in the 
digest authentication into the core stun protocol, and then allowing the 
TURN allocate to use it).

This would vastly simplify TURN security, and make it on par with most 
existing SIP deployments which work the same way. The other option would 
continue to exist and be supported, I'd probably also add a way for the 
TURN server to reject the digest credentials and tell the user they need 
to obtain a one-time-password. This allows for server operators to 
change policies about whether this is allowed and still maintain interop 
with clients.

I'd like to go ahead and make this change, but would like feedback from 
the group on it.

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Dec 2005 10:54:33 -0800 (PST)

I saw no public responses to this, though I did get a private reply 
supporting it. Barring objections, I will move forward with my proposal 
to make this change.

Thanks,
Jonathan R.
Jonathan Rosenberg wrote:

Thanks,
Jonathan R.

---

From: "Justin Uberti" <[email-masked]>
Date: Mon, 19 Dec 2005 13:27:23 -0800 (PST)

I am in favor of this. We also found TURN security to be complex and 
expensive, and had to implement our own lightweight security.

Thanks,
Justin Uberti
Chief Architect, AOL

Jonathan Rosenberg wrote on 12/19/2005, 1:54 PM:

 > _______________________________________________
 > Ietf-behave mailing list
 > Ietf-behave@xxxxxxxxxxxxxxxxxxx
 > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
 >