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

From: Justin Uberti <[email-masked]>
Date: Mon, 8 Jul 2013 00:24:48 -0400

Just uploaded a 00 version of a spec for requesting time-limited TURN
credentials for WebRTC apps. Would like to get 10 minutes of agenda time to
present this in Berlin.

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

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

Filename:        draft-uberti-rtcweb-turn-rest
Revision:        00
Title:           A REST API For Access To TURN Services
Creation date:   2013-07-08
Group:           Individual Submission
Number of pages: 7
URL:
http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-turn-rest-00.txt
Status:
http://datatracker.ietf.org/doc/draft-uberti-rtcweb-turn-rest
Htmlized:        http://tools.ietf.org/html/draft-uberti-rtcweb-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: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 8 Jul 2013 05:52:49 +0000

Hi Justin,

A few quick comments:
1) The primary advantage of the proposed mechanism seems not requiring any interaction between the web service and the TURN service in order for the TURN service to grant TURN credentials in the HTTP response -- this absence of interaction isn't evident on a first read. A diagram showing the client, web service, TURN service and the messages exchanged would be helpful.

2)
|If desired, the TURN server can optionally verify that the parsed
|user id value corresponds to a currently valid user of an external
|service (e.g. is currently logged in to the web app that is making
|use of TURN).  This requires proprietary communication between the
|TURN server and external service on each ALLOCATE request, so this
|usage is not recommended for typical applications.  If this external
|verification fails, it SHOULD reject the request with a 401
|(Unauthorized) error.

Was the intention of putting "not recommended" having a normative statement? If not, it would be better to change it to "no needed".

3) There is no text describing how the timestamp encoded in the UNSERNAME attribute of the ALLOCAE requested could be protected.

4) draft-reddy-behave-turn-auth describes the issues with TURN authentication and draft-uberti-rtcweb-turn-rest looks like one possible solution. Looks both could reference each other.

Muthu

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Monday, July 08, 2013 9:55 AM
To: [email-masked]
Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt

Just uploaded a 00 version of a spec for requesting time-limited TURN credentials for WebRTC apps. Would like to get 10 minutes of agenda time to present this in Berlin.

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

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

Abstract:

The IETF Secretariat

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 8 Jul 2013 06:19:43 +0000

|4) draft-reddy-behave-turn-auth describes the issues with TURN
|authentication and draft-uberti-rtcweb-turn-rest looks like one
|possible solution. Looks both could reference each other.

Missed to mention:
And it would be interesting to see what issues described in the former draft are addressed by the later..

Muthu

From: Muthu Arul Mozhi Perumal (mperumal)
Sent: Monday, July 08, 2013 11:23 AM
To: 'Justin Uberti'; [email-masked]
Subject: RE: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt

Hi Justin,

A few quick comments:

2)

Muthu

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Monday, July 08, 2013 9:55 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt

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

Abstract:

The IETF Secretariat

---

From: Simon Perreault <[email-masked]>
Date: Mon, 08 Jul 2013 14:23:39 +0200

Le 2013-07-08 06:24, Justin Uberti a écrit :
> credentials for WebRTC apps. Would like to get 10 minutes of agenda time
> to present this in Berlin.

Cool.

One small comment: shouldn't the response also contain the value of the
REALM parameter?

Thanks,
Simon

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Jul 2013 09:48:02 -0700

Two separate replies...

>> to present this in Berlin.

Justin, is this the right working group for this draft?  Presumably,
you want to talk to whoever owns TURN, which is (I believe) behave.

> One small comment: shouldn't the response also contain the value of the

I assume that this is intended to use the short term credential
mechanism.  No need to use long term credentials in this case.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 8 Jul 2013 14:02:10 -0400

> you want to talk to whoever owns TURN, which is (I believe) behave.

WebRTC applications are the primary beneficiaries of this proposal, which
is why I submitted it here. I can certainly send it to BEHAVE if that's a
better fit. (Depending on how closely this references
draft-reddy-behave-turn-auth, that might be a good indication of where this
should end up.)

> mechanism.  No need to use long term credentials in this case.

RFC 5766 mandates the use of the long-term credential mechanism. One of the
goals of this proposal is to work with existing TURN servers, so it also
uses the long-term credential mechanism, the key point being that the
vended credentials have finite lifetimes.

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

---

From: Justin Uberti <[email-masked]>
Date: Mon, 8 Jul 2013 14:12:21 -0400

On Mon, Jul 8, 2013 at 8:23 AM, Simon Perreault <[email-masked]
> wrote:

> One small comment: shouldn't the response also contain the value of the

It could carry the REALM parameter, but if so, it would only be used to
verify the REALM that was supplied by the server as part of the ALLOCATE
challenge. Did you have something else in mind?

---

From: Justin Uberti <[email-masked]>
Date: Mon, 8 Jul 2013 14:15:55 -0400

On Mon, Jul 8, 2013 at 1:52 AM, Muthu Arul Mozhi Perumal (mperumal) <
[email-masked]> wrote:

