Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-party-authz-15: (with DISCUSS and COMMENT)

Brandon Williams <brandon.williams@akamai.com> Tue, 12 May 2015 17:31 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 5DFF81ACDA7; Tue, 12 May 2015 10:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 6nWKzLqns4Xl; Tue, 12 May 2015 10:31:04 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD9B1ACDB7; Tue, 12 May 2015 10:31:02 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id EADDD47D58; Tue, 12 May 2015 17:31:01 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A5A6F47E1F; Tue, 12 May 2015 17:31:01 +0000 (GMT)
Received: from [172.28.115.142] (bowill.kendall.corp.akamai.com [172.28.115.142]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id A1B06204C; Tue, 12 May 2015 17:31:01 +0000 (GMT)
Message-ID: <555238D5.7050109@akamai.com>
Date: Tue, 12 May 2015 13:31:01 -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: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <20150428212204.9453.5930.idtracker@ietfa.amsl.com> <D1667313.5436C%praspati@cisco.com> <554142C5.6030505@cs.tcd.ie> <CALDtMrJFBJKL-chgCF48N2vP9uM3s07zST2kLT_yUrXRFiJoJg@mail.gmail.com> <5541DDF6.7000205@cs.tcd.ie> <CALDtMrLZLBLS2MH1QYKx9BraJvdgGqtr67fCNDeS9jUX_GV5Qg@mail.gmail.com> <5541E966.80602@cs.tcd.ie> <913383AAA69FF945B8F946018B75898A4782328F@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A4782328F@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/O_HsefXyJsR-2nFwMvgwJAZ_vPc>
Cc: "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" <draft-ietf-tram-turn-third-party-authz.ad@ietf.org>, "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" <draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org>, "tram@ietf.org" <tram@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-party-authz-15: (with DISCUSS and COMMENT)
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 17:31:06 -0000

Resending with a condensed recipient list that will hopefully still get 
to the same set of people and be accepted by the tram list. Sorry for 
the duplicate message to those who got it already.

---

I can see the value of a MTI for interop. It would be good for any relay 
service to be able to on-board new customers without requiring 
development effort on the part of either the relay service provider or 
the customers, and a MTI would make that more likely to be the case.

That said, I'm not convinced that we've identified a suitable MTI 
method, and no one has yet been able to point me at a suitable method in 
use in a similar context. Also, as Tiru notes, I'm not convinced that an 
MTI is required for initial adoption of the method.

In short, I think a MTI key exchange method is a good goal, but I don't 
think we're in a position to declare one at this time and I don't think 
it's necessary to declare one in order to begin seeing adoption of the 
3rd party auth method.

--Brandon


On 05/01/2015 12:43 AM, Tirumaleswar Reddy (tireddy) wrote:
>> -----Original Message-----
>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>> Sent: Thursday, April 30, 2015 2:06 PM
>> To: Oleg Moskalenko
>> Cc: Prashanth Patil (praspati); The IESG; tram-chairs@ietf.org; tram@ietf.org;
>> draft-ietf-tram-turn-third-party-authz@ietf.org;
>> gonzalo.camarillo@ericsson.com; draft-ietf-tram-turn-third-party-
>> authz.ad@ietf.org; draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org
>> Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-
>> party-authz-15: (with DISCUSS and COMMENT)
>>
>>
>>
>> On 30/04/15 09:22, Oleg Moskalenko wrote:
>>> On Thu, Apr 30, 2015 at 12:47 AM, Stephen Farrell
>>> <stephen.farrell@cs.tcd.ie> wrote:
>>>>
>>>>
>>>> On 30/04/15 02:02, Oleg Moskalenko wrote:
>>>
>>> Yes, we disagree. With your proposal, you will achieve exactly
>>> opposite from what you are declaring.
>>>
>>> WebRTC server and TURN server are modular servers. They have different
>>> semi-independent parts. The essential parts functionality is dictated
>>> by the corresponding standards. There is absolutely no necessity to
>>> mandate one way or another in the key exchange parts. In reality, as
>>> it is usually deployed, the same people are controlling both servers.
>
> Yes, even for the use case where TURN server and WebRTC server are in different administrative domains (e.g. Akamai only providing the relay service) the feedback is that MTI is not required for key exchange. I got  similar response even from OAuth WG http://www.ietf.org/mail-archive/web/oauth/current/msg14321.html using long-term secret b/w AS and RS for OAuth 2.0 self-contained token.
>
> -Tiru
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>

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

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