[要約] RFC 8952は、キャプティブポータルアーキテクチャに関する文書で、ネットワークへのアクセス前にユーザー認証や情報提供を行うシステムを標準化します。主に公共のWi-Fiなどで利用され、安全なインターネット接続の確立を目的としています。
Internet Engineering Task Force (IETF) K. Larose
Request for Comments: 8952 Agilicus
Category: Informational D. Dolson
ISSN: 2070-1721
H. Liu
Google
November 2020
Captive Portal Architecture
キャプティブポータルアーキテクチャ
Abstract
概要
This document describes a captive portal architecture. Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution.
このドキュメントでは、キャプティブポータルアーキテクチャについて説明します。DHCPまたはルータ広告（RAS）、オプションのシグナリングプロトコル、およびHTTP APIなどのネットワークプロビジョニングプロトコルがソリューションを提供するために使用されます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8952.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8952で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
1.2. Terminology
2. Components
2.1. User Equipment
2.2. Provisioning Service
2.2.1. DHCP or Router Advertisements
2.2.2. Provisioning Domains
2.3. Captive Portal API Server
2.4. Captive Portal Enforcement Device
2.5. Captive Portal Signal
2.6. Component Diagram
3. User Equipment Identity
3.1. Identifiers
3.2. Recommended Properties
3.2.1. Uniquely Identify User Equipment
3.2.2. Hard to Spoof
3.2.3. Visible to the API Server
3.2.4. Visible to the Enforcement Device
3.3. Evaluating Types of Identifiers
3.4. Example Identifier Types
3.4.1. Physical Interface
3.4.2. IP Address
3.4.3. Media Access Control (MAC) Address
3.5. Context-Free URI
4. Solution Workflow
4.1. Initial Connection
4.2. Conditions about to Expire
4.3. Handling of Changes in Portal URI
5. IANA Considerations
6. Security Considerations
6.1. Trusting the Network
6.2. Authenticated APIs
6.3. Secure APIs
6.4. Risks Associated with the Signaling Protocol
6.5. User Options
6.6. Privacy
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Existing Captive Portal Detection Implementations
Acknowledgments
Authors' Addresses
In this document, "Captive Portal" is used to describe a network to which a device may be voluntarily attached, such that network access is limited until some requirements have been fulfilled. Typically, a user is required to use a web browser to fulfill requirements imposed by the network operator, such as reading advertisements, accepting an acceptable-use policy, or providing some form of credentials.
この文書では、「キャプティブポータル」は、デバイスが自発的に取り付けられているネットワークを説明するために使用され、そのようにネットワークアクセスが満たされるまでネットワークアクセスが制限される。通常、ユーザは、広告を読み取ること、許容されるポリシーを受け入れるなど、ネットワークオペレータによって課される要件を満たすためにウェブブラウザを使用すること、または何らかの形式の資格情報を提供することが必要である。
Implementations of captive portals generally require a web server, some method to allow/block traffic, and some method to alert the user. Common methods of alerting the user in implementations prior to this work involve modifying HTTP or DNS traffic.
キャプティブポータルの実装は一般的にWebサーバー、トラフィックを許可/ブロックする方法、およびユーザーに警告する方法を必要とします。この作業の前に実装内のユーザーに警告する一般的な方法には、HTTPまたはDNSトラフィックの変更が含まれます。
This document describes an architecture for implementing captive portals while addressing most of the problems arising for current captive portal mechanisms. The architecture is guided by these requirements:
このドキュメントでは、現在のキャプティブポータルメカニズムに起因する問題のほとんどの問題に対処しながら、キャプティブポータルを実装するためのアーキテクチャについて説明します。アーキテクチャはこれらの要件によって導かれます。
* Current captive portal solutions typically implement some variations of forging DNS or HTTP responses. Some attempt man-in-the-middle (MITM) proxy of HTTPS in order to forge responses. Captive portal solutions should not have to break any protocols or otherwise act in the manner of an attacker. Therefore, solutions MUST NOT require the forging of responses from DNS or HTTP servers or from any other protocol.
* 現在のキャプティブ ポータル ソリューションは通常、DNS または HTTP 応答を偽造するいくつかのバリエーションを実装しています。 応答を偽造するために、HTTPS の中間者 (MITM) プロキシを試みる人もいます。 キャプティブ ポータル ソリューションは、プロトコルを破ったり、攻撃者のように振る舞ったりする必要はありません。 したがって、解決策は、DNS または HTTP サーバーまたはその他のプロトコルからの応答の偽造を要求してはなりません (MUST NOT)。
* Solutions MUST permit clients to perform DNSSEC validation, which rules out solutions that forge DNS responses. Solutions SHOULD permit clients to detect and avoid TLS man-in-the-middle attacks without requiring a human to perform any kind of "exception" processing.
* ソリューションは、クライアントがDNSSEC検証を実行することを許可する必要があります。これは、DNS応答をフォジェットするソリューションをルールを除いています。解決策は、人間があらゆる種類の「例外」処理を実行することを要求することなく、TLSマンインザマン攻撃を検出して回避することを許可する必要があります。
* To maximize universality and adoption, solutions MUST operate at the layer of Internet Protocol (IP) or above, not being specific to any particular access technology such as cable, Wi-Fi, or mobile telecom.
* 普遍性と採用を最大化するために、解決策はインターネットプロトコル（IP）以上で動作しなければなりません。ケーブル、Wi-Fi、またはモバイルテレコムなどの特定のアクセステクノロジに固有のものではありません。
* Solutions SHOULD 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 Appendix A). 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.
* 解決策は、デバイスがネットワークに問い合わせることを可能にし、デバイスが捕獲された瞬時プロトコルに結合されているか、またはデバイスが「カナリア」のURIを「カナリア」のURIに検査することを許可する（付録Aを参照）。DNSまたはHTTPに影響を与えることによって機能する現在の非責任のポータルソリューションは、一般にブラウザを使用して意図されたものだけであり、それらのプロトコルを使用して他のアプリケーションを破っています。他のプロトコルを使用したアプリケーションは、ネットワークがキャプティブポータルであることは警告されていません。
* The state of captivity SHOULD be explicitly available to devices via a standard protocol, rather than having to infer the state indirectly.
* 捕獲された状態は、間接的に状態を推測するのではなく、標準プロトコルを介してデバイスに明示的に利用可能であるべきです。
* The architecture MUST 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.
* アーキテクチャは、既存の既存のポータルとエンドユーザーデバイスの実装とソフトウェアバージョンの存在を認めて、増分移行のパスを提供しなければなりません。この要件は、既存のアプローチを推奨または標準化することではなく、むしろデバイスとポータルの実装者に新しい標準へのパスを提供することです。
A 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.
この文書に記載されているアーキテクチャの側面の利点は、ユーザーインターフェイスなしのデバイスが登録率のパラメータを識別できることです。ただし、この文書は、制限されていないネットワークアクセスのためにネゴシエートするためのそのようなデバイスのメカニズムを説明していません。将来の文書は、ユーザーインターフェイスなしでデバイスの解決策を提供できます。このドキュメントはユーザーインターフェイスを持つデバイスに焦点を当てています。
The architecture uses the following mechanisms:
アーキテクチャは次のメカニズムを使用します。
* Network provisioning protocols provide end-user devices with a Uniform Resource Identifier (URI) [RFC3986] for the API that end-user devices query for information about what is required to escape captivity. DHCP, DHCPv6, and Router Advertisement options for this purpose are available in [RFC8910]. Other protocols (such as RADIUS), Provisioning Domains [CAPPORT-PVD], or static configuration may also be used to convey this Captive Portal API URI. A device MAY query this API at any time to determine whether the network is holding the device in a captive state.
* ネットワークプロビジョニングプロトコルは、エンドユーザーデバイスがキャプチャー向けをエスケープするために必要なものについての情報を問い合わせるAPIに対して、URIリソースID（URI）[RFC3986]を備えたエンドユーザーデバイスを提供します。DHCP、DHCPv6、およびルーター広告オプションは、[RFC8910]で利用できます。他のプロトコル（RADIUSなど）、プロビジョニングドメイン[CAPPORT-PVD]、または静的構成もこのキャプティブポータルAPI URIを伝えるために使用されてもよい。デバイスは、ネットワークがデバイスを拘束状態に保持しているかどうかを判断するために、いつでもこのAPIに問い合わせることができます。
* A Captive Portal can signal User Equipment in response to transmissions by the User Equipment. This signal works in response to any Internet protocol and is not done by modifying protocols in band. This signal does not carry the Captive Portal API URI; rather, it provides a signal to the User Equipment that it is in a captive state.
* キャプティブポータルは、ユーザ機器による送信に応答してユーザ機器を知らせることができる。この信号は、任意のインターネットプロトコルに応答して機能し、帯域内のプロトコルを変更することによって行われません。この信号はキャプティブポータルAPI URIを運ばない。むしろ、それはそれが拘束状態にあることをユーザ機器に提供する。
* Receipt of a Captive Portal Signal provides a hint that User Equipment could be captive. In response, the device MAY 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).
* キャプティブポータル信号の受信は、ユーザー機器が拘束される可能性があるヒントを提供します。それに応答して、デバイスはプロビジョニングされたAPIに問い合わせることができ、ネットワーク状態に関する情報を取得することができる。このデバイスはポータルを満たすために即時の行動をとることができます（その構成/ポリシーに従って）。
The architecture attempts to provide confidentiality, authentication, and safety mechanisms to the extent possible.
アーキテクチャは、可能な限り機密性、認証、および安全メカニズムを提供しようとします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Captive Portal A network 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).
キャプティブポータルユーザーが非公開ポータル条件を満たすまで、接続されているデバイスの通信を制限するネットワークは、ユーザーがより広いホストセット（通常はインターネット）にアクセスできます。
Captive Portal Conditions Site-specific requirements that a user or device must satisfy in order to gain access to the wider network.
Portal Portal Conditionsサイト固有の要件は、より広いネットワークにアクセスするためにユーザーまたはデバイスが満たされなければならない必要があります。
Captive Portal Enforcement Device The network equipment that enforces the traffic restriction. Also known as "Enforcement Device".
キャプティブポータル施行装置交通制限を強制するネットワーク機器。「施行装置」とも呼ばれます。
Captive Portal User Equipment A device that has voluntarily joined a network for purposes of communicating beyond the constraints of the Captive Portal. Also known as "User Equipment".
キャプティブポータルユーザ機器拘束ポータルの制約を超えて通信する目的でネットワークに自発的に結合された装置。「ユーザー機器」とも呼ばれます。
User Portal The web server providing a user interface for assisting the user in satisfying the conditions to escape captivity.
ユーザーポータルWebサーバーは、ユーザーが捕獲率を逃がすための条件を満たすことでユーザーがユーザーを支援するためのユーザーインターフェイスを提供します。
Captive Portal API 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., by visiting a URI). Also known as "API".
Captive Portal API HTTP APIは、ユーザー機器がキャプティブポータル内の捕獲された状態に関する情報を照会することを可能にする。この情報は、（例えば、URIを訪問することによって）フルネットワークアクセスを取得する方法を含み得る。「API」とも呼ばれます。
Captive Portal API Server A server hosting the Captive Portal API. Also known as "API Server".
キャプティブポータルAPIサーバーキャプティブポータルAPIをホストしているサーバー。「APIサーバー」とも呼ばれます。
Captive Portal Signal A notification from the network used to signal to the User Equipment that the state of its captivity could have changed.
キャプティブポータル信号捕獲された状態が変更された可能性があることがユーザー機器に通知されるネットワークからの通知。
Captive Portal Signaling Protocol The protocol for communicating Captive Portal Signals. Also known as "Signaling Protocol".
キャプティブポータルシグナリングプロトコルキャプティブポータル信号を伝達するためのプロトコル。「シグナリングプロトコル」とも呼ばれます。
Captive Portal Session Also referred to simply as the "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 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 Section 3).
非公開ポータルセッションは、単に「セッション」とも呼ばれ、キャプティブポータルセッションは、キャプティブポータルと対話したときに開始され、ネットワークへのオープンアクセスを許可し、ユーザ機器が戻ってきたときに終了する特定のユーザ機器のインスタンスの関連付けです。元の拘束状態に。キャプティブネットワークは各アクティブセッションの状態を維持し、時間の長さまたは使用されるバイト数に基づいてセッションを制限できます。セッションは、ユーザー機器の識別子を使用して特定のユーザー機器インスタンスに関連付けられています（セクション3を参照）。
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 Section 2.4, until site-specific requirements have been met.
ユーザ機器は、ユーザがネットワーク上の全てのホストへのフルアクセス（例えば、インターネットアクセスを有すること）を有するネットワークに添付されたい装置である。ユーザ機器通信は、典型的には、サイト固有の要件が満たされるまで、セクション2.4で説明されている実施機器によって制限される。
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.
この文書はWebブラウザを持つデバイスのみを考慮し、Webアプリケーションはキャプティブポータル条件を満たす手段です。そのようなユーザ機器の例はスマートフォンです。
The User Equipment:
ユーザー機器：
* SHOULD support provisioning of the URI for the Captive Portal API (e.g., by DHCP).
* キャプティブポータルAPIのURIのプロビジョニング（例えば、DHCP）のプロビジョニングをサポートする必要があります。
* SHOULD distinguish Captive Portal API access per network interface, in the manner of Provisioning Domain Architecture [RFC7556].
* ドメインアーキテクチャ[RFC7556]をプロビジョニングする方法で、ネットワークインタフェースごとに非公開Portal APIアクセスを区別する必要があります。
* SHOULD have a non-spoofable mechanism for notifying the user of the Captive Portal.
* キャプティブポータルのユーザーに通知するためのスプーフィック可能なメカニズムを持つべきです。
* SHOULD have a web browser so that the user may navigate to the User Portal.
* ユーザーがユーザーポータルに移動できるようにWebブラウザを持つ必要があります。
* SHOULD support updates to the Captive Portal API URI from the Provisioning Service.
* プロビジョニングサービスからキャプティブポータルAPI URIへの更新をサポートする必要があります。
* MAY prevent applications from using networks that do not grant full network access. For example, a device connected to a mobile network may be connecting to a captive Wi-Fi network; the operating system could avoid updating the default route to a device on the captive 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".
* フルネットワークアクセスを許可しないネットワークを使用するのを防ぐことができます。例えば、モバイルネットワークに接続された装置は、キャプティブWi - Fiネットワークに接続されていてもよい。オペレーティングシステムは、ネットワークアクセス制限が解除されるまで（ユーザーポータルへのアクセスを除く）、キャプティブWi-Fiネットワーク上のデバイスへのデフォルトルートへのデフォルトルートを更新しないようにします。これは「ブレーク前にする」と呼ばれています。
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.
（a）ユーザやデバイスがキャプティブポータルへのフルアクセスを求める必要がないので、上記の要件は必須ではありません。（b）キャプティブポータルWebアプリケーションを手動で訪問することで要件を満たすことができます。（c）レガシデバイスはサポートされ続ける必要があります。
If User Equipment supports the Captive Portal API, it MUST validate the API Server's TLS certificate (see [RFC2818]) according to the procedures in [RFC6125]. The API 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 is identified by IP address, the iPAddress subjectAltName is used to validate the server certificate. An Enforcement Device SHOULD allow access to any services that User Equipment could need to contact to perform certificate validation, such as Online Certificate Status Protocol (OCSP) responders, Certificate Revocation Lists (CRLs), and NTP servers; see Section 4.1 of [RFC8908] for more information. If certificate validation fails, User Equipment MUST NOT make any calls to the API Server.
ユーザー機器がキャプティブポータルAPIをサポートしている場合は、[RFC6125]の手順に従ってAPIサーバーのTLS証明書（[RFC2818]を参照）を検証する必要があります。APIサーバのURIは、ネットワークプロビジョニングプロトコルを介して取得され、これは通常、サーバ証明書内のDNS - IDに対して、TLSサーバ証明書検証で使用されるホスト名を提供する。APIサーバーがIPアドレスで識別されている場合は、IPAddress件名TNAMEを使用してサーバー証明書を検証します。執行装置は、オンライン証明書ステータスプロトコル（OCSP）応答者、証明書失効リスト（CRL）、およびNTPサーバなど、ユーザ機器が証明書検証を実行するために連絡する必要があるサービスへのアクセスを許可する必要がある。詳細については、[RFC8908]のセクション4.1を参照してください。証明書検証が失敗した場合、ユーザー機器はAPIサーバーを呼び出すことはできません。
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 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.
ユーザ機器は、キャプティブポータルAPIから受信した最後の応答を、キャプティブポータル内のその状態のキャッシュされたビューとして保存することができる。この状態を使用して、そのキャプティブポータルセッションが有効期限に近いかどうかを判断できます。たとえば、ユーザー機器は、セッションが現在の時間に期限切れになるかを示すタイムスタンプを比較することがあります。このようにして状態を保存することで、キャプティブポータルAPIとの通信の必要性を減らすことができます。ただし、関連する条件（バイトクォータなど）のユーザー機器の見解が拘束Portal APIと一致していない場合は、状態になる可能性があります。
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 could also be the same service 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 that may be used to provide the Captive Portal API URI to the User Equipment.
プロビジョニングサービスは、主にネットワークに接続しているとき、およびURIが変わった場合に後でキャプティブポータルAPI URIを提供することを担当します。プロビジョニングサービスは、（例えば、IPアドレスで提供することによって）キャプティブポータルへのアクセスのためのユーザ機器をプロビジョニングする責任があるのと同じサービスであり得る。このセクションでは、キャプティブポータルAPI URIをユーザー機器に提供するために使用され得る2つのメカニズムについて説明します。
A standard for providing a Captive Portal API URI using DHCP or Router Advertisements is described in [RFC8910]. The captive portal architecture expects this URI to indicate the API described in Section 2.3.
DHCPまたはルーター広告を使用してキャプティブポータルAPI URIを提供するための標準は[RFC8910]に記載されています。キャプティブポータルアーキテクチャは、このURIがセクション2.3に記載されているAPIを示すことを期待しています。
[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.
[Capport-PVD]は、セクション2.3に記載されているAPIのURIを含むプロビジョニングドメイン（PVD）ブートストラップ情報をユーザ機器に提供するためのメカニズムを提案する。
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 Appendix A) queries to check for response tampering.
キャプティブポータルAPIの目的は、ユーザーを中断せずにキャプティブポータル状態のクエリを許可することです。これにより、このAPIは、ユーザ機器のクリアテキスト「カナリア」（付録Aを参照）クエリを実行して、応答の改ざんをチェックする必要がなくなります。
The URI of this API will have been provisioned to the User Equipment. (Refer to Section 2.2.)
このAPIのURIはユーザー機器にプロビジョニングされました。（2.2項を参照してください。）
This architecture expects the User Equipment to query the API when the User Equipment attaches to the network and multiple times thereafter. Therefore, the API MUST support multiple repeated queries from the same User Equipment and return the state of captivity for the equipment.
このアーキテクチャは、ユーザ機器がネットワークに接続されていてその後複数回添付されたときに、ユーザ機器がAPIに問い合わせることを期待している。したがって、APIは同じユーザー機器から複数の繰り返しクエリをサポートし、機器の捕獲された状態を返す必要があります。
At minimum, the API MUST provide the state of captivity. Further, the API MUST be able to provide a URI for the User Portal. The scheme for the URI MUST be "https" so that the User Equipment communicates with the User Portal over TLS.
最低では、APIは捕獲さの状態を提供しなければなりません。さらに、APIはユーザーポータルのURIを提供できなければなりません。URIの方式は「https」でなければなりませんので、ユーザー機器はTLSを介してユーザーポータルと通信します。
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 API might use the User Equipment's identifier for authentication, this requirement motivates Section 3.2.2.
APIが要求側のユーザ機器に対応していない状態の要求を受信した場合、APIはアクセスを拒否する必要があります。APIが認証にユーザ機器の識別子を使用することがあることを考えると、この要件は3.2.2を動機付ける。
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 [RFC8908], this might be achieved by using a content type that is unique to the protocol.
APIへの発信者は、受信しているコンテンツがそれがサポートしているバージョンのAPIに対する証拠で提示される必要があります。[RFC8908]などのHTTPベースの対話の場合、これはプロトコルに固有のコンテンツタイプを使用することによって達成される可能性があります。
When User Equipment receives Captive Portal Signals, the User Equipment MAY query the API to check its state of captivity. The User Equipment SHOULD rate-limit these API queries in the event of the signal being flooded. (See Section 6.)
ユーザ機器がキャプティブポータル信号を受信すると、ユーザ機器はその捕獲状態を確認するためにAPIに問い合わせることができる。ユーザ機器は、信号がフラッディングされた場合にこれらのAPIクエリをレート制限する必要があります。（6を参照）
The API MUST be extensible to support future use cases by allowing extensible information elements.
APIは、拡張可能な情報要素を許可することによって将来の使用例をサポートするために拡張可能でなければなりません。
The API MUST use TLS to ensure server authentication. The implementation of the API MUST ensure both confidentiality and integrity of any information provided by or required by it.
APIはサーバー認証を確実にするためにTLSを使用する必要があります。APIの実装は、それによって提供されている、またはそれによって必要とされる情報の機密性と完全性の両方を確実にする必要があります。
This document does not specify the details of the API.
この文書では、APIの詳細は指定されていません。
The Enforcement Device component restricts the network access of User Equipment according to the site-specific policy. 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.
執行装置コンポーネントは、サイト固有のポリシーに従ってユーザー機器のネットワークアクセスを制限します。通常、ユーザ機器は、（ネットワークプロバイダのポリシーに従って）ごとに（ネットワークプロバイダのポリシーに従って）アクセスが許可されており、キャプティブポータル条件を満たすまで一般的なネットワークアクセスが拒否されます。
The Enforcement Device component:
執行装置コンポーネント
* Allows traffic to pass for User Equipment that is permitted to use the network and has satisfied the Captive Portal Conditions.
* ネットワークを使用することが許可されており、キャプティブポータル条件を満たしているユーザー機器を通過させることができます。
* Blocks (discards) traffic according to the site-specific policy for User Equipment that has not yet satisfied the Captive Portal Conditions.
* まだキャプティブポータル条件を満たしていないユーザー機器のサイト固有のポリシーに従って、ブロック（破棄）トラフィックをブロック（破棄）トラフィック。
* Optionally signals User Equipment using the Captive Portal Signaling Protocol if certain traffic is blocked.
* オプションで、特定のトラフィックがブロックされている場合は、キャプティブポータルシグナリングプロトコルを使用してユーザー機器を送信します。
* Permits User Equipment that has not satisfied the Captive Portal Conditions to access necessary APIs and web pages to fulfill requirements for escaping captivity.
* キャプティブポータル条件を満たしていないユーザー機器は、必要なAPIとWebページにアクセスして捕獲率を免れるための要件を満たすためにアクセスできます。
* Updates allow/block rules per User Equipment in response to operations from the User Portal.
* ユーザーポータルからの操作に応じて、ユーザー機器ごとに許可/ブロック規則を更新します。
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 is imminent or when network access was denied. For simplicity, and to reduce the attack surface, all signals SHOULD be considered equivalent by the User Equipment as a hint to contact the API. If future solutions have multiple signal types, each type SHOULD be rate-limited independently.
ユーザ機器が最初にネットワークに接続する場合、またはステータスの変更がある場合、執行装置はユーザ機器に向かって信号を生成することができる。この信号は、ユーザ機器が更新された情報を受信するためにAPIサーバに連絡する必要があるかもしれないことを示す。たとえば、この信号は、セッションの終わりが差し迫っているとき、またはネットワークアクセスが拒否されたときに生成される可能性があります。簡単にするために、そして攻撃面を減らすために、すべての信号は、APIに連絡するヒントとしてユーザー機器と同等のものと見なされるべきです。将来の解決策が複数の信号タイプを持っている場合、各タイプは独立してレート制限されるべきです。
An Enforcement Device MUST rate-limit any signal generated in response to these conditions. See Section 6.4 for a discussion of risks related to a Captive Portal Signal.
執行装置は、これらの条件に応答して生成された信号をレート制限しなければならない。非公開ポータル信号に関連するリスクについての議論については、6.4項を参照してください。
The following diagram shows the communication between each component in the case where the Captive Portal has a User Portal and the User Equipment chooses to visit the User Portal in response to discovering and interacting with the API Server.
次の図は、キャプティブポータルがユーザーポータルを持っている場合の各コンポーネント間の通信を示し、ユーザー機器はAPIサーバーとの検出と対話に応答してユーザーポータルにアクセスすることを選択します。
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
Figure 1: Captive Portal Architecture Component Diagram
図1：キャプティブポータルアーキテクチャコンポーネント図
In the diagram:
ダイアグラムで：
* During provisioning (e.g., DHCP), and possibly later, the User Equipment acquires the Captive Portal API URI.
* プロビジョニング中（例えば、DHCP）、そしておそらく後で、ユーザ機器はキャプティブポータルAPI URIを取得する。
* 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.
* ユーザ機器は、その捕獲さの状態について学ぶためにAPIに問い合わせる。キャプティブの場合、ユーザ機器は、ユーザポータルからユーザへのポータルユーザインタフェースを提示する。
* Based on user interaction, the User Portal directs the Enforcement Device to either allow or deny external network access for the User Equipment.
* ユーザーの対話に基づいて、ユーザーポータルは執行装置をユーザー機器の外部ネットワークアクセスを許可または拒否します。
* The User Equipment attempts to communicate to the external network through the Enforcement Device.
* ユーザ機器は、執行装置を介して外部ネットワークと通信しようとする。
* The Enforcement Device either allows the User Equipment's packets to the external network or blocks the packets. If blocking traffic and a signal has been implemented, it may respond with a Captive Portal Signal.
* 施行装置は、ユーザ機器のパケットを外部ネットワークへのパケットまたはパケットをブロックすることを可能にする。トラフィックと信号が実装されている場合は、キャプティブポータル信号で応答することがあります。
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.
プロビジョニングサービス、APIサーバー、およびユーザーポータルは、離散機能として説明されています。実装は単一のエンティティ内で複数の機能を提供するかもしれません。さらに、これらの関数は、組み合わされているか否か、および執行装置は、冗長またはスケールのために複製することができる。
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 and agree on the identity of the User Equipment when interacting with each other.
アーキテクチャ内の複数のコンポーネントは、ユーザー機器と互いに両方と対話します。ユーザ機器はこれらの相互作用の焦点であるので、部品はそれとの対話からユーザ機器を識別し、相互作用するときにユーザ機器の身元を同意することができなければならない。
The methods by which the components interact restrict the type of information that may be used as an identifying characteristic. This section discusses the identifying characteristics.
コンポーネントが対話する方法は、識別特性として使用され得る情報の種類を制限する。このセクションでは、識別特性について説明します。
An 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 can be a field contained in packets sent by the User Equipment to the external network. Or, an identifier can be an ephemeral property not contained in packets destined for the external network, but instead correlated with such information through knowledge available to the different components.
識別子は、どの特定のユーザ機器インスタンスがそれらと対話しているかを一意に決定するために、キャプティブポータルの構成要素によって使用されるユーザ機器の特徴である。識別子は、ユーザ機器によって外部ネットワークに送信されたパケットに含まれるフィールドであり得る。あるいは、識別子は、外部ネットワーク宛てのパケットに含まれていないが、代わりに異なるコンポーネントで利用可能な知識を通じてそのような情報と相関しています。
The set of possible identifiers is quite large. However, in order to be considered a good identifier, an identifier SHOULD 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:
可能な識別子のセットはかなり大きいです。ただし、優れた識別子と見なすために、識別子は次の基準を満たすべきです。最適な識別子は、ネットワーク内のコンポーネントの位置とそれらに利用可能な情報によって異なる可能性があります。識別子は次のとおりです。
* uniquely identify the User Equipment
* ユーザー機器を一意に識別します
* be hard to spoof
* スプラッフが難しい
* be visible to the API Server
* APIサーバーに表示されます
* be visible to the Enforcement Device
* 執行機器に見えるようになります
An identifier might only apply to the current point of network attachment. If the device moves to a different network location, its identity could change.
識別子は、ネットワーク添付ファイルの現在のポイントにのみ適用される場合があります。デバイスが異なるネットワークの場所に移動すると、その識別情報が変わる可能性があります。
The Captive Portal MUST associate the User Equipment with an identifier that is unique among all of the User Equipment interacting with the Captive Portal at that time.
キャプティブポータルは、その時点でキャプティブポータルと対話するすべてのユーザー機器の中で一意のユーザー機器をユーザー機器に関連付ける必要があります。
Over time, the User Equipment assigned to an identifier value MAY change. Allowing the identified device to change over time ensures that the space of possible identifying values need not be overly large.
時間が経つにつれて、識別子値に割り当てられているユーザ機器が変わる可能性があります。識別されたデバイスが時間の経過とともに変更されることを可能にすることは、可能な識別値のスペースが過度に大きい必要はないことを保証する。
Independent Captive Portals MAY use the same identifying value to identify different User 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.
独立したキャプティブポータルは、異なるユーザー機器インスタンスを識別するために同じ識別値を使用することがあります。独立したキャプティブポータルが識別値を再利用できるようにすることで、識別子をローカルネットワークのプロパティとすることができ、可能な識別子のスペースを拡大します。
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 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 or when the identity of the User Equipment could imply liability.
良い識別子が簡単になりすましていることを貸していません。いずれにせず、両方が同時にアクティブかどうかにかかわらず、1人のユーザー機器インスタンスのふりをすることができるように単純か直読されるべきです。このプロパティは、ユーザ機器識別子が請求システムなどの装置によって外部から外部的に参照されている場合、またはユーザ機器の身元が責任を満たすことができるときに特に重要である。
Since the API Server will need to perform operations 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.
ユーザ機器がキャプティブかについてのクエリに答えるなど、APIサーバはユーザ機器の身元に頼る操作を実行する必要があるので、APIサーバは要求を行うユーザ機器に要求を関連付けることができる必要がある。。
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.
執行装置は、パケットが外部ネットワークに転送されるべきかどうかをパケットごとに決定する。この決定はどのユーザ機器インスタンスがパケットを送信したかに依存するので、執行装置はパケットをユーザ機器の概念にマッピングすることができることを要求する。
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 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.
識別子の種類が適切かどうかを評価するには、アーキテクチャ内のコンポーネント間の相互作用の観点から推奨されるすべてのプロパティを検討する必要があります。識別子の種類を比較するときは、推奨されるすべてのプロパティを最もよく満たすものを選択してください。アーキテクチャは、識別子タイプが特定のプロパティを満たすことの正確な尺度を提供しません。評価を実行する際に注意する必要があります。
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 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.
このセクションでは、いくつかの識別子タイプをいくつか示し、それらが適切なタイプであるかどうかのいくつかの評価を示します。識別子型のリストは網羅的なものではありません。他の種類を使用することができる。注意する重要な点は、特定の識別子タイプが適切かどうか、コンポーネントの機能に大きく、ネットワーク内のコンポーネントが存在する場所に依存します。
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.
ユーザ機器がネットワークに接続されている物理的インタフェースを使用して、ユーザ機器を識別することができる。この識別子タイプは、スプーフが非常に困難であるという性質を持っています。ユーザー機器はその財産に気付いていません。1つのユーザー機器インスタンスは、そのインタラクションをもう一度表示させることはできません。
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 instances are attached to the network on the same physical interface, then this type is not appropriate.
さらに、単一のユーザ機器インスタンスのみが所与の物理インタフェースに接続されている場合、識別子は一意になる。複数のユーザー機器インスタンスが同じ物理インターフェイス上のネットワークに接続されている場合、このタイプは適切ではありません。
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 invalidate their state related to the User Equipment.
ユーザ機器の一意性に関する別の考慮事項は、添付されたユーザ機器が変更された場合、APIサーバと執行装置の両方がユーザ機器に関連するそれらの状態を無効にしなければならないことである。
The Enforcement Device needs to be aware of the physical interface, which constrains the 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., a tunnel).
執行装置は物理的インターフェースを認識する必要があります。これは環境を制限します。それは、物理的アクセスを提供する（例えば、ファームウェアで実装されている）デバイスの一部でなければならないか、またはネットワークを通過するパケットは、ソース物理インターフェース（例えば、トンネル）に関する情報を含むように拡張されなければならない。
The API Server faces a similar problem, implying that it should co-exist with the Enforcement Device or that the Enforcement Device should extend requests to it with the identifying information.
APIサーバは同様の問題に直面し、執行装置と共存するべきであること、または執行装置が識別情報との要求を延長すべきであることを意味する。
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.
考慮すべき自然識別子タイプは、ユーザー機器のIPアドレスです。常に、ネットワーク上のデバイスはネットワークを誤動作させることなく同じIPアドレスを持つことはできませんので、一意性の観点から適切です。
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 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 remove or update their mapping to prevent spoofing. Demonstrations of return 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).
ただし、特にネットワークの適切な機能が悪意のある俳優に必要ではない悪意のある理由で、IPアドレスを偽装することが可能です。その結果、IPアドレスを使用したソリューションは、IPアドレスのスプーフィングを予防しようとする必要があります。同様に、ユーザー機器へのIPアドレスのマッピングが変更された場合、アーキテクチャのコンポーネントは、スプーフィングを防ぐためにマッピングを削除または更新する必要があります。TCP接続確立に必要なものなどのリターンルーティング性のデモンストレーションは、ブロッキングメディア（一部の無線ネットワークなど）を使用するネットワークでは十分ではないかもしれませんが、スプーフィングに対する防御は十分な防御です。
Since the IP address may traverse multiple segments of the network, more flexibility is afforded to the Enforcement Device and the API 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.
IPアドレスはネットワークの複数のセグメントを通過することがあるので、施行装置およびAPIサーバにより柔軟性が与えられる。それらは単にIPアドレスがまだ一意であるネットワークのセグメントに存在しなければなりません。ただし、NATがユーザー機器と執行装置との間に展開され得ると考える。そのような場合、コンポーネントがポートマッピングを認識している場合、コンポーネントがデバイスを一意に識別することが可能です。
In some situations, the User Equipment may have multiple IP addresses (either IPv4, IPv6, or a dual-stack [RFC4213] 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 instance, or should it tie the multiple addresses together into one view of the subscriber? An implementation MAY 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.
状況によっては、ユーザ機器は、依然としてすべての推奨されるプロパティを満たしながら、複数のIPアドレス（IPv4、IPv6、またはデュアルスタック[RFC4213]組み合わせ）を持つことができます。これにより、ネットワークのコンポーネントにいくつかの課題があります。たとえば、ユーザー機器が複数のIPアドレスを持つネットワークにアクセスしようとすると、執行デバイスとAPIサーバーが各IPアドレスを固有のユーザー機器インスタンスとして扱う場合、または複数のアドレスをサブスクライバの1つのビューにまとめる必要がありますか。実装もすることができます。IPv6に注意を払う必要があり、デバイスが単一のリンクで複数のIPv6アドレスを持つことが予想されるという事実を課す必要があります。そのような場合、IPが属する/ 64などのサブネットによって識別を実行できます。
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 Section 3.2.
デバイスのMACアドレスは、既存の実装内の識別子としてよく使用されます。この文書では、キャプティブポータルシステム内のMACアドレスの使用については説明していませんが、セクション3.2の基準に従って、識別子型として使用できます。
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.
キャプティブポータルAPIは、そのクライアントに固有のクライアントに情報を提示する必要があります。これを行うために、一部のシステムは、ソースアドレスなどの要求のコンテキストからの情報を使用して、ユーザー機器を識別します。
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 [RFC8499]).
URIからの情報ではなくコンテキストからの情報を使用すると、同じURIをさまざまなクライアントに使用できます。しかしながら、それはまた、ユーザ機器が異なるネットワーク経路を使用して要求をする場合には、リソースが関連情報を提供することができないことを意味する。これは、ユーザー機器に複数のネットワークインタフェースがある場合に発生する可能性があります。DNSによって提供されたAPIのアドレスが、クエリが発信された場所（Split DNS [RFC8499]）に依存する場合にも発生する可能性があります。
Accessing the API MAY depend on contextual information. However, the URIs provided in the API SHOULD be unique to the User Equipment and not dependent on contextual information to function correctly.
APIへのアクセスは、コンテキスト情報によって異なります。しかしながら、APIに提供されたURIは、ユーザ機器に固有のものであり、正しく機能するコンテキスト情報に依存しないはずである。
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.
ユーザ機器が異なるネットワークからの要求を行うと、URIが正しく解決される可能性があるが、ユーザ機器がキャプティブポータルを使用して要求を実行するときにいくつかの機能を制限することができる可能性がある。たとえば、支払いオプションが不在である可能性があるか、支払いが現在の接続に対してはないことを示すために警告を表示することができます。
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.
URIは、URIのユーザ機器を識別するいくつかの手段を含むことができる。しかしながら、URI内の認証されていないユーザ機器識別子を含むことは、サービスをスプーフィングまたは再生攻撃にさらすことができる。
This section aims to improve understanding by describing a possible workflow of solutions adhering to the architecture. Note that the section is not normative; it describes only a subset of possible implementations.
このセクションでは、アーキテクチャに付着している解決策の可能なワークフローを説明することによって理解を向上させることを目的としています。セクションは規範的ではありません。それは可能な実装のサブセットのみを説明します。
This section describes a possible workflow when User Equipment initially joins a Captive Portal.
このセクションでは、ユーザー機器が最初にキャプティブポータルに参加するときの可能なワークフローについて説明します。
1. The User Equipment joins the Captive Portal by acquiring a DHCP lease, RA, or similar, acquiring provisioning information.
1. ユーザ機器は、DHCPリース、RA、または同様のプロビジョニング情報を取得することによって、キャプティブポータルに参加します。
2. The User Equipment learns the URI for the Captive Portal API from the provisioning information (e.g., [RFC8910]).
2. ユーザ機器は、プロビジョニング情報（例えば、[RFC8910]）から、キャプティブポータルAPIのURIを学習する。
3. 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.)
3. ユーザ機器は、ユーザポータルURIを含む、キャプティブポータルのパラメータを受信するためにキャプティブポータルAPIにアクセスする。（このステップはクリアテキストクエリをカナリアURIに置き換えます。）
4. If necessary, the user navigates to the User Portal to gain access to the external network.
4. 必要に応じて、ユーザーはユーザーポータルに移動して外部ネットワークへのアクセスを取得します。
5. If the 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.
5. 前のステップでユーザーポータルと対話して外部ネットワークにアクセスすると、ユーザーPortalは、ユーザー機器が外部ネットワークにアクセスできるようにする強制装置を示す。
6. The User Equipment attempts a connection outside the Captive Portal.
6. ユーザー機器は、拘束ポータルの外部で接続を試みます。
7. If the requirements have been satisfied, the access is permitted; otherwise, the "Expired" behavior occurs.
7. 要件が満たされた場合、アクセスは許可されます。それ以外の場合は、「期限切れ」動作が発生します。
8. The User Equipment accesses the network until conditions expire.
8. ユーザ機器は、条件が期限切れになるまでネットワークにアクセスする。
This section describes a possible workflow when access is about to expire.
このセクションでは、アクセスが期限切れになっているときに可能なワークフローについて説明します。
1. Precondition: the API has provided the User Equipment with a duration over which its access is valid.
1. 前提条件：APIは、そのアクセスが有効な期間でユーザー機器を提供しました。
2. The User Equipment is communicating with the outside network.
2. ユーザ機器は外部ネットワークと通信しています。
3. 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.
3. ユーザ機器は、そのアクセスのために残された時間の長さが、格納された有効期限を現在の時刻と比較することによって閾値を下回ったことを検出する。
4. The User Equipment visits the API again to validate the expiry time.
4. ユーザー機器は、有効期限を検証するためにもう一度APIを訪問します。
5. If expiry is still imminent, the User Equipment prompts the user to access the User Portal URI again.
5. 有効期限がまだ差し迫っている場合、ユーザー機器はユーザーにユーザーPortal URIにアクセスするように促します。
6. The user accepts the prompt displayed by the User Equipment.
6. ユーザーはユーザー機器によって表示されるプロンプトを受け入れます。
7. The user extends their access through the User Portal via the User Equipment's user interface.
7. ユーザは、ユーザ機器のユーザインタフェースを介してユーザポータルを介してアクセスを拡張する。
8. The User Equipment's access to the outside network continues uninterrupted.
8. ユーザー機器の外部ネットワークへのアクセスは中断されない。
A different Captive Portal API URI could be returned in the following cases:
以下の場合、異なるキャプティブポータルAPI URIを返すことができます。
* If DHCP is used, a lease renewal/rebind may return a different Captive Portal API URI.
* DHCPが使用されている場合、リース更新/ Rebindは別の拘束ポータルAPI URIを返すことがあります。
* If RA is used, a new Captive Portal API URI may be specified in a new RA message received by end User Equipment.
* RAが使用されている場合、エンドユーザー機器によって受信された新しいRAメッセージに新しいキャプティブポータルAPI URIを指定できます。
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 as it normally would until the expiry conditions it retrieved from the old URI are about to expire.
プロビジョニングサービスがキャプティブポータルAPI URIを更新すると、ユーザ機器はすぐにURIから更新された状態を取得することができ、あるいはそれが通常のURIから検索された有効期限が期限切れになるまでそれが通常待機することができる。
This document has no IANA actions.
この文書にはIANAの行動がありません。
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 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 [RFC7556] provides some discussion on authenticating an operator.
ネットワークに参加するとき、いくつかの信頼がネットワーク事業者に配置されます。これは通常、組織の評判に基づいてユーザーによる決定であると考えられています。しかしながら、ユーザがそのような決定を下すと、プロトコルは、ネットワークがそれを動作させると主張すると主張することによって運営されることを認証することができる。プロビジョニングドメインアーキテクチャ[RFC7556]は、オペレータの認証に関するいくつかの説明を提供します。
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, the network SHOULD do so securely so that the user's trust in the network can extend to their trust of the Captive Portal URI. For example, the DHCPv6 AUTH option can sign this information.
ユーザは、拘束ポータルURIを訪問し、信頼することを知らせた選択をします。ネットワークはキャプティブポータルURIをユーザ機器に提供するので、ネットワークへのユーザの信頼が秘密のポータルURIの信頼に及ぶ可能性があるように、ネットワークは安全にするべきである。たとえば、DHCPv6 AUTHオプションはこの情報に署名できます。
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.
ユーザーが攻撃ネットワークを誤って信頼することを決定した場合、それらは攻撃を開くWebページを訪問し、攻撃者にとって不義の資格情報を提供することを確信している可能性があります。ブラウザはサーバーを認証できますが、たとえば巧妙にスペルミスされたドメインを検出することはできません。
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 the attacker could modify the traffic inline.
さらに、攻撃ネットワークにおけるオンパス攻撃者がいくつかのリスクを招く可能性がある。攻撃者はトラフィックを任意の目的地にリダイレクトすることができます。攻撃者は、機密性の喪失につながるユーザーのトラフィックを分析することも、攻撃者はトラフィックをインラインで変更することができます。
The solution described here requires that when the User Equipment needs to access the API Server, the User Equipment authenticates the server; see Section 2.1.
ここで説明されているソリューションでは、ユーザー機器がAPIサーバーにアクセスする必要がある場合、ユーザー機器はサーバーを認証することを必要とする。セクション2.1を参照してください。
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 Provisioning Service.
キャプティブポータルAPI URIは、キャプティブポータルセッション中に変更される可能性があります。ユーザ機器は、プロビジョニングサービスから最初に受信されたURIと同じように同じ信頼メカニズムを新しいURIに適用することができる。
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 that can be used to validate future interactions. The API MUST ensure the integrity of this information, as well as its confidentiality.
ここに記載されている解決策は、APIがTLSを使用して固定されることを必要とする。これは、ユーザー機器およびAPIサーバーが将来の対話を検証するために使用できる秘密を交換できるようにするために必要です。APIは、その機密性だけでなく、この情報の整合性を保証しなければなりません。
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, deny the User Equipment service by ending their 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 or cause them to appear as different User Equipment instances.
この情報へのアクセスを持つ攻撃者は、APIと対話するときに特定のユーザー機器インスタンスとしてマスカレードできる可能性があります。これにより、ユーザーPortalと対話するときにユーザー機器インスタンスとしてマスカレードすることができます。これにより、ユーザ機器がポータルにアクセスしたかどうかを判断することができ、ユーザポータルが提供するメカニズムを使用してユーザ機器サービスを拒否するか、そのユーザ機器のクォータを消費しているかを判断することができる。情報を変更する能力を持つ攻撃者は、ユーザー機器へのサービスを拒否したり、異なるユーザー機器のインスタンスとして表示される可能性があります。
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:
シグナリングプロトコルが実装されている場合、インターネット上の任意のユーザが受信機器がキャプティブポータルAPIと通信させる試みにおいて信号を送信することが可能であり得る。これが考慮され、実装は次のようになるかもしれません：
* The signal only signals to the User Equipment to query the API. It does not carry any information that may mislead or misdirect the User Equipment.
* 信号のみがAPIを問い合わせるためのユーザー機器に信号のみを送信します。ユーザー機器を誤解または誤って誤って誤って誤っている可能性がある情報を持ちません。
* Even when responding to the signal, the User Equipment securely authenticates with API Servers.
* 信号に応答しても、ユーザー機器はAPIサーバーで安全に認証します。
* The User Equipment limits the 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 signaling information.
* ユーザ機器は、APIにアクセスするレートを制限し、ユーザ機器またはAPIのいずれかに過大な負荷を生み出すことを試みる攻撃の影響を軽減します。信号に応答して1種類の信号と1種類のAPI要求のみがあるため、このレート制限はシグナリング情報の損失を引き起こさないことに注意してください。
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 permit users to disable automatic reaction to Captive Portal 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 allow users to manually control captive portal interactions, possibly on the granularity of Provisioning Domains.
キャプティブポータル信号は、それが拘束されているユーザ機器に信号を送ることができる。ユーザー機器がこれについて何かをする必要はありません。デバイスは、プライバシー上の理由から、キャプティブポータル信号の指標に対して自動反応を無効にすることができます。ただし、ネットワークアクセスが制限されているときにユーザーが通知されないトレードオフがあります。したがって、エンドユーザデバイスは、ユーザがおそらくプロビジョニングドメインの粒度を手動で手動で制御することを可能にし得る。
Section 3 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.
セクション3は、キャプティブポータル内のすべてのコンポーネントが、ユーザー機器を一意に識別するために同じ識別子を使用するように設計されているメカニズムを示しています。この識別子はユーザーを追跡するために虐待される可能性があります。キャプティブポータルの実装者と設計者は、保存されている場合は識別子が安全に保存されていることを確認するように注意する必要があります。同様に、コンポーネントがネットワーク上で識別子を通信する場合、TLSなどの暗号化を使用して、ワイヤ上の識別子の機密性を確保する必要があります。
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; an attacker could use it to tie traffic back to the originating User Equipment, despite the User Equipment having changed identifiers.
可変の匿名識別子を選択することは恩恵を受けています。たとえば、ユーザー機器は、長期追跡を防ぐために複数の識別子を循環させることができます。ただし、ネットワークのコンポーネントが内部マッピングを使用して識別子の変更に対処するために識別情報を安定した長期的な値にマッピングする場合、それらはその値を機密情報として扱う必要があります。攻撃者が変更された識別子を有するユーザ機器にもかかわらず、攻撃者はそれを使用することができる。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] RESCORLA、E.、「HTTP over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https：//www.rfc-editor.org/info/rfc2818>。
[RFC6125] Saint-Andre, P. and J. Hodges, "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)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Transport Layer Security（TLS）のコンテキストでのX.509（PKIX）証明書を使用したInternet Publicキーインフラストラクチャ内のインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証の表現と検証RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>。
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, <https://www.rfc-editor.org/info/rfc7556>.
[RFC7556] Anipko、D.、ED。、「複数プロビジョニングドメインアーキテクチャ」、RFC 7556、DOI 10.17487 / RFC7556、2015年6月、<https：//www.rfc-editor.org/info/rfc7556>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8910] Kumari, W. and E. Kline, "Captive-Portal Identification in DHCP and Router Advertisements (RAs)", RFC 8910, DOI 10.17487/RFC8910, September 2020, <https://www.rfc-editor.org/info/rfc8910>.
[RFC8910] Kumari、W.およびE. kline、「DHCPおよびルーター広告（RAS）」、RFC 8910、DOI 10.17487 / RFC8910、9月2020年9月、<https://www.rfc-editor.org/ info / rfc8910>。
[CAPPORT-PVD] Pfister, P. and T. Pauly, "Using Provisioning Domains for Captive Portal Discovery", Work in Progress, Internet-Draft, draft-pfister-capport-pvd-00, 30 June 2018, <https://tools.ietf.org/html/draft-pfister-capport-pvd-00>.
[Capport-PVD] Pfister、P.およびT. Pauly、「捕虜ポータル発見のためのプロビジョニングドメインの使用」、インターネットドラフト、ドラフト - PFISTER-CAPPORT-PVD-00,30年6月30日、<https：//tools.ietf.org/html/draft-pfister-capport-pvd-00>>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、「Uniform Resource Identifier（URI）：汎用構文」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, <https://www.rfc-editor.org/info/rfc4213>.
[RFC4213] Nordmark、E.およびR.Gilligan、「IPv6ホストおよびルータの基本遷移メカニズム」、RFC 4213、DOI 10.17487 / RFC4213、2005年10月、<https：//ww.rfc-editor.org/info/rfc4213>。
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8499] Hoffman、P.、Sullivan、A.、K. Fujiwara、「DNS用語」、BCP 219、RFC 8499、DOI 10.17487 / RFC8499、2019年1月、<https：//www.rfc-editor.org/情報/ RFC8499>。
[RFC8908] Pauly, T., Ed. and D. Thakore, Ed., "Captive Portal API", RFC 8908, DOI 10.17487/RFC8908, September 2020, <https://www.rfc-editor.org/info/rfc8908>.
[RFC8908] Pouly、T.、ED。D. Thakore、Ed。、「Captive Portal API」、RFC 8908、DOI 10.17487 / RFC8908、2020年9月、<https：//www.rfc-editor.org/info/rfc8908>。
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 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.
オペレーティングシステムおよびユーザアプリケーションは、デバイスが秘密のポータルでネットワークに接続されているかどうかを判断するためにネットワーク接続が確立されたときに様々なテストを実行することができる。一般的な方法は、固定応答を持つ既知のベンダーホストエンドポイントにHTTPリクエストを実行しようとすることです。他の応答は、拘束ポータルが存在する信号として解釈されます。このチェックは通常、キャプティブポータルを持つネットワークが接続を傍受する可能性があるため、TLSで保護されていません。ホスト名の不一致につながります。これは「カナリア」要求と呼ばれています。炭鉱のカナリアのように、それは問題が間違っている最初の兆候である可能性があります。
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.
実行できるもう1つのテストは、予想される回答を持つ既知のアドレスへのDNSルックアップです。答えが予想回答と異なる場合、機器は拘束ポータルが存在することを検出します。実装の複雑さのために、TCPまたはHTTPSを介したDNSクエリは、UDPよりもDNSクエリよりも変更される可能性が低いです。
The different tests may produce different conclusions, varying by whether or not the implementation treats both TCP and UDP traffic and by which types of DNS are intercepted.
異なるテストは、実装がTCPトラフィックとUDPトラフィックの両方を扱うかどうかによって異なる、異なる結論を生み出すことができ、そのタイプのDNSが傍受されます。
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.
キャプティブポータルが存在する悪意のあるまたは誤った構成のネットワークは、これらのカナリア要求を傍受し、それらを通過させるか偽装することを選択し、偽陰性を持つデバイスにつながります。
Acknowledgments
謝辞
The authors thank Lorenzo Colitti for providing the majority of the content for the Captive Portal Signal requirements.
著者らはLorenzo Colittiに、拘束ポータル信号要件のためにコンテンツの大部分を提供していただきありがとうございます。
The authors thank Benjamin Kaduk for providing the content related to TLS certificate validation of the API Server.
APIサーバーのTLS証明書の検証に関連するコンテンツを提供するために、Benjamin Kadukに感謝します。
The authors thank Michael Richardson for providing wording requiring DNSSEC and TLS to operate without the user adding exceptions.
著者らは、ユーザが例外を追加せずにDNSSECとTLSを操作することを要求する文言を提供するためにMichael Richardsonに感謝します。
The authors thank various individuals for their feedback on the mailing list and during the IETF 98 hackathon: David Bird, Erik Kline, Alexis La Goulette, Alex Roscoe, Darshak Thakore, and Vincent van Dam.
著者らは、メーリングリストに関するフィードバックに感謝し、IETF 98ハッカソンの間に、David Bird、Erik Kline、Alexis La Goulette、Alex Roscoe、Darshak Thakore、Vincent Van Damの間にありがとうございました。
Authors' Addresses
著者の住所
Kyle Larose Agilicus
カイルはagiliCusのラロース
Email: kyle@agilicus.com
David Dolson
デビッドドルソン
Email: ddolson@acm.org
Heng Liu Google
heng liu Google
Email: liucougar@google.com