From nobody Sat May 2 06:29:26 2015 Return-Path: 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 62FC21B3038; Thu, 30 Apr 2015 21:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 vsaCgoTuSV_t; Thu, 30 Apr 2015 21:43:19 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968681B3037; Thu, 30 Apr 2015 21:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2296; q=dns/txt; s=iport; t=1430455399; x=1431664999; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cWd5gdIe4zn7Mhhqz0oFvSmBmbpa6tkFuTHEcaPQ90Q=; b=QpncfeqDmuABIRYa2jwz4jr2ICog7com+ncDbtW3RbtTbusp8aYo43pM euVvVcpAqVGTYOBQADRnF/NE/6a8sftKM71uXiAmsK9H6lNs2eLSPIHfg BfegLWnRHo3JhxrJdG15b+qaT6sxBpce0p6ozvSMYPurjVPvr0zeDTYvz c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AUBQCyA0NV/5pdJa1cgwxTXAWDGMFTgkOGBAIcgTxMAQEBAQEBgQuEIAEBAQQjEUUMBAIBCBEEAQEBAgIGGQQDAgICMBQBCAgCBAENBQgBiCINs3qTPwEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYoXhDMBAQUaFhsHBoJiL4EWBZFvi22RCoNQI2CBBVOBPG8BgQo5gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,348,1427760000"; d="scan'208";a="416245713" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 01 May 2015 04:43:18 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t414hHL1002877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 May 2015 04:43:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.218]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 30 Apr 2015 23:43:17 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Stephen Farrell , Oleg Moskalenko Thread-Topic: [tram] Stephen Farrell's Discuss on draft-ietf-tram-turn-third-party-authz-15: (with DISCUSS and COMMENT) Thread-Index: AQHQgfljn3eNkKZMFkCfMqDWMLcdXp1kslWAgAAYOYCAAEf1gIAAcQwAgAAJ/YCAAAOlAIAA8P+Q Date: Fri, 1 May 2015 04:43:17 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A4782328F@xmb-rcd-x10.cisco.com> References: <20150428212204.9453.5930.idtracker@ietfa.amsl.com> <554142C5.6030505@cs.tcd.ie> <5541DDF6.7000205@cs.tcd.ie> <5541E966.80602@cs.tcd.ie> In-Reply-To: <5541E966.80602@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.86] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 02 May 2015 06:29:25 -0700 Cc: "Prashanth Patil \(praspati\)" , "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" , The IESG , "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) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 04:43:20 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGVwaGVuIEZhcnJlbGwgW21h aWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwg MzAsIDIwMTUgMjowNiBQTQ0KPiBUbzogT2xlZyBNb3NrYWxlbmtvDQo+IENjOiBQcmFzaGFudGgg UGF0aWwgKHByYXNwYXRpKTsgVGhlIElFU0c7IHRyYW0tY2hhaXJzQGlldGYub3JnOyB0cmFtQGll dGYub3JnOw0KPiBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoekBpZXRmLm9y ZzsNCj4gZ29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tOyBkcmFmdC1pZXRmLXRyYW0tdHVy bi10aGlyZC1wYXJ0eS0NCj4gYXV0aHouYWRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdHJhbS10dXJu LXRoaXJkLXBhcnR5LWF1dGh6LnNoZXBoZXJkQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdHJh bV0gU3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGly ZC0NCj4gcGFydHktYXV0aHotMTU6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiAN Cj4gDQo+IE9uIDMwLzA0LzE1IDA5OjIyLCBPbGVnIE1vc2thbGVua28gd3JvdGU6DQo+ID4gT24g VGh1LCBBcHIgMzAsIDIwMTUgYXQgMTI6NDcgQU0sIFN0ZXBoZW4gRmFycmVsbA0KPiA+IDxzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllPiB3cm90ZToNCj4gPj4NCj4gPj4NCj4gPj4gT24gMzAvMDQv MTUgMDI6MDIsIE9sZWcgTW9za2FsZW5rbyB3cm90ZToNCj4gPg0KPiA+IFllcywgd2UgZGlzYWdy ZWUuIFdpdGggeW91ciBwcm9wb3NhbCwgeW91IHdpbGwgYWNoaWV2ZSBleGFjdGx5DQo+ID4gb3Bw b3NpdGUgZnJvbSB3aGF0IHlvdSBhcmUgZGVjbGFyaW5nLg0KPiA+DQo+ID4gV2ViUlRDIHNlcnZl ciBhbmQgVFVSTiBzZXJ2ZXIgYXJlIG1vZHVsYXIgc2VydmVycy4gVGhleSBoYXZlIGRpZmZlcmVu dA0KPiA+IHNlbWktaW5kZXBlbmRlbnQgcGFydHMuIFRoZSBlc3NlbnRpYWwgcGFydHMgZnVuY3Rp b25hbGl0eSBpcyBkaWN0YXRlZA0KPiA+IGJ5IHRoZSBjb3JyZXNwb25kaW5nIHN0YW5kYXJkcy4g VGhlcmUgaXMgYWJzb2x1dGVseSBubyBuZWNlc3NpdHkgdG8NCj4gPiBtYW5kYXRlIG9uZSB3YXkg b3IgYW5vdGhlciBpbiB0aGUga2V5IGV4Y2hhbmdlIHBhcnRzLiBJbiByZWFsaXR5LCBhcw0KPiA+ IGl0IGlzIHVzdWFsbHkgZGVwbG95ZWQsIHRoZSBzYW1lIHBlb3BsZSBhcmUgY29udHJvbGxpbmcg Ym90aCBzZXJ2ZXJzLg0KDQpZZXMsIGV2ZW4gZm9yIHRoZSB1c2UgY2FzZSB3aGVyZSBUVVJOIHNl cnZlciBhbmQgV2ViUlRDIHNlcnZlciBhcmUgaW4gZGlmZmVyZW50IGFkbWluaXN0cmF0aXZlIGRv bWFpbnMgKGUuZy4gQWthbWFpIG9ubHkgcHJvdmlkaW5nIHRoZSByZWxheSBzZXJ2aWNlKSB0aGUg ZmVlZGJhY2sgaXMgdGhhdCBNVEkgaXMgbm90IHJlcXVpcmVkIGZvciBrZXkgZXhjaGFuZ2UuIEkg Z290ICBzaW1pbGFyIHJlc3BvbnNlIGV2ZW4gZnJvbSBPQXV0aCBXRyBodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNDMyMS5odG1sIHVzaW5nIGxv bmctdGVybSBzZWNyZXQgYi93IEFTIGFuZCBSUyBmb3IgT0F1dGggMi4wIHNlbGYtY29udGFpbmVk IHRva2VuLg0KDQotVGlydQ0KIA0KDQo= From nobody Sat May 2 06:29:28 2015 Return-Path: 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 811EE1B308D; Thu, 30 Apr 2015 23:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 BmEhvSmmC8vm; Thu, 30 Apr 2015 23:25:26 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BF11B308C; Thu, 30 Apr 2015 23:25:26 -0700 (PDT) Received: by widdi4 with SMTP id di4so40444517wid.0; Thu, 30 Apr 2015 23:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7wlWcs+ZWwXJvcf9PlJQbr9UI+kF/VtWvLyJJcatT4k=; b=eRvyK+Fp5Gd4Ok5+liOMS8dA+DvR25XhVmDSgUlCwsocGhIJb5lsSlcksUg/qD2dKM JG9/as9tDlKLINcel0Pk0KPuybXATPJgvpQTtAuf3czys8+09XPJI3PgfBlXcaeuDtIt +NxKh8wvfVDta2JWTpMpDoJHaPsMQc0wOmj4Nu24stJD/ACWeP4ezJfBq8xjE7mnnDJH DIu3HxYKGB4DvcgdYZnRSKoKaTpbgEPMgJHy9A/Emv9HAv3XN6lda0DadTfyLWA/wyk9 YpryxoSi4QtUHo3fMSyxdaIYLsSoWgT6+ld0Zke/7ADA8m2VklcyIzPTGHiKo/7u0hF1 9wVA== MIME-Version: 1.0 X-Received: by 10.194.77.98 with SMTP id r2mr14750079wjw.130.1430461524755; Thu, 30 Apr 2015 23:25:24 -0700 (PDT) Received: by 10.194.190.7 with HTTP; Thu, 30 Apr 2015 23:25:24 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A4782328F@xmb-rcd-x10.cisco.com> References: <20150428212204.9453.5930.idtracker@ietfa.amsl.com> <554142C5.6030505@cs.tcd.ie> <5541DDF6.7000205@cs.tcd.ie> <5541E966.80602@cs.tcd.ie> <913383AAA69FF945B8F946018B75898A4782328F@xmb-rcd-x10.cisco.com> Date: Thu, 30 Apr 2015 23:25:24 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Sat, 02 May 2015 06:29:25 -0700 Cc: "Prashanth Patil \(praspati\)" , "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" , The IESG , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , Stephen Farrell 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 06:25:27 -0000 On Thu, Apr 30, 2015 at 9:43 PM, 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 >> > 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. Yes, this is a good example. > 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. Yes, that group is very cautious. From nobody Wed May 6 08:57:47 2015 Return-Path: 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 9B7A91B2BAA; Wed, 6 May 2015 08:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_NOTICE=2.3, SPF_PASS=-0.001] autolearn=no 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 gDpdkD1KJISt; Wed, 6 May 2015 08:57:41 -0700 (PDT) Received: from mail-vn0-x230.google.com (mail-vn0-x230.google.com [IPv6:2607:f8b0:400c:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87441B2A30; Wed, 6 May 2015 08:57:25 -0700 (PDT) Received: by vnbg7 with SMTP id g7so1013405vnb.10; Wed, 06 May 2015 08:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EAaRn/7Qcc9TB3DQveUFHctVsV+B7KcARk86aXGaPkM=; b=uO8vsmWUIK5KlZOLrccR8NWGjX1ulkKzgrRxUYul3lMCfom0Mkhp5K/vWjzTKuUYCx Osh8wM0ng5o9d8X9s9zxIu4+9j8H4UnDFxlTY8gchvcdWOIl/6HLa3WCzVDHwMF/2aEB aw1X2x1lA8ZO3DMyzZAifdl8/Aa+x/DAxxNLwSf0OFuKoBh41ZHMknlVmSlzmOp8kWED BeL2YfEbu2zrttnYRoXZoig1EHfceDO2kPr3V69M78W4K0l1HpM1K8MP4z1pLOk8pImD CpzzMrv/9gf+iGItU9ynGMaMxXiLwUWm9YBM0MN0f6IL59IA0oSVPKPglMUk1GuhojZF zWQA== MIME-Version: 1.0 X-Received: by 10.52.240.14 with SMTP id vw14mr35614898vdc.29.1430927844985; Wed, 06 May 2015 08:57:24 -0700 (PDT) Received: by 10.52.106.100 with HTTP; Wed, 6 May 2015 08:57:24 -0700 (PDT) In-Reply-To: <20150421153635.27696.5302.idtracker@ietfa.amsl.com> References: <20150421153635.27696.5302.idtracker@ietfa.amsl.com> Date: Wed, 6 May 2015 10:57:24 -0500 Message-ID: From: Alan Johnston To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c31fbee651f205156bd9dc Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, Simon Perreault , The IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 15:57:44 -0000 --001a11c31fbee651f205156bd9dc Content-Type: text/plain; charset=UTF-8 Stephen, The purpose of this extension is not gathering analytics to monetize people's WebRTC usage. It is all about solving some pressing authentication issues in today's STUN and TURN usage, and we have running code for both clients and servers today. It's not productive to wait for some other new authentication method to be finalized and perhaps deployed. The authors of the draft, and the implementors (browser and server) have discussed the issues you raise, and below is our response. The draft identifies 6 usages of STUN, and two are ruled out with a MUST NOT (ICE and Media keepalives) and one is SHOULD NOT (SIP keepalives). We did this because we could not see a benefit of ORIGIN in those usages and because of consideration of privacy concerns. Lets look at the other 3 usages of STUN that are described. Consider the TURN usage. The most important use case of ORIGIN is to help the TURN server select the correct REALM for the authentication challenge. I'm not aware of public TURN servers being common, unlike STUN servers. TURN requires authentication (hence the need for REALMs), and the credentials used identify at least the site if not the individual user of the TURN service. Hence, the ORIGIN information does not provide any additional privacy-sensitive information to the TURN server. However, for cases where a TURN server perhaps accepts an anonymous login, or a login that is shared among many sites, the presence of ORIGIN could leak privacy information. Section 7.3 of RFC 6454 says: " Whenever a user agent issues an HTTP request from a "privacy- sensitive" context, the user agent MUST send the value "null" in the Origin header field. NOTE: This document does not define the notion of a privacy- sensitive context. Applications that generate HTTP requests can designate contexts as privacy-sensitive to impose restrictions on how user agents generate Origin header fields." We had proposed also sending an empty ORIGIN attribute to be aligned with the HTTP usage of Origin. However, we could instead just omit the ORIGIN attribute under the same conditions of a "privacy-sensitive" context. We propose changing the start of Section 2.2: OLD: When the origin is a web origin, TURN [RFC5766] Allocate requests MUST include the ORIGIN attribute. For all other TURN requests, including the Send method, the use of the ORIGIN attribute is NOT RECOMMENDED. For other origins, such as SIP or XMPP, TURN Allocate requests SHOULD include the ORIGIN attribute. NEW: For all types of origins, TURN [RFC5766] Allocate requests SHOULD include the ORIGIN attribute, All other TURN requests, including the Send method, SHOULD NOT include the ORIGIN attribute. In a "privacy-sensitive" context, the ORIGIN MUST NOT be included. END The STUN usage and NAT Discovery Usage are covered together, since they are very similar. As a cloud service, there are many operational reasons why the operator of a STUN server will want to know what applications are using it, just like for web services. For dedicated applications, the STUN SOFTWARE attribute (which is a SHOULD include in RFC 5389) provides information about the client generating STUN requests to the STUN server today. For WebRTC users, this will only tell which browser is using the server. Without Origin information, they don't know who is directing this client to send traffic (perhaps errored or invalid traffic) to their STUN server. With Origin, the STUN server operator can contact the operator of the service and try to get them to fix their client, and failing that they could drop these packets based on the Origin without having to process them further or have these errant packets fill up their error logs. Furthermore, real-world WebRTC applications will make use of both STUN and TURN servers, and there is no good reason why they would be provided by different service providers (since STUN is a subset of TURN). As such, there does not seem to be a good reason to include origin in TURN, but prohibit it from STUN. And if, for some reason, the web application provider definitely does not want to disclose any information to its STUN provider, it can simply set up its own STUN server (this is trivially expensive). We propose changing the first two paragraphs of 2.1 from OLD: For STUN requests sent without authentication to a STUN server (i.e. STUN binding requests sent to a STUN server), the STUN client MUST include the ORIGIN attribute when the origin is a web origin. For other origins, such as SIP or XMPP, the STUN client SHOULD include the ORIGIN attribute. Note that for privacy reasons, an empty ORIGIN attribute can be sent, as described in the Security Considerations. NEW: For STUN requests sent without authentication to a STUN server (i.e. STUN binding requests sent to a STUN server), the STUN client SHOULD include the ORIGIN attribute. The ORIGIN attribute MUST NOT be included if it is a "privacy-sensitive" context, as discussed in the Security Considerations section. END Does this resolve your DISCUSS? The new text simplifies the extension by not making behavior specific on the Origin type. We could of course replace the MUST NOT for privacy-sensitive contexts with EMPTY ORIGIN as originally specified (for the consistency reason stated) but either meets our objective and we have now proposed not sending for simplicity. See below for answers on your COMMENTs. - Alan - On Tue, Apr 21, 2015 at 10:36 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-tram-stun-origin-05: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > "Analytics" here together with the MUST include > statements could amount to a fancy way to > describe monetizing people's WebRTC calls in ways > that the end user will just not expect. I'd like > to check that we're not doing that, as it'd > arguably run counter to e.g. RFC7258 or to the > general trend towards data minimisation. And > making privacy worse, even by a little, seems > worse than making it better. (Note: I am here > asking about the STUN/TURN server being perhaps > unnecessarily told the origin, not the risk that > someone sees that in-transit, which is handled in > the draft already.) > > I do agree that the TURN 401-like challenge > use-case is perhaps needed, but I do not see that > other use cases need to see the origin for them > to work at all. And I'm not sure that such a > spoofable origin is so useful for that TURN case, > esp. when there's parallel work on an > authenticated equivalent. (I mean the tram 3rd > party thing.) I also don't see that that is > needed for network management reasons - surely > everything needed for network managment is no > more nor less visible to the STUN or TURN servers > when this is used vs. when this is not used. > > So why are we pushing for this? If it is really > only for so-called "analytics" then is that ok? > (And where can I find a definition of what that > means?) > > Apologies if this discuss seems somewhat high > level, but as well as the general concern, the > last paragraph of the current tram charter seems > to me to me to say that tram ought not make > privacy worse. But maybe I'm missing the > networking function that needs this - if so, I'm > sure someone will point that out. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > > - intro, para 2: STUN only defines two auth modes > that I can see, and you only mention two here - > what's the 3rd one you mean? (Is it DTLS?) > No, the third mode is no authentication - that is the third method described at the end of the paragraph. > > - What if >1 TURN session with different origins > is being setup from same client/browser? Does > that work? (Say two parallel calls, not the case > where the same resource is being accessed at the > same time loaded from different referring web > pages.) > Yes, they are separate Peer Connections, but having the same ORIGIN won't cause any problems. > > - I'd suggest to not allow >1 ORIGIN in a STUN > request? But that discussion seems to be in-hand. > Right, that is the proposed resolution. > > - section 2: suggest providng similar examples > for all schemes, http(s),sip & xmpp. > We could, although we very carefully define the syntax per the ABNF. > > - 2.1 & 2.2: MUST include web origin - couldn't > there be "private browsing" scenarios where that > MUST would be a problem? I'm not suggesting that > the origin exposes very much but I think a SHOULD > would be more appropriate. > See above rewrites of these paragraphs. > > - 2.1 last para: source here means the webrtc > server right? That's a bit ambiguous and would be > better clarified. > It means the http, sip, or xmpp URL. We can clarify. > > - What is the benefit of sending an empty origin > as opposed to no origin attribute? I don't see > any and the former just advertises that the > client is "privacy sensitive" which seems > incongruous. > > This is how HTTP Origin handles privacy situations, but we plan to change it to omit the ORIGIN in these cases. We can't think of anything that will break if we do this. --001a11c31fbee651f205156bd9dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

S= tephen,

=C2=A0

The purpose of this exte= nsion is not gathering analytics to monetize people's WebRTC usage.=C2= =A0 It is all about solving some pressing authentication issues in today= 9;s=C2=A0STUN=C2=A0and TURN usage, and we have running code for both = clients and servers today.=C2=A0 It's not productive to wait=C2=A0for=C2=A0some other new authentication method to be fina= lized and perhaps deployed.=C2=A0 The authors of the draft, and the impleme= ntors (browser and server) have discussed the issues you raise, and below i= s our response.

The draft identifies 6 usages of STUN, and two are ruled o= ut with a MUST NOT (ICE and Media keepalives) and one is SHOULD NOT (SIP ke= epalives).=C2=A0 We did this because we could not see a benefit of ORIGIN i= n those usages and because of consideration of privacy concerns. Lets look = at the other 3 usages of STUN that are described.
=C2=A0
Consider the TURN usage.=C2= =A0 The most important use case of ORIGIN is to help the TURN server select= the correct REALM for the authentication challenge.=C2=A0 I'm not awar= e of public TURN servers being common, unlike STUN servers.=C2=A0 TURN requ= ires authentication (hence the need for REALMs), and the credentials used i= dentify at least the site if not the individual user of the TURN service.= =C2=A0 Hence, the ORIGIN information does not provide any additional privac= y-sensitive information to the TURN server.=C2=A0 However, for cases where = a TURN server perhaps accepts an anonymous login, or a login that is shared= among many sites, the presence of ORIGIN could leak privacy information.= =C2=A0 Section 7.3 of RFC 6454 says:
=C2=A0=
" =C2=A0Whenever a user agent issues = an HTTP request from a "privacy-
=C2= =A0 =C2=A0sensitive" context, the user agent MUST send the value "= ;null" in the
=C2=A0 =C2=A0Origin head= er field.
=C2=A0
=C2=A0 =C2=A0 =C2=A0 NOTE: This document does not define the notion o= f a privacy-
=C2=A0 =C2=A0 =C2=A0 sensitive= context.=C2=A0 Applications that generate HTTP requests can
=C2=A0 =C2=A0 =C2=A0 designate contexts as privacy-sensit= ive to impose restrictions on
=C2=A0 =C2=A0= =C2=A0 how user agents generate Origin header fields."
=C2=A0
We had proposed al= so sending an empty ORIGIN attribute to be aligned with the HTTP usage of O= rigin.=C2=A0 However, we could instead just omit the ORIGIN attribute under= the same conditions of a "privacy-sensitive" context.
=C2=A0
We propose cha= nging the start of Section 2.2:
=C2=A0
OLD:
=C2=A0
=C2=A0 =C2=A0When the origin is a web origin, = TURN [RFC5766] Allocate requests
=C2=A0 =C2= =A0MUST include the ORIGIN attribute.=C2=A0 For all other TURN requests,
=C2=A0 =C2=A0including the Send method, the u= se of the ORIGIN attribute is NOT
=C2=A0 = =C2=A0RECOMMENDED.=C2=A0 For other origins, such as SIP or XMPP, TURN Alloc= ate
=C2=A0 =C2=A0requests SHOULD include th= e ORIGIN attribute.
=C2=A0
NEW:

=C2=A0 =C2=A0For all types of o= rigins, TURN [RFC5766] Allocate requests
= =C2=A0 =C2=A0SHOULD include the ORIGIN attribute, =C2=A0 All other TURN req= uests,
=C2=A0 =C2=A0including the Send meth= od, SHOULD NOT include the ORIGIN attribute.=C2=A0
=C2=A0 =C2=A0In a "privacy-sensitive" context, the ORIGIN= MUST NOT be included.

END

=
The STUN usage and NAT Discovery Usage are covered togeth= er, since they are very similar.=C2=A0 As a cloud service, there are many o= perational reasons why the operator of a STUN server will want to know what= applications are using it, just like for web services.=C2=A0 For dedicated= applications, the STUN SOFTWARE attribute (which is a SHOULD include in RF= C 5389) provides information about the client generating STUN requests to t= he STUN server today. For WebRTC users, this will only tell which browser i= s using the server.=C2=A0 Without Origin information, they don't know w= ho is directing this client to send traffic (perhaps errored or invalid tra= ffic) to their STUN server. With Origin, the STUN server operator can conta= ct the operator of the service and try to get them to fix their client, and= failing that they could drop these packets based on the Origin without hav= ing to process them further or have these errant packets fill up their erro= r logs. =C2=A0
Furthermore, real-world WebRTC applications will make use of bot= h STUN and TURN servers, and there is no good reason why they would be prov= ided by different service providers (since STUN is a subset of TURN). As su= ch, there does not seem to be a good reason to include origin in TURN, but = prohibit it from STUN. And if, for some reason, the web application provide= r definitely does not want to disclose any information to its STUN provider= , it can simply set up its own STUN server (this is trivially expensive).= =C2=A0

We propose changing the first two paragraphs of= 2.1 from

=C2= =A0

OLD:

=C2=A0

=C2=A0 =C2=A0For=C2=A0STUN=C2=A0requests sent wit= hout authentication to a=C2=A0STUN=C2=A0server (i.e.

=C2=A0 = =C2=A0STUN=C2=A0binding requests sent to a=C2=A0STUN=C2=A0server), the=C2= =A0STUN=C2=A0client MUST

=C2=A0 =C2=A0include the=C2=A0ORIGI= N=C2=A0attribute when the=C2=A0origin=C2=A0is a web=C2=A0origin.=C2=A0 For<= u>

=C2=A0 =C2=A0other origins, such as SIP or XMPP, the=C2=A0ST= UN=C2=A0client SHOULD include

=C2=A0 =C2=A0the=C2=A0ORIGIN= =C2=A0attribute.

= =C2=A0

<= p class=3D"MsoNormal">=C2=A0 =C2=A0 =C2=A0 = Note that for privacy reasons, an empty=C2=A0ORIGIN=C2=A0attribute can be

=C2=A0 =C2=A0 =C2=A0 sent, as described in the Security Consi= derations.

<= /u>=C2=A0

NEW:=

=C2=A0

=C2=A0 =C2=A0For=C2=A0STUN=C2=A0requests sent wi= thout authentication to a=C2=A0STUN=C2=A0server (i.e.<= /p>

=C2=A0 =C2=A0STUN=C2=A0binding requests se= nt to a=C2=A0STUN=C2=A0server), the=C2=A0STUN=C2=A0client SHOULD=C2=A0

=C2=A0 =C2=A0include the= =C2=A0ORIGIN=C2=A0attribute.=C2=A0 The=C2=A0ORIGIN=C2=A0attribute MUST NOT = be included=C2=A0

=C2= =A0 =C2=A0if it is a "privacy-sensitive" context, as discussed in= the Security Considerations

=C2=A0 =C2=A0section.

=C2=A0

END

=C2=A0

Does this resolve your DISCUSS? The = new text simplifies the extension by not making behavior specific on the Or= igin type.=C2=A0 We could of course replace the MUST NOT for privacy-sensit= ive contexts with EMPTY=C2=A0ORIGIN=C2=A0as originally specified (for the c= onsistency reason stated) but either meets our objective and we have now pr= oposed not sending for simplicity.

=C2=A0

= See below for answers on your COMMENTs.

=C2=A0

- Alan -


<= /div>

On Tue, Apr 21, 2015 at 10:36 AM, Stephen Farrell &= lt;stephen.f= arrell@cs.tcd.ie> wrote:
Stephen Farrell = has entered the following ballot position for
draft-ietf-tram-stun-origin-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


"Analytics" here together with the MUST include
statements could amount to a fancy way to
describe monetizing people's WebRTC calls in ways
that the end user will just not expect. I'd like
to check that we're not doing that, as it'd
arguably run counter to e.g. RFC7258 or to the
general trend towards data minimisation. And
making privacy worse, even by a little, seems
worse than making it better. (Note: I am here
asking about the STUN/TURN server being perhaps
unnecessarily told the origin, not the risk that
someone sees that in-transit, which is handled in
the draft already.)

I do agree that the TURN 401-like challenge
use-case is perhaps needed, but I do not see that
other use cases need to see the origin for them
to work at all.=C2=A0 And I'm not sure that such a
spoofable origin is so useful for that TURN case,
esp. when there's parallel work on an
authenticated equivalent. (I mean the tram 3rd
party thing.) I also don't see that that is
needed for network management reasons - surely
everything needed for network managment is no
more nor less visible to the STUN or TURN servers
when this is used vs. when this is not used.

So why are we pushing for this?=C2=A0 If it is really
only for so-called "analytics" then is that ok?
(And where can I find a definition of what that
means?)

Apologies if this discuss seems somewhat high
level, but as well as the general concern, the
last paragraph of the current tram charter seems
to me to me to say that tram ought not make
privacy worse. But maybe I'm missing the
networking function that needs this - if so, I'm
sure someone will point that out.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------



- intro, para 2: STUN only defines two auth modes
that I can see, and you only mention two here -
what's the 3rd one you mean? (Is it DTLS?)

No, the third mode is no aut= hentication - that is the third method described at the end of the paragrap= h.
=C2=A0

- What if >1 TURN session with different origins
is being setup from same client/browser? Does
that work? (Say two parallel calls, not the case
where the same resource is being accessed at the
same time loaded from different referring web
pages.)

Yes, they are separate Peer Connections, but having the same ORIGIN= won't cause any problems.
=C2=A0

- I'd suggest to not allow >1 ORIGIN in a STUN
request? But that discussion seems to be in-hand.

=
Right, that is the propos= ed resolution.
=C2=A0=C2=A0

- section 2: suggest providng similar examples
for all schemes, http(s),sip & xmpp.

We could, although we very careful= ly define the syntax per the ABNF.
=C2=A0=C2=A0

- 2.1 & 2.2: MUST include web origin - couldn't
there be "private browsing" scenarios where that
MUST would be a problem? I'm not suggesting that
the origin exposes very much but I think a SHOULD
would be more appropriate.

See above rewrites of these paragraphs.
=C2=A0=C2=A0

- 2.1 last para: source here means the webrtc
server right? That's a bit ambiguous and would be
better clarified.

It means the http, sip, or xmpp URL.=C2=A0 We can clarify= .
=C2=A0=C2= =A0

- What is the benefit of sending an empty origin
as opposed to no origin attribute? I don't see
any and the former just advertises that the
client is "privacy sensitive" which seems
incongruous.


