idnits 2.17.1 draft-ietf-capport-api-04.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: '...the API endpoint MUST be accessed usin...' RFC 2119 keyword, line 126: '... (HTTPS) and SHOULD be served on port 443 [RFC2818]. The client...' RFC 2119 keyword, line 127: '... SHOULD NOT assume that the URI for ...' RFC 2119 keyword, line 128: '...ay the same, and SHOULD rely on the di...' RFC 2119 keyword, line 150: '...tname of the API SHOULD be displayed t...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 January 2020) is 1576 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) == Outdated reference: A later version (-10) exists of draft-ietf-capport-architecture-05 Summary: 2 errors (**), 0 flaws (~~), 2 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: 5 July 2020 CableLabs 6 2 January 2020 8 Captive Portal API 9 draft-ietf-capport-api-04 11 Abstract 13 This document describes an HTTP API that allows clients to interact 14 with a Captive Portal system. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 5 July 2020. 33 Copyright Notice 35 Copyright (c) 2020 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. API Details . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4.1. URI of Captive Portal API endpoint . . . . . . . . . . . 3 54 4.1.1. Server Authentication . . . . . . . . . . . . . . . . 4 55 4.2. JSON Keys . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.3. Example Interaction . . . . . . . . . . . . . . . . . . . 6 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 7 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 6.1. Captive Portal API JSON Media Type Registration . . . . . 7 61 6.2. Captive Portal API Keys Registry . . . . . . . . . . . . 8 62 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 8.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 This document describes a HyperText Transfer Protocol (HTTP) 71 Application Program Interface (API) that allows clients to interact 72 with a Captive Portal system. The API defined in this document has 73 been designed to meet the requirements in the Captive Portal 74 Architecture [I-D.ietf-capport-architecture]. Specifically, the API 75 provides: 77 * The state of captivity (whether or not the client has access to 78 the Internet) 80 * A URI that a client browser can present to a user to get out of 81 captivity 83 * An encrypted connection (TLS for both the API and portal URI) 85 2. Terminology 87 This document leverages the terminology and components described in 88 [I-D.ietf-capport-architecture] and additionally uses the following 89 association: 91 * Captive Portal Client: The client that interacts with the Captive 92 Portal API is typically some application running on the User 93 Equipment that is connected to the Captive Network. This is also 94 referred to as the "client" in this document. 96 * Captive Portal API Server: The server exposing the API's defined 97 in this document to the client. This is also referred to as the 98 "API server" in this document. 100 3. Workflow 102 The Captive Portal Architecture defines several categories of 103 interaction between clients and Captive Portal systems: 105 1. Provisioning, in which a client discovers that a network has a 106 captive portal, and learns the URI of the API server. 108 2. API Server interaction, in which a client queries the state of 109 the captive portal and retrieves the necessary information to get 110 out of captivity. 112 3. Enforcement, in which the enforcement device in the network 113 blocks disallowed traffic. 115 This document defines the mechanisms used in the second category. It 116 is assumed that the location of the Captive Portal API server has 117 been discovered by the client as part of Provisioning. The mechanism 118 for discovering the API Server endpoint is not covered by this 119 document. 121 4. API Details 123 4.1. URI of Captive Portal API endpoint 125 The URI of the API endpoint MUST be accessed using HTTP over TLS 126 (HTTPS) and SHOULD be served on port 443 [RFC2818]. The client 127 SHOULD NOT assume that the URI for a given network attachment will 128 stay the same, and SHOULD rely on the discovery or provisioning 129 process each time it joins the network. Depending on how the Captive 130 Portal system is configured, the URI might be unique for each client 131 host and between sessions for the same client host. 133 For example, if the Captive Portal API server is hosted at 134 example.org, the URI's of the API could be: 136 * "https://example.org/captive-portal/api" 138 * "https://example.org/captive-portal/api/X54PD" 140 4.1.1. Server Authentication 142 The purpose of accessing the Captive Portal API over an HTTPS 143 connection is twofold: first, the encrypted connection protects the 144 integrity and confidentiality of the API exchange from other parties 145 on the local network; and second, it provides the client of the API 146 an opportunity to authenticate the server that is hosting the API. 147 This authentication is aimed at allowing a user to be reasonably 148 confident that the entity providing the Captive Portal API has a 149 valid certificate for the hostname in the URI (such as 150 "example.com"). The hostname of the API SHOULD be displayed to the 151 user in order to indicate the entity which is providing the API 152 service. 154 Clients performing revocation checking will need some means of 155 accessing revocation information for certificates presented by the 156 API server. Online Certificate Status Protocol [RFC6960] (OCSP) 157 stapling, using the TLS Certificate Status Request extension 158 [RFC6066] SHOULD be used. OCSP stapling allows a client to perform 159 revocation checks without initiating new connections. To allow for 160 other forms of revocation checking, a captive network could permit 161 connections to OCSP responders or Certificate Revocation Lists (CRLs) 162 that are referenced by certificates provided by the API server. In 163 addition to connections to OCSP responders and CRLs, a captive 164 network SHOULD also permit connections to Network Time Protocol (NTP) 165 [RFC5905] servers or other time-sync mechnisms to allow clients to 166 accurately validate certificates. 168 Certificates with missing intermediate certificates that rely on 169 clients validating the certificate chain using the URI specified in 170 the Authority Information Access (AIA) extension [RFC5280] SHOULD NOT 171 be used by the Captive Portal API server. If the certificates do 172 require the use of AIA, the captive network will need to allow client 173 access to the host specified in the URI. 175 If the client is unable to validate the certificate presented by the 176 API server, it MUST NOT proceed with any of the behavior for API 177 interaction described in this document. The client will proceed to 178 interact with the captive network as if the API capabilities were not 179 present. It may still be possible for the user to access the network 180 by being redirected to a web portal. 182 4.2. JSON Keys 184 The Captive Portal API data structures are specified in JavaScript 185 Object Notation (JSON) [RFC8259]. Requests and responses for the 186 Captive Portal API use the "application/captive+json" media type. 187 Clients SHOULD include this media type as an Accept header in their 188 GET requests, and servers MUST mark this media type as their Content- 189 Type header in responses. 191 The following keys are defined at the top-level of the JSON structure 192 returned by the API server: 194 * "captive" (required, boolean): indicates whether the client is in 195 a state of captivity, i.e it has not satisfied the conditions to 196 access the external network. If the client is captive (i.e. 197 captive=true), it can still be allowed enough access for it to 198 perform server authentication Section 4.1.1. 200 * "user-portal-url" (optional, string): provides the URL of a web 201 portal with which a user can interact. 203 * "venue-info-url" (optional, string): provides the URL of a webpage 204 or site on which the operator of the network has information that 205 it wishes to share with the user (e.g., store info, maps, flight 206 status, or entertainment). 208 * "seconds-remaining" (optional, integer): indicates the number of 209 seconds remaining, after which the client will be placed into a 210 captive state. The API server SHOULD include this value if the 211 client is not captive (i.e. captive=false) and SHOULD omit this 212 value for captive clients. 214 * "bytes-remaining" (optional, integer): indicates the number of 215 bytes remaining, after which the client will be in placed into a 216 captive state. The byte count represents the total number of IP 217 packet (layer 3) bytes sent and received by the client. Captive 218 portal systems might not count traffic to whitelisted servers, 219 such as the API server, but clients cannot rely on such behavior. 221 The valid JSON keys can be extended by adding entries to the Captive 222 Portal API Keys Registry Section 6. If a client receives a key that 223 it does not recognize, it MUST ignore the key and any associated 224 values. All keys other than the ones defined in this document as 225 "required" will be considered optional. 227 4.3. Example Interaction 229 A client connected to a captive network upon discovering the URI of 230 the API server will query the API server to retrieve information 231 about its captive state and conditions to escape captivity. To 232 request the Captive Portal JSON content, a client sends an HTTP GET 233 request: 235 GET /captive-portal/api/X54PD 236 Host: example.org 237 Accept: application/captive+json 239 The server then responds with the JSON content for that client: 241 HTTP/1.1 200 OK 242 Cache-Control: private 243 Date: Mon, 04 Dec 2013 05:07:35 GMT 244 Content-Type: application/captive+json 246 { 247 "captive": true, 248 "user-portal-url": "https://example.org/portal.html", 249 "venue-info-url": "https://flight.example.com/entertainment", 250 "expire-date": "2014-01-01T23:28:56.782Z" 251 } 253 Upon receiving this information the client will provide this 254 information to the user so that they may navigate the web portal (as 255 specified by the user-portal-url value) to enable access to the 256 external network. Once the user satisfies the requirements for 257 extenal network access, the client SHOULD query the API server again 258 to verify that it is no longer captive. 260 5. Security Considerations 262 One of the goals of this protocol is to improve the security of the 263 communication between client hosts and Captive Portal systems. 264 Client traffic is protected from passive listeners on the local 265 network by requiring TLS-encrypted connections between the client and 266 the Captive Portal API server, as described in Section 4. All 267 communication between the clients and the API server MUST be 268 encrypted. 270 In addition to encrypting communications between clients and Captive 271 Portal systems, this protocol requires a basic level of 272 authentication from the API server, as described in Section 4.1.1. 273 Specifically, the API server MUST present a valid certificate on 274 which the client can perform revocation checks. This allows the 275 client to ensure that the API server has authority for a hostname 276 that can be presented to a user. 278 It is important to note that while the server authentication checks 279 can validate a specific hostname, it is certainly possible for the 280 API server to present a valid certificate for a hostname that uses 281 non-standard characters or is otherwise designed to trick the user 282 into believing that its hostname is some other, more trustworthy, 283 name. This is a danger of any scenario in which a hostname is not 284 typed in by a user. 286 5.1. Privacy Considerations 288 Information passed in this protocol may include a user's personal 289 information, such as a full name and credit card details. Therefore, 290 it is important that Captive Portal API Servers do not allow access 291 to the Captive Portal API over unencrypted sessions. 293 6. IANA Considerations 295 IANA is requested to create a registration for an "application/ 296 captive+json" media type (Section 6.1) and a registry for fields in 297 that format (Section 6.2). 299 6.1. Captive Portal API JSON Media Type Registration 301 This document registers the media type for Captive Portal API JSON 302 text, "application/captive+json". 304 Type name: application 306 Subtype name: captive+json 308 Required parameters: None 310 Optional parameters: None 312 Encoding considerations: Encoding considerations are identical to 313 those specified for the "application/json" media type. 315 Security considerations: See Section 5 317 Interoperability considerations: This document specifies format of 318 conforming messages and the interpretation thereof. 320 Published specification: This document 321 Applications that use this media type: This media type is intended 322 to be used by servers presenting the Captive Portal API, and 323 clients connecting to such captive networks. 325 Additional information: None 327 Person & email address to contact for further information: See 328 Authors' Addresses section. 330 Intended usage: COMMON 332 Restrictions on usage: None 334 Author: CAPPORT IETF WG 336 Change controller: IETF 338 6.2. Captive Portal API Keys Registry 340 IANA is asked to create and maintain a new registry called "Captive 341 Portal API Keys", which will reserve JSON keys for use in Captive 342 Portal API data structures. The initial contents of this registry 343 are provided in Section 4.2. 345 Each entry in the registry contains the following fields: 347 Key: The JSON key being registered, in string format. 349 Type: The type of the JSON value to be stored, as one of the value 350 types defined in [RFC8259]. 352 Description: A brief description explaining the meaning of the 353 value, how it might be used, and/or how it should be interpreted 354 by clients. 356 New assignments for Captive Portal API Keys Registry will be 357 administered by IANA through Expert Review [RFC8126]. The Designated 358 Expert is expected to validate the existence of documentation 359 describing new keys in a permanent publicly available specification. 360 The expert is expected to validate that new keys have a clear meaning 361 and do not create unnecessary confusion or overlap with existing 362 keys. Keys that are specific to non-generic use cases, particularly 363 ones that are not specified as part of an IETF document, are 364 encouraged to use a domain-specific prefix. 366 7. Acknowledgments 368 This work in this document was started by Mark Donnelly and Margaret 369 Cullen. Thanks to everyone in the CAPPORT Working Group who has 370 given input. 372 8. References 374 8.1. Normative References 376 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 377 DOI 10.17487/RFC2818, May 2000, 378 . 380 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 381 Housley, R., and W. Polk, "Internet X.509 Public Key 382 Infrastructure Certificate and Certificate Revocation List 383 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 384 . 386 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 387 "Network Time Protocol Version 4: Protocol and Algorithms 388 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 389 . 391 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 392 Extensions: Extension Definitions", RFC 6066, 393 DOI 10.17487/RFC6066, January 2011, 394 . 396 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 397 Galperin, S., and C. Adams, "X.509 Internet Public Key 398 Infrastructure Online Certificate Status Protocol - OCSP", 399 RFC 6960, DOI 10.17487/RFC6960, June 2013, 400 . 402 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 403 Writing an IANA Considerations Section in RFCs", BCP 26, 404 RFC 8126, DOI 10.17487/RFC8126, June 2017, 405 . 407 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 408 Interchange Format", STD 90, RFC 8259, 409 DOI 10.17487/RFC8259, December 2017, 410 . 412 8.2. Informative References 414 [I-D.ietf-capport-architecture] 415 Larose, K. and D. Dolson, "CAPPORT Architecture", Work in 416 Progress, Internet-Draft, draft-ietf-capport-architecture- 417 05, 31 December 2019, . 420 Authors' Addresses 422 Tommy Pauly (editor) 423 Apple Inc. 424 One Apple Park Way 425 Cupertino, California 95014, 426 United States of America 428 Email: tpauly@apple.com 430 Darshak Thakore (editor) 431 CableLabs 432 858 Coal Creek Circle 433 Louisville, CO 80027, 434 United States of America 436 Email: d.thakore@cablelabs.com