Subject: Re: [tram] Path Forward for STUN ORIGIN

From: Justin Uberti <[email-masked]>
Date: Tue, 25 Aug 2015 20:50:11 +0000

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 <[email-masked]>
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 -
>
>
>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 26 Aug 2015 23:08:48 +0000

splitting thread

On Wed, Aug 26, 2015 at 2:07 PM Alan Johnston <[email-masked]>
wrote:

> 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 think OAuth can solve #1, #2, and #3. The app's interaction with the AS
can give the AS context, which can be encoded into the returned token. This
then allows the TURN server to have this context when receiving the token,
such that it can make informed decisions for #1/#2/#3.

>
> 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.
>

Since the origin can be determined by the AS, it's not clear why this would
also be needed at the TURN server. One might ask, why it is better to use
origin to the AS versus the TURN server? The upsides of origin over HTTP to
AS are that 1) it is encrypted and 2) it's easier to deal with the privacy
implications of origin in a single protocol rather than 2 protocols.

>
> And using domain-specific USERNAME attributes sounds a bit like the
> problem that Martin mentioned of simply working around the approach.
>
>
Yes - that's what I was trying to say as well.

> - Alan -
>
> On Tue, Aug 25, 2015 at 3:50 PM, Justin Uberti <[email-masked]> wrote:
>
>> Overall, I think most/all of the goals that ORIGIN is trying to
>> accomplish would be better handled by STUN OAuth (
>>> 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.
>>>
>>> Also, the following use cases have also been discussed but are not in
>>> the draft
>>>
>>> 5. draft-jennings-behave-rtcweb-firewall-01 discusses how a firewall
>>> with STUN server could use ORIGIN in authorization decisions.
>>>
>>> 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.
>>>

---

From: Brandon Williams <[email-masked]>
Date: Tue, 01 Sep 2015 18:00:42 -0400

I agree that using the RFC7635 mechanism can work for #2, and I prefer 
that to ORIGIN for this purpose. That said, I think the mechanism is 
currently underspecified, in that there is nothing explicitly defined in 
RFC7635 that could be used to play the role of ORIGIN for auth purposes, 
so interoperability could be an issue.

If the kid value delivered in the USERNAME attribute is unique to the 
relay, then the kid value alone is enough to allow ORIGIN 
identification. This rules out the method for key distribution describe 
in section 4.1.1 of the RFC though, since that method has the auth 
server selecting the keys/kid, not the relay server, and I don't know 
how the necessary uniqueness would be guaranteed in that case. As long 
as the kid is unique to the relay, though, the necessary keys can be 
retrieved.

If the kid is not guaranteed to be unique for the relay, then some 
method to qualify the kid and provide uniqueness would be necessary. 
Either ORIGIN or REALM could be used for this purpose, but whichever one 
it is would itself have to be unique for the relay in order to ensure 
that qualifier+kid is unique.

RFC7635 doesn't impose requirements on kid uniqueness, nor does it 
require REALM, ORIGIN, or any other source of uniqueness to be present 
in the message that contains the token. Provided that either kid or 
realm+kid is unique to the relay, I agree that ORIGIN itself is not 
required for auth and the information could be delivered via some other 
mechanism.

All of this assumes that the STUN server name sent to the client from 
the relay as part of the initial unauthenticated exchange is a global 
value for the service and does not need to be allowed to be ORIGIN 
specific. In other words, any OAuth server that generates an access 
token for the 3rd party relay service would receive the same server name 
from a specific STUN server.

--Brandon

------------------------------------------------------------------------
*From:* Justin Uberti <[email-masked]>
*Sent:* Wednesday, August 26, 2015 7:08 PM
*To:* Alan Johnston
*Cc:* [email-masked]; [email-masked]
*Subject:* [tram] Oauth vs Origin [Was: Path Forward for STUN ORIGIN]
splitting thread

On Wed, Aug 26, 2015 at 2:07 PM Alan Johnston <[email-masked] 
<mailto:[email-masked]>> wrote:

    Justin,

    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 think OAuth can solve #1, #2, and #3. The app's interaction with the 
AS can give the AS context, which can be encoded into the returned 
token. This then allows the TURN server to have this context when 
receiving the token, such that it can make informed decisions for #1/#2/#3.

    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.

Since the origin can be determined by the AS, it's not clear why this 
would also be needed at the TURN server. One might ask, why it is better 
to use origin to the AS versus the TURN server? The upsides of origin 
over HTTP to AS are that 1) it is encrypted and 2) it's easier to deal 
with the privacy implications of origin in a single protocol rather than 
2 protocols.

    - Alan -

    On Tue, Aug 25, 2015 at 3:50 PM, Justin Uberti <[email-masked]
    <mailto:[email-masked]>> 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/
        <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtram-2Dturn-2Dthird-2Dparty-2Dauthz_&d=BQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=YAVYqLAvlnjV5WFeb0DMhGTziYu4jLvpB3UTCbrR8T4&s=uYVEJtj6D0D8AALXY1GfSzY-RO-q9CHJJjr2mCjvWlk&e=>)

        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
        <[email-masked] <mailto:[email-masked]>>
        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/
            <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtram-2Dstun-2Dorigin_ballot_&d=BQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=YAVYqLAvlnjV5WFeb0DMhGTziYu4jLvpB3UTCbrR8T4&s=lx5ApLOv-KiXbtLZppLxrkE5vHcqXhUqPSXlDcF-O28&e=>).
            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.

            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
            <https://urldefense.proofpoint.com/v2/url?u=http-3A__sub1.example.com&d=BQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=YAVYqLAvlnjV5WFeb0DMhGTziYu4jLvpB3UTCbrR8T4&s=rmZxvMmZrZEWtX42fGrg7dcvFr_RUv9ngo2yod2ZHPo&e=>
            and sub2.example.com
            <https://urldefense.proofpoint.com/v2/url?u=http-3A__sub2.example.com&d=BQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=YAVYqLAvlnjV5WFeb0DMhGTziYu4jLvpB3UTCbrR8T4&s=AyGtdO3Zale2SSP5BSnM64KJGpiFT9ICrzuSzeBVj7k&e=>
            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.)

            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.

            - Alan -

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 1 Sep 2015 18:59:42 -0700

