idnits 2.17.1 draft-ietf-capport-rfc7710bis-03.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 draft header indicates that this document obsoletes RFC7710, but the abstract doesn't seem to directly say this. It does mention RFC7710 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (March 30, 2020) is 1487 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'THIS-RFC' is mentioned on line 306, but not defined == Missing Reference: 'Deprecated' is mentioned on line 312, but not defined -- Looks like a reference, but probably isn't: '1' on line 465 -- Looks like a reference, but probably isn't: '2' on line 467 -- Looks like a reference, but probably isn't: '3' on line 469 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7710 (Obsoleted by RFC 8910) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google 4 Obsoletes: 7710 (if approved) E. Kline 5 Intended status: Standards Track Loon 6 Expires: October 1, 2020 March 30, 2020 8 Captive-Portal Identification in DHCP / RA 9 draft-ietf-capport-rfc7710bis-03 11 Abstract 13 In many environments offering short-term or temporary Internet access 14 (such as coffee shops), it is common to start new connections in a 15 captive portal mode. This highly restricts what the customer can do 16 until the customer has authenticated. 18 This document describes a DHCP option (and a Router Advertisement 19 (RA) extension) to inform clients that they are behind some sort of 20 captive-portal enforcement device, and that they will need to 21 authenticate to get Internet access. It is not a full solution to 22 address all of the issues that clients may have with captive portals; 23 it is designed to be used in larger solutions. The method of 24 authenticating to, and interacting with the captive portal is out of 25 scope of this document. 27 RFC7710 used DHCP code point 160. Due to a conflict, this document 28 specifies TBD. 30 [ This document is being collaborated on in Github at: 31 https://github.com/capport-wg/7710bis. The most recent version of 32 the document, open issues, etc should all be available here. The 33 authors (gratefully) accept pull requests. Text in square brackets 34 will be removed before publication. ] 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on October 1, 2020. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 72 2. The Captive-Portal Option . . . . . . . . . . . . . . . . . . 3 73 2.1. IPv4 DHCP Option . . . . . . . . . . . . . . . . . . . . 4 74 2.2. IPv6 DHCP Option . . . . . . . . . . . . . . . . . . . . 5 75 2.3. The Captive-Portal IPv6 RA Option . . . . . . . . . . . . 5 76 3. Precedence of API URIs . . . . . . . . . . . . . . . . . . . 6 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 78 4.1. IETF params Registration . . . . . . . . . . . . . . . . 6 79 4.1.1. Registry name: Captive Portal Unrestricted Identifier 6 80 4.2. BOOTP Vendor Extensions and DHCP Options Code Change . . 7 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 83 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 84 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 10 85 Appendix B. Changes from RFC 7710 . . . . . . . . . . . . . . . 10 86 Appendix C. Observations From IETF 106 Network Experiment . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 89 1. Introduction 91 In many environments, users need to connect to a captive-portal 92 device and agree to an Acceptable Use Policy (AUP) and / or provide 93 billing information before they can access the Internet. Regardless 94 of how that mechanism operates, this document provides functionality 95 to allow the client to know when it is behind a captive portal and 96 how to contact it. 98 In order to present users with the payment or AUP pages, presently a 99 captive-portal enforcement device has to intercept the user's 100 connections and redirect the user to a captive portal server, using 101 methods that are very similar to man-in-the-middle (MITM) attacks. 102 As increasing focus is placed on security, and end nodes adopt a more 103 secure stance, these interception techniques will become less 104 effective and/or more intrusive. 106 This document describes a DHCP ([RFC2131]) option (Captive-Portal) 107 and an IPv6 Router Advertisement (RA) ([RFC4861]) extension that 108 informs clients that they are behind a captive-portal enforcement 109 device and how to contact an API for more information. 111 1.1. Requirements Notation 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. The Captive-Portal Option 119 The Captive Portal DHCP / RA Option informs the client that it may be 120 behind a captive portal and provides the URI to access an API as 121 defined by [draft-ietf-capport-api]. This is primarily intended to 122 improve the user experience by showing the user the captive portal 123 information faster and more reliably. Note that, for the foreseeable 124 future, captive portals will still need to implement the interception 125 techniques to serve legacy clients, and clients will need to perform 126 probing to detect captive portals. 128 Clients that support the Captive Portal DHCP option SHOULD include 129 the option in the Parameter Request List in DHCPREQUEST messages. 130 DHCP servers MAY send the Captive Portal option without any explicit 131 request. 133 In order to support multiple "classes" of clients (e.g. IPv4 only, 134 IPv6 only with DHCPv6 ([RFC3315]), and IPv6 only with RA) the captive 135 network can provision the client with the URI via multiple methods 136 (IPv4 DHCP, IPv6 DHCP, and IPv6 RA). The captive portal operator 137 SHOULD ensure that the URIs provisioned by each method are equivalent 138 to reduce the chance of operational problems. The maximum length of 139 the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer 140 than 255 bytes should not be provisioned via IPv6 DHCP or IPv6 RA 141 either. 143 In all variants of this option, the URI MUST be that of the captive 144 portal API endpoint, conforming to the recommendations for such URIs 145 [draft-ietf-capport-api]. 147 A captive portal server MAY redirect requests that do not have an 148 Accept header field ([RFC7231] Section 5.3) containing a field item 149 whose content-type is "application/capport+json" to the URL conveyed 150 in the "user-portal-url" API key. When performing such content 151 negotiation ([RFC7231] Section 3.4), captive portals implementors 152 need to keep in mind that such responses might be cached, and 153 therefore SHOULD include an appropriate Vary header field ([RFC7231] 154 Section 7.1.4) or mark them explicitly uncacheable (for example, 155 using Cache-Control: no-store [RFC7234] Section 5.2.2.3). 157 A captive portal MAY do content negotiation ([RFC7231] section 3.4) 158 and attempt to redirect clients querying without an explicit 159 indication of support for the captive portal API content type (i.e. 160 without application/capport+json listed explicitly anywhere within an 161 Accept header vis. [RFC7231] section 5.3). In so doing, the captive 162 portal SHOULD redirect the client to the value associated with the 163 "user-portal-url" API key. 165 The URI SHOULD NOT contain an IP address literal. 167 Networks with no captive portals MAY explicitly indicate this 168 condition by using this option with the IANA-assigned URI for this 169 purpose (see Section 4.1.1). Clients observing the URI value 170 "urn:ietf:params:capport-unrestricted" MAY forego time-consuming 171 forms of captive portal detection. 173 2.1. IPv4 DHCP Option 175 The format of the IPv4 Captive-Portal DHCP option is shown below. 177 Code Len Data 178 +------+------+------+------+------+-- --+-----+ 179 | code | len | URI ... | 180 +------+------+------+------+------+-- --+-----+ 182 o Code: The Captive-Portal DHCPv4 Option (TBD) (one octet) 184 o Len: The length, in octets of the URI. 186 o URI: The URI for the captive portal API endpoint to which the user 187 should connect (encoded following the rules in [RFC3986]). 189 Note that the URI parameter is not null terminated. 191 2.2. IPv6 DHCP Option 193 The format of the IPv6 Captive-Portal DHCP option is shown below. 195 0 1 2 3 196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | option-code | option-len | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 . URI (variable length) . 201 | ... | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 o option-code: The Captive-Portal DHCPv6Option (103) (two octets) 206 o option-len: The length, in octets of the URI. 208 o URI: The URI for the captive portal API endpoint to which the user 209 should connect (encoded following the rules in [RFC3986]). 211 See [RFC7227], Section 5.7 for more examples of DHCP Options with 212 URIs. 214 Note that the URI parameter is not null terminated. 216 2.3. The Captive-Portal IPv6 RA Option 218 This section describes the Captive-Portal Router Advertisement 219 option. 221 0 1 2 3 222 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type | Length | URI . 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 226 . . 227 . . 228 . . 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 2: Captive-Portal RA Option Format 232 Type 37 234 Length 8-bit unsigned integer. The length of the option (including 235 the Type and Length fields) in units of 8 bytes. 237 URI The URI for the captive portal API endpoint to which the user 238 should connect. This MUST be padded with NULL (0x00) to make the 239 total option length (including the Type and Length fields) a 240 multiple of 8 bytes. 242 Note that the URI parameter is not guaranteed to be null terminated. 244 3. Precedence of API URIs 246 A device may learn about Captive Portal API URIs through more than 247 one of (or indeed all of) the above options. It is a network 248 configuration error if the learned URIs are not all identical. 250 However, if the URIs learned are not in fact all identical the 251 captive device MUST prioritize URIs learned from network provisioning 252 or configuration mechanisms before all other URIs. Specifically, 253 URIs learned via any of the options in Section 2 should take 254 precedence over any URI learned via some other mechanism, such as a 255 redirect. 257 If the URIs learned via more than one option described in Section 2 258 are not all identical, this condition should be logged for the device 259 owner or administrator. Implementations can select their own 260 precedence order. 262 4. IANA Considerations 264 This document requests one new IETF URN protocol parameter 265 ([RFC3553]) entry. This document also requests a reallocation of 266 DHCPv4 option codes (see Appendix C for background). 268 Thanks IANA! 270 4.1. IETF params Registration 272 4.1.1. Registry name: Captive Portal Unrestricted Identifier 274 Registry name: Captive Portal Unrestricted Identifier 276 URN: urn:ietf:params:capport-unrestricted 278 Specification: RFC TBD (this document) 280 Repository: RFC TBD (this document) 282 Index value: Only one value is defined (see URN above). No hierarchy 283 is defined and therefore no sub-namespace registrations are possible. 285 4.2. BOOTP Vendor Extensions and DHCP Options Code Change 287 [ RFC Ed: Please remove before publication: RFC7710 uses DHCP Code 288 160 -- unfortunately, it was discovered that this option code is 289 already widely used by Polycom (see appendix). Option 114 (URL) is 290 currently assigned to Apple (RFC3679, Section 3.2.3 - Contact: Dieter 291 Siegmund, dieter@apple.com - Reason to recover: Never published in an 292 RFC) Tommy Pauly (Apple) and Dieter Siegmund confirm that this 293 codepoint hasn't been used, and Apple is willing to relinquish it for 294 use in CAPPORT. Please see thread: 295 https://mailarchive.ietf.org/arch/msg/captive-portals/ 296 TmqQz6Ma_fznD3XbhwkH9m2dB28 for more background. ] 298 The IANA is requested to update the "BOOTP Vendor Extensions and DHCP 299 Options" registry (https://www.iana.org/assignments/bootp-dhcp- 300 parameters/bootp-dhcp-parameters.xhtml) as follows. 302 Tag: 114 303 Name: DHCP Captive-Portal 304 Data Length: N 305 Meaning: DHCP Captive-Portal 306 Reference: [THIS-RFC] 308 Tag: 160 309 Name: REMOVED/Unassigned 310 Data Length: 311 Meaning: 312 Reference: [RFC7710][Deprecated] 314 5. Security Considerations 316 An attacker with the ability to inject DHCP messages or RAs could 317 include an option from this document to force users to contact an 318 address of his choosing. As an attacker with this capability could 319 simply list himself as the default gateway (and so intercept all the 320 victim's traffic); this does not provide them with significantly more 321 capabilities, but because this document removes the need for 322 interception, the attacker may have an easier time performing the 323 attack. As the operating systems and application that make use of 324 this information know that they are connecting to a captive-portal 325 device (as opposed to intercepted connections) they can render the 326 page in a sandboxed environment and take other precautions, such as 327 clearly labeling the page as untrusted. The means of sandboxing and 328 user interface presenting this information is not covered in this 329 document - by its nature it is implementation specific and best left 330 to the application and user interface designers. 332 Devices and systems that automatically connect to an open network 333 could potentially be tracked using the techniques described in this 334 document (forcing the user to continually authenticate, or exposing 335 their browser fingerprint). However, similar tracking can already be 336 performed with the presently common captive portal mechanisms, so 337 this technique does not give the attackers more capabilities. 339 Captive portals are increasingly hijacking TLS connections to force 340 browsers to talk to the portal. Providing the portal's URI via a 341 DHCP or RA option is a cleaner technique, and reduces user 342 expectations of being hijacked - this may improve security by making 343 users more reluctant to accept TLS hijacking, which can be performed 344 from beyond the network associated with the captive portal. 346 By simplifying the interaction with the captive portal systems, and 347 doing away with the need for interception, we think that users will 348 be less likely to disable useful security safeguards like DNSSEC 349 validation, VPNs, etc. In addition, because the system knows that it 350 is behind a captive portal, it can know not to send cookies, 351 credentials, etc. By handing out a URI which is protected with TLS, 352 the captive portal operator can attempt to reassure the user that the 353 captive portal is not malicious. 355 6. Acknowledgements 357 This document is a -bis of RFC7710. Thanks to all of the original 358 authors (Warren Kumari, Olafur Gudmundsson, Paul Ebersman, Steve 359 Sheng), and original contributors. 361 Also thanks to the CAPPORT WG for all of the discussion and 362 improvements including contributions and review from Joe Clarke, 363 Lorenzo Colitti, Dave Dolson, Hans Kuhn, Kyle Larose, Clemens 364 Schimpe, Martin Thompson, Michael Richardson, Remi Nguyen Van, Bernie 365 Volz, and Tommy Pauly. 367 7. References 369 7.1. Normative References 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, 373 DOI 10.17487/RFC2119, March 1997, 374 . 376 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 377 RFC 2131, DOI 10.17487/RFC2131, March 1997, 378 . 380 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 381 C., and M. Carney, "Dynamic Host Configuration Protocol 382 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 383 2003, . 385 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 386 IETF URN Sub-namespace for Registered Protocol 387 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 388 2003, . 390 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 391 Resource Identifier (URI): Generic Syntax", STD 66, 392 RFC 3986, DOI 10.17487/RFC3986, January 2005, 393 . 395 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 396 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 397 DOI 10.17487/RFC4861, September 2007, 398 . 400 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 401 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 402 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 403 . 405 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 406 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 407 DOI 10.17487/RFC7231, June 2014, 408 . 410 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 411 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 412 RFC 7234, DOI 10.17487/RFC7234, June 2014, 413 . 415 [RFC7710] Kumari, W., Gudmundsson, O., Ebersman, P., and S. Sheng, 416 "Captive-Portal Identification Using DHCP or Router 417 Advertisements (RAs)", RFC 7710, DOI 10.17487/RFC7710, 418 December 2015, . 420 7.2. URIs 422 [1] https://tickets.meeting.ietf.org/wiki/IETF106network#Experiments 424 [2] https://tickets.meeting.ietf.org/wiki/CAPPORT 426 [3] https://community.polycom.com/t5/VoIP-SIP-Phones/DHCP- 427 Standardization-160-vs-66/td-p/72577 429 Appendix A. Changes / Author Notes. 431 [RFC Editor: Please remove this section before publication ] 433 From initial to -00. 435 o Import of RFC7710. 437 From -00 to -01. 439 o Remove link-relation text. 441 o Clarify option should be in DHCPREQUEST parameter list. 443 o Uppercase some SHOULDs. 445 Appendix B. Changes from RFC 7710 447 This document incorporates the following changes from [RFC7710]. 449 1. Clarify that IP string literals are NOT RECOMMENDED. 451 2. Clarify that the option URI SHOULD be that of the captive portal 452 API endpoint. 454 3. Clarify that captive portals MAY do content negotiation. 456 4. Added text about Captive Portal API URI precedence in the event 457 of a network configuration error. 459 5. Added urn:ietf:params:capport-unrestricted URN. 461 6. Notes that the DHCP Code changed from 160 to 114. 463 Appendix C. Observations From IETF 106 Network Experiment 465 During IETF 106 in Singapore an experiment [1] enabling Captive 466 Portal API compatible clients to discover a venue-info-url (see 467 experiment description [2] for more detail) revealed that some 468 Polycom devices on the same network made use of DHCPv4 option code 469 160 for other purposes [3]. 471 The presence of DHCPv4 Option code 160 holding a value indicating the 472 Captive Portal API URL caused these devices to not function as 473 desired. For this reason, this document requests IANA deprecate 474 option code 160 and reallocate different value to be used for the 475 Captive Portal API URL. 477 Authors' Addresses 479 Warren Kumari 480 Google 481 1600 Amphitheatre Parkway 482 Mountain View, CA 94043 483 US 485 Email: warren@kumari.net 487 Erik Kline 488 Loon 489 1600 Amphitheatre Parkway 490 Mountain View, CA 94043 491 US 493 Email: ek@loon.com