Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt

From: Justin Uberti <[email-masked]>
Date: Mon, 15 Jul 2013 17:52:50 -0400

I have changed the WG for this draft from RTCWEB to BEHAVE. Many, but not
all of the comments I received on the RTCWEB mailing list have been
addressed.

BEHAVE chairs, I would like 10 minutes of agenda time to discuss this draft.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Jul 15, 2013 at 5:49 PM
Subject: New Version Notification for draft-uberti-behave-turn-rest-00.txt
To: Justin Uberti <[email-masked]>

A new version of I-D, draft-uberti-behave-turn-rest-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename:        draft-uberti-behave-turn-rest
Revision:        00
Title:           A REST API For Access To TURN Services
Creation date:   2013-07-15
Group:           Individual Submission
Number of pages: 8
URL:
http://www.ietf.org/internet-drafts/draft-uberti-behave-turn-rest-00.txt
Status:
http://datatracker.ietf.org/doc/draft-uberti-behave-turn-rest
Htmlized:        http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00

Abstract:
   This document describes a proposed standard REST API for obtaining
   access to TURN services via ephemeral (i.e. time-limited)
   credentials.  These credentials are vended by a web service over
   HTTP, and then supplied to and checked by a TURN server using the
   standard TURN protocol.  The usage of ephemeral credentials ensures
   that access to the TURN server can be controlled even if the
   credentials can be discovered by the user, as is the case in WebRTC
   where TURN credentials must be specified in Javascript.

The IETF Secretariat

---

From: Rajmohan Banavi <[email-masked]>
Date: Thu, 18 Jul 2013 00:26:22 +0530

Hi Justin,

I reviewed draft-uberti-behave-turn-rest-00 and have the following comments.

   1. IMHO, calling the API as REST does not seem to be appropriate since
   the API does not follow the REST principles of addressing/operating on a
   resource.
   2. Sec 4.3 last paragraph - "Because the password is derived from the
   USERNAME, successful verification of the MESSAGE-INTEGRITY ensures that the
   username is trustworthy". I believe this validation is taken care of in the
   TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, the TURN
   client generates a long term key which is computed as => key =
   MD5(username ":" realm ":" SASLprep(password)). This key is used to perform
   hmac on the message. The same is done on the TURN server end as well. If
   the MESSAGE-INTEGRITY is verified, then it implies that the username is
   trustworthy. So why not just generate a TURN password randomly? This
   would avoid the need to have a secret key between the TURN server and the
   webrtc app. Am I missing any scenario here where this extra security is
   required?
   3. sec 4.1 Client - Does it make it more clear if we reword the last
   sentence as - and the "password" value as input to generate the HMAC digest
   key used while calculating MESSAGE-INTEGRITY hash.
   4. Sec 5.1 Revocation - Why is revoking of specific credentials not
   possible? Probably need more clarity on who would try to revoke the
   credentials and under what scenario?
   5. Sec 5.2 Key Rotation - I presume here that the shared secret
   mentioned is the one shared between the TURN server and the webrtc
   application. The TURN password once generated using say secretkey1 and
   user1 will be valid on the TURN server till the expiry timeout (as per
   suggested value of 1 day) value. Why do we then need the TURN server to
   validate the message integrity against 2 secret keys? Wouldn't this
   behavior not contradict the one stated in TURN RFC?

Thanks,
Rajmohan
MindBricks

On Tue, Jul 16, 2013 at 3:22 AM, Justin Uberti <[email-masked]> wrote:

> Htmlized:
> http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00
>
>
> Abstract:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

-- 

Life is here and now, not yesterday, not tomorrow...!

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 17 Jul 2013 22:39:34 +0200

> I reviewed draft-uberti-behave-turn-rest-00 and have the following comments.
[...]
>     trustworthy.

Let me try to address that with a lenghty example:
The web server returns
password = BASE64(HMAC-SHA1(username, sharedsecret))
to the browser.

For example, with username = "12334939:mbzrxpgjys" and sharedsecret 
"secret", the password given to the browser would be
"+4pCXR06gx/cqAikLYnBajtZW6E=" (hopefully)

The browser passes the username, uri and password to it's webrtc stack.
The password is exposed to the user of the browser (which might be 
anyone surfing your website) during that process.

That stack does long term authentication and uses this password string 
as input for calculating MESSAGE-INTEGRITY with
key = MD5(username ":" realm ":" SASLprep(password))

