Subject: Re: [OAUTH-WG] Review of draft-ietf-tram-turn-third-party-authz-01

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 22 Aug 2014 04:30:02 +0000

Hi Hannes,

Thanks for the review. Please see inline

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Friday, August 22, 2014 12:21 AM
> To: [email-masked]
> Cc: [email-masked];
> [email-masked] >> Gonzalo Camarillo;
> [email-masked]
> Subject: Review of draft-ietf-tram-turn-third-party-authz-01
> 
> Hi all,
> 
> Simon asked us (Derek and myself) to do a quick review of this document
> developed within another working group that happens to use OAuth.
> 
> * Background
> 
> TURN is a special tunnelling gateway (very much like an IPsec gateway would
> be) but designed specifically to relay voice/video traffic. To prevent attacks a
> TURN client (such as a VoIP phone) uses a shared secret (username &
> password) with the TURN server (=gateway).
> 
> So, if Alice calls Bob and uses a TURN server then her VoIP client uses SIP or
> WebRTC (as a signaling protocol) to establish the necessary communication
> so that voice packets can be exchanged between the two VoIP clients with
> the help of the TURN server.
> 
> The main idea of this document is to re-use OAuth to authorize the use of
> this TURN server.
> 
> * The Design
> 
> I would have used OAuth as is (or maybe selected a specific grant type) to
> obtain an access token. Then, I would have defined how the access token is
> carried in the TURN protocol. This is a bit similar what we have already done
> with the OAuth SASL draft where we defined a new way to convey the access
> token from the SASL client to the SASL server.
> 
> How did the authors solve that problem? They pretty much did what I just
> explained. Since TURN does not use DTLS (or TLS) the proof-of-possession
> security work we are doing becomes relevant (namely the symmetric key-
> based part).

Yes, the communication b/w TURN client and server may or may not use (D)TLS, hence 
proof-of-possession security work is used.

> 
> Putting discovery information in-band into the exchange is also find (which is
> what we did in the SASL document).
> 
> Instead of using the JWT access token format the authors have defined a
> new, binary encoding to keep the size smaller. The OAuth framework allows
> other token formats to be used - so that's fine as well.
> (As a minor remark, I would use AEAD ciphers here since that's what
> everyone is doing noways.)

Good point, will update the draft to use AEAD.

> 
> Two things surprised me:
> 
> a) The spec leaves the way to obtain the access token pretty much open.
> A big benefit from using OAuth is that there is a protocol mechanism defined
> for getting the access token. You could, for example, recommend using
> authorization code flow. This concerns the text written in Section 4.

Using authorization code flow is discussed in Section 4 of the draft.

<snip>
   OAuth in [RFC6749] defines four grant types.  This specification uses
   the OAuth grant type "Implicit" explained in section 1.3.2 of
   [RFC6749] where the WebRTC client is issued an access token directly.
</snip>

Are you suggesting that we add more details ?

> 
> b) You describe a key establishment scheme to be used between the
> resource server and the authorization server. What assumption do you make
> about the relationship between the authorization server and the resource
> server? Are they supposed to have a business relationship or some other
> relationship with each other ?

Authorization and Resource servers could have a business relationship (loosely coupled, for example Enterprise network using TURN server provided by third party provider like Akamai) or could be deployed in the same administrative domain (tightly coupled, for example Google providing both WebRTC and TURN servers)

> 
> Minor aspects:
> 
>  * Would the TURN server name really be an email alike address rather than
> a URI ?

Yes, for more information please refer to http://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00

> 
>  * Would you use Dynamic Client Registration to provision the client with the
> necessary parameter? Is there the expectation that random clients would
> work with random authorization servers ?

No, client must authenticate with the authorization server (SIP/WebRTC server) to make a call.

> 
>  * Wouldn't you want to define a scope value for use with the TURN service
> so that the authorization server is able to restrict the access token for use
> with TURN only?

The scope value for use with the TURN service is defined in section 4

<snip>
   The scope of the access token explained in section 3.3 of [RFC6749]
   MUST be TURN.
</snip>

