Captive Portal API
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
tpauly@apple.com
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
United States of America
d.thakore@cablelabs.com
Captive Portal Interaction
Internet-Draft
This document describes an HTTP API that allows clients to interact with a Captive Portal system.
Introduction
This document describes a HyperText Transfer Protocol (HTTP) Application Program Interface (API) that allows clients to interact with a Captive Portal system. The API defined in this document has been designed to meet the requirements in the Captive Portal Architecture . Specifically, the API provides:
- The state of captivity (whether or not the client has access to the Internet)
- A URI that a client browser can present to a user to get out of captivity
- An encrypted connection (TLS for both the API and portal URI)
Terminology
This document leverages the terminology and components described in and additionally uses the following association:
- Captive Portal Client: The client that interacts with the Captive Portal API is typically some application running on the User Equipment that is connected to the Captive Network. This is also referred to as the "client" in this document.
- Captive Portal API Server: The server exposing the API's defined in this document to the client. This is also referred to as the "API server" in this document.
Workflow
The Captive Portal Architecture defines several categories of interaction between clients and Captive Portal systems:
- Provisioning, in which a client discovers that a network has a captive portal, and learns the URI of the API server.
- API Server interaction, in which a client queries the state of the captive portal and retrieves the necessary information to get out of captivity.
- Enforcement, in which the enforcement device in the network blocks disallowed traffic.
This document defines the mechanisms used in the second category. It is assumed that the location of the Captive Portal API server has been discovered by the client as part of Provisioning. The mechanism for discovering the API Server endpoint is not covered by this document.
API Details
URI of Captive Portal API endpoint
The URI of the API endpoint MUST be accessed using HTTP over TLS (HTTPS) and SHOULD be served on port 443 .
The client SHOULD NOT assume that the URI for a given network attachment will stay the same, and SHOULD rely on the discovery or provisioning process each time it joins the network. Depending on how the Captive Portal system is configured, the URI might be unique for each client host and between sessions for the same client host.
For example, if the Captive Portal API server is hosted at example.org, the URI's of the API could be:
- "https://example.org/captive-portal/api"
- "https://example.org/captive-portal/api/X54PD"
Server Authentication
The purpose of accessing the Captive Portal API over an HTTPS connection is twofold: first, the encrypted connection protects the integrity and confidentiality of the API exchange from other parties on the local network; and second, it provides the client of the API an opportunity to authenticate the server that is hosting the API. This authentication is aimed at allowing a user to be reasonably confident that the entity providing the Captive Portal API has a valid certificate for the hostname in the URI (such as "example.com"). The hostname of the API SHOULD be displayed to the user in order to indicate the entity which is providing the API service.
Clients performing revocation checking will need some means of accessing revocation information for certificates presented by the API server. Online Certificate Status Protocol (OCSP) stapling, using the TLS Certificate Status Request extension SHOULD be used. OCSP stapling allows a client to perform revocation checks without initiating new connections. To allow for other forms of revocation checking, a captive network could permit connections to OCSP responders or Certificate Revocation Lists (CRLs) that are referenced by certificates provided by the API server. In addition to connections to OCSP responders and CRLs, a captive network SHOULD also permit connections to Network Time Protocol (NTP) servers or other time-sync mechnisms to allow clients to accurately validate certificates.
Certificates with missing intermediate certificates that rely on clients validating the certificate chain using the URI specified in the Authority Information Access (AIA) extension SHOULD NOT be used by the Captive Portal API server. If the certificates do require the use of AIA, the captive network will need to allow client access to the host specified in the URI.
If the client is unable to validate the certificate presented by the API server, it MUST NOT proceed with any of the behavior for API interaction described in this document. The client will proceed to interact with the captive network as if the API capabilities were not present. It may still be possible for the user to access the network by being redirected to a web portal.
JSON Keys
The Captive Portal API data structures are specified in JavaScript Object Notation (JSON) . Requests and responses for the Captive Portal API use the "application/captive+json" media type. Clients SHOULD include this media type as an Accept header in their GET requests, and servers MUST mark this media type as their Content-Type header in responses.
The following keys are defined at the top-level of the JSON structure returned by the API server:
- "captive" (required, boolean): indicates whether the client is in a state of captivity, i.e it has not satisfied the conditions to access the external network. If the client is captive (i.e. captive=true), it can still be allowed enough access for it to perform server authentication .
- "user-portal-url" (optional, string): provides the URL of a web portal with which a user can interact.
- "venue-info-url" (optional, string): provides the URL of a webpage or site on which the operator of the network has information that it wishes to share with the user (e.g., store info, maps, flight status, or entertainment).
- "can-extend-session" (optional, boolean): indicates that the URL specified as "user-portal-url" allows the user to extend a session once the client is no longer in a state of captivity. This provides a hint that a client system can suggest accessing the portal URL to the user when the session is near its limit in terms of time or bytes.
- "seconds-remaining" (optional, integer): indicates the number of seconds remaining, after which the client will be placed into a captive state. The API server SHOULD include this value if the client is not captive (i.e. captive=false) and SHOULD omit this value for captive clients.
- "bytes-remaining" (optional, integer): indicates the number of bytes remaining, after which the client will be in placed into a captive state. The byte count represents the total number of IP packet (layer 3) bytes sent and received by the client. Captive portal systems might not count traffic to whitelisted servers, such as the API server, but clients cannot rely on such behavior.
The valid JSON keys can be extended by adding entries to the Captive Portal API Keys Registry . If a client receives a key that it does not recognize, it MUST ignore the key and any associated values. All keys other than the ones defined in this document as "required" will be considered optional.
Example Interaction
A client connected to a captive network upon discovering the URI of the API server will query the API server to retrieve information about its captive state and conditions to escape captivity.
To request the Captive Portal JSON content, a client sends an HTTP GET request:
The server then responds with the JSON content for that client:
Upon receiving this information the client will provide this information to the user so that they may navigate the web portal (as specified by the user-portal-url value) to enable access to the external network. Once the user satisfies the requirements for extenal network access, the client SHOULD query the API server again to verify that it is no longer captive.
Security Considerations
One of the goals of this protocol is to improve the security of the communication between client hosts and Captive Portal systems. Client traffic is protected from passive listeners on the local network by requiring TLS-encrypted connections between the client and the Captive Portal API server, as described in . All communication between the clients and the API server MUST be encrypted.
In addition to encrypting communications between clients and Captive Portal systems, this protocol requires a basic level of authentication from the API server, as described in . Specifically, the API server MUST present a valid certificate on which the client can perform revocation checks. This allows the client to ensure that the API server has authority for a hostname that can be presented to a user.
It is important to note that while the server authentication checks can validate a specific hostname, it is certainly possible for the API server to present a valid certificate for a hostname that uses non-standard characters or is otherwise designed to trick the user into believing that its hostname is some other, more trustworthy, name. This is a danger of any scenario in which a hostname is not typed in by a user.
Privacy Considerations
Information passed in this protocol may include a user's personal information, such as a full name and credit card details. Therefore, it is important that Captive Portal API Servers do not allow access to the Captive Portal API over unencrypted sessions.
IANA Considerations
IANA is requested to create a registration for an "application/captive+json" media type () and a registry for fields in that format ().
Captive Portal API JSON Media Type Registration
This document registers the media type for Captive Portal API JSON text, "application/captive+json".
- Type name:
-
application
- Subtype name:
-
captive+json
- Required parameters:
-
None
- Optional parameters:
-
None
- Encoding considerations:
-
Encoding considerations are identical to those specified for the "application/json" media type.
- Security considerations:
-
See
- Interoperability considerations:
-
This document specifies format of conforming messages and the interpretation thereof.
- Published specification:
-
This document
- Applications that use this media type:
-
This media type is intended to be used by servers presenting the Captive Portal API, and clients connecting to such captive networks.
- Additional information:
-
None
- Person & email address to contact for further information:
-
See Authors' Addresses section.
- Intended usage:
-
COMMON
- Restrictions on usage:
-
None
- Author:
-
CAPPORT IETF WG
- Change controller:
-
IETF
Captive Portal API Keys Registry
IANA is asked to create and maintain a new registry called "Captive Portal API Keys", which will reserve JSON keys for use in Captive Portal API data structures. The initial contents of this registry are provided in .
Each entry in the registry contains the following fields:
- Key:
-
The JSON key being registered, in string format.
- Type:
-
The type of the JSON value to be stored, as one of the value types defined in .
- Description:
-
A brief description explaining the meaning of the value, how it might be used, and/or how it should be interpreted by clients.
New assignments for Captive Portal API Keys Registry will be administered by IANA through Expert Review .
The Designated Expert is expected to validate the existence of documentation describing new keys in a permanent
publicly available specification. The expert is expected to validate that new keys have a clear meaning and do not
create unnecessary confusion or overlap with existing keys. Keys that are specific to non-generic use cases, particularly
ones that are not specified as part of an IETF document, are encouraged to use a domain-specific prefix.
Acknowledgments
This work in this document was started by Mark Donnelly and Margaret Cullen. Thanks to everyone in the CAPPORT Working Group who has given input.
References
Normative References
HTTP Over TLS
This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.
Transport Layer Security (TLS) Extensions: Extension Definitions
This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]
Network Time Protocol Version 4: Protocol and Algorithms Specification
The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]
The JavaScript Object Notation (JSON) Data Interchange Format
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.
Guidelines for Writing an IANA Considerations Section in RFCs
Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).
To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.
This is the third edition of this document; it obsoletes RFC 5226.
Informative References
CAPPORT Architecture
This document aims to document consensus on the CAPPORT architecture. DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution. The role of Provisioning Domains (PvDs) is described.