This is how HTTP= Origin handles privacy situations, but we plan to change it to omit the OR= IGIN in these cases.=C2=A0 We can't think of anything that will break i= f we do this.=C2=A0=C2=A0

--001a11c31fbee651f205156bd9dc-- From nobody Wed May 6 12:10:59 2015 Return-Path: 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 E00401ACEB8 for ; Wed, 6 May 2015 12:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 9Pzwo4pcHcIb for ; Wed, 6 May 2015 12:10:56 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3501B2BA1 for ; Wed, 6 May 2015 12:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2964; q=dns/txt; s=iport; t=1430939454; x=1432149054; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7lMD7H6JHU4a8qUHIXK2/MRwFVwuIbeiS2xj3FVQc3o=; b=RMywJMqf/exDCIJQIQ1nXt+lS4pwH646ZeytCV+1pN/RaLTfA2s2zIuz OmSpjjGxdwlFM/GwNVgTHzrqC54z+7AjjDxy+CVcL03/o115WdIERnwe9 K3ndHFuIYsDsGYADkV5f6KxAiTZF98fpmftS3YPIqMVvzoFtFU/dCqR1R E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ArBQCjZkpV/5hdJa1cgwxUXgaDGMFjZgmBWIYDAhyBDDgUAQEBAQEBAYEKhCABAQEEIxFDDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgTiBENsgmTWQEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYoYhDoaFiIGgmIvgRYFiyeHAYQUh2g9gxmRPyODdm8BgUOBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,380,1427760000"; d="scan'208";a="147621594" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 06 May 2015 19:10:53 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t46JArCl028015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 May 2015 19:10:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.74]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 6 May 2015 14:10:52 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-wing-tram-turn-mobility-03.txt Thread-Index: AQHQiC/NJuBVwNpRl0iQng1RdZXj3p1vT3bg Date: Wed, 6 May 2015 19:10:52 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47833BB0@xmb-rcd-x10.cisco.com> References: <20150506190642.6461.13442.idtracker@ietfa.amsl.com> In-Reply-To: <20150506190642.6461.13442.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.73.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-03.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 19:10:58 -0000 SW4gdGhpcyByZXZpc2lvbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2luZy10 cmFtLXR1cm4tbW9iaWxpdHktMDMgdXBkYXRlZCBJbnRyb2R1Y3Rpb24gdG8gY29tcGFyZSB0aGUg cHJvcG9zZWQgdGVjaG5pcXVlIHdpdGggSUNFIHJlc3RhcnQgYW5kIGNvbnRpbnVvdXMgbm9taW5h dGlvbiBwcm9jZWR1cmUuIENvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCg0K LVRpcnUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVy c2RheSwgTWF5IDA3LCAyMDE1IDEyOjM3IEFNDQpUbzogUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0 aSk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGly ZWRkeSk7IERhbiBXaW5nIChkd2luZyk7IERhbiBXaW5nIChkd2luZyk7IFBhbCBNYXJ0aW5zZW4g KHBhbG1hcnRpKTsgUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSk7IFBhbCBNYXJ0aW5zZW4gKHBh bG1hcnRpKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13aW5n LXRyYW0tdHVybi1tb2JpbGl0eS0wMy50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtd2luZy10cmFtLXR1cm4tbW9iaWxpdHktMDMudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJl cG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC13aW5nLXRyYW0tdHVybi1tb2JpbGl0eQ0KUmV2aXNp b246CTAzDQpUaXRsZToJCU1vYmlsaXR5IHdpdGggVFVSTg0KRG9jdW1lbnQgZGF0ZToJMjAxNS0w NS0wNg0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTENClVSTDogICAg ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd2luZy10 cmFtLXR1cm4tbW9iaWxpdHktMDMudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2luZy10cmFtLXR1cm4tbW9iaWxpdHkvDQpIdG1saXpl ZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbmctdHJhbS10dXJu LW1vYmlsaXR5LTAzDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LXdpbmctdHJhbS10dXJuLW1vYmlsaXR5LTAzDQoNCkFic3RyYWN0Og0KICAg SXQgaXMgZGVzaXJhYmxlIHRvIG1pbmltaXplIHRyYWZmaWMgZGlzcnVwdGlvbiBjYXVzZWQgYnkg Y2hhbmdpbmcgSVANCiAgIGFkZHJlc3MgZHVyaW5nIGEgbW9iaWxpdHkgZXZlbnQuICBPbmUgbWVj aGFuaXNtIHRvIG1pbmltaXplDQogICBkaXNydXB0aW9uIGlzIHRvIGV4cG9zZSBhIHNob3J0ZXIg bmV0d29yayBwYXRoIHRvIHRoZSBtb2JpbGl0eSBldmVudA0KICAgc28gb25seSB0aGUgbG9jYWwg bmV0d29yayBlbGVtZW50cyBhcmUgYXdhcmUgb2YgdGhlIGNoYW5nZWQgSVANCiAgIGFkZHJlc3Mg YnV0IHRoZSByZW1vdGUgcGVlciBpcyB1bmF3YXJlIG9mIHRoZSBjaGFuZ2VkIElQIGFkZHJlc3Mu DQoNCiAgIFRoaXMgZHJhZnQgcHJvdmlkZXMgc3VjaCBhbiBJUCBhZGRyZXNzIG1vYmlsaXR5IHNv bHV0aW9uIHVzaW5nDQogICBUcmF2ZXJzYWwgVXNpbmcgUmVsYXlzIGFyb3VuZCBOQVQgKFRVUk4p LiAgVGhpcyBpcyBhY2hpZXZlZCBieQ0KICAgYWxsb3dpbmcgYSBjbGllbnQgdG8gcmV0YWluIGFu IGFsbG9jYXRpb24gb24gdGhlIFRVUk4gc2VydmVyIHdoZW4gdGhlDQogICBJUCBhZGRyZXNzIG9m IHRoZSBjbGllbnQgY2hhbmdlcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Sun May 10 04:51:07 2015 Return-Path: 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 15B331A891C; Sun, 10 May 2015 04:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_NOTICE=2.3, 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 g6J0zpR8lPiW; Sun, 10 May 2015 04:51:01 -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 0D6D11A8907; Sun, 10 May 2015 04:50:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 25405BED3; Sun, 10 May 2015 12:50:56 +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 NKsnJwYPkoB2; Sun, 10 May 2015 12:50:53 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.109]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0DBC3BED2; Sun, 10 May 2015 12:50:53 +0100 (IST) Message-ID: <554F461C.4040603@cs.tcd.ie> Date: Sun, 10 May 2015 12:50:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alan Johnston References: <20150421153635.27696.5302.idtracker@ietfa.amsl.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, Simon Perreault , The IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 11:51:05 -0000 Hi Alan, Sorry for the slow response, was travelling... On 06/05/15 16:57, Alan Johnston wrote: > Stephen, > > > The purpose of this extension is not gathering analytics to monetize > people's WebRTC usage. Good to hear. Does it have that side-effect though? If so, oughtn't we think about that? And that still leaves me puzzled as to the mentions of "analytics" in the draft, which at least in my understanding of the term (admittedly not a very expert one) does involve using information to make money however one can. So while it's good to hear the above, my concerns are not fully assuaged. > It is all about solving some pressing > authentication issues in today's STUN and TURN usage, and we have running > code for both clients and servers today. For me, a consequence of the above would be that the scheme must not be trivially defeated by the browser telling lies. Otherwise you have not solved any authentication issue at all. > It's not productive to wait for some > other new authentication method to be finalized and perhaps deployed. Hmm. Since both are tram WG drafts, I assume this was discussed on the list. If so, can you point me at that thread. It seems odd to have two schemes for one thing, esp. with such different properties, and yet to not have the reasons for that being a good plan documented somewhere. (And I'd be fine with that being in meeting minutes, mails or whatever.) > The > authors of the draft, and the implementors (browser and server) have > discussed the issues you raise, and below is our response. > > The draft identifies 6 usages of STUN, and two are ruled out with a MUST > NOT (ICE and Media keepalives) and one is SHOULD NOT (SIP keepalives). We > did this because we could not see a benefit of ORIGIN in those usages and > because of consideration of privacy concerns. Lets look at the other 3 > usages of STUN that are described. BTW, I just re-read the draft and I do appreciate that the authors are seriously considering privacy issues. > > Consider the TURN usage. The most important use case of ORIGIN is to help > the TURN server select the correct REALM for the authentication challenge. Right. OTOH, one could also use the "user@realm" convention for the username in an authentication in some cases, but I agree that has it's downsides if it is forced into an existing authentication scheme. The upside is that this information is only sent during and not before authentication. Since we are in any case changing things, that may be a better alternative. Were such ideas considered? > I'm not aware of public TURN servers being common, unlike STUN servers. > TURN requires authentication (hence the need for REALMs), and the > credentials used identify at least the site if not the individual user of > the TURN service. Hence, the ORIGIN information does not provide any > additional privacy-sensitive information to the TURN server. However, for > cases where a TURN server perhaps accepts an anonymous login, or a login > that is shared among many sites, the presence of ORIGIN could leak privacy > information. Section 7.3 of RFC 6454 says: > > " Whenever a user agent issues an HTTP request from a "privacy- > sensitive" context, the user agent MUST send the value "null" in the > Origin header field. > > NOTE: This document does not define the notion of a privacy- > sensitive context. Applications that generate HTTP requests can > designate contexts as privacy-sensitive to impose restrictions on > how user agents generate Origin header fields." > > We had proposed also sending an empty ORIGIN attribute to be aligned with > the HTTP usage of Origin. However, we could instead just omit the ORIGIN > attribute under the same conditions of a "privacy-sensitive" context. I did make a comment about that, and clarifications such as that below would be good, once we've landed the discussion someplace. Right now, I'm not sure if this change is the right thing. > > We propose changing the start of Section 2.2: > > OLD: > > When the origin is a web origin, TURN [RFC5766] Allocate requests > MUST include the ORIGIN attribute. For all other TURN requests, > including the Send method, the use of the ORIGIN attribute is NOT > RECOMMENDED. For other origins, such as SIP or XMPP, TURN Allocate > requests SHOULD include the ORIGIN attribute. > > NEW: > > For all types of origins, TURN [RFC5766] Allocate requests > SHOULD include the ORIGIN attribute, All other TURN requests, > including the Send method, SHOULD NOT include the ORIGIN attribute. > In a "privacy-sensitive" context, the ORIGIN MUST NOT be included. > > END > > The STUN usage and NAT Discovery Usage are covered together, since they are > very similar. As a cloud service, there are many operational reasons why > the operator of a STUN server will want to know what applications are using > it, just like for web services. Sure. The question for us is the extent to which we ought design the protocol to essentially force the UA to send that given that we also want to consider the privacy concerns of the people using these services. > For dedicated applications, the STUN > SOFTWARE attribute (which is a SHOULD include in RFC 5389) provides > information about the client generating STUN requests to the STUN server > today. For WebRTC users, this will only tell which browser is using the > server. Without Origin information, they don't know who is directing this > client to send traffic (perhaps errored or invalid traffic) to their STUN > server. With Origin, the STUN server operator can contact the operator of Contact based on an unauthenticated attribute? That has some downsides. > the service and try to get them to fix their client, and failing that they > could drop these packets based on the Origin without having to process them > further or have these errant packets fill up their error logs. > Furthermore, real-world WebRTC applications will make use of both STUN and > TURN servers, and there is no good reason why they would be provided by > different service providers (since STUN is a subset of TURN). As such, > there does not seem to be a good reason to include origin in TURN, but > prohibit it from STUN. And if, for some reason, the web application > provider definitely does not want to disclose any information to its STUN > provider, it can simply set up its own STUN server (this is trivially > expensive). > > We propose changing the first two paragraphs of 2.1 from > > > > OLD: > > > > For STUN requests sent without authentication to a STUN server (i.e. > > STUN binding requests sent to a STUN server), the STUN client MUST > > include the ORIGIN attribute when the origin is a web origin. For > > other origins, such as SIP or XMPP, the STUN client SHOULD include > > the ORIGIN attribute. > > > > Note that for privacy reasons, an empty ORIGIN attribute can be > > sent, as described in the Security Considerations. > > > > NEW: > > > > For STUN requests sent without authentication to a STUN server (i.e. > > STUN binding requests sent to a STUN server), the STUN client SHOULD > > include the ORIGIN attribute. The ORIGIN attribute MUST NOT be included > > if it is a "privacy-sensitive" context, as discussed in the Security > Considerations > > section. > > > > END > > > > Does this resolve your DISCUSS? Not yet. First, we need to talk about whether/when this information is needed (which we're doing above, but we've not yet finished that discussion). Second, but only really after that (so I suggest we don't try to bottom out on this yet), I think saying privacy-sensitive is really not that useful here. (I accept that it may be clear to each browser implementer, but perhaps with different meanings?) > The new text simplifies the extension by > not making behavior specific on the Origin type. We could of course > replace the MUST NOT for privacy-sensitive contexts with EMPTY ORIGIN as > originally specified (for the consistency reason stated) but either meets > our objective and we have now proposed not sending for simplicity. > > > > See below for answers on your COMMENTs. Those all seem fine, or will be when we resolve the discuss. Cheers, S. > > > > - Alan - > > > On Tue, Apr 21, 2015 at 10:36 AM, Stephen Farrell > wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-tram-stun-origin-05: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> "Analytics" here together with the MUST include >> statements could amount to a fancy way to >> describe monetizing people's WebRTC calls in ways >> that the end user will just not expect. I'd like >> to check that we're not doing that, as it'd >> arguably run counter to e.g. RFC7258 or to the >> general trend towards data minimisation. And >> making privacy worse, even by a little, seems >> worse than making it better. (Note: I am here >> asking about the STUN/TURN server being perhaps >> unnecessarily told the origin, not the risk that >> someone sees that in-transit, which is handled in >> the draft already.) >> >> I do agree that the TURN 401-like challenge >> use-case is perhaps needed, but I do not see that >> other use cases need to see the origin for them >> to work at all. And I'm not sure that such a >> spoofable origin is so useful for that TURN case, >> esp. when there's parallel work on an >> authenticated equivalent. (I mean the tram 3rd >> party thing.) I also don't see that that is >> needed for network management reasons - surely >> everything needed for network managment is no >> more nor less visible to the STUN or TURN servers >> when this is used vs. when this is not used. >> >> So why are we pushing for this? If it is really >> only for so-called "analytics" then is that ok? >> (And where can I find a definition of what that >> means?) >> >> Apologies if this discuss seems somewhat high >> level, but as well as the general concern, the >> last paragraph of the current tram charter seems >> to me to me to say that tram ought not make >> privacy worse. But maybe I'm missing the >> networking function that needs this - if so, I'm >> sure someone will point that out. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> >> - intro, para 2: STUN only defines two auth modes >> that I can see, and you only mention two here - >> what's the 3rd one you mean? (Is it DTLS?) >> > > No, the third mode is no authentication - that is the third method > described at the end of the paragraph. > > >> >> - What if >1 TURN session with different origins >> is being setup from same client/browser? Does >> that work? (Say two parallel calls, not the case >> where the same resource is being accessed at the >> same time loaded from different referring web >> pages.) >> > > Yes, they are separate Peer Connections, but having the same ORIGIN won't > cause any problems. > > >> >> - I'd suggest to not allow >1 ORIGIN in a STUN >> request? But that discussion seems to be in-hand. >> > > Right, that is the proposed resolution. > > >> >> - section 2: suggest providng similar examples >> for all schemes, http(s),sip & xmpp. >> > > We could, although we very carefully define the syntax per the ABNF. > > >> >> - 2.1 & 2.2: MUST include web origin - couldn't >> there be "private browsing" scenarios where that >> MUST would be a problem? I'm not suggesting that >> the origin exposes very much but I think a SHOULD >> would be more appropriate. >> > > See above rewrites of these paragraphs. > > >> >> - 2.1 last para: source here means the webrtc >> server right? That's a bit ambiguous and would be >> better clarified. >> > > It means the http, sip, or xmpp URL. We can clarify. > > >> >> - What is the benefit of sending an empty origin >> as opposed to no origin attribute? I don't see >> any and the former just advertises that the >> client is "privacy sensitive" which seems >> incongruous. >> >> > This is how HTTP Origin handles privacy situations, but we plan to change > it to omit the ORIGIN in these cases. We can't think of anything that will > break if we do this. > From nobody Sun May 10 10:20:03 2015 Return-Path: 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 926F11A878E for ; Sun, 10 May 2015 10:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 AQJaWM5qJxeJ for ; Sun, 10 May 2015 10:19:59 -0700 (PDT) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C738F1A8764 for ; Sun, 10 May 2015 10:19:56 -0700 (PDT) Received: by qku63 with SMTP id 63so74921398qku.3 for ; Sun, 10 May 2015 10:19:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OFKoRPOIjkCigdinEbaTMn6iqOv81a3fBxmYGw4ZT7s=; b=LStHInuj98vnlB6RvpIQm6emZR1mBcE006gSuvvKrar+1R1F4OZPOpfT6cjGEfQurn VTRVXg3nPrGuXxgqnBgA8ku2lgle4G2vdu0X+S+4ZflXMVkcBmGOmMU+XmMwvIaQ1LIu wPcI8Cdn7RduFgR+jmEsKbR+8FqG/FXrRfruMJWCL0Qyxb+l/+9UMdy5kerdE8sLtiZ3 DWfHq4gPNtlVlXFFXDALrkj8A6pXLBdz7lm3kuPvzQdLeJLsEF0wLp2cBPNp6AA9K9Qd i7ah3ihvQD/2Au5cC02SxKl31oMA2edM5GR1QU6U1rXDnDBk3gMRqmC390JMhA5Nf3vy lQAg== X-Gm-Message-State: ALoCoQmTx0UG6T+HxOyhUZyYSSfPdYOocRo1OP/RxKAybaUnPh3LmRLQULU8yn+DUa+oGtueMjgh X-Received: by 10.140.147.143 with SMTP id 137mr9122593qht.7.1431278396067; Sun, 10 May 2015 10:19:56 -0700 (PDT) Received: from [192.168.1.131] ([24.53.47.130]) by mx.google.com with ESMTPSA id w17sm8420360qkw.32.2015.05.10.10.19.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 May 2015 10:19:55 -0700 (PDT) Message-ID: <554F9339.4090404@jive.com> Date: Sun, 10 May 2015 13:19:53 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , Alan Johnston References: <20150421153635.27696.5302.idtracker@ietfa.amsl.com> <554F461C.4040603@cs.tcd.ie> In-Reply-To: <554F461C.4040603@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, The IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 17:20:00 -0000 A few comments as shepherd and as a person involved in TRAM since before the first bar BoF... Le 2015-05-10 07:50, Stephen Farrell a écrit : >> The purpose of this extension is not gathering analytics to monetize >> people's WebRTC usage. > > Good to hear. Does it have that side-effect though? If so, oughtn't > we think about that? And that still leaves me puzzled as to the > mentions of "analytics" in the draft, which at least in my understanding > of the term (admittedly not a very expert one) does involve using > information to make money however one can. So while it's good to hear > the above, my concerns are not fully assuaged. The way to implement multi-tenant servers currently, without ORIGIN, is to dedicate one IP address per tenant. This is a pain point for a number of reasons you can imagine. ORIGIN plays the same role as the Host header in HTTP: it allows virtual hosting. I see the comparison with the Host header as more accurate than with the Origin header. (One could also compare with the SNI extension in TLS.) Therefore, ORIGIN does not enable more analytics than current practice (i.e., dedicating one IP address per tenant). >> It is all about solving some pressing >> authentication issues in today's STUN and TURN usage, and we have running >> code for both clients and servers today. > > For me, a consequence of the above would be that the scheme must not > be trivially defeated by the browser telling lies. Otherwise you have > not solved any authentication issue at all. I don't follow. If the browser lies, then authentication will fail. Where's the problem? >> It's not productive to wait for some >> other new authentication method to be finalized and perhaps deployed. > > Hmm. Since both are tram WG drafts, I assume this was discussed on the > list. If so, can you point me at that thread. It seems odd to have two > schemes for one thing, esp. with such different properties, and yet to > not have the reasons for that being a good plan documented somewhere. > (And I'd be fine with that being in meeting minutes, mails or whatever.) As far as I can remember, WG participants have agreed that both ORIGIN and third-party-auth were necessary. I don't remember a list discussion about this. People running servers now need to solve the multi-tenant problem with the current authentication scheme. Moving to third-party-auth is not always possible especially for non-WebRTC uses. As a concrete example, think of a multi-tenant server being used for SIP. SIP clients could plausibly be modified to include the ORIGIN attribute, but moving to third-party-auth is unthinkable. >> Consider the TURN usage. The most important use case of ORIGIN is to help >> the TURN server select the correct REALM for the authentication challenge. > > Right. OTOH, one could also use the "user@realm" convention for the > username in an authentication in some cases, but I agree that has it's > downsides if it is forced into an existing authentication scheme. Yes, this is established practice as well, but not always possible, for reasons you might guess. Dedicating one IP address per tenant is the most generic and flexible workaround. > The > upside is that this information is only sent during and not before > authentication. Dedicating one IP address per tenant is the same as ORIGIN on this aspect: the information is sent before authentication. > Since we are in any case changing things, that may be > a better alternative. Were such ideas considered? Yes, most definitely. It is current practice, and it is a pain point. Simon From nobody Mon May 11 16:30:16 2015 Return-Path: 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 80C741AC3FB; Mon, 11 May 2015 16:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no 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 PDW9HGVxlfKO; Mon, 11 May 2015 16:30:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F91D1AC3EC; Mon, 11 May 2015 16:30:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 16:30:12 -0700 Archived-At: Cc: tram-chairs@ietf.org, tram@ietf.org, draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, sperreault@jive.com, draft-ietf-tram-stun-origin@ietf.org Subject: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 23:30:13 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-tram-stun-origin-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a bit of a weird DISCUSS since I didn't manage to ballot when the document was first on the IESG's agenda, so I'm coming in mid-stream. I support Stephen's DISCUSS. If Alan's proposed changes make it into the document, they would resolve most of my concerns. However, I still see a problem with this proposed new text: "For STUN requests sent without authentication to a STUN server (i.e. STUN binding requests sent to a STUN server), the STUN client SHOULD include the ORIGIN attribute. The ORIGIN attribute MUST NOT be included if it is a "privacy-sensitive" context, as discussed in the Security Considerations section." For requests sent with authentication, I understand that the origin attribute needs to be accurate in order for the client to authenticate. In those cases, the STUN server can rely on the attribute it receives. But for requests without authentication, what prevents the client from lying? And if those requests are not (D)TLS-protected, what prevents them from being modified in transit? I understand Alan to be saying that the justification for the origin in this case is operational troubleshooting, but if the server can't rely on the origin it receives, doesn't that make it risky for the server to act on that information? My additional concern is about the use of "logging" as a justification for including and origin attribute. Logging in and of itself is not a reasonable justification. Alan's mail discussed the use of the origin for operational troubleshooting, which seems like what might actually be intended instead of "logging." In any event the purpose for the logging either needs to be explained or "logging" should not be listed as a justification. From nobody Mon May 11 16:45:11 2015 Return-Path: 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 69C7D1AC3A6; Mon, 11 May 2015 16:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 65S72BC3oVX4; Mon, 11 May 2015 16:45:05 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4F01A92FE; Mon, 11 May 2015 16:45:04 -0700 (PDT) Received: by wggj6 with SMTP id j6so8287852wgg.3; Mon, 11 May 2015 16:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mhz/24cQC64cSfR5wK/A6PUn2pFouwleIIzyR8F/IYY=; b=gLd5x1nv5SO21dMTCeS8TH1QW5s9l1grrK/Y2znXXl4jgHh0ZEj0OpbioEmiuB0t2S nueX0WOk6akE/6q09RyYLg7gdOXX6kU1bOG3EaEinpq//weThfxhPsT7m5O2TPfCoCwz LP9M77AZRF4BCGGEjNX/Vzqc4o108rBujupYCIFiw/YPYc8kynOy4Xf5s5bMWSOMQXHR qKK7J9ZSsluuJmsc06T2X/7zpb24ra5DToruonrl9GsH/4sq6Lav2LqTU2gcy33F7WCy sYnMxyN61CWnHsd8GvM9XNbDtzJ2SpiUGdgcltD7F53sjeKeo5+BES3cgc4hrdFYNTh5 KPfg== MIME-Version: 1.0 X-Received: by 10.194.186.145 with SMTP id fk17mr24910203wjc.156.1431387903492; Mon, 11 May 2015 16:45:03 -0700 (PDT) Received: by 10.194.233.105 with HTTP; Mon, 11 May 2015 16:45:03 -0700 (PDT) In-Reply-To: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> References: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 16:45:03 -0700 Message-ID: From: Oleg Moskalenko To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, Simon Perreault , The IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 23:45:06 -0000 On Mon, May 11, 2015 at 4:30 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-tram-stun-origin-05: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is a bit of a weird DISCUSS since I didn't manage to ballot when the > document was first on the IESG's agenda, so I'm coming in mid-stream. > > I support Stephen's DISCUSS. If Alan's proposed changes make it into the > document, they would resolve most of my concerns. However, I still see a > problem with this proposed new text: > > "For STUN requests sent without authentication to a STUN server (i.e. > > STUN binding requests sent to a STUN server), the STUN client SHOULD > > include the ORIGIN attribute. The ORIGIN attribute MUST NOT be > included > > if it is a "privacy-sensitive" context, as discussed in the Security > Considerations > > section." > > For requests sent with authentication, I understand that the origin > attribute needs to be accurate in order for the client to authenticate. > In those cases, the STUN server can rely on the attribute it receives. > But for requests without authentication, what prevents the client from > lying? if the client is lying, then the request will not be authenticated and it will be rejected - because the client's credentials will be incorrect. I see that many people cannot grasp that very simple concept. There is no benefits in lying in this case. Think about ORIGIN as simply a logical virtual database name where the user account will be searched and against that database the credentials will be verified. This information is not sensitive, and lying is not giving you any unjust benefits. The only outcome that you can achieve by lying is screwing your own request - that's it. > And if those requests are not (D)TLS-protected, what prevents them > from being modified in transit? I understand Alan to be saying that the > justification for the origin in this case is operational troubleshooting, > but if the server can't rely on the origin it receives, doesn't that make > it risky for the server to act on that information? No, as I explained above. > > My additional concern is about the use of "logging" as a justification > for including and origin attribute. Logging in and of itself is not a > reasonable justification. Why ? > Alan's mail discussed the use of the origin for > operational troubleshooting, which seems like what might actually be > intended instead of "logging." In any event the purpose for the logging > either needs to be explained or "logging" should not be listed as a > justification. Why ? > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon May 11 17:52:24 2015 Return-Path: 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 B1F0D1B2AF7 for ; Mon, 11 May 2015 17:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 TsYY7GFIfziR for ; Mon, 11 May 2015 17:52:19 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838C41B2AE2 for ; Mon, 11 May 2015 17:52:19 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5DD5320AAB for ; Mon, 11 May 2015 20:43:55 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Mon, 11 May 2015 20:43:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=6m+3q3/2GhDAKX1DYTfLG1dtzbw=; b=withay mQs76wiy+Pp//BvhhlZKk85bRd41Gf3VZvJI9g+yo07fN0PVuUaetZ4CA6TAYXn0 YZiUxx/R9FE0fTY54z/4qFaQLaTvHlaXnl7FJfAQtuEJpHBeYC3w52Txrts4OeI+ W2Zdv9giN8NCSg3rU3SllpkVUwdBXHlDiaZyM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=6m+3q3/2GhDAKX1 DYTfLG1dtzbw=; b=c5RWRG4dvzElg9B3xGbo+nrjcn3IULRntekOfTWgm51qNel HqP85BcvvJcaBkM5zxFo0q9eGTaHNURtDknk7YJFGKzDdeEkW4QpOZQWoDlfahVb ZomqZP6bE+0a1vf0xrbHNkbc7W5Gi+cMyrxk64OWAaSOfRaS2mjGRecPLBAU= X-Sasl-enc: wFB9Z0t0DAJfb7PH4CK3YrXZ2zO6DkF3wVgLzcit4FDU 1431391435 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.181]) by mail.messagingengine.com (Postfix) with ESMTPA id 0CFDE6800FE; Mon, 11 May 2015 20:43:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: Date: Mon, 11 May 2015 17:43:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> To: Oleg Moskalenko X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, Simon Perreault , IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 00:52:20 -0000 Hi Oleg, On May 11, 2015, at 4:45 PM, Oleg Moskalenko = wrote: >>=20 >> For requests sent with authentication, I understand that the origin >> attribute needs to be accurate in order for the client to = authenticate. >> In those cases, the STUN server can rely on the attribute it = receives. >> But for requests without authentication, what prevents the client = from >> lying? >=20 > if the client is lying, then the request will not be authenticated and > it will be rejected - because the client's credentials will be > incorrect. My question was about requests without authentication, as I said. I = assume the origin is not used for authentication in that case, since = authentication is not performed. > I see that many people cannot grasp that very simple > concept. I would appreciate if you would use a more respectful tone in the = future. Thanks, Alissa > There is no benefits in lying in this case. Think about > ORIGIN as simply a logical virtual database name where the user > account will be searched and against that database the credentials > will be verified. This information is not sensitive, and lying is not > giving you any unjust benefits. The only outcome that you can achieve > by lying is screwing your own request - that's it. >=20 >> And if those requests are not (D)TLS-protected, what prevents them >> from being modified in transit? I understand Alan to be saying that = the >> justification for the origin in this case is operational = troubleshooting, >> but if the server can't rely on the origin it receives, doesn't that = make >> it risky for the server to act on that information? >=20 > No, as I explained above. >=20 >>=20 >> My additional concern is about the use of "logging" as a = justification >> for including and origin attribute. Logging in and of itself is not a >> reasonable justification. >=20 > Why ? >=20 >> Alan's mail discussed the use of the origin for >> operational troubleshooting, which seems like what might actually be >> intended instead of "logging." In any event the purpose for the = logging >> either needs to be explained or "logging" should not be listed as a >> justification. >=20 > Why ? >=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram From nobody Mon May 11 18:04:29 2015 Return-Path: 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 C368F1A87C8; Mon, 11 May 2015 18:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 9dzybhLNIWfA; Mon, 11 May 2015 18:04:21 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0C91A8035; Mon, 11 May 2015 18:04:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAN5QUVWHCzIm/2dsb2JhbABSBwOCZilUXgaDGMNEhggCHIEdTAEBAQEBAYELhCABAQEBAxIREUUMBAIBCA0EBAEBAwIGHQMCAgIwFAEICAIEAQ0FCBMHiAoBDKozik+TbgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYkWgQKEIgYKAgEFGhYLEAcGC4JXL4EWBYZfi2GEHoJHhSM+gxyCcY5rI2GBBSMcgVJvAQEBgUKBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,411,1427774400"; d="scan'208";a="102181591" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 May 2015 21:04:16 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 11 May 2015 21:04:17 -0400 Received: from AZ-US1EXMB06.global.avaya.com ([fe80::38da:dafb:7358:e6f5]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0174.001; Mon, 11 May 2015 21:04:16 -0400 From: "Yoakum, John H (John)" To: Alissa Cooper , The IESG Thread-Topic: Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) Thread-Index: AQHQjEJu2EaI+z27Nk29xRdZAbCz/J13fTng Date: Tue, 12 May 2015 01:04:15 +0000 Message-ID: <93BEDDC39A54294B9E78C7860516FA47673B781F@AZ-US1EXMB06.global.avaya.com> References: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> In-Reply-To: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-stun-origin.shepherd@ietf.org" , "draft-ietf-tram-stun-origin.ad@ietf.org" , "sperreault@jive.com" , "draft-ietf-tram-stun-origin@ietf.org" Subject: Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 01:04:23 -0000 VGhlcmUgc2VlbXMgdG8gYmUgc29tZSBxdWVzdGlvbnMgYXJvdW5kIHdoeSB0aGluZ3MgbGlrZSBs b2dnaW5nIGFuZCBhZG1pbmlzdHJhdGl2ZSBkZWJ1Z2dpbmcgYXJlIHVzZWZ1bCBhbmQgcG9zc2li bHkgc29tZSBvZiBpdCBpcyBhIG1hdHRlciBvZiBjb250ZXh0LiAgSW5zaWRlIGVudGVycHJpc2Vz IGl0IGlzIHZlcnkgY29tbW9uIHRvIGhhdmUgYSB2YXJpZXR5IG9mIGxvZ2dpbmcgY2FwYWJpbGl0 aWVzIGFjcm9zcyBhbGwgcGFydHMgb2YgYSBzeXN0ZW0gb3Igc29sdXRpb24gYXMgd2VsbCBhcyB0 byBwZXJmb3JtIGRlYnVnZ2luZyBhY3Rpdml0aWVzIGJhc2VkIG9uIHdoYXRldmVyIGNvbWJpbmF0 aW9ucyBvZiBpbnNpZ2h0IGFyZSBhdmFpbGFibGUgd2hlbmV2ZXIgcHJvYmxlbXMgb2NjdXIuICAN Cg0KV2l0aCBXZWJSVEMgaXMgd2lsbCBiZSB2ZXJ5IGNvbW1vbiB0byBmaW5kIFRVUk4gc2VydmVy cyBydW4gYnkgZW50ZXJwcmlzZXMgdG8gc2VydmUgdmFyaW91cyBlbnRlcnByaXNlLWNlbnRyaWMg d2Vic2l0ZXMgdGhhdCBkZXNpcmUgcmVhbC10aW1lIGNvbW11bmljYXRpb25zIGFzIHBhcnQgb2Yg dGhlIGVudGVycHJpc2Ugd2ViIGV4cGVyaWVuY2UgZm9yIHBlb3BsZSBmcm9tIG91dHNpZGUgdGhl IGVudGVycHJpc2Ugd2hvIG1heSBiZSBleHRlcm5hbCBwYXJ0aWVzIG9yIGluIG1hbnkgdXNlIGNh c2VzIG1heSBhY3R1YWxseSBiZSBlbnRlcnByaXNlIGVtcGxveWVlcy4gIE9SSUdOIHRlbGxzIGEg U1RVTiBvciBUVVJOIHNlcnZlciB3aGF0IHJlYWxtIGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgcmVx dWVzdC4gIFRoYXQgcGllY2Ugb2Yga25vd2xlZGdlIGlzIGFscmVhZHkgd2VsbCBrbm93biBieSB0 aGUgYnJvd3NlciBtYWtpbmcgdGhlIHJlcXVlc3QgKGV4Y2VwdCBpbiB0aGUgcHJpdmFjeS1zZW5z aXRpdmUgc2l0dWF0aW9ucyBhY2NvbW1vZGF0ZWQgaW4gdGhlIGRyYWZ0LCB3aGljaCB3aWxsIHNl bGRvbSBiZSB0aGUgY2FzZSBmb3IgZW1wbG95ZWVzIG9mIGFuIGVudGVycHJpc2VzKSBhbmQgaXMg aGlnaGx5IHVzZWZ1bCB0byBlbnRlcnByaXNlcyB3aG8gaGF2ZSB3ZWIgc2VydmljZXMgYW5kIHJl bGF0ZWQgY29tbXVuaWNhdGlvbnMgZW5hYmxlbWVudCBnZWFyIGxpa2UgU1RVTiBhbmQgVFVSTiBz ZXJ2ZXJzIG5lY2Vzc2FyeSB0byBhbGxvdyBlbXBsb3llZXMgYWNjZXNzIGZyb20gaG9tZSwgdmly dHVhbCBvZmZpY2VzLCBvciB3aGlsZSB0cmF2ZWxpbmcgKHdpdGhvdXQgdGhlIG5lZWQgZm9yIFZQ TnMgb3Igb3RoZXIgc3BlY2lhbGl6ZWQgbmV0d29yayBjb25uZWN0aW9ucykuICBMYXJnZSBlbnRl cnByaXNlcyBvZnRlbiBoYXZlIG11bHRpcGxlIGFwcGxpY2F0aW9ucywgbXVsdGlwbGUgZG9tYWlu cyBvciBzdWJkb21haW5zLCBhbmQgbXVsdGlwbGUgcmVhbG1zLiAgVGhpcyBzaW1wbGUgZXh0ZW5z aW9uIHRvIFNUVU4gdG8gY29udmV5cyBpbnNpZ2h0IHJlbGF0ZWQgdG8gdGhlIHdlYiBhcHBsaWNh dGlvbnMgdXNpbmcgY29tbXVuaWNhdGlvbnMgZW5ub2JsZW1lbnRzIGxpa2UgU1RVTiBhbmQgVFVS TiBzZXJ2ZXJzIHdpbGwgZmluZCBtYW55IHVzZXMgaW5zaWRlIGVudGVycHJpc2VzLg0KDQpPUklH SU4gaXMgbm90IGEgc3Vic3RpdHV0ZSBmb3IgbW9yZSBhY2N1cmF0ZSBhdXRoZW50aWNhdGlvbiwg aXQgaXMgYSB3YXkgdG8gcXVpY2tseSBkZXRlcm1pbmUgdGhlIGJlc3QgYXV0aGVudGljYXRpb24g dG8gYXR0ZW1wdCBhcyB3ZWxsIGFzIHRvIHF1aWNrbHkgZmlsdGVyIG91dCB0aGluZ3Mgd2hlcmUg YXV0aGVudGljYXRpb24gYXR0ZW1wdHMgb3Igb3RoZXIgcHJvY2Vzc2luZyAoZXZlbiBzaW1wbGUg U1RVTiByZXF1ZXN0cykgYXJlIGEgd2FzdGUgb2YgcmVzb3VyY2VzIGFzIHRoYXQgcmVhbG0gd2ls bCBuZXZlciBiZSBzZXJ2aWNlZCBhbnl3YXkuDQoNCkluIHRlcm1zIG9mIHRyb3VibGVzaG9vdGlu Zywgd2l0aGluIGFuIGVudGVycHJpc2UgaXQgaXMgaGlnaGx5IHVzZWZ1bCB0byBsb29rIGF0IGlu c2lnaHQgZnJvbSBhbGwgdGhlIHBhcnRzIG9mIGEgc29sdXRpb24gYW5kIGlkZW50aWZ5IGluY29u c2lzdGVuY2VzLiAgQXMgYW4gZXhhbXBsZSBpZiBpdCBpcyBkaXNjb3ZlcmVkIHdoaWxlIGRlYnVn Z2luZyBhIGNvbW11bmljYXRpb25zIGZhaWx1cmUgdGhhdCBhIGJyb3dzZXIgaW5zaWRlIGFuIGVu dGVycHJpc2UgaXMgbHlpbmcgYWJvdXQgT1JJR0lOIGl0IG1heSBoZWxwIGluIHVuY292ZXJpbmcg dGhhdCB0aGUgYnJvd3NlciBoYXMgYmVlbiBjb21wcm9taXNlZCBieSBtYWx3YXJlLiAgRW50ZXJw cmlzZXMgY2FuIG5ldmVyIGhhdmUgdG9vIG11Y2ggaW5zaWdodCBpbiB0aGVpciBsb2dzIGZvciBz aG9ydCBwZXJpb2RzIG9mIHRpbWUgYXMgdGhhdCBpcyB3aGF0IHRoZXkgcmVseSBvbiB0byBkZWJ1 ZyBzb3BoaXN0aWNhdGVkIHN5c3RlbXMuICBKdXN0IGFzIGltcG9ydGFudGx5IGxvZyBkYXRhIGlz IG9mdGVuIHVzZWQgdG8ganVkZ2Ugc3lzdGVtIHVzYWdlIHRvIGhlbHAganVzdGlmeSBpbnZlc3Rp bmcgaW4gYWRkaXRpb25hbCByZXNvdXJjZXMgb3Igc3ByZWFkIGNvc3RzIHRvIHRoZSBhcHBsaWNh dGlvbnMgb3IgZGVwYXJ0bWVudHMgaW52b2x2ZWQuDQoNCklzIGFueSBvZiB0aGlzIGVudGVycHJp c2UgcGVyc3BlY3RpdmUgaGVscGZ1bCBvciBqdXN0IGFkZGluZyB0byB0aGUgY29uZnVzaW9uPyAg T25lIG9mIHRoZSBncmVhdCBwcm9taXNlcyBvZiBXZWJSVEMgaXMgdG8gYWxsb3cgc2ltcGxlciBz eXN0ZW1zIHdpdGhvdXQgYWxsIHRoZSBjb21wbGljYXRlZCB0ZWxlcGhvbnkgYXBwcm9hY2hlcyBm cm9tIHRoZSBwYXN0IGFuZCBjYXBpdGFsaXppbmcgb24gc2ltcGxlIHdlYi1jZW50cmljIGNvbmNl cHRzIGxpa2UgT1JJR0lOIGlzIG9uZSBncmVhdCBlbmFibGVyLiAgVGhpcyBkcmFmdCBldmVuIGV4 dGVuZHMgdGhlc2UgbW9yZSBtb2Rlcm4gY29uY2VwdHMgdG8gdGhpbmdzIGxpa2UgU0lQIHRvIGhl bHAgc2ltcGxpZnkgc29tZSBvZiB0aGUgbW9yZSBjb252ZW50aW9uYWwgdGVjaG5vbG9naWVzLg0K DQoNCkNoZWVycywNCkpvaG4NCg0KQVZBWUENCjEuOTE5LjQyNS44NDQ2IA0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbGlzc2EgQ29vcGVyIFttYWlsdG86YWxpc3NhQGNv b3BlcncuaW5dIA0KU2VudDogTW9uZGF5LCBNYXkgMTEsIDIwMTUgNzozMCBQTQ0KVG86IFRoZSBJ RVNHDQpDYzogdHJhbS1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdHJhbS1zdHVuLW9yaWdp bi5zaGVwaGVyZEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi10cmFtLXN0dW4tb3JpZ2luLmFkQGlldGYu b3JnOyBzcGVycmVhdWx0QGppdmUuY29tOyBkcmFmdC1pZXRmLXRyYW0tc3R1bi1vcmlnaW5AaWV0 Zi5vcmc7IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6IEFsaXNzYSBDb29wZXIncyBEaXNjdXNzIG9u IGRyYWZ0LWlldGYtdHJhbS1zdHVuLW9yaWdpbi0wNTogKHdpdGggRElTQ1VTUykNCg0KQWxpc3Nh IENvb3BlciBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRy YWZ0LWlldGYtdHJhbS1zdHVuLW9yaWdpbi0wNTogRGlzY3Vzcw0KDQpXaGVuIHJlc3BvbmRpbmcs IHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1h aWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUg dG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KUGxlYXNl IHJlZmVyIHRvIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX2llc2dfc3RhdGVtZW50X2Rpc2N1c3MtMkRjcml0ZXJpYS5odG1s JmQ9QXdJQ2FRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPU80T0l6QVc3RVZQeE9FaFlYemo3 RWcmbT1VVXc2dGxQWXdpUFRxVGlQYi04ZDBKelhBc2hVeXlNcWJFdmVaMUFQSHlnJnM9Ny1LeTNn QmtqLW5oNWxzektoOEEyVDVMS1Y5dFV1bTVRcEpLYk5VRlVlTSZlPQ0KZm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUg ZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5k IGhlcmU6DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkR0cmFtLTJEc3R1bi0y RG9yaWdpbl8mZD1Bd0lDYVEmYz1CRnBXUXc4YnN1S3BsMVNnaVpINjRRJnI9TzRPSXpBVzdFVlB4 T0VoWVh6ajdFZyZtPVVVdzZ0bFBZd2lQVHFUaVBiLThkMEp6WEFzaFV5eU1xYkV2ZVoxQVBIeWcm cz1xeUFOX2p5R1lhZnBQZ0ozSHhnOWJ5Ym8zVURPVUhvQ3hVVTJDWmhjcG1RJmU9IA0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KRElTQ1VTUzoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhpcyBpcyBhIGJpdCBv ZiBhIHdlaXJkIERJU0NVU1Mgc2luY2UgSSBkaWRuJ3QgbWFuYWdlIHRvIGJhbGxvdCB3aGVuIHRo ZQ0KZG9jdW1lbnQgd2FzIGZpcnN0IG9uIHRoZSBJRVNHJ3MgYWdlbmRhLCBzbyBJJ20gY29taW5n IGluIG1pZC1zdHJlYW0uDQoNCkkgc3VwcG9ydCBTdGVwaGVuJ3MgRElTQ1VTUy4gSWYgQWxhbidz IHByb3Bvc2VkIGNoYW5nZXMgbWFrZSBpdCBpbnRvIHRoZQ0KZG9jdW1lbnQsIHRoZXkgd291bGQg cmVzb2x2ZSBtb3N0IG9mIG15IGNvbmNlcm5zLiBIb3dldmVyLCBJIHN0aWxsIHNlZSBhDQpwcm9i bGVtIHdpdGggdGhpcyBwcm9wb3NlZCBuZXcgdGV4dDoNCg0KIkZvciBTVFVOIHJlcXVlc3RzIHNl bnQgd2l0aG91dCBhdXRoZW50aWNhdGlvbiB0byBhIFNUVU4gc2VydmVyIChpLmUuDQoNCiAgIFNU VU4gYmluZGluZyByZXF1ZXN0cyBzZW50IHRvIGEgU1RVTiBzZXJ2ZXIpLCB0aGUgU1RVTiBjbGll bnQgU0hPVUxEIA0KDQogICBpbmNsdWRlIHRoZSBPUklHSU4gYXR0cmlidXRlLiAgVGhlIE9SSUdJ TiBhdHRyaWJ1dGUgTVVTVCBOT1QgYmUNCmluY2x1ZGVkIA0KDQogICBpZiBpdCBpcyBhICJwcml2 YWN5LXNlbnNpdGl2ZSIgY29udGV4dCwgYXMgZGlzY3Vzc2VkIGluIHRoZSBTZWN1cml0eQ0KQ29u c2lkZXJhdGlvbnMNCg0KICAgc2VjdGlvbi4iDQoNCkZvciByZXF1ZXN0cyBzZW50IHdpdGggYXV0 aGVudGljYXRpb24sIEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBvcmlnaW4NCmF0dHJpYnV0ZSBuZWVk cyB0byBiZSBhY2N1cmF0ZSBpbiBvcmRlciBmb3IgdGhlIGNsaWVudCB0byBhdXRoZW50aWNhdGUu DQpJbiB0aG9zZSBjYXNlcywgdGhlIFNUVU4gc2VydmVyIGNhbiByZWx5IG9uIHRoZSBhdHRyaWJ1 dGUgaXQgcmVjZWl2ZXMuDQpCdXQgZm9yIHJlcXVlc3RzIHdpdGhvdXQgYXV0aGVudGljYXRpb24s IHdoYXQgcHJldmVudHMgdGhlIGNsaWVudCBmcm9tDQpseWluZz8gQW5kIGlmIHRob3NlIHJlcXVl c3RzIGFyZSBub3QgKEQpVExTLXByb3RlY3RlZCwgd2hhdCBwcmV2ZW50cyB0aGVtDQpmcm9tIGJl aW5nIG1vZGlmaWVkIGluIHRyYW5zaXQ/IEkgdW5kZXJzdGFuZCBBbGFuIHRvIGJlIHNheWluZyB0 aGF0IHRoZQ0KanVzdGlmaWNhdGlvbiBmb3IgdGhlIG9yaWdpbiBpbiB0aGlzIGNhc2UgaXMgb3Bl cmF0aW9uYWwgdHJvdWJsZXNob290aW5nLA0KYnV0IGlmIHRoZSBzZXJ2ZXIgY2FuJ3QgcmVseSBv biB0aGUgb3JpZ2luIGl0IHJlY2VpdmVzLCBkb2Vzbid0IHRoYXQgbWFrZQ0KaXQgcmlza3kgZm9y IHRoZSBzZXJ2ZXIgdG8gYWN0IG9uIHRoYXQgaW5mb3JtYXRpb24/DQoNCk15IGFkZGl0aW9uYWwg Y29uY2VybiBpcyBhYm91dCB0aGUgdXNlIG9mICJsb2dnaW5nIiBhcyBhIGp1c3RpZmljYXRpb24N CmZvciBpbmNsdWRpbmcgYW5kIG9yaWdpbiBhdHRyaWJ1dGUuIExvZ2dpbmcgaW4gYW5kIG9mIGl0 c2VsZiBpcyBub3QgYQ0KcmVhc29uYWJsZSBqdXN0aWZpY2F0aW9uLiBBbGFuJ3MgbWFpbCBkaXNj dXNzZWQgdGhlIHVzZSBvZiB0aGUgb3JpZ2luIGZvcg0Kb3BlcmF0aW9uYWwgdHJvdWJsZXNob290 aW5nLCB3aGljaCBzZWVtcyBsaWtlIHdoYXQgbWlnaHQgYWN0dWFsbHkgYmUNCmludGVuZGVkIGlu c3RlYWQgb2YgImxvZ2dpbmcuIiBJbiBhbnkgZXZlbnQgdGhlIHB1cnBvc2UgZm9yIHRoZSBsb2dn aW5nDQplaXRoZXIgbmVlZHMgdG8gYmUgZXhwbGFpbmVkIG9yICJsb2dnaW5nIiBzaG91bGQgbm90 IGJlIGxpc3RlZCBhcyBhDQpqdXN0aWZpY2F0aW9uLg0KDQoNCg0KDQo= From nobody Mon May 11 18:13:52 2015 Return-Path: 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 6AC441ACCD8; Mon, 11 May 2015 18:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Eoq5J7KHj86Z; Mon, 11 May 2015 18:13:49 -0700 (PDT) Received: from mail-vn0-x232.google.com (mail-vn0-x232.google.com [IPv6:2607:f8b0:400c:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24AE1A8992; Mon, 11 May 2015 18:13:48 -0700 (PDT) Received: by vnbg62 with SMTP id g62so10811527vnb.7; Mon, 11 May 2015 18:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xdfsQoIqS9kVJop7ZYQXq5BId69j8nCreiWJdZI0w/s=; b=qSP3/PnmwZ1ZkpntvuhIy0eLPxyfMCnVNQ/eJFYJVnuL6KLZmTvX8BnSbhUYDNpEWm pafNM34ivVmT3UQl2bKZo1E4Qcdz/XRJMV3QUQUhbj6K0F0kaKK2n782NrxRnPLY9wIj 73zHszfxzZfnz1GCrW0UMz7OMi/50mONIZvSOy8DKRlA0k+E+qBedSliFPp388Zuelqz Pt1wxkfPnP76KBWonGYbEaWmPDEw8j0j+ixs7onPQD+Y8OmtU1F1yE1uLS7cE+KtOcSh jnBch5af+qxAd/OVQGSS/cpes1Aav+AJfa8aN7QYAW8y/xzAS89XDs/lROMmK63udH+x MafQ== MIME-Version: 1.0 X-Received: by 10.52.240.137 with SMTP id wa9mr9556071vdc.97.1431393228035; Mon, 11 May 2015 18:13:48 -0700 (PDT) Received: by 10.52.106.100 with HTTP; Mon, 11 May 2015 18:13:47 -0700 (PDT) In-Reply-To: <554F9339.4090404@jive.com> References: <20150421153635.27696.5302.idtracker@ietfa.amsl.com> <554F461C.4040603@cs.tcd.ie> <554F9339.4090404@jive.com> Date: Mon, 11 May 2015 20:13:47 -0500 Message-ID: From: Alan Johnston To: Simon Perreault Content-Type: multipart/alternative; boundary=20cf30780daee41f4b0515d83476 Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, The IESG , draft-ietf-tram-stun-origin@ietf.org, Stephen Farrell Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 01:13:51 -0000 --20cf30780daee41f4b0515d83476 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stephen, Thanks for your reply. I agree with Simon on all points below. Especially the point about what if the browser lies about the ORIGIN. TURN requires an authentication credential. If you don't have this credential, lying about ORIGIN doesn't help you in any way shape or form. The workarounds and other solutions have been investigated, but the WG has moved forward with ORIGIN, and there is running code to backup this interest. Does this resolve your DISCUSS? - Alan - On Sun, May 10, 2015 at 12:19 PM, Simon Perreault wrote: > A few comments as shepherd and as a person involved in TRAM since before > the first bar BoF... > > Le 2015-05-10 07:50, Stephen Farrell a =C3=A9crit : > >> The purpose of this extension is not gathering analytics to monetize > >> people's WebRTC usage. > > > > Good to hear. Does it have that side-effect though? If so, oughtn't > > we think about that? And that still leaves me puzzled as to the > > mentions of "analytics" in the draft, which at least in my understandin= g > > of the term (admittedly not a very expert one) does involve using > > information to make money however one can. So while it's good to hear > > the above, my concerns are not fully assuaged. > > The way to implement multi-tenant servers currently, without ORIGIN, is > to dedicate one IP address per tenant. This is a pain point for a number > of reasons you can imagine. > > ORIGIN plays the same role as the Host header in HTTP: it allows virtual > hosting. I see the comparison with the Host header as more accurate than > with the Origin header. (One could also compare with the SNI extension > in TLS.) > > Therefore, ORIGIN does not enable more analytics than current practice > (i.e., dedicating one IP address per tenant). > > >> It is all about solving some pressing > >> authentication issues in today's STUN and TURN usage, and we have > running > >> code for both clients and servers today. > > > > For me, a consequence of the above would be that the scheme must not > > be trivially defeated by the browser telling lies. Otherwise you have > > not solved any authentication issue at all. > > I don't follow. If the browser lies, then authentication will fail. > Where's the problem? > > >> It's not productive to wait for some > >> other new authentication method to be finalized and perhaps deployed. > > > > Hmm. Since both are tram WG drafts, I assume this was discussed on the > > list. If so, can you point me at that thread. It seems odd to have two > > schemes for one thing, esp. with such different properties, and yet to > > not have the reasons for that being a good plan documented somewhere. > > (And I'd be fine with that being in meeting minutes, mails or whatever.= ) > > As far as I can remember, WG participants have agreed that both ORIGIN > and third-party-auth were necessary. I don't remember a list discussion > about this. People running servers now need to solve the multi-tenant > problem with the current authentication scheme. Moving to > third-party-auth is not always possible especially for non-WebRTC uses. > > As a concrete example, think of a multi-tenant server being used for > SIP. SIP clients could plausibly be modified to include the ORIGIN > attribute, but moving to third-party-auth is unthinkable. > > >> Consider the TURN usage. The most important use case of ORIGIN is to > help > >> the TURN server select the correct REALM for the authentication > challenge. > > > > Right. OTOH, one could also use the "user@realm" convention for the > > username in an authentication in some cases, but I agree that has it's > > downsides if it is forced into an existing authentication scheme. > > Yes, this is established practice as well, but not always possible, for > reasons you might guess. Dedicating one IP address per tenant is the > most generic and flexible workaround. > > > The > > upside is that this information is only sent during and not before > > authentication. > > Dedicating one IP address per tenant is the same as ORIGIN on this > aspect: the information is sent before authentication. > > > Since we are in any case changing things, that may be > > a better alternative. Were such ideas considered? > > Yes, most definitely. It is current practice, and it is a pain point. > > Simon > --20cf30780daee41f4b0515d83476 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stephen,

Thanks for your reply.=C2=A0 I= agree with Simon on all points below.=C2=A0

Espec= ially the point about what if the browser lies about the ORIGIN.=C2=A0 TURN= requires an authentication credential.=C2=A0 If you don't have this cr= edential, lying about ORIGIN doesn't help you in any way shape or form.=

The workarounds and other solutions have been inv= estigated, but the WG has moved forward with ORIGIN, and there is running c= ode to backup this interest.

Does this resolve you= r DISCUSS?

- Alan -

On Sun, May 10, 2015 at 12:19 PM, Simon Pe= rreault <sperreault@jive.com> wrote:
A few comments as shepherd and as a person involved in TRAM s= ince before
the first bar BoF...

Le 2015-05-10 07:50, Stephen Farrell a =C3=A9crit :
>> The purpose of this extension is not gathering analytics to moneti= ze
>> people's WebRTC usage.
>
> Good to hear. Does it have that side-effect though? If so, oughtn'= t
> we think about that? And that still leaves me puzzled as to the
> mentions of "analytics" in the draft, which at least in my u= nderstanding
> of the term (admittedly not a very expert one) does involve using
> information to make money however one can. So while it's good to h= ear
> the above, my concerns are not fully assuaged.

The way to implement multi-tenant servers currently, without ORIGIN, is
to dedicate one IP address per tenant. This is a pain point for a number of reasons you can imagine.

ORIGIN plays the same role as the Host header in HTTP: it allows virtual hosting. I see the comparison with the Host header as more accurate than with the Origin header. (One could also compare with the SNI extension
in TLS.)

Therefore, ORIGIN does not enable more analytics than current practice
(i.e., dedicating one IP address per tenant).

>> It is all about solving some pressing
>> authentication issues in today's STUN and TURN usage, and we h= ave running
>> code for both clients and servers today.
>
> For me, a consequence of the above would be that the scheme must not > be trivially defeated by the browser telling lies. Otherwise you have<= br> > not solved any authentication issue at all.

I don't follow. If the browser lies, then authentication will fail.
Where's the problem?

>> It's not productive to wait for some
>> other new authentication method to be finalized and perhaps deploy= ed.
>
> Hmm. Since both are tram WG drafts, I assume this was discussed on the=
> list. If so, can you point me at that thread. It seems odd to have two=
> schemes for one thing, esp. with such different properties, and yet to=
> not have the reasons for that being a good plan documented somewhere.<= br> > (And I'd be fine with that being in meeting minutes, mails or what= ever.)

As far as I can remember, WG participants have agreed that both ORIGIN
and third-party-auth were necessary. I don't remember a list discussion=
about this. People running servers now need to solve the multi-tenant
problem with the current authentication scheme. Moving to
third-party-auth is not always possible especially for non-WebRTC uses.

As a concrete example, think of a multi-tenant server being used for
SIP. SIP clients could plausibly be modified to include the ORIGIN
attribute, but moving to third-party-auth is unthinkable.

>> Consider the TURN usage.=C2=A0 The most important use case of ORIG= IN is to help
>> the TURN server select the correct REALM for the authentication ch= allenge.
>
> Right. OTOH, one could also use the "user@realm" convention = for the
> username in an authentication in some cases, but I agree that has it&#= 39;s
> downsides if it is forced into an existing authentication scheme.

Yes, this is established practice as well, but not always possible, for
reasons you might guess. Dedicating one IP address per tenant is the
most generic and flexible workaround.

> The
> upside is that this information is only sent during and not before
> authentication.

Dedicating one IP address per tenant is the same as ORIGIN on this
aspect: the information is sent before authentication.

> Since we are in any case changing things, that may be
> a better alternative. Were such ideas considered?

Yes, most definitely. It is current practice, and it is a pain point.

Simon

--20cf30780daee41f4b0515d83476-- From nobody Mon May 11 18:14:34 2015 Return-Path: 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 F16421A8992; Mon, 11 May 2015 18:14:30 -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 zVmo4SJ4FCpD; Mon, 11 May 2015 18:14:28 -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 0A4A61A1BA4; Mon, 11 May 2015 18:14:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4A281BED5; Tue, 12 May 2015 02:14:26 +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 LCi5ddJONZEY; Tue, 12 May 2015 02:14:25 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.109]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0FE72BEB5; Tue, 12 May 2015 02:14:25 +0100 (IST) Message-ID: <555153F0.4050204@cs.tcd.ie> Date: Tue, 12 May 2015 02:14:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alissa Cooper , Oleg Moskalenko References: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, Simon Perreault , IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 01:14:31 -0000 Hiya, On 12/05/15 01:43, Alissa Cooper wrote: >>> >>> if the client is lying, then the request will not be >>> authenticated and it will be rejected - because the client's >>> credentials will be incorrect. > > My question was about requests without authentication, as I said. I > assume the origin is not used for authentication in that case, since > authentication is not performed. > There's also this issue. If user credentials can collide over >1 "realm" (where authentication realm means in the HTTP basic/digest sense) then those are almost certainly human memorable (why else could they collide with non-negligible probability?) and in the case of STUN/TURN and, in particular, WebRTC, setting up to use human memorable credentials is just basically broken given that the humans aren't actually logging in to the STUN/TURN server. So I actually doubt the supposed security benefit even when the web-origin is pre-emptively sent as an authentication realm (in the HTTP basic/digest sense) just in case authentication with a STUN/TURN server is later required. And pre-emptively sending has the privacy downside that is recognised in the draft and as previously noted. Put another way: if a WebRTC server cannot arrange to use high entropy credentials with a STUN/TURN server then perhaps we're just promoting the wrong authentication scheme(s) and maybe also prioritising avoiding the wrong code changes? (Some code change being required in all cases.) So if there is a real reason why there ought be a well designed scheme for WebRTC with a non-negligible probability of credential collision then I'd like to hear about it. (I'm not saying that's impossible, but dumb old me can't figure it out;-) Or perhaps we're conflating user authentication with other protocol features (e.g. multi-tenant support) in a way that does unnecessarily damage privacy for users? S. From nobody Mon May 11 18:19:21 2015 Return-Path: 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 BAAD11B2B07; Mon, 11 May 2015 18:19:20 -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 HNok9bFsBe5H; Mon, 11 May 2015 18:19:18 -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 1085B1A8A7F; Mon, 11 May 2015 18:19:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BF97CBED5; Tue, 12 May 2015 02:19:16 +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 EHiJK7Iky_HT; Tue, 12 May 2015 02:19:15 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.19.109]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 078C8BEB5; Tue, 12 May 2015 02:19:15 +0100 (IST) Message-ID: <55515512.2060705@cs.tcd.ie> Date: Tue, 12 May 2015 02:19:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alan Johnston , Simon Perreault References: <20150421153635.27696.5302.idtracker@ietfa.amsl.com> <554F461C.4040603@cs.tcd.ie> <554F9339.4090404@jive.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, The IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 01:19:20 -0000 Hi Alan, On 12/05/15 02:13, Alan Johnston wrote: > Stephen, > > Thanks for your reply. I agree with Simon on all points below. Well yes and no. I don't doubt the IP-per-tenant setup he describes nor the downsides of that. I very much do doubt that the existence of bad-approach-X means that the WG has to adopt an approach that is equally bad from the privacy perspective. > > Especially the point about what if the browser lies about the ORIGIN. TURN > requires an authentication credential. If you don't have this credential, > lying about ORIGIN doesn't help you in any way shape or form. > > The workarounds and other solutions have been investigated, but the WG has > moved forward with ORIGIN, and there is running code to backup this > interest. > > Does this resolve your DISCUSS? Sorry no. I think this one requires some higher bandwidth (or more extended;-) discussion. I'm sure we'll get there though. S. > > - Alan - > > On Sun, May 10, 2015 at 12:19 PM, Simon Perreault > wrote: > >> A few comments as shepherd and as a person involved in TRAM since before >> the first bar BoF... >> >> Le 2015-05-10 07:50, Stephen Farrell a écrit : >>>> The purpose of this extension is not gathering analytics to monetize >>>> people's WebRTC usage. >>> >>> Good to hear. Does it have that side-effect though? If so, oughtn't >>> we think about that? And that still leaves me puzzled as to the >>> mentions of "analytics" in the draft, which at least in my understanding >>> of the term (admittedly not a very expert one) does involve using >>> information to make money however one can. So while it's good to hear >>> the above, my concerns are not fully assuaged. >> >> The way to implement multi-tenant servers currently, without ORIGIN, is >> to dedicate one IP address per tenant. This is a pain point for a number >> of reasons you can imagine. >> >> ORIGIN plays the same role as the Host header in HTTP: it allows virtual >> hosting. I see the comparison with the Host header as more accurate than >> with the Origin header. (One could also compare with the SNI extension >> in TLS.) >> >> Therefore, ORIGIN does not enable more analytics than current practice >> (i.e., dedicating one IP address per tenant). >> >>>> It is all about solving some pressing >>>> authentication issues in today's STUN and TURN usage, and we have >> running >>>> code for both clients and servers today. >>> >>> For me, a consequence of the above would be that the scheme must not >>> be trivially defeated by the browser telling lies. Otherwise you have >>> not solved any authentication issue at all. >> >> I don't follow. If the browser lies, then authentication will fail. >> Where's the problem? >> >>>> It's not productive to wait for some >>>> other new authentication method to be finalized and perhaps deployed. >>> >>> Hmm. Since both are tram WG drafts, I assume this was discussed on the >>> list. If so, can you point me at that thread. It seems odd to have two >>> schemes for one thing, esp. with such different properties, and yet to >>> not have the reasons for that being a good plan documented somewhere. >>> (And I'd be fine with that being in meeting minutes, mails or whatever.) >> >> As far as I can remember, WG participants have agreed that both ORIGIN >> and third-party-auth were necessary. I don't remember a list discussion >> about this. People running servers now need to solve the multi-tenant >> problem with the current authentication scheme. Moving to >> third-party-auth is not always possible especially for non-WebRTC uses. >> >> As a concrete example, think of a multi-tenant server being used for >> SIP. SIP clients could plausibly be modified to include the ORIGIN >> attribute, but moving to third-party-auth is unthinkable. >> >>>> Consider the TURN usage. The most important use case of ORIGIN is to >> help >>>> the TURN server select the correct REALM for the authentication >> challenge. >>> >>> Right. OTOH, one could also use the "user@realm" convention for the >>> username in an authentication in some cases, but I agree that has it's >>> downsides if it is forced into an existing authentication scheme. >> >> Yes, this is established practice as well, but not always possible, for >> reasons you might guess. Dedicating one IP address per tenant is the >> most generic and flexible workaround. >> >>> The >>> upside is that this information is only sent during and not before >>> authentication. >> >> Dedicating one IP address per tenant is the same as ORIGIN on this >> aspect: the information is sent before authentication. >> >>> Since we are in any case changing things, that may be >>> a better alternative. Were such ideas considered? >> >> Yes, most definitely. It is current practice, and it is a pain point. >> >> Simon >> > From nobody Mon May 11 19:10:52 2015 Return-Path: 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 0B11A1B2B6F; Mon, 11 May 2015 19:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 DEyEiBLLS_1d; Mon, 11 May 2015 19:10:49 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8868C1B2B5C; Mon, 11 May 2015 19:10:48 -0700 (PDT) Received: by labbd9 with SMTP id bd9so106389692lab.2; Mon, 11 May 2015 19:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dSM0TrAwGNKWE6cedxcEmi54yTkZQmCSKuUsvyVX5Z4=; b=zzG8BN6F4H4K8i5yrv3RDaMbyG/1TmQ2zlzZ36nU0kK/3vtbQ+0aVnIeVSUGJnDtxE /HZHArFRmuoikQiQSdBW1ePzYexflLHfCGXog1pCXwb3aWk/IIEqHSIXydU54otpWoKK GA7H5gt96Wuu1Xcb1FA0XA28kfRRDzSZKs95afqcPeaq0fUoexbDabrNmITNdqSCzhU7 gxZ7xUzgGvlWFk7LMC9eEskGIgGakck6GTURRzsG2l8TQjJ0ArtKPOvubjt7nWDSDrNf jQzdSkqWvjOrkPcCMeHx7sf88wmsdkKjVicN7emF7Hb0JCYHrmkuIAlx4IUSRiTyS4Ea lkmQ== MIME-Version: 1.0 X-Received: by 10.112.202.234 with SMTP id kl10mr10074609lbc.51.1431396647017; Mon, 11 May 2015 19:10:47 -0700 (PDT) Received: by 10.152.129.3 with HTTP; Mon, 11 May 2015 19:10:46 -0700 (PDT) In-Reply-To: <55515512.2060705@cs.tcd.ie> References: <20150421153635.27696.5302.idtracker@ietfa.amsl.com> <554F461C.4040603@cs.tcd.ie> <554F9339.4090404@jive.com> <55515512.2060705@cs.tcd.ie> Date: Mon, 11 May 2015 21:10:46 -0500 Message-ID: From: Spencer Dawkins at IETF To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c367ecada25d0515d900f9 Archived-At: Cc: "tram-chairs@ietf.org" , "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, Simon Perreault , The IESG , draft-ietf-tram-stun-origin@ietf.org, Alan Johnston Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 02:10:52 -0000 --001a11c367ecada25d0515d900f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, On Mon, May 11, 2015 at 8:19 PM, Stephen Farrell wrote: > > Hi Alan, > > On 12/05/15 02:13, Alan Johnston wrote: > > Stephen, > > > > Thanks for your reply. I agree with Simon on all points below. > > Well yes and no. I don't doubt the IP-per-tenant setup he describes > nor the downsides of that. > > I very much do doubt that the existence of bad-approach-X means that > the WG has to adopt an approach that is equally bad from the privacy > perspective. > > > > > Especially the point about what if the browser lies about the ORIGIN. > TURN > > requires an authentication credential. If you don't have this > credential, > > lying about ORIGIN doesn't help you in any way shape or form. > > > > The workarounds and other solutions have been investigated, but the WG > has > > moved forward with ORIGIN, and there is running code to backup this > > interest. > > > > Does this resolve your DISCUSS? > > Sorry no. I think this one requires some higher bandwidth (or more > extended;-) discussion. I'm sure we'll get there though. Are we all talking about keeping the same information private from the same entities? I'm not sure about that. Thanks, Spencer > S. > > > > > > - Alan - > > > > On Sun, May 10, 2015 at 12:19 PM, Simon Perreault > > wrote: > > > >> A few comments as shepherd and as a person involved in TRAM since befo= re > >> the first bar BoF... > >> > >> Le 2015-05-10 07:50, Stephen Farrell a =C3=A9crit : > >>>> The purpose of this extension is not gathering analytics to monetize > >>>> people's WebRTC usage. > >>> > >>> Good to hear. Does it have that side-effect though? If so, oughtn't > >>> we think about that? And that still leaves me puzzled as to the > >>> mentions of "analytics" in the draft, which at least in my > understanding > >>> of the term (admittedly not a very expert one) does involve using > >>> information to make money however one can. So while it's good to hear > >>> the above, my concerns are not fully assuaged. > >> > >> The way to implement multi-tenant servers currently, without ORIGIN, i= s > >> to dedicate one IP address per tenant. This is a pain point for a numb= er > >> of reasons you can imagine. > >> > >> ORIGIN plays the same role as the Host header in HTTP: it allows virtu= al > >> hosting. I see the comparison with the Host header as more accurate th= an > >> with the Origin header. (One could also compare with the SNI extension > >> in TLS.) > >> > >> Therefore, ORIGIN does not enable more analytics than current practice > >> (i.e., dedicating one IP address per tenant). > >> > >>>> It is all about solving some pressing > >>>> authentication issues in today's STUN and TURN usage, and we have > >> running > >>>> code for both clients and servers today. > >>> > >>> For me, a consequence of the above would be that the scheme must not > >>> be trivially defeated by the browser telling lies. Otherwise you have > >>> not solved any authentication issue at all. > >> > >> I don't follow. If the browser lies, then authentication will fail. > >> Where's the problem? > >> > >>>> It's not productive to wait for some > >>>> other new authentication method to be finalized and perhaps deployed= . > >>> > >>> Hmm. Since both are tram WG drafts, I assume this was discussed on th= e > >>> list. If so, can you point me at that thread. It seems odd to have tw= o > >>> schemes for one thing, esp. with such different properties, and yet t= o > >>> not have the reasons for that being a good plan documented somewhere. > >>> (And I'd be fine with that being in meeting minutes, mails or > whatever.) > >> > >> As far as I can remember, WG participants have agreed that both ORIGIN > >> and third-party-auth were necessary. I don't remember a list discussio= n > >> about this. People running servers now need to solve the multi-tenant > >> problem with the current authentication scheme. Moving to > >> third-party-auth is not always possible especially for non-WebRTC uses= . > >> > >> As a concrete example, think of a multi-tenant server being used for > >> SIP. SIP clients could plausibly be modified to include the ORIGIN > >> attribute, but moving to third-party-auth is unthinkable. > >> > >>>> Consider the TURN usage. The most important use case of ORIGIN is t= o > >> help > >>>> the TURN server select the correct REALM for the authentication > >> challenge. > >>> > >>> Right. OTOH, one could also use the "user@realm" convention for the > >>> username in an authentication in some cases, but I agree that has it'= s > >>> downsides if it is forced into an existing authentication scheme. > >> > >> Yes, this is established practice as well, but not always possible, fo= r > >> reasons you might guess. Dedicating one IP address per tenant is the > >> most generic and flexible workaround. > >> > >>> The > >>> upside is that this information is only sent during and not before > >>> authentication. > >> > >> Dedicating one IP address per tenant is the same as ORIGIN on this > >> aspect: the information is sent before authentication. > >> > >>> Since we are in any case changing things, that may be > >>> a better alternative. Were such ideas considered? > >> > >> Yes, most definitely. It is current practice, and it is a pain point. > >> > >> Simon > >> > > > --001a11c367ecada25d0515d900f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

