Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.txt

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 1 Sep 2014 00:32:56 -0700

I have more comments on the document:

===================================
Section 6.2. ACCESS-TOKEN

The token is structured as follows:

         struct {
             opaque {
                 ushort key_length;
                 opaque mac_key[key_length];
                 opaque timestamp[8];
                 long   lifetime;
             } encrypted_block;
             opaque mac[mac_length];
         } token;
====================================

I'd suggest the following:

1) ushort and long are values of unknown length. I understand that the
authors meant "2-bytes unsigned integer" and "4-bytes integer" but it is
true only for 32-bits Unixes (and even for them it is not 100% true). Use
the exact POSIX-style type names with definite size - like uint16_t and
uint32_t. Or just say that it is a 2-bytes and 4-bytes unsigned integers.

2) The lifetime cannot be negative, so it must be an unsigned value.

3) It is worth mentioning that all numbers are in network byte order.

4) The timestamp definition is unnecessary complex. Why would we need
anything else than seconds since 1970 ? That's not a realtime
milliseconds-precision value.

I'd re-wrote the whole structure as:

 struct {
    struct {
       uint16_t key_length;
       uint8_t mac_key[key_length];
       uint64_t timestamp;
       uint32_t lifetime;
    } encrypted_block;
    uint8_t mac[mac_length];
 } token;

5) I did not get the exact token encryption procedure. I think that I
understand what was the intended procedure but the wording is just not
clear and inaccurate. It says that "The token MUST be encoded as
defined in Section 4
of [RFC4648] <http://tools.ietf.org/html/rfc4648#section-4> and then
encrypted using the symmetric long-term key established between the
resource server and the authorization server,". Why we need Base64 here ?
What exactly has to be base64-processed here (the encrypted_block before
the encryption) ? The current wording is impossible because the whole
structure is the token. So you cannot refer to the encrypted portion as a
token per se. Please clarify and put more detailed steps what exactly has
to be processed and how. And, may be, it all has to be Base64-ed AFTER the
encryption and signing ? (current wording suggest to base64 the data BEFORE
the encryption).

Thanks !
Oleg

On Wed, Aug 27, 2014 at 3:37 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> This version addresses comments from Hannes and Oleg.
>
> -Tiru
>
> > -----Original Message-----
> > From: tram [mailto:[email-masked]] On Behalf Of internet-
> > [email-masked]
> > Sent: Wednesday, August 27, 2014 3:19 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >  This draft is a work item of the TURN Revised and Modernized Working
> > Group of the IETF.
> >
> >         Title           : TURN Extension for Third Party Authorization
> >         Authors         : Tirumaleswar Reddy
> >                           Prashanth Patil
> >                           Ram Mohan Ravindranath
> >                           Justin Uberti
> >       Filename        : draft-ietf-tram-turn-third-party-authz-02.txt
> >       Pages           : 16
> >       Date            : 2014-08-27
> >
> > Abstract:
> >    This document proposes the use of OAuth to obtain and validate
> >    ephemeral tokens that can be used for TURN authentication.  The usage
> >    of ephemeral tokens ensure that access to a TURN server can be
> >    controlled even if the tokens are compromised.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-02
> >
> > A diff from the previous version is available at:
> >
> http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-02
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > tram mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tram
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 2 Sep 2014 12:33:30 +0000

Hi Oleg,
Please see inline..

From: Oleg Moskalenko <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 1, 2014 1:02 PM
To: "Tirumaleswar Reddy (tireddy)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.txt

         struct {
             opaque {
                 ushort key_length;

1) ushort and long are values of unknown length. I understand that the authors meant "2-bytes unsigned integer" and "4-bytes integer" but it is true only for 32-bits Unixes (and even for them it is not 100% true). Use the exact POSIX-style type names with definite size - like uint16_t and uint32_t. Or just say that it is a 2-bytes and 4-bytes unsigned integers.

PRA: Yes, we've updated with uintN_t wherever applicable.

PRA: Yes.

PRA: Sure.

4) The timestamp definition is unnecessary complex. Why would we need anything else than seconds since 1970 ? That's not a realtime milliseconds-precision value.

