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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 03 Sep 2009 16:12:52 +0200

Philip Matthews skrev:
> 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?

Well, if you actually used real certificates for TLS in the client that
would clearly satisfy the security requirement of identifying the
client. Which would be an argument for saying MUST use Long-Term
credential mechanism or other equal or stronger mechanism to identify
the client.

But in most cases aren't the TLS clients using self signed certificates
that provide no value for client authentication.

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: Magnus Westerlund <[email-masked]>
Date: Thu, 03 Sep 2009 16:24:39 +0200

Hadriel Kaplan skrev:
> 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?)

First of all TURN allocation on a TURN server does not allow inbound
traffic openly. The client must have installed a permission. Thus it can
only receive traffic from known peers, not anyone.

However, TURN servers that do not require using authentication of any
TURN clients request are vulnerable to attacks that allows the attacker
to install permissions. Thus enabling an attacker to send traffic to the
target on the inside.

Please do review the security consideration section and think about all
the attacks that are listed but said to be stopped by authentication.
They are all possible if authentication is not used.

Cheers

Magnus

> 
> -hadriel
> 
>> -----Original Message-----
>> 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,
>>
>> 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
>> _______________________________________________
>> Behave mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/behave
> 

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Sep 2009 09:15:04 +0200

WG,

This topic has now been open for a month and a half. I have seen no
comments on my latest posting (10 days ago). Thus, I am proposing an
RFC-editor note to change the wording in the document (on version 16).

Section 4, page 20, third paragraph in section:

OLD:
   [RFC5389] specifies a Long-Term Credential mechanism for STUN.  TURN
   servers and clients MUST implement this mechanism.  The server SHOULD
   demand that all requests from the client be authenticated using this
   mechanism, and the client MUST be prepared to authenticate requests
   if required.

NEW:
   [RFC5389] specifies a Long-Term Credential mechanism for STUN.  TURN
   servers and clients MUST implement this mechanism.  The server MUST
   demand that all requests from the client be authenticated using this
   mechanism, or that a equally strong or stronger mechanism for client
   authentication is used. One such mechanism is TLS, if using client
   and server certificates that actually identify the parties, i.e. no
   self-signed certificates.  The client MUST always be prepared to
   authenticate requests use the Long-Term Credential mechanism if
   required.

Cullen and Tim, does this text satisfies your discusses?

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Sep 2009 07:48:18 -0400

>    authenticate requests use the Long-Term Credential mechanism if

I strongly disagree. I once again point you to Matthew Kaufman's argument, 
which you seemed to agree with last time (I wasn't sure from your response):
http://www.ietf.org/mail-archive/web/behave/current/msg05733.html

Don't you think this is a valid (and potentially frequent) use case where not 
using authentication can be justified?

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 14 Sep 2009 07:28:09 -0700

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

Both the above-mentioed long-term credential requirement and the failure 
to address applications/protocols for which the added requirement of 
CreatePermission for each destination address is incompatible are still 
open problems with TURN, as far as I'm concerned.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 14 Sep 2009 07:43:25 -0700

For additional background, I see that I failed to notice/respond to 
discussion earlier on this topic:

Magnus Westerlund wrote:
> ...
> TURN's main purpose. 

The problem with this is that doing this also converts TURN's 
generality, with a "main purpose" of Internet-accessible relays and a 
"secondary purpose" as a proxy protocol which started out superior to 
SOCKS (and other proprietary choices) for the corporate mandatory-proxy 
case, into a more narrower protocol which has an "only purpose" of 
Internet-accessible relays and a large number of other applications for 
which Yet Another Protocol must now be implemented/deployed.

Not only does that increase the number of different protocols in the 
world, but it also means that clients may now be forced for reasons of 
code size or implementation time to do only one or the other, thus 
eliminating the possibility of interworking with the other.

If I were engineering a widely-deployed application which needs a proxy 
protocol for the second use case (which I am), I wouldn't object to TURN 
making the long-term credential mechanism a MUST... but I'd stop using 
TURN and switch to an alternative proxy protocol for that reason.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 14 Sep 2009 07:46:22 -0700

Magnus Westerlund wrote:
> ...
> 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.
> ...
>   
>
> 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?
>
>   
Yes. The deployment in the Flash case is *not* that Adobe provides 
public TURN servers for use by Flash Player. Rather, Adobe has made it 
possible for corporate IT departments to deploy Flash Player along with 
a static configuration file which points them at a TURN server operated 
by that IT department which is only accessible from the inside network 
and which can only initiate sessions towards outside addresses. The TURN 
server is secured and operated in parallel with an equally 
unauthenticated-but-secured HTTP proxy.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 14 Sep 2009 08:57:41 -0700

And to second what Hadriel Kaplan asked,...

Magnus Westerlund wrote:
> The main usage of TURN will be with publicly reachable
> authentication is not used, will prevent that trust to exist. 

I don't understand this argument at all. There are only a few firewall 
configurations that matter:

1) Deciding whether or not to enable outbound access from my client PCs 
to the TURN port generally.

