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

[Dave Dolson <[e-mail]>]

Regarding the AP/client identification, this is the reason I suggested in an earlier email,
https://mailarchive.ietf.org/arch/msg/captive-portals/RPwEIuLlW6ZSLmEyaqfxgDrF88Q

"
Posting to the create_href:
POST http://<server>/capport/sessions (Accept: application/json)
{ "identity": "<USERNAME>"}

…

The USERNAME could be DHCP option-12 value or MAC address or ?
"

I didn’t know exactly what this identity should be. Maybe multiple identity options are useful.

-Dave


From: Captive-portals [mailto:[e-mail]] On Behalf Of David Bird
Sent: Tuesday, April 18, 2017 1:09 PM
To: James Wood
Cc: [e-mail]
Subject: Re: [Captive-portals] A view from a WiFi provider on captive portal requirements, challenges and improvements

Welcome and thanks for the input James!

Comments in-line.


On Tue, Apr 18, 2017 at 8:21 AM, James Wood <[e-mail]<mailto:[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<http://facebook.com>, akamaihd.net<http://akamaihd.net> and connect.facebook.net<http://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<http://%3cNAS-IP%3e/redirect> which the NAS responds to with a redirect to https://<real-portal-domain>/<https://%3creal-portal-domain%3e/>... 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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/captive-portals