idnits 2.17.1 draft-nottingham-capport-problem-01.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.) 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 (April 4, 2016) is 2937 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 261 -- Looks like a reference, but probably isn't: '5' on line 263 -- Looks like a reference, but probably isn't: '6' on line 202 -- Looks like a reference, but probably isn't: '7' on line 205 -- Looks like a reference, but probably isn't: '1' on line 253 -- Looks like a reference, but probably isn't: '2' on line 255 -- Looks like a reference, but probably isn't: '3' on line 258 -- Looks like a reference, but probably isn't: '8' on line 268 Summary: 1 error (**), 0 flaws (~~), 2 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 April 4, 2016 4 Intended status: Informational 5 Expires: October 6, 2016 7 Captive Portals Problem Statement 8 draft-nottingham-capport-problem-01 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 October 6, 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 and Networks . . . . . . . . . . . . 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 . . . . . . . . . . 5 67 4.1. Issues Caused by Defeating Captive Portal Detection . . . 5 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 6.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 and Networks 89 A "_captive network_" is a network that employs a captive portal for 90 a variety of purposes; see Section 2.1. A "_captive portal_" is a 91 Web site that captive networks direct users to. 93 This is achieved by directing requests for "normal" Web access to the 94 captive portal, through variety of techniques, including DNS 95 poisoning, TCP interception, HTTP response modification and/or HTTP 96 redirection. 98 Once the captive network's goals are met, the network "remembers" 99 that the user is allowed network access, usually by MAC address, 100 although there is a significant amount of variance between 101 implementations. 103 Over time, operating systems have developed "_captive portal 104 detection_" processes to discover captive networks, and to assist 105 users through the process of obtaining full network access. They 106 often involve specialised "_captive portal browsers_" which only 107 allow the captive portal to use a subset of the full capabilities of 108 a Web browser, and have a different user experience. 110 2.1. Why Captive Portals Are Used 112 Captive portals are deployed in a variety of situations, but the most 113 common motivations are: 115 o *Authentication* - Obtaining user credentials before authorising 116 network access 118 o *Payment* - Obtaining payment for using the network. 120 o *Information* - Presenting information to the user. This might 121 include displaying legal notices, details about the network 122 provider and/or its location, advertisements, policies, etc., and 123 obtaining user consent. 125 o *Notifications* - Some networks use the same mechanisms as captive 126 portals to notify users of account status, network downtime, 127 emergency alerts, etc. See [RFC6108] for an example of one way 128 this is done. 130 In all of these cases, using a Web browser is attractive, because it 131 gives the network the ability to tailor the user's interface and 132 experience, as well as the ability to integrate third-party payment, 133 advertising, authentication and other services. 135 3. Issues Caused by Captive Portals 137 When a network imposes a captive portal, it can cause a variety of 138 issues, both for applications and end users. 140 o *False Negatives* - Because so many different heuristics are used 141 to detect a captive portal, it's common for an OS or browser to 142 think it's on an open network, when in fact there is a captive 143 portal [4] in place. 145 o *Longevity* - Often, it's necessary to repeatedly log into a 146 captive portal [5], thanks to timeout issues. The effects of this 147 range from annoyance to inability to complete tasks, depending on 148 the timeout and the task at hand. 150 o *Interoperability Issues* - Captive portals often depend on 151 specific operating system and browser capabilities and behaviours. 152 Client systems that do not share those quirks often have 153 difficulty connecting to captive portals. 155 o *Confusion* - Because captive portals are effectively a man-in- 156 the-middle attack, they can confuse users as well as user agents 157 (e.g., caches). For example, when the portal's TLS certificate 158 doesn't match that of the requested site, or the captive portal's 159 /favicon.ico gets used as that of the originally requested site. 161 o *DNS*/*DNSSEC* - When portals respond with forged DNS answers, 162 they confuse DNS resolvers and interoperate poorly with host- 163 validating DNSSEC resolvers and applications. 165 o *TLS* - Portals that attempt to intercept TLS sessions (HTTPS, 166 IMAPS, or other) can cause certificate error messages on clients, 167 encouraging bad practice to click through such errors. 169 o *Unexpected Configuration* - Some captive portals do not work with 170 clients using unexpected configurations, for example clients using 171 static IP, custom DNS servers, or HTTP proxies. 173 o *Stealing Access* - because captive portals often associate a user 174 with a MAC address, it is possible for an attacker to impersonate 175 an authenticated client (e.g., one that has paid for Internet 176 access). Note that this is specific to open Wifi, and can be 177 prevented by using a secure wireless medium. However, 178 configuration of secure wireless is often deemed to be too complex 179 for captive networks. 181 o *Non-Browser Clients* - It is becoming more common for Internet 182 devices without the ability to run a browser to be used, thanks to 183 the "Internet of Things." These devices cannot easily use most 184 networks that interpose a captive portal. 186 o *Connectivity Interruption* - For a device with multiple network 187 interfaces (e.g., cellular and WiFi), connecting to a network can 188 require dropping access to alternative network interfaces. If 189 such a device connects to a network with a captive portal, it can 190 lose network connectivity until the captive portal requirements 191 are satisfied. 193 4. Issues Caused by Captive Portal Detection 195 Many operating systems attempt to detect when they are on a captive 196 network. Detection aims to minimize the negative effects caused by 197 interposition of captive portals, but can cause different issues, 198 including: 200 o *False Positives* - Some networks don't use a Web browser 201 interface to log in; e.g., they require a VPN to access the 202 network [6], so captive portal detection relying on HTTP is 203 counterproductive. 205 o *Non-Internet Networks* - Some applications [7] and/or networks 206 don't assume Internet access, but captive portal detection often 207 conflates "network access" with "Internet access". 209 o *Sandboxing* - When a captive portal is detected, some operating 210 systems access the captive portal in a highly sandboxed captive 211 portal browser. This might have reduced capabilities, such as 212 limited access to browser APIs. In addition, this environment is 213 separate from a user's normal browsing environment and therefore 214 does not include state. While sandboxing seems a good idea to 215 protect user data (particularly on Open WiFi), it is implemented 216 differently on various platforms and often causes a (severely) 217 broken user experience on the captive portal (even when the 218 operator is protecting user data end-to-end with HTTPS). To offer 219 a consistent and rich experience on the captive portal, some 220 operators actively try to defeat operating system captive portal 221 detection. 223 4.1. Issues Caused by Defeating Captive Portal Detection 225 Many captive portal devices provide optional mechanisms that aim to 226 defeat captive portal detection. 228 Such defeat mechanisms aim to avoid the problems caused by captive 229 portal detection (see Section 4), with the consequence that they also 230 cause the same problems that detection was intended to avoid (see 231 Section 3). 233 5. Security Considerations 235 TBD 237 6. References 239 6.1. Normative References 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 243 RFC2119, March 1997, 244 . 246 [RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. 247 Van Lieu, "Comcast's Web Notification System Design", RFC 248 6108, DOI 10.17487/RFC6108, February 2011, 249 . 251 6.2. URIs 253 [1] https://discussions.apple.com/thread/6251349 255 [2] https://community.aerohive.com/aerohive/topics/ 256 ios_7_captive_portal_issues 258 [3] http://stackoverflow.com/questions/14606131/using-captive- 259 network-assistant-on-macosx-to-connect-to-vpn 261 [4] http://forum.piratebox.cc/read.php?9,8879 263 [5] https://github.com/httpwg/wiki/wiki/Captive-Portals 265 Appendix A. Acknowledgements 267 This draft was seeded from the HTTP Working Group Wiki Page on 268 Captive Portals [8]; thanks to all who contributed there. 270 Thanks to Martin Thomson, Yaron Sheffer, David Bird and Jason 271 Livingood for their suggestions. 273 Author's Address 275 Mark Nottingham 277 Email: mnot@mnot.net 278 URI: https://www.mnot.net/