Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt

[Oleg Moskalenko <[e-mail]>]

Hi Tiru

I have some comments:

1) Section 4. Obtaining a Token Using OAuth, figure 4

I believe that the sequence of messages is incorrect. The TURN server most
probably will contact the Authorization server AFTER it gets the Allocate
request. But on the figure 4, it looks like it somehow can predict the
incoming request. The correct sequence must be, in the general case:

   Access Token Request (1) from client to Auth server
   Access Token + Session Key (2) from Auth server to client
   Allocate request from client to TURN server (3)
   Get Token from TURN Server to Auth server (4)
   Token metadata from Auth Server to TURN server (5)
   Allocate response from TURN server to the client (6)

The sequence shown on the figure 4 is possible only is the Auth Server and
TURN server are somehow closely integrated and that is unnecessary.

2) The document is saying that the client when communicating to the Auth
Server uses HTTP requests with JSON (REST API ?). May be it would be
helpful if the communication protocol between TURN server and Auth server
would be mentioned, too.

3) Section 7.2:

OAuth does not impose any limitation on the length of the access token but since
   STUN messages cannot exceed 548 bytes (Section 7.1 of [RFC5389]),
   access token length needs to be restricted to fit within the maximum
   STUN message size.

I am not sure that the STUN (Binding ?) max message size is relevant here
and worth mentioning at all - because this doc is about TURN, and the TURN
messages are often much larger than 548 bytes (especially when carrying the
video traffic). So I see no relevance of the 548 limit to the new
authentication standard. And that limitation of 548 bytes is applicable
only to the cases when we suspect that the path MTU is really really low
and that is an extremely rare case.

4) Are we sure that we want to limit the OAuth applicability only to the
long-term credentials mechanism ? I see no technical or philosophical
reasons why not to use it for short-term credentials mechanism, too. It
would be a more "symmetric" approach.

5) I'd put more definite wording how TURN server handles the token
lifetime. What happens in the middle of the TURN session, is the auth token
expires while the session is still active ? There may be two possible cases:

   - the token lifetime is applicable only to the session initiation
procedure. When the TURN session has been already established, it can go
indefinitely while the client is refreshing the session properly.

   - in second case when the token expires, the server rejects new requests
from the client (in the same TURN session) until the client sends the new
token data in re-authentication exchange.

I'd suggest the first case as an eisier case for the implementation.

Regards,
Oleg






On Fri, Feb 14, 2014 at 6:41 PM, Tirumaleswar Reddy (tireddy) <
[e-mail]> wrote:

> This document proposes the use of third party authorization using OAuth
> for TURN. Comments and suggestions are welcome.
>
> -Tiru
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, February 14, 2014 1:59 PM
> To: Ram Mohan R (rmohanr); Prashanth Patil (praspati); Tirumaleswar Reddy
> (tireddy); Prashanth Patil (praspati); Justin Uberti; Justin Uberti;
> Tirumaleswar Reddy (tireddy); Ram Mohan R (rmohanr)
> Subject: New Version Notification for
> draft-reddy-tram-turn-third-party-authz-00.txt
>
>
> A new version of I-D, draft-reddy-tram-turn-third-party-authz-00.txt
> has been successfully submitted by Tirumaleswar Reddy and posted to the
> IETF repository.
>
> Name:           draft-reddy-tram-turn-third-party-authz
> Revision:       00
> Title:          TURN Extension for Third Party Authorization
> Document date:  2014-02-14
> Group:          Individual Submission
> Pages:          11
> URL:
> http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-third-party-authz-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-reddy-tram-turn-third-party-authz/
> Htmlized:
> http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz-00
>
>
> 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, as is the case in
>    WebRTC where TURN credentials must be specified in Javascript.  It
>    also addresses the need for stronger authentication described in
>    [I-D.reddy-behave-turn-auth].
>
>
>
>
> 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.
>
> The IETF Secretariat
>
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>