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

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 21 Aug 2014 23:56:47 -0700

I have the following comment:

In the section 4.1.1 and 4.1.2, the encryption algorithm AES_256_CBC has to
be used, because the HKDF-Expand function of length 16 does not make much
sense, according to RFC 5869 section 2.3.

So, I suggest to use AES_256_CBC consistently across the draft text as
the default
encryption algorithm. In the section 4.1.3 it is already used as the
default algorithm,
anyway.

Thanks
Oleg

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 22 Aug 2014 07:48:32 +0000

From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Friday, August 22, 2014 12:27 PM
To: [email-masked]
Subject: [tram] draft-ietf-tram-turn-third-party-authz-03

I have the following comment:
In the section 4.1.1 and 4.1.2, the encryption algorithm AES_256_CBC has to be used, because the HKDF-Expand function of length 16 does not make much sense, according to RFC 5869 section 2.3.

So, I suggest to use AES_256_CBC consistently across the draft text as the default
encryption algorithm. In the section 4.1.3 it is already used as the default algorithm,

anyway.

[TR] Thanks, will that in the next revision.

-Tiru

Thanks
Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 22 Aug 2014 08:34:45 -0700

Sorry, scratch that - I take back my comment.

Thanks
Oleg

On Fri, Aug 22, 2014 at 12:48 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>    *From:* tram [mailto:[email-masked]] *On Behalf Of *Oleg
> Moskalenko
> *Sent:* Friday, August 22, 2014 12:27 PM
> *To:* [email-masked]
> *Subject:* [tram] draft-ietf-tram-turn-third-party-authz-03
>
>
>
> In the section 4.1.1 and 4.1.2, the encryption algorithm AES_256_CBC has
> to be used, because the HKDF-Expand function of length 16 does not make
> much sense, according to RFC 5869 section 2.3.
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 22 Aug 2014 09:11:17 -0700

But I still think that making a single algorithm (like AES_256_CBC) default
across all use cases is a good idea, I just used wrong explanation for that.

Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 22 Aug 2014 23:47:22 -0700

Tiru, I found an error in the 6.2 section (ACCESS_TOKEN). It is mentioning
the HMAC-SHA-1 algorithm with 160 bits key. This is actually incorrect:
HMAC-SHA-1 has 160 bits output result, but it uses 128 bits input key,
normally.

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.

So the text has to be fixed:

OLD TEXT:
----------------

 key_length:  Length of the session key.  Key length of 160-bits MUST
      be supported (i.e only 160-bit key is used by HMAC-SHA-1 for
      message integrity of STUN message).  The key length facilitates
      the hash agility plan discussed in section 16.3 of [RFC5389]
<http://tools.ietf.org/html/rfc5389#section-16.3>.

NEW TEXT:
------------------

 key_length:  Length of the session key.  Key length of 128-bits MUST
      be supported (128-bit key is used by HMAC-SHA-1 for
      message integrity of STUN message).  Key length of 256-bits SHOULD
      be supported (256-bit key is used by HMAC-SHA-256). Other key lengths
      MAY be supported. The key length facilitates the hash agility:
      the SHA digest algorithm is chosen depending on the key length.

Thanks
Oleg

On Fri, Aug 22, 2014 at 9:11 AM, Oleg Moskalenko <[email-masked]>
wrote:

> But I still think that making a single algorithm (like AES_256_CBC)
> default across all use cases is a good idea, I just used wrong explanation
> for that.
>
> Oleg
>
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Sat, 23 Aug 2014 00:37:35 -0700

Actually, although, normally, 128-bits keys are used with HMAC-SHA-1, other
key lengths are possible with that function. I admit that my suggestion may
not be entirely accurate.

Oleg

On Fri, Aug 22, 2014 at 11:47 PM, Oleg Moskalenko <[email-masked]>
wrote:

>       the hash agility plan discussed in section 16.3 of [RFC5389] <http://tools.ietf.org/html/rfc5389#section-16.3>.
>
>
> NEW TEXT:
> ------------------
>
>>>> In the section 4.1.1 and 4.1.2, the encryption algorithm AES_256_CBC
>>>> has to be used, because the HKDF-Expand function of length 16 does not make

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 23 Aug 2014 14:41:40 +0000

No problem,  updated the draft to use single algorithm.

Thanks,
-Tiru

From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Friday, August 22, 2014 9:41 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03

But I still think that making a single algorithm (like AES_256_CBC) default across all use cases is a good idea, I just used wrong explanation for that.

Oleg

On Fri, Aug 22, 2014 at 8:34 AM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:
Sorry, scratch that - I take back my comment.

Thanks
Oleg

On Fri, Aug 22, 2014 at 12:48 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Oleg Moskalenko
Sent: Friday, August 22, 2014 12:27 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [tram] draft-ietf-tram-turn-third-party-authz-03

anyway.

-Tiru

Thanks
Oleg

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 23 Aug 2014 15:18:17 +0000

Yes, http://tools.ietf.org/html/rfc4868#section-2.1.1 discusses the key length and output length;
<snip>
key lengths less than the output length
decrease security strength, and keys longer than the output length do
not significantly increase security strength
</snip>

Let me know if you still think the below text needs to be fixed.

For the hash agility support, TURN client and server will have to negotiate the algorithms supported and agree on the hash function (I am assuming STUNbis draft will cover this part). After this step as explained in draft-ietf-oauth-pop-key-distribution-00, client signals the respective algorithm to authorization server in ‘alg’ parameter and receives the symmetric key whose is length is determined by the authorization server based on the algorithm conveyed by the client.

