Subject: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS)

From: "Alissa Cooper" <[email-masked]>
Date: Mon, 11 May 2015 16:30:12 -0700

Alissa Cooper 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a bit of a weird DISCUSS since I didn't manage to ballot when the
document was first on the IESG's agenda, so I'm coming in mid-stream.

I support Stephen's DISCUSS. If Alan's proposed changes make it into the
document, they would resolve most of my concerns. However, I still see a
problem with this proposed new text:

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

For requests sent with authentication, I understand that the origin
attribute needs to be accurate in order for the client to authenticate.
In those cases, the STUN server can rely on the attribute it receives.
But for requests without authentication, what prevents the client from
lying? And if those requests are not (D)TLS-protected, what prevents them
from being modified in transit? I understand Alan to be saying that the
justification for the origin in this case is operational troubleshooting,
but if the server can't rely on the origin it receives, doesn't that make
it risky for the server to act on that information?

My additional concern is about the use of "logging" as a justification
for including and origin attribute. Logging in and of itself is not a
reasonable justification. Alan's mail discussed the use of the origin for
operational troubleshooting, which seems like what might actually be
intended instead of "logging." In any event the purpose for the logging
either needs to be explained or "logging" should not be listed as a
justification.

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 11 May 2015 16:45:03 -0700

On Mon, May 11, 2015 at 4:30 PM, Alissa Cooper <[email-masked]> wrote:
> lying?

if the client is lying, then the request will not be authenticated and
it will be rejected - because the client's credentials will be
incorrect. I see that many people cannot grasp that very simple
concept. There is no benefits in lying in this case. Think about
ORIGIN as simply a logical virtual database name where the user
account will be searched and against that database the credentials
will be verified. This information is not sensitive, and lying is not
giving you any unjust benefits. The only outcome that you can achieve
by lying is screwing your own request - that's it.

> And if those requests are not (D)TLS-protected, what prevents them

No, as I explained above.

> reasonable justification.

Why ?

> Alan's mail discussed the use of the origin for

Why ?

>
>
>
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 11 May 2015 17:43:53 -0700

Hi Oleg,

On May 11, 2015, at 4:45 PM, Oleg Moskalenko <[email-masked]> wrote:

> incorrect.

My question was about requests without authentication, as I said. I assume the origin is not used for authentication in that case, since authentication is not performed.

> I see that many people cannot grasp that very simple
> concept.

I would appreciate if you would use a more respectful tone in the future.

Thanks,
Alissa

> There is no benefits in lying in this case. Think about

---

From: "Yoakum, John H (John)" <[email-masked]>
Date: Tue, 12 May 2015 01:04:15 +0000

There seems to be some questions around why things like logging and administrative debugging are useful and possibly some of it is a matter of context.  Inside enterprises it is very common to have a variety of logging capabilities across all parts of a system or solution as well as to perform debugging activities based on whatever combinations of insight are available whenever problems occur.  

With WebRTC is will be very common to find TURN servers run by enterprises to serve various enterprise-centric websites that desire real-time communications as part of the enterprise web experience for people from outside the enterprise who may be external parties or in many use cases may actually be enterprise employees.  ORIGN tells a STUN or TURN server what realm is associated with the request.  That piece of knowledge is already well known by the browser making the request (except in the privacy-sensitive situations accommodated in the draft, which will seldom be the case for employees of an enterprises) and is highly useful to enterprises who have web services and related communications enablement gear like STUN and TURN servers necessary to allow employees access from home, virtual offices, or while traveling (without the need for VPNs or other specialized network connections).  Large enterprises often have multiple applications, multiple domains or subdomains, and multiple realms.  This simple extension to STUN to conveys insight related to the web applications using communications ennoblements like STUN and TURN servers will find many uses inside enterprises.

ORIGIN is not a substitute for more accurate authentication, it is a way to quickly determine the best authentication to attempt as well as to quickly filter out things where authentication attempts or other processing (even simple STUN requests) are a waste of resources as that realm will never be serviced anyway.

In terms of troubleshooting, within an enterprise it is highly useful to look at insight from all the parts of a solution and identify inconsistences.  As an example if it is discovered while debugging a communications failure that a browser inside an enterprise is lying about ORIGIN it may help in uncovering that the browser has been compromised by malware.  Enterprises can never have too much insight in their logs for short periods of time as that is what they rely on to debug sophisticated systems.  Just as importantly log data is often used to judge system usage to help justify investing in additional resources or spread costs to the applications or departments involved.

Is any of this enterprise perspective helpful or just adding to the confusion?  One of the great promises of WebRTC is to allow simpler systems without all the complicated telephony approaches from the past and capitalizing on simple web-centric concepts like ORIGIN is one great enabler.  This draft even extends these more modern concepts to things like SIP to help simplify some of the more conventional technologies.

