Subject: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-00.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 24 Apr 2013 03:22:20 +0000

This draft discusses some of the problems with current TURN authentication so that it can serve as the basis for stronger TURN authentication mechanisms.  

comments and suggestions are welcome.

Best Regards,
--Authors.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, April 23, 2013 6:04 PM
To: Ram Mohan R (rmohanr); Tirumaleswar Reddy (tireddy); Muthu Arul Mozhi Perumal (mperumal); Alper Yegin; Ram Mohan R (rmohanr); Alper E. Yegin; Muthu Arul Mozhi Perumal (mperumal)
Subject: New Version Notification for draft-reddy-behave-turn-auth-00.txt

A new version of I-D, draft-reddy-behave-turn-auth-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Filename:	 draft-reddy-behave-turn-auth
Revision:	 00
Title:		 Problems with TURN Authentication
Creation date:	 2013-04-23
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-reddy-behave-turn-auth-00.txt
Status:          http://datatracker.ietf.org/doc/draft-reddy-behave-turn-auth
Htmlized:        http://tools.ietf.org/html/draft-reddy-behave-turn-auth-00

Abstract:
   This document discusses some of the issues with TURN authentication.

The IETF Secretariat

---

From: Simon Perreault <[email-masked]>
Date: Wed, 24 Apr 2013 10:23:43 +0200

> comments and suggestions are welcome.

And here are some...

- "TURN authentication" doesn't exist. It's "STUN authentication" that 
you're talking about. TURN just uses STUN auth.

- In section "4. Problems with TURN Authentication", what's the 
difference between problems 1 and 2?

- Problem 4 could also include the REALM attribute, which could be 
snooped and harvested similarly.

- About the above: wasn't this all well known and accepted at the time 
STUN auth was being designed?

- I have encountered another problem: it's impossible to host multiple 
realms on a single IP address. When the server needs to send the REALM 
attribute in response to an unauthenticated request, it has no useful 
information for determining which realm it should send, except the 
destination address of the request. This sucks, IPv4 addresses being not 
exactly free...

I'm very interested in hearing about any solution you may have in mind...

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 25 Apr 2013 18:44:24 +0000

Hi Sam,

Thanks for the comments; please see inline

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Wednesday, April 24, 2013 1:54 PM
> To: [email-masked]
> Subject: Re: [BEHAVE] FW: New Version Notification for draft-reddy-behave-
> turn-auth-00.txt
> 
> > This draft discusses some of the problems with current TURN authentication
> so that it can serve as the basis for stronger TURN authentication mechanisms.
> >

Yes, TURN uses the authentication mechanism specified in STUN. TURN authentication is required because resources will be allocated on the TURN server, whereas with STUN there are no resources allocated on the STUN server. The STUN server is stateless and is only responding to the request from the client. Though both techniques need authentication for integrity protection of request and response. But there are STUN servers deployed without authentication and if the endpoints use DTLS-SRTP then there may not be a problem even if man-in-middle device modifies the STUN response. 

But TURN servers let's say deployed in DMZ need authentication.

> difference between problems 1 and 2 ?

[TR] Problem 1 seem to be possible even if strong password is used. since password does not change frequently, the attacker could keep trying a number of candidate passwords.
[/TR]

> STUN auth was being designed ?

May be the authors of STUN/TURN could answer this question, if these attacks were previously discussed or not in WG. If TURN over TLS is used it would solve the problem; but it would impact sending media over TCP and could introduce delays which are directly noticeable.

> destination address of the request. This sucks, IPv4 addresses being not

Good point. For web Authentication, destination IP address helps to pick different REALM, but with TURN the only 
information available is the Source IP.

> I'm very interested in hearing about any solution you may have in mind...

we are still discussing the solutions, some of them already being discussed in PCP WG that needs to be evaluated for TURN are EAP-over-TURN, PANA etc. 

--Tiru.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 26 Apr 2013 10:12:02 +0200

