idnits 2.17.1 draft-ietf-capport-api-08.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 (18 June 2020) is 1407 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) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) == Outdated reference: A later version (-10) exists of draft-ietf-capport-architecture-08 == Outdated reference: A later version (-11) exists of draft-ietf-capport-rfc7710bis-07 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Captive Portal Interaction T. Pauly, Ed. 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track D. Thakore, Ed. 5 Expires: 20 December 2020 CableLabs 6 18 June 2020 8 Captive Portal API 9 draft-ietf-capport-api-08 11 Abstract 13 This document describes an HTTP API that allows clients to interact 14 with a Captive Portal system. With this API, clients can discover 15 how to get out of captivity and fetch state about their Captive 16 Portal sessions. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 20 December 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. API Connection Details . . . . . . . . . . . . . . . . . . . 3 55 4.1. Server Authentication . . . . . . . . . . . . . . . . . . 4 56 5. API State Structure . . . . . . . . . . . . . . . . . . . . . 5 57 6. Example Interaction . . . . . . . . . . . . . . . . . . . . . 6 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 8.1. Captive Portal API JSON Media Type Registration . . . . . 9 62 8.2. Captive Portal API Keys Registry . . . . . . . . . . . . 9 63 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 66 10.2. Informative References . . . . . . . . . . . . . . . . . 12 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 This document describes a HyperText Transfer Protocol (HTTP) 72 Application Program Interface (API) that allows clients to interact 73 with a Captive Portal system. The API defined in this document has 74 been designed to meet the requirements in the Captive Portal 75 Architecture [I-D.ietf-capport-architecture]. Specifically, the API 76 provides: 78 * The state of captivity (whether or not the client has access to 79 the Internet) 81 * A URI of a user-facing web portal that can be used to get out of 82 captivity 84 * Authenticated and encrypted connections, using TLS for connections 85 to both the API and user-facing web portal 87 2. Terminology 89 This document leverages the terminology and components described in 90 [I-D.ietf-capport-architecture] and additionally defines the 91 following terms: 93 * Captive Portal Client: The client that interacts with the Captive 94 Portal API is typically some application running on the User 95 Equipment that is connected to the Captive Network. This is also 96 referred to as the "client" in this document. 98 * Captive Portal API Server: The server exposing the APIs defined in 99 this document to the client. This is also referred to as the "API 100 server" in this document. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 3. Workflow 110 The Captive Portal Architecture defines several categories of 111 interaction between clients and Captive Portal systems: 113 1. Provisioning, in which a client discovers that a network has a 114 captive portal, and learns the URI of the API server. 116 2. API Server interaction, in which a client queries the state of 117 captivity and retrieves the necessary information to get out of 118 captivity. 120 3. Enforcement, in which the enforcement device in the network 121 blocks disallowed traffic. 123 This document defines the mechanisms used in the second category. It 124 is assumed that the location of the Captive Portal API server has 125 been discovered by the client as part of Provisioning. A set of 126 mechanisms for discovering the API Server endpoint is defined in 127 [I-D.ietf-capport-rfc7710bis]. 129 4. API Connection Details 131 The API server endpoint MUST be accessed over HTTP using an https URI 132 [RFC2818], and SHOULD use the default https port. For example, if 133 the Captive Portal API server is hosted at "example.org", the URI of 134 the API could be "https://example.org/captive-portal/api" 136 The client SHOULD NOT assume that the URI of the API server for a 137 given network will stay the same, and SHOULD rely on the discovery or 138 provisioning process each time it joins the network. 140 As described in Section 3 of [I-D.ietf-capport-architecture], the 141 identity of the client needs to be visible to the Captive Portal API 142 server in order for the server to correctly reply with the client's 143 portal state. If the identifier used by the Captive Portal system is 144 the client's set of IP addresses, the system needs to ensure that the 145 same IP addresses are visible to both the API server and the 146 enforcement device. 148 If the API server needs information about the client identity that is 149 not otherwise visible to it, the URI provided to the client during 150 provisioning SHOULD be distinct per client. Thus, depending on how 151 the Captive Portal system is configured, the URI will be unique for 152 each client host and between sessions for the same client host. 154 For example, a Captive Portal system that uses per-client session 155 URIs could use "https://example.org/captive-portal/api/X54PD39JV" as 156 its API URI. 158 4.1. Server Authentication 160 The purpose of accessing the Captive Portal API over an HTTPS 161 connection is twofold: first, the encrypted connection protects the 162 integrity and confidentiality of the API exchange from other parties 163 on the local network; and second, it provides the client of the API 164 an opportunity to authenticate the server that is hosting the API. 165 This authentication allows the client to ensure that the entity 166 providing the Captive Portal API has a valid certificate for the 167 hostname provisioned by the network using the mechanisms defined in 168 [I-D.ietf-capport-rfc7710bis], by validating that a DNS-ID [RFC6125] 169 on the certificate is equal to the provisioned hostname. 171 Clients performing revocation checking will need some means of 172 accessing revocation information for certificates presented by the 173 API server. Online Certificate Status Protocol [RFC6960] (OCSP) 174 stapling, using the TLS Certificate Status Request extension 175 [RFC6066] SHOULD be used. OCSP stapling allows a client to perform 176 revocation checks without initiating new connections. To allow for 177 other forms of revocation checking, especially for clients that do 178 not support OCSP stapling, a captive network SHOULD permit 179 connections to OCSP responders or Certificate Revocation Lists (CRLs) 180 that are referenced by certificates provided by the API server. For 181 more discussion on certificate revocation checks, see Section 6.5 of 182 BCP 195 [RFC7525]. In addition to connections to OCSP responders and 183 CRLs, a captive network SHOULD also permit connections to Network 184 Time Protocol (NTP) [RFC5905] servers or other time-sync mechanisms 185 to allow clients to accurately validate certificates. 187 Certificates with missing intermediate certificates that rely on 188 clients validating the certificate chain using the URI specified in 189 the Authority Information Access (AIA) extension [RFC5280] SHOULD NOT 190 be used by the Captive Portal API server. If the certificates do 191 require the use of AIA, the captive network MUST allow client access 192 to the host specified in the URI. 194 If the client is unable to validate the certificate presented by the 195 API server, it MUST NOT proceed with any of the behavior for API 196 interaction described in this document. The client will proceed to 197 interact with the captive network as if the API capabilities were not 198 present. It may still be possible for the user to access the network 199 if the network redirects a cleartext webpage to a web portal. 201 5. API State Structure 203 The Captive Portal API data structures are specified in JavaScript 204 Object Notation (JSON) [RFC8259]. Requests and responses for the 205 Captive Portal API use the "application/captive+json" media type. 206 Clients SHOULD include this media type as an Accept header in their 207 GET requests, and servers MUST mark this media type as their Content- 208 Type header in responses. 210 The following key MUST be included in the top-level of the JSON 211 structure returned by the API server: 213 * "captive" (boolean): indicates whether the client is in a state of 214 captivity, i.e it has not satisfied the conditions to access the 215 external network. If the client is captive (i.e. captive=true), 216 it will still be allowed enough access for it to perform server 217 authentication (Section 4.1). 219 The following keys can be optionally included in the top-level of the 220 JSON structure returned by the API server: 222 * "user-portal-url" (string): provides the URL of a web portal that 223 MUST be accessed over TLS with which a user can interact. 225 * "venue-info-url" (string): provides the URL of a webpage or site 226 that SHOULD be accessed over TLS on which the operator of the 227 network has information that it wishes to share with the user 228 (e.g., store info, maps, flight status, or entertainment). 230 * "can-extend-session" (boolean): indicates that the URL specified 231 as "user-portal-url" allows the user to extend a session once the 232 client is no longer in a state of captivity. This provides a hint 233 that a client system can suggest accessing the portal URL to the 234 user when the session is near its limit in terms of time or bytes. 236 * "seconds-remaining" (number): an integer that indicates the number 237 of seconds remaining, after which the client will be placed into a 238 captive state. The API server SHOULD include this value if the 239 client is not captive (i.e. captive=false) and the client session 240 is time-limited, and SHOULD omit this value for captive clients 241 (i.e. captive=true) or when the session is not time-limited. 243 * "bytes-remaining" (number): an integer that indicates the number 244 of bytes remaining, after which the client will be in placed into 245 a captive state. The byte count represents the sum of the total 246 number of IP packet (layer 3) bytes sent and received by the 247 client, including IP headers. Captive portal systems might not 248 count traffic to whitelisted servers, such as the API server, but 249 clients cannot rely on such behavior. The API server SHOULD 250 include this value if the client is not captive (i.e. 251 captive=false) and the client session is byte-limited, and SHOULD 252 omit this value for captive clients (i.e. captive=true) or when 253 the session is not byte-limited. 255 The valid JSON keys can be extended by adding entries to the Captive 256 Portal API Keys Registry (Section 8). If a client receives a key 257 that it does not recognize, it MUST ignore the key and any associated 258 values. All keys other than the ones defined in this document as 259 "required" will be considered optional. 261 Captive Portal JSON content can contain per-client data that is not 262 appropriate to store in an intermediary cache. Captive Portal API 263 servers SHOULD set the Cache-Control header field in any responses to 264 "private", or a more restrictive value such as "no-store" [RFC7234]. 266 Client behavior for issuing requests for updated JSON content is 267 implementation-specific, and can be based on user interaction or the 268 indications of seconds and bytes remaining in a given session. If at 269 any point the client does not receive valid JSON content from the API 270 server, either due to an error or due to receiving no response, the 271 client SHOULD continue to apply the most recent valid content it had 272 received; or, if no content had been received previously, proceed to 273 interact with the captive network as if the API capabilities were not 274 present. 276 6. Example Interaction 278 A client connected to a captive network upon discovering the URI of 279 the API server will query the API server to retrieve information 280 about its captive state and conditions to escape captivity. In this 281 example, the client discovered the URI "https://example.org/captive- 282 portal/api/X54PD39JV" using one of the mechanisms defined in 283 [I-D.ietf-capport-rfc7710bis]. 285 To request the Captive Portal JSON content, a client sends an HTTP 286 GET request: 288 GET /captive-portal/api/X54PD39JV HTTP/1.1 289 Host: example.org 290 Accept: application/captive+json 292 The server then responds with the JSON content for that client: 294 HTTP/1.1 200 OK 295 Cache-Control: private 296 Date: Mon, 02 Mar 2020 05:07:35 GMT 297 Content-Type: application/captive+json 299 { 300 "captive": true, 301 "user-portal-url": "https://example.org/portal.html" 302 } 304 Upon receiving this information the client will use this information 305 to direct the user to the web portal (as specified by the user- 306 portal-url value) to enable access to the external network. Once the 307 user satisfies the requirements for external network access, the 308 client SHOULD query the API server again to verify that it is no 309 longer captive. 311 When the client requests the Captive Portal JSON content after 312 gaining external network access, the server responds with updated 313 JSON content: 315 HTTP/1.1 200 OK 316 Cache-Control: private 317 Date: Mon, 02 Mar 2020 05:08:13 GMT 318 Content-Type: application/captive+json 320 { 321 "captive": false, 322 "user-portal-url": "https://example.org/portal.html", 323 "venue-info-url": "https://flight.example.com/entertainment", 324 "seconds-remaining": 326, 325 "can-extend-session": true 326 } 328 7. Security Considerations 330 One of the goals of this protocol is to improve the security of the 331 communication between client hosts and Captive Portal systems. 332 Client traffic is protected from passive listeners on the local 333 network by requiring TLS-encrypted connections between the client and 334 the Captive Portal API server, as described in Section 4. All 335 communication between the clients and the API server MUST be 336 encrypted. 338 In addition to encrypting communications between clients and Captive 339 Portal systems, this protocol requires a basic level of 340 authentication from the API server, as described in Section 4.1. 341 Specifically, the API server MUST present a valid certificate on 342 which the client can perform revocation checks. This allows the 343 client to ensure that the API server has authority for the hostname 344 that was provisioned by the network using 345 [I-D.ietf-capport-rfc7710bis]. Note that this validation only 346 confirms that the API server matches what the network's provisioning 347 mechanism (such as DHCP or IPv6 Router Advertisements) provided, and 348 not validating the security of those provisioning mechanisms or the 349 user's trust relationship to the network. 351 7.1. Privacy Considerations 353 Information passed between a client and the user-facing web portal 354 may include a user's personal information, such as a full name and 355 credit card details. Therefore, it is important that both the user- 356 facing web portal and the API server that points a client to the web 357 portal are only accessed over encrypted connections. 359 It is important to note that although communication to the user- 360 facing web portal requires using TLS, the authentication only 361 validates that the web portal server matches the name in the URI 362 provided by the API server. Since this is not a name that a user 363 typed in, the hostname of the web site that would be presented to the 364 user may include "confusable characters" that can mislead the user. 365 See Section 12.5 of [RFC8264] for a discussion of confusable 366 characters. 368 8. IANA Considerations 370 IANA is requested to create a registration for an "application/ 371 captive+json" media type (Section 8.1) and a registry for fields in 372 that format (Section 8.2). 374 8.1. Captive Portal API JSON Media Type Registration 376 This document registers the media type for Captive Portal API JSON 377 text, "application/captive+json". 379 Type name: application 381 Subtype name: captive+json 383 Required parameters: N/A 385 Optional parameters: N/A 387 Encoding considerations: Encoding considerations are identical to 388 those specified for the "application/json" media type. 390 Security considerations: See Section 7 392 Interoperability considerations: This document specifies format of 393 conforming messages and the interpretation thereof. 395 Published specification: This document 397 Applications that use this media type: This media type is intended to 398 be used by servers presenting the Captive Portal API, and clients 399 connecting to such captive networks. 401 Fragment identifier considerations: N/A 403 Additional information: N/A 405 Person and email address to contact for further information: See 406 Authors' Addresses section 408 Intended usage: COMMON 410 Restrictions on usage: N/A 412 Author: CAPPORT IETF WG 414 Change controller: IETF 416 8.2. Captive Portal API Keys Registry 418 IANA is asked to create and maintain a new registry called "Captive 419 Portal API Keys", which will reserve JSON keys for use in Captive 420 Portal API data structures. The initial contents of this registry 421 are provided in Section 5. 423 Each entry in the registry contains the following fields: 425 Key: The JSON key being registered, in string format. 427 Type: The type of the JSON value to be stored, as one of the value 428 types defined in [RFC8259]. 430 Description: A brief description explaining the meaning of the 431 value, how it might be used, and/or how it should be interpreted 432 by clients. 434 Specification: A reference to a specification that defines the key 435 and explains its usage. 437 New assignments for Captive Portal API Keys Registry will be 438 administered by IANA using the Specification Required policy 439 [RFC8126]. The Designated Expert is expected to validate the 440 existence of documentation describing new keys in a permanent 441 publicly available specification, such as an Internet Draft or RFC. 442 The expert is expected to validate that new keys have a clear meaning 443 and do not create unnecessary confusion or overlap with existing 444 keys. Keys that are specific to non-generic use cases, particularly 445 ones that are not specified as part of an IETF document, are 446 encouraged to use a domain-specific prefix. 448 9. Acknowledgments 450 This work in this document was started by Mark Donnelly and Margaret 451 Cullen. Thanks to everyone in the CAPPORT Working Group who has 452 given input. 454 10. References 456 10.1. Normative References 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, 460 DOI 10.17487/RFC2119, March 1997, 461 . 463 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 464 DOI 10.17487/RFC2818, May 2000, 465 . 467 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 468 Housley, R., and W. Polk, "Internet X.509 Public Key 469 Infrastructure Certificate and Certificate Revocation List 470 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 471 . 473 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 474 "Network Time Protocol Version 4: Protocol and Algorithms 475 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 476 . 478 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 479 Extensions: Extension Definitions", RFC 6066, 480 DOI 10.17487/RFC6066, January 2011, 481 . 483 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 484 Verification of Domain-Based Application Service Identity 485 within Internet Public Key Infrastructure Using X.509 486 (PKIX) Certificates in the Context of Transport Layer 487 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 488 2011, . 490 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 491 Galperin, S., and C. Adams, "X.509 Internet Public Key 492 Infrastructure Online Certificate Status Protocol - OCSP", 493 RFC 6960, DOI 10.17487/RFC6960, June 2013, 494 . 496 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 497 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 498 RFC 7234, DOI 10.17487/RFC7234, June 2014, 499 . 501 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 502 Writing an IANA Considerations Section in RFCs", BCP 26, 503 RFC 8126, DOI 10.17487/RFC8126, June 2017, 504 . 506 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 507 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 508 May 2017, . 510 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 511 Interchange Format", STD 90, RFC 8259, 512 DOI 10.17487/RFC8259, December 2017, 513 . 515 10.2. Informative References 517 [I-D.ietf-capport-architecture] 518 Larose, K., Dolson, D., and H. Liu, "CAPPORT 519 Architecture", Work in Progress, Internet-Draft, draft- 520 ietf-capport-architecture-08, 11 May 2020, 521 . 524 [I-D.ietf-capport-rfc7710bis] 525 Kumari, W. and E. Kline, "Captive-Portal Identification in 526 DHCP / RA", Work in Progress, Internet-Draft, draft-ietf- 527 capport-rfc7710bis-07, 23 May 2020, . 530 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 531 "Recommendations for Secure Use of Transport Layer 532 Security (TLS) and Datagram Transport Layer Security 533 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 534 2015, . 536 [RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 537 Preparation, Enforcement, and Comparison of 538 Internationalized Strings in Application Protocols", 539 RFC 8264, DOI 10.17487/RFC8264, October 2017, 540 . 542 Authors' Addresses 544 Tommy Pauly (editor) 545 Apple Inc. 546 One Apple Park Way 547 Cupertino, California 95014, 548 United States of America 550 Email: tpauly@apple.com 552 Darshak Thakore (editor) 553 CableLabs 554 858 Coal Creek Circle 555 Louisville, CO 80027, 556 United States of America 558 Email: d.thakore@cablelabs.com