idnits 2.17.1 draft-nottingham-capport-problem-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 15, 2016) is 2987 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '4' on line 245 -- Looks like a reference, but probably isn't: '5' on line 247 -- Looks like a reference, but probably isn't: '6' on line 198 -- Looks like a reference, but probably isn't: '7' on line 201 -- Looks like a reference, but probably isn't: '1' on line 237 -- Looks like a reference, but probably isn't: '2' on line 239 -- Looks like a reference, but probably isn't: '3' on line 242 -- Looks like a reference, but probably isn't: '8' on line 252 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft February 15, 2016 4 Intended status: Informational 5 Expires: August 18, 2016 7 Before You Log In, Here's A Brief Message From Our Sponsors! 8 draft-nottingham-capport-problem-00 10 Abstract 12 This draft attempts to establish a problem statement for "Captive 13 Portals", in order to inform discussions of improving their 14 operation. 16 Note to Readers 18 The issues list for this draft can be found at 19 https://github.com/mnot/I-D/labels/capport-problem . 21 The most recent (often, unpublished) draft is at 22 https://mnot.github.io/I-D/capport-problem/ . 24 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 25 pages/capport-problem . 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 18, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 63 2. Defining Captive Portals . . . . . . . . . . . . . . . . . . 2 64 2.1. Why Captive Portals Are Used . . . . . . . . . . . . . . 3 65 3. Issues Caused by Captive Portals . . . . . . . . . . . . . . 3 66 4. Issues Caused by Captive Portal Detection . . . . . . . . . . 4 67 4.1. Issues Caused by Defeating Captive Portal Detection . . . 5 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 71 6.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 This draft attempts to establish a problem statement for "Captive 78 Portals", in order to inform discussions of improving their 79 operation. 81 1.1. Notational Conventions 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Defining Captive Portals 89 A captive portal is a mechanism whereby a network requires a user to 90 interact with a specific Web site before allowing broader (but not 91 necessarily complete) Internet access. 93 This is achieved by directing requests for "normal" Web access to the 94 nominated server, through variety of techniques, including DNS 95 poisoning, TCP interception, and/or HTTP redirection. 97 Once the captive portal's goals (see below) are met, the network 98 "remembers" that the user is allowed network access, usually by MAC 99 address. 101 2.1. Why Captive Portals Are Used 103 Captive portals are deployed in a variety of situations, but the most 104 common motivations are: 106 o *Authentication* - Obtaining user credentials before authorising 107 network access 109 o *Payment* - Obtaining payment for using the network. 111 o *Information* - Presenting information to the user. This might 112 include legal notices, details about the network provider and/or 113 its location, advertisements, etc. 115 o *Notifications* - Some networks use the same mechanisms as captive 116 portals to notify users of account status, network downtime, 117 emergency alerts, etc. 119 In all of these cases, using a Web browser is attractive, because it 120 gives the network the ability to tailor the user's interface and 121 experience, as well as the ability to integrate third-party payment, 122 advertising, authentication and other services. 124 3. Issues Caused by Captive Portals 126 When a network imposes a captive portal, it can cause a variety of 127 issues, both for applications and end users. 129 o *False Negatives* - Because so many different heuristics are used 130 to detect a captive portal, it's common for an OS or browser to 131 think it's on an open network, when in fact there is a captive 132 portal [4] in place. 134 o *Longevity* - Often, it's necessary to repeatedly log into a 135 captive portal [5], thanks to timeout issues. The effects of this 136 range from annoyance to inability to complete tasks, depending on 137 the timeout and the task at hand. 139 o *Interoperability Issues* - Captive portals often depend on 140 specific operating system and browser capabilities and behaviours. 141 Client systems that do not share those quirks often have 142 difficulty connecting to captive portals. 144 o *Confusion* - Because captive portals are effectively a man-in- 145 the-middle attack, they can confuse users as well as user agents 146 (e.g., caches). For example, when the portal's TLS certificate 147 doesn't match that of the requested site, or the captive portal's 148 /favicon.ico gets used as that of the originally requested site. 150 o *DNS*/*DNSSEC* - When portals respond with forged DNS answers, 151 they confuse DNS resolvers and interoperate poorly with host- 152 validating DNSSEC resolvers and applications. 154 o *TLS* - Portals that attempt to intercept TLS sessions (HTTPS, 155 IMAPS, or other) can cause certificate error messages on clients, 156 encouraging bad practice to click through such errors. 158 o *Unexpected Configuration* - Some captive portals rely upon DNS 159 interception to direct users to the portal; however, this doesn't 160 work when the user has configured their own DNS server in 161 preference to that provided by DHCP (e.g., 8.8.8.8). 163 o *Stealing Access* - because captive portals most often associate a 164 user with a MAC address, it is possible for an attacker to 165 impersonate an authenticated client (e.g., one that has paid for 166 Internet access). 168 o *Access to Privileged Information* - Some captive portals want to 169 utilise external information about the user, such as social media 170 account logins and/or advertising tracking/targeting services. 171 However, because the captive portal is effectively acting as a 172 man-in-the-middle, providing these capabilities can put the user 173 at risk. 175 o *Non-Browser Clients* - It is becoming more common for Internet 176 devices without the ability to run a browser to be used, thanks to 177 the "Internet of Things." These devices cannot easily use most 178 networks that interpose a captive portal. 180 o *Connectivity Interruption* - For a device with multiple network 181 interfaces (e.g., cellular and WiFi), connecting to a network can 182 require dropping access to alternative network interfaces. If 183 such a device connects to a network with a captive portal, it 184 loses network connectivity until the captive portal requirements 185 are satisfied. 187 4. Issues Caused by Captive Portal Detection 189 Many operating systems attempt to detect when they are on a captive 190 network. Detection aims to minimize the negative effects caused by 191 captive portals in several ways. 193 Captive portal detection can cause issues in some networks; for 194 example: 196 o *False Positives* - Some networks don't use a Web browser 197 interface to log in; e.g., they require a VPN to access the 198 network [6], so captive portal detection relying on HTTP is 199 counterproductive. 201 o *Non-Internet Networks* - Some applications [7] and/or networks 202 don't assume Internet access, but captive portal detection often 203 conflates "network access" with "Internet access". 205 o *Sandboxing* - When a captive portal is detected, some operating 206 systems access the captive portal in a highly sandboxed 207 environment. This might have reduced capabilities, such as 208 limited access to browser APIs. In addition, this environment is 209 separate from a user's normal browsing environment and therefore 210 does not include state. 212 4.1. Issues Caused by Defeating Captive Portal Detection 214 Many captive portal devices provide optional mechanisms that aim to 215 defeat captive portal detection. 217 Such defeat mechanisms aim to avoid the problems caused by captive 218 portal detection (see Section 4), with the consequence that they also 219 cause the same problems that detection was intended to avoid (see 220 Section 3). 222 5. Security Considerations 224 TBD 226 6. References 228 6.1. Normative References 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, 232 DOI 10.17487/RFC2119, March 1997, 233 . 235 6.2. URIs 237 [1] https://discussions.apple.com/thread/6251349 239 [2] https://community.aerohive.com/aerohive/topics/ 240 ios_7_captive_portal_issues 242 [3] http://stackoverflow.com/questions/14606131/using-captive- 243 network-assistant-on-macosx-to-connect-to-vpn 245 [4] http://forum.piratebox.cc/read.php?9,8879 247 [5] https://github.com/httpwg/wiki/wiki/Captive-Portals 249 Appendix A. Acknowledgements 251 This draft was seeded from the HTTP Working Group Wiki Page on 252 Captive Portals [8]; thanks to all who contributed there. 254 Thanks to Martin Thomson for his suggestions. 256 Author's Address 258 Mark Nottingham 260 Email: mnot@mnot.net 261 URI: https://www.mnot.net/