idnits 2.17.00 (12 Aug 2021) /tmp/idnits55689/draft-wkumari-dhc-capport-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 13, 2014) is 3050 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2939' is mentioned on line 255, but not defined == Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 300, but no explicit reference was found in the text == Outdated reference: draft-ietf-sidr-iana-objects has been published as RFC 6491 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC W. Kumari 3 Internet-Draft Google 4 Intended status: Informational O. Gudmundsson 5 Expires: July 17, 2014 Shinkuro Inc. 6 P. Ebersman 7 Infoblox 8 S. Sheng 9 ICANN 10 January 13, 2014 12 Captive-Portal identification in DHCP 13 draft-wkumari-dhc-capport-00 15 Abstract 17 In many environments (such as hotels, coffee shops and other 18 establishments that offer Internet service to customers) it is common 19 to start new connections in a captive portal mode, i.e. highly 20 restrict what the customer can do until the customer has accepted 21 terms of service, provided payment information or authenticated. 23 This document describes a DHCP option to inform clients that they are 24 behind some sort of captive portal device, and that they will need to 25 authenticate to get Internet Access. 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 July 17, 2014. 44 Copyright Notice 46 Copyright (c) 2014 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. Requirements notation . . . . . . . . . . . . . . . . . . 3 63 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.1. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 3 65 2.2. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 4 66 2.3. IP Hijacking . . . . . . . . . . . . . . . . . . . . . . 4 67 3. The Captive-Portal DHCP Option . . . . . . . . . . . . . . . 4 68 4. Use of the Captive-Portal Option . . . . . . . . . . . . . . 5 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 8.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 In many environments (coffee shops and hotels) users need to connect 81 to a captive portal device and agree to an acceptable use policy or 82 provide billing information before they can access the Internet. 84 In order to present the user with the captive portal web page, many 85 devices perform DNS and / or HTTP and / or IP hijacks. As well as 86 being kludgy hacks, these techniques looks very similar to attacks 87 that DNSSEC and TLS protect against. 89 This document describes a DHCP option (Captive-Portal) that informs 90 DHCP clients that they are behind a captive portal device, and how to 91 contact it. 93 This document neither condones nor condemns captive portals; instead 94 it recognises that they are here to stay, and attempts to improve the 95 user's experience. 97 1.1. Requirements notation 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Background 105 Many Internet Service Providers (ISPs) that offer public Internet 106 access require theuser to first accept an Acceptable Use Policy (AUP) 107 and / or provides billing information (such as their last name and / 108 or room number in a hotel, credit card information, etc) through a 109 web interface. 111 In order to meet this requirement, some ISPs implement a captive 112 portal (CP) - a system that intercepts user requests and redirects 113 them to an interstitial login page. 115 Captive portals intercept and redirects user requests in a number of 116 ways, including: 118 o DNS Redirection 120 o IP Redirection 122 o HTTP Redirection 124 o Restricted scope addresses 126 o Traffic blocking (until the user is authenticated) 128 In order to ensure that the user is unable to access the Internet, 129 captive portals usually implement IP based filters, or place the user 130 in to a restricted VLAN or restricted IP range until after they have 131 been authorized. 133 2.1. DNS Redirection 135 The CP either intercepts all DNS traffic or advertises itself (for 136 example using DHCP) as the recursive server for the network. Until 137 the user has authenticated to the captive portal, the CP responds to 138 all DNS requests listing the address of its web portal. Once the 139 user has authenticated the CP returns the "correct" addresses. 141 This technique has many shortcomings. It fails if the client is 142 performing DNSSEC validation, or if the client already has the DNS 143 information cached. 145 2.2. HTTP Redirection 147 In this implmentation, the CP acts like a transparent HTTP proxy, but 148 when it sees an HTTP request from an unauthenticated client it 149 intercepts the request and responds with an HTTP status code 302 to 150 redirect the client to the Captive Portal Login. 152 The issues with this technique include: 154 o It fails if the user is only using HTTPS 156 o It exposes various private user information, such as HTTP Cookies, 157 etc. 159 o It doesn't work if the client has a VPN and / or proxies their web 160 traffic to an external web proxy. 162 2.3. IP Hijacking 164 In this scenario, the captive portal intercepts connections to any IP 165 address. It spoofs the destination IP address and "pretends" to be 166 whatever the user tried to access. 168 This technique has similar issues as the HTTP solution, but may also 169 break other protocols, and may expose more of the users private 170 information, etc. 172 3. The Captive-Portal DHCP Option 174 The Captive Portal DHCP Option (TBA1) informs the DHCP client that it 175 is behind a captive portal and provides the URI to access the 176 authentication page. 178 The format of the DHCPv4 Captive-Portal DHCP option is shown below. 180 Code Len Data 181 +------+------+------+------+------+-- --+-----+ 182 | code | len | URI ... | 183 +------+------+------+------+------+-- --+-----+ 185 o Code: The Captive-Portal DHCP Option (TBA1) 187 o Len: The length, in octets of the URI. 189 o URI: The URI of the authentication page that the user should 190 connect to. 192 The URI SHOULD be a URL with an IP-literal for the host portion (to 193 remove the need to allow DNS from unauthenticated clients). 195 [ED NOTE: Using an address literal is less than awesome, but better 196 than the alternatives. Recommending a DNS name means that the CP 197 would need to allow DNS from unauthenticated clients (as we don't 198 want to force users to use the CP's provided DNS) and some folk would 199 use this to DNS Tunnel out. This would make the CP admin block 200 external recursives).] 202 4. Use of the Captive-Portal Option 204 [ED NOTE: This section is, and probably will remain, fairly hand 205 wavy. This option provides notice to the OS / User applications that 206 there is a CP, but I think that the UI / etc is best designed / 207 handled by the Operating System vendors / Application developers. ] 209 The purpose of the Captive-Portal DHCP Option is to inform the 210 operating system and applications that they are behind a captive 211 portal type device, and will need to authenticate before getting 212 network access (and how to reach the authentication page). 214 The exact method that the interaction with the user occurs is device 215 / operating system / application dependent, the below is simply one 216 option. 218 When the device receives a DHCP response with the Captive-Portal 219 Option it SHOULD: 221 1. Not initiate new IP connections until the CP has been satisfied. 222 [TODO(Someone): Existing connections should be placed on hold 223 (need better text). This will happen more often than some expect 224 -- you buy 1h of Internet at a cafe and stay there for 3h -- this 225 will "interrupt" you a few times).] 227 2. Present a dialog box to the user informing that they are behind a 228 captive portal and ask if they wish to proceed. 230 3. If the user elects to proceed, the device should initiate a 231 connection to the captive portal login page using a web browser 232 configured with a separate cookie store. Some captive portals 233 send the user a cookie when they authenticate (so that the user 234 can re-authenticate more easily in the future - the browser 235 should keep these CP cookies separate from other cookies. 237 4. Once the user has authenticated (how does it know? HTTP 238 response?! Probe (ugh?)) normal IP connectivity should resume. 240 5. The device should (using an OS dependent method) expose to the 241 user / user applications that they have connected though a 242 captive portal (for example by creating a file in /proc/net/ 243 containing the interface and captive portal URI). This should 244 continue until the network changes, or a new DHCP message without 245 the CP is received. 247 5. IANA Considerations 249 [ This section stolen from draft-ietf-dhc-access-network-identifier. 250 :-) ] 252 This document defines DHCPv4 Captive-Portal option which requires 253 assignment of DHCPv4 option code TBD1 assigned from "Bootp and DHCP 254 options" registry (http://www.iana.org/assignments/ bootp-dhcp- 255 parameters/bootp-dhcp-parameters.xml), as specified in [RFC2939]. 257 6. Security Considerations 259 An attacker with the ability to inject DHCP messages could include 260 this option and so force users to contact him. As an attacker with 261 this capability could simply list himself as the default gateway (and 262 so see all the victims traffic) we do not think this gives them 263 significantly more capabilities. Fake DHCP servers are currently a 264 security concern - this doesn't make them any better or worse. 266 Devices and systems that automatically connect to open network could 267 potentially be tracked using the techniques described in this 268 document (forcing the user to continually authenticate, or exposing 269 their browser fingerprint), but similar tracking could already be 270 performed with the standard captive portal mechanisms, so this 271 doesn't seem to give the attackers more capabilities. 273 By simplifying the interaction with the captive portal systems, and 274 doing away with the need for interception, we think that users will 275 be less likely to disable useful security safeguards like DNSSEC 276 validation, VPNs, etc. 278 7. Acknowledgements 280 The primary author has discussed this idea with a number of folk, and 281 asked them to assist by becoming co-authors. Unfortunately he has 282 forgotten who many of them were; if you were one of them, I 283 apologize. 285 Thanks to Vint Cerf for the initial idea / asking me to write this. 287 8. References 289 8.1. Normative References 291 [IANA.AS_Numbers] 292 IANA, "Autonomous System (AS) Numbers", 293 . 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, March 1997. 298 8.2. Informative References 300 [I-D.ietf-sidr-iana-objects] 301 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 302 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 303 progress), May 2011. 305 Appendix A. Changes / Author Notes. 307 [RFC Editor: Please remove this section before publication ] 309 From -00 to -01. 311 o Nothing changed in the template! 313 Authors' Addresses 315 Warren Kumari 316 Google 317 1600 Amphitheatre Parkway 318 Mountain View, CA 94043 319 US 321 Email: warren@kumari.net 323 Olafur Gudmundsson 324 Shinkuro Inc. 325 4922 Fairmont Av, Suite 250 326 Bethesda, MD 20814 327 USA 329 Email: ogud@ogud.com 330 Paul Ebersman 331 Infoblox 333 Email: ebersman-ietf@dragon.net 335 Steve Sheng 336 Internet Corporation for Assigned Names and Numbers 337 12025 Waterfront Drive, Suite 300 338 Los Angeles 90094 339 United States of America 341 Phone: +1.310.301.5800 342 Email: steve.sheng@icann.org