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

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 30 Jul 2013 06:37:12 +0200

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.

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.

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

Thanks.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 30 Jul 2013 05:40:15 +0000

Marc,

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

Would it be wise to say there are indeed problems with long-term authentication and document them for the benefit of the community?

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

+1

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Petit-Huguenin
|Sent: Tuesday, July 30, 2013 10:07 AM
|To: [email-masked]
|Subject: [BEHAVE] Comments on the TURN REST Server API presentation
|
|-----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.
|
|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.
|
|Finally a small nit:  In the presentation the wrong syntax was used for the
|turn uri:  the parameter name is transport=, not proto=.
|
|Thanks.
|
|- --
|Marc Petit-Huguenin
|Email: [email-masked]
|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
[email-masked]
|https://www.ietf.org/mailman/listinfo/behave

---

From: Simon Perreault <[email-masked]>
Date: Tue, 30 Jul 2013 07:58:18 +0200

> generate/verify the same username/password, so an I-D is required to ensure

After hearing the presentation and the discussion, that's the way I'm 
thinking too. I would expect that third option to not be 
username/password based, but rather token-based.

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 30 Jul 2013 08:26:14 +0200

On 07/30/2013 07:40 AM, Muthu Arul Mozhi Perumal (mperumal) wrote:
> Marc,
> 
> |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.
> 
> Would it be wise to say there are indeed problems with long-term 
> authentication and document them for the benefit of the community?
> 

There is no undocumented problem with long-term authentication (as this is
similar to HTTP digest).  TURN over DTLS can help, and I plan to write an I-D
describing it as I need the reference in another draft developed in P2PSIP.

- -- 
Marc Petit-Huguenin

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 30 Jul 2013 06:49:52 +0000

>username/password based, but rather token-based.

Yes, a token based approach should be considered. A TURN server can then
also, more easily, cater to regular clients that want to use
username/password like they do today.

The draft does not provide details on the mechanics of shared secret
exchange between the web-server and turn-server. The assumption is that
the two are always well known to each other, but that not may not be the
case always - a turn server should be able to fetch shared secret from a
previously unknown server, on demand. Also, what if multiple web-servers
want to avail the services of the same turn server? How does the turn
server know which shared secret to choose, realm maybe?

-Prashanth

>_______________________________________________
>Behave mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/behave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 30 Jul 2013 12:53:53 +0200

On 07/30/2013 08:49 AM, Prashanth Patil (praspati) wrote:
>>> 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.
>> 

Yes, I was talking with someone about that yesterday.  We need two different
ways to provision the shared key:

- - In the model proposed by Justin, the key is manually shared between the TURN
server and the Web server.  This requires that the two servers are under the
control of the same entity.

- - A different model would be necessary when the TURN server is not directly
controlled by the same entity that is controlling the Web server.  That would
require a protocol between the Web server and the TURN server so they agree on
a common key (but also can rollover new keys).  That would require a second
I-D to define this protocol.

- -- 
Marc Petit-Huguenin

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 30 Jul 2013 15:59:42 +0000

> -----Original Message-----
> From: Prashanth Patil (praspati)
> Sent: Tuesday, July 30, 2013 12:20 PM
> To: Simon Perreault; [email-masked]
> Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation
> 
> 
> 
> >>authentication
> >>ensure

Agreed. OAuth 2.0 framework could be used to solve the problem which discusses both self-contained and handle tokens.

--Tiru.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 30 Jul 2013 17:59:12 +0000

|-----Original Message-----
|From: Marc Petit-Huguenin [mailto:[email-masked]]
|Sent: Tuesday, July 30, 2013 11:56 AM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]
|Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation
|
|-----BEGIN PGP SIGNED MESSAGE-----
|Hash: SHA256
|
|On 07/30/2013 07:40 AM, Muthu Arul Mozhi Perumal (mperumal) wrote:
|> Marc,
|>
|> |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.
|>
|> Would it be wise to say there are indeed problems with long-term
|> authentication and document them for the benefit of the community?
|>
|
|There is no undocumented problem with long-term authentication (as this is
|similar to HTTP digest).  TURN over DTLS can help, and I plan to write an I-D
|describing it as I need the reference in another draft developed in P2PSIP.

What are the motivations for the third authentication mechanism for TURN and why is TURN over DTLS needed?

Muthu

|
|- --
|Marc Petit-Huguenin
|Email: [email-masked]
|Blog: http://blog.marc.petit-huguenin.org
|Profile: http://www.linkedin.com/in/petithug
|-----BEGIN PGP SIGNATURE-----
|Version: GnuPG v1.4.14 (GNU/Linux)
|
|iQIcBAEBCAAGBQJR91yEAAoJECnERZXWan7EXvsQANOnVeBhvgnuhIN7Kj7CJRyH
|FRkZVTQP+7wix1+JPie9PQawyQkJ4ef3YVK0D/WNHJOx7DtoBUxFsGx69ttvZ6IQ
|F6mbWfi7vmGeZhlc54dpgcOzsK5zUynQgVG3/jiat4LPEEoy1PDh1M1elVdNl0qx
|4ZPtoAzep9VqBiDyGlqDx4n/yEKMJgasF3SQihhqsxnfeSvC1hByrHc0eo1uzAa1
|0iJTgVDVTQDUQD/BZ6EvkJ0rs8I3fDM/xaMxOHpEGWTRa/a8iszXGRlQkZqmLy05
|bI1EZMIjkogUN086Lvx92iIU7yuRUTn0mCocmI5wEh4ZMqjqk62q1+HJFilsLPuz
|aVn5ckrJb7pxvQaOLp/JWvqDWtLXUSF+zkJTVb3uYzYGWQElEMUIyTlANRuq0Mdp
|MntVcPrwTLxOzFylwnkqZgRIWQ4agXRrq7j+PokkBam/zC0+wZHTrWlb2VbcTmYw
|vFfVKLqPUSw4vGmU+nN+Yy1oGWmlBzFoZdFUHPyML7Y+bB7Qy6uQs/RGlMTwrD0f
|dKD3ECsQm5m4Fm5YdFBnbdaUus2SDCY1eySHVoVIFJyYLo5tLQXY54C63qU2O3JQ
|oudSjsBiqDS2g2Lf6G3J+0dAZgFBuoad9YbOq15uU86LebGllGxmBeifj9b/HacC
|n6YlqkFeLfBm9qOyKuHs
|=cg/q
|-----END PGP SIGNATURE-----

