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.
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
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."
*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., 188.8.131.52).
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))
*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
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.
*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
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?
*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
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.