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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Sam,

Thanks for the comments; please see inline

> -----Original Message-----
> From: Simon Perreault [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2013 1:54 PM
> To: [e-mail]
> Subject: Re: [BEHAVE] FW: New Version Notification for draft-reddy-behave-
> turn-auth-00.txt
> 
> Le 2013-04-24 05:22, Tirumaleswar Reddy (tireddy) a écrit :
> > 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.
> 
> And here are some...
> 
> - "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. 

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

> 
> - In section "4. Problems with TURN Authentication", what's the
> 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]

> 
> - 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 ?

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.

> 
> - 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.

> 
> 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.

> 
> Simon