<?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 --> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     category="info" consensus="true"
     docName="draft-ietf-capport-architecture-10" number="8952"
     ipr="trust200902" tocInclude="true" tocDepth="4" symRefs="true"
     sortRefs="true" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 2.37.2 -->
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" -->
  <!-- ***** FRONT MATTER ***** -->

  <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</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-capport-architecture-10"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->
    <!-- Another author who claims to be an editor --> name="RFC" value="8952"/>

    <author fullname="Kyle Larose" initials="K." surname="Larose">
      <organization>Agilicus</organization>
      <address>
        <email>kyle@agilicus.com</email>
        <!-- uri and facsimile elements may also be added -->

      </address>
    </author>
    <author fullname="David Dolson" initials="D." surname="Dolson">
      <address>
        <email>ddolson@acm.org</email>
        <!-- uri and facsimile elements may also be added -->

      </address>
    </author>
    <author fullname="Heng Liu" initials="H." surname="Liu">
      <organization>Google</organization>
      <address>
        <email>liucougar@google.com</email>
      </address>
    </author>
    <date year="2020"/> year="2020" month="November" />

    <area>art</area>
    <workgroup>Internet Engineering Task Force</workgroup>

<!-- If the month and year are both specified and are the current ones, xml2rfc will fill [rfced] Please insert any keywords (beyond those that appear in the current day
title) for you. If only the current year is specified, xml2rfc will fill
        in the current day use on https://www.rfc-editor.org/search.
-->

<keyword>example</keyword>

    <abstract>
      <t>This document describes a captive portal architecture.
        Network provisioning protocols such as DHCP or Router Advertisements (RAs),
        an optional signaling protocol, and month for you. If the year is not an HTTP API are used to provide the current one, it solution.
      </t>
    </abstract>
  </front>
  <middle>
    <section>
      <name>Introduction</name>
      <t>
       In this document, "Captive Portal" is
        necessary used to specify at least a month (xml2rfc assumes day="1" if not specified for the
        purpose of calculating the expiry date).  With drafts it is normally sufficient to
        specify just the year. -->
    <!-- Meta-data Declarations -->
    <area>art</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.
        If this element is not present, the default is "Network Working Group",
        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
        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>
      <t>This document describes a captive portal architecture.
        Network provisioning protocols such as DHCP or Router Advertisements (RAs),
        an optional signaling protocol, and an HTTP API are used to provide the solution.
      </t>
    </abstract>
  </front>
  <middle>
    <section>
      <name>Introduction</name>
      <t>
       In this document, "Captive Portal" is used to describe describe a network to
       which a device may be voluntarily attached, such that network access is
       limited until some requirements have been fulfilled.  Typically  Typically, a user
       is required to use a web browser to fulfill requirements imposed by the
       network operator, such as reading advertisements, accepting an
       acceptable-use policy, or providing some form of credentials.
      </t>
      <t>
       Implementations of captive portals generally require a web server, some
       method to allow/block traffic, and some method to alert the user.
       Common methods of alerting the user in implementations prior to this
       work involve modifying HTTP or DNS traffic.
      </t>
      <t>
       This document describes an architecture for implementing captive
       portals while addressing most of the problems arising for current
       captive portal mechanisms. The architecture is guided by these
       requirements:
      </t>
      <ul spacing="normal">
        <li>Current captive portal solutions typically implement some variations
            of forging DNS or HTTP responses.
            Some attempt man-in-the-middle (MITM) proxy of HTTPS in
            order to forge reponses. responses.
            Captive Portal Solutions portal solutions should not have to break any protocols or
            otherwise act in the manner of an attacker.
            Therefore, solutions MUST NOT <bcp14>MUST NOT</bcp14> require the forging of responses from
            DNS or HTTP servers, servers or from any other protocol.</li>
        <li>Solutions MUST <bcp14>MUST</bcp14> permit clients to perform DNSSEC validation, which rules out solutions
            that forge DNS responses.
            Solutions SHOULD <bcp14>SHOULD</bcp14> permit clients to detect and avoid TLS man-in-the-middle attacks
            without requiring a human to perform any kind of "exception" processing.</li>
        <li>To maximize universality and adoption, solutions MUST <bcp14>MUST</bcp14> operate at the
            layer of Internet Protocol (IP) or above, not being specific to any
            particular access technology such as Cable, WiFi cable, Wi-Fi, or mobile
            telecom.</li>
        <li>Solutions SHOULD <bcp14>SHOULD</bcp14> allow a device to query the
        network to determine whether the device is captive, without the
        solution being coupled to forging intercepted protocols or requiring
        the device to make sacrificial queries to "canary" URIs to check for
        response tampering (see <xref target="app-additional"/>). Current
        captive portal solutions that work by affecting DNS or HTTP generally
        only function as intended with browsers, breaking other applications
        using those protocols; applications using other protocols are not
        alerted that the network is a captive portal.</li>
        <li>The state of captivity SHOULD <bcp14>SHOULD</bcp14> be explicitly available to devices via
            a standard protocol, rather than having to infer the state indirectly.</li>
        <li>The architecture MUST <bcp14>MUST</bcp14> provide a path of incremental migration,
            acknowledging the existence of a huge variety of pre-existing
            portals and end-user device implementations and software versions.
            This requirement is not to recommend or standardize existing
            approaches, but rather to provide device and portal implementors a path
            to a new standard.</li>
      </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>
       A side-benefit side benefit of the architecture described in this document is that
       devices without user interfaces are able to identify parameters of
       captivity. However, this document does not describe a mechanism for
       such devices to negotiate for unrestricted network access. A future
       document could provide a solution to devices without user
       interfaces. This document focuses on devices with user interfaces.
      </t>
      <t>
       The architecture uses the following mechanisms:
      </t>
      <ul spacing="normal">
        <li>Network provisioning protocols provide end-user devices with a
        Uniform Resource Identifier (URI) <xref target="RFC3986"/> (URI) for the API
        that end-user devices query for information about what is required to
        escape captivity. DHCP, DHCPv6, and
            Router-Advertisement Router Advertisement options for
        this purpose are available in <xref target="RFC7710bis"/>. target="RFC8910"/>. Other
        protocols (such as RADIUS), Provisioning Domains <xref
        target="I-D.pfister-capport-pvd"/>, or static configuration may also
        be used to convey this Captive Portal API URI.  A device MAY
        <bcp14>MAY</bcp14> query this API at any time to determine whether the
        network is holding the device in a captive state.
         </li>
        <li>A Captive Portal can signal User Equipment in response to
        transmissions by the User Equipment. This signal works in response to
        any Internet protocol, protocol and is not done by modifying protocols in-band. in band.
        This signal does not carry the Captive Portal API URI; rather rather, it
        provides a signal to the User Equipment that it is in a captive state.
        </li>
        <li>
            Receipt of a Captive Portal Signal provides a hint that User Equipment could be captive.
            In response, the device MAY <bcp14>MAY</bcp14> query the provisioned API to obtain
            information about the network state.
            The device can take immediate action to satisfy the portal
            (according to its configuration/policy).
         </li>
      </ul>
      <t>
       The architecture attempts to provide confidentiality, authentication, and safety mechanisms
       to the extent possible.
      </t>
      <section>
        <name>Requirements Language</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
	  "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP
	  14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
        </t>

      </section>
      <section>
        <name>Terminology</name>
        <t>Captive Portal: A