In this case, I need to decide if I'm ok with my PC users initiating UDP 
sessions to a service that I may not control at all. Having TURN 
long-term-credentials mandatory makes no difference here, because an 
evil TURN server could just let anyone in... or it might not even run 
TURN but instead run some other evil protocol.

I also need to decide if I'm ok with my PC users using such a thing to 
get traffic relayed back to them... but then I have that same problem 
when I let them use HTTP to get to the outside world.

2) Deciding whether or not to enable outbound access from my client PCs 
to a *specific* TURN server (port and IP address).

In this case, I need to decide if I'm ok with my PC users initiating UDP 
sessions to a specific server which I then need to trust. I trust this 
best if it is in a DMZ that I control so that I can prevent 
externally-initiated traffic from coming to the TURN port/address, but I 
might for whatever reason need to trust one that is out on the wild 
Internet. That's not as safe, and so then I need to consider whether its 
operator is or is not running it in a relatively safe manner, and 
long-term credentials is something I might expect them to have turned on.

3) Deciding whether or not to enable inbound access to a TURN server I 
am running.

In this case, I'm the provider of a TURN server accessible to other 
hosts that I don't control. Relaying traffic costs me money, so I need 
to do everything possible to make sure that I control who uses the 
server. Of course I'll enable long-term credentials. I'll also turn on a 
whole lot of logging, do traffic shaping, set up alerts for suspicious 
traffic patterns, etc. If I'm an IT department, I never open a port up 
without a full security analysis of the system I'm providing access to, 
so there's not really any way the port is getting opened without the 
server being set up properly first.

None of these use cases is made safer by *requiring* long-term 
credential authentication, or any authentication. In use case 1, once 
you've allowed your clients out, they might be connecting to *anything*, 
and you don't really care if the server gets abused. In use case 2, 
you've still let your clients out and it still isn't really your problem 
if the server gets misused by others. In use case 3, you're the 
responsible operator of the server and so you already need to be fully 
aware of the risks of running such a thing in whatever mode you've 
configured it in.

The reality is that most firewalls will be configured to let UDP 
sessions initiated from inside go to the outside, on all ports, and a 
few (run by paranoid IT departments, as opposed to being freebies that 
come with home gateways) will be configured to let *no* UDP sessions 
initiated from inside to go to the outside. The latter ones may make 
exceptions for specific ports, but TURN's advertised ability to be used 
as a way for people to get back to the originating host will make that 
one of the less-likely exceptions... and mandatory authentication 
doesn't solve the problem they're worried about at all.

Matthew Kaufman

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 14 Sep 2009 09:01:03 -0700

> unauthenticated-but-secured HTTP proxy.

IT department can deploy whatever they want, with whatever security level they
want on an inside network.  But TURN, which is an *Internet* protocol, must be
secure.

I fully support Magnus text.

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 14 Sep 2009 10:22:26 -0700

> want on an inside network.  But TURN, which is an *Internet* protocol, must be
[Delete references to many recent insecure Internet protocols as 
counterexamples]

