idnits 2.17.1 draft-ietf-capport-architecture-02.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 (June 28, 2018) is 2123 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7710 (Obsoleted by RFC 8910) == Outdated reference: A later version (-11) exists of draft-ietf-intarea-provisioning-domains-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Larose 3 Internet-Draft Agilicus 4 Intended status: Informational D. Dolson 5 Expires: December 30, 2018 June 28, 2018 7 CAPPORT Architecture 8 draft-ietf-capport-architecture-02 10 Abstract 12 This document aims to document consensus on the CAPPORT architecture. 13 DHCP or Router Advertisements, an optional signaling protocol, and an 14 HTTP API are used to provide the solution. The role of Provisioning 15 Domains (PvDs) is described. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 30, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Components . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.1. User Equipment . . . . . . . . . . . . . . . . . . . . . 5 56 2.2. Provisioning Service . . . . . . . . . . . . . . . . . . 6 57 2.2.1. DHCP or Router Advertisements . . . . . . . . . . . . 6 58 2.2.2. Provisioning Domains . . . . . . . . . . . . . . . . 6 59 2.3. Captive Portal API Server . . . . . . . . . . . . . . . . 7 60 2.4. Captive Portal Enforcement . . . . . . . . . . . . . . . 8 61 2.5. Captive Portal Signal . . . . . . . . . . . . . . . . . . 8 62 2.6. Component Diagram . . . . . . . . . . . . . . . . . . . . 9 63 3. User Equipment Identity . . . . . . . . . . . . . . . . . . . 11 64 3.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 11 65 3.2. Recommended Properties . . . . . . . . . . . . . . . . . 11 66 3.2.1. Uniquely Identify User Equipment . . . . . . . . . . 12 67 3.2.2. Hard to Spoof . . . . . . . . . . . . . . . . . . . . 12 68 3.2.3. Visible to the API . . . . . . . . . . . . . . . . . 12 69 3.2.4. Visible to the Enforcement Device . . . . . . . . . . 12 70 3.3. Evaluating an Identifier . . . . . . . . . . . . . . . . 12 71 3.4. Examples of an Identifier . . . . . . . . . . . . . . . . 13 72 3.4.1. Physical Interface . . . . . . . . . . . . . . . . . 13 73 3.4.2. IP Address . . . . . . . . . . . . . . . . . . . . . 13 74 4. Solution Workflow . . . . . . . . . . . . . . . . . . . . . . 14 75 4.1. Initial Connection . . . . . . . . . . . . . . . . . . . 14 76 4.2. Conditions Expire . . . . . . . . . . . . . . . . . . . . 15 77 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 7.1. Trusting the Network . . . . . . . . . . . . . . . . . . 16 81 7.2. Authenticated APIs . . . . . . . . . . . . . . . . . . . 16 82 7.3. Secure APIs . . . . . . . . . . . . . . . . . . . . . . . 16 83 7.4. Risk of Nuisance Captive Portal . . . . . . . . . . . . . 17 84 7.5. User Options . . . . . . . . . . . . . . . . . . . . . . 17 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 87 8.2. Informative References . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 In this document, "Captive Portal" is used to describe a network to 93 which a device may be voluntarily attached, such that network access 94 is limited until some requirements have been fulfilled. Typically a 95 user is required to use a web browser to fulfill requirements imposed 96 by the network operator, such as reading advertisements, accepting an 97 acceptable-use policy, or providing some form of credentials. 99 Implementations generally require a web server, some method to allow/ 100 block traffic, and some method to alert the user. Common methods of 101 alerting the user involve modifying HTTP or DNS traffic. 103 Problems with captive portal implementations have been described in 104 [I-D.nottingham-capport-problem]. [If that document cannot be 105 published, consider putting its best parts into an appendix of this 106 document.] 108 This document standardizes an architecture for implementing captive 109 portals that provides tools for addressing most of those problems. 110 We are guided by these principles: 112 o Solutions SHOULD NOT require the forging of responses from DNS or 113 HTTP servers, or any other protocol. In particular, solutions 114 SHOULD NOT require man-in-the-middle proxy of TLS traffic. 116 o Solutions MUST operate at the layer of Internet Protocol (IP) or 117 above, not being specific to any particular access technology such 118 as Cable, WiFi or 3GPP. 120 o Solutions SHOULD allow a device to be alerted that it is in a 121 captive network when attempting to use any application on the 122 network. (Versus requiring a user to visit a clear-text HTTP site 123 in order to receive a notification.) 125 o Solutions SHOULD allow a device to learn that it is in a captive 126 network before any application attempts to use the network. 128 o The state of captivity SHOULD be explicitly available to devices 129 (in contrast to modification of DNS or HTTP, which is only 130 indirectly machine-detectable by the client--by comparing 131 responses to well-known queries with expected responses). 133 o The architecture MUST provide a path of incremental migration, 134 acknowledging a huge variety of portals and end-user device 135 implementations and software versions. 137 o The architecture SHOULD improve security by providing mechanisms 138 for trust, allowing alerts from trusted network operators to be 139 distinguished from attacks from untrusted agents. 141 A side-benefit of the architecture described in this document is that 142 devices without user interfaces are able to identify parameters of 143 captivity. However, this document does not yet describe a mechanism 144 for such devices to escape captivity. 146 The architecture uses the following mechanisms: 148 o Network provisioning protocols provide end-user devices with a URI 149 for the API that end-user devices query for information about what 150 is required to escape captivity. DHCP, DHCPv6, and Router- 151 Advertisement options for this purpose are available in [RFC7710]. 152 Other protocols (such as RADIUS), Provisioning Domains 153 [I-D.ietf-intarea-provisioning-domains], or static configuration 154 may also be used. A device MAY query this API at any time to 155 determine whether the network is holding the device in a captive 156 state. 158 o End-user devices are notified of captivity with Captive Portal 159 Signals in response to traffic. This notification should work 160 with any Internet protocol, not just clear-text HTTP. This 161 notification does not carry the portal URI; rather it provides a 162 notification to the User Equipment that it is in a captive state. 163 This document will specify requirements for the signaling protocol 164 which will generate Captive Portal Signals. 166 o Receipt of a Captive Portal Signal informs an end-user device that 167 it is captive. In response, the device SHOULD query the 168 provisioned API to obtain information about the network state. 169 The device MAY take immediate action to satisfy the portal 170 (according to its configuration/policy). 172 The architecture attempts to provide privacy, authentication, and 173 safety mechanisms to the extent possible. 175 1.1. Requirements Language 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in RFC 2119 [RFC2119]. 181 1.2. Terminology 183 Captive Network: A network which limits communication of attached 184 devices to restricted hosts until the user has satisfied Captive 185 Portal Conditions, after which access is permitted to a wider set of 186 hosts (typically the internet). 188 Captive Portal Conditions: site-specific requirements that a user or 189 device must satisfy in order to gain access to the wider network. 191 Captive Portal Enforcement: The network equipment which enforces the 192 traffic restriction and notifies the User Equipment it is in a 193 captive state. 195 Captive Portal User Equipment: Also known as User Equipment. A 196 device which has voluntarily joined a network for purposes of 197 communicating beyond the constraints of the captive network. 199 Captive Portal Server: The web server providing a user interface for 200 assisting the user in satisfying the conditions to escape captivity. 202 Captive Portal Signaling Protocol: Also known as Signaling Protocol. 203 A protocol used by the Enforcement device to signal the User 204 Equipment information about the state of its captivity. 206 2. Components 208 2.1. User Equipment 210 The User Equipment is the device that a user desires to be attached 211 to a network with full access to all hosts on the network (e.g., to 212 have Internet access). The User Equipment communication is typically 213 restricted by the Captive Portal Enforcement, described in 214 Section 2.4, until site-specific requirements have been met. 216 At this time we consider only devices with web browsers, with web 217 applications being the means of satisfying Captive Portal Conditions. 219 o An example interactive User Equipment is a smart phone. 221 o SHOULD support provisioning of the URI for the Captive Portal API 222 (e.g., by DHCP) 224 o SHOULD distinguish Captive Portal API access per network 225 interface, in the manner of Provisioning Domain Architecture 226 [RFC7556]. 228 o SHOULD have a mechanism for notifying the user of the Captive 229 Portal 231 o SHOULD have a web browser so that the user may navigate the 232 Captive Portal user interface. 234 o SHOULD be able to receive and validate the Captive Portal Signal, 235 and to access the Captive Portal API in response. 237 o MAY restrict application access to networks not granting full 238 network access. E.g., a device connected to a mobile network may 239 be connecting to a WiFi network; the operating system MAY avoid 240 updating the default route until network access restrictions have 241 been lifted (excepting access to the Captive Portal server). This 242 has been termed "make before break". 244 None of the above requirements are mandatory because (a) we do not 245 wish to say users or devices must seek access beyond the captive 246 network, (b) the requirements may be fulfilled by manually visiting 247 the captive portal web application, and (c) legacy devices must 248 continue to be supported. 250 2.2. Provisioning Service 252 Here we discuss candidate mechanisms for provisioning the User 253 Equipment with the URI of the API to query captive portal state and 254 navigate the portal. 256 2.2.1. DHCP or Router Advertisements 258 A standard for providing a portal URI using DHCP or Router 259 Advertisements is described in [RFC7710]. The CAPPORT architecture 260 expects this URI to indicate the API described in Section 2.3. 262 Although it is not clear from RFC7710 what protocol should be 263 executed at the specified URI, some readers might have assumed it to 264 be an HTML page, and hence there might be User Equipment assuming a 265 browser should open this URI. For backwards compatibility, it is 266 RECOMMENDED that the server check the "Accept" field when serving the 267 URI, and serve HTML pages for "text/html" and serve the API for 268 "application/json". [REVISIT: are these details appropriate?] 270 2.2.2. Provisioning Domains 272 Although still a work in progress, 273 [I-D.ietf-intarea-provisioning-domains] proposes a mechanism for User 274 Equipment to be provided with PvD Bootstrap Information containing 275 the URI for a JSON file containing key-value pairs to be downloaded 276 over HTTPS. This JSON file would fill the role of the Captive Portal 277 API described in Section 2.3. 279 The PvD security model provides secure binding between the 280 information provided by the trusted Router Advertisement and the 281 HTTPS server. 283 One key-value pair can be used to indicate the network has restricted 284 access, requiring captive portal navigation by a user. E.g., 285 key="captivePortal" and value=. The key-value pair 286 should provide a different result when access is not restricted. 287 E.g., key="captivePortal" and value="". 289 This JSON file is extensible, allowing new key-value pairs to 290 indicate such things as network access expiry time, URI for API 291 access by IOT devices, etc. 293 The PvD server MUST support multiple (repeated) queries from each 294 User Equipment, always returning the current captive portal 295 information. The User Equipment is expected to make this query upon 296 receiving (and validating) a Captive Portal Signal (see Section 2.5). 298 2.3. Captive Portal API Server 300 The purpose of a Captive Portal API is to permit a query of Captive 301 Portal state without interrupting the user. This API thereby removes 302 the need for a device to perform clear-text "canary" HTTP queries to 303 check for response tampering. 305 The URI of this API will have been provisioned to the User Equipment. 306 (Refer to Section 2.2). 308 This architecture expects the User Equipment to query the API when 309 the User Equipment attaches to the network and multiple times 310 thereafter. Therefore the API MUST support multiple repeated queries 311 from the same User Equipment, returning the current state of 312 captivity for the equipment. 314 At minimum the API MUST provide: (1) the state of captivity and (2) a 315 URI for a browser to present the portal application to the user. The 316 API SHOULD provide evidence to the caller that it supports the 317 present architecture. 319 When user equipment receives (and validates) Captive Portal Signals, 320 the user equipment SHOULD query the API to check the state. The User 321 Equipment SHOULD rate-limit these API queries in the event of the 322 signal being flooded. (See Section 7.) 324 The API MUST be extensible to support future use-cases by allowing 325 extensible information elements. Suggestions include quota 326 information, expiry time, method of providing credentials, security 327 token for validating Captive Portal Signals. 329 The API MUST use TLS for privacy and server authentication. The 330 implementation of the API MUST ensure both privacy and integrity of 331 any information provided by or required by it. 333 This document does not specify the details of the API. 335 2.4. Captive Portal Enforcement 337 The Captive Portal Enforcement component restricts network access to 338 User Equipment according to site-specific policy. Typically User 339 Equipment is permitted access to a small number of services and is 340 denied general network access until it has performed some action. 342 The Captive Portal Enforcement component: 344 o Allows traffic through for allowed User Equipment. 346 o Blocks (discards) traffic for disallowed User Equipment. 348 o May signal User Equipment using the Captive Portal Signaling 349 protocol if traffic is blocked. 351 o Permits disallowed User Equipment to access necessary APIs and web 352 pages to fulfill requirements of exiting captivity. 354 o Updates allow/block rules per User Equipment in response to 355 operations from the Captive Portal back-end. 357 As an upgrade path, captive portals MAY continue to support methods 358 that work today, such as modification of port-80 HTTP responses to 359 redirect users to the portal. Various user-equipment vendors probe 360 canary URLs to identify the state captivity [reference Mariko 361 Kobayashi's survey]. While doing so, Captive Portal Signals SHOULD 362 also be sent, to activate work-flows in supporting devices. [TODO: 363 give some thought to precise recommendations for backwards 364 compatibility.] 366 2.5. Captive Portal Signal 368 User Equipment may send traffic outside the captive network prior to 369 the Enforcement device granting it access. The Enforcement Device 370 rightly blocks or resets these requests. However, lacking a signal 371 from the Enforcement Device, the User Equipment can only guess at 372 whether it is captive. Consequently, allowing the Enforcement Device 373 to signal to the User Equipment that there is a problem with its 374 connectivity may improve the user's experience. 376 An Enforcement Device may also want to inform the User Equipment of a 377 pending expiry of its access to the external network, so providing 378 the Enforcement Device the ability to preemptively signal may be 379 desirable. 381 A specific Captive Portal Signaling Protocol is out of scope for this 382 document. However, in order to ensure that future protocols fit into 383 the architecture, requirements for a Captive Portal Signaling 384 Protocol follow: 386 1. The notification SHOULD NOT be easy to spoof. If an attacker can 387 send spoofed notifications to the User Equipment, they can cause 388 the User Equipment to unnecessarily access the API. Rather than 389 relying solely on rate limits to prevent problems, a good 390 protocol will strive to limit the feasibility of such attacks. 392 2. It SHOULD be possible to send the notification before the captive 393 portal closes. This will help ensure seamless connectivity for 394 the user, as the User Equipment will not need to wait for a 395 network failure to refresh its login. On receipt of preemptive 396 notification, the User Equipment can prompt the user to refresh. 398 3. The protocol SHOULD have a method of identifying the source of 399 signals. 401 4. The signal SHOULD NOT include any information other than a prompt 402 to contact the API, and any information necessary for validation. 404 5. There is no requirement that the protocol be reliable. Thus, The 405 protocol SHOULD continue to send signals as long as the state 406 which triggered the first signal holds, subject to reasonable 407 rate limiting. This is necessary to handle network loss or rate 408 limits between the Enforcement Device and the User Equipment. 410 The Captive Portal Enforcement function SHOULD send Captive Portal 411 Signals when disallowed User Equipment attempts to send to the 412 network. These signals MUST be rate-limited to a configurable rate. 414 The signals MUST NOT be sent to the Internet devices. The 415 indications are only sent to the User Equipment. 417 2.6. Component Diagram 418 The following diagram shows the communication between each component. 420 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 421 . CAPTIVE NETWORK . 422 . +--------------+ . 423 . +------------+ Provision API URI | Provisioning | . 424 . | |<---------------------------+| Service | . 425 . | User | +--------------+ . 426 . | Equipment | Query CAPPORT status; +-------------+ . 427 . | |+--------------------------->| CAPPORT API | . 428 . | | | Server | . 429 . | | +------+------+ . 430 . | | |Status . 431 . | | Portal user interface +------+------+ . 432 . | |+--------------------------> | CAPPORT | . 433 . +------------+ | web portal | . 434 . ^ | Connection Attempt +-------------+ . 435 . | | to prohibited service. | . 436 . | +------------------> +---------------+ Allow/Deny . 437 . | | | Rules . 438 . | CAPPORT Signal | Captive Portal| | . 439 . +---------------------+ | Enforcement | <---+ . 440 . +---------------+ . 441 . | . 442 . To/from external network . 443 . | . 444 . | . 445 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 446 EXTERNAL NETWORK 448 Figure 1: Captive Portal Architecture Component Diagram 450 In the diagram: 452 o During provisioning (e.g., DHCP), the User Equipment acquires the 453 URI for the CAPPORT API. 455 o The User Equipment queries the API to learn of its state of 456 captivity. If captive, the User Equipment presents the portal 457 user interface to the user. 459 o The User Equipment attempts to communicate to the external network 460 through the Captive Portal enforcement device. 462 o The Captive Portal Enforcement device either allows the User 463 Equipment's packets to the external network, or responds with a 464 Captive Portal Signal. 466 o The CAPPORT web portal server directs the Captive Portal 467 Enforcement device to either allow or deny external network access 468 for the User Equipment. 470 Although the provisioning, API, and web portal functions are shown as 471 discrete blocks, they could of course be combined into a single 472 element. 474 3. User Equipment Identity 476 Multiple components in the architecture interact with both the User 477 Equipment and each other. Since the User Equipment is the focus of 478 these interactions, the components must be able to both identify the 479 user equipment from their interactions with it, and be able to agree 480 on the identify of the user equipment when interacting with each 481 other. 483 The methods by which the components interact restrict the type of 484 information that may be used as an identifying characteristics. This 485 section discusses the identifying characteristics. 487 3.1. Identifiers 489 An Identifier is a characteristic of the User Equipment used by the 490 components of a Captive Portal to uniquely determine which specific 491 User Equipment is interacting with them. An Identifier MAY be a 492 field contained in packets sent by the User Equipment to the External 493 Network. Or, an Identifier MAY be an ephemeral property not 494 contained in packets destined for the External Network, but instead 495 correlated with such information through knowledge available to the 496 different components. 498 3.2. Recommended Properties 500 The set of possible identifiers is quite large. However, in order to 501 be considered a good identifier, an identifier SHOULD meet the 502 following criteria. Note that the optimal identifier will likely 503 change depending on the position of the components in the network as 504 well as the information available to them. An identifier SHOULD: 506 o Uniquely Identify the User Equipment 508 o Be Hard to Spoof 510 o Be Visible to the API 512 o Be Visible to the Enforcement Device 514 3.2.1. Uniquely Identify User Equipment 516 In order to uniquely identify the User Equipment, at most one user 517 equipment interacting with the other components of the Captive Portal 518 MUST have a given value of the identifier. 520 Over time, the user equipment identified by the value MAY change. 521 Allowing the identified device to change over time ensures that the 522 space of possible identifying values need not be overly large. 524 Independent Captive Portals MAY use the same identifying value to 525 identify different User Equipment. Allowing independent captive 526 portals to reuse identifying values allows the identifier to be a 527 property of the local network, expanding the space of possible 528 identifiers. 530 3.2.2. Hard to Spoof 532 A good identifier does not lend itself to being easily spoofed. At 533 no time should it be simple or straightforward for one User Equipment 534 to pretend to be another User Equipment, regardless of whether both 535 are active at the same time. This property is particularly important 536 when the user equipment is extended externally to devices such as 537 billing systems, or where the identity of the User Equipment could 538 imply liability. 540 3.2.3. Visible to the API 542 Since the API will need to perform operations which rely on the 543 identify of the user equipment, such as query whether it is captive, 544 the API needs to be able to relate requests to the User Equipment 545 making the request. 547 3.2.4. Visible to the Enforcement Device 549 The Enforcement Device will decide on a per packet basis whether it 550 should be permitted to communicate with the external network. Since 551 this decision depends on which User Equipment sent the packet, the 552 Enforcement Device requires that it be able to map the packet to its 553 concept of the User Equipment. 555 3.3. Evaluating an Identifier 557 To evaluate whether an identifier is appropriate, one should consider 558 every recommended property from the perspective of interactions among 559 the components in the architecture. When comparing identifiers, 560 choose the one which best satisfies all of the recommended 561 properties. The architecture does not provide an exact measure of 562 how well an identifier satisfies a given property; care should be 563 taken in performing the evaluation. 565 3.4. Examples of an Identifier 567 This section provides some examples of identifiers, along with some 568 evaluation of whether they are good identifiers. The list of 569 identifiers is not exhaustive. Other identifiers may be used. An 570 important point to note is that whether the identifiers are good 571 depends heavily on the capabilities of the components and where in 572 the network the components exist. 574 3.4.1. Physical Interface 576 The physical interface by which the User Equipment is attached to the 577 network can be used to identify the User Equipment. This identifier 578 has the property of being extremely difficult to spoof: the User 579 Equipment is unaware of the property; one User Equipment cannot 580 manipulate its interactions to appear as though it is another. 582 Further, if only a single User Equipment is attached to a given 583 physical interface, then the identifier will be unique. If multiple 584 User Equipment is attached to the network on the same physical 585 interface, then this property is not appropriate. 587 Another consideration related to uniqueness of the User Equipment is 588 that if the attached User Equipment changes, both the API server and 589 the Enforcement Device must invalidate their state related to the 590 User Equipment. 592 The Enforcement Device needs to be aware of the physical interface, 593 which constrains the environment: it must either be part of the 594 device providing physical access (e.g., implemented in firmware), or 595 packets traversing the network must be extended to include 596 information about the source physical interface (e.g. a tunnel). 598 The API server faces a similar problem, implying that it should co- 599 exist with the Enforcement Device, or that the enforcement device 600 should extend requests to it with the identifying information. 602 3.4.2. IP Address 604 A natural identifier to consider is the IP address of the User 605 Equipment. At any given time, no device on the network can have the 606 same IP address without causing the network to malfunction, so it is 607 appropriate from the perspective of uniqueness. 609 However, it may be possible to spoof the IP address, particularly for 610 malicious reasons where proper functioning of the network is not 611 necessary for the malicious actor. Consequently, any solution using 612 the IP address should proactively try to prevent spoofing of the IP 613 address. Similarly, if the mapping of IP address to User Equipment 614 is changed, the components of the architecture must remove or update 615 their mapping to prevent spoofing. Demonstrations of return 616 routeability, such as that required for TCP connection establishment, 617 might be sufficient defense against spoofing, though this might not 618 be sufficient in networks that use broadcast media (such as some 619 wireless networks). 621 Since the IP address may traverse multiple segments of the network, 622 more flexibility is afforded to the Enforcement Device and the API 623 server: they simply must exist on a segment of the network where the 624 IP address is still unique. However, consider that a NAT may be 625 deployed between the User Equipment and the Enforcement Device. In 626 such cases, it is possible for the components to still uniquely 627 identify the device if they are aware of the port mapping. 629 In some situations, the User Equipment may have multiple IP 630 addresses, while still satisfying all of the recommended properties. 631 This raises some challenges to the components of the network. For 632 example, if the user equipment tries to access the network with 633 multiple IP addresses, should the enforcement device and API server 634 treat each IP address as a unique User Equipment, or should it tie 635 the multiple addresses together into one view of the subscriber? An 636 implementation MAY do either. Attention should be paid to IPv6 and 637 the fact that it is expected for a device to have multiple IPv6 638 addresses on a single link. In such cases, identification could be 639 performed by subnet, such as the /64 to which the IP belongs. 641 4. Solution Workflow 643 This section aims to improve understanding by describing a possible 644 workflow of solutions adhering to the architecture. 646 4.1. Initial Connection 648 This section describes a possible work-flow when User Equipment 649 initially joins a Captive Network. 651 1. The User Equipment joins the Captive Network by acquiring a DHCP 652 lease, RA, or similar, acquiring provisioning information. 654 2. The User Equipment learns the URI for the Captive Portal API from 655 the provisioning information (e.g., [RFC7710]). 657 3. The User Equipment accesses the CAPPORT API to receive parameters 658 of the Captive Network, including web-portal URI. (This step 659 replaces the clear-text query to a canary URL.) 661 4. If necessary, the User navigates the web portal to gain access to 662 the external network. 664 5. The Captive Portal API server indicates to the Captive Portal 665 Enforcement device that the User Equipment is allowed to access 666 the external network. 668 6. The User Equipment attempts a connection outside the captive 669 network 671 7. If the requirements have been satisfied, the access is permitted; 672 otherwise the "Expired" behavior occurs. 674 8. The User Equipment accesses the network until conditions Expire. 676 4.2. Conditions Expire 678 This section describes a possible work-flow when conditions expire 679 and the user visits the portal again (e.g., low quota, or time 680 expiry). 682 1. Precondition: the Captive Portal Enforcement has been configured 683 to detect an expiry condition, which has now occurred. 685 2. The User Equipment sends a packet to the outside network. 687 3. The Captive Portal Enforcement detects that the packet is from an 688 expired User Equipment. 690 4. The Captive Portal Enforcement sends a Captive Portal Signal to 691 the User Equipment indicating that it needs to refresh its 692 access. 694 5. The User Equipment verifies the signal is plausible. 696 6. The User Equipment queries the Captive Portal API to refresh 697 parameters and status of the Captive Network. 699 7. If necessary, the User once again navigates the web portal to 700 gain access to the external network. 702 8. The Captive Portal API Server gives more quota (time, bytes, 703 etc.) to the User Equipment by indicating to the Captive Portal 704 Enforcement the new, extended quota. 706 9. The User Equipment accesses the external network. 708 5. Acknowledgments 710 The authors thank Lorenzo Colitti for providing the majority of the 711 content for the Captive Portal Signal requirements. 713 The authors thank various individuals for their feedback on the 714 mailing list and during the IETF98 hackathon: David Bird, Erik Kline, 715 Alexis La Goulette, Alex Roscoe, Darshak Thakore, and Vincent van 716 Dam. 718 6. IANA Considerations 720 This memo includes no request to IANA. 722 7. Security Considerations 724 7.1. Trusting the Network 726 When joining a network, some trust is placed in the network operator. 727 This is usually considered to be a decision by a user on the basis of 728 the reputation of an organization. However, once a user makes such a 729 decision, protocols can support authenticating a network is operated 730 by who claims to be operating it. The Provisioning Domain 731 Architecture [RFC7556] provides some discussion on authenticating an 732 operator. 734 Given that a user chooses to visit a Captive Portal URI, the URI 735 location SHOULD be securely provided to the user's device. E.g., the 736 DHCPv6 AUTH option can sign this information. 738 If a user decides to incorrectly trust an attacking network, they 739 might be convinced to visit an attacking web page and unwittingly 740 provide credentials to an attacker. Browsers can authenticate 741 servers but cannot detect cleverly misspelled domains, for example. 743 7.2. Authenticated APIs 745 The solution described here assumes that when the User Equipment 746 needs to trust the API server, server authentication will be 747 performed using TLS mechanisms. 749 7.3. Secure APIs 751 The solution described here requires that the API be secured using 752 TLS. This is required to allow the user equipment and API server to 753 exchange secrets which can be used to validate future interactions. 755 The API must ensure the integrity of this information, as well as its 756 confidentiality. 758 7.4. Risk of Nuisance Captive Portal 760 It is possible for any user on the Internet to send signals in 761 attempt to cause the receiving equipment to go to the captive portal. 762 This has been considered and addressed in the following ways: 764 The signal only informs the User Equipment to query the API. It 765 does not carry any information which may mislead or misdirect the 766 User Equipment. 768 Even when responding to the signal, the User Equipment securely 769 authenticates with API servers. 771 Accesses to the API server are rate limited, limiting the impact 772 of a repeated attack. 774 7.5. User Options 776 The Signal informs the User Equipment that it is being held captive. 777 There is no requirement that the User Equipment do something about 778 this. Devices MAY permit users to disable automatic reaction to 779 captive-portal indications for privacy reasons. However, there is 780 the trade-off that the user doesn't get notified when network access 781 is restricted. Hence, end-user devices MAY allow users to manually 782 control captive portal interactions, possibly on the granularity of 783 Provisioning Domains. 785 8. References 787 8.1. Normative References 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, 791 DOI 10.17487/RFC2119, March 1997, 792 . 794 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 795 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 796 . 798 [RFC7710] Kumari, W., Gudmundsson, O., Ebersman, P., and S. Sheng, 799 "Captive-Portal Identification Using DHCP or Router 800 Advertisements (RAs)", RFC 7710, DOI 10.17487/RFC7710, 801 December 2015, . 803 8.2. Informative References 805 [I-D.ietf-intarea-provisioning-domains] 806 Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W. 807 Shao, "Discovering Provisioning Domain Names and Data", 808 draft-ietf-intarea-provisioning-domains-02 (work in 809 progress), June 2018. 811 [I-D.nottingham-capport-problem] 812 Nottingham, M., "Captive Portals Problem Statement", 813 draft-nottingham-capport-problem-01 (work in progress), 814 April 2016. 816 Authors' Addresses 818 Kyle Larose 819 Agilicus 821 Email: kyle@agilicus.com 823 David Dolson 825 Email: ddolson@acm.org