On Mon, May 11, 2015 at 8:19 PM, Stephen Farrell <stephen= .farrell@cs.tcd.ie> wrote:
=
Hi Alan,

On 12/05/15 02:13, Alan Johnston wrote:
> Stephen,
>
> Thanks for your reply.=C2=A0 I agree with Simon on all points below.
Well yes and no. I don't doubt the IP-per-tenant setup he descri= bes
nor the downsides of that.

I very much do doubt that the existence of bad-approach-X means that
the WG has to adopt an approach that is equally bad from the privacy
perspective.

>
> Especially the point about what if the browser lies about the ORIGIN.= =C2=A0 TURN
> requires an authentication credential.=C2=A0 If you don't have thi= s credential,
> lying about ORIGIN doesn't help you in any way shape or form.
>
> The workarounds and other solutions have been investigated, but the WG= has
> moved forward with ORIGIN, and there is running code to backup this > interest.
>
> Does this resolve your DISCUSS?

Sorry no. I think this one requires some higher bandwidth (or more extended;-) discussion. I'm sure we'll get there though.

Are we all talking about keeping the same information= private from the same entities? I'm not sure about that.
Thanks,

Spencer
=C2=A0
=
S.


>
> - Alan -
>
> On Sun, May 10, 2015 at 12:19 PM, Simon Perreault <sperreault@jive.com>
> wrote:
>
>> A few comments as shepherd and as a person involved in TRAM since = before
>> the first bar BoF...
>>
>> Le 2015-05-10 07:50, Stephen Farrell a =C3=A9crit :
>>>> The purpose of this extension is not gathering analytics t= o monetize
>>>> people's WebRTC usage.
>>>
>>> Good to hear. Does it have that side-effect though? If so, oug= htn't
>>> we think about that? And that still leaves me puzzled as to th= e
>>> mentions of "analytics" in the draft, which at least= in my understanding
>>> of the term (admittedly not a very expert one) does involve us= ing
>>> information to make money however one can. So while it's g= ood to hear
>>> the above, my concerns are not fully assuaged.
>>
>> The way to implement multi-tenant servers currently, without ORIGI= N, is
>> to dedicate one IP address per tenant. This is a pain point for a = number
>> of reasons you can imagine.
>>
>> ORIGIN plays the same role as the Host header in HTTP: it allows v= irtual
>> hosting. I see the comparison with the Host header as more accurat= e than
>> with the Origin header. (One could also compare with the SNI exten= sion
>> in TLS.)
>>
>> Therefore, ORIGIN does not enable more analytics than current prac= tice
>> (i.e., dedicating one IP address per tenant).
>>
>>>> It is all about solving some pressing
>>>> authentication issues in today's STUN and TURN usage, = and we have
>> running
>>>> code for both clients and servers today.
>>>
>>> For me, a consequence of the above would be that the scheme mu= st not
>>> be trivially defeated by the browser telling lies. Otherwise y= ou have
>>> not solved any authentication issue at all.
>>
>> I don't follow. If the browser lies, then authentication will = fail.
>> Where's the problem?
>>
>>>> It's not productive to wait for some
>>>> other new authentication method to be finalized and perhap= s deployed.
>>>
>>> Hmm. Since both are tram WG drafts, I assume this was discusse= d on the
>>> list. If so, can you point me at that thread. It seems odd to = have two
>>> schemes for one thing, esp. with such different properties, an= d yet to
>>> not have the reasons for that being a good plan documented som= ewhere.
>>> (And I'd be fine with that being in meeting minutes, mails= or whatever.)
>>
>> As far as I can remember, WG participants have agreed that both OR= IGIN
>> and third-party-auth were necessary. I don't remember a list d= iscussion
>> about this. People running servers now need to solve the multi-ten= ant
>> problem with the current authentication scheme. Moving to
>> third-party-auth is not always possible especially for non-WebRTC = uses.
>>
>> As a concrete example, think of a multi-tenant server being used f= or
>> SIP. SIP clients could plausibly be modified to include the ORIGIN=
>> attribute, but moving to third-party-auth is unthinkable.
>>
>>>> Consider the TURN usage.=C2=A0 The most important use case= of ORIGIN is to
>> help
>>>> the TURN server select the correct REALM for the authentic= ation
>> challenge.
>>>
>>> Right. OTOH, one could also use the "user@realm" con= vention for the
>>> username in an authentication in some cases, but I agree that = has it's
>>> downsides if it is forced into an existing authentication sche= me.
>>
>> Yes, this is established practice as well, but not always possible= , for
>> reasons you might guess. Dedicating one IP address per tenant is t= he
>> most generic and flexible workaround.
>>
>>> The
>>> upside is that this information is only sent during and not be= fore
>>> authentication.
>>
>> Dedicating one IP address per tenant is the same as ORIGIN on this=
>> aspect: the information is sent before authentication.
>>
>>> Since we are in any case changing things, that may be
>>> a better alternative. Were such ideas considered?
>>
>> Yes, most definitely. It is current practice, and it is a pain poi= nt.
>>
>> Simon
>>
>

--001a11c367ecada25d0515d900f9-- From nobody Tue May 12 06:36:11 2015 Return-Path: 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 53B4F1A870D; Tue, 12 May 2015 06:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3QmhQzFnAC9J; Tue, 12 May 2015 06:36:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DA31A86E0; Tue, 12 May 2015 06:36:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150512133607.26808.51688.idtracker@ietfa.amsl.com> Date: Tue, 12 May 2015 06:36:07 -0700 Archived-At: Cc: tram-chairs@ietf.org, tram@ietf.org, draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, sperreault@jive.com, tjc@ecs.soton.ac.uk, draft-ietf-tram-stun-origin@ietf.org Subject: [tram] Benoit Claise's No Objection on draft-ietf-tram-stun-origin-05: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 13:36:09 -0000 Benoit Claise has entered the following ballot position for draft-ietf-tram-stun-origin-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Here is Tim Chown's OPS DIR review, along the same lines as Stephen and Alissa's DISCUSSES. The feedback was sent to the authors on April 22nd, and I have not seen any reply so far. Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I would summarise this document as being Not Ready. My concern with the draft lies with privacy aspects. While the area is not one that I am particularly familiar with, but there would seem to be additional potential exposure through this method, and the language of the draft seems at odds with the language in RFC6454 (Section 7.3). I would therefore urge the AD to review this aspect, and to determine whether the utility of the draft outweighs the privacy concerns, and if it does, that appropriate privacy ‘knobs’ are included for those who are ‘privacy-sensitive’ (in the language of RFC6454). I think the rationale and tradeoffs could be more clearly stated in the document. With recent passive pervasive monitoring threats, the IETF is now supposed to be considering whether given information *needs* to be transmitted in any given protocol. Would I as a user, for example, be able to toggle a setting that would mean my ORIGIN would always be “nullâ€, as per RFC6454 section 7.3? Is the use of ORIGIN *required*, or is it just ‘desirable’? Would my application fail, or not? It appears from Section 1 that its inclusion is ‘useful’, but not required. Section 4 talks of TLS for avoiding eavesdropping of ORIGIN in STUN messages, but the privacy concern is not necessarily only with transmission of the information. I think here paragraph 3 of Section 4 is at odds with RFC6454 Section 7.3 - with this draft saying MAY wrt use of a “null†Origin, and RFC6454 saying MUST for use of “nullâ€. The same applies to the end of the last paragraph in Section 4 as well. The draft should probably use the ‘privacy-senstive’ context terminology of RFC6454, as per Section 7.3, and describe how the user can influence the privacy settings where they which to maximise their privacy. Tim ===================================================== A point of detail, really, if you update the draft. For a web application provider STUN or TURN server, the server will have no idea which web pages or sites are sending binding requests to the service. In conventional applications, the SOFTWARE attribute would provide some identifying information to the service, but that no longer works when the browser is the application. SOFTWARE attribute: a reference to http://tools.ietf.org/html/rfc5389#section-15.10 would be beneficial From nobody Tue May 12 06:43:09 2015 Return-Path: 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 ; 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 ; 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 ; 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 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)" , Stephen Farrell , "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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. From nobody Tue May 12 09:02:37 2015 Return-Path: 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 3808F1A8F45 for ; Tue, 12 May 2015 09:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 kd432RA8Ebx0 for ; Tue, 12 May 2015 09:02:32 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D791ACD75 for ; Tue, 12 May 2015 09:02:29 -0700 (PDT) Received: by qgdy78 with SMTP id y78so6659160qgd.0 for ; Tue, 12 May 2015 09:02:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zkmJ2OiuWb9fhWj3F2gOjDznfxnlb67lD30R6C5KpNU=; b=BvTIcvtaaXxLkPhU1c7q5/yHaRjlc+RlZH3YmAIrbLQcEgRmt7Yd8cH5ME9Y2A7Cl1 K/TPUCdhhN6CDYISbJDttBXAGcyEn+2zsLXgqV6C5ue050RVjaBs7yDkzkfLk36mlYSa BWO+g5vLx5HgQNyeXy6RRBwr05SnRWzX7JxLVFMUOTPhT/DfLjehY7pVfaz9oRc6tzFi ktbG3W4EHAzpUstQYwYonsRmz4HvVlr3dy0HcV4+hDwuBM78a346P5+PXALMAKPwWbLH OY5BGumquML1MFk+lY6Bnd1a+LIusQdEB9QsCoCOup9mKol6aXlw3ywJtJPWAiNaJmdZ 2QUg== X-Gm-Message-State: ALoCoQlW8uwHXNARuO6A3PY/d5ACNLaE/98moyjDLwzQkd70bchSEcgazU+cAquMdQ9ii6D6JWcC X-Received: by 10.55.31.137 with SMTP id n9mr34480605qkh.91.1431446548617; Tue, 12 May 2015 09:02:28 -0700 (PDT) Received: from [192.168.1.131] ([24.53.47.130]) by mx.google.com with ESMTPSA id f9sm13500235qhe.34.2015.05.12.09.02.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2015 09:02:27 -0700 (PDT) Message-ID: <55522411.10104@jive.com> Date: Tue, 12 May 2015 12:02:25 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , Alissa Cooper , Oleg Moskalenko References: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> <555153F0.4050204@cs.tcd.ie> In-Reply-To: <555153F0.4050204@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 16:02:33 -0000 Le 2015-05-11 21:14, Stephen Farrell a écrit : > There's also this issue. If user credentials can collide over >1 > "realm" (where authentication realm means in the HTTP basic/digest > sense) then those are almost certainly human memorable (why else > could they collide with non-negligible probability?) and in the > case of STUN/TURN and, in particular, WebRTC, setting up to use > human memorable credentials is just basically broken given that > the humans aren't actually logging in to the STUN/TURN server. In the case where a single entity controls the authentication databases for all tenants of a single server, you're right. However, that condition does not hold in general. That is, we really do need to properly handle username collisions across realms. That is a pain point that is currently being handled with a number of operational hacks. Clever username generation is one of them. It does work for some use cases, but not in general. What you're describing is current practice, and we don't like it. I'd appreciate if we could recognize that there is a problem with current practice, and actually discuss the merits of the ORIGIN solution. I understand the privacy concerns, but I don't get two things: 1) Are those concerns identical or different from those applying to, e.g., the Host HTTP header, or the SNI TLS extension? If they're different, how are they different? 2) Is there a proposal that could fix the privacy issue? So far I've seen IESG members pointing out the issue, authors acknowledging the issue, but no discussion of solutions. Simon From nobody Tue May 12 09:10:02 2015 Return-Path: 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 355641ACD7E for ; Tue, 12 May 2015 09:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 CCJEtWnp8a6X for ; Tue, 12 May 2015 09:09:56 -0700 (PDT) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09041ACD75 for ; Tue, 12 May 2015 09:09:55 -0700 (PDT) Received: by qkgx75 with SMTP id x75so8958622qkg.1 for ; Tue, 12 May 2015 09:09:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=olnXdocw9ecl3iZOLDFf46J1I4r4KLEDo6k1pPwGxuc=; b=ET97yes+wNuTrscg4XjBn3FnMhVwQV+yNErbKeIuMqQ28Hx/eim88K8h+S59FrpeG3 AUxoZBbhcBpgXId7AXmbq/whuFexoXXtj8OCdtiY8hkdJ7z8Mgjb34SQwb+pE6crHFst 2ZaXWfsUFZUwIqOJ8prYrvoUrQYVSNyzys4CKWpqyXTLl6WdULRXeihRKn9HsHjtMJS3 IT+2h5vpuwQZR6YCdtp0W0lo7OzP8rd8Fe/kOgQx5Dq61a1U9GCeeiY/8GdmdBL8Yyna 924iRtV9CkyygdyDX9nETQ4lZxHIlKvp2e6x/ljq0TPNEY3ZGBLTgDPXvHQlVk0g2Jxj SIrA== X-Gm-Message-State: ALoCoQmpogw7ZiSDspYWwDLsBCPbFAxLSnUwkqTURYN8u1MoppwDfUANcvo2Cla5oNOzIiVLPj9F X-Received: by 10.140.86.47 with SMTP id o44mr20602546qgd.98.1431446994985; Tue, 12 May 2015 09:09:54 -0700 (PDT) Received: from [192.168.1.131] ([24.53.47.130]) by mx.google.com with ESMTPSA id x142sm13501560qkx.28.2015.05.12.09.09.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2015 09:09:54 -0700 (PDT) Message-ID: <555225CF.9040904@jive.com> Date: Tue, 12 May 2015 12:09:51 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alissa Cooper , The IESG References: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> In-Reply-To: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram-chairs@ietf.org, draft-ietf-tram-stun-origin.shepherd@ietf.org, tram@ietf.org, draft-ietf-tram-stun-origin@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org Subject: Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 16:09:57 -0000 Le 2015-05-11 19:30, Alissa Cooper a écrit : > For requests sent with authentication, I understand that the origin > attribute needs to be accurate in order for the client to authenticate. > In those cases, the STUN server can rely on the attribute it receives. > But for requests without authentication, what prevents the client from > lying? Note that the client does not know in advance whether its request is going to be authenticated or not. Although I supposes it could try to guess, or maybe re-try the request without lying when it receives an authentication challenge. > And if those requests are not (D)TLS-protected, what prevents them > from being modified in transit? Nothing. Per STUN design. Unauthenticated requests cannot be trusted. The server operator can require authentication if trust is a problem. > I understand Alan to be saying that the > justification for the origin in this case is operational troubleshooting, > but if the server can't rely on the origin it receives, doesn't that make > it risky for the server to act on that information? Note that this concern applies to all other pieces of information contained in unauthenticated STUN requests. Simon From nobody Tue May 12 09:12:32 2015 Return-Path: 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 50A3B1ACD68 for ; Tue, 12 May 2015 09:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 CMsqGshDu51D for ; Tue, 12 May 2015 09:12:30 -0700 (PDT) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0A91ACD79 for ; Tue, 12 May 2015 09:12:28 -0700 (PDT) Received: by qkgy4 with SMTP id y4so9000449qkg.2 for ; Tue, 12 May 2015 09:12:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PgIA/gPfgaaluCXgj9ps6Tv5EhY8vzUiLO5jn9YpCy8=; b=R6XAN+Qk5aIobg9W3293v+qzZ1ujeKsqt4Pp4Q7E4V73S1MVIBKCrQ24pdVhK6O4Gr bAkf639MFbjjYNjPVNmCwgvdNYaKIdAXhRXyiKPrluyo8T3EZ1JPNJAgFmy2SwM96ban WyN03Qnjt219ETIUY3rV7ZU+gD1YjmlyKXp/7hLq9Ir6cJ7RsXxWArl0lB2tUlDtf1xw cPWkF+0XkscLFbmDc9uviBNVr9Fw+l9xJwvY/j2zm6qqARCUkogx/vy4w1KTEXixzjT0 R5v6cj0EpVyfP9zVf/Ul61Mt2M93OCsy6t+PoJitnwsXP9BCnhZg5Wc22oqS0UhiElvS rpHg== X-Gm-Message-State: ALoCoQkOknDt4WCCXwJCMZGk6AFAGybJENTl1xKAunZhpsiXKE6zqe1JtGvKsI6WYhJiChITmzWz X-Received: by 10.140.96.119 with SMTP id j110mr20314353qge.22.1431447147635; Tue, 12 May 2015 09:12:27 -0700 (PDT) Received: from [192.168.1.131] ([24.53.47.130]) by mx.google.com with ESMTPSA id b5sm407416qkh.36.2015.05.12.09.12.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2015 09:12:26 -0700 (PDT) Message-ID: <55522669.80607@jive.com> Date: Tue, 12 May 2015 12:12:25 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , Alan Johnston References: <20150421153635.27696.5302.idtracker@ietfa.amsl.com> <554F461C.4040603@cs.tcd.ie> <554F9339.4090404@jive.com> <55515512.2060705@cs.tcd.ie> In-Reply-To: <55515512.2060705@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, The IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 16:12:31 -0000 Le 2015-05-11 21:19, Stephen Farrell a écrit : > Sorry no. I think this one requires some higher bandwidth (or more > extended;-) discussion. So, uh, what is normal procedure in this case? Should we set up a conference call? Simon From nobody Tue May 12 09:42:10 2015 Return-Path: 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 AE6F21A8AF6; Tue, 12 May 2015 09:42:08 -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 ZVIyxxYne2xS; Tue, 12 May 2015 09:42:00 -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 7A1A71A87E9; Tue, 12 May 2015 09:42:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 39F3BBEAA; Tue, 12 May 2015 17:41:59 +0100 (IST) 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 aiydlj1AUW3H; Tue, 12 May 2015 17:41:59 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0F2F7BE8E; Tue, 12 May 2015 17:41:59 +0100 (IST) Message-ID: <55522D57.8090009@cs.tcd.ie> Date: Tue, 12 May 2015 17:41:59 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Simon Perreault , Alissa Cooper , Oleg Moskalenko References: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> <555153F0.4050204@cs.tcd.ie> <55522411.10104@jive.com> In-Reply-To: <55522411.10104@jive.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 16:42:08 -0000 On 12/05/15 17:02, Simon Perreault wrote: > Le 2015-05-11 21:14, Stephen Farrell a écrit : >> There's also this issue. If user credentials can collide over >1 >> "realm" (where authentication realm means in the HTTP basic/digest >> sense) then those are almost certainly human memorable (why else >> could they collide with non-negligible probability?) and in the >> case of STUN/TURN and, in particular, WebRTC, setting up to use >> human memorable credentials is just basically broken given that >> the humans aren't actually logging in to the STUN/TURN server. > > In the case where a single entity controls the authentication databases > for all tenants of a single server, you're right. However, that > condition does not hold in general. That is, we really do need to > properly handle username collisions across realms. Sorry, I'm really not getting that. It is not a name for a person, at least in WebRTC, right? It is some name agreed between the WebRTC JS code and the TURN server. And I'd hope it ought change frequently if it matters at all or else it'll be scraped from the JS (or debug tooling). > > That is a pain point that is currently being handled with a number of > operational hacks. Clever username generation is one of them. It does > work for some use cases, but not in general. > > What you're describing is current practice, and we don't like it. > > I'd appreciate if we could recognize that there is a problem with > current practice, I believe I did that already. > and actually discuss the merits of the ORIGIN > solution. I understand the privacy concerns, but I don't get two things: > > 1) Are those concerns identical or different from those applying to, > e.g., the Host HTTP header, or the SNI TLS extension? If they're > different, how are they different? They may or may not be different but doing something better also may or may not be more tractable. And the world has changed since e.g. SNI was defined. (There is also desire to hide SNI in the TLS 1.3 handshake if possible. We don't know if it will be possible or not but the desire is there and is real.) > > 2) Is there a proposal that could fix the privacy issue? So far I've > seen IESG members pointing out the issue, authors acknowledging the > issue, but no discussion of solutions. >From my POV, that is the discussion we are having and that is not yet done. S. > > Simon > From nobody Tue May 12 09:43:10 2015 Return-Path: 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 B3E351A8F37; Tue, 12 May 2015 09:43:08 -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 eulI3KgMopYe; Tue, 12 May 2015 09:43:07 -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 19B231A8AF6; Tue, 12 May 2015 09:43:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BDE19BECF; Tue, 12 May 2015 17:43:04 +0100 (IST) 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 ChejT-HYvABJ; Tue, 12 May 2015 17:43:04 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 945A8BE8E; Tue, 12 May 2015 17:43:04 +0100 (IST) Message-ID: <55522D98.5040404@cs.tcd.ie> Date: Tue, 12 May 2015 17:43:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Simon Perreault , Alan Johnston References: <20150421153635.27696.5302.idtracker@ietfa.amsl.com> <554F461C.4040603@cs.tcd.ie> <554F9339.4090404@jive.com> <55515512.2060705@cs.tcd.ie> <55522669.80607@jive.com> In-Reply-To: <55522669.80607@jive.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, The IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 16:43:08 -0000 On 12/05/15 17:12, Simon Perreault wrote: > Le 2015-05-11 21:19, Stephen Farrell a écrit : >> Sorry no. I think this one requires some higher bandwidth (or more >> extended;-) discussion. > > So, uh, what is normal procedure in this case? Should we set up a > conference call? It'll be discussed on this Thursday's IESG telechat is the next step. We may end up with some concall being needed, bit early to say (I'd guess) but Spencer as responsible AD will drive that along. S. > > Simon > From nobody Tue May 12 10:00:21 2015 Return-Path: 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 40B441ACD0E for ; Tue, 12 May 2015 10:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 6cT_8u337kgC for ; Tue, 12 May 2015 10:00:10 -0700 (PDT) Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45B01ACD14 for ; Tue, 12 May 2015 10:00:03 -0700 (PDT) Received: by qkgx75 with SMTP id x75so10044749qkg.1 for ; Tue, 12 May 2015 10:00:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nKMvnqRpEjB1zvbGQUGnXLAOsFNf0QEY+/cO0lMwrAg=; b=R+Drp1E65K3UogwAWGwa0nLV69Ldpqjwkh27EumwUQXGEFT2xq98f528iwpWQQcUlN ejmXQMC3wMsV93cIipmDeExzMOwtGnra4KXvjStXnnOXy8I75qkLRC8kHAEYNnqcqTtQ LoXaLriqqI7E51faHpckt+gDFoUACfE3GyFIITgWTKEyjn3cYn/YG7nCNGMHUv1uJyee 3nxS9F/PUz3MaMlEQpMcuA4JjqUBbgjamtGlAaGmGhJCvKgi3NN1O1xQxpNirczilLoG JYScOdBZwBlTudD4AAlTznNU1lZi3VWgSo45SJ+m9PGNbhRyrZA0j8QNe8fYBZRSSB6W A5Ng== X-Gm-Message-State: ALoCoQmcw2Z/DPgakFf/kHCNEyrgDQH/9mP1l8bM7G/ebQIOQ+Ht+26RdFAQxqVH+0kIbmurRTSn X-Received: by 10.141.18.202 with SMTP id u193mr21636805qhd.16.1431450003101; Tue, 12 May 2015 10:00:03 -0700 (PDT) Received: from [192.168.1.131] ([24.53.47.130]) by mx.google.com with ESMTPSA id 5sm13755258qgg.28.2015.05.12.10.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2015 10:00:02 -0700 (PDT) Message-ID: <5552318F.6050508@jive.com> Date: Tue, 12 May 2015 12:59:59 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , Alissa Cooper , Oleg Moskalenko References: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> <555153F0.4050204@cs.tcd.ie> <55522411.10104@jive.com> <55522D57.8090009@cs.tcd.ie> In-Reply-To: <55522D57.8090009@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 17:00:15 -0000 Le 2015-05-12 12:41, Stephen Farrell a écrit : >> In the case where a single entity controls the authentication databases >> for all tenants of a single server, you're right. However, that >> condition does not hold in general. That is, we really do need to >> properly handle username collisions across realms. > > Sorry, I'm really not getting that. It is not a name for > a person, at least in WebRTC, right? It is some name > agreed between the WebRTC JS code and the TURN server. And > I'd hope it ought change frequently if it matters at all > or else it'll be scraped from the JS (or debug tooling). What you say is true for WebRTC. A REST API for obtaining ephemeral usernames was even proposed: https://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 For SIP, however, usernames are not ephemeral, are not easily changed, and, depending on what client provisioning allows, are often constrained to be identical to the SIP username, while the realm is often constrained to be identical to the SIP domain name. WebRTC front-ends to SIP infrastructure could also have the same constraints. >> I'd appreciate if we could recognize that there is a problem with >> current practice, > > I believe I did that already. Sorry, I understood your last email as suggesting that username hacks made ORIGIN unnecessary. >> 1) Are those concerns identical or different from those applying to, >> e.g., the Host HTTP header, or the SNI TLS extension? If they're >> different, how are they different? > > They may or may not be different but doing something better also > may or may not be more tractable. And the world has changed since > e.g. SNI was defined. (There is also desire to hide SNI in the > TLS 1.3 handshake if possible. We don't know if it will be possible > or not but the desire is there and is real.) I'm all for discussing something better, but at the moment I don't know what that could be... Maybe it is obvious to security folks, but it is not to me! >> 2) Is there a proposal that could fix the privacy issue? So far I've >> seen IESG members pointing out the issue, authors acknowledging the >> issue, but no discussion of solutions. > > From my POV, that is the discussion we are having and that is not > yet done. Ok, I'm happy to continue then! :) Simon From nobody Tue May 12 10:31:07 2015 Return-Path: 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 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 References: <20150428212204.9453.5930.idtracker@ietfa.amsl.com> <554142C5.6030505@cs.tcd.ie> <5541DDF6.7000205@cs.tcd.ie> <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: Cc: "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "tram@ietf.org" , The IESG 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >>> 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. From nobody Tue May 12 12:06:12 2015 Return-Path: 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 510141A885B; Tue, 12 May 2015 12:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 3rbQ1lZlfRzl; Tue, 12 May 2015 12:06:05 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ABAE1A87EF; Tue, 12 May 2015 12:06:05 -0700 (PDT) Received: by laat2 with SMTP id t2so13253615laa.1; Tue, 12 May 2015 12:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6O8iZuX7yNhWYq+/2nnGFqu9W/8NPjvgsWegsC3zsdM=; b=gK6Lzh/mWJCclg6Kj++BKVyQrkq6hYXif8rbTRcyfh3GI15Yq4ICxxsP+BMNeH6efE 9S/SW4dS8sXEEYWJfp0avVI1VQ9V/J3zLp867bGXdKZRY9xuZ53gSynaN5jthZVmMbeM raxy+VnhrhXrswX1n6kqqo9+JMCEg32fDCMeDOvMyv1+nztQXyBuyeNHP5X4J610OK80 AiwN1irGNCaj6yiXIOcGul2Nz5LW22GkybJEJUDIXHcdw9qHgFhm+Z1ixooh5LnWZgzX bgSb6C6MEX9VzdOKW/K0SGzqSv/ta6+Ciqqx/4oil5zwpsjwjTOy4/Pevz5DiHWsTIQT Vt1w== MIME-Version: 1.0 X-Received: by 10.112.154.138 with SMTP id vo10mr13163722lbb.68.1431457563849; Tue, 12 May 2015 12:06:03 -0700 (PDT) Received: by 10.152.129.3 with HTTP; Tue, 12 May 2015 12:06:03 -0700 (PDT) In-Reply-To: <55522D98.5040404@cs.tcd.ie> References: <20150421153635.27696.5302.idtracker@ietfa.amsl.com> <554F461C.4040603@cs.tcd.ie> <554F9339.4090404@jive.com> <55515512.2060705@cs.tcd.ie> <55522669.80607@jive.com> <55522D98.5040404@cs.tcd.ie> Date: Tue, 12 May 2015 14:06:03 -0500 Message-ID: From: Spencer Dawkins at IETF To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0122879e9aba920515e72fe3 Archived-At: Cc: "tram-chairs@ietf.org" , "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, Simon Perreault , The IESG , draft-ietf-tram-stun-origin@ietf.org, Alan Johnston Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:06:07 -0000 --089e0122879e9aba920515e72fe3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Simon, On Tue, May 12, 2015 at 11:43 AM, Stephen Farrell wrote: > > > On 12/05/15 17:12, Simon Perreault wrote: > > Le 2015-05-11 21:19, Stephen Farrell a =C3=A9crit : > >> Sorry no. I think this one requires some higher bandwidth (or more > >> extended;-) discussion. > > > > So, uh, what is normal procedure in this case? Should we set up a > > conference call? > > It'll be discussed on this Thursday's IESG telechat is the next > step. We may end up with some concall being needed, bit early to > say (I'd guess) but Spencer as responsible AD will drive that > along. Just to follow up on this ... Stephen's correct, and Simon is invited as document shepherd in case a high-bandwidth Q&A is still needed (of course, the rest of the world is invited to attend as observers). That can allow probably five to ten minutes of discussion on a single document. If more discussion is needed, I would add it to the agenda for the informal telechat scheduled the following Thursday, when we can spend more time. It's possible to set up ad hoc conference calls, but that would require doodle polls with busy people to schedule one, and the IESG already has informal telechats on our calendars. Having said that, e-mail is still a good thing, and the discussion that's happening (now, I believe, on the thread under Allisa's Discuss) looks promising. My suggestion is to make sure we all understand what the information we're discussing is (the difference between ethereal RTCWeb usernames and long-lived SIP usernames seems important), and who has to know that information. I hope that's helpful, of course. SPencer > S. > > > > > Simon > > > --089e0122879e9aba920515e72fe3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Simon,

