Subject: [tram] stun-origin status==? Is it dead?

From: Mészáros Mihály <[email-masked]>
Date: Wed, 18 Jan 2017 12:45:26 +0100

Hi,

I am planning to build a multi realm TURN service that would use multi
realm feature in coturn.

But I sadly realized that there was some for me not very clear IETF
concerns and somehow writing draft-ietf-tram-stun-origin has been stopped..

I am wondering what is the WG position about this draft status and future?

I need this multi domain to avoid server duplication:

  * I need to use multi realm to reuse TURN servers and separate user
    credential domains, to avoid TURN server duplication for every realm
    in every region.
  * If this origin way could not be fixed then then I don't see any way
    to make a multi realm TURN service.
    (coTURN name is based on this feature AFAIK.)
  * If we don't send any information from client side that could be use
    on coTURN side to identify user credential realm than coTRUN
    multidomain feature could not be used at all.. :(

I am wondering if you know what was the main concern about in IESG/IETF
tram?

And if this is final or not? Could it be somehow work it out?

Why is it a show stopper concern?

Is it possible to make any workaround to make it possible to send any
realm related info to to turn server ?

I read the connected tram list mails and the ballot
<https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ballot/>,
but still not clear for me the main concern, and the actual status.

(The hardest concern was I think Stephen Farrell concerns, but I feel it
could be addressed.)

Unfortunately I saw all WebRTC browsers stopped implementing it.

  * https://bugzilla.mozilla.org/show_bug.cgi?id=1123722
  * https://bugs.chromium.org/p/webrtc/issues/detail?id=4091#c10

All in all I would like to know the reasons behind Justin statement:

This feature is dead. We should plan to remove the code when convenient.

I would like to turn it back if possible and find a way to make multi
realm TURN work.

Any comments would be highly appreciated!

Thanks,
Misi

---

From: Alan Johnston <[email-masked]>
Date: Wed, 18 Jan 2017 05:39:52 -0800

Hi Misi,

Yes, it is dead.  While the mechanism is convenient, it leaks too much
meta-data so the working group abandoned the effort.

- Alan -

On Wed, Jan 18, 2017 at 3:45 AM, Mészáros Mihály <[email-masked]> wrote:

>    - I need to use multi realm to reuse TURN servers and separate user
>    credential domains, to avoid TURN server duplication for every realm in
>    every region.
>    - If this origin way could not be fixed then then I don't see any way
>    - If we don't send any information from client side that could be use
>    on coTURN side to identify user credential realm than coTRUN multidomain
>    feature could not be used at all.. :(
>
>    - https://bugzilla.mozilla.org/show_bug.cgi?id=1123722
>    - https://bugs.chromium.org/p/webrtc/issues/detail?id=4091#c10
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>
>

---

From: Mészáros Mihály <[email-masked]>
Date: Wed, 18 Jan 2017 15:48:56 +0100

Hi Alan et al.

Many thanks for your fast reply!

Do you know any alternatives/workaround to use TURN server with multiple
realms?

What if a client sends in the first STUN request the preferred realm
(which the client's username/credential belongs to) instead of the web
origin?
(In practice the Web ORIGIN is almost useless AFAIU for the TURN server,
it is only used to map it to a realm.)

Add a new attribute in STUN, e.g. "PREFERRED_REALM"

So instead of sending origin, what if we add a new STUN attribute with
the preferred REALM and so, if the client adds it to the first STUN
request then the STUN/TURN server use this realm (instead of default
realm) during the response with the nonce?

(and may add a new optional attribute "realm" in stun/turn credential in
WebRTC STUN/TURN iceServer to indicate for TURN server which realm the
user credential belongs to.)

This hopefully address the origin based too much info leakage.

Could be the idea above a possible acceptable workaround way forward to
continue work on multi domain turn?

Any alternatives?

What are Your thoughts?

Thx,
Misi

2017-01-18 14:39 keltezéssel, Alan Johnston írta:
> On Wed, Jan 18, 2017 at 3:45 AM, Mészáros Mihály <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     I am planning to build a multi realm TURN service that would use
>     multi realm feature in coturn.
>
>     But I sadly realized that there was some for me not very clear
>     IETF concerns and somehow writing draft-ietf-tram-stun-origin has
>     been stopped..
>
>       * I need to use multi realm to reuse TURN servers and separate
>         user credential domains, to avoid TURN server duplication for
>         every realm in every region.
>       * If this origin way could not be fixed then then I don't see
>         any way to make a multi realm TURN service.
>       * If we don't send any information from client side that could
>         be use on coTURN side to identify user credential realm than
>         coTRUN multidomain feature could not be used at all.. :(
>
>     I am wondering if you know what was the main concern about in
>     IESG/IETF tram?
>
>     Is it possible to make any workaround to make it possible to send
>     any realm related info to to turn server ?
>
>     (The hardest concern was I think Stephen Farrell concerns, but I
>     feel it could be addressed.)
>
>         <https://bugzilla.mozilla.org/show_bug.cgi?id=1123722>
>         <https://bugs.chromium.org/p/webrtc/issues/detail?id=4091#c10>
>
>     I would like to turn it back if possible and find a way to make
>     multi realm TURN work.
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tram>
>
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 18 Jan 2017 15:21:41 -0700

> Do you know any alternatives/workaround to use TURN server with multiple

OAuth does the trick.
https://tools.ietf.org/html/rfc7635

-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | +1 418 478 0989 ext. 1241 | [email-masked]

---

From: Mészáros Mihály <[email-masked]>
Date: Thu, 19 Jan 2017 09:20:47 +0100

> https://tools.ietf.org/html/rfc7635
Hello Simon,

Despite You are right multiple Auth Server could use with one TURN
server, but on the wire even in OAuth case, STUN/TURN still use TURN
server default realm with the mac_key.

And may some TURN server client would like to have a fully customized
realm according their own domain and hide the TURN service provider "realm".
So even in case of OAuth it could have benefit to find solution to
mutlidomain TURN.

But the main point that unfortunately OAuth is not implemented and used
in real world actually AFAIK.
Furthermore even in STUN-bis I could see that the LTC password auth is
still exists. And this way if I understand it correctly the
username+password auth will not fade out very soon.

All in all, I still feel the need to find a solution for multidomain TURN.
I need your help: Would it be possible to work according my idea that
(almost) address the concern that raised against ORIGIN. So stun client
could send his preferred_realm and TURN server could decide if it
handles such realm then replaces default realm with the one the user has
preferred/requested?

Do you see any weakens problem with this idea?

Thx,
Misi

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 19 Jan 2017 16:43:32 +0000

The other proposal that was made to replace the ORIGIN attribute was a HOST attribute — this would be a way for a STUN / TURN client to send the DNS name it used to lookup the server, and thus do virtual hosting more directly.  This would have similar security properties to SNI in TLS.  It would allow virtual hosting, without exposing nearly as much information as ORIGIN would.

However, I don’t know if anything ever came of this.

Of course, if you’re using TURN over TLS or DTLS, the TLS SNI field itself will also allow you to do virtual hosting.

> On Jan 19, 2017, at 3:20 AM, Mészáros Mihály <[email-masked]> wrote:
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 19 Jan 2017 17:56:53 +0100

I think we need to have a writeup on:

1) What it's legitimate for the STUN service provider to learn about the
user
2) What it's NOT legitimate for the STUN service provider to learn about
the user

Possibly scoped by scenario.
Usually, if something dies because "it's a privacy violation", we can't get
any further without some privacy analysis.

On Thu, Jan 19, 2017 at 5:43 PM, Jonathan Lennox <[email-masked]> wrote:

> The other proposal that was made to replace the ORIGIN attribute was a
> HOST attribute — this would be a way for a STUN / TURN client to send the
> DNS name it used to lookup the server, and thus do virtual hosting more
> directly.  This would have similar security properties to SNI in TLS.  It
> would allow virtual hosting, without exposing nearly as much information as
> ORIGIN would.
>
> Of course, if you’re using TURN over TLS or DTLS, the TLS SNI field itself
> will also allow you to do virtual hosting.
>

---

From: Mészáros Mihály <[email-masked]>
Date: Fri, 20 Jan 2017 15:07:10 +0100

STUN RFC5389 <https://tools.ietf.org/html/rfc5389#section-15.7>  REALM
definition links back to RFC3261.

And RFC3261 in section 22.1 States "The realm string alone defines the
protection domain."

So it is not mandatory that it is connected to the TURN server host FQDN.
(It is NOT a MUST to set REALM equivalent to TURN server FQDN or domain
name.)

On multi domain TURN server case the TURN server already has info about
which user belongs to which realm.
The realm,username,HA1(password) information is in the backend userdb,
and this way client do not reveal any new information that the TURN
server not knows already...

So I still think that sending a new STUN attribute in first request e.g.
"preferred_realm" and replace server "default_realm from that point
could be a solution and a way forward.
Do you agree, or do have you any concerns?

Thx,
Misi

2017-01-19 17:56 keltezéssel, Harald Alvestrand írta:
> 1) What it's legitimate for the STUN service provider to learn about
> the user
> 2) What it's NOT legitimate for the STUN service provider to learn
> about the user
>
> Usually, if something dies because "it's a privacy violation", we
> can't get any further without some privacy analysis.
>
>
> On Thu, Jan 19, 2017 at 5:43 PM, Jonathan Lennox <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     The other proposal that was made to replace the ORIGIN attribute
>     was a HOST attribute — this would be a way for a STUN / TURN
>     client to send the DNS name it used to lookup the server, and thus
>     do virtual hosting more directly.  This would have similar
>     security properties to SNI in TLS.  It would allow virtual
>     hosting, without exposing nearly as much information as ORIGIN would.
>
>     Of course, if you’re using TURN over TLS or DTLS, the TLS SNI
>     field itself will also allow you to do virtual hosting.
>
>     > On Jan 19, 2017, at 3:20 AM, Mészáros Mihály <[email-masked]
>     <https://tools.ietf.org/html/rfc7635>
>     >>
>     > Hello Simon,
>     >