Subject: [BEHAVE] TURN: Make Security a MUST for servers?

From: Philip Matthews <[email-masked]>
Date: Wed, 8 Apr 2009 08:00:16 -0400

At present, the TURN spec says:
* a server SHOULD use the Long-Term Credential mechanism, and
* a client MUST be prepared to use the mechanism if the server  
requires it.

One thing that has come up in the IESG review of TURN is the question  
of whether the SHOULD for servers should be changed to a MUST. The  
motivation is that TURN typically has terrible security if the Long- 
Term Credential mechanism is not used.

Right now, I see two occasions where a server might not want to use  
the Long-Term Credential mechanism:
1) If the client is using TLS transport between the client and the  
server, and if the server has some way to confirm that the client is  
authorized to use the server (or if the server doesn't care);
2) In special environments, where security is not an issue (for  
example, inside a corporate environment, where TURN is being used to  
work through an internal NAT).

Can anyone think of any other cases?

Comments on this topic? How do people feel about it?

What have various implementors done? Has everyone implemented the Long- 
Term Credential mechanism on the client side? On the server side?

- Philip

---

From: Simon Perreault <[email-masked]>
Date: Wed, 08 Apr 2009 08:09:18 -0400

> * a server SHOULD use the Long-Term Credential mechanism, and
[...]
> 2) In special environments, [...]

This is exactly what SHOULD means: it's a MUST with an exception for special
environments.

> What have various implementors done? Has everyone implemented the
> Long-Term Credential mechanism on the client side? On the server side?