On Tue, May 12, 2015 at 11:43 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 12/05/15 17:12, Simon Perreault wrote:
> Le 2015-05-11 21:19, Stephen Farrell a =C3=A9crit :
>> Sorry no. I think this one requires some higher bandwidth (or more=
>> extended;-) discussion.
>
> So, uh, what is normal procedure in this case? Should we set up a
> conference call?

It'll be discussed on this Thursday's IESG telechat is = the next
step. We may end up with some concall being needed, bit early to
say (I'd guess) but Spencer as responsible AD will drive that
along.

Just to follow up on this ...=C2=A0<= /div>

Stephen's correct, and Simon is invited as doc= ument shepherd in case a high-bandwidth Q&A is still needed (of course,= the rest of the world is invited to attend as observers). That can allow p= robably five to ten minutes of discussion on a single document.=C2=A0
=

If more discussion is needed, I would add it to the age= nda for the informal telechat scheduled the following Thursday, when we can= spend more time. It's possible to set up ad hoc conference calls, but = that would require doodle polls with busy people to schedule one, and the I= ESG already has informal telechats on our calendars.

Having said that, e-mail is still a good thing, and the discussion that&= #39;s happening (now, I believe, on the thread under Allisa's Discuss) = looks promising. My suggestion is to make sure we all understand what the i= nformation we're discussing is (the difference between ethereal RTCWeb = usernames and long-lived SIP usernames seems important), and who has to kno= w that information.

I hope that's helpful, of = course.

SPencer
=C2=A0
S.

>
> Simon
>

--089e0122879e9aba920515e72fe3-- From nobody Wed May 13 02:59:08 2015 Return-Path: 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 8F00A1B29F0; Wed, 13 May 2015 02:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Pm5Uj7syGgu4; Wed, 13 May 2015 02:59:03 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB381B29EC; Wed, 13 May 2015 02:58:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A950C2CC61; Wed, 13 May 2015 12:58:43 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOor5Iu1USpU; Wed, 13 May 2015 12:58:41 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 41A3A2CC5A; Wed, 13 May 2015 12:58:40 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Content-Type: multipart/signed; boundary="Apple-Mail=_5EF3B775-6534-4603-90FE-097C15CEBBE2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: Date: Wed, 13 May 2015 11:58:38 +0200 Message-Id: References: To: "Black, David" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "justin@uberti.name" , "tram@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "yoakum@avaya.com" , Alan Johnston , "ietf@ietf.org" Subject: Re: [tram] [Gen-art] Gen-ART review of draft-ietf-tram-stun-origin-05 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 09:59:05 -0000 --Apple-Mail=_5EF3B775-6534-4603-90FE-097C15CEBBE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks, all. I will assume the changes will be made in an upcoming = revision. Jari On 21 Apr 2015, at 17:08, Black, David wrote: > Alan, > =20 > This approach seems fine. Please add an RFC reference for the STUN = rules, preferably citing a section # to make the rules easy to find (if = you had trouble locating them, it=92ll be even harder for other readers = ...). > =20 > Thanks, > --David > =20 > From: Alan Johnston [mailto:alan.b.johnston@gmail.com]=20 > Sent: Tuesday, April 21, 2015 7:21 AM > To: Jari Arkko > Cc: Black, David; justin@uberti.name; yoakum@avaya.com; General Area = Review Team (gen-art@ietf.org); ietf@ietf.org; tram@ietf.org > Subject: Re: [Gen-art] Gen-ART review of = draft-ietf-tram-stun-origin-05 > =20 > Hi Jari, > =20 > We unfortunately did not reply to David for his review - our mistake. = See below for our response. > =20 > - Alan - > =20 > On Tue, Apr 21, 2015 at 1:55 AM, Jari Arkko = wrote: > Thanks for your review, David. I am trying to determine > how to deal with this draft in the upcoming IESG telechat. > Has there been any discussion of the issue you raise? > Do the authors have a response? >=20 > Jari >=20 > On 21 Mar 2015, at 06:12, Black, David wrote: >=20 > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > > > . > > > > Please resolve these comments along with any other Last Call = comments > > you may receive. > > > > Document: draft-ietf-tram-stun-origin-05 > > Reviewer: David L. Black > > Review Date: March 20, 2015 > > IETF LC End Date: March 17, 2015 > > > > Summary: This draft is on the right track, but has open issues > > described in the review. > > > > This draft describes the addition of a web origin attribute to STUN = and > > usage of that attribute in several protocol contexts. The draft is = well- > > written and easy to read. I found one minor issue which may be = editorial. > > > > Major issues: None. > > > > Minor issues: > > > > Section 2.7 discusses use of multiple STUN origins with Web RTC and > > concludes by imposing a "MUST" requirement on use of multiple STUN > > origins with HTTP in general (use first origin, ignore others). = While > > Web RTC may be the predominant or only current use of STUN and TURN = with > > HTTP, this "MUST" could foreclose the use of STUN origins with other > > uses of HTTP. I'm not sure what those possible future uses might = be, > > but at a minimum this draft ought to more tightly scope its = discussion > > of use of STUN origins with HTTP to limit that usage to Web RTC. If > > there's a good way for a STUN or TURN server to detect Web RTC = usage, > > requiring STUN and TURN servers to look for Web RTC as the use of > > HTTP, and only impose this "MUST" requirement if Web RTC is detected > > would better align that requirement with the discussion in this = draft. > =20 > David, > =20 > Apologies for not responding to you earlier earlier. Since this text = was written, we have realized that there are no valid use cases for = HTTP, SIP, or XMPP for multiple Origins, and also that the STUN = specification says that even if multiples were sent, only the first will = be processed. So we are dropping the MUST that you reference here. We = also plan to change the multiple Origins language in section 2 to say: =20= > =20 > "Senders SHOULD NOT include multiple ORIGIN attributes in a request = since per STUN rules, only the first will be processed and the rest = ignored." > =20 > > > > Nits/editorial comments: > > > > idnits 2.13.01 turned up a reference problem: > > > > =3D=3D Unused Reference: 'RFC7350' is defined on line 490, but no = explicit > > reference was found in the text > > > > That RFC should be cited somewhere. In addition, there are no RFCs = cited > > or referenced for TLS and DTLS - they should be added (I believe = that > > RFC 5246 and RFC 6347 are appropriate, respectively). > =20 > RFC 7350 is DTLS transport for STUN, so we should reference it in the = Security Considerations when we discuss DTLS. > =20 > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > david.black@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > > > _______________________________________________ > > Gen-art mailing list > > Gen-art@ietf.org > > https://www.ietf.org/mailman/listinfo/gen-art >=20 --Apple-Mail=_5EF3B775-6534-4603-90FE-097C15CEBBE2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVUyBOAAoJEM80gCTQU46qm84P/itlgGoi9aEBHG5Q6aPgCl6O /2xgOMluTWZcFP+VA9jFM2nBBbWXSUGjjEWV91dRwITE2743Y+KvO1uCsvdZTAXR oh55uzctnoDG/gnQSgtFas/JRCipwYfygRe789ttfVpGNJKQ+LJwBPQaFuFkTlm7 sd+rnTk97KZZ4CyP3QZcXqgyJ3dlBrQO43anbmRGPHmMRZd1luu1N/PWrXGssfTs ETJaqONphSObDkM2q9JdRmY98q0ze1B/3showVj1DCIyxu/EH8U1shNyhEIHnv61 RFbunO0Yu0lBBY4j9HK24rwKPyZJ0YeOVLay0Uw0ajKm7kLdkyT08rb2hbvnJqUU ZWCk0x+OvDRSbQvTJS/tJe99fTdm31MNO/6kjMl2AAvpUn2kFBw8qtG0xXPp0hQ3 aSdG+t3uFm0Zzmehs0tcxWB+mX4hobjNZdPvytJZAjvTcqEFeGaFi/3xEcON8ur0 pRYJLWK1flCohc2pSCS5to5UG3Uxxv0gsxWArP1rEavQhm6ME172mEIv8DIevuRO 7wddTfr9GuHKwMv19e1r0Lj4T+1wXKR1T/rB0W88KBPgHrF3XT+SLVREVcz4TcI7 wzbKkEKvSyru8V8JaBgJPZisfSlP9ZlN8g8TP+LO9aN7p/woEF61ezyy4acb9N3C MIqHqLo/xukS33iZgDwM =tC6T -----END PGP SIGNATURE----- --Apple-Mail=_5EF3B775-6534-4603-90FE-097C15CEBBE2-- From nobody Wed May 13 03:42:57 2015 Return-Path: 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 4742B1B2B37; Wed, 13 May 2015 03:42:56 -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 jmlXHlfHesZW; Wed, 13 May 2015 03:42:53 -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 E3EF51B2B3B; Wed, 13 May 2015 03:42:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CBE23BEBF; Wed, 13 May 2015 11:42:50 +0100 (IST) 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 wp8p3MZ-Isrt; Wed, 13 May 2015 11:42:50 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A2642BE55; Wed, 13 May 2015 11:42:50 +0100 (IST) Message-ID: <55532AAA.1040407@cs.tcd.ie> Date: Wed, 13 May 2015 11:42:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Simon Perreault , Alissa Cooper , Oleg Moskalenko References: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> <555153F0.4050204@cs.tcd.ie> <55522411.10104@jive.com> <55522D57.8090009@cs.tcd.ie> <5552318F.6050508@jive.com> In-Reply-To: <5552318F.6050508@jive.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 10:42:56 -0000 On 12/05/15 17:59, Simon Perreault wrote: > Le 2015-05-12 12:41, Stephen Farrell a écrit : >>> In the case where a single entity controls the authentication databases >>> for all tenants of a single server, you're right. However, that >>> condition does not hold in general. That is, we really do need to >>> properly handle username collisions across realms. >> >> Sorry, I'm really not getting that. It is not a name for >> a person, at least in WebRTC, right? It is some name >> agreed between the WebRTC JS code and the TURN server. And >> I'd hope it ought change frequently if it matters at all >> or else it'll be scraped from the JS (or debug tooling). > > What you say is true for WebRTC. A REST API for obtaining ephemeral > usernames was even proposed: > https://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 > > For SIP, however, usernames are not ephemeral, are not easily changed, > and, depending on what client provisioning allows, are often constrained > to be identical to the SIP username, while the realm is often > constrained to be identical to the SIP domain name. WebRTC front-ends to > SIP infrastructure could also have the same constraints. Hmm. Wouldn't addressing that issue (same protocol field is sometimes based on human memorable secrets and sometimes now) have been a fine thing for the tram wg to have done. Is that being addressed by the WG, other than via the oauth approach? S. > >>> I'd appreciate if we could recognize that there is a problem with >>> current practice, >> >> I believe I did that already. > > Sorry, I understood your last email as suggesting that username hacks > made ORIGIN unnecessary. > >>> 1) Are those concerns identical or different from those applying to, >>> e.g., the Host HTTP header, or the SNI TLS extension? If they're >>> different, how are they different? >> >> They may or may not be different but doing something better also >> may or may not be more tractable. And the world has changed since >> e.g. SNI was defined. (There is also desire to hide SNI in the >> TLS 1.3 handshake if possible. We don't know if it will be possible >> or not but the desire is there and is real.) > > I'm all for discussing something better, but at the moment I don't know > what that could be... Maybe it is obvious to security folks, but it is > not to me! > >>> 2) Is there a proposal that could fix the privacy issue? So far I've >>> seen IESG members pointing out the issue, authors acknowledging the >>> issue, but no discussion of solutions. >> >> From my POV, that is the discussion we are having and that is not >> yet done. > > Ok, I'm happy to continue then! :) > > Simon > From nobody Wed May 13 03:58:39 2015 Return-Path: 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 2F5501B2B91; Wed, 13 May 2015 03:58:38 -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 K-1uIo_TdSxb; Wed, 13 May 2015 03:58:36 -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 B0DA41B2B8F; Wed, 13 May 2015 03:58:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7DE89BECF; Wed, 13 May 2015 11:58:35 +0100 (IST) 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 4tIT2jKSVUQN; Wed, 13 May 2015 11:58:35 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 537ADBECA; Wed, 13 May 2015 11:58:35 +0100 (IST) Message-ID: <55532E5B.5050204@cs.tcd.ie> Date: Wed, 13 May 2015 11:58:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Simon Perreault , Alan Johnston References: <20150421153635.27696.5302.idtracker@ietfa.amsl.com> <554F461C.4040603@cs.tcd.ie> <554F9339.4090404@jive.com> In-Reply-To: <554F9339.4090404@jive.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, The IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 10:58:38 -0000 On 10/05/15 18:19, Simon Perreault wrote: > I don't follow. If the browser lies, then authentication will fail. > Where's the problem? > So let's say that a TURN server works on behalf of two "tenant" services, S1 and S2 (legacy-SIP or WebRTC doesn't matter for this point). S1 are mean and charge the end user per byte/second and when the TURN server is working on behalf of S1 then the TURN server will do loads of accounting that'll eventually turn into billing from S1 to the user at the UA. S2 however are rich new Internet kids and offer calling for nothing - they just use some of their vast advertising revenue to pay the TURN server operator a big pile of cash and the end user never has to pay, because S2 make money elsewhere. As a user, I can have accounts with both, and can authenticate to the TURN server as either. (I'm not saying that is good but it is what you've told me I think.) I will of course always assert that the "origin" for all of my calls is S2 and authenticate with those credentials, even when I'm making a call that is setup by S1 and that properly ought to be billed that way. (And such a call can be to a destination that is simply not reachable via S2's signalling of course.) The fact that this origin is used by the TURN server to pick between those and that there is no binding between that and the in-progress call enables me to succeed when I try the age-old trick of getting calls for nothing. And similar issues will arise if there is any differentiation between what the STUN/TURN server does for any of it's multiple tenants. (Logically, that would seem to imply that the TURN server has to offer the exact same service to all tenants as a result of this protocol feature/flaw, which would presumably de-value all multi-tenant features to the extent they'd just die out. But then logic doesn't always rule I guess:-) Can you tell me what in the current proposal (or the underlying context, and hence perhaps properly not documented here) means that the above is a non-issue? Or where else am I going wrong? Cheers, S. PS: It's obvious I guess, but this isn't directly about the privacy aspects of the draft, though any solutions would impinge on the discussion of the privacy aspects of the draft and hence on this overall discussion. From nobody Wed May 13 07:05:19 2015 Return-Path: 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 291B81B2C39 for ; Wed, 13 May 2015 07:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 rsGUCrZ2MLeD for ; Wed, 13 May 2015 07:05:16 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EFC1B2C50 for ; Wed, 13 May 2015 07:04:54 -0700 (PDT) Received: by qcyk17 with SMTP id k17so22796777qcy.1 for ; Wed, 13 May 2015 07:04:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OJ5tWex6xkZQhpDSgfi4EZj5Jy2z7axJFGtS0VrjSME=; b=dnU8Jqggdj9osodAdI6gCB9AqJkZJjrtlOdBTG8z6wtCvBI/qmqK6FgqOLUTt550F7 aOMF3KoKntcch7zhLD+d62OcEvJGCaSEBVFL2IjaEfy3oWgIT6BKVlKvEcU2J8RedPw8 T8FkEj+yIkGFs3taCmG2onIVrTWXZZyjqf50w0j/+en1NNF3XnURET0nIZ9GfNbp+zFk uu27R+iE2WC1ebPhr7p1qPa+abuaPAp4MDh+bzLUTD+0t1hJNanh17NY8150jtI+Jyoh dHru7bJvK70a3agzG7N6ADjGiDzfvEgJnbl+fz37un8V2WSdQ3xI2YjrqjCxRIjk3WcY 7l+Q== X-Gm-Message-State: ALoCoQmNP1ja4BXA7cz3wrp47yCBow1sAnJeIIba1vwuSrzWQPJM2dSTWBOWvFgvQklRaZ4XlF4f X-Received: by 10.55.22.194 with SMTP id 63mr45148138qkw.3.1431525893956; Wed, 13 May 2015 07:04:53 -0700 (PDT) Received: from [192.168.1.131] ([24.53.47.130]) by mx.google.com with ESMTPSA id g38sm15781109qge.4.2015.05.13.07.04.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2015 07:04:53 -0700 (PDT) Message-ID: <55535A02.2020202@jive.com> Date: Wed, 13 May 2015 10:04:50 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , Alissa Cooper , Oleg Moskalenko References: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> <555153F0.4050204@cs.tcd.ie> <55522411.10104@jive.com> <55522D57.8090009@cs.tcd.ie> <5552318F.6050508@jive.com> <55532AAA.1040407@cs.tcd.ie> In-Reply-To: <55532AAA.1040407@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 14:05:17 -0000 Le 2015-05-13 06:42, Stephen Farrell a écrit : > Hmm. Wouldn't addressing that issue (same protocol field is > sometimes based on human memorable secrets and sometimes > now) have been a fine thing for the tram wg to have done. Is > that being addressed by the WG, other than via the oauth > approach? It's not. Simon From nobody Wed May 13 09:21:12 2015 Return-Path: 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 DEDFC1B2FFC for ; Wed, 13 May 2015 09:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 fdheeExeqJNV for ; Wed, 13 May 2015 09:21:10 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193A01B2E71 for ; Wed, 13 May 2015 09:21:09 -0700 (PDT) Received: by qgej70 with SMTP id j70so24087466qge.2 for ; Wed, 13 May 2015 09:21:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ISqRdghFVpZxT6qVvXkY8nkP9/vyW13Lwyx918mnFOo=; b=eMERhpWhdQC9uKrVH6BwyDI+QU7iin1uCEBSvoMg3FLEvmeUE6SpyoMDaQpUzW68dc 3FIEQUTdBro8NE+uFhpXHXa+tL3q2CZY6wVcpqYCTd3E2LPfQUElPPcUIyRAAAqKQzda EHL9UuMsbGIgdMmaFXldKTtrH8Gbwgw6V6DXRvzlFYTTsjhd5u5GnuGQlLQ9l8bnGvlf rFgWRP6tnIWVY0rJrOjQchIHK2VRKBbD3v2fxKsWJC7EKFhP7iUuK9m+hReCEIRodMcC WnxdT0mQCJjnjpingIJj3w8sYiSABsXY8vXs0kizXUuj+kj6m3caIG2FMZG9lbFRmUzW ZvvQ== X-Gm-Message-State: ALoCoQlx4bWVMQONHGG0LNiq9xSB0E3O5gryluOP4K83n+LwRzux90yXabuLFtqEm5B3ORHn96gO X-Received: by 10.55.20.87 with SMTP id e84mr45378663qkh.43.1431534068383; Wed, 13 May 2015 09:21:08 -0700 (PDT) Received: from [192.168.1.131] ([24.53.47.130]) by mx.google.com with ESMTPSA id g184sm15868910qhc.6.2015.05.13.09.21.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2015 09:21:07 -0700 (PDT) Message-ID: <555379F1.8050704@jive.com> Date: Wed, 13 May 2015 12:21:05 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , Alan Johnston References: <20150421153635.27696.5302.idtracker@ietfa.amsl.com> <554F461C.4040603@cs.tcd.ie> <554F9339.4090404@jive.com> <55532E5B.5050204@cs.tcd.ie> In-Reply-To: <55532E5B.5050204@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: tram-chairs@ietf.org, "tram@ietf.org" , draft-ietf-tram-stun-origin.shepherd@ietf.org, draft-ietf-tram-stun-origin.ad@ietf.org, The IESG , draft-ietf-tram-stun-origin@ietf.org Subject: Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:21:12 -0000 Le 2015-05-13 06:58, Stephen Farrell a écrit : > On 10/05/15 18:19, Simon Perreault wrote: >> I don't follow. If the browser lies, then authentication will fail. >> Where's the problem? >> > > So let's say that a TURN server works on behalf of two "tenant" > services, S1 and S2 (legacy-SIP or WebRTC doesn't matter for this > point). > > S1 are mean and charge the end user per byte/second and when the > TURN server is working on behalf of S1 then the TURN server will do > loads of accounting that'll eventually turn into billing from S1 to > the user at the UA. > > S2 however are rich new Internet kids and offer calling for nothing > - they just use some of their vast advertising revenue to pay the > TURN server operator a big pile of cash and the end user never has to > pay, because S2 make money elsewhere. > > As a user, I can have accounts with both, and can authenticate to > the TURN server as either. (I'm not saying that is good but it is > what you've told me I think.) > > I will of course always assert that the "origin" for all of my calls > is S2 and authenticate with those credentials, even when I'm making a > call that is setup by S1 and that properly ought to be billed that > way. (And such a call can be to a destination that is simply not > reachable via S2's signalling of course.) > > The fact that this origin is used by the TURN server to pick between > those and that there is no binding between that and the in-progress > call enables me to succeed when I try the age-old trick of getting > calls for nothing. Correct. However, imagine the same situation with current STUN authentication (i.e., no ORIGIN, no third-party-auth). You have an account on each of S1's and S2's servers, each of which listen on different IP addresses. You can still use S2's server for a call signalled using S1's servers. What makes this possible is that STUN authentication has no binding with call signalling. ORIGIN does not attempt to change this. > Can you tell me what in the current proposal (or the underlying > context, and hence perhaps properly not documented here) means that > the above is a non-issue? Or where else am I going wrong? STUN/TURN is by design a stand-alone NAT traversal service. An important design principle is that the endpoints are responsible for their own NAT traversal. Contrast this to hosted NAT traversal [RFC7362]. That is, endpoints using a generic RFC 3261 SIP proxy as signalling server can use ICE with STUN/TURN servers of their choosing to establish a peer-to-peer session. The SIP proxy does not need to be aware of any of this. By design, the STUN/TURN server has a relationship with the endpoint, not with the signalling infrastructure. With WebRTC, the typical deployment model has the application provider in charge of signalling, endpoint provisioning, and STUN/TURN server operations This particular model makes a binding between signalling and STUN authentication a possibility. However, in general, by design, STUN/TURN is a client-server protocol, and has nothing to do with signalling. Therefore, when a client has an account with a server, it can use it with whatever signalling it wants. The server is not aware of this. By design. Simon From nobody Wed May 13 11:55:54 2015 Return-Path: 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 0D0A41ACDEB; Wed, 13 May 2015 11:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 KTKS2rsKlU_l; Wed, 13 May 2015 11:55:48 -0700 (PDT) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1551ACE3B; Wed, 13 May 2015 11:55:47 -0700 (PDT) Received: by vnbg190 with SMTP id g190so3585390vnb.12; Wed, 13 May 2015 11:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I7FId2B+fKA3pFP4bByNd/DdUtYSpn20oktqlEnv7xU=; b=B2OnnE2hmHu+hrL1xxXmiW8Kmw0r+7WqJsLGvsKAHP1X7iadvkvclbwQb7QF1Y54aK 264EbiLExj61QVlc+Sh0CvSjMfNawnvepGFUeSLuiFdIVUbyBthFHygI51DINO2/pYbt Ys4NoBtc0jNfcJ/aNgXXfS8GDZ+j4zDsOhLT745ogyIQKC3V4zhNOyYw6ZUOtl3G7xAf dd8eRqY/umMk8cM9US8MhDvekIPzDp4rSYwCXczrqgKtIF3ePkOgmooxvvdDSucMe9ZS VGy/PHCI24CmpFdnz2pBux/hZ/DStS9HVGSEe9czGJWg2Drdc459hovRfzrTYN3RGIRx NpSw== MIME-Version: 1.0 X-Received: by 10.52.153.164 with SMTP id vh4mr373536vdb.31.1431543346881; Wed, 13 May 2015 11:55:46 -0700 (PDT) Received: by 10.52.106.100 with HTTP; Wed, 13 May 2015 11:55:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 May 2015 13:55:46 -0500 Message-ID: From: Alan Johnston To: Jari Arkko Content-Type: multipart/alternative; boundary=bcaec51b9b91abe9380515fb286b Archived-At: Cc: "justin@uberti.name" , "tram@ietf.org" , "Black, David" , "yoakum@avaya.com" , "General Area Review Team \(gen-art@ietf.org\)" , "ietf@ietf.org" Subject: Re: [tram] [Gen-art] Gen-ART review of draft-ietf-tram-stun-origin-05 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 18:55:51 -0000 --bcaec51b9b91abe9380515fb286b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jari, Yes, we will make these changes in our next rev. - Alan - On Wed, May 13, 2015 at 4:58 AM, Jari Arkko wrote: > Thanks, all. I will assume the changes will be made in an upcoming > revision. > > Jari > > On 21 Apr 2015, at 17:08, Black, David wrote: > > > Alan, > > > > This approach seems fine. Please add an RFC reference for the STUN > rules, preferably citing a section # to make the rules easy to find (if y= ou > had trouble locating them, it=E2=80=99ll be even harder for other readers= ...). > > > > Thanks, > > --David > > > > From: Alan Johnston [mailto:alan.b.johnston@gmail.com] > > Sent: Tuesday, April 21, 2015 7:21 AM > > To: Jari Arkko > > Cc: Black, David; justin@uberti.name; yoakum@avaya.com; General Area > Review Team (gen-art@ietf.org); ietf@ietf.org; tram@ietf.org > > Subject: Re: [Gen-art] Gen-ART review of draft-ietf-tram-stun-origin-05 > > > > Hi Jari, > > > > We unfortunately did not reply to David for his review - our mistake. > See below for our response. > > > > - Alan - > > > > On Tue, Apr 21, 2015 at 1:55 AM, Jari Arkko > wrote: > > Thanks for your review, David. I am trying to determine > > how to deal with this draft in the upcoming IESG telechat. > > Has there been any discussion of the issue you raise? > > Do the authors have a response? > > > > Jari > > > > On 21 Mar 2015, at 06:12, Black, David wrote: > > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > > Gen-ART, please see the FAQ at > > > > > > . > > > > > > Please resolve these comments along with any other Last Call comments > > > you may receive. > > > > > > Document: draft-ietf-tram-stun-origin-05 > > > Reviewer: David L. Black > > > Review Date: March 20, 2015 > > > IETF LC End Date: March 17, 2015 > > > > > > Summary: This draft is on the right track, but has open issues > > > described in the review. > > > > > > This draft describes the addition of a web origin attribute to STUN a= nd > > > usage of that attribute in several protocol contexts. The draft is > well- > > > written and easy to read. I found one minor issue which may be > editorial. > > > > > > Major issues: None. > > > > > > Minor issues: > > > > > > Section 2.7 discusses use of multiple STUN origins with Web RTC and > > > concludes by imposing a "MUST" requirement on use of multiple STUN > > > origins with HTTP in general (use first origin, ignore others). Whil= e > > > Web RTC may be the predominant or only current use of STUN and TURN > with > > > HTTP, this "MUST" could foreclose the use of STUN origins with other > > > uses of HTTP. I'm not sure what those possible future uses might be, > > > but at a minimum this draft ought to more tightly scope its discussio= n > > > of use of STUN origins with HTTP to limit that usage to Web RTC. If > > > there's a good way for a STUN or TURN server to detect Web RTC usage, > > > requiring STUN and TURN servers to look for Web RTC as the use of > > > HTTP, and only impose this "MUST" requirement if Web RTC is detected > > > would better align that requirement with the discussion in this draft= . > > > > David, > > > > Apologies for not responding to you earlier earlier. Since this text > was written, we have realized that there are no valid use cases for HTTP, > SIP, or XMPP for multiple Origins, and also that the STUN specification > says that even if multiples were sent, only the first will be processed. > So we are dropping the MUST that you reference here. We also plan to > change the multiple Origins language in section 2 to say: > > > > "Senders SHOULD NOT include multiple ORIGIN attributes in a request > since per STUN rules, only the first will be processed and the rest > ignored." > > > > > > > > Nits/editorial comments: > > > > > > idnits 2.13.01 turned up a reference problem: > > > > > > =3D=3D Unused Reference: 'RFC7350' is defined on line 490, but no ex= plicit > > > reference was found in the text > > > > > > That RFC should be cited somewhere. In addition, there are no RFCs > cited > > > or referenced for TLS and DTLS - they should be added (I believe that > > > RFC 5246 and RFC 6347 are appropriate, respectively). > > > > RFC 7350 is DTLS transport for STUN, so we should reference it in the > Security Considerations when we discuss DTLS. > > > > > > > > Thanks, > > > --David > > > ---------------------------------------------------- > > > David L. Black, Distinguished Engineer > > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > david.black@emc.com Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > > > > > > > > _______________________________________________ > > > Gen-art mailing list > > > Gen-art@ietf.org > > > https://www.ietf.org/mailman/listinfo/gen-art > > > > --bcaec51b9b91abe9380515fb286b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jari,

Yes, we will make these change= s in our next rev.

- Alan -

On Wed, May 13, 2015 at 4:5= 8 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
Thanks, all. I will assume the changes will be made= in an upcoming revision.

Jari

On 21 Apr 2015, at 17:08, Black, David <david.black@emc.com> wrote:

> Alan,
>
> This approach seems fine.=C2=A0 Please add an RFC reference for the ST= UN rules, preferably citing a section # to make the rules easy to find (if = you had trouble locating them, it=E2=80=99ll be even harder for other reade= rs ...).
>
> Thanks,
> --David
>
> From: Alan Johnston [mailto:alan.b.johnston@gmail.com]
> Sent: Tuesday, April 21, 2015 7:21 AM
> To: Jari Arkko
> Cc: Black, David; justin@uberti.= name; yoakum@avaya.com; General= Area Review Team (gen-art@ietf.org= ); ietf@ietf.org; tram@ietf.org
> Subject: Re: [Gen-art] Gen-ART review of draft-ietf-tram-stun-origin-0= 5
>
> Hi Jari,
>
> We unfortunately did not reply to David for his review - our mistake.= =C2=A0 See below for our response.
>
> - Alan -
>
> On Tue, Apr 21, 2015 at 1:55 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
> Thanks for your review, David. I am trying to determine
> how to deal with this draft in the upcoming IESG telechat.
> Has there been any discussion of the issue you raise?
> Do the authors have a response?
>
> Jari
>
> On 21 Mar 2015, at 06:12, Black, David <david.black@emc.com> wrote:
>
> > I am the assigned Gen-ART reviewer for this draft. For background= on
> > Gen-ART, please see the FAQ at
> >
> > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenA= rtfaq>.
> >
> > Please resolve these comments along with any other Last Call comm= ents
> > you may receive.
> >
> > Document: draft-ietf-tram-stun-origin-05
> > Reviewer: David L. Black
> > Review Date: March 20, 2015
> > IETF LC End Date: March 17, 2015
> >
> > Summary: This draft is on the right track, but has open issues > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0described i= n the review.
> >
> > This draft describes the addition of a web origin attribute to ST= UN and
> > usage of that attribute in several protocol contexts.=C2=A0 The d= raft is well-
> > written and easy to read.=C2=A0 I found one minor issue which may= be editorial.
> >
> > Major issues: None.
> >
> > Minor issues:
> >
> > Section 2.7 discusses use of multiple STUN origins with Web RTC a= nd
> > concludes by imposing a "MUST" requirement on use of mu= ltiple STUN
> > origins with HTTP in general (use first origin, ignore others).= =C2=A0 While
> > Web RTC may be the predominant or only current use of STUN and TU= RN with
> > HTTP, this "MUST" could foreclose the use of STUN origi= ns with other
> > uses of HTTP.=C2=A0 I'm not sure what those possible future u= ses might be,
> > but at a minimum this draft ought to more tightly scope its discu= ssion
> > of use of STUN origins with HTTP to limit that usage to Web RTC.= =C2=A0 If
> > there's a good way for a STUN or TURN server to detect Web RT= C usage,
> > requiring STUN and TURN servers to look for Web RTC as the use of=
> > HTTP, and only impose this "MUST" requirement if Web RT= C is detected
> > would better align that requirement with the discussion in this d= raft.
>
> David,
>
> Apologies for not responding to you earlier earlier.=C2=A0 Since this = text was written, we have realized that there are no valid use cases for HT= TP, SIP, or XMPP for multiple Origins, and also that the STUN specification= says that even if multiples were sent, only the first will be processed.= =C2=A0 So we are dropping the MUST that you reference here.=C2=A0 We also p= lan to change the multiple Origins language in section 2 to say:
>
> "Senders SHOULD NOT include multiple ORIGIN attributes in a reque= st since per STUN rules, only the first will be processed and the rest igno= red."
>
> >
> > Nits/editorial comments:
> >
> > idnits 2.13.01 turned up a reference problem:
> >
> >=C2=A0 =3D=3D Unused Reference: 'RFC7350' is defined on li= ne 490, but no explicit
> >=C2=A0 =C2=A0 =C2=A0reference was found in the text
> >
> > That RFC should be cited somewhere.=C2=A0 In addition, there are = no RFCs cited
> > or referenced for TLS and DTLS - they should be added (I believe = that
> > RFC 5246 and RFC 6347 are appropriate, respectively).
>
> RFC 7350 is DTLS transport for STUN, so we should reference it in the = Security Considerations when we discuss DTLS.
>
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > EMC Corporation, 176 South St., Hopkinton, MA=C2=A0 01748
> > +1 (508) 293-7953=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= FAX: +1 (508) 293-7786
> > david.black@emc.com=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> >
> > _______________________________________________
> > Gen-art mailing list
> > Gen-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/gen-art
>


--bcaec51b9b91abe9380515fb286b-- From nobody Wed May 13 14:55:57 2015 Return-Path: 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 059161B2E39; Wed, 13 May 2015 14:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 CqyDqEb2AjWO; Wed, 13 May 2015 14:55:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2A51B2E4C; Wed, 13 May 2015 14:55:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150513215543.23435.39076.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 14:55:43 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 21:55:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized Working Group of the IETF. Title : TURN Server Auto Discovery Authors : Prashanth Patil Tirumaleswar Reddy Dan Wing Filename : draft-ietf-tram-turn-server-discovery-02.txt Pages : 13 Date : 2015-05-13 Abstract: Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto discovery mechanisms that a TURN client could use with no or minimal configuration. This document describes three such mechanisms for TURN server discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-server-discovery-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 13 14:58:09 2015 Return-Path: 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 A950C1B2ECE for ; Wed, 13 May 2015 14:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 UyftJM1gNSLN for ; Wed, 13 May 2015 14:58:05 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C621B2ECD for ; Wed, 13 May 2015 14:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2225; q=dns/txt; s=iport; t=1431554284; x=1432763884; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/AK7rcXWMLue17orPeXImMMufHfN1hnLTieIXAgrs+Q=; b=A5iV5zcPdeLBswrs06GnjWlVXjVSzqKjj9a2rvub3hwt8PrFjioLscJ+ sRmKQNp4DN9lzbgHKcC8RRVShLyMQyc+infqLNb6LkPSfSzdyjOH2ESyx aHX6d01Q1m15JPDosO13nHsS88b0lA7N4CxCJ1pYYKICSMEWuV7rd1Ozx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BWBAAcyFNV/5pdJa1cgw9UXgbEI2YJgU4MhgMCgT44FAEBAQEBAQGBCoQhAQEEAQEBNzQbAgEINhAnCyUCBBOILA3JKgEBAQEBAQEDAQEBAQEBARuLOoQsDhg6hC0FklaEJ4ZJgSU+gyWRbiODd2+BA0KBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,422,1427760000"; d="scan'208";a="149739209" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 13 May 2015 21:58:04 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t4DLw4hF019207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 13 May 2015 21:58:04 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.117]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Wed, 13 May 2015 16:58:03 -0500 From: "Prashanth Patil (praspati)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-02.txt Thread-Index: AQHQjcfi7OSEaUyN+EGh2UbDsowJpQ== Date: Wed, 13 May 2015 21:58:02 +0000 Message-ID: References: <20150513215543.23435.39076.idtracker@ietfa.amsl.com> In-Reply-To: <20150513215543.23435.39076.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.155.209.23] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 21:58:06 -0000 A new version of the TURN discovery draft has been submitted. Updates: - DNS-SD as an additional discovery mechanism - Removed sections that deal with reverse IP lookup for service resolution - Addresses comments received on the mailer. -Prashanth On 5/13/15, 2:55 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the TURN Revised and Modernized Working >Group of the IETF. > > Title : TURN Server Auto Discovery > Authors : Prashanth Patil > Tirumaleswar Reddy > Dan Wing > Filename : draft-ietf-tram-turn-server-discovery-02.txt > Pages : 13 > Date : 2015-05-13 > >Abstract: > Current Traversal Using Relays around NAT (TURN) server discovery > mechanisms are relatively static and limited to explicit > configuration. These are usually under the administrative control of > the application or TURN service provider, and not the enterprise, > ISP, or the network in which the client is located. Enterprises and > ISPs wishing to provide their own TURN servers need auto discovery > mechanisms that a TURN client could use with no or minimal > configuration. This document describes three such mechanisms for > TURN server discovery. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-02 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-server-discovery-= 02 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Wed May 13 23:36:12 2015 Return-Path: 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 567E81B342C; Wed, 13 May 2015 23:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 eOa7utjW_Brt; Wed, 13 May 2015 23:36:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB4B1B3421; Wed, 13 May 2015 23:36:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150514063610.1000.3209.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 23:36:10 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-16.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 06:36:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized Working Group of the IETF. Title : Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization Authors : Tirumaleswar Reddy Prashanth Patil Ram Mohan Ravindranath Justin Uberti Filename : draft-ietf-tram-turn-third-party-authz-16.txt Pages : 23 Date : 2015-05-13 Abstract: This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 13 23:43:36 2015 Return-Path: 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 0DE9B1B3448; Wed, 13 May 2015 23:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 szLLbeDJPSPc; Wed, 13 May 2015 23:43:33 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4851B343D; Wed, 13 May 2015 23:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1742; q=dns/txt; s=iport; t=1431585813; x=1432795413; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RoDIdqSSOOQ1mAowMay+XcZIylZjq7ukTGr9t+9X9BM=; b=jsEqmXqTbs2WYokJLrOi2V0DXB3383tA8qgCxSF/72wGRPlbugyGOlMV mcDJ4oTlfhXQXe2ObKUEPdXcNHHb93mWePFp6gIeFtZjoI//S/vJjvyII 1/LDmNITtrElUbn6HzcgQ1FHJX9iQ2MfZDYPIr4WdgxNY0T4Ixo7BrGeF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BIBQBpQ1RV/5hdJa1cgw9UXgaDGMBogkmGAwIcgRZMAQEBAQEBgQuEIAEBAQQjEUMOBAIBCBEEAQEDAgYdAwICAh8RFAEICAIEARIIiA8DEg2zJp8oDYR8AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhihmCTYIHFiIGgmIvgRYBBJJbhCeEdYJ6PoMliniGdiODd2+BRYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,426,1427760000"; d="scan'208";a="416473746" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 14 May 2015 06:43:30 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t4E6hUdi022082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 May 2015 06:43:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 14 May 2015 01:43:30 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram-chairs@ietf.org" , "draft-ietf-tram-turn-third-party-authz.ad@ietf.org" , "draft-ietf-tram-turn-third-party-authz.shepherd@ietf.org" , "spencerdawkins.ietf@gmail.com" , "stephen.farrell@cs.tcd.ie" , "tram@ietf.org" , "Salz, Rich (rsalz@akamai.com)" Thread-Topic: New Version Notification - draft-ietf-tram-turn-third-party-authz-16.txt Thread-Index: AQHQjhBG5kpmRGMS1k2gdAUg9KPz7Z17BKNw Date: Thu, 14 May 2015 06:43:29 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478446A6@xmb-rcd-x10.cisco.com> References: <20150514063610.1000.25357.idtracker@ietfa.amsl.com> In-Reply-To: <20150514063610.1000.25357.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.46.223] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tram] New Version Notification - draft-ietf-tram-turn-third-party-authz-16.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 06:43:35 -0000 VGhpcyByZXZpc2lvbiBhZGRyZXNzZXMgY29tbWVudHMgZnJvbSBTYWx6IGFuZCBTdGVwaGVuLiBI b3BlZnVsbHkgdGhpcyB3aWxsIGJlIHN1ZmZpY2llbnQgdG8gY2xlYXIgRElTQ1VTUy4NCg0KQ2hl ZXJzLA0KLVRpcnUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+ IFNlbnQ6IFRodXJzZGF5LCBNYXkgMTQsIDIwMTUgMTI6MDYgUE0NCj4gVG86IHRyYW0tY2hhaXJz QGlldGYub3JnOyBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoekBpZXRmLm9y ZzsNCj4gZ29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tOyBkcmFmdC1pZXRmLXRyYW0tdHVy bi10aGlyZC1wYXJ0eS0NCj4gYXV0aHouYWRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdHJhbS10dXJu LXRoaXJkLXBhcnR5LWF1dGh6LnNoZXBoZXJkQGlldGYub3JnOw0KPiBzcGVuY2VyZGF3a2lucy5p ZXRmQGdtYWlsLmNvbTsgc3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZQ0KPiBTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gLSBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1h dXRoei0NCj4gMTYudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiAoLTE2KSBoYXMgYmVlbiBz dWJtaXR0ZWQgZm9yIGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LQ0KPiBhdXRoejoN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtdHJhbS10 dXJuLXRoaXJkLXBhcnR5LWF1dGh6LQ0KPiAxNi50eHQNCj4gDQo+IA0KPiBUaGUgSUVURiBkYXRh dHJhY2tlciBwYWdlIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRo ei8NCj4gDQo+IERpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uOg0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHot MTYNCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IElFVEYg U2VjcmV0YXJpYXQuDQoNCg== From nobody Thu May 14 06:48:28 2015 Return-Path: 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 B42C41AD376 for ; Thu, 14 May 2015 06:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 kLBRIh9Jt6Za for ; Thu, 14 May 2015 06:48:25 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340D21B2A34 for ; Thu, 14 May 2015 06:48:11 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9FD1620969 for ; Thu, 14 May 2015 09:48:10 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 14 May 2015 09:48:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=acgIWJrZb8RDuc6Pn7Mp4VOTZy4=; b=lWwWFK XG2coEvE+tHoj9Txm+ceSqvICgdBwct4KQMj/NMQxcK8/5Dzb76BREsX4Pv+eoFI r9JEFKK5cQRpdFrunq907uaDEq3aXCmMo5Tr6iW7pLWdaGuU+rMD9TbbD2iwSMlV RKSwxrZboG+GSfrQ84McScBu1UufoBx+Vm10U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=acgIWJrZb8RDuc6 Pn7Mp4VOTZy4=; b=L/kS4gq0pLSzEsGsBgrg1xeT2omnaIgaHy/gXuZ2ZikndG0 8i1iKFba7YRem1lnT5qLvXKVEhiAxHRPlH84BUz0exrwqEhigX5z6fczYwELieZb 3Hf+K0FT44C7i8WPv5wytrvkCZP9EQ4oD610+lnr3RTP9gluhqokp3L2Brx0= X-Sasl-enc: KbpDSjpF7qLC2eXBN/IuUIf7X3anxY3I918rdlKdyOVz 1431611290 Received: from [192.168.1.193] (unknown [24.6.61.198]) by mail.messagingengine.com (Postfix) with ESMTPA id 32BED6801A4; Thu, 14 May 2015 09:48:10 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alissa Cooper X-Mailer: iPhone Mail (12F70) In-Reply-To: <93BEDDC39A54294B9E78C7860516FA47673B781F@AZ-US1EXMB06.global.avaya.com> Date: Thu, 14 May 2015 06:48:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <13E02B6B-0D89-4AD3-8B69-06426A26732E@cooperw.in> References: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> <93BEDDC39A54294B9E78C7860516FA47673B781F@AZ-US1EXMB06.global.avaya.com> To: "Yoakum, John H (John)" Archived-At: Cc: "tram-chairs@ietf.org" , "tram@ietf.org" , "draft-ietf-tram-stun-origin.shepherd@ietf.org" , "draft-ietf-tram-stun-origin.ad@ietf.org" , "sperreault@jive.com" , The IESG , "draft-ietf-tram-stun-origin@ietf.org" Subject: Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 13:48:26 -0000 If some of this context could be added to the draft, I think that would be m= uch better than just saying "logging and analytics." Thanks, Alissa > On May 11, 2015, at 6:04 PM, Yoakum, John H (John) wrot= e: >=20 > There seems to be some questions around why things like logging and admini= strative debugging are useful and possibly some of it is a matter of context= . Inside enterprises it is very common to have a variety of logging capabil= ities across all parts of a system or solution as well as to perform debuggi= ng activities based on whatever combinations of insight are available whenev= er problems occur. =20 >=20 > With WebRTC is will be very common to find TURN servers run by enterprises= to serve various enterprise-centric websites that desire real-time communic= ations as part of the enterprise web experience for people from outside the e= nterprise who may be external parties or in many use cases may actually be e= nterprise employees. ORIGN tells a STUN or TURN server what realm is associ= ated with the request. That piece of knowledge is already well known by the= browser making the request (except in the privacy-sensitive situations acco= mmodated in the draft, which will seldom be the case for employees of an ent= erprises) and is highly useful to enterprises who have web services and rela= ted communications enablement gear like STUN and TURN servers necessary to a= llow employees access from home, virtual offices, or while traveling (withou= t the need for VPNs or other specialized network connections). Large enterp= rises often have multiple applications, multiple domains or subdomains, and m= ultiple realms. This simple extension to STUN to conveys insight related to= the web applications using communications ennoblements like STUN and TURN s= ervers will find many uses inside enterprises. >=20 > ORIGIN is not a substitute for more accurate authentication, it is a way t= o quickly determine the best authentication to attempt as well as to quickly= filter out things where authentication attempts or other processing (even s= imple STUN requests) are a waste of resources as that realm will never be se= rviced anyway. >=20 > In terms of troubleshooting, within an enterprise it is highly useful to l= ook at insight from all the parts of a solution and identify inconsistences.= As an example if it is discovered while debugging a communications failure= that a browser inside an enterprise is lying about ORIGIN it may help in un= covering that the browser has been compromised by malware. Enterprises can n= ever have too much insight in their logs for short periods of time as that i= s what they rely on to debug sophisticated systems. Just as importantly log= data is often used to judge system usage to help justify investing in addit= ional resources or spread costs to the applications or departments involved.= >=20 > Is any of this enterprise perspective helpful or just adding to the confus= ion? One of the great promises of WebRTC is to allow simpler systems withou= t all the complicated telephony approaches from the past and capitalizing on= simple web-centric concepts like ORIGIN is one great enabler. This draft e= ven extends these more modern concepts to things like SIP to help simplify s= ome of the more conventional technologies. >=20 >=20 > Cheers, > John >=20 > AVAYA > 1.919.425.8446=20 >=20 >=20 > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in]=20 > Sent: Monday, May 11, 2015 7:30 PM > To: The IESG > Cc: tram-chairs@ietf.org; draft-ietf-tram-stun-origin.shepherd@ietf.org; d= raft-ietf-tram-stun-origin.ad@ietf.org; sperreault@jive.com; draft-ietf-tram= -stun-origin@ietf.org; tram@ietf.org > Subject: Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with D= ISCUSS) >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-tram-stun-origin-05: Discuss >=20 > When responding, please keep the subject line intact and reply to all emai= l addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) >=20 >=20 > Please refer to https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www= .ietf.org_iesg_statement_discuss-2Dcriteria.html&d=3DAwICaQ&c=3DBFpWQw8bsuKp= l1SgiZH64Q&r=3DO4OIzAW7EVPxOEhYXzj7Eg&m=3DUUw6tlPYwiPTqTiPb-8d0JzXAshUyyMqbE= veZ1APHyg&s=3D7-Ky3gBkj-nh5lszKh8A2T5LKV9tUum5QpJKbNUFUeM&e=3D > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_doc_draft-2Dietf-2Dtram-2Dstun-2Dorigin_&d=3DAwICaQ&c=3DBFpWQw8bsuKpl1SgiZ= H64Q&r=3DO4OIzAW7EVPxOEhYXzj7Eg&m=3DUUw6tlPYwiPTqTiPb-8d0JzXAshUyyMqbEveZ1AP= Hyg&s=3DqyAN_jyGYafpPgJ3Hxg9bybo3UDOUHoCxUU2CZhcpmQ&e=3D=20 >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This is a bit of a weird DISCUSS since I didn't manage to ballot when the > document was first on the IESG's agenda, so I'm coming in mid-stream. >=20 > I support Stephen's DISCUSS. If Alan's proposed changes make it into the > document, they would resolve most of my concerns. However, I still see a > problem with this proposed new text: >=20 > "For STUN requests sent without authentication to a STUN server (i.e. >=20 > STUN binding requests sent to a STUN server), the STUN client SHOULD=20 >=20 > include the ORIGIN attribute. The ORIGIN attribute MUST NOT be > included=20 >=20 > if it is a "privacy-sensitive" context, as discussed in the Security > Considerations >=20 > section." >=20 > For requests sent with authentication, I understand that the origin > attribute needs to be accurate in order for the client to authenticate. > In those cases, the STUN server can rely on the attribute it receives. > But for requests without authentication, what prevents the client from > lying? And if those requests are not (D)TLS-protected, what prevents them > from being modified in transit? I understand Alan to be saying that the > justification for the origin in this case is operational troubleshooting, > but if the server can't rely on the origin it receives, doesn't that make > it risky for the server to act on that information? >=20 > My additional concern is about the use of "logging" as a justification > for including and origin attribute. Logging in and of itself is not a > reasonable justification. Alan's mail discussed the use of the origin for > operational troubleshooting, which seems like what might actually be > intended instead of "logging." In any event the purpose for the logging > either needs to be explained or "logging" should not be listed as a > justification. >=20 >=20 >=20 >=20 From nobody Thu May 14 08:55:47 2015 Return-Path: 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 291171A8718; Thu, 14 May 2015 08:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 bDoDLNWfG1Lf; Thu, 14 May 2015 08:55:38 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5E91A8732; Thu, 14 May 2015 08:55:35 -0700 (PDT) Received: by labbd9 with SMTP id bd9so74286117lab.2; Thu, 14 May 2015 08:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8mb7idLwEuLkASrc2zYunjXAce4dK4MVkJxdT2kpmz4=; b=Bgi9fto2VU1/1bIzShCOsebPUt+aWI+wrSxt+TGOBBg7bomXrfFsn/RH8wk1KUBuRA O1PcWZRafsYyOmdE9bWO5BTL2t2UUjUlGN7idrpGUBlu7xTc87V11wyBwOW3tLsBW8zu I3CP1a7hYO80F4v5YF4hFkHm9iElcgFAwSzI3E2kvlJuyuj49kx+7YOMlf+ShXCAqkYD R8sjtFjP/T4KRhGLkDmJS1xWlqEUgD7NevvtozdspbfrUCIDwLHDeqe7PQYN+YGFhfPJ tZPeEiNiopmJRFiuIwiDWqnJPSgTTr9xffvGsTDyaRqhzWSL/HYipX5egkINPuwFEahq ExhA== MIME-Version: 1.0 X-Received: by 10.152.204.7 with SMTP id ku7mr3765011lac.38.1431618934152; Thu, 14 May 2015 08:55:34 -0700 (PDT) Received: by 10.152.129.3 with HTTP; Thu, 14 May 2015 08:55:34 -0700 (PDT) In-Reply-To: <13E02B6B-0D89-4AD3-8B69-06426A26732E@cooperw.in> References: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> <93BEDDC39A54294B9E78C7860516FA47673B781F@AZ-US1EXMB06.global.avaya.com> <13E02B6B-0D89-4AD3-8B69-06426A26732E@cooperw.in> Date: Thu, 14 May 2015 10:55:34 -0500 Message-ID: From: Spencer Dawkins at IETF To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=001a1134309206252905160cc232 Archived-At: Cc: "tram-chairs@ietf.org" Subject: Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 15:55:45 -0000 --001a1134309206252905160cc232 Content-Type: text/plain; charset=UTF-8 Dear TRAMsters, Thanks to everyone who has helped with IESG evaluation for this draft so far. We had a nice conversation on today's formal telechat about this document, and I summarized the state of play as --- BEGIN Barry's Discuss has been resolved Ben's Discuss has been resolved Benoit forwarded the OPSDIR review that hadn't gotten where it needed to go, and it will be handled The Gen-ART review will be handled Stephen's Discuss had a few parts - what "analytics" are we talking about here? I think the answer was "for network operation and debugging". This was also in Alissa's Discuss, but she was OK with adding text to explain that. Origin was intended to be the equivalent of Host in HTTP, and the analytic impact is no worse than one IP address per realm, which is what's used today. - this also touched on "MUST NOT send Origin if it's privacy-sensitive, but Stephen didn't think that was the right answer - Stephen also asked why Origin and third-party-auth were both needed. The answer was that SIP would require a lot of changes to use third-party-auth. Alissa's Discuss had a few parts, and Stephen included a couple of additional questions in her ballot thread. - what kinds of things needed to be logged, and what the privacy implications were - whether unauthenticated requests could be twiddled with. The answer is that they can be, so you should require authentication if you care. - Stephen included a question about unique usernames across realms - Stephen included a question about a client with a username in more than one realm playing games with which username it submits to avoid charging. I thought the answer was that anyone charging would be doing it off either signaling or media and not off STUN, but Simon corrected me that charging for operators who only provide TURN servers would be in scope, so it's still an open question. This was also in Stephen's Discuss thread, on "lying", - Stephen included a question about user-memorable usernames being long-lived, and tied to an identity. The answer was that this is not true for RTCWeb, but was true for SIP. --- END After chatting on the call, here's what I think needs to happen. There are relatively minor comments and questions, most of which have been answered, but there are a couple of large and more intertwined questions that the IESG needs help with, especially in understanding the relationship between Origin and third-party-authz, and how long-lived usernames (in SIP) versus short-lived or even ephemeral usernames (which are possible in RTCWeb) work in the same protocol mechanism. The IESG has regularly-scheduled "informal telechats" every two weeks, to work through questions like this. It would be helpful for Simon (as document shepherd) and any authors who should participate to attend one, so we can work through the high-order questions. The next informal telechat is next week, May 21, at 10 AM EDT. The coordinates are https://workgreen.webex.com/workgreen/j.php?MTID=m305722fec48b24d34908d4074b6f0bbe Meeting number: 826 345 248 Meeting password: 1234 If you'd like to take the opportunity to have that conversation, please let me know, and I'll add draft-ietf-tram-stun-origin to the agenda. Thanks for all your work to date, and we'll get through the questions. Spencer --001a1134309206252905160cc232 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear TRAMsters,