<dl newline="true">

<dt>Captive Portal
</dt>
<dd>A network which that limits the communication of attached devices to restricted
hosts until the user has satisfied Captive Portal Conditions, after which
access is permitted to a wider set of hosts (typically the Internet).</t>
        <t>Captive Internet).
</dd>

<dt>Captive Portal Conditions: site-specific Conditions
</dt>
<dd>Site-specific requirements that a user or device must satisfy in order to
gain access to the wider network.</t>
        <t>Captive network.
</dd>

<dt>Captive Portal Enforcement Device: The Device
</dt>
<dd>The network equipment which that enforces the traffic restriction. Also known
as Enforcement Device.</t>
        <t>Captive "Enforcement Device".
</dd>

<dt>Captive Portal User Equipment: Also known as User Equipment. A Equipment
</dt>
<dd>A device
          which that has voluntarily joined a
network for purposes of communicating beyond the constraints of the Captive Portal.</t>
        <t>User Portal: The
Portal. Also known as "User Equipment".
</dd>

<dt>User Portal
</dt>
<dd>The web server providing a user interface for assisting the user in
satisfying the conditions to escape
          captivity.</t>
        <t>Captive captivity.
</dd>

<dt>Captive Portal API: Also known as API. An API
</dt>
<dd>An HTTP API allowing User Equipment to query information about its state
of captivity within the Captive Portal. This information might include how to
obtain full network access (e.g. (e.g., by visting visiting a URI).
        </t>
        <t>Captive Portal API Server: Also known as "API".
</dd>

<dt>Captive Portal API Server. A Server
</dt>
<dd>A server hosting the Captive Portal API.
        </t>
        <t>Captive Portal Signal: A Also known as "API Server".
</dd>

<dt>Captive Portal Signal
</dt>
<dd>A notification from the network used to signal to the User Equipment that
the state of its captivity could have changed.
        </t>
        <t>Captive
</dd>

<dt>Captive Portal Signaling Protocol: Also known as Signaling Protocol. The Protocol
</dt>
<dd>The protocol for communicating Captive Portal Signals.
        </t>
        <t>
        Captive Portal Session: Also known as
"Signaling Protocol".
</dd>

<dt>Captive Portal Session
</dt>
<dd>Also referred to simply as the “session”, "Session", a Captive Portal Session is the
association for a particular User Equipment instance that starts when it interacts with
the Captive Portal and gains open access to the network, network and ends when the
User Equipment moves back into the original captive state. The Captive Network
maintains the state of each active Session, 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 <xref
target="ue_identity"/>).
        </t>
</dd>

