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

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

> -----Original Message-----
> From: Simon Perreault [mailto:[e-mail]]
> Sent: Friday, April 26, 2013 1:42 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [e-mail]
> Subject: Re: [BEHAVE] FW: New Version Notification for draft-reddy-behave-
> turn-auth-00.txt
> 
> 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.

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

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

Yes, will highlight that point.

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

Yes it does, Do you want us to merge problem 1 and 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?

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.

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

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

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

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.

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

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.

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