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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Aug 2014 20:50:42 +0200

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).

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.)

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.

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?

Minor aspects:

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

 * 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?

 * 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?

 * 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)?

 * 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.

Ciao
Hannes

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 24 Aug 2014 06:24:45 +0000

Hi Hannes,

Please see inline

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Friday, August 22, 2014 2:06 PM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> Cc: [email-masked];
> [email-masked] >> Gonzalo Camarillo;
> [email-masked]; [email-masked]
> Subject: Re: Review of draft-ietf-tram-turn-third-party-authz-01
> 
> Hi Tiru,
> 
> ~snip~
> >> * 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.
> 
> 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.

TURN request/response will always be integrity protected independent of whether (D)TLS is used or not and the media traffic relayed through the TURN server is encrypted (e.g. using DTLS-SRTP) for end-to-end security. Is there need to support channel binding ?

> >> Instead of using the JWT access token format the authors have defined
> >> a new, binary encoding to keep the size smaller. The OAuth framework
> > Good point, will update the draft to use AEAD.
> 
> Ok
> 
> >
> >>
> >> Two things surprised me:
> >>
> >> 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 ?
> 
> I missed that. That's fine.
> 
> >
> >>
> >> 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)
> 
> 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). 

Yes

> 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.

Agreed, will update the draft.

> >> than a URI ?
> > 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?

The procedure is as follows:

Client -> DNS: DNS Lookup (turn.com)
Client <- DNS: something domain name back Client -> DNS: NAPTR Client <-
DNS: IP address back
Client -> TURN server: Establish Tunnel
Client <- TURN server: error - here is my "email" alike address
([email-masked])

The unique TURN server name ([email-masked]) is provided by the TURN server in the error response so that client can convey the unique TURN server name to the authorization server. Authorization server uses the TURN server name to identify the appropriate keying material to generate the self-contained token. 

> >> clients would work with random authorization servers ?
> >
> > No, client must authenticate with the authorization server (SIP/WebRTC
> server) to make a call.
> 
> Ok.
> 
> >
> >>
> >> 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>
> 
> Ok. The scope string is 'turn'.

Yes, updated the above line to make it more clear.

NEW:
The value of the scope parameter explained in section 3.3 of [RFC6749] must be 'turn' string.

> 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.
> 
> OK. Is there any plan to provide more than just HMAC-SHA1 ?

Yes, there is future plan to provide STUN hash agility in STUNbis draft (work is yet to start on this draft). Crypto algorithm negotiation could work as follows:
For the hash agility support, TURN client and server will have to negotiate the algorithms supported and agree on the hash function. After this step as explained in draft-ietf-oauth-pop-key-distribution-00, client signals the respective algorithm to authorization server in ‘alg’ parameter and receives the symmetric key whose is length is determined by the authorization server based on the algorithm conveyed by the client. 

Cheers,
-Tiru

> 
> >
> >>
> >>  * 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.
> That's what I thought.
> 
> Ciao
> Hannes
> 
> >
> > Cheers,
> > -Tiru
> >
> >>
> >> Ciao
> >> Hannes
> >>
> >>
> >>
> >