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

[Mark Nottingham <[e-mail]>]

Hi David,

Thanks for the feedback. Some responses below, and changes at:
  https://github.com/mnot/I-D/commit/165bc6744e04380757d


> On 7 Mar 2016, at 1:03 PM, David Bird <[e-mail]> wrote:
> 
> 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."

I *think* we can get away with defining just "captive portal" and "captive network" for now; see rewrite.


> 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))

Done.


> 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.

I've added:

"""
Note that this is specific to open Wifi, and can be prevented by using a secure wireless medium. However, configuration of secure wireless is often deemed to be too complex for captive networks.
"""



> 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?

I've seen CPs that ask for Facebook username and password, but NOT over HTTPS, and not to a Facebook domain (IIRC); it's more of a user education / security UX problem than anything.

Still, that's probably out of scope here (even if it is scary). I'll remove the section unless someone else wants to keep it.


> 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. 

Fixed.


> 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: ..."

Done, thanks.


> 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.

Done.


> 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.

Has anyone looked at exactly what the sandbox restrictions are in current OSs?

Thanks again!

--
Mark Nottingham   https://www.mnot.net/