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 <[email protected]> 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/ _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