As I said, I have no problem with TURN going this way, but then a widely 
deployed TURN (draft) client will undoubtedly be switching to a 
different, most likely proprietary, proxy protocol. Which is really 
unfortunate in that it could be a big driver for TURN server 
implementation and deployment, but seems already necessary in light of 
the lack of response on the CreatePermission issue.

Matthew Kaufman

---

From: Dave Thaler <[email-masked]>
Date: Mon, 14 Sep 2009 20:10:06 +0000

>    authenticate requests use the Long-Term Credential mechanism if

IF we go with MUST, then I disagree with the phrasing
" if using client and server certificates that actually identify 
the parties, i.e. no self-signed certificates"
My understanding is that whether the certificates are self-signed or 
signed by someone else is irrelevant.  What is relevant is whether they're
signed by something that the server trusts.  The server can certainly
be configured to trust a specific self-signed cert.

Suggest "if using client certificates that the server trusts" or
equivalent wording, if the decision is to go with the proposed new text.

-Dave

---

From: "Peter Livesey" <[email-masked]>
Date: Mon, 14 Sep 2009 18:17:13 +0200

It's only an *Internet* protocol if it has many implementations which
are widely used. If people/vendors are reluctant to implement it until
the drafts become a RFC then delaying it over a MUST/SHOULD seems self
defeating.

If it's a SHOULD then vendors can decide if their implementations make
it a MUST by always challenging  or leave it up to the administrators of
their equipment to decide (via configuration), based on the deployment
case.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marc Petit-Huguenin
Sent: 14 September 2009 17:01
To: [email-masked]
Cc: Behave WG; Tim Polk
Subject: Re: [BEHAVE] Discusses regarding security mechanism usage for
TURN

> unauthenticated-but-secured HTTP proxy.

IT department can deploy whatever they want, with whatever security
level they
want on an inside network.  But TURN, which is an *Internet* protocol,
must be
secure.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Sep 2009 13:02:13 -0700

> their equipment to decide (via configuration), based on the deployment

Most software developers will use anything they can to not implement stuff, and
for them SHOULD = do not bother.  I saw it happen so many time that it is not
funny anymore.  Making it configurable is OK but having two different products,
one for the Internet and another for the walled gardens is even better.  The
important part is been able to blame the sysadmins when bad things _will_ happen.

So far I didn't see one single use case where a TURN server on the *Internet*
would need disabled authentication.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Sep 2009 16:16:16 -0400

The proposed text doesn't talk about what needs to be implemented, it talks 
about what goes on the wire.

I'd be fine with a MUST implement, SHOULD use.

The proposed text says MUST implement, MUST use.

On Tuesday 15 September 2009 16:02:13 Marc Petit-Huguenin wrote:
> So far I didn't see one single use case where a TURN server on the
> *Internet* would need disabled authentication.

           +-------<Internet>-----------+
           |                            |
        +-----+                 +-------------+
--------| NAT |-----------------| TURN server |------------------------
        +-----+                 +-------------+
           |                            |
           +-----<Private network>------+

Authentication is not needed on the private side. It is pointless to mandate 
it.

If the proposed text's "MUST use" only applies to the Internet side, it needs 
to be more explicit.

Simon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Sep 2009 13:50:53 -0700

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

Well, your diagram shows that the TURN server is not on the Internet so why an
Internet protocol should apply to it?  At best it is an Internet host (the side
connected to the Internet), and should follow RFC 1122 but not much more can be
said about this.

I would add that the TURN spec specifically talk about a TURN server with the
two sides on the Internet:

"This relay typically sits in the public Internet and relays packets between two
hosts that both sit behind NATs."

Some people probably have a need for a "TURN" server that works like your
diagram, but it should defined be, IMO, in a different spec (or better, a
different SDO).

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 15 Sep 2009 14:19:05 -0700