Thanks to everyone who = has helped with IESG evaluation for this draft so far.

We had a nice conversation on today's formal telechat=C2=A0about thi= s document, and I summarized the state of play as=C2=A0

--- BEGIN

Barry's Discuss has been = resolved

Ben's Discuss has been resolved
=

Benoit forwarded the OPSDIR review that hadn't gott= en where it needed to go, and it will be handled

T= he Gen-ART review will be handled

Stephen's Di= scuss had a few parts

- what "analytics"= are we talking about here? I think the answer was "for network operat= ion and debugging". This was also in Alissa's Discuss, but she was= OK with adding text to explain that. Origin was intended to be the equival= ent of Host in HTTP, and the analytic impact is no worse than one IP addres= s per realm, which is what's used today.

- thi= s also touched on "MUST NOT send Origin if it's privacy-sensitive,= but Stephen didn't think that was the right answer

- Stephen also asked why Origin and third-party-auth were both needed= . The answer was that SIP would require a lot of changes to use third-party= -auth.

Alissa's Discuss had a few parts, and S= tephen included a couple of additional questions in her ballot thread.

- what kinds of things needed to be logged, and what t= he privacy implications were

- whether unauthentic= ated requests could be twiddled with. The answer is that they can be, so yo= u should require authentication if you care.