</dl>

      </section>
    </section>
    <section>
      <name>Components</name>
      <section anchor="section_client">
        <name>User Equipment</name>
        <t>
       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
       Internet access). The User Equipment communication is typically
       restricted by the Enforcement Device, described in <xref target="section_capport_enforcement"/>,
       until site-specific requirements have been met.
        </t>
        <t>
        This document only considers devices with web browsers, with web
        applications being the means of satisfying Captive Portal Conditions.
        An example of such User Equipment is a smart phone.
        </t>
        <t>
        The User Equipment:
        </t>
        <ul spacing="normal">
          <li>SHOULD
          <li><bcp14>SHOULD</bcp14> support provisioning of the URI for the
          Captive Portal API (e.g., by DHCP)</li>
          <li>SHOULD DHCP).</li>
          <li><bcp14>SHOULD</bcp14> distinguish Captive Portal API access per
          network interface, in the manner of Provisioning Domain Architecture
          <xref target="RFC7556"/>.</li>
          <li>SHOULD
          <li><bcp14>SHOULD</bcp14> have a non-spoofable mechanism for
          notifying the user of the Captive Portal</li>
          <li>SHOULD Portal.</li>
          <li><bcp14>SHOULD</bcp14> have a web browser so that the user may
          navigate to the User Portal.</li>
          <li>SHOULD
          <li><bcp14>SHOULD</bcp14> support updates to the Captive Portal API
          URI from the network provisioning
              service.</li>
          <li>MAY Provisioning Service.</li>
          <li><bcp14>MAY</bcp14> prevent applications from using networks that
          do not grant full network access. E.g., For example, a device connected to a
          mobile network may be connecting to a captive WiFi Wi-Fi network; the
          operating system could avoid updating the default route to a device
          on the captive WiFi Wi-Fi network until network access restrictions have been
          lifted (excepting access to the User Portal) in the new
          network. This has been termed "make before break".</li>
        </ul>
        <t>
        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,
        (b) the requirements may be fulfilled by manually visiting the captive
	portal web application, and (c) legacy devices must continue to be
        supported.
        </t>
        <t>
        If User Equipment supports the Captive Portal API, it MUST
        <bcp14>MUST</bcp14> validate the API server's Server's TLS certificate (see
        <xref target="RFC2818"/>) according to the procedures in <xref
        target="RFC6125"/>.  The API server's Server's URI is obtained via a network
        provisioning protocol, which will typically provide a hostname to be
        used in TLS server certificate validation, against a DNS-ID in the
        server certificate.  If the API server Server is identified by IP address,
        the iPAddress subjectAltName is used to validate the server
        certificate.  An Enforcement Device SHOULD <bcp14>SHOULD</bcp14> allow access
        to any services that User Equipment could need to contact to perform
        certificate validation, such as OCSP Online Certificate Status Protocol
        (OCSP) responders, CRLs, Certificate Revocation Lists (CRLs), and NTP
        servers; see Section 4.1 of <xref target="I-D.ietf-capport-api"/> target="RFC8908" sectionFormat="of" section="4.1"/>
        for more information.  If certificate validation fails, User Equipment MUST NOT
        <bcp14>MUST NOT</bcp14> make any calls to the API
        server. Server.
        </t>
        <t>
        The User Equipment can store the last response it received from the
	Captive Portal API
        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
        Equipment might compare a timestamp indicating when the session Session expires to the current
        time. Storing state in this way can reduce the need for communication with the
        Captive Portal API. However, it could lead to the state becoming
        stale if the User Equipment's view of the relevant conditions (byte quota, for example)
        is not consistent with the Captive Portal API's.
        </t>
      </section>
      <section anchor="section_provisioning">
        <name>Provisioning Service</name>
        <t>
          The Provisioning Service is primarily responsible for providing a
          Captive Portal API URI to the User Equipment when it connects to the
          network, and later if the URI changes.  The provisioning service Provisioning Service
          could also be the same service which that is responsible for provisioning
          the User Equipment for access to the Captive Portal (e.g., by
          providing it with an IP address).  This section discusses two
          mechanisms which that may be used to provide the Captive Portal API URI
          to the User Equipment.
        </t>
        <section anchor="section_dhcp">
          <name>DHCP or Router Advertisements</name>
          <t>
           A standard for providing a Captive Portal API URI using DHCP or Router
           Advertisements is described in <xref target="RFC7710bis"/>. target="RFC8910"/>.  The
           captive portal architecture expects this URI to indicate the API described
           in <xref target="section_api"/>.
          </t>
        </section>
        <section anchor="section_pvd">
          <name>Provisioning Domains</name>
          <t>

