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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 28 Aug 2014 08:53:41 +0000

> -----Original Message-----
> From: Brandon Williams [mailto:[email-masked]]
> Sent: Wednesday, August 27, 2014 12:00 AM
> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko
> Cc: [email-masked]
> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03
> 
> I don't think that it's reasonable for the client to select a single auth algorithm
> from a list of those supported by the relay server, because there is a risk that
> it will select one that doesn't meet the policy requirements being enforced by
> the oauth server.

Why should the policy requirements enforced by the authorization server care about the algorithm used by the client and TURN server to integrity protect messages ?

> 
> In addition, I think the oauth administrator has to know the algorithms
> supported by the relay server in order to configure a reasonable policy.

As part of communication between authorization server and resource server to establish a long-term symmetric key, resource server can inform the algorithms it supports.
But what I don't understand is why should authorization server know the algorithms supported by the resource or relay server ?
Do you see some attack or security hole because of which you are suggesting this approach ?

> I don't think the policy configuration requirement can be met with in-band
> communication of the supported algorithms.
> 
> I agree that the client and the oauth server have to agree on the algorithm in
> order for the oauth server to send an appropriately sized key. 

Okay.

> I'm suggesting
> that the algorithm should be selected by the oauth server from among the
> union of the set supported by the client and the algorithm supported by the
> relay server. I'm also suggesting that the client should not be allowed to
> declare what the union set is, which is a shortcoming of delivering the
> information in-band.
> 
> All of the above having been said, I think that we may be getting ahead of the
> discussion. Is there general agreement that we need to come up with a new
> hash agility approach for STUN? 

I think STUNbis will provide hash agility support. http://www.ietf.org/mail-archive/web/tram/current/msg00000.html charter proposal mentions supporting hash agility.

> And if so, has someone actually taken that
> on? What we come up with on hash agility for 3rd party auth may depend
> upon how hash agility is resolved for STUN in general.

-Tiru

