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 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/ |