Re: [tram] Path Forward for STUN ORIGIN

[Alan Johnston <[e-mail]>]

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]> 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]>
> 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 and 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 -
>>
>>
>>