The kid value must be unique across the server (the relay ?).
Otherwise, it all does not make sense. Probably the RFC7635 writers
even did not consider possibility that it may be not unique... and I
understand why. Non-unique kids raise all sorts of weird questions.

We can assign single unique REALM to each KID, and then we achieve
"multi-homeness".

Thanks
Oleg

On Tue, Sep 1, 2015 at 3:00 PM, Brandon Williams
<[email-masked]> wrote:
> I agree that using the RFC7635 mechanism can work for #2, and I prefer that
> to ORIGIN for this purpose. That said, I think the mechanism is currently
> underspecified, in that there is nothing explicitly defined in RFC7635 that
> could be used to play the role of ORIGIN for auth purposes, so
> interoperability could be an issue.
>
>
> If the kid value delivered in the USERNAME attribute is unique to the relay,
> then the kid value alone is enough to allow ORIGIN identification. This
> rules out the method for key distribution describe in section 4.1.1 of the
> RFC though, since that method has the auth server selecting the keys/kid,
> not the relay server, and I don't know how the necessary uniqueness would be
> guaranteed in that case. As long as the kid is unique to the relay, though,
> the necessary keys can be retrieved.
>
>
> If the kid is not guaranteed to be unique for the relay, then some method to
> qualify the kid and provide uniqueness would be necessary. Either ORIGIN or
> REALM could be used for this purpose, but whichever one it is would itself
> have to be unique for the relay in order to ensure that qualifier+kid is
> unique.
>
>
> RFC7635 doesn't impose requirements on kid uniqueness, nor does it require
> REALM, ORIGIN, or any other source of uniqueness to be present in the
> message that contains the token. Provided that either kid or realm+kid is
> unique to the relay, I agree that ORIGIN itself is not required for auth and
> the information could be delivered via some other mechanism.
>
>
> All of this assumes that the STUN server name sent to the client from the
> relay as part of the initial unauthenticated exchange is a global value for
> the service and does not need to be allowed to be ORIGIN specific. In other
> words, any OAuth server that generates an access token for the 3rd party
> relay service would receive the same server name from a specific STUN
> server.
>
>
> --Brandon
>
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 2 Sep 2015 02:10:24 +0000

Yes, kid must be unique. If relay server receives kid from an AS which conflicts with the kid already provisioned by another AS then relay server must request another kid using the mechanism specified in section 4.1. 

