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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 26 Aug 2014 06:19:29 +0000

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

---

From: Brandon Williams <[email-masked]>
Date: Tue, 26 Aug 2014 14:30:09 -0400

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.

In addition, I think the oauth administrator has to know the algorithms 
supported by the relay server in order to configure a reasonable policy. 
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. 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? 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.

--Brandon

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