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

[Simon Perreault <[e-mail]>]

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.
>
> But TURN servers let's say deployed in DMZ need authentication.

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.

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

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

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

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