Cheers,
John

AVAYA
1.919.425.8446 

-----Original Message-----
From: Alissa Cooper [mailto:[email-masked]] 
Sent: Monday, May 11, 2015 7:30 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with 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 https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=AwICaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=O4OIzAW7EVPxOEhYXzj7Eg&m=UUw6tlPYwiPTqTiPb-8d0JzXAshUyyMqbEveZ1APHyg&s=7-Ky3gBkj-nh5lszKh8A2T5LKV9tUum5QpJKbNUFUeM&e=
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtram-2Dstun-2Dorigin_&d=AwICaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=O4OIzAW7EVPxOEhYXzj7Eg&m=UUw6tlPYwiPTqTiPb-8d0JzXAshUyyMqbEveZ1APHyg&s=qyAN_jyGYafpPgJ3Hxg9bybo3UDOUHoCxUU2CZhcpmQ&e= 

   section."

---

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

Hiya,

On 12/05/15 01:43, Alissa Cooper wrote:
>>> 
>>> if the client is lying, then the request will not be
>>> authenticated and it will be rejected - because the client's
>>> credentials will be incorrect.
>
> My question was about requests without authentication, as I said. I
> assume the origin is not used for authentication in that case, since
> authentication is not performed.
>

There's also this issue. If user credentials can collide over >1
"realm" (where authentication realm means in the HTTP basic/digest
sense) then those are almost certainly human memorable (why else
could they collide with non-negligible probability?) and in the
case of STUN/TURN and, in particular, WebRTC, setting up to use
human memorable credentials is just basically broken given that
the humans aren't actually logging in to the STUN/TURN server.

So I actually doubt the supposed security benefit even when the
web-origin is pre-emptively sent as an authentication realm (in
the HTTP basic/digest sense) just in case authentication with a
STUN/TURN server is later required. And pre-emptively sending
has the privacy downside that is recognised in the draft and
as previously noted.

Put another way: if a WebRTC server cannot arrange to use high
entropy credentials with a STUN/TURN server then perhaps we're
just promoting the wrong authentication scheme(s) and maybe
also prioritising avoiding the wrong code changes? (Some code
change being required in all cases.)

So if there is a real reason why there ought be a well designed
scheme for WebRTC with a non-negligible probability of credential
collision then I'd like to hear about it. (I'm not saying that's
impossible, but dumb old me can't figure it out;-)

Or perhaps we're conflating user authentication with other
protocol features (e.g. multi-tenant support) in a way that does
unnecessarily damage privacy for users?

S.

---

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

> the humans aren't actually logging in to the STUN/TURN server.

In the case where a single entity controls the authentication databases
for all tenants of a single server, you're right. However, that
condition does not hold in general. That is, we really do need to
properly handle username collisions across realms.

That is a pain point that is currently being handled with a number of
operational hacks. Clever username generation is one of them. It does
work for some use cases, but not in general.

What you're describing is current practice, and we don't like it.

I'd appreciate if we could recognize that there is a problem with
current practice, and actually discuss the merits of the ORIGIN
solution. I understand the privacy concerns, but I don't get two things:

1) Are those concerns identical or different from those applying to,
e.g., the Host HTTP header, or the SNI TLS extension? If they're
different, how are they different?

2) Is there a proposal that could fix the privacy issue? So far I've
seen IESG members pointing out the issue, authors acknowledging the
issue, but no discussion of solutions.

Simon

---

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

> But for requests without authentication, what prevents the client from

Note that the client does not know in advance whether its request is
going to be authenticated or not. Although I supposes it could try to
guess, or maybe re-try the request without lying when it receives an
authentication challenge.

> from being modified in transit?

Nothing. Per STUN design. Unauthenticated requests cannot be trusted.
The server operator can require authentication if trust is a problem.

> I understand Alan to be saying that the

Note that this concern applies to all other pieces of information
contained in unauthenticated STUN requests.

Simon

---

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

> properly handle username collisions across realms.

Sorry, I'm really not getting that. It is not a name for
a person, at least in WebRTC, right? It is some name
agreed between the WebRTC JS code and the TURN server. And
I'd hope it ought change frequently if it matters at all
or else it'll be scraped from the JS (or debug tooling).

> current practice, 

I believe I did that already.

> and actually discuss the merits of the ORIGIN

They may or may not be different but doing something better also
may or may not be more tractable. And the world has changed since
e.g. SNI was defined. (There is also desire to hide SNI in the
TLS 1.3 handshake if possible. We don't know if it will be possible
or not but the desire is there and is real.)

>From my POV, that is the discussion we are having and that is not
yet done.

S.

---

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

> or else it'll be scraped from the JS (or debug tooling).

What you say is true for WebRTC. A REST API for obtaining ephemeral
usernames was even proposed:
https://tools.ietf.org/html/draft-uberti-behave-turn-rest-00