>  Hi Justin,****
>
> ** **
>
> A few quick comments:****
>
> 1) The primary advantage of the proposed mechanism seems not requiring any
> interaction between the web service and the TURN service in order for the
> TURN service to grant TURN credentials in the HTTP response -- this absence
> of interaction isn't evident on a first read. A diagram showing the client,
> web service, TURN service and the messages exchanged would be helpful.
>

This is mentioned in the introduction, but agree a diagram would be
helpful.

> ****
>
> ** **
>
> 2) ****
>
> |If desired, the TURN server can optionally verify that the parsed****
>
> |user id value corresponds to a currently valid user of an external****
>
> |service (e.g. is currently logged in to the web app that is making****
>
> |use of TURN).  This requires proprietary communication between the****
>
> |TURN server and external service on each ALLOCATE request, so this****
>
> |usage is not recommended for typical applications.  If this external****
>
> |verification fails, it SHOULD reject the request with a 401****
>
> |(Unauthorized) error.****
>
> ** **
>
> Was the intention of putting "not recommended" having a normative
> statement? If not, it would be better to change it to "no needed".
>

I was waffling on this - I think I will just make it "not needed", and
leave this decision up to the implementor.

> ****
>
> ** **
>
> 3) There is no text describing how the timestamp encoded in the UNSERNAME
> attribute of the ALLOCAE requested could be protected.
>

In the HTTP Interactions section, I mention that the password used for the
MESSAGE-INTEGRITY is a digest of the username, but I can make this more
explicit.

> ****
>
> ** **
>
> 4) draft-reddy-behave-turn-auth describes the issues with TURN
> authentication and draft-uberti-rtcweb-turn-rest looks like one possible
> solution. Looks both could reference each other.
>

Agreed - hadn't seen that draft before since it wasn't in rtcweb.

> ****
>
> ** **
>
> Muthu****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Justin Uberti
> *Sent:* Monday, July 08, 2013 9:55 AM
> *To:* [email-masked]
> *Subject:* [rtcweb] Fwd: New Version Notification for
> draft-uberti-rtcweb-turn-rest-00.txt****
>
> ** **
>
> present this in Berlin.****
>
> ** **
>
> Htmlized:
> http://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00
>
>
> Abstract:
> The IETF Secretariat****
> ** **
> ** **

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Jul 2013 11:16:31 -0700

On 8 July 2013 11:02, Justin Uberti <[email-masked]> wrote:
> uses the long-term credential mechanism, the key point being that the vended
> credentials have finite lifetimes.

You could update 5766 to remove this constraint (I forgot about that
bit)...and the extra round trip required for the challenge.

Or you could provide the client with a realm and nonce in the
response, but that seems like a little too much.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 08 Jul 2013 20:41:22 +0200

> challenge. Did you have something else in mind?

Either that or the text needs to say that the REALM sent by the server 
is to be ignored by the client.

I have no opinion at this point, really, other than the text needs to 
say something about REALM.

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: Justin Uberti <[email-masked]>
Date: Mon, 8 Jul 2013 16:09:20 -0400

> > uses the long-term credential mechanism, the key point being that the
vended
> response, but that seems like a little too much.

The issue with using short term credentials, without a nonce, is the
possibility of replay attacks by an eavesdropper.

Passing realm and nonce solves this but is problematic because nonces need
to be per-allocation, so you'd need some sort of master nonce that could be
used for nonce generation. Plus the Rtciceserver API would need to be
expanded.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Jul 2013 14:43:35 -0700

> possibility of replay attacks by an eavesdropper.

It is no less vulnerable than having the long term credential set
(username, nonce, realm, and password) overheard.  Assuming that the
lifetime of the password is the same in both cases.  In either case,
the link that the eavesdropper is required to attack is the HTTP link.

> Passing realm and nonce solves this [...]

I was suggesting that since you have spent some very expensive
round-trips getting this information, there are no advantages in
spending yet another round-trip on a challenge.  I don't think that
passing realm and nonce is a good idea in practice - it creates a
tighter coupling between this new thing and the TURN server.

In practice, a master nonce is not quite what you need, you need a
nonce-generator function, or a line to the TURN server whereby you
query for every request you get.  The former imposes too-strong
constraints on implementations, the latter renders much of the
advantages of something like this moot.

---

From: Adam Roach <[email-masked]>
Date: Mon, 08 Jul 2013 16:50:59 -0500

On 7/7/13 23:24, Justin Uberti wrote:
> credentials for WebRTC apps. Would like to get 10 minutes of agenda 
> time to present this in Berlin.

Thanks for getting ball rolling on this, Justin. I agree that this is an 
important mechanism to have defined.

I only find one issue in my initial read through the document: why are 
we proposing the use of HTTP POST for stateless, idempotent information 
retrieval? The key benefit of this approach is that it doesn't actually 
create state in the network. That's a much better fit for GET.

Compare RFC 2616, sections 9.3 and 9.5, and see if you don't agree.

