rfc8952xml2.original.xml   rfc8952.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
etf-capport-architecture-10" ipr="trust200902" tocInclude="true" tocDepth="4" sy <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
mRefs="true" sortRefs="true" version="3"> category="info" consensus="true"
<!-- xml2rfc v2v3 conversion 2.37.2 --> docName="draft-ietf-capport-architecture-10" number="8952"
<!-- category values: std, bcp, info, exp, and historic ipr="trust200902" tocInclude="true" tocDepth="4" symRefs="true"
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902 sortRefs="true" xml:lang="en" version="3">
,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="Captive Portal Architecture">Captive Portal Architecture</tit le> <title abbrev="Captive Portal Architecture">Captive Portal Architecture</tit le>
<seriesInfo name="Internet-Draft" value="draft-ietf-capport-architecture-10" <seriesInfo name="RFC" value="8952"/>
/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Kyle Larose" initials="K." surname="Larose"> <author fullname="Kyle Larose" initials="K." surname="Larose">
<organization>Agilicus</organization> <organization>Agilicus</organization>
<address> <address>
<email>kyle@agilicus.com</email> <email>kyle@agilicus.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="David Dolson" initials="D." surname="Dolson"> <author fullname="David Dolson" initials="D." surname="Dolson">
<address> <address>
<email>ddolson@acm.org</email> <email>ddolson@acm.org</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Heng Liu" initials="H." surname="Liu"> <author fullname="Heng Liu" initials="H." surname="Liu">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<email>liucougar@google.com</email> <email>liucougar@google.com</email>
</address> </address>
</author> </author>
<date year="2020"/> <date year="2020" month="November" />
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2r
fc will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>art</area> <area>art</area>
<workgroup>Internet Engineering Task Force</workgroup> <workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions. <!-- [rfced] Please insert any keywords (beyond those that appear in the
If this element is not present, the default is "Network Working Group", title) for use on https://www.rfc-editor.org/search.
which is used by the RFC Editor as a nod to the history of the IETF. --> -->
<keyword>plus</keyword>
<!-- Keywords will be incorporated into HTML output <keyword>example</keyword>
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>This document describes a captive portal architecture. <t>This document describes a captive portal architecture.
Network provisioning protocols such as DHCP or Router Advertisements (RA s), Network provisioning protocols such as DHCP or Router Advertisements (RA s),
an optional signaling protocol, and an HTTP API are used to provide the solution. an optional signaling protocol, and an HTTP API are used to provide the solution.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section> <section>
<name>Introduction</name> <name>Introduction</name>
<t> <t>
In this document, "Captive Portal" is used to describe a network to In this document, "Captive Portal" is used to describe a network to
which a device may be voluntarily attached, such that network access is which a device may be voluntarily attached, such that network access is
limited until some requirements have been fulfilled. Typically a user limited until some requirements have been fulfilled. Typically, a user
is required to use a web browser to fulfill requirements imposed by the is required to use a web browser to fulfill requirements imposed by the
network operator, such as reading advertisements, accepting an network operator, such as reading advertisements, accepting an
acceptable-use policy, or providing some form of credentials. acceptable-use policy, or providing some form of credentials.
</t> </t>
<t> <t>
Implementations of captive portals generally require a web server, some Implementations of captive portals generally require a web server, some
method to allow/block traffic, and some method to alert the user. method to allow/block traffic, and some method to alert the user.
Common methods of alerting the user in implementations prior to this Common methods of alerting the user in implementations prior to this
work involve modifying HTTP or DNS traffic. work involve modifying HTTP or DNS traffic.
</t> </t>
<t> <t>
This document describes an architecture for implementing captive This document describes an architecture for implementing captive
portals while addressing most of the problems arising for current portals while addressing most of the problems arising for current
captive portal mechanisms. The architecture is guided by these captive portal mechanisms. The architecture is guided by these
requirements: requirements:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Current captive portal solutions typically implement some variations <li>Current captive portal solutions typically implement some variations
of forging DNS or HTTP responses. of forging DNS or HTTP responses.
Some attempt man-in-the-middle (MITM) proxy of HTTPS in Some attempt man-in-the-middle (MITM) proxy of HTTPS in
order to forge reponses. order to forge responses.
Captive Portal Solutions should not have to break any protocols or Captive portal solutions should not have to break any protocols or
otherwise act in the manner of an attacker. otherwise act in the manner of an attacker.
Therefore, solutions MUST NOT require the forging of responses from Therefore, solutions <bcp14>MUST NOT</bcp14> require the forging of
DNS or HTTP servers, or any other protocol.</li> responses from
<li>Solutions MUST permit clients to perform DNSSEC validation, which ru DNS or HTTP servers or from any other protocol.</li>
les out solutions <li>Solutions <bcp14>MUST</bcp14> permit clients to perform DNSSEC valid
ation, which rules out solutions
that forge DNS responses. that forge DNS responses.
Solutions SHOULD permit clients to detect and avoid TLS man-in-the-m iddle attacks Solutions <bcp14>SHOULD</bcp14> permit clients to detect and avoid T LS man-in-the-middle attacks
without requiring a human to perform any kind of "exception" process ing.</li> without requiring a human to perform any kind of "exception" process ing.</li>
<li>To maximize universality and adoption, solutions MUST operate at the <li>To maximize universality and adoption, solutions <bcp14>MUST</bcp14> operate at the
layer of Internet Protocol (IP) or above, not being specific to any layer of Internet Protocol (IP) or above, not being specific to any
particular access technology such as Cable, WiFi or mobile particular access technology such as cable, Wi-Fi, or mobile
telecom.</li> telecom.</li>
<li>Solutions SHOULD allow a device to query the network to determine wh <li>Solutions <bcp14>SHOULD</bcp14> allow a device to query the
ether the device is network to determine whether the device is captive, without the
captive, without the solution being coupled to forging intercepted p solution being coupled to forging intercepted protocols or requiring
rotocols or the device to make sacrificial queries to "canary" URIs to check for
requiring the device to make sacrificial queries to "canary" URIs to response tampering (see <xref target="app-additional"/>). Current
check for response captive portal solutions that work by affecting DNS or HTTP generally
tampering (see <xref target="app-additional"/>). Current captive only function as intended with browsers, breaking other applications
portal solutions that work by affecting DNS or HTTP generally only f using those protocols; applications using other protocols are not
unction as intended alerted that the network is a captive portal.</li>
with browsers, breaking other applications using those protocols; ap <li>The state of captivity <bcp14>SHOULD</bcp14> be explicitly available
plications using to devices via
other protocols are not alerted that the network is a captive portal
.</li>
<li>The state of captivity SHOULD be explicitly available to devices via
a standard protocol, rather than having to infer the state indirectl y.</li> a standard protocol, rather than having to infer the state indirectl y.</li>
<li>The architecture MUST provide a path of incremental migration, <li>The architecture <bcp14>MUST</bcp14> provide a path of incremental m igration,
acknowledging the existence of a huge variety of pre-existing acknowledging the existence of a huge variety of pre-existing
portals and end-user device implementations and software versions. portals and end-user device implementations and software versions.
This requirement is not to recommend or standardize existing This requirement is not to recommend or standardize existing
approaches, rather to provide device and portal implementors a path approaches, but rather to provide device and portal implementors a p
to new standard.</li> ath
to a new standard.</li>
</ul> </ul>
<!-- [rfced] We have updated "path to new standard" to read "path to a new
standard" (i.e., added indefinite pronoun. Please let us know if this
should read "path to new standards" (plural) instead.
Original:
This requirement is not to recommend or standardize existing approaches,
rather to provide device and portal implementors a path to new standard.
Current:
This requirement is not to recommend or standardize existing approaches,
but rather to provide device and portal implementors a path to a new standard
.
-->
<t> <t>
A side-benefit of the architecture described in this document is that A side benefit of the architecture described in this document is that
devices without user interfaces are able to identify parameters of devices without user interfaces are able to identify parameters of
captivity. However, this document does not describe a mechanism for such captivity. However, this document does not describe a mechanism for
devices to negotiate for unrestricted network access. A future document c such devices to negotiate for unrestricted network access. A future
ould provide a solution document could provide a solution to devices without user
to devices without user interfaces. This document focuses on devices interfaces. This document focuses on devices with user interfaces.
with user interfaces.
</t> </t>
<t> <t>
The architecture uses the following mechanisms: The architecture uses the following mechanisms:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>Network provisioning protocols provide end-user devices with a <li>Network provisioning protocols provide end-user devices with a
Uniform Resource Identifier <xref target="RFC3986"/> (URI) for Uniform Resource Identifier (URI) <xref target="RFC3986"/> for the API
the API that end-user devices query for information about that end-user devices query for information about what is required to
what is required to escape captivity. DHCP, DHCPv6, and escape captivity. DHCP, DHCPv6, and Router Advertisement options for
Router-Advertisement options for this purpose are available in this purpose are available in <xref target="RFC8910"/>. Other
<xref target="RFC7710bis"/>. Other protocols (such as RADIUS), protocols (such as RADIUS), Provisioning Domains <xref
Provisioning Domains target="I-D.pfister-capport-pvd"/>, or static configuration may also
<xref target="I-D.pfister-capport-pvd"/>, or be used to convey this Captive Portal API URI. A device
static configuration may also be used to convey this Captive Portal <bcp14>MAY</bcp14> query this API at any time to determine whether the
API URI. network is holding the device in a captive state.
A device MAY query this API at any time to determine whether the
network is holding the device in a captive state.
</li> </li>
<li>A Captive Portal can signal User Equipment in response to transmissi <li>A Captive Portal can signal User Equipment in response to
ons by transmissions by the User Equipment. This signal works in response to
the User Equipment. This signal works in response to any Internet pr any Internet protocol and is not done by modifying protocols in band.
otocol, This signal does not carry the Captive Portal API URI; rather, it
and is not done by modifying protocols in-band. This signal does no provides a signal to the User Equipment that it is in a captive state.
t carry the
Captive Portal API URI; rather it provides a signal to the User Equi
pment that it
is in a captive state.
</li> </li>
<li> <li>
Receipt of a Captive Portal Signal provides a hint that User Equipme nt could be captive. Receipt of a Captive Portal Signal provides a hint that User Equipme nt could be captive.
In response, the device MAY query the provisioned API to obtain In response, the device <bcp14>MAY</bcp14> query the provisioned API to obtain
information about the network state. information about the network state.
The device can take immediate action to satisfy the portal The device can take immediate action to satisfy the portal
(according to its configuration/policy). (according to its configuration/policy).
</li> </li>
</ul> </ul>
<t> <t>
The architecture attempts to provide confidentiality, authentication, and safety mechanisms The architecture attempts to provide confidentiality, authentication, and safety mechanisms
to the extent possible. to the extent possible.
</t> </t>
<section> <section>
<name>Requirements Language</name> <name>Requirements Language</name>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
when, they appear in all capitals, as shown here. "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
</section> </section>
<section> <section>
<name>Terminology</name> <name>Terminology</name>
<t>Captive Portal: A network which limits communication of attached
devices to restricted hosts until the user has satisfied <dl newline="true">
Captive Portal Conditions, after which access is permitted to a wider
set of hosts (typically the Internet).</t> <dt>Captive Portal
<t>Captive Portal Conditions: site-specific requirements that a user </dt>
or device must satisfy in order to gain access to the wider network.</ <dd>A network that limits the communication of attached devices to restricted
t> hosts until the user has satisfied Captive Portal Conditions, after which
<t>Captive Portal Enforcement Device: The network equipment which enforc access is permitted to a wider set of hosts (typically the Internet).
es the </dd>
traffic restriction. Also known as Enforcement Device.</t>
<t>Captive Portal User Equipment: Also known as User Equipment. A device <dt>Captive Portal Conditions
which has voluntarily joined a network for purposes of communicating </dt>
beyond the constraints of the Captive Portal.</t> <dd>Site-specific requirements that a user or device must satisfy in order to
<t>User Portal: The web server providing a user interface for gain access to the wider network.
assisting the user in satisfying the conditions to escape </dd>
captivity.</t>
<t>Captive Portal API: Also known as API. An HTTP API allowing User Equi <dt>Captive Portal Enforcement Device
pment </dt>
to query information about its state of captivity within the Captive P <dd>The network equipment that enforces the traffic restriction. Also known
ortal. This as "Enforcement Device".
information might include how to obtain full network access (e.g. by v </dd>
isting a URI).
</t> <dt>Captive Portal User Equipment
<t>Captive Portal API Server: Also known as API Server. A server hosting </dt>
the <dd>A device that has voluntarily joined a
Captive Portal API. network for purposes of communicating beyond the constraints of the Captive
</t> Portal. Also known as "User Equipment".
<t>Captive Portal Signal: A notification from the network used to signal </dd>
to the User Equipment
that the state of its captivity could have changed. <dt>User Portal
</t> </dt>
<t>Captive Portal Signaling Protocol: Also known as Signaling Protocol. <dd>The web server providing a user interface for assisting the user in
The protocol for satisfying the conditions to escape captivity.
communicating Captive Portal Signals. </dd>
</t>
<t> <dt>Captive Portal API
Captive Portal Session: Also referred to simply as the “session”, a Capt </dt>
ive Portal <dd>An HTTP API allowing User Equipment to query information about its state
Session is the association for a particular User Equipment that starts w of captivity within the Captive Portal. This information might include how to
hen it obtain full network access (e.g., by visiting a URI). Also known as "API".
interacts with the Captive Portal and gains open access to the network, </dd>
and ends
when the User Equipment moves back into the original captive state. The <dt>Captive Portal API Server
Captive </dt>
Network maintains the state of each active Session, and can limit Sessio <dd>A server hosting the Captive Portal API. Also known as "API Server".
ns based </dd>
on a length of time or a number of bytes used. The Session is associated
with a <dt>Captive Portal Signal
particular User Equipment using the User Equipment's identifier (see </dt>
<xref target="ue_identity"/>). <dd>A notification from the network used to signal to the User Equipment that
</t> the state of its captivity could have changed.
</dd>
<dt>Captive Portal Signaling Protocol
</dt>
<dd>The protocol for communicating Captive Portal Signals. Also known as
"Signaling Protocol".
</dd>
<dt>Captive Portal Session
</dt>
<dd>Also referred to simply as the "Session", a Captive Portal Session is the
association for a particular User Equipment instance that starts when it interac
ts with
the Captive Portal and gains open access to the network and ends when the
User Equipment moves back into the original captive state. The Captive Network
maintains the state of each active Session and can limit Sessions based on a
length of time or a number of bytes used. The Session is associated with a
particular User Equipment instance using the User Equipment's identifier (see <x
ref
target="ue_identity"/>).
</dd>
</dl>
</section> </section>
</section> </section>
<section> <section>
<name>Components</name> <name>Components</name>
<section anchor="section_client"> <section anchor="section_client">
<name>User Equipment</name> <name>User Equipment</name>
<t> <t>
The User Equipment is the device that a user desires to be attached to The User Equipment is the device that a user desires to be attached to
a network with full access to all hosts on the network (e.g., to have a network with full access to all hosts on the network (e.g., to have
Internet access). The User Equipment communication is typically Internet access). The User Equipment communication is typically
skipping to change at line 259 skipping to change at line 277
</t> </t>
<t> <t>
This document only considers devices with web browsers, with web This document only considers devices with web browsers, with web
applications being the means of satisfying Captive Portal Conditions. applications being the means of satisfying Captive Portal Conditions.
An example of such User Equipment is a smart phone. An example of such User Equipment is a smart phone.
</t> </t>
<t> <t>
The User Equipment: The User Equipment:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>SHOULD support provisioning of the URI for the Captive Portal API <li><bcp14>SHOULD</bcp14> support provisioning of the URI for the
(e.g., by DHCP)</li> Captive Portal API (e.g., by DHCP).</li>
<li>SHOULD distinguish Captive Portal API access per network interface <li><bcp14>SHOULD</bcp14> distinguish Captive Portal API access per
, in the manner network interface, in the manner of Provisioning Domain Architecture
of Provisioning Domain Architecture <xref target="RFC7556"/>.</li> <xref target="RFC7556"/>.</li>
<li>SHOULD have a non-spoofable mechanism for notifying the user of th <li><bcp14>SHOULD</bcp14> have a non-spoofable mechanism for
e Captive Portal</li> notifying the user of the Captive Portal.</li>
<li>SHOULD have a web browser so that the user may navigate to the Use <li><bcp14>SHOULD</bcp14> have a web browser so that the user may
r Portal.</li> navigate to the User Portal.</li>
<li>SHOULD support updates to the Captive Portal API URI from the netw <li><bcp14>SHOULD</bcp14> support updates to the Captive Portal API
ork provisioning URI from the Provisioning Service.</li>
service.</li> <li><bcp14>MAY</bcp14> prevent applications from using networks that
<li>MAY prevent applications from using networks that do not grant ful do not grant full network access. For example, a device connected to a
l mobile network may be connecting to a captive Wi-Fi network; the
network access. E.g., a device connected to a mobile network may operating system could avoid updating the default route to a device
be connecting to a captive WiFi network; the operating system could on the captive Wi-Fi network until network access restrictions have be
avoid updating the default route to a device on captive WiFi network en
until lifted (excepting access to the User Portal) in the new
network access restrictions have been lifted (excepting access to the network. This has been termed "make before break".</li>
User Portal) in
the new network. This has been termed "make before break".</li>
</ul> </ul>
<t> <t>
None of the above requirements are mandatory because (a) we do not wish None of the above requirements are mandatory because (a) we do not wish
to say users or devices must seek full access to the Captive Portal, to say users or devices must seek full access to the Captive Portal,
(b) the requirements may be fulfilled by manually visiting the captive (b) the requirements may be fulfilled by manually visiting the captive
portal web application, and (c) legacy devices must continue to be portal web application, and (c) legacy devices must continue to be
supported. supported.
</t> </t>
<t> <t>
If User Equipment supports the Captive Portal API, it MUST validate the If User Equipment supports the Captive Portal API, it
API server's <bcp14>MUST</bcp14> validate the API Server's TLS certificate (see
TLS certificate (see <xref target="RFC2818"/>) according to the procedur <xref target="RFC2818"/>) according to the procedures in <xref
es in target="RFC6125"/>. The API Server's URI is obtained via a network
<xref target="RFC6125"/>. The API server's URI is obtained via a networ provisioning protocol, which will typically provide a hostname to be
k used in TLS server certificate validation, against a DNS-ID in the
provisioning protocol, which will typically provide a hostname to be use server certificate. If the API Server is identified by IP address,
d the iPAddress subjectAltName is used to validate the server
in TLS server certificate validation, against a DNS-ID in the server cer certificate. An Enforcement Device <bcp14>SHOULD</bcp14> allow access
tificate. to any services that User Equipment could need to contact to perform
If the API server is identified by IP address, the iPAddress subjectAltN certificate validation, such as Online Certificate Status Protocol
ame (OCSP) responders, Certificate Revocation Lists (CRLs), and NTP
is used to validate the server certificate. An Enforcement Device SHOUL servers; see <xref target="RFC8908" sectionFormat="of" section="4.1"/>
D allow access to for more information. If certificate validation fails, User Equipment
any services that User Equipment could need to contact to perform certif <bcp14>MUST NOT</bcp14> make any calls to the API Server.
icate validation,
such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of
<xref target="I-D.ietf-capport-api"/> for more information.
If certificate validation fails, User Equipment MUST NOT make any calls
to the API
server.
</t> </t>
<t> <t>
The User Equipment can store the last response it received from the Capt The User Equipment can store the last response it received from the
ive Portal API Captive Portal API
as a cached view of its state within the Captive Portal. This state can be used to as a cached view of its state within the Captive Portal. This state can be used to
determine whether its Captive Portal Session is near expiry. For example , the User determine whether its Captive Portal Session is near expiry. For example , the User
Equipment might compare a timestamp indicating when the session expires to the current Equipment might compare a timestamp indicating when the Session expires to the current
time. Storing state in this way can reduce the need for communication wi th the time. Storing state in this way can reduce the need for communication wi th the
Captive Portal API. However, it could lead to the state becoming Captive Portal API. However, it could lead to the state becoming
stale if the User Equipment's view of the relevant conditions (byte quot a, for example) stale if the User Equipment's view of the relevant conditions (byte quot a, for example)
is not consistent with the Captive Portal API's. is not consistent with the Captive Portal API's.
</t> </t>
</section> </section>
<section anchor="section_provisioning"> <section anchor="section_provisioning">
<name>Provisioning Service</name> <name>Provisioning Service</name>
<t> <t>
The Provisioning Service is primarily responsible for providing a Capt The Provisioning Service is primarily responsible for providing a
ive Captive Portal API URI to the User Equipment when it connects to the
Portal API URI to the User Equipment when it connects to the network, network, and later if the URI changes. The Provisioning Service
and could also be the same service that is responsible for provisioning
later if the URI changes. The provisioning service could also be the the User Equipment for access to the Captive Portal (e.g., by
same providing it with an IP address). This section discusses two
service which is responsible for provisioning the User Equipment for mechanisms that may be used to provide the Captive Portal API URI
access to the Captive Portal (e.g., by providing it with an IP address to the User Equipment.
).
This section discusses two mechanisms which may be used to provide the
Captive Portal API URI to the User Equipment.
</t> </t>
<section anchor="section_dhcp"> <section anchor="section_dhcp">
<name>DHCP or Router Advertisements</name> <name>DHCP or Router Advertisements</name>
<t> <t>
A standard for providing a Captive Portal API URI using DHCP or Route r A standard for providing a Captive Portal API URI using DHCP or Route r
Advertisements is described in <xref target="RFC7710bis"/>. The Advertisements is described in <xref target="RFC8910"/>. The
captive portal architecture expects this URI to indicate the API desc ribed captive portal architecture expects this URI to indicate the API desc ribed
in <xref target="section_api"/>. in <xref target="section_api"/>.
</t> </t>
</section> </section>
<section anchor="section_pvd"> <section anchor="section_pvd">
<name>Provisioning Domains</name> <name>Provisioning Domains</name>
<!-- [rfced] FYI: We have updated this sentence as follows (i.e., removed
introductory phrase) as the status of this I-D may change.
Original:
Although still a work in progress, [I-D.pfister-capport-pvd] proposes
a mechanism for User Equipment to be provided with PvD Bootstrap
Information containing the URI for the API described in Section 2.3.
Updated:
[CAPPORT-PVD] proposes a mechanism for User Equipment to be provided
with Provisioning Domain (PvD) Bootstrap Information containing the
URI for the API described in Section 2.3.
-->
<t> <t>
Although still a work in progress,
<xref target="I-D.pfister-capport-pvd"/> <xref target="I-D.pfister-capport-pvd"/>
proposes a mechanism for User Equipment to be provided with PvD proposes a mechanism for User Equipment to be provided with
Bootstrap Information containing the URI for the API described in Provisioning Domain (PvD) Bootstrap Information containing the URI
<xref target="section_api"/>. for the API described in <xref target="section_api"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="section_api"> <section anchor="section_api">
<name>Captive Portal API Server</name> <name>Captive Portal API Server</name>
<t> <t>
The purpose of a Captive Portal API is to permit a query of Captive The purpose of a Captive Portal API is to permit a query of
Portal state without interrupting the user. This API thereby removes Captive Portal state without interrupting the user. This API thereby
the need for User Equipment to perform clear-text "canary" (see removes the need for User Equipment to perform clear-text "canary"
<xref target="app-additional"/>) queries to check for response tamperin (see <xref target="app-additional"/>) queries to check for response
g. tampering.
</t> </t>
<t> <t>
The URI of this API will have been provisioned to the User Equipment. The URI of this API will have been provisioned to the User Equipment.
(Refer to <xref target="section_provisioning"/>). (Refer to <xref target="section_provisioning"/>.)
</t> </t>
<t> <t>
This architecture expects the User Equipment to query the API when the This architecture expects the User Equipment to query the API when the
User Equipment attaches to the network and multiple times thereafter. User Equipment attaches to the network and multiple times thereafter.
Therefore the API MUST support multiple repeated queries from the same Therefore, the API <bcp14>MUST</bcp14> support multiple repeated querie s from the same
User Equipment and return the state of captivity for the equipment. User Equipment and return the state of captivity for the equipment.
</t> </t>
<t> <t>
At minimum, the API MUST provide the state of captivity. Further the At minimum, the API <bcp14>MUST</bcp14> provide the state of captivity.
API MUST be able to provide a URI for the User Portal. The scheme for Further, the
the URI MUST be https so that the User Equipment communicates with API <bcp14>MUST</bcp14> be able to provide a URI for the User Portal. T
he scheme for
the URI <bcp14>MUST</bcp14> be "https" so that the User Equipment commu
nicates with
the User Portal over TLS. the User Portal over TLS.
</t> </t>
<t> <t>
If the API receives a request for state that does not correspond to the If the API receives a request for state that does not correspond to the
requesting User Equipment, the API SHOULD deny access. Given that the requesting User Equipment, the API <bcp14>SHOULD</bcp14> deny access. Given that the
API might use the User Equipment's identifier for authentication, this API might use the User Equipment's identifier for authentication, this
requirement motivates <xref target="id_recommended_hard"/>. requirement motivates <xref target="id_recommended_hard"/>.
</t> </t>
<t> <t>
A caller to the API needs to be presented with evidence that the conten A caller to the API needs to be presented with evidence that the
t content it is receiving is for a version of the API that it
it is receiving is for a version of the API that it supports. For an supports. For an HTTP-based interaction, such as in <xref
HTTP-based interaction, such as in <xref target="I-D.ietf-capport-api"/ target="RFC8908"/>, this might be achieved by using a content type
> that is unique to the protocol.
this might be achieved by using a content type that is unique to the
protocol.
</t> </t>
<t> <t>
When User Equipment receives Captive Portal Signals, the User Equipment When User Equipment receives Captive Portal Signals, the User Equipment
MAY query the API to check its state of captivity. <bcp14>MAY</bcp14> query the API to check its state of captivity.
The User Equipment SHOULD rate-limit these API queries in the event of The User Equipment <bcp14>SHOULD</bcp14> rate-limit these API queries i
n the event of
the signal being flooded. (See <xref target="Security"/>.) the signal being flooded. (See <xref target="Security"/>.)
</t> </t>
<t> <t>
The API MUST be extensible to support future use-cases by allowing The API <bcp14>MUST</bcp14> be extensible to support future use cases b y allowing
extensible information elements. extensible information elements.
</t> </t>
<t> <t>
The API MUST use TLS to ensure server authentication. The API <bcp14>MUST</bcp14> use TLS to ensure server authentication.
The implementation of the API MUST ensure both confidentiality and The implementation of the API <bcp14>MUST</bcp14> ensure both confident
iality and
integrity of any information provided by or required by it. integrity of any information provided by or required by it.
</t> </t>
<t> <t>
This document does not specify the details of the API. This document does not specify the details of the API.
</t> </t>
</section> </section>
<section anchor="section_capport_enforcement"> <section anchor="section_capport_enforcement">
<name>Captive Portal Enforcement Device</name> <name>Captive Portal Enforcement Device</name>
<t> <t>
The Enforcement Device component restricts the network access of The Enforcement Device component restricts the network access of
User Equipment according to site-specific policy. Typically User Equipme nt User Equipment according to the site-specific policy. Typically, User Eq uipment
is permitted access to a small number of services (according to the poli cies is permitted access to a small number of services (according to the poli cies
of the network provider) and is denied general of the network provider) and is denied general
network access until it satisfies the Captive Portal Conditions. network access until it satisfies the Captive Portal Conditions.
</t> </t>
<t> <t>
The Enforcement Device component: The Enforcement Device component:
</t> </t>
<ul spacing="normal">
<ul spacing="normal">
<li>Allows traffic to pass for User Equipment that is permitted to <li>Allows traffic to pass for User Equipment that is permitted to
use the network and has satisfied the Captive Portal Conditions.</ li> use the network and has satisfied the Captive Portal Conditions.</ li>
<li>Blocks (discards) traffic according to the site-specific policy <li>Blocks (discards) traffic according to the site-specific policy
for User Equipment that has not yet satisfied the Captive Portal Con ditions.</li> for User Equipment that has not yet satisfied the Captive Portal Con ditions.</li>
<li>Optionally signals User Equipment using the Captive Portal Signali ng protocol <li>Optionally signals User Equipment using the Captive Portal Signali ng Protocol
if certain traffic is blocked.</li> if certain traffic is blocked.</li>
<li>Permits User Equipment that has not satisfied the Captive Portal C onditions <li>Permits User Equipment that has not satisfied the Captive Portal C onditions
to access necessary APIs and web pages to fulfill requirements for esc aping captivity.</li> to access necessary APIs and web pages to fulfill requirements for esc aping captivity.</li>
<li>Updates allow/block rules per User Equipment in response to operat ions <li>Updates allow/block rules per User Equipment in response to operat ions
from the User Portal.</li> from the User Portal.</li>
</ul> </ul>
</section> </section>
<section anchor="section_signal"> <section anchor="section_signal">
<name>Captive Portal Signal</name> <name>Captive Portal Signal</name>
<t> <t>
When User Equipment first connects to a network, or when there are chang es in status, When User Equipment first connects to a network, or when there are chang es in status,
the Enforcement Device could generate a signal toward the User Equipment . This signal the Enforcement Device could generate a signal toward the User Equipment . This signal
indicates that the User Equipment might need to contact the API Server t o receive indicates that the User Equipment might need to contact the API Server t o receive
updated information. For instance, this signal might be generated when the end of a updated information. For instance, this signal might be generated when the end of a
session is imminent, or when network access was denied. Session is imminent or when network access was denied.
For simplicity, and to reduce the attack surface, all signals SHOULD be For simplicity, and to reduce the attack surface, all signals <bcp14>SHO
considered ULD</bcp14> be considered
equivalent by the User Equipment: as a hint to contact the API. equivalent by the User Equipment as a hint to contact the API.
If future solutions have multiple signal types, each type SHOULD be rate If future solutions have multiple signal types, each type <bcp14>SHOULD<
-limited /bcp14> be rate-limited
independently. independently.
</t> </t>
<t> <t>
An Enforcement Device MUST rate-limit any signal generated in response t o these conditions. See <xref target="section_signal_risks"/> for a discussion of An Enforcement Device <bcp14>MUST</bcp14> rate-limit any signal generate d in response to these conditions. See <xref target="section_signal_risks"/> fo r a discussion of
risks related to a Captive Portal Signal. risks related to a Captive Portal Signal.
</t> </t>
</section> </section>
<section> <section>
<name>Component Diagram</name> <name>Component Diagram</name>
<t> <t>
The following diagram shows the communication between each component in the The following diagram shows the communication between each component in the
case where the Captive Portal has a User Portal, and the User Equipm ent case where the Captive Portal has a User Portal and the User Equipme nt
chooses to visit the User Portal in response to discovering and inte racting chooses to visit the User Portal in response to discovering and inte racting
with the API Server. with the API Server.
</t> </t>
<figure anchor="components"> <figure anchor="components">
<name>Captive Portal Architecture Component Diagram</name> <name>Captive Portal Architecture Component Diagram</name>
<artwork><![CDATA[ <artwork><![CDATA[
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
. CAPTIVE PORTAL . . CAPTIVE PORTAL .
. +------------+ Join Network +--------------+ . . +------------+ Join Network +--------------+ .
. | |+--------------------------->| Provisioning | . . | |+--------------------------->| Provisioning | .
skipping to change at line 486 skipping to change at line 528
o . . . . . . . . . . . . . . . . . . .| |. . . . . . . . . . . o o . . . . . . . . . . . . . . . . . . .| |. . . . . . . . . . . o
| v | v
EXTERNAL NETWORK EXTERNAL NETWORK
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
In the diagram: In the diagram:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>During provisioning (e.g., DHCP), and possibly later, the User <li>During provisioning (e.g., DHCP), and possibly later, the User
Equipment acquires the Captive Portal API URI.</li> Equipment acquires the Captive Portal API URI.</li>
<li>The User Equipment queries the API to learn of its state of <li>The User Equipment queries the API to learn of its state of
captivity. If captive, the User Equipment presents the portal captivity. If captive, the User Equipment presents the portal user
user interface from the User Portal to the user.</li> interface from the User Portal to the user.</li>
<li>Based on user interaction, the User Portal directs the <li>Based on user interaction, the User Portal directs the
Enforcement Device to either allow or deny external network Enforcement Device to either allow or deny external network access
access for the User Equipment.</li> for the User Equipment.</li>
<li>The User Equipment attempts to communicate to the external <li>The User Equipment attempts to communicate to the external
network through the Enforcement Device.</li> network through the Enforcement Device.</li>
<li>The Enforcement Device either allows the User <li>The Enforcement Device either allows the User Equipment's
Equipment's packets to the external network, or blocks the packets to the external network or blocks the packets. If blocking
packets. If blocking traffic and a signal has traffic and a signal has been implemented, it may respond with a
been implemented, it may respond with a Captive Portal Signal.< Captive Portal Signal.</li>
/li>
</ul> </ul>
<t> <t>
The Provisioning Service, API Server, and User Portal are The Provisioning Service, API Server, and User Portal are
described as discrete functions. An implementation might provide the described as discrete functions. An implementation might provide the
multiple functions within a single entity. Furthermore, these functions, combined or not, multiple functions within a single entity. Furthermore, these functions, combined or not,
as well as the Enforcement Device, could be replicated for redundancy or scale. as well as the Enforcement Device, could be replicated for redundancy or scale.
</t> </t>
</section> </section>
</section> </section>
<section anchor="ue_identity"> <section anchor="ue_identity">
<name>User Equipment Identity</name> <name>User Equipment Identity</name>
<t> <t>
Multiple components in the architecture interact with both the User Multiple components in the architecture interact with both the User
Equipment and each other. Since the User Equipment is the focus of Equipment and each other. Since the User Equipment is the focus of
these interactions, the components must be able to both identify th e these interactions, the components must be able to both identify th e
User Equipment from their interactions with it, and to agree User Equipment from their interactions with it and agree
on the identity of the User Equipment when interacting with each on the identity of the User Equipment when interacting with each
other. other.
</t> </t>
<t> <t>
The methods by which the components interact restrict the type of The methods by which the components interact restrict the type of
information that may be used as an identifying characteristics. Thi s information that may be used as an identifying characteristic. This
section discusses the identifying characteristics. section discusses the identifying characteristics.
</t> </t>
<section anchor="id_identifiers"> <section anchor="id_identifiers">
<name>Identifiers</name> <name>Identifiers</name>
<t> <t>
An Identifier is a characteristic of the User Equipment used by An identifier is a characteristic of the User Equipment used by
the components of a Captive Portal to uniquely determine which the components of a Captive Portal to uniquely determine which
specific User Equipment is interacting with them. specific User Equipment instance is interacting with them.
An Identifier can be a field contained in packets An identifier can be a field contained in packets
sent by the User Equipment to the External Network. Or, an sent by the User Equipment to the external network. Or, an
Identifier can be an ephemeral property not contained in packet identifier can be an ephemeral property not contained in packet
s s
destined for the External Network, but instead correlated with destined for the external network, but instead correlated with
such information through knowledge available to the different such information through knowledge available to the different
components. components.
</t> </t>
</section> </section>
<section anchor="id_recommended_props"> <section anchor="id_recommended_props">
<name>Recommended Properties</name> <name>Recommended Properties</name>
<t> <t>
The set of possible identifiers is quite large. However, in order The set of possible identifiers is quite large. However, in order
to be considered a good identifier, an identifier SHOULD meet the to be considered a good identifier, an identifier <bcp14>SHOULD</bc p14> meet the
following criteria. Note that the optimal identifier will likely following criteria. Note that the optimal identifier will likely
change depending on the position of the components in the network change depending on the position of the components in the network
as well as the information available to them. as well as the information available to them.
An identifier SHOULD: An identifier <bcp14>SHOULD</bcp14>:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>uniquely identify the User Equipment</li> <li>uniquely identify the User Equipment</li>
<li>be hard to spoof</li> <li>be hard to spoof</li>
<li>be visible to the API Server</li> <li>be visible to the API Server</li>
<li>be visible to the Enforcement Device</li> <li>be visible to the Enforcement Device</li>
</ul> </ul>
<t> <t>
An identifier might only apply to the current point of network atta chment. If the An identifier might only apply to the current point of network atta chment. If the
device moves to a different network location its identity could cha nge. device moves to a different network location, its identity could ch ange.
</t> </t>
<section anchor="id_recommended_unique"> <section anchor="id_recommended_unique">
<name>Uniquely Identify User Equipment</name> <name>Uniquely Identify User Equipment</name>
<t> <t>
The Captive Portal MUST associate the User Equipment with an The Captive Portal <bcp14>MUST</bcp14> associate the User
identifier that is unique among the User Equipment that are Equipment with an identifier that is unique among all of the
interacting with the Captive Portal at that time. User Equipment interacting with the Captive Portal at that
time.
</t> </t>
<t> <t>
Over time, the User Equipment assigned to an identifier value Over time, the User Equipment assigned to an identifier
MAY change. Allowing the value <bcp14>MAY</bcp14> change. Allowing the identified
identified device to change over time ensures that the space o device to change over time ensures that the space of
f possible possible identifying values need not be overly large.
identifying values need not be overly large.
</t> </t>
<t> <t>
Independent Captive Portals MAY use the same identifying value Independent Captive Portals <bcp14>MAY</bcp14> use the same
to identify identifying value to identify different User
different User Equipment. Allowing independent captive portals Equipment instances. Allowing independent captive portals to r
to reuse euse
identifying values allows the identifier to be a property of t identifying values allows the identifier to be a property of
he local the local network, expanding the space of possible
network, expanding the space of possible identifiers. identifiers.
</t> </t>
</section> </section>
<section anchor="id_recommended_hard"> <section anchor="id_recommended_hard">
<name>Hard to Spoof</name> <name>Hard to Spoof</name>
<t> <t>
A good identifier does not lend itself to being easily spoofed A good identifier does not lend itself to being easily
. At no time spoofed. At no time should it be simple or straightforward
should it be simple or straightforward for one User Equipment for one User Equipment instance to pretend to be another User
to Equipment instance, regardless of whether both are active at t
pretend to be another User Equipment, regardless of whether bo he same
th are active time. This property is particularly important when the User
at the same time. This property is particularly important when Equipment identifier is referenced externally by devices
the User such as billing systems or when the identity of the User
Equipment identifier is referenced externally by devices such Equipment could imply liability.
as billing systems,
or where the identity of the User Equipment could imply liabil
ity.
</t> </t>
</section> </section>
<section anchor="id_recommended_visible_api"> <section anchor="id_recommended_visible_api">
<name>Visible to the API Server</name> <name>Visible to the API Server</name>
<t> <t>
Since the API Server will need to perform operations which rel y on the identity Since the API Server will need to perform operations that rely on the identity
of the User Equipment, such as answering a query about of the User Equipment, such as answering a query about
whether the User Equipment is captive, the API Server needs whether the User Equipment is captive, the API Server needs
to be able to relate a request to the User Equipment making to be able to relate a request to the User Equipment making
the request. the request.
</t> </t>
</section> </section>
<section anchor="id_recommended_visible_ed"> <section anchor="id_recommended_visible_ed">
<name>Visible to the Enforcement Device</name> <name>Visible to the Enforcement Device</name>
<t> <t>
The Enforcement Device will decide on a per-packet basis wheth The Enforcement Device will decide on a per-packet basis
er whether the packet should be forwarded to the external
the packet should be forwarded to the external network. Since network. Since this decision depends on which User Equipment
this decision depends on which User Equipment sent the packet, instance sent the packet, the Enforcement Device requires
the that it be able to map the packet to its concept of the User
Enforcement Device requires that it be able to map the packet Equipment.
to its
concept of the User Equipment.
</t> </t>
</section> </section>
</section> </section>
<section anchor="id_evaluating"> <section anchor="id_evaluating">
<name>Evaluating Types of Identifiers</name> <name>Evaluating Types of Identifiers</name>
<t> <t>
To evaluate whether a type of identifier is appropriate, one sh ould consider To evaluate whether a type of identifier is appropriate, one sh ould consider
every recommended property from the perspective of interactions among every recommended property from the perspective of interactions among
the components in the architecture. When comparing identifier t ypes, choose the components in the architecture. When comparing identifier t ypes, choose
the one which best satisfies all of the recommended properties. The the one that best satisfies all of the recommended properties. The
architecture does not provide an exact measure of how well an i dentifier architecture does not provide an exact measure of how well an i dentifier
type satisfies a given property; care should be taken in perfor ming the type satisfies a given property; care should be taken in perfor ming the
evaluation. evaluation.
</t> </t>
</section> </section>
<section anchor="id_examples"> <section anchor="id_examples">
<name>Example Identifier Types</name> <name>Example Identifier Types</name>
<t> <t>
This section provides some example identifier types, along with some This section provides some example identifier types, along with some
evaluation of whether they are suitable types. The list of iden tifier types evaluation of whether they are suitable types. The list of iden tifier types
is not exhaustive. Other types may be used. An important point to note is not exhaustive; other types may be used. An important point to note
is that whether a given identifier type is suitable depends hea vily on the is that whether a given identifier type is suitable depends hea vily on the
capabilities of the components and where in the network the com ponents exist. capabilities of the components and where in the network the com ponents exist.
</t> </t>
<section anchor="id_example_interface"> <section anchor="id_example_interface">
<name>Physical Interface</name> <name>Physical Interface</name>
<t> <t>
The physical interface by which the User Equipment is attached to the The physical interface by which the User Equipment is attached to the
network can be used to identify the User Equipment. This identi fier type has network can be used to identify the User Equipment. This identi fier type has
the property of being extremely difficult to spoof: the User Eq uipment is the property of being extremely difficult to spoof: the User Eq uipment is
unaware of the property; one User Equipment cannot manipulate i ts unaware of the property; one User Equipment instance cannot man ipulate its
interactions to appear as though it is another. interactions to appear as though it is another.
</t> </t>
<t>
Further, if only a single User Equipment is attached to a given <t>
physical Further, if only a single User Equipment instance is attached
interface, then the identifier will be unique. If multiple User to a given physical interface, then the identifier will be
Equipment unique. If multiple User Equipment instances are attached
is attached to the network on the same physical interface, then to the network on the same physical interface, then this type
this type
is not appropriate. is not appropriate.
</t> </t>
<t> <t>
Another consideration related to uniqueness of the User Equipme Another consideration related to uniqueness of the User
nt is that Equipment is that if the attached User Equipment changes,
if the attached User Equipment changes, both the API Server and both the API Server and the Enforcement Device
the <bcp14>MUST</bcp14> invalidate their state related to the
Enforcement Device MUST invalidate their state related to the U User Equipment.
ser Equipment.
</t> </t>
<t> <t>
The Enforcement Device needs to be aware of the physical interf The Enforcement Device needs to be aware of the physical
ace, interface, which constrains the environment; it must either
which constrains the environment: it must either be part of the be part of the device providing physical access (e.g.,
device providing implemented in firmware), or packets traversing the network
physical access (e.g., implemented in firmware), or packets tra must be extended to include information about the source
versing the network physical interface (e.g., a tunnel).
must be extended to include information about the source physic
al interface (e.g.
a tunnel).
</t> </t>
<t> <t>
The API Server faces a similar problem, implying that it should co-exist with the The API Server faces a similar problem, implying that it should co-exist with the
Enforcement Device, or that the Enforcement Device should exten d requests to it Enforcement Device or that the Enforcement Device should extend requests to it
with the identifying information. with the identifying information.
</t> </t>
</section> </section>
<section anchor="id_example_IP_address"> <section anchor="id_example_IP_address">
<name>IP Address</name> <name>IP Address</name>
<t> <t>
A natural identifier type to consider is the IP address of the User Equipment. A natural identifier type to consider is the IP address of the User Equipment.
At any given time, no device on the network can have the same IP address At any given time, no device on the network can have the same IP address
without causing the network to malfunction, so it is appropria te from the without causing the network to malfunction, so it is appropria te from the
perspective of uniqueness. perspective of uniqueness.
</t> </t>
<t> <t>
However, it may be possible to spoof the IP address, particula rly for However, it may be possible to spoof the IP address, particula rly for
malicious reasons where proper functioning of the network is n ot necessary malicious reasons where proper functioning of the network is n ot necessary
for the malicious actor. Consequently, any solution using the IP address for the malicious actor. Consequently, any solution using the IP address
SHOULD proactively try to prevent spoofing of the IP address. Similarly, <bcp14>SHOULD</bcp14> proactively try to prevent spoofing of t he IP address. Similarly,
if the mapping of IP address to User Equipment is changed, the components if the mapping of IP address to User Equipment is changed, the components
of the architecture MUST remove or update their mapping to pre of the architecture <bcp14>MUST</bcp14> remove or update their
vent spoofing. mapping to prevent spoofing.
Demonstrations of return routeability, such as that required f Demonstrations of return routability, such as that required fo
or TCP r TCP
connection establishment, might be sufficient defense against spoofing, connection establishment, might be sufficient defense against spoofing,
though this might not be sufficient in networks that use broad cast media though this might not be sufficient in networks that use broad cast media
(such as some wireless networks). (such as some wireless networks).
</t> </t>
<t> <t>
Since the IP address may traverse multiple segments of the net work, more Since the IP address may traverse multiple segments of the net work, more
flexibility is afforded to the Enforcement Device and the API Server: they flexibility is afforded to the Enforcement Device and the API Server; they
simply must exist on a segment of the network where the IP add ress is still simply must exist on a segment of the network where the IP add ress is still
unique. However, consider that a NAT may be deployed between t he User Equipment unique. However, consider that a NAT may be deployed between t he User Equipment
and the Enforcement Device. In such cases, it is possible for the components and the Enforcement Device. In such cases, it is possible for the components
to still uniquely identify the device if they are aware of the port mapping. to still uniquely identify the device if they are aware of the port mapping.
</t> </t>
<t> <t>
In some situations, the User Equipment may have multiple IP addr In some situations, the User Equipment may have multiple IP
esses (either addresses (either IPv4, IPv6, or a dual-stack <xref
IPv4, IPv6 or a dual-stack <xref target="RFC4213"/> combination) target="RFC4213"/> combination) while still satisfying all of
, while the recommended properties. This raises some challenges to the
still satisfying all of the recommended properties. This raises components of the network. For example, if the User Equipment
some challenges tries to access the network with multiple IP addresses, should
to the components of the network. For example, if the User Equip the Enforcement Device and API Server treat each IP address as
ment tries a unique User Equipment instance, or should it tie the multiple
to access the network with multiple IP addresses, should the Enf addresses together into one view of the subscriber? An
orcement Device implementation <bcp14>MAY</bcp14> do either. Attention should
and API Server treat each IP address as a unique User Equipment, be paid to IPv6 and the fact that it is expected for a device
or should it to have multiple IPv6 addresses on a single link. In such
tie the multiple addresses together into one view of the subscri cases, identification could be performed by subnet, such as
ber? the /64 to which the IP belongs.
An implementation MAY do either. Attention should be paid to IPv
6 and the fact
that it is expected for a device to have multiple IPv6 addresses
on a single
link. In such cases, identification could be performed by subnet
, such as the /64
to which the IP belongs.
</t> </t>
</section> </section>
<section anchor="id_example_mac_address"> <section anchor="id_example_mac_address">
<name>Media Access Control (MAC) Address</name> <name>Media Access Control (MAC) Address</name>
<t> <t>
The MAC address of a device is often used as an identifier in existi ng implementations. The MAC address of a device is often used as an identifier in existi ng implementations.
This document does not discuss the use of MAC addresses within a cap tive portal system, but they can be used This document does not discuss the use of MAC addresses within a cap tive portal system, but they can be used
as an identifier type, subject to the criteria in <xref target="id_r ecommended_props"/>. as an identifier type, subject to the criteria in <xref target="id_r ecommended_props"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="context_free_uri"> <section anchor="context_free_uri">
<name>Context-free URI</name> <name>Context-Free URI</name>
<t> <t>
A Captive Portal API needs to present information to clients A Captive Portal API needs to present information to clients
that is unique to that client. To do this, some systems use that is unique to that client. To do this, some systems use
information from the context of a request, such as the source information from the context of a request, such as the source
address, to identify the User Equipment. address, to identify the User Equipment.
</t> </t>
<t> <t>
Using information from context rather than information from the Using information from context rather than information from the
URI allows the same URI to be used for different clients. However, URI allows the same URI to be used for different clients. However,
it also means that the resource is unable to provide relevant it also means that the resource is unable to provide relevant
information if the User Equipment makes a request using a different network information if the User Equipment makes a request using a different network
path. This might happen when User Equipment has multiple network int erfaces. path. This might happen when User Equipment has multiple network int erfaces.
It might also happen if the address of the API provided by DNS It might also happen if the address of the API provided by DNS
depends on where the query originates (as in split DNS depends on where the query originates (as in split DNS
<xref target="RFC8499"/>). <xref target="RFC8499"/>).
</t> </t>
<t> <t>
Accessing the API MAY depend on contextual information. However, Accessing the API <bcp14>MAY</bcp14> depend on contextual informatio
the URIs provided in the API SHOULD be unique to the User Equipment n. However,
and not the URIs provided in the API <bcp14>SHOULD</bcp14> be unique to the
User Equipment and not
dependent on contextual information to function correctly. dependent on contextual information to function correctly.
</t> </t>
<t> <t>
Though a URI might still correctly resolve when the User Equipment m akes the Though a URI might still correctly resolve when the User Equipment m akes the
request from a different network, it is possible that some request from a different network, it is possible that some
functions could be limited to when the User Equipment makes requests using the functions could be limited to when the User Equipment makes requests using the
Captive Portal. For example, payment options could be absent or a Captive Portal. For example, payment options could be absent or a
warning could be displayed to indicate the payment is not for the warning could be displayed to indicate the payment is not for the
current connection. current connection.
</t> </t>
skipping to change at line 756 skipping to change at line 815
<t> <t>
URIs could include some means of identifying the User Equipment in URIs could include some means of identifying the User Equipment in
the URIs. However, including unauthenticated User Equipment the URIs. However, including unauthenticated User Equipment
identifiers in the URI may expose the service to spoofing or replay identifiers in the URI may expose the service to spoofing or replay
attacks. attacks.
</t> </t>
</section> </section>
</section> </section>
<section anchor="section_workflow"> <section anchor="section_workflow">
<name>Solution Workflow</name> <name>Solution Workflow</name>
<t> <t>
This section aims to improve understanding by describing a possible This section aims to improve understanding by describing a possible
workflow of solutions adhering to the architecture. Note that the section is workflow of solutions adhering to the architecture. Note that the section is
not normative: it describes only as subset of possible implementations. not normative; it describes only a subset of possible implementations.
</t> </t>
<section> <section>
<name>Initial Connection</name> <name>Initial Connection</name>
<t> <t>
This section describes a possible workflow when User Equipment initially This section describes a possible workflow when User Equipment initially
joins a Captive Portal. joins a Captive Portal.
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>The User Equipment joins the Captive Portal by acquiring a DHCP <li>The User Equipment joins the Captive Portal by acquiring a DHCP
lease, RA, or similar, acquiring provisioning information.</li> lease, RA, or similar, acquiring provisioning information.</li>
<li>The User Equipment learns the URI for the Captive Portal API from the <li>The User Equipment learns the URI for the Captive Portal API from the
skipping to change at line 771 skipping to change at line 832
<section> <section>
<name>Initial Connection</name> <name>Initial Connection</name>
<t> <t>
This section describes a possible workflow when User Equipment initially This section describes a possible workflow when User Equipment initially
joins a Captive Portal. joins a Captive Portal.
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>The User Equipment joins the Captive Portal by acquiring a DHCP <li>The User Equipment joins the Captive Portal by acquiring a DHCP
lease, RA, or similar, acquiring provisioning information.</li> lease, RA, or similar, acquiring provisioning information.</li>
<li>The User Equipment learns the URI for the Captive Portal API from the <li>The User Equipment learns the URI for the Captive Portal API from the
provisioning information (e.g., <xref target="RFC7710bis"/>).</li> provisioning information (e.g., <xref target="RFC8910"/>).</li>
<li>The User Equipment accesses the Captive Portal API to receive para meters <li>The User Equipment accesses the Captive Portal API to receive para meters
of the Captive Portal, including User Portal URI. (This step replaces of the Captive Portal, including the User Portal URI. (This step replac es
the clear-text query to a canary URI.)</li> the clear-text query to a canary URI.)</li>
<li>If necessary, the User navigates to the User Portal to gain access to the <li>If necessary, the user navigates to the User Portal to gain access to the
external network.</li> external network.</li>
<li> <li>
If the User interacted with the User Portal to gain access to the ex ternal If the user interacted with the User Portal to gain access to the ex ternal
network in the previous step, the User Portal indicates to the Enfor cement network in the previous step, the User Portal indicates to the Enfor cement
Device that the User Equipment is allowed to access the external net work. Device that the User Equipment is allowed to access the external net work.
</li> </li>
<li>The User Equipment attempts a connection outside the Captive Porta <li>The User Equipment attempts a connection outside the Captive Porta
l</li> l.</li>
<li>If the requirements have been satisfied, the access is permitted; <li>If the requirements have been satisfied, the access is
otherwise the "Expired" behavior occurs.</li> permitted; otherwise, the "Expired" behavior occurs.</li>
<li>The User Equipment accesses the network until conditions Expire.</ <li>The User Equipment accesses the network until conditions expire.</
li> li>
</ol> </ol>
</section> </section>
<section> <section>
<name>Conditions About to Expire</name> <name>Conditions about to Expire</name>
<t> <t>
This section describes a possible workflow when access is about to expire. This section describes a possible workflow when access is about to expire.
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Precondition: the API has provided the User Equipment with a durat ion <li>Precondition: the API has provided the User Equipment with a durat ion
over which its access is valid.</li> over which its access is valid.</li>
<li>The User Equipment is communicating with the outside network.</li> <li>The User Equipment is communicating with the outside network.</li>
<li> <li>
The User Equipment detects that the length of time left The User Equipment detects that the length of time left
for its access has fallen below a threshold by comparing its stored for its access has fallen below a threshold by comparing its stored
expiry time with the current time. expiry time with the current time.
</li> </li>
<li>The User Equipment visits the API again to validate the expiry tim e.</li> <li>The User Equipment visits the API again to validate the expiry tim e.</li>
<li>If expiry is still imminent, the User Equipment prompts the user t o access the <li>If expiry is still imminent, the User Equipment prompts the user t o access the
User Portal URI again.</li> User Portal URI again.</li>
<li>The User accepts the prompt displayed by the User Equipment.</li> <li>The user accepts the prompt displayed by the User Equipment.</li>
<li>The User extends their access through the User Portal via the User <li>The user extends their access through the User Portal via the User
Equipment's user interface.</li> Equipment's user interface.</li>
<li>The User Equipment's access to the outside network continues unint errupted.</li> <li>The User Equipment's access to the outside network continues unint errupted.</li>
</ol> </ol>
</section> </section>
<section> <section>
<name>Handling of Changes in Portal URI</name> <name>Handling of Changes in Portal URI</name>
<t>A different Captive Portal API URI could be returned in the following cases:</t> <t>A different Captive Portal API URI could be returned in the following cases:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If DHCP is used, a lease renewal/rebind may return a different Cap tive <li>If DHCP is used, a lease renewal/rebind may return a different Cap tive
Portal API URI.</li> Portal API URI.</li>
<li>If RA is used, a new Captive Portal API URI may be specified in a new RA <li>If RA is used, a new Captive Portal API URI may be specified in a new RA
message received by end User Equipment.</li> message received by end User Equipment.</li>
</ul> </ul>
<t>When the Network Provisioning Service updates the Captive Portal API URI, the User <t>When the Provisioning Service updates the Captive Portal API URI, the User
Equipment can retrieve updated state from the URI immediately, or it can wait Equipment can retrieve updated state from the URI immediately, or it can wait
as it normally would until the expiry conditions it retrieved from th e old URI are as it normally would until the expiry conditions it retrieved from th e old URI are
about to expire. about to expire.
</t> </t>
</section> </section>
</section> </section>
<section anchor="Acknowledgments">
<name>Acknowledgments</name>
<t>The authors thank Lorenzo Colitti for providing the majority of the con
tent
for the Captive Portal Signal requirements.</t>
<t>The authors thank Benjamin Kaduk for providing the content related to T
LS
certificate validation of the API server.</t>
<t>The authors thank Michael Richardson for providing wording requiring DN
SSEC and TLS to
operate without the user adding exceptions.</t>
<t>The authors thank various individuals for their feedback on
the mailing list and during the IETF98 hackathon:
David Bird,
Erik Kline,
Alexis La Goulette,
Alex Roscoe,
Darshak Thakore,
and Vincent van Dam.
</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA"> <section anchor="IANA">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This memo includes no request to IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="Security"> <section anchor="Security">
<name>Security Considerations</name> <name>Security Considerations</name>
<!--All drafts are required to have a security considerations section. Se e RFC3552 -->
<section> <section>
<name>Trusting the Network</name> <name>Trusting the Network</name>
<t> <t>
When joining a network, some trust is placed in the network operator. When joining a network, some trust is placed in the network operator.
This is usually considered to be a decision by a user on the basis of This is usually considered to be a decision by a user on the basis of
the reputation of an organization. However, once a user makes such a the reputation of an organization. However, once a user makes such a
decision, protocols can support authenticating that a network is operat ed decision, protocols can support authenticating that a network is operat ed
by who claims to be operating it. The Provisioning Domain by who claims to be operating it. The Provisioning Domain
Architecture <xref target="RFC7556"/> provides some discussion on Architecture <xref target="RFC7556"/> provides some discussion on
authenticating an operator. authenticating an operator.
</t> </t>
<t> <t>
The user makes an informed choice to visit and trust the Captive The user makes an informed choice to visit and trust the Captive
Portal URI. Since the network provides Captive Portal URI to the user Portal URI. Since the network provides the Captive Portal URI to the
equipment, the network SHOULD do so securely so that the user's trust i User Equipment, the network <bcp14>SHOULD</bcp14> do so securely so
n the that the user's trust in the network can extend to their trust of the
network can extend to their trust of the Captive Portal URI. E.g., the Captive Portal URI. For example, the DHCPv6 AUTH option can sign this
DHCPv6 information.
AUTH option can sign this information.
</t> </t>
<t> <t>
If a user decides to incorrectly trust an attacking network, they might If a user decides to incorrectly trust an attacking network, they might
be convinced to visit an attacking web page and unwittingly provide be convinced to visit an attacking web page and unwittingly provide
credentials to an attacker. Browsers can authenticate servers but credentials to an attacker. Browsers can authenticate servers but
cannot detect cleverly misspelled domains, for example. cannot detect cleverly misspelled domains, for example.
</t> </t>
<t> <t>
Further, the possibility of an on-path attacker in an attacking network Further, the possibility of an on-path attacker in an attacking network
introduces some risks. The attacker could redirect traffic to arbitrary introduces some risks. The attacker could redirect traffic to arbitrary
destinations. The attacker could analyze the user's destinations. The attacker could analyze the user's
traffic leading to loss of confidentiality. Or, the attacker could modi fy traffic leading to loss of confidentiality, or the attacker could modif y
the traffic inline. the traffic inline.
</t> </t>
</section> </section>
<section> <section>
<name>Authenticated APIs</name> <name>Authenticated APIs</name>
<t> <t>
The solution described here requires that when the User Equipment needs to The solution described here requires that when the User Equipment needs to
access the API server, the User Equipment authenticates the access the API Server, the User Equipment authenticates the
server; see <xref target="section_client"/>. server; see <xref target="section_client"/>.
</t> </t>
<t> <t>
The Captive Portal API URI might change during the Captive Portal Sessi on. The Captive Portal API URI might change during the Captive Portal Sessi on.
The User Equipment can apply the same trust mechanisms to the new URI a s it The User Equipment can apply the same trust mechanisms to the new URI a s it
did to the URI it received initially from the network provisioning serv ice. did to the URI it received initially from the Provisioning Service.
</t> </t>
</section> </section>
<section> <section>
<name>Secure APIs</name> <name>Secure APIs</name>
<t> <t>
The solution described here requires that the API be secured using TL S. The solution described here requires that the API be secured using TL S.
This is required to allow the User Equipment and API Server to exchan ge This is required to allow the User Equipment and API Server to exchan ge
secrets which can be used to validate future interactions. The API MU ST secrets that can be used to validate future interactions. The API <bc p14>MUST</bcp14>
ensure the integrity of this information, as well as its confidential ity. ensure the integrity of this information, as well as its confidential ity.
</t> </t>
<t> <t>
An attacker with access to this information might be able to An attacker with access to this information might be able to
masquerade as a specific User Equipment when interacting with the API masquerade as a specific User Equipment instance when interacting wit
, which h the
could then allow them to masquerade as that User Equipment when inter API, which could then allow them to masquerade as that User
acting Equipment instance when interacting with the User Portal. This could
with the User Portal. This could give them the ability to determine w give
hether them the ability to determine whether the User Equipment has
the User Equipment has accessed the portal, or deny the User Equipmen accessed the portal, deny the User Equipment service by ending
t service their Session using mechanisms provided by the User Portal, or
by ending their session using mechanisms provided by the User Portal, consume that User Equipment's quota. An attacker with the ability
or consume that to modify the information could deny service to the User Equipment
User Equipment's quota. An attacker with the ability to modify the in or cause them to appear as different User Equipment instances.
formation
could deny service to the User Equipment, or cause them to appear as
a different
User Equipment.
</t> </t>
</section> </section>
<section anchor="section_signal_risks"> <section anchor="section_signal_risks">
<name>Risks Associated with the Signaling Protocol</name> <name>Risks Associated with the Signaling Protocol</name>
<t> <t>
If a Signaling Protocol is implemented, it may be possible for any user on If a Signaling Protocol is implemented, it may be possible for any user on
the Internet to send signals in attempt to cause the receiving equipmen t to the Internet to send signals in an attempt to cause the receiving equip ment to
communicate with the Captive Portal API. This has been considered, and implementations may communicate with the Captive Portal API. This has been considered, and implementations may
address it in the following ways: address it in the following ways:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The signal only signals to the User Equipment to query the API. It does not <li>The signal only signals to the User Equipment to query the API. It does not
carry any information which may mislead or misdirect the User Equi pment.</li> carry any information that may mislead or misdirect the User Equip ment.</li>
<li>Even when responding to the signal, the User Equipment securely au thenticates <li>Even when responding to the signal, the User Equipment securely au thenticates
with API Servers.</li> with API Servers.</li>
<li>Accesses to the Captive Portal API are rate-limited, reducing the
impact of an <!-- AD approval required for below change?
attack attempting to generate excessive load on either User Equipm -->
ent or API.
Note that because there is only one type of signal and one type of <li>The User Equipment limits the rate at which it accesses the API,
API request in reducing the impact of an attack attempting to generate excessive
response to the signal, this rate-limiting will not cause loss of load on either the User Equipment or API. Note that because there
signalling is only one type of signal and one type of API request in response
information. to the signal, this rate-limiting will not cause loss of signaling
information.
</li> </li>
</ul> </ul>
</section> </section>
<section> <section>
<name>User Options</name> <name>User Options</name>
<t> <t>
The Captive Portal Signal could signal to the User Equipment that it is being held The Captive Portal Signal could signal to the User Equipment that it is being held
captive. There is no requirement that the User Equipment do something captive. There is no requirement that the User Equipment do something
about this. about this.
Devices MAY permit users to disable automatic reaction to Devices <bcp14>MAY</bcp14> permit users to disable automatic reaction t
Captive Portal Signals indications for privacy reasons. o
Captive Portal Signal indications for privacy reasons.
However, there would be the trade-off that the user doesn't get notifie d However, there would be the trade-off that the user doesn't get notifie d
when network access is restricted. when network access is restricted.
Hence, end-user devices MAY allow users to manually control captive Hence, end-user devices <bcp14>MAY</bcp14> allow users to manually cont rol captive
portal interactions, possibly on the granularity of Provisioning portal interactions, possibly on the granularity of Provisioning
Domains. Domains.
</t> </t>
</section> </section>
<section> <section>
<name>Privacy</name> <name>Privacy</name>
<t> <t>
<xref target="ue_identity"/> describes a mechanism by which all compon ents within <xref target="ue_identity"/> describes a mechanism by which all compon ents within
the Captive Portal are designed to use the same identifier to uniquely identify the Captive Portal are designed to use the same identifier to uniquely identify
the User Equipment. This identifier could be abused to track the user . the User Equipment. This identifier could be abused to track the user .
Implementers and designers of Captive Portals should take care to ensu re that Implementers and designers of Captive Portals should take care to ensu re that
identifiers, if stored, are stored securely. Likewise, if any componen t identifiers, if stored, are stored securely. Likewise, if any componen t
communicates the identifier over the network, it should ensure the con fidentiality communicates the identifier over the network, it should ensure the con fidentiality
of the identifier on the wire by using encryption such as TLS. of the identifier on the wire by using encryption such as TLS.
</t> </t>
<t> <t>
There are benefits to choosing mutable anonymous identifiers. For There are benefits to choosing mutable anonymous identifiers. For
example, User Equipment could cycle through multiple identifiers to he example, User Equipment could cycle through multiple identifiers to
lp prevent help prevent long-term tracking. However, if the components of the
long-term tracking. However, if the components of the network use an i network use an internal mapping to map the identity to a stable,
nternal long-term value in order to deal with changing identifiers, they
mapping to map the identity to a stable, long-term value in order to d need to treat that value as sensitive information; an attacker could
eal with use it to tie traffic back to the originating User Equipment, despite
changing identifiers, they need to treat that value as sensitive infor the User Equipment having changed identifiers.
mation: an
attacker could use it to tie traffic back to the originating User Equi
pment,
despite the User Equipment having changed identifiers.
</t> </t>
</section> </section>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation librarie
s:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (
as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml
"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x
ml")
Both are cited textually in the same manner: by using xref elements. <displayreference target="I-D.pfister-capport-pvd" to="CAPPORT-PVD"/>
If you use the PI option, xml2rfc will, by default, try to find included fil
es in the same
directory as the including file. You can also define the XML_LIBRARY environ
ment variable
with a value containing a set of directories to search. These can be either
in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="BCP" value="14"/>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization/>
</author>
<date year="1997" month="March"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
</reference>
<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8
174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor='RFC7710bis'>
<front>
<title>Captive-Portal Identification in DHCP / RA</title>
<author initials='W' surname='Kumari' fullname='Warren Kumari'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<organization /> xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
xml"/>
<author initials='E' surname='Kline' fullname='Erik Kline'> <!-- [I-D.ietf-capport-rfc7710bis] Published as RFC 8910 -->
<organization />
</author>
<date month='January' day='12' year='2020' /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8910. xml"/>
<abstract><t>In many environments offering short-term or temporary Internet acce <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7556.
ss (such as coffee shops), it is common to start new connections in a captive po xml"/>
rtal mode. This highly restricts what the customer can do until the customer ha <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6125.
s authenticated. This document describes a DHCP option (and a Router Advertisem xml"/>
ent (RA) extension) to inform clients that they are behind some sort of captive- <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2818.
portal device, and that they will need to authenticate to get Internet access. xml"/>
It is not a full solution to address all of the issues that clients may have wit
h captive portals; it is designed to be used in larger solutions. The method of </references>
authenticating to, and interacting with the captive portal is out of scope of t
his document. [ This document is being collaborated on in Github at: https://gi
thub.com/wkumari/draft-ekwk-capport-rfc7710bis. The most recent version of the
document, open issues, etc should all be available here. The authors (gratefull
y) accept pull requests. Text in square brackets will be removed before publica
tion. ]</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-capport-rfc7710bis-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-capport-rfc7710bi
s-01.txt' />
</reference>
<reference anchor="RFC7556" target="https://www.rfc-editor.org/info/rfc7
556" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.75
56.xml">
<front>
<title>Multiple Provisioning Domain Architecture</title>
<seriesInfo name="DOI" value="10.17487/RFC7556"/>
<seriesInfo name="RFC" value="7556"/>
<author initials="D." surname="Anipko" fullname="D. Anipko" role="ed
itor">
<organization/>
</author>
<date year="2015" month="June"/>
<abstract>
<t>This document is a product of the work of the Multiple Interfac
es Architecture Design team. It outlines a solution framework for some of the i
ssues experienced by nodes that can be attached to multiple networks simultaneou
sly. The framework defines the concept of a Provisioning Domain (PvD), which is
a consistent set of network configuration information. PvD-aware nodes learn P
vD-specific information from the networks they are attached to and/or other sour
ces. PvDs are used to enable separation and configuration consistency in the pr
esence of multiple concurrent connections.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6125" target="https://www.rfc-editor.org/info/rfc6
125">
<front>
<title>Representation and Verification of Domain-Based Applicati
on Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
Certificates in the Context of Transport Layer Security (TLS)</title>
<author initials="P." surname="Saint-Andre" fullname="P. Saint-A
ndre">
<organization/>
</author>
<author initials="J." surname="Hodges" fullname="J. Hodges">
<organization/>
</author>
<date year="2011" month="March"/>
<abstract>
<t>Many application technologies enable secure communication
between two entities by means of Internet Public Key Infrastructure Using X.509
(PKIX) certificates in the context of Transport Layer Security (TLS). This docu
ment specifies procedures for representing and verifying the identity of applica
tion services in such interactions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6125"/>
<seriesInfo name="DOI" value="10.17487/RFC6125"/>
</reference>
<reference anchor="RFC2818" target="https://www.rfc-editor.org/info/rfc2
818">
<front>
<title>HTTP Over TLS</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2000" month="May"/>
<abstract>
<t>This memo describes how to use Transport Layer Security (TLS) t
o secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This
memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2818"/>
<seriesInfo name="DOI" value="10.17487/RFC2818"/>
</reference>
</references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3
986"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.
<front> xml"/>
<title>Uniform Resource Identifier (URI): Generic Syntax</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4213.
<author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee xml"/>
"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499.
<organization/> xml"/>
</author>
<author initials="R." surname="Fielding" fullname="R. Fielding"> <!-- [I-D.pfister-capport-pvd] IESG state Expired -->
<organization/>
</author> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.pfister
<author initials="L." surname="Masinter" fullname="L. Masinter"> -capport-pvd.xml"/>
<organization/>
</author> <!-- [I-D.ietf-capport-api] Published as RFC 8908 -->
<date year="2005" month="January"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8908.
<t> xml"/>
A Uniform Resource Identifier (URI) is a compact sequence of chara
cters that identifies an abstract or physical resource. This specification defin
es the generic URI syntax and a process for resolving URI references that might
be in relative form, along with guidelines and security considerations for the u
se of URIs on the Internet. The URI syntax defines a grammar that is a superset
of all valid URIs, allowing an implementation to parse the common components of
a URI reference without knowing the scheme-specific requirements of every possib
le identifier. This specification does not define a generative grammar for URIs;
that task is performed by the individual specifications of each URI scheme. [ST
ANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="RFC4213" target="https://www.rfc-editor.org/info/rfc4
213">
<front>
<title>Basic Transition Mechanisms for IPv6 Hosts and Routers</t
itle>
<author initials="E." surname="Nordmark" fullname="E. Nordmark">
<organization/>
</author>
<author initials="R." surname="Gilligan" fullname="R. Gilligan">
<organization/>
</author>
<date year="2005" month="October"/>
<abstract>
<t>This document specifies IPv4 compatibility mechanisms tha
t can be implemented by IPv6 hosts and routers. Two mechanisms are specified, du
al stack and configured tunneling. Dual stack implies providing complete impleme
ntations of both versions of the Internet Protocol (IPv4 and IPv6), and configur
ed tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing
infrastructures.</t>
<t>This document obsoletes RFC 2893. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4213"/>
<seriesInfo name="DOI" value="10.17487/RFC4213"/>
</reference>
<reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8
499">
<front>
<title>DNS Terminology</title>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization/>
</author>
<author initials="A." surname="Sullivan" fullname="A. Sullivan">
<organization/>
</author>
<author initials="K." surname="Fujiwara" fullname="K. Fujiwara">
<organization/>
</author>
<date year="2019" month="January"/>
<abstract>
<t>The Domain Name System (DNS) is defined in literally dozens of
different RFCs. The terminology used by implementers and developers of DNS prot
ocols, and by operators of DNS systems, has sometimes changed in the decades sin
ce the DNS was first defined. This document gives current definitions for many
of the terms used in the DNS in a single document.</t>
<t>This document obsoletes RFC 7719 and updates RFC 2308.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="219"/>
<seriesInfo name="RFC" value="8499"/>
<seriesInfo name="DOI" value="10.17487/RFC8499"/>
</reference>
<reference anchor="I-D.pfister-capport-pvd" xml:base="https://xml2rfc.to
ols.ietf.org/public/rfc/bibxml3/reference.I-D.pfister-capport-pvd.xml" target="h
ttp://www.ietf.org/internet-drafts/draft-pfister-capport-pvd-00.txt">
<front>
<title>Using Provisioning Domains for Captive Portal Discovery</titl
e>
<seriesInfo name="Internet-Draft" value="draft-pfister-capport-pvd-0
0"/>
<author initials="P" surname="Pfister" fullname="Pierre Pfister">
<organization/>
</author>
<author initials="T" surname="Pauly" fullname="Tommy Pauly">
<organization/>
</author>
<date month="June" day="30" year="2018"/>
<abstract>
<t>Devices that connect to Captive Portals need a way to identify
that the network is restricted and discover a method for opening
up access. This document defines how to use Provisioning Domain
Additional Information to discover a Captive Portal API URI.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-capport-api">
<front>
<title>Captive Portal API</title>
<author initials="T" surname="Pauly" fullname="Tommy Pauly">
<organization/>
</author>
<author initials="D" surname="Thakore" fullname="Darshak Thakore">
<organization/>
</author>
<date month="March" day="31" year="2020"/>
<abstract>
<t>This document describes an HTTP API that allows clients to inte
ract with a Captive Portal system. With this API, clients can discover how to g
et out of captivity and fetch state about their Captive Portal sessions.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-capport-api-06"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-i
etf-capport-api-06.txt"/>
</reference>
</references> </references>
</references> </references>
<section anchor="app-additional"> <section anchor="app-additional">
<name>Existing Captive Portal Detection Implementations</name> <name>Existing Captive Portal Detection Implementations</name>
<t> <t>
Operating systems and user applications may perform various tests when Operating systems and user applications may perform various tests when
network connectivity is established to determine if the device is network connectivity is established to determine if the device is
attached to a network with a captive portal present. A common method is attached to a network with a captive portal present. A common method is
to attempt to make a HTTP request to a known, vendor-hosted endpoint with to attempt to make an HTTP request to a known, vendor-hosted endpoint wit h
a fixed response. Any other response is interpreted as a signal that a a fixed response. Any other response is interpreted as a signal that a
captive portal is present. This check is typically not secured with TLS, captive portal is present. This check is typically not secured with TLS,
as a network with a captive portal may intercept the connection, leading as a network with a captive portal may intercept the connection, leading
to a host name mismatch. This has been referred to as a "canary" request to a host name mismatch. This has been referred to as a "canary" request
because, like the canary in the coal mine, it can be the first sign because, like the canary in the coal mine, it can be the first sign
that something is wrong. that something is wrong.
</t> </t>
<t> <t>
Another test that can be performed is a DNS lookup to a known address Another test that can be performed is a DNS lookup to a known address
with an expected answer. If the answer differs from the expected answer, with an expected answer. If the answer differs from the expected answer,
the equipment detects that a captive portal is present. the equipment detects that a captive portal is present.
DNS queries over TCP or HTTPS are less likely to be modified than DNS DNS queries over TCP or HTTPS are less likely to be modified than DNS
queries over UDP due to the complexity of implementation. queries over UDP due to the complexity of implementation.
</t> </t>
<t> <t>
The different tests may produce different conclusions, varying by The different tests may produce different conclusions, varying by
whether or not the implementation treats both TCP and UDP traffic, whether or not the implementation treats both TCP and UDP traffic
and by which types of DNS are intercepted. and by which types of DNS are intercepted.
</t> </t>
<t> <t>
Malicious or misconfigured networks with a captive portal present may Malicious or misconfigured networks with a captive portal present may
not intercept these canary requests and choose to pass them through or de cide to not intercept these canary requests and choose to pass them through or de cide to
impersonate, leading to the device having a false negative. impersonate, leading to the device having a false negative.
</t> </t>
</section> </section>
<section anchor="Acknowledgments" numbered="false">
<name>Acknowledgments</name>
<t>The authors thank <contact fullname="Lorenzo Colitti"/> for providing
the majority of the content for the Captive Portal Signal
requirements.</t>
<t>The authors thank <contact fullname="Benjamin Kaduk"/> for providing
the content related to TLS certificate validation of the API Server.</t>
<t>The authors thank <contact fullname="Michael Richardson"/> for
providing wording requiring DNSSEC and TLS to operate without the user
adding exceptions.</t>
<t>The authors thank various individuals for their feedback on
the mailing list and during the IETF 98 hackathon:
<contact fullname="David Bird"/>,
<contact fullname="Erik Kline"/>,
<contact fullname="Alexis La Goulette"/>,
<contact fullname="Alex Roscoe"/>,
<contact fullname="Darshak Thakore"/>,
and <contact fullname="Vincent van Dam"/>.
</t>
</section>
<!-- [rfced] Terminology
a) We see instances of both "Captive Portal" (capitalized) and "captive
portal" (lowercase) in this document. Please let us know if any updates should
be made for consistency. We see that RFC 8910 mostly uses the lowercase form
in general text, but RFC 8908 seems to mostly use the capitalized form in
general text.
Note that we will apply your decision here to "User Portal" as well.
b) We note inconsistencies in the terms listed below. We chose the form on the
right. Please let us know any objections.
Expire vs. expire
External Network vs. external network
Identifier vs. identifier
user equipment (1 instance) vs. User Equipment (143 instances)
Captive Portal Solutions vs. captive portal solutions
the User vs. the user
Note: We did not update this in the context of "User Equipment" or "User
Portal".
d) In the following sentences (or any others), should "User Equipment" read
"User Equipments"? Note that "equipment" is typically an uncountable noun;
however, we see the plural "User Equipments" used once in past RFCs, and we
see a number of instances of the plural acronym "UEs".
THIS ISN:T REALLY RESOLVED. JUST LEAVE AS IS?
Original:
If multiple User Equipment
is attached to the network on the same physical interface,…
...
Independent Captive Portals MAY use the same identifying value to
identify different User Equipment.
...
The Captive Portal MUST associate the User Equipment with an
identifier that is unique among the User Equipment that are interacting
with the Captive Portal at that time.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 123 change blocks. 
769 lines changed or deleted 543 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/