Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 4 Sep 2014 10:25:47 +0000

> -----Original Message-----
> From: Brandon Williams [mailto:[email-masked]]
> Sent: Wednesday, September 03, 2014 11:47 PM
> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko
> Cc: [email-masked]
> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03
> 
> On 09/03/2014 01:10 PM, Tirumaleswar Reddy (tireddy) wrote:
> 
> [snip]
> 
> >> In a 3rd party relay server scenario, the owner of the OAuth server
> >> is probably a customer of the owner of relay server, not the client,
> >> so the owner of the OAuth server has a business interest in securing
> >> access to the resources that it is paying for. For this reason, the
> >> owner of the OAuth server will likely desire to impose requirements
> >> on the hash algorithm used. The owner of the OAuth server is also the
> >> one who has to fulfill regulatory requirements if/when they apply.
> >
> > Okay, but the TURN server can always make sure that the client picks an
> acceptable hash algorithm. The TURN server also has a security interest to
> make sure that the client does not pick some inferior algorithm that is
> susceptible to attacks. This way client can only signal the hash algorithm
> finalized with the TURN server to the Authorization server.
> >
> > If you could explain attacks possible with this approach then it will help the
> discussion.
> >
> 
> At a high level, what I have to do is tell my customers the list of supported
> algorithms and let them decide which ones make the most sense for them. It
> certainly is possible for the customer to tell me which algorithm they want to
> use ahead of time, in which case the TURN server can make the decision on
> their behalf. However, this is not ideal, because it requires the customer to
> interact directly with both my system (to make their selection) and their own
> system (to validate the selection). It is simpler for the customer if they only
> have to interact with their own system if they want to change security
> requirements.

Authorization server cannot implicitly make assumption that the algorithm it wants is supported by both client and TURN server. 

> It is important for the TURN server to only have one algorithm that it could
> possibly select for the customer and for the customer to verify that this is the
> algorithm selected. If not, the system is susceptible to an algorithm
> downgrade by the client, since there is nothing that requires the client to
> signal the same algorithm to the OAuth server that it received from the TURN
> server. This is the attack vector that I would be concerned about.

If the client and TURN server had negotiated let's say algorithm X but client signals inferior algorithm Y and let's say Authorization server provides the key. But the client cannot force the TURN server to downgrade to use algorithm Y. I still don't see a possible attack.

The other way of solving the problem could be:

1)Authorization server and TURN server as part of long term key establishment finalize the list of hash algorithms.
2)If the client sends an hash algorithm to the authorization server which is not finalized in step 1 then authorization server responds with an error to the client to select among the list of hash algorithms that authorization server and TURN server had previously agreed.
 
-Tiru

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

---

From: Brandon Williams <[email-masked]>
Date: Thu, 04 Sep 2014 09:08:27 -0400

> Authorization server cannot implicitly make assumption that the algorithm it wants is supported by both client and TURN server.

Correct, and that works both ways. Neither side can pick a single 
algorithm to be used without knowing the set of algorithms the other 
side supports. My argument is that it is better for the relay service 
provider to allow the auth server provider to control the selection. 
That's certainly the model that our customers will want.

> If the client and TURN server had negotiated let's say algorithm X but client signals inferior algorithm Y and let's say Authorization server provides the key. But the client cannot force the TURN…

You're right that the client is in a position to force the session to 
use the lowest security algorithm supported by the union of those 
supported by both the relay server and the oauth server. I guess there's 
really no way to prevent that without ensuring that there is only one 
algorithm that could possibly be selected by both the relay server and 
the auth server.

If there's no attack vector that can be avoided, then it's just about 
which method will provide better algorithm selection semantics.

> 1)Authorization server and TURN server as part of long term key establishment finalize the list of hash algorithms.

This is what I meant by "tell my customers the list of supported 
algorithms".

> 2)If the client sends an hash algorithm to the authorization server which is not finalized in step 1 then authorization server responds with an error to the client to select among the list of hash…

This is fine, but suboptimal. The client doesn't have to probe to figure 
out which algorithm will be considered OK. The negotiation can be 
completed in a single step without the need for an error return if the 
clients sends its list of supported algorithms and the auth server sends 
a key for the algorithm that it picked. This will most likely be what is 
required for algorithm selection between the client and the relay server 
outside of the 3rd party context, too.

Here are the ideas running through my head at the moment. The algorithm 
to use for standard STUN authentication could be selected in one of the 
two following ways (assuming that the client can't be pre-configured to 
know the algorithm in advance).

Standard STUN Auth option 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~
* client sends algorithm list in initial allocation request
* relay server selects an algorithm and send that in the allocation 
error response
* client sends allocation request with message integrity using selected 
algorithm

Standard STUN Auth option 2
~~~~~~~~~~~~~~~~~~~~~~~~~~~
* client sends initial allocation request as per existing spec
* relay server sends a list of supported algorithms in the allocation 
error response
* client selects an algorithm from the list and uses it to generate 
message integrity for the new allocation request

I like option 2 better because I think it works better with 3rd party 
auth by allowing for indirect in-band negotiation between the relay and 
auth servers as well as out-of-band negotiation, while at the same time 
not requiring the client to be pre-configured in either case.

3rd Party Auth with initial relay server exchange
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* no out-of-band algorithm exchange required between relay server and 
oauth server
* client sends initial allocation request as per existing spec
* relay server sends a list of supported algorithms in the allocation 
error response
* client sends token request to oauth with the union set of algorithms 
supported by the client and the turn server
* oauth server selects an algorithm from the list and sends an 
appropriate key in the token
* client sends allocation request with message integrity using selected 
algorithm

3rd Party Auth without initial relay server exchange
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* relay server provides oauth server with list of supported algorithms 
via out-of-band mechanism
* client sends token request to oauth with the list of algorithms 
supported by the client
* oauth server selects an algorithm from the set of algorithms supported 
by both the client and the relay server, and it sends an appropriate key 
in the token
* client sends allocation request with message integrity using selected 
algorithm

What are your thoughts on the above?

--Brandon

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