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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 5 Sep 2014 17:01:02 +0000

> -----Original Message-----
> From: Brandon Williams [mailto:[email-masked]]
> Sent: Friday, September 05, 2014 6:57 PM
> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko
> Cc: [email-masked]
> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03
> 
> On 09/05/2014 07:21 AM, Tirumaleswar Reddy (tireddy) wrote:
> 
> [snip]
> 
> >> -----Original Message-----
> >> From: Brandon Williams [mailto:[email-masked]]
> >> Here are the ideas running through my head at the moment. The
> >> algorithm to use for standard STUN authentication could be selected
> >> in one of the two following ways (assuming that the client can't be
> >> pre-configured to know the algorithm in advance).
> >>
> >> Standard STUN Auth option 1
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> * client sends algorithm list in initial allocation request
> >> * relay server selects an algorithm and send that in the allocation
> >> error response
> >> * client sends allocation request with message integrity using
> >> selected algorithm
> >>
> >> Standard STUN Auth option 2
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> * client sends initial allocation request as per existing spec
> >> * relay server sends a list of supported algorithms in the allocation
> >> error response
> >> * client selects an algorithm from the list and uses it to generate
> >> message integrity for the new allocation request
> >>
> >> I like option 2 better because I think it works better with 3rd party
> >> auth by allowing for indirect in-band negotiation between the relay
> >> and auth servers as well as out-of-band negotiation, while at the
> >> same time not requiring the client to be pre-configured in either case.
> >
> > Yes, option 2 is more suitable.
> >
> >>
> >> 3rd Party Auth with initial relay server exchange
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> * no out-of-band algorithm exchange required between relay server and
> >> oauth server
> >> * client sends initial allocation request as per existing spec
> >> * relay server sends a list of supported algorithms in the allocation
> >> error response
> >> * client sends token request to oauth with the union set of
> >> algorithms supported by the client and the turn server
> >
> > I think you mean intersection.
> >
> 
> Oops, yes, I was thinks intersection throughout the earlier e-mail and writing
> union. Guess I should have waited until after that second cup of coffee.
> 
> >> * oauth server selects an algorithm from the list and sends an
> >> appropriate key in the token
> >> * client sends allocation request with message integrity using
> >> selected algorithm
> >
> > This approach looks good.
> >
> 
> OK. So, if we go with this model, then in the 3rd party draft, the the OAuth
> request would specify a list of supported algorithms, and the OAuth
> response would specify the selected algorithm. For now, the only valid value
> in each direction would be "hmac-sha1" or something similar.
> In the future, after hash agility and the list of must/should algorithms have
> been specified, other algorithm specifiers can be added.
> 
> Does that sound reasonable ?

Yes. Updated draft and attached the diff, please have a look.

Cheers,
-Tiru

> 
> --Brandon
> 
> > -Tiru
> >
> >>
> >> 3rd Party Auth without initial relay server exchange
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> * relay server provides oauth server with list of supported
> >> algorithms via out- of-band mechanism
> >> * client sends token request to oauth with the list of algorithms
> >> supported by the client
> >> * oauth server selects an algorithm from the set of algorithms
> >> supported by both the client and the relay server, and it sends an
> >> appropriate key in the token
> >> * client sends allocation request with message integrity using
> >> selected algorithm
> >>
> >>
> >> What are your thoughts on the above?
> >>
> >> --Brandon
> >>
> >> --
> >> Brandon Williams; Senior Principal Software Engineer Emerging
> >> Products Engineering; Akamai Technologies Inc.
> >>
> >> _______________________________________________
> >> tram mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/tram
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 5 Sep 2014 10:17:53 -0700

I agree with the changes.

Thanks
Oleg

---

From: Brandon Williams <[email-masked]>
Date: Fri, 05 Sep 2014 13:25:05 -0400

Looks good to me too.

--Brandon

On 09/05/2014 01:17 PM, Oleg Moskalenko wrote:
> On Fri, Sep 5, 2014 at 10:01 AM, Tirumaleswar Reddy (tireddy)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > From: Brandon Williams [mailto:[email-masked] <mailto:[email-masked]>]
>     > Cc:[email-masked] <mailto:[email-masked]>
>      > >> From: Brandon Williams [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      > >> [email-masked] <mailto:[email-masked]>

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 6 Sep 2014 02:22:01 +0000

Thanks Oleg and Brandon for the review.

-Tiru

> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Friday, September 05, 2014 10:55 PM
> To: Oleg Moskalenko; Tirumaleswar Reddy (tireddy)
> Cc: [email-masked]