[要約] RFC 9965は、EAP（拡張認証プロトコル）において事前認証情報を持たないデバイスのブートストラップ（初期設定）問題を解決するための標準化トラック文書です。EAPピアがEAPサーバーに対して制限付きかつ未認証のネットワークアクセスを要求するためのシグナリング手段として、「eap.arpa.」ドメインを定義しています。これにより、RFC 5216および9190を更新して未認証プロビジョニング手段を定義し、RFC 9140の「eap-noob.arpa」を「@noob.eap.arpa」へと置き換えます。
Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 9965 InkBridge Networks
Updates: 5216, 9140, 9190 May 2026
Category: Standards Track
ISSN: 2070-1721
This document defines the eap.arpa. domain for use only in Network Access Identifiers (NAIs) as a way for Extensible Authentication Protocol (EAP) peers to signal to EAP servers that they wish to obtain limited, and unauthenticated, network access. EAP peers signal which kind of access is required via certain predefined identifiers that use the NAI format of RFC 7542. A table of identifiers and meanings is defined, which includes entries for RFC 9140.
この文書は、EAP（Extensible Authentication Protocol）ピアがEAPサーバーに対し、制限付きかつ未認証のネットワークアクセスを取得したいことを通知する手段として、ネットワークアクセス識別子（NAI）内でのみ使用されるeap.arpa.ドメインを定義します。EAPピアは、RFC 7542のNAI形式を使用する特定の事前定義された識別子を介して、どの種類のアクセスが必要であるかをシグナリングします。識別子とそれらが示す意味の表が定義されており、これにはRFC 9140のエントリが含まれます。
This document updates RFCs 5216 and 9190 to define an unauthenticated provisioning method. Those specifications suggest that such a method is possible, but they do not define how it would be done. This document also updates RFC 9140 to deprecate "eap-noob.arpa" and replace it with "@noob.eap.arpa".
この文書は、RFC 5216 および 9190 を更新して、非認証プロビジョニング方法を定義します。これらの仕様は、そのような方法が可能であることを示唆していますが、それがどのように行われるかを定義していません。また、この文書は RFC 9140 を更新して、「eap-noob.arpa」を非推奨にし、「@noob.eap.arpa」に置き換えます。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9965.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9965 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Background and Rationale
1.1.1. Review of Existing Functionality
1.1.2. Taxonomy of Provisioning Types
1.1.3. Rationale for Provisioning over EAP
2. Terminology
3. Overview
3.1. The eap.arpa Realm
3.2. The Realm Field
3.3. The Username Field
3.4. Operation
3.4.1. EAP Peers
3.4.2. EAP Servers
3.5. Other Considerations
3.6. Considerations for Provisioning Specifications
3.6.1. Negotiation
3.6.2. Renewal of Credentials
3.7. Notes on AAA Routability
4. Interaction with EAP Methods
4.1. High Level Requirements
4.2. EAP-TLS
4.3. EAP-NOOB
5. IANA Considerations
5.1. .arpa Updates
5.1.1. Deprecating eap-noob.arpa
5.1.2. Defining the eap.arpa. Domain
5.2. EAP Provisioning Identifiers Registry
5.2.1. Initial Values of the EAP Provisioning Identifiers
Registry
5.2.2. Guidelines for Designated Experts
5.2.3. Method Type
5.2.4. Designated Experts
5.2.5. Organization Self Assignment
6. Privacy Considerations
7. Security Considerations
7.1. On-Path Attackers and Impersonation
7.2. Provisioning is Unauthenticated
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Author's Address
In most uses, EAP [RFC3748] requires that the EAP peers have pre-provisioned credentials. Without pre-provisioned credentials, the device cannot obtain network access in order to be provisioned with credentials. This limitation creates a bootstrapping problem.
ほとんどの使用法では、EAP [RFC3748] では、EAP ピアが事前にプロビジョニングされた資格情報を持っていることが必要です。事前にプロビジョニングされた資格情報がないと、デバイスは資格情報をプロビジョニングするためにネットワーク アクセスを取得できません。この制限により、ブートストラップの問題が発生します。
This specification addresses that bootstrapping problem. It creates a framework for predefined "well-known" provisioning credentials and instantiates that framework for two mechanisms.
この仕様は、そのブートストラップの問題に対処します。事前定義された「既知の」プロビジョニング資格情報のフレームワークを作成し、そのフレームワークを 2 つのメカニズム用にインスタンス化します。
Clients can submit these predefined provisioning credentials to a server in order to obtain limited network access. At the same time, servers can know in advance that these credentials are to be used only for provisioning; thus, they can avoid granting unrestricted network access to peers that submit these credentials.
クライアントは、制限されたネットワーク アクセスを取得するために、これらの事前定義されたプロビジョニング資格情報をサーバーに送信できます。同時に、サーバーは、これらの資格情報がプロビジョニングのみに使用されることを事前に知ることができます。したがって、これらの資格情報を送信するピアに無制限のネットワーク アクセスを許可することを回避できます。
The device can either use the EAP channel itself for provisioning, as with the Tunnel Extensible Authentication Protocol (TEAP) [RFC9930], or the EAP server can give the device access to a limited captive portal such as with [RFC8952]. Once the device is provisioned, it can use those provisioned credentials to obtain full network access.
デバイスは、Tunnel Extensible Authentication Protocol (TEAP) [RFC9930] のように、プロビジョニングに EAP チャネル自体を使用するか、[RFC8952] などの限定されたキャプティブ ポータルへのアクセスを EAP サーバーがデバイスに与えることができます。デバイスがプロビジョニングされると、それらのプロビジョニングされた資格情報を使用して完全なネットワーク アクセスを取得できます。
The predefined provisioning credentials use a generic identity format. Identifiers in this space are generically referred to as "EAP Provisioning Identifiers" (or "EPIs").
事前定義されたプロビジョニング認証情報では、汎用の ID 形式が使用されます。この領域の識別子は、一般に「EAP プロビジョニング識別子」(または「EPI」) と呼ばれます。
Since the identity is predefined and used only for unauthenticated network access, there is little benefit to specifying predefined passwords. Where supported by the underlying EAP method, this specification provides for password-less access. Where passwords are required, the password is defined to be the same as the identity.
ID は事前定義されており、認証されていないネットワーク アクセスにのみ使用されるため、事前定義されたパスワードを指定するメリットはほとんどありません。基礎となる EAP メソッドでサポートされている場合、この仕様ではパスワードなしのアクセスが提供されます。パスワードが必要な場合、パスワードは ID と同じになるように定義されます。
In this section, we provide background on the existing functionality and describe why it was necessary to define provisioning methods for EAP.
このセクションでは、既存の機能の背景を説明し、EAP のプロビジョニング方法を定義する必要がある理由を説明します。
For EAP-TLS, both [RFC5216], Section 2.1.1 and [RFC9190] provide for "peer unauthenticated access". However, those documents define no way for a peer to signal that it is requesting such access. The presumption is that the peer connects with some value for the EAP Identity, but does so without using a client certificate. The EAP server is then supposed to determine that the peer is requesting unauthenticated access and take the appropriate steps to limit authorization.
EAP-TLS については、[RFC5216] セクション 2.1.1 と [RFC9190] の両方で「ピア非認証アクセス」が規定されています。ただし、これらの文書では、ピアがそのようなアクセスを要求していることを通知する方法は定義されていません。ピアは EAP ID の何らかの値を使用して接続しますが、クライアント証明書を使用せずに接続すると想定されます。EAP サーバーは、ピアが認証されていないアクセスを要求していると判断し、認可を制限するための適切な手順を実行する必要があります。
There appears to be no EAP peer or server implementations that support such access since there is no defined way to perform any of the steps required, i.e., to signal that this access is desired and then limit access.
必要な手順を実行する方法、つまり、このアクセスが必要であることを通知してアクセスを制限する方法が定義されていないため、そのようなアクセスをサポートする EAP ピアまたはサーバーの実装はないようです。
The Wi-Fi Alliance has defined an unauthenticated EAP-TLS method, using a vendor-specific EAP method as part of HotSpot 2.0r2 [HOTSPOT]. However, there appear to be few deployments of this specification.
Wi-Fi Alliance は、HotSpot 2.0r2 [HOTSPOT] の一部としてベンダー固有の EAP メソッドを使用する、非認証 EAP-TLS メソッドを定義しました。ただし、この仕様の導入はほとんどないようです。
Nimble Out-of-Band Authentication for EAP (EAP-NOOB) [RFC9140] takes this process a step further. It defines both a way to signal that provisioning is desired and a way to exchange provisioning information within EAP-NOOB. That is, there is no need for the device to obtain limited network access as all of the provisioning is done inside of the EAP-NOOB protocol.
EAP 用の Nimble Out-of-Band Authentication (EAP-NOOB) [RFC9140] は、このプロセスをさらに一歩進めたものです。これは、プロビジョニングが必要であることを通知する方法と、EAP-NOOB 内でプロビジョニング情報を交換する方法の両方を定義します。つまり、すべてのプロビジョニングが EAP-NOOB プロトコル内で行われるため、デバイスは制限されたネットワーク アクセスを取得する必要がありません。
TEAP [RFC9930] provides for provisioning via an unauthenticated TLS tunnel. It provides for a server unauthenticated provisioning mode, but the inner TLS exchange requires that both ends authenticate each other. There are ways to provision a certificate, but the peer must still authenticate itself to the server with preexisting credentials. As a result, any provisioning method that uses TEAP will have to address this limitation.
TEAP [RFC9930] は、未認証の TLS トンネルを介したプロビジョニングを提供します。これはサーバー非認証プロビジョニング モードを提供しますが、内部 TLS 交換では両端が相互に認証する必要があります。証明書をプロビジョニングする方法はありますが、ピアは既存の資格情報を使用してサーバーに対して自身を認証する必要があります。その結果、TEAP を使用するプロビジョニング方法では、この制限に対処する必要があります。
There are two scenarios where provisioning can be done. The first is where provisioning is done within the EAP method, as with EAP-NOOB [RFC9140]. The second is where EAP is used to obtain limited network access (e.g., as with a captive portal). That limited network access is then used to run IP-based provisioning over more complex protocols.
プロビジョニングを実行できるシナリオは 2 つあります。1 つ目は、EAP-NOOB [RFC9140] のように、プロビジョニングが EAP メソッド内で行われる場所です。2 つ目は、制限されたネットワーク アクセスを取得するために EAP が使用される場合です (たとえば、キャプティブ ポータルの場合など)。この制限されたネットワーク アクセスは、より複雑なプロトコル上で IP ベースのプロビジョニングを実行するために使用されます。
It is often useful to do all provisioning inside of EAP because the EAP / Authentication, Authorization, and Accounting (AAA) admin does not have control over the network. It is not always possible to define a captive portal where provisioning can be done. As a result, we need to be able to perform provisioning via EAP: not via some IP.
EAP/認証、認可、およびアカウンティング (AAA) 管理者はネットワークを制御できないため、EAP 内ですべてのプロビジョニングを行うと便利なことがよくあります。プロビジョニングを実行できるキャプティブ ポータルを定義できるとは限りません。そのため、IP 経由ではなく、EAP 経由でプロビジョニングを実行できる必要があります。
EAP Provisioning Identifier
EAP プロビジョニング識別子
The EAP Provisioning Identifier (or EPI) is defined to be a strict subset of the NAI [RFC7542]. The EPI is an NAI that is a subdomain of "eap.arpa.". The "realm" portion of the NAI is defined in [RFC7542], Section 2.2, which is a more restrictive subset of the domain name conventions specified in [STD13].
EAP プロビジョニング識別子 (EPI) は、NAI [RFC7542] の厳密なサブセットとして定義されています。EPI は、「eap.arpa.」のサブドメインである NAI です。NAI の「レルム」部分は [RFC7542] のセクション 2.2 で定義されており、[STD13] で指定されているドメイン名規則のより制限的なサブセットです。
Readers of this document should note that the realm portion of the NAI is different from a domain name. In addition to the character set being more limited, the realm portion of the NAI does not include a trailing period (".").
この文書の読者は、NAI のレルム部分がドメイン名とは異なることに注意してください。文字セットがより制限されていることに加えて、NAI のレルム部分には末尾のピリオド (「.」) が含まれません。
eap.arpa
eap.arpa
The realm portion of the NAI.
NAI のレルム部分。
This document uses the term "eap.arpa realm" when using that name within the context of an NAI.
このドキュメントでは、NAI のコンテキスト内でその名前を使用する場合、「eap.arpa レルム」という用語を使用します。
eap.arpa.
eap.arpa.
The domain name "eap.arpa.".
ドメイン名は「eap.arpa.」。
This document uses the term "eap.arpa. domain" when using that name within the context of the DNS. The trailing period (".") is added for consistency with DNS specifications.
このドキュメントでは、DNSのコンテキスト内でその名前を使用する場合、「eap.arpa.ドメイン」という用語を使用します。DNS仕様との一貫性を保つために、末尾のピリオド（「.」）が追加されます。
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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
A device that has no device-specific credentials can use a predefined provisioning identifier in NAI format [RFC7542]. The NAI is composed of two portions: the utf8-username and the utf8-realm domain. For simplicity, we refer to these as the "username" and "realm" fields.
デバイス固有の認証情報を持たないデバイスは、NAI 形式 [RFC7542] の事前定義されたプロビジョニング識別子を使用できます。NAI は、utf8-username と utf8-realm ドメインの 2 つの部分で構成されます。簡単にするために、これらを「ユーザー名」フィールドと「レルム」フィールドと呼びます。
The realm is chosen to be independent of, and unused by, any existing organization; thus, it is to be usable by all organizations. The realm needs to be one that is not automatically proxied by any existing AAA proxy framework as defined in [RFC7542], Section 3. The realm also needs to be one that does not return results for dynamic discovery as described in [RFC7585].
レルムは、既存の組織から独立し、既存の組織によって使用されないように選択されます。したがって、すべての組織が使用できるようにする必要があります。レルムは、[RFC7542] のセクション 3 で定義されているように、既存の AAA プロキシ フレームワークによって自動的にプロキシされないものである必要があります。レルムは、[RFC7585] で説明されているように、動的検出の結果を返さないものである必要もあります。
However, this specification does not forbid the routing of packets for NAIs in the eap.arpa realm. Instead, it leaves such routing up to individual organizations.
ただし、この仕様は、eap.arpa レルム内の NAI のパケットのルーティングを禁止していません。代わりに、そのようなルーティングは個々の組織に任せられます。
This specification is fully compatible with all known EAP implementations, so it is fail-safe. When presented with a peer wishing to use this specification, existing implementations will return EAP Failure and will not otherwise misbehave.
この仕様は、既知のすべての EAP 実装と完全に互換性があるため、フェールセーフです。この仕様の使用を希望するピアに提示された場合、既存の実装は EAP Failure を返しますが、それ以外の場合は誤動作しません。
This document defines the eap.arpa realm as being used for provisioning within EAP. A similar domain has previously been used for EAP-NOOB [RFC9140] as "eap-noob.arpa". This document extends that concept and standardizes the practices surrounding it.
このドキュメントでは、eap.arpa レルムを EAP 内のプロビジョニングに使用するものとして定義します。同様のドメインは、以前に「eap-noob.arpa」として EAP-NOOB [RFC9140] に使用されていました。この文書はその概念を拡張し、それを取り巻く実践を標準化します。
The NAIs defined by this specification use the "realm" field defined in [RFC7542] to signal the behavior being requested; in particular, the subdomain under the eap.arpa. domain allows for different requested methods to be distinguished. The subdomain in the realm field is assigned via the "EAP Provisioning Identifiers" registry [EAPREG], which is defined in Section 5.2. The subdomain MUST follow the syntax defined in [RFC7542], Section 2.2, which is a more restrictive subset of the domain name conventions specified in [STD13].
この仕様で定義されているNAIは、[RFC7542]で定義されている「レルム」フィールドを使用して要求されている動作を通知します。特に、eap.arpa.ドメイン配下のサブドメインにより、要求された異なるメソッドを区別することができます。レルムフィールド内のサブドメインは、セクション5.2で定義されている「EAPプロビジョニング識別子」レジストリ[EAPREG]を介して割り当てられます。サブドメインは、[RFC7542]のセクション2.2で定義されている構文に従わなければなりません（MUST）。これは、[STD13]で指定されているドメイン名規則のより制限的なサブセットです。
Where possible, the first subdomain of the eap.arpa. domain SHOULD use the EAP method name, as defined in the "Extensible Authentication Protocol (EAP) Registry" registry group, "Method Types" registry. However, the names in the "EAP Method Type" registry [EAPREG] do not follow the domain name formats specified in [STD13], so it is not always possible to make a one-to-one mapping between the Method Type name and a subdomain of the eap.arpa. domain.
可能な場合は、eap.arpa.ドメインの最初のサブドメインは、「Extensible Authentication Protocol (EAP) Registry」レジストリグループの「Method Types」レジストリで定義されているEAPメソッド名を使用すべきです（SHOULD）。しかし、「EAP Method Type」レジストリ[EAPREG]内の名前は[STD13]で指定されているドメイン名形式に従っていないため、メソッドタイプ名とeap.arpa.ドメインのサブドメインとの間で常に1対1のマッピングを作成できるとは限りません。
Where it is not possible to make a direct mapping between the EAP Method Type name due to the EAP Method Type name not matching the [RFC7542], Section 2.2 format, the NAI that is defined in the "EAP Provisioning Identifiers" registry MUST use a realm name that is similar enough to allow the average reader to understand which EAP Method Type is being used.
EAPメソッドタイプ名が[RFC7542]セクション2.2の形式と一致しないため、EAPメソッドタイプ名間の直接マッピングを作成できない場合、「EAPプロビジョニング識別子」レジストリで定義されているNAIは、一般的な読者がどのEAPメソッドタイプが使用されているかを理解できるほど十分に類似したレルム名を使用しなければなりません（MUST）。
Additional subdomains are permitted in the realm; these permit vendors and Standards Development Organizations (SDOs) the ability to self-assign a delegated range of identifiers that do not conflict with other identifiers.
レルム内では追加のサブドメインが許可されます。これらにより、ベンダーと標準開発機関 (SDO) は、他の識別子と競合しない、委任された範囲の識別子を自己割り当てできるようになります。
Any realm defined in this registry (e.g., "tls.eap.arpa") also implicitly defines a sub-realm "v." (e.g., "v.tls.eap.arpa"). Vendors or SDOs can self-allocate within the "v." realm using realms that they own. For example, a company that owns the "example.com." domain could self-allocate and use the realm "example.com.v.tls.eap.arpa". See Section 5.2.5 for more discussion of this topic.
このレジストリで定義されたレルム（「tls.eap.arpa」など）は、サブレルム「v.」（例：「v.tls.eap.arpa」）も暗黙的に定義します。ベンダーやSDOは、自身が所有するレルムを使用して「v.」レルム内で自己割り当てを行うことができます。例えば、「example.com.」ドメインを所有する企業は、自己割り当てを行って「example.com.v.tls.eap.arpa」レルムを使用することができます。このトピックの詳細については、セクション5.2.5を参照してください。
This specification does not make any provisions for private-use realms. The "v." sub-realm is sufficient for all private uses.
この仕様では、私的使用領域については何も規定していません。「v」サブレルムは、すべての私的使用に十分です。
Experimental provisioning methods MUST be defined within the appropriate vendor's name space. For documents within the IETF, the "ietf.org" vendor space MUST be used. Different uses SHOULD be distinguished by using the name of a working group or document, such as "emu.ietf.org.v.eap.arpa".
実験的なプロビジョニング方法は、適切なベンダーの名前空間内で定義する必要があります。IETF 内のドキュメントについては、「ietf.org」ベンダー スペースを使用しなければなりません。異なる用途は、「emu.ietf.org.v.eap.arpa」などの作業グループまたは文書の名前を使用して区別する必要があります (SHOULD)。
The username field is dependent on the EAP method being used for provisioning. For example, [RFC9140] uses the username "noob". Other EAP methods MAY omit the username as recommended in [RFC7542]. The username "anonymous" is NOT RECOMMENDED for specifications using this format, even though it is permitted by [RFC7542]. The name "anonymous" is widely used in NAIs today, and we wish to avoid confusion.
ユーザー名フィールドは、プロビジョニングに使用される EAP メソッドによって異なります。たとえば、[RFC9140] ではユーザー名「noob」が使用されます。他の EAP メソッドでは、[RFC7542] で推奨されているように、ユーザー名を省略してもよい(MAY)。ユーザー名「anonymous」は、[RFC7542] で許可されている場合でも、この形式を使用する仕様では推奨されません。「匿名」という名前は現在 NAI で広く使用されており、混乱を避けたいと考えています。
The username field is assigned via the "EAP Provisioning Identifiers" registry, which is defined in Section 5.2. The username field MAY be empty or hold a fixed value. While [RFC7542] recommends omitting the username portion for user privacy, the names here are defined in public specifications. Therefore, user privacy is not needed for provisioning identifiers; the username field can be publicly visible.
ユーザー名フィールドは、セクション 5.2 で定義されている「EAP プロビジョニング識別子」レジストリを介して割り当てられます。ユーザー名フィールドは空にするか、固定値を保持することができます。[RFC7542] では、ユーザーのプライバシーを保護するためにユーザー名の部分を省略することを推奨していますが、ここでの名前は公開仕様で定義されています。したがって、識別子のプロビジョニングにはユーザーのプライバシーは必要ありません。ユーザー名フィールドは一般に公開できます。
Having described the format and contents of NAIs in the eap.arpa realm to define the EPI, we now describe how those EPIs are used by EAP peers and EAP servers to signal provisioning information.
EPI を定義するための eap.arpa レルム内の NAI の形式と内容について説明しました。次に、これらの EPI が EAP ピアおよび EAP サーバーによってプロビジョニング情報を通知するためにどのように使用されるかを説明します。
An EAP peer signals that it wishes a certain kind of provisioning by using an EPI along with an associated EAP method. The meaning of the EPI, and behavior of the peer, are defined by a separate specification. That specification will typically define both the EPI and the EAP method or methods that are used for provisioning.
EAP ピアは、EPI と関連する EAP メソッドを使用して、特定の種類のプロビジョニングを希望していることを通知します。EPI の意味とピアの動作は、別の仕様によって定義されます。この仕様では通常、EPI とプロビジョニングに使用される EAP メソッドの両方が定義されます。
The EPI used by the peer MUST be taken from an entry in the "EAP Provisioning Identifiers" registry, and the EAP method used with that NAI MUST match the corresponding EAP method from that same entry.
ピアが使用する EPI は、「EAP Provisioning Identifiers」レジストリのエントリから取得する必要があり、その NAI で使用される EAP メソッドは、同じエントリの対応する EAP メソッドと一致しなければなりません。
Where an EAP peer allows local selection of a provisioning method, the EPI is defined by the provisioning method and not by the end user. As a result, when a provisioning method is being selected, the EAP peer MUST NOT have a configuration interface that lets the EAP user identifier field be configured directly. Instead, the user (or some other process) chooses a provisioning method and the EAP peer then selects the EPI that matches that provisioning method.
EAP ピアがプロビジョニング方法のローカル選択を許可する場合、EPI はエンド ユーザーではなくプロビジョニング方法によって定義されます。その結果、プロビジョニング方法が選択されている場合、EAP ピアは EAP ユーザー識別子フィールドを直接設定できる設定インターフェイスを持ってはなりません (MUST NOT)。代わりに、ユーザー (または他のプロセス) がプロビジョニング方法を選択し、EAP ピアがそのプロビジョニング方法と一致する EPI を選択します。
While EAP peers allow users to enter user identifiers directly for existing EAP methods, they MUST NOT check whether those identifiers match any EPI. Any user who enters an identifier that matches an EPI either will get rejected because the server does not support provisioning or the user will be placed into a captive portal. There are no security or privacy issues with a user manually entering an EPI as the user identifier.
EAP ピアでは、ユーザーが既存の EAP メソッドにユーザー識別子を直接入力することを許可していますが、それらの識別子が EPI と一致するかどうかを確認してはなりません (MUST NOT)。EPI に一致する識別子を入力したユーザーは、サーバーがプロビジョニングをサポートしていないために拒否されるか、キャプティブ ポータルに配置されます。ユーザーが EPI をユーザー識別子として手動で入力する場合、セキュリティやプライバシーの問題は発生しません。
When all goes well, running EAP with the EPI results in new authentication credentials being provisioned. The peer then drops its network connection and re-authenticates using the newly provisioned credentials. The user MAY be involved in this process, but, in general, provisioning results in the EAP peer automatically gaining network access using the provisioned credentials.
すべてがうまくいけば、EPI を使用して EAP を実行すると、新しい認証資格情報がプロビジョニングされます。その後、ピアはネットワーク接続を切断し、新しくプロビジョニングされた資格情報を使用して再認証します。ユーザーはこのプロセスに関与する場合がありますが、一般に、プロビジョニングの結果、EAP ピアはプロビジョニングされた資格情報を使用してネットワーク アクセスを自動的に取得します。
There are a number of ways in which provisioning can fail. One way is when the server does not implement the provisioning method. Therefore, EAP peers MUST track which provisioning methods have been tried and not repeat the same method to the same EAP server when receiving an EAP Nak.
プロビジョニングが失敗する原因は数多くあります。1 つの方法は、サーバーがプロビジョニング メソッドを実装していない場合です。したがって、EAP ピアは、どのプロビジョニング方法が試行されたかを追跡し、EAP Nak を受信したときに同じ EAP サーバーに対して同じ方法を繰り返してはなりません (MUST)。
Peers MUST rate limit their provisioning attempts. If provisioning fails, it is likely because provisioning is not available. Retrying provisioning repeatedly and in quick succession is not likely to change the server behavior. Instead, it is likely to result in the peer being blocked. The peer SHOULD retry provisioning no more than once every few minutes and SHOULD include jitter and exponential backoff on its provisioning attempts.
ピアはプロビジョニングの試行をレート制限しなければなりません (MUST)。プロビジョニングが失敗する場合は、プロビジョニングが利用できないことが原因である可能性があります。プロビジョニングを繰り返し短時間で再試行しても、サーバーの動作が変わる可能性は高くありません。代わりに、ピアがブロックされる可能性があります。ピアは、プロビジョニングを数分に 1 回以上再試行すべきではなく、プロビジョニングの試行にジッターと指数バックオフを含めるべきです (SHOULD)。
Since there is no way to signal whether the failed provisioning is due to a transient failure on the EAP server or due to the EAP server not supporting that provisioning method, EAP peers SHOULD err on the side of long delays between retrying the same provisioning method to an EAP server. EAP peers MAY retry a given provisioning method after a sufficiently long interval that the EAP server might have implemented the provisioning method, e.g., at least a day and perhaps no more than a month.
失敗したプロビジョニングが EAP サーバー上の一時的な障害によるものか、それとも EAP サーバーがそのプロビジョニング方法をサポートしていないためであるかを通知する方法がないため、EAP ピアは、EAP サーバーに対して同じプロビジョニング方法を再試行する間に長い遅延が発生することを考慮すべきです(SHOULD)。EAP ピアは、EAP サーバーがプロビジョニング方法を実装した可能性がある十分に長い間隔 (たとえば、少なくとも 1 日、おそらく 1 か月以内) の後に、指定されたプロビジョニング方法を再試行してもよい(MAY)。
Another way for the provisioning method to fail is when the new credentials do not result in network access. It is RECOMMENDED that when peers are provisioned with credentials, they immediately try to gain network access using those credentials. That process allows errors to be quickly discovered and addressed.
プロビジョニング方法が失敗するもう 1 つの原因は、新しい認証情報がネットワーク アクセスにつながらない場合です。ピアに資格情報がプロビジョニングされたら、すぐにその資格情報を使用してネットワーク アクセスを取得しようとすることが推奨されます。このプロセスにより、エラーを迅速に発見して対処できるようになります。
An EAP peer may have been provisioned with temporary credentials or credentials that expire after some period of time (e.g., an X.509 certificate with notAfter date set). Therefore, it SHOULD attempt to provision new credentials before the current set expires. Unfortunately, any re-provisioning process with EAP will involve the device dropping off from the "full" network in order to connect to the provisioning network. Therefore, it is RECOMMENDED that re-provisioning methods be provided that can be used when the device has full network access. See Section 3.6 for additional discussion on this topic.
EAP ピアには、一時的な認証情報、または一定期間後に期限切れになる認証情報 (notAfter 日付が設定された X.509 証明書など) がプロビジョニングされている可能性があります。したがって、現在のセットが期限切れになる前に、新しい資格情報のプロビジョニングを試みるべきです(SHOULD)。残念ながら、EAP を使用した再プロビジョニング プロセスでは、プロビジョニング ネットワークに接続するために、デバイスが「フル」ネットワークからドロップオフする必要があります。したがって、デバイスが完全なネットワーク アクセスを持っている場合に使用できる再プロビジョニング方法を提供することが推奨されます。このトピックの詳細については、セクション 3.6 を参照してください。
An EAP session begins with the server receiving an initial EAP-Request/Identity message. An EAP server implementing this specification MUST examine the identity to see if it uses a realm located under the eap.arpa realm. If so, the identity is an EPI. Processing of all other identities is unchanged by this specification.
EAP セッションは、サーバーが最初の EAP-Request/Identity メッセージを受信することで始まります。この仕様を実装する EAP サーバーは、アイデンティティを検査して、eap.arpa レルムの下にあるレルムを使用しているかどうかを確認する必要があります。そうである場合、アイデンティティは EPI です。他のすべての ID の処理は、この仕様では変更されません。
If the server receives an EPI that is malformed, it MUST reply with an EAP Failure as per [RFC3748], Section 4.2. For example, an NAI may end with the eap.arpa realm but may also contain data that is not permitted by the format described in [RFC7542]. Otherwise, the EPI is examined to determine which provisioning method is being requested by the peer.
サーバーが不正な形式の EPI を受信した場合、[RFC3748] セクション 4.2 に従って EAP Failure で応答しなければなりません (MUST)。たとえば、NAI は eap.arpa レルムで終わる場合がありますが、[RFC7542] で説明されている形式で許可されていないデータも含まれる場合があります。それ以外の場合は、EPI が検査されて、ピアによってどのプロビジョニング方式が要求されているかが判断されます。
If the server does not recognize the EPI requested by the peer, it MUST reply with an EAP Nak of type zero (0). This reply indicates that the requested provisioning method is not available. The server also MUST reply with a Nak of type zero (0) as per [RFC3748], Section 5.3.1 if the peer proposes an EAP method that is not supported by the server or is not recognized as being valid for that provisioning method. The peer can then take any remedial action that it determines to be appropriate.
サーバーがピアによって要求された EPI を認識しない場合、サーバーはタイプ ゼロ (0) の EAP Nak で応答しなければなりません (MUST)。この応答は、要求されたプロビジョニング方法が利用できないことを示します。また、サーバーがサポートしていない EAP メソッドをピアが提案した場合、またはそのプロビジョニングメソッドが有効であると認識されなかった場合、サーバーは [RFC3748] セクション 5.3.1 に従ってタイプ 0 (0) の Nak で応答しなければなりません (MUST)。その後、ピアは適切であると判断したあらゆる是正措置を講じることができます。
Once the server accepts the provisioning method, it then replies with an EAP method that MUST match the one associated with the EPI. The EAP process then proceeds as per the EAP state machine outlined in [RFC3748].
サーバーがプロビジョニング メソッドを受け入れると、EPI に関連付けられた EAP メソッドと一致する必要がある EAP メソッドで応答します。その後、EAP プロセスは、[RFC3748] で概説されている EAP ステート マシンに従って続行されます。
Implementations MUST treat peers using an EPI as untrusted and untrustworthy. Once such a peer is authenticated, it MUST be placed into a limited network such as a captive portal. The limited network MUST NOT permit unrestricted network access. Implementations should be aware of methods that bypass simple blocking such as tunneling data over DNS.
実装では、EPI を使用するピアを信頼できないものとして扱わなければなりません (MUST)。このようなピアが認証されると、キャプティブ ポータルなどの限定されたネットワークに配置されなければなりません。制限されたネットワークでは、無制限のネットワーク アクセスを許可してはなりません。実装では、DNS 経由のデータのトンネリングなどの単純なブロックをバイパスする方法を認識する必要があります。
A secure provisioning network is one where only the expected traffic is allowed and all other traffic is blocked. The alternative of blocking only selected "bad" traffic results in substantial security failures. As most provisioning methods permit unauthenticated devices to gain network access, these methods have a substantial potential for abuse by malicious actors. As a result, the limited network needs to be designed assuming that it will be abused by malicious actors.
安全なプロビジョニング ネットワークとは、予想されるトラフィックのみが許可され、その他のトラフィックはすべてブロックされるネットワークです。選択した「悪い」トラフィックのみをブロックするという代替方法では、重大なセキュリティ障害が発生します。ほとんどのプロビジョニング方法では、認証されていないデバイスによるネットワーク アクセスが許可されるため、これらの方法は悪意のある攻撃者による悪用の可能性が大きくあります。そのため、制限されたネットワークは悪意のある者によって悪用されることを想定して設計する必要があります。
A limited network SHOULD also limit the duration of network access by devices being provisioned. The provisioning process should be fairly quick: in the order of seconds to tens of seconds in duration. Provisioning times longer than this likely indicate an issue; it may be useful to block the problematic device from the network.
ネットワークが制限されている場合は、プロビジョニングされているデバイスによるネットワーク アクセスの期間も制限すべきです。プロビジョニング プロセスは、数秒から数十秒程度と、非常に高速である必要があります。プロビジョニング時間がこれより長い場合は、問題があることを示している可能性があります。問題のあるデバイスをネットワークからブロックすると便利な場合があります。
A limited network SHOULD also limit the amount of data being transferred by devices being provisioned and SHOULD limit the network services that are available to those devices. The provisioning process generally does not need to download large amounts of data; similarly, it does not need access to a large number of services.
制限されたネットワークでは、プロビジョニングされているデバイスによって転送されるデータの量も制限すべきであり、それらのデバイスが利用できるネットワーク サービスも制限すべきです。通常、プロビジョニング プロセスでは大量のデータをダウンロードする必要はありません。同様に、多数のサービスにアクセスする必要もありません。
Servers SHOULD rate limit provisioning attempts. A misbehaving peer can be blocked temporarily or even permanently. Implementations SHOULD limit the total number of peers being provisioned at the same time. There is no requirement for RADIUS servers to allow all peers to connect without limit. Instead, peers are provisioned at the discretion of the network being accessed, which may permit or deny those devices based on reasons that are not explained to those devices.
サーバーはプロビジョニングの試行をレート制限すべきです(SHOULD)。不正な動作をしているピアは、一時的に、または永久にブロックされる場合があります。実装では、同時にプロビジョニングされるピアの総数を制限する必要があります (SHOULD)。RADIUS サーバーには、すべてのピアが無制限に接続できるようにする必要はありません。代わりに、アクセスされるネットワークの裁量でピアがプロビジョニングされ、デバイスに説明されていない理由に基づいてデバイスが許可または拒否される場合があります。
Implementations SHOULD use functionality such as the RADIUS Filter-Id attribute ([RFC2865], Section 5.11) to limit network access for the peer being provisioned, as discussed in Section 3.4.2. For ease of administration, the Filter-Id name could simply be the EPI or a similar name. Such consistency aids with operational considerations when managing complex networks.
実装では、セクション 3.4.2 で説明したように、プロビジョニングされるピアのネットワーク アクセスを制限するために、RADIUS Filter-Id 属性 ([RFC2865]、セクション 5.11) などの機能を使用する必要があります (SHOULD)。管理を容易にするために、Filter-Id 名を単純に EPI または同様の名前にすることができます。このような一貫性は、複雑なネットワークを管理する際の運用上の考慮事項に役立ちます。
Implementations MUST prevent peers in the limited network from communicating with each other. There is no reason for a system that is being provisioned to communicate with anything other than the provisioning server(s).
実装では、制限されたネットワーク内のピアが相互に通信できないようにしなければなりません。プロビジョニング中のシステムがプロビジョニング サーバー以外と通信する理由はありません。
Implementations MUST NOT permit EAP method negotiation with provisioning credentials. That is, when an EPI is used, any EAP Nak sent by a server must contain only EAP method zero (0). When an EAP peer uses an EPI and receives an EAP Nak, any EAP methods given in that Nak MUST be ignored.
実装では、プロビジョニング資格情報を使用した EAP メソッドのネゴシエーションを許可してはなりません (MUST NOT)。つまり、EPI が使用される場合、サーバーによって送信される EAP Nak には EAP メソッド ゼロ (0) のみが含まれている必要があります。EAP ピアが EPI を使用し、EAP Nak を受信した場合、その Nak で指定された EAP メソッドは無視されなければなりません (MUST)。
While a server may support multiple provisioning methods, there is no way in EAP to negotiate which provisioning method can be used. It is also expected that the provisioning methods will be specific to a particular type of peer device. That is, a given peer is likely to support only one provisioning method.
サーバーは複数のプロビジョニング方法をサポートする場合がありますが、EAP ではどのプロビジョニング方法を使用できるかをネゴシエートする方法がありません。また、プロビジョニング方法が特定のタイプのピア デバイスに固有のものになることも予想されます。つまり、特定のピアは 1 つのプロビジョニング方法のみをサポートする可能性があります。
As a result, there is no need to require a method for negotiating provisioning methods.
その結果、プロビジョニング方法をネゴシエートするためのメソッドを要求する必要はありません。
The operational considerations discussed in this document have a number of impacts on specifications that define provisioning methods.
このドキュメントで説明する運用上の考慮事項は、プロビジョニング方法を定義する仕様に多くの影響を与えます。
Specifications that define provisioning for an EAP method SHOULD provide a method-specific process by which implementations can negotiate a mutually acceptable provisioning method.
EAP メソッドのプロビジョニングを定義する仕様は、実装が相互に受け入れ可能なプロビジョニングメソッドをネゴシエートできるメソッド固有のプロセスを提供する必要があります (SHOULD)。
However, for the reasons noted in this document, we cannot make this suggestion mandatory. If it is not possible for a provisioning method to define any negotiation, then that limitation should not be a barrier to publishing the specification.
ただし、この文書に記載されている理由により、この提案を強制することはできません。プロビジョニング方法でネゴシエーションを定義できない場合、その制限が仕様の公開の障害になるべきではありません。
Where a provisioning method is expected to create credentials that do not expire, the specification SHOULD state this explicitly.
プロビジョニング方法が期限切れのない認証情報を作成することが期待される場合、仕様はこれを明示的に記述する必要があります (SHOULD)。
Where credentials expire, it is RECOMMENDED that specifications provide guidance on how the credentials are to be updated. For example, an EAP method could permit re-provisioning to be done as part of a normal EAP authentication using the currently provisioned credentials.
資格情報の有効期限が切れた場合、資格情報を更新する方法に関するガイダンスを仕様に提供することが推奨されます。たとえば、EAP メソッドでは、現在プロビジョニングされている資格情報を使用して、通常の EAP 認証の一部として再プロビジョニングを実行できます。
It is RECOMMENDED that the provisioning methods provide for a method that can be used without affecting network access. A specification could define provisioning endpoints such as Enrollment over Secure Transport (EST) [RFC7030] or Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) [RFC9810]. The provisioning endpoints could be available both on the provisioning network and on the provisioned (i.e., normal) network. Such an architecture means that devices can be re-provisioned without losing network access.
プロビジョニング方法は、ネットワークアクセスに影響を与えずに使用できる方法を提供することが推奨されます。仕様では、Enrollment over Secure Transport (EST) [RFC7030] や Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) [RFC9810] などのプロビジョニング エンドポイントを定義できます。プロビジョニング エンドポイントは、プロビジョニング ネットワークとプロビジョニングされた (通常の) ネットワークの両方で使用できます。このようなアーキテクチャは、ネットワーク アクセスを失うことなくデバイスを再プロビジョニングできることを意味します。
[RFC7542], Section 3 describes how the NAI allows authentication requests to be routable within a AAA proxy system. While the EPI uses the NAI format, the eap.arpa realm has been chosen because it is not routable within a AAA proxy system.
[RFC7542] のセクション 3 では、NAI が AAA プロキシ システム内で認証リクエストをルーティング可能にする方法について説明しています。EPI は NAI 形式を使用しますが、AAA プロキシ システム内でルーティングできないため、eap.arpa レルムが選択されています。
When we say that the eap.arpa realm is not routable in a AAA proxy system, we mean two different things:
eap.arpa レルムが AAA プロキシ システムでルーティングできないという場合、次の 2 つの異なることを意味します。
1. The eap.arpa. domain does not exist within the DNS, so it will never be resolvable for dynamic discovery as described in [RFC7585].
1. eap.arpa.ドメインはDNS内に存在しないため、[RFC7585]で説明されているように動的検出のために解決されることはありません。
2. The eap.arpa realm will never be used by any administrator; the administrator is unable to satisfy the requirements of [RFC7542], Section 2.5 by registering the realm within the DNS.
2. eap.arpa レルムは管理者によって使用されることはありません。管理者は、DNS 内にレルムを登録することによって、[RFC7542] セクション 2.5 の要件を満たすことができません。
In addition, administrators will not have statically configured AAA proxy routes for this domain. Where routes are added for this domain, they will generally be used to implement this specification.
さらに、管理者は、このドメインに対して静的に設定された AAA プロキシ ルートを持ちません。このドメインにルートが追加される場合、それらは通常、この仕様を実装するために使用されます。
In order to avoid spurious DNS lookups, RADIUS servers supporting [RFC7585] SHOULD perform filtering in the domains that are sent to DNS. Specifically, names in the eap.arpa. domain MUST NOT be looked up in DNS.
無駄なDNSルックアップを回避するために、[RFC7585]をサポートするRADIUSサーバーはDNSに送信されるドメインのフィルタリングを実行すべきです（SHOULD）。具体的には、eap.arpa.ドメイン内の名前をDNSで検索してはなりません（MUST NOT）。
As the provisioning identifier is used within EAP, it necessarily has interactions with, and effects on, the various EAP methods. This section discusses those effects in more detail.
プロビジョニング識別子は EAP 内で使用されるため、必然的にさまざまな EAP メソッドと相互作用し、影響を与えます。このセクションでは、それらの影響について詳しく説明します。
Some EAP methods require shared credentials such as passwords in order to succeed. For example, both EAP-MSCHAPv2 (Protected Extensible Authentication Protocol aka PEAP) and EAP-pwd [RFC5931] perform cryptographic exchanges where both parties know a shared password. Where password-based methods are used, the password SHOULD be the same as the provisioning identifier, as there are few reasons to define a method-specific password.
一部の EAP メソッドは、成功するためにパスワードなどの共有資格情報を必要とします。たとえば、EAP-MSCHAPv2 (保護された拡張認証プロトコル、別名 PEAP) と EAP-pwd [RFC5931] は両方とも、双方が共有パスワードを知っている暗号交換を実行します。パスワードベースのメソッドが使用される場合、メソッド固有のパスワードを定義する理由はほとんどないため、パスワードはプロビジョニング識別子と同じである必要があります (SHOULD)。
This requirement also applies to TLS-based EAP methods such as EAP Tunneled Transport Layer Security (EAP-TTLS) and PEAP. Where the TLS-based EAP method provides for an inner identity and inner authentication method, the credentials used there SHOULD be the provisioning identifier for both the inner identity and any inner password.
この要件は、EAP トンネル トランスポート層セキュリティ (EAP-TTLS) や PEAP などの TLS ベースの EAP 方式にも適用されます。TLS ベースの EAP メソッドが内部 ID と内部認証メソッドを提供する場合、そこで使用される資格情報は、内部 ID と内部パスワードの両方のプロビジョニング識別子である必要があります (SHOULD)。
It is RECOMMENDED that provisioning be done via a TLS-based EAP method. TLS provides for authentication of the EAP server along with integrity and confidentiality protection for any provisioning data exchanged in the tunnel. Similarly, if provisioning is done in a captive portal outside of EAP, EAP-TLS permits the EAP peer to run a full EAP authentication session while having nothing more than a few Certification Authorities (CAs) locally configured.
プロビジョニングは、TLS ベースの EAP メソッドを介して実行されることが推奨されます。TLS は、トンネル内で交換されるプロビジョニング データの整合性と機密性の保護とともに、EAP サーバーの認証を提供します。同様に、プロビジョニングが EAP の外部のキャプティブ ポータルで行われる場合、EAP-TLS により、EAP ピアはローカルに少数の認証局 (CA) のみを構成しながら、完全な EAP 認証セッションを実行できます。
All provisioning methods that are specified within the eap.arpa. domain MUST define a way to authenticate the server. This authentication can happen either at the EAP layer (as with TLS-based EAP methods) or after network access has been granted (if credentials are provisioned over HTTPS).
eap.arpa.ドメイン内で指定されているすべてのプロビジョニングメソッドは、サーバーを認証する方法を定義しなければなりません（MUST）。この認証は、EAP層（TLSベースのEAPメソッドと同様）またはネットワークアクセスが許可された後（資格情報がHTTPS経由でプロビジョニングされている場合）のいずれかで実行できます。
Where TLS-based EAP methods are used, implementations MUST still validate EAP server certificates in all situations other than provisioning. Where the provisioning method under the eap.arpa. domain defines that provisioning happens via another protocol such as with HTTPS, the EAP peer MAY skip validating the EAP server certificate.
TLSベースのEAPメソッドが使用される場合でも、実装はプロビジョニング以外のすべての状況でEAPサーバー証明書を依然として検証しなければなりません（MUST）。eap.arpa.ドメイン配下のプロビジョニングメソッドにおいて、プロビジョニングがHTTPSなどの別のプロトコルを介して行われると定義されている場合、EAPピアはEAPサーバー証明書の検証をスキップしてもよい（MAY）。
Whether or not the server certificate is ignored, the peer MUST treat the local network as untrusted. [RFC8952], Section 6 has more discussion on this topic.
サーバー証明書が無視されるかどうかに関係なく、ピアはローカルネットワークを信頼できないものとして扱わなければなりません(MUST)。[RFC8952] のセクション 6 では、このトピックについてさらに詳しく説明されています。
The ability to not validate the EAP server certificates relaxes the requirements of [RFC5216], Section 5.3 that the server certificate always be validated. For provisioning, it is acceptable in some cases to not validate the EAP server certificate but only when there are other means to authenticate the data that is being provisioned.
EAP サーバー証明書を検証しない機能により、サーバー証明書が常に検証されるという [RFC5216] セクション 5.3 の要件が緩和されます。プロビジョニングの場合、場合によっては EAP サーバー証明書を検証しなくても問題ありませんが、プロビジョニングされるデータを認証する他の手段がある場合に限ります。
However, since the device is likely otherwise configured with web CAs [CAB], the captive portal would also be unauthenticated provisioning methods could use those CAs within an EAP method in order to allow the peer to authenticate the EAP server. Further discussion of this topic is better suited for the specification(s) that define a particular provisioning method. This issue is not discussed further here, other than to say that it is technically possible.
ただし、デバイスは Web CA [CAB] を使用して構成されている可能性が高いため、キャプティブ ポータルも認証されず、ピアが EAP サーバーを認証できるようにするために、プロビジョニング メソッドが EAP メソッド内でこれらの CA を使用する可能性があります。このトピックのさらなる議論は、特定のプロビジョニング方法を定義する仕様に適しています。この問題については、技術的に可能であるという以外に、ここではこれ以上議論しません。
This document defines an NAI "portal@tls.eap.arpa", which allows EAP peers to use unauthenticated EAP-TLS. The purpose of the identifier is to allow EAP peers to signal to EAP servers that they wish to obtain "captive portal" network access.
この文書では、EAP ピアが認証されていない EAP-TLS を使用できるようにする NAI「portal@tls.eap.arpa」を定義します。識別子の目的は、EAP ピアが「キャプティブ ポータル」ネットワーク アクセスを取得したいことを EAP サーバーに通知できるようにすることです。
This identifier signals to the EAP server that the peer wishes to obtain "peer unauthenticated access" as per [RFC5216], Section 2.1.1 and [RFC9190]. Note that peer unauthenticated access MUST provide for authentication of the EAP server, such as with a server certificate. Using TLS-PSK with a well-known Pre-Shared Key (PSK) value is generally not appropriate, as it would not provide server authentication.
この識別子は、ピアが [RFC5216]、セクション 2.1.1、および [RFC9190] に従って「ピア非認証アクセス」の取得を望んでいることを EAP サーバーに通知します。ピアの非認証アクセスは、サーバー証明書などによる EAP サーバーの認証を提供しなければならないことに注意してください。既知の事前共有キー (PSK) 値で TLS-PSK を使用することは、サーバー認証を提供しないため、通常は適切ではありません。
An EAP server that agrees to authenticate this request MUST ensure that the device is placed into a captive portal with limited network access as discussed above in Section 3.4.2.
このリクエストの認証に同意する EAP サーバーは、セクション 3.4.2 で説明したように、ネットワーク アクセスが制限されたキャプティブ ポータルにデバイスが配置されることを保証しなければなりません (MUST)。
This method is an improvement over existing captive portals, which are typically completely unsecured and unauthenticated. Using peer unauthenticated TLS for network access ensures that the EAP server is proven to be authentic. The use of 802.1X [IEEE802.1X] ensures that the link between the EAP peer and EAP authenticator (e.g., access point) is also secured.
この方法は、通常は完全に安全で認証されていない既存のキャプティブ ポータルを改善したものです。ネットワーク アクセスにピア非認証 TLS を使用すると、EAP サーバーが本物であることが確実に証明されます。802.1X [IEEE802.1X] を使用すると、EAP ピアと EAP 認証システム (アクセス ポイントなど) の間のリンクも確実に保護されます。
Further details of the captive portal architecture can be found in [RFC8952]. The captive portal can advertise support for the eap.arpa. domain via an 802.11u [IEEE802.11u] realm.
キャプティブポータルアーキテクチャの詳細については、[RFC8952]を参照してください。キャプティブポータルは、802.11u [IEEE802.11u]レルム経由でeap.arpa.ドメインのサポートをアドバタイズできます。
It is RECOMMENDED that server implementations of EAP-NOOB accept both identities "noob@eap-noob.arpa" and "@noob.eap.arpa" as synonyms.
EAP-NOOB のサーバー実装は、「noob@eap-noob.arpa」と「@noob.eap.arpa」の両方のアイデンティティを同義語として受け入れることが推奨されます。
It is RECOMMENDED that EAP-NOOB peers use "@noob.eap.arpa" first and, if that does not succeed, then they use "noob@eap-noob.arpa".
EAP-NOOB ピアが最初に「@noob.eap.arpa」を使用し、それが成功しない場合は「noob@eap-noob.arpa」を使用することが推奨されます。
This document describes a number of IANA actions:
この文書では、IANA のさまざまなアクションについて説明します。
* IANA has made two registry updates in order to define the eap.arpa. domain (Section 5.1).
* IANAは、eap.arpa.ドメインを定義するために2つのレジストリ更新を行いました（セクション5.1）。
* IANA has created a new registry (see Section 5.2).
* IANA は新しいレジストリを作成しました (セクション 5.2 を参照)。
There are two updates to the ".ARPA Zone Management" registry [ARPAREG] (detailed in Sections 5.1.1 and 5.1.2).
「.ARPA Zone Management」レジストリ [ARPAREG] には 2 つの更新があります (詳細はセクション 5.1.1 および 5.1.2 を参照)。
IANA has also been instructed to refuse further allocation requests that are directly within the ".ARPA Zone Management" registry for any functionality related to the EAP. Instead, allocations related to EAP are to be made within the new "EAP Provisioning Identifiers" registry in the "Extensible Authentication Protocol (EAP) Registry" registry group (see [EAPREG]).
IANA はまた、EAP に関連する機能について、「.ARPA Zone Management」レジストリ内に直接含まれるさらなる割り当て要求を拒否するよう指示されています。代わりに、EAP に関連する割り当ては、「Extensible Authentication Protocol (EAP) Registry」レジストリ グループ内の新しい「EAP Provisioning Identifiers」レジストリ内で行われます ([EAPREG] を参照)。
IANA has updated the "eap-noob.arpa" entry in the ".ARPA Zone Management" registry [ARPAREG] as follows:
IANA は、「.ARPA Zone Management」レジストリ [ARPAREG] の「eap-noob.arpa」エントリを次のように更新しました。
The USAGE/REFERENCE field has been updated to prefix the text with (DEPRECATED) and to add a reference to this document (RFC 9965).
USAGE/REFERENCE フィールドが更新され、テキストの先頭に (DEPRECATED) が付けられ、このドキュメント (RFC 9965) への参照が追加されました。
IANA has updated the ".ARPA Zone Management" registry [ARPAREG] to include the following entry:
IANA は、「.ARPA Zone Management」レジストリ [ARPAREG] を更新して、次のエントリを追加しました。
DOMAIN:
ドメイン：
eap.arpa
eap.arpa
USAGE/REFERENCE:
使用方法/参照:
For provisioning within the Extensible Authentication Protocol framework. RFC 9965
Extensible Authentication Protocol フレームワーク内でのプロビジョニング用。RFC 9965
IANA has updated the "Special-Use Domain Names" registry (see [SPECIAL-USE]) as follows:
IANA は、「特殊用途ドメイン名」レジストリ ([特殊用途] を参照) を次のように更新しました。
Name:
名前：
eap.arpa.
eap.arpa.
Reference:
参照：
RFC 9965
RFC 9965
This section answers the questions that are required by Section 5 of [RFC6761]. At a high level, these new domain names are used in certain situations in EAP. The domain names are never seen by users, and they do not appear in any networking protocol other than EAP.
このセクションは、[RFC6761] のセクション 5 で要求される質問に答えます。大まかに言うと、これらの新しいドメイン名は EAP の特定の状況で使用されます。ドメイン名はユーザーに表示されることはなく、EAP 以外のネットワーク プロトコルには表示されません。
1. Users: Human users are not expected to recognize these names as special or use them differently from other domain names. The use of these names in EAP is invisible to end users.
1. ユーザー: 人間のユーザーは、これらの名前を特別なものとして認識したり、他のドメイン名とは異なる方法で使用したりすることを期待されていません。EAP でのこれらの名前の使用はエンド ユーザーには見えません。
2. Application Software: EAP servers and clients are expected to make their software recognize these names as special and treat them differently. This document discusses that behavior. EAP peers should recognize these names as special and should refuse to allow users to enter them in any interface. EAP servers and RADIUS servers should recognize the eap.arpa. domain as special and refuse to do dynamic discovery ([RFC7585]) for it.
2. アプリケーションソフトウェア：EAPサーバーおよびクライアントは、ソフトウェアがこれらの名前を特別なものとして認識し、異なる方法で処理することを可能にすることが期待されます。本ドキュメントではその動作について説明します。EAPピアはこれらの名前を特別なものとして認識し、ユーザーがいかなるインターフェイスでもそれらを入力することを拒否すべきです（SHOULD）。EAPサーバーおよびRADIUSサーバーは、eap.arpa.ドメインを特別なものとして認識し、それに対する動的検出（[RFC7585]）の実行を拒否すべきです（SHOULD）。
3. Name Resolution APIs and Libraries: Writers of these APIs and libraries are not expected to recognize these names or treat them differently.
3. 名前解決 API およびライブラリ: これらの API およびライブラリの作成者は、これらの名前を認識したり、異なる方法で扱ったりすることは期待されていません。
4. Caching DNS Servers: Writers of caching DNS servers are not expected to recognize these names or treat them differently.
4. キャッシュ DNS サーバー: キャッシュ DNS サーバーの作成者は、これらの名前を認識したり、異なる方法で扱ったりすることは期待されていません。
5. Authoritative DNS Servers: Writers of authoritative DNS servers are not expected to recognize these names or treat them differently.
5. 権威 DNS サーバー: 権威 DNS サーバーの作成者は、これらの名前を認識したり、異なる方法で扱ったりすることは期待されていません。
6. DNS Server Operators: These domain names have minimal impact on DNS server operators. They should never be used in DNS or in any networking protocol outside of EAP.
6. DNS サーバー オペレーター: これらのドメイン名は、DNS サーバー オペレーターに最小限の影響を与えます。これらは、DNS や EAP 以外のネットワーク プロトコルでは決して使用しないでください。
Some DNS servers may receive lookups for this domain, if EAP or RADIUS servers are configured to do dynamic discovery for realms as defined in [RFC7585], and where those servers are not updated to ignore the .arpa domain. When queried for the eap.arpa. domain, DNS servers SHOULD return an NXDOMAIN error.
EAPまたはRADIUSサーバーが[RFC7585]で定義されているレルムの動的検出を行うように設定されており、それらのサーバーが.arpaドメインを無視するように更新されていない場合、一部のDNSサーバーがこのドメインのルックアップを受信することがあります。eap.arpa.ドメインを照会したとき、DNSサーバーはNXDOMAINエラーを返す必要があります（SHOULD）。
If they try to configure their authoritative DNS as authoritative for this reserved name, compliant name servers do not need to do anything special. They can accept the domain or reject it. Either behavior will have no impact on implementations of this specification.
権威 DNS をこの予約名に対する権威として構成しようとする場合、準拠ネーム サーバーは特別なことを行う必要はありません。ドメインを受け入れることも拒否することもできます。どちらの動作も、この仕様の実装には影響しません。
7. DNS Registries/Registrars: DNS Registries/Registrars should deny requests to register this reserved domain name.
7. DNS レジストリ/レジストラ: DNS レジストリ/レジストラは、この予約済みドメイン名の登録リクエストを拒否する必要があります。
IANA has added the following new registry to the "Extensible Authentication Protocol (EAP) Registry" registry group (see [EAPREG]).
IANA は、次の新しいレジストリを「Extensible Authentication Protocol (EAP) Registry」レジストリ グループに追加しました ([EAPREG] を参照)。
Assignments in this registry are made via "Expert Review" as described in [RFC8126], Section 4.5. Guidelines for experts are provided in Section 5.2.2.
このレジストリの割り当ては、[RFC8126] のセクション 4.5 に記載されている「専門家レビュー」を通じて行われます。専門家向けのガイドラインはセクション 5.2.2 に記載されています。
The registry format is as follows:
レジストリの形式は次のとおりです。
Title:
タイトル：
EAP Provisioning Identifiers
EAP プロビジョニング識別子
Registration Procedure(s):
登録手順:
Expert Review
専門家のレビュー
Reference:
参照：
RFC 9965
RFC 9965
NAI:
NAI:
The Network Access Identifier in the format described in [RFC7542].
[RFC7542] で説明されている形式のネットワーク アクセス識別子。
Method Type:
メソッドの種類:
The EAP method name, taken from the "Description" field of the "Method Types" registry (see [EAPREG]) .
EAP メソッド名。「メソッド タイプ」レジストリの「説明」フィールドから取得されます ([EAPREG] を参照)。
Reference:
参照：
Reference where this identifier was defined.
この識別子が定義された参照。
+=====================+=============+========================+
| NAI | Method Type | Reference |
+=====================+=============+========================+
| @noob.eap.arpa | EAP-NOOB | [RFC9140] and RFC 9965 |
+---------------------+-------------+------------------------+
| portal@tls.eap.arpa | EAP-TLS | [RFC9190] and RFC 9965 |
+---------------------+-------------+------------------------+
Table 1: Initial Values of the EAP Provisioning Identifiers Registry
表 1: EAP プロビジョニング識別子レジストリの初期値
The following text gives guidelines for designated experts who review allocation requests for the "EAP Provisioning Identifiers" registry.
次のテキストでは、「EAP プロビジョニング識別子」レジストリの割り当てリクエストをレビューする指定された専門家向けのガイドラインを示します。
The intent is for the NAI to describe both the EAP Method Type and the purpose of the provisioning method. A descriptive format allows administrators who are unfamiliar with a particular NAI to make reasonable deductions about the provisioning method being requested. For example, with an EAP Method Type "name" and a purpose "action", the NAI SHOULD be of the form "action@name.eap.arpa".
その目的は、NAI が EAP メソッド タイプとプロビジョニング メソッドの目的の両方を説明することです。記述形式により、特定の NAI に詳しくない管理者でも、要求されているプロビジョニング方法について合理的な推測を行うことができます。たとえば、EAP メソッド タイプが「name」、目的が「action」の場合、NAI は「action@name.eap.arpa」の形式である必要があります（SHOULD）。
The NAI MUST satisfy the requirements of the format in [RFC7542], Section 2.2. The utf8-username portion MAY be empty. The utf8-username portion MUST NOT be "anonymous". The NAI MUST be a subdomain within the eap.arpa realm. NAIs with any "v." subdomain MUST NOT be registered in order to preserve the functionality of that subdomain.
NAIは、[RFC7542]セクション2.2の形式の要件を満たさなければなりません（MUST）。utf8-username部分は空でも構いません。utf8-username部分は「anonymous」であってはなりません（MUST NOT）。NAIはeap.arpaレルム内のサブドメインでなければなりません（MUST）。「v.」サブドメインを持ついかなるNAIも、そのサブドメインの機能を維持するために登録してはなりません（MUST NOT）。
NAIs in the registry MUST NOT contain more than one subdomain. NAIs with a leading "v." subdomain MUST NOT be registered. That subdomain is reserved for vendor and SDO extensions.
レジストリ内の NAI には複数のサブドメインを含めてはなりません。先頭に「v」が付いた NAIサブドメインを登録してはなりません。このサブドメインは、ベンダーおよび SDO 拡張機能用に予約されています。
The subdomain of the NAI field should correspond to the EAP Method Type name. Care should be taken so that the domain name conventions specified in [STD13] are followed.
NAI フィールドのサブドメインは、EAP メソッド タイプ名に対応する必要があります。[STD13] で指定されているドメイン名規則に従うように注意する必要があります。
The NAIs in this registry are case-insensitive. While [RFC7542] notes that similar identifiers of different cases can be considered to be different, this registry requires that all entries MUST be lowercase for simplicity.
このレジストリ内の NAI では大文字と小文字が区別されません。[RFC7542] では、異なるケースの類似した識別子は異なるものとみなされる可能性があると述べていますが、このレジストリでは、簡単にするためにすべてのエントリが小文字でなければならないと要求しています。
Identifiers MUST be unique when compared in a case-insensitive fashion. While [RFC7542] notes that similar identifiers of different cases can be considered to be different, this registry is made simpler by requiring case-insensitivity.
大文字と小文字を区別せずに比較する場合、識別子は一意である必要があります。[RFC7542] では、異なるケースの類似した識別子は異なるものとみなされる可能性があると述べていますが、このレジストリは大文字と小文字を区別しないことを要求することにより簡素化されています。
Entries in the registry should be short. NAIs defined here will generally be sent in a RADIUS packet in the User-Name attribute ([RFC2865], Section 5.1). That specification recommends that implementations should support User-Names of at least 63 octets. NAI length considerations are further discussed in [RFC7542], Section 2.3, and any allocations in this registry need to take those limitations into consideration.
レジストリのエントリは短くする必要があります。ここで定義された NAI は通常、User-Name 属性の RADIUS パケットで送信されます ([RFC2865]、セクション 5.1)。この仕様では、実装で少なくとも 63 オクテットのユーザー名をサポートすることが推奨されています。NAI の長さに関する考慮事項は [RFC7542] のセクション 2.3 でさらに説明されており、このレジストリ内の割り当てではこれらの制限を考慮する必要があります。
Implementations are likely to support a total NAI length of 63 octets. Lengths between 63 and 253 octets may work. Lengths of 254 octets or more will not work with RADIUS [RFC2865].
実装では、NAI の合計長 63 オクテットがサポートされる可能性があります。63 ～ 253 オクテットの長さが機能する可能性があります。254 オクテット以上の長さは、RADIUS [RFC2865] では機能しません。
Values in the "Method Type" field of this registry MUST be taken from the "Method Types" registry (see [EAPREG]); otherwise, a value MUST be an Expanded Type, which usually indicates a vendor-specific EAP method.
このレジストリの「メソッド タイプ」フィールドの値は、「メソッド タイプ」レジストリから取得する必要があります ([EAPREG] を参照)。それ以外の場合、値は拡張タイプでなければならず、通常はベンダー固有の EAP メソッドを示します。
The EAP Method Type MUST provide a Master Session Key (MSK) and an Extended MSK (EMSK) as defined in [RFC3748]. Failure to provide these keys means that the Method Type will not be usable within an authentication framework that requires those methods, such as with [IEEE802.1X].
EAP メソッド タイプは、[RFC3748] で定義されているように、マスター セッション キー (MSK) と拡張 MSK (EMSK) を提供しなければなりません (MUST)。これらのキーを提供しないことは、[IEEE802.1X] などのこれらのメソッドを必要とする認証フレームワーク内でメソッド タイプが使用できないことを意味します。
The designated expert will post a request to the EAP Method Update (EMU) WG mailing list (or a successor designated by the Area Director) for comment and review, including an I-D or reference to an external specification. Before a period of 30 days has passed, the designated expert will either approve or deny the registration request and publish a notice of the decision to the EMU WG mailing list (or its successor) as well as inform IANA. A denial notice must be justified by an explanation; in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable should be provided.
指定された専門家は、I-D または外部仕様への参照を含む、コメントとレビューを求めるリクエストを EAP Method Update (EMU) WG メーリング リスト (またはエリア ディレクターが指定した後継者) に投稿します。30 日の期間が経過する前に、指定された専門家は登録要求を承認または拒否し、決定の通知を EMU WG メーリング リスト (またはその後継) に公開し、IANA に通知します。拒否通知は説明によって正当化されなければなりません。可能な場合には、受け入れられるようリクエストをどのように変更できるかについての具体的な提案を提供する必要があります。
The "EAP Provisioning Identifiers" registry allows organizations to request allocations from it, but explicit allocations are not always required. Any NAI defined in this registry also implicitly defines a subdomain "v.". Organizations can self-allocate in this space under the "v." subdomain, e.g., "local@example.com.v.tls.eap.arpa".
「EAP Provisioning Identifiers」レジストリを使用すると、組織はレジストリからの割り当てを要求できますが、明示的な割り当てが常に必要なわけではありません。このレジストリで定義された NAI は、暗黙的にサブドメイン「v.」も定義します。組織は、「v」の下のこのスペースに自己割り当てできます。サブドメイン、例: "local@example.com.v.tls.eap.arpa"。
The purpose of self-assigned realms is for testing and for future expansion. There are currently no use cases being envisioned for these realms, but we do not wish to forbid future expansion.
自己割り当てレルムの目的は、テストと将来の拡張です。現在、これらの領域で想定されているユースケースはありませんが、将来の拡張を禁止するつもりはありません。
An organization that has registered a Fully Qualified Domain Name (FQDN) within the DNS can use that name within the "v." subdomain.
DNS 内に完全修飾ドメイン名 (FQDN) を登録している組織は、その名前を「v」内で使用できます。サブドメイン。
As DNS registrations can change over time, an organization may stop using a domain at some point. This change is reflected in the DNS but is unlikely to be reflected in shipped products that use a self-assigned realm. There is no solution to this problem other than suggesting that organizations using self-assigned realms do not allow their DNS registrations to expire.
DNS 登録は時間の経過とともに変更される可能性があるため、組織はある時点でドメインの使用を停止する可能性があります。この変更は DNS に反映されますが、自己割り当てレルムを使用する出荷された製品には反映されない可能性があります。この問題に対する解決策は、自己割り当てレルムを使用している組織が DNS 登録の有効期限を切れないようにすることを提案すること以外にありません。
Therefore, it is RECOMMENDED that organizations avoid the use of self-assigned realms. Organizations MAY use self-assigned realms only when no other alternative exists and when the organization expects to maintain operation for at least the lifetime of the devices that use these realms.
したがって、組織は自己割り当てレルムの使用を避けることが推奨されます。組織は、他に代替手段が存在せず、少なくともこれらのレルムを使用するデバイスの存続期間中は運用を維持すると予想される場合にのみ、自己割り当てレルムを使用してもよい(MAY)。
The EAP Identity field is generally publicly visible to parties who can observe the EAP traffic. As the names given here are in a public specification, there is no privacy implication to exposing those names within EAP. In fact, the entire goal of this specification is to make those names public so that unknown (and private) parties can publicly (and anonymously) declare what kind of network access they desire.
EAP ID フィールドは通常、EAP トラフィックを観察できる関係者に公開されます。ここで指定されている名前は公開仕様に含まれているため、EAP 内でこれらの名前を公開してもプライバシーに影響はありません。実際、この仕様の全体的な目標は、これらの名前を公開して、未知の (および非公開の) 当事者がどのような種類のネットワーク アクセスを希望するかを公に (そして匿名で) 宣言できるようにすることです。
However, there are many additional privacy concerns around this specification. Most EAP traffic is sent over RADIUS [RFC2865]. The RADIUS Access-Request packets typically contain large amounts of information such as Media Access Control (MAC) addresses, device location, etc.
ただし、この仕様に関しては、さらに多くのプライバシー上の懸念があります。ほとんどの EAP トラフィックは RADIUS [RFC2865] 経由で送信されます。RADIUS Access-Request パケットには通常、メディア アクセス コントロール (MAC) アドレス、デバイスの場所などの大量の情報が含まれています。
This specification does not change RADIUS or EAP and, as such, does not change which information is publicly available or is kept private. Those issues are dealt with in other specifications, such as [INSECURE-RADIUS].
この仕様は RADIUS や EAP を変更するものではなく、したがってどの情報が公開されるか、または非公開にされるかは変更されません。これらの問題は、[INSECURE-RADIUS] などの他の仕様で扱われます。
However, this specification can increase privacy by allowing devices to anonymously obtain network access and then securely obtain credentials.
ただし、この仕様では、デバイスが匿名でネットワーク アクセスを取得し、資格情報を安全に取得できるようにすることで、プライバシーを強化できます。
The NAIs used here are contained in a public registry; therefore, they do not have to follow the username privacy recommendations of [RFC7542], Section 2.4. However, there may be other personally identifying information contained in EAP or AAA packets. This situation is no different from normal EAP authentication; thus, it has no additional positive or negative implications for privacy.
ここで使用される NAI は公開レジストリに含まれています。したがって、[RFC7542] セクション 2.4 のユーザー名プライバシーに関する推奨事項に従う必要はありません。ただし、EAP または AAA パケットには他の個人を特定する情報が含まれる場合があります。この状況は通常の EAP 認証と変わりません。したがって、プライバシーに対して追加のプラスまたはマイナスの影響はありません。
This specification defines a framework that permits unknown, anonymous, and unauthenticated devices to request and to obtain network access. As such, it is critical that network operators provide limited access to those devices.
この仕様は、未知、匿名、および認証されていないデバイスがネットワーク アクセスを要求および取得できるようにするフレームワークを定義します。したがって、ネットワーク オペレータがこれらのデバイスへのアクセスを制限することが重要です。
Future specifications that define an NAI within this registry, should give detailed descriptions of what kind of network access is to be provided.
このレジストリ内で NAI を定義する将来の仕様では、どのような種類のネットワーク アクセスが提供されるかについて詳細に説明する必要があります。
In most EAP use cases, the server identity is validated (usually through a certificate) or the EAP method allows the TLS tunnel to be cryptographically bound to the inner application data. For the methods outlined here, the use of public credentials and/or skipping server validation allows "on-path" attacks to succeed where they would normally fail.
ほとんどの EAP 使用例では、サーバー ID が (通常は証明書によって) 検証されるか、EAP メソッドによって TLS トンネルが内部アプリケーション データに暗号的にバインドされることが許可されます。ここで説明する方法では、公開資格情報の使用やサーバー検証のスキップにより、通常は失敗する「オンパス」攻撃が成功する可能性があります。
EAP peers and servers MUST assume that all data sent over an EAP session is visible to attackers and can be modified by them.
EAP ピアとサーバーは、EAP セッションを介して送信されるすべてのデータが攻撃者に可視であり、攻撃者によって変更される可能性があることを想定しなければなりません (MUST)。
The methods defined here MUST only be used to bootstrap initial network access. Once a device has been provisioned, it gains network access via the provisioned credentials and any network access policies can be applied.
ここで定義されたメソッドは、最初のネットワーク アクセスをブートストラップするためにのみ使用しなければなりません (MUST)。デバイスがプロビジョニングされると、プロビジョニングされた資格情報を介してネットワーク アクセスを取得し、任意のネットワーク アクセス ポリシーを適用できます。
This specification allows unauthenticated EAP peers to obtain network access, however limited. As with any unauthenticated process, this access can be abused. Implementations should take care to limit the use of the provisioning network.
この仕様により、認証されていない EAP ピアがネットワーク アクセスを取得できるようになりますが、制限はあります。他の非認証プロセスと同様に、このアクセスも悪用される可能性があります。実装では、プロビジョニング ネットワークの使用を制限するように注意する必要があります。
Section 3.4.2 describes a number of methods that can be used to secure the provisioning network. In summary:
セクション 3.4.2 では、プロビジョニング ネットワークを保護するために使用できるいくつかの方法について説明します。要約すれば：
* allow only traffic that is needed for the current provisioning method. All other traffic should be blocked. Most notable, DNS has been used to exfiltrate network traffic, so DNS recursive resolvers SHOULD NOT be made available on the provisioning network.
* 現在のプロビジョニング方法に必要なトラフィックのみを許可します。他のトラフィックはすべてブロックする必要があります。最も注目すべき点は、DNS がネットワーク トラフィックの抽出に使用されているため、DNS 再帰リゾルバーをプロビジョニング ネットワークで利用できるようにすべきではないということです。
* limit the services available on the provisioning network to only those services that are needed for provisioning.
* プロビジョニング ネットワーク上で利用可能なサービスを、プロビジョニングに必要なサービスのみに制限します。
* limit the number of devices that can access the provisioning network at the same time.
* プロビジョニング ネットワークに同時にアクセスできるデバイスの数を制限します。
* for any one device, rate limit its access to the provisioning network.
* 任意の 1 つのデバイスに対して、プロビジョニング ネットワークへのアクセスをレート制限します。
* for a device that has accessed the provisioning network, limit the total amount of time that it is allowed to remain on the network.
* プロビジョニング ネットワークにアクセスしたデバイスに対して、ネットワーク上に留まることが許可される合計時間を制限します。
* for a device that has accessed the provisioning network, limit the total amount of data that it is allowed to transfer through the network.
* プロビジョニング ネットワークにアクセスしたデバイスに対して、ネットワーク経由で転送できるデータの総量を制限します。
[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>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <https://www.rfc-editor.org/info/rfc5216>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC9140] Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band
Authentication for EAP (EAP-NOOB)", RFC 9140,
DOI 10.17487/RFC9140, December 2021,
<https://www.rfc-editor.org/info/rfc9140>.
[STD13] Internet Standard 13,
<https://www.rfc-editor.org/info/std13>.
At the time of writing, this STD comprises the following:
Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[ARPAREG] IANA, ".ARPA Zone Management",
<https://www.iana.org/domains/arpa>.
[CAB] CA/Browser Forum, "CA/Browser Forum",
<https://cabforum.org/>.
[EAPREG] IANA, "Extensible Authentication Protocol (EAP) Registry",
<https://www.iana.org/assignments/eap-numbers>.
[HOTSPOT] Wi-Fi Alliance, "Passpoint",
<https://www.wi-fi.org/discover-wi-fi/passpoint>.
[IEEE802.11u]
IEEE, "IEEE Standard for Information Technology -
Telecommunications and information exchange between
systems - Local and Metropolitan networks-specific
requirements - Part II: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) specifications: Amendment
9: Interworking with External Networks", IEEE Std 802.11u-
2011, DOI 10.1109/IEEESTD.2011.5721908, 2011,
<https://ieeexplore.ieee.org/document/5721908>.
[IEEE802.1X]
IEEE, "IEEE Standard for Local and metropolitan area
networks--Port-Based Network Access Control", IEEE Std
802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, 2020,
<https://ieeexplore.ieee.org/document/5409813>.
[INSECURE-RADIUS]
DeKok, A., "Deprecating Insecure Practices in RADIUS",
Work in Progress, Internet-Draft, draft-ietf-radext-
deprecating-radius-09, 15 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-
deprecating-radius-09>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication
Protocol (EAP) Authentication Using Only a Password",
RFC 5931, DOI 10.17487/RFC5931, August 2010,
<https://www.rfc-editor.org/info/rfc5931>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013,
<https://www.rfc-editor.org/info/rfc6761>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>.
[RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for
RADIUS/TLS and RADIUS/DTLS Based on the Network Access
Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October
2015, <https://www.rfc-editor.org/info/rfc7585>.
[RFC8952] Larose, K., Dolson, D., and H. Liu, "Captive Portal
Architecture", RFC 8952, DOI 10.17487/RFC8952, November
2020, <https://www.rfc-editor.org/info/rfc8952>.
[RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the
Extensible Authentication Protocol with TLS 1.3",
RFC 9190, DOI 10.17487/RFC9190, February 2022,
<https://www.rfc-editor.org/info/rfc9190>.
[RFC9810] Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
"Internet X.509 Public Key Infrastructure -- Certificate
Management Protocol (CMP)", RFC 9810,
DOI 10.17487/RFC9810, July 2025,
<https://www.rfc-editor.org/info/rfc9810>.
[RFC9930] DeKok, A., Ed., "Tunnel Extensible Authentication Protocol
(TEAP) Version 1", RFC 9930, DOI 10.17487/RFC9930,
February 2026, <https://www.rfc-editor.org/info/rfc9930>.
[SPECIAL-USE]
IANA, "Special-Use Domain Names",
<https://www.iana.org/assignments/special-use-domain-
names>.
Mohit Sethi provided valuable insight that using subdomains was better and more informative than the original method, which used only the utf8-username portion of the NAI.
Mohit Sethi は、NAI の utf8-username 部分のみを使用する元の方法よりも、サブドメインを使用する方が優れており、より有益であるという貴重な洞察を提供しました。
The document was further improved with reviews from Maria Ines Robles and Ben Kaduk.
この文書は、Maria Ines Robles と Ben Kaduk によるレビューによってさらに改善されました。
Alan DeKok
InkBridge Networks
Email: alan.dekok@inkbridge.io