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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 18 Feb 2014 06:48:59 +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.

Cheers,
-Tiru

From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Tuesday, February 18, 2014 10:42 AM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
[TR] Drafts in OAuth WG like https://tools.ietf.org/html/draft-richer-oauth-introspection-04 discuss the communication mechanism b/w Resource Server and Authorization server.  You may also want to look into http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html 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:

http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

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 ?

Thanks,
Oleg

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 18 Feb 2014 12:27:01 +0000

Hi Oleg,

"short-term mechanism" is currently only used for ICE connectivity checks and not used for TURN. I don't see any difference how the INTEGRITY field is calculated with both the short-term and long-term credential mechanisms
key = MD5(username ":" realm ":" SASLprep(password))
The only exception is "realm" would always be missing for short-term mechanism.

Anyways like you have mentioned with third party authorization the session key (password), kid (username) would change frequently and has similarities with short-term mechanism.

-Tiru
Sent: Tuesday, February 18, 2014 11:40 AM

Hi Tiru
regarding the authentication mechanisms: yes, I am talking about section 10.1 of STUN RFC 5389:

http://tools.ietf.org/search/rfc5389#section-10.1

STUN defines both short-term mechanism and long-term mechanism. They differ in the ways how the INTEGRITY field is calculated, and in some other minor details. The names are somewhat unfortunate and confusing; the "short-term mechanism" is NOT about short-lived ephemeral identities. The proposed token-based authorization is equally applicable to both short-term and long-term mechanisms - taking into account different INTEGRITY calculation algorithms.
>From the pure technical point of view, I think that the token authorization is equally applicable to the short-term mechanism than to the long-term mechanism.
Of course the short-term mechanism is not very important in this context because this proposed standard is mostly about WebRTC. But it would be "cleaner" if the token authorization will be applied to the whole STUN/TURN specs, not to a particular case of WebRTC. And may be some day WebRTC will decide to adopt the short-term mechanism...

Regards,
Oleg