> 
>  * Crypto algorithm negotiation: would you expect the authorization server to
> tell the client what crypto algorithms to use (since the authorization server
> not only needs to share a key with the resource server but also needs to have
> knowledge about the supported cryptographic algorithms) ?

Currently STUN only uses HMAC-SHA1, hence details about authorization server telling the client about the crypto algorithm to use is not explicitly mentioned in the draft.

> 
>  * In your TURN <-> OAuth terminology mapping you say that the resource
> owner corresponds to the RTCWeb server. I don't think that's true. The
> resource owner is the user but I believe you are trying to say that the user
> grants authorization implicitly by making a WebRTC call.

The resource owner is the WebRTC server. When client makes a call using the WebRTC server, it authorizes the client to use the resources on the TURN server for a specific period of time. The user is granted authorization implicitly by making a WebRTC call.

Cheers,
-Tiru

> Ciao
> Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Aug 2014 10:35:30 +0200

Hi Tiru,

~snip~
> proof-of-possession security work is used.

I know saw in one of the references that there is a proposal for DTLS.
In that case you might already want to consider re-using the channel
binding work as well.

> Good point, will update the draft to use AEAD.

Ok

> Are you suggesting that we add more details ?

I missed that. That's fine.

> Authorization and Resource servers could have a business relationship (loosely coupled, for example Enterprise network using TURN server provided by third party provider like Akamai) or could be de…

I guess you assume that there is some long-term secret (such as
asymmetric credential) in place and you then derive the symmetric keys
from it (by using DSKPP). Maybe you want to say that (in addition to the
assumed relationship between the two entities). If there is no
relationship between the two parties then they will certainly be a
challenge to get this done securely.

> Yes, for more information please refer to http://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00

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
([email-masked])
Client -> DNS: DNS Lookup (turn.com)
Client <- DNS: something domain name back
Client -> DNS: NAPTR
Client <- DNS: IP address back

Is this correct?

> No, client must authenticate with the authorization server (SIP/WebRTC server) to make a call.

Ok.

>    The scope of the access token explained in section 3.3 of [RFC6749]

Ok. The scope string is 'turn'.

> Currently STUN only uses HMAC-SHA1, hence details about authorization server telling the client about the crypto algorithm to use is not explicitly mentioned in the draft.

OK. Is there any plan to provide more than just HMAC-SHA1?

> The resource owner is the WebRTC server. When client makes a call using the WebRTC server, it authorizes the client to use the resources on the TURN server for a specific period of time. The user i…
That's what I thought.

Ciao
Hannes

---

From: Eve Maler <[email-masked]>
Date: Sun, 24 Aug 2014 15:16:53 -0700

In case the UMA model of establishing and conducting loosely coupled AS-RS relationships is of interest, you can find more information here:

http://tools.ietf.org/html/draft-hardjono-oauth-umacore-10 (for the AS's protection API, the OAuth token securing that API, and the declaration of AS config data including endpoints)
http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-03 (for the resource set registration sub-API)

	Eve

On 22 Aug 2014, at 1:35 AM, Hannes Tschofenig <[email-masked]> wrote:

>> ...
>>> ...

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 25 Aug 2014 17:03:12 +0000

> From: Brandon Williams [mailto:[email-masked]]
> Sent: Monday, August 25, 2014 8:29 PM
> To: Hannes Tschofenig; Tirumaleswar Reddy (tireddy); [email-masked]
> Cc: [email-masked]; draft-ietf-tram-turn-third-party-
> [email-masked]; [email-masked] >> Gonzalo
> Camarillo; [email-masked]
> 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
> "[email-masked]" 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?
> >
> > Client -> TURN server: Establish Tunnel Client <- TURN server: error -
> > here is my "email" alike address
> > ([email-masked])
> > 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.

---

From: Brandon Williams <[email-masked]>
Date: Mon, 25 Aug 2014 10:58:32 -0400

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 "[email-masked]" to mean "generate a token 
for the server named foo at service provider turn.com".

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:
>> >Yes, for more information please refer tohttp://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00
>> >

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