/a

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Jul 2013 14:57:09 -0700

On 8 July 2013 14:50, Adam Roach <[email-masked]> wrote:
> I only find one issue in my initial read through the document: why are we
> proposing the use of HTTP POST for stateless, idempotent information

That's an interesting question.  From one perspective, this is not
idempotent, nor is it safe.  It creates a new resource: a new
username/password pair with a defined validity.  You could even
identify this "resource" with a URI.  Imagine what a DELETE on that
resource would do...

But it's equally valid to try to pretend otherwise and use GET.  After
all, most servers won't actually be allocating any state for these
things.  And I can't think of an actual, practical use for DELETE, so
that's just a silly feature.

--Martin

p.s., I was going to let this slide, but this design is not RESTful,
no sense in pretending like it is.

---

From: Adam Roach <[email-masked]>
Date: Mon, 08 Jul 2013 17:05:57 -0500

On 7/8/13 16:57, Martin Thomson wrote:
> username/password pair with a defined validity.

That's like claiming that every time I hit cnn.com, it creates a new 
resource, since the organization of the articles and ads changes as a 
function of time (new articles are added) and local cookies (encoding my 
section preferences). I think both are kind of a tortured interpretation 
of resource creation.

> things.

I hope none of them do. It's kind of the main point of the whole draft.

> no sense in pretending like it is.

I'm not sure I agree with your assessment. Which of these six 
constraints do you believe are violated?

http://en.wikipedia.org/wiki/Representational_state_transfer#Constraints

/a

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Jul 2013 15:30:32 -0700

> I hope none of them do. It's kind of the main point of the whole draft.

I expect all of them to do so, but not hold clients responsible for
that, so GET is still OK.

> I'm not sure I agree with your assessment. Which of these six constraints do
> you believe are violated?
>

Will you think worse of me if I avoid opening this particular can of
worms?  I regret even mentioning it.

I've learned not to use the term RESTful, I should have known better.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 8 Jul 2013 20:51:14 -0400

> the link that the eavesdropper is required to attack is the HTTP link.

I don't think this is true. In the short term case, with no nonce, the
packet can be replayed verbatim.

> advantages of something like this moot.

Right, the master nonce I suggested would be used to generate regular
nonces. But it's not a good idea anyway.

---

From: Matt Fredrickson <[email-masked]>
Date: Tue, 9 Jul 2013 16:59:00 -0500

> MESSAGE-INTEGRITY is a digest of the username, but I can make this more

Muthu,

What situations did you have in mind with regards to timestamp protection
that potentially would be vulnerable (beyond any protection the the digest
gives)?

Matthew Fredrickson

---

From: Justin Uberti <[email-masked]>
Date: Wed, 10 Jul 2013 00:39:46 -0400

> Compare RFC 2616, sections 9.3 and 9.5, and see if you don't agree.

I originally had this as a GET and switched it to a POST for basically the
same reasons that Martin outlined - it wasn't completely stateless, and two
different requests would return different usernames (because of new
timestamps). But if these concerns are overall insignificant, I would be
more than happy to switch back to GET.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 10 Jul 2013 06:40:17 +0000

|What situations did you have in mind with regards to timestamp protection
|that potentially would be vulnerable (beyond any protection the the digest
|gives)?

I think the digest protection should suffice for all practical purposes. On the other hand, is the web and TURN server clocks expected to be in sync? I think the draft should discuss it.

Muthu

From: Matt Fredrickson [mailto:[email-masked]]
Sent: Wednesday, July 10, 2013 3:29 AM
To: Justin Uberti
Cc: Muthu Arul Mozhi Perumal (mperumal); [email-masked]
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-turn-rest-00.txt

On Mon, Jul 8, 2013 at 1:15 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Jul 8, 2013 at 1:52 AM, Muthu Arul Mozhi Perumal (mperumal) <[email-masked]<mailto:[email-masked]>> wrote:
3) There is no text describing how the timestamp encoded in the UNSERNAME attribute of the ALLOCAE requested could be protected.

In the HTTP Interactions section, I mention that the password used for the MESSAGE-INTEGRITY is a digest of the username, but I can make this more explicit.

Muthu,

What situations did you have in mind with regards to timestamp protection that potentially would be vulnerable (beyond any protection the the digest gives)?

Matthew Fredrickson

---

From: Matt Fredrickson <[email-masked]>
Date: Wed, 10 Jul 2013 10:11:47 -0500

On Wed, Jul 10, 2013 at 1:40 AM, Muthu Arul Mozhi Perumal (mperumal) <
[email-masked]> wrote:

> I think the digest protection should suffice for all practical purposes.
> On the other hand, is the web and TURN server clocks expected to be in
> sync? I think the draft should discuss it.
>

I tend to agree as well.  Just from an implementation perspective, it seems
like that a presumed current timestamp on the credentials could be useful
for TTLs on the credentials.  It seems that this also could be a potential
security vulnerability if the time was out of sync between the two servers.

Matthew Fredrickson