- Ste= phen included a question about unique usernames across realms
- Stephen included a question about a client with a username in= more than one realm =C2=A0playing games with which username it submits to = avoid charging. I thought the answer was that anyone charging would be doin= g it off either signaling or media and not off STUN, but Simon corrected me= that charging for operators who only provide TURN servers would be in scop= e, so it's still an open question. This was also in Stephen's Discu= ss thread, on "lying",

- Stephen include= d a question about user-memorable usernames being long-lived, and tied to a= n identity. The answer was that this is not true for RTCWeb, but was true f= or SIP.

--- END

Aft= er chatting on the call, here's what I think needs to happen.

There are relatively minor comments and questions, most of = which have been answered, but there are a couple of large and more intertwi= ned questions that the IESG needs help with, especially in understanding th= e relationship between Origin and third-party-authz, and how long-lived use= rnames (in SIP) versus short-lived or even ephemeral usernames (which are p= ossible in RTCWeb) work in the same protocol mechanism.

The IESG has regularly-scheduled "informal telechats" every= two weeks, to work through questions like this. It would be helpful for Si= mon (as document shepherd) and any authors who should participate to attend= one, so we can work through the high-order questions.

=
The next informal telechat is next week, May 21, at 10 AM EDT. The coo= rdinates are=C2=A0


If you'd like to take the opportun= ity to have that conversation, please let me know, and I'll add=C2=A0dr= aft-ietf-tram-stun-origin to the agenda.

Thanks fo= r all your work to date, and we'll get through the questions.

Spencer
--001a1134309206252905160cc232-- From nobody Thu May 14 09:08:51 2015 Return-Path: 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 BCEFC1A879F; Thu, 14 May 2015 09:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 h9PI8PxrteTE; Thu, 14 May 2015 09:08:48 -0700 (PDT) Received: from mail-vn0-x233.google.com (mail-vn0-x233.google.com [IPv6:2607:f8b0:400c:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3A81A8797; Thu, 14 May 2015 09:08:48 -0700 (PDT) Received: by vnbf190 with SMTP id f190so5493429vnb.10; Thu, 14 May 2015 09:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cs6+FAkwUvc+p36z8wzWnXQdaDpJvWSPIxmCqTmTnus=; b=VuiI29msoUnsERJ/dFXqbwPjPJQ7WU+IqnpKQv4LG7KPbmaRki0u6MdLmog95lWaxW daka6p0+tNC7vftw6h1WqcBxGHzJOOunEJlvhUhqxfGu5bjo6CFZAC/lCtsvUnz7xslo eC9ybFEjOkFj1u58y7nEzpeNuymAnYTckrwqXJOBJsNyDEdKhc7wd1bsukKhLtiiDMvp IdqMvojiZeDqqtIpd8Xc/xnDIfrnz563lOiCrhfRohJawHM3L3/3xzwWfoCoToHjY0kT WILLGBmnftJ6CEzbvk7KLssFAg7yJGFuU9XPLtqXBzBUG9YAnkRLJgZKpqRzqX0QmphZ RyqA== MIME-Version: 1.0 X-Received: by 10.52.240.137 with SMTP id wa9mr4419313vdc.97.1431619727146; Thu, 14 May 2015 09:08:47 -0700 (PDT) Received: by 10.52.106.100 with HTTP; Thu, 14 May 2015 09:08:47 -0700 (PDT) In-Reply-To: References: <20150511233012.17046.42319.idtracker@ietfa.amsl.com> <93BEDDC39A54294B9E78C7860516FA47673B781F@AZ-US1EXMB06.global.avaya.com> <13E02B6B-0D89-4AD3-8B69-06426A26732E@cooperw.in> Date: Thu, 14 May 2015 11:08:47 -0500 Message-ID: From: Alan Johnston To: Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary=20cf30780dae4a461a05160cf1aa Archived-At: Cc: "tram-chairs@ietf.org" , "tram@ietf.org" Subject: Re: [tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 16:08:50 -0000 --20cf30780dae4a461a05160cf1aa Content-Type: text/plain; charset=UTF-8 Thanks, Spencer. I think this is a very good path forward. I will join next week's call. - Alan - On Thu, May 14, 2015 at 10:55 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Dear TRAMsters, > > Thanks to everyone who has helped with IESG evaluation for this draft so > far. > > We had a nice conversation on today's formal telechat about this document, > and I summarized the state of play as > > --- BEGIN > > Barry's Discuss has been resolved > > Ben's Discuss has been resolved > > Benoit forwarded the OPSDIR review that hadn't gotten where it needed to > go, and it will be handled > > The Gen-ART review will be handled > > Stephen's Discuss had a few parts > > - what "analytics" are we talking about here? I think the answer was "for > network operation and debugging". This was also in Alissa's Discuss, but > she was OK with adding text to explain that. Origin was intended to be the > equivalent of Host in HTTP, and the analytic impact is no worse than one IP > address per realm, which is what's used today. > > - this also touched on "MUST NOT send Origin if it's privacy-sensitive, > but Stephen didn't think that was the right answer > > - Stephen also asked why Origin and third-party-auth were both needed. The > answer was that SIP would require a lot of changes to use third-party-auth. > > Alissa's Discuss had a few parts, and Stephen included a couple of > additional questions in her ballot thread. > > - what kinds of things needed to be logged, and what the privacy > implications were > > - whether unauthenticated requests could be twiddled with. The answer is > that they can be, so you should require authentication if you care. > > - Stephen included a question about unique usernames across realms > > - Stephen included a question about a client with a username in more than > one realm playing games with which username it submits to avoid charging. > I thought the answer was that anyone charging would be doing it off either > signaling or media and not off STUN, but Simon corrected me that charging > for operators who only provide TURN servers would be in scope, so it's > still an open question. This was also in Stephen's Discuss thread, on > "lying", > > - Stephen included a question about user-memorable usernames being > long-lived, and tied to an identity. The answer was that this is not true > for RTCWeb, but was true for SIP. > > --- END > > After chatting on the call, here's what I think needs to happen. > > There are relatively minor comments and questions, most of which have been > answered, but there are a couple of large and more intertwined questions > that the IESG needs help with, especially in understanding the relationship > between Origin and third-party-authz, and how long-lived usernames (in SIP) > versus short-lived or even ephemeral usernames (which are possible in > RTCWeb) work in the same protocol mechanism. > > The IESG has regularly-scheduled "informal telechats" every two weeks, to > work through questions like this. It would be helpful for Simon (as > document shepherd) and any authors who should participate to attend one, so > we can work through the high-order questions. > > The next informal telechat is next week, May 21, at 10 AM EDT. The > coordinates are > > > https://workgreen.webex.com/workgreen/j.php?MTID=m305722fec48b24d34908d4074b6f0bbe > Meeting number: 826 345 248 > Meeting password: 1234 > > If you'd like to take the opportunity to have that conversation, please > let me know, and I'll add draft-ietf-tram-stun-origin to the agenda. > > Thanks for all your work to date, and we'll get through the questions. > > Spencer > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --20cf30780dae4a461a05160cf1aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Spencer.=C2=A0 I think this is a very good path fo= rward. I will join next week's call.

- Alan -
<= /div>

On Thu, May = 14, 2015 at 10:55 AM, Spencer Dawkins at IETF <spencerdawkins.= ietf@gmail.com> wrote:
Dear TRAMsters,

Thanks to everyone who has = helped with IESG evaluation for this draft so far.

W= e had a nice conversation on today's formal telechat=C2=A0about this do= cument, and I summarized the state of play as=C2=A0

--- BEGIN

Barry's Discuss has been reso= lved

Ben's Discuss has been resolved

Benoit forwarded the OPSDIR review that hadn't gotten w= here it needed to go, and it will be handled

The G= en-ART review will be handled

Stephen's Discus= s had a few parts

- what "analytics" are= we talking about here? I think the answer was "for network operation = and debugging". This was also in Alissa's Discuss, but she was OK = with adding text to explain that. Origin was intended to be the equivalent = of Host in HTTP, and the analytic impact is no worse than one IP address pe= r realm, which is what's used today.

- this al= so touched on "MUST NOT send Origin if it's privacy-sensitive, but= Stephen didn't think that was the right answer

- Stephen also asked why Origin and third-party-auth were both needed. Th= e answer was that SIP would require a lot of changes to use third-party-aut= h.

Alissa's Discuss had a few parts, and Steph= en included a couple of additional questions in her ballot thread.

- what kinds of things needed to be logged, and what the p= rivacy implications were

- whether unauthenticated= requests could be twiddled with. The answer is that they can be, so you sh= ould require authentication if you care.

- Stephen= included a question about unique usernames across realms

- Stephen included a question about a client with a username in mor= e than one realm =C2=A0playing games with which username it submits to avoi= d charging. I thought the answer was that anyone charging would be doing it= off either signaling or media and not off STUN, but Simon corrected me tha= t charging for operators who only provide TURN servers would be in scope, s= o it's still an open question. This was also in Stephen's Discuss t= hread, on "lying",

- Stephen included a = question about user-memorable usernames being long-lived, and tied to an id= entity. The answer was that this is not true for RTCWeb, but was true for S= IP.

--- END

After c= hatting on the call, here's what I think needs to happen.
There are relatively minor comments and questions, most of whic= h have been answered, but there are a couple of large and more intertwined = questions that the IESG needs help with, especially in understanding the re= lationship between Origin and third-party-authz, and how long-lived usernam= es (in SIP) versus short-lived or even ephemeral usernames (which are possi= ble in RTCWeb) work in the same protocol mechanism.

The IESG has regularly-scheduled "informal telechats" every two= weeks, to work through questions like this. It would be helpful for Simon = (as document shepherd) and any authors who should participate to attend one= , so we can work through the high-order questions.

The next informal telechat is next week, May 21, at 10 AM EDT. The coordin= ates are=C2=A0


If you'd like to t= ake the opportunity to have that conversation, please let me know, and I= 9;ll add=C2=A0draft-ietf-tram-stun-origin to the agenda.

Thanks for all your work to date, and we'll get through the ques= tions.

<= div>Spencer

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--20cf30780dae4a461a05160cf1aa-- From nobody Thu May 14 10:56:16 2015 Return-Path: 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 B7BF81B2CB3 for ; Thu, 14 May 2015 10:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 1pr8cI5hAZay for ; Thu, 14 May 2015 10:56:13 -0700 (PDT) Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E2B1B2C99 for ; Thu, 14 May 2015 10:56:13 -0700 (PDT) Received: by qkgw4 with SMTP id w4so14285349qkg.3 for ; Thu, 14 May 2015 10:56:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Po6aGn/OW+z3YtlbirXmLtuxFskHKKizfBbT8y7gVdk=; b=NpleZEuzBHA6C1kkVOTCzuvszPUuBBqpv9p5tD7FhYVQtjiYV9cRb349fazZZv+JYw WwhV+kvdMg32oMoBmMOCGVnNlAkafeH6sJHroV1yEju79q0CUxva3YBGGJ4KIfzYEiC6 UmhLk+vAk9jyZfzSP5RdR8wJDL2S+TGqcsoeKFjvEie/rIZeTmo6wZqcW5BxrgRQ+1nM cmBf3wzsUcC+6G4mPCGPPJaxi5Pd1G9fRrUrIj+kUo9+RbOAl4KezoeiWYu11krFU8ZR NBK4Fwhu5ixdFilXungsA7WIHZmQBF3wOys/GvEGxK2JRoX1dkrzqJvCHZImLenTt7Xr pS4g== X-Gm-Message-State: ALoCoQlZNOvQ6aQ6gBBSuJh511KBSP3NyUJlhIKb6RNaSWrGlyeG1vMxmRlaHZcsbM5554VcS5N5 X-Received: by 10.140.36.137 with SMTP id p9mr7048941qgp.16.1431626172329; Thu, 14 May 2015 10:56:12 -0700 (PDT) Received: from [192.168.1.131] ([24.53.47.130]) by mx.google.com with ESMTPSA id 93sm18294439qkx.38.2015.05.14.10.56.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 10:56:11 -0700 (PDT) Message-ID: <5554E1B9.5090201@jive.com> Date: Thu, 14 May 2015 13:56:09 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [tram] STUN auth: The endpoint is in control 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 17:56:14 -0000 TRAMsters, I think it is important, in order to make STUN's authentication model clearer in the face of WebRTC usage, that we start re-emphasizing that the endpoint is in control of its own NAT traversal, independent of call signalling. This is a core design principle of STUN/TURN/ICE. ======================= Exhibit A: This is a freely-available STUN/TURN server. You just sign up for an account and start using it with whatever signalling infrastructure you want. With SIP, just configure the server address, username, and password into your SIP client and you're ready to go. With WebRTC you can do the same by configuring those into your browser, which should override any application-provided servers. Notice that the endpoint is fully in charge of its own destiny. It has a relationship with the server, but the signalling infrastructure does not. With this use-case the IP addresses on which the server listens are dedicated to the public service. ORIGIN would be useful in order to co-locate the public service with some class of private services (different auth database) without dedicating new IP addresses for each private service. ======================== Exhibit B: RETURN is a way for WebRTC endpoints, browsers in particular, to force usage of a particular TURN server, with which the endpoint has a prior trust relationship, in order to ensure some level of privacy for the endpoint. A second layer of non-privacy-providing TURN may be used in order to provide NAT traversal. In this case too the endpoint is fully in control. The signalling infrastructure (i.e., the WebRTC application) has no relationship with the privacy-providing TURN server, and no control over it. ======================== What I'm getting at is that trying to bind STUN auth with the signalling session goes against STUN/TURN/ICE design. Thoughts? Comments? Simon From nobody Thu May 14 13:39:46 2015 Return-Path: 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 E8F061A87ED for ; Thu, 14 May 2015 13:39:44 -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 KSBJLu0zN2uz for ; Thu, 14 May 2015 13:39:42 -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 E07A21A8783 for ; Thu, 14 May 2015 13:39:41 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9C3DF286EF for ; Thu, 14 May 2015 20:39:40 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 8B9E1286F1 for ; Thu, 14 May 2015 20:39:40 +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 869962082 for ; Thu, 14 May 2015 20:39:40 +0000 (GMT) Message-ID: <5555080C.7070009@akamai.com> Date: Thu, 14 May 2015 16:39:40 -0400 From: Brandon Williams 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 References: <5554E1B9.5090201@jive.com> In-Reply-To: <5554E1B9.5090201@jive.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] STUN auth: The endpoint is in control 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 20:39:45 -0000 Hi Simon, I agree that this usage model can be desirable in many cases. For example, if my enterprise or ISP provides TURN relay service to me, I will likely get better performance if I use that rather than using a relay service with a very small data center footprint that is not geographically diverse. It should be possible for me to choose to use this more optimal relay service as my data path if the relay preferred by my application would be less optimal for performance. Likewise, a remotely located fixed point relay service might be a better selection for privacy reasons, and if privacy is my primary concern then I should be able to select that relay service. Where you and I may differ (I'm uncertain from this e-mail) is on the question of whether I should be able to use any relay service to which I have access as the data path for any data flow. If the relay service is preferred and paid for by one application service that I use, should I be able to use that relay service for any/all of my p2p applications? Or should it be possible for the relay service to limit use to just the applications that have been approved for access? On the one hand, I think that I as an end user should be able to pick which of the acceptable relays will be used for a particular data flow based on my requirements for that session. On the other hand, I also think that the relay service provider should be able to limit access in cases where the relay service has a relationship with the application provider and not with me. The protocol doesn't allow this differentiation today, but I don't think that means that it must not allow this in the future. In short, I don't think that the protocol should _require_ any sort of binding between the signaling session and STUN auth, but I do think that in some cases there may be reasons to _allow_ such binding. --Brandon On 05/14/2015 01:56 PM, Simon Perreault wrote: > TRAMsters, > > I think it is important, in order to make STUN's authentication model > clearer in the face of WebRTC usage, that we start re-emphasizing that > the endpoint is in control of its own NAT traversal, independent of call > signalling. This is a core design principle of STUN/TURN/ICE. > > ======================= > > Exhibit A: > > This is a freely-available STUN/TURN server. You just sign up for an > account and start using it with whatever signalling infrastructure you > want. With SIP, just configure the server address, username, and > password into your SIP client and you're ready to go. With WebRTC you > can do the same by configuring those into your browser, which should > override any application-provided servers. > > Notice that the endpoint is fully in charge of its own destiny. It has a > relationship with the server, but the signalling infrastructure does not. > > With this use-case the IP addresses on which the server listens are > dedicated to the public service. ORIGIN would be useful in order to > co-locate the public service with some class of private services > (different auth database) without dedicating new IP addresses for each > private service. > > ======================== > > Exhibit B: > > RETURN is a way for WebRTC endpoints, browsers in particular, to force > usage of a particular TURN server, with which the endpoint has a prior > trust relationship, in order to ensure some level of privacy for the > endpoint. A second layer of non-privacy-providing TURN may be used in > order to provide NAT traversal. > > In this case too the endpoint is fully in control. The signalling > infrastructure (i.e., the WebRTC application) has no relationship with > the privacy-providing TURN server, and no control over it. > > ======================== > > What I'm getting at is that trying to bind STUN auth with the signalling > session goes against STUN/TURN/ICE design. > > Thoughts? Comments? > > Simon > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. From nobody Thu May 14 14:05:58 2015 Return-Path: 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 B21A81A8AE5 for ; Thu, 14 May 2015 14:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 Y--dHeUWT0dC for ; Thu, 14 May 2015 14:05:53 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940261A8AE0 for ; Thu, 14 May 2015 14:05:53 -0700 (PDT) Received: by qgg76 with SMTP id 76so17875489qgg.3 for ; Thu, 14 May 2015 14:05:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yB/2nebiKYvemv2p+FH65v3mdaz6ItJv+R+khJJHarA=; b=IK1qXmVFetgsjNHlg2jR4k/SBea+kSu6LGHpGJxjfzgNqVcgWON47NnBs9AKFW73pT LfjFiF0iumPInbFMuMhu0l/bNeYogIQeh9VeMDetp1ZtzahRHcCXs9vN78zf9Dpj1OYf gltz3etIkuPNFB2xRj8k1B088swhybnb63xcirRe0O5ylOzoogDuBMqsC9WIzWQgUOoo 5Q+9MHRo1CysqxePjwVj5id8T7ozZ946tBcrQpZT8WhLRJB3uC3sM/hBV5kOy67M6ZY/ gB73t2e6sj78tM1ZR2SZ4GQ+gt9B8zkK0W8Tq/v4csdPTbT4E7lJ6XibtZjBCgvpZl9x Le8A== X-Gm-Message-State: ALoCoQnD/YKAG6hAeLSvuKxHjDAZgqJtXPgmltJfzwVEboQxT/j6O7FI8PkvETzLSvPLTzLSCBlM X-Received: by 10.229.98.200 with SMTP id r8mr8542927qcn.15.1431637552860; Thu, 14 May 2015 14:05:52 -0700 (PDT) Received: from [192.168.1.131] ([24.53.47.130]) by mx.google.com with ESMTPSA id k85sm131921qkh.48.2015.05.14.14.05.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 14:05:51 -0700 (PDT) Message-ID: <55550E2D.9050508@jive.com> Date: Thu, 14 May 2015 17:05:49 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Brandon Williams , tram@ietf.org References: <5554E1B9.5090201@jive.com> <5555080C.7070009@akamai.com> In-Reply-To: <5555080C.7070009@akamai.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] STUN auth: The endpoint is in control 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 21:05:55 -0000 Le 2015-05-14 16:39, Brandon Williams a écrit : > Where you and I may differ (I'm uncertain from this e-mail) is on the > question of whether I should be able to use any relay service to which I > have access as the data path for any data flow. If the relay service is > preferred and paid for by one application service that I use, should I > be able to use that relay service for any/all of my p2p applications? Or > should it be possible for the relay service to limit use to just the > applications that have been approved for access? The latter. You're right, this was not clear from my email. > On the one hand, I think that I as an end user should be able to pick > which of the acceptable relays will be used for a particular data flow > based on my requirements for that session. On the other hand, I also > think that the relay service provider should be able to limit access in > cases where the relay service has a relationship with the application > provider and not with me. The protocol doesn't allow this > differentiation today, but I don't think that means that it must not > allow this in the future. Fully agreed. Classical STUN auth, with or without ORIGIN, does not allow this limitation. Third-party-auth does (or I think it does, not quite sure anymore). > In short, I don't think that the protocol should _require_ any sort of > binding between the signaling session and STUN auth, but I do think that > in some cases there may be reasons to _allow_ such binding. Exactly. Schematically: OK: "example.com's TURN server can only be used on example.com" NOT OK: "example.com can only be used with example.com's TURN server" Simon From nobody Thu May 14 14:10:11 2015 Return-Path: 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 D64011A87D7 for ; Thu, 14 May 2015 14:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 7JjvCctyt8mS for ; Thu, 14 May 2015 14:10:08 -0700 (PDT) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E521A87BB for ; Thu, 14 May 2015 14:10:08 -0700 (PDT) Received: by qkgx75 with SMTP id x75so58386391qkg.1 for ; Thu, 14 May 2015 14:10:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=j5bRVIVB0DwYQQJ9/UZ2PfEMgY3QsWW5kh+ZYcZ50fU=; b=X7/Zuo/tppBYmhDynWRBYazUw4pS9SGO/wKCyB18hoZJ232SGAIIX7nUZ+mENg2Rnd bk2wps9mAKP0D/bmKgHWXe+/U0ssOLQmxg1jrpjv6L63Q62ByJsHnbMD6HgcGAAIyY73 UkMgWRyTKPSNYYkn+IOGg8licIqoj7LjQM6CFMloye69zmvFgyFIzRxQt5nJsVEtkycG zh0X+Zsy+pR791T8QtUoKzbnJnjWM3A51z4QdmLSn/evpZHlsx40kCrNRdfaxbafHaS1 O46r2de2bdFjvhyQIi9A5Ebh17WXIZmg4S8yG7KRaHXg1mPvq404kR4e0ga8jtgL3aIG fMwQ== X-Gm-Message-State: ALoCoQl5UYQHq5y4NnsUAIAdv1x4R1AowxlrNSW1/L/+FVFlLerJx6nQxZfFA7zf2rZSr4yhyjoJ X-Received: by 10.140.165.150 with SMTP id l144mr8308696qhl.99.1431637807857; Thu, 14 May 2015 14:10:07 -0700 (PDT) Received: from [192.168.1.131] ([24.53.47.130]) by mx.google.com with ESMTPSA id o189sm156349qhb.25.2015.05.14.14.10.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 14:10:07 -0700 (PDT) Message-ID: <55550F2D.6010303@jive.com> Date: Thu, 14 May 2015 17:10:05 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Brandon Williams , tram@ietf.org References: <5554E1B9.5090201@jive.com> <5555080C.7070009@akamai.com> <55550E2D.9050508@jive.com> In-Reply-To: <55550E2D.9050508@jive.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] STUN auth: The endpoint is in control 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 21:10:10 -0000 Le 2015-05-14 17:05, Simon Perreault a écrit : >> On the one hand, I think that I as an end user should be able to pick >> which of the acceptable relays will be used for a particular data flow >> based on my requirements for that session. On the other hand, I also >> think that the relay service provider should be able to limit access in >> cases where the relay service has a relationship with the application >> provider and not with me. The protocol doesn't allow this >> differentiation today, but I don't think that means that it must not >> allow this in the future. > > Fully agreed. Classical STUN auth, with or without ORIGIN, does not > allow this limitation. Actually, ephemeral credentials may be sufficient in many cases. It's not air-tight, but may be good enough. Just mentioning for completeness. Simon From nobody Fri May 15 05:56:46 2015 Return-Path: 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 4C5951A6FEC for ; Fri, 15 May 2015 05:56:45 -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 8LT7x50HMFzA for ; Fri, 15 May 2015 05:56:43 -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 BD2791A1EEA for ; Fri, 15 May 2015 05:55:54 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C106347F5F; Fri, 15 May 2015 12:55:53 +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 B556F47E60; Fri, 15 May 2015 12:55:53 +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 B0CEC2067; Fri, 15 May 2015 12:55:53 +0000 (GMT) Message-ID: <5555ECD9.1050501@akamai.com> Date: Fri, 15 May 2015 08:55:53 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Simon Perreault , tram@ietf.org References: <5554E1B9.5090201@jive.com> <5555080C.7070009@akamai.com> <55550E2D.9050508@jive.com> In-Reply-To: <55550E2D.9050508@jive.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] STUN auth: The endpoint is in control 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 12:56:45 -0000 On 05/14/2015 05:05 PM, Simon Perreault wrote: >> On the one hand, I think that I as an end user should be able to pick >> >which of the acceptable relays will be used for a particular data flow >> >based on my requirements for that session. On the other hand, I also >> >think that the relay service provider should be able to limit access in >> >cases where the relay service has a relationship with the application >> >provider and not with me. The protocol doesn't allow this >> >differentiation today, but I don't think that means that it must not >> >allow this in the future. > Fully agreed. Classical STUN auth, with or without ORIGIN, does not > allow this limitation. Third-party-auth does (or I think it does, not > quite sure anymore). > Even with third-party-auth and/or a creative use of short-term credentials, I think that all we can get today is an assurance that I must be a user of an authorized service in order to get an allocation. Once I have an allocation, there's no way via STUN/TURN for the relay service to know whether a specific ChannelBind/Permission is also approved by the application service. I can use my established allocation for any data flow I want unless the relay service and the application service build an OOB method for validation. I think it would be fairly easy to build peer address signing into the protocol such that it would be possible to enforce such a limitation. I'll be curious to hear whether anyone else would be interested in this. --Brandon -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. From nobody Fri May 15 06:09:03 2015 Return-Path: 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 BE45B1A1BE6 for ; Fri, 15 May 2015 06:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 jLikklZl7PoD for ; Fri, 15 May 2015 06:09:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 048F61A0023 for ; Fri, 15 May 2015 06:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2585; q=dns/txt; s=iport; t=1431695341; x=1432904941; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cWv3IyJbWFI8JMPMDIZqXvuleulJkeiti/IYUJLp3GI=; b=eXtNhvmWFCK58Enec4+tuskDWxqyx0YGyx0Qrl7bazO0bmnYn7xCGZuO THcPqQhEHW9k1lCS9YLZZiL7G4I4lXD9vILNQJPE9aNNzeaEpKUFhmGte pSJRTY/hidvmanwl8WGRMIJwJ6SeRLjU24x4vPk6LBJkVtJNBwejQAA88 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AUBQBP71VV/4MNJK1cgw9UXgbDd4I+CoV2AoE5TAEBAQEBAYELhCIBAQEDAQEBATc0BBMEAgEIEQQBAQEKFAkHJwsUCQgCBAESCIgcCA3WawEBAQEBAQEBAQEBAQEBAQEBAQEBARMEizqELQ0aOAaDEYEWBZJhhCmCSpp/I2GDF2+BBAEeBhyBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,433,1427760000"; d="scan'208";a="420004132" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP; 15 May 2015 13:09:00 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t4FD906n019114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 May 2015 13:09:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Fri, 15 May 2015 08:08:59 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] STUN auth: The endpoint is in control Thread-Index: AQHQjm9JsVuipIFzokmPTt0sRQQlWp18QyYAgAAHToCAAQlygP//rXyQ Date: Fri, 15 May 2015 13:08:59 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47845269@xmb-rcd-x10.cisco.com> References: <5554E1B9.5090201@jive.com> <5555080C.7070009@akamai.com> <55550E2D.9050508@jive.com> <5555ECD9.1050501@akamai.com> In-Reply-To: <5555ECD9.1050501@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.18.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] STUN auth: The endpoint is in control 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 13:09:02 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Friday, May 15, 2015 6:26 PM > To: Simon Perreault; tram@ietf.org > Subject: Re: [tram] STUN auth: The endpoint is in control >=20 > On 05/14/2015 05:05 PM, Simon Perreault wrote: > >> On the one hand, I think that I as an end user should be able to pick > >> >which of the acceptable relays will be used for a particular data > >> >flow based on my requirements for that session. On the other hand, I > >> >also think that the relay service provider should be able to limit > >> >access in cases where the relay service has a relationship with the > >> >application provider and not with me. The protocol doesn't allow > >> >this differentiation today, but I don't think that means that it > >> >must not allow this in the future. > > Fully agreed. Classical STUN auth, with or without ORIGIN, does not > > allow this limitation. Third-party-auth does (or I think it does, not > > quite sure anymore). > > >=20 > Even with third-party-auth and/or a creative use of short-term credential= s, I > think that all we can get today is an assurance that I must be a user of = an > authorized service in order to get an allocation. > Once I have an allocation, there's no way via STUN/TURN for the relay > service to know whether a specific ChannelBind/Permission is also approve= d > by the application service. I can use my established allocation for any d= ata > flow I want unless the relay service and the application service build an= OOB > method for validation. Yes, we are exploring that option to prevent misuse, it helps the Enterpris= e TURN server use-cases where FW is configured to only permit UDP traffic t= o well-known TURN servers. Enterprise TURN server is configured to support = both first party authentication and third party authorization to differenti= ate b/w calls. Token introspection work done in OAuth 2.0 https://tools.iet= f.org/html/draft-ietf-oauth-introspection-08 can be leveraged for this purp= ose. >=20 > I think it would be fairly easy to build peer address signing into the pr= otocol > such that it would be possible to enforce such a limitation. > I'll be curious to hear whether anyone else would be interested in this. -Tiru >=20 > --Brandon >=20 > -- > Brandon Williams; Chief Architect > Cloud Networking; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri May 15 06:39:20 2015 Return-Path: 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 08A401A8A0E for ; Fri, 15 May 2015 06:39:18 -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 KcBw6BCgJ1Bv for ; Fri, 15 May 2015 06:39:15 -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 B3EBF1A0389 for ; Fri, 15 May 2015 06:38:11 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E637747F73; Fri, 15 May 2015 13:38:10 +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 D14E547F6A; Fri, 15 May 2015 13:38:10 +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 CE18A2071; Fri, 15 May 2015 13:38:10 +0000 (GMT) Message-ID: <5555F6C2.2060507@akamai.com> Date: Fri, 15 May 2015 09:38:10 -0400 From: Brandon Williams 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)" , Simon Perreault , "tram@ietf.org" References: <5554E1B9.5090201@jive.com> <5555080C.7070009@akamai.com> <55550E2D.9050508@jive.com> <5555ECD9.1050501@akamai.com> <913383AAA69FF945B8F946018B75898A47845269@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A47845269@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] STUN auth: The endpoint is in control 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 13:39:18 -0000 Just to be clear, I wasn't suggesting that I think an OOB communication method between the relay server and the application server is the right approach for this. I'd prefer an in-band validation method; perhaps one that takes advantage of the keys used for 3rd party auth and/or an auth key used for app server origin signing as per Stephen's suggestion. --Brandon On 05/15/2015 09:08 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams >> Sent: Friday, May 15, 2015 6:26 PM >> To: Simon Perreault; tram@ietf.org >> Subject: Re: [tram] STUN auth: The endpoint is in control >> >> On 05/14/2015 05:05 PM, Simon Perreault wrote: >>>> On the one hand, I think that I as an end user should be able to pick >>>>> which of the acceptable relays will be used for a particular data >>>>> flow based on my requirements for that session. On the other hand, I >>>>> also think that the relay service provider should be able to limit >>>>> access in cases where the relay service has a relationship with the >>>>> application provider and not with me. The protocol doesn't allow >>>>> this differentiation today, but I don't think that means that it >>>>> must not allow this in the future. >>> Fully agreed. Classical STUN auth, with or without ORIGIN, does not >>> allow this limitation. Third-party-auth does (or I think it does, not >>> quite sure anymore). >>> >> >> Even with third-party-auth and/or a creative use of short-term credentials, I >> think that all we can get today is an assurance that I must be a user of an >> authorized service in order to get an allocation. >> Once I have an allocation, there's no way via STUN/TURN for the relay >> service to know whether a specific ChannelBind/Permission is also approved >> by the application service. I can use my established allocation for any data >> flow I want unless the relay service and the application service build an OOB >> method for validation. > > Yes, we are exploring that option to prevent misuse, it helps the Enterprise TURN server use-cases where FW is configured to only permit UDP traffic to well-known TURN servers. Enterprise TURN server is configured to support both first party authentication and third party authorization to differentiate b/w calls. Token introspection work done in OAuth 2.0 https://tools.ietf.org/html/draft-ietf-oauth-introspection-08 can be leveraged for this purpose. > >> >> I think it would be fairly easy to build peer address signing into the protocol >> such that it would be possible to enforce such a limitation. >> I'll be curious to hear whether anyone else would be interested in this. > > -Tiru > >> >> --Brandon >> >> -- >> Brandon Williams; Chief Architect >> Cloud Networking; Akamai Technologies Inc. >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. From nobody Fri May 15 07:21:00 2015 Return-Path: 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 0F5731A92E1 for ; Fri, 15 May 2015 07:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 NLLHZmfii3xS for ; Fri, 15 May 2015 07:20:53 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E517E1A92BC for ; Fri, 15 May 2015 07:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3855; q=dns/txt; s=iport; t=1431699653; x=1432909253; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Oh1Sl/snqJi5lZMT08MXFFGnhz4qrJ/AKvyztBDEzs8=; b=mbIa4zvq0VwGh5J5RUudH9mzWyaKOv7MScCGU2Yl5YgpEMTQcCBZd9ns 6trw92RqBxx26kdf4HdFJTlbUH9tjS3lT72XGgipydmmA8h0BY94Bt89n UXNXdsB1ez2EtTgYlgBfpEwFNlkCqpqbF11kIWaOe1QUHq3v4lrevAsxa A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BWBADy/1VV/5JdJa1cgw9UXgbDeWYJgU8KhXYCgTk4FAEBAQEBAQGBCoQiAQEBBAEBATc0BBMEAgEIEQQBAQEKFAkHJwsUCQgCBAESCIgkDdcFAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLOoQtDRo4BoMRgRYFkmGEKYJKmn8jYYMXb4EEAR4GHIEBAQEB X-IronPort-AV: E=Sophos;i="5.13,434,1427760000"; d="scan'208";a="150496435" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP; 15 May 2015 14:20:52 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t4FEKpJq003206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 May 2015 14:20:52 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Fri, 15 May 2015 09:20:51 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] STUN auth: The endpoint is in control Thread-Index: AQHQjm9JsVuipIFzokmPTt0sRQQlWp18QyYAgAAHToCAAQlygP//rXyQgABeVQD//7WBsA== Date: Fri, 15 May 2015 14:20:50 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478452CF@xmb-rcd-x10.cisco.com> References: <5554E1B9.5090201@jive.com> <5555080C.7070009@akamai.com> <55550E2D.9050508@jive.com> <5555ECD9.1050501@akamai.com> <913383AAA69FF945B8F946018B75898A47845269@xmb-rcd-x10.cisco.com> <5555F6C2.2060507@akamai.com> In-Reply-To: <5555F6C2.2060507@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.18.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] STUN auth: The endpoint is in control 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 14:20:59 -0000 > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Friday, May 15, 2015 7:08 PM > To: Tirumaleswar Reddy (tireddy); Simon Perreault; tram@ietf.org > Subject: Re: [tram] STUN auth: The endpoint is in control >=20 > Just to be clear, I wasn't suggesting that I think an OOB communication > method between the relay server and the application server is the right > approach for this. I'd prefer an in-band validation method; perhaps one t= hat > takes advantage of the keys used for 3rd party auth and/or an auth key us= ed > for app server origin signing as per Stephen's suggestion. I am not sure how this mechanism works. Application server will only be awa= re of the selected candidates after the controlling endpoint sends an updat= ed offer after ICE connectivity checks are complete. The other problem is p= eer-reflexive candidates will be discovered during ICE checks. -Tiru >=20 > --Brandon >=20 > On 05/15/2015 09:08 AM, Tirumaleswar Reddy (tireddy) wrote: > >> -----Original Message----- > >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon > >> Williams > >> Sent: Friday, May 15, 2015 6:26 PM > >> To: Simon Perreault; tram@ietf.org > >> Subject: Re: [tram] STUN auth: The endpoint is in control > >> > >> On 05/14/2015 05:05 PM, Simon Perreault wrote: > >>>> On the one hand, I think that I as an end user should be able to > >>>> pick > >>>>> which of the acceptable relays will be used for a particular data > >>>>> flow based on my requirements for that session. On the other hand, > >>>>> I also think that the relay service provider should be able to > >>>>> limit access in cases where the relay service has a relationship > >>>>> with the application provider and not with me. The protocol > >>>>> doesn't allow this differentiation today, but I don't think that > >>>>> means that it must not allow this in the future. > >>> Fully agreed. Classical STUN auth, with or without ORIGIN, does not > >>> allow this limitation. Third-party-auth does (or I think it does, > >>> not quite sure anymore). > >>> > >> > >> Even with third-party-auth and/or a creative use of short-term > >> credentials, I think that all we can get today is an assurance that I > >> must be a user of an authorized service in order to get an allocation. > >> Once I have an allocation, there's no way via STUN/TURN for the relay > >> service to know whether a specific ChannelBind/Permission is also > >> approved by the application service. I can use my established > >> allocation for any data flow I want unless the relay service and the > >> application service build an OOB method for validation. > > > > Yes, we are exploring that option to prevent misuse, it helps the Enter= prise > TURN server use-cases where FW is configured to only permit UDP traffic t= o > well-known TURN servers. Enterprise TURN server is configured to support > both first party authentication and third party authorization to differen= tiate > b/w calls. Token introspection work done in OAuth 2.0 > https://tools.ietf.org/html/draft-ietf-oauth-introspection-08 can be leve= raged > for this purpose. > > > >> > >> I think it would be fairly easy to build peer address signing into > >> the protocol such that it would be possible to enforce such a limitati= on. > >> I'll be curious to hear whether anyone else would be interested in thi= s. > > > > -Tiru > > > >> > >> --Brandon > >> > >> -- > >> Brandon Williams; Chief Architect > >> Cloud Networking; Akamai Technologies Inc. > >> > >> _______________________________________________ > >> tram mailing list > >> tram@ietf.org > >> https://www.ietf.org/mailman/listinfo/tram >=20 > -- > Brandon Williams; Chief Architect > Cloud Networking; Akamai Technologies Inc. From nobody Mon May 18 00:45:15 2015 Return-Path: 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 E09DC1A876D for ; Mon, 18 May 2015 00:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 FI6TZn6LGeeD for ; Mon, 18 May 2015 00:45:12 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860691A876A for ; Mon, 18 May 2015 00:45:12 -0700 (PDT) Received: by iesa3 with SMTP id a3so76779002ies.2 for ; Mon, 18 May 2015 00:45:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:subject:mime-version :content-type; bh=kR6uMBRnR3ecq3Gw2FOVj9BVqsgZ+/daAbWhRDpT1X0=; b=gDIRg1FNyRRhdmcVTZbZMGTRD+4IiCYRVHcraZEX2JMcxt90X4RXbTE0O+2xBrlcym nxWNs1EvwajH1oj9mq2v/xsjM1sNVU3+mkCy9NkxWDkQCBGeEmV9J1V3+w3xZ+Urswbs xCvKRG1kjSTWjSBUUFui6Jan1aSV9oS5bYCrvU3n9OvLLACYz3RU5V3oJlBfdG6yhjKe HF5Zt/4W595xVhpgxiPUJvfvCKuZd3ytgeSDl67WtSVXkOcfxKOujhVrVZIt8RiNwzAE d56LgQnKa4zB7ahZd7lSTpxxQOow2ZjAVle5hsT4p6Gco720mQTkcs47Vzm0+ic9P9iw Xavw== X-Gm-Message-State: ALoCoQlRvUmbLes7eAttxHPzVKvQU4JdItM33qc+UX0wl2anQ9oedqs8eacTzTp1ZBj1HBc+ugwE X-Received: by 10.50.93.69 with SMTP id cs5mr12940210igb.4.1431935111861; Mon, 18 May 2015 00:45:11 -0700 (PDT) Received: from edios.local (c-71-195-233-26.hsd1.ut.comcast.net. [71.195.233.26]) by mx.google.com with ESMTPSA id qt1sm5095397igb.5.2015.05.18.00.45.09 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 May 2015 00:45:10 -0700 (PDT) Date: Mon, 18 May 2015 01:45:11 -0600 From: Eduardo Gueiros To: tram@ietf.org Message-ID: X-Mailer: Airmail (249) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55599887_46e87ccd_3a1" Archived-At: Cc: praspati@cisco.com, dwing@cisco.com, tireddy@cisco.com Subject: [tram] Review draft-ietf-tram-turn-server-discovery-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 07:45:15 -0000 --55599887_46e87ccd_3a1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Authors, I have read draft-ietf-tram-turn-server-discovery-02 and the fol= lowing small review.=C2=A0 Overall I am impressed with the quality of the document. It has been easy= to read, it has good references and I really like the proposed solutions= and how they are individually addressed. Well done addressing security c= oncerns. It is very well written and I this time I=E2=80=99d like just to point so= me writing nits and suggestions.=C2=A0 Thanks,=C2=A0 Eduardo eduardo at jive.com =E2=80=94 Introduction Paragraph 1 General comment: Paragraph too large. Consider breaking down in two or th= ree paragraphs. Introduction Paragraph 2 >=C2=A0based on the network in the which the TURN client finds=C2=A0itsel= f. - Remove extra=C2=A0=E2=80=9Cthe=E2=80=9D to read: based on the network in which the TURN client finds=C2=A0itself. - Suggestion: Add text before bullets: The three discovery mechanisms are: Section 3, bullet =231 >1. Local Configuration : Local or manual configuration should be > tried first, as it may be an explicit preferred choice of a user.= Suggestion: 1. Local Configuration : If local or manual configuration exists, they s= hould be tried first, as it may be an explicit preferred choice of a user. Section 3, bullet =232 >Service Resolution : Service Resolution : The TURN client > attempts to perform TURN service resolution using the host's DNS > domain. - Remove duplicate =22Service Resolution=22:=C2=A0 Service Resolution: The TURN client attempts to perform TURN service resolution using the host's DNS domain. Section 3, paragraph 4 >A client MAY optionaly > choose to perform the discovery procedure only for a desired > interface/address combination, if the client does not wish to > discover a TURN server for all combinations of interface and address > family. - The comma made this sentence not very clear when I=C2=A0first read it. = In my opinion removing the=C2=A0common=C2=A0makes=C2=A0the sentence clear= er.=C2=A0 A client MAY optionaly choose to perform the discovery procedure only for a desired interface/address combination if the client does not wish to discover a TURN server for all combinations of interface and address family. --55599887_46e87ccd_3a1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline