[Captive-portals] Thoughts/comments on draft-nottingham-capport-problem-01

[David Bird <[e-mail]>]

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