Subject: Re: [tram] stun-origin status==? Is it dead?
From: Harald Alvestrand <[email-masked]>
To: Jonathan Lennox <[email-masked]>
Cc: Oleg Moskalenko <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,Mészáros Mihály <[email-masked]>, Simon Perreault <[email-masked]>, "[email-masked]" <[email-masked]>, Alan Johnston <[email-masked]>
Date: Thu, 19 Jan 2017 17:56:53 +0100
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>

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.
>
> 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:
> >
> > 2017-01-18 23:21 keltezéssel, Simon Perreault írta:
> >> Le 2017-01-18 à 07:48, Mészáros Mihály a écrit :
> >>> Do you know any alternatives/workaround to use TURN server with
> multiple
> >>> realms?
> >> OAuth does the trick.
> >> 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
> >
> > _______________________________________________
> > tram mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tram
> >
>
>