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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 5 Sep 2014 11:21:50 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Thursday, September 04, 2014 6:38 PM
> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko
> Cc: [email-masked]
> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03
> 
> On 09/04/2014 06:25 AM, Tirumaleswar Reddy (tireddy) wrote:
> >> -----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.
> >
> 
> 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.
> 
> >> 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.
> >
> 
> 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.
> 
> > 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.
> 
> This is what I meant by "tell my customers the list of supported algorithms".

Okay.

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

Yes, option 2 is more suitable.

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

I think you mean intersection.
 
> * 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

This approach looks good.

-Tiru

> 
> 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.
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Fri, 05 Sep 2014 09:27:06 -0400

On 09/05/2014 07:21 AM, Tirumaleswar Reddy (tireddy) wrote:

[snip]

> I think you mean intersection.

Oops, yes, I was thinks intersection throughout the earlier e-mail and 
writing union. Guess I should have waited until after that second cup of 
coffee.

> This approach looks good.

OK. So, if we go with this model, then in the 3rd party draft, the the 
OAuth request would specify a list of supported algorithms, and the 
OAuth response would specify the selected algorithm. For now, the only 
valid value in each direction would be "hmac-sha1" or something similar. 
In the future, after hash agility and the list of must/should algorithms 
have been specified, other algorithm specifiers can be added.

Does that sound reasonable?

--Brandon

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