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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 1 Jun 2015 14:45:32 +0200

Simon,

I see some significant dangers to privacy with this trend. I think it is 
very important that we don't motivate that this is correct in an WebRTC 
context, just because ICE/STUN/TURN was designed in a particular way 
because it needed to work with SIP.

Lets look at the privacy implications of using a single STUN/TURN 
provider in your UA that overrides the web service's own STUN/TURN 
servers. That means that these configured STUN/TURN servers will see all 
the cases where you establish a PeerConnection and what destinations on 
the media plane. Thus, this STUN/TURN provider will get a very complete 
picture of what you do and who you communicate with. This means trusting 
an additional part with information of the users behaviours.

Lets compare this with a case if one only uses the Web service's STUN 
and TURN servers. In that case, the Web Services already knows about who 
you are communicating within the web application due to its role as find 
and connection provider. However, it only knows what you are doing 
within that single application. When you switch tab and use another 
service the first has no view into what you are doing here. Thus, an 
important separation of concerns is established.

I do understand that there are use cases where it is important or even 
mandated for one's organization or employer to know who one communicates 
with and thus there are a strong need to enable this local 
configuration. However, I think it is important this do not occur 
automatically without the user's knowledge. It is after all a question 
of trust.

For your final question about binding STUN authentication to the 
session. What I think is important is that one have to accept is that 
the cost must be possible to place on the one that creates the cost. 
Thus, the web service must be able to limit the usage of their STUN/TURN 
service to usage related to their service.

Cheers

Magnus Westerlund

Simon Perreault skrev den 2015-05-14 19:56:
> 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.
>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------