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

"Tirumaleswar Reddy (tireddy)" <> Mon, 17 February 2014 11:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0F4C71A0481 for <>; Mon, 17 Feb 2014 03:10:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.049
X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eS_22kReiqal for <>; Mon, 17 Feb 2014 03:10:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2EF491A0489 for <>; Mon, 17 Feb 2014 03:10:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7272; q=dns/txt; s=iport; t=1392635430; x=1393845030; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=D7Y2a3ZRXPcsM0JD0AAxKUEE4X1fJ8aAcIXLw+GC4gk=; b=EY2UuWjT850XCf34qieRjF/zQUqSFjQULbrulfGMN9qe63k48Y9Hs0ko i64GoHs5dEFlHN0cWFo/gtvH6e7l9yt8u4WLIHTotWCyDeEf5oHmcISsy Ylcl0seZeGMO8Y036pzIpq/yU7aztjPpmSMQGZ29BLvQS7BmLSJ7lsh4s Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.95,859,1384300800"; d="scan'208";a="20995198"
Received: from ([]) by with ESMTP; 17 Feb 2014 11:10:26 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s1HBAPW5000857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 11:10:26 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 05:10:25 -0600
From: "Tirumaleswar Reddy (tireddy)" <>
To: Oleg Moskalenko <>
Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt
Thread-Index: Ac8r0NgRqrA6RMrjS1qsrfIex+lw1w==
Date: Mon, 17 Feb 2014 11:10:24 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Feb 2014 11:10:36 -0000

Hi Oleg,

Thanks for the review. Please see inline [TR]

From: Oleg Moskalenko [] 
Sent: Sunday, February 16, 2014 10:31 AM
To: Tirumaleswar Reddy (tireddy)
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt

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)

[TR] Good catch, fixed it. It got messed when we were changing from self-contained to handle token.
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.

[TR] Yes, the AS and TURN server have to be integrated. There may be ways to standardize this, but this is not in the scope of this doc right away.

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.

[TR] Drafts in OAuth WG like discuss the communication mechanism b/w Resource Server and Authorization server.  You may also want to look into which discusses such communication mechanism already implemented but for a different purpose. I guess it all worked because Resource server and Authorization server are developed by the same company but with this use case we may have to discuss if standardization is required for the communication mechanism.

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.

[TR] Good point. But RFC 5766 recommends to restrict the size (Section 2.7 Avoiding Fragmentation)


   As a guideline, sending a maximum of 500 bytes of application data in
   a single TURN message (by the client on the client-to-server leg) or
   a UDP datagram (by the peer on the peer-to-server leg) will generally
   avoid IP fragmentation.


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.

[TR] what is the use case for short-term credential mechanism with TURN ?

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.

[TR] The client MUST obtain a new token after the previously used one expires. As you point out an already established TURN session can continue, the new token is applicable for new requests.  If the client uses the token after its lifetime then the TURN server MUST return error that the token is invalid which is in line with the steps defined in 

We will update these details next revision.



On Fri, Feb 14, 2014 at 6:41 PM, Tirumaleswar Reddy (tireddy) <> wrote:
This document proposes the use of third party authorization using OAuth for TURN. Comments and suggestions are welcome.


-----Original Message-----
From: []
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

   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

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at

The IETF Secretariat

tram mailing list