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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 25 Apr 2014 14:14:02 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Thursday, April 24, 2014 8:29 PM
> To: [email-masked]
> Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-
> third-party-authz-01.txt
> 
> 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.

No, the client need not have to learn the kid from the TURN server nor needs to send it to the authorization server. Since the kid is unique per TURN server, the client needs to only convey the TURN server IP address to the authorization server when requesting the token. The authorization server identifies the keying material using the TURN server IP address and returns the self-contained token, mac_key, kid, expires_in etc.  Client has to pass the kid and self-contained token to the TURN server for authorization. I don't see any increase in the allocation establishment time because of using kid.

-Tiru

> 
> 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:
> > 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
> >
> > _______________________________________________
> > tram mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tram
> >
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Fri, 25 Apr 2014 14:05:34 -0400

I was referring to the POST body in Section 3 of the current draft. Do 
you intend to change that section of the draft? Or did you intend that 
to be an example of what the token request might look like?

--Brandon

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 26 Apr 2014 06:15:04 +0000

> From: Brandon Williams [mailto:[email-masked]]
> Sent: Friday, April 25, 2014 11:34 PM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> I was referring to the POST body in Section 3 of the current draft. Do you intend
> to change that section of the draft? 

> Or did you intend that to be an example of what the token request might look like?

Yes, it's example of what token request might look like. But will update the example and remove kid from POST body.   Good catch.

Cheers,
-Tiru

> >> Subject: Re: [tram] FW: New Version Notification for
> >> draft-reddy-tram-turn- third-party-authz-01.txt
> >>
> >> 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
> >> 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.
> >
> > No, the client need not have to learn the kid from the TURN server nor needs
> to send it to the authorization server. Since the kid is unique per TURN server,
> the client needs to only convey the TURN server IP address to the authorization
> server when requesting the token. The authorization server identifies the keying
> material using the TURN server IP address and returns the self-contained token,
> mac_key, kid, expires_in etc.  Client has to pass the kid and self-contained token
> to the TURN server for authorization. I don't see any increase in the allocation
> establishment time because of using kid.
> >
> > -Tiru
> >
> >>
> >> 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.
> >>
> >> change is that it’s now using self-contained token and addresses the
> >> comments received from the WG.
> >> Brandon Williams; Senior Principal Software Engineer Emerging
> >> Products Engineering; Akamai Technologies Inc.
> >>