idnits 2.17.1 draft-wkumari-dhc-capport-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 23, 2014) is 3739 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2939' is mentioned on line 287, but not defined == Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 338, but no explicit reference was found in the text 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 27, 2014 Shinkuro Inc. 6 P. Ebersman 7 Infoblox 8 S. Sheng 9 ICANN 10 January 23, 2014 12 Captive-Portal identification in DHCP 13 draft-wkumari-dhc-capport-01 15 Abstract 17 In many environments (such as hotels, coffee shops and other 18 establishments that offer Internet service to customers), it is 19 common 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 27, 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 . . . . . . . . . . . . . . . . . . . 7 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 8.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 the user to first accept an Acceptable Use Policy 107 (AUP) and / or provides billing information (such as their last name 108 and / or room number in a hotel, credit card information, etc) 109 through a 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 implementation, the CP acts like a transparent HTTP proxy; 148 but 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. This is primarily intended to improve the user 177 experiance; for the forseeable future captive portals will still need 178 to implement the interception techniques to serve legacy clinets. 180 This draft is not intended to provide guidance on how to implement a 181 captive portal. As such, it assumes that the captive portal on a 182 dual-stack or IPv6-only network is already capable of intercepting 183 IPv6 traffic. However, in order to support IPv6 with the proposed 184 DHCP option, there are some additional considerations. In a dual- 185 stack network, the network supports both IPv4 and IPv6 protocols 186 simultaneously, but can have a mix of IPv4-only, IPv6-only, and dual- 187 stack devices using the network, meaning that it may be necessary to 188 have parallel notifications via DHCPv4 and DHCPv6. 190 IPv4-only and dual-stack devices can technically both support 191 receiving the option via DHCPv4, but dual-stack implementations would 192 need to ensure that the correct action would be taken for both IPv4 193 and IPv6 traffic despite only receiving an option via IPv4. For 194 devices/networks that only speak IPv6, and to avoid this dependency 195 on the implementation, a DHCPv6 option is necessary. 197 [ED NOTE:] This is complicated by the fact that not all devices 198 support DHCPv6, and thus it may be necessary to investigate other 199 methods to notify IPv6-only devices of a captive portal. Since this 200 option is only intended to help clients gracefully deal with networks 201 that have a captive portal, it may be acceptable to note that if a 202 client does not support DHCPv6, it simply won't be able to take 203 advantage of this optimization, but will otherwise function normally. 204 [/note] 206 The format of the DHCP Captive-Portal DHCP option is identical for 207 both DHCPv4 and DHCPv6 and is shown below. 209 Code Len Data 210 +------+------+------+------+------+-- --+-----+ 211 | code | len | URI ... | 212 +------+------+------+------+------+-- --+-----+ 214 o Code: The Captive-Portal DHCP Option (TBA1 for DHCPv4, TBA2 for 215 DHCPv6) 217 o Len: The length, in octets of the URI. 219 o URI: The URI of the authentication page that the user should 220 connect to. 222 The URI MUST be a URL with an IP-literal for the host portion (to 223 remove the need to allow DNS from unauthenticated clients). The 224 DHCPv4 URI MUST contain an IPv4 address, and the DHCPv6 URI MUST 225 contain an IPv6 address (to account for IPv4 only or IPv6 only 226 capable devices - not everyting is dual stack!) 228 [ED NOTE: Using an address literal is less than ideal, but better 229 than the alternatives. Recommending a DNS name means that the CP 230 would need to allow DNS from unauthenticated clients (as we don't 231 want to force users to use the CP's provided DNS) and some folk would 232 use this to DNS Tunnel out. This would make the CP admin block 233 external recursives).] 235 4. Use of the Captive-Portal Option 237 [ED NOTE: This section is, and probably will remain, fairly hand 238 wavy. This option provides notice to the OS / User applications that 239 there is a CP, but I think that the UI / etc is best designed / 240 handled by the Operating System vendors / Application developers. ] 241 The purpose of the Captive-Portal DHCP Option is to inform the 242 operating system and applications that they are behind a captive 243 portal type device and will need to authenticate before getting 244 network access (and how to reach the authentication page). 246 The exact method that the interaction with the user occurs is device 247 / operating system / application dependent. The below is simply one 248 option. 250 When the device receives a DHCP response with the Captive-Portal 251 Option it SHOULD: 253 1. Not initiate new IP connections until the CP has been satisfied. 254 [TODO(Someone): Existing connections should be quiesced. This 255 will happen more often than some expect -- you buy 1h of Internet 256 at a cafe and stay there for 3h -- this will "interrupt" you a 257 few times).] 259 2. Present a dialog box to the user informing that they are behind a 260 captive portal and ask if they wish to proceed. 262 3. If the user elects to proceed, the device should initiate a 263 connection to the captive portal login page using a web browser 264 configured with a separate cookie store. Some captive portals 265 send the user a cookie when they authenticate (so that the user 266 can re-authenticate more easily in the future - the browser 267 should keep these CP cookies separate from other cookies. 269 4. Once the user has authenticated (how does it know? HTTP 270 response?! Probe (ugh?)) normal IP connectivity should resume. 272 5. The device should (using an OS dependent method) expose to the 273 user / user applications that they have connected though a 274 captive portal (for example by creating a file in /proc/net/ 275 containing the interface and captive portal URI). This should 276 continue until the network changes, or a new DHCP message without 277 the CP is received. 279 5. IANA Considerations 281 [ This section stolen from draft-ietf-dhc-access-network-identifier. 282 :-) ] 284 This document defines DHCPv4 Captive-Portal option which requires 285 assignment of DHCPv4 option code TBA1 assigned from "Bootp and DHCP 286 options" registry (http://www.iana.org/assignments/ bootp-dhcp- 287 parameters/bootp-dhcp-parameters.xml), as specified in [RFC2939]. 289 The IANA is requested to assign an option codes for the DHCPv6 290 Captive-Portal (TBA2) option from the "DHCPv6 and DHCPv6 options" 291 registry (http:// www.iana.org/assignments/dhcpv6-parameters/ 292 dhcpv6-parameters.xml). 294 6. Security Considerations 296 An attacker with the ability to inject DHCP messages could include 297 this option and so force users to contact him. As an attacker with 298 this capability could simply list himself as the default gateway (and 299 so see all the victim's traffic), we do not think this gives them 300 significantly more capabilities. Fake DHCP servers are currently a 301 security concern - this doesn't make them any better or worse. 303 Devices and systems that automatically connect to open network could 304 potentially be tracked using the techniques described in this 305 document (forcing the user to continually authenticate, or exposing 306 their browser fingerprint), but similar tracking could already be 307 performed with the standard captive portal mechanisms, so this 308 doesn't seem to give the attackers more capabilities. 310 By simplifying the interaction with the captive portal systems, and 311 doing away with the need for interception, we think that users will 312 be less likely to disable useful security safeguards like DNSSEC 313 validation, VPNs, etc. 315 7. Acknowledgements 317 The primary author has discussed this idea with a number of folk, and 318 asked them to assist by becoming co-authors. Unfortunately he has 319 forgotten who many of them were; if you were one of them, I 320 apologize. 322 Thanks to Vint Cerf for the initial idea / asking me to write this. 323 Thanks to Wes George for supplying the v6 text. 325 8. References 327 8.1. Normative References 329 [IANA.AS_Numbers] 330 IANA, "Autonomous System (AS) Numbers", 331 . 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, March 1997. 336 8.2. Informative References 338 [I-D.ietf-sidr-iana-objects] 339 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 340 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 341 progress), May 2011. 343 Appendix A. Changes / Author Notes. 345 [RFC Editor: Please remove this section before publication ] 347 From -00 to -01: 349 o Many nits and editorial changes. 351 o Whole bunch of extra text and review from Wes George on v6. 353 From initial to -00. 355 o Nothing changed in the template! 357 Authors' Addresses 359 Warren Kumari 360 Google 361 1600 Amphitheatre Parkway 362 Mountain View, CA 94043 363 US 365 Email: warren@kumari.net 367 Olafur Gudmundsson 368 Shinkuro Inc. 369 4922 Fairmont Av, Suite 250 370 Bethesda, MD 20814 371 USA 373 Email: ogud@ogud.com 375 Paul Ebersman 376 Infoblox 378 Email: ebersman-ietf@dragon.net 379 Steve Sheng 380 Internet Corporation for Assigned Names and Numbers 381 12025 Waterfront Drive, Suite 300 382 Los Angeles 90094 383 United States of America 385 Phone: +1.310.301.5800 386 Email: steve.sheng@icann.org