Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 1 Aug 2013 07:52:10 +0000

>The others (rtcweb password exposure, TURN credential DB) are addressed by the ephemeral/token based approach. There seems to be a general desire to do >this through OAuth, using either normal tokens that are checked back against the AS, or self-contained tokens which can be checked directly at the TURN >server, so I will look at updating the draft to use OAuth. This will also resolve the issues raised about how separate web and TURN servers can share a >secret. 

OAuth RFC 6819 discusses the pros/cons of self-contained token verses handle token. 

>The main question here is whether this requires an update to the TURN protocol to specify a token-based auth mechanism, or if it is possible to overload >the long-term auth mechanism, since I think they will be fairly similar in operation.

If let's say self-contained/handle token is selected then there is no need to send any USERNAME, new STUN attribute to indicate TURN server supports this new mechanism, new STUN attribute to send the token to TURN server etc. 
PCP http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-00 also uses similar technique.

--Tiru.

From: Justin Uberti [mailto:[email-masked]] 
Sent: Wednesday, July 31, 2013 5:27 PM
To: Marc Petit-Huguenin
Cc: [email-masked]
Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation

On Tue, Jul 30, 2013 at 6:37 AM, Marc Petit-Huguenin <[email-masked]> wrote:

About this presentation, I agree with what Martin Thomson said on the
microphone (trying to paraphrase from memory as the audio recording is not
available yet):  There is no need to standardize a RESTful API because the
server can send the username/password in the web page that uses rtcweb, or can
use any proprietary API between the javascript client and the server.  There
is no interoperability issue here.

I think rtcweb (including non-browser clients) would benefit from having a common interface defined to get access to TURN servers, so that it would be easy to use different providers. But perhaps the IETF is not the right forum for this.

Second, I do not think that trying to overload the long-term authentication
mechanism is wise - and I take exceptions with the previous presentation that
characterized long-term authentication as having problems.  This is how
long-term authentication works, and that should be left alone.  IMO what is
needed is to design a third authentication option for TURN (probably with new
attributes) that is doing the username/password stateless verification.  Here
there is a need to define how the web server and the turn server can
generate/verify the same username/password, so an I-D is required to ensure
interoperability.

I think it's clear that there are limitations to long-term authentication. Some (cleartext USERNAME, dictionary attacks on M-I) can be largely mitigated if we add support for TURN over DTLS, which I think is a good idea.

The others (rtcweb password exposure, TURN credential DB) are addressed by the ephemeral/token based approach. There seems to be a general desire to do this through OAuth, using either normal tokens that are checked back against the AS, or self-contained tokens which can be checked directly at the TURN server, so I will look at updating the draft to use OAuth. This will also resolve the issues raised about how separate web and TURN servers can share a secret. 

The main question here is whether this requires an update to the TURN protocol to specify a token-based auth mechanism, or if it is possible to overload the long-term auth mechanism, since I think they will be fairly similar in operation.

Finally a small nit:  In the presentation the wrong syntax was used for the
turn uri:  the parameter name is transport=, not proto=.

My mistake. Thanks. 

Thanks.

- --
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave