Re: [Captive-portals] A view from a WiFi provider on captive portal requirements, challenges and improvements

[David Bird <[e-mail]>]

Welcome and thanks for the input James!

Comments in-line.


On Tue, Apr 18, 2017 at 8:21 AM, James Wood <[e-mail]>
wrote:

> [snip]
> 1. Security. Nobody prefers to join an open network, but most end up doing
> because that's the way it is. The hype around Hotspot 2.0 came and went as
> that was never really deisgned to help captive portals but rather for
> seamless, non-interaction from the user. As a portal provider, we don't
> want
> that, we want to show a portal even if it's just a 'welcome back, you're
> now
> online' message.
>
>
No doubt, Wi-Fi security is important in public access, but I'd argue
outside the scope of the WG. While captive portals are often used on Open
Wi-Fi, they are not limited to public access (there are LTE use-cases, for
example). Also, security in public access transcends L1 security -- do you
trust any wired LAN you plug into while in public places? HS2.0 (more or
less) solves the public Wi-Fi security problem in that users trust their
providers (albeit to varying degrees) and their providers have a
relationship with the HS2.0 network provider. Even if deployed, this
doesn't address situations where users have no trust relationship with the
network provider and still want Wi-Fi (as most people, they assume Apps are
increasingly using TLS and provide end-to-end security).



> 2. More devices/browers/web servers are defaulting to checking/redirecting
> to a HTTPs URL. As you know, when in a captive portal/walled garden state,
> this will cause a problem because you can't intercept a HTTPs request
> (rightly so!) to a captive portal page without a browser/certificate
> warning. This breaks everything from the end user perspective.
>
>
Yes, we need to fix this! It is disturbing that vendors commonly hijack
https even with the security errors.



> 3. Built-in OS captive popups provide limited browser
> functionality/cookies/etc. When trying to offer login options like
> Facebook,
> it can really affect the user experience when cookies are not permitted or
> other features disabled. The behaviour is also different per device. In
> Android 5.0+, the captive portal window immediately dissappears when the
> user is authenticated. This is a pain for us as we want to display a "you
> are now online" page, or redirect the user to a landing page with
> information etc.
>
>
Very common problems.


> 4. Walled garden. It's a nightmare having to manage lists of domains/IP's
> across all the different vendors kit out there. For example to offer a
> social login through Facebook we need to allow certain domains like
> facebook.com, akamaihd.net and connect.facebook.net etc. This is all
> static
> lists inside an AP/controller, and would be a nightmare to update should
> Facebook change the URLs they send authentication requests throught etc.
> How
> about some way to dynamicly pass back a list of domains as part of the DHCP
> option or some other way to allow the operator to set the required domains
> at time of connection? Or, how about, as part of the capport API, we are
> able to send a list of domains back to the AP, so if someone chooses
> Facebook, we open the Facebook domains for that MAC for a few minutes to
> allow them to login.
>
>
Managing the walled garden configuration is probably also outside the code
of the WG. I don't think we should have any API inform the client directly
of the walled garden as that information could be misleading, or wrong. I
do agree that the real issue is having the walled garden configuration
synchronized with the NAS/AP ... however, vendors do their own proprietary
ways of doing this already.



> Other thoughts...
>
> I had a look at "draft-wkumari-capport-icmp-unreach-02". I note that it
> describes the example URL that could be returned as part of the captive
> portal URL: https://wifi.domain.com/portal?icmp_session=10&policy_
> class=100.
> However, what about the other traditional parameters that a captive portal
> redirect injects? As a minimum, we need the ap_mac, client_mac and
> login_url
> to which we post the login request back to (traditional captive portal
> login
> request). Without such parameters, we cannot identify the venue/ap/client
> and provide the relevant portal splash page and user specific options. I
> may
> have misunderstood this?
>
>
This is an area where I expect discussion. If the DHCP server is integrated
with the NAS, then the RFC7710 URL could contain all the necessary
session-specific query string parameters and the additional parameters are
just added. It is also possible that the RFC7710 URL is something like
http://<NAS-IP>/redirect which the NAS responds to with a redirect to
https://<real-portal-domain>/... with all the necessary parameters. This
becomes implementation specific, but all the information required can be
captured one way or another.



> Does anyone here see Hotspot 2.0 (release 2 or further in particular) and
> OSU as the answer? I don't think I do. It just doesn't seem to help us as a
> provider but instead tries to be around getting the user online as quickly
> and without any interaction. Providers are all for making it easy for users
> to on board, but they need to get something out of it to make it pay.
>
>
I think Hotspot 2.0 has its place and will get deployed... and addresses,
imho, the security of Wi-Fi in public access. It is doing do with security
and "auto-connect" in mind. One issue I think that remains is that post
authentication, HS2.0 doesn't necessarily protect the data-plane on the LAN
or send it back to the operator. I think operators will be selective in
which networks they trust and partner with. I don't think this will replace
captive portals on Open Wi-Fi or elsewhere.



> I am more than willing to take any questions and offer as much insight as I
> can.
>
> Thanks
>
> James
>
>
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals
>