[要約] RFC 9427 は、TLS 1.3 と組み合わせて使用するための EAP タイプを拡張することを目的としており、既存の EAP タイプを新しい鍵導出方法に更新し、TLS 1.3 に必要な追加変更を提供しています。
Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 9427 FreeRADIUS
Updates: 4851, 5281, 7170 June 2023
Category: Standards Track
ISSN: 2070-1721
The Extensible Authentication Protocol-TLS (EAP-TLS) (RFC 5216) has been updated for TLS 1.3 in RFC 9190. Many other EAP Types also depend on TLS, such as EAP-Flexible Authentication via Secure Tunneling (EAP-FAST) (RFC 4851), EAP-Tunneled TLS (EAP-TTLS) (RFC 5281), the Tunnel Extensible Authentication Protocol (TEAP) (RFC 7170). It is possible that many vendor-specific EAP methods, such as the Protected Extensible Authentication Protocol (PEAP), depend on TLS as well. This document updates those methods in order to use the new key derivation methods available in TLS 1.3. Additional changes necessitated by TLS 1.3 are also discussed.
拡張可能な認証プロトコル-TLS（EAP-TLS）（RFC 5216）は、RFC 9190のTLS 1.3について更新されています。4851）、EAPタンネルTLS（EAP-TTLS）（RFC 5281）、トンネル拡張可能な認証プロトコル（TEAP）（RFC 7170）。保護された拡張可能な認証プロトコル（PEAP）など、多くのベンダー固有のEAPメソッドもTLSに依存する可能性があります。このドキュメントは、TLS 1.3で利用可能な新しいキー派生方法を使用するために、これらのメソッドを更新します。TLS 1.3によって必要な追加の変更についても説明します。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc9427.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9427で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
2. Using TLS-Based EAP Methods with TLS 1.3
2.1. Key Derivation
2.2. TEAP
2.2.1. Client Certificates
2.3. EAP-FAST
2.3.1. Client Certificates
2.4. EAP-TTLS
2.4.1. Client Certificates
2.5. PEAP
2.5.1. Client Certificates
3. Application Data
3.1. Identities
4. Resumption
5. Security Considerations
5.1. Handling of TLS NewSessionTicket Messages
5.2. Protected Success and Failure Indications
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Author's Address
EAP-TLS has been updated for TLS 1.3 in [RFC9190]. Many other EAP Types also depend on TLS, such as EAP-FAST [RFC4851], EAP-TTLS [RFC5281], and TEAP [RFC7170]. It is possible that many vendor-specific EAP methods, such as PEAP [PEAP], depend on TLS as well. All of these methods use key derivation functions that are no longer applicable to TLS 1.3; thus, these methods are incompatible with TLS 1.3.
EAP-TLSは、[RFC9190]でTLS 1.3について更新されています。他の多くのEAPタイプは、EAP-FAST [RFC4851]、EAP-TTLS [RFC5281]、TEAP [RFC7170]などのTLSにも依存しています。PEAP [PEAP]などの多くのベンダー固有のEAPメソッドもTLSに依存する可能性があります。これらの方法はすべて、TLS 1.3に適用できなくなったキー導入関数を使用します。したがって、これらの方法はTLS 1.3と互換性がありません。
This document updates these methods in order to be used with TLS 1.3. These changes involve defining new key derivation functions. We also discuss implementation issues in order to highlight differences between TLS 1.3 and earlier versions of TLS.
このドキュメントは、TLS 1.3で使用するためにこれらの方法を更新します。これらの変更には、新しいキー派生関数の定義が含まれます。また、TLS 1.3とTLSの以前のバージョンの違いを強調するために、実装の問題についても説明します。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
In general, all of the requirements in [RFC9190] apply to other EAP methods that wish to use TLS 1.3. Unless otherwise required herein, implementations of EAP methods that wish to use TLS 1.3 MUST follow the guidelines in [RFC9190].
一般に、[RFC9190]のすべての要件は、TLS 1.3を使用したい他のEAPメソッドに適用されます。本明細書に特に要求されない限り、TLS 1.3を使用したいEAPメソッドの実装は、[RFC9190]のガイドラインに従う必要があります。
There remain some differences between EAP-TLS and other TLS-based EAP methods that are addressed by this document. The main difference is that [RFC9190] uses the EAP-TLS Type (value 0x0D) in a number of calculations, whereas other method types will use their own Type value instead of the EAP-TLS Type value. This topic is discussed further in Section 2.1.
このドキュメントで扱われるEAP-TLSと他のTLSベースのEAPメソッドの間には、いくつかの違いが残っています。主な違いは、[RFC9190]が多くの計算でEAP-TLSタイプ（値0x0D）を使用するのに対し、他のメソッドタイプはEAP-TLSタイプ値の代わりに独自のタイプ値を使用することです。このトピックについては、セクション2.1でさらに説明します。
An additional difference is that [RFC9190], Section 2.5 requires the EAP server to send a protected success result indication once the EAP-TLS handshake has completed. This indication is composed of one octet (0x00) of application data. Other TLS-based EAP methods also use this result indication, but only during resumption. When other TLS-based EAP methods use full authentication, the result indication is not needed or used. This topic is explained in more detail in Sections 3 and 4.
追加の違いは、[RFC9190]、セクション2.5では、EAP-TLSハンドシェイクが完了したら、EAPサーバーが保護された成功結果表示を送信する必要があることです。この適応症は、アプリケーションデータの1つのオクテット（0x00）で構成されています。他のTLSベースのEAPメソッドは、この結果表示も使用しますが、再開中にのみ使用します。他のTLSベースのEAPメソッドが完全な認証を使用している場合、結果の表示は必要または使用しません。このトピックについては、セクション3および4で詳しく説明します。
Finally, this document includes clarifications on how various TLS-based parameters are calculated when using TLS 1.3. These parameters are different for each EAP method, so they are discussed separately.
最後に、このドキュメントには、TLS 1.3を使用するときにさまざまなTLSベースのパラメーターがどのように計算されるかについての明確化が含まれています。これらのパラメーターはEAPメソッドごとに異なるため、個別に説明します。
The key derivation for TLS-based EAP methods depends on the value of the EAP Type as defined by [IANA] in the "Extensible Authentication Protocol (EAP) Registry". The most important definition is of the Type field, as first defined in [RFC3748], Section 2:
TLSベースのEAPメソッドの重要な導出は、「拡張可能な認証プロトコル（EAP）レジストリ」の[IANA]で定義されているEAPタイプの値に依存します。最も重要な定義は、[RFC3748]、セクション2で最初に定義されているように、タイプフィールドのものです。
Type = value of the EAP Method type
type = EAPメソッドタイプの値
For the purposes of this specification, when we refer to logical Type, we mean that the logical Type is defined as one octet for values smaller than 254 (the value for the Expanded Type). When Expanded EAP Types are used, the logical Type is defined as the concatenation of the fields required to define the Expanded Type, including the Type with value 0xfe, Vendor-Id (in network byte order), and Vendor-Type fields (in network byte order) defined in [RFC3748], Section 5.7, as given below:
この仕様の目的のために、論理タイプを参照する場合、論理タイプは254より小さい値（拡張型の値）の1オクテットとして定義されることを意味します。拡張されたEAPタイプを使用すると、論理タイプは、値0xfe、ベンダー-ID（ネットワークバイト順）、ベンダータイプのフィールドを含むタイプを含む拡張型タイプを定義するために必要なフィールドの連結として定義されます（ネットワーク内で）[RFC3748]、セクション5.7で定義されているバイト順）。
Type = 0xFE || Vendor-Id || Vendor-Type
This definition does not alter the meaning of Type in [RFC3748] or change the structure of EAP packets. Instead, this definition allows us to simplify references to EAP Types by using a logical "Type" instead of referring to "the Type field or the Type field with value 0xfe, plus the Vendor-ID and Vendor-Type". For example, the value of Type for PEAP is simply 0x19.
この定義は、[RFC3748]のタイプの意味を変更したり、EAPパケットの構造を変更したりしません。代わりに、この定義により、「型フィールドまたは値0xfeのタイプフィールド、さらにベンダーIDとベンダータイプのタイプフィールド」を参照する代わりに、論理的な「タイプ」を使用することにより、EAPタイプへの参照を簡素化できます。たとえば、PEAPのタイプの値は0x19です。
Note that unlike TLS 1.2 and earlier, the calculation of the TLS-Exporter function depends on the length passed to it. Therefore, implementations MUST pass the correct length instead of passing a large length and truncating the output. Any output calculated using a larger length value, which is then truncated, will be different from the output that was calculated using the correct length.
TLS 1.2以前とは異なり、TLS-Exporter関数の計算は、渡された長さに依存することに注意してください。したがって、実装は、大きな長さを通過して出力を切り捨てる代わりに、正しい長さを渡す必要があります。より大きな長さの値を使用して計算された出力は、その後切り捨てられますが、正しい長さを使用して計算された出力とは異なります。
Unless otherwise discussed below, the key derivation functions for all TLS-based EAP Types are defined in [RFC9190], Section 2.3 and reproduced here for clarity. These definitions include ones for the Master Session Key (MSK) and the Extended Master Session Key (EMSK):
以下に別段の説明がない場合を除き、すべてのTLSベースのEAPタイプの重要な導出関数は、[RFC9190]、セクション2.3で定義され、明確にするためにここで再現されています。これらの定義には、マスターセッションキー（MSK）および拡張マスターセッションキー（EMSK）の定義が含まれます。
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
Type, 128)
Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",
Type, 64)
Session-Id = Type || Method-Id
MSK = Key_Material(0, 63)
EMSK = Key_Material(64, 127)
We note that these definitions reuse the EAP-TLS exporter labels and change the derivation only by adding a dependency on the logical Type. The reason for this change is simplicity. The inclusion of the EAP Type makes the derivation method specific. There is no need to use different labels for different EAP Types as was done earlier.
これらの定義は、EAP-TLS輸出業者ラベルを再利用し、論理タイプに依存することによってのみ派生を変更することに注意してください。この変更の理由は簡単です。EAPタイプを含めると、派生方法が固有になります。以前に行われたように、異なるEAPタイプに異なるラベルを使用する必要はありません。
These definitions apply in their entirety to EAP-TTLS [RFC5281] and PEAP as defined in [PEAP] and [MSPEAP]. Some definitions apply to EAP-FAST and TEAP with exceptions as noted below.
これらの定義は、[PEAP]および[MSPEAP]で定義されているEAP-TTLS [RFC5281]およびPEAPに完全に適用されます。いくつかの定義は、以下に示すように例外を除いて、EAP-FASTおよびTEAPに適用されます。
It is RECOMMENDED that vendor-defined and TLS-based EAP methods use the above definitions for TLS 1.3. There is no compelling reason to use different definitions.
ベンダー定義およびTLSベースのEAPメソッドを使用することをお勧めします。TLS1.3の上記の定義を使用します。異なる定義を使用する説得力のある理由はありません。
TEAP previously used a Protected Access Credential (PAC), which is functionally equivalent to session tickets provided by TLS 1.3 that contain a pre-shared key (PSK) along with other data. As such, the use of a PAC is deprecated for TEAP in TLS 1.3. PAC provisioning, as defined in [RFC7170], Section 3.8.1, is also no longer part of TEAP when TLS 1.3 is used.
TEAPは以前、保護されたアクセス資格情報（PAC）を使用していました。これは、他のデータとともに事前共有キー（PSK）を含むTLS 1.3が提供するセッションチケットと機能的に同等です。そのため、TLS 1.3のTEAPに対してPACの使用は非推奨です。[RFC7170]で定義されているPACプロビジョニングは、TLS 1.3を使用すると、TEAPの一部ではなくなりました。
[RFC7170], Section 5.2 gives a definition for the Inner Method Session Key (IMSK), which depends on the TLS Pseudorandom Function (PRF) (also known as TLS-PRF). When the j'th inner method generates an EMSK, we update that definition for TLS 1.3 as:
[RFC7170]、セクション5.2は、TLS擬似ランダム関数（PRF）（TLS-PRFとも呼ばれる）に依存する内部メソッドセッションキー（IMSK）の定義を示しています。J'th Inner MethodがEMSKを生成すると、TLS 1.3の定義を次のように更新します。
IMSK[j] = TLS-Exporter("TEAPbindkey@ietf.org", secret, 32)
The secret is the EMSK or MSK from the j'th inner method. When an inner method does not provide an EMSK or MSK, IMSK[j] is 32 octets of zero.
秘密は、J'th Inner MethodのEMSKまたはMSKです。内側の方法がEMSKまたはMSKを提供しない場合、IMSK [J]はゼロの32オクテットです。
The other key derivations for TEAP are given here. All derivations not given here are the same as given above in the previous section. These derivations are also used for EAP-FAST, but using the EAP-FAST Type.
Teapの他の重要な派生物はここで説明されています。ここに記載されていないすべての派生物は、前のセクションで上記と同じです。これらの派生物は、EAP-FASTにも使用されますが、EAP-FASTタイプを使用します。
The derivation of the IMSKs, Inner Method Compound Keys (IMCKs), and Compound Session Keys (CMKs) is given below.
IMSK、内部メソッド化合物キー（IMCKS）、および複合セッションキー（CMK）の導出を以下に示します。
session_key_seed = TLS-Exporter("EXPORTER: teap session key seed",
Type, 40)
S-IMCK[0] = session_key_seed
For j = 1 to n-1 do
IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
S-IMCK[j-1] || IMSK[j], 60)
S-IMCK[j] = first 40 octets of IMCK[j]
CMK[j] = last 20 octets of IMCK[j]
Note: In these definitions, || denotes concatenation.
注：これらの定義では、||連結を示します。
In TLS 1.3, the derivation of IMCK[j] uses both a different label and a different order of concatenating fields than what was used by TEAP with TLS 1.2. Similarly, the session_key_seed in TLS 1.3 uses the Type as the context. In TLS 1.2, the context was a zero-length field.
TLS 1.3では、IMCK [j]の導出は、TLS 1.2でTEAPが使用したものとは異なるラベルと異なる順序の連結フィールドの両方を使用します。同様に、TLS 1.3のsession_key_seedは、タイプをコンテキストとして使用します。TLS 1.2では、コンテキストはゼロの長さのフィールドでした。
The outer MSK and EMSK are then derived from the final ("n"th) inner method, as follows:
次のように、外側のMSKとEMSKは、次のように、最終的な（ "n" th）内側の方法から派生します。
MSK = TLS-Exporter(
"EXPORTER: Session Key Generating Function",
S-IMCK[n], 64)
EMSK = TLS-Exporter(
"EXPORTER: Extended Session Key Generating Function",
S-IMCK[n], 64)
The TEAP Compound Message Authentication Code (MAC) defined in [RFC7170], Section 5.3 remains the same, but the MAC for TLS 1.3 is computed with the Hashed Message Authentication Code (HMAC) algorithm negotiated for the HMAC-based Key Derivation Function (HKDF) in the key schedule, as per [RFC8446], Section 7.1. That is, the MAC used is the MAC derived from the TLS handshake:
[RFC7170]で定義されているTEAPコンパウンドメッセージ認証コード（MAC）、セクション5.3は同じままですが、TLS 1.3のMACはHMACベースのキー派生関数（HKDF）[RFC8446]に従って、主要なスケジュールで、セクション7.1。つまり、使用されるMacは、TLSの握手から派生したMacです。
Compound-MAC = MAC( CMK[n], BUFFER )
where we define CMK[n] as the CMK taken from the final ("n"th) inner method.
ここで、CMK [n]をファイナル（ "n" th）内の方法から取得したCMKとして定義します。
For TLS 1.3, the MAC is computed with the HMAC algorithm negotiated for HKDF in the key schedule, as per [RFC8446], Section 7.1. That is, the MAC used is the MAC derived from the TLS handshake.
TLS 1.3の場合、MACは[RFC8446]、セクション7.1に従って、キースケジュールでHKDFと交渉されたHMACアルゴリズムで計算されます。つまり、使用されるMacは、TLSの握手から派生したMacです。
The definition of BUFFER is unchanged from [RFC7170], Section 5.3.
バッファーの定義は、[RFC7170]、セクション5.3から変更されていません。
The use of client certificates is still permitted when using TEAP with TLS 1.3. However, if the client certificate is accepted, then the EAP peer MUST proceed with additional authentication of Phase 2, as per [RFC7170], Section 7.6. If there is no Phase 2 data, then the EAP server MUST reject the session.
TLS 1.3でTEAPを使用する場合、クライアント証明書の使用は引き続き許可されています。ただし、クライアント証明書が受け入れられた場合、EAPピアは[RFC7170]、セクション7.6に従って、フェーズ2の追加認証を続行する必要があります。フェーズ2のデータがない場合、EAPサーバーはセッションを拒否する必要があります。
While [RFC5281], Section 7.6 permits "authentication of the client via client certificate during phase 1, with no additional authentication or information exchange required," this practice is forbidden when TEAP is used with TLS 1.3. If there is a requirement to use client certificates with no inner tunnel methods, then EAP-TLS should be used instead of TEAP.
[RFC5281]が、セクション7.6では、「フェーズ1の間にクライアント証明書を介してクライアントの認証を許可します。追加の認証または情報交換は必要ありません」と、TLS 1.3でTEAPを使用すると、このプラクティスは禁止されています。内部トンネルメソッドのないクライアント証明書を使用する必要がある場合は、TEAPの代わりにEAP-TLを使用する必要があります。
[RFC7170], Section 7.4.1 suggests that client certificates should be sent in Phase 2 of the TEAP exchange "since TLS client certificates are sent in the clear". While TLS 1.3 no longer sends client certificates in the clear, TEAP implementations need to distinguish identities for both User and Machine using the Identity-Type TLV (with values 1 and 2, respectively). When a client certificate is sent outside of the TLS tunnel, it MUST include Identity-Type as an outer TLV in order to signal the type of identity which that client certificate is for.
[RFC7170]、セクション7.4.1は、TLSクライアント証明書がClearで送信されるため、THEP Exchangeのフェーズ2でクライアント証明書を送信する必要があることを示唆しています。TLS 1.3はクライアント証明書を明確に送信しなくなりましたが、TEAP実装は、IDタイプTLV（それぞれ値1と2を使用）を使用して、ユーザーとマシンの両方のIDを区別する必要があります。クライアント証明書がTLSトンネルの外部で送信される場合、そのクライアント証明書が目的であるIDのタイプを信号するために、外部TLVとしてIDタイプを含める必要があります。
For EAP-FAST, the session_key_seed is also part of the key_block as defined in [RFC4851], Section 5.1.
EAP-FASTの場合、session_key_seedは[RFC4851]で定義されているKey_Blockの一部であるセクション5.1でもあります。
The definitions of S-IMCK[n], MSK, and EMSK are the same as given above for TEAP. We reiterate that the EAP-FAST Type must be used when deriving the session_key_seed and not the TEAP Type.
S-IMCK [n]、MSK、およびEMSKの定義は、TEAPの上記と同じです。TEAPタイプではなく、session_key_seedを導出するときにEAP-fastタイプを使用する必要があることを繰り返します。
Unlike [RFC4851], Section 5.2, the definition of IMCK[j] places the reference to S-IMCK after the textual label and then concatenates the IMSK instead of the MSK.
[RFC4851]、セクション5.2とは異なり、IMCK [J]の定義は、テキストラベルの後にS-IMCKへの参照を配置し、MSKの代わりにIMSKを連結します。
EAP-FAST previously used a PAC that is functionally equivalent to session tickets provided by TLS 1.3, which contain a PSK along with other data. As such, the use of a PAC is deprecated for EAP-FAST in TLS 1.3. PAC provisioning [RFC5422] is also no longer part of EAP-FAST when TLS 1.3 is used.
EAP-FASTは、以前にPACを使用していました。これは、TLS 1.3が提供するセッションチケットと機能的に同等のPACを使用していました。そのため、PACの使用は、TLS 1.3でEAP-FASTに対して非推奨です。PACプロビジョニング[RFC5422]も、TLS 1.3を使用する場合、EAP-FASTの一部ではなくなりました。
The T-PRF given in [RFC4851], Section 5.5 is not used for TLS 1.3. Instead, it is replaced with the TLS 1.3 TLS-Exporter function.
[RFC4851]に与えられたT-PRF、セクション5.5はTLS 1.3には使用されていません。代わりに、TLS 1.3 TLS-Exporter関数に置き換えられます。
The use of client certificates is still permitted when using EAP-FAST with TLS 1.3. However, if the client certificate is accepted, then the EAP peer MUST proceed with additional authentication of Phase 2, as per [RFC4851], Section 7.4.1. If there is no Phase 2 data, then the EAP server MUST reject the session.
TLS 1.3でEAP-FASTを使用する場合、クライアント証明書の使用は引き続き許可されています。ただし、クライアント証明書が受け入れられた場合、EAPピアは[RFC4851]、セクション7.4.1に従って、フェーズ2の追加認証を続行する必要があります。フェーズ2のデータがない場合、EAPサーバーはセッションを拒否する必要があります。
While [RFC4851] implicitly permits the use of client certificates without proceeding to Phase 2, this practice is forbidden when EAP-FAST is used with TLS 1.3. If there is a requirement to use client certificates with no inner tunnel methods, then EAP-TLS should be used instead of EAP-FAST.
[RFC4851]は、フェーズ2に進むことなくクライアント証明書の使用を暗黙的に許可しますが、EAP-FASTがTLS 1.3で使用される場合、このプラクティスは禁止されています。内部トンネルメソッドのないクライアント証明書を使用する必要がある場合は、EAP-FASTの代わりにEAP-TLを使用する必要があります。
[RFC5281], Section 11.1 defines an implicit challenge when the inner methods of the Challenge Handshake Authentication Protocol (CHAP) [RFC1994], MS-CHAP [RFC2433], or MS-CHAPv2 [RFC2759] are used. The derivation for TLS 1.3 is instead given as:
[RFC5281]、セクション11.1は、チャレンジハンドシェイク認証プロトコル（CHAP）[RFC1994]、MS-CHAP [RFC2433]、またはMS-CHAPV2 [RFC2759]の内部方法が使用される場合、暗黙の課題を定義します。TLS 1.3の派生は、代わりに次のように与えられます。
EAP-TTLS_challenge = TLS-Exporter("ttls challenge",, n)
There is no "context_value" ([RFC8446], Section 7.5) passed to the TLS-Exporter function. The value "n" given here is the length of the data required; [RFC5281] requires it to be 17 octets for CHAP ([RFC5281], Section 11.2.2) and MS-CHAPv2 ([RFC5281], Section 11.2.4), and 9 octets for MS-CHAP ([RFC5281], Section 11.2.3).
TLS-Exporter関数に渡された「Context_Value」（[RFC8446]、セクション7.5）はありません。ここで与えられる値「n」は、必要なデータの長さです。[RFC5281]では、チャップ（[RFC5281]、セクション11.2.2）およびMS-CHAPV2（[RFC5281]、セクション11.2.4）、およびMS-Chap（[RFC5281]、セクション11.2.2.2.2.2.2.2.2.2.2.2.2.2.2.2.2.2.2.2.4）の場合は17オクテットであることが必要です。.3）。
When the Password Authentication Protocol (PAP), CHAP, or MS-CHAPv1 are used as inner authentication methods, there is no opportunity for the EAP server to send a protected success indication, as is done in [RFC9190], Section 2.5. Instead, when TLS session tickets are disabled, the response from the EAP server MUST be either EAP-Success or EAP-Failure. These responses are unprotected and can be forged by a skilled attacker.
パスワード認証プロトコル（PAP）、CHAP、またはMS-CHAPV1が内部認証方法として使用される場合、[RFC9190]、セクション2.5で行われるように、EAPサーバーが保護された成功指標を送信する機会はありません。代わりに、TLSセッションチケットが無効になっている場合、EAPサーバーからの応答はEAPサクセスまたはEAPフェイルのいずれかでなければなりません。これらの応答は保護されておらず、熟練した攻撃者によって偽造される可能性があります。
Where TLS session tickets are enabled, the response from the EAP server may also continue TLS negotiation with a TLS NewSessionTicket message. Since this message is protected by TLS, it can serve as the protected success indication.
TLSセッションチケットが有効になっている場合、EAPサーバーからの応答は、TLS NewsessionTicketメッセージとのTLS交渉を継続することもできます。このメッセージはTLSによって保護されているため、保護された成功指示として機能します。
Therefore, it is RECOMMENDED that EAP servers always send a TLS NewSessionTicket message, even if resumption is not configured. When the EAP peer attempts to use the ticket, the EAP server can instead request a full authentication. As noted earlier, implementations SHOULD NOT send TLS NewSessionTicket messages until the "inner tunnel" authentication has completed in order to take full advantage of the message as a protected success indication.
したがって、再開が構成されていなくても、EAPサーバーは常にTLS NewsessionTicketメッセージを送信することをお勧めします。EAPピアがチケットを使用しようとする場合、EAPサーバーは代わりに完全な認証を要求できます。前述のように、実装は、「内部トンネル」認証が完了するまで、TLS NewsessionTicketメッセージを送信して、保護された成功指標としてメッセージを最大限に活用するために完了する必要があります。
When resumption is not used, the TLS NewSessionTicket message is not available and some authentication methods will not have a protected success indication. While we would like to always have a protected success indication, limitations of the underlying protocols, implementations, and deployment requirements make that impossible.
再開が使用されない場合、TLS NewsessionTicketメッセージは利用できず、一部の認証方法は保護された成功の兆候がありません。常に保護された成功の兆候を示したいと考えていますが、基礎となるプロトコル、実装、展開要件の制限はそれを不可能にします。
EAP peers MUST continue running their EAP state machine until they receive either an EAP-Success or an EAP-Failure. Receiving a TLS NewSessionTicket message in response to inner method PAP, CHAP, or MS-CHAP authentication is normal and MUST NOT be treated as a failure.
EAPピアは、EAPサクセスまたはEAPフェイルのいずれかを受け取るまで、EAPステートマシンを実行し続ける必要があります。PAP、CHAP、またはMS-Chap認証の内部に応じてTLS NewsessionTicketメッセージを受信することは正常であり、失敗として扱われてはなりません。
[RFC5281], Section 7.6 permits "authentication of the client via client certificate during phase 1, with no additional authentication or information exchange required." This practice is forbidden when EAP-TTLS is used with TLS 1.3. If there is a requirement to use client certificates with no inner tunnel methods, then EAP-TLS should be used instead of EAP-TTLS.
[RFC5281]、セクション7.6では、「フェーズ1の間にクライアント証明書を介してクライアントの認証を許可します。追加の認証または情報交換は必要ありません。」このプラクティスは、EAP-TTLSがTLS 1.3で使用される場合、禁止されています。内部トンネルメソッドのないクライアント証明書を使用する必要がある場合は、EAP-TTLSの代わりにEAP-TLを使用する必要があります。
The use of client certificates is still permitted when using EAP-TTLS with TLS 1.3. However, if the client certificate is accepted, then the EAP peer MUST proceed with additional authentication of Phase 2, as per [RFC5281], Section 7.2. If there is no Phase 2 data, then the EAP server MUST reject the session.
TLS 1.3でEAP-TTLSを使用する場合、クライアント証明書の使用は引き続き許可されています。ただし、クライアント証明書が受け入れられた場合、EAPピアは[RFC5281]、セクション7.2に従って、フェーズ2の追加認証を続行する必要があります。フェーズ2のデータがない場合、EAPサーバーはセッションを拒否する必要があります。
When PEAP uses crypto binding, it uses a different key calculation defined in [PEAP-MPPE] that consumes inner EAP method keying material. The PRF+ function used in [PEAP-MPPE] is not taken from the TLS exporter but is instead calculated via a different method that is given in [PEAP-PRF]. That derivation remains unchanged in this specification.
Peapが暗号結合を使用する場合、内部EAPメソッドキーイング材料を消費する[PEAP-MPPE]で定義された別のキー計算を使用します。[PEAP-MPPE]で使用されるPRF関数は、TLS輸出業者から取得されるのではなく、[PEAP-PRF]で与えられる別の方法で計算されます。この仕様では、その派生は変化しません。
Note that the above derivation uses SHA-1, which may be formally deprecated in the near future.
上記の派生はSHA-1を使用していることに注意してください。SHA-1は、近い将来に正式に廃止される可能性があることに注意してください。
However, the PRF+ calculation uses a PEAP Tunnel Key (TK), which is defined in [PEAP-TK] as:
ただし、PRF計算では、[PEAP-TK]で定義されているPEAPトンネルキー（TK）を使用します。
... the TK is the first 60 octets of the Key_Material, as specified in [RFC5216]: TLS-PRF-128 (master secret, "client EAP encryption", client.random || server.random).
... TKは、[rfc5216]で指定されているように、key_materialの最初の60オクテットです。
We note that the text in [PEAP-PRF] does not define Key_Material. Instead, it defines TK as the first octets of Key_Material and gives a definition of Key_Material that is appropriate for TLS versions before TLS 1.3.
[PEAP-PRF]のテキストはKey_Materialを定義していないことに注意してください。代わりに、TKをkey_materialの最初のオクテットとして定義し、TLS 1.3の前にTLSバージョンに適したkey_materialの定義を提供します。
For TLS 1.3, the TK should be derived from the Key_Material defined here in Section 2.1 instead of using the TLS-PRF-128 derivation given in [PEAP-PRF]. The method defined in [PEAP-TK] MUST NOT be used.
TLS 1.3の場合、TKは、[PEAP-PRF]で与えられたTLS-PRF-128派生を使用する代わりに、セクション2.1でここで定義されているkey_materialから導出する必要があります。[PEAP-TK]で定義されている方法は使用してはなりません。
As with EAP-TTLS, [PEAP] permits the use of client certificates in addition to inner tunnel methods. The practice of using client certificates with no "inner method" is forbidden when PEAP is used with TLS 1.3. If there is a requirement to use client certificates with no inner tunnel methods, then EAP-TLS should be used instead of PEAP.
EAP-TTLSと同様に、[PEAP]は、内部トンネルメソッドに加えてクライアント証明書の使用を許可します。PEAPがTLS 1.3で使用される場合、「内部方法」のないクライアント証明書を使用する慣行は禁止されています。内部トンネルメソッドのないクライアント証明書を使用する必要がある場合は、PEAPの代わりにEAP-TLを使用する必要があります。
The use of client certificates is still permitted when using PEAP with TLS 1.3. However, if the client certificate is accepted, then the EAP peer MUST proceed with additional authentication of the inner tunnel. If there is no inner tunnel authentication data, then the EAP server MUST reject the session.
TLS 1.3でPEAPを使用する場合、クライアント証明書の使用はまだ許可されています。ただし、クライアント証明書が受け入れられた場合、EAPピアは内部トンネルの追加認証を続行する必要があります。内部トンネル認証データがない場合、EAPサーバーはセッションを拒否する必要があります。
Unlike previous TLS versions, TLS 1.3 can continue negotiation after the initial TLS handshake has been completed; TLS 1.3 calls this the "CONNECTED" state. Some implementations use receipt of a Finished message as an indication that TLS negotiation has completed and that an "inner tunnel" session can now be negotiated. This assumption is not always correct with TLS 1.3.
以前のTLSバージョンとは異なり、TLS 1.3は、最初のTLSハンドシェイクが完了した後、交渉を継続できます。TLS 1.3はこれを「接続」状態と呼びます。一部の実装では、TLS交渉が完了し、「内部トンネル」セッションを交渉できることを示す兆候として、完成したメッセージの受信を使用します。この仮定は、TLS 1.3で常に正しいとは限りません。
Earlier TLS versions did not send application data along with the Finished message. It was then possible for implementations to assume that a receipt of a Finished message also meant that there was no application data available and that another round trip was required.
以前のTLSバージョンは、完成したメッセージとともにアプリケーションデータを送信しませんでした。その後、完成したメッセージの受領がアプリケーションデータが利用できず、別の往復が必要であることを意味することを実装することが可能になりました。
This assumption is not true with TLS 1.3, and applications relying on that behavior will not operate correctly with TLS 1.3.
この仮定はTLS 1.3では真実ではなく、その動作に依存するアプリケーションはTLS 1.3で正しく動作しません。
As a result, implementations MUST check for application data once the TLS session has been established. This check MUST be performed before proceeding with another round trip of TLS negotiation. TLS-based EAP methods, such as EAP-TTLS, PEAP, and EAP-FAST, each have method-specific application data that MUST be processed according to the EAP Type.
その結果、TLSセッションが確立されたら、実装はアプリケーションデータを確認する必要があります。このチェックは、TLS交渉の別の往復を進める前に実行する必要があります。EAP-TTLS、PEAP、EAP-FASTなどのTLSベースのEAPメソッドには、それぞれがEAPタイプに従って処理する必要があるメソッド固有のアプリケーションデータを持っています。
TLS 1.3 in [RFC8446], Section 4.6.1 also permits NewSessionTicket messages to be sent after the server has received the client Finished message, which is a change from earlier TLS versions. This change can cause implementations to fail in a number of different ways due to a reliance on implicit behavior seen in earlier TLS versions.
[RFC8446]のTLS 1.3、セクション4.6.1は、サーバーがクライアントの完成メッセージを受信した後にNewsessionTicketメッセージを送信することも許可しています。これは以前のTLSバージョンからの変更です。この変更により、以前のTLSバージョンで見られる暗黙の行動に依存しているため、実装がさまざまな方法で失敗する可能性があります。
In order to correct this failure, we require that implementations MUST NOT send or expect to receive application data in the TLS session if the underlying TLS connection is still performing negotiation. Implementations MUST delay processing of application data until such time as the TLS negotiation has finished. If the TLS negotiation is successful, then the application data can be examined. If the TLS negotiation is unsuccessful, then the application data is untrusted; therefore, it MUST be discarded without being examined.
この失敗を修正するために、基礎となるTLS接続がまだ交渉を実行している場合、実装はTLSセッションでアプリケーションデータを送信または期待しないでください。実装は、TLS交渉が終了するまでアプリケーションデータの処理を遅らせる必要があります。TLS交渉が成功した場合、アプリケーションデータを調べることができます。TLS交渉に失敗した場合、アプリケーションデータは信頼されません。したがって、検査されることなく廃棄する必要があります。
The default for many TLS library implementations is to send a NewSessionTicket message immediately after or along with the Finished message. This ticket could be used for resumption, even if the "inner tunnel" authentication has not been completed. If the ticket could be used, then it could allow a malicious EAP peer to completely bypass the "inner tunnel" authentication.
多くのTLSライブラリの実装のデフォルトは、完成したメッセージの直後またはそれと一緒にNewsessionTicketメッセージを送信することです。このチケットは、「内部トンネル」認証が完了していなくても、再開に使用できます。チケットを使用できれば、悪意のあるEAPピアが「内部トンネル」認証を完全にバイパスできるようになります。
Therefore, the EAP server MUST NOT permit any session ticket to successfully resume authentication unless the inner tunnel authentication has completed successfully. The alternative would allow an attacker to bypass authentication by obtaining a session ticket, immediately closing the current session, and "resuming" using the session ticket.
したがって、EAPサーバーは、内側のトンネル認証が正常に完了していない限り、セッションチケットが認証を正常に再開することを許可してはなりません。代替案により、攻撃者はセッションチケットを取得し、すぐに現在のセッションを閉じ、セッションチケットを使用して「再開」することにより、認証をバイパスできます。
To protect against that attack, implementations SHOULD NOT send NewSessionTicket messages until the "inner tunnel" authentication has completed. There is no reason to send session tickets that will later be invalidated or ignored. However, we recognize that this suggestion may not always be possible to implement with some available TLS libraries. As such, EAP servers MUST take care to either invalidate or discard session tickets that are associated with sessions that terminate in EAP Failure.
その攻撃から保護するために、実装は「内部トンネル」認証が完了するまでNewsessionTicketメッセージを送信してはなりません。後に無効または無視されるセッションチケットを送る理由はありません。ただし、この提案は、利用可能ないくつかのTLSライブラリを使用して常に実装できるとは限らないことを認識しています。そのため、EAPサーバーは、EAP障害で終了するセッションに関連付けられているセッションチケットを無効または破棄するように注意する必要があります。
The NewSessionTicket message SHOULD also be sent along with other application data, if possible. Sending that message alone prolongs the packet exchange to no benefit. In addition to prolonging the packet exchange, using a separate NewSessionTicket message can lead to non-interoperable implementations.
可能であれば、NewsessionTicketメッセージも他のアプリケーションデータとともに送信する必要があります。そのメッセージを単独で送信すると、パケット交換が延長されます。パケット交換の延長に加えて、個別のNewsessionTicketメッセージを使用すると、挿入不可能な実装につながる可能性があります。
[RFC9190], Section 2.5 requires a protected result indication, which indicates that TLS negotiation has finished. Methods that use "inner tunnel" methods MUST instead begin their "inner tunnel" negotiation by sending Type-specific application data.
[RFC9190]、セクション2.5では、TLS交渉が終了したことを示す保護された結果兆候が必要です。「内部トンネル」メソッドを使用する方法は、代わりに、型固有のアプリケーションデータを送信することにより、「内部トンネル」交渉を開始する必要があります。
For EAP-TLS, Sections 2.1.3 and 2.1.7 of [RFC9190] recommend the use of anonymous Network Access Identifiers (NAIs) [RFC7542] in the EAP Response/Identity packet. However, as EAP-TLS does not send application data inside of the TLS tunnel, that specification does not address the subject of "inner" identities in tunneled EAP methods. However, this subject must be addressed for the tunneled methods.
EAP-TLSの場合、[RFC9190]のセクション2.1.3および2.1.7は、EAP応答/IDパケットで匿名ネットワークアクセス識別子（NAIS）[RFC7542]を使用することを推奨しています。ただし、EAP-TLSはTLSトンネル内にアプリケーションデータを送信しないため、その仕様はトンネル付きEAPメソッドの「内部」アイデンティティの主題に対処しません。ただし、この主題は、トンネルされた方法について対処する必要があります。
Using an anonymous NAI for the outer identity as per [RFC7542], Section 2.4 has a few benefits. An NAI allows the EAP session to be routed in a AAA framework as described in [RFC7542], Section 3. Using an anonymous realm also ensures that user identifiers are kept private.
[RFC7542]に従って外側のアイデンティティに匿名NAIを使用すると、セクション2.4にはいくつかの利点があります。NAIを使用すると、[RFC7542]、セクション3で説明されているAAAフレームワークでEAPセッションをルーティングできます。匿名の領域を使用すると、ユーザー識別子がプライベートに保たれます。
As for the inner identity, we define it generically as the identification information carried inside of the TLS tunnel. For PEAP, that identity may be an EAP Response/Identity. For EAP-TTLS, it may be the User-Name attribute. Vendor-specific EAP methods that use TLS will generally also have an inner identity. This identity is carried inside of the TLS tunnel and is therefore both routed to the correct destination by the outer identity and kept private by the use of TLS.
内的アイデンティティについては、TLSトンネル内で携帯される識別情報として一般的に定義します。PEAPの場合、そのアイデンティティはEAP応答/アイデンティティである可能性があります。EAP-TTLSの場合、それはユーザー名属性かもしれません。TLSを使用するベンダー固有のEAPメソッドは、一般に内部のアイデンティティもあります。このアイデンティティはTLSトンネルの内側に運ばれているため、両方とも外側のアイデンティティによって正しい目的地にルーティングされ、TLSの使用によってプライベートに保たれます。
In other words, we can view the outer TLS layer of tunneled EAP methods as a secure transport layer that is responsible for getting the actual (inner) authentication credentials securely from the EAP peer to the EAP server. The EAP server then uses the inner identity and inner authentication data to identify and authenticate a particular user.
言い換えれば、トンネル付きEAPメソッドの外側TLS層を、実際の（内側の）認証資格情報をEAPピアからEAPサーバーにしっかりと取得する責任のある安全な輸送層として表示できます。EAPサーバーは、内部IDと内部認証データを使用して、特定のユーザーを識別および認証します。
As the authentication data is routed to the correct destination, there is little reason for the inner identity to also contain a realm. Therefore, we have a few recommendations on the inner and outer identities, along with their relationship to each other.
認証データは正しい宛先にルーティングされるため、内的アイデンティティにも領域を含める理由はほとんどありません。したがって、内側と外側のアイデンティティに関するいくつかの推奨事項と、互いに関係があります。
The outer identity SHOULD use an anonymous NAI realm that allows for both user privacy and for the EAP session to be routed in a AAA framework as described in [RFC7542], Section 3. Where NAI realms are not used, packets will not be routable outside of the local organization.
外側のアイデンティティは、[RFC7542]、セクション3で説明されているように、ユーザープライバシーとEAPセッションの両方をAAAフレームワークでルーティングできる匿名のNAIレルムを使用する必要があります。地元の組織の。
The inner identity MUST NOT use an anonymous NAI realm. If anonymous network access is desired, EAP peers MUST use EAP-TLS without peer authentication, as per [RFC9190], Section 2.1.5. EAP servers MUST cause authentication to fail if an EAP peer uses an anonymous "inner" identity for any TLS-based EAP method.
内面のアイデンティティは、匿名のnai領域を使用してはなりません。匿名のネットワークアクセスが必要な場合、EAPピアは[RFC9190]、セクション2.1.5に従って、ピア認証なしでEAP-TLSを使用する必要があります。EAPサーバーは、EAPピアがTLSベースのEAPメソッドに対して匿名の「内部」IDを使用する場合、認証を失敗させる必要があります。
Implementations SHOULD NOT use inner identities that contain an NAI realm. Many organizations typically use only one realm for all user accounts.
実装は、NAIレルムを含む内部のアイデンティティを使用しないでください。多くの組織は通常、すべてのユーザーアカウントに1つの領域のみを使用しています。
However, there are situations where it is useful for an inner identity to contain a realm. For example, an organization may have multiple independent sub-organizations, each with a different and unique realm. These realms may be independent of one another, or the realms may be a subdomain (or subdomains) of the public outer realm.
ただし、内的アイデンティティが領域を含めることが役立つ状況があります。たとえば、組織には複数の独立したサブ組織があり、それぞれが異なるユニークな領域を持つ場合があります。これらの領域は互いに独立している可能性があります。または、領域は、公共の外側の領域のサブドメイン（またはサブドメイン）である場合があります。
In that case, an organization can configure one public "routing" realm and multiple separate "inner" realms. This separation of realms also allows an organization to split users into logical groups by realm, where the "user" portion of the NAI may otherwise conflict. For example, "user@example.com" and "user@example.org" are different NAIs that can both be used as inner identities.
その場合、組織は、1つのパブリック「ルーティング」レルムと複数の個別の「内部」レルムを構成できます。また、このレルムの分離により、組織はユーザーを領域ごとに論理グループに分割することができます。そこでは、NAIの「ユーザー」部分が競合する可能性があります。たとえば、「user@example.com」と「user@example.org」は、両方とも内部のアイデンティティとして使用できる異なるNAISです。
Using only one public realm both keeps internal information private and simplifies realm management for external entities by minimizing the number of realms that have to be tracked by them.
1つの公共の領域のみを使用すると、内部情報をプライベートに保ち、それらが追跡する必要があるレルムの数を最小限に抑えることにより、外部エンティティのレルム管理を簡素化します。
In most situations, routing identifiers should be associated with the authentication data that they are routing. For example, if a user has an inner identity of "user@example.com", then it generally makes little sense to have an outer identity of "@example.org". The authentication request would then be routed to the "example.org" domain, which may have no idea what to do with the credentials for "user@example.com". At best, the authentication request would be discarded. At worst, the "example.org" domain could harvest user credentials for later use in attacks on "example.com".
ほとんどの状況では、ルーティング識別子は、ルーティングである認証データに関連付けられる必要があります。たとえば、ユーザーが「user@example.com」の内的アイデンティティを持っている場合、一般に「@example.org」の外側のアイデンティティを持つことはほとんど意味がありません。その後、認証要求は「embler.org」ドメインにルーティングされます。これは、「user@example.com」の資格情報をどうするかわからない場合があります。せいぜい、認証要求は破棄されます。最悪の場合、「Example.org」ドメインは、「Example.com」での攻撃で後で使用するためにユーザー資格情報を収集できます。
When an EAP server receives an inner identity for a realm which it is not authoritative, it MUST reject the authentication. There is no reason for one organization to authenticate users from a different (and independent) organization.
EAPサーバーが権威ではない領域に対して内部のアイデンティティを受信する場合、認証を拒否する必要があります。ある組織が異なる（および独立した）組織からユーザーを認証する理由はありません。
In addition, associating inner/outer identities from different organizations in the same EAP authentication session means that otherwise unrelated realms are tied together, which can make networks more fragile.
さらに、同じEAP認証セッションで異なる組織から内/外側のアイデンティティを関連付けることは、それ以外の場合は無関係な領域が結び付けられていることを意味し、ネットワークをより脆弱にすることができます。
For example, an organization that uses a "hosted" AAA provider may choose to use the realm of the AAA provider as the outer identity for user authentication. The inner identity can then be fully qualified: username plus realm of the organization. This practice may result in successful authentications, but it has practical difficulties.
たとえば、「ホストされた」AAAプロバイダーを使用する組織は、AAAプロバイダーの領域をユーザー認証の外部IDとして使用することを選択できます。その後、内的アイデンティティは、組織のユーザー名と領域を完全に適格にすることができます。このプラクティスは認証を成功させる可能性がありますが、実際的な困難があります。
Additionally, an organization may host their own AAA servers but use a "cloud" identity provider to hold user accounts. In that situation, the organizations could try to use their own realm as the outer (routing) identity and then use an identity from the "cloud" provider as the inner identity.
さらに、組織は独自のAAAサーバーをホストする場合がありますが、「クラウド」IDプロバイダーを使用してユーザーアカウントを保持します。そのような状況では、組織は自分の領域を外側（ルーティング）アイデンティティとして使用し、「クラウド」プロバイダーからのIDを内的アイデンティティとして使用しようとすることができます。
This practice is NOT RECOMMENDED. User accounts for an organization should be qualified as belonging to that organization and not to an unrelated third party. There is no reason to tie the configuration of user systems to public realm routing; that configuration more properly belongs in the network.
この慣行は推奨されません。組織のユーザーアカウントは、無関係なサードパーティではなく、その組織に属していると認定されるべきです。ユーザーシステムの構成をパブリックレルムルーティングに結び付ける理由はありません。その構成は、より適切にネットワークに属します。
Both of these practices mean that changing "cloud" providers is difficult. When such a change happens, each individual EAP peer must be updated with a different outer identity that points to the new "cloud" provider. This process can be expensive, and some EAP peers may not be online when this changeover happens. The result could be devices or users who are unable to obtain network access, even if all relevant network systems are online and functional.
これらのプラクティスはどちらも、「クラウド」プロバイダーを変更することが難しいことを意味します。このような変更が発生した場合、個々のEAPピアは、新しい「クラウド」プロバイダーを指す別の外側のアイデンティティで更新する必要があります。このプロセスは高価になる可能性があり、一部のEAPピアは、この切り替えが発生したときにオンラインではない場合があります。結果は、すべての関連するネットワークシステムがオンラインで機能的であっても、ネットワークアクセスを取得できないデバイスまたはユーザーになります。
Further, standards such as [RFC7585] allow for dynamic discovery of home servers for authentication. This specification has been widely deployed and means that there is minimal cost to routing authentication to a particular domain. The authentication can also be routed to a particular identity provider and changed at will with no loss of functionality. That specification is also scalable since it does not require changes to many systems when a domain updates its configuration. Instead, only one thing has to change: the configuration of that domain. Everything else is discovered dynamically.
さらに、[RFC7585]などの標準により、認証用のホームサーバーの動的な発見が可能になります。この仕様は広く展開されており、特定のドメインへの認証をルーティングするには最小限のコストがあることを意味します。認証は、特定のIDプロバイダーにルーティングされ、機能を損なうことなく自由に変更することもできます。ドメインが構成を更新する場合、多くのシステムの変更を必要としないため、その仕様もスケーラブルです。代わりに、変更する必要があるのは1つだけです。そのドメインの構成です。他のすべてが動的に発見されます。
That is, changing the configuration for one domain is significantly simpler and more scalable than changing the configuration for potentially millions of end-user devices.
つまり、1つのドメインの構成を変更することは、潜在的に数百万のエンドユーザーデバイスの構成を変更するよりもはるかに単純でスケーラブルです。
We recognize that there may be existing use cases where the inner and outer identities use different realms. As such, we cannot forbid that practice. We hope that the discussion above shows not only why such practices are problematic, but how alternative methods are more flexible, more scalable, and are easier to manage.
内側と外側のアイデンティティが異なる領域を使用する既存のユースケースがある可能性があることを認識しています。そのため、その練習を禁止することはできません。上記の議論が、そのようなプラクティスが問題になる理由だけでなく、代替方法がより柔軟で、よりスケーラブルで、管理が容易であることを示していることを願っています。
[RFC9190], Section 2.1.3 defines the process for resumption. This process is the same for all TLS-based EAP Types. The only practical difference is that the value of the Type field is different. The requirements on identities, use of TLS cipher suites, resumption, etc. remain unchanged from that document.
[RFC9190]、セクション2.1.3は、再開のプロセスを定義しています。このプロセスは、すべてのTLSベースのEAPタイプで同じです。唯一の実際的な違いは、タイプフィールドの値が異なることです。アイデンティティ、TLS暗号スイートの使用、再開などに関する要件は、そのドキュメントから変更されていません。
Note that if resumption is performed, then the EAP server MUST send the protected success result indication (one octet of 0x00) inside the TLS tunnel, as per [RFC9190]. The EAP peer MUST in turn check for the existence of the protected success result indication (one octet of 0x00) and cause authentication to fail if that octet is not received. If either the peer or the server initiates an inner tunnel method instead, then that method MUST be followed, and inner authentication MUST NOT be skipped.
再開が実行された場合、EAPサーバーは、[RFC9190]に従って、TLSトンネル内に保護された成功結果表示（0x00の1オクテット）を送信する必要があることに注意してください。EAPピアは、保護された成功結果の表示（0x00の1オクテット）の存在を順番にチェックし、そのオクテットが受信されない場合は認証が失敗する必要があります。ピアまたはサーバーのいずれかが代わりに内部トンネルメソッドを開始する場合、その方法に従う必要があり、内部認証をスキップしてはなりません。
All TLS-based EAP methods support resumption, as it is a property of the underlying TLS protocol. All EAP servers and peers MUST support resumption for all TLS-based EAP methods. We note that EAP servers and peers can still choose to not resume any particular session. For example, EAP servers may forbid resumption for administrative or other policy reasons.
すべてのTLSベースのEAPメソッドは、基礎となるTLSプロトコルの特性であるため、再開をサポートします。すべてのEAPサーバーとピアは、すべてのTLSベースのEAPメソッドの再開をサポートする必要があります。EAPサーバーとピアは、特定のセッションを再開しないことを選択できることに注意してください。たとえば、EAPサーバーは、管理またはその他の政策上の理由で再開を禁止する場合があります。
It is RECOMMENDED that EAP servers and peers enable resumption and use it where possible. The use of resumption decreases the number of round trips used for authentication. This decrease leads to lower latency for authentications and less load on the EAP server. Resumption can also lower load on external systems, such as databases that contain user credentials.
EAPサーバーとピアが再開を有効にし、可能な場合はそれを使用することをお勧めします。再開を使用すると、認証に使用される往復の数が減少します。この減少により、認証のレイテンシが低くなり、EAPサーバーの負荷が少なくなります。また、ユーザーの資格情報を含むデータベースなど、外部システムの負荷が低下する可能性があります。
As the packet flows for resumption are essentially identical across all TLS-based EAP Types, it is technically possible to authenticate using EAP-TLS (Type 13) and then perform resumption using another EAP Type, such as with EAP-TTLS (Type 21). However, there is no practical benefit to doing so. It is also not clear what this behavior would mean or what (if any) security issues there may be with it. As a result, this behavior is forbidden.
再開のパケットフローはすべてのTLSベースのEAPタイプで本質的に同一であるため、EAP-TLS（タイプ13）を使用して認証し、EAP-TTLSなどの別のEAPタイプを使用して再開を実行することができます（タイプ21）。ただし、そうすることには実際的な利点はありません。また、この動作が何を意味するのか、または（もしあれば）セキュリティの問題がそれにある可能性があることは明らかではありません。その結果、この動作は禁止されています。
EAP servers therefore MUST NOT resume sessions across different EAP Types, and EAP servers MUST reject resumptions in which the EAP Type value is different from the original authentication.
したがって、EAPサーバーは、さまざまなEAPタイプにわたってセッションを再開してはなりません。EAPサーバーは、EAPタイプの値が元の認証とは異なる想像を拒否する必要があります。
[RFC9190], Section 5 is included here by reference.
[RFC9190]、セクション5は参照によりここに含まれています。
Updating the above EAP methods to use TLS 1.3 is of high importance for the Internet community. Using the most recent security protocols can significantly improve security and privacy of a network.
上記のEAPメソッドを更新してTLS 1.3を使用することは、インターネットコミュニティにとって非常に重要です。最新のセキュリティプロトコルを使用すると、ネットワークのセキュリティとプライバシーを大幅に改善できます。
For PEAP, some derivations use HMAC-SHA1 [PEAP-MPPE]. In the interests of interoperability and minimal changes, we do not change that derivation, as there are no known security issues with HMAC-SHA1. Further, the data derived from the HMAC-SHA1 calculations is exchanged inside of the TLS tunnel and is visible only to users who have already successfully authenticated. As such, the security risks are minimal.
PEAPの場合、一部の派生物はHMAC-SHA1 [PEAP-MPPE]を使用します。相互運用性と最小限の変更のために、HMAC-Sha1には既知のセキュリティの問題がないため、その派生は変化しません。さらに、HMAC-SHA1計算から派生したデータはTLSトンネル内で交換され、すでに正常に認証されているユーザーにのみ表示されます。そのため、セキュリティリスクは最小限です。
In some cases, client certificates are not used for TLS-based EAP methods. In those cases, the user is authenticated only after successful completion of the inner tunnel authentication. However, [RFC8446], Section 4.6.1 states that "at any time after the server has received the client Finished message, it MAY send a NewSessionTicket message." This message is sent by the server before the inner authentication method has been run and therefore before the user has been authenticated.
場合によっては、クライアント証明書はTLSベースのEAPメソッドには使用されません。そのような場合、ユーザーは内部トンネル認証が正常に完了した後にのみ認証されます。ただし、[RFC8446]、セクション4.6.1は、「サーバーが終了したメッセージを受信した後いつでも、NewsessionTicketメッセージを送信する可能性がある」と述べています。このメッセージは、内部認証メソッドが実行される前にサーバーによって送信されるため、ユーザーが認証される前に送信されます。
This separation of data allows for a "time of use, time of check" security issue. Malicious clients can begin a session and receive a NewSessionTicket message. The malicious client can then abort the authentication session and use the obtained NewSessionTicket to "resume" the previous session. If the server allows the session to resume without verifying that the user had first been authenticated, the malicious client can then obtain network access without ever being authenticated.
このデータの分離により、「使用時間、チェック時間」セキュリティの問題が可能になります。悪意のあるクライアントはセッションを開始し、NewsessionTicketメッセージを受信できます。悪意のあるクライアントは、認証セッションを中止し、取得したNewsessionTicketを使用して前のセッションを「再開」することができます。ユーザーが最初に認証されたことを確認せずにサーバーがセッションを再開できる場合、悪意のあるクライアントは、認証されることなくネットワークアクセスを取得できます。
As a result, EAP servers MUST NOT assume that a user has been authenticated simply because a TLS session is being resumed. Even if a session is being resumed, an EAP server MAY have policies that still force the inner authentication methods to be run. For example, the user's password may have expired in the time interval between first authentication and session resumption.
その結果、EAPサーバーは、TLSセッションが再開されているという理由だけで、ユーザーが認証されていると想定してはなりません。セッションが再開されていても、EAPサーバーには、内部認証方法が実行されるように強制されるポリシーがある場合があります。たとえば、ユーザーのパスワードは、最初の認証とセッションの再開の間の時間間隔で有効になっている可能性があります。
Therefore, the guidelines given here describe situations where an EAP server is permitted to allow session resumption rather than where an EAP server is required to allow session resumption. An EAP server could simply refuse to issue session tickets or could run the full inner authentication, even if a session was resumed.
したがって、ここで与えられるガイドラインでは、EAPサーバーがセッション再開を許可するために必要な場合ではなく、セッション再開を許可される状況を説明しています。EAPサーバーは、セッションが再開されたとしても、セッションチケットの発行を拒否したり、完全な内部認証を実行することもできます。
Where session tickets are used, the EAP server SHOULD track the successful completion of an inner authentication and associate that status with any session tickets issued for that session. This requirement can be met in a number of different ways.
セッションチケットが使用される場合、EAPサーバーは内部認証の正常な完了を追跡し、そのステータスをそのセッションで発行されたセッションチケットと関連付ける必要があります。この要件は、さまざまな方法で満たすことができます。
One way is for the EAP server to simply not send any TLS NewSessionTicket messages until the inner authentication has completed successfully. The EAP server then knows that the existence of a session ticket is proof that a user was authenticated, and the session can be resumed.
1つの方法は、EAPサーバーが、内部認証が正常に完了するまでTLS NewsessionTicketメッセージを単に送信しないことです。EAPサーバーは、セッションチケットの存在がユーザーが認証され、セッションを再開できることの証拠であることを知っています。
Another way is for the EAP server to simply discard or invalidate any session tickets until after the inner authentication has completed successfully. When the user is authenticated, a new TLS NewSessionTicket message can be sent to the client, and the new ticket can be cached and/or validated.
別の方法は、EAPサーバーが、内部認証が正常に完了するまで、セッションチケットを単純に破棄または無効にすることです。ユーザーが認証されると、新しいTLS NewsessionTicketメッセージをクライアントに送信でき、新しいチケットをキャッシュおよび/または検証できます。
Another way is for the EAP server to associate the inner authentication status with each session ticket. When a session ticket is used, the authentication status is checked. When a session ticket shows that the inner authentication did not succeed, the EAP server MUST run the inner authentication method(s) in the resumed tunnel and only grant access based on the success or failure of those inner methods.
別の方法は、EAPサーバーが各セッションチケットに内部認証ステータスを関連付けることです。セッションチケットを使用すると、認証ステータスがチェックされます。セッションチケットが内部認証が成功しなかったことを示した場合、EAPサーバーは再開されたトンネルで内部認証方法を実行し、それらの内部方法の成功または失敗に基づいてのみ付与アクセスを付与する必要があります。
However, the interaction between EAP implementations and any underlying TLS library may be complex, and the EAP server may not be able to make the above guarantees. Where the EAP server is unable to determine the user's authentication status from the session ticket, it MUST assume that inner authentication has not completed, and it MUST run the inner authentication method(s) successfully in the resumed tunnel before granting access.
ただし、EAP実装と基礎となるTLSライブラリとの間の相互作用は複雑である可能性があり、EAPサーバーは上記の保証を作成できない場合があります。EAPサーバーがセッションチケットからユーザーの認証ステータスを決定できない場合、内部認証が完了していないと仮定する必要があり、アクセスを付与する前に再開されたトンネルで内部認証方法を正常に実行する必要があります。
This issue is not relevant for EAP-TLS, which only uses client certificates for authentication in the TLS handshake. It is only relevant for TLS-based EAP methods that do not use the TLS layer to authenticate.
この問題は、TLSハンドシェイクの認証にクライアント証明書のみを使用するEAP-TLSには関係ありません。TLSベースのEAPメソッドには、TLSレイヤーを使用して認証されていないことにのみ関連しています。
[RFC9190] provides for protected success and failure indications as discussed in [RFC4137], Section 4.1.1. These result indications are provided for both full authentication and resumption.
[RFC9190]は、[RFC4137]、セクション4.1.1で説明されているように、保護された成功と失敗の適応を提供します。これらの結果の表示は、完全な認証と再開の両方に提供されます。
Other TLS-based EAP methods provide these result indications only for resumption.
他のTLSベースのEAPメソッドは、これらの結果を再開するためのみを提供します。
For full authentication, the other TLS-based EAP methods do not provide for protected success and failure indications as part of the outer TLS exchange. That is, the protected result indication is not used, and there is no TLS-layer alert sent when the inner authentication fails. Instead, there is simply either an EAP-Success or an EAP-Failure sent. This behavior is the same as for previous TLS versions; therefore, it introduces no new security issues.
完全な認証のために、他のTLSベースのEAPメソッドは、外部TLS交換の一部として保護された成功と失敗の適応を提供しません。つまり、保護された結果兆候は使用されず、内部認証が失敗したときにTLSレイヤーアラートは送信されません。代わりに、EAP-SUCSESSまたはEAP-FAILUREが送信されるだけです。この動作は、以前のTLSバージョンの場合と同じです。したがって、新しいセキュリティの問題は導入されません。
We note that most TLS-based EAP methods provide for success and failure indications as part of the authentication exchange performed inside of the TLS tunnel. These result indications are therefore protected, as they cannot be modified or forged.
TLSベースのEAPメソッドのほとんどは、TLSトンネル内で実行される認証交換の一部として、成功と失敗の適応を提供することに注意してください。したがって、これらの結果の適応症は、変更または偽造できないため、保護されています。
However, some inner methods do not provide for success or failure indications. For example, the use of EAP-TTLS with inner PAP, CHAP, or MS-CHAP. Those methods send authentication credentials to the EAP server via the inner tunnel with no method to signal success or failure inside of the tunnel.
ただし、一部の内部方法では、成功や失敗の兆候を提供しません。たとえば、内側のPAP、CHAP、またはMS-Chapを使用したEAP-TTLSの使用。これらのメソッドは、トンネル内で成功または障害を示す方法なしで、内部トンネルを介して認証資格情報をEAPサーバーに送信します。
There are functionally equivalent authentication methods that can be used to provide protected result indications. PAP can often be replaced with EAP-GTC, CHAP with EAP-MD5, and MS-CHAPv1 with MS-CHAPv2 or EAP-MSCHAPv2. All of the replacement methods provide for similar functionality and have protected success and failure indication. The main cost to this change is additional round trips.
保護された結果の表示を提供するために使用できる機能的に同等の認証方法があります。PAPは、多くの場合、EAP-GTC、EAP-MD5でCHAP、MS-CHAPV2またはEAP-MSCHAPV2でMS-CHAPV1に置き換えることができます。交換方法はすべて、同様の機能を提供し、成功と失敗の兆候を保護しています。この変更の主なコストは、追加の往復です。
It is RECOMMENDED that implementations deprecate inner tunnel methods that do not provide protected success and failure indications when TLS session tickets cannot be used. Implementations SHOULD use EAP-GTC instead of PAP and EAP-MD5 instead of CHAP. Implementations SHOULD use MS-CHAPv2 or EAP-MSCHAPv2 instead of MS-CHAPv1. New TLS-based EAP methods MUST provide protected success and failure indications inside of the TLS tunnel.
TLSセッションチケットを使用できない場合に、保護された成功と失敗の適応症を提供しない内部トンネルメソッドを控除することをお勧めします。実装では、PAPおよびEAP-MD5の代わりにchapの代わりにEAP-GTCを使用する必要があります。実装では、MS-Chapv1の代わりにMS-Chapv2またはEAP-MSCHAPV2を使用する必要があります。新しいTLSベースのEAPメソッドは、TLSトンネル内で保護された成功と失敗の表示を提供する必要があります。
When the inner authentication protocol indicates that authentication has failed, then implementations MUST fail authentication for the entire session. There may be additional protocol exchanges in order to exchange more detailed failure indications, but the final result MUST be a failed authentication. As noted earlier, any session tickets for this failed authentication MUST be either invalidated or discarded.
内部認証プロトコルが認証が失敗したことを示した場合、実装はセッション全体の認証を失敗する必要があります。より詳細な障害の表示を交換するために、追加のプロトコル交換があるかもしれませんが、最終結果は認証の失敗でなければなりません。前述のように、この失敗した認証のセッションチケットは、無効または破棄される必要があります。
Similarly, when the inner authentication protocol indicates that authentication has succeeded, implementations SHOULD cause authentication to succeed for the entire session. There MAY be additional protocol exchanges that could still cause failure, so we cannot mandate sending success on successful authentication.
同様に、内部認証プロトコルが認証が成功したことを示した場合、実装はセッション全体で認証を成功させるはずです。依然として障害を引き起こす可能性のある追加のプロトコル交換がある可能性があるため、成功した認証で成功を送信することを義務付けることはできません。
In both of these cases, the EAP server MUST send an EAP-Failure or EAP-Success message, as indicated by Step 4 in Section 2 of [RFC3748]. Even though both parties have already determined the final authentication status, the full EAP state machine must still be followed.
これらの両方のケースでは、EAPサーバーは、[RFC3748]のセクション2でステップ4で示されるように、EAPフェイルまたはEAPサクセスメッセージを送信する必要があります。両当事者はすでに最終認証ステータスを決定していますが、完全なEAP状態マシンにまだ従う必要があります。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding the registration of values related to the TLS-based EAP methods for the TLS 1.3 protocol in accordance with [RFC8126].
このセクションでは、[RFC8126]に従って、TLS 1.3プロトコルのTLSベースのEAPメソッドに関連する値の登録に関するインターネットに割り当てられた番号局（IANA）にガイダンスを提供します。
IANA has added the following labels to the "TLS Exporter Label" registry defined by [RFC5705]. These labels are used in the derivation of Key_Material and Method-Id as defined above in Section 2, and they are used only for TEAP.
IANAは、[RFC5705]で定義された「TLS Exporterラベル」レジストリに次のラベルを追加しました。これらのラベルは、セクション2で上記で定義されているように、key_materialとmethod-idの派生に使用され、teapにのみ使用されます。
+============================+=========+=============+===========+
| Value | DTLS-OK | Recommended | Reference |
+============================+=========+=============+===========+
| EXPORTER: teap session key | N | Y | RFC 9427 |
| seed | | | |
+----------------------------+---------+-------------+-----------+
| EXPORTER: Inner Methods | N | Y | RFC 9427 |
| Compound Keys | | | |
+----------------------------+---------+-------------+-----------+
| EXPORTER: Session Key | N | Y | RFC 9427 |
| Generating Function | | | |
+----------------------------+---------+-------------+-----------+
| EXPORTER: Extended Session | N | Y | RFC 9427 |
| Key Generating Function | | | |
+----------------------------+---------+-------------+-----------+
| TEAPbindkey@ietf.org | N | Y | RFC 9427 |
+----------------------------+---------+-------------+-----------+
Table 1: TLS Exporter Labels Registry
表1：TLS Exporter Labelsレジストリ
[IANA] IANA, "Method Types",
<https://www.iana.org/assignments/eap-numbers/>.
[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>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>.
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[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>.
[MSPEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP)", Protocol Revision 31.0,
June 2021,
<https://msdn.microsoft.com/en-us/library/cc238354.aspx>.
[PEAP] Palekar, A., Josefsson, S., Simon, D., Zorn, G., Salowey,
J., and H. Zhou, "Protected EAP Protocol (PEAP) Version
2", Work in Progress, Internet-Draft, draft-josefsson-
pppext-eap-tls-eap-10, 15 October 2004,
<https://datatracker.ietf.org/doc/html/draft-josefsson-
pppext-eap-tls-eap-10>.
[PEAP-MPPE]
Microsoft Corporation, "Key Management", Section 3.1.5.7,
October 2020, <https://learn.microsoft.com/en-
us/openspecs/windows_protocols/ms-peap/e75b0385-915a-
4fc3-a549-fd3d06b995b0>.
[PEAP-PRF] Microsoft Corporation, "Intermediate PEAP MAC Key (IPMK)
and Compound MAC Key (CMK)", Section 3.1.5.5.2.2, February
2019, <https://docs.microsoft.com/en-
us/openspecs/windows_protocols/MS-PEAP/0de54161-0bd3-424a-
9b1a-854b4040a6df>.
[PEAP-TK] Microsoft Corporation, "PEAP Tunnel Key (TK)",
Section 3.1.5.5.2.1, April 2021,
<https://docs.microsoft.com/en-
us/openspecs/windows_protocols/MS-PEAP/41288c09-3d7d-482f-
a57f-e83691d4d246>.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, DOI 10.17487/RFC1994, August
1996, <https://www.rfc-editor.org/info/rfc1994>.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, DOI 10.17487/RFC2433, October 1998,
<https://www.rfc-editor.org/info/rfc2433>.
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
RFC 2759, DOI 10.17487/RFC2759, January 2000,
<https://www.rfc-editor.org/info/rfc2759>.
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
"State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator", RFC 4137,
DOI 10.17487/RFC4137, August 2005,
<https://www.rfc-editor.org/info/rfc4137>.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851,
DOI 10.17487/RFC4851, May 2007,
<https://www.rfc-editor.org/info/rfc4851>.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
DOI 10.17487/RFC5281, August 2008,
<https://www.rfc-editor.org/info/rfc5281>.
[RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou,
"Dynamic Provisioning Using Flexible Authentication via
Secure Tunneling Extensible Authentication Protocol (EAP-
FAST)", RFC 5422, DOI 10.17487/RFC5422, March 2009,
<https://www.rfc-editor.org/info/rfc5422>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.
[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>.
Thanks to Jorge Vergara for a detailed review of the requirements for various EAP Types.
さまざまなEAPタイプの要件の詳細なレビューをしてくれたJorge Vergaraに感謝します。
Thanks to Jorge Vergara, Bruno Periera Vidal, Alexander Clouter, Karri Huhtanen, and Heikki Vatiainen for reviews of this document and for assistance with interoperability testing.
Jorge Vergara、Bruno Periera Vidal、Alexander Clouter、Karri Huhtanen、およびHeikki Vatiainenに感謝し、この文書のレビューと相互運用性テストの支援について。
Alan DeKok
The FreeRADIUS Server Project
Email: aland@freeradius.org