Re: [tram] signature based 3rd party scheme

Brandon Williams <brandon.williams@akamai.com> Tue, 12 May 2015 13:43 UTC

Return-Path: <brandon.williams@akamai.com>
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 C2F9B1B2D03 for <tram@ietfa.amsl.com>; Tue, 12 May 2015 06:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 YBKVz7KQUrlm for <tram@ietfa.amsl.com>; Tue, 12 May 2015 06:43:01 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 301FC1B2D02 for <tram@ietf.org>; Tue, 12 May 2015 06:43:01 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 65AC128648; Tue, 12 May 2015 13:43:00 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 4498128611; Tue, 12 May 2015 13:43:00 +0000 (GMT)
Received: from [172.28.115.142] (unknown [172.28.115.142]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 3FF3F80044; Tue, 12 May 2015 13:43:00 +0000 (GMT)
Message-ID: <55520364.4060209@akamai.com>
Date: Tue, 12 May 2015 09:43:00 -0400
From: Brandon Williams <brandon.williams@akamai.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "tram@ietf.org" <tram@ietf.org>
References: <913383AAA69FF945B8F946018B75898A47821E90@xmb-rcd-x10.cisco.com> <55409F56.3090003@cs.tcd.ie> <913383AAA69FF945B8F946018B75898A47822B94@xmb-rcd-x10.cisco.com> <55422C68.8010505@cs.tcd.ie> <913383AAA69FF945B8F946018B75898A47822E1B@xmb-rcd-x10.cisco.com> <55425B69.6080008@cs.tcd.ie> <913383AAA69FF945B8F946018B75898A47823028@xmb-rcd-x10.cisco.com> <55426126.9020605@cs.tcd.ie> <913383AAA69FF945B8F946018B75898A4782322D@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A4782322D@xmb-rcd-x10.cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tram/yk0a2UJ7JwkkcZstG1QWhu1WmxE>
Subject: Re: [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, 12 May 2015 13:43:07 -0000

Picking this up again ...

I think that part of the disconnect here is that we're discussing 
authentication of two different parties (the user and the WebRTC server) 
as if they were the same entity. I think it's possible for the TURN 
service to have in interest in authenticating each of these independently.

For example, I can see the possibility of a TURN server being made 
available to authorized users but only for a set of specific 
pre-approved services where the owner of the TURN server and the owner 
of the WebRTC server(s) have no pre-arranged relationship. In this case, 
it would be desirable for the TURN server to be able to authenticate 
both the user and the WebRTC server, but the two authentications would 
be distinct, since being an authorized user of the WebRTC service is not 
enough to allow access to the TURN server. In this case, Stephen's 
suggested signature based authentication of the WebRTC server would be 
useful, while user-level authentication would be handled via one of the 
other methods.

Additionally, I can see the possibility that such a TURN server is 
deployed in such a way that the owner does not require any user-level 
authentication at all. For example, an ISP might offer such a service to 
its end users and might not consider it valuable to require user-level 
authentication for the relay since it already has per-subscriber 
authentication of some sort for access to its network. IOW, there is a 
desire to authenticate the WebRTC server but no corresponding desire to 
explicitly authenticate the user.

If this is the requirement set, and especially (though not only) if DTLS 
is in use for the client-to-TURN connection, signature based 
authentication of the WebRTC server would be the only required TURN 
authentication for the session.

--Brandon

On 04/30/2015 11:56 PM, Tirumaleswar Reddy (tireddy) wrote:
>> -----Original Message-----
>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>> Sent: Thursday, April 30, 2015 10:37 PM
>> To: Tirumaleswar Reddy (tireddy); tram@ietf.org
>> Subject: Re: [tram] signature based 3rd party scheme
>>
>>
>>
>> On 30/04/15 17:58, Tirumaleswar Reddy (tireddy) wrote:
>>>>>
>>>>> Indeed, if the current draft were the only way to do this then all
>>>>> enterprises would have to pre-arrange things with all WebRTC servers.
>>> No, pre-arrangement is not required with all WebRTC servers.
>>
>> Sorry, how?
>
> It is discussed in http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-15#section-6.1. If WebRTC server has pre-arrangement with the Enterprise network then client uses third party authorization with the TURN server in Enterprise network and when WebRTC server(s) do not have any pre-arrangement with the Enterprise network then the client uses first party authentication with the TURN server.
>
> -Tiru
>
>>
>> S.
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.