[tram] signature based 3rd party scheme

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 28 April 2015 20:56 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653941A8A06 for <tram@ietfa.amsl.com>; Tue, 28 Apr 2015 13:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3uxV9xmVJmi for <tram@ietfa.amsl.com>; Tue, 28 Apr 2015 13:56:16 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8481A8942 for <tram@ietf.org>; Tue, 28 Apr 2015 13:53:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 73124BE35 for <tram@ietf.org>; Tue, 28 Apr 2015 21:53:52 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8HC0pBbzhQs for <tram@ietf.org>; Tue, 28 Apr 2015 21:53:51 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.42.29.198]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D22B6BDCC for <tram@ietf.org>; Tue, 28 Apr 2015 21:53:50 +0100 (IST)
Message-ID: <553FF35E.4030203@cs.tcd.ie>
Date: Tue, 28 Apr 2015 21:53:50 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "tram@ietf.org" <tram@ietf.org>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tram/tik9Rq0aIdCYzbhme2kw12ijCok>
Subject: [tram] signature based 3rd party scheme
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Apr 2015 20:56:21 -0000

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