> diagram, but it should defined be, IMO, in a different spec (or better, a

BEHAVE's charter is to work on NAT traversal. TURN has the opportunity 
to be a fairly general UDP-over-UDP relay protocol usable for NAT 
traversal in both the "TURN server on public Internet" and "TURN server 
sitting in parallel with non-compliant NAT" cases. Or, by requiring 
"MUST" here, TURN can be made less applicable for the latter case.

If we wanted to ignore everything that isn't "on the public Internet", 
then I suppose BEHAVE wouldn't have any work to do, as everything behind 
a NAT isn't. I think you may be confusing "the public Internet" and 
"those networks over which IETF-standardized protocols might run", as 
the latter is a much larger scope, and most definitely within both 
IETF's scope and the BEHAVE WG's charter.

Matthew Kaufman

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Sep 2009 14:55:22 -0700

Matthew Kaufman wrote:
>>> The proposed text doesn't talk about what needs to be implemented, it
>>> talks about what goes on the wire.
>>>
>>> Authentication is not needed on the private side. It is pointless to
>>> mandate it.
>>>
>>> If the proposed text's "MUST use" only applies to the Internet side,
>>> it needs to be more explicit.
>>>     
>>

Then call NRUT the version of TURN that does not do authentication, and I will
have no other objection.

> IETF's scope and the BEHAVE WG's charter.

I am not confusing anything, and "public Internet" is a pleonasm.

Your computer is no more connected to the Internet than the faucet in my kitchen
is connected to the Almaden Reservoir.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Sep 2009 16:21:03 -0700

OK, let's be practical.  What about saying that if the client request comes from
a non RFC 1918 IP address, the request MUST be authenticated? (and adding the
equivalent for IPv6).

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 15 Sep 2009 19:30:59 -0400

> a non RFC 1918 IP address, the request MUST be authenticated? (and adding the

the problem with this proposal is that the source IP address does not 
tell if you are on public or private or ... These days, broadband 
providers are deploying RFC1918 to the subscribers... In fact, I think 
the wording should instead be related to the deployment scenario. This 
is not the first case in IETF for this kind of scenarios. I'm sure we 
can borrow some text from other protocols on this.

Marc.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Sep 2009 16:47:16 -0700

Marc Blanchet wrote:
> providers are deploying RFC1918 to the subscribers...

I am not sure to understand why this scenario would be a problem.  If the TURN
server is outside the provider's network, then there will be authentication.  If
inside, then no authentication but it is fine because this is all the provider's
customers.  Or is there something I missed?

> In fact, I think

And in fact I just realized that a TURN client (on a private or public network)
that succeed to connect to a TURN server on a public network without
authentication should better disconnect immediately.  I do not want my customers
to be investigated when the TURN server will be seized to find who is using it
to anonymously stream illegal stuff.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 15 Sep 2009 21:01:22 -0400

Marc Petit-Huguenin a écrit :
> I am not sure to understand why this scenario would be a problem.

What I'm just saying is that the assumption that a type of IP address 
(RFC1918 or non-RFC1918) does not tell you anything about the location 
of the node. Therefore, one can not use this criteria for deciding to 
use or not to use authentication.

Marc.

>  If the TURN

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Sep 2009 11:56:25 +0200

> equivalent wording, if the decision is to go with the proposed new text.

Yes, I think that is a better wording. No problem with such a change
from my perspective.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Sep 2009 13:05:29 +0200

Hi Matthew,

Tim and Cullen can you please comment also.

I think you have me convinced about the placement on the border of an
enterprise domain and only serve internal requests. I can't answer for
the other ADs. Cullen has raised concerns that the document isn't well
structured to describe this usage in good way.

Can you propose how to implement this deployment scenario in the
document such that is made clear the following:

- Only in this specific deployment may it be ok to not use individual
authentication.
- What requirements it puts on the TURN server when it comes to usage.
In other words, what messages MUST be comming from the internal side and
 how to determine that.

Best Regards

Magnus

-- 

Magnus Westerlund

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 16 Sep 2009 10:51:33 -0600

> Cullen and Tim, does this text satisfies your discusses?

That would solve my concern.

Cullen <in my AD role>

---

From: "Polk, William T." <[email-masked]>
Date: Wed, 30 Sep 2009 09:06:53 -0400

This would work for me too.

On 9/16/09 12:51 PM, "Cullen Jennings" <[email-masked]> wrote:

Cullen <in my AD role>