Le 2013-04-25 20:44, Tirumaleswar Reddy (tireddy) a écrit :
>> - "TURN authentication" doesn't exist. It's "STUN authentication"
>> that you're talking about. TURN just uses STUN auth.
>
> Yes, TURN uses the authentication mechanism specified in STUN. TURN
> authentication is required because resources will be allocated on the
> TURN server, whereas with STUN there are no resources allocated on
> the STUN server. The STUN server is stateless and is only responding
> to the request from the client. Though both techniques need
> authentication for integrity protection of request and response. But
> there are STUN servers deployed without authentication and if the
> endpoints use DTLS-SRTP then there may not be a problem even if
> man-in-middle device modifies the STUN response.
>

I understand all that, but that's not the point.

The point is that "TURN authentication" does not *exist*. All the 
problems you have identified apply to *STUN* authentication, which is 
defined in the *STUN* RFC.

The fact that the Allocate request is more likely than the Binding 
request to be identified by a server administrator as needing auth 
protection is completely irrelevant, except perhaps in the introduction, 
or an operational considerations section.

> [TR] Problem 1 seem to be possible even if strong password is used.
> since password does not change frequently, the attacker could keep
> trying a number of candidate passwords. [/TR]

Doesn't that characteristic also apply to problem 2?

>> - About the above: wasn't this all well known and accepted at the
>> time STUN auth was being designed ?
>
> May be the authors of STUN/TURN could answer this question, if these
> attacks were previously discussed or not in WG. If TURN over TLS is
> used it would solve the problem; but it would impact sending media
> over TCP and could introduce delays which are directly noticeable.

DTLS?

>> - I have encountered another problem: it's impossible to host
>> multiple realms on a single IP address. When the server needs to
>> send the REALM attribute in response to an unauthenticated request,
>> it has no useful information for determining which realm it should
>> send, except the destination address of the request. This sucks,
>> IPv4 addresses being not exactly free...
>
> Good point. For web Authentication, destination IP address helps to
> pick different REALM, but with TURN the only information available is
> the Source IP.

Exactly!

I guess (D)TLS would solve that issue with the server_name extension 
[RFC6066].

> we are still discussing the solutions, some of them already being
> discussed in PCP WG that needs to be evaluated for TURN are
> EAP-over-TURN, PANA etc.

I don't think we can rely on the PCP stuff also applying to STUN. The 
environments are very different, both on servers and clients.

Anyway, I would appreciate being involved in that discussion.

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 26 Apr 2013 13:05:26 +0000

> Sent: Friday, April 26, 2013 1:42 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [email-masked]

Agreed, will update in the next version to say it's a problem with STUN Authentication.

> or an operational considerations section.

Yes, will highlight that point.

> Doesn't that characteristic also apply to problem 2 ?

Yes it does, Do you want us to merge problem 1 and 2 ?

> > over TCP and could introduce delays which are directly noticeable.

Yes, that is one possibility to use EAP over DTLS and multiplex the channelData also on the same 5-tuple (for fate sharing).
we are yet to evaluate if it works, any problems with multiplexing etc.

> snooped and harvested similarly.

Do you have an attack or privacy problem in mind with REALM that we can add ? 

> I guess (D)TLS would solve that issue with the server_name extension

Yes, it will solve the problem. will add the problem you mentioned in the next version, so that it will help coming up with a solution.

> environments are very different, both on servers and clients.

Agreed, though there could be some scenarios where PCP capable Firewall and TURN server could be co-located. 

> Anyway, I would appreciate being involved in that discussion.

sure, will be happy to involve you in the discussion.

Regards,
--Tiru.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 26 Apr 2013 15:16:11 +0200

> Yes it does, Do you want us to merge problem 1 and 2 ?

Well, I'm just trying to understand. If 1 and 2 are the same problem, 
then yes they should be merged. At this point I don't see any difference 
between the two.

> Do you have an attack or privacy problem in mind with REALM that we can add ?

Not really. I guess that leaking the domain of a call is acceptable.

> Agreed, though there could be some scenarios where PCP capable Firewall and TURN server could be co-located.

Right. I am more focused on the WebRTC use case, where the TURN server 
is operated by the WebRTC application provider, and thus completely 
separate from any firewall the user might be behind.

Simon

---

From: Alper Yegin <[email-masked]>
Date: Fri, 26 Apr 2013 19:30:05 +0300

>> environments are very different, both on servers and clients.

I think the point is, there are two approaches here: One is to define protocol-specific EAP transport (such as EAP-over-PCP, and EAP-over-TURN, etc.), or to rely on using PANA.