[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
- [tram] signature based 3rd party scheme Stephen Farrell
- Re: [tram] signature based 3rd party scheme Tirumaleswar Reddy (tireddy)
- Re: [tram] signature based 3rd party scheme Stephen Farrell
- Re: [tram] signature based 3rd party scheme Tirumaleswar Reddy (tireddy)
- Re: [tram] signature based 3rd party scheme Stephen Farrell
- Re: [tram] signature based 3rd party scheme Tirumaleswar Reddy (tireddy)
- Re: [tram] signature based 3rd party scheme Stephen Farrell
- Re: [tram] signature based 3rd party scheme Tirumaleswar Reddy (tireddy)
- Re: [tram] signature based 3rd party scheme Stephen Farrell
- Re: [tram] signature based 3rd party scheme Tirumaleswar Reddy (tireddy)
- Re: [tram] signature based 3rd party scheme Brandon Williams