We can add a note to explain this part using non-normative text and update it once STUNbis adds support for hash agility.

-Tiru

From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Saturday, August 23, 2014 1:08 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03

Actually, although, normally, 128-bits keys are used with HMAC-SHA-1, other key lengths are possible with that function. I admit that my suggestion may not be entirely accurate.
Oleg

On Fri, Aug 22, 2014 at 11:47 PM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:
Tiru, I found an error in the 6.2 section (ACCESS_TOKEN). It is mentioning the HMAC-SHA-1 algorithm with 160 bits key. This is actually incorrect: HMAC-SHA-1 has 160 bits output result, but it uses 128 bits input key, normally.

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.

      the hash agility plan discussed in section 16.3 of [RFC5389]<http://tools.ietf.org/html/rfc5389#section-16.3>.

NEW TEXT:

------------------

Thanks

Oleg

On Fri, Aug 22, 2014 at 9:11 AM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:
But I still think that making a single algorithm (like AES_256_CBC) default across all use cases is a good idea, I just used wrong explanation for that.

Oleg

Thanks
Oleg

anyway.

-Tiru

Thanks
Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Sat, 23 Aug 2014 10:18:02 -0700

That's fine, thanks.

Oleg

> On Aug 23, 2014, at 8:18 AM, "Tirumaleswar Reddy (tireddy)" <[email-masked]> wrote:
> 
> On Fri, Aug 22, 2014 at 11:47 PM, Oleg Moskalenko <[email-masked]> wrote:
>       the hash agility plan discussed in section 16.3 of [RFC5389].
> 
> NEW TEXT:
> 
>  
> ------------------
> 
> On Fri, Aug 22, 2014 at 9:11 AM, Oleg Moskalenko <[email-masked]> wrote:
> On Fri, Aug 22, 2014 at 8:34 AM, Oleg Moskalenko <[email-masked]> wrote:
> On Fri, Aug 22, 2014 at 12:48 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:

---

From: Brandon Williams <[email-masked]>
Date: Mon, 25 Aug 2014 10:10:50 -0400

rfc2104 states that the key may be any length up to the block size, but 
that when it is shorter it must be padded with zero bytes in order to 
extend it out to the block size. When longer, it must be first hashed 
using the algorithm in order to trim it. In other words, every SHA-1 key 
has a 160 bit form, even if the user provided a key that is either 
shorter or longer.

--Brandon

On 08/23/2014 03:37 AM, Oleg Moskalenko wrote:
> Actually, although, normally, 128-bits keys are used with HMAC-SHA-1,
> other key lengths are possible with that function. I admit that my
> suggestion may not be entirely accurate.
>
> Oleg
>
>
>
>     Tiru, I found an error in the 6.2 section (ACCESS_TOKEN). It is
>     mentioning the HMAC-SHA-1 algorithm with 160 bits key. This is
>     actually incorrect: HMAC-SHA-1 has 160 bits output result, but it
>     uses 128 bits input key, normally.
>
>     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.
>
>
>            the hash agility plan discussed insection 16.3 of [RFC5389]  <http://tools.ietf.org/html/rfc5389#section-16.3>.
>
>
>     NEW TEXT:
>
>
>     ------------------
>
>            message integrity of STUN message).Key length of256-bits  SHOULD
>            be supported (256-bit key is used by HMAC-SHA-256).Other key lengths
>     On Fri, Aug 22, 2014 at 9:11 AM, Oleg Moskalenko
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         But I still think that making a single algorithm (like
>         AES_256_CBC) default across all use cases is a good idea, I just
>         used wrong explanation for that.
>
>         Oleg
>
>
>         On Fri, Aug 22, 2014 at 8:34 AM, Oleg Moskalenko
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             On Fri, Aug 22, 2014 at 12:48 AM, Tirumaleswar Reddy
>             (tireddy) <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 *From:*tram [mailto:[email-masked]
>                 <mailto:[email-masked]>] *On Behalf Of *Oleg
>                 Moskalenko
>                 *To:* [email-masked] <mailto:[email-masked]>
>                 *Subject:* [tram]
>                 draft-ietf-tram-turn-third-party-authz-03____
>
>                 __ __
>
>                 I have the following comment:____
>
>                 In the section 4.1.1 and 4.1.2, the encryption algorithm
>                 AES_256_CBC has to be used, because the HKDF-Expand
>                 function of length 16 does not make much sense,
>                 according to RFC 5869 section 2.3.____
>
>                 ____
>                 anyway.____
>                 [TR] Thanks, will that in the next revision.____
>
>                 -Tiru____
>
>                 Thanks
>                 Oleg____
>
>
>
>
>

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

---

From: Brandon Williams <[email-masked]>
Date: Mon, 25 Aug 2014 10:35:37 -0400

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.

--Brandon

On 08/23/2014 02:47 AM, Oleg Moskalenko wrote:
> 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.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 25 Aug 2014 16:50:21 +0000

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

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

---

From: Brandon Williams <[email-masked]>
Date: Mon, 25 Aug 2014 13:10:13 -0400

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 25 Aug 2014 17:27:44 +0000

> Sent: Monday, August 25, 2014 10:40 PM
> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko
> Cc: [email-masked]
> 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
> 
> >> 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.
> >
> > 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
> >>
> >>> current level of
> >>> 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.
> 
> --

---

From: Brandon Williams <[email-masked]>
Date: Mon, 25 Aug 2014 13:49:57 -0400

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?

--Brandon