Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS and COMMENT)

From: Alan Johnston <[email-masked]>
Date: Wed, 6 May 2015 10:57:24 -0500

Stephen,

The purpose of this extension is not gathering analytics to monetize
people's WebRTC usage.  It is all about solving some pressing
authentication issues in today's STUN and TURN usage, and we have running
code for both clients and servers today.  It's not productive to wait for some
other new authentication method to be finalized and perhaps deployed.  The
authors of the draft, and the implementors (browser and server) have
discussed the issues you raise, and below is our response.

The draft identifies 6 usages of STUN, and two are ruled out with a MUST
NOT (ICE and Media keepalives) and one is SHOULD NOT (SIP keepalives).  We
did this because we could not see a benefit of ORIGIN in those usages and
because of consideration of privacy concerns. Lets look at the other 3
usages of STUN that are described.

Consider the TURN usage.  The most important use case of ORIGIN is to help
the TURN server select the correct REALM for the authentication challenge.
I'm not aware of public TURN servers being common, unlike STUN servers.
TURN requires authentication (hence the need for REALMs), and the
credentials used identify at least the site if not the individual user of
the TURN service.  Hence, the ORIGIN information does not provide any
additional privacy-sensitive information to the TURN server.  However, for
cases where a TURN server perhaps accepts an anonymous login, or a login
that is shared among many sites, the presence of ORIGIN could leak privacy
information.  Section 7.3 of RFC 6454 says:

"  Whenever a user agent issues an HTTP request from a "privacy-
   sensitive" context, the user agent MUST send the value "null" in the
   Origin header field.

      NOTE: This document does not define the notion of a privacy-
      sensitive context.  Applications that generate HTTP requests can
      designate contexts as privacy-sensitive to impose restrictions on
      how user agents generate Origin header fields."

We had proposed also sending an empty ORIGIN attribute to be aligned with
the HTTP usage of Origin.  However, we could instead just omit the ORIGIN
attribute under the same conditions of a "privacy-sensitive" context.

We propose changing the start of Section 2.2:

OLD:

   When the origin is a web origin, TURN [RFC5766] Allocate requests
   MUST include the ORIGIN attribute.  For all other TURN requests,
   including the Send method, the use of the ORIGIN attribute is NOT
   RECOMMENDED.  For other origins, such as SIP or XMPP, TURN Allocate
   requests SHOULD include the ORIGIN attribute.

NEW:

   For all types of origins, TURN [RFC5766] Allocate requests
   SHOULD include the ORIGIN attribute,   All other TURN requests,
   including the Send method, SHOULD NOT include the ORIGIN attribute.
   In a "privacy-sensitive" context, the ORIGIN MUST NOT be included.

END

The STUN usage and NAT Discovery Usage are covered together, since they are
very similar.  As a cloud service, there are many operational reasons why
the operator of a STUN server will want to know what applications are using
it, just like for web services.  For dedicated applications, the STUN
SOFTWARE attribute (which is a SHOULD include in RFC 5389) provides
information about the client generating STUN requests to the STUN server
today. For WebRTC users, this will only tell which browser is using the
server.  Without Origin information, they don't know who is directing this
client to send traffic (perhaps errored or invalid traffic) to their STUN
server. With Origin, the STUN server operator can contact the operator of
the service and try to get them to fix their client, and failing that they
could drop these packets based on the Origin without having to process them
further or have these errant packets fill up their error logs.
Furthermore, real-world WebRTC applications will make use of both STUN and
TURN servers, and there is no good reason why they would be provided by
different service providers (since STUN is a subset of TURN). As such,
there does not seem to be a good reason to include origin in TURN, but
prohibit it from STUN. And if, for some reason, the web application
provider definitely does not want to disclose any information to its STUN
provider, it can simply set up its own STUN server (this is trivially
expensive).

We propose changing the first two paragraphs of 2.1 from

