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

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Sep 2014 12:00:56 -0400

On 08/28/2014 04:53 AM, Tirumaleswar Reddy (tireddy) wrote:
>> -----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 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.

--Brandon

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

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 3 Sep 2014 17:10:11 +0000

> Sent: Wednesday, September 03, 2014 9:31 PM
> >> 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 ?
> >
> 
> 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.

-Tiru

> 
> --Brandon
> 
> >>
> >> 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 ?
> >> 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
> >>
> >>>> 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?
> >>>
> >> 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
> >>>>
> >>>>>> 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 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
> >>>>>>
> >>>>>>>> purpose. That should probably be part of the stun-bis effort,
> >>>>>>>> or at happen concurrently so that stun-bis can reference the
> >>>>>>>> relevant
> >>>> document.
> >>>>>>>> publishing a draft that requires an immediate update in order
> >>>>>>>> to satisfy a
> >>>>>>>> not-yet-
> >>>>>>>> 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.
> >>>>>>>
> >>>>>>>>> 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
> >>>>>>>>> "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"

---

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Sep 2014 14:17:17 -0400

On 09/03/2014 01:10 PM, Tirumaleswar Reddy (tireddy) wrote:

[snip]

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

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.

--Brandon