Captive Portal Architecture
RFC 8952
Internet Engineering Task Force (IETF) K. Larose
Request for Comments: 8952 Agilicus
Category: Informational D. Dolson
ISSN: 2070-1721
H. Liu
Google
November 2020
Captive Portal Architecture
Abstract
This document describes a captive portal architecture. Network
provisioning protocols such as DHCP or Router Advertisements (RAs),
an optional signaling protocol, and an HTTP API are used to provide
the solution.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8952.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
1.1. Requirements Language
1.2. Terminology
2. Components
2.1. User Equipment
2.2. Provisioning Service
2.2.1. DHCP or Router Advertisements
2.2.2. Provisioning Domains
2.3. Captive Portal API Server
2.4. Captive Portal Enforcement Device
2.5. Captive Portal Signal
2.6. Component Diagram
3. User Equipment Identity
3.1. Identifiers
3.2. Recommended Properties
3.2.1. Uniquely Identify User Equipment
3.2.2. Hard to Spoof
3.2.3. Visible to the API Server
3.2.4. Visible to the Enforcement Device
3.3. Evaluating Types of Identifiers
3.4. Example Identifier Types
3.4.1. Physical Interface
3.4.2. IP Address
3.4.3. Media Access Control (MAC) Address
3.5. Context-Free URI
4. Solution Workflow
4.1. Initial Connection
4.2. Conditions about to Expire
4.3. Handling of Changes in Portal URI
5. IANA Considerations
6. Security Considerations
6.1. Trusting the Network
6.2. Authenticated APIs
6.3. Secure APIs
6.4. Risks Associated with the Signaling Protocol
6.5. User Options
6.6. Privacy
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Existing Captive Portal Detection Implementations
Acknowledgments
Authors' Addresses
1. Introduction
In this document, "Captive Portal" is used to describe a network to
which a device may be voluntarily attached, such that network access
is limited until some requirements have been fulfilled. Typically, a
user is required to use a web browser to fulfill requirements imposed
by the network operator, such as reading advertisements, accepting an
acceptable-use policy, or providing some form of credentials.
Implementations of captive portals generally require a web server,
some method to allow/block traffic, and some method to alert the
user. Common methods of alerting the user in implementations prior
to this work involve modifying HTTP or DNS traffic.
This document describes an architecture for implementing captive
portals while addressing most of the problems arising for current
captive portal mechanisms. The architecture is guided by these
requirements:
* Current captive portal solutions typically implement some
variations of forging DNS or HTTP responses. Some attempt man-in-
the-middle (MITM) proxy of HTTPS in order to forge responses.
Captive portal solutions should not have to break any protocols or
otherwise act in the manner of an attacker. Therefore, solutions
MUST NOT require the forging of responses from DNS or HTTP servers
or from any other protocol.
Show full document text