---

From: Justin Uberti <[email-masked]>
Date: Wed, 31 Jul 2013 13:56:30 +0200

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>

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.

> generate/verify the same username/password, so an I-D is required to ensure

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.

> turn uri:  the parameter name is transport=, not proto=.

My mistake. Thanks.

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 31 Jul 2013 16:28:26 +0200

On 07/30/2013 07:59 PM, Muthu Arul Mozhi Perumal (mperumal) wrote:
> |-----Original Message----- |From: Marc Petit-Huguenin
> [mailto:[email-masked]] |Sent: Tuesday, July 30, 2013 11:56 AM |To: Muthu
> Arul Mozhi Perumal (mperumal) |Cc: [email-masked] |Subject: Re: [BEHAVE]
> Comments on the TURN REST Server API presentation | |-----BEGIN PGP SIGNED
> MESSAGE----- |Hash: SHA256 | |On 07/30/2013 07:40 AM, Muthu Arul Mozhi
> Perumal (mperumal) wrote: |> Marc, |> |> |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. |> |> Would it be wise to
> say there are indeed problems with long-term |> authentication and document
> them for the benefit of the community? |> | |There is no undocumented
> problem with long-term authentication (as this is |similar to HTTP digest).
> TURN over DTLS can help, and I plan to write an I-D |describing it as I
> need the reference in another draft developed in P2PSIP.
> 
> What are the motivations for the third authentication mechanism for TURN

The server side implementation of the long-term authentication as proposed by
Justin would be different than an server-side implementation of the long-term
authentication described in RFC 5389.  Having a different authentication
protocol (on the wire) would permit to have TURN server implementation that
can implement the two variants of long-term authentication (e.g. if a TURN
server is used for both SIP and Webrtc)

> and why is TURN over DTLS needed?

For the same reasons HTTPS is needed for Digest Authentication.

> 
> Muthu
> 
> | |- -- |Marc Petit-Huguenin |Email: [email-masked] |Blog:
> http://blog.marc.petit-huguenin.org |Profile:
> http://www.linkedin.com/in/petithug |-----BEGIN PGP SIGNATURE----- 
> |Version: GnuPG v1.4.14 (GNU/Linux) | 
> |n6YlqkFeLfBm9qOyKuHs |=cg/q |-----END PGP SIGNATURE-----
> 

- -- 
Marc Petit-Huguenin

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 31 Jul 2013 16:50:53 +0200

[...]
> server is used for both SIP and Webrtc)

I do not think this is a problem. The authentication can be attempted 
first against the (known) set of sip users and if the user is not known, 
shared secret authentication is tried.

The other difference between the two groups is that for ssauth users, 
the timestamp needs to be checked for expiration. The other way round 
this might be phrased as "expiration is indefinite for sip users".

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 31 Jul 2013 17:00:02 +0200

On 07/31/2013 01:56 PM, Justin Uberti wrote:
> 
> On Tue, Jul 30, 2013 at 6:37 AM, Marc Petit-Huguenin <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 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.

I agree, but in this case you probably also need to define the mechanism to
share the key with the provider of the TURN server.  I would suggest to have
the RESTful API and this key sharing mechanism  in a separate document, and to
keep the new authentication alone in this one (i.e. when the Web server and
turn server are from the same provider, so key provisioning can stay unspecified).

>> But perhaps the IETF is not the right forum for this.
> 
> 
> 
> 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.

As I said I plan to release such I-D before Vancouver.

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

My vote is on specifying a token-based authentication mechanism.

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

- -- 
Marc Petit-Huguenin

---

From: Justin Uberti <[email-masked]>
Date: Wed, 31 Jul 2013 21:16:06 +0200

On Wed, Jul 31, 2013 at 4:50 PM, Philipp Hancke
<[email-masked]>wrote:

> The other difference between the two groups is that for ssauth users, the
> timestamp needs to be checked for expiration. The other way round this
> might be phrased as "expiration is indefinite for sip users".

To avoid the possible double check, we could just define a prefix that is
part of the username, e.g. the complete username would be
"rest:12345678:foo".

>
> ______________________________**_________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/behave<https://www.ietf.org/mailman/listinfo/behave>
>

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 01 Aug 2013 08:56:41 +0200

Am 31.07.2013 21:16, schrieb Justin Uberti:
[...]
> part of the username, e.g. the complete username would be

For differentiating shared secret and sip users this shouldn't even be 
necessary since sip localparts typically don't contain a colon (see e.g. 
the table of disallowed characters in
http://tools.ietf.org/html/draft-ietf-stox-core-00#section-4.2).