PRA: A lot of specifications define timestamp this way. See http://tools.ietf.org/html/rfc3971#section-5.3.1. Also, linux gettimeofday() function gets the current time, expressed in seconds and microseconds since midnight (0 hour), January 1, 1970 UTC (http://linux.die.net/man/2/gettimeofday) — making things easier for developers.

 struct {
    struct {
       uint16_t key_length;

5) I did not get the exact token encryption procedure. I think that I understand what was the intended procedure but the wording is just not clear and inaccurate. It says that "The token MUST be encoded as defined in Section 4 of [RFC4648]<http://tools.ietf.org/html/rfc4648#section-4> and then encrypted using the symmetric long-term key established between the resource server and the authorization server,". Why we need Base64 here ?

PRA: This is to ensure that data remains intact without modification during transport. It is common practice to encode binary data in ASCII string format when sending over HTTP.

What exactly has to be base64-processed here (the encrypted_block before the encryption) ?

PRA: The entire token i.e. 'encrypted_block' and the 'mac' is to be base64 encoded.

The current wording is impossible because the whole structure is the token. So you cannot refer to the encrypted portion as a token per se. Please clarify and put more detailed steps what exactly has to be processed and how. And, may be, it all has to be Base64-ed AFTER the encryption and signing ? (current wording suggest to base64 the data BEFORE the encryption).

PRA: You're right, the current wording is quite confusing. Please see attached diffs for updated text. Let us know if the updates are fine.

-Prashanth

Thanks !
Oleg

On Wed, Aug 27, 2014 at 3:37 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
This version addresses comments from Hannes and Oleg.

-Tiru

> From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of internet-
> [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 2 Sep 2014 09:21:24 -0700

I agree with the changes.

Thanks !
Oleg

On Tue, Sep 2, 2014 at 5:33 AM, Prashanth Patil (praspati) <
[email-masked]> wrote:

>  Hi Oleg,
> Please see inline..
>
>    From: Oleg Moskalenko <[email-masked]>
> To: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> Subject: Re: [tram] I-D Action:
> draft-ietf-tram-turn-third-party-authz-02.txt
>
>  PRA: A lot of specifications define timestamp this way. See
> http://tools.ietf.org/html/rfc3971#section-5.3.1. Also, linux gettimeofday()
> function gets the current time, expressed in seconds and microseconds
> since midnight (0 hour), January 1, 1970 UTC (
> http://linux.die.net/man/2/gettimeofday) — making things easier for
> developers.
>
> clear and inaccurate. It says that "The token MUST be encoded as defined in Section 4
>  PRA: This is to ensure that data remains intact without modification
> during transport. It is common practice to encode binary data in ASCII
> string format when sending over HTTP.
>
>    The current wording is impossible because the whole structure is the
> token. So you cannot refer to the encrypted portion as a token per se.
> Please clarify and put more detailed steps what exactly has to be processed
> and how. And, may be, it all has to be Base64-ed AFTER the encryption and
> signing ? (current wording suggest to base64 the data BEFORE the
> encryption).
>
>  PRA: You're right, the current wording is quite confusing. Please see
> attached diffs for updated text. Let us know if the updates are fine.
>
>  -Prashanth
>
>  Thanks !
> Oleg
>
>
>
>
>> > Subject: [tram] I-D Action:
>> draft-ietf-tram-turn-third-party-authz-02.txt
>> >
>> >

---

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Sep 2014 10:31:21 -0400

I see the following new text related to hash algorithm agility in the 
new draft.

"Discussion: 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."

I've got two concerns about this, which are both just reiterations of 
things I've mentioned previously on the list. First, I think it may be 
premature to say anything about hash agility in this draft until we've 
settled the question more broadly in stunbis. Second, I think the OAuth 
server must be in a position to enforce policy on the minimum acceptable 
hash algorithm, and so allowing the client to pick one makes the 
mechanism more fragile. It may be preferable for the client to signal 
it's full list of capabilities in the request and for the server to 
signal its selection from among the options (or an error if nothing from 
the client's list is considered acceptable).

On a separate note, I was reminded by the meeting notes that I promised 
to send some comments to the list about resource utilization. Customers 
of a 3rd party service will often have contracts that limit resource 
utilization. There may be limits in terms of the total number of 
concurrent end-to-end streams, aggregate bandwidth, etc. Considering 
this, it may be necessary for the OAuth server to authorize the client 
for a certain maximum utilization to be associated with the 
ACCESS-TOKEN. Although it could make the token larger, I think it may be 
important to include this authorized utilization information within the 
token. Does anyone have any thoughts about this? Perhaps an alternate 
way to handle the same concern?

--Brandon

On 08/27/2014 05:48 AM, [email-masked] wrote:
>   This draft is a work item of the TURN Revised and Modernized Working Group of the IETF.
>

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

---

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

> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Wednesday, September 03, 2014 8:01 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> I see the following new text related to hash algorithm agility in the new draft.
> 
> 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."
> 
> I've got two concerns about this, which are both just reiterations of things
> I've mentioned previously on the list. First, I think it may be premature to say
> anything about hash agility in this draft until we've settled the question more
> broadly in stunbis. 

The questions before us are:
Do we want to stall progress on this draft till hash agility is finalized in STUNbis OR 
Have a discussion right now, finalize the behavior and update the draft OR
Don't discuss about hash agility in the draft and take it forward ?

> Second, I think the OAuth server must be in a position to
> enforce policy on the minimum acceptable hash algorithm, and so allowing
> the client to pick one makes the mechanism more fragile. It may be
> preferable for the client to signal it's full list of capabilities in the request and
> for the server to signal its selection from among the options (or an error if
> nothing from the client's list is considered acceptable).

I have responded to the above suggestion in another mail thread.

> 
> On a separate note, I was reminded by the meeting notes that I promised to
> send some comments to the list about resource utilization. Customers of a
> 3rd party service will often have contracts that limit resource utilization.
> There may be limits in terms of the total number of concurrent end-to-end
> streams, aggregate bandwidth, etc. Considering this, it may be necessary for
> the OAuth server to authorize the client for a certain maximum utilization to
> be associated with the ACCESS-TOKEN. Although it could make the token
> larger, I think it may be important to include this authorized utilization
> information within the token. Does anyone have any thoughts about this?
> Perhaps an alternate way to handle the same concern ?

The two possible approaches for solving the problem are discussed in http://tools.ietf.org/html/draft-hardjono-oauth-umacore-10#section-3.3 and I don't think we should complicate the draft with token profile. Probably take up this effort as a separate draft.

-Tiru

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 3 Sep 2014 17:54:38 +0000

> Don't discuss about hash agility in the draft and take it forward ?

My preference is we have the discussion and let the results of that feed into STUNbis.  The draft can refer to STUNbis for all things hash agility.  We have this on the list and plan to produce a version very soon, so I don't expect long delays to this work.

Cheers,

Gonzalo

---

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

Agreed. We don't have to have a finalized stunbis. We just need to have 
a reasonable idea what the mechanism will look like.

--Brandon