For our public server (http://numb.viagenie.ca), LTC is definitely a MUST.

I can envision many cases where LTC is needed, just as I can envision many other
cases where it is not.

I see no problem with keeping it a SHOULD.

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

---

From: Sebastien Vincent <[email-masked]>
Date: Wed, 08 Apr 2009 14:19:19 +0200

Philip Matthews a écrit :
> motivation is that TURN typically has terrible security if the 
> Long-Term Credential mechanism is not used.
>

Long-term credentials is a MUST for TurnServer project 
(http://www.turnserver.org).

--
Sebastien Vincent

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Apr 2009 08:27:35 -0400

IMHO, server _support_ for some sort of authentication mechanism is a
MUST.  I'm not sure whether it's reasonable to insist that it be the
Long-Term Credential mechanism, but you do need to make sure that
clients and servers have a way of interoperating securely.

Whether servers require it is an operational choice.  However, running
any kind of unauthenticated packet laundering service would generally be
 considered bad behavior.

I have a hard time buying the "special environments" exemption because
(a) it's ridiculous to assume that there are no threats within an
enterprise network of any significant size (yes I realize this is a
common assumption), and (b) this kind of service would be extremely
useful to a malicious process operating from within an enterprise network.

Keith

> * a client MUST be prepared to use the mechanism if the server requires it.
> 
> One thing that has come up in the IESG review of TURN is the question of
> whether the SHOULD for servers should be changed to a MUST. The
> motivation is that TURN typically has terrible security if the Long-Term
> Credential mechanism is not used.
> 
> Right now, I see two occasions where a server might not want to use the
> Long-Term Credential mechanism:
> 2) In special environments, where security is not an issue (for example,
> inside a corporate environment, where TURN is being used to work through
> an internal NAT).
>

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 08 Apr 2009 05:50:58 -0700

> inside a corporate environment, where TURN is being used to work through

Operationally I don't think of corprate environments as a place where
security is not an issue, precisely the opposite in fact given turn's
applications in such an environment.

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 08 Apr 2009 08:55:26 -0400

- I think we are going in the wrong track here.
- The question is not if corp environments need security or not.
- the question is if in some environments (such as corp), there is a
need to _not_ use Long-Term Credential of a turn server.

I agree that it should be a "SHOULD". i.e.: you should implement it, but
it might be not used in some networks. I see an option in the server
config to control that behavior...

Marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

---

From: Scott Godin <[email-masked]>
Date: Wed, 8 Apr 2009 09:11:38 -0400

I agree.  I think MUST is fine.  reTurn will implements a configuration
option for this.
Scott Godin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 08 Apr 2009 08:21:47 -0700

> Comments on this topic? How do people feel about it?

I think TURN server MUST authenticate and SHOULD use LTC.  Client
MUST support LTC.

> Long-Term Credential mechanism on the client side? On the server side?

LTC is a MUST in my server implementation and is implemented in our
two client implementations.

-- 
Marc Petit-Huguenin
Home: [email-masked]
Work: [email-masked]

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 08 Apr 2009 08:43:42 -0700

> Can anyone think of any other cases?
Case #2 is the case I care about.
> Comments on this topic? How do people feel about it?
I believe that SHOULD is appropriate.
> Long-Term Credential mechanism on the client side? On the server side?
Adobe Flash Player 10.0 (installed on over 55% of all Internet-connected 
personal computers as of December 2008, the last month for which I can 
talk about statistics) implements TURN draft-08 WITHOUT long-term 
credentials.

This was done at the request of IT departments which wish to enable 
Flash Player's UDP-based RTMFP protocol without opening their firewall 
to all UDP traffic. This permits them to separately manage that traffic 
and log usage, just like an HTTP proxy does. And like their HTTP proxy, 
they don't particularly care about individual user authentication. They 
know that things like 802.1X, tight control over system software 
installation, and the ability to terminate people who don't comply with 
IT policies means that they have sufficient controls over how the 
internal network is used and how it connects to the Internet. Requiring 
configuration of individual credentials would be an impediment to 
deployment.

The most common request is for DHCP-based or similar autodiscovery of 
the proxy, and it would be even more difficult to add this while 
requiring individual clients to authenticate. (Where would they 
automatically get their credentials from?)

More recent TURN drafts have made TURN less efficient and more difficult 
to implement for use with a protocol that operates as RTMFP does 
(specifically, the requirement to allocate individual bindings prior to 
use, which conflicts with a protocol which wishes to send a flurry of 
single packets to candidate destination addresses at session startup, 
most of which will never be used again), and adding Long-Term Credential 
as a MUST could very well be the "straw that breaks the camel's back" 
and force a change to a proprietary proxy protocol.

The above is my personal opinion, not an official corporate position and 
this message is sent from my personal email account.

Matthew Kaufman

---

From: Philip Matthews <[email-masked]>
Date: Wed, 8 Apr 2009 21:38:57 -0400

Changing the topic to discuss a point that Matthew made.

On Wed, 8-Apr-09, at 11:43 , Matthew Kaufman wrote:

>
> More recent TURN drafts have made TURN less efficient and more  
> difficult to implement for use with a protocol that operates as  
> RTMFP does (specifically, the requirement to allocate individual  
> bindings prior to use, which conflicts with a protocol which wishes  
> to send a flurry of single packets to candidate destination  
> addresses at session startup, most of which will never be used  
> again), ...

Can you explain in more detail what you mean about this inefficiency  
point, perhaps with a call-flow diagram? If I understand your  
application correctly, without Long-Term Credentials this could be  
done as follows:

Client                         Server
   |--- Allocate request ----------------------->|
   |<----------------------- Allocate response --|
   |                                             |
   |-- CreatePermission (list of permissions) -->|
   |<----------- CreatePermission response ------|
   |                                             |
   |-- Send ind (packet to destination A)------->|
   |-- Send ind (packet to destination B)------->|
   |-- Send ind (packet to destination C)------->|
        etc.

This seems pretty efficient. In fact, you can send the  
CreatePermission before receiving the Allocate response, which makes  
the exchange run faster. (An a future enhancement, one could even  
devise a way to put the Allocate and CreatePermission into a single  
packet).

What am I missing?

- Philip

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 08 Apr 2009 20:56:46 -0700

Philip Matthews wrote:
>> difficult to implement for use with a protocol that operates as RTMFP 
>> does (specifically, the requirement to allocate individual bindings 
>> prior to use, which conflicts with a protocol which wishes to send a 
>> flurry of single packets to candidate destination addresses at 
>> session startup, most of which will never be used again), ...
>
Mostly the problem comes from the fact that we don't know all the 
addresses for the CreatePermission until we've done a few send 
indications and gotten responses back. That, and the fact that our 
implementation has a protocol stack that very deliberately doesn't know 
about TURN and a virtual interface that does the TURN part... 
CreatePermission means that the virtual interface isn't just "set up and 
use" but becomes "adjust for every new destination address the protocol 
stack tries to use". Here's some more detail:

Without a TURN server, our packet flow is one of these (from the POV of 
the client... there is also other packet flow from the server which 
isn't shown):

(case 1):
Client looks up A record and receives list of 1 or more IPv4 addresses
Client looks up AAAA record and receives list of 1 or more IPv6 addresses
Client sends to UDP port 1935 at some or all of those addresses
One or more of those packets elicit responses which redirect client to a 
new port number and possibly new IP address
Those redirections are added to the list of addresses which are being 
opened to
Each newly-added address+port and any address+port for which a 
retransmit timer has fired is sent another packet
Eventually a packet is returned which causes a session to be established 
and packet flow is entirely between that address+port pair, unless IP 
mobility occurs in which case probes are sent to confirm mobility, then 
the session is moved to the new address.

(case 2):
Client is already talking to a server at an existing address and port
Client sends a UDP packet to that server to open a peer-to-peer connection
Server responds with a list of candidate IPv4 and/or IPv6 addresses 
which may include actual addresses of the peer, addresses of servers 
which know the address of the peer, or addresses of servers which can 
relay introductions to the peer
Client sends a UDP packet to each of those candidate addresses (up to a 
limit in each round)
Some of those may cause responses which redirect client to additional 
new IP addresses+port number
Each newly-added address+port and any address+port for which a 
retransmit timer has fired is sent another packet
Eventually a packet is returned which causes a session to be established 
and packet flow is entirely between that address+port pair, unless IP 
mobility occurs in which case probes are sent to confirm mobility, then 
the session is moved to the new address.

This is all implemented by a highly platform-independent protocol stack 
library.

With a TURN server, the platform implements an additional interface for 
the library which is actual a virtual interface with a TURN 
implementation underneath.

Then the packet flows, now that CreatePermission is required, look like 
this:

(case 1):
When the client is first started, the platform performs an Allocate to 
set up the TURN server end of the virtual interface.
Client looks up A and AAAA records
Client tries to send packets to these addresses at port 1935, but the 
platform has to stop and do a CreatePermission to each. It is committed 
to sending these, so it does, even if by the time the CreatePermission 
is done the protocol stack has actually received a packet back which 
causes the binding to a single address and port for a session.
One or more of these packets elicits responses which redirect client to 
a new port number and possibly new IP address.
These redirections are added to the list of addresses which are being 
opened to
Each newly-added address+port is sent another packet, but the platform 
has to stop at this point again and send a CreatePermission. Again, 
there is a window during which the platform is committed to sending the 
packet and is waiting for the CreatePermission handshake, but the 
protocol stack may in fact learn that it no longer needs to send that 
packet.
And, of course, at this point we've now made what might be a dozen 
CreatePermission requests and waited for responses, some of which we 
could bunch up because we had all the addresses at once (like if they 
came in a single DNS reply), but others had to be sent one at a time 
because we needed to do the CreatePermission ASAP when the redirection 
came in and didn't know that milliseconds later we'd actually have a 
second redirect packet in hand that needs even more permissions added. 
If the TURN server is at the far side of a corporate VPN, the latency 
for each is high.
Eventually a packet is returned which causes a session to be established 
and packet flow is entirely between that address+port pair. If IP 
mobility of the client behind the TURN server occurs, TURN isn't 
mobility-aware and so the client totally loses their association with 
the TURN server. Game over. If IP mobility of the other side occurs, the 
probes can't be sent until a CreatePermission is sent and responded to, 
which may again in the VPN case add significantly to the time required 
to effect the mobility switchover.

case 2 is similar, but worse because we have an even bigger list of 
candidate addresses and it may be that *both sides* are behind TURN 
servers, and so just responding requires doing CreatePermission as well. 
This is extra fun if they're both behind the *same* TURN server, so 
eventually use a discovery mechanism (we have several) that finds the 
behind-firewall addresses and uses them but in the meantime they've each 
made a bunch of CreatePermission requests and are still waiting for them 
when the session does come up.

Matthew Kaufman

---

From: "Craig, Dave" <[email-masked]>
Date: Fri, 10 Apr 2009 15:06:26 -0700

What about keeping the Short-Term Credential, but adding a security consideration that a TURN usage should keep a short-term credential alive as long as the TURN server keeps a Nonce alive?

Thanks,
Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Philip Matthews
> Sent: Wednesday, April 08, 2009 5:00 AM
> To: Behave WG
> Subject: [BEHAVE] TURN: Make Security a MUST for servers?
>

---

From: Philip Matthews <[email-masked]>
Date: Mon, 13 Apr 2009 04:07:17 -0400

On Fri, 10-Apr-09, at 18:06 , Craig, Dave wrote:

> What about keeping the Short-Term Credential, but adding a security  
> consideration that a TURN usage should keep a short-term credential  
> alive as long as the TURN server keeps a Nonce alive?

Sorry, but I am not following this. (I assume you mean "Long-Term"  
rather than "Short-Term" credential, but even with this change I am  
not following your idea).

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Mon, 13 Apr 2009 04:22:05 -0400

On Wed, 8-Apr-09, at 11:43 , Matthew Kaufman wrote:

> Adobe Flash Player 10.0 (installed on over 55% of all Internet- 
> connected personal computers as of December 2008, the last month for  
> which I can talk about statistics) implements TURN draft-08 WITHOUT  
> long-term credentials.
>
> Flash Player's UDP-based RTMFP protocol without opening their  
> firewall to all UDP traffic. This permits them to separately manage  
> that traffic and log usage, just like an HTTP proxy does. And like  
> their HTTP proxy, they don't particularly care about individual user  
> authentication. They know that things like 802.1X, tight control  
> over system software installation, and the ability to terminate  
> people who don't comply with IT policies means that they have  
> sufficient controls over how the internal network is used and how it  
> connects to the Internet. Requiring configuration of individual  
> credentials would be an impediment to deployment.

Where is the TURN server itself deployed? Behind a corporate firewall,  
or in the Internet itself? If the latter, then how do you protect this  
server?

>
> The most common request is for DHCP-based or similar autodiscovery  
> of the proxy, and it would be even more difficult to add this while  

I agree that this would be a nice extension. There has been a little  
thought on anycast discovery of TURN servers, but no one has written  
up a concrete proposal yet.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Mon, 13 Apr 2009 04:23:00 -0400

From the responses right now, I am seeing a rough consensus to the  
spec saying that:

   TURN servers MUST implement the Long-Term Credential mechanism and  
SHOULD use it

with one significant comment about a large deployment that doesn't use  
security and says that it is not needed.

- Philip

---

From: "Craig, Dave" <[email-masked]>
Date: Mon, 13 Apr 2009 13:47:17 -0700

> From: Philip Matthews [mailto:[email-masked]]
> Sent: Monday, April 13, 2009 1:07 AM
> To: Craig, Dave
> Cc: Behave WG
> Subject: Re: [BEHAVE] TURN: Make Security a MUST for servers?
> 
> 

I had thought the MUST was on using long-term credential not just on having to implement it.  Nevertheless, if I have a TURN server implementation that rotates the short-term credentials frequently, why do I need to implement long-term credentials?

Thanks,
Dave

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 13 Apr 2009 14:51:18 -0700

> or in the Internet itself? If the latter, then how do you protect this 
We've seen two different architectures that people have talked to us about:

1) The TURN server has multiple network interfaces. An interface on a 
trusted network talks to TURN clients. Another interface is in a 
semi-trusted DMZ zone and is only for the unencapsulated packets.

2) The TURN server has a single network interface. The interface is in a 
more-internal DMZ of multiple layers of DMZ. There are specific firewall 
rules allowing it, and only it, from only its interface, to talk UDP to 
the outside world and this is via a stateful firewall so that only 
sessions it initiates can go outbound. The TURN port, specifically, is 
blocked inbound. There are other firewall rules allowing internal hosts 
to access the box, only at the TURN port. Again, this is a stateful 
firewall, so things on the inside must initiate connections towards the 
TURN server.

Basically the trust model is the same as the HTTP proxy used to be, back 
before bump-on-the-wire transparent HTTP proxies were invented. The 
company doesn't particularly care which employee is using it or for 
what, but wants to be able to log the traffic as it goes through a very 
narrow bottleneck, and wants to be able to subscribe to blacklists that 
interface with the proxy to turn off reachability to specific "bad" 
addresses if necessary.

Matthew Kaufman

---

From: Philip Matthews <[email-masked]>
Date: Mon, 13 Apr 2009 21:45:34 -0400

On Mon, 13-Apr-09, at 16:47 , Craig, Dave wrote:

> I had thought the MUST was on using long-term credential not just on  
> having to implement it.  Nevertheless, if I have a TURN server  
> implementation that rotates the short-term credentials frequently,  
> why do I need to implement long-term credentials?

Mostly because TURN is currently specified to only uses the Long-Term  
Credential mechanism. That is not to say that using STUN's Short-Term  
Credential mechanism with TURN is impossible, but no one has written  
an I-D on how to do it.

- Philip