OLD:

   For STUN requests sent without authentication to a STUN server (i.e.

   STUN binding requests sent to a STUN server), the STUN client MUST

   include the ORIGIN attribute when the origin is a web origin.  For

   other origins, such as SIP or XMPP, the STUN client SHOULD include

   the ORIGIN attribute.

      Note that for privacy reasons, an empty ORIGIN attribute can be

      sent, as described in the Security Considerations.

NEW:

   For STUN requests sent without authentication to a STUN server (i.e.

   STUN binding requests sent to a STUN server), the STUN client SHOULD

   include the ORIGIN attribute.  The ORIGIN attribute MUST NOT be included

   if it is a "privacy-sensitive" context, as discussed in the Security
Considerations

   section.

END

Does this resolve your DISCUSS? The new text simplifies the extension by
not making behavior specific on the Origin type.  We could of course
replace the MUST NOT for privacy-sensitive contexts with EMPTY ORIGIN as
originally specified (for the consistency reason stated) but either meets
our objective and we have now proposed not sending for simplicity.

See below for answers on your COMMENTs.

- Alan -

On Tue, Apr 21, 2015 at 10:36 AM, Stephen Farrell <[email-masked]
> wrote:

> Stephen Farrell has entered the following ballot position for
> draft-ietf-tram-stun-origin-05: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
> "Analytics" here together with the MUST include
> statements could amount to a fancy way to
> describe monetizing people's WebRTC calls in ways
> that the end user will just not expect. I'd like
> to check that we're not doing that, as it'd
> arguably run counter to e.g. RFC7258 or to the
> general trend towards data minimisation. And
> making privacy worse, even by a little, seems
> worse than making it better. (Note: I am here
> asking about the STUN/TURN server being perhaps
> unnecessarily told the origin, not the risk that
> someone sees that in-transit, which is handled in
> the draft already.)
>
> I do agree that the TURN 401-like challenge
> use-case is perhaps needed, but I do not see that
> other use cases need to see the origin for them
> to work at all.  And I'm not sure that such a
> spoofable origin is so useful for that TURN case,
> esp. when there's parallel work on an
> authenticated equivalent. (I mean the tram 3rd
> party thing.) I also don't see that that is
> needed for network management reasons - surely
> everything needed for network managment is no
> more nor less visible to the STUN or TURN servers
> when this is used vs. when this is not used.
>
> So why are we pushing for this?  If it is really
> only for so-called "analytics" then is that ok?
> (And where can I find a definition of what that
> means?)
>
> Apologies if this discuss seems somewhat high
> level, but as well as the general concern, the
> last paragraph of the current tram charter seems
> to me to me to say that tram ought not make
> privacy worse. But maybe I'm missing the
> networking function that needs this - if so, I'm
> sure someone will point that out.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
>
> - intro, para 2: STUN only defines two auth modes
> that I can see, and you only mention two here -
> what's the 3rd one you mean? (Is it DTLS?)
>

No, the third mode is no authentication - that is the third method
described at the end of the paragraph.

>
> - What if >1 TURN session with different origins
> is being setup from same client/browser? Does
> that work? (Say two parallel calls, not the case
> where the same resource is being accessed at the
> same time loaded from different referring web
> pages.)
>

Yes, they are separate Peer Connections, but having the same ORIGIN won't
cause any problems.

>
> - I'd suggest to not allow >1 ORIGIN in a STUN
> request? But that discussion seems to be in-hand.
>

Right, that is the proposed resolution.

>
> - section 2: suggest providng similar examples
> for all schemes, http(s),sip & xmpp.
>

We could, although we very carefully define the syntax per the ABNF.

>
> - 2.1 & 2.2: MUST include web origin - couldn't
> there be "private browsing" scenarios where that
> MUST would be a problem? I'm not suggesting that
> the origin exposes very much but I think a SHOULD
> would be more appropriate.
>

See above rewrites of these paragraphs.

>
> - 2.1 last para: source here means the webrtc
> server right? That's a bit ambiguous and would be
> better clarified.
>

It means the http, sip, or xmpp URL.  We can clarify.