<!-- [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>
           <xref target="I-D.pfister-capport-pvd"/>
           proposes a mechanism for User Equipment to be provided with PvD
           Provisioning Domain (PvD) Bootstrap Information containing the URI
           for the API described in <xref target="section_api"/>.
          </t>
        </section>
      </section>
      <section anchor="section_api">
        <name>Captive Portal API Server</name>
        <t>
         The purpose of a Captive Portal API is to permit a query of
         Captive Portal state without interrupting the user.  This API thereby
         removes the need for User Equipment to perform clear-text "canary"
         (see <xref target="app-additional"/>) queries to check for response
         tampering.
        </t>
        <t>
         The URI of this API will have been provisioned to the User Equipment.
         (Refer to <xref target="section_provisioning"/>). target="section_provisioning"/>.)
        </t>
        <t>
         This architecture expects the User Equipment to query the API when the
         User Equipment attaches to the network and multiple times thereafter.
         Therefore
         Therefore, the API MUST <bcp14>MUST</bcp14> support multiple repeated queries from the same
         User Equipment and return the state of captivity for the equipment.
        </t>
        <t>
         At minimum, the API MUST <bcp14>MUST</bcp14> provide the state of captivity. Further Further, the
         API MUST <bcp14>MUST</bcp14> be able to provide a URI for the User Portal. The scheme for
         the URI MUST <bcp14>MUST</bcp14> be https "https" so that the User Equipment communicates with
         the User Portal over TLS.
        </t>
        <t>
         If the API receives a request for state that does not correspond to the
         requesting User Equipment, the API SHOULD <bcp14>SHOULD</bcp14> deny access.  Given that the
         API might use the User Equipment's identifier for authentication, this
         requirement motivates <xref target="id_recommended_hard"/>.
        </t>
         <t>
         A caller to the API needs to be presented with evidence that the
         content it is receiving is for a version of the API that it
         supports. For an 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.
        </t>
        <t>
         When User Equipment receives Captive Portal Signals, the User Equipment
         MAY
         <bcp14>MAY</bcp14> query the API to check its state of captivity.
         The User Equipment SHOULD <bcp14>SHOULD</bcp14> rate-limit these API queries in the event of
         the signal being flooded. (See <xref target="Security"/>.)
        </t>
        <t>
         The API MUST <bcp14>MUST</bcp14> be extensible to support future use-cases use cases by allowing
         extensible information elements.
        </t>
        <t>
         The API MUST <bcp14>MUST</bcp14> use TLS to ensure server authentication.
         The implementation of the API MUST <bcp14>MUST</bcp14> ensure both confidentiality and
         integrity of any information provided by or required by it.
        </t>
        <t>
         This document does not specify the details of the API.
        </t>
      </section>
      <section anchor="section_capport_enforcement">
        <name>Captive Portal Enforcement Device</name>
        <t>
        The Enforcement Device component restricts the network access of
        User Equipment according to the site-specific policy. Typically Typically, User Equipment
        is permitted access to a small number of services (according to the policies
        of the network provider) and is denied general
        network access until it satisfies the Captive Portal Conditions.
        </t>
        <t>
       The Enforcement Device component:
        </t>

 <ul spacing="normal">
          <li>Allows traffic to pass for User Equipment that is permitted to
              use the network and has satisfied the Captive Portal Conditions.</li>
          <li>Blocks (discards) traffic according to the site-specific policy
            for User Equipment that has not yet satisfied the Captive Portal Conditions.</li>
          <li>Optionally signals User Equipment using the Captive Portal Signaling protocol Protocol
           if certain traffic is blocked.</li>
          <li>Permits User Equipment that has not satisfied the Captive Portal Conditions
          to access necessary APIs and web pages to fulfill requirements for escaping captivity.</li>
          <li>Updates allow/block rules per User Equipment in response to operations
           from the User Portal.</li>
        </ul>
      </section>
      <section anchor="section_signal">
        <name>Captive Portal Signal</name>
        <t>
        When User Equipment first connects to a network, or when there are changes in status,
        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 to receive
        updated information.  For instance, this signal might be generated when the end of a
        session
        Session is imminent, imminent or when network access was denied.
        For simplicity, and to reduce the attack surface, all signals SHOULD <bcp14>SHOULD</bcp14> be considered
        equivalent by the User Equipment: Equipment as a hint to contact the API.
        If future solutions have multiple signal types, each type SHOULD <bcp14>SHOULD</bcp14> be rate-limited
        independently.
        </t>
        <t>
        An Enforcement Device MUST <bcp14>MUST</bcp14> rate-limit any signal generated in response to these conditions.  See <xref target="section_signal_risks"/> for a discussion of
        risks related to a Captive Portal Signal.
        </t>
      </section>
      <section>
        <name>Component Diagram</name>
        <t>
            The following diagram shows the communication between each component in the
            case where the Captive Portal has a User Portal, Portal and the User Equipment
            chooses to visit the User Portal in response to discovering and interacting
            with the API Server.
        </t>
        <figure anchor="components">
          <name>Captive Portal Architecture Component Diagram</name>
          <artwork><![CDATA[
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
. CAPTIVE PORTAL                                                .
. +------------+  Join Network               +--------------+   .
. |            |+--------------------------->| Provisioning |   .
. |            |  Provision API URI          |  Service     |   .
. |            |<---------------------------+|              |   .
. |   User     |                             +--------------+   .
. | Equipment  |  Query captivity status     +-------------+    .
. |            |+--------------------------->|  API        |    .
. |            |  Captivity status response  |  Server     |    .
. |            |<---------------------------+|             |    .
. |            |                             +------+------+    .
. |            |                                    | Status    .
. |            | Portal UI page requests     +------+------+    .
. |            |+--------------------------->|             |    .
. |            | Portal UI pages             | User Portal |    .
. |            |<---------------------------+|             |    .
. +------------+                             |             |    .
.     ^   ^ |                                +-------------+    .
.     |   | | Data to/from ext. network               |         .
.     |   | +-----------------> +---------------+  Allow/Deny   .
.     |   +--------------------+|               |    Rules      .
.     |                         | Enforcement   |     |         .
.     |   Captive Portal Signal | Device        |<----+         .
.     +-------------------------+---------------+               .
.                                      ^ |                      .
.                                      | |                      .
.                          Data to/from external network        .
.                                      | |                      .
o . . . . . . . . . . . . . . . . . . .| |. . . . . . . . . . . o
                                       | v
                                  EXTERNAL NETWORK
	   ]]></artwork>
        </figure>
        <t>
        In the diagram:
        </t>
        <ul spacing="normal">
          <li>During provisioning (e.g., DHCP), and possibly later, the User
          Equipment acquires the Captive Portal API URI.</li>
          <li>The User Equipment queries the API to learn of its state of
          captivity. If captive, the User Equipment presents the portal user
          interface from the User Portal to the user.</li>
          <li>Based on user interaction, the User Portal directs the
          Enforcement Device to either allow or deny external network access
          for the User Equipment.</li>
          <li>The User Equipment attempts to communicate to the external
          network through the Enforcement Device.</li>
          <li>The Enforcement Device either allows the User Equipment's
          packets to the external network, network or blocks the packets. If blocking
          traffic and a signal has been implemented, it may respond with a
          Captive Portal Signal.</li>
        </ul>
        <t>
        The Provisioning Service, API Server, and User Portal are
        described as discrete functions. An implementation might provide the
        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.
        </t>
      </section>
    </section>
    <section anchor="ue_identity">
      <name>User Equipment Identity</name>
      <t>
             Multiple components in the architecture interact with both the User
             Equipment and each other. Since the User Equipment is the focus of
             these interactions, the components must be able to both identify the
             User Equipment from their interactions with it, it and to agree
             on the identity of the User Equipment when interacting with each
             other.
      </t>
      <t>
             The methods by which the components interact restrict the type of
             information that may be used as an identifying characteristics. characteristic. This
             section discusses the identifying characteristics.
      </t>

      <section anchor="id_identifiers">
        <name>Identifiers</name>
        <t>
                 An Identifier identifier is a characteristic of the User Equipment used by
                 the components of a Captive Portal to uniquely determine which
                 specific User Equipment instance is interacting with them.
                 An Identifier identifier can be a field contained in packets
                 sent by the User Equipment to the External Network. external network. Or, an
                 Identifier
                 identifier can be an ephemeral property not contained in packets
                 destined for the External Network, external network, but instead correlated with
                 such information through knowledge available to the different
                 components.
        </t>
      </section>
      <section anchor="id_recommended_props">
        <name>Recommended Properties</name>
        <t>
             The set of possible identifiers is quite large. However, in order
             to be considered a good identifier, an identifier SHOULD <bcp14>SHOULD</bcp14> meet the
             following criteria. Note that the optimal identifier will likely
             change depending on the position of the components in the network
             as well as the information available to them.

             An identifier SHOULD: <bcp14>SHOULD</bcp14>:
        </t>
        <ul spacing="normal">
          <li>uniquely identify the User Equipment</li>
          <li>be hard to spoof</li>
          <li>be visible to the API Server</li>
          <li>be visible to the Enforcement Device</li>
        </ul>
        <t>

             An identifier might only apply to the current point of network attachment. If the
             device moves to a different network location location, its identity could change.
        </t>
        <section anchor="id_recommended_unique">
          <name>Uniquely Identify User Equipment</name>
          <t>
                  The Captive Portal MUST <bcp14>MUST</bcp14> associate the User
                  Equipment with an identifier that is unique among all of the
                  User Equipment that are interacting with the Captive Portal at that
                  time.
          </t>
          <t>
                  Over time, the User Equipment assigned to an identifier
                  value MAY <bcp14>MAY</bcp14> change. Allowing the identified
                  device to change over time ensures that the space of
                  possible identifying values need not be overly large.
          </t>
          <t>
                  Independent Captive Portals MAY <bcp14>MAY</bcp14> use the same
                  identifying value to identify different User Equipment.
                  Equipment instances. Allowing independent captive portals to reuse
                  identifying values allows the identifier to be a property of
                  the local network, expanding the space of possible
                  identifiers.
          </t>
        </section>
        <section anchor="id_recommended_hard">
          <name>Hard to Spoof</name>

          <t>
                  A good identifier does not lend itself to being easily
                  spoofed. At no time should it be simple or straightforward
                  for one User Equipment instance to pretend to be another User Equipment,
                  Equipment instance, regardless of whether both are active at the same
                  time. This property is particularly important when the User
                  Equipment identifier is referenced externally by devices
                  such as billing systems, systems or where when the identity of the User
                  Equipment could imply liability.
          </t>
        </section>
        <section anchor="id_recommended_visible_api">
          <name>Visible to the API Server</name>
          <t>
                  Since the API Server will need to perform operations which that rely on the identity
                  of the User Equipment, such as answering a query about
                  whether the User Equipment is captive, the API Server needs
                  to be able to relate a request to the User Equipment making
                  the request.
          </t>
        </section>
        <section anchor="id_recommended_visible_ed">
          <name>Visible to the Enforcement Device</name>
          <t>
                  The Enforcement Device will decide on a per-packet basis
                  whether the packet should be forwarded to the external
                  network. Since this decision depends on which User Equipment
                  instance sent the packet, the Enforcement Device requires
                  that it be able to map the packet to its concept of the User
                  Equipment.
          </t>
        </section>
      </section>
      <section anchor="id_evaluating">
        <name>Evaluating Types of Identifiers</name>
        <t>
                 To evaluate whether a type of identifier is appropriate, one should consider
                 every recommended property from the perspective of interactions among
                 the components in the architecture. When comparing identifier types, choose
                 the one which that best satisfies all of the recommended properties. The
                 architecture does not provide an exact measure of how well an identifier
                 type satisfies a given property; care should be taken in performing the
                 evaluation.
        </t>
      </section>
      <section anchor="id_examples">
        <name>Example Identifier Types</name>
        <t>
                 This section provides some example identifier types, along with some
                 evaluation of whether they are suitable types. The list of identifier types
                 is not exhaustive. Other exhaustive; other types may be used. An important point to note
                 is that whether a given identifier type is suitable depends heavily on the
                 capabilities of the components and where in the network the components exist.
        </t>
        <section anchor="id_example_interface">
          <name>Physical Interface</name>
          <t>
                 The physical interface by which the User Equipment is attached to the
                 network can be used to identify the User Equipment. This identifier type has
                 the property of being extremely difficult to spoof: the User Equipment is
                 unaware of the property; one User Equipment instance cannot manipulate its
                 interactions to appear as though it is another.
          </t>

    <t>
                 Further, if only a single User Equipment instance is attached
                 to a given physical interface, then the identifier will be
                 unique. If multiple User Equipment
                 is instances are attached
                 to the network on the same physical interface, then this type
                 is not appropriate.
          </t>
          <t>
                 Another consideration related to uniqueness of the User
                 Equipment is that if the attached User Equipment changes,
                 both the API Server and the Enforcement Device MUST
                 <bcp14>MUST</bcp14> invalidate their state related to the
                 User Equipment.
          </t>
          <t>
                 The Enforcement Device needs to be aware of the physical
                 interface, which constrains the environment: environment; it must either
                 be part of the device providing physical access (e.g.,
                 implemented in firmware), or packets traversing the network
                 must be extended to include information about the source
                 physical interface (e.g. (e.g., a tunnel).
          </t>
          <t>
                 The API Server faces a similar problem, implying that it should co-exist with the
                 Enforcement Device, Device or that the Enforcement Device should extend requests to it
                 with the identifying information.
          </t>
        </section>
        <section anchor="id_example_IP_address">
          <name>IP Address</name>
          <t>
                  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
                  without causing the network to malfunction, so it is appropriate from the
                  perspective of uniqueness.
          </t>
          <t>
                  However, it may be possible to spoof the IP address, particularly for
                  malicious reasons where proper functioning of the network is not necessary
                  for the malicious actor. Consequently, any solution using the IP address
                  SHOULD
                  <bcp14>SHOULD</bcp14> proactively try to prevent spoofing of the IP address. Similarly,
                  if the mapping of IP address to User Equipment is changed, the components
                  of the architecture MUST <bcp14>MUST</bcp14> remove or update their mapping to prevent spoofing.
                  Demonstrations of return routeability, routability, such as that required for TCP
                  connection establishment, might be sufficient defense against spoofing,
                  though this might not be sufficient in networks that use broadcast media
                  (such as some wireless networks).
          </t>
          <t>
                  Since the IP address may traverse multiple segments of the network, more
                  flexibility is afforded to the Enforcement Device and the API Server: Server; they
                  simply must exist on a segment of the network where the IP address is still
                  unique. However, consider that a NAT may be deployed between the User Equipment
                  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.
          </t>
          <t>
                In some situations, the User Equipment may have multiple IP
                addresses (either IPv4, IPv6 IPv6, or a dual-stack <xref
                target="RFC4213"/> combination), combination) while still satisfying all of
                the recommended properties. This raises some challenges to the
                components of the network. For example, if the User Equipment
                tries to access the network with multiple IP addresses, should
                the Enforcement Device and API Server treat each IP address as
                a unique User Equipment, Equipment instance, or should it tie the multiple
                addresses together into one view of the subscriber?  An
                implementation MAY <bcp14>MAY</bcp14> do either. Attention should
                be paid to IPv6 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>
        </section>
        <section anchor="id_example_mac_address">
          <name>Media Access Control (MAC) Address</name>
          <t>
            The MAC address of a device is often used as an identifier in existing implementations.
            This document does not discuss the use of MAC addresses within a captive portal system, but they can be used
            as an identifier type, subject to the criteria in <xref target="id_recommended_props"/>.
          </t>
        </section>
      </section>
        <section anchor="context_free_uri">
          <name>Context-free
          <name>Context-Free URI</name>
          <t>
            A Captive Portal API needs to present information to clients
            that is unique to that client. To do this, some systems use
            information from the context of a request, such as the source
            address, to identify the User Equipment.
          </t>
          <t>
            Using information from context rather than information from the
            URI allows the same URI to be used for different clients. However,
            it also means that the resource is unable to provide relevant
            information if the User Equipment makes a request using a different network
            path. This might happen when User Equipment has multiple network interfaces.
            It might also happen if the address of the API provided by DNS
            depends on where the query originates (as in split DNS
            <xref target="RFC8499"/>).
          </t>
          <t>
            Accessing the API MAY <bcp14>MAY</bcp14> depend on contextual information. However,
            the URIs provided in the API SHOULD <bcp14>SHOULD</bcp14> be unique to the User Equipment and not
            dependent on contextual information to function correctly.
          </t>
          <t>
            Though a URI might still correctly resolve when the User Equipment makes the
            request from a different network, it is possible that some
            functions could be limited to when the User Equipment makes requests using the
            Captive Portal. For example, payment options could be absent or a
            warning could be displayed to indicate the payment is not for the
            current connection.
          </t>
          <t>
            URIs could include some means of identifying the User Equipment in
            the URIs.  However, including unauthenticated User Equipment
            identifiers in the URI may expose the service to spoofing or replay
            attacks.
          </t>
        </section>
    </section>
    <section anchor="section_workflow">
      <name>Solution Workflow</name>

      <t>
      This section aims to improve understanding by describing a possible
      workflow of solutions adhering to the architecture. Note that the section is
      not normative: normative; it describes only as a subset of possible implementations.
      </t>

      <section>
        <name>Initial Connection</name>
        <t>
      This section describes a possible workflow when User Equipment initially
      joins a Captive Portal.
        </t>
        <ol spacing="normal" type="1">
          <li>The User Equipment joins the Captive Portal by acquiring a DHCP
         lease, RA, or similar, acquiring provisioning information.</li>
          <li>The User Equipment learns the URI for the Captive Portal API from the
         provisioning information (e.g., <xref target="RFC7710bis"/>).</li> target="RFC8910"/>).</li>
          <li>The User Equipment accesses the Captive Portal API to receive parameters
         of the Captive Portal, including the User Portal URI. (This step replaces
         the clear-text query to a canary URI.)</li>
          <li>If necessary, the User user navigates to the User Portal to gain access to the
         external network.</li>
          <li>
            If the User user interacted with the User Portal to gain access to the external
            network in the previous step, the User Portal indicates to the Enforcement
            Device that the User Equipment is allowed to access the external network.
         </li>
          <li>The User Equipment attempts a connection outside the Captive Portal</li> Portal.</li>
          <li>If the requirements have been satisfied, the access is
          permitted;
         otherwise otherwise, the "Expired" behavior occurs.</li>
          <li>The User Equipment accesses the network until conditions Expire.</li> expire.</li>
        </ol>
      </section>
      <section>
        <name>Conditions About about to Expire</name>
        <t>
      This section describes a possible workflow when access is about to expire.
        </t>
        <ol spacing="normal" type="1">
          <li>Precondition: the API has provided the User Equipment with a duration
         over which its access is valid.</li>
          <li>The User Equipment is communicating with the outside network.</li>
          <li>
            The User Equipment detects that the length of time left
            for its access has fallen below a threshold by comparing its stored
            expiry time with the current time.
          </li>
          <li>The User Equipment visits the API again to validate the expiry time.</li>
          <li>If expiry is still imminent, the User Equipment prompts the user to access the
         User Portal URI again.</li>
          <li>The User user accepts the prompt displayed by the User Equipment.</li>
          <li>The User user extends their access through the User Portal via the User Equipment's user interface.</li>
          <li>The User Equipment's access to the outside network continues uninterrupted.</li>
        </ol>
      </section>
      <section>
        <name>Handling of Changes in Portal URI</name>
        <t>A different Captive Portal API URI could be returned in the following cases:</t>
        <ul spacing="normal">
          <li>If DHCP is used, a lease renewal/rebind may return a different Captive
          Portal API URI.</li>
          <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>
        </ul>
        <t>When the Network Provisioning Service updates the Captive Portal API URI, the User
           Equipment can retrieve updated state from the URI immediately, or it can wait
           as it normally would until the expiry conditions it retrieved from the old URI are
           about to expire.
        </t>
      </section>
    </section>

    <section anchor="Acknowledgments">
      <name>Acknowledgments</name>
      <t>The authors thank Lorenzo Colitti for providing the majority of the content
         for anchor="IANA">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
    <section anchor="Security">
      <name>Security Considerations</name>

      <section>
        <name>Trusting the Captive Portal Signal requirements.</t>
      <t>The authors thank Benjamin Kaduk for providing Network</name>
        <t>
         When joining a network, some trust is placed in the content related to TLS
         certificate validation of the API server.</t>
      <t>The authors thank 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 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">
      <name>IANA Considerations</name>
      <t>This memo includes no request to IANA.</t>
    </section>
    <section anchor="Security">
      <name>Security Considerations</name>
      <!--All drafts are required to have a security considerations section.  See RFC3552 -->
      <section>
        <name>Trusting the Network</name>
        <t>
         When joining a network, some trust is placed in the network operator.
         This is usually considered network operator.
         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
         decision, protocols can support authenticating that a network is operated
         by who claims to be operating it.  The Provisioning Domain
         Architecture <xref target="RFC7556"/> provides some discussion on
         authenticating an operator.
        </t>
        <t>
         The user makes an informed choice to visit and trust the Captive
         Portal URI. Since the network provides the Captive Portal URI to the user
         equipment,
         User Equipment, the network SHOULD <bcp14>SHOULD</bcp14> do so securely so
         that the user's trust in the network can extend to their trust of the
         Captive Portal URI. E.g., For example, the DHCPv6 AUTH option can sign this
         information.
        </t>
        <t>
         If a user decides to incorrectly trust an attacking network, they might
         be convinced to visit an attacking web page and unwittingly provide
         credentials to an attacker. Browsers can authenticate servers but
         cannot detect cleverly misspelled domains, for example.
        </t>
        <t>
         Further, the possibility of an on-path attacker in an attacking network
         introduces some risks. The attacker could redirect traffic to arbitrary
         destinations. The attacker could analyze the user's
         traffic leading to loss of confidentiality. Or, confidentiality, or the attacker could modify
         the traffic inline.
        </t>
      </section>
      <section>
        <name>Authenticated APIs</name>
        <t>
         The solution described here requires that when the User Equipment needs to
         access the API server, Server, the User Equipment authenticates the
         server; see <xref target="section_client"/>.
        </t>
        <t>
         The Captive Portal API URI might change during the Captive Portal Session.
         The User Equipment can apply the same trust mechanisms to the new URI as it
         did to the URI it received initially from the network provisioning service. Provisioning Service.
        </t>
      </section>
      <section>
        <name>Secure APIs</name>
        <t>
           The solution described here requires that the API be secured using TLS.
           This is required to allow the User Equipment and API Server to exchange
           secrets which that can be used to validate future interactions. The API MUST <bcp14>MUST</bcp14>
           ensure the integrity of this information, as well as its confidentiality.
        </t>
        <t>
           An attacker with access to this information might be able to
           masquerade as a specific User Equipment instance when interacting with the
           API, which could then allow them to masquerade as that User
           Equipment instance when interacting with the User Portal. This could give
           them the ability to determine whether the User Equipment has
           accessed the portal, or deny the User Equipment service by ending
           their session Session using mechanisms provided by the User Portal, or
           consume that User Equipment's quota. An attacker with the ability
           to modify the information could deny service to the User Equipment, Equipment
           or cause them to appear as a different User Equipment. Equipment instances.
        </t>
      </section>
      <section anchor="section_signal_risks">
        <name>Risks Associated with the Signaling Protocol</name>
        <t>
         If a Signaling Protocol is implemented, it may be possible for any user on
         the Internet to send signals in an attempt to cause the receiving equipment to
         communicate with the Captive Portal API. This has been considered, and implementations may
         address it in the following ways:
        </t>
        <ul spacing="normal">
          <li>The signal only signals to the User Equipment to query the API. It does not
              carry any information which that may mislead or misdirect the User Equipment.</li>
          <li>Even when responding to the signal, the User Equipment securely authenticates
               with API Servers.</li>
          <li>Accesses to

 <!-- AD approval required for below change?