For the example this would be
key =MD5("12334939:mbzrxpgjys" ":" realm ":" 
SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=")

On the TURN server, the key for MESSAGE-INTEGRITY is calculated using
key = MD5(username ":" realm ":" SASLprep(BASE64(HMAC-SHA1(USERNAME, 
sharedsecret))

So for the example this would be
  = MD5("12334939:mbzrxpgjys" ":" realm ":" 
SASLprep(BASE64(HMAC-SHA1("12334939:mbzrxpgjys", "secret"))
  = MD5("12334939:mbzrxpgjys" ":" realm ":" 
SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=")

So the browser and turn server use the same input to the M-I. This can 
be done by looking at the request alone given the shared secret.

Does that make it clearer?

philipp,
who only understood it after implementing it

---

From: Justin Uberti <[email-masked]>
Date: Wed, 17 Jul 2013 16:51:45 -0400

Thanks for your comments. Responses inline.

On Wed, Jul 17, 2013 at 2:56 PM, Rajmohan Banavi
<[email-masked]>wrote:

> This came up in some earlier rtcweb feedback, but I think it falls within
the definition of REST, as it meets the REST design constraints:
http://en.wikipedia.org/wiki/**Representational_state_**transfer#Constraints<http://en.wikipedia.org/wiki/Representational_state_transfer#Constraints>

>
>    1. Sec 4.3 last paragraph - "Because the password is derived from the
> RFC 5766 doesn't make any guarantees regarding the USERNAME attribute. You
know it hasn't been tampered with on the wire, via MESSAGE-INTEGRITY, but
you don't know that the USERNAME value is in fact something that the *web
server* previously gave out.

The construct defines in this draft ties the password to the USERNAME, so
that the client cannot change the USERNAME value and still have
MESSAGE-INTEGRITY validate properly.

This is also why a TURN password can't be generated randomly - the TURN
server wouldn't know what random value to use when computing its own
MESSAGE-INTEGRITY.

>
>    1. sec 4.1 Client - Does it make it more clear if we reword the last
> Yes, thanks.

>
>    1. Sec 5.1 Revocation - Why is revoking of specific credentials not
> There is no way to revoke credentials through the REST interface, since
there is no communication path between the web server and the TURN server.

>
>    1. Sec 5.2 Key Rotation - I presume here that the shared secret
> The lifetime of vended credentials may be 1 day, but if key rotation is
performed, sometimes a key rotation will occur during the lifetime of a
credential set. As such, the credentials will always need to be validated
against secretkey1 (old) and secretkey2(current) until 1 day after the key
rotation.

---

From: Rajmohan Banavi <[email-masked]>
Date: Thu, 18 Jul 2013 02:39:14 +0530

Thanks for the detailed example. I agree with the entire flow you have
given. My only concern is - why should the ephemeral password be generated
by TURN server using HMAC SHA on then username string? Why can't this be
some random unique string?

Taking your example -

Suppose TURN server generates credentials, username = "12334939:mbzrxpgjys"
and password ="+somerandomstring+". This is a randomly generated string and
passed onto webrtc app. The TURN server also stores these credentials for
later validation.
var iceServer = {
     "username": 12334939:mbzrxpgjys,
     "credential": +somerandomstring+,
   };

These credentials are passed from JS to the webrtc client stack in the
browser.

On Browser WebTRC Client.
key = MD5(12334939:mbzrxpgjys ":" realm ":" +somerandomstring+)
Similarly on the TURN server, the key for MESSAGE-INTEGRITY is calculated
using
key = MD5(12334939:mbzrxpgjys ":" realm ":" +somerandomstring+)

So the browser and turn server use the same input to the M-I. The one
implementation related advantage I see with this way of generation of TURN
password using HMAC is that the TURN server need not really store the HMAC
generated password, but can calculate the same using the USERNAME attribute
in the received TURN request.

In fact, I do not see why the sharedsecret needs to be shared between the
TURN server and the WebRTC application. The sharedsecret key "secret" is
only required by the TURN server for validating the received TURN ALLOCATE
requests once it has generated and sent out the ephemeral credentials. What
does the WebRTC application do with the shared secret key?

Thanks,
Rajmohan

On Thu, Jul 18, 2013 at 2:09 AM, Philipp Hancke
<[email-masked]>wrote:

>> I reviewed draft-uberti-behave-turn-rest-**00 and have the following
>> comments.
>>
> [...]
>
> The password is exposed to the user of the browser (which might be anyone
> surfing your website) during that process.
>
> That stack does long term authentication and uses this password string as
> input for calculating MESSAGE-INTEGRITY with
> key =MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep("+4pCXR06gx/**
> cqAikLYnBajtZW6E=")
>
>
>
>
> key = MD5(username ":" realm ":" SASLprep(BASE64(HMAC-SHA1(**USERNAME,
> sharedsecret))
>
>  = MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep(BASE64(HMAC-SHA1("**12334939:mbzrxpgjys",
> "secret"))
>  = MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep("+4pCXR06gx/**
> cqAikLYnBajtZW6E=")
>
> So the browser and turn server use the same input to the M-I. This can be
> done by looking at the request alone given the shared secret.
>
>

--

---

From: Justin Uberti <[email-masked]>
Date: Wed, 17 Jul 2013 18:11:42 -0400

On Wed, Jul 17, 2013 at 5:09 PM, Rajmohan Banavi
<[email-masked]>wrote:

> Suppose TURN server generates credentials, username =
> "12334939:mbzrxpgjys" and password ="+somerandomstring+". This is a
> randomly generated string and passed onto webrtc app. The TURN server also
> stores these credentials for later validation.
> var iceServer = {

Correct, but that is a significant advantage, especially when the web and
TURN servers are separate entities.

> does the WebRTC application do with the shared secret key?

The WebRTC client application doesn't see the secret key, this is only
shared between the web and TURN servers.

>
> On Thu, Jul 18, 2013 at 2:09 AM, Philipp Hancke <[email-masked]
> > wrote:
>

---

From: Rajmohan Banavi <[email-masked]>
Date: Thu, 18 Jul 2013 17:58:17 +0530

Hi  Justin, comments inline with additional comments at the end.

> TURN servers are separate entities.

IMHO, the standard spec should not be based on any specific implementation
method. Now I agree that the TURN server validation becomes easier using
this method because it does not have to do some sort of lookup. However,
some another TURN server implementer can achieve the same functionality by
providing REST API but using randomly generated pasword (rather than use
HMAC) and using some sort of lookup for TURN username when TURN ALLOCATE
request is received.

Now lets look at the collateral affects of using this proposed
implementation way
- TURN server needs to perform MESSAGE-INTEGRITY validation across two
secrets (worst case due to key rotation) when TURN ALLOCATE request is
received
- TURN username needs to consist of entire state (user identifier + expiry
time). And upon receiving the ALLOCATE request, TURN server must check if
the username is still valid based on expiry time part (of username)
- Time sync needs to be maintained across the web server and the TURN
server.

All of the above are not needed if one does not use the implementation
method specified in the draft but still provide REST API to generate
ephemeral credentials. How these ephemeral credentials are generated and
how the TURN requests are validated is an implementation decision. And it
is not desirable to have standards which caters to each implementation
method.

> shared between the web and TURN servers.

What does the web server do with the secret key? This is not clear from the
text.

Additional comments.

   1. Sec 4.2 Server - "Note that the REALM value supplied by the server is
   not meaningful in this context, and can be set to any valid value". Which
   realm value is being referred here? The REALM attribute value in the 401
   challenge response sent by the TURN server (in response to initial ALLOCATE
   request)?
   2. The implementation method proposed is implicit and not clear from the
   draft text for the reader. The text states that username must be so and so,
   password must be HMAC processed etc, but it is not clear why these need to
   be done. It must be made clear somewhere in the draft that these are being
   proposed to ensure that the TURN server can validate the TURN ALLOCATE
   requests by performing HMAC on the USERNAME attribute received. And that
   the TURN server does not have to maintain/store ephemeral credentials. This
   will help the reader to comprehend the draft in a better way.

Hope it is clear.

Thanks,
Rajmohan Banavi

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 22 Jul 2013 12:53:47 +0000

Hi Justin,

You may also want to consider your using OAuth 2.0 framework. For example consider draft (http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-04#section-6.1) Where WebServer would act as Authorization Server (AS), TURN Server as Resource Server (RS) and Client will be the WebRTC Client.

The advantage of using OAuth is that

[1] If handle token is chosen, AS can revoke the credentials after the call is terminated. This would ensure that even if the temporary credentials are exposed to JavaScript, these credentials can be only used for the duration of the call. This would prevent any attacks possible of someone else using the temporary credentials even after the call is terminated.

[2] AS and RS need to not be co-located.

[3] AS and RS need not use static shared secret; OAuth provides flexibility for the AS to update the RS with session keys.

[4] I believe there are already implementations available of OAuth.

Best Regards,
--Tiru.
From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Tuesday, July 16, 2013 3:23 AM
To: [email-masked]; [email-masked]
Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt

I have changed the WG for this draft from RTCWEB to BEHAVE. Many, but not all of the comments I received on the RTCWEB mailing list have been addressed.

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jul 15, 2013 at 5:49 PM
Subject: New Version Notification for draft-uberti-behave-turn-rest-00.txt
To: Justin Uberti <[email-masked]<mailto:[email-masked]>>

Filename:        draft-uberti-behave-turn-rest
Revision:        00
Title:           A REST API For Access To TURN Services
Creation date:   2013-07-15
Group:           Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-uberti-behave-turn-rest-00.txt
Status:          http://datatracker.ietf.org/doc/draft-uberti-behave-turn-rest
Htmlized:        http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00

Abstract:

The IETF Secretariat

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Jul 2013 15:16:24 -0500

On 7/18/13 07:28, Rajmohan Banavi wrote:
>     Correct, but that is a significant advantage, especially when the
>     web and TURN servers are separate entities.
>
>
> IMHO, the standard spec should not be based on any specific 
> implementation method. Now I agree that the TURN server validation 
> becomes easier using this method because it does not have to do some 
> sort of lookup. However, some another TURN server implementer can 
> achieve the same functionality by providing REST API but using 
> randomly generated pasword (rather than use HMAC) and using some sort 
> of lookup for TURN username when TURN ALLOCATE request is received.

I think the value here -- the value in defining a common scheme for 
password generation -- is that I could get an off-the-shelf TURN server 
from arbitrary vendor A, and run an off-the-shelf credential server from 
abitrary vendor B, and it would all work together. What you propose 
requires collusion between the TURN server provider and the credential 
server provider, using a not-yet-defined (and, if I read your proposal, 
never-publicly-defined) protocol to share credential information via a 
back-channel.

What Justin proposes gets us this inter-vendor interop cheaply and 
easily. What you're counterproposing forces people into a single-vendor 
(or, at least, partnered) solution, which kinda defeats the purpose of 
defining this in an SDO in the first place.

/a

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 22 Jul 2013 22:46:52 +0200

> defining this in an SDO in the first place.

Right. What Justin proposed was originally located at
https://code.google.com/p/webrtc/issues/detail?id=1197
I liked the plan, implemented it in restund and improved it a litle. It 
was discussed at 
https://groups.google.com/forum/#!topic/discuss-webrtc/nn8b6UboqRA/discussion 
and also implemented in rfc-5766-turn-server.

Rough consensus and running code...

---

From: Justin Uberti <[email-masked]>
Date: Tue, 23 Jul 2013 16:45:12 -0400

So there are two parts to the proposal - the HTTP request for the
credentials and interactions with WebRTC, and the stateless implementation
that avoids the need for communication between web and TURN servers. And it
is true that other implementations besides the suggested stateless one are
possible, e.g. OAuth2.

Would you prefer that I address the protocol and implementation parts
separately in the document, and mention that other implementations with the
same HTTP protocol are possible? RFC 5766 does something similar, where it
defines the TURN protocol, but in Section 6.2 talks about how a "stateless
stack" implementation can be used to simplify the processing on the TURN
server.

On Mon, Jul 22, 2013 at 5:37 PM, Oleg Moskalenko <[email-masked]>wrote:

> The overall proposal by Justin:
>
> http://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00
>
> has been implemented in our rfc5766-turn-server for months, and I see
> nothing proprietary in the proposal. I liked the proposal from the
> beginning. Its been discussed and its been quite handy for the users - I
> hear stories of success from the users.  I believe that Philipp shares the
> same view.
>
> One especially good thing about the proposal is that is does not
> contradict by any means to the RFC 5766. It just specifies the way how the
> passwords are stored/generated - and the RFC 5766 does not say anything
> about that matter. It means that Justin's proposal is 100% compatible with
> RFC 5766.
>
> Thanks
> Oleg
> http://code.google.com/p/rfc5766-turn-server/
>
>
>
>
> On Mon, Jul 22, 2013 at 1:46 PM, Philipp Hancke <[email-masked]
> > wrote:
>
>> https://code.google.com/p/**webrtc/issues/detail?id=1197<https://code.google.com/p/webrtc/issues/detail?id=1197>
>> was discussed at https://groups.google.com/**
>> forum/#!topic/discuss-webrtc/**nn8b6UboqRA/discussion<https://groups.google.com/forum/#!topic/discuss-webrtc/nn8b6UboqRA/discussion>and also implemented in rfc-5766-turn-server.
>>
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: Rajmohan Banavi <[email-masked]>
Date: Wed, 24 Jul 2013 12:24:34 +0530

> As you pointed out, the draft essentially has 2 parts - the REST API and
the stateless stack implementation which are completely independent. So
yes, separating them would help because we want other implementations to
also be compliant to the spec. Having said that, I would like opinions and
consensus from others as well.

Just to make my earlier point clearer - The credentials are generated by
TURN server and validated by TURN server. None of the other components in
the chain - web server, web application and the webrtc client, are
concerned with it (sort of like a blob). So the interoperability is not an
issue at all irrespective of what implementation approach you take.

I had some other comments earlier, which are collated below.

   1. What does the web server do with the shared (with TURN server) secret
   key? This is not clear from the text.
   2. Sec 4.2 Server - "Note that the REALM value supplied by the server is
   not meaningful in this context, and can be set to any valid value". Which
   realm value is being referred here? The REALM attribute value in the 401
   challenge response sent by the TURN server (in response to initial ALLOCATE
   request)?
   3. The 2 statements seem to be contradictory: sec 1 "However, as a relay
   service, it imposes a nontrivial cost on the service provider". sec 5.1
   "The assumption is that TURN services are of low enough value that waiting
   for the timeout to expire is a valid approach for dealing with
   possibly-compromised credentials". I am OK with the text, but would prefer
   if this could be reworded in anyway.

---

From: Rajmohan Banavi <[email-masked]>
Date: Wed, 24 Jul 2013 14:16:59 +0530

This is the draft (BEHAVE WG) I am referring to -
http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00

> This is not the case. It is not the TURN server who generates the
> credentials. The web server must generate the temporary password, and to be
> able to do that the web server must have the shared secret - the same as
> TURN server has. How they share the same shared secret I'd leave outside
> the proposed specs.
>
> OK fine.

> It is rather clear - the web server takes the shared secret and it
> generates the temporary password for long-term TURN credentials. The TURN
> server can reproduce that generation process and obtain the same temporary
> password - because the TURN server knows the same shared secret as the web
> server.
>

OK fine.

Thanks,
Rajmohan

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 24 Jul 2013 00:11:21 -0700

Please see my comments in the text:

>    1. What does the web server do with the shared (with TURN server)
>    secret key? This is not clear from the text.
>

>
>    1.
>    2. Sec 4.2 Server - "Note that the REALM value supplied by the server
>    is not meaningful in this context, and can be set to any valid value".
>    Which realm value is being referred here? The REALM attribute value in the
>    401 challenge response sent by the TURN server (in response to initial
>    ALLOCATE request)?
>
>
I do not see those words in the draft text on the Internet:

is there a newer version somewhere ?

>
>    1.
>    2. The 2 statements seem to be contradictory: sec 1 "However, as a
>    relay service, it imposes a nontrivial cost on the service provider". sec
>    5.1 "The assumption is that TURN services are of low enough value that
>    waiting for the timeout to expire is a valid approach for dealing with
I'd really like to have an access to the fresh draft,it seems like it was
not posted publicly - I cannot find it.

Thanks
Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 24 Jul 2013 07:06:27 -0700

Thank you for the new link.

I checked the new version of the draft and I personally see no problem in
the text. There is no proprietary software requirements in the draft. It
simply defines the logic how the TURN server and web server can organize
the temporary password generation, without imposing any proprietary
requirements and specs on the software. It is mentioning a possible
communication channel between web server and TURN server without defining
any specs and as it is written that channel is not required. As it is
written, I do not think that it has to be separated into two pieces - it is
a single solid logical functionality definition.

Thanks
Oleg

---

From: Kaiduan Xie <[email-masked]>
Date: Fri, 26 Jul 2013 09:42:56 -0400

Justin,

I recommend you to put a note into the draft to state the following two
points,

1) The user name and password are generated by the web server instead of
the TURN server.

2) There is no communication channel required between web server and TURN
server.

>From the title (TURN Server REST API) and the text, it is easy to
misunderstand that TURN server processes the HTTP POST request.

Thanks,

/Kaiduan

On Wed, Jul 24, 2013 at 10:06 AM, Oleg Moskalenko <[email-masked]>wrote:

> On Wed, Jul 24, 2013 at 1:46 AM, Rajmohan Banavi <[email-masked]
> > wrote:
>