>
> - What is the benefit of sending an empty origin
> as opposed to no origin attribute? I don't see
> any and the former just advertises that the
> client is "privacy sensitive" which seems
> incongruous.
>
>
This is how HTTP Origin handles privacy situations, but we plan to change
it to omit the ORIGIN in these cases.  We can't think of anything that will
break if we do this.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 10 May 2015 12:50:52 +0100

Hi Alan,

Sorry for the slow response, was travelling...

On 06/05/15 16:57, Alan Johnston wrote:
> people's WebRTC usage.  

Good to hear. Does it have that side-effect though? If so, oughtn't
we think about that? And that still leaves me puzzled as to the
mentions of "analytics" in the draft, which at least in my understanding
of the term (admittedly not a very expert one) does involve using
information to make money however one can. So while it's good to hear
the above, my concerns are not fully assuaged.

> It is all about solving some pressing
> code for both clients and servers today.  

For me, a consequence of the above would be that the scheme must not
be trivially defeated by the browser telling lies. Otherwise you have
not solved any authentication issue at all.

> It's not productive to wait for some
> other new authentication method to be finalized and perhaps deployed.  

Hmm. Since both are tram WG drafts, I assume this was discussed on the
list. If so, can you point me at that thread. It seems odd to have two
schemes for one thing, esp. with such different properties, and yet to
not have the reasons for that being a good plan documented somewhere.
(And I'd be fine with that being in meeting minutes, mails or whatever.)

> The

BTW, I just re-read the draft and I do appreciate that the authors are
seriously considering privacy issues.

> the TURN server select the correct REALM for the authentication challenge.

Right. OTOH, one could also use the "user@realm" convention for the
username in an authentication in some cases, but I agree that has it's
downsides if it is forced into an existing authentication scheme. The
upside is that this information is only sent during and not before
authentication. Since we are in any case changing things, that may be
a better alternative. Were such ideas considered?

> attribute under the same conditions of a "privacy-sensitive" context.

I did make a comment about that, and clarifications such as that
below would be good, once we've landed the discussion someplace. Right
now, I'm not sure if this change is the right thing.

> it, just like for web services. 

Sure. The question for us is the extent to which we ought design the
protocol to essentially force the UA to send that given that we also
want to consider the privacy concerns of the people using these
services.

> For dedicated applications, the STUN

Contact based on an unauthenticated attribute? That has some downsides.

> Does this resolve your DISCUSS? 

Not yet. First, we need to talk about whether/when this information is
needed (which we're doing above, but we've not yet finished that
discussion). Second, but only really after that (so I suggest we don't
try to bottom out on this yet), I think saying privacy-sensitive is
really not that useful here. (I accept that it may be clear to each
browser implementer, but perhaps with different meanings?)

> The new text simplifies the extension by

Those all seem fine, or will be when we resolve the discuss.

Cheers,
S.

---

From: Simon Perreault <[email-masked]>
Date: Sun, 10 May 2015 13:19:53 -0400

A few comments as shepherd and as a person involved in TRAM since before
the first bar BoF...

> the above, my concerns are not fully assuaged.

The way to implement multi-tenant servers currently, without ORIGIN, is
to dedicate one IP address per tenant. This is a pain point for a number
of reasons you can imagine.

ORIGIN plays the same role as the Host header in HTTP: it allows virtual
hosting. I see the comparison with the Host header as more accurate than
with the Origin header. (One could also compare with the SNI extension
in TLS.)

Therefore, ORIGIN does not enable more analytics than current practice
(i.e., dedicating one IP address per tenant).

> not solved any authentication issue at all.

I don't follow. If the browser lies, then authentication will fail.
Where's the problem?

> (And I'd be fine with that being in meeting minutes, mails or whatever.)

As far as I can remember, WG participants have agreed that both ORIGIN
and third-party-auth were necessary. I don't remember a list discussion
about this. People running servers now need to solve the multi-tenant
problem with the current authentication scheme. Moving to
third-party-auth is not always possible especially for non-WebRTC uses.

As a concrete example, think of a multi-tenant server being used for
SIP. SIP clients could plausibly be modified to include the ORIGIN
attribute, but moving to third-party-auth is unthinkable.

> downsides if it is forced into an existing authentication scheme.

Yes, this is established practice as well, but not always possible, for
reasons you might guess. Dedicating one IP address per tenant is the
most generic and flexible workaround.

> authentication.

Dedicating one IP address per tenant is the same as ORIGIN on this
aspect: the information is sent before authentication.

> Since we are in any case changing things, that may be

Yes, most definitely. It is current practice, and it is a pain point.

Simon

---

From: Alan Johnston <[email-masked]>
Date: Mon, 11 May 2015 20:13:47 -0500

Stephen,

Thanks for your reply.  I agree with Simon on all points below.

Especially the point about what if the browser lies about the ORIGIN.  TURN
requires an authentication credential.  If you don't have this credential,
lying about ORIGIN doesn't help you in any way shape or form.

The workarounds and other solutions have been investigated, but the WG has
moved forward with ORIGIN, and there is running code to backup this
interest.

- Alan -

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 May 2015 02:19:14 +0100

Hi Alan,

> Thanks for your reply.  I agree with Simon on all points below.

Well yes and no. I don't doubt the IP-per-tenant setup he describes
nor the downsides of that.

I very much do doubt that the existence of bad-approach-X means that
the WG has to adopt an approach that is equally bad from the privacy
perspective.

> Does this resolve your DISCUSS?

Sorry no. I think this one requires some higher bandwidth (or more
extended;-) discussion. I'm sure we'll get there though.

S.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 11 May 2015 21:10:46 -0500

Dear all,

> extended;-) discussion. I'm sure we'll get there though.

Are we all talking about keeping the same information private from the same
entities? I'm not sure about that.

Thanks,

Spencer

---

From: Simon Perreault <[email-masked]>
Date: Tue, 12 May 2015 12:12:25 -0400

Le 2015-05-11 21:19, Stephen Farrell a écrit :
> extended;-) discussion.

So, uh, what is normal procedure in this case? Should we set up a
conference call?

Simon

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 May 2015 17:43:04 +0100

> So, uh, what is normal procedure in this case? Should we set up a

It'll be discussed on this Thursday's IESG telechat is the next
step. We may end up with some concall being needed, bit early to
say (I'd guess) but Spencer as responsible AD will drive that
along.

S.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 12 May 2015 14:06:03 -0500

Hi, Simon,

On Tue, May 12, 2015 at 11:43 AM, Stephen Farrell <[email-masked]

> say (I'd guess) but Spencer as responsible AD will drive that

Just to follow up on this ...

Stephen's correct, and Simon is invited as document shepherd in case a
high-bandwidth Q&A is still needed (of course, the rest of the world is
invited to attend as observers). That can allow probably five to ten
minutes of discussion on a single document.

If more discussion is needed, I would add it to the agenda for the informal
telechat scheduled the following Thursday, when we can spend more time.
It's possible to set up ad hoc conference calls, but that would require
doodle polls with busy people to schedule one, and the IESG already has
informal telechats on our calendars.

Having said that, e-mail is still a good thing, and the discussion that's
happening (now, I believe, on the thread under Allisa's Discuss) looks
promising. My suggestion is to make sure we all understand what the
information we're discussing is (the difference between ethereal RTCWeb
usernames and long-lived SIP usernames seems important), and who has to
know that information.

I hope that's helpful, of course.

SPencer

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 May 2015 11:58:35 +0100

> I don't follow. If the browser lies, then authentication will fail.

So let's say that a TURN server works on behalf of two
"tenant" services, S1 and S2 (legacy-SIP or WebRTC doesn't
matter for this point).

S1 are mean and charge the end user per byte/second and
when the TURN server is working on behalf of S1 then the
TURN server will do loads of accounting that'll eventually
turn into billing from S1 to the user at the UA.

S2 however are rich new Internet kids and offer calling
for nothing - they just use some of their vast advertising
revenue to pay the TURN server operator a big pile of cash
and the end user never has to pay, because S2 make money
elsewhere.

As a user, I can have accounts with both, and can authenticate
to the TURN server as either. (I'm not saying that is good
but it is what you've told me I think.)

I will of course always assert that the "origin" for all of
my calls is S2 and authenticate with those credentials, even
when I'm making a call that is setup by S1 and that properly
ought to be billed that way. (And such a call can be to a
destination that is simply not reachable via S2's signalling
of course.)

The fact that this origin is used by the TURN server to
pick between those and that there is no binding between
that and the in-progress call enables me to succeed when I
try the age-old trick of getting calls for nothing.

And similar issues will arise if there is any differentiation
between what the STUN/TURN server does for any of it's
multiple tenants. (Logically, that would seem to imply that
the TURN server has to offer the exact same service to all
tenants as a result of this protocol feature/flaw, which
would presumably de-value all multi-tenant features to the
extent they'd just die out. But then logic doesn't always
rule I guess:-)

Can you tell me what in the current proposal (or the underlying
context, and hence perhaps properly not documented here) means
that the above is a non-issue? Or where else am I going wrong?

Cheers,
S.

PS: It's obvious I guess, but this isn't directly about the
privacy aspects of the draft, though any solutions would impinge
on the discussion of the privacy aspects of the draft and hence
on this overall discussion.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 May 2015 12:21:05 -0400

Le 2015-05-13 06:58, Stephen Farrell a écrit :
> So let's say that a TURN server works on behalf of two "tenant" 
> services, S1 and S2 (legacy-SIP or WebRTC doesn't matter for this 
> point).
> 
> S1 are mean and charge the end user per byte/second and when the
> TURN server is working on behalf of S1 then the TURN server will do
> loads of accounting that'll eventually turn into billing from S1 to
> the user at the UA.
> 
> S2 however are rich new Internet kids and offer calling for nothing
> - they just use some of their vast advertising revenue to pay the
> TURN server operator a big pile of cash and the end user never has to
> pay, because S2 make money elsewhere.
> 
> As a user, I can have accounts with both, and can authenticate to
> the TURN server as either. (I'm not saying that is good but it is
> what you've told me I think.)
> 
> I will of course always assert that the "origin" for all of my calls 
> is S2 and authenticate with those credentials, even when I'm making a
> call that is setup by S1 and that properly ought to be billed that 
> way. (And such a call can be to a destination that is simply not 
> reachable via S2's signalling of course.)
> 
> The fact that this origin is used by the TURN server to pick between 
> those and that there is no binding between that and the in-progress 
> call enables me to succeed when I try the age-old trick of getting 
> calls for nothing.

Correct.

However, imagine the same situation with current STUN authentication
(i.e., no ORIGIN, no third-party-auth). You have an account on each of
S1's and S2's servers, each of which listen on different IP addresses.
You can still use S2's server for a call signalled using S1's servers.

What makes this possible is that STUN authentication has no binding with
call signalling. ORIGIN does not attempt to change this.

> context, and hence perhaps properly not documented here) means that 
> the above is a non-issue? Or where else am I going wrong?

STUN/TURN is by design a stand-alone NAT traversal service. An important
design principle is that the endpoints are responsible for their own NAT
traversal. Contrast this to hosted NAT traversal [RFC7362].

That is, endpoints using a generic RFC 3261 SIP proxy as signalling
server can use ICE with STUN/TURN servers of their choosing to establish
a peer-to-peer session. The SIP proxy does not need to be aware of any
of this. By design, the STUN/TURN server has a relationship with the
endpoint, not with the signalling infrastructure.

With WebRTC, the typical deployment model has the application provider
in charge of signalling, endpoint provisioning, and STUN/TURN server
operations This particular model makes a binding between signalling and
STUN authentication a possibility.

However, in general, by design, STUN/TURN is a client-server protocol,
and has nothing to do with signalling. Therefore, when a client has an
account with a server, it can use it with whatever signalling it wants.
The server is not aware of this. By design.

Simon