> 
> --Brandon
> 
> On 08/26/2014 02:19 AM, Tirumaleswar Reddy (tireddy) wrote:
> >> -----Original Message-----
> >> From: Brandon Williams [mailto:[email-masked]]
> >> Sent: Monday, August 25, 2014 11:20 PM
> >> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko
> >> Cc: [email-masked]
> >> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03
> >>
> >> Why should it be necessary for the TURN server to send a list? Can't
> >> the list of supported auth algorithms be agreed upon between the
> >> relay and oauth servers out-of-band like the other security
> >> parameters? And how is this better than a more typical model wherein
> >> the client advertises its capabilities and the server enforces its policy?
> >
> > Both models will work and even in the above case client will have to signal
> the algorithm to the authorization server so as to get key with correct length.
> In the below proposal, there is no need for list of supported authentication
> algorithms to be agreed upon between the RS and AS servers.
> >
> > -Tiru
> >
> >>
> >> --Brandon
> >>
> >> On 08/25/2014 01:27 PM, Tirumaleswar Reddy (tireddy) wrote:
> >>>> -----Original Message-----
> >>>> From: Brandon Williams [mailto:[email-masked]]
> >>>> Sent: Monday, August 25, 2014 10:40 PM
> >>>> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko
> >>>> Cc: [email-masked]
> >>>> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03
> >>>>
> >>>> I don't think that the client will be (or can safely be allow to
> >>>> be) responsible for selecting the algorithm. Somehow, this decision
> >>>> must be up to the OAuth server. The most that I think the client
> >>>> can do is send a list of what it supports, which will allow the
> >>>> server to select the best of the bunch (or reject if none are good
> enough).
> >>>
> >>> I am thinking other way around. TURN server sends lists of HMAC
> >> algorithms it supports, client picks the algorithm it would like to
> >> use and conveys it to the authorization server. OAuth has already defined
> 'alg'
> >> parameter for the client to signal the algorithm to the authorization
> server.
> >>>
> >>> -Tiru
> >>>
> >>>>
> >>>> I haven't read the referenced draft or your proposed changes so it
> >>>> may be that you've already dealt with this part of the problem.
> >>>>
> >>>> --Brandon
> >>>>
> >>>> On 08/25/2014 12:50 PM, Tirumaleswar Reddy (tireddy) wrote:
> >>>>>> -----Original Message-----
> >>>>>> From: Brandon Williams [mailto:[email-masked]]
> >>>>>> Sent: Monday, August 25, 2014 8:06 PM
> >>>>>> To: Oleg Moskalenko; Tirumaleswar Reddy (tireddy)
> >>>>>> Cc: [email-masked]
> >>>>>> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03
> >>>>>>
> >>>>>> I agree that the 5389 hash agility plan seems problematic and
> >>>>>> should be replaced with something more suitable to the stated
> >>>>>> purpose. That should probably be part of the stun-bis effort, or
> >>>>>> at happen concurrently so that stun-bis can reference the
> >>>>>> relevant
> >> document.
> >>>>>> Completion of this effort might be a requirement for publishing
> >>>>>> the 3rd party auth draft, because we don't want to end up
> >>>>>> publishing a draft that requires an immediate update in order to
> >>>>>> satisfy a
> >>>>>> not-yet-
> >>>> written hash agility requirement.
> >>>>>>
> >>>>>> The area that I think is most likely to be challenging with the
> >>>>>> current 3rd party auth draft is algorithm identification. It will
> >>>>>> be necessary at some point in the future for the TURN server to
> >>>>>> select from among multiple supported auth algorithms, but there
> >>>>>> is no obvious way at the moment for the auth algorithm to be
> >>>>>> communicated from the auth server to either the client or the
> >>>>>> TURN server. The only value that could currently be used to guess
> >>>>>> the auth algorithm is the key_length in the token, but using
> >>>>>> key_length as an algorithm identifier seems risky, even if it
> >>>>>> would work with the most likely
> >>>> candidates today.
> >>>>>
> >>>>> I have updated the draft to address the problem in the following way:
> >>>>> When STUN supports HMAC algorithms other than HMAC-SHA-1 then
> >> client
> >>>>> will convey the algorithm negotiated with the TURN server to  the
> >>>> authorization server in the value of 'alg' parameter defined in
> >>>> [I-D.ietf-oauth- pop-key-distribution].  Authorization server
> >>>> determines length of the mac_key based on the HMAC algorithm
> >> conveyed by the client.
> >>>>>
> >>>>> -Tiru
> >>>>>
> >>>>>>
> >>>>>> --Brandon
> >>>>>>
> >>>>>> On 08/23/2014 02:47 AM, Oleg Moskalenko wrote:
> >>>>>>> Another problem is that I am not sure that the hash agility plan
> >>>>>>> idea described in RFC5389 is still valid. I am afraid that it is
> >>>>>>> unnecessary complicated and outdated, taking into account the
> >>>>>>> current level of
> >>>>>>> SHA-256 adoption. The plan was designed to support,
> >>>>>>> "transparently", the old TURN servers. But in these specs, we do
> >>>>>>> not necessary have to support the "old" servers with HMAC-SHA-1
> >>>>>>> only implementations; as we are writing a new oAuth procedure,
> >>>>>>> there
> >> will be only "new"
> >>>>>>> servers supporting the draft specs, anyway. The "old" servers
> >>>>>>> will not be able to use the oAuth specs. SO we can design a
> >>>>>>> cleaner simpler hash agility procedure.
> >>>>>>
> >>>>>> --
> >>>>>> Brandon Williams; Senior Principal Software Engineer Emerging
> >>>>>> Products Engineering; Akamai Technologies Inc.
> >>>>
> >>>> --
> >>>> Brandon Williams; Senior Principal Software Engineer Emerging
> >>>> Products Engineering; Akamai Technologies Inc.
> >>
> >> --
> >> Brandon Williams; Senior Principal Software Engineer Emerging
> >> Products Engineering; Akamai Technologies Inc.
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.