-Tiru

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
> Sent: Wednesday, September 02, 2015 7:30 AM
> To: Brandon Williams
> Cc: Justin Uberti; Alan Johnston; [email-masked]; draft-ietf-tram-stun-
> [email-masked]
> Subject: Re: [tram] Oauth vs Origin [Was: Path Forward for STUN ORIGIN]
> 
> Otherwise, it all does not make sense. Probably the RFC7635 writers even did
> not consider possibility that it may be not unique... and I understand why.
> Non-unique kids raise all sorts of weird questions.
> 
> We can assign single unique REALM to each KID, and then we achieve "multi-
> homeness".
> 
> Thanks
> Oleg
> 
> 
> > currently underspecified, in that there is nothing explicitly defined
> > in RFC7635 that could be used to play the role of ORIGIN for auth
> > purposes, so interoperability could be an issue.
> >
> >
> > identification. This rules out the method for key distribution
> > describe in section 4.1.1 of the RFC though, since that method has the
> > auth server selecting the keys/kid, not the relay server, and I don't
> > know how the necessary uniqueness would be guaranteed in that case. As
> > long as the kid is unique to the relay, though, the necessary keys can be
> retrieved.
> >
> >
> > Either ORIGIN or REALM could be used for this purpose, but whichever
> > one it is would itself have to be unique for the relay in order to
> > ensure that qualifier+kid is unique.
> >
> >
> > token for the 3rd party relay service would receive the same server
> > name from a specific STUN server.
> >
> >
> > --Brandon
> >
> >
> > On Wed, Aug 26, 2015 at 2:07 PM Alan Johnston
> > would also be needed at the TURN server. One might ask, why it is
> > better to use origin to the AS versus the TURN server? The upsides of
> > origin over HTTP to AS are that 1) it is encrypted and 2) it's easier
> > to deal with the privacy implications of origin in a single protocol rather
> than 2 protocols.
> >
> >
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
> > .org_doc_draft-2Dietf-2Dtram-2Dturn-2Dthird-2Dparty-
> 2Dauthz_&d=BQMFaQ&
> > c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> NSnsgwbBVUJa4mZfmEIBXg
> >
> &m=YAVYqLAvlnjV5WFeb0DMhGTziYu4jLvpB3UTCbrR8T4&s=uYVEJtj6D0D8A
> ALXY1GfS
> > zY-RO-q9CHJJjr2mCjvWlk&e=>)
> >
> >
> > <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtram-2Dstun-
> 2Dorigin_ballot_&d=BQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
> nnRGWmcGKRIuadq6-
> NSnsgwbBVUJa4mZfmEIBXg&m=YAVYqLAvlnjV5WFeb0DMhGTziYu4jLvpB3UT
> CbrR8T4&s=lx5ApLOv-KiXbtLZppLxrkE5vHcqXhUqPSXlDcF-O28&e=>).
> >
> > <https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__sub1.example.com&d=BQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
> nnRGWmcGKRIuadq6-
> NSnsgwbBVUJa4mZfmEIBXg&m=YAVYqLAvlnjV5WFeb0DMhGTziYu4jLvpB3UT
> CbrR8T4&s=rmZxvMmZrZEWtX42fGrg7dcvFr_RUv9ngo2yod2ZHPo&e=>
> >            and sub2.example.com
> >
> > <https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__sub2.example.com&
> > d=BQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
> NSnsgwbBVUJa4
> >
> mZfmEIBXg&m=YAVYqLAvlnjV5WFeb0DMhGTziYu4jLvpB3UTCbrR8T4&s=AyGt
> dO3Zale2
> > SSP5BSnM64KJGpiFT9ICrzuSzeBVj7k&e=>
> >

---

From: Brandon Williams <[email-masked]>
Date: Thu, 03 Sep 2015 10:26:00 -0400

I agree that a kid must be unique within its scope. I disagree that the 
only possible scope is global. For example, as Oleg has called out, 
REALM _could_ be used to scope the kid. ORIGIN, if adopted, could also 
be used to scope the kid.

My point is that the RFC does not in fact speak to this question, which 
presents possible interoperability issues, since one relay service 
provider could choose to use REALM for this purpose and another could 
choose to require global scoping. Maybe that flexibility is OK, or maybe 
it's something that needs to be resolved if we decide to discard/limit 
ORIGIN.

--Brandon