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

>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:juberti@google.com] 
Sent: Wednesday, July 31, 2013 5:27 PM
To: Marc Petit-Huguenin
Cc: Behave@ietf.org
Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation

On Tue, Jul 30, 2013 at 6:37 AM, Marc Petit-Huguenin <petithug@acm.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBCAAGBQJR90LqAAoJECnERZXWan7EoiMP/R90khv1Ez+2652uCRIBjNhS
JyGpoNNVsqaPFPHo9jJ5pvJu0qYEUKrzXwoZtRn80UFFUojJIFsx0XmzwkDl7qAq
hsz+rPxCvVL3iTBvNGSee8HEZiLzzSkba34nwDoH4qrVEiWX3njcJH1P1bfbrrhk
rOxVMTSoXK7P118RFp0iQYyfTAf5RlH292u9vrCRljW2OjE644APBNgWyEyoi/J5
vJnPPvBSrR5hYftn0DrCRLsOm5PPc+6lZ23BzEa+0yJdp2C4Fez7Z4uHTMhw4bBP
UOpXb88ZpuUlcLUjj+XU9JMYm7VhP+CKZw+AkXMGXAmiMa4jc6Ria1sTkeCXdT8J
cXyyxjBl/CYuhxqMhM3Hxm2ifeV6jQEX5bdk+5y+Qp8Jg++cjjeNYd/Yt8uJPYe3
nFxkKHAK4kr63NIwfPJFWfVE44NwbvmyCsHmTNcDXloq4DFeWGKxsEnngWjeSOIE
3HddtKgcTtL8AtNY9FVlPZMlmDI+Lh9eO+l+05IRIizIDsL8w3WMlpCXiPfrUq1X
SQcCxMBJHSAINqMGT4U0sw+VAI6lCTAnJW9AQFZebdDmf2KAsWDxLGwkW0G47/yg
rwKGAZhi14OuMc8yY8eWIbU+KRxPUkbS3p7AWVh5qNhTXYdllVjzJORvZ584vp0I
RjEwVbloGz5LYN0CCCBh
=L8qI
-----END PGP SIGNATURE-----
_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave