Subject: [tram] STUN auth: The endpoint is in control

From: Simon Perreault <[email-masked]>
Date: Thu, 14 May 2015 13:56:09 -0400

TRAMsters,

I think it is important, in order to make STUN's authentication model
clearer in the face of WebRTC usage, that we start re-emphasizing that
the endpoint is in control of its own NAT traversal, independent of call
signalling. This is a core design principle of STUN/TURN/ICE.

=======================

Exhibit A: <http://numb.viagenie.ca>

This is a freely-available STUN/TURN server. You just sign up for an
account and start using it with whatever signalling infrastructure you
want. With SIP, just configure the server address, username, and
password into your SIP client and you're ready to go. With WebRTC you
can do the same by configuring those into your browser, which should
override any application-provided servers.

Notice that the endpoint is fully in charge of its own destiny. It has a
relationship with the server, but the signalling infrastructure does not.

With this use-case the IP addresses on which the server listens are
dedicated to the public service. ORIGIN would be useful in order to
co-locate the public service with some class of private services
(different auth database) without dedicating new IP addresses for each
private service.

========================

Exhibit B: <https://tools.ietf.org/html/draft-ietf-rtcweb-return-00>

RETURN is a way for WebRTC endpoints, browsers in particular, to force
usage of a particular TURN server, with which the endpoint has a prior
trust relationship, in order to ensure some level of privacy for the
endpoint. A second layer of non-privacy-providing TURN may be used in
order to provide NAT traversal.

In this case too the endpoint is fully in control. The signalling
infrastructure (i.e., the WebRTC application) has no relationship with
the privacy-providing TURN server, and no control over it.

========================

What I'm getting at is that trying to bind STUN auth with the signalling
session goes against STUN/TURN/ICE design.

Thoughts? Comments?

Simon

---

From: Brandon Williams <[email-masked]>
Date: Thu, 14 May 2015 16:39:40 -0400

Hi Simon,

I agree that this usage model can be desirable in many cases. For 
example, if my enterprise or ISP provides TURN relay service to me, I 
will likely get better performance if I use that rather than using a 
relay service with a very small data center footprint that is not 
geographically diverse. It should be possible for me to choose to use 
this more optimal relay service as my data path if the relay preferred 
by my application would be less optimal for performance. Likewise, a 
remotely located fixed point relay service might be a better selection 
for privacy reasons, and if privacy is my primary concern then I should 
be able to select that relay service.

Where you and I may differ (I'm uncertain from this e-mail) is on the 
question of whether I should be able to use any relay service to which I 
have access as the data path for any data flow. If the relay service is 
preferred and paid for by one application service that I use, should I 
be able to use that relay service for any/all of my p2p applications? Or 
should it be possible for the relay service to limit use to just the 
applications that have been approved for access?

On the one hand, I think that I as an end user should be able to pick 
which of the acceptable relays will be used for a particular data flow 
based on my requirements for that session. On the other hand, I also 
think that the relay service provider should be able to limit access in 
cases where the relay service has a relationship with the application 
provider and not with me. The protocol doesn't allow this 
differentiation today, but I don't think that means that it must not 
allow this in the future.

In short, I don't think that the protocol should _require_ any sort of 
binding between the signaling session and STUN auth, but I do think that 
in some cases there may be reasons to _allow_ such binding.

--Brandon

On 05/14/2015 01:56 PM, Simon Perreault wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

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

---

From: Simon Perreault <[email-masked]>
Date: Thu, 14 May 2015 17:05:49 -0400

> applications that have been approved for access?

The latter. You're right, this was not clear from my email.

> allow this in the future.

Fully agreed. Classical STUN auth, with or without ORIGIN, does not
allow this limitation. Third-party-auth does (or I think it does, not
quite sure anymore).

> in some cases there may be reasons to _allow_ such binding.

Exactly. Schematically:

OK: "example.com's TURN server can only be used on example.com"

NOT OK: "example.com can only be used with example.com's TURN server"

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 14 May 2015 17:10:05 -0400

Le 2015-05-14 17:05, Simon Perreault a écrit :
> allow this limitation.

Actually, ephemeral credentials may be sufficient in many cases. It's
not air-tight, but may be good enough. Just mentioning for completeness.

Simon

---

From: Brandon Williams <[email-masked]>
Date: Fri, 15 May 2015 08:55:53 -0400

> allow this limitation. Third-party-auth does (or I think it does, not

Even with third-party-auth and/or a creative use of short-term 
credentials, I think that all we can get today is an assurance that I 
must be a user of an authorized service in order to get an allocation. 
Once I have an allocation, there's no way via STUN/TURN for the relay 
service to know whether a specific ChannelBind/Permission is also 
approved by the application service. I can use my established allocation 
for any data flow I want unless the relay service and the application 
service build an OOB method for validation.

I think it would be fairly easy to build peer address signing into the 
protocol such that it would be possible to enforce such a limitation. 
I'll be curious to hear whether anyone else would be interested in this.

--Brandon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 15 May 2015 13:08:59 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Friday, May 15, 2015 6:26 PM
> To: Simon Perreault; [email-masked]
> Subject: Re: [tram] STUN auth: The endpoint is in control
> 
> >> >which of the acceptable relays will be used for a particular data
> >> >flow based on my requirements for that session. On the other hand, I
> >> >also think that the relay service provider should be able to limit
> >> >access in cases where the relay service has a relationship with the
> >> >application provider and not with me. The protocol doesn't allow
> >> >this differentiation today, but I don't think that means that it
> >> >must not allow this in the future.
> Even with third-party-auth and/or a creative use of short-term credentials, I
> think that all we can get today is an assurance that I must be a user of an
> authorized service in order to get an allocation.
> service to know whether a specific ChannelBind/Permission is also approved
> by the application service. I can use my established allocation for any data
> flow I want unless the relay service and the application service build an OOB
> method for validation.

Yes, we are exploring that option to prevent misuse, it helps the Enterprise TURN server use-cases where FW is configured to only permit UDP traffic to well-known TURN servers. Enterprise TURN server is configured to support both first party authentication and third party authorization to differentiate b/w calls. Token introspection work done in OAuth 2.0 https://tools.ietf.org/html/draft-ietf-oauth-introspection-08 can be leveraged for this purpose.

> 
> I think it would be fairly easy to build peer address signing into the protocol
> such that it would be possible to enforce such a limitation.

-Tiru

---

From: Brandon Williams <[email-masked]>
Date: Fri, 15 May 2015 09:38:10 -0400

Just to be clear, I wasn't suggesting that I think an OOB communication 
method between the relay server and the application server is the right 
approach for this. I'd prefer an in-band validation method; perhaps one 
that takes advantage of the keys used for 3rd party auth and/or an auth 
key used for app server origin signing as per Stephen's suggestion.

--Brandon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 15 May 2015 14:20:50 +0000

> From: Brandon Williams [mailto:[email-masked]]
> Sent: Friday, May 15, 2015 7:08 PM
> To: Tirumaleswar Reddy (tireddy); Simon Perreault; [email-masked]
> approach for this. I'd prefer an in-band validation method; perhaps one that
> takes advantage of the keys used for 3rd party auth and/or an auth key used
> for app server origin signing as per Stephen's suggestion.

I am not sure how this mechanism works. Application server will only be aware of the selected candidates after the controlling endpoint sends an updated offer after ICE connectivity checks are complete. The other problem is peer-reflexive candidates will be discovered during ICE checks.

-Tiru

> >>>>> flow based on my requirements for that session. On the other hand,
> >>>>> I also think that the relay service provider should be able to
> >>>>> limit access in cases where the relay service has a relationship
> >>>>> with the application provider and not with me. The protocol
> >>>>> doesn't allow this differentiation today, but I don't think that
> >>>>> means that it must not allow this in the future.
> >>> allow this limitation. Third-party-auth does (or I think it does,
> >>> not quite sure anymore).
> >>>
> >>
> >> approved by the application service. I can use my established
> >> allocation for any data flow I want unless the relay service and the
> >> application service build an OOB method for validation.
> >
> > Yes, we are exploring that option to prevent misuse, it helps the Enterprise
> TURN server use-cases where FW is configured to only permit UDP traffic to
> well-known TURN servers. Enterprise TURN server is configured to support
> both first party authentication and third party authorization to differentiate
> b/w calls. Token introspection work done in OAuth 2.0
> https://tools.ietf.org/html/draft-ietf-oauth-introspection-08 can be leveraged
> for this purpose.
> >
> >>
> >> I think it would be fairly easy to build peer address signing into
> >> the protocol such that it would be possible to enforce such a limitation.