-->

          <li>The User Equipment limits the Captive Portal API are rate-limited, rate at which it accesses the API,
          reducing the impact of an attack attempting to generate excessive
          load on either the User Equipment or API.  Note that because there
          is only one type of signal and one type of API request in response
          to the signal, this rate-limiting will not cause loss of signalling signaling
          information.
              </li>
        </ul>
      </section>
      <section>
        <name>User Options</name>
        <t>
         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
         about this.
         Devices MAY <bcp14>MAY</bcp14> permit users to disable automatic reaction to
         Captive Portal Signals Signal indications for privacy reasons.
         However, there would be the trade-off that the user doesn't get notified
         when network access is restricted.
         Hence, end-user devices MAY <bcp14>MAY</bcp14> allow users to manually control captive
         portal interactions, possibly on the granularity of Provisioning
         Domains.
        </t>
      </section>
      <section>
        <name>Privacy</name>
        <t>
          <xref target="ue_identity"/> describes a mechanism by which all components within
          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.
          Implementers and designers of Captive Portals should take care to ensure that
          identifiers, if stored, are stored securely. Likewise, if any component
          communicates the identifier over the network, it should ensure the confidentiality
          of the identifier on the wire by using encryption such as TLS.
        </t>
        <t>
          There are benefits to choosing mutable anonymous identifiers. For
          example, User Equipment could cycle through multiple identifiers to
          help prevent long-term tracking. However, if the components of the
          network use an internal mapping to map the identity to a stable,
          long-term value in order to deal with changing identifiers, they
          need to treat that value as sensitive information: information; an attacker could
          use it to tie traffic back to the originating User Equipment, despite
          the User Equipment having changed identifiers.
        </t>
      </section>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->
    <!-- There are 2 ways to insert reference entries from the citation libraries:
    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.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included files in the same
    directory as the including file. You can also define the XML_LIBRARY environment 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/... ).-->

