Subject: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 23 Apr 2014 14:57:40 +0000

Revised draft-reddy-tram-turn-third-party-authz has been published. Major change is that it’s now using self-contained token and addresses the comments received from the WG. 
Further comments and suggestions are welcome.

Thanks and Regards,
-Authors

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2014 7:40 PM
To: Ram Mohan R (rmohanr); Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati); Justin Uberti; Justin Uberti; Tirumaleswar Reddy (tireddy); Ram Mohan R (rmohanr)
Subject: New Version Notification for draft-reddy-tram-turn-third-party-authz-01.txt

A new version of I-D, draft-reddy-tram-turn-third-party-authz-01.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository.

Name:		draft-reddy-tram-turn-third-party-authz
Revision:	01
Title:		TURN Extension for Third Party Authorization
Document date:	2014-04-23
Group:		Individual Submission
Pages:		14
URL:            http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-third-party-authz-01.txt
Status:         https://datatracker.ietf.org/doc/draft-reddy-tram-turn-third-party-authz/
Htmlized:       http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-reddy-tram-turn-third-party-authz-01

Abstract:
   This document proposes the use of OAuth to obtain and validate
   ephemeral tokens that can be used for TURN authentication.  The usage
   of ephemeral tokens ensure that access to a TURN server can be
   controlled even if the tokens are compromised, as is the case in
   WebRTC where TURN credentials must be specified in Javascript.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Brandon Williams <[email-masked]>
Date: Thu, 24 Apr 2014 10:58:50 -0400

The current revision requires a unique key identifier (kid) per TURN 
server that will be shared between the authorization aerver and the TURN 
server. This has some drawbacks for 3rd party TURN service providers and 
their customers that I have some concerns about, the primary one being 
that the authorization server must maintain a key pair for each 
individual TURN server deployed by the TURN service provider. This adds 
complexity to the problem of deploying new TURN server capacity and 
compounds the problem of key rotation by increasing the number of keys. 
Additionally, it increases allocation establishment time by requiring 
the client to learn the correct kid from the TURN server in order to 
send the kid to the auth server in its token request. The client cannot 
optimize allocation because it is required to have access to the kid 
before contacting that auth server for a token.

An alternative is for the auth server and the TURN service to share a 
single key pair, with any individual TURN server being able to decrypt 
and authenticate the token. This allows the TURN service provider to 
provision new relay capacity without any direct interaction with the 
auth server, and it also means that there is only one pre-shared keypair 
to be managed between the auth server and the TURN service.

One shortcoming of this approach is that a single token could be 
considered valid by multiple TURN servers, and thus used by a 
compromised client to establish multiple allocations when only a single 
one was authorized. This risk is easily mitigated by requiring the 
client to send the relay server's IP address within the token request to 
the auth server (in place of the kid) and for the mac field within the 
encrypted token to include the server's IP address as part of the 
authenticated data. This would make the token's mac valid for just the 
intended receiver without increasing the size of the token.

Another shortcoming of this approach is that compromise of one keypair 
is a global compromise, rather than just compromise of a single TURN 
relay. This risk is easily mitigated through relay-side 
monitoring/rate-limiting and the ability to manually rotate keys.

Are there other shortcomings of this proposed change that I'm not 
thinking of? And do the mitigations that I describe seem reasonable?

Thanks,
--Brandon

On 04/23/2014 10:57 AM, Tirumaleswar Reddy (tireddy) wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Brandon Williams <[email-masked]>
Date: Thu, 24 Apr 2014 11:04:14 -0400

One other comment that I have about the proposal is that I think the mac 
for the token should cover the encrypted token, rather than the 
encryption covering the mac. So, this ...

          struct {
              ushort key_length;
              opaque mac_key[key_length];
              opaque timestamp[8];
              long   lifetime;
              opaque mac[16];
          } token;

would become this ...

          struct {
              opaque {
                  ushort key_length;
                  opaque mac_key[key_length];
                  opaque timestamp[8];
                  long   lifetime;
              } encrypted_block;
              opaque mac[16];
          } token;

This may increase the size of the resulting token, but only by a small 
amount (at most 16 bytes).

--Brandon