idnits 2.17.1 draft-ietf-capport-api-06.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 125: '... server endpoint MUST be accessed usin...' RFC 2119 keyword, line 126: '... and SHOULD be served on port 443 [RFC2818]. The client SHOULD NOT...' RFC 2119 keyword, line 128: '... same, and SHOULD rely on the discov...' RFC 2119 keyword, line 162: '...tname of the API SHOULD be displayed t...' RFC 2119 keyword, line 170: '... [RFC6066] SHOULD be used. OCSP stapling allows a client to perform...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (31 March 2020) is 1459 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) == Outdated reference: A later version (-11) exists of draft-ietf-capport-rfc7710bis-03 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) == Outdated reference: A later version (-10) exists of draft-ietf-capport-architecture-06 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: 2 October 2020 CableLabs 6 31 March 2020 8 Captive Portal API 9 draft-ietf-capport-api-06 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 2 October 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 . . . . . . . . . . . . . . . . . . . 7 59 7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 7 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 8.1. Captive Portal API JSON Media Type Registration . . . . . 7 62 8.2. Captive Portal API Keys Registry . . . . . . . . . . . . 8 63 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 10.2. Informative References . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 that a client browser can present to a user to get out of 82 captivity 84 * An encrypted connection (using TLS for connections to both the API 85 and user 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 API's defined 99 in this document to the client. This is also referred to as the 100 "API server" in this document. 102 3. Workflow 104 The Captive Portal Architecture defines several categories of 105 interaction between clients and Captive Portal systems: 107 1. Provisioning, in which a client discovers that a network has a 108 captive portal, and learns the URI of the API server. 110 2. API Server interaction, in which a client queries the state of 111 the captive portal and retrieves the necessary information to get 112 out of captivity. 114 3. Enforcement, in which the enforcement device in the network 115 blocks disallowed traffic. 117 This document defines the mechanisms used in the second category. It 118 is assumed that the location of the Captive Portal API server has 119 been discovered by the client as part of Provisioning. A set of 120 mechanisms for discovering the API Server endpoint is defined in 121 [I-D.ietf-capport-rfc7710bis]. 123 4. API Connection Details 125 The API server endpoint MUST be accessed using HTTP over TLS (HTTPS) 126 and SHOULD be served on port 443 [RFC2818]. The client SHOULD NOT 127 assume that the URI for a given network attachment will stay the 128 same, and SHOULD rely on the discovery or provisioning process each 129 time it joins the network. 131 For example, if the Captive Portal API server is hosted at 132 "example.org", the URI of the API could be "https://example.org/ 133 captive-portal/api" 135 As described in Section 3 of [I-D.ietf-capport-architecture], the 136 identity of the client needs to be visible to the Captive Portal API 137 server in order for the server to correctly reply with the client's 138 portal state. If the identifier used by the Captive Portal system is 139 the client's IP address, the system needs to ensure that the same IP 140 address is visible to both the API server and the enforcement device. 142 If the API server needs information about the client identity that is 143 not otherwise visible to it, the URI provided to the client during 144 provisioning can be distinct per client. Thus, depending on how the 145 Captive Portal system is configured, the URI might be unique for each 146 client host and between sessions for the same client host. 148 For example, a Captive Portal system that uses per-client session 149 URIs could use "https://example.org/captive-portal/api/X54PD" as its 150 API URI. 152 4.1. Server Authentication 154 The purpose of accessing the Captive Portal API over an HTTPS 155 connection is twofold: first, the encrypted connection protects the 156 integrity and confidentiality of the API exchange from other parties 157 on the local network; and second, it provides the client of the API 158 an opportunity to authenticate the server that is hosting the API. 159 This authentication is aimed at allowing a user to be reasonably 160 confident that the entity providing the Captive Portal API has a 161 valid certificate for the hostname in the URI (such as 162 "example.com"). The hostname of the API SHOULD be displayed to the 163 user in order to indicate the entity which is providing the API 164 service. 166 Clients performing revocation checking will need some means of 167 accessing revocation information for certificates presented by the 168 API server. Online Certificate Status Protocol [RFC6960] (OCSP) 169 stapling, using the TLS Certificate Status Request extension 170 [RFC6066] SHOULD be used. OCSP stapling allows a client to perform 171 revocation checks without initiating new connections. To allow for 172 other forms of revocation checking, a captive network could permit 173 connections to OCSP responders or Certificate Revocation Lists (CRLs) 174 that are referenced by certificates provided by the API server. In 175 addition to connections to OCSP responders and CRLs, a captive 176 network SHOULD also permit connections to Network Time Protocol (NTP) 177 [RFC5905] servers or other time-sync mechnisms to allow clients to 178 accurately validate certificates. 180 Certificates with missing intermediate certificates that rely on 181 clients validating the certificate chain using the URI specified in 182 the Authority Information Access (AIA) extension [RFC5280] SHOULD NOT 183 be used by the Captive Portal API server. If the certificates do 184 require the use of AIA, the captive network MUST allow client access 185 to the host specified in the URI. 187 If the client is unable to validate the certificate presented by the 188 API server, it MUST NOT proceed with any of the behavior for API 189 interaction described in this document. The client will proceed to 190 interact with the captive network as if the API capabilities were not 191 present. It may still be possible for the user to access the network 192 by being redirected to a web portal. 194 5. API State Structure 196 The Captive Portal API data structures are specified in JavaScript 197 Object Notation (JSON) [RFC8259]. Requests and responses for the 198 Captive Portal API use the "application/captive+json" media type. 199 Clients SHOULD include this media type as an Accept header in their 200 GET requests, and servers MUST mark this media type as their Content- 201 Type header in responses. 203 The following key MUST be included in the top-level of the JSON 204 structure returned by the API server: 206 * "captive" (boolean): indicates whether the client is in a state of 207 captivity, i.e it has not satisfied the conditions to access the 208 external network. If the client is captive (i.e. captive=true), 209 it can still be allowed enough access for it to perform server 210 authentication Section 4.1. 212 The following keys can be optionally included in the top-level of the 213 JSON structure returned by the API server: 215 * "user-portal-url" (string): provides the URL of a web portal with 216 which a user can interact. 218 * "venue-info-url" (string): provides the URL of a webpage or site 219 on which the operator of the network has information that it 220 wishes to share with the user (e.g., store info, maps, flight 221 status, or entertainment). 223 * "can-extend-session" (boolean): indicates that the URL specified 224 as "user-portal-url" allows the user to extend a session once the 225 client is no longer in a state of captivity. This provides a hint 226 that a client system can suggest accessing the portal URL to the 227 user when the session is near its limit in terms of time or bytes. 229 * "seconds-remaining" (integer): indicates the number of seconds 230 remaining, after which the client will be placed into a captive 231 state. The API server SHOULD include this value if the client is 232 not captive (i.e. captive=false) and the client session is time- 233 limited, and SHOULD omit this value for captive clients (i.e. 234 captive=true). 236 * "bytes-remaining" (integer): indicates the number of bytes 237 remaining, after which the client will be in placed into a captive 238 state. The byte count represents the sum of the total number of 239 IP packet (layer 3) bytes sent and received by the client. 240 Captive portal systems might not count traffic to whitelisted 241 servers, such as the API server, but clients cannot rely on such 242 behavior. The API server SHOULD include this value if the client 243 is not captive (i.e. captive=false) and the client session is 244 byte-limited, and SHOULD omit this value for captive clients (i.e. 245 captive=true). 247 The valid JSON keys can be extended by adding entries to the Captive 248 Portal API Keys Registry Section 8. If a client receives a key that 249 it does not recognize, it MUST ignore the key and any associated 250 values. All keys other than the ones defined in this document as 251 "required" will be considered optional. 253 6. Example Interaction 255 A client connected to a captive network upon discovering the URI of 256 the API server will query the API server to retrieve information 257 about its captive state and conditions to escape captivity. To 258 request the Captive Portal JSON content, a client sends an HTTP GET 259 request: 261 GET /captive-portal/api/X54PD 262 Host: example.org 263 Accept: application/captive+json 265 The server then responds with the JSON content for that client: 267 HTTP/1.1 200 OK 268 Cache-Control: private 269 Date: Mon, 02 Mar 2020 05:07:35 GMT 270 Content-Type: application/captive+json 272 { 273 "captive": true, 274 "user-portal-url": "https://example.org/portal.html", 275 "venue-info-url": "https://flight.example.com/entertainment", 276 "seconds-remaining": 326, 277 "can-extend-session": true 278 } 280 Upon receiving this information the client will provide this 281 information to the user so that they may navigate the web portal (as 282 specified by the user-portal-url value) to enable access to the 283 external network. Once the user satisfies the requirements for 284 extenal network access, the client SHOULD query the API server again 285 to verify that it is no longer captive. 287 Captive Portal JSON content can contain per-client data that is not 288 appropriate to store in an intermediary cache. Captive Portal API 289 servers SHOULD set the Cache-Control header in any responses to 290 "private", or a more restrictive value [RFC7234]. 292 7. Security Considerations 294 One of the goals of this protocol is to improve the security of the 295 communication between client hosts and Captive Portal systems. 296 Client traffic is protected from passive listeners on the local 297 network by requiring TLS-encrypted connections between the client and 298 the Captive Portal API server, as described in Section 4. All 299 communication between the clients and the API server MUST be 300 encrypted. 302 In addition to encrypting communications between clients and Captive 303 Portal systems, this protocol requires a basic level of 304 authentication from the API server, as described in Section 4.1. 305 Specifically, the API server MUST present a valid certificate on 306 which the client can perform revocation checks. This allows the 307 client to ensure that the API server has authority for a hostname 308 that can be presented to a user. 310 It is important to note that while the server authentication checks 311 can validate a specific hostname, it is certainly possible for the 312 API server to present a valid certificate for a hostname that uses 313 non-standard characters or is otherwise designed to trick the user 314 into believing that its hostname is some other, more trustworthy, 315 name. This is a danger of any scenario in which a hostname is not 316 typed in by a user. 318 7.1. Privacy Considerations 320 Information passed between a client and a Captive Portal system may 321 include a user's personal information, such as a full name and credit 322 card details. Therefore, it is important that Captive Portal API 323 Servers do not allow access to the Captive Portal API over 324 unencrypted sessions. 326 8. IANA Considerations 328 IANA is requested to create a registration for an "application/ 329 captive+json" media type (Section 8.1) and a registry for fields in 330 that format (Section 8.2). 332 8.1. Captive Portal API JSON Media Type Registration 334 This document registers the media type for Captive Portal API JSON 335 text, "application/captive+json". 337 Type name: application 339 Subtype name: captive+json 341 Required parameters: None 343 Optional parameters: None 345 Encoding considerations: Encoding considerations are identical to 346 those specified for the "application/json" media type. 348 Security considerations: See Section 7 350 Interoperability considerations: This document specifies format of 351 conforming messages and the interpretation thereof. 353 Published specification: This document 355 Applications that use this media type: This media type is intended 356 to be used by servers presenting the Captive Portal API, and 357 clients connecting to such captive networks. 359 Additional information: None 361 Person & email address to contact for further information: See 362 Authors' Addresses section. 364 Intended usage: COMMON 366 Restrictions on usage: None 368 Author: CAPPORT IETF WG 370 Change controller: IETF 372 8.2. Captive Portal API Keys Registry 374 IANA is asked to create and maintain a new registry called "Captive 375 Portal API Keys", which will reserve JSON keys for use in Captive 376 Portal API data structures. The initial contents of this registry 377 are provided in Section 5. 379 Each entry in the registry contains the following fields: 381 Key: The JSON key being registered, in string format. 383 Type: The type of the JSON value to be stored, as one of the value 384 types defined in [RFC8259]. 386 Description: A brief description explaining the meaning of the 387 value, how it might be used, and/or how it should be interpreted 388 by clients. 390 New assignments for Captive Portal API Keys Registry will be 391 administered by IANA through Expert Review [RFC8126]. The Designated 392 Expert is expected to validate the existence of documentation 393 describing new keys in a permanent publicly available specification. 394 The expert is expected to validate that new keys have a clear meaning 395 and do not create unnecessary confusion or overlap with existing 396 keys. Keys that are specific to non-generic use cases, particularly 397 ones that are not specified as part of an IETF document, are 398 encouraged to use a domain-specific prefix. 400 9. Acknowledgments 402 This work in this document was started by Mark Donnelly and Margaret 403 Cullen. Thanks to everyone in the CAPPORT Working Group who has 404 given input. 406 10. References 408 10.1. Normative References 410 [I-D.ietf-capport-rfc7710bis] 411 Kumari, W. and E. Kline, "Captive-Portal Identification in 412 DHCP / RA", Work in Progress, Internet-Draft, draft-ietf- 413 capport-rfc7710bis-03, 30 March 2020, 414 . 417 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 418 DOI 10.17487/RFC2818, May 2000, 419 . 421 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 422 Housley, R., and W. Polk, "Internet X.509 Public Key 423 Infrastructure Certificate and Certificate Revocation List 424 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 425 . 427 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 428 "Network Time Protocol Version 4: Protocol and Algorithms 429 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 430 . 432 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 433 Extensions: Extension Definitions", RFC 6066, 434 DOI 10.17487/RFC6066, January 2011, 435 . 437 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 438 Galperin, S., and C. Adams, "X.509 Internet Public Key 439 Infrastructure Online Certificate Status Protocol - OCSP", 440 RFC 6960, DOI 10.17487/RFC6960, June 2013, 441 . 443 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 444 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 445 RFC 7234, DOI 10.17487/RFC7234, June 2014, 446 . 448 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 449 Writing an IANA Considerations Section in RFCs", BCP 26, 450 RFC 8126, DOI 10.17487/RFC8126, June 2017, 451 . 453 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 454 Interchange Format", STD 90, RFC 8259, 455 DOI 10.17487/RFC8259, December 2017, 456 . 458 10.2. Informative References 460 [I-D.ietf-capport-architecture] 461 Larose, K., Dolson, D., and H. Liu, "CAPPORT 462 Architecture", Work in Progress, Internet-Draft, draft- 463 ietf-capport-architecture-06, 15 February 2020, 464 . 467 Authors' Addresses 469 Tommy Pauly (editor) 470 Apple Inc. 471 One Apple Park Way 472 Cupertino, California 95014, 473 United States of America 475 Email: tpauly@apple.com 477 Darshak Thakore (editor) 478 CableLabs 479 858 Coal Creek Circle 480 Louisville, CO 80027, 481 United States of America 483 Email: d.thakore@cablelabs.com