<displayreference target="I-D.pfister-capport-pvd" to="CAPPORT-PVD"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <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 signify the requirements in the specification.  These words are often capitalized. This document defines these words

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

<!-- [I-D.ietf-capport-rfc7710bis] Published as they should be interpreted in IETF documents.  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/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</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'>
    <organization />
</author>

<author initials='E' surname='Kline' fullname='Erik Kline'>
    <organization />
</author>

<date month='January' day='12' year='2020' />

<abstract><t>In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode.  This highly restricts what the customer can do until the customer has authenticated.  This document describes a DHCP option (and a Router Advertisement (RA) extension) to inform clients that they are behind some sort of captive-portal device, and that they will need to authenticate to get Internet access.  It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions.  The method of authenticating to, and interacting with the captive portal is out of scope of this document.  [ This document is being collaborated on in Github at: https://github.com/wkumari/draft-ekwk-capport-rfc7710bis.  The most recent version of the document, open issues, etc should all be available here.  The authors (gratefully) accept pull requests.  Text in square brackets will be removed before publication. ]</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-rfc7710bis-01.txt' />
</reference>
        <reference anchor="RFC7556" target="https://www.rfc-editor.org/info/rfc7556" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7556.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="editor">
              <organization/>
            </author>
            <date year="2015" month="June"/>
            <abstract>
              <t>This document is a product of the work of the Multiple Interfaces Architecture Design team.  It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously.  The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information.  PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources.  PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6125" target="https://www.rfc-editor.org/info/rfc6125">
            <front>
                <title>Representation and Verification of Domain-Based Application 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-Andre">
                <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 document specifies procedures for representing and verifying the identity of application 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/rfc2818">
          <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) to 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>
        <name>Informative References</name>
        <reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
              <organization/>
            </author>
            <author initials="R." surname="Fielding" fullname="R. Fielding">
              <organization/>
            </author>
            <author initials="L." surname="Masinter" fullname="L. Masinter">
              <organization/>
            </author>
            <date year="2005" month="January"/>
            <abstract>
              <t>
              A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines 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 use 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 possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-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/rfc4213">
            <front>
                <title>Basic Transition Mechanisms for IPv6 Hosts and Routers</title>
                <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 that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured 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/rfc8499">
          <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 protocols, and by operators of DNS systems, has sometimes changed in the decades since 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.tools.ietf.org/public/rfc/bibxml3/reference.I-D.pfister-capport-pvd.xml" target="http://www.ietf.org/internet-drafts/draft-pfister-capport-pvd-00.txt">
          <front>
            <title>Using Provisioning Domains for Captive Portal Discovery</title>
            <seriesInfo name="Internet-Draft" value="draft-pfister-capport-pvd-00"/>
            <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 interact with a Captive Portal system.  With this API, clients can discover how to get out of captivity and fetch 8910 -->

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8910.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7556.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml"/>

    </references>

      <references>
        <name>Informative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4213.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/>

