Re: [tram] Path Forward for STUN ORIGIN

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Alan,

OAuth solves all the below use cases, #4 and #5 is discussed in https://www.iab.org/wp-content/IAB-uploads/2015/01/semi2015_reddy.pdf.

-Tiru

From: tram [mailto:[e-mail]] On Behalf Of Alan Johnston
Sent: Thursday, August 27, 2015 2:37 AM
To: Justin Uberti
Cc: [e-mail]; [e-mail]
Subject: Re: [tram] Path Forward for STUN ORIGIN

Justin,

It is an important question for the WG on whether ORIGIN is a useful solution to the use cases.  Hopefully we'll get more feedback on this.

Your comments seem mainly directed towards a solution for use case #2 below (REALM selection for TURN authentication), right?  I'm not sure if use case #3 applies or not.  I don't think OAuth helps with #1 or #4 or #5.

I know we have discussed it before, but I also don't think that everyone believes that OAuth means that ORIGIN is no longer needed. There have been suggestions that a multi-tenanted TURN server using OAuth might still use ORIGIN.

And using domain-specific USERNAME attributes sounds a bit like the problem that Martin mentioned of simply working around the approach.

- Alan -

On Tue, Aug 25, 2015 at 3:50 PM, Justin Uberti <[e-mail]<mailto:[e-mail]>> wrote:
Overall, I think most/all of the goals that ORIGIN is trying to accomplish would be better handled by STUN OAuth (https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/)

Generally, it's not clear that ORIGIN is a great solution for any of the use cases listed.
1) is easily accomplished via oauth, without any of the restrictions present here
2) can be dealt with using other means (e.g. oauth, or supplying domain info in USERNAME)
3) is fairly weak control, and can be done better through oauth, or domained USERNAMEs

Of course, as noted by others, use of domained USERNAMEs creates a quasi-ORIGIN value within the USERNAME attribute, which makes OAuth more attractive.

On Tue, Aug 25, 2015 at 12:57 PM Alan Johnston <[e-mail]<mailto:[e-mail]>> wrote:
All,

Based on feedback during IETF-93 in Prague, the authors of draft-ietf-stun-origin are looking for feedback on a possible path forward to solve the privacy/meta data issues and clear the DISCUSSes (see https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ballot/).  There are two areas of feedback: Use Cases and Proposed Solution.

Use Cases
========

First, we want to be sure that we are considering all the use cases for STUN ORIGIN.  In the draft, three are described:

1.  Logging of usage of STUN/TURN server. An operator of a STUN or TURN server would learn the Origin of the web, SIP, and XMPP users.

2.  REALM selection for multi-tenanted TURN server. This avoids having to run multiple instances on different ports or IP addresses when more than one REALM is in use.

3.  Service determination after authentication.  Bandwidth or QoS policy can be applied, after authentication, based on the Origin.

Also, the following use cases have also been discussed but are not in the draft

4.  Authorization at border TURN server after authentication.  An enterprise border TURN server can apply policy and allow usage for certain Origins (whitelist) or block usage of others (blacklist).

5. draft-jennings-behave-rtcweb-firewall-01 discusses how a firewall with STUN server could use ORIGIN in authorization decisions.

Are there any other use cases we should consider?

Possible Solution
=============

The solution that was discussed in Prague that seems to be the best tradeoff between privacy and functionality is to only include ORIGIN information in a STUN or TURN request if the domain of the Origin matches the domain of the STUN or TURN server in the STUN or TURN URI.  Since web and STUN and TURN run on different ports, and often will resolve to different IP addresses, a full host comparison is not possible.  This proposal is not perfect: it does not provide perfect privacy for subdomains (e.g. sub1.example.com<http://sub1.example.com> and sub2.example.com<http://sub2.example.com> will match with this rule, even if they are separate entities.  Of course, subdomain users could always register a new domain and point DNS records to their sub hoster.)

In comparing this solution against the use cases above:

1. Allows logging of your own users on your own TURN server (or one that you setup DNS SRV records to point towards).  Other users of your STUN or TURN server will not be identified by an Origin, but you will at least know if others are using your server.

2. Works for REALM selection as long as you use your own TURN server (or one that you setup DNS SRV records to point towards).

3. Again, works for service determination as long as you use your own TURN server (or one that you setup DNS SRV records to point towards).  Having service-specific TURN credentials is another solution that doesn't rely on ORIGIN.

4. & 5. Does not seem provide a good solution for these use cases.

Does this analysis make sense?

Feedback most welcome so we can move forward with this draft.

- Alan -