Subject: [tram] signature based 3rd party scheme

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Apr 2015 21:53:50 +0100

Hiya,

As part of my discuss [1] on draft-ietf-tram-turn-third-party-authz [2]
I questioned why the WG have only defined a shared secret based scheme
(with the secret between the TURN and WebRTC servers in that case). That
requires pre-arrangement between WebRTC servers and TURN servers, which
I think isn't always going to be easily done, and seems to me to assume
certain business models and to be more suited for larger providers (for
both servers) and less suited for what may well be a fairly substantial
long tail of WebRTC and TURN servers. Note that I am not saying that
the scheme from [2] is broken but that it has some properties that are
less desirable and the DISCUSS point is to ask if the WG had looked at
other possibilities. I'm told that the WG have not, so this mail is to
ask the question in more detail. (When this thread has run it's course,
or if the response to this is crickets, I'll clear that discuss point.)

I could envisage a signature based scheme, where the WebRTC server
digitally signs some form of token that the browser can then present
to the TURN server and that the TURN server can then validate (if it
wants to). That could provide accountability and be a sufficient
counter against abuse of the TURN server's bandwidth. I could actually
see lots of potential usage models that could be built on such a
scheme, some involving someone billing someone and others not. But
the main point is that the would be no a-priori need for co-ordination
between the TURN server and the WebRTC server ahead of time.

The above is obviously just a sketch and a real scheme derived from
that would not have otherwise identical properties to [2] but should
I think be something that could be used and more easily deployed than
the scheme from [2].

So - would such a scheme be attractive to the WG, and if so, then what's
the right course of action wrt [2]? (That could be to push [2] along and
start another draft on a signature based scheme, or to just push [2[
along, or something else.)

Thanks,
S.

PS: I'm not subscribed to this list, so would appreciate if you'd cc
me on responses.

[1]
https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ballot/#stephen-farrell
[2] https://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-15