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

"Tirumaleswar Reddy (tireddy)" <> Tue, 18 February 2014 06:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9E92C1A0366 for <>; Mon, 17 Feb 2014 22:49:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 aEzt8pwgwzV9 for <>; Mon, 17 Feb 2014 22:49:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3C83A1A042D for <>; Mon, 17 Feb 2014 22:49:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=13644; q=dns/txt; s=iport; t=1392706141; x=1393915741; h=from:to:cc:subject:date:message-id:mime-version; bh=tkwgcBh1+txYcOXaZxAHoTe4Wse4n/Mkn5+3C0qGFxg=; b=lWwdZrX0o7hzX/LRGT9ePswFHwGlQ5UaSo2wPDZ0r8GrhkJPDAg5dpo1 74i6+bTyieoFtDTrPTUxaCnTYGYRvOybmY2BH+w9yu4ObPHInWlISNJtt cAK5y2m2HeMXhcSX7oxZJZVcjrX4awAOt8P8BNGYIIhRybpc/Z6QJR/4o Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.97,500,1389744000"; d="scan'208,217"; a="21179865"
Received: from ([]) by with ESMTP; 18 Feb 2014 06:49:00 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s1I6n0E3006419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 06:49:00 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 00:49:00 -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: Ac8sdX3TMieZnzYhT5uLjwFOIolCjg==
Date: Tue, 18 Feb 2014 06:48:59 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242C02A9xmbrcdx10ciscoc_"
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: Tue, 18 Feb 2014 06:49:07 -0000

Hi Oleg,

OAuth is a framework and we are only using it's concepts in the TURN third party authorization draft. There are vendors who have implemented and deployed OAuth for authentication and authorization. If standardization is required we can have a separate draft for the communication mechanism b/w the TURN server and Authorization server. But only after there is WG consensus that handle token better suites TURN third party authorization problem than self-contained token.

I see good progress happening in the OAuth WG, for any other generic concerns about OAuth it would be fair to include OAuth IETF WG.


From: Oleg Moskalenko []
Sent: Tuesday, February 18, 2014 10:42 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 went thru the OAuth interoperability links which you suggested (see below):

On Mon, Feb 17, 2014 at 10:29 AM, Oleg Moskalenko <<>> wrote:
[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.

The links provide meaningful suggestions - but the drafts did not result in definite standards. The current situation in OAuth is that it is a pretty fragmented and balkanized field... and it is not moving toward a definite interoperability standard.
As of now, OAuth is actually not a standard - it is more a framework. So we have a logical conflict - the TURN specs are definitely a standard, not a framework, but we introduce a dependency on something that is just a framework. That would be inconsistent.

Each OAuth server provider defines its own proprietary API for the Resource Server. That does not sounds very attractive. In practice, every TURN server provider will have to provide its own OAuth server, too. That will lead to further fragmentation.
Overall, OAuth is a heated minefield full of emotions and from the outside, it seems to be going nowhere in terms of interoperability. The lead developer of OAuth withdrew himself:

As a TURN server developer, I'd be very hesitant to tie, closely, the implementation to OAuth. I'd rather suggest to look at other alternatives, giving the current state of OAuth - or wait till the things will be clarified and OAuth will get more interoperability.
Of course we can develop our own OAuth server but that would be a rather unfortunate outcome of the standardization process.

I am not saying that from the technical point of view this draft specs is a bad idea. The TURN field is ready for something like that; but I see that OAuth is not ready - and I have concerns on being dependent on OAuth.
Tiru, can you address my concerns ?