<!--  [I-D.pfister-capport-pvd] IESG 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-ietf-capport-api-06.txt"/>
        </reference> Expired -->

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.pfister-capport-pvd.xml"/>

<!--  [I-D.ietf-capport-api] Published as RFC 8908 -->

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8908.xml"/>

      </references>
    </references>

    <section anchor="app-additional">
      <name>Existing Captive Portal Detection Implementations</name>
      <t>
       Operating systems and user applications may perform various tests when
       network connectivity is established to determine if the device is
       attached to a network with a captive portal present. A common method is
       to attempt to make a an HTTP request to a known, vendor-hosted endpoint with
       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,
       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
       because, like the canary in the coal mine, it can be the first sign
       that something is wrong.
      </t>

      <t>
       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,
       the equipment detects that a captive portal is present.
       DNS queries over TCP or HTTPS are less likely to be modified than DNS
       queries over UDP due to the complexity of implementation.
      </t>

      <t>
       The different tests may produce different conclusions, varying by
       whether or not the implementation treats both TCP and UDP traffic, traffic
       and by which types of DNS are intercepted.
      </t>

      <t>
       Malicious or misconfigured networks with a captive portal present may
       not intercept these canary requests and choose to pass them through or decide to
       impersonate, leading to the device having a false negative.
      </t>
    </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>
</rfc>