Subject: [BEHAVE] Discusses regarding security mechanism usage for TURN

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Jul 2009 14:27:21 +0200

Behave WG,

Cullen Jennings and Tim Polk each have a discuss on TURN on the same
basic issue. The issue is around what security functions must be used to
ensure that TURN operates in a secure and usable fashion. This has been
discussed a number of times if one reviews the list and minutes from
meetings. The last time was in April when Philip brought this up as a
result of these discusses. All three of us had some additional
discussion around the implications of the currently document MUST
implement SHOULD use authentication in the TURN specification. Our joint
view is that this appears too weak a recommendation from IETF around
usage of authentication for the TURN protocol. We therefore are strongly
proposing that TURN actually needs specify that one MUST use
authentication.

The reasons we have for this proposal is directly related to the core of
TURN's purpose. The main usage of TURN will be with publicly reachable
relays. In most cases located outside of firewalls belonging to
companies, governmental agencies, private homes, etc. These firewalls
needs to have a certain trust in TURN so that they allow TURN to pass
through. The security vulnerabilities that exist with TURN if
authentication is not used, will prevent that trust to exist. As a
result we see that IETF only by publishing TURN saying SHOULD use
authentication rather than MUST use authentication has severe impact on
TURN's main purpose. We do note that the usage documented in TURN
(Version 16) that motivates the SHOULD appears to have acceptable
security. However, that usage is judged from our point of view to be a
marginal one, and the "SHOULD use" will open a hole for other usage with
less satisfying securities that we deem to be very serious.

Thus we strongly urge the WG to discuss our views and recommendation to
sharpen the SHOULD use authentication to a MUST use authentication.
Magnus will make a decision based on any received input after two weeks
and present that to the discussing ADs.

Best Regards

Magnus Westerlund
Tim Polk
Cullen Jennings

---

From: Simon Perreault <[email-masked]>
Date: Mon, 27 Jul 2009 14:44:11 +0200

Magnus Westerlund wrote:
> However, that usage is judged from our point of view to be a
> marginal one

Not addressing all the other (valid) points, and not taking any position...

Flash 10 is widely deployed and implements a TURN client without
long-term auth. That's certainly not marginal.

Matthew Kaufman presented a compelling argument for this:
http://www.ietf.org/mail-archive/web/behave/current/msg05733.html

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Jul 2009 15:11:23 +0200

> long-term auth. That's certainly not marginal.

So if I understand this correctly, this deployment is exactly such a one
that will be vulnerable to the security threats. You have some TURN
servers operated by Adobe, they are located in the Internet as viewed
from the client perspective. Thus, they are not fulfilling even the
exception case for using security based on TURN server policies with
restricting the location of the clients to the internal domain.

So running without security in this case do leave TURN wide open to the
threats listed in the security consideration.

> http://www.ietf.org/mail-archive/web/behave/current/msg05733.html

Well, the argument is operational and does not appear to me to take the
security issues with TURN itself into consideration.

Am I misunderstanding the deployment in the flash case?

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 27 Jul 2009 16:19:59 +0300

> restricting the location of the clients to the internal domain.

Actually, that's not my understanding. This case seemed more like TURN relays 
being deployed on the edge between a walled garden and the Internet. TURN 
clients are not authenticated, but they must be on the garden side, whereas 
TURN peers must be on the Internet side.

In other words, the authentication mechanism is the ability to reach the TURN 
server (on the client side). I reckon corporate HTTP proxies often operate in 
that manner.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

---

From: Simon Perreault <[email-masked]>
Date: Mon, 27 Jul 2009 15:26:28 +0200

> restricting the location of the clients to the internal domain.

I think in this deployment the server would only accept TURN requests on
an interface to the private network (e.g. an RFC1918 network). It would
relay packets to peers on another interface to the Internet. It would
run under the assumption that clients that can access its private
interface are trusted.

I can envision a popular deployment scenario to look like the following:

           +-------<Internet>-----------+
           |                            |
        +-----+                 +-------------+
--------| NAT |-----------------| TURN server |------------------------
        +-----+                 +-------------+
           |                            |
           +----<RFC 1918 network>------+

Simon

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Jul 2009 18:40:34 +0200

>            +-------<Internet>-----------+

Okay,

I are apparently misunderstanding. As we said in the email, in the case
you actually are restricting clients based on network and them being
controlled in some other sense. Which brings this back to the original
statement in our email about the perception on TURNs security and the
protocols usability for the other usage.

Cheers

Magnus Westerlund

---

From: Dave Thaler <[email-masked]>
Date: Mon, 27 Jul 2009 17:17:01 +0000

I wonder if it would help to make it conditionally mandatory.
E.g., MUST use authentication for any client connections accepted
from the Internet or any other public network?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Magnus Westerlund
> Sent: Monday, July 27, 2009 6:41 PM
> To: Simon Perreault
> Cc: Tim Polk; Behave WG; [email-masked]
> Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for
> TURN
>
> Simon Perreault skrev:
> > Magnus Westerlund wrote:
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Tue, 28 Jul 2009 06:00:59 -0400

Magnus:

What is your proposal for the case where TLS transport is used between  
the client and the server. Would the client have to use the Long-Term  
Credential mechanism in this case?

- Philip

On Mon, 27-Jul-09, at 13:17 , Dave Thaler wrote:

>>>> So if I understand this correctly, this deployment is exactly  
>>>> such a
>> one
>>> I think in this deployment the server would only accept TURN  
>>> requests
>> on
>>> --------| NAT |-----------------| TURN server  
>>> |----------------------
>> --
>>>        +-----+                 +-------------+
>>>           |                            |

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 29 Jul 2009 02:01:57 -0400

Can you summarize why you guys feel turning on TURN authentication would make an Enterprise any more willing to allow TURN through their firewall?

Maybe I'm not thinking clearly, but ISTM that an Enterprise would block TURN because they don't want their PC's opening permanent holes for "inbound" traffic.  The fact that a PC can prove it's known to a TURN server in the Internet - not owned by the Enterprise - does nothing to help the Enterprise feel safer, does it??  (did I miss something in TURN auth that actually cleared the evil-bit somehow?)

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Magnus Westerlund
> Sent: Monday, July 27, 2009 8:27 AM
> To: Behave WG
> Cc: Tim Polk
> Subject: [BEHAVE] Discusses regarding security mechanism usage for TURN
> 
> Behave WG,
>