Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

David Bird <dbird@google.com> Fri, 03 July 2020 21:52 UTC

Return-Path: <dbird@google.com>
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 745EF3A083D for <captive-portals@ietfa.amsl.com>; Fri, 3 Jul 2020 14:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 H0ZvrzC2k4iM for <captive-portals@ietfa.amsl.com>; Fri, 3 Jul 2020 14:52:55 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 8151A3A082F for <captive-portals@ietf.org>; Fri, 3 Jul 2020 14:52:55 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id t27so23371980ill.9 for <captive-portals@ietf.org>; Fri, 03 Jul 2020 14:52:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gTppIM44aL4UEdPtGZu8iuorSkw0mnt7cylapfxQYuY=; b=JW8HpR+1nVaOO3N/0pwtReKzT1wRGUb6hL7+LhS9Q23bPGd5Aodc1SdvvdBAmjEhED K4yURYubhSKchJ/LP8aPe7Du8yOcvAkkKnE2CS56cavVp8SVpx4Aa9RjYH8M9Ovdu1Yq Ru/pAqiegrjRu8gY+axxxmCP834PCJ1FZbmQEFONcKVDG3QcuOjhQ3+cOPhSDD7D8jKo LbQWZMtE7+v8S9oc8TqDlA67TJWDASq2LVVJGA/V2vojn9Z8FP7+RN5e1OumQGtvYAQb xXztTdgWgNs0qSUU9FyaV+1u54PFB5qhrAbpeVkogJMDIIy7F1IwxY+cMSyVcDnPlE2u vuGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gTppIM44aL4UEdPtGZu8iuorSkw0mnt7cylapfxQYuY=; b=lOeRfCOGVm/eLhstKq9yblwcrT+CrFam80QcVntWPIUs+/OfqzP3NPWNAzkSaHpabU 43yFJawdBmgcGf1S8gdnyF3AJpMrkxGE3P4gWe5Ndm7e4fT+l2HMKQBN2xhWA9CdADBd NzpI6S1CgUd8nl01S+fJKfuDmniDY0N7a3hijMSD8lHMdxk05S3SHym6xntklMwxlaDW peQdH0Yd7+dN3OiCbZTd9J/GaJ+0ZJVud/ZYnfmfMWHhesZdh/hoEAxS4WSy43cQxJIO c7/XhzpIAbpWZ/Uk80VG3hfDrIDn/usIwCa0c6xar1VcygUedAW5147cEHLsIJm1Sn68 69SA==
X-Gm-Message-State: AOAM533qJokNRzTniFA2j6BHFo5fbf7V8vOWci+aV9U7xHIN57lH1DRd O33U+nsf6n9YpTOS3dvbG0GW+CKXhWh/uUfsDeFiQg==
X-Google-Smtp-Source: ABdhPJwLIHHtzY6s8Vmhv5X5e2fq+Hv/zfRLU9xweRPeBY4xmlPlPQb2hNMyzUySdid703oQFvilwalB9ZICB8s+UPM=
X-Received: by 2002:a92:8b0e:: with SMTP id i14mr18733444ild.307.1593813174294; Fri, 03 Jul 2020 14:52:54 -0700 (PDT)
MIME-Version: 1.0
References: <CADo9JyUVZfRSpmjYLxBBH73hd7F-+1hwSbr2qDzriaQjLndmFA@mail.gmail.com> <4E013237-9B3C-426B-961A-878EDFCE4806@apple.com> <CADo9JyWD6=hXtB8RURYtgc_xQhZvO+=iWfJr6zauZ1OtzExOrA@mail.gmail.com> <D41B4C9B-C23B-4357-BCD7-BCC520F6B4A4@boaz.org.uk> <CADo9JyWNvNXrFQ3uMb4eZ4OJMieSYKYwP2Yod-A2zOhx68VAeA@mail.gmail.com> <6F344EAD-88F4-4004-92AB-1F60E3D94D48@boaz.org.uk> <CAMGpriXsKQQkF--KuywXTM7NcmWYi1oO+vG=jCks3P80eGv8zQ@mail.gmail.com>
In-Reply-To: <CAMGpriXsKQQkF--KuywXTM7NcmWYi1oO+vG=jCks3P80eGv8zQ@mail.gmail.com>
From: David Bird <dbird@google.com>
Date: Fri, 3 Jul 2020 14:52:43 -0700
Message-ID: <CADo9JyXOWR5Gm62CVqAOxbZMLy5YRcO+_8LCK2PMh2qX4k=iYQ@mail.gmail.com>
To: Erik Kline <ek.ietf@gmail.com>
Cc: Steve Haskew <steve@boaz.org.uk>, captive-portals <captive-portals@ietf.org>, Tommy Pauly <tpauly@apple.com>
Content-Type: multipart/alternative; boundary="00000000000017fe9a05a9908c51"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/fK_UoRO9_wDFfBMbm3X4b72V9c0>
Subject: Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jul 2020 21:53:00 -0000

As an individual design decision, I agree... Just that the protocol spec
does not attempt at requiring this...
Also has deployment issues as each enforcement device now needs the
"operator" SSL certificate.

On Fri, Jul 3, 2020 at 1:33 PM Erik Kline <ek.ietf@gmail.com> wrote:

> The enforcement device and the API endpoint can be the same device, if you
> like.
>
> On Fri, Jul 3, 2020 at 9:37 AM Steve Haskew <steve@boaz.org.uk> wrote:
> >
> > David,
> >
> > This is a very good observation - and one that we have had to consider
> in our implementation. The source of the captive status needs to be
> reliable and quick enough to achieve the flow described in section 6
> (Example Interaction):
> >
> > "Once the user satisfies the requirements for external network access,
> the client SHOULD query the API server again to verify that it is no longer
> captive.”.
> >
> > For us, the API saying the user is online but the enforcement device
> still blocking them would be a major support headache, but could be caused
> by a number of different scenarios. This sentence was key in making us seek
> a robust solution to that possibility.
> >
> > Thanks,
> >
> > Steve
> >
> >
> > On 3 Jul 2020, at 17:23, David Bird <dbird=40google.com@dmarc.ietf.org>
> wrote:
> >
> > Thanks Steve, I have no doubt that some operators will implement this
> very well! :-)
> >
> > Indeed, the login flow is the same through the Portal via API (assuming
> you figure out the "unique device identity" question).. and I'm sure you'll
> have the API server fully integrated with your AAA so that all sorts of
> logout events are handled (e.g. NAS restart, idle timeout, etc).
> >
> > In the long-tale of public access, I believe users will experience a
> wide range of networks, with various levels of integration. My concern is
> more that users learn (or even told by venue staff) to disable CAPPORT
> support if they find it often "wrong" (e.g. there is a CAPPORT API but no
> NAS enforcement; API says you are logged in, but NAS is
> dropping/redirecting; etc)...
> >
> > [I personally believe we missed an opportunity to make a more robust
> protocol by directly involving the NAS (for notification of captivity),
> providing a single source of truth...]
> >
> > On Fri, Jul 3, 2020 at 7:13 AM Steve Haskew <steve@boaz.org.uk> wrote:
> >>
> >> Hi David, Tommy, all,
> >>
> >> Just to add the the discussion, from the perspective of a network
> operator! We are just implementing and going to be testing this very soon.
> We don’t see any issues in terms of policy application, because the final
> step to log the user in will be the same with either approach. Actually,
> this provides a really nice route for us to resolve the ever-increasing
> issue of the ugliness of forcing redirects, especially with the decreasing
> use of plain HTTP (and therefore causing SSL warnings). We can only hope
> that other vendors roll this out soon too! I see it as a big step forward.
> >>
> >> However, the challenge for us that is linked revolves around identity.
> MAC Randomisation (also coming in iOS 14)  is great for privacy, but in the
> short term is poor for user experience on any form of guest wifi,
> particularly for longer stays (e.g. hotel, vs cafe). We’ve actually seen a
> deterioration of support for Hotspot2.0/Passpoint, in that installation of
> a profile from within the Captive Network Assistant on iOS no longer works.
> >>
> >> It feels like the dichotomy of privacy vs user experience here has no
> practical solutions - could this be something that the wider WG has
> previously considered, and is it within the remit of the group to look at?
> >>
> >> Thanks,
> >>
> >> Steve Haskew
> >>
> >>
> >> On 3 Jul 2020, at 14:23, David Bird <dbird=40google.com@dmarc.ietf.org>
> wrote:
> >>
> >> Thanks Tommy,
> >>
> >> Might you have screenshots of the user experience ? I'd be interested
> to see it....
> >>
> >> Agreed, adopting the new CAPPORT spec is very easy to setup (just a
> DHCP server config change at the access point, and an API/Portal server on
> the Internet). The complexity for network operators comes when fully
> integrating this new "application" method of captive portaling with
> existing "network" (NAS/redirect) methods. The complexity is in ensuring
> the NAS and API are enforcing the same policies, for all kinds of users
> (roaming, paid, free, etc) ... if the network operator doesn't do this
> well, or at all, then the complexity is shifted to client device support,
> answering questions like "Why does the WiFi at airport X not work only for
> new devices?". For this reason, I believe you will eventually start probing
> for redirects again...
> >>
> >> You may trust the API, but you may also want to verify.... :)
> >>
> >>
> >> On Thu, Jul 2, 2020 at 7:24 AM Tommy Pauly <tpauly@apple.com> wrote:
> >>>
> >>> Hi David,
> >>>
> >>> One point I wanted to clarify: the iOS and macOS betas support for
> CAPPORT discovery and APIs still goes through the standard and existing UI
> flow for captive portals. The times in which the captive portal UI is shown
> is limited, for example to times when the user is in WiFi settings. Thus,
> while adoption should indeed be easy and only require adding a small bit of
> infrastructure in order to provide a flow that doesn’t require redirects,
> the set of circumstances in which a network can display content to the user
> is not increased.
> >>>
> >>> Thanks,
> >>> Tommy
> >>>
> >>> On Jul 1, 2020, at 5:27 PM, David Bird <dbird@google.com> wrote:
> >>>
> >>> 
> >>> That's pretty cool!
> >>>
> >>> This will give new opportunities in monetizing WiFi for new iOS and
> macOS devices with only a DHCP server change and an API server!
> >>>
> >>> On Wed, Jul 1, 2020 at 4:22 PM Erik Kline <ek.ietf@gmail.com> wrote:
> >>>>
> >>>> +1
> >>>>
> >>>> Out of curiosity, does the implementation handle the 7710bis options'
> >>>> urn:ietf:params:capport:unrestricted value?
> >>>>
> >>>> On Mon, Jun 22, 2020 at 5:00 PM Martin Thomson <mt@lowentropy.net>
> wrote:
> >>>> >
> >>>> > Tommy, this is great!  Thanks for all your work here, it's good to
> see this turn into something concrete.
> >>>> >
> >>>> > On Tue, Jun 23, 2020, at 07:30, Tommy Pauly wrote:
> >>>> > > Hello CAPPORT,
> >>>> > >
> >>>> > > I wanted to highlight an announcement we’ve made for the betas of
> iOS
> >>>> > > and macOS released today:
> >>>> > >
> >>>> > > How to modernize your captive network
> >>>> > > <https://developer.apple.com/news/?id=q78sq5rv>
> >>>> > >
> >>>> > > The betas for iOS and macOS support both
> draft-ietf-capport-rfc7710bis
> >>>> > > and draft-ietf-capport-api by default. This doesn’t change the
> user
> >>>> > > experience of logging onto captive networks, but the system will
> >>>> > > request the DHCP options and handle the RA option, and will prefer
> >>>> > > using the Captive Portal API Server interaction over having a
> probe
> >>>> > > that is intercepted.
> >>>> > >
> >>>> > > If you have a portal system that is already implementing the
> CAPPORT
> >>>> > > features, please test out these betas and let us know if you see
> any
> >>>> > > issues! And if you have a captive portal solution, we’d encourage
> you
> >>>> > > to start supporting this soon.
> >>>> > >
> >>>> > > Best,
> >>>> > > Tommy
> >>>> > > _______________________________________________
> >>>> > > Captive-portals mailing list
> >>>> > > Captive-portals@ietf.org
> >>>> > > https://www.ietf.org/mailman/listinfo/captive-portals
> >>>> > >
> >>>> >
> >>>> > _______________________________________________
> >>>> > Captive-portals mailing list
> >>>> > Captive-portals@ietf.org
> >>>> > https://www.ietf.org/mailman/listinfo/captive-portals
> >>>>
> >>>> _______________________________________________
> >>>> Captive-portals mailing list
> >>>> Captive-portals@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/captive-portals
> >>
> >> _______________________________________________
> >> Captive-portals mailing list
> >> Captive-portals@ietf.org
> >> https://www.ietf.org/mailman/listinfo/captive-portals
> >>
> >>
> >> _______________________________________________
> >> Captive-portals mailing list
> >> Captive-portals@ietf.org
> >> https://www.ietf.org/mailman/listinfo/captive-portals
> >
> > _______________________________________________
> > Captive-portals mailing list
> > Captive-portals@ietf.org
> > https://www.ietf.org/mailman/listinfo/captive-portals
> >
> >
> > _______________________________________________
> > Captive-portals mailing list
> > Captive-portals@ietf.org
> > https://www.ietf.org/mailman/listinfo/captive-portals
>