> -----Original Message----- > From: Brandon Williams [mailto:brandon.willi...@akamai.com] > Sent: Monday, August 25, 2014 8:29 PM > To: Hannes Tschofenig; Tirumaleswar Reddy (tireddy); oauth@ietf.org > Cc: sperrea...@jive.com; draft-ietf-tram-turn-third-party- > au...@tools.ietf.org; gonzalo.camari...@ericsson.com >> Gonzalo > Camarillo; t...@ietf.org > Subject: Re: [tram] Review of draft-ietf-tram-turn-third-party-authz-01 > > The TURN server name value in the THIRD-PARTY-AUTHORIZATION attribute > servers 2 purposes, although only one of them is clearly called out in the > document. The first purpose is to allow the OAuth server to select from > among multiple 3rd party TURN service providers so that the appropriate key > material can be selected when generating the token. The second purpose, > which isn't called out in the document, is to provide a unique identifier for > the specific server within the deployment so that the generated ACCESS- > TOKEN value will only be considered valid by that specific server (i.e. to > prevent replay of the token to multiple TURN servers). So, you can consider > "f...@turn.com" to mean "generate a token for the server named foo at > service provider turn.com".
The second purpose is also discussed in section 6.2 <snip> HMAC is computed using the encrypted portion of the token and TURN server name to ensure that the client does not use the same token to gain illegal access to other TURN servers provided by the same administrative domain. This attack is possible when multiple TURN servers in a single administrative domain share the same symmetric key with the authorization server. </snip> -Tiru > > I think the client would perform the required DNS lookups first to get the > address of a specific server, after which it would attempt to establish the > tunnel in order to get the error with the server name back. Alternatively, > based on the service provider's naming conventions and use of IP addresses, > it might be possible to avoid the initial exchange with the TURN server by > allowing the client to construct the server name without having to ask (at > least that's what I hope to do). > > --Brandon > > On 08/22/2014 04:35 AM, Hannes Tschofenig wrote: > >>> Minor aspects: > >>> >> > >>> >> * Would the TURN server name really be an email alike address > >>> >>rather than a URI ? > >> > > >> >Yes, for more information please refer > >> >tohttp://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-0 > >> >0 > >> > > > Thanks. Why do you need the username part for the discovery of the > > TURN server capabilities? I couldn't find the answer to that question > > by quickly looking at the TURN server discovery document. Do you > > expect that the configuration is different from user to user? > > > > The procedure seems to be: > > > > Client -> TURN server: Establish Tunnel Client <- TURN server: error - > > here is my "email" alike address > > (f...@turn.com) > > Client -> DNS: DNS Lookup (turn.com) > > Client <- DNS: something domain name back Client -> DNS: NAPTR Client > > <- DNS: IP address back > > > > Is this correct? > > > > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
