Subject: Re: [BEHAVE] TurnServer - An OpenSource TURN server implementation

From: Philip Matthews <[email-masked]>
Date: Mon, 24 Nov 2008 20:58:07 -0500

A late reply to the message below requesting that TURN implementations  
allow the long-term authentication mechanism to be disabled.

I would just like to point out that TURN robustness and security  
strongly depends on the long-term authentication mechanism. Unless you  
have complete confidence in your clients, I would not recommend  
disabling this mechanism. This mechanism is used not only to protect  
against against actively hostile clients, but also plays a part in  
protecting against clients which are intended to be benign but which  
have a coding fault that causes them to misbehave.

- Philip

On Sat, 26-Jul-08, at 16:34 , Matthew Kaufman wrote:

> Sébastien Vincent wrote:
>> ... The server requires the long-term authentication for TURN  
>> requests....
> We are about to ship a product (in fact, it is already in beta) that  
> uses TURN and *does not* send long-term authentication. The use case  
> is a TURN server located in a corporate DMZ, so clients are already  
> de-facto authenticated by being on the correct side of the firewall.  
> We would like to strongly encourage the development of TURN servers  
> that can have the long-term authentication requirement disabled at  
> compile or run time so they may be used for this use case.
>
> The product is Adobe Flash Player 10, so will be fairly widely  
> deployed.
>
> Matthew Kaufman
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 24 Nov 2008 20:25:34 -0800

> have a coding fault that causes them to misbehave.
How would you compare the security of a TURN server located in a 
corporate DMZ with the TURN port reachable only by desktop machines 
managed by IT to that of an unauthenticated HTTP proxy set up in a 
corporate DMZ, with the proxy port only reachable from desktop machines 
managed by the IT department (a fairly typical way of bottlenecking all 
web traffic via a box that can log and inspect it)?

Matthew Kaufman

---

From: Philip Matthews <[email-masked]>
Date: Tue, 25 Nov 2008 07:33:47 -0500

On Mon, 24-Nov-08, at 23:25 , Matthew Kaufman wrote:

> Philip Matthews wrote:
>> A late reply to the message below requesting that TURN  
>> implementations allow the long-term authentication mechanism to be  
>> disabled.
>>
>> strongly depends on the long-term authentication mechanism. Unless  
>> you have complete confidence in your clients, I would not recommend  
>> disabling this mechanism. This mechanism is used not only to  
>> protect against against actively hostile clients, but also plays a  
>> part in protecting against clients which are intended to be benign  
>> but which have a coding fault that causes them to misbehave.
>>
>> - Philip
> corporate DMZ, with the proxy port only reachable from desktop  
> machines managed by the IT department (a fairly typical way of  
> bottlenecking all web traffic via a box that can log and inspect it)?

I don't feel qualified to make such a comparison.
My point is simply that the long-term authentication mechanism is not  
very onerous, and that the TURN spec recommends that TURN servers  
limit things like the number of allocations per username in order to  
protect itself.
- Philip
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 25 Nov 2008 07:58:50 -0800

> limit things like the number of allocations per username in order to 

Long-term authentication isn't hard to do in software, but it is hard 
for an IT department to administer for some of the "corporate proxy" use 
cases. It is already a pain to get the TURN proxy address to the 
software, given that there's no autodiscovery mechanism yet... adding 
unique usernames and authentication information to what  needs to be 
pushed out to every system just multiplies that task.

If TURN servers don't exist that can be configured by IT departments in 
unauthenticated mode, then IT departments will demand an alternative 
that isn't TURN.

Matthew Kaufman

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 25 Nov 2008 08:24:02 -0800

Matthew Kaufman wrote:
> software, given that there's no autodiscovery mechanism yet... 

Have a look to this draft (adopted as WG item in Minneapolis):

http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-03

The domain learned from DHCP can be used to build the TURN URI.
Because an indirection mechanism is built in the URI mechanism, the
TURN servers can even be managed by a third party.

> adding

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave