From nobody Wed Mar 2 16:04:32 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B3E1B35BB for ; Wed, 2 Mar 2016 16:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.23 X-Spam-Level: X-Spam-Status: No, score=0.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, 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 rR804E7JLujV for ; Wed, 2 Mar 2016 16:04:30 -0800 (PST) Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96A11B35B5 for ; Wed, 2 Mar 2016 16:04:29 -0800 (PST) X-AuditID: 60721c4c-f79106d000001de0-48-56d77f8cf5c0 Received: from VAADCEX38.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 11.73.07648.C8F77D65; Wed, 2 Mar 2016 19:04:28 -0500 (EST) Received: from VAADCEX39.cable.comcast.com (147.191.103.216) by VAADCEX38.cable.comcast.com (147.191.103.215) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 2 Mar 2016 19:04:27 -0500 Received: from VAADCEX39.cable.comcast.com ([fe80::3aea:a7ff:fe12:37f4]) by VAADCEX39.cable.comcast.com ([fe80::3aea:a7ff:fe12:37f4%19]) with mapi id 15.00.1130.005; Wed, 2 Mar 2016 19:04:27 -0500 From: "Livingood, Jason" To: Warren Kumari , Mark Nottingham , "captive-portals@ietf.org" , Steven Bauer Thread-Topic: [Captive-portals] CAPPORT meeting at IETF95 in Buenos Aires. Thread-Index: AQHRaBjgltaD1aljGkaCtYr49+EF6J9G8EsA Date: Thu, 3 Mar 2016 00:04:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.11] Content-Type: multipart/alternative; boundary="_000_D2FCDC7212A67Fjasonlivingoodcablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsWSUOxpodtTfz3M4F2zqsXsFXMYLebOamC1 WP/pMaPF4WOXmRxYPJYs+cnkcfvGH3aPpjNHmT02Lv7OGsASxWWTkpqTWZZapG+XwJXxYq5Y wTzligNrpjM2MJ6S7WLk5JAQMJFo3bCEGcIWk7hwbz1bFyMXh5DAFiaJo717GCGcg4wSE34c Y4FwTjBKvH7UxwrSwiZgJnF34RVmkISIwHxGieXv7oDNEhbwlNi89REjiC0i4CWxbXUzE4Rt JHFi4iKwOIuAisSSUzPA6nkF7CXWXv3NAmILCQRIzNhwFqyGUyBQonXnR7A4I9B930+tAZvD LCAucevJfCaIuwUkluw5D/WDqMTLx//AjhMV0JM4+GklK0RcR+Ls9SeMELaBxNal+4BmcgDZ 8hIf50KNTJb4eKiRCeIcQYmTM5+wQJSLSxw+soN1AqPkLCSbZyFpmYWkBSKuJ3Fj6hQ2CFtb YtnC18wQtq7EjH+HoGocJJp7T6KoWcDIsYpRriwxMSU5NyO/tMTASC85MSknVS85Pzc5sbgE RG9iBKWIIhmfHYyfpnkcYhTgYFTi4c2qvh4mxJpYVlyZe4hRgoNZSYRXoRYoxJuSWFmVWpQf X1Sak1p8iFGag0VJnJf1zNUwIYH0xJLU7NTUgtQimCwTB6dUA2NY5KNbluvvm4h2Ttimutbc z3itR8MnBZlzzltvaD5ZLXhFwnq+6DWXHeXz8qWqbM5K6My9V5mxJVrhtfwvkwVC017Uqnnz rPz5ZeUOsaMnk2UfFfjP/twoxbTrtFVq8YGyRyZBGhNF3qjWyf6dvuLFpmPbNq3+tfdkyqeV bofa3rctzlsde+KjEktxRqKhFnNRcSIAOTsmaw0DAAA= Archived-At: Subject: Re: [Captive-portals] CAPPORT meeting at IETF95 in Buenos Aires. X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 00:04:31 -0000 --_000_D2FCDC7212A67Fjasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 2/15/16, 12:46 PM, "Captive-portals on behalf of Warren Kumari" on behal= f of warren@kumari.net> wrote: We are in the process of organizing the agenda - one of the things which we= heard from you at the BoFs is that you would like something like a "survey= of the industry" (e.g motivation for deploying a CP) and a more complete u= nderstanding of why captive portal operators do things like defeating / whi= telisting the captive portal probes. Speaking as an operator there is a wide range of ways we use captive portal= like tools. I'm happy to try to organize a presentation if that is helpful= . Our definition of "captive portal" may be a bit broader than folks on thi= s list may think, so it may be interesting. So, if you develop and / or operate a CP, we'd really like to hear from you= - we give priority agenda time to drafts which have had online discussion,= but may be willing to also have more of a discussion type presentation. One person who may have interesting thoughts to contribute is Steve Bauer f= rom MIT, copied here. He has a novel idea for the need to have a portal-lik= e communication channel to end users that he's called "net.info" as a worki= ng title. I wonder if that might have some applicability here. - Jason --_000_D2FCDC7212A67Fjasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <890D2C056355BE4C968D3CD9ABCC6020@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
On 2/15/16, 12:46 PM, "Captive-portals on behalf of Warren Kumari= " <captive-port= als-bounces@ietf.org on behalf of warren@kumari.net> wrote:

We are in the process of organizing the= agenda - one of the things which we heard from you at the BoFs is that you= would like something like a "survey of the industry" (e.g motiva= tion for deploying a CP) and a more complete understanding of why captive portal operators do things like defeating / w= hitelisting the captive portal probes.

Speaking as an operator there is a wide range of ways we use captive p= ortal like tools. I’m happy to try to organize a presentation if that= is helpful. Our definition of “captive portal” may be a bit br= oader than folks on this list may think, so it may be interesting.

So, if you develop and / or operate a C= P, we'd really like to hear from you - we give priority agenda time to draf= ts which have had online discussion, but may be willing to also have more o= f a discussion type presentation.

One person who may have interesting thoughts to contribute is Steve Ba= uer from MIT, copied here. He has a novel idea for the need to have a porta= l-like communication channel to end users that he’s called “net= .info” as a working title. I wonder if that might have some applicability here.

- Jason


--_000_D2FCDC7212A67Fjasonlivingoodcablecomcastcom_-- From nobody Wed Mar 2 16:16:31 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2A11B365A for ; Wed, 2 Mar 2016 16:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.229 X-Spam-Level: X-Spam-Status: No, score=0.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.006, 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 5ExJoIGvkXVp for ; Wed, 2 Mar 2016 16:16:29 -0800 (PST) Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038721B3659 for ; Wed, 2 Mar 2016 16:16:28 -0800 (PST) X-AuditID: 60721c4c-f79106d000001de0-2e-56d7825b3eb1 Received: from VAADCEX40.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 91.93.07648.B5287D65; Wed, 2 Mar 2016 19:16:28 -0500 (EST) Received: from VAADCEX39.cable.comcast.com (147.191.103.216) by VAADCEX40.cable.comcast.com (147.191.103.217) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 2 Mar 2016 19:16:27 -0500 Received: from VAADCEX39.cable.comcast.com ([fe80::3aea:a7ff:fe12:37f4]) by VAADCEX39.cable.comcast.com ([fe80::3aea:a7ff:fe12:37f4%19]) with mapi id 15.00.1130.005; Wed, 2 Mar 2016 19:16:27 -0500 From: "Livingood, Jason" To: "captive-portals@ietf.org" , Mark Nottingham Thread-Topic: Comments on draft-nottingham-capport-problem-00 Thread-Index: AQHRdOHt/hRKzm1WEUW2YeZh8fMn5w== Date: Thu, 3 Mar 2016 00:16:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.9] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsWSUOxpoRvTdD3M4NoBJou5sxpYLdZ/eszo wOSxZMlPJo+Ni7+zBjBFcdmkpOZklqUW6dslcGUs/3idreAvW8WLdXsYGxgfsXYxcnJICJhI rLm1iw3CFpO4cG89mC0ksIVJYtu09C5GLiD7IKNEU1MjM4RzglFi9YHl7CBVbAJmEncXXmEG sUUEYiQaW4+xgNjCAhYSvx5NZoOI20p8m/GasYuRA8jWk7i1OAokzCKgIrHk9Uewcl4Be4ln j7uZQGxGoCO+n1oDZjMLiEvcejKfCeI4AYkle84zQ9iiEi8f/wN7QBRo5MFPK6Ge0ZE4e/0J I4RtILF16T4WCFtOYtnPO8wQM/UkbkydwgZhO0gs2DSFFcLWlli28DUzxD2CEidnPoHqlZQ4 uOIGywRGyVlITpqFZNQsJKNmIRk1C8moBYysqxjlyhITU5JzM/JLSwyM9JITk3JS9ZLzc5MT i0tA9CZGUMQWyfjsYPw0zeMQowAHoxIPb1b19TAh1sSy4srcQ4wSHMxKIrwKtUAh3pTEyqrU ovz4otKc1OJDjNIcLErivKxnroYJCaQnlqRmp6YWpBbBZJk4OKUaGOeLRip6hV2UuFSyIHvV wrDrJx0Kvsnue/Csd5PmccdZtscfLf3MW8Oa9lNUp5Trzk4Wrfvpf6zFfhmuU/s5kaXzptSl mxMe3FKbWe6+KMVi4iuxldWNCh8PX5wf1LP6XOVJ/5PKmTfcn5Zt27zeY9GhWMfXv3g1LeUr F/+V33Vd3nPzFvNDEU+VWIozEg21mIuKEwF2Bc+H1AIAAA== Archived-At: Subject: [Captive-portals] Comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 00:16:30 -0000 Good document overall. Some comments/suggestions to consider for a =AD01 update.=20 2.0, consider extending (IN CAPS): =B3...before allowing broader (but not necessarily complete) Internet access, OR FOR OTHER PURPOSES.=B2 2.0, consider adding techniques to include HTML injection, Internet Content Adaptation Protocol (RFC 3507), and the method described in RFC 6108. 2.1, Information or Notifications, some possible additional examples: security alerts, critical service information, account status, usage status 3.0, consider adding: HTML injection, such as methods using ICAP, which runs counter to the preferences of some users. 3.0, Feel free to take a look at the text in Section 12 of RFC 6108 and use some of that text. You got the gist of it in the Non-Browser Clients sub-section though (https://tools.ietf.org/html/rfc6108#section-12) Regards Jason From nobody Wed Mar 2 16:24:44 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469051B3699 for ; Wed, 2 Mar 2016 16:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 XI-nZN-3qRwd for ; Wed, 2 Mar 2016 16:24:42 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 D94311B369B for ; Wed, 2 Mar 2016 16:24:41 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id l127so10497481iof.3 for ; Wed, 02 Mar 2016 16:24:41 -0800 (PST) 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; bh=J11N0u7hJNyO0GV4Wu48M4nTdKO52rZPiENzKotR0ho=; b=XlLjVGBLMplHbivPBFyWrYRS0a1VcCGw8Dr7PrRhiHYt1IarvC3huWd42qYY7Q1q8X 9XcHHXlkrXXGud8o6Xb6BOmJN6+uzupcYyZX/FGn/WMBDr1FMeAxlrPWLQNp94WJ2b38 XAVjcYxuWCu8Oh9GZl6Xo4AavnjmfhGGj78AsWGd3D1DA22aIlIQkXt1EMYk+GcXGl6w TbZ6ditvkjs8jAwJIfNexehn5DQQfLYvqRvhktStkLz3h+YgnFWCvBK81TRdrkf88Mqx C5ai8kyS5ay6P72wxWBFZ3t2NC2eI+Xq+bW+OPH8N+7VTggsgdS9se75Bss+CuThyyrG 0jmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=J11N0u7hJNyO0GV4Wu48M4nTdKO52rZPiENzKotR0ho=; b=UWtBdWI9YotL9dqgQWSLUvCc17ooXG/20v9WaWLP1e+qkn35Um3RfT5pY2a8RX8S3n 0YIpgIESwaeVSmByAI/MDX2usn2iHwiOkmp+mbAE+uYja5F9wonp+Z1I0asCVp3uygmk c5e0qGHEK3L+R4scZRLbQI9cXx//g0qLEv1BQUTjy+UmH3O2VRIYphpHwC2yKC/tTzlO v2iAUTTFSc+YZXF0MZkhneyMBl6EZv+ATho2Fi6aB8Df/Fj0l4dF/zl00HGrgBGhDWRu azozYeH39MOxIn11v2wjOf3FK0p5uzo13uKVtc+K94Uu0YVP8TbAZiSpFSQ/4qk5mu6G aQEA== X-Gm-Message-State: AD7BkJLfdm5jrtTE/+p3t2wdxpYCof4PtyGPFn9vFlhzEM3Tu1MZXudzbf+bpWuayodstcz081Z6mMXuU7LRag== MIME-Version: 1.0 X-Received: by 10.107.131.27 with SMTP id f27mr202409iod.190.1456964681306; Wed, 02 Mar 2016 16:24:41 -0800 (PST) Received: by 10.36.43.5 with HTTP; Wed, 2 Mar 2016 16:24:41 -0800 (PST) In-Reply-To: References: Date: Thu, 3 Mar 2016 11:24:41 +1100 Message-ID: From: Martin Thomson To: "Livingood, Jason" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mark Nottingham , "captive-portals@ietf.org" Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 00:24:43 -0000 On 3 March 2016 at 11:16, Livingood, Jason wrote: > 3.0, Feel free to take a look at the text in Section 12 of RFC 6108 and > use some of that text. You got the gist of it in the Non-Browser Clients > sub-section though (https://tools.ietf.org/html/rfc6108#section-12) This raises an interesting point about internet dot org by facebook. I wonder if there are any lessons to be learned from that as well. From nobody Wed Mar 2 18:02:26 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D6D1B38A0 for ; Wed, 2 Mar 2016 18:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 n8WVxiIfqpKx for ; Wed, 2 Mar 2016 18:02:22 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6BC1B389A for ; Wed, 2 Mar 2016 18:02:21 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 910F822E261; Wed, 2 Mar 2016 21:02:14 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Mark Nottingham In-Reply-To: Date: Thu, 3 Mar 2016 13:02:11 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Livingood, Jason" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "captive-portals@ietf.org" Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 02:02:24 -0000 Hi Jason,=20 Thanks for that, I've made some edits; see: https://github.com/mnot/I-D/commit/950dcd04dfbb Regarding notifications, I think we should discuss whether it's useful = to consider them as 'captive portals' or not. The techniques are similar = in many cases, but there are some important differences. Cheers, > On 3 Mar 2016, at 11:16 AM, Livingood, Jason = wrote: >=20 > Good document overall. Some comments/suggestions to consider for a =AD01= > update.=20 >=20 > 2.0, consider extending (IN CAPS): > =B3...before allowing broader (but not necessarily complete) Internet > access, OR FOR OTHER PURPOSES.=B2 >=20 > 2.0, consider adding techniques to include HTML injection, Internet > Content Adaptation Protocol (RFC 3507), and the method described in = RFC > 6108. >=20 > 2.1, Information or Notifications, some possible additional examples: > security alerts, critical service information, account status, usage = status >=20 > 3.0, consider adding: > HTML injection, such as methods using ICAP, which runs counter to the > preferences of some users. >=20 > 3.0, Feel free to take a look at the text in Section 12 of RFC 6108 = and > use some of that text. You got the gist of it in the Non-Browser = Clients > sub-section though (https://tools.ietf.org/html/rfc6108#section-12) >=20 > Regards > Jason >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Mar 2 22:37:40 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168441B3EF2 for ; Wed, 2 Mar 2016 22:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 PcjbaZlLS2oY for ; Wed, 2 Mar 2016 22:37:36 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 C6BFB1B3EF4 for ; Wed, 2 Mar 2016 22:37:36 -0800 (PST) Received: by mail-ig0-x22c.google.com with SMTP id hb3so58199575igb.0 for ; Wed, 02 Mar 2016 22:37:36 -0800 (PST) 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; bh=V2GRlLy3FDK0nkr6lsAEvfe0CsL05VJpKSfeMhIClVI=; b=lZglXBRPSNulee5DuuPIF6yeR1x6b7oC0EQip5V3kCFdzS8iLcjrpykeMHRcG+Yjfw oSzlf560C4azdZ4f3U+Y14YANSrvAk0eW4+KR+BWlwmPdb/vqB0ZYedP3QW3qbGGZmeK Jw4CBHlOYaEFO5ZMnApRxBAXCzZuRh+yePMpHFPY/mJyoeBVnsyCTJjBnFNXtD5RQI4E OFO73TPGvYn9ZtbNgEmO7EaORybSHjuJuY7j2kEO8G9Wg+lRJc9XI7CT6RKYPVY0lyVN nrlr3z5Xp7+PmADhvoVBsQvwolHI/RsppKNt/porQ6q8kFD8yUCbFqLf+jl+BBeEbhVb AQqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=V2GRlLy3FDK0nkr6lsAEvfe0CsL05VJpKSfeMhIClVI=; b=C60xa6yRWAnHETjnMocAlEolCo20IsgFlyZ/WO7uHO1gdyAbTETX1M+aisRPL4Vwo3 I/WYtFfQVUNTbWbzdBcz40yOENxmz7D6qlT1SXQ6RwoCii3jOBuoF6R/JbG4D23M9Hlx zk6nRU/DPyLAnBP0EbJqZyh/UG5ot+lJxTQCC5HUPoqRLmaKJOLsr0JrHKMyUbi3hn9D 0Z095/tGVetZW3GzxkZXLmNtcWL6qx75yPirz1HScbTxjt+UuRyJCx3NPA7Co8X7UVOw r+PvzsrZgi1Vwg3KT3qRntVQeOkvS1f+8P8KhQj8uHuhRN75eM5DC+UpNUpl33lFEvzj Okug== X-Gm-Message-State: AD7BkJJK9OBHDBpwFelWKQe9RHnsuaV+/P5PNdsydqumrqQ+tFHV5l/WKrocqBDA4yyEfWIslIWj7J8/mSLZeQ== MIME-Version: 1.0 X-Received: by 10.50.60.34 with SMTP id e2mr1441975igr.77.1456987056227; Wed, 02 Mar 2016 22:37:36 -0800 (PST) Received: by 10.36.43.5 with HTTP; Wed, 2 Mar 2016 22:37:36 -0800 (PST) In-Reply-To: References: Date: Thu, 3 Mar 2016 17:37:36 +1100 Message-ID: From: Martin Thomson To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Livingood, Jason" , "captive-portals@ietf.org" Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 06:37:38 -0000 On 3 March 2016 at 13:02, Mark Nottingham wrote: > Regarding notifications, I think we should discuss whether it's useful to consider them as 'captive portals' or not. The techniques are similar in many cases, but there are some important differences. I caution that this might be a case where we have to watch scope. It might be good to understand the methods and reasons, but those differences could lead us down a rathole. From nobody Wed Mar 2 22:38:28 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950711B3EF4 for ; Wed, 2 Mar 2016 22:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 i08PLYlYxgEN for ; Wed, 2 Mar 2016 22:38:24 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914A41A1A28 for ; Wed, 2 Mar 2016 22:38:24 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E6B9622E262; Thu, 3 Mar 2016 01:38:16 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Mark Nottingham In-Reply-To: Date: Thu, 3 Mar 2016 17:38:14 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "Livingood, Jason" , "captive-portals@ietf.org" Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 06:38:26 -0000 > On 3 Mar 2016, at 5:37 PM, Martin Thomson = wrote: >=20 > On 3 March 2016 at 13:02, Mark Nottingham wrote: >> Regarding notifications, I think we should discuss whether it's = useful to consider them as 'captive portals' or not. The techniques are = similar in many cases, but there are some important differences. >=20 > I caution that this might be a case where we have to watch scope. It > might be good to understand the methods and reasons, but those > differences could lead us down a rathole. +1 -- Mark Nottingham https://www.mnot.net/ From nobody Thu Mar 3 05:24:40 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BBF1ACD42 for ; Thu, 3 Mar 2016 05:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.229 X-Spam-Level: X-Spam-Status: No, score=0.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.006, 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 EEjWIq5oIbeI for ; Thu, 3 Mar 2016 05:24:38 -0800 (PST) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D7B1ACD41 for ; Thu, 3 Mar 2016 05:24:37 -0800 (PST) X-AuditID: 60721c4b-f79016d000007994-ff-56d83b148b83 Received: from VAADCEX35.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 2E.C6.31124.41B38D65; Thu, 3 Mar 2016 08:24:36 -0500 (EST) Received: from VAADCEX39.cable.comcast.com (147.191.103.216) by VAADCEX35.cable.comcast.com (147.191.103.212) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 3 Mar 2016 08:24:35 -0500 Received: from VAADCEX39.cable.comcast.com ([fe80::3aea:a7ff:fe12:37f4]) by VAADCEX39.cable.comcast.com ([fe80::3aea:a7ff:fe12:37f4%19]) with mapi id 15.00.1130.005; Thu, 3 Mar 2016 08:24:35 -0500 From: "Livingood, Jason" To: Martin Thomson , Mark Nottingham Thread-Topic: [Captive-portals] Comments on draft-nottingham-capport-problem-00 Thread-Index: AQHRdOHdJIQshoH8vkKD1VG28lgEHJ9HS3OAgABM8wCAAB3hAA== Date: Thu, 3 Mar 2016 13:24:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsWSUOxpoStifSPM4MlaGYu5sxpYLa6d+cdo sf7TY0YHZo+ds+6yeyxZ8pPJY+Pi76wBzFFcNimpOZllqUX6dglcGb975QvWslesbDBoYPzB 2sXIySEhYCLx6fkldghbTOLCvfVsXYxcHEICW5gkGn53s0I4BxklXm+fAuWcYJR4v3AzC0gL m4CZxN2FV5hBbBEBP4kZDcfA4swClhI7X65nArGFgeLbj7dB1QRKvLuzAcp2kri8AOIMFgEV iY1H+sDqeQXsJTbO28EMsWwHo8Tjr/1gQzmBmt98PA3WzAh06/dTa5gglolL3HoynwniBwGJ JXvOM0PYohIvH/8DWyAqoCdx8NNKqJ91JM5ef8IIYRtIbF26jwXClpc4MuEf1AMGEu/PzWeG sB0kGs6uZoSwtSWWLXzNDHGooMTJmU+geiUlDq64wTKBUWYWkpNmIRk1C8moWUhGzUIyagEj 6ypGubLExJTk3Iz80hIDQ73kxKScVL3k/NzkxOISEL2JEZQOimS8dzCu++l+iFGAg1GJh3et xo0wIdbEsuLK3EOMEhzMSiK87xSBQrwpiZVVqUX58UWlOanFhxilOViUxHnZz1wNExJITyxJ zU5NLUgtgskycXBKNTAGNxq53dbjrtEWmOd9e3LVzAzNVauYv236t1XPfdrtiKRWa48r6rfL tVeas4Syv138/eDrA0m+U8U4dxjsYbsRX84SaWt6g8X/h01yLlOU3R7vg+9rT8YkWYesS+I2 b317ySaSR/L1vKLPeyRetLeoaRmkl207zmtX8l1TJDF1/plduQ2zJimxFGckGmoxFxUnAgDX 6f+YAwMAAA== Archived-At: Cc: "captive-portals@ietf.org" Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 13:24:39 -0000 >On 3 March 2016 at 13:02, Mark Nottingham wrote: >> Regarding notifications, I think we should discuss whether it's useful >>to consider them as 'captive portals' or not. The techniques are similar >>in many cases, but there are some important differences. > >I caution that this might be a case where we have to watch scope. It >might be good to understand the methods and reasons, but those >differences could lead us down a rathole. Fair concern. But we may not want the WG to be overly exclusive at this early stage as to future implementations. I say that especially since at least this operator would love to find better and more standardized methods to do notifications using output from this WG that may fall into a grey area between a captive portal and semi-captive portal (or however we choose to label it) - it addition to improving =8Cclassic=B9 captive portal= s as defined here. Jason From nobody Fri Mar 4 02:29:38 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9501B3621 for ; Fri, 4 Mar 2016 02:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.007 X-Spam-Level: X-Spam-Status: No, score=-0.007 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.006] 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 I4nXGmEa70u5 for ; Fri, 4 Mar 2016 02:29:33 -0800 (PST) Received: from mx1.asteas.com (mx1.asteas.com [83.218.160.135]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5151B3628 for ; Fri, 4 Mar 2016 02:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at frozentux.org Received: from EXCHANGE.mbox.local (EXCHANGE.mbox.local [192.168.101.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.asteas.com (on Asteas-Business-Server) with ESMTPS id A6E6B1860239 for ; Fri, 4 Mar 2016 11:29:27 +0100 (CET) From: Lukas RUETZ To: "captive-portals@ietf.org" Thread-Topic: Thoughts/comments on draft-nottingham-capport-problem-00 Thread-Index: AdF1/WQqxigydv5zQoWQHYB2MGlz2w== Date: Fri, 4 Mar 2016 10:29:25 +0000 Message-ID: <04FC2BF6CA29744989A8227EB45685C6019D1162@EXCHANGE.mbox.local> Accept-Language: de-AT, en-US Content-Language: de-AT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.3.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 10:29:37 -0000 Hi everyone,=0A= =0A= we found some time now to think about the current draft. Please find some m= inor additions=0A= and some discussion below:=0A= =0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=0A= =0A= 2. Defining Captive Portals=0A= This is achieved by directing requests for "normal" Web access to the=0A= nominated server, through variety of techniques, including DNS=0A= poisoning, TCP interception, and/or HTTP redirection.=0A= =0A= You could add "ARP spoofing" here too.=0A= =0A= ---------------------------------------------------------------------------= ---=0A= =0A= 2.1. Why Captive Portals Are Used=0A= =0A= This may be added as separate point to the list:=0A= =0A= *Collect user data* - Some CP operators want to collect user data in exchan= ge=0A= for free internet (email addresses, time/location information, ...).=0A= =0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=0A= =0A= 3. Issues Caused by Captive Portals=0A= =0A= o *Confusion* - Because captive portals are effectively a man-in-=0A= the-middle attack, they can confuse users as well as user agents=0A= (e.g., caches). For example, when the portal's TLS certificate=0A= doesn't match that of the requested site, or the captive portal's=0A= /favicon.ico gets used as that of the originally requested site.=0A= =0A= I would not call it man-in-the-middle "attack" - it's more a MITM "constell= ation".=0A= The sent and expected certificate are different, but not forged. If the CP= =0A= would send a fake certificate for example.com that would be a real MITM att= ack.=0A= Maybe there are other CPs out there which are doing that. I'm only aware of= big=0A= firewalls that are able to break up TLS, but of course they have their CA i= nstalled=0A= on the clients and (hopefully) their employees informed.=0A= =0A= ---------------------------------------------------------------------------= ---=0A= =0A= o *TLS* - Portals that attempt to intercept TLS sessions (HTTPS,=0A= IMAPS, or other) can cause certificate error messages on clients,=0A= encouraging bad practice to click through such errors.=0A= =0A= You may consider adding something like:=0A= This bad practice is now avoided by many web sites that are sending an HSTS= HTTP header,=0A= in which case the user can't add an exception for that certifcate if the br= owser was on=0A= the wanted page before. Same for HPKP headers. The user is stuck until s/he= opens an=0A= http:// URL.=0A= =0A= ---------------------------------------------------------------------------= ---=0A= =0A= o *Non-Browser Clients* - It is becoming more common for Internet=0A= devices without the ability to run a browser to be used, thanks to=0A= the "Internet of Things." These devices cannot easily use most=0A= networks that interpose a captive portal.=0A= =0A= To get such devices online they are often whitelisted on the CP with their = MAC address=0A= what opens up an uncontrolled hole in the CP.=0A= =0A= (Examples usages: different kind of internet radio players, printers, netwo= rk-devices=0A= (due to bad network design))=0A= =0A= ---------------------------------------------------------------------------= ---=0A= =0A= o *Connectivity Interruption* - For a device with multiple network=0A= interfaces (e.g., cellular and WiFi), connecting to a network can=0A= require dropping access to alternative network interfaces. If=0A= such a device connects to a network with a captive portal, it=0A= loses network connectivity until the captive portal requirements=0A= are satisfied.=0A= =0A= (We see an even more complicated version of it - devices with multiple inte= rfaces=0A= sometimes switch back from WiFi to 3G/4G because the "online check" of the = device reports=0A= that the device is offline. This leads to the problem that users with data = plans at the=0A= location of the CP (like a hotel in the same country) have problems to get = to the login=0A= page of the CP or have to try a few times.)=0A= =0A= ---------------------------------------------------------------------------= ---=0A= =0A= You may consider to add another point to 3. - because it's not specific to = CPs I'm not sure if=0A= you want to add that:=0A= =0A= *NAT* - (Network Address Translation) Because most of the CPs are masqu= erading the=0A= client traffic, they also inherit all kind of problems known to NAT. Mo= st notably=0A= VPNs that can't be masqueraded like some IPSec based VPNs.=0A= =0A= Another point would be:=0A= *Problematic client settings* - Some devices and/or software make certa= in assumptions=0A= or have settings that work in an unrestricted network but are actually = bad/questionable practice=0A= and fail behind CPs. For example some clients with fixed proxy settings= have problems=0A= to establish connections. Intranet applications doing unknown tests to = find out if they=0A= are on the intranet. Mobile apps that flood the CP as soon as the WiFi = interface is up,=0A= not waiting after a connection reset.=0A= =0A= (We have a long list of examples - not sure how concrete/general the statem= ent should be)=0A= =0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=0A= =0A= 5. Security Considerations=0A= =0A= The current situation for our customers looks usually like this. The client= s are=0A= connecting via unencrypted WiFi to the CP.=0A= =0A= * WPA(2) with a pre-shared key is almost never used because=0A= - it does not add real security if everyone who asks gets the pre-share= d key=0A= - especially CP operators (I'm talking about hotels here) don't want th= e guest to ask anything - it should just work=0A= - it's another step that many users would not be able to deal with=0A= =0A= * Although 802.1x would be possible too (different credentials per user, on= e login) it's not very widespread because=0A= - most CP operators (often without inhouse IT staff) find it too comple= x to setup/operate=0A= - it's incompatible with many access methods like a login via social pl= atforms=0A= =0A= Many CP operators are moving from username+password to password only, becau= se the error-rate=0A= of mistyped credentials on mobile devices is quite high. So nobody wants to= add another password (for WiFi).=0A= =0A= Security considerations for the client using a CP:=0A= One could argue that the client is always in a risky situation when connect= ing via a CP. But the risk is actually not=0A= different than by connecting over any other network device like routers or = firewalls.=0A= =0A= We think regarding security the most important point is not to mess with TL= S connections. If we can get=0A= rid of this redirect-to-login situation this would increase the security of= end-users a lot because they don't=0A= "lear" to click through certificate warnings. RFC-7710 would be a first imp= ortant step.=0A= =0A= Looking forward to your comments,=0A= Lukas=0A= =0A= =0A= --=0A= Lukas RUETZ=0A= www.iacbox.com=0A= =0A= From nobody Fri Mar 4 06:33:27 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D1E1A038C for ; Fri, 4 Mar 2016 06:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.299 X-Spam-Level: * X-Spam-Status: No, score=1.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_37=0.6, RP_MATCHES_RCVD=-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 onw2S95Ohscs for ; Fri, 4 Mar 2016 06:33:21 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE6F1A047A for ; Fri, 4 Mar 2016 06:33:21 -0800 (PST) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-03v.sys.comcast.net with comcast id RqZL1s0014s37d401qZLTs; Fri, 04 Mar 2016 14:33:20 +0000 Received: from odin.ULTHAR.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by resomta-po-01v.sys.comcast.net with comcast id RqZ91s0062Ekl4801qZD1W; Fri, 04 Mar 2016 14:33:18 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ULTHAR.us (8.15.2/8.14.5) with ESMTP id u24EX7Ct017862 for ; Fri, 4 Mar 2016 09:33:07 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.15.2/8.15.2/Submit) id u24EX71v017861 for captive-portals@ietf.org; Fri, 4 Mar 2016 09:33:07 -0500 Date: Fri, 4 Mar 2016 09:33:07 -0500 From: Scott Schmit To: captive-portals@ietf.org Message-ID: <20160304143307.GA17578@odin.ulthar.us> References: <04FC2BF6CA29744989A8227EB45685C6019D1162@EXCHANGE.mbox.local> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <04FC2BF6CA29744989A8227EB45685C6019D1162@EXCHANGE.mbox.local> User-Agent: Mutt/1.5.24 (2015-08-30) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457102000; bh=6PkcgXB+Ync1Gs+1CbLrQQZkDtLy2BNUKG3wl2zZMEw=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=iGW3lDxqYogKojHNhVhPs4gSanHK4hfE66OLDQQPPeChh71XLdF3D/pl1bPJ1Cmm1 0g8lneUtVPmRmEkGAAUEnagvffF91xfb9Iu13JgqqFvjMGyp16ApM86iFkuZ3NZqwX FfPw5Neq9F+eO3SSaACTHe+05YYEBHUxoeRi0hO6NFwrv5xGHwFvayToGFKuduHIbx 9rs+ZeghakT1sIs6oIrphl0b3R5NutR7XrF2wlr3U4nQkKmDRElHGFBEfvQDiiYMhi +QxKDDrKQTP9LdJGlJ0O2ja4N2AwknXx8ujnsO9GBCPeFTgVy0tr3KZkeeh+nTbEtF OFlbB3uJksy/A== Archived-At: Subject: Re: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 14:33:24 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 04, 2016 at 10:29:25AM +0000, Lukas RUETZ wrote: > 3. Issues Caused by Captive Portals >=20 > o *Confusion* - Because captive portals are effectively a man-in- > the-middle attack, they can confuse users as well as user agents > (e.g., caches). For example, when the portal's TLS certificate > doesn't match that of the requested site, or the captive portal's > /favicon.ico gets used as that of the originally requested site. >=20 > I would not call it man-in-the-middle "attack" - it's more a MITM > "constellation". The sent and expected certificate are different, but > not forged. If the CP would send a fake certificate for example.com > that would be a real MITM attack. I disagree. A MITM attack occurs when Alice sends traffic to Bob, but Mallory replies in Bob's place and makes some effort to speak as though Mallory is Bob. What you're quibbling about is the quality of the impersonation (and maybe a lack of malicious intent). When I first use a captive portal and attempt to connect to https://mail.example/ and then I get a TLS error from my client, it doesn't really matter if the error is that the server certificate says "mail.example" but has an untrusted CA or if it says "captive-portal.example" instead. Either way, the captive portal has intercepted my traffic at an IP & TCP level and responded to it as though I had intended to talk directly to it. That's a MITM. In a perfect world, we'd say that it's blatantly obvious that "mail.example" doesn't match "captive-portal.example" so anyone can tell what's going on. Unfortunately, even without a captive portal, I still get the occasional certificate mismatch error going to foo.example because I get a certificate for baz.akamai.net instead...which I typically click through because I figure that they misconfigured the akamai node to not include foo.example in their SAN list. > -------------------------------------------------------------------------= ----- >=20 > o *TLS* - Portals that attempt to intercept TLS sessions (HTTPS, > IMAPS, or other) can cause certificate error messages on clients, > encouraging bad practice to click through such errors. >=20 > You may consider adding something like: > This bad practice is now avoided by many web sites that are sending an > HSTS HTTP header, in which case the user can't add an exception for > that certifcate if the browser was on the wanted page before. Same for > HPKP headers. The user is stuck until s/he opens an http:// URL. For now. I'm imagining a dark world where most of the web has migrated to HTTPS & browsers do HTTPS with HSTS/HPKP by default but captive portals stubbornly continue to try to MITM the connections, so users complain to browsers that they can't click through the errors to satisfy the captive portal and let them get to the real site...and the *browsers* relent. :-/ Also, it doesn't help anything if users attempt to connect to the HTTP vers= ion of the site instead -- that's just as much of a "click through". > -------------------------------------------------------------------------= ----- >=20 > o *Connectivity Interruption* - For a device with multiple network > interfaces (e.g., cellular and WiFi), connecting to a network can > require dropping access to alternative network interfaces. If > such a device connects to a network with a captive portal, it > loses network connectivity until the captive portal requirements > are satisfied. >=20 > (We see an even more complicated version of it - devices with multiple > interfaces sometimes switch back from WiFi to 3G/4G because the > "online check" of the device reports that the device is offline. This > leads to the problem that users with data plans at the location of the > CP (like a hotel in the same country) have problems to get to the > login page of the CP or have to try a few times.) Worse, if the device abandons WiFi to use the data plan, the user may be incurring significant charges (e.g., because they're in a foreign country). > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >=20 > 5. Security Considerations >=20 > We think regarding security the most important point is not to mess > with TLS connections. If we can get rid of this redirect-to-login > situation this would increase the security of end-users a lot because > they don't "lear" to click through certificate warnings. RFC-7710 > would be a first important step. I don't want CPs to just stop messing with TLS connections, because MITM of unsecured traffic isn't really any better, it's just less visible to software that something is wrong. I think the ideal future state is that: CPs don't falsify or redirect *ANY* traffic. DNS reports honest answers, with DNSSEC if requested. ARP/IPv6-ND is answered honestly. IP traffic to anything but the CP login server is blackholed (not redirected) until the login server has whitelisted the user. Then, once the user is whitelisted, all the information previously learned is still valid (no cache flushes required) and the user can go on with life until their session with the login server times out (if ever). I too think RFC 7710 is a sensible first step, and then it looks like capport's job is to come up with protocols/mechanisms for software to discover connectivity status, time remaining, access limitations. Maybe the way we get captive portals to start stepping in this direction is to give the client some way of reporting "I understand RFC 7710 (etc), so if you just level with me, I'll make this easy for both of us to get what we want and move on."? In response, the CP would rely on RFC 7710 (etc) and disable all the hacks used to funnel users to the login server. The important question is why don't CPs (or OSs) use RFC 7710 now? Or are they? --=20 Scott Schmit --X1bOJ3K7DJ5YkBrT Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIO1AYJKoZIhvcNAQcCoIIOxTCCDsECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DAUwggXZMIIDwaADAgECAgcWZ1TjwnBRMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklM MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTAeFw0wNzEwMTQyMTAxNTVaFw0yMjEwMTQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPM zi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0t svVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpb fuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKk DiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggFMMIIBSDASBgNV HRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwaQYIKwYBBQUHAQEE XTBbMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwMAYIKwYBBQUH MAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAyBgNVHR8EKzApMCeg JaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwQwYDVR0gBDwwOjA4BgRV HSAAMDAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw DQYJKoZIhvcNAQELBQADggIBAHQKh/oy3viYt+qvMyyQhqWiIb9kP1KRhqWHGFMID7OAbofo UgDKVUJ7UsiBnPmleGa2pUwvf2B67qPqc2e9Ge9/kBvJtV8rSES3z+/KVrx6UwlX8VyWnkRN GV0PLvCD+34cIOqhF3Tjmt4jpfYSTjkXcOpa7F4RGZbmu0+j1HO46XAYypOisgXD3XWecqqX zEMimZVrF3DlsMYTYMmFtzRYAeaDh2BxczJlV4HeBs8gw7d4USUoDWHckMR4QK0zLVVmQ1F6 6irltWWsJ9CFKVyz9ZTBspi3FDJCT93XfR4OrOUHB+I5P18lTWHDD1p/9dX7Zh8bdwlOSKdE fsKvzaxVZbKkuXXo7FMG2v6LQ2Jmv6Gc4jJ8jSyjatpy86llJJT2R3tJFPRGlfPcZ1ge3Ad/ qXDZKPI4pN8D5so89WUPAJ7z9ZeDqSFdGTWaynTZaCRPAIC/e35VtTyNuIam+n6nuaZFgccp ACw51vkgFUij6AKxByq7CNgB1Zn/FRX15qZA9bu2ZI8QTHJT/8zM3njXAgV6AsFOf682t14q sYSBz0jpef8kU0q15uV9oZSGjy1ph/0ysQD+342MIh3PQlKp62dj3eWWP3MBF7gtQTbERX1P mMzfTIsyMbjq+pv9P4iKROw0+8MNp0PUNtilMG2fKLBRoczLiZ7hMLjyedCXMIIGJDCCBQyg AwIBAgIDDl5qMA0GCSqGSIb3DQEBCwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwHhcNMTUwNjE0MDkzOTIzWhcNMTYwNjE0MDExMTU1WjBAMRswGQYDVQQDDBJpLmdy b2tAY29tY2FzdC5uZXQxITAfBgkqhkiG9w0BCQEWEmkuZ3Jva0Bjb21jYXN0Lm5ldDCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMIjn4wl8+qbVrQuvFdai6tCinDeN32epeHl 6TTZrVEkSnrwfbcw8+Ym0vnK504W9pcw1nMbmLEA+2u4VtQ2An/Riill57rqxnQXxCJI1MRX UYhwlJRDHlMgIWvJs/Eo+UuY8Pey3xMbZHNA2ZEy29eliAPyWo5PYp6FEBKJeGXbim5iNYtl 5Bxa7/e+lg+1OEKXtHkbdQVhIdPq0pg3qxrgPg+5DCj6Ftxprc5O5IC3H98aAZ1CVUmxwHND c1lhcUJAShVy8jXex/G7RcujkV3c/3FQnyWmKRqAYhJZZuDdgpNIu7eaUYcxmRjmzez9Znlz GpyP5w7rR2g2xHu94oUCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUA+UZJvC5M48j4hknTLlE TizD1rowHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESaS5n cm9rQGNvbWNhc3QubmV0MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASow LgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5U aGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZh bGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlh bmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhl IHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBC BggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5j bGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq hkiG9w0BAQsFAAOCAQEAuN6y26buqE5ITv9ta2IDW10kv0MMZ1HexkSZR1Qvn3rrwJbb5SJA lB8fgMuTVxCRS1c0shrfOQlbCyYfDis+Yzgjda1efaheMLnVcenZ1vtQQ/kotkqQEBWPxW/T 99R2DpCQCJbi4Yg2hiX48THcFq4Qvo0QGwiiyz3QzXbNWDIBPAPKneQzcHo+5x1+7qec0WK/ Lcjflz0I3lmvlxzGWHV/lkaERBjpbVUimTyrZUtzvUi56u/TVsARG2q3vuYpQvRTsiwMIxyD ZZTGvRDDwQ6OWJSFCJb0Wv+lApWH9sr/cG090AaouZRIC/D2Ru3W2NJDBdjyhjwg0Qd4jGVq ZzGCApcwggKTAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAw5e ajAJBgUrDgMCGgUAoIHYMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE2MDMwNDE0MzMwN1owIwYJKoZIhvcNAQkEMRYEFA0GobwKaFJ9E4IBdi+trYGnNALc MHkGCSqGSIb3DQEJDzFsMGowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBALMzwiP7f6FTmCuLU0KZJWFOT0yY QQOjwdoHfXrr4EiD5Y+kd+n0vE/v8IpwNv45xgUQ7n9xm/KpJjdNJORP9miqfWJp3RZhWaUu EZ/TMl7xLqQSEmB8ptnJffy+y8PyjXnApK5nNGHrCi5Fqqpgay5tt5S/g+EZAt4k8XOTacw6 FPkQMDGMXSN1AUYRTt4b/bmJ1x1YDyleHIssP24N8346KsTzDRKiTpTmG9IA798NKvY0i6kV od4Vu3sL8VrnoIruXUYFeGnSyRury4Uy+d6rPbZZJJZZKFdD0UBoZyUBI5XZMcRrG+8gzLCm TNWJGiafqnhT7u75hFBo3pj0s8M= --X1bOJ3K7DJ5YkBrT-- From nobody Fri Mar 4 07:42:22 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B40E1A219B for ; Fri, 4 Mar 2016 07:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 BuMulxlTfL1z for ; Fri, 4 Mar 2016 07:42:19 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (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 862631A1EEE for ; Fri, 4 Mar 2016 07:42:19 -0800 (PST) Received: by mail-yk0-x22a.google.com with SMTP id 1so24315528ykg.3 for ; Fri, 04 Mar 2016 07:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=kKQ23g/P7ikEPykjRrt5M18VLcCTAQTpMKOBK1rYkMA=; b=D83H0qeT2h0RQRxOa/iVO0cnJbgZ2tU+QPOGM2u+eFBXOH5WIDTr9mNqUFv2tUXyxJ qRdWXc2fxlnrS+BidxYTWcksw7ri7JIzxlBOLuuYsPCoCUGjoYjt05tUBT431WCmAtJB kS+q6qVh6vye5Vg6aAEvzx4H+Y02EJ3x7imSV63pvwyj3+o4bWOyBEsYDgTjsCjLYhDE pWGFm7rxtcAUSHDJyWGdi9WbGUTI3I/UyxYdZsn9SDZDtZYsyII1YO96Q8S7D7gZHlqT H5GXjJiGqrJLvjqw/B+9d7QznR8zswumqcsH60AuZ5Vkvqcd7FsSHRxw6ve2jr96bWYl bJAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=kKQ23g/P7ikEPykjRrt5M18VLcCTAQTpMKOBK1rYkMA=; b=FWCyhZjlpTPoi7Id8KJFmagZtzEDZGIBeKhSMuVAZLA2D1ughpL/woCMUuzACn0onP UToV+6vX2gplhpgZx4ZIEit9uolBpw8bPdP7PvJtivODuze325Y2bPS2jqnbADAWNjUU CtPNlKcclNb/g5yjxNRDeDyptNRYXZCC4Z/k+K59PCypl+rgwjGDo2CycYmkjHr3mEER hxcfBo+SahLp9SqxT4r+Laeem7wbOSmuLTyNcKtf3du3a8vLwydSk9SOF6pMfK4BhMzx hWH4HetlK0cPB079pOfmXT920O/2Dr6aNxTCvsjHCDyibktT7dHVLWmYwB8lqqDLCHis 60Nw== X-Gm-Message-State: AD7BkJKh/9F03JGqEiZOqshtXtC7YJuAjN4FiJPWgZNpS3Elk0UN+qhI0aopEIzD7zSjC8aDNdP8VdJgpJ6PSuIb X-Received: by 10.37.94.215 with SMTP id s206mr5009165ybb.119.1457106138747; Fri, 04 Mar 2016 07:42:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Fri, 04 Mar 2016 15:42:09 +0000 Message-ID: To: "Livingood, Jason" , Mark Nottingham , "captive-portals@ietf.org" , Steven Bauer Content-Type: multipart/alternative; boundary=001a11423a72cd0b47052d3af54e Archived-At: Subject: Re: [Captive-portals] CAPPORT meeting at IETF95 in Buenos Aires. X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 15:42:21 -0000 --001a11423a72cd0b47052d3af54e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 2, 2016 at 7:04 PM Livingood, Jason wrote: > On 2/15/16, 12:46 PM, "Captive-portals on behalf of Warren Kumari" < > captive-portals-bounces@ietf.org on behalf of warren@kumari.net> wrote: > > We are in the process of organizing the agenda - one of the things which > we heard from you at the BoFs is that you would like something like a > "survey of the industry" (e.g motivation for deploying a CP) and a more > complete understanding of why captive portal operators do things like > defeating / whitelisting the captive portal probes. > > > Speaking as an operator there is a wide range of ways we use captive > portal like tools. I=E2=80=99m happy to try to organize a presentation if= that is > helpful. Our definition of =E2=80=9Ccaptive portal=E2=80=9D may be a bit = broader than folks > on this list may think, so it may be interesting. > Yes please. I think that it would be very useful to get views from operators. This working group is likely to be run somewhat differently to other working groups - a fair bit of it will be getting operators, vendors and users to talk together, and understand each others views. W > > So, if you develop and / or operate a CP, we'd really like to hear from > you - we give priority agenda time to drafts which have had online > discussion, but may be willing to also have more of a discussion type > presentation. > > > One person who may have interesting thoughts to contribute is Steve Bauer > from MIT, copied here. He has a novel idea for the need to have a > portal-like communication channel to end users that he=E2=80=99s called = =E2=80=9Cnet.info=E2=80=9D > as a working title. I wonder if that might have some applicability here. > > - Jason > > > --001a11423a72cd0b47052d3af54e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed= , Mar 2, 2016 at 7:04 PM Livingood, Jason <Jason_Livingood@comcast.com> wrote:


- Jason


--001a11423a72cd0b47052d3af54e-- From nobody Fri Mar 4 07:43:49 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2761A219B for ; Fri, 4 Mar 2016 07:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-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 9z4I5B2rypEG for ; Fri, 4 Mar 2016 07:43:45 -0800 (PST) Received: from mx1.asteas.com (mx1.asteas.com [83.218.160.135]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1E61A1EEE for ; Fri, 4 Mar 2016 07:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at frozentux.org Received: from EXCHANGE.mbox.local (EXCHANGE.mbox.local [192.168.101.1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.asteas.com (on Asteas-Business-Server) with ESMTPS id C33411860239 for ; Fri, 4 Mar 2016 16:43:40 +0100 (CET) From: Lukas RUETZ To: "captive-portals@ietf.org" Thread-Topic: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-00 Thread-Index: AdF1/WQqxigydv5zQoWQHYB2MGlz2wAHP6uAAANtNFM= Date: Fri, 4 Mar 2016 15:43:40 +0000 Message-ID: <04FC2BF6CA29744989A8227EB45685C6019D21DA@EXCHANGE.mbox.local> References: <04FC2BF6CA29744989A8227EB45685C6019D1162@EXCHANGE.mbox.local>, <20160304143307.GA17578@odin.ulthar.us> In-Reply-To: <20160304143307.GA17578@odin.ulthar.us> Accept-Language: de-AT, en-US Content-Language: de-AT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.3.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 15:43:48 -0000 Hey Scott,=0A= =0A= thanks for your comments - I'm answering inline=0A= =0A= > > 3. Issues Caused by Captive Portals=0A= > >=0A= > > o *Confusion* - Because captive portals are effectively a man-in-= =0A= > > the-middle attack, they can confuse users as well as user agents= =0A= > > (e.g., caches). For example, when the portal's TLS certificate= =0A= > > doesn't match that of the requested site, or the captive portal's= =0A= > > /favicon.ico gets used as that of the originally requested site.= =0A= > >=0A= > > I would not call it man-in-the-middle "attack" - it's more a MITM=0A= > > "constellation". The sent and expected certificate are different, but= =0A= > > not forged. If the CP would send a fake certificate for example.com=0A= > > that would be a real MITM attack.=0A= >=0A= > I disagree. A MITM attack occurs when Alice sends traffic to Bob, but=0A= > Mallory replies in Bob's place and makes some effort to speak as though= =0A= > Mallory is Bob.=0A= >=0A= > What you're quibbling about is the quality of the impersonation (and=0A= > maybe a lack of malicious intent).=0A= =0A= Because a CP does not/should not have this malicious intent, I wasn't=0A= happy with the word "attack". Of course the client can't see the difference= .=0A= =0A= > > -----------------------------------------------------------------------= -------=0A= > >=0A= > > o *TLS* - Portals that attempt to intercept TLS sessions (HTTPS,=0A= > > IMAPS, or other) can cause certificate error messages on clients,= =0A= > > encouraging bad practice to click through such errors.=0A= > >=0A= > > You may consider adding something like:=0A= > > This bad practice is now avoided by many web sites that are sending an= =0A= > > HSTS HTTP header, in which case the user can't add an exception for=0A= > > that certifcate if the browser was on the wanted page before. Same for= =0A= > > HPKP headers. The user is stuck until s/he opens an http:// URL.=0A= >=0A= > For now. I'm imagining a dark world where most of the web has migrated= =0A= > to HTTPS & browsers do HTTPS with HSTS/HPKP by default but captive=0A= > portals stubbornly continue to try to MITM the connections, so users=0A= > complain to browsers that they can't click through the errors to satisfy= =0A= > the captive portal and let them get to the real site...and the *browsers*= =0A= > relent. :-/=0A= >=0A= > Also, it doesn't help anything if users attempt to connect to the HTTP ve= rsion=0A= > of the site instead -- that's just as much of a "click through".=0A= =0A= With the addition I tried to make clear in the document what happens if HST= S=0A= and HPKP are used, nothing else.=0A= Calling an http:// URL is the only working way at the moment to get a valid= =0A= redirect until there is a real solution to this. Sadly people don't read,= =0A= so the URL to the login-page printed on the tickets is almost never used.= =0A= =0A= QR-Codes already helped a bit, but only a few users have QR-code readers in= stalled.=0A= =0A= > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=0A= > >=0A= > > 5. Security Considerations=0A= > >=0A= > > We think regarding security the most important point is not to mess=0A= > > with TLS connections. If we can get rid of this redirect-to-login=0A= > > situation this would increase the security of end-users a lot because= =0A= > > they don't "lear" to click through certificate warnings. RFC-7710=0A= > > would be a first important step.=0A= >=0A= > I don't want CPs to just stop messing with TLS connections, because MITM= =0A= > of unsecured traffic isn't really any better, it's just less visible=0A= > to software that something is wrong.=0A= >=0A= > I think the ideal future state is that:=0A= >=0A= > CPs don't falsify or redirect *ANY* traffic. DNS reports honest=0A= > answers, with DNSSEC if requested. ARP/IPv6-ND is answered honestly.=0A= > IP traffic to anything but the CP login server is blackholed (not=0A= > redirected) until the login server has whitelisted the user.=0A= >=0A= > Then, once the user is whitelisted, all the information previously=0A= > learned is still valid (no cache flushes required) and the user can go=0A= > on with life until their session with the login server times out (if=0A= > ever).=0A= >=0A= > I too think RFC 7710 is a sensible first step, and then it looks like=0A= > capport's job is to come up with protocols/mechanisms for software to=0A= > discover connectivity status, time remaining, access limitations.=0A= >=0A= > Maybe the way we get captive portals to start stepping in this direction= =0A= > is to give the client some way of reporting "I understand RFC 7710=0A= > (etc), so if you just level with me, I'll make this easy for both of us= =0A= > to get what we want and move on."? In response, the CP would rely on=0A= > RFC 7710 (etc) and disable all the hacks used to funnel users to the=0A= > login server.=0A= >=0A= > The important question is why don't CPs (or OSs) use RFC 7710 now? Or=0A= > are they?=0A= =0A= Well we completely agree in this point - it just sounds a bit like you thin= k=0A= CPs are doing this for fun. Most of this hacks are made to get the user=0A= to the login-page. We hope that this WG pushes things further.=0A= =0A= And by the way ... we ship RFC-7710 since this year, but AFAIK no device=0A= supports it. We're waiting for the OS vendors to implement it.=0A= =0A= BR=0A= Lukas=0A= =0A= =0A= =0A= -- =0A= Lukas RUETZ=0A= www.iacbox.com=0A= =0A= From nobody Sun Mar 6 18:03:08 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797BF1A6F3B for ; Sun, 6 Mar 2016 18:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.321 X-Spam-Level: * X-Spam-Status: No, score=1.321 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 B8wn16bbqlEb for ; Sun, 6 Mar 2016 18:03:05 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 275ED1A6F33 for ; Sun, 6 Mar 2016 18:03:05 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id e6so103157372vkh.2 for ; Sun, 06 Mar 2016 18:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=0FW5i0mlGr1/o5gdiS2Pv4YdrFN/le99a3InuLNJxBY=; b=HLc3CuiUb1040/MptVqzLxXW580Ub8jc0rAXkMbF9zi/3TVp7LTh4i/+IPxSUd6rLT fB+0U6RiiXb1oVM2JjDK1b+H7uToRNmeq7bhilrwliKSpDqC7GyfQ55Nz9CjyukOzsLz jXC8p7ABXZEOHMhxg1/xycTqpfqkrX6k4xVae7iiyakeUAqQ1pbx6QI3ZQ3oEdFrPdqm L+ATYuKDs2HntbctQC09dJSVp3fN8TgtisurAOI3InRavwQzRM+sm3jb+82CXX0jfMqv Q/OzvTIWNkIrXppDOQvJO0E/wONsmdRTZFYvLvHz/BMEYkLHV7g8P1xCLNOMPTCFsJ6t fA+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=0FW5i0mlGr1/o5gdiS2Pv4YdrFN/le99a3InuLNJxBY=; b=HsUk3wsPQ8As7qRYHPQ7hvOo1ESyg2ojYgJzJmaWy/LUDJ6+izBD19H4tkmvUvh+s4 AR5DSV0I7dn/kTbA5JsjnryWO9jkARDKio+K/ixQ2T28ZEqlZylXtRV279QgEfzRXLaw 6lcO4twzUOOIgikh1L/ujIiaplyYZ+9NxsicZkB7BvQFwVN5as7fCHyNKjPQhDokMAee wOt1SVM47kDXFMIk0xXi9kms361gfRWOv1tmBqJJX57Urx347PcyJS1R5xlIk3jZNg3R GOu6qchWz6ZlnVi/jcoe4WSeR0VOKaIfJ52D6UCX12bHzEQhK2iL2j9uAfA5KdlXQfLE IA5w== X-Gm-Message-State: AD7BkJLlzSmKIHgkoMUcAXUNehA0egut18zv/mc5XsTlkc56YOV7wm5fwBmCEcIcG+TIvyn6ELc3nzKd8sT8WCw0 MIME-Version: 1.0 X-Received: by 10.31.194.10 with SMTP id s10mr18484667vkf.72.1457316183945; Sun, 06 Mar 2016 18:03:03 -0800 (PST) Received: by 10.159.37.42 with HTTP; Sun, 6 Mar 2016 18:03:03 -0800 (PST) Date: Sun, 6 Mar 2016 18:03:03 -0800 Message-ID: From: David Bird To: captive-portals@ietf.org Content-Type: multipart/alternative; boundary=001a114661dc78827d052d6bdd86 Archived-At: Subject: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-01 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 02:03:07 -0000 --001a114661dc78827d052d6bdd86 Content-Type: text/plain; charset=UTF-8 Greetings, Overall a good and much needed document! A few first round comments: -- I find the terms "captive portal" and "portals" can be confusing in the doc. It can mean the general feature, from the end-user-perspective, of being hijacked and being presented a captive portal page. At times, it means the specific hijacking mechanism within the network - the Network Access Server (NAS), and at other times it can mean specifically the captive portal website itself. I was hoping this doc could include some terminology. Maybe: Captive Portal - The feature of forcing users to a specific captive portal website CP-Network - A network the employs a captive portal; integrated CP-NAS and CP-Web (depth of integration varies) CP-NAS - A feature of the network infrastructure that enforces a captive portal, redirecting to CP-Web CP-Web - A website application that authorizes users onto CP-Network -- In Section 2, Once the captive portal's goals (see below) are met, the network "remembers" that the user is allowed network access, usually by MAC address. Maybe "Once the CP-Web's requirements (see below) are met, the user is released from the captive state within the CP-NAS. The implementation details and degree of integration between CP-Web, CP-NAS, and other network services (such as DHCP, DNS, etc) will vary between CP-Networks." -- Regarding: *Unexpected Configuration* - Some captive portals rely upon DNS interception to direct users to the portal; however, this doesn't work when the user has configured their own DNS server in preference to that provided by DHCP (e.g., 8.8.8.8). The supporting text seems rather specific to CPs that use forged DNS... Maybe "Some captive portals do not work with clients using unexpected configurations, for example clients using static IP, custom DNS servers, or HTTP proxies." (If kept, s/doesn't work/may not work/ - the CP-NAS could override with a DNAT to a specific DNS (not that I ever think faking DNS is a good solution)) -- Regarding: *Stealing Access* - because captive portals most often associate a user with a MAC address, it is possible for an attacker to impersonate an authenticated client (e.g., one that has paid for Internet access). This is an issue with Open WiFi, not necessarily with captive portals. If you removed the Open WiFi (say the CP is being used on a secure wireless medium), then this completely doesn't apply. While I agree this is an issue with (especially paid) access over Open WiFi, not sure it belongs in this doc, and securing the Open Bss shouldn't be within the scope of the WG. -- Regarding: *Access to Privileged Information* - Some captive portals want to utilise external information about the user, such as social media account logins and/or advertising tracking/targeting services. However, because the captive portal is effectively acting as a man-in-the-middle, providing these capabilities can put the user at risk. Not sure I follow this one... True that a CP might require an external login of some kind, but if done within the walled garden and over HTTPS, then how does the CP-Network increase exposure here? Or, is this also talking more about Open WiFi problems? -- Regarding: *Connectivity Interruption* - For a device with multiple network interfaces (e.g., cellular and WiFi), connecting to a network can require dropping access to alternative network interfaces. If such a device connects to a network with a captive portal, it CAN lose network connectivity until the captive portal requirements are satisfied. I added the CAN above as not all devices will drop the existing good connection when connecting to a network with a CP detected. -- In section 4, it says "Detection aims to minimize the negative effects caused by captive portals in several ways. Captive portal detection can cause issues in some networks; for example: .." Suggestion: after "several ways, " list a few, or change to something like "Detection aims to minimize the above negative effects caused by captive portals, but can cause different issues, including: ..." -- I don't feel we have explained the reasons for operators wanting to defeat the CP detection in section 4.1. Perhaps in section 4, under *Sandboxing* we can explain: While sandboxing seems a good idea to protect user data (particularly on Open WiFi), it is implemented differently on various platforms and often causes a (severely) broken user experience on the operator's CP-Web site (even when the operator is protecting user data end-to-end with HTTPS). To offer a consistent and rich experience on the CP-Web, some operators actively try to defeat OS CP detection. -- If I may rant a bit... OS vendors and others doing CP detection are conflating security issues around Open WiFi and Public Access Networks, and the need to protect user data in such networks, with CP detection. While CP detection is perhaps a good signal for designating a network as Public Access, it does not inherently mean the underlying network is "insecure". Nor does the absence of a CP in an Open WiFi network mean the underlying network is in anyway "secure" (and therefore not Sandboxed). The reasons for vendors being extra suspicious of CP networks is because of the similarities with mitm attacks - which is understandable. However, as CP networks are more common place and the mechanisms for signaling become more formalized (thanks to this WG), vendors need to work with, not against, operators who utilize TLS to protect user-data even in Open WiFi public access networks, to offer a full browser CP-Web experience. -- David --001a114661dc78827d052d6bdd86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Greetings,

Overall a good and much need= ed document! A few first round comments:

--

I find the terms "captive portal" and &quo= t;portals" can be confusing in the doc. It can mean the general featur= e, from the end-user-perspective, of being hijacked and being presented a c= aptive portal page. At times, it means the specific hijacking mechanism wit= hin the network - the Network Access Server (NAS), and at other times it ca= n mean specifically the captive portal website itself. I was hoping this do= c could include some terminology.=C2=A0

Maybe:
Captive Portal - The feature of forcing users to a specific captive porta= l website
CP-Network - A network the employs a captive portal; in= tegrated CP-NAS and CP-Web (depth of integration varies)
CP-NAS -= A feature of the network infrastructure that enforces a captive portal, re= directing to CP-Web
CP-Web - A website application that authorize= s users onto CP-Network

--
=
In Section 2,=C2=A0
Once the captive portal's goals (see below)= are met, the network
"remembers" that the user is allowed net= work access, usually by MAC
address.

Maybe "Onc= e the CP-Web's requirements (see below) are met, the user is released f= rom the captive state within the CP-NAS. The implementation details and deg= ree of integration between CP-Web, CP-NAS, and other network services (such= as DHCP, DNS, etc) will vary between CP-Networks."

--

Regarding:
*Unexpected Configuration* = - Some captive portals rely upon DNS
interception to direct users to the= portal; however, this doesn't
work when the user has configured the= ir own DNS server in
preference to that provided by DHCP (e.g., 8.8.8.8)= .

The supporting text seems rather spec= ific to CPs that use forged DNS... Maybe "Some captive portals do not = work with clients using unexpected configurations, for example clients usin= g static IP, custom DNS servers, or HTTP proxies."

<= /div>
(If kept, s/doesn't work/may not work/ - the CP-NAS coul= d override with a DNAT to a specific DNS (not that I ever think faking DNS = is a good solution))

--

Regardi= ng:
*Stealing Access* - because captive portals most often associate a
u= ser with a MAC address, it is possible for an attacker to
impersonate an= authenticated client (e.g., one that has paid for
Internet access).
=
This is an issue with Open WiFi, not necessarily with capt= ive portals. If you removed the Open WiFi (say the CP is being used on a se= cure wireless medium), then this completely doesn't apply. While I agre= e this is an issue with (especially paid) access over Open WiFi, not sure i= t belongs in this doc, and securing the Open Bss shouldn't be within th= e scope of the WG.

--

Regarding= :
*Connectivity Interruption* - For a device with multi= ple network
interfaces (e.g., cellular and WiFi), connecting to a networ= k can
require dropping access to alternative network interfaces. If
s= uch a device connects to a network with a captive portal, it
CAN lose ne= twork connectivity until the captive portal requirements
are satisfied.<= br>
I added the CAN above as not all devices will drop the = existing good connection when connecting to a network with a CP detected.= =C2=A0

--

In section 4, it says &quo= t;Detection aims to minimize the negative effects caused by=C2=A0captive po= rtals in several ways.=C2=A0 Captive portal detection can cause issues in s= ome networks; for=C2=A0example: .."

Suggestion: aft= er "several ways, " list a few, or change to something like "= ;Detection aims to minimize the above negative effects caused by captive po= rtals, but can cause different issues, including: ..."

<= /div>
--

I don't feel we have explained th= e reasons for operators wanting to defeat the CP detection in section 4.1. = Perhaps in section 4, under *Sandboxing* we can explain:

While sandboxing seems a good idea to protect user data (particularly on = Open WiFi), it is implemented differently on various platforms and often ca= uses a (severely) broken user experience on the operator's CP-Web site = (even when the operator is protecting user data end-to-end with HTTPS). To = offer a consistent and rich experience on the CP-Web, some operators active= ly try to defeat OS CP detection.

--

If I may rant a bit... OS ve= ndors and others doing CP detection are conflating security issues around O= pen WiFi and Public Access Networks, and the need to protect user data in s= uch networks, with CP detection. While CP detection is perhaps a good signa= l for designating a network as Public Access, it does not inherently mean t= he underlying network is "insecure". Nor does the absence of a CP= in an Open WiFi network mean the underlying network is in anyway "sec= ure" (and therefore not Sandboxed). The reasons for vendors being extr= a suspicious of CP networks is because of the similarities with mitm attack= s - which is understandable. However, as CP networks are more common place = and the mechanisms for signaling become more formalized (thanks to this WG)= , vendors need to work with, not against, operators who utilize TLS to prot= ect user-data even in Open WiFi public access networks, to offer a full bro= wser CP-Web experience.

--

David

--001a114661dc78827d052d6bdd86-- From nobody Mon Mar 7 07:08:37 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E98F1B427C for ; Mon, 7 Mar 2016 07:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 GJg5h6l5Yfd6 for ; Mon, 7 Mar 2016 07:08:29 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 391CA1B4272 for ; Mon, 7 Mar 2016 07:08:29 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 7 Mar 2016 10:08:28 -0500 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Mon, 7 Mar 2016 10:08:19 -0500 From: Dave Dolson To: Martin Thomson , "Livingood, Jason" Thread-Topic: [Captive-portals] Comments on draft-nottingham-capport-problem-00 Thread-Index: AQHRdOMXZOFwZ0XXhk2b4ei54nIPUJ9OFNFg Date: Mon, 7 Mar 2016 15:08:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Mark Nottingham , "captive-portals@ietf.org" Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 15:08:35 -0000 Regarding non-browser clients, even non-HTTP clients, and considering this is the IETF, it seems reasonable to find an IP-layer solution vs.=20 an HTTP-layer solution. E.g., a new ICMP/ICMP6 error code to indicate the host is walled, with a po= inter to the method to authenticate in the payload. This could be an extension to "Network Unreachable", or a new code. ICMP messages are handled by the O/S, and could trigger an authentication w= ork-flow appropriate to the device, whether it be a human-interface device like a ta= blet or a head-less IOT device. E.g., suppose the a VoIP phone becomes walled during a call. Outgoing packe= ts are answered with an ICMP message; the O/S immediately performs the authent= ication using previously-provided credentials, and the call continues shortly there= after. If the credentials fail, the user can be presented with a window or browse= r. The ICMP payload would be a standard format, and could have security featur= es to avoid spoofing. I guess I'm jumping ahead of the problem statement, but I think the "Non-Browser Clients" issue could be changed to "Non-HTTP Clients", providing a huge win. -Dave -----Original Message----- From: Captive-portals [mailto:captive-portals-bounces@ietf.org] On Behalf O= f Martin Thomson Sent: Wednesday, March 02, 2016 7:25 PM To: Livingood, Jason Cc: Mark Nottingham; captive-portals@ietf.org Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem= -00 On 3 March 2016 at 11:16, Livingood, Jason wr= ote: > 3.0, Feel free to take a look at the text in Section 12 of RFC 6108 and > use some of that text. You got the gist of it in the Non-Browser Clients > sub-section though (https://tools.ietf.org/html/rfc6108#section-12) This raises an interesting point about internet dot org by facebook. I wonder if there are any lessons to be learned from that as well. _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals From nobody Mon Mar 7 07:38:38 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FE21B42FA for ; Mon, 7 Mar 2016 07:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.234 X-Spam-Level: X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-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 ID4U6TcFDtQX for ; Mon, 7 Mar 2016 07:38:36 -0800 (PST) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4844F1B42F9 for ; Mon, 7 Mar 2016 07:38:36 -0800 (PST) X-AuditID: 60721c4b-f79016d000007994-97-56dda07b1512 Received: from VAADCEX38.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 3B.51.31124.B70ADD65; Mon, 7 Mar 2016 10:38:35 -0500 (EST) Received: from VAADCEX37.cable.comcast.com (147.191.103.214) by VAADCEX38.cable.comcast.com (147.191.103.215) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 7 Mar 2016 10:38:34 -0500 Received: from VAADCEX37.cable.comcast.com ([fe80::3aea:a7ff:fe12:38b0]) by VAADCEX37.cable.comcast.com ([fe80::3aea:a7ff:fe12:38b0%19]) with mapi id 15.00.1130.005; Mon, 7 Mar 2016 10:38:34 -0500 From: "Livingood, Jason" To: Dave Dolson , Martin Thomson Thread-Topic: [Captive-portals] Comments on draft-nottingham-capport-problem-00 Thread-Index: AQHReIdo/WCGGu/hX0OKWSkVnY8sZQ== Date: Mon, 7 Mar 2016 15:38:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.7] Content-Type: text/plain; charset="us-ascii" Content-ID: <971ACC6059A4A449A09A642024987643@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsWSUOxpoVu94G6Yweo9vBZzZzWwWmxd9pDd 4tqZf4wW6z89ZnRg8dg56y67x5IlP5k8Ni7+zurxdfN21gCWKC6blNSczLLUIn27BK6Mq+dn Mxe0MlVsfzmHtYHxKmMXIyeHhICJxL8vW6BsMYkL99azdTFycQgJbGGSuHNiIytIQkjgIKPE wr8OEPYJRolfa+JBbDYBM4m7C68wg9giAsESvYcvMIHYzAIxEqu3HmYDsYUF/CS2H2+DqgmU eHdnA5StJ9Ha3QA2n0VAReJsxw+wOK+AvcTm5XuhjjjDKPHiySmw6zgFAiSW/DkHNpQR6NLv p9ZALROXuPVkPhPEBwISS/acZ4awRSVePv4HtkAUaNnBTytZIeI6EmevP4H62EBi69J9LBC2 nMTc1/dYIGbqSCzY/YkNwnaQ6Ng3jRHC1pZYtvA11KGCEidnPoHqFZc4fGQH6wRGmVlITpqF ZNQsJKNmIRk1C8moBYysqxjlyhITU5JzM/JLSwwM9ZITk3JS9ZLzc5MTi0tA9CZGUIookvHe wbjup/shRgEORiUe3l/T74YJsSaWFVfmHmKU4GBWEuEVnQ8U4k1JrKxKLcqPLyrNSS0+xCjN waIkzst+5mqYkEB6YklqdmpqQWoRTJaJg1OqgXFaG2fnbdaTcbtM9dX9X5Zcq5fq/esoYf/W ynWinsjladzH6n+6ef0MdXvxc84srcMiu17v5d8g9Vp8wbad8rVOi95FTBV14fvqIb9Ew8Ok t4P7vYeSv7TN3QciC71OiTreU9P5xydtz7nkqqnPpucVrDn7LaNqbyduVVvjzTRfRfbYTL6A zUosxRmJhlrMRcWJAF79IsgNAwAA Archived-At: Cc: Mark Nottingham , "captive-portals@ietf.org" Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 15:38:37 -0000 On 3/7/16, 10:08 AM, "Dave Dolson" wrote: >Regarding non-browser clients, even non-HTTP clients, and considering >this is the IETF, it seems reasonable to find an IP-layer solution vs. >an HTTP-layer solution. +1 to that!=20 From nobody Mon Mar 7 07:54:27 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF4A1B433C for ; Mon, 7 Mar 2016 07:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 ww0wWXWSZRi2 for ; Mon, 7 Mar 2016 07:54:25 -0800 (PST) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B9DF1B4288 for ; Mon, 7 Mar 2016 07:54:24 -0800 (PST) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by mail.dragon.net (Postfix) with ESMTP id 5E7A23740943; Mon, 7 Mar 2016 07:54:23 -0800 (PST) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id 1590733519F0; Mon, 7 Mar 2016 10:54:23 -0500 (EST) Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id 1524133519EF; Mon, 7 Mar 2016 10:54:23 -0500 (EST) To: Dave Dolson , Martin Thomson , Mark Nottingham , "captive-portals@ietf.org" From: Paul Ebersman In-reply-to: References: Comments: In-reply-to "Livingood, Jason" message dated "Mon, 07 Mar 2016 15:38:34 +0000." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 07 Mar 2016 10:54:23 -0500 Message-Id: <20160307155423.1590733519F0@fafnir.remote.dragon.net> Archived-At: Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 15:54:26 -0000 ddolson> Regarding non-browser clients, even non-HTTP clients, and ddolson> considering this is the IETF, it seems reasonable to find an ddolson> IP-layer solution vs. an HTTP-layer solution. Indeed... All sorts of phone apps don't use HTTP but need to tickle the reaction. From nobody Mon Mar 7 09:23:10 2016 Return-Path: X-Original-To: captive-portals@ietfc.amsl.com Delivered-To: captive-portals@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 596851CD622 for ; Mon, 7 Mar 2016 09:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCgSamnEstmg for ; Mon, 7 Mar 2016 09:23:07 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 02C661CD61E for ; Mon, 7 Mar 2016 09:23:04 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id k1so108374701vkb.0 for ; Mon, 07 Mar 2016 09:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=rB1oUUy47fljMHlvWzBQqftjuV18hVLKDGEEgHDbbM0=; b=jCXuDNrwbu5AupP9HaBfeWpvhEgnfK9CZ5w5RP8IBNY0EphVdhbPQDLyZmjYCFH5Ul oV2JDLvUFIFUZkxhQY79JJ69Stmho155sI8h83guW4w3tuE053fNe3FK1v7yg1fCpvEl tJDffokluwdr8iJREPTsaPmdK9OER1nH0j63VceZT75pqrUzD+n8Z+EUFmGEzdGF3oul 4vw2hYB74Hw63a1QE9G5hXQfsDt899zGFdYQPJlzBnlro57TZqe4n3ISDLHk8fOEzgOO sH0s7KFDYPSXeCqrg9gGHTSePf7JvS3kRbT+E3epTxDHFmiz2JJhXNDXBhtNCE+9ZOY1 lwTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rB1oUUy47fljMHlvWzBQqftjuV18hVLKDGEEgHDbbM0=; b=KHvp6GAcDfdD2NQiGEFzdTHTyLJaCeqJKv8NnhjISYAlLAbc5RwTK/zaxbUO8fJEdv o2oRHfgvgaInqYSed/x3oOSfUjscOunK/8SFB2FPNositdvNsCrefKznhIWcXcuFSfj7 7qW61V05lU8+iaK3l0M8BYRsVJW8/2NEsr1U+j5lcvYsSaz694yurHuMniAEyeS/iv8C NJflqAPCsEem9E6cChocFmU4CM0JM+n87gwWTRGcKNIxa4yjqtouVkAXdaBaNBDG+MN7 VqQqIJIuo+maAF/cY31XOY2vx92Cx1GjRfir0iM3tYwGKlM/ERW3rNWNGG25beLrySlE JtkQ== X-Gm-Message-State: AD7BkJJkeWcxPkYUlzhnKgttY1Fd858Fk2lsdJ845cP7KZwCQWrHuRrt/P/GI+foGe2Zn96I7LPVB8/gitjJc0Fv MIME-Version: 1.0 X-Received: by 10.31.180.215 with SMTP id d206mr20931643vkf.125.1457370032338; Mon, 07 Mar 2016 09:00:32 -0800 (PST) Received: by 10.159.37.42 with HTTP; Mon, 7 Mar 2016 09:00:32 -0800 (PST) In-Reply-To: <20160307155423.1590733519F0@fafnir.remote.dragon.net> References: <20160307155423.1590733519F0@fafnir.remote.dragon.net> Date: Mon, 7 Mar 2016 09:00:32 -0800 Message-ID: From: David Bird To: Paul Ebersman Content-Type: multipart/alternative; boundary=001a1143f35615e16b052d786743 Archived-At: Cc: "captive-portals@ietf.org" , Mark Nottingham , Martin Thomson , Dave Dolson Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 17:23:08 -0000 --001a1143f35615e16b052d786743 Content-Type: text/plain; charset=UTF-8 +1 for an ICMP solution ... https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-00 On Mon, Mar 7, 2016 at 7:54 AM, Paul Ebersman < list-captive-portals@dragon.net> wrote: > > ddolson> Regarding non-browser clients, even non-HTTP clients, and > ddolson> considering this is the IETF, it seems reasonable to find an > ddolson> IP-layer solution vs. an HTTP-layer solution. > > Indeed... All sorts of phone apps don't use HTTP but need to tickle the > reaction. > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > --001a1143f35615e16b052d786743 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 7, 2016 at 7:54 AM, Paul Eb= ersman <list-captive-portals@dragon.net> wrote= :

ddolson> Regarding non-browser clients, even non-HTTP clients, and
ddolson> considering this is the IETF, it seems reasonable to find an ddolson> IP-layer solution vs. an HTTP-layer solution.

Indeed... All sorts of phone apps don't use HTTP but need to tickle the=
reaction.

_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-p= ortals

--001a1143f35615e16b052d786743-- From nobody Mon Mar 7 09:36:13 2016 Return-Path: X-Original-To: captive-portals@ietfc.amsl.com Delivered-To: captive-portals@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8CFB01CD662 for ; Mon, 7 Mar 2016 09:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wrHlpVeRpUo for ; Mon, 7 Mar 2016 09:36:10 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 5349A1CD668 for ; Mon, 7 Mar 2016 09:36:10 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id e185so125349994vkb.1 for ; Mon, 07 Mar 2016 09:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=EMl7d1HN40u/4co5F8W4sNpozvBa4WLRHR49EYE1qDk=; b=dxyQDRlFUp2dCFE60idALigNRw0bXqtJG0u6DNLXWWear5AOQQmhPMr8PzOXG4gO+l nrxt054eIc/z974vm9qu8WU1ioT6NBpYfbRcrjxDafRpHDl0WA2QbA3WF9HjluX4Bh29 GJZL6j7HzbuO3uw5s6x4MSJ8nS88+ZEUCA4rELQUj7Ez1AOo0gky41OZppDfyfdlN3mn eeE2PSOJU+DX6aGpG/lxdbygZOvdgI1LvNH0jFfMHHSSvT0wdL1X7UJ/aOTxQ26mXpKA UK4xiqw4+85JiyigvECVU1z1hcDpWo9IPu1AtBCl7tlIkkCVGcfQ6Bu2oT40ZJhd90KN Wkjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=EMl7d1HN40u/4co5F8W4sNpozvBa4WLRHR49EYE1qDk=; b=Dhmpa2sZYH3eOLkw/MdgtY/XiwNOKuiLUCx5vD+iksRIG2BEzoYdCRRvq3UObF07M5 /PVVhiuCN2CLUs8hzO/b+iObhzpVAFt197Va0X4RKc17r19v9OyT9ycOBCMEbPgrp1yZ NQBylURtGjsRX1rtlBtFjZD+6ibPG/V5rL6AaNzJqDXCOGBUE2476kONPefOBKdUOhkI Z5+JZkBgGGFKO6YBCorq8mGaF2H2Q0pChfoazBh1YlU+mzbYR4keaheBwVfAehMyGBb3 pAQORjS6V8S4PWktoHBWH6BXxUCDB7oSW96z6sWbBUIfAtWLcLucIWi2sqyii9BuEOlB iOow== X-Gm-Message-State: AD7BkJKtPQKKL+mZ8bqsiDw+uw7XiWRr1dDloVBbPxNvkbssSFpGEoHzE2Nrc+9iHdhd6+tGsTM3ZurjpY+geYow MIME-Version: 1.0 X-Received: by 10.31.194.10 with SMTP id s10mr22086708vkf.72.1457370295237; Mon, 07 Mar 2016 09:04:55 -0800 (PST) Received: by 10.159.37.42 with HTTP; Mon, 7 Mar 2016 09:04:55 -0800 (PST) In-Reply-To: References: <20160307155423.1590733519F0@fafnir.remote.dragon.net> Date: Mon, 7 Mar 2016 09:04:55 -0800 Message-ID: From: David Bird To: Paul Ebersman Content-Type: multipart/alternative; boundary=001a114661dcc19f4c052d78761d Archived-At: Cc: "captive-portals@ietf.org" , Mark Nottingham , Martin Thomson , Dave Dolson Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 17:36:11 -0000 --001a114661dcc19f4c052d78761d Content-Type: text/plain; charset=UTF-8 Sorry, link was to wrong version: https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-01 On Mon, Mar 7, 2016 at 9:00 AM, David Bird wrote: > +1 for an ICMP solution ... > https://tools.ietf.org/html/draft-wkumari-capport-icmp-unreach-00 > > On Mon, Mar 7, 2016 at 7:54 AM, Paul Ebersman < > list-captive-portals@dragon.net> wrote: > >> >> ddolson> Regarding non-browser clients, even non-HTTP clients, and >> ddolson> considering this is the IETF, it seems reasonable to find an >> ddolson> IP-layer solution vs. an HTTP-layer solution. >> >> Indeed... All sorts of phone apps don't use HTTP but need to tickle the >> reaction. >> >> _______________________________________________ >> Captive-portals mailing list >> Captive-portals@ietf.org >> https://www.ietf.org/mailman/listinfo/captive-portals >> > > --001a114661dcc19f4c052d78761d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 7, 2016 at 9:00 AM, D= avid Bird <dbird@google.com> wrote:
On Mon, Mar 7, 2016 at 7:54 AM, Paul Ebersman = <list-captive-portals@dragon.net> wrote:

ddolson> Regarding non-browser clients, even non-HTTP clients, and
ddolson> considering this is the IETF, it seems reasonable to find an ddolson> IP-layer solution vs. an HTTP-layer solution.

Indeed... All sorts of phone apps don't use HTTP but need to tickle the=
reaction.

_______________________________________________
Captive-portals mailing list
Captive-porta= ls@ietf.org
https://www.ietf.org/mailman/listinfo/captive-p= ortals


--001a114661dcc19f4c052d78761d-- From nobody Mon Mar 7 17:24:35 2016 Return-Path: X-Original-To: captive-portals@ietfc.amsl.com Delivered-To: captive-portals@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 788561CD75C for ; Mon, 7 Mar 2016 17:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ou8ScmdY52z for ; Mon, 7 Mar 2016 17:24:32 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id A84221CD759 for ; Mon, 7 Mar 2016 17:24:32 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5643C509B5; Mon, 7 Mar 2016 20:24:30 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Mark Nottingham In-Reply-To: Date: Tue, 8 Mar 2016 12:24:27 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <18C84D29-4E74-463D-B617-5CF25E9DCE7A@mnot.net> References: To: Dave Dolson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "captive-portals@ietf.org" , "Livingood, Jason" , Martin Thomson Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 01:24:34 -0000 On 8 Mar 2016, at 2:08 AM, Dave Dolson wrote: >=20 > Regarding non-browser clients, even non-HTTP clients, and considering > this is the IETF, it seems reasonable to find an IP-layer solution vs.=20= > an HTTP-layer solution. Making the presence of a CP clear to non-HTTP clients seems like a good = thing. Doing much more than that (e.g., presenting something to the = user, getting their credentials) is less attractive. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Mar 8 00:09:43 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E5012D506 for ; Mon, 7 Mar 2016 23:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIiBaYDK9cos for ; Mon, 7 Mar 2016 23:45:25 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E53012D4FF for ; Mon, 7 Mar 2016 23:45:25 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CB56850A85; Tue, 8 Mar 2016 02:45:22 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Mark Nottingham In-Reply-To: Date: Tue, 8 Mar 2016 18:45:19 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <51DE1996-428B-4F22-AB02-64C31F812E39@mnot.net> References: To: David Bird X-Mailer: Apple Mail (2.3112) Archived-At: Cc: captive-portals@ietf.org Subject: Re: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-01 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 07:45:28 -0000 Hi David, Thanks for the feedback. Some responses below, and changes at: https://github.com/mnot/I-D/commit/165bc6744e04380757d > On 7 Mar 2016, at 1:03 PM, David Bird wrote: >=20 > Greetings, >=20 > Overall a good and much needed document! A few first round comments: >=20 > -- >=20 > I find the terms "captive portal" and "portals" can be confusing in = the doc. It can mean the general feature, from the end-user-perspective, = of being hijacked and being presented a captive portal page. At times, = it means the specific hijacking mechanism within the network - the = Network Access Server (NAS), and at other times it can mean specifically = the captive portal website itself. I was hoping this doc could include = some terminology.=20 >=20 > Maybe: > Captive Portal - The feature of forcing users to a specific captive = portal website > CP-Network - A network the employs a captive portal; integrated CP-NAS = and CP-Web (depth of integration varies) > CP-NAS - A feature of the network infrastructure that enforces a = captive portal, redirecting to CP-Web > CP-Web - A website application that authorizes users onto CP-Network >=20 > In Section 2,=20 > Once the captive portal's goals (see below) are met, the network > "remembers" that the user is allowed network access, usually by MAC > address. >=20 > Maybe "Once the CP-Web's requirements (see below) are met, the user is = released from the captive state within the CP-NAS. The implementation = details and degree of integration between CP-Web, CP-NAS, and other = network services (such as DHCP, DNS, etc) will vary between = CP-Networks." I *think* we can get away with defining just "captive portal" and = "captive network" for now; see rewrite. > Regarding: > *Unexpected Configuration* - Some captive portals rely upon DNS > interception to direct users to the portal; however, this doesn't > work when the user has configured their own DNS server in > preference to that provided by DHCP (e.g., 8.8.8.8). >=20 > The supporting text seems rather specific to CPs that use forged = DNS... Maybe "Some captive portals do not work with clients using = unexpected configurations, for example clients using static IP, custom = DNS servers, or HTTP proxies." >=20 > (If kept, s/doesn't work/may not work/ - the CP-NAS could override = with a DNAT to a specific DNS (not that I ever think faking DNS is a = good solution)) Done. > Regarding: > *Stealing Access* - because captive portals most often associate a > user with a MAC address, it is possible for an attacker to > impersonate an authenticated client (e.g., one that has paid for > Internet access). >=20 > This is an issue with Open WiFi, not necessarily with captive portals. = If you removed the Open WiFi (say the CP is being used on a secure = wireless medium), then this completely doesn't apply. While I agree this = is an issue with (especially paid) access over Open WiFi, not sure it = belongs in this doc, and securing the Open Bss shouldn't be within the = scope of the WG. I've added: """ Note that this is specific to open Wifi, and can be prevented by using a = secure wireless medium. However, configuration of secure wireless is = often deemed to be too complex for captive networks. """ > Regarding: > *Access to Privileged Information* - Some captive portals want to > utilise external information about the user, such as social media > account logins and/or advertising tracking/targeting services. > However, because the captive portal is effectively acting as a > man-in-the-middle, providing these capabilities can put the user > at risk. >=20 > Not sure I follow this one... True that a CP might require an external = login of some kind, but if done within the walled garden and over HTTPS, = then how does the CP-Network increase exposure here? Or, is this also = talking more about Open WiFi problems? I've seen CPs that ask for Facebook username and password, but NOT over = HTTPS, and not to a Facebook domain (IIRC); it's more of a user = education / security UX problem than anything. Still, that's probably out of scope here (even if it is scary). I'll = remove the section unless someone else wants to keep it. > Regarding: > *Connectivity Interruption* - For a device with multiple network > interfaces (e.g., cellular and WiFi), connecting to a network can > require dropping access to alternative network interfaces. If > such a device connects to a network with a captive portal, it > CAN lose network connectivity until the captive portal requirements > are satisfied. >=20 > I added the CAN above as not all devices will drop the existing good = connection when connecting to a network with a CP detected.=20 Fixed. > In section 4, it says "Detection aims to minimize the negative effects = caused by captive portals in several ways. Captive portal detection can = cause issues in some networks; for example: .." >=20 > Suggestion: after "several ways, " list a few, or change to something = like "Detection aims to minimize the above negative effects caused by = captive portals, but can cause different issues, including: ..." Done, thanks. > I don't feel we have explained the reasons for operators wanting to = defeat the CP detection in section 4.1. Perhaps in section 4, under = *Sandboxing* we can explain: >=20 > While sandboxing seems a good idea to protect user data (particularly = on Open WiFi), it is implemented differently on various platforms and = often causes a (severely) broken user experience on the operator's = CP-Web site (even when the operator is protecting user data end-to-end = with HTTPS). To offer a consistent and rich experience on the CP-Web, = some operators actively try to defeat OS CP detection. Done. > If I may rant a bit... OS vendors and others doing CP detection are = conflating security issues around Open WiFi and Public Access Networks, = and the need to protect user data in such networks, with CP detection. = While CP detection is perhaps a good signal for designating a network as = Public Access, it does not inherently mean the underlying network is = "insecure". Nor does the absence of a CP in an Open WiFi network mean = the underlying network is in anyway "secure" (and therefore not = Sandboxed). The reasons for vendors being extra suspicious of CP = networks is because of the similarities with mitm attacks - which is = understandable. However, as CP networks are more common place and the = mechanisms for signaling become more formalized (thanks to this WG), = vendors need to work with, not against, operators who utilize TLS to = protect user-data even in Open WiFi public access networks, to offer a = full browser CP-Web experience. Has anyone looked at exactly what the sandbox restrictions are in = current OSs? Thanks again! -- Mark Nottingham https://www.mnot.net/ From nobody Tue Mar 8 01:20:24 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FF212D57E for ; Tue, 8 Mar 2016 01:20:21 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFVmw9kAVKC0 for ; Tue, 8 Mar 2016 01:20:20 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 5166412D592 for ; Tue, 8 Mar 2016 01:11:27 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id g203so18955054iof.2 for ; Tue, 08 Mar 2016 01:11:27 -0800 (PST) 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; bh=/sWN0r3SG8DFKnrP41k1YoOK6GI+Dslob/yTs1euY98=; b=BGiQQGowr6cFjnT3mxvLdx579HBrFX/Tg/TcISxCwhs9b2tpT5gkRN/hNJD9QReHmt dYKfRoC7mbhX408vzuUn5S604Czy3QOKfYOpyLQ9h5ER54alem9V5KC0GGHUAGqhP0mZ 0aD17RO4JCgwkTaMV4tVG6q6wvE/LEJAIsOJ3d8tV/s0mti2WOR3ppqd7E3pinICppyw b9kzTasG8hYOIfEjPjMENksTyE4m0dtV9q7wVl9lwFaR3AU7ahkTz8RpLUu6dAAS/mPA OY55wKNjzUGiJhXGQ7JhVrj353vvae+hcokEdvD6I4Y0ueLbhoK4kqktT7Zx40YJHAs0 pieg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/sWN0r3SG8DFKnrP41k1YoOK6GI+Dslob/yTs1euY98=; b=BQIOoR/B/XF6W7X9vTQBXJqQuwEEHKGivGbNCBFIFCkatbkDEHIvUcwxm1gDUla3kp EwZTK9THt0oNZNJpiPDkYHGYltz10UTMYP1Z00akPmVt90MC/xJvel6MAmzP5gAO3zPu OSDEuw56aPnl2DGe5gpVRXRSagC11z8m8iFBKeCNnbtDs2s4sj1IyJ3Ths4dA1wu1Z2Z J9gGxGsVdPIN5JBMIKDhrheMmSa53Ii5gCovuy4eiawvLf7OZu98t6Ek2Gnup1fFlg9l hq8tUS9kq9/zvyns9HGiX6XczDiFW8pk3v2UtLaSwVyS1jL7sYIfQF84OEQvVdNbTe5j /JRA== X-Gm-Message-State: AD7BkJLR46inO12+iwiFId/vwhjSQr6zODPXiiXzogyAHIaqp5qfE39K50qyybRPPW+oEkMCsU91EULZpV7Teg== MIME-Version: 1.0 X-Received: by 10.107.41.133 with SMTP id p127mr26688995iop.100.1457428286550; Tue, 08 Mar 2016 01:11:26 -0800 (PST) Received: by 10.36.43.5 with HTTP; Tue, 8 Mar 2016 01:11:26 -0800 (PST) In-Reply-To: <51DE1996-428B-4F22-AB02-64C31F812E39@mnot.net> References: <51DE1996-428B-4F22-AB02-64C31F812E39@mnot.net> Date: Tue, 8 Mar 2016 20:11:26 +1100 Message-ID: From: Martin Thomson To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: captive-portals@ietf.org, David Bird Subject: Re: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-01 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 09:20:21 -0000 On 8 March 2016 at 18:45, Mark Nottingham wrote: > I've seen CPs that ask for Facebook username and password, but NOT over HTTPS, and not to a Facebook domain (IIRC); it's more of a user education / security UX problem than anything. That's perhaps an extreme - and horrific - example of what I thought you intended here. Loading a real browser allows a CP to close the loop with tracking bugs. That is less offensive, though to what degree might depend on where you sit. There are probably plenty of potentially relevant reasons too. For example, a network operator might simply want to authorize one set of users (their paying customers) over others. A sandbox in that context represents a hurdle for their users, who can't rely on cookies or other preexisting state. The sandbox then has security drawbacks in that it encourages users to pick less secure passwords. From nobody Tue Mar 8 04:50:03 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F43512D6AA for ; Tue, 8 Mar 2016 04:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEaDXV5AoUdo for ; Tue, 8 Mar 2016 04:50:01 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA3A12D620 for ; Tue, 8 Mar 2016 04:50:01 -0800 (PST) Received: (qmail 9520 invoked from network); 8 Mar 2016 12:49:59 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 8 Mar 2016 12:49:59 -0000 Date: 8 Mar 2016 12:49:37 -0000 Message-ID: <20160308124937.2948.qmail@ary.lan> From: "John Levine" To: captive-portals@ietf.org In-Reply-To: <20160307155423.1590733519F0@fafnir.remote.dragon.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: list-captive-portals@dragon.net Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 12:50:02 -0000 >ddolson> Regarding non-browser clients, even non-HTTP clients, and >ddolson> considering this is the IETF, it seems reasonable to find an >ddolson> IP-layer solution vs. an HTTP-layer solution. > >Indeed... All sorts of phone apps don't use HTTP but need to tickle the >reaction. Even worse, they do use HTTP but expect an answer from their own server and strange things happen when they get the portal's page instead. R's, John From nobody Tue Mar 8 07:37:18 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB1E12D791 for ; Tue, 8 Mar 2016 07:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=umn.edu Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_IkTJ8Sji5Y for ; Tue, 8 Mar 2016 07:37:15 -0800 (PST) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41EAC12D768 for ; Tue, 8 Mar 2016 07:37:15 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id AA4DF236 for ; Tue, 8 Mar 2016 15:37:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6S955i40OYQ for ; Tue, 8 Mar 2016 09:37:14 -0600 (CST) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 73652220 for ; Tue, 8 Mar 2016 09:37:14 -0600 (CST) Received: by mail-ig0-f177.google.com with SMTP id hb3so67277548igb.0 for ; Tue, 08 Mar 2016 07:37:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=reply-to:subject:references:to:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MH9yywSK+aU8ay2FO6TPiSPm8DZ0CQjWJ78Mlm+w9Uo=; b=D8Q+eADlnkKNS4kT1Pp9VGFJQ09f6/HuhX7grAYBoVEZJWqF3qPg1AeWmuwgvzxTPA mmtg2q5b+Ys0wNS7oSZQ949PjQbL2vY9t/M+8QMnNdCcGxTGpYwYZKUBfVLzAbT21ZYR R7/2r1SM7WU6pD2wEzu49TuGPLIIJeRFOMo0o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=MH9yywSK+aU8ay2FO6TPiSPm8DZ0CQjWJ78Mlm+w9Uo=; b=HMGFyAw4uAeUo/xwEQToEOQI8V+gO6PRWJK0t16RxUq4iqME7/zYRsAPUSKZNG4Mkf oukycuIJpVPFsrQsLdnATDe1yjkoqIv4AQJNktS6Cuoufaka2jZDzKCjNWtRn/LiaKgw 8ZrKIjcvdeGIvurZyeIErupmt6jraLS6WBbEmwon7jR00QkzTf2AMn7gXZoW8HRn3fMP WxcLQXlsNUOXM/zMV+Aj7Th5J8vYutArSd825YWQ6gqkLQph8kEDb3R/uZC9hUQmPrDm 4HJv1W2qLxXWRMZPWvRS98mP/IJqKNhVdFrLhRkRwctLBbZ25qlcFioVMEpTqTwGc8lR G6mA== X-Gm-Message-State: AD7BkJKaE6UVNQ7UVLwprMbzCkRffym6CAsjQQJArsIjDggzI1Kgu15Lbe02QiNoAx756vueHA87e5P8qm7RrvhMgtcND5e9GLFBFbnus7YMX4Pt5MbHhCc5vTEKPGB1SgsEUi8BFiV8/kxdww== X-Received: by 10.50.73.161 with SMTP id m1mr18232191igv.48.1457451431953; Tue, 08 Mar 2016 07:37:11 -0800 (PST) X-Received: by 10.50.73.161 with SMTP id m1mr18232173igv.48.1457451431742; Tue, 08 Mar 2016 07:37:11 -0800 (PST) Received: from x-134-84-1-148.vpn.umn.edu (x-134-84-1-148.vpn.umn.edu. [134.84.1.148]) by smtp.gmail.com with ESMTPSA id 65sm490526ioq.43.2016.03.08.07.37.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Mar 2016 07:37:10 -0800 (PST) References: <18C84D29-4E74-463D-B617-5CF25E9DCE7A@mnot.net> To: Mark Nottingham , Dave Dolson From: David Farmer Organization: University of Minnesota Message-ID: <56DEF1A4.70206@umn.edu> Date: Tue, 8 Mar 2016 09:37:08 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <18C84D29-4E74-463D-B617-5CF25E9DCE7A@mnot.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: David Farmer , "Livingood, Jason" , "captive-portals@ietf.org" , Martin Thomson Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: David Farmer List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 15:37:17 -0000 While at the same time if we want people to actually use it, a non-HTTP solution can't become a trivially easy off-path attack vector or any of a number of other security problems either. I think a non-HTTP solution is critically important, but it's equally important to get the security right for all of this, HTTP(S) based or not. This is going to fundamentally be hard to get right, if it was easy we would have dealt with this long ago, but now it time to work through this and get it right. Thanks On 3/7/16 19:24 , Mark Nottingham wrote: > On 8 Mar 2016, at 2:08 AM, Dave Dolson wrote: >> >> Regarding non-browser clients, even non-HTTP clients, and considering >> this is the IETF, it seems reasonable to find an IP-layer solution vs. >> an HTTP-layer solution. > > Making the presence of a CP clear to non-HTTP clients seems like a good thing. Doing much more than that (e.g., presenting something to the user, getting their credentials) is less attractive. > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Thu Mar 10 15:51:38 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467D912DEEA for ; Thu, 10 Mar 2016 15:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3e8TL5oC5eOZ for ; Thu, 10 Mar 2016 15:51:33 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B81912DEE4 for ; Thu, 10 Mar 2016 15:51:32 -0800 (PST) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6A63D22E253; Thu, 10 Mar 2016 18:51:25 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Mark Nottingham In-Reply-To: Date: Fri, 11 Mar 2016 10:51:21 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <16287DD0-2408-4164-A945-F10A0D9BF22D@mnot.net> References: <51DE1996-428B-4F22-AB02-64C31F812E39@mnot.net> To: Martin Thomson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: captive-portals@ietf.org, David Bird Subject: Re: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-01 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 23:51:37 -0000 On 8 Mar 2016, at 8:11 PM, Martin Thomson = wrote: >=20 > On 8 March 2016 at 18:45, Mark Nottingham wrote: >> I've seen CPs that ask for Facebook username and password, but NOT = over HTTPS, and not to a Facebook domain (IIRC); it's more of a user = education / security UX problem than anything. >=20 >=20 > That's perhaps an extreme - and horrific - example of what I thought > you intended here. >=20 > Loading a real browser allows a CP to close the loop with tracking > bugs. That is less offensive, though to what degree might depend on > where you sit. >=20 > There are probably plenty of potentially relevant reasons too. For > example, a network operator might simply want to authorize one set of > users (their paying customers) over others. A sandbox in that context > represents a hurdle for their users, who can't rely on cookies or > other preexisting state. The sandbox then has security drawbacks in > that it encourages users to pick less secure passwords. One aspect that's potentially different is that current CP detection = implementations (going to add a term for that :) can be automatically = triggered; if the OS recognises a SSID ("ATTWifi", anyone?), it'll pop = up a window. Without sandboxing, that means the network gets tracking data without = any user intent in a very common case. An attacker can also spoof a = common SSID to gather such data. Of course, OSs could stop automatically joining Wifi networks, but that = would make for a lot of unhappy users... -- Mark Nottingham https://www.mnot.net/ From nobody Thu Mar 10 16:10:02 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA5912DEEF for ; Thu, 10 Mar 2016 16:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 U4DzUuElvm65 for ; Thu, 10 Mar 2016 16:09:58 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 82CE412DF0F for ; Thu, 10 Mar 2016 16:09:58 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id e185so116085226vkb.1 for ; Thu, 10 Mar 2016 16:09:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OfSrANKsEF/ot/Qd8uqPiXjMyil7B0PMHeLKrYsCByQ=; b=Skco4Nz567fEX68ERJ+3Yn+arDjeSjWMLOPbul3CK4oSphu5M59JNHOB6Nd0ZReFw8 3oBSA9zzNRX1WrIjdJOcGUzWeG+bSWIidChq3pTZ3wLvEPuuCXvttUBEfp731MMdNDa7 lIZYge0ngVafNulx5DdFmenoalhwbeyfWQW7po3ktJKR+ocbm6xFWQsVJgMF3vBTuq+O osZOQJSPD3SlrxzyEi4uBWqOip1UWS7wRRgl8q5cZt6AFK/WZrwX1H8pt4AoGTLQ2KI9 S0NrocmIyAGLPlC0gpFFs6JUWvN1elxz6dyG7tR7O33Q4m5AKolwjLWNYLUCarAZtE7o kArg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=OfSrANKsEF/ot/Qd8uqPiXjMyil7B0PMHeLKrYsCByQ=; b=RLUV5dcwgDo0uoGDnyULvUlVRTdlxZVou6Jt48JIKOyJRhAH4yD4hZWefl1auPZS8h Jb7klu2eQnwFg4RBpUTkphPJwbk/zpMI45DG+YEqWeW7ix3Sry5wr8RybzcYkD76/7Cz 0E7JOqE+PqyCh0BTo1WIL98ajDptks54W1Rx+ItZv9hlbNmbWAlF9hWWlOj2VzED5ZUf uUWH8+1LdQvVzIsC6seEceKsL3lHUj4aXfPhy61zWRUqUr5MPdG8WPAl5BqzH3OJhcYu lKU6/vmhRrlk4bcerEdSr1ER1pXHpVbzwpIpI6Ljfx5QtYwey21Gpm5UZKyJJgbE3j30 D4vg== X-Gm-Message-State: AD7BkJIEIlA4X58Cz/8Nft7eA8dqgyxSl1AR/gpreECTRIX0TFf9QJQcwYDb5RoJwVHPfoMHU3Ml8RLWY2cT/P2H MIME-Version: 1.0 X-Received: by 10.31.180.215 with SMTP id d206mr6417154vkf.125.1457654997535; Thu, 10 Mar 2016 16:09:57 -0800 (PST) Received: by 10.159.37.42 with HTTP; Thu, 10 Mar 2016 16:09:57 -0800 (PST) In-Reply-To: <16287DD0-2408-4164-A945-F10A0D9BF22D@mnot.net> References: <51DE1996-428B-4F22-AB02-64C31F812E39@mnot.net> <16287DD0-2408-4164-A945-F10A0D9BF22D@mnot.net> Date: Thu, 10 Mar 2016 16:09:57 -0800 Message-ID: From: David Bird To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a1143f356559ac2052dbac0b3 Archived-At: Cc: captive-portals@ietf.org, Martin Thomson Subject: Re: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-01 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 00:10:01 -0000 --001a1143f356559ac2052dbac0b3 Content-Type: text/plain; charset=UTF-8 I'm not aware of any CP detection being triggered only based on the SSID. (What does it do if there actually isn't a CP?) ... An attacker gets a LOT more mileage out of a Open SSID evil twin with NO captive portal if the desire is to capture cookies... Any attacker that gets tripped up by clients doing a Sandboxed browser isn't a very good attacker :) David On Thu, Mar 10, 2016 at 3:51 PM, Mark Nottingham wrote: > On 8 Mar 2016, at 8:11 PM, Martin Thomson > wrote: > > > > On 8 March 2016 at 18:45, Mark Nottingham wrote: > >> I've seen CPs that ask for Facebook username and password, but NOT over > HTTPS, and not to a Facebook domain (IIRC); it's more of a user education / > security UX problem than anything. > > > > > > That's perhaps an extreme - and horrific - example of what I thought > > you intended here. > > > > Loading a real browser allows a CP to close the loop with tracking > > bugs. That is less offensive, though to what degree might depend on > > where you sit. > > > > There are probably plenty of potentially relevant reasons too. For > > example, a network operator might simply want to authorize one set of > > users (their paying customers) over others. A sandbox in that context > > represents a hurdle for their users, who can't rely on cookies or > > other preexisting state. The sandbox then has security drawbacks in > > that it encourages users to pick less secure passwords. > > One aspect that's potentially different is that current CP detection > implementations (going to add a term for that :) can be automatically > triggered; if the OS recognises a SSID ("ATTWifi", anyone?), it'll pop up a > window. > > Without sandboxing, that means the network gets tracking data without any > user intent in a very common case. An attacker can also spoof a common SSID > to gather such data. > > Of course, OSs could stop automatically joining Wifi networks, but that > would make for a lot of unhappy users... > > > -- > Mark Nottingham https://www.mnot.net/ > > --001a1143f356559ac2052dbac0b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not aware of any CP detection being triggered only= based on the SSID. (What does it do if there actually isn't a CP?) ...=

An attacker gets a LOT more mileage out of a Open SSID = evil twin with NO captive portal if the desire is to capture cookies... Any= attacker that gets tripped up by clients doing a Sandboxed browser isn'= ;t a very good attacker :)

David


On Thu, = Mar 10, 2016 at 3:51 PM, Mark Nottingham <mnot@mnot.net> wrote:<= br>
O= n 8 Mar 2016, at 8:11 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> On 8 March 2016 at 18:45, Mark Nottingham <mnot@mnot.net> wrote:
>> I've seen CPs that ask for Facebook username and password, but= NOT over HTTPS, and not to a Facebook domain (IIRC); it's more of a us= er education / security UX problem than anything.
>
>
> That's perhaps an extreme - and horrific - example of what I thoug= ht
> you intended here.
>
> Loading a real browser allows a CP to close the loop with tracking
> bugs.=C2=A0 That is less offensive, though to what degree might depend= on
> where you sit.
>
> There are probably plenty of potentially relevant reasons too.=C2=A0 F= or
> example, a network operator might simply want to authorize one set of<= br> > users (their paying customers) over others.=C2=A0 A sandbox in that co= ntext
> represents a hurdle for their users, who can't rely on cookies or<= br> > other preexisting state.=C2=A0 The sandbox then has security drawbacks= in
> that it encourages users to pick less secure passwords.

One aspect that's potentially different is that current CP = detection implementations (going to add a term for that :) can be automatic= ally triggered; if the OS recognises a SSID ("ATTWifi", anyone?),= it'll pop up a window.

Without sandboxing, that means the network gets tracking data without any u= ser intent in a very common case. An attacker can also spoof a common SSID = to gather such data.

Of course, OSs could stop automatically joining Wifi networks, but that wou= ld make for a lot of unhappy users...


--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/


--001a1143f356559ac2052dbac0b3-- From nobody Thu Mar 10 16:12:26 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF03512DF0F for ; Thu, 10 Mar 2016 16:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WV0LZFXJ6j4E for ; Thu, 10 Mar 2016 16:12:22 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5DBE12DF0E for ; Thu, 10 Mar 2016 16:12:21 -0800 (PST) Received: from [192.168.2.11] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4A73422E255; Thu, 10 Mar 2016 19:12:20 -0500 (EST) Content-Type: multipart/alternative; boundary=Apple-Mail-113C8235-E208-47C9-A2F8-C7B472167E86 Mime-Version: 1.0 (1.0) From: Mark Nottingham X-Mailer: iPhone Mail (13D15) In-Reply-To: Date: Fri, 11 Mar 2016 11:12:16 +1100 Content-Transfer-Encoding: 7bit Message-Id: <455D0008-E6E5-42C7-8C61-81CEA6916445@mnot.net> References: <51DE1996-428B-4F22-AB02-64C31F812E39@mnot.net> <16287DD0-2408-4164-A945-F10A0D9BF22D@mnot.net> To: David Bird Archived-At: Cc: captive-portals@ietf.org, Martin Thomson Subject: Re: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-01 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 00:12:25 -0000 --Apple-Mail-113C8235-E208-47C9-A2F8-C7B472167E86 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Good point.=20 Sent from my iPhone > On 11 Mar 2016, at 11:09 AM, David Bird wrote: >=20 > I'm not aware of any CP detection being triggered only based on the SSID. (= What does it do if there actually isn't a CP?) ... >=20 > An attacker gets a LOT more mileage out of a Open SSID evil twin with NO c= aptive portal if the desire is to capture cookies... Any attacker that gets t= ripped up by clients doing a Sandboxed browser isn't a very good attacker :)= >=20 > David >=20 >=20 >> On Thu, Mar 10, 2016 at 3:51 PM, Mark Nottingham wrote: >> On 8 Mar 2016, at 8:11 PM, Martin Thomson wrot= e: >> > >> > On 8 March 2016 at 18:45, Mark Nottingham wrote: >> >> I've seen CPs that ask for Facebook username and password, but NOT ove= r HTTPS, and not to a Facebook domain (IIRC); it's more of a user education /= security UX problem than anything. >> > >> > >> > That's perhaps an extreme - and horrific - example of what I thought >> > you intended here. >> > >> > Loading a real browser allows a CP to close the loop with tracking >> > bugs. That is less offensive, though to what degree might depend on >> > where you sit. >> > >> > There are probably plenty of potentially relevant reasons too. For >> > example, a network operator might simply want to authorize one set of >> > users (their paying customers) over others. A sandbox in that context >> > represents a hurdle for their users, who can't rely on cookies or >> > other preexisting state. The sandbox then has security drawbacks in >> > that it encourages users to pick less secure passwords. >>=20 >> One aspect that's potentially different is that current CP detection impl= ementations (going to add a term for that :) can be automatically triggered;= if the OS recognises a SSID ("ATTWifi", anyone?), it'll pop up a window. >>=20 >> Without sandboxing, that means the network gets tracking data without any= user intent in a very common case. An attacker can also spoof a common SSID= to gather such data. >>=20 >> Of course, OSs could stop automatically joining Wifi networks, but that w= ould make for a lot of unhappy users... >>=20 >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >=20 --Apple-Mail-113C8235-E208-47C9-A2F8-C7B472167E86 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Good point. 

Sent from my i= Phone

On 11 Mar 2016, at 11:09 AM, David Bird <dbird@google.com> wrote:

I'm not aware of any CP detection b= eing triggered only based on the SSID. (What does it do if there actually is= n't a CP?) ...

An attacker gets a LOT more mileage out of= a Open SSID evil twin with NO captive portal if the desire is to capture co= okies... Any attacker that gets tripped up by clients doing a Sandboxed brow= ser isn't a very good attacker :)

David
<= br>

On T= hu, Mar 10, 2016 at 3:51 PM, Mark Nottingham <mnot@mnot.net> wrote:=
On= 8 Mar 2016, at 8:11 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> On 8 March 2016 at 18:45, Mark Nottingham <mnot@mnot.net> wrote:
>> I've seen CPs that ask for Facebook username and password, but NOT o= ver HTTPS, and not to a Facebook domain (IIRC); it's more of a user educatio= n / security UX problem than anything.
>
>
> That's perhaps an extreme - and horrific - example of what I thought > you intended here.
>
> Loading a real browser allows a CP to close the loop with tracking
> bugs.  That is less offensive, though to what degree might depend o= n
> where you sit.
>
> There are probably plenty of potentially relevant reasons too.  Fo= r
> example, a network operator might simply want to authorize one set of > users (their paying customers) over others.  A sandbox in that con= text
> represents a hurdle for their users, who can't rely on cookies or
> other preexisting state.  The sandbox then has security drawbacks i= n
> that it encourages users to pick less secure passwords.

One aspect that's potentially different is that current CP detec= tion implementations (going to add a term for that :) can be automatically t= riggered; if the OS recognises a SSID ("ATTWifi", anyone?), it'll pop up a w= indow.

Without sandboxing, that means the network gets tracking data without any us= er intent in a very common case. An attacker can also spoof a common SSID to= gather such data.

Of course, OSs could stop automatically joining Wifi networks, but that woul= d make for a lot of unhappy users...


--
Mark Nottingham   https://www.mnot.net/


= --Apple-Mail-113C8235-E208-47C9-A2F8-C7B472167E86-- From prolag@gmail.com Fri Mar 11 07:58:44 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3CF12D6C6 for ; Fri, 11 Mar 2016 07:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Rr690vqBNMPb for ; Fri, 11 Mar 2016 07:58:33 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 D8ECD12D899 for ; Fri, 11 Mar 2016 07:57:55 -0800 (PST) Received: by mail-lb0-x234.google.com with SMTP id k15so162836136lbg.0 for ; Fri, 11 Mar 2016 07:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc; bh=5pybKI2c9G0L+vz5pFfmDcfBGjfT8mr7EyhCkL2I+6I=; b=kBfC9t+c8GNFzfDBXsLYhJwUGnDD24bKfq+LLMZDrT2BTmL7Nx3zFWbpmX4vzrwdPf o/rC/aj0yuCTIiBHbQCFy6x7o/+DsETOBFeaqvLimTTC1Ctew8LQQZ6XszrXYOfOZ0GV ChITDpfMalUYfCWgVgppGuiVcHGGiKIxt/XJzM+PGh3A3oPMq/KxvTL5sF3EbYryQlwy TO+dcO7y3VeTtnpSgvL7EAx5KmdjFr7hWYodu/fcBxdC85Oq3DilBunAH5xmXourZtCI cD2UNFLb+cWYlP6gTWfY3fLPsQyrDt9xi3+j7WBqf7BHB40il7earOALvCFYlqV7JS0A Gfwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:sender:in-reply-to :references:date:message-id:subject:from:to:cc; bh=5pybKI2c9G0L+vz5pFfmDcfBGjfT8mr7EyhCkL2I+6I=; b=kIUvhCglBm95/+rPEsSPBoAL0TS5xQj9zyve0GIk9HWTmxyrwgbS3nKxcOpUVjtDdQ mdNTYJh5uyP/OWknTdHr7SkJEcyPK4ToS7YbW0DX6k7MPthvYEMuJSRI5z77I/hSGRfh JLiNzmfNQ2TSqdXF+h4VkURtPvlc9bYX6hnk5xyKACYmK6uTyC/og8vkI2WRLk/RQIPJ cbC1p1bgnQYsXEDGV+Syj7fyrFReq/04y0HjErj2991ZFbClLD4kxbOMqD4JfMy3fAox JmDUlYuARczz/xv24Zdxjo94NfRcZ4a1V+we++15Wk7c7K95LMDHxZQ1EJmJdMQs/i4x QQKQ== X-Gm-Message-State: AD7BkJJBeKalDsAPe12bLXwaXN3LTLqjgPzXb9b3tHRQu63qKaMvwmXEKHHh4CmK5IFl/GP4aMeF4Y9BtKgwdw== MIME-Version: 1.0 X-Received: by 10.25.35.87 with SMTP id j84mr3567039lfj.119.1457711873983; Fri, 11 Mar 2016 07:57:53 -0800 (PST) Sender: prolag@gmail.com Received: by 10.25.213.70 with HTTP; Fri, 11 Mar 2016 07:57:53 -0800 (PST) In-Reply-To: <16287DD0-2408-4164-A945-F10A0D9BF22D@mnot.net> References: <51DE1996-428B-4F22-AB02-64C31F812E39@mnot.net> <16287DD0-2408-4164-A945-F10A0D9BF22D@mnot.net> Date: Fri, 11 Mar 2016 16:57:53 +0100 X-Google-Sender-Auth: z9lT8johuUQf6gBuv6tOk1j9dvk Message-ID: From: Alexis La Goutte To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a113c9ba06f0f6e052dc7fe70 Archived-At: Cc: captive-portals@ietf.org, Martin Thomson , David Bird Subject: Re: [Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-01 X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: alexis.lagoutte@gmail.com List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 16:00:24 -0000 --001a113c9ba06f0f6e052dc7fe70 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 11, 2016 at 12:51 AM, Mark Nottingham wrote: > On 8 Mar 2016, at 8:11 PM, Martin Thomson > wrote: > > > > On 8 March 2016 at 18:45, Mark Nottingham wrote: > >> I've seen CPs that ask for Facebook username and password, but NOT over > HTTPS, and not to a Facebook domain (IIRC); it's more of a user education / > security UX problem than anything. > > > > > > That's perhaps an extreme - and horrific - example of what I thought > > you intended here. > > > > Loading a real browser allows a CP to close the loop with tracking > > bugs. That is less offensive, though to what degree might depend on > > where you sit. > > > > There are probably plenty of potentially relevant reasons too. For > > example, a network operator might simply want to authorize one set of > > users (their paying customers) over others. A sandbox in that context > > represents a hurdle for their users, who can't rely on cookies or > > other preexisting state. The sandbox then has security drawbacks in > > that it encourages users to pick less secure passwords. > > One aspect that's potentially different is that current CP detection > implementations (going to add a term for that :) can be automatically > triggered; if the OS recognises a SSID ("ATTWifi", anyone?), it'll pop up a > window. > Hi, it is the idea of HotSpot 2.0 from WiFi Alliance ? Add on SSID announce frame (Beacon Frame), It is a SSID with Captif Portal.... HotSpot 2.0 is already supported by WiFi Vendor (Like Aruba / Cisco)... > > Without sandboxing, that means the network gets tracking data without any > user intent in a very common case. An attacker can also spoof a common SSID > to gather such data. > > Of course, OSs could stop automatically joining Wifi networks, but that > would make for a lot of unhappy users... > > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > --001a113c9ba06f0f6e052dc7fe70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 11, 2016 at 12:51 AM, Mark Nottingham <= ;mnot@mnot.net> wrote:
On 8 Mar 20= 16, at 8:11 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> On 8 March 2016 at 18:45, Mark Nottingham <mnot@mnot.net> wrote:
>> I've seen CPs that ask for Facebook username and password, but= NOT over HTTPS, and not to a Facebook domain (IIRC); it's more of a us= er education / security UX problem than anything.
>
>
> That's perhaps an extreme - and horrific - example of what I thoug= ht
> you intended here.
>
> Loading a real browser allows a CP to close the loop with tracking
> bugs.=C2=A0 That is less offensive, though to what degree might depend= on
> where you sit.
>
> There are probably plenty of potentially relevant reasons too.=C2=A0 F= or
> example, a network operator might simply want to authorize one set of<= br> > users (their paying customers) over others.=C2=A0 A sandbox in that co= ntext
> represents a hurdle for their users, who can't rely on cookies or<= br> > other preexisting state.=C2=A0 The sandbox then has security drawbacks= in
> that it encourages users to pick less secure passwords.

One aspect that's potentially different is that current CP detec= tion implementations (going to add a term for that :) can be automatically = triggered; if the OS recognises a SSID ("ATTWifi", anyone?), it&#= 39;ll pop up a window.
Hi,
it is the ide= a of HotSpot 2.0 from WiFi Alliance ? Add on SSID announce frame (Beacon Fr= ame), It is a SSID with Captif Portal....
HotSpot 2.0 is alr= eady supported by WiFi Vendor (Like Aruba / Cisco)...=C2=A0=C2=A0

Without sandboxing, that means the network gets tracking data without any u= ser intent in a very common case. An attacker can also spoof a common SSID = to gather such data.

Of course, OSs could stop automatically joining Wifi networks, but that wou= ld make for a lot of unhappy users...=C2=A0


--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

____________________________= ___________________
Captive-portals mailing list
Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-p= ortals

--001a113c9ba06f0f6e052dc7fe70-- From nobody Fri Mar 11 08:22:44 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5229512D883 for ; Fri, 11 Mar 2016 08:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BV8vGNpUiFG0 for ; Fri, 11 Mar 2016 08:22:38 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 276AE12D868 for ; Fri, 11 Mar 2016 08:22:38 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id s68so49628577qkh.3 for ; Fri, 11 Mar 2016 08:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=gZUGT53dcB0WmMfNirjm/aq1Ly3tUlMFpAFjpWkf8hU=; b=Hn/oXPGbhyh2//zQ2XPbl22KUJyT030R9A1G3YAcoI2Fd9hj/V1LmN6ahm7FuxDrDY gZzX3o2qUPO8ltV8fuC2ufLh4K2H90u++Yn0c2y9icHIm/AahPKPVfYldnHnuPV/nwy1 VHC9os0YJm5Q56I9xp2PZp4T9yy2tQnMccP+VLXNWsAs8tLwhbTFLMRiD4SxjdtgUUUL oI8fSJ4Z82jE3+DicXUR+j3V73jYFeSOZHEokOaPsHfCx4BM1JLEGAr8LoHiRNCkTujP t1Keh7xQdwcjI06YL/DlaOc5eETWTwfZQoMS6i1QzgNdczCN9RI3F3ofD72HXKjlMyTS Hp5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=gZUGT53dcB0WmMfNirjm/aq1Ly3tUlMFpAFjpWkf8hU=; b=W7JtSu0BBCXMJ9/Ej5dz2WqSrMYzLMLzmBiGAuB5Tfjkz6uWKreNwUaXh1JtAbKXC7 vYPmA4rr/3TMXuz2nl9T8vaLKw/9dKtDRtxuEWTU75i1eC4tJSfCbqFkw64w6Hty1Hz3 xqjMgxM0FTsU+dK2azFXl0h3veVvLktyL02Li/HrlxSKdrKP9acozGuy/3SDXRayW15T 28e17Y6gJjSNCD/tmjbSReKuzlpl8VoVhNUQWZAiDhcUBsOP1haQRKozhalS/d9YCcf3 UdD/E/PgVPvFpKDNTCpafi7tUCE/A8PD1XTHubzYmmo0zZctSw0+4vVIB87ZwiGXfxFN uxeg== X-Gm-Message-State: AD7BkJLkHLZFlj/ADeYjUBpCOxMKWTdJOZREKRq+sovvSF6Ryu490RpmhNSUvGLkrMQp1DVDip4RpVSURDBYwA== MIME-Version: 1.0 X-Received: by 10.55.71.135 with SMTP id u129mr5859372qka.26.1457713357187; Fri, 11 Mar 2016 08:22:37 -0800 (PST) Received: by 10.140.101.140 with HTTP; Fri, 11 Mar 2016 08:22:37 -0800 (PST) Date: Fri, 11 Mar 2016 10:22:37 -0600 Message-ID: From: Basavaraj Patil To: captive-portals@ietf.org Content-Type: multipart/alternative; boundary=001a114a7d20d701f6052dc856c3 Archived-At: Subject: [Captive-portals] Scope question X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 16:22:43 -0000 --001a114a7d20d701f6052dc856c3 Content-Type: text/plain; charset=UTF-8 Detecting a captive portal and redirecting a browser to a specific page is one aspect. But does the WG intend to also address the issue of apps that require Internet connectivity? Most users on a smartphone/tablet use apps Vs a browser. While the apps use HTTP/HTTPS extensively, it is not possible to redirect to a captive portal and display that page. Will the WG address this aspect as well? -Raj --001a114a7d20d701f6052dc856c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Detecting a captive portal and redirecting = a browser to a specific page is one aspect.
But does the WG intend to a= lso address the issue of apps that require Internet connectivity?
Most users on a smartphone/tablet use apps Vs a browser.=C2=A0
W= hile the apps use HTTP/HTTPS extensively, it is not possible to redirect to= a captive portal and display that page.=C2=A0

Wil= l the WG address this aspect as well?

-Raj

--001a114a7d20d701f6052dc856c3-- From nobody Sun Mar 13 01:52:27 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1592512D56D for ; Sun, 13 Mar 2016 01:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 pdDtDe0JcwIm for ; Sun, 13 Mar 2016 01:52:24 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 2932812D564 for ; Sun, 13 Mar 2016 01:52:24 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id g127so136870679ywf.2 for ; Sun, 13 Mar 2016 01:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4tKeQyOqbkQUlC5YaGi3MpPqmj2XDdHSFPcJVZfnq/U=; b=1u675A7Teg9KIX91DhJ7Klvk2Q7yPBi9zeW612vtbp2o1xj9DO9FAYpgYkb7dVMo7X uhszKxif+1X4/N+SN8sf/OXO2CQGVYd9pqvuX/+6r81cyepuGeTXqvuFFWMLL1lj6wyb d/IyiJkZewdcgt9Un4ofmgfh/CyCah6d908VMel8Wh8s/EVxHbIPVM9CJidKs5lAHZIg EFFml+rEW22CyNZCXTX1kLa4tpdvp6tuQe8W8q29uRwbWm0yN2aWVKAV55eWKQMQY98F Ugox5dka4qeZ3IHxyIwMdfEjs25auAusMSmxcYCvy9ZI+kPYjvSCa4aKY0BTOVqHA13B hStw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4tKeQyOqbkQUlC5YaGi3MpPqmj2XDdHSFPcJVZfnq/U=; b=az+1pALYhqAh3gvU7m9lgnOG1yyt8g2Xzo7hle7hD70OgSl1k2lo2BC35AyV6EFKkH BAUnKvku7LL4+CwxuUMwtDiUlsca/yK6a1wCBHRjFKxoMPSPfhNwwzTuXuW3fgU8q5VL s4UPzzVZNNtxl+XMJ9P0/4w1Ts40DDFcbHc9rfJmsKcSgjVJvrmmtsZ+4Xui7N/rx0tC 2hb9IUjlNhff/BXxL4cFidVech64hSILDBz/Q/lyNbO7mSzG8k5TXHq+FZn4j6MjdbbD qeg0oIOQlX9UMVaC3+iDXeCyWhAEJmh1MKoT0WQtLcWmDPcawg8NlESS3djTWyabf1Xj PK7g== X-Gm-Message-State: AD7BkJL7MzgTTvv1jxz2t9dj6kF8ud0evcNVe4L1fmcf/JCCVaevgiBSNGimyjkD1AP33XxRbdpY1RfKZjFGkMg0 X-Received: by 10.37.103.138 with SMTP id b132mr566677ybc.174.1457862743355; Sun, 13 Mar 2016 01:52:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Sun, 13 Mar 2016 09:52:13 +0000 Message-ID: To: Basavaraj Patil , captive-portals@ietf.org Content-Type: multipart/alternative; boundary=001a1142f7aef32731052deb1e7a Archived-At: Subject: Re: [Captive-portals] Scope question X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 09:52:26 -0000 --001a1142f7aef32731052deb1e7a Content-Type: text/plain; charset=UTF-8 On Sat, Mar 12, 2016 at 12:22 AM Basavaraj Patil wrote: > > Detecting a captive portal and redirecting a browser to a specific page is > one aspect. > But does the WG intend to also address the issue of apps that require > Internet connectivity? > Most users on a smartphone/tablet use apps Vs a browser. > While the apps use HTTP/HTTPS extensively, it is not possible to redirect > to a captive portal and display that page. > > Will the WG address this aspect as well? > Yes and no. This isn't really "redirecting the browser to a specific page", it is more like "telling the *device* that it needs to contact a specific page. Presumably the device will then open a browser (perhaps a special one) and connect that to the page" -- if you've used a recent Android or iOS, you've probably seen something like this behavior already. On a related note: Initially, the working group will focus on simplifying captive portal interactions where a user is present. A secondary goal is to look at the problem posed to or by devices that have little or no recourse to human interaction. W > > -Raj > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > --001a1142f7aef32731052deb1e7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat= , Mar 12, 2016 at 12:22 AM Basavaraj Patil <bpatil1@gmail.com> wrote:

Detecting a captive portal and redir= ecting a browser to a specific page is one aspect.
But does the WG inte= nd to also address the issue of apps that require Internet connectivity?
Most users on a smartphone/tablet use apps Vs a browser.=C2=A0
While the apps use HTTP/HTTPS extensively, it is not possible to redi= rect to a captive portal and display that page.=C2=A0

<= div>Will the WG address this aspect as well?
<= br>
Yes and no.

This isn't really &q= uot;redirecting the browser to a specific page", it is more like "= ;telling the *device* that it needs to contact a specific page. Presumably = the device will then open a browser (perhaps a special one) and connect tha= t to the page" -- if you've used a recent Android or iOS, you'= ve probably seen something like this behavior already.

=
On a related note:
Initially, the working group will focus on simplify= ing captive portal
interactions where a user is present. A secondary goal is to look at the=
problem posed t= o or by devices that have little or no recourse to human
interaction.
=

-Raj

_______________________________________________
Captive-portals mailing list
Captive-porta= ls@ietf.org
https://www.ietf.org/mailman/listinfo/captive-p= ortals
--001a1142f7aef32731052deb1e7a-- From nobody Sun Mar 13 19:37:32 2016 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C9E12D913 for ; Sun, 13 Mar 2016 19:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 mX7419aykOE0 for ; Sun, 13 Mar 2016 19:37:29 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 067AF12D911 for ; Sun, 13 Mar 2016 19:37:28 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id d65so152019597ywb.0 for ; Sun, 13 Mar 2016 19:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=dQQFJ8RnJejFFeCKYpQPQTToolPJc8Ehv6Nz0kqLWro=; b=aP8g36yw0400Ue1mFYIdf64T4k7LVSisGAu721JB8twgX+o3jNqTlsCyT0vUE1d2dr FkFHOIxBl6phd978ld/MTcv1QY9anjtjwYdK5gJdtQTjLjdOimdtH+YGVZ+CB+Ez8d7U X5WZCpYZqcZoC/vvEfdOlCGxKiUSkNZ1HhnI/6OsnmQV3OYPdM5Q4nXhtqf0H83U1Zl/ zwYhl201eAjNDKCYgEtM+OObvkK6WbzzsCp0LmC2zAobSPrQLUCVHg7ZjJh1fwHjr5BP 9iZp/0CENoT2hotNpMYmrVSWnaMDok4oj+LS/ysvNzRgsBWpFbnndXE5JCQoEIk4JrM7 7Sdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dQQFJ8RnJejFFeCKYpQPQTToolPJc8Ehv6Nz0kqLWro=; b=NJYZNmjrsABbkJj1eHN3NJ/gEodkBujYCyriaj+FBzXYI200paNcfmZ77w5dEjvkeo NN9cnKIULvNvS/9nGKHwFXyS+Oy99kDdMtcReww94h9FY4JlOweqNJXWSj02sxw+32St RR1z2lPZNDiBOTzwbTEqH7N1IjnTDWS7gC20JUNryzX2OYGF807BZy2ho1egHPk+fPl8 00hig9qhkOJR8NvbIbT2cofA3krBpYK0HjZI4aDeVOc/4qE3VfZUBGw8zk9kAhuTUXxn kla6HpnFTsraCY5lfSVO9V2WSToZE4C0ZJEmpZvNG7qoUNnv9mt2ESjRFn60QjnmWHve oYdA== X-Gm-Message-State: AD7BkJLtXt/bXuQEdr+JUYYJqEsPi5rh+cw5U82CUrk/inuWfwWGpp/iG8usztjprdDUaXrEdW2J3sGtQ1xSs7qB X-Received: by 10.13.210.67 with SMTP id u64mr10696156ywd.42.1457923048213; Sun, 13 Mar 2016 19:37:28 -0700 (PDT) MIME-Version: 1.0 From: Warren Kumari Date: Mon, 14 Mar 2016 02:37:18 +0000 Message-ID: To: "captive-portals@ietf.org" Content-Type: multipart/alternative; boundary=001a114e7e3066416f052df92946 Archived-At: Subject: [Captive-portals] Agenda requests - CAPPORT @ IETF 95 in BA. X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 02:37:30 -0000 --001a114e7e3066416f052df92946 Content-Type: text/plain; charset=UTF-8 Hi there all, We still have space on the agenda. Please let us know if you'd like some time.... W --001a114e7e3066416f052df92946 Content-Type: text/html; charset=UTF-8
Hi there all,

We still have space on the agenda. Please let us know if you'd like some time....

W
--001a114e7e3066416f052df92946--