For SIP, however, usernames are not ephemeral, are not easily changed,
and, depending on what client provisioning allows, are often constrained
to be identical to the SIP username, while the realm is often
constrained to be identical to the SIP domain name. WebRTC front-ends to
SIP infrastructure could also have the same constraints.

> I believe I did that already.

Sorry, I understood your last email as suggesting that username hacks
made ORIGIN unnecessary.

> or not but the desire is there and is real.)

I'm all for discussing something better, but at the moment I don't know
what that could be... Maybe it is obvious to security folks, but it is
not to me!

> From my POV, that is the discussion we are having and that is not

Ok, I'm happy to continue then! :)

Simon

---

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

> SIP infrastructure could also have the same constraints.

Hmm. Wouldn't addressing that issue (same protocol field is
sometimes based on human memorable secrets and sometimes
now) have been a fine thing for the tram wg to have done. Is
that being addressed by the WG, other than via the oauth
approach?

S.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 May 2015 10:04:50 -0400

> that being addressed by the WG, other than via the oauth

It's not.

Simon

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 14 May 2015 06:48:08 -0700

If some of this context could be added to the draft, I think that would be much better than just saying "logging and analytics."

Thanks,
Alissa

> On May 11, 2015, at 6:04 PM, Yoakum, John H (John) <[email-masked]> wrote:
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 14 May 2015 10:55:34 -0500

Dear TRAMsters,

Thanks to everyone who has helped with IESG evaluation for this draft so
far.

We had a nice conversation on today's formal telechat about this document,
and I summarized the state of play as

--- BEGIN

Barry's Discuss has been resolved

Ben's Discuss has been resolved

Benoit forwarded the OPSDIR review that hadn't gotten where it needed to
go, and it will be handled

The Gen-ART review will be handled

Stephen's Discuss had a few parts

- what "analytics" are we talking about here? I think the answer was "for
network operation and debugging". This was also in Alissa's Discuss, but
she was OK with adding text to explain that. Origin was intended to be the
equivalent of Host in HTTP, and the analytic impact is no worse than one IP
address per realm, which is what's used today.

- this also touched on "MUST NOT send Origin if it's privacy-sensitive, but
Stephen didn't think that was the right answer

- Stephen also asked why Origin and third-party-auth were both needed. The
answer was that SIP would require a lot of changes to use third-party-auth.

Alissa's Discuss had a few parts, and Stephen included a couple of
additional questions in her ballot thread.

- what kinds of things needed to be logged, and what the privacy
implications were

- whether unauthenticated requests could be twiddled with. The answer is
that they can be, so you should require authentication if you care.

- Stephen included a question about unique usernames across realms

- Stephen included a question about a client with a username in more than
one realm  playing games with which username it submits to avoid charging.
I thought the answer was that anyone charging would be doing it off either
signaling or media and not off STUN, but Simon corrected me that charging
for operators who only provide TURN servers would be in scope, so it's
still an open question. This was also in Stephen's Discuss thread, on
"lying",

- Stephen included a question about user-memorable usernames being
long-lived, and tied to an identity. The answer was that this is not true
for RTCWeb, but was true for SIP.

--- END

After chatting on the call, here's what I think needs to happen.

There are relatively minor comments and questions, most of which have been
answered, but there are a couple of large and more intertwined questions
that the IESG needs help with, especially in understanding the relationship
between Origin and third-party-authz, and how long-lived usernames (in SIP)
versus short-lived or even ephemeral usernames (which are possible in
RTCWeb) work in the same protocol mechanism.

The IESG has regularly-scheduled "informal telechats" every two weeks, to
work through questions like this. It would be helpful for Simon (as
document shepherd) and any authors who should participate to attend one, so
we can work through the high-order questions.

The next informal telechat is next week, May 21, at 10 AM EDT. The
coordinates are

https://workgreen.webex.com/workgreen/j.php?MTID=m305722fec48b24d34908d4074b6f0bbe
Meeting number: 826 345 248
Meeting password: 1234

If you'd like to take the opportunity to have that conversation, please let
me know, and I'll add draft-ietf-tram-stun-origin to the agenda.

Thanks for all your work to date, and we'll get through the questions.

Spencer

---

From: Alan Johnston <[email-masked]>
Date: Thu, 14 May 2015 11:08:47 -0500

Thanks, Spencer.  I think this is a very good path forward. I will join
next week's call.

- Alan -

On Thu, May 14, 2015 at 10:55 AM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> - this also touched on "MUST NOT send Origin if it's privacy-sensitive,
> but Stephen didn't think that was the right answer
>
> If you'd like to take the opportunity to have that conversation, please
> let me know, and I'll add draft-ietf-tram-stun-origin to the agenda.
>