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

> -----Original Message-----
> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams
> Sent: Wednesday, September 03, 2014 8:01 PM
> To: internet-drafts@ietf.org; i-d-announce@ietf.org
> Cc: tram@ietf.org
> Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.txt
> 
> 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. 

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

> 
> --Brandon
> 
> On 08/27/2014 05:48 AM, internet-drafts@ietf.org wrote:
> >
> > 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
> > tram@ietf.org
> > https://www.ietf.org/mailman/listinfo/tram
> >
> 
> --
> Brandon Williams; Senior Principal Software Engineer
> Emerging Products Engineering; Akamai Technologies Inc.
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram