[要約] この文書は、トンネル拡張認証プロトコル (TEAP) バージョン 1 を定義しています。TLSを使用して安全なトンネルを確立し、その中で認証データをTLV形式でやり取りするトンネルベースのEAP方式です。本仕様は RFC 7170 を廃止し RFC 9427 を更新するもので、ベンダー固有ではない標準化トラックのプロトコルを提供します。
Internet Engineering Task Force (IETF) A. DeKok, Ed.
Request for Comments: 9930 February 2026
Obsoletes: 7170
Updates: 9427
Category: Standards Track
ISSN: 2070-1721
This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. This document obsoletes RFC 7170 and updates RFC 9427 by moving all TEAP specifications from those documents to this one.
この文書では、トンネル拡張認証プロトコル (TEAP) バージョン 1 を定義します。 TEAP は、トランスポート層セキュリティ (TLS) プロトコルを使用して相互認証されたトンネルを確立することにより、ピアとサーバー間の安全な通信を可能にするトンネルベースの EAP 方式です。トンネル内では、TLV オブジェクトを使用して、EAP ピアと EAP サーバーの間で認証関連のデータを伝達します。この文書は RFC 7170 を廃止し、すべての TEAP 仕様をそれらの文書からこの文書に移動することで RFC 9427 を更新します。
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/rfc9930.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9930 で入手できます。
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. Interoperability Issues
1.2. Requirements Language
1.3. Terminology
2. Protocol Overview
2.1. Architectural Model
2.2. Protocol-Layering Model
2.3. Outer TLVs Versus Inner TLVs
3. TEAP Protocol
3.1. Version Negotiation
3.2. TEAP Authentication Phase 1: Tunnel Establishment
3.3. Server Certificate Requirements
3.4. Server Certificate Validation
3.4.1. Client Certificates Sent During Phase 1
3.5. Resumption
3.5.1. TLS Session Resumption Using Server State
3.5.2. TLS Session Resumption Using Client State
3.6. TEAP Authentication Phase 2: Tunneled Authentication
3.6.1. Inner Method Ordering
3.6.2. Inner EAP Authentication
3.6.3. Inner Password Authentication
3.6.4. EAP-MSCHAPv2
3.6.5. Limitations on Inner Methods
3.6.6. Protected Termination and Acknowledged Result
Indication
3.7. Determining Peer-Id and Server-Id
3.8. TEAP Session Identifier
3.9. Error Handling
3.9.1. Outer-Layer Errors
3.9.2. TLS Layer Errors
3.9.3. Phase 2 Errors
3.10. Fragmentation
3.11. Services Requested by the Peer
3.11.1. Certificate Provisioning Within the Tunnel
3.11.2. Certificate Content and Uses
3.11.3. Server Unauthenticated Provisioning Mode
3.11.4. Channel Binding
4. Message Formats
4.1. TEAP Message Format
4.2. TEAP TLV Format and Support
4.2.1. General TLV Format
4.2.2. Authority-ID TLV
4.2.3. Identity-Type TLV
4.2.4. Result TLV
4.2.5. NAK TLV
4.2.6. Error TLV
4.2.7. Channel-Binding TLV
4.2.8. Vendor-Specific TLV
4.2.9. Request-Action TLV
4.2.10. EAP-Payload TLV
4.2.11. Intermediate-Result TLV
4.2.12. PAC TLV
4.2.13. Crypto-Binding TLV
4.2.14. Basic-Password-Auth-Req TLV
4.2.15. Basic-Password-Auth-Resp TLV
4.2.16. PKCS#7 TLV
4.2.17. PKCS#10 TLV
4.2.18. Trusted-Server-Root TLV
4.2.19. CSR-Attributes TLV
4.2.20. Identity-Hint TLV
4.3. TLV Rules
4.3.1. Outer TLVs
4.3.2. Inner TLVs
5. Limitations of TEAPv1
5.1. Interoperable Inner Methods
5.2. Explanation and Background
5.3. Next Steps
6. Cryptographic Calculations
6.1. TEAP Authentication Phase 1: Key Derivations
6.2. Intermediate Compound Key Derivations
6.2.1. Generating the Inner Method Session Key
6.2.2. Generating S-IMCK
6.2.3. Choosing Inner Methods Securely
6.2.4. Managing and Computing Crypto-Binding
6.2.5. Unintended Side Effects
6.3. Computing the Compound MAC
6.4. EAP Master Session Key Generation
7. IANA Considerations
7.1. TEAP TLV Types
7.2. TEAP Error TLV (value 5) Error Codes
7.3. TLS Exporter Labels
7.4. Extended Master Session Key (EMSK) Parameters
7.5. Extensible Authentication Protocol (EAP) Registry
8. Security Considerations
8.1. Mutual Authentication and Integrity Protection
8.2. Method Negotiation
8.3. Separation of Phase 1 and Phase 2 Servers
8.4. Mitigation of Known Vulnerabilities and Protocol
Deficiencies
8.4.1. User Identity Protection and Verification
8.5. Dictionary Attack Resistance
8.5.1. Protection Against On-Path Attacks
8.6. Protecting Against Forged Cleartext EAP Packets
8.7. Use of Cleartext Passwords
8.8. Accidental or Unintended Behavior
8.9. Implicit Challenge
8.10. Security Claims
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Evaluation Against Tunnel-Based EAP Method
Requirements
A.1. Requirement 4.1.1: RFC Compliance
A.2. Requirement 4.2.1: TLS Requirements
A.3. Requirement 4.2.1.1.1: Cipher Suite Negotiation
A.4. Requirement 4.2.1.1.2: Tunnel Data Protection Algorithms
A.5. Requirement 4.2.1.1.3: Tunnel Authentication and Key
Establishment
A.6. Requirement 4.2.1.2: Tunnel Replay Protection
A.7. Requirement 4.2.1.3: TLS Extensions
A.8. Requirement 4.2.1.4: Peer Identity Privacy
A.9. Requirement 4.2.1.5: Session Resumption
A.10. Requirement 4.2.2: Fragmentation
A.11. Requirement 4.2.3: Protection of Data External to Tunnel
A.12. Requirement 4.3.1: Extensible Attribute Types
A.13. Requirement 4.3.2: Request/Challenge Response Operation
A.14. Requirement 4.3.3: Indicating Criticality of Attributes
A.15. Requirement 4.3.4: Vendor-Specific Support
A.16. Requirement 4.3.5: Result Indication
A.17. Requirement 4.3.6: Internationalization of Display Strings
A.18. Requirement 4.4: EAP Channel-Binding Requirements
A.19. Requirement 4.5.1.1: Confidentiality and Integrity
A.20. Requirement 4.5.1.2: Authentication of Server
A.21. Requirement 4.5.1.3: Server Certificate Revocation Checking
A.22. Requirement 4.5.2: Internationalization
A.23. Requirement 4.5.3: Metadata
A.24. Requirement 4.5.4: Password Change
A.25. Requirement 4.6.1: Method Negotiation
A.26. Requirement 4.6.2: Chained Methods
A.27. Requirement 4.6.3: Cryptographic Binding with the TLS
Tunnel
A.28. Requirement 4.6.4: Peer-Initiated EAP Authentication
A.29. Requirement 4.6.5: Method Metadata
Appendix B. Major Differences from EAP-FAST
Appendix C. Examples
C.1. Successful Authentication
C.2. Failed Authentication
C.3. Full TLS Handshake Using Certificate-Based Cipher Suite
C.4. Client Authentication During Phase 1 with Identity Privacy
C.5. Fragmentation and Reassembly
C.6. Sequence of EAP Methods
C.7. Failed Crypto-Binding
C.8. Sequence of EAP Method with Vendor-Specific TLV Exchange
C.9. Peer Requests Inner Method After Server Sends Result TLV
C.10. Channel Binding
C.11. PKCS Exchange
C.12. Failure Scenario
C.13. Client Certificate in Phase 1
Appendix D. Changes from RFC 7170
Acknowledgments
Contributors
Author's Address
A tunnel-based Extensible Authentication Protocol (EAP) method is an EAP method that establishes a secure tunnel and executes other EAP methods under the protection of that secure tunnel. A tunnel-based EAP method can be used in any lower-layer protocol that supports EAP authentication. There are several existing tunnel-based EAP methods that use Transport Layer Security (TLS) [RFC8446] to establish the secure tunnel. EAP methods supporting this include Protected EAP (PEAP) [PEAP], EAP Tunneled Transport Layer Security (EAP-TTLS) [RFC5281], and EAP Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851]. However, they all are either vendor-specific or informational, and the industry calls for a Standards Track tunnel-based EAP method. [RFC6678] outlines the list of requirements for a standard tunnel-based EAP method.
トンネルベースの拡張認証プロトコル (EAP) メソッドは、安全なトンネルを確立し、その安全なトンネルの保護の下で他の EAP メソッドを実行する EAP メソッドです。トンネルベースの EAP 方式は、EAP 認証をサポートする下位層プロトコルで使用できます。Transport Layer Security (TLS) [RFC8446] を使用して安全なトンネルを確立する既存のトンネルベースの EAP メソッドがいくつかあります。これをサポートする EAP メソッドには、保護された EAP (PEAP) [PEAP]、EAP トンネル トランスポート層セキュリティ (EAP-TTLS) [RFC5281]、およびセキュア トンネリングによる EAP Flexible Authentication (EAP-FAST) [RFC4851] が含まれます。ただし、それらはすべてベンダー固有または情報提供のいずれかであり、業界では Standards Track トンネルベースの EAP 方式を求めています。[RFC6678] は、標準的なトンネルベースの EAP 方式の要件のリストを概説しています。
This document describes the Tunnel Extensible Authentication Protocol (TEAP) version 1, which is based on EAP-FAST [RFC4851]. The changes from EAP-FAST to TEAP are largely minor in order to meet the requirements outlined in [RFC6678] for a standard tunnel-based EAP method.
この文書では、EAP-FAST [RFC4851] に基づくトンネル拡張認証プロトコル (TEAP) バージョン 1 について説明します。EAP-FAST から TEAP への変更は、[RFC6678] で概説されている標準のトンネルベースの EAP 方式の要件を満たすために、ほとんどが小規模です。
This document also defines cryptographic derivations for use with TLS 1.2. When TLS 1.3 is used, the definitions of cryptographic derivations in [RFC9427] MUST be used instead of the ones given here.
この文書では、TLS 1.2 で使用する暗号派生も定義します。TLS 1.3 が使用される場合、ここで与えられるものの代わりに、[RFC9427] の暗号派生の定義を使用しなければなりません (MUST)。
Note that while it is technically possible to use TEAPv1 with TLS 1.0 and TLS 1.1, those protocols have been deprecated in [RFC8996]. As such, the definitions given here are only applicable for TLS 1.2 and TLS 1.3.
TLS 1.0 および TLS 1.1 で TEAPv1 を使用することは技術的には可能ですが、これらのプロトコルは [RFC8996] で非推奨になっていることに注意してください。そのため、ここで示す定義は TLS 1.2 と TLS 1.3 にのみ適用されます。
This document contains substantial changes from [RFC7170]. These changes are largely clarifications and corrections to that specification.
この文書には、[RFC7170] からの大幅な変更が含まれています。これらの変更は主に、その仕様の明確化と修正です。
However, there is one major change from [RFC7170] in the specification of the cryptographic-binding information. While there were multiple implementations of [RFC7170], the text in that document was interpreted differently by each implementation. The implementations are interoperable, but only for a subset of the functionalities described in [RFC7170].
ただし、暗号結合情報の仕様には [RFC7170] からの大きな変更が 1 つあります。[RFC7170] には複数の実装がありましたが、その文書内のテキストは実装ごとに異なって解釈されました。実装は相互運用可能ですが、[RFC7170] で説明されている機能のサブセットのみを対象としています。
This specification describes how TEAPv1 works in theory but also explains what subset of TEAPv1 is currently interoperable. In order to simplify the description of an already complex specification, all interoperability issues are documented separately from the normal protocol operation.
この仕様では、TEAPv1 が理論的にどのように動作するかについて説明するだけでなく、TEAPv1 のどのサブセットが現在相互運用可能であるかについても説明します。すでに複雑な仕様の説明を簡素化するために、すべての相互運用性の問題は通常のプロトコル動作とは別に文書化されています。
Please see Section 5 for further discussion of interoperability issues.
相互運用性の問題の詳細については、セクション 5 を参照してください。
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] で説明されているように解釈されます。
Much of the terminology in this document comes from [RFC3748]. Additional terms are defined below:
この文書の用語の多くは [RFC3748] から引用しています。追加の用語は以下のように定義されます。
Type-Length-Value (TLV)
型-長さ-値 (TLV)
The TEAP utilizes objects in TLV format. The TLV format is defined in Section 4.2.
TEAP は TLV 形式のオブジェクトを利用します。TLV フォーマットはセクション 4.2 で定義されています。
Inner Method
内部メソッド
An authentication method that is sent as application data inside of a TLS exchange that is carried over TEAP. The Inner Method can be an EAP authentication method, a username/password authentication, or a vendor-specific authentication method. Where the TLS connection is authenticated, the Inner Method could also be a Public Key Cryptography Standard (PKCS) exchange.
TEAP 経由で伝送される TLS 交換内のアプリケーション データとして送信される認証方法。内部方式には、EAP 認証方式、ユーザー名/パスワード認証、またはベンダー固有の認証方式を使用できます。TLS 接続が認証される場合、内部メソッドは公開キー暗号化標準 (PKCS) 交換である可能性もあります。
TEAP authentication occurs in two phases after the initial EAP Identity request/response exchange. In the first phase, TEAP employs the TLS [RFC8446] handshake to provide an authenticated key exchange and to establish a protected tunnel. Once the tunnel is established, the second phase begins with the peer and server engaging in further conversations to establish the required authentication and authorization policies. TEAP makes use of TLV objects to carry out the inner authentication, results, and other information, such as channel-binding information.
TEAP 認証は、最初の EAP ID 要求/応答交換後の 2 つのフェーズで発生します。最初のフェーズでは、TEAP は TLS [RFC8446] ハンドシェイクを使用して、認証されたキー交換を提供し、保護されたトンネルを確立します。トンネルが確立されると、第 2 フェーズが始まり、ピアとサーバーがさらに会話を行って、必要な認証および認可ポリシーを確立します。TEAP は TLV オブジェクトを利用して、内部認証、結果、およびチャネル バインディング情報などのその他の情報を実行します。
As discussed in Section 2.1.7 of [RFC9190] and Section 3.1 of [RFC9427], the outer EAP Identity SHOULD be an anonymous Network Access Identifier (NAI) as described in Section 2.4 of [RFC7542]. While Section 5.1 of [RFC3748] places no limits on the contents of the Identity field, Section 2.6 of [RFC7542] states that Identities that do not follow the NAI format cannot be transported in an Authentication, Authorization, and Accounting (AAA) proxy network. As such, Identities in non-NAI form are likely to not work outside of limited and local networks.
[RFC9190] のセクション 2.1.7 および [RFC9427] のセクション 3.1 で説明されているように、外部 EAP アイデンティティは、[RFC7542] のセクション 2.4 で説明されている匿名ネットワーク アクセス識別子 (NAI) である必要があります (SHOULD)。[RFC3748] のセクション 5.1 では ID フィールドの内容に制限はありませんが、[RFC7542] のセクション 2.6 では、NAI 形式に従わないアイデンティティは AAA (Authentication, Authorization, and Accounting) プロキシ ネットワークで転送できないと述べられています。そのため、非 NAI 形式の ID は、限定されたローカル ネットワークの外では機能しない可能性があります。
Any inner identities (EAP or otherwise) SHOULD also follow the recommendations of [RFC9427], Section 3.1 about inner identities.
内部アイデンティティ (EAP またはその他) も、内部アイデンティティに関する [RFC9427] セクション 3.1 の推奨事項に従うべきです (SHOULD)。
[RFC7170] defined a Protected Access Credential (PAC) to mirror EAP-FAST [RFC4851]. However, implementation experience and analysis determined that the PAC was not necessary. Instead, TEAP performs session resumption using the NewSessionTicket message as defined in Sections 2.1.2 and 2.1.3 of [RFC9190]. As such, the PAC has been deprecated.
[RFC7170] は、EAP-FAST [RFC4851] をミラーリングするための Protected Access Credential (PAC) を定義しました。ただし、実装の経験と分析により、PAC は必要ないと判断されました。代わりに、TEAP は、[RFC9190] のセクション 2.1.2 および 2.1.3 で定義されているように、NewSessionTicket メッセージを使用してセッション再開を実行します。そのため、PAC は非推奨になりました。
The TEAP conversation is used to establish or resume an existing session to typically establish network connectivity between a peer and the network. Upon successful execution of TEAP, the EAP peer and EAP server both derive strong session key material (Master Session Key [RFC3748]) that can then be communicated to the network access server (NAS) for use in establishing a link-layer security association.
TEAP 会話は、既存のセッションを確立または再開するために使用され、通常はピアとネットワーク間のネットワーク接続を確立します。TEAP の実行が成功すると、EAP ピアと EAP サーバーは両方とも、リンク層セキュリティ アソシエーションの確立に使用するためにネットワーク アクセス サーバー (NAS) に通信できる強力なセッション キー素材 (マスター セッション キー [RFC3748]) を導出します。
The network architectural model for TEAP usage is shown below:
TEAP を使用するためのネットワーク アーキテクチャ モデルを以下に示します。
+----------+ +----------+ +----------+ +----------+
| | | | | | | Inner |
| Peer |<---->| Authen- |<---->| TEAP |<---->| Method |
| | | ticator | | server | | server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
Figure 1: TEAP Architectural Model
図 1: TEAP アーキテクチャ モデル
The Peer and Authenticator are defined in [RFC3748], Section 1.2. The TEAP server is the "backend authentication server" defined in [RFC3748], Section 1.2. The "Inner Method server" is usually part of the TEAP server and handles the application data (Inner Methods, EAP, passwords, etc.) inside of the TLS tunnel.
ピアとオーセンティケータは [RFC3748] のセクション 1.2 で定義されています。TEAP サーバーは、[RFC3748] セクション 1.2 で定義されている「バックエンド認証サーバー」です。「インナー メソッド サーバー」は通常、TEAP サーバーの一部であり、TLS トンネル内のアプリケーション データ (インナー メソッド、EAP、パスワードなど) を処理します。
The entities depicted above are logical entities and may or may not correspond to separate network components. For example, the TEAP server and Inner Method server might be a single entity; the authenticator and TEAP server might be a single entity; or the functions of the authenticator, TEAP server, and Inner Method server might be combined into a single physical device. For example, typical IEEE 802.11 deployments place the authenticator in an access point (AP) while a RADIUS server may provide the TEAP and inner method server components. The above diagram illustrates the division of labor among entities in a general manner and shows how a distributed system might be constructed; however, actual systems might be realized more simply. The security considerations in Section 8.3 provide an additional discussion of the implications of separating the TEAP server from the Inner Method server.
上に示したエンティティは論理エンティティであり、個別のネットワーク コンポーネントに対応する場合と対応しない場合があります。たとえば、TEAP サーバーとインナー メソッド サーバーは 1 つのエンティティである場合があります。認証システムと TEAP サーバーは単一のエンティティである場合があります。または、オーセンティケータ、TEAP サーバー、および内部メソッド サーバーの機能が 1 つの物理デバイスに統合される場合もあります。たとえば、一般的な IEEE 802.11 の展開では、オーセンティケータがアクセス ポイント (AP) に配置され、RADIUS サーバーが TEAP およびインナー メソッド サーバー コンポーネントを提供する場合があります。上の図は、エンティティ間の役割分担を一般的な方法で示し、分散システムがどのように構築されるかを示しています。ただし、実際のシステムはもっと単純に実現される可能性があります。セクション 8.3 のセキュリティに関する考慮事項では、TEAP サーバーをインナー メソッド サーバーから分離することの影響についてさらに説明します。
TEAP packets are encapsulated within EAP; EAP in turn requires a transport protocol. TEAP packets encapsulate TLS, which is then used to encapsulate user authentication information. Thus, TEAP messaging can be described using a layered model, where each layer encapsulates the layer above it. The following diagram clarifies the relationship between protocols:
TEAP パケットは EAP 内にカプセル化されます。EAP にはトランスポート プロトコルが必要です。TEAP パケットは TLS をカプセル化し、これを使用してユーザー認証情報がカプセル化されます。したがって、TEAP メッセージングは、各層がその上の層をカプセル化する階層化モデルを使用して説明できます。次の図は、プロトコル間の関係を明確に示しています。
+------------------------------------------+
| Inner EAP Method | Other TLV information |
|------------------------------------------|
| TLV Encapsulation (TLVs) |
|------------------------------------------+---------------------+
| TLS | Optional Outer TLVs |
|----------------------------------------------------------------|
| TEAP |
|----------------------------------------------------------------|
| EAP |
|----------------------------------------------------------------|
| Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.) |
+----------------------------------------------------------------+
Figure 2: Protocol-Layering Model
図 2: プロトコル階層化モデル
The TLV layer is a payload with TLV objects as defined in Section 4.2. The TLV objects are used to carry arbitrary parameters between an EAP peer and an EAP server. All data exchanges in the TEAP-protected tunnel are encapsulated in a TLV layer.
TLV レイヤーは、セクション 4.2 で定義されている TLV オブジェクトを含むペイロードです。TLV オブジェクトは、EAP ピアと EAP サーバー間で任意のパラメータを伝達するために使用されます。TEAP で保護されたトンネル内のすべてのデータ交換は、TLV 層でカプセル化されます。
Methods for encapsulating EAP within carrier protocols are already defined. For example, IEEE 802.1X [IEEE.802-1X.2020] may be used to transport EAP between the peer and the authenticator; RADIUS [RFC3579] or Diameter [RFC4072] may be used to transport EAP between the authenticator and the EAP server.
キャリアプロトコル内で EAP をカプセル化する方法はすでに定義されています。たとえば、IEEE 802.1X [IEEE.802-1X.2020] は、ピアと認証者の間で EAP を転送するために使用される場合があります。RADIUS [RFC3579] または Diameter [RFC4072] は、オーセンティケータと EAP サーバーの間で EAP を転送するために使用できます。
TEAP packets may include TLVs both inside and outside the TLS tunnel defined as follows:
TEAP パケットには、次のように定義された TLS トンネルの内側と外側の両方に TLV が含まれる場合があります。
Outer TLVs
外部TLV
This term is used to refer to optional TLVs outside the TLS tunnel, which are only allowed in the first two messages in the TEAP. That is the first EAP-server-to-peer message and first peer-to-EAP-server message. If the message is fragmented, the whole set of fragments is counted as one message.
この用語は、TEAP の最初の 2 つのメッセージでのみ許可される、TLS トンネルの外側のオプションの TLV を指すために使用されます。これは、最初の EAP サーバーからピアへのメッセージと最初のピアから EAP サーバーへのメッセージです。メッセージが断片化されている場合、断片のセット全体が 1 つのメッセージとしてカウントされます。
Inner TLVs
内部TLV
This term is used to refer to TLVs sent within the TLS tunnel. In TEAP Phase 1, Outer TLVs are used to help establish the TLS tunnel, but no Inner TLVs are used. In Phase 2 of TEAP, TLS records may encapsulate zero or more Inner TLVs, but no Outer TLVs are used.
この用語は、TLS トンネル内で送信される TLV を指すために使用されます。TEAP フェーズ 1 では、TLS トンネルの確立に外部 TLV が使用されますが、内部 TLV は使用されません。TEAP のフェーズ 2 では、TLS レコードは 0 個以上の内部 TLV をカプセル化できますが、外部 TLV は使用されません。
The operation of the protocol, including Phase 1 and Phase 2, is the topic of this section. The format of TEAP messages is given in Section 4, and the cryptographic calculations are given in Section 6.
フェーズ 1 とフェーズ 2 を含むプロトコルの操作がこのセクションのトピックです。TEAP メッセージの形式はセクション 4 に示され、暗号計算はセクション 6 に示されます。
TEAP packets contain a 3-bit Version field, following the TLS Flags field, which enables future TEAP implementations to be backward compatible with previous versions of the protocol. This specification documents the TEAP version 1 protocol; implementations of this specification MUST use a Version field set to 1.
TEAP パケットには、TLS フラグ フィールドに続いて 3 ビットのバージョン フィールドが含まれており、これにより将来の TEAP 実装がプロトコルの以前のバージョンと下位互換性を持つことが可能になります。この仕様は、TEAP バージョン 1 プロトコルを文書化します。この仕様の実装では、1 に設定された Version フィールドを使用しなければなりません (MUST)。
Version negotiation proceeds as follows:
バージョンのネゴシエーションは次のように進行します。
1. In the first EAP-Request sent with EAP type=TEAP, the EAP server MUST set the Version field to the highest version it supports.
1. EAP type=TEAP で送信される最初の EAP-Request では、EAP サーバーは Version フィールドをサポートする最高のバージョンに設定しなければなりません (MUST)。
2. If the EAP peer supports this version of the protocol, it responds with an EAP-Response of EAP type=TEAP, including the version number proposed by the TEAP server.
2. EAP ピアがこのバージョンのプロトコルをサポートしている場合は、TEAP サーバーによって提案されたバージョン番号を含む EAP type=TEAP の EAP-Response で応答します。
3. If the TEAP peer does not support the proposed version but supports a lower version, it responds with an EAP-Response of EAP type=TEAP and sets the Version field to its highest supported version.
3. TEAP ピアが提案されたバージョンをサポートせず、それよりも低いバージョンをサポートする場合、EAP type=TEAP の EAP-Response で応答し、Version フィールドをサポートされている最高のバージョンに設定します。
4. If the TEAP peer only supports versions higher than the version proposed by the TEAP server, then use of TEAP will not be possible. In this case, the TEAP peer sends back an EAP-Nak either to negotiate a different EAP type or to indicate no other EAP types are available.
4. TEAP ピアが TEAP サーバーによって提案されたバージョンよりも新しいバージョンのみをサポートしている場合、TEAP を使用することはできません。この場合、TEAP ピアは、別の EAP タイプをネゴシエートするか、他の EAP タイプが利用できないことを示すために EAP-Nak を送り返します。
5. If the TEAP server does not support the version number proposed by the TEAP peer, it MUST either terminate the conversation with an EAP Failure or negotiate a new EAP type.
5. TEAP サーバーが TEAP ピアによって提案されたバージョン番号をサポートしていない場合、EAP Failure で会話を終了するか、新しい EAP タイプをネゴシエートしなければなりません (MUST)。
6. If the TEAP server does support the version proposed by the TEAP peer, then the conversation continues using the version proposed by the TEAP peer.
6. TEAP サーバーが TEAP ピアによって提案されたバージョンをサポートしている場合、会話は TEAP ピアによって提案されたバージョンを使用して続行されます。
The version negotiation procedure guarantees that the TEAP peer and server will agree to the latest version supported by both parties. If version negotiation fails, then use of TEAP will not be possible, and another mutually acceptable EAP method will need to be negotiated if authentication is to proceed.
バージョン ネゴシエーション手順により、TEAP ピアとサーバーが、双方がサポートする最新バージョンに同意することが保証されます。バージョン ネゴシエーションが失敗した場合、TEAP は使用できなくなり、認証を続行するには、相互に受け入れられる別の EAP 方式をネゴシエートする必要があります。
The TEAP version is not protected by TLS and hence can be modified in transit. In order to detect a bid-down attack on the TEAP version, the peers MUST exchange the TEAP version number received during version negotiation using the Crypto-Binding TLV described in Section 4.2.13. The receiver of the Crypto-Binding TLV MUST verify that the version received in the Crypto-Binding TLV matches the version sent by the receiver in the TEAP version negotiation.
TEAP バージョンは TLS によって保護されていないため、転送中に変更される可能性があります。TEAP バージョンに対する入札ダウン攻撃を検出するために、ピアは、セクション 4.2.13 で説明されている暗号バインディング TLV を使用して、バージョン ネゴシエーション中に受信した TEAP バージョン番号を交換しなければなりません (MUST)。Crypto-Binding TLV の受信者は、Crypto-Binding TLV で受信したバージョンが、TEAP バージョン ネゴシエーションで受信者によって送信されたバージョンと一致することを確認しなければなりません (MUST)。
Intermediate results are signaled via the Intermediate-Result TLV (Section 4.2.11). However, the Crypto-Binding TLV MUST be validated before any Intermediate-Result TLV or Result TLV is examined. If the Crypto-Binding TLV fails to be validated for any reason, then it is a fatal error and is handled as described in Section 3.9.3.
中間結果は、Intermediate-Result TLV (セクション 4.2.11) を介して通知されます。ただし、Crypto-Binding TLV は、中間結果 TLV または結果 TLV が検査される前に検証されなければなりません (MUST)。何らかの理由で Crypto-Binding TLV の検証に失敗した場合、それは致命的なエラーであり、セクション 3.9.3 で説明されているように処理されます。
The true success or failure of TEAP is conveyed by the Result TLV with value Success or Failure. However, as EAP terminates with either a cleartext EAP Success or Failure, a peer will also receive a cleartext EAP Success or Failure. The received cleartext EAP Success or Failure MUST match that received in the Result TLV; the peer SHOULD silently discard those cleartext EAP Success or Failure messages that do not coincide with the status sent in the protected Result TLV.
TEAP の真の成功または失敗は、成功または失敗の値を持つ結果 TLV によって伝えられます。ただし、EAP は平文 EAP 成功または失敗で終了するため、ピアも平文 EAP 成功または失敗を受信します。受信した平文 EAP の成功または失敗は、結果 TLV で受信したものと一致する必要があります。ピアは、保護された結果 TLV で送信されたステータスと一致しない平文 EAP 成功または失敗メッセージをサイレントに破棄すべきです (SHOULD)。
TEAP relies on the TLS handshake [RFC8446] to establish an authenticated and protected tunnel. The TLS version offered by the peer and server MUST be TLS version 1.2 [RFC5246] or later. This version of the TEAP implementation MUST support the following TLS cipher suites:
TEAP は、TLS ハンドシェイク [RFC8446] に依存して、認証され保護されたトンネルを確立します。ピアとサーバーが提供する TLS バージョンは、TLS バージョン 1.2 [RFC5246] 以降でなければなりません。このバージョンの TEAP 実装は、次の TLS 暗号スイートをサポートする必要があります。
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Other cipher suites MAY be supported. Implementations MUST implement the recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2 and in [RFC8446], Section 9.1 for TLS 1.3.
他の暗号スイートもサポートされる可能性があります。実装は、TLS 1.2 については [RFC9325] のセクション 4.2 で、TLS 1.3 については [RFC8446] のセクション 9.1 で推奨されている暗号スイートを実装しなければなりません (MUST)。
It is REQUIRED that anonymous cipher suites such as TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC5246] only be used in the case when the Inner Method provides mutual authentication, key generation, and resistance to on-path and dictionary attacks. TLS cipher suites that do not provide confidentiality MUST NOT be used. During the TEAP Phase 1, the TEAP endpoints MAY negotiate TLS compression. During TLS tunnel establishment, TLS extensions MAY be used. For instance, the Certificate Status Request extension [RFC6066] and the Multiple Certificate Status Request extension [RFC6961] can be used to leverage a certificate-status protocol such as the Online Certificate Status Protocol (OCSP) [RFC6960] to check the validity of server certificates. TLS renegotiation indications defined in [RFC5746] MUST be supported.
TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC5246] などの匿名暗号スイートは、内部方式が相互認証、鍵生成、およびパス上および辞書攻撃に対する耐性を提供する場合にのみ使用することが必須です。機密性を提供しない TLS 暗号スイートは使用してはなりません。TEAP フェーズ 1 中に、TEAP エンドポイントは TLS 圧縮をネゴシエートしてもよい(MAY)。TLS トンネルの確立中に、TLS 拡張機能を使用してもよい(MAY)。たとえば、Certificate Status Request 拡張 [RFC6066] と Multiple Certificate Status Request 拡張 [RFC6961] を使用すると、Online Certificate Status Protocol (OCSP) [RFC6960] などの証明書ステータス プロトコルを活用して、サーバー証明書の有効性を確認できます。[RFC5746] で定義されている TLS 再ネゴシエーション指示がサポートされなければなりません (MUST)。
Use of TLS-PSK is NOT RECOMMENDED. TEAP has not been designed to work with TLS-PSK, and no use cases, security analyses, or implementations have been done. TLS-PSK may work (or not) with TEAP, depending on the status of a particular implementation, and it is therefore not useful to deploy it.
TLS-PSK の使用は推奨されません。TEAP は TLS-PSK で動作するように設計されておらず、ユースケース、セキュリティ分析、実装は行われていません。TLS-PSK は、特定の実装のステータスに応じて TEAP で動作する (または動作しない) 場合があるため、展開することは役に立ちません。
The EAP server initiates the TEAP conversation with an EAP request containing a TEAP/Start packet. This packet includes a set Start (S) bit, the TEAP version as specified in Section 3.1, and an authority identity TLV. The TLS payload in the initial packet is empty. The authority identity TLV (Authority-ID TLV) is used to provide the peer a hint of the server's identity that may be useful in helping the peer select the appropriate credential to use. Assuming that the peer supports TEAP, the conversation continues with the peer sending an EAP-Response packet with EAP type of TEAP with the Start (S) bit clear and the version as specified in Section 3.1. This message encapsulates one or more TLS handshake messages. If the TEAP version negotiation is successful, then the TEAP conversation continues until the EAP server and EAP peer are ready to enter Phase 2. When the full TLS handshake is performed, then the first payload of TEAP Phase 2 MAY be sent along with a server-finished handshake message to reduce the number of round trips.
EAP サーバーは、TEAP/Start パケットを含む EAP 要求を使用して TEAP 会話を開始します。このパケットには、設定された開始 (S) ビット、セクション 3.1 で指定されている TEAP バージョン、および権限 ID TLV が含まれています。最初のパケットの TLS ペイロードは空です。機関 ID TLV (Authority-ID TLV) は、ピアが使用する適切な資格情報を選択するのに役立つサーバーの ID のヒントをピアに提供するために使用されます。ピアが TEAP をサポートしていると仮定すると、会話はピアが開始 (S) ビットをクリアし、セクション 3.1 で指定されているバージョンを持つ TEAP の EAP タイプを持つ EAP 応答パケットを送信して続行します。このメッセージは、1 つ以上の TLS ハンドシェイク メッセージをカプセル化します。TEAP バージョン ネゴシエーションが成功した場合、TEAP 会話は、EAP サーバーと EAP ピアがフェーズ 2 に入る準備ができるまで継続します。完全な TLS ハンドシェイクが実行されると、ラウンドトリップ数を減らすために、TEAP フェーズ 2 の最初のペイロードがサーバー終了ハンドシェイク メッセージと一緒に送信されてもよい[MAY]。
TEAP implementations MUST support mutual peer authentication during tunnel establishment using the TLS cipher suites specified in this section. The TEAP peer does not need to authenticate as part of the TLS exchange but can alternatively be authenticated through additional exchanges carried out in Phase 2.
TEAP 実装は、このセクションで指定された TLS 暗号スイートを使用したトンネル確立中の相互ピア認証をサポートしなければなりません (MUST)。TEAP ピアは TLS 交換の一部として認証する必要はありませんが、フェーズ 2 で実行される追加の交換を通じて認証することもできます。
The TEAP tunnel protects peer identity information exchanged during Phase 2 from disclosure outside the tunnel. Implementations that wish to provide identity privacy for the peer identity need to carefully consider what information is disclosed outside the tunnel prior to Phase 2. TEAP implementations SHOULD support the immediate renegotiation of a TLS session to initiate a new handshake message exchange under the protection of the current cipher suite. This allows support for protection of the peer's identity when using TLS client authentication. An example of the exchanges using TLS renegotiation to protect privacy is shown in Appendix C.
TEAP トンネルは、フェーズ 2 中に交換されるピア ID 情報をトンネル外部への開示から保護します。ピア ID に ID プライバシーを提供したい実装は、フェーズ 2 の前にトンネルの外にどのような情報が開示されるかを慎重に検討する必要があります。TEAP 実装は、現在の暗号スイートの保護の下で新しいハンドシェイク メッセージ交換を開始するための TLS セッションの即時再ネゴシエーションをサポートすべきです(SHOULD)。これにより、TLS クライアント認証を使用する場合のピアの ID の保護のサポートが可能になります。プライバシーを保護するために TLS 再ネゴシエーションを使用した交換の例を付録 C に示します。
Server certificates MUST include a subjectAltName extension, with the dnsName attribute containing a Fully Qualified Domain Name (FQDN) string. Server certificates MAY also include a SubjectDN containing a single element, "CN=", which contains the FQDN of the server. However, this use of SubjectDN is deprecated for TEAP and is forbidden in [RFC9525], Section 2.
サーバー証明書には、完全修飾ドメイン名 (FQDN) 文字列を含む dnsName 属性を持つ subjectAltName 拡張子を含める必要があります。サーバー証明書には、サーバーの FQDN を含む単一要素「CN=」を含む SubjectDN を含めることもできます (MAY)。ただし、この SubjectDN の使用は TEAP では非推奨であり、[RFC9525] セクション 2 で禁止されています。
The KeyUsage extensions MAY be included but are not required.
KeyUsage 拡張機能を含めてもよいですが、必須ではありません。
The Extended Key Usage extensions defined in [RFC5280] MAY also be included, but their use is discouraged. Systems SHOULD use a private Certification Authority (CA) for EAP in preference to public CAs. The most commonly used public CAs are focused on the web, and those certificates are not always suitable for use with EAP. In contrast, private CAs can be designed for any purposes and can be restricted to an enterprise or an other organization.
[RFC5280] で定義されている拡張キー使用拡張も含めることができます (MAY) が、その使用は推奨されません。システムは、パブリック CA ではなくプライベート認証局 (CA) を EAP に使用する必要があります (SHOULD)。最も一般的に使用されるパブリック CA は Web に重点を置いており、これらの証明書は EAP での使用に必ずしも適しているとは限りません。対照的に、プライベート CA はあらゆる目的に設計でき、企業またはその他の組織に限定することもできます。
As part of the TLS negotiation, the server usually presents a certificate to the peer. In most cases, the certificate needs to be validated, but there are a number of situations where the EAP peer does not need to do certificate validation:
TLS ネゴシエーションの一環として、サーバーは通常、ピアに証明書を提示します。ほとんどの場合、証明書を検証する必要がありますが、EAP ピアが証明書の検証を行う必要がない状況も数多くあります。
* when the peer has the server's End Entity (EE) certificate pinned or loaded directly into it's trusted anchor information [RFC4949];
* ピアがサーバーのエンドエンティティ (EE) 証明書を信頼できるアンカー情報に固定または直接ロードしている場合 [RFC4949]。
* when the peer is requesting server unauthenticated provisioning;
* ピアがサーバーの非認証プロビジョニングを要求している場合。
* when the peer is certain that it will be using an authenticated Inner Method.
* ピアが認証された内部メソッドを使用することを確信している場合。
In some cases, such as onboarding (or "bootstrapping"), the certificate validation may be delayed. However, once the onboarding has taken place, the validation steps described below MUST still be performed.
オンボーディング (または「ブートストラップ」) などの場合によっては、証明書の検証が遅れることがあります。ただし、オンボーディングが行われた後も、以下で説明する検証手順を実行する必要があります。
In all other cases, the EAP peer MUST validate the server certificate. This validation is done in the same manner as is done for EAP-TLS, which is discussed in [RFC9190], Section 5.3 and in [RFC5216], Section 5.3. Further guidance on server identity validation can be found in [RFC9525], Section 6.
それ以外の場合はすべて、EAP ピアはサーバー証明書を検証しなければなりません (MUST)。この検証は、[RFC9190] のセクション 5.3 および [RFC5216] のセクション 5.3 で説明されている EAP-TLS の場合と同じ方法で行われます。サーバー ID 検証に関するさらなるガイダンスは、[RFC9525] のセクション 6 に記載されています。
Where the EAP peer has an NAI, EAP peers MUST use the realm to perform the DNS-ID validation as per [RFC9525], Section 6. The realm is used both to construct the list of reference identifiers as defined in [RFC9525], Section 6, and as the "source domain" field of that same section.
EAP ピアが NAI を持つ場合、EAP ピアは [RFC9525] セクション 6 に従って DNS-ID 検証を実行するためにレルムを使用しなければなりません (MUST)。 レルムは、[RFC9525] セクション 6 で定義されている参照識別子のリストを構築するためと、同じセクションの「ソース ドメイン」フィールドとしての両方に使用されます。
When performing server certificate validation, implementations MUST also support the rules in [RFC5280] for validating certificates against a known trust anchor. In addition, implementations MUST support matching the realm portion of the peer's NAI against a SubjectAltName of type dnsName within the server certificate. However, in certain deployments, this comparison might not be appropriate or enabled.
サーバー証明書の検証を実行する場合、実装は、既知のトラスト アンカーに対して証明書を検証するための [RFC5280] のルールもサポートしなければなりません (MUST)。さらに、実装は、ピアの NAI のレルム部分と、サーバー証明書内の dnsName タイプの SubjectAltName との照合をサポートしなければなりません (MUST)。ただし、特定の展開では、この比較が適切でないか、有効でない場合があります。
In most situations, the EAP peer will have no network access during the authentication process. It will therefore have no way of correlating the server identity given in the certificate presented by the EAP server with a hostname, as is done with other protocols such as HTTPS. Therefore, if the EAP peer has no preconfigured trust anchor, it will have few, if any, ways of validating the server's certificate.
ほとんどの状況では、EAP ピアは認証プロセス中にネットワークにアクセスできません。したがって、HTTPS などの他のプロトコルのように、EAP サーバーによって提示された証明書で指定されたサーバー ID とホスト名を関連付ける方法はありません。したがって、EAP ピアに事前構成されたトラスト アンカーがない場合、サーバーの証明書を検証する方法は、たとえあったとしてもほとんどありません。
Note that since TLS client certificates are sent in the clear with TLS 1.2, if identity protection is required, then it is possible for the TLS authentication to be renegotiated after the first server authentication. To accomplish this, the server will typically not request a certificate in the server_hello; then, after the server_finished message is sent and before TEAP Phase 2, the server MAY send a TLS hello_request. This allows the peer to perform client authentication by sending a client_hello if it wants to or sending a no_renegotiation alert to the server indicating that it wants to continue with TEAP Phase 2 instead. Assuming that the peer permits renegotiation by sending a client_hello, then the server will respond with server_hello, certificate, and certificate_request messages. The peer replies with certificate, client_key_exchange, and certificate_verify messages. Since this renegotiation occurs within the encrypted TLS channel, it does not reveal client certificate details. It is possible to perform certificate authentication using EAP (for example, EAP-TLS) within the TLS session in TEAP Phase 2 instead of using TLS handshake renegotiation.
TLS クライアント証明書は TLS 1.2 を使用して平文で送信されるため、ID 保護が必要な場合は、最初のサーバー認証の後に TLS 認証が再ネゴシエートされる可能性があることに注意してください。これを実現するために、サーバーは通常、server_hello で証明書を要求しません。その後、server_finished メッセージが送信された後、TEAP フェーズ 2 の前に、サーバーは TLS hello_request を送信してもよい(MAY)。これにより、ピアは、必要に応じて client_hello を送信するか、代わりに TEAP フェーズ 2 を続行したいことを示す no_renegotiation アラートをサーバーに送信することにより、クライアント認証を実行できるようになります。ピアが client_hello を送信することによって再ネゴシエーションを許可すると仮定すると、サーバーは、server_hello、certificate、およびcertificate_request メッセージで応答します。ピアは、certificate、client_key_exchange、およびcertificate_verify メッセージで応答します。この再ネゴシエーションは暗号化された TLS チャネル内で行われるため、クライアント証明書の詳細は明らかにされません。TLS ハンドシェイク再ネゴシエーションを使用する代わりに、TEAP フェーズ 2 の TLS セッション内で EAP (EAP-TLS など) を使用して証明書認証を実行することができます。
When TLS 1.3 or later is used, it is RECOMMENDED that client certificates are sent in Phase 1 instead of via Phase 2 and EAP-TLS. Doing so will reduce the number of round trips. Further discussion of this issue is given below in Section 3.6.5
TLS 1.3 以降を使用する場合、クライアント証明書はフェーズ 2 および EAP-TLS 経由ではなくフェーズ 1 で送信されることが推奨されます。そうすることで往復回数が減ります。この問題の詳細については、以下のセクション 3.6.5 で説明します。
For resumption, [RFC9190], Section 5.7 discusses EAP-TLS resumption for all versions of TLS and is incorporated herein by reference. [RFC9427], Section 4 is also incorporated by reference, as it provides generic discussion of resumption for TLS-based EAP methods when TLS 1.3 is used.
再開については、[RFC9190] のセクション 5.7 で TLS のすべてのバージョンに対する EAP-TLS の再開について説明しており、参照により本明細書に組み込まれます。[RFC9427] のセクション 4 も、TLS 1.3 が使用されている場合の TLS ベースの EAP メソッドの再開に関する一般的な説明を提供するため、参照により組み込まれます。
This document only describes TEAP issues when resumption is used for TLS versions of 1.2 and earlier. It also describes resumption issues that are specific to TEAP for TLS 1.3.
このドキュメントでは、TLS バージョン 1.2 以前で再開が使用される場合の TEAP の問題についてのみ説明します。また、TLS 1.3 の TEAP に固有の再開の問題についても説明します。
If the server agrees to resume the session, Phase 2 is bypassed entirely. If the server does not agree to resume the session, then the server rejects the resumption as per [RFC9190], Section 5.7. It then continues with a full handshake. After the full TLS handshake has completed, both EAP server and peer MUST proceed with Phase 2.
サーバーがセッションの再開に同意した場合、フェーズ 2 は完全にバイパスされます。サーバーがセッションの再開に同意しない場合、サーバーは [RFC9190] のセクション 5.7 に従って再開を拒否します。その後、完全な握手が続きます。完全な TLS ハンドシェイクが完了した後、EAP サーバーとピアの両方はフェーズ 2 に進む必要があります。
All TEAP implementations MUST support resumption. Using resumption can significantly improve the scalability and stability of authentication systems. For example, some environments such as universities may have users re-authenticating multiple times a day, if not hourly. Failure to implement resumption would increase the load on the user database by orders of magnitude, leading to unnecessary cost.
すべての TEAP 実装は再開をサポートしなければなりません (MUST)。再開を使用すると、認証システムのスケーラビリティと安定性が大幅に向上します。たとえば、大学などの一部の環境では、ユーザーが 1 時間ごとではないにしても、1 日に複数回再認証を行うことがあります。再開を実装しないと、ユーザー データベースの負荷が桁違いに増加し、不必要なコストが発生する可能性があります。
The following sections describe how a TEAP session can be resumed based on server-side or client-side state.
次のセクションでは、サーバー側またはクライアント側の状態に基づいて TEAP セッションを再開する方法について説明します。
TEAP session resumption is achieved in the same manner TLS achieves session resumption. To support session resumption, the server and peer cache the Session ID, master secret, and cipher suite. The peer attempts to resume a session by including a valid Session ID from a previous TLS handshake in its ClientHello message. If the server finds a match for the Session ID and is willing to establish a new connection using the specified session state, the server will respond with the same Session ID and proceed with the TEAP Phase 1 tunnel establishment based on a TLS abbreviated handshake.
TEAP セッションの再開は、TLS がセッションを再開するのと同じ方法で実現されます。セッションの再開をサポートするために、サーバーとピアはセッション ID、マスター シークレット、および暗号スイートをキャッシュします。ピアは、以前の TLS ハンドシェイクからの有効なセッション ID を ClientHello メッセージに含めることによって、セッションを再開しようとします。サーバーがセッション ID の一致を見つけ、指定されたセッション状態を使用して新しい接続を確立しようとする場合、サーバーは同じセッション ID で応答し、TLS 短縮ハンドシェイクに基づいて TEAP フェーズ 1 トンネルの確立を続行します。
TEAP supports the resumption of sessions based on the state being stored on the client side using the TLS SessionTicket extension techniques described in [RFC5077] and [RFC9190].
TEAP は、[RFC5077] および [RFC9190] で説明されている TLS SessionTicket 拡張技術を使用して、クライアント側に保存されている状態に基づくセッションの再開をサポートします。
The second portion of the TEAP authentication occurs immediately after successful completion of Phase 1. Phase 2 occurs even if both peer and authenticator are authenticated in the Phase 1 TLS negotiation. Phase 2 MUST NOT occur if the Phase 1 TLS handshake fails, as that will compromise the security as the tunnel has not been established successfully. Phase 2 consists of a series of requests and responses encapsulated in TLV objects defined in Section 4.2. Phase 2 MUST always end with a Crypto-Binding TLV exchange described in Section 4.2.13 and a protected termination exchange described in Section 3.6.6.
TEAP 認証の 2 番目の部分は、フェーズ 1 が正常に完了した直後に発生します。フェーズ 2 は、フェーズ 1 の TLS ネゴシエーションでピアとオーセンティケータの両方が認証された場合でも発生します。フェーズ 1 の TLS ハンドシェイクが失敗した場合、フェーズ 2 は発生してはなりません。トンネルが正常に確立されていないため、セキュリティが危険にさらされることになります。フェーズ 2 は、セクション 4.2 で定義された TLV オブジェクトにカプセル化された一連の要求と応答で構成されます。フェーズ 2 は常に、セクション 4.2.13 で説明されている暗号結合 TLV 交換とセクション 3.6.6 で説明されている保護された終了交換で終了しなければなりません (MUST)。
If the peer is not authenticated in Phase 1, the TEAP peer SHOULD send one or more Identity-Hint TLVs (Section 4.2.20) as soon as the TLS connection has been established. This information lets the TEAP server choose an authentication type that is appropriate for that identity. When the TEAP peer does not provide an Identity-Hint TLV, the TEAP server does not know which Inner Method is supported by the peer. It must choose an Inner Method and propose it to the peer, which may reject that Inner Method. As a result, the peer fails to authenticate and fails to obtain network access.
ピアがフェーズ 1 で認証されない場合、TEAP ピアは、TLS 接続が確立され次第、1 つ以上の Identity-Hint TLV (セクション 4.2.20) を送信すべきです (SHOULD)。この情報により、TEAP サーバーはその ID に適した認証タイプを選択できます。TEAP ピアが Identity-Hint TLV を提供しない場合、TEAP サーバーはピアがどの内部メソッドをサポートしているかを知りません。内部メソッドを選択してピアに提案する必要がありますが、ピアはその内部メソッドを拒否する可能性があります。その結果、ピアは認証に失敗し、ネットワーク アクセスの取得に失敗します。
The TLV exchange includes the execution of zero or more inner methods within the protected tunnel as described in Sections 3.6.2 and 3.6.3. A server MAY proceed directly to the protected termination exchange without performing any inner authentication if it does not wish to request further authentication from the peer. A server MAY request one or more authentications within the protected tunnel. After completion of each Inner Method, the server decides whether or not to begin another Inner Method or to send a Result TLV.
TLV 交換には、セクション 3.6.2 および 3.6.3 で説明されているように、保護されたトンネル内で 0 個以上の内部メソッドの実行が含まれます。サーバーは、ピアからさらなる認証を要求したくない場合、内部認証を実行せずに保護された終端交換に直接進むことができます(MAY)。サーバーは、保護されたトンネル内で 1 つ以上の認証を要求してもよい (MAY)。各内部メソッドの完了後、サーバーは別の内部メソッドを開始するか、結果 TLV を送信するかを決定します。
Implementations MUST support at least two sequential Inner Methods, which allows both machine and user authentication to be performed. Implementations SHOULD also limit the number of sequential inner authentications, as there is no reason to perform a large number of inner authentications in one TEAP conversation.
実装では、マシン認証とユーザー認証の両方を実行できるようにする、少なくとも 2 つの連続した内部メソッドをサポートしなければなりません (MUST)。実装では、1 つの TEAP 会話で多数の内部認証を実行する理由がないため、連続する内部認証の数も制限する必要があります (SHOULD)。
Implementations wishing to use their own proprietary authentication method may substitute the EAP-Payload or Basic-Password-Auth-Req TLV for the Vendor-Specific TLV, which carries another authentication method. Any vendor-specific authentication method MUST support calculation of the Crypto-Binding TLV and MUST use Intermediate-Result TLV and Result TLV as is done with other authentication methods.
独自の認証方法を使用したい実装では、別の認証方法を実行するベンダー固有 TLV を EAP-Payload または Basic-Password-Auth-Req TLV に置き換えることができます。ベンダー固有の認証方法は、他の認証方法と同様に、暗号バインディング TLV の計算をサポートしなければならず、中間結果 TLV と結果 TLV を使用しなければなりません。
Due to issues noted in Section 5, the order of Inner Methods has implications for both security and interoperability.
セクション 5 で述べた問題のため、内部メソッドの順序はセキュリティと相互運用性の両方に影響します。
Where the authentication is expected to use multiple Inner Methods, implementations SHOULD order the methods so that a method that derives an Extended Master Session Key (EMSK) is used first before any other method. This ordering helps to securely tie the Inner Method to the TLS session and therefore can prevent attacks.
認証で複数の内部メソッドを使用することが予想される場合、実装では、拡張マスター セッション キー (EMSK) を導出するメソッドが他のメソッドよりも先に使用されるようにメソッドを順序付けする必要があります (SHOULD)。この順序は、内部メソッドを TLS セッションに安全に結び付けるのに役立ち、攻撃を防ぐことができます。
Implementations SHOULD support both EAP and basic password authentication for inner methods. Implementations that support multiple types of Inner Methods (User and Machine) MUST support all of those methods in any order or combination. That is, it is explicitly permitted to "mix and match" Inner Methods.
実装では、内部メソッドの EAP 認証と基本パスワード認証の両方をサポートする必要があります (SHOULD)。複数のタイプの内部メソッド (ユーザーとマシン) をサポートする実装は、それらのメソッドをすべて、任意の順序または組み合わせでサポートしなければなりません (MUST)。つまり、内部メソッドを「組み合わせて使用する」ことが明示的に許可されています。
For example, a server can request user authentication from the peer and have the peer return machine authentication (or vice versa). If the server is configured to accept machine authentication, it MUST accept that response. If that authentication succeeds, then depending on local policy, the server SHOULD proceed with requesting user authentication again.
たとえば、サーバーはピアにユーザー認証を要求し、ピアにマシン認証を返すようにすることができます (またはその逆)。サーバーがマシン認証を受け入れるように構成されている場合は、その応答を受け入れなければなりません。その認証が成功した場合、ローカルポリシーに応じて、サーバーは再度ユーザー認証の要求を続行する必要があります(SHOULD)。
Similarly, a peer that is configured to support multiple types of Inner Methods (User and Machine) can return a method other than what the server requested. This action is usually taken by the peer so that it orders Inner Methods for increased security. See Section 6.2.3 for further discussion of this issue.
同様に、複数のタイプの内部メソッド (ユーザーとマシン) をサポートするように構成されたピアは、サーバーが要求したもの以外のメソッドを返すことができます。このアクションは通常、セキュリティを強化するために内部メソッドを命令するためにピアによって実行されます。この問題の詳細については、セクション 6.2.3 を参照してください。
However, the peer and server MUST NOT assume that either will skip Inner Methods or other TLV exchanges, as the other peer might have a different security policy. The peer may have roamed to a network that requires conformance with a different authentication policy, or the peer may request the server take additional action (e.g., channel binding) through the use of the Request-Action TLV as defined in Section 4.2.9.
ただし、ピアとサーバーは、もう一方のピアが異なるセキュリティ ポリシーを持っている可能性があるため、どちらかが内部メソッドまたは他の TLV 交換をスキップすると想定してはなりません (MUST NOT)。ピアは、異なる認証ポリシーへの準拠を必要とするネットワークにローミングしている可能性があります。または、ピアは、セクション 4.2.9 で定義されているリクエストアクション TLV の使用を通じて、サーバーに追加のアクション (チャネル バインディングなど) を実行するよう要求する可能性があります。
The completion of each Inner Method is signaled by an Intermediate-Result TLV. Where the Intermediate-Result TLV indicates failure, an Error TLV SHOULD also be included using the most descriptive error code possible. The Intermediate-Result TLV may be accompanied by another TLV indicating that the server wishes to perform a subsequent authentication. When all Inner Methods have completed, the server MUST send a Result TLV indicating success or failure instead of a TLV that carries an Inner Method.
各内部メソッドの完了は、中間結果 TLV によって通知されます。中間結果 TLV が失敗を示す場合、可能な限り最も説明的なエラー コードを使用してエラー TLV も含めるべきです (SHOULD)。中間結果 TLV には、サーバーが後続の認証の実行を希望していることを示す別の TLV が伴う場合があります。すべての内部メソッドが完了したら、サーバーは内部メソッドを伝送する TLV の代わりに、成功または失敗を示す結果 TLV を送信しなければなりません (MUST)。
EAP [RFC3748] prohibits use of multiple authentication methods within a single EAP conversation in order to limit vulnerabilities to on-path attacks. TEAP addresses on-path attacks through support for cryptographic protection of the inner EAP exchange and cryptographic binding of the inner EAP method(s) to the protected tunnel. Inner Methods are executed serially in a sequence. This version of TEAP does not support initiating multiple Inner Methods simultaneously in parallel. The Inner Methods need not be distinct. For example, EAP-TLS ([RFC5216] and [RFC9190]) could be run twice as an inner method, first using machine credentials, followed by a second instance using user credentials.
EAP [RFC3748] では、パス上の攻撃に対する脆弱性を制限するために、単一の EAP 会話内で複数の認証方法を使用することを禁止しています。TEAP は、内部 EAP 交換の暗号化保護と、保護されたトンネルへの内部 EAP メソッドの暗号化バインディングのサポートを通じて、オンパス攻撃に対処します。内部メソッドはシーケンス内でシリアルに実行されます。このバージョンの TEAP は、複数の内部メソッドを同時に並行して開始することをサポートしていません。内部メソッドは個別である必要はありません。たとえば、EAP-TLS ([RFC5216] および [RFC9190]) は、内部メソッドとして 2 回実行できます。最初はマシンの資格情報を使用し、次にユーザーの資格情報を使用して 2 番目のインスタンスを実行します。
When EAP is used as an Inner Method, the EAP messages are carried within EAP-Payload TLVs defined in Section 4.2.10. Note that in this use case, TEAP is simply a carrier for EAP, much as RADIUS is a carrier for EAP. The full EAP state machine runs as normal and is carried over the EAP-Payload TLV. Each distinct EAP authentication MUST be managed as a separate EAP state machine.
EAP が内部メソッドとして使用される場合、EAP メッセージはセクション 4.2.10 で定義された EAP ペイロード TLV 内で伝送されます。この使用例では、RADIUS が EAP のキャリアであるのと同様に、TEAP は単に EAP のキャリアであることに注意してください。完全な EAP ステート マシンは通常どおり実行され、EAP ペイロード TLV 経由で伝送されます。それぞれの個別の EAP 認証は、個別の EAP ステート マシンとして管理されなければなりません (MUST)。
A TEAP server therefore MUST begin an EAP authentication with an EAP-Request/Identity (carried in an EAP-Payload TLV). However, a TEAP server MUST NOT finish the EAP conversation with an EAP Success or EAP Failure packet; the Intermediate-Result TLV is used instead.
したがって、TEAP サーバーは、EAP-Request/Identity (EAP-Payload TLV で運ばれる) を使用して EAP 認証を開始しなければなりません (MUST)。ただし、TEAP サーバーは、EAP 成功または EAP 失敗パケットで EAP 会話を終了してはなりません。代わりに、中間結果 TLV が使用されます。
Upon completion of each EAP authentication in the tunnel, the server MUST send an Intermediate-Result TLV indicating the result of that authentication. When the result indicates success, it MUST be accompanied by a Crypto-Binding TLV. The peer MUST respond to the Intermediate-Result TLV indicating its own result. Similarly, upon success, the peer MUST accompany the TLV with its own Crypto-Binding TLV. The peer MUST respond to the Intermediate-Result TLV indicating its own result and similarly on success MUST accompany the TLV with its own Crypto-Binding TLV. The Crypto-Binding TLV is further discussed in Sections 4.2.13 and 6.3. The Intermediate-Result TLVs can be included with other TLVs that indicate a subsequent authentication or with the Result TLV used in the protected termination exchange.
トンネル内の各 EAP 認証が完了すると、サーバーはその認証の結果を示す中間結果 TLV を送信しなければなりません (MUST)。結果が成功を示した場合、それには暗号バインディング TLV が伴わなければなりません (MUST)。ピアは、自身の結果を示す中間結果 TLV に応答しなければなりません (MUST)。同様に、成功した場合、ピアは独自の暗号バインディング TLV を TLV に添付しなければなりません (MUST)。ピアは、自身の結果を示す中間結果 TLV に応答しなければならず (MUST)、同様に成功した場合には、TLV に自身の暗号バインディング TLV を付加しなければなりません (MUST)。暗号バインディング TLV については、セクション 4.2.13 および 6.3 でさらに説明します。中間結果 TLV は、後続の認証を示す他の TLV または保護された終了交換で使用される結果 TLV に含めることができます。
If both peer and server indicate success, then the authentication is considered successful. If either indicates failure, then the authentication is considered failed. The result of failure of an EAP authentication does not always imply a failure of the overall authentication. If one Inner Method fails, the server may attempt to authenticate the peer with a different method (EAP or password).
ピアとサーバーの両方が成功を示した場合、認証は成功したとみなされます。どちらかが失敗を示している場合、認証は失敗したとみなされます。EAP 認証の失敗の結果は、必ずしも認証全体の失敗を意味するとは限りません。1 つの内部メソッドが失敗した場合、サーバーは別のメソッド (EAP またはパスワード) を使用してピアの認証を試みる場合があります。
The authentication server (AS) initiates password authentication by sending a Basic-Password-Auth-Req TLV defined in Section 4.2.14. If the peer wishes to participate in password authentication, then it responds with a Basic-Password-Auth-Resp TLV that contains the username and password as defined in Section 4.2.15. If it does not wish to perform password authentication, then it responds with a Negative Acknowledgment (NAK) TLV indicating the rejection of the Basic-Password-Auth-Req TLV.
認証サーバー (AS) は、セクション 4.2.14 で定義されている Basic-Password-Auth-Req TLV を送信することでパスワード認証を開始します。ピアがパスワード認証への参加を希望する場合、セクション 4.2.15 で定義されているユーザー名とパスワードを含む Basic-Password-Auth-Resp TLV で応答します。パスワード認証を実行したくない場合は、Basic-Password-Auth-Req TLV の拒否を示す Negative Acknowledgment (NAK) TLV で応答します。
The basic password authentication defined here is similar in functionality to that used by EAP-TTLS [RFC5281] with inner password authentication. It shares a similar security and risk analysis.
ここで定義される基本パスワード認証は、内部パスワード認証を備えた EAP-TTLS [RFC5281] で使用されるものと機能的に似ています。同様のセキュリティとリスク分析を共有します。
Multiple round trips of password authentication requests and responses MAY be used to support some "housekeeping" functions such as a password or pin change before a user is considered to be authenticated. Multiple rounds MAY also be used to communicate a user's password and, separately, a one-time password such as Time-Based One-Time Passwords (TOTPs) [RFC6238].
ユーザーが認証されたとみなされる前に、パスワードや暗証番号の変更などの一部の「ハウスキーピング」機能をサポートするために、パスワード認証の要求と応答の複数の往復を使用してもよい(MAY)。ユーザーのパスワードと、それとは別に、時間ベースのワンタイム パスワード (TOTP) [RFC6238] などのワンタイム パスワードを伝達するために、複数のラウンドを使用してもよい (MAY)。
Implementations MUST limit the number of round trips for password authentication. It is reasonable to use one or two round trips. Further round trips are likely to be problematic and SHOULD be avoided.
実装では、パスワード認証の往復回数を制限しなければなりません (MUST)。1～2往復程度の利用が妥当です。これ以上の往復は問題が発生する可能性が高いため、避けるべきです。
The first Basic-Password-Auth-Req TLV received in a session MUST include a prompt, which the peer displays to the user. Subsequent authentication rounds SHOULD include a prompt, but it is not always necessary.
セッションで受信した最初の Basic-Password-Auth-Req TLV には、ピアがユーザーに表示するプロンプトが含まれなければなりません (MUST)。後続の認証ラウンドにはプロンプトが含まれる必要がありますが、常に必要というわけではありません。
When the peer first receives a Basic-Password-Auth-Req TLV, it should allow the user to enter both a username and a password, which are then placed in the Basic-Password-Auth-Resp TLV. If the peer receives subsequent Basic-Password-Auth-Req TLVs in the same authentication session, it MUST NOT prompt for a username and MUST instead allow the user to enter only a password. The peer MUST copy the username used in the first Basic-Password-Auth-Resp TLV into all subsequent Basic-Password-Auth-Resp TLVs.
ピアが最初に Basic-Password-Auth-Req TLV を受信すると、ユーザーはユーザー名とパスワードの両方を入力できるようになり、これらは Basic-Password-Auth-Resp TLV に配置されます。ピアが同じ認証セッションで後続の Basic-Password-Auth-Req TLV を受信した場合、ユーザー名の入力を求めてはならず、代わりにユーザーにパスワードのみの入力を許可しなければなりません (MUST)。ピアは、最初の Basic-Password-Auth-Resp TLV で使用されているユーザー名を、後続のすべての Basic-Password-Auth-Resp TLV にコピーしなければなりません (MUST)。
Servers MUST track the username across multiple password rounds and reject authentication if the identity changes from one Basic-Password-Auth-Resp TLV to the next. There is no reason for a user (or machine) to change identities in the middle of authentication.
サーバーは、複数のパスワード ラウンドにわたってユーザー名を追跡し、Basic-Password-Auth-Resp TLV 間で ID が変更された場合は認証を拒否しなければなりません (MUST)。ユーザー (またはマシン) が認証の途中で ID を変更する理由はありません。
Upon reception of a Basic-Password-Auth-Resp TLV in the tunnel, the server MUST send an Intermediate-Result TLV indicating the result. The peer MUST respond to the Intermediate-Result TLV indicating its result. If the result indicates success, the Intermediate-Result TLV MUST be accompanied by a Crypto-Binding TLV. The Crypto-Binding TLV is further discussed in Sections 4.2.13 and 6.3.
トンネル内で Basic-Password-Auth-Resp TLV を受信した場合、サーバーは結果を示す Intermediate-Result TLV を送信しなければなりません (MUST)。ピアは、その結果を示す中間結果 TLV に応答しなければなりません (MUST)。結果が成功を示した場合、中間結果 TLV には暗号バインディング TLV が伴わなければなりません (MUST)。暗号バインディング TLV については、セクション 4.2.13 および 6.3 でさらに説明します。
The Intermediate-Result TLVs can be included with other TLVs that indicate a subsequent authentication or with the Result TLV used in the protected termination exchange.
中間結果 TLV は、後続の認証を示す他の TLV または保護された終了交換で使用される結果 TLV に含めることができます。
The use of EAP-FAST-GTC as defined in [RFC5421] is NOT RECOMMENDED with TEAPv1 because EAP-FAST-GTC is not compliant with EAP-GTC defined in [RFC3748]. Implementations should instead make use of the password authentication TLVs defined in this specification.
EAP-FAST-GTC は [RFC3748] で定義されている EAP-GTC に準拠していないため、[RFC5421] で定義されている EAP-FAST-GTC の使用は TEAPv1 では推奨されません。実装では、代わりに、この仕様で定義されているパスワード認証 TLV を使用する必要があります。
If using EAP-MSCHAPv2 [KAMATH] as an inner EAP method, the EAP-FAST-MSCHAPv2 variant defined in [RFC5422], Section 3.2.3 MUST be used instead of the derivation defined in [MSCHAP].
EAP-MSCHAPv2 [KAMATH] を内部 EAP メソッドとして使用する場合、[RFC5422] セクション 3.2.3 で定義されている EAP-FAST-MSCHAPv2 バリアントを、[MSCHAP] で定義されている派生の代わりに使用しなければなりません (MUST)。
The difference between EAP-MSCHAPv2 and EAP-FAST-MSCHAPv2 is that the first and the second 16 octets of the EAP-MSCHAPv2 Master Session Key (MSK) are swapped when it is used as the Inner Method Session Keys (IMSKs) for TEAP.
EAP-MSCHAPv2 と EAP-FAST-MSCHAPv2 の違いは、EAP-MSCHAPv2 マスター セッション キー (MSK) が TEAP の内部メソッド セッション キー (IMSK) として使用される場合、最初と 2 番目の 16 オクテットが交換されることです。
Implementations SHOULD limit the permitted inner EAP methods to a small set such as EAP-TLS and the EAP-FAST-MSCHAPv2 variant of EAP-MSCHAPv2. These EAP methods are the most commonly supported inner methods in TEAP and are known to be interoperable among multiple implementations.
実装では、許可される内部 EAP メソッドを、EAP-TLS や EAP-MSCHAPv2 の EAP-FAST-MSCHAPv2 バリアントなどの小さなセットに制限する必要があります (SHOULD)。これらの EAP メソッドは、TEAP で最も一般的にサポートされている内部メソッドであり、複数の実装間で相互運用できることが知られています。
Other EAP methods such as EAP-pwd, EAP-SIM, EAP-AKA, or EAP-AKA' can be used within a TEAP tunnel. Any EAP method that derives both MSK and EMSK is likely to work as an Inner Method for TEAP, because EAP-TLS has that behavior and it works. EAP methods that derive only MSK should work, as EAP-FAST-MSCHAPv2 has that behavior, and it works. Other EAP methods are untested and may or may not work.
EAP-pwd、EAP-SIM、EAP-AKA、または EAP-AKA' などの他の EAP 方式を TEAP トンネル内で使用できます。MSK と EMSK の両方を導出する EAP メソッドは、EAP-TLS がその動作を備えており、機能するため、TEAP の内部メソッドとして機能する可能性があります。EAP-FAST-MSCHAPv2 にはその動作があり、機能するため、MSK のみを派生する EAP メソッドは機能するはずです。他の EAP 方法はテストされていないため、機能する場合と機能しない場合があります。
Tunneled EAP methods such as PEAP [PEAP], EAP-TTLS [RFC5281], and EAP-FAST [RFC4851] MUST NOT be used for inner EAP authentication. There is no reason to have multiple layers of TLS in order to protect a password exchange.
PEAP [PEAP]、EAP-TTLS [RFC5281]、EAP-FAST [RFC4851] などのトンネル EAP 方式は、内部 EAP 認証に使用してはなりません (MUST NOT)。パスワード交換を保護するために複数の TLS 層を使用する理由はありません。
The EAP methods defined in [RFC3748], Section 5, such as MD5-Challenge, One-Time Password (OTP), and Generic Token Card (GTC), do not derive an MSK or an EMSK and are vulnerable to on-path attacks. The construction of the OTP and GTC methods makes this attack less relevant, as the information being sent is generally a one-time token. However, EAP-OTP and EAP-GTC offer no benefit over the basic password authentication defined in Section 3.6.3, which also does not perform crypto-binding of the Inner Method to the TLS session. These EAP methods are therefore not useful as Phase 2 methods within TEAP.
[RFC3748] セクション 5 で定義されている MD5 チャレンジ、ワンタイム パスワード (OTP)、および汎用トークン カード (GTC) などの EAP メソッドは、MSK または EMSK を導出せず、オンパス攻撃に対して脆弱です。OTP および GTC メソッドの構築により、送信される情報は通常 1 回限りのトークンであるため、この攻撃の関連性は低くなります。ただし、EAP-OTP および EAP-GTC には、セクション 3.6.3 で定義されている基本パスワード認証に勝る利点はなく、TLS セッションへの内部メソッドの暗号バインディングも実行されません。したがって、これらの EAP メソッドは、TEAP 内のフェーズ 2 メソッドとしては役に立ちません。
Other EAP methods are less widely used and highly likely to not work as the inner EAP method for TEAP.
他の EAP 方式はあまり広く使用されておらず、TEAP の内部 EAP 方式として機能しない可能性が高くなります。
In order to protect from on-path attacks, TEAP implementations MUST NOT permit the use of inner EAP methods that fail to perform crypto-binding of the Inner Method to the TLS session.
オンパス攻撃から保護するために、TEAP 実装は、TLS セッションへの内部メソッドの暗号バインディングを実行できない内部 EAP メソッドの使用を許可してはなりません (MUST NOT)。
Implementations MUST NOT permit resumption for the inner EAP methods such as EAP-TLS. If the user or machine needs to be authenticated, it should use a method that provides full authentication. If the user or machine needs to do resumption, it can perform a full authentication once and then rely on the outer TLS session for resumption. This restriction applies also to all TLS-based EAP methods that can tunnel other EAP methods. As a result, this document updates [RFC9427].
実装では、EAP-TLS などの内部 EAP メソッドの再開を許可してはなりません (MUST NOT)。ユーザーまたはマシンを認証する必要がある場合は、完全な認証を提供する方法を使用する必要があります。ユーザーまたはマシンが再開する必要がある場合、完全な認証を 1 回実行してから、外部の TLS セッションに依存して再開できます。この制限は、他の EAP メソッドをトンネリングできるすべての TLS ベースの EAP メソッドにも適用されます。その結果、この文書は [RFC9427] を更新します。
In general, the reason to use a non-TLS-based EAP method inside of a TLS-based EAP method such as TEAP is for privacy. Many previous EAP methods may leak information about user identity, and those leaks are prevented by running the method inside of a protected TLS tunnel.
一般に、TEAP などの TLS ベースの EAP メソッドの内部で非 TLS ベースの EAP メソッドを使用する理由は、プライバシーのためです。以前の EAP メソッドの多くはユーザー ID に関する情報を漏洩する可能性がありますが、保護された TLS トンネル内でメソッドを実行することで、これらの漏洩は防止されます。
EAP-TLS is permitted in Phase 2 for two use cases. The first use case is when TLS 1.2 is used, as the client certificate is not protected as with TLS 1.3. It is therefore RECOMMENDED that when TLS 1.3 is used for the outer TEAP exchange, the client certificate is sent in Phase 1 instead of doing EAP-TLS in Phase 2. This behavior will simplify the authentication exchange and use fewer round trips than doing EAP-TLS inside of TEAP.
EAP-TLS はフェーズ 2 で 2 つのユースケースに対して許可されます。最初の使用例は、クライアント証明書が TLS 1.3 のように保護されないため、TLS 1.2 が使用される場合です。したがって、外側の TEAP 交換に TLS 1.3 を使用する場合、フェーズ 2 で EAP-TLS を実行する代わりに、フェーズ 1 でクライアント証明書を送信することが推奨されます。この動作により、認証交換が簡素化され、TEAP 内部で EAP-TLS を実行する場合よりも往復回数が減ります。
The second use case for EAP-TLS in Phase 2 is where both the user and machine use client certificates for authentication. Since TLS permits only one client certificate to be presented, only one certificate can be used in Phase 1. The second certificate is then presented via EAP-TLS in Phase 2.
フェーズ 2 の EAP-TLS の 2 番目の使用例は、ユーザーとマシンの両方が認証にクライアント証明書を使用する場合です。TLS ではクライアント証明書の提示が 1 つだけ許可されるため、フェーズ 1 では 1 つの証明書のみを使用できます。その後、フェーズ 2 で 2 番目の証明書が EAP-TLS 経由で提示されます。
For basic password authentication, it is RECOMMENDED that this method be only used for the exchange of one-time passwords. The existence of password-based EAP methods such as EAP-pwd ([RFC5931] and [RFC8146]) makes most cleartext password exchanges unnecessary. The updates to EAP-pwd in [RFC8146] permit it to be used with databases that store passwords in "salted" form, which greatly increases security.
基本パスワード認証の場合、この方法はワンタイム パスワードの交換にのみ使用することが推奨されます。EAP-pwd ([RFC5931] および [RFC8146]) などのパスワードベースの EAP メソッドの存在により、ほとんどの平文パスワード交換が不要になります。[RFC8146] の EAP-pwd の更新により、パスワードを「ソルト」形式で保存するデータベースで EAP-pwd を使用できるようになり、セキュリティが大幅に向上します。
Where no Inner Method provides an EMSK, the Crypto-Binding TLV offers little protection, as it cannot tie the inner EMSK to the TLS session via the TLS-PRF. As a result, the TEAP session will be vulnerable to on-path active attacks. Implementations and deployments SHOULD adopt various mitigation strategies described in [RFC7029], Section 3.2. Implementations also need to implement the Inner Method ordering described in Section 6.1 in order to fully prevent on-path attacks.
内部メソッドが EMSK を提供しない場合、暗号バインディング TLV は、TLS-PRF を介して内部 EMSK を TLS セッションに結び付けることができないため、ほとんど保護を提供しません。その結果、TEAP セッションはパス上のアクティブな攻撃に対して脆弱になります。実装と展開では、[RFC7029] のセクション 3.2 に記載されているさまざまな緩和戦略を採用する必要があります (SHOULD)。実装では、オンパス攻撃を完全に防ぐために、セクション 6.1 で説明されている内部メソッドの順序付けも実装する必要があります。
A successful TEAP Phase 2 conversation MUST always end in a successful Crypto-Binding TLV and Result TLV exchange. A TEAP server may initiate the Crypto-Binding TLV and Result TLV exchange without initiating any Inner Methods in TEAP Phase 2. After the final Result TLV exchange, the TLS tunnel is terminated, and a cleartext EAP Success or EAP Failure is sent by the server. Peers implementing TEAP MUST NOT accept a cleartext EAP Success or Failure packet prior to the peer and server reaching synchronized protected result indication.
成功した TEAP フェーズ 2 会話は、常に、Crypto-Binding TLV と Result TLV 交換の成功で終了しなければなりません。TEAP サーバーは、TEAP フェーズ 2 で内部メソッドを開始せずに、暗号バインディング TLV と結果 TLV 交換を開始する場合があります。最後の結果 TLV 交換の後、TLS トンネルは終了し、平文の EAP 成功または EAP 失敗がサーバーによって送信されます。TEAP を実装しているピアは、ピアとサーバーが同期された保護された結果の表示に達する前に、平文の EAP 成功または失敗パケットを受け入れてはなりません (MUST NOT)。
The Crypto-Binding TLV exchange is used to prove that both the peer and server participated in the tunnel establishment and sequence of authentications. It also provides verification of the TEAP type, version negotiated, and Outer TLVs exchanged before the TLS tunnel establishment. Except as noted below, the Crypto-Binding TLV MUST be exchanged and verified before the final Result TLV exchange, regardless of whether or not there is an Inner Method. The Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform cryptographic binding after each successful authentication in a sequence of one or more Inner Methods. The server may send the final Result TLV along with an Intermediate-Result TLV and a Crypto-Binding TLV to indicate its intention to end the conversation. If the peer requires nothing more from the server, it will respond with a Result TLV indicating success accompanied by a Crypto-Binding TLV and Intermediate-Result TLV if necessary. The server then tears down the tunnel and sends a cleartext EAP Success or EAP Failure.
Crypto-Binding TLV 交換は、ピアとサーバーの両方がトンネルの確立と一連の認証に参加したことを証明するために使用されます。また、TEAP タイプ、ネゴシエートされたバージョン、および TLS トンネルの確立前に交換されたアウター TLV の検証も提供します。以下に記載されている場合を除き、内部メソッドがあるかどうかに関係なく、最終的な結果 TLV 交換の前に、Crypto-Binding TLV を交換して検証する必要があります。1 つ以上の内部メソッドのシーケンスで認証が成功するたびに暗号化バインディングを実行するために、Crypto-Binding TLV と Intermediate-Result TLV を含める必要があります。サーバーは、会話を終了する意図を示すために、中間結果 TLV および暗号バインディング TLV とともに最終結果 TLV を送信する場合があります。ピアがサーバーからそれ以上何も要求しない場合、ピアは成功を示す結果 TLV で応答し、必要に応じて暗号バインディング TLV および中間結果 TLV を伴います。その後、サーバーはトンネルを切断し、平文の EAP 成功または EAP 失敗を送信します。
If the peer receives a Result TLV indicating success from the server, but its authentication policies are not satisfied (for example, it requires a particular authentication mechanism to be run), it may request further action from the server using the Request-Action TLV. The Request-Action TLV is sent with a Status field indicating what EAP Success/Failure result the peer would expect if the requested action is not granted. The value of the Action field indicates what the peer would like to do next. The format and values for the Request-Action TLV are defined in Section 4.2.9.
ピアがサーバーから成功を示す結果 TLV を受信したが、その認証ポリシーが満たされていない場合 (たとえば、特定の認証メカニズムの実行が必要な場合)、ピアはリクエスト-アクション TLV を使用してサーバーにさらなるアクションを要求することがあります。要求アクション TLV は、要求されたアクションが許可されなかった場合にピアが期待する EAP 成功/失敗結果を示すステータス フィールドとともに送信されます。Action フィールドの値は、ピアが次に何を実行したいかを示します。Request-Action TLV の形式と値はセクション 4.2.9 で定義されています。
Upon receiving the Request-Action TLV, the server may process the request or ignore it, based on its policy. If the server ignores the request, it proceeds with termination of the tunnel and sends the cleartext EAP Success or Failure message based on the Status field of the peer's Request-Action TLV. If the server honors and processes the request, it continues with the requested action. The conversation completes with a Result TLV exchange. The Result TLV may be included with the TLV that completes the requested action.
Request-Action TLV を受信すると、サーバーはポリシーに基づいてリクエストを処理するか、無視することができます。サーバーが要求を無視した場合、サーバーはトンネルの終了を続行し、ピアの Request-Action TLV の Status フィールドに基づいて平文の EAP 成功または失敗メッセージを送信します。サーバーがリクエストを受け入れて処理すると、リクエストされたアクションが続行されます。会話は結果 TLV 交換で完了します。結果 TLV は、要求されたアクションを完了する TLV に含めることができます。
Error handling for Phase 2 is discussed in Section 3.9.3.
フェーズ 2 のエラー処理については、セクション 3.9.3 で説明します。
The Peer-Id and Server-Id [RFC5247] may be determined based on the types of credentials used during either the TEAP tunnel creation or authentication. In the case of multiple peer authentications, all authenticated peer identities and their corresponding identity types (Section 4.2.3) need to be exported. In the case of multiple server authentications, all authenticated server identities need to be exported.
Peer-Id と Server-Id [RFC5247] は、TEAP トンネルの作成または認証中に使用される資格情報のタイプに基づいて決定できます。複数のピア認証の場合、すべての認証されたピア ID とそれに対応する ID タイプ (セクション 4.2.3) をエクスポートする必要があります。複数のサーバー認証の場合は、認証されたすべてのサーバー ID をエクスポートする必要があります。
When X.509 certificates are used for peer authentication, the Peer-Id is determined by the subject and subjectAltName fields in the peer certificate. As noted in [RFC5280]:
X.509 証明書がピア認証に使用される場合、Peer-Id はピア証明書の subject フィールドと subjectAltName フィールドによって決定されます。[RFC5280] に記載されているように:
The subject field identifies the entity associated with the public key stored in the subject public key field. The subject name MAY be carried in the subject field and/or the subjectAltName extension. . . . If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical.
サブジェクト フィールドは、サブジェクト公開キー フィールドに格納されている公開キーに関連付けられたエンティティを識別します。件名名は、件名フィールドおよび/または subjectAltName 拡張子に含めることができます (MAY)。。。。サブジェクトの命名情報が subjectAltName 拡張子内にのみ存在する場合 (例: 電子メール アドレスまたは URI のみにバインドされたキー)、サブジェクト名は空のシーケンスでなければならず、subjectAltName 拡張子はクリティカルでなければなりません。
Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN).
空でない場合、件名フィールドには X.500 識別名 (DN) が含まれなければなりません (MUST)。
If an inner EAP authentication method is run, then the Peer-Id is obtained from that inner EAP authentication method.
内部 EAP 認証方式が実行されている場合、Peer-Id はその内部 EAP 認証方式から取得されます。
When the server uses an X.509 certificate to establish the TLS tunnel, the Server-Id is determined in a similar fashion as stated above for the Peer-Id, e.g., the subject and subjectAltName fields in the server certificate define the Server-Id.
サーバーが X.509 証明書を使用して TLS トンネルを確立する場合、サーバー ID はピア ID について上で説明したのと同様の方法で決定されます。たとえば、サーバー証明書の subject フィールドと subjectAltName フィールドが Server-Id を定義します。
For TLS 1.2 and earlier, the EAP session identifier [RFC5247] is constructed using the tls-unique from the Phase 1 outer tunnel at the beginning of Phase 2 as defined by Section 3.1 of [RFC5929]. The Session-Id is defined as follows:
TLS 1.2 以前の場合、EAP セッション識別子 [RFC5247] は、[RFC5929] のセクション 3.1 で定義されているように、フェーズ 2 の開始時にフェーズ 1 の外部トンネルからの tls-unique を使用して構築されます。セッション ID は次のように定義されます。
Session-Id = teap_type | tls-unique
Where:
ただし：
* | denotes concatenation,
* |は連結を表し、
* teap_type is the EAP Type assigned to TEAP, and
* teap_type は、TEAP に割り当てられた EAP タイプです。
* tls-unique = tls-unique from the Phase 1 outer tunnel at the beginning of Phase 2 as defined by Section 3.1 of [RFC5929].
* tls-unique = [RFC5929] のセクション 3.1 で定義されている、フェーズ 2 の開始時のフェーズ 1 外部トンネルからの tls-unique。
The Session-Id derivation for TLS 1.3 is given in [RFC9427], Section 2.1
TLS 1.3 のセッション ID の導出は、[RFC9427] のセクション 2.1 に記載されています。
TEAP uses the error-handling rules summarized below:
TEAP は、以下にまとめたエラー処理ルールを使用します。
1. Errors in the outer EAP packet layer are handled as defined in Section 3.9.1.
1. 外部 EAP パケット層のエラーは、セクション 3.9.1 で定義されているように処理されます。
2. Errors in the TLS layer are communicated via TLS alert messages in both phases of TEAP.
2. TLS 層のエラーは、TEAP の両方のフェーズで TLS アラート メッセージを介して通知されます。
3. The Intermediate-Result TLVs carry success or failure indications of the individual Inner Methods in TEAP Phase 2. Errors within an EAP conversation in Phase 2 are expected to be handled by the individual EAP authentication methods.
3. 中間結果 TLV は、TEAP フェーズ 2 の個々の内部メソッドの成功または失敗を示します。フェーズ 2 の EAP 会話内のエラーは、個々の EAP 認証メソッドによって処理されることが期待されます。
4. Violations of the Inner TLV rules are handled using Result TLVs together with Error TLVs.
4. 内部 TLV ルールの違反は、結果 TLV とエラー TLV を使用して処理されます。
5. Tunnel-compromised errors (errors caused by a failed or missing Crypto-Binding) are handled using Result TLVs and Error TLVs.
5. トンネル侵害エラー (暗号化バインディングの失敗または欠落によって引き起こされるエラー) は、結果 TLV とエラー TLV を使用して処理されます。
Errors on the TEAP outer-packet layer are handled in the following ways:
TEAP 外側パケット層のエラーは次の方法で処理されます。
1. If Outer TLVs are invalid or contain unknown values, they will be ignored.
1. 外部 TLV が無効であるか、不明な値が含まれている場合、それらは無視されます。
2. The entire TEAP packet will be ignored if other fields (version, length, flags, etc.) are inconsistent with this specification.
2. 他のフィールド (バージョン、長さ、フラグなど) がこの仕様と一致しない場合、TEAP パケット全体が無視されます。
If the TEAP server detects an error at any point in the TLS handshake or the TLS layer, the server SHOULD send a TEAP request encapsulating a TLS record containing the appropriate TLS alert message rather than immediately terminating the TEAP exchange so as to allow the peer to inform the user of the cause of the failure. The TEAP peer MUST send a TEAP response to an alert message. The EAP-Response packet sent by the peer SHOULD contain a TEAP response with a zero-length message. The server MUST terminate the TEAP exchange with an EAP Failure packet no matter what the client says.
TEAP サーバーが TLS ハンドシェイクまたは TLS 層のいずれかの時点でエラーを検出した場合、サーバーは、ピアがユーザーに障害の原因を通知できるように、TEAP 交換を直ちに終了するのではなく、適切な TLS 警告メッセージを含む TLS レコードをカプセル化した TEAP リクエストを送信する必要があります (SHOULD)。TEAP ピアは、アラート メッセージに対して TEAP 応答を送信しなければなりません (MUST)。ピアによって送信される EAP 応答パケットには、長さゼロのメッセージを含む TEAP 応答が含まれる必要があります (SHOULD)。サーバーは、クライアントが何と言おうと、EAP Failure パケットで TEAP 交換を終了しなければなりません (MUST)。
If the TEAP peer detects an error at any point in the TLS layer, the TEAP peer SHOULD send a TEAP response encapsulating a TLS record containing the appropriate TLS alert message, which contains a zero-length message. The server then MUST terminate the conversation with an EAP failure as discussed in the previous paragraph.
TEAP ピアが TLS 層のいずれかの時点でエラーを検出した場合、TEAP ピアは、長さゼロのメッセージを含む適切な TLS 警告メッセージを含む TLS レコードをカプセル化した TEAP 応答を送信する必要があります (SHOULD)。サーバーは、前の段落で説明したように、EAP エラーで会話を終了しなければなりません (MUST)。
While TLS 1.3 [RFC8446] allows for the TLS conversation to be restarted, it is not clear when that would be useful (or used) for TEAP. Fatal TLS errors will cause the TLS conversation to fail. Non-fatal TLS errors can likely be ignored entirely. As a result, TEAP implementations MUST NOT permit TLS restarts.
TLS 1.3 [RFC8446] では TLS 会話の再開が可能ですが、それが TEAP にとっていつ役立つ (または使用される) かは明らかではありません。致命的な TLS エラーにより、TLS 会話が失敗します。致命的ではない TLS エラーは、完全に無視できる可能性があります。結果として、TEAP 実装は TLS の再起動を許可してはなりません (MUST NOT)。
There are a large number of situations where errors can occur during Phase 2 processing. This section describes both errors and the recommended processing of them.
フェーズ 2 の処理中にエラーが発生する状況は数多くあります。このセクションでは、両方のエラーとその推奨される処理について説明します。
When the server receives a Result TLV with a fatal Error TLV from the peer, it MUST terminate the TLS tunnel and reply with an EAP Failure.
サーバーがピアから致命的エラー TLV を含む結果 TLV を受信した場合、サーバーは TLS トンネルを終了し、EAP 失敗で応答しなければなりません (MUST)。
When the peer receives a Result TLV with a fatal Error TLV from the server, it MUST respond with a Result TLV indicating failure. The server MUST discard any data it receives from the peer and reply with an EAP Failure. The final message from the peer is required by the EAP state machine and serves only to allow the server to reply to the peer with the EAP Failure.
ピアがサーバーから致命的エラー TLV を含む結果 TLV を受信した場合、失敗を示す結果 TLV で応答しなければなりません (MUST)。サーバーはピアから受信したデータをすべて破棄し、EAP 失敗で応答しなければなりません (MUST)。ピアからの最終メッセージは EAP ステート マシンに必要であり、サーバーがピアに EAP 失敗を応答できるようにするためにのみ機能します。
The following items describe specific errors and processing in more detail.
次の項目では、特定のエラーと処理について詳しく説明します。
Fatal Error processing a TLV:
TLV の処理中に致命的なエラーが発生しました:
Any time the peer or the server finds a fatal error outside of the TLS layer during Phase 2 TLV processing, it MUST send a Result TLV of failure and an Error TLV using the most descriptive error code possible.
ピアまたはサーバーがフェーズ 2 TLV 処理中に TLS 層の外側で致命的なエラーを発見した場合は常に、可能な限り最もわかりやすいエラー コードを使用して、失敗の結果 TLV とエラー TLV を送信しなければなりません (MUST)。
Fatal Error during TLV Exchanges:
TLV 交換中の致命的なエラー:
For errors involving the processing of the sequence of exchanges, such as a violation of TLV rules (e.g., multiple EAP-Payload TLVs), the error code is Unexpected TLVs Exchanged.
TLV ルール違反 (複数の EAP ペイロード TLV など) など、一連の交換の処理に関連するエラーの場合、エラー コードは「予期しない TLV 交換」です。
Fatal Error due to tunnel compromise:
トンネル侵害による致命的エラー:
For errors involving a tunnel compromise, such as when the Crypto-Binding TLV fails validation, the error code is Tunnel Compromise Error.
暗号バインディング TLV の検証に失敗した場合など、トンネル侵害に関連するエラーの場合、エラー コードはトンネル侵害エラーです。
Non-Fatal Error due to Inner Method:
内部メソッドによる致命的ではないエラー:
If there is a non-fatal error while running the Inner Method, the receiving side SHOULD NOT silently drop the Inner Method exchange. Instead, it SHOULD reply with an Error TLV using the most descriptive error code possible.
内部メソッドの実行中に致命的ではないエラーが発生した場合、受信側は内部メソッド交換をサイレントにドロップしてはなりません (SHOULD NOT)。代わりに、可能な限り最もわかりやすいエラー コードを使用して、エラー TLV で応答する必要があります (SHOULD)。
If there is no error code that matches the particular issue, then the value Inner Method Error (1001) SHOULD be used. This response is a positive indication that there was an error processing the current Inner Method. The side receiving a non-fatal Error TLV MAY decide to start a new and different Inner Method instead or send back a Result TLV to terminate the TEAP authentication session.
特定の問題に一致するエラー コードがない場合は、値 Inner Method Error (1001) を使用する必要があります (SHOULD)。この応答は、現在の内部メソッドの処理中にエラーがあったことを明確に示しています。致命的ではないエラー TLV を受信した側は、代わりに新しい異なる内部メソッドを開始するか、結果 TLV を送り返して TEAP 認証セッションを終了することを決定してもよい(MAY)。
Fragmentation of EAP packets is discussed in [RFC5216], Section 2.1.5. There is no special handling of fragments for TEAP.
EAP パケットの断片化については、[RFC5216] のセクション 2.1.5 で説明されています。TEAP のフラグメントには特別な処理はありません。
Several TEAP operations, including server unauthenticated provisioning, certificate provisioning, and channel binding, depend on the peer trusting the TEAP server. If the peer trusts the provided server certificate, then the server is authenticated.
サーバー非認証プロビジョニング、証明書プロビジョニング、チャネル バインディングなどのいくつかの TEAP 操作は、TEAP サーバーを信頼するピアに依存します。ピアが提供されたサーバー証明書を信頼する場合、サーバーは認証されます。
Typically, this authentication process involves the peer validating the certificate to a trust anchor by verifying that the server presenting the certificate holds the private key and confirming that the entity named by the certificate is the intended server. Server authentication also occurs when the procedures in Section 3.2 are used to resume a session where the peer and server were previously mutually authenticated. Alternatively, the server is deemed to be authenticated if an inner EAP method provides mutual authentication along with an MSK and/or EMSK. The Inner Method MUST also provide for cryptographic binding via the Compound Message Authentication Code (MAC), as discussed in Section 4.2.13. This issue is further described in Section 3.11.3.
通常、この認証プロセスには、証明書を提示するサーバーが秘密キーを保持していることを確認し、証明書によって指定されたエンティティが目的のサーバーであることを確認することによって、トラスト アンカーに対して証明書を検証するピアが含まれます。サーバー認証は、ピアとサーバーが以前に相互認証されていたセッションを再開するためにセクション 3.2 の手順を使用するときにも行われます。あるいは、内部 EAP メソッドが MSK や EMSK とともに相互認証を提供する場合、サーバーは認証されているとみなされます。内部メソッドは、セクション 4.2.13 で説明したように、複合メッセージ認証コード (MAC) を介した暗号化バインディングも提供しなければなりません (MUST)。この問題については、セクション 3.11.3 で詳しく説明します。
TEAP peers MUST track whether or not server authentication has taken place. When the server cannot be authenticated, the peer MUST NOT request any services such as certificate provisioning (Section 3.11.1) from it.
TEAP ピアは、サーバー認証が行われたかどうかを追跡しなければなりません (MUST)。サーバーが認証できない場合、ピアはサーバーに対して証明書プロビジョニング (セクション 3.11.1) などのサービスを要求してはなりません (MUST NOT)。
Unless the peer requests server unauthenticated provisioning, it MUST authenticate the server and fail the current authentication session. The authentication session fails if the server cannot be authenticated.
ピアがサーバーの非認証プロビジョニングを要求しない限り、サーバーを認証し、現在の認証セッションに失敗しなければなりません。サーバーを認証できない場合、認証セッションは失敗します。
An additional complication arises when an Inner Method authenticates multiple parties, such as authenticating both the peer machine and the peer user to the EAP server. Depending on how authentication is achieved, only some of these parties may have confidence in it. For example, if a strong shared secret is used to mutually authenticate the user and the EAP server, the machine may not have confidence that the EAP server is the authenticated party if the machine cannot trust the user not to disclose the shared secret to an attacker. In these cases, the parties who participate in the authentication need to be considered when evaluating whether the peer should request these services or whether the server should provide them.
EAP サーバーに対してピア マシンとピア ユーザーの両方を認証するなど、内部メソッドが複数の当事者を認証する場合、さらに複雑な問題が発生します。認証の方法によっては、一部の当事者のみが認証を信頼できる場合があります。たとえば、強力な共有秘密を使用してユーザーと EAP サーバーを相互認証する場合、ユーザーが共有秘密を攻撃者に開示しないことをマシンが信頼できない場合、マシンは EAP サーバーが認証された当事者であるという確信を持てない可能性があります。このような場合、ピアがこれらのサービスを要求すべきか、サーバーがサービスを提供すべきかを評価するときに、認証に参加する当事者を考慮する必要があります。
The server MUST also authenticate the peer before providing these services. The alternative is to send provisioning data to unauthenticated and potentially malicious peers, which can have negative impacts on security.
サーバーは、これらのサービスを提供する前にピアを認証しなければなりません (MUST)。代替案は、認証されていない潜在的に悪意のあるピアにプロビジョニング データを送信することですが、これはセキュリティに悪影響を与える可能性があります。
When a device is provisioned via TEAP, any subsequent authorization MUST be done on the authenticated credentials. That is, there may be no credentials (or anonymous credentials) passed in Phase 1, but there will be credentials passed or provisioned in Phase 2. If later authorizations are done on the Phase 1 identity, then a device could obtain the wrong authorization. If authorization is done on the authenticated credentials instead, then the device will obtain the correct kind of network access.
デバイスが TEAP 経由でプロビジョニングされる場合、その後の承認は認証された資格情報に基づいて行われなければなりません (MUST)。つまり、フェーズ 1 では認証情報 (または匿名の認証情報) が渡されない可能性がありますが、フェーズ 2 では認証情報が渡されるか、プロビジョニングされます。 その後の承認がフェーズ 1 の ID に対して行われる場合、デバイスは間違った認証を取得する可能性があります。代わりに、認証された資格情報に対して認可が行われる場合、デバイスは正しい種類のネットワーク アクセスを取得します。
The correct authorization must also be applied to any resumption, as noted in [RFC9190], Section 5.7. However, as it is possible in TEAP for the credentials to change, the new credentials MUST be associated with the session ticket. If this association cannot be done, then the server MUST invalidate any session tickets for the current session. This invalidation will force a full re-authentication on any subsequent connection; at which point, the correct authorization will be associated with any session ticket.
[RFC9190] のセクション 5.7 に記載されているように、正しい許可はあらゆる再開にも適用されなければなりません。ただし、TEAP では資格情報が変更される可能性があるため、新しい資格情報をセッション チケットに関連付ける必要があります。この関連付けができない場合、サーバーは現在のセッションのセッション チケットを無効にしなければなりません (MUST)。この無効化により、後続の接続で完全な再認証が強制されます。この時点で、正しい認証がセッション チケットに関連付けられます。
Note that the act of re-provisioning a device is essentially indistinguishable from any initial provisioning. The device authenticates and obtains new credentials via the standard provisioning mechanisms. The only caveat is that the device SHOULD NOT discard the old credentials unless either they are known to have expired or the new credentials have been verified to work.
デバイスを再プロビジョニングする行為は、基本的に最初のプロビジョニングと区別できないことに注意してください。デバイスは標準のプロビジョニング メカニズムを介して認証し、新しい認証情報を取得します。唯一の注意点は、有効期限が切れていることが判明しているか、新しい認証情報が機能することが確認されていない限り、デバイスは古い認証情報を破棄すべきではないということです。
Provisioning of a peer's certificate is supported in TEAP by performing the Simple PKI Request/Response from [RFC5272] using PKCS#10 and PKCS#7 TLVs, respectively. A peer sends the Simple PKI Request using a PKCS#10 CertificationRequest [RFC2986] encoded into the body of a PKCS#10 TLV (see Section 4.2.17). The TEAP server issues a Simple PKI Response using a PKCS#7 [RFC2315] unsigned (i.e., degenerate) "Certificates Only" message encoded into the body of a PKCS#7 TLV (see Section 4.2.16) only after an Inner Method has run and provided an identity proof on the peer prior to a certificate is being issued.
ピアの証明書のプロビジョニングは、それぞれ PKCS#10 および PKCS#7 TLV を使用して [RFC5272] の Simple PKI 要求/応答を実行することによって、TEAP でサポートされます。ピアは、PKCS#10 TLV の本文にエンコードされた PKCS#10 CertificationRequest [RFC2986] を使用して、Simple PKI Request を送信します (セクション 4.2.17 を参照)。TEAP サーバーは、内部メソッドが実行され、証明書が発行される前にピアに ID 証明を提供した後でのみ、PKCS#7 TLV (セクション 4.2.16 を参照) の本文にエンコードされた PKCS#7 [RFC2315] の未署名 (つまり縮退) 「証明書のみ」メッセージを使用して簡易 PKI 応答を発行します。
In order to provide linking identity and proof-of-possession by including information specific to the current authenticated TLS session within the signed certification request, the peer generating the request SHOULD obtain the tls-unique value from the TLS subsystem as defined in "Channel Bindings for TLS" [RFC5929]. The TEAP peer operations between obtaining the tls-unique value through generation of the Certification Signing Request (CSR) that contains the current tls-unique value and the subsequent verification of this value by the TEAP server are the "phases of the application protocol during which application-layer authentication occurs" that are protected by the synchronization interoperability mechanism described in the interoperability note in "Channel Bindings for TLS" ([RFC5929], Section 3.1). When performing renegotiation, TLS "secure_renegotiation" [RFC5746] MUST be used.
署名された認証リクエスト内に現在認証されている TLS セッションに固有の情報を含めることによって、リンク ID と所有証明を提供するために、リクエストを生成するピアは、「TLS のチャネル バインディング」[RFC5929] で定義されているように、TLS サブシステムから tls 固有の値を取得する必要があります (SHOULD)。現在の tls 固有値を含む証明書署名要求 (CSR) の生成による tls 固有値の取得と、それに続く TEAP サーバーによるこの値の検証の間の TEAP ピア操作は、「TLS のチャネル バインディング」([RFC5929]、セクション3.1)。再ネゴシエーションを実行するときは、TLS "secure_renegotiation" [RFC5746] を使用しなければなりません (MUST)。
The tls-unique value is base-64-encoded as specified in Section 4 of [RFC4648], and the resulting string is placed in the certification request challengePassword field ([RFC2985], Section 5.4.1). The challengePassword field is limited to 255 octets (Section 7.4.9 of [RFC5246] indicates that no existing cipher suite would result in an issue with this limitation). If tls-unique information is not embedded within the certification request, the challengePassword field MUST be empty to indicate that the peer did not include the optional channel-binding information (any value submitted is verified by the server as tls-unique information).
tls 固有の値は、[RFC4648] のセクション 4 で指定されているように Base-64 でエンコードされ、その結果の文字列が認証要求のChallengePassword フィールドに配置されます ([RFC2985]、セクション 5.4.1)。ChallengePassword フィールドは 255 オクテットに制限されています ([RFC5246] のセクション 7.4.9 は、既存の暗号スイートがこの制限の問題を引き起こすことはないことを示しています)。tls 固有の情報が認証リクエスト内に埋め込まれていない場合、ピアにオプションのチャネル バインディング情報が含まれていないことを示すために、challengePassword フィールドは空でなければなりません (送信された値はすべて、tls 固有の情報としてサーバーによって検証されます)。
The server SHOULD verify the tls-unique information. This ensures that the signed certificate request is being presented by an authenticated TEAP peer that is in possession of the private key.
サーバーは tls 固有の情報を検証する必要があります (SHOULD)。これにより、署名付き証明書要求が、秘密キーを所有する認証された TEAP ピアによって提示されることが保証されます。
The Simple PKI Request/Response generation and processing rules of [RFC5272] SHALL apply to TEAP, with the exception of error conditions. In the event of an error, the TEAP server SHOULD respond with an Error TLV using the most descriptive error code possible; it MAY ignore the PKCS#10 request that generated the error.
[RFC5272] の Simple PKI 要求/応答の生成および処理規則は、エラー条件を除いて TEAP に適用されます (SHALL)。エラーが発生した場合、TEAP サーバーは可能な限り最もわかりやすいエラー コードを使用してエラー TLV で応答する必要があります (SHOULD)。エラーを生成した PKCS#10 リクエストを無視してもよい(MAY)。
It is not enough to verify that the CSR provided by the peer to the authenticator is from an authenticated user. The CSR itself should also be examined by the authenticator or CA before any certificate is issued.
ピアによって認証システムに提供された CSR が認証されたユーザーからのものであることを検証するだけでは十分ではありません。CSR 自体も、証明書が発行される前に認証者または CA によって検査される必要があります。
The format of a CSR is complex and contains a substantial amount of information. That information could be incorrect, such as a user claiming a wrong physical address, email address, etc. It is RECOMMENDED that systems provisioning these certificates validate that the CSR contains the expected data and that it does not contain unexpected data. For example, a CA could refuse to issue the certificate if the CSR contained unknown fields or if a known field contained an unexpected or invalid value. The CA can modify or refuse a particular CSR to address these deficiencies for any reasons, including local site policy. We note that the "A" in "CA" means for "Authority", while the "R" in "CSR" means "Request". There is no requirement for a CA to sign any and all CSRs that are presented to it.
CSR の形式は複雑で、大量の情報が含まれています。その情報は、ユーザーが間違った物理アドレスや電子メール アドレスなどを主張しているなど、間違っている可能性があります。これらの証明書をプロビジョニングするシステムは、CSR に予期されるデータが含まれていること、および予期しないデータが含まれていないことを検証することが推奨されます。たとえば、CSR に未知のフィールドが含まれている場合、または既知のフィールドに予期しない値または無効な値が含まれている場合、CA は証明書の発行を拒否する可能性があります。CA は、ローカル サイト ポリシーなどの理由を問わず、これらの欠陥に対処するために特定の CSR を変更または拒否できます。「CA」の「A」は「権限」を意味し、「CSR」の「R」は「リクエスト」を意味します。CA は、提示されたすべての CSR に署名する必要はありません。
Once an EAP peer receives the signed certificate, the peer could potentially be (ab)used for in TLS contexts other than TEAP. For example, the certificate could be used with EAP-TLS, or even with HTTPS. It is NOT RECOMMENDED to use certificates provisioned via TEAP for any non-TEAP. One method of enforcing this restriction is to have different CAs (or different intermediate CAs) that issue certificates for different uses. For example, TLS-based EAP methods could share one CA, and even use different intermediary CAs for different TLS-based EAP methods. HTTPS servers could use an entirely different CA. The different protocols could then be configured to validate client certificates only from their preferred CA, which would prevent peers from using certificates outside of the intended use case.
EAP ピアが署名付き証明書を受信すると、そのピアは TEAP 以外の TLS コンテキストで（悪用）される可能性があります。たとえば、証明書は EAP-TLS で使用したり、HTTPS で使用したりすることもできます。TEAP 以外の証明書に対して TEAP 経由でプロビジョニングされた証明書を使用することは推奨されません。この制限を強制する 1 つの方法は、さまざまな用途に証明書を発行するさまざまな CA (またはさまざまな中間 CA) を用意することです。たとえば、TLS ベースの EAP メソッドは 1 つの CA を共有し、異なる TLS ベースの EAP メソッドに対して異なる中間 CA を使用することもできます。HTTPS サーバーはまったく異なる CA を使用する可能性があります。その後、さまざまなプロトコルを、優先 CA からのクライアント証明書のみを検証するように構成できます。これにより、ピアが意図された使用例以外の証明書を使用することを防ぐことができます。
Another method of limiting the uses of a certificate is to provision it with an appropriate value for the Extended Key Purpose field [RFC7299]. For example, the id-kp-eapOverLAN [RFC4334] value could be used to indicate that this certificate is intended for use only with EAP.
証明書の使用を制限するもう 1 つの方法は、Extended Key Purpose フィールドに適切な値を指定して証明書をプロビジョニングすることです [RFC7299]。たとえば、id-kp-eapOverLAN [RFC4334] 値を使用して、この証明書が EAP でのみ使用することを意図していることを示すことができます。
It is difficult to give more detailed recommendations than the above. Each CA or organization may have its own local policy as to what is permitted or forbidden in a certificate. All we can do in this document is to highlight the issues and make the reader aware that they have to be addressed.
上記より詳細な推奨事項を提供することは困難です。各 CA または組織には、証明書で何が許可されるか、何が禁止されるかについて独自のローカル ポリシーがある場合があります。この文書で私たちにできることは、問題を強調し、それらに対処する必要があることを読者に認識させることだけです。
In Server Unauthenticated Provisioning Mode, an unauthenticated tunnel is established in Phase 1, and the peer and server negotiate an Inner Method or methods in Phase 2. This Inner Method MUST support mutual authentication, provide key derivation, and be resistant to attacks such as on-path and dictionary attacks. In most cases, this Inner Method will be an EAP authentication method. Example Inner Methods that satisfy these criteria include EAP-pwd [RFC5931] and EAP-EKE [RFC6124] but not EAP-FAST-MSCHAPv2.
サーバー非認証プロビジョニング モードでは、非認証トンネルがフェーズ 1 で確立され、ピアとサーバーはフェーズ 2 で内部メソッドをネゴシエートします。この内部メソッドは、相互認証をサポートし、キー導出を提供し、オンパス攻撃や辞書攻撃などの攻撃に耐性がなければなりません (MUST)。ほとんどの場合、この内部メソッドは EAP 認証メソッドになります。これらの基準を満たす内部メソッドの例には、EAP-pwd [RFC5931] および EAP-EKE [RFC6124] が含まれますが、EAP-FAST-MSCHAPv2 は含まれません。
This provisioning mode enables the bootstrapping of peers when the peer lacks the ability to authenticate the server during Phase 1. This includes both cases in which the cipher suite negotiated does not provide authentication and in which the cipher suite negotiated provides the authentication, but the peer is unable to validate the identity of the server for some reason.
このプロビジョニング モードでは、フェーズ 1 でピアにサーバーを認証する機能がない場合に、ピアのブートストラップが有効になります。これには、ネゴシエートされた暗号スイートが認証を提供しない場合と、ネゴシエートされた暗号スイートが認証を提供するが、ピアが何らかの理由でサーバーの ID を検証できない場合の両方が含まれます。
Upon successful completion of the Inner Method in Phase 2, the peer and server exchange a Crypto-Binding TLV to bind the Inner Method with the outer tunnel and ensure that an on-path attack has not been attempted.
フェーズ 2 の内部メソッドが正常に完了すると、ピアとサーバーは暗号バインディング TLV を交換して、内部メソッドを外部トンネルにバインドし、パス上攻撃が試行されていないことを確認します。
Support for the Server Unauthenticated Provisioning Mode is optional. The cipher suite TLS_DH_anon_WITH_AES_128_CBC_SHA is RECOMMENDED when using Server Unauthenticated Provisioning Mode, but other anonymous cipher suites MAY be supported as long as the TLS pre-master secret is generated from contribution from both peers.
サーバー非認証プロビジョニング モードのサポートはオプションです。サーバー非認証プロビジョニング モードを使用する場合、暗号スイート TLS_DH_anon_WITH_AES_128_CBC_SHA が推奨されます (RECOMMENDED) が、TLS プリマスター シークレットが両方のピアからの貢献から生成される限り、他の匿名暗号スイートもサポートされてもよい (MAY)。
When a strong Inner Method is not used with Server Unauthenticated Provisioning Mode, it is possible for an attacker to perform an on-path attack. In effect, Server Unauthenticated Provisioning Mode has similar security issues as just running the Inner Method in the open without the protection of TLS. All of the information in the tunnel should be assumed to be visible to, and modifiable by, an attacker.
サーバー非認証プロビジョニング モードで強力な内部メソッドが使用されていない場合、攻撃者がオンパス攻撃を実行する可能性があります。実際、サーバー非認証プロビジョニング モードには、TLS の保護なしで内部メソッドをオープンで実行する場合と同様のセキュリティ問題があります。トンネル内のすべての情報は攻撃者に表示され、変更可能であると想定する必要があります。
Implementations SHOULD exchange minimal data in Server Unauthenticated Provisioning Mode. Instead, they should use that mode to set up a secure/authenticated tunnel and then use that tunnel to perform any needed data exchange.
実装では、サーバー非認証プロビジョニング モードで最小限のデータを交換する必要があります。代わりに、そのモードを使用して安全な/認証されたトンネルを設定し、そのトンネルを使用して必要なデータ交換を実行する必要があります。
It is RECOMMENDED that client implementations and deployments authenticate TEAP servers if at all possible. Authenticating the server means that a client can be provisioned securely with no chance of an attacker eaves-dropping on the connection.
可能であれば、クライアントの実装と展開で TEAP サーバーを認証することが推奨されます。サーバーを認証するということは、攻撃者が接続を盗聴する可能性がなく、クライアントを安全にプロビジョニングできることを意味します。
Note that server unauthenticated provisioning can only use anonymous cipher suites in TLS 1.2 and earlier. These cipher suites have been deprecated in TLS 1.3 ([RFC8446], Appendix C.5). For TLS 1.3, the server MUST provide a certificate, and the peer performs server unauthenticated provisioning by not validating the certificate chain or any of its contents.
サーバーの非認証プロビジョニングでは、TLS 1.2 以前の匿名暗号スイートのみを使用できることに注意してください。これらの暗号スイートは、TLS 1.3 ([RFC8446]、付録 C.5) で非推奨になりました。TLS 1.3 の場合、サーバーは証明書を提供しなければならず、ピアは証明書チェーンまたはその内容を検証せずにサーバーの非認証プロビジョニングを実行します。
[RFC6677] defines channel bindings for EAP that solve the "lying NAS" and the "lying provider" problems, using a process in which the EAP peer gives information about the characteristics of the service provided by the authenticator to the Authentication, Authorization, and Accounting (AAA) server protected within the EAP authentication method. This allows the server to verify the authenticator is providing information to the peer that is consistent with the information received from this authenticator as well as the information stored about this authenticator.
[RFC6677] は、EAP ピアが、認証システムによって提供されるサービスの特性に関する情報を、EAP 認証方式内で保護されている認証、認可、およびアカウンティング (AAA) サーバーに提供するプロセスを使用して、「嘘つき NAS」および「嘘つきプロバイダー」問題を解決する EAP のチャネル バインディングを定義しています。これにより、サーバーは、オーセンティケータが、このオーセンティケータから受信した情報およびこのオーセンティケータについて保存されている情報と一致する情報をピアに提供していることを検証できます。
TEAP supports EAP channel binding using the Channel-Binding TLV defined in Section 4.2.7. If the TEAP server wants to request the channel-binding information from the peer, it sends an empty Channel-Binding TLV to indicate the request. The peer responds to the request by sending a Channel-Binding TLV containing a channel-binding message as defined in [RFC6677]. The server validates the channel-binding message and sends back a Channel-Binding TLV with a result code. If the server did not initiate the channel-binding request and the peer still wants to send the channel-binding information to the server, it can do that by using the Request-Action TLV along with the Channel-Binding TLV. The peer MUST only send channel-binding information after it has successfully authenticated the server and established the protected tunnel.
TEAP は、セクション 4.2.7 で定義されている Channel-Binding TLV を使用して EAP チャネル バインディングをサポートします。TEAP サーバーがピアからチャネル バインディング情報を要求したい場合は、空のチャネル バインディング TLV を送信して要求を示します。ピアは、[RFC6677] で定義されているチャネル バインディング メッセージを含む Channel-Binding TLV を送信することでリクエストに応答します。サーバーはチャネル バインディング メッセージを検証し、結果コードを含むチャネル バインディング TLV を送り返します。サーバーがチャネル バインディング リクエストを開始せず、ピアが依然としてチャネル バインディング情報をサーバーに送信したい場合、リクエスト アクション TLV とチャネル バインディング TLV を使用してそれを行うことができます。ピアは、サーバーの認証に成功し、保護されたトンネルを確立した後にのみ、チャネル バインディング情報を送信しなければなりません (MUST)。
The following sections describe the message formats used in TEAP. The fields are transmitted from left to right in network byte order.
次のセクションでは、TEAP で使用されるメッセージ形式について説明します。フィールドは、ネットワーク バイト オーダーで左から右に送信されます。
A summary of the TEAP Request/Response packet format is shown below.
TEAP 要求/応答パケットのフォーマットの概要を以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Ver | Message Length :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Message Length | Outer TLV Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Outer TLV Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
コード
The Code field is one octet in length and is defined as follows:
コード フィールドの長さは 1 オクテットで、次のように定義されます。
1
1
Request
リクエスト
2
2
Response
応答
Identifier
識別子
The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed on each Request packet. The Identifier field in the Response packet MUST match the Identifier field from the corresponding request.
識別子フィールドは 1 オクテットで、応答と要求を照合するのに役立ちます。識別子フィールドは、リクエストパケットごとに変更しなければなりません(MUST)。応答パケットの識別子フィールドは、対応するリクエストの識別子フィールドと一致しなければなりません。
Length
長さ
The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, Flags, Ver, Message Length, TLS Data, and Outer TLVs fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception.
長さフィールドは 2 オクテットで、コード、識別子、長さ、タイプ、フラグ、Ver、メッセージ長、TLS データ、および外部 TLV フィールドを含む EAP パケットの長さを示します。長さフィールドの範囲外のオクテットはデータリンク層のパディングとして扱われ、受信時に無視される必要があります。
Type
タイプ
55 for TEAP
TEAPの場合は55
Flags
フラグ
0 1 2 3 4
+-+-+-+-+-+
|L M S O R|
+-+-+-+-+-+
L
L
Length included; set to indicate the presence of the four-octet Message Length field. It MUST be present for the first fragment of a fragmented message. It MUST NOT be present for any other message.
長さは含まれています。4 オクテットのメッセージ長フィールドの存在を示すように設定されます。これは、断片化されたメッセージの最初の断片に存在する必要があります。他のメッセージには存在してはなりません。
M
M
More fragments; set on all but the last fragment.
さらなる断片。最後のフラグメントを除くすべてのフラグメントに設定します。
S
S
TEAP start; set in a TEAP Start message sent from the server to the peer.
TEAP 開始;サーバーからピアに送信される TEAP 開始メッセージで設定されます。
O
○
Outer TLV length included; set to indicate the presence of the four-octet Outer TLV Length field. It MUST be present only in the initial request and response messages. If the initial message is fragmented, then it MUST be present only on the first fragment.
外側の TLV 長が含まれます。4 オクテットの外部 TLV 長フィールドの存在を示すように設定されます。これは、最初の要求メッセージと応答メッセージにのみ存在しなければなりません (MUST)。最初のメッセージが断片化されている場合、それは最初の断片にのみ存在しなければなりません。
R
R
Reserved (MUST be zero and ignored upon receipt)
予約済み (ゼロにする必要があり、受信時に無視されます)
Ver
バージョン
This field contains the version of the protocol. This document describes version 1 (001 in binary) of TEAP.
このフィールドにはプロトコルのバージョンが含まれます。この文書では、TEAP のバージョン 1 (バイナリで 001) について説明します。
Message Length
メッセージの長さ
The Message Length field is four octets and is present only if the L bit is set. This field provides the total length of the message that may be fragmented over the data fields of multiple packets.
メッセージ長フィールドは 4 オクテットで、L ビットが設定されている場合にのみ存在します。このフィールドは、複数のパケットのデータ フィールドにわたって断片化される可能性があるメッセージの全長を提供します。
Outer TLV Length
外側のTLVの長さ
The Outer TLV Length field is four octets and is present only if the O bit is set. This field provides the total length of the Outer TLVs if present.
外部 TLV 長フィールドは 4 オクテットで、O ビットが設定されている場合にのみ存在します。このフィールドは、アウター TLV が存在する場合、その全長を提供します。
TLS Data
TLSデータ
When the TLS Data field is present, it consists of an encapsulated TLS packet in TLS record format. A TEAP packet with Flags and Version fields, but with zero length TLS Data field, is used to indicate TEAP acknowledgment for either a fragmented message, a TLS Alert message, or a TLS Finished message.
TLS データ フィールドが存在する場合、これは TLS レコード形式でカプセル化された TLS パケットで構成されます。Flags フィールドと Version フィールドを持ち、長さ 0 の TLS Data フィールドを持つ TEAP パケットは、断片化されたメッセージ、TLS アラート メッセージ、または TLS Finished メッセージのいずれかに対する TEAP 確認応答を示すために使用されます。
Outer TLVs
外部TLV
The Outer TLVs consist of the optional data used to help establish the TLS tunnel in TLV format. They are only allowed in the first two messages in the TEAP. That is the first EAP-server-to-peer message and first peer-to-EAP-server message. The start of the Outer TLVs can be derived from the EAP Length field and Outer TLV Length field.
アウター TLV は、TLV 形式で TLS トンネルを確立するために使用されるオプションのデータで構成されます。これらは、TEAP の最初の 2 つのメッセージでのみ許可されます。これは、最初の EAP サーバーからピアへのメッセージと最初のピアから EAP サーバーへのメッセージです。アウター TLV の開始は、EAP 長フィールドとアウター TLV 長フィールドから導き出すことができます。
The TLVs defined here are TLV objects. The TLV objects could be used to carry arbitrary parameters between an EAP peer and EAP server within the protected TLS tunnel.
ここで定義される TLV は TLV オブジェクトです。TLV オブジェクトは、保護された TLS トンネル内の EAP ピアと EAP サーバーの間で任意のパラメータを伝達するために使用される可能性があります。
The EAP peer may not necessarily implement all the TLVs supported by the EAP server. To allow for interoperability, TLVs are designed to allow an EAP server to discover if a TLV is supported by the EAP peer using the NAK TLV. The mandatory bit in a TLV indicates whether support of the TLV is required. If the peer or server does not support a TLV marked mandatory, then it MUST send a NAK TLV in the response, and all the other TLVs in the message MUST be ignored. If an EAP peer or server finds an unsupported TLV that is marked as optional, it can ignore the unsupported TLV. It MUST only send a NAK TLV for a TLV that is marked mandatory but is not understood and MUST NOT otherwise send a NAK TLV. If all TLVs in a message are marked optional and none are understood by the peer, then a Result TLV SHOULD be sent to the other side in order to continue the conversation. It is also possible to send a NAK TLV when all TLVs in a message are marked optional.
EAP ピアは、EAP サーバーによってサポートされるすべての TLV を必ずしも実装するとは限りません。相互運用性を可能にするために、TLV は、EAP サーバーが NAK TLV を使用して TLV が EAP ピアによってサポートされているかどうかを検出できるように設計されています。TLV の必須ビットは、TLV のサポートが必要かどうかを示します。ピアまたはサーバーが必須とマークされた TLV をサポートしていない場合は、応答で NAK TLV を送信しなければならず (MUST)、メッセージ内の他のすべての TLV は無視されなければなりません (MUST)。EAP ピアまたはサーバーは、オプションとしてマークされているサポートされていない TLV を検出した場合、そのサポートされていない TLV を無視できます。必須とマークされているが理解されていない TLV に対してのみ NAK TLV を送信しなければならず (MUST)、それ以外の場合は NAK TLV を送信してはなりません (MUST)。メッセージ内のすべての TLV がオプションとしてマークされており、ピアが理解できるものがない場合、会話を継続するために結果 TLV を相手側に送信する必要があります (SHOULD)。メッセージ内のすべての TLV がオプションとしてマークされている場合、NAK TLV を送信することもできます。
Note that a peer or server may support a TLV with the mandatory bit set but may not understand the contents. The appropriate response to a supported TLV with content that is not understood is defined by the individual TLV specification.
ピアまたはサーバーは、必須ビットが設定された TLV をサポートしている可能性がありますが、内容を理解できない場合があることに注意してください。理解できないコンテンツを含むサポートされている TLV に対する適切な応答は、個々の TLV 仕様によって定義されます。
EAP implementations compliant with this specification MUST support TLV exchanges as well as the processing of mandatory/optional settings on the TLV. Implementations conforming to this specification MUST support the following TLVs:
この仕様に準拠する EAP 実装は、TLV 交換および TLV 上の必須/オプション設定の処理をサポートしなければなりません (MUST)。この仕様に準拠する実装は、次の TLV をサポートしなければなりません。
* Authority-ID TLV
* 権限ID TLV
* Identity-Type TLV
* ID タイプ TLV
* Result TLV
* 結果TLV
* NAK TLV
* NAK TLV
* Error TLV
* エラーTLV
* Request-Action TLV
* リクエストアクションTLV
* EAP-Payload TLV
* EAP ペイロード TLV
* Intermediate-Result TLV
* 中間結果 TLV
* Crypto-Binding TLV
* 暗号バインディング TLV
* Basic-Password-Auth-Req TLV
* 基本パスワード認証要求 TLV
* Basic-Password-Auth-Resp TLV
* 基本パスワード認証応答 TLV
TLVs are defined as described below. The fields are transmitted from left to right.
TLV は以下のように定義されます。フィールドは左から右に送信されます。
If a peer or server receives a TLV that is not of the correct format, the TLV MUST be discarded. It is generally useful to log an error or debugging message that indicates which TLV had an issue and what the problem is. However, TLVs that are malformed are invalid and cannot be used.
ピアまたはサーバーが正しい形式ではない TLV を受信した場合、その TLV は破棄されなければなりません (MUST)。一般に、どの TLV に問題があり、その問題が何であるかを示すエラーまたはデバッグ メッセージをログに記録すると便利です。ただし、形式が不正な TLV は無効であるため、使用できません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0
0
Optional TLV
オプションのTLV
1
1
Mandatory TLV
必須のTLV
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
A 14-bit field, denoting the TLV type. Allocated types include:
TLV タイプを示す 14 ビットのフィールド。割り当てられるタイプには次のものがあります。
0
0
Unassigned
未割り当て
1
1
Authority-ID TLV (Section 4.2.2)
機関 ID TLV (セクション 4.2.2)
2
2
Identity-Type TLV (Section 4.2.3)
ID タイプ TLV (セクション 4.2.3)
3
3
Result TLV (Section 4.2.4)
結果 TLV (セクション 4.2.4)
4
4
NAK TLV (Section 4.2.5)
NAK TLV (セクション 4.2.5)
5
5
Error TLV (Section 4.2.6)
エラー TLV (セクション 4.2.6)
6
6
Channel-Binding TLV (Section 4.2.7)
チャネルバインディング TLV (セクション 4.2.7)
7
7
Vendor-Specific TLV (Section 4.2.8)
ベンダー固有の TLV (セクション 4.2.8)
8
8
Request-Action TLV (Section 4.2.9)
リクエスト-アクション TLV (セクション 4.2.9)
9
9
EAP-Payload TLV (Section 4.2.10)
EAP ペイロード TLV (セクション 4.2.10)
10
10
Intermediate-Result TLV (Section 4.2.11)
中間結果 TLV (セクション 4.2.11)
11
11
PAC TLV (DEPRECATED)
PAC TLV (非推奨)
12
12
Crypto-Binding TLV (Section 4.2.13)
暗号バインディング TLV (セクション 4.2.13)
13
13
Basic-Password-Auth-Req TLV (Section 4.2.14)
基本パスワード認証要求 TLV (セクション 4.2.14)
14
14
Basic-Password-Auth-Resp TLV (Section 4.2.15)
基本パスワード認証応答 TLV (セクション 4.2.15)
15
15
PKCS#7 TLV (Section 4.2.16)
PKCS#7 TLV (セクション 4.2.16)
16
16
PKCS#10 TLV (Section 4.2.17)
PKCS#10 TLV (セクション 4.2.17)
17
17
Trusted-Server-Root TLV (Section 4.2.18)
トラステッドサーバールート TLV (セクション 4.2.18)
18
18
CSR-Attributes TLV (Section 4.2.19)
CSR 属性 TLV (セクション 4.2.19)
19
19
Identity-Hint TLV (Section 4.2.20)
ID ヒント TLV (セクション 4.2.20)
Length
長さ
The length of the Value field in octets.
オクテット単位の値フィールドの長さ。
Value
価値
The value of the TLV.
TLV の値。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Optional TLV
0 - オプションの TLV
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
1 - Authority-ID
1 - 権限ID
Length
長さ
The Length field is two octets and contains the length of the ID field in octets.
長さフィールドは 2 オクテットで、ID フィールドの長さがオクテット単位で含まれます。
ID
ID
Hint of the identity of the server to help the peer to match the credentials available for the server. It should be unique across the deployment.
ピアがサーバーで利用可能な資格情報を照合するのに役立つサーバーの ID のヒント。これはデプロイメント全体で一意である必要があります。
The Identity-Type TLV allows an EAP server to send a hint to help the EAP peer select the right type of identity, for example, user or machine. TEAPv1 implementations MUST support this TLV. Only one Identity-Type TLV SHOULD be present in the TEAP request or response packet.
ID タイプ TLV を使用すると、EAP サーバーは、EAP ピアが適切なタイプの ID (ユーザーやマシンなど) を選択するのに役立つヒントを送信できます。TEAPv1 実装は、この TLV をサポートしなければなりません。TEAP 要求または応答パケットには、Identity-Type TLV が 1 つだけ存在する必要があります (SHOULD)。
A server sending the Identity-Type TLV MUST also include an EAP-Payload TLV or a Basic-Password-Auth-Resp TLV. A peer sending an Identity-Type TLV MUST also include EAP-Payload TLV or a Basic-Password-Auth-Resp TLV.
Identity-Type TLV を送信するサーバーには、EAP-Payload TLV または Basic-Password-Auth-Resp TLV も含めなければなりません (MUST)。Identity-Type TLV を送信するピアには、EAP-Payload TLV または Basic-Password-Auth-Resp TLV も含めなければなりません (MUST)。
An EAP peer receiving an Identity-Type request SHOULD respond with an Identity-Type TLV with the requested type. If the Identity-Type field does not contain one of the known values, or if the EAP peer does not have an identity corresponding to the identity type requested, then the peer SHOULD respond with an Identity-Type TLV with the one of available identity types.
Identity-Type 要求を受信した EAP ピアは、要求されたタイプの Identity-Type TLV で応答する必要があります (SHOULD)。Identity-Type フィールドに既知の値が含まれていない場合、または EAP ピアが要求された ID タイプに対応する ID を持たない場合、ピアは利用可能な ID タイプの 1 つを含む Identity-Type TLV で応答する必要があります (SHOULD)。
A server receiving an Identity-Type in the response MUST check if the value of the Identity-Type in the response matches the value of the Identity-Type that was sent in the request. A match means that the server can proceed with authentication.
応答で Identity-Type を受信したサーバーは、応答での Identity-Type の値がリクエストで送信された Identity-Type の値と一致するかどうかを確認しなければなりません (MUST)。一致した場合は、サーバーが認証を続行できることを意味します。
However, if the values do not match, the server can proceed with authentication if and only if the following two conditions match. If either of the following two conditions does not match, the server MUST respond with a Result TLV of Failure.
ただし、値が一致しない場合、サーバーは次の 2 つの条件が一致する場合にのみ認証を続行できます。次の 2 つの条件のいずれかが一致しない場合、サーバーは失敗の結果 TLV で応答しなければなりません (MUST)。
1. The Identity-Type contains a value permitted by the server configuration.
1. Identity-Type には、サーバー構成で許可されている値が含まれています。
2. The Identity-Type value was not previously used for a successful authentication.
2. Identity-Type 値は、以前は認証の成功に使用されていませんでした。
The first condition allows a server to be configured to permit only user authentication, or else only machine authentication. A server could also use an Identity-Hint TLV sent in the response to permit different types of authentication for different identities. A server could also permit or forbid different kinds of authentication based on other information, such an outer EAP Identity, fields in an outer EAP client certificate, or other fields received in a RADIUS or Diameter packet along with the TEAP session. There is no requirement that a server has to support both user and machine authentication for all TEAP sessions.
最初の条件では、ユーザー認証のみを許可するか、そうでない場合はマシン認証のみを許可するようにサーバーを構成できます。サーバーは、応答で送信された Identity-Hint TLV を使用して、異なる ID に対して異なる種類の認証を許可することもできます。サーバーは、外部 EAP ID、外部 EAP クライアント証明書内のフィールド、または TEAP セッションとともに RADIUS パケットまたは Diameter パケットで受信したその他のフィールドなどの他の情報に基づいて、さまざまな種類の認証を許可または禁止することもできます。サーバーがすべての TEAP セッションに対してユーザー認証とマシン認証の両方をサポートする必要はありません。
The second condition ensures that if a particular Inner Method succeeds, the server does not attempt a subsequent Inner Method for the same Identity-Type. For example, if a user is authenticated via an Inner Method of EAP-TLS, there is no benefit to also requesting additional authentication via a different Inner Method. Similarly, there is no benefit to repeating an authentication sessions for the same user; the result will not change.
2 番目の条件は、特定の内部メソッドが成功した場合に、サーバーが同じ ID タイプに対して後続の内部メソッドを試行しないことを保証します。たとえば、ユーザーが EAP-TLS の内部メソッド経由で認証されている場合、別の内部メソッド経由で追加の認証を要求してもメリットはありません。同様に、同じユーザーに対して認証セッションを繰り返すことにはメリットがありません。結果は変わりません。
This second condition also forbids multiple rounds of challenge/ response authentication via the Basic-Password-Auth-Req TLV. TEAPv1 supports only one round of Basic-Password-Auth-Req followed by Basic-Password-Auth-Resp. The result of that round MUST NOT be another Basic-Password-Auth-Req TLV.
この 2 番目の条件は、Basic-Password-Auth-Req TLV を介した複数ラウンドのチャレンジ/レスポンス認証も禁止します。TEAPv1 は、Basic-Password-Auth-Req とそれに続く Basic-Password-Auth-Resp の 1 ラウンドのみをサポートします。そのラウンドの結果は、別の Basic-Password-Auth-Req TLV であってはなりません。
This second condition also means that a server MUST NOT send an Identity-Hint TLV that has the same value as was previously used for a successful authentication.
この 2 番目の条件は、サーバーが、認証の成功に以前に使用されたものと同じ値を持つ Identity-Hint TLV を送信してはいけない (MUST NOT) ことも意味します。
The Identity-Type TLV is defined as follows:
ID タイプ TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identity-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必須、1 に設定します
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
2 - Identity-Type TLV
2 - ID タイプ TLV
Length
長さ
2
2
Identity-Type
アイデンティティタイプ
The Identity-Type field is two octets. Values include:
Identity-Type フィールドは 2 オクテットです。値には次のものが含まれます。
1
1
User
ユーザー
2
2
Machine
機械
The Result TLV provides support for acknowledged success and failure messages for protected termination within TEAP. If the Status field does not contain one of the known values, then the peer or EAP server MUST treat this as a fatal error of Unexpected TLVs Exchanged. The behavior of the Result TLV is further discussed in Sections 3.6.6 and 3.9.3.
Result TLV は、TEAP 内の保護された終了に対する確認済みの成功メッセージと失敗メッセージのサポートを提供します。Status フィールドに既知の値が含まれていない場合、ピアまたは EAP サーバーは、これを予期しない TLV 交換の致命的エラーとして扱わなければなりません (MUST)。Result TLV の動作については、セクション 3.6.6 および 3.9.3 で詳しく説明します。
A Result TLV indicating failure MUST NOT be accompanied by the following TLVs: NAK, EAP-Payload, or Crypto-Binding.
失敗を示す結果 TLV には、NAK、EAP ペイロード、または暗号バインディングの TLV を伴ってはなりません (MUST NOT)。
A Result TLV indicating success MUST be accompanied by a Crypto-Binding TLV.
成功を示す結果 TLV には、暗号バインディング TLV が伴わなければなりません (MUST)。
The Result TLV is defined as follows:
結果 TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必須、1 に設定します
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
3 - Result TLV
3 - 結果TLV
Length
長さ
2
2
Status
状態
The Status field is two octets. Values include:
Status フィールドは 2 オクテットです。値には次のものが含まれます。
1
1
Success
成功
2
2
Failure
失敗
The NAK TLV allows a peer to detect TLVs that are not supported by the other peer. A TEAP packet can contain 0 or more NAK TLVs. A NAK TLV should not be accompanied by other TLVs. A NAK TLV MUST NOT be sent in response to a message containing a Result TLV, instead a Result TLV of failure should be sent indicating failure and an Error TLV of Unexpected TLVs Exchanged. The NAK TLV is defined as follows:
NAK TLV を使用すると、ピアは他のピアによってサポートされていない TLV を検出できます。TEAP パケットには 0 個以上の NAK TLV を含めることができます。NAK TLV は他の TLV を伴うべきではありません。NAK TLV は、結果 TLV を含むメッセージに応答して送信してはなりません。代わりに、失敗を示す失敗の結果 TLV と、交換された予期しない TLV のエラー TLV を送信する必要があります。NAK TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK-Type | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必須、1 に設定します
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
4 - NAK TLV
4 - NAK TLV
Length
長さ
>=6
>=6
Vendor-Id
ベンダーID
The Vendor-Id field is four octets and contains the Vendor-Id of the TLV that was not supported. The high-order octet is 0, and the low-order three octets are the Structure of Management Information (SMI) Network Management Private Enterprise Number of the Vendor in network byte order. The Vendor-Id field MUST be zero for TLVs that are not Vendor-Specific TLVs.
Vendor-Id フィールドは 4 オクテットで、サポートされていない TLV の Vendor-Id が含まれています。上位オクテットは 0 で、下位 3 オクテットはネットワーク バイト オーダーで表したベンダーの管理情報構造 (SMI) ネットワーク管理民間企業番号です。Vendor-Specific TLV ではない TLV の場合、Vendor-Id フィールドはゼロでなければなりません (MUST)。
NAK-Type
NAK型
The NAK-Type field is two octets. The field contains the type of the TLV that was not supported. A TLV of this type MUST have been included in the previous packet.
NAK-Type フィールドは 2 オクテットです。このフィールドには、サポートされていない TLV のタイプが含まれています。このタイプの TLV は前のパケットに含まれていなければなりません (MUST)。
TLVs
TLV
This field contains a list of zero or more TLVs, each of which MUST NOT have the mandatory bit set. These optional TLVs are for future extensibility to communicate why the offending TLV was determined to be unsupported.
このフィールドには 0 個以上の TLV のリストが含まれており、それぞれに必須ビットを設定してはなりません (MUST NOT)。これらのオプションの TLV は、問題の TLV がサポートされていないと判断された理由を伝えるための将来の拡張性を目的としています。
The Error TLV allows an EAP peer or server to indicate errors to the other party. A TEAP packet can contain 0 or more Error TLVs. The Error-Code field describes the type of error. Error codes 1-999 represent successful outcomes (informative messages), 1000-1999 represent warnings, and 2000-2999 represent fatal errors. A fatal Error TLV MUST be accompanied by a Result TLV indicating failure, and the conversation is terminated as described in Section 3.9.3.
エラー TLV を使用すると、EAP ピアまたはサーバーは相手にエラーを通知できます。TEAP パケットには 0 個以上のエラー TLV を含めることができます。Error-Code フィールドには、エラーの種類が示されます。エラー コード 1 ～ 999 は成功結果 (情報メッセージ) を表し、1000 ～ 1999 は警告を表し、2000 ～ 2999 は致命的なエラーを表します。致命的なエラー TLV には、失敗を示す結果 TLV が伴わなければなりません (MUST)。セクション 3.9.3 で説明されているように、会話は終了します。
Many of the error codes below refer to errors in Inner Method processing that may be retrieved if made available by the inner method. Implementations MUST take care that error messages do not reveal too much information to an attacker. For example, the usage of error message 1031 (User account credentials incorrect) is NOT RECOMMENDED, because it allows an attacker to determine valid usernames by differentiating this response from other responses. It should only be used for troubleshooting purposes.
以下のエラー コードの多くは、内部メソッドで使用可能になっている場合に取得できる内部メソッド処理のエラーを指します。実装では、エラー メッセージが攻撃者にあまりにも多くの情報を明らかにしないように注意しなければなりません。たとえば、エラー メッセージ 1031 (ユーザー アカウントの認証情報が正しくありません) の使用は推奨されません。これは、攻撃者がこの応答を他の応答と区別して有効なユーザー名を判断できるためです。トラブルシューティングの目的でのみ使用してください。
The Error TLV is defined as follows:
エラー TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必須、1 に設定します
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
5 - Error TLV
5 - エラー TLV
Length
長さ
4
4
Error-Code
エラーコード
The Error-Code field is four octets. Currently defined values for Error-Code include:
Error-Code フィールドは 4 オクテットです。現在定義されているエラー コードの値は次のとおりです。
1
1
User account expires soon
ユーザーアカウントの有効期限がもうすぐ切れます
2
2
User account credential expires soon
ユーザー アカウントの認証情報の有効期限がまもなく切れます
3
3
User account authorizations change soon
ユーザーアカウントの権限がまもなく変更されます
4
4
Clock skew detected
クロックスキューが検出されました
5
5
Contact administrator
管理者に連絡する
6
6
User account credentials change required
ユーザーアカウントの認証情報の変更が必要です
1001
1001
Inner Method Error
内部メソッドエラー
1002
1002
Unspecified authentication infrastructure problem
不特定の認証インフラストラクチャの問題
1003
1003
Unspecified authentication failure
不特定の認証失敗
1004
1004
Unspecified authorization failure
不特定の認可失敗
1005
1005
User account credentials unavailable
ユーザーアカウントの認証情報が利用できない
1006
1006
User account expired
ユーザーアカウントの有効期限が切れました
1007
1007
User account locked: try again later
ユーザー アカウントがロックされました: 後でもう一度お試しください
1008
1008
User account locked: admin intervention required
ユーザーアカウントがロックされました: 管理者の介入が必要です
1009
1009
Authentication infrastructure unavailable
認証インフラストラクチャが利用できない
1010
1010
Authentication infrastructure not trusted
認証インフラストラクチャが信頼されていない
1011
1011
Clock skew too great
クロックスキューが大きすぎます
1012
1012
Invalid inner realm
無効な内部レルム
1013
1013
Token out of sync: administrator intervention required
トークンが同期していません: 管理者の介入が必要です
1014
1014
Token out of sync: PIN change required
トークンが同期していません: PIN の変更が必要です
1015
1015
Token revoked
トークンが取り消されました
1016
1016
Tokens exhausted
トークンが枯渇した
1017
1017
Challenge expired
チャレンジの有効期限が切れました
1018
1018
Challenge algorithm mismatch
チャレンジアルゴリズムの不一致
1019
1019
Client certificate not supplied
クライアント証明書が提供されていません
1020
1020
Client certificate rejected
クライアント証明書が拒否されました
1021
1021
Realm mismatch between inner and outer identity
レルムの内部アイデンティティと外部アイデンティティの間の不一致
1022
1022
Unsupported Algorithm In Certificate Signing Request
証明書署名リクエストでサポートされていないアルゴリズム
1023
1023
Unsupported Extension In Certificate Signing Request
証明書署名リクエストでサポートされていない拡張子
1024
1024
Bad Identity In Certificate Signing Request
証明書署名リクエストの ID が不正です
1025
1025
Bad Certificate Signing Request
不正な証明書署名リクエスト
1026
1026
Internal CA Error
内部 CA エラー
1027
1027
General PKI Error
一般的な PKI エラー
1028
1028
Inner Method's channel-binding data required but not supplied
内部メソッドのチャネル バインディング データが必要ですが、提供されていません
1029
1029
Inner Method's channel-binding data did not include required information
インナーメソッドのチャネルバインディングデータに必要な情報が含まれていませんでした
1030
1030
Inner Method's channel binding failed
内部メソッドのチャネル バインディングが失敗しました
1031
1031
User account credentials incorrect [USAGE NOT RECOMMENDED]
ユーザー アカウントの認証情報が正しくありません [使用は推奨されません]
1032
1032
Inner Method not supported
内部メソッドはサポートされていません
2001
2001年
Tunnel Compromise Error
トンネル侵害エラー
2002
2002年
Unexpected TLVs Exchanged
予期しない TLV が交換されました
2003
2003年
The Crypto-Binding TLV is invalid (Version, Received-Ver, or Sub-Type)
暗号バインディング TLV が無効です (バージョン、受信バージョン、またはサブタイプ)
2004
2004年
The first Inner Method did not derive EMSK
最初の内部メソッドは EMSK を導出しませんでした
2005
2005年
The Crypto-Binding TLV did not include a required MSK Compound MAC
暗号バインディング TLV に必要な MSK 複合 MAC が含まれていませんでした
2006
2006年
The MSK Compound MAC fails verification
MSK 複合 MAC が検証に失敗する
2007
2007年
The Crypto-Binding TLV did not include a required EMSK Compound MAC
暗号バインディング TLV に必要な EMSK 複合 MAC が含まれていませんでした
2008
2008年
The EMSK Compound MAC fails verification
EMSK 複合 MAC が検証に失敗する
2009
2009年
The EMSK Compound MAC exists, but the Inner Method did not derive EMSK
EMSK 複合 MAC は存在しますが、内部メソッドは EMSK を導出しませんでした。
The Channel-Binding TLV provides a mechanism for carrying channel-binding data from the peer to the EAP server and a channel-binding response from the EAP server to the peer as described in [RFC6677]. TEAPv1 implementations MAY support this TLV, which cannot be responded to with a NAK TLV. If the Channel-Binding data field does not contain one of the known values or if the EAP server does not support this TLV, then the server MUST ignore the value. The Channel-Binding TLV is defined as follows:
Channel-Binding TLV は、[RFC6677] で説明されているように、ピアから EAP サーバーにチャネル バインディング データを伝送し、EAP サーバーからピアにチャネル バインディング応答を伝送するためのメカニズムを提供します。TEAPv1 実装は、NAK TLV で応答できないこの TLV をサポートしてもよい(MAY)。Channel-Binding データフィールドに既知の値が含まれていない場合、または EAP サーバーがこの TLV をサポートしていない場合、サーバーはその値を無視しなければなりません (MUST)。チャネル バインディング TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Optional TLV
0 - オプションの TLV
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
6 - Channel-Binding TLV
6 - チャネルバインディングTLV
Length
長さ
variable
変数
Data
データ
The data field contains a channel-binding message as defined in Section 5.3 of [RFC6677].
データフィールドには、[RFC6677] のセクション 5.3 で定義されているチャネルバインディングメッセージが含まれます。
The Vendor-Specific TLV is available to allow vendors to support their own extended attributes not suitable for general usage. A Vendor-Specific TLV attribute can contain one or more TLVs, referred to as Vendor TLVs. The TLV type of a particular Vendor TLV is defined by the vendor. All the Vendor TLVs inside a single Vendor-Specific TLV belong to the same vendor. There can be multiple Vendor-Specific TLVs from different vendors in the same message. Error handling in the Vendor TLV could use the vendor's own specific error-handling mechanism or use the standard TEAP error codes defined.
ベンダー固有の TLV を使用すると、ベンダーが一般的な使用には適さない独自の拡張属性をサポートできるようになります。ベンダー固有の TLV 属性には、ベンダー TLV と呼ばれる 1 つ以上の TLV を含めることができます。特定のベンダー TLV の TLV タイプはベンダーによって定義されます。単一のベンダー固有 TLV 内のすべてのベンダー TLV は、同じベンダーに属します。同じメッセージ内に、異なるベンダーからの複数のベンダー固有 TLV が存在する可能性があります。ベンダー TLV でのエラー処理では、ベンダー独自のエラー処理メカニズムを使用することも、定義されている標準の TEAP エラー コードを使用することもできます。
Vendor TLVs may be optional or mandatory. Vendor TLVs sent with Result TLVs MUST be marked as optional. If the Vendor-Specific TLV is marked as mandatory, then it is expected that the receiving side needs to recognize the vendor ID, parse all Vendor TLVs within, and deal with error handling within the Vendor-Specific TLV as defined by the vendor.
ベンダー TLV はオプションまたは必須の場合があります。結果 TLV とともに送信されるベンダー TLV は、オプションとしてマークされなければなりません。ベンダー固有の TLV が必須としてマークされている場合、受信側はベンダー ID を認識し、その中のすべてのベンダー TLV を解析し、ベンダーの定義に従ってベンダー固有の TLV 内でエラー処理を処理する必要があることが予想されます。
Where a Vendor-Specific TLV carries an authentication protocol in the Inner Method, it MUST define values for MSK and EMSK. Where these values cannot be derived from cryptographic primitives, they MUST be set to zero, as happens when Basic-Password-Auth-Req is used.
ベンダー固有の TLV が内部メソッドで認証プロトコルを伝送する場合、MSK と EMSK の値を定義しなければなりません (MUST)。これらの値を暗号化プリミティブから導出できない場合は、Basic-Password-Auth-Req が使用される場合と同様に、ゼロに設定しなければなりません。
The Vendor-Specific TLV is defined as follows:
ベンダー固有の TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 or 1
0 または 1
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
7 - Vendor-Specific TLV
7 - ベンダー固有の TLV
Length
長さ
4 + cumulative length of all included Vendor TLVs
4 + 含まれるすべてのベンダー TLV の累積長
Vendor-Id
ベンダーID
The Vendor-Id field is four octets and contains the Vendor-Id of the TLV. The high-order octet is 0, and the low-order 3 octets are the SMI Network Management Private Enterprise Number of the Vendor in network byte order.
Vendor-Id フィールドは 4 オクテットで、TLV の Vendor-Id が含まれます。上位オクテットは 0 で、下位 3 オクテットはネットワーク バイト オーダーでのベンダーの SMI ネットワーク管理民間企業番号です。
Vendor TLVs
ベンダーTLV
This field is of indefinite length. It contains Vendor-Specific TLVs, in a format defined by the vendor.
このフィールドの長さは無制限です。これには、ベンダーによって定義された形式のベンダー固有 TLV が含まれます。
The Request-Action TLV MAY be sent at any time. The Request-Action TLV allows the peer or server to request that the other side negotiates additional Inner Methods or process TLVs that are passed inside of the Request-Action TLV.
Request-Action TLV はいつでも送信できます (MAY)。Request-Action TLV を使用すると、ピアまたはサーバーは、相手側が追加の内部メソッドをネゴシエートするか、Request-Action TLV 内で渡される TLV を処理するように要求できます。
The receiving side MUST process this TLV. The processing for the TLV is as follows:
受信側はこの TLV を処理しなければなりません (MUST)。TLV の処理は次のとおりです。
The receiving entity MAY choose to process any of the TLVs that are included in the message.
受信側エンティティは、メッセージに含まれる TLV のいずれかを処理することを選択してもよい (MAY)。
If the receiving entity chooses NOT to process any TLV in the list, then it sends back a Result TLV with the same code in the Status field of the Request-Action TLV.
受信側エンティティがリスト内の TLV を処理しないことを選択した場合、Request-Action TLV の Status フィールドに同じコードを持つ Result TLV を送り返します。
If multiple Request-Action TLVs are in the request, the session can continue if any of the TLVs in any Request-Action TLV are processed.
リクエストに複数のリクエスト-アクション TLV が含まれている場合、いずれかのリクエスト-アクション TLV のいずれかの TLV が処理されれば、セッションは継続できます。
If multiple Request-Action TLVs are in the request and none of them is processed, then the most fatal status should be used in the Result TLV returned. If a status code in the Request-Action TLV is not understood by the receiving entity, then it SHOULD be treated as a fatal error. Otherwise, the receiving entity MAY send a Request-Action TLV containing an Error TLV of value 2002 (Unexpected TLVs Exchanged).
リクエスト内に複数のリクエスト/アクション TLV があり、どれも処理されない場合は、返される結果 TLV で最も致命的なステータスを使用する必要があります。Request-Action TLV のステータス コードが受信エンティティによって理解されない場合、それは致命的なエラーとして扱われる必要があります (SHOULD)。それ以外の場合、受信側エンティティは、値 2002 (予期しない TLV 交換) のエラー TLV を含むリクエストアクション TLV を送信してもよい(MAY)。
After processing the TLVs or Inner Method in the request, another round of Result TLV exchange MUST occur to synchronize the final status on both sides.
リクエスト内の TLV または内部メソッドを処理した後、両側の最終ステータスを同期するために、別のラウンドの Result TLV 交換が発生しなければなりません (MUST)。
The peer or the server MAY send multiple Request-Action TLVs to the other side. Two Request-Action TLVs MUST NOT occur in the same TEAP packet if they have the same Status value. The order of processing multiple Request-Action TLVs is implementation dependent. If the receiving side processes the optional (non-fatal) items first, it is possible that the fatal items will disappear at a later time. If the receiving side processes the fatal items first, the communication time will be shorter.
ピアまたはサーバーは、複数の Request-Action TLV を相手側に送信してもよい (MAY)。2 つの Request-Action TLV が同じ Status 値を持つ場合、同じ TEAP パケット内に存在してはなりません (MUST NOT)。複数のリクエストアクション TLV を処理する順序は実装に依存します。受信側がオプション（致命的ではない）項目を先に処理すると、後で致命的な項目が消滅する可能性があります。受信側で致命的な項目を先に処理すると通信時間が短くなります。
The peer or the server MAY return a new set of Request-Action TLVs after one or more of the requested items have been processed and the other side has signaled it wants to end the EAP conversation.
ピアまたはサーバーは、1 つ以上の要求された項目が処理され、相手側が EAP 会話を終了したいと通知した後、新しいセットの Request-Action TLV を返してもよい(MAY)。
The Request-Action TLV is defined as follows:
リクエスト-アクション TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Action | TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-
M
M
Mandatory, set to one (1)
必須、1 に設定します
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
8 - Request-Action TLV
8 - リクエストアクションTLV
Length
長さ
2 + cumulative length of all included TLVs
2 + 含まれるすべての TLV の累積長
Status
状態
The Status field is one octet. This indicates the result if the party who receives this TLV does not process the action. Values include:
ステータスフィールドは 1 オクテットです。これは、この TLV を受信した当事者がアクションを処理しなかった場合の結果を示します。値には次のものが含まれます。
1
1
Success
成功
2
2
Failure
失敗
Action
アクション
The Action field is one octet. Values include:
Action フィールドは 1 オクテットです。値には次のものが含まれます。
1
1
Process-TLV
プロセス-TLV
2
2
Negotiate-EAP
ネゴシエート-EAP
TLVs
TLV
This field is of indefinite length. It contains TLVs that the peer wants the server to process.
このフィールドの長さは無制限です。これには、ピアがサーバーに処理してほしい TLV が含まれています。
To allow coalescing an EAP request or response with other TLVs, the EAP-Payload TLV is defined, which includes an encapsulated EAP packet and a list of optional TLVs. The optional TLVs are provided for future extensibility to provide hints about the current EAP authentication. Only one EAP-Payload TLV is allowed in a message. The EAP-Payload TLV is defined as follows:
EAP 要求または応答を他の TLV と結合できるようにするために、カプセル化された EAP パケットとオプションの TLV のリストを含む EAP ペイロード TLV が定義されます。オプションの TLV は、現在の EAP 認証に関するヒントを提供する将来の拡張のために提供されています。メッセージ内で許可される EAP ペイロード TLV は 1 つだけです。EAP ペイロード TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP packet...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必須、1 に設定します
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
9 - EAP-Payload TLV
9 - EAP ペイロード TLV
Length
長さ
length of embedded EAP packet + cumulative length of additional TLVs
埋め込まれた EAP パケットの長さ + 追加の TLV の累積長さ
EAP packet
EAPパケット
This field contains a complete EAP packet, including the EAP header (Code, Identifier, Length, Type) fields. The length of this field is determined by the Length field of the encapsulated EAP packet.
このフィールドには、EAP ヘッダー (コード、識別子、長さ、タイプ) フィールドを含む完全な EAP パケットが含まれます。このフィールドの長さは、カプセル化された EAP パケットの長さフィールドによって決まります。
TLVs
TLV
This (optional) field contains a list of TLVs associated with the EAP packet field. The TLVs MUST NOT have the mandatory bit set. The total length of this field is equal to the Length field of the EAP-Payload TLV, minus the Length field in the EAP header of the EAP packet field.
この (オプション) フィールドには、EAP パケット フィールドに関連付けられた TLV のリストが含まれます。TLV には必須ビットを設定してはなりません (MUST NOT)。このフィールドの合計長は、EAP ペイロード TLV の長さフィールドから、EAP パケット フィールドの EAP ヘッダーの長さフィールドを引いたものに等しくなります。
The Intermediate-Result TLV signals intermediate Success and Failure messages for all inner methods. The Intermediate-Result TLV MUST be used for all Inner Methods.
中間結果 TLV は、すべての内部メソッドの中間成功メッセージと失敗メッセージを通知します。中間結果 TLV はすべての内部メソッドに使用しなければなりません (MUST)。
An Intermediate-Result TLV indicating success MUST be accompanied by a Crypto-Binding TLV.
成功を示す中間結果 TLV には、暗号バインディング TLV が伴わなければなりません (MUST)。
An Intermediate-Result TLV indicating failure SHOULD be accompanied by an Error TLV that indicates why the authentication failed.
失敗を示す中間結果 TLV には、認証が失敗した理由を示すエラー TLV が伴うべきです(SHOULD)。
The optional TLVs associated with this TLV are provided for future extensibility to provide hints about the current result. The Intermediate-Result TLV is defined as follows:
この TLV に関連付けられたオプションの TLV は、現在の結果に関するヒントを提供するために将来の拡張のために提供されています。中間結果 TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必須、1 に設定します
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
10 - Intermediate-Result TLV
10 - 中間結果 TLV
Length
長さ
2 + cumulative length of the embedded associated TLVs
2 + 埋め込まれた関連 TLV の累積長
Status
状態
The Status field is two octets. Values include:
Status フィールドは 2 オクテットです。値には次のものが含まれます。
1
1
Success
成功
2
2
Failure
失敗
TLVs
TLV
This field is of indeterminate length and contains zero or more of the TLVs associated with the Intermediate Result TLV. The TLVs in this field MUST NOT have the mandatory bit set.
このフィールドの長さは不定であり、中間結果 TLV に関連付けられた 0 個以上の TLV が含まれます。このフィールドの TLV には必須ビットを設定してはなりません (MUST NOT)。
[RFC7170] defined a Protected Access Credential (PAC) to mirror EAP-FAST [RFC4851]. However, implementation experience and analysis determined that the PAC was not necessary. Instead, TEAP performs session resumption using the NewSessionTicket message as defined in Sections 2.1.2 and 2.1.3 of [RFC9190]. As such, the PAC TLV has been deprecated.
[RFC7170] は、EAP-FAST [RFC4851] をミラーリングするための Protected Access Credential (PAC) を定義しました。ただし、実装の経験と分析により、PAC は必要ないと判断されました。代わりに、TEAP は、[RFC9190] のセクション 2.1.2 および 2.1.3 で定義されているように、NewSessionTicket メッセージを使用してセッション再開を実行します。そのため、PAC TLV は非推奨になりました。
As the PAC TLV is deprecated, an entity receiving it SHOULD send a Result TLV indicating failure and an Error TLV of Unexpected TLVs Exchanged.
PAC TLV は非推奨であるため、それを受信するエンティティは、失敗を示す結果 TLV と交換された予期しない TLV のエラー TLV を送信する必要があります (SHOULD)。
The Crypto-Binding TLV is used to prove that both the peer and server participated in the tunnel establishment and sequence of authentications. It also provides verification of the TEAP type, version negotiated, and Outer TLVs exchanged before the TLS tunnel establishment.
暗号バインディング TLV は、ピアとサーバーの両方がトンネルの確立と一連の認証に参加したことを証明するために使用されます。また、TEAP タイプ、ネゴシエートされたバージョン、および TLS トンネルの確立前に交換されたアウター TLV の検証も提供します。
A Crypto-Binding MUST be accompanied by an Intermediate-Result TLV indicating success.
暗号バインディングには、成功を示す中間結果 TLV が伴わなければなりません (MUST)。
The Crypto-Binding TLV MUST be exchanged and validated before any Intermediate-Result or Result TLV value is examined, regardless of whether there is an Inner Method or not. It MUST be included with the Intermediate-Result TLV to perform cryptographic binding after each successful Inner Method in a sequence of inner methods, before proceeding with another Inner Method. If no MSK or EMSK has been generated and a Crypto-Binding TLV is required, then the MSK Compound MAC field contains the MAC using keys generated according to Section 6.3.
Crypto-Binding TLV は、内部メソッドがあるかどうかに関係なく、中間結果または結果 TLV 値が検査される前に交換および検証されなければなりません (MUST)。一連の内部メソッドの成功した各内部メソッドの後で、別の内部メソッドに進む前に、暗号化バインディングを実行するために、中間結果 TLV にこれを含める必要があります。MSK または EMSK が生成されておらず、暗号結合 TLV が必要な場合、MSK 複合 MAC フィールドには、セクション 6.3 に従って生成されたキーを使用する MAC が含まれます。
The Crypto-Binding TLV is valid only if the following checks pass on its contents:
Crypto-Binding TLV は、その内容が次のチェックに合格した場合にのみ有効です。
* The Version field contain a known value.
* [バージョン] フィールドには既知の値が含まれています。
* The Received-Ver field matches the TEAP version sent by the receiver during the EAP version negotiation.
* Received-Ver フィールドは、EAP バージョン ネゴシエーション中に受信者によって送信された TEAP バージョンと一致します。
* The Sub-Type field is set to the correct value for this exchange.
* Sub-Type フィールドは、この交換の正しい値に設定されています。
* The Flags field is set to a known value.
* Flags フィールドは既知の値に設定されます。
* The Compound MAC(s) verify correctly.
* 複合 MAC は正しく検証されます。
If any of the above checks fails, then the TLV is invalid. An invalid Crypto-Binding TLV is a fatal error and is handled as described in Section 3.9.3
上記のチェックのいずれかが失敗した場合、TLV は無効です。無効な暗号バインディング TLV は致命的なエラーであり、セクション 3.9.3 で説明されているように処理されます。
See Section 6 for a more detailed discussion of how the Compound MAC fields are constructed and verified.
複合 MAC フィールドの構築および検証方法の詳細については、セクション 6 を参照してください。
The Crypto-Binding TLV is defined as follows:
暗号バインディング TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Version | Received-Ver.| Flags|Sub-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ EMSK Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MSK Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必須、1 に設定します
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
12 - Crypto-Binding TLV
12 - 暗号バインディング TLV
Length
長さ
76
76
Reserved
予約済み
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
Version
バージョン
The Version field is a single octet, which is set to the version of Crypto-Binding TLV the TEAP method is using. For an implementation compliant with TEAPv1, the version number MUST be set to one (1).
Version フィールドは単一のオクテットで、TEAP メソッドが使用している Crypto-Binding TLV のバージョンに設定されます。TEAPv1 に準拠した実装の場合、バージョン番号は 1 に設定しなければなりません。
Received-Ver
受信Ver
The Received-Ver field is a single octet and MUST be set to the TEAP version number received during version negotiation. Note that this field only provides protection against downgrade attacks, where a version of EAP requiring support for this TLV is required on both sides.
Received-Ver フィールドは単一のオクテットであり、バージョン ネゴシエーション中に受信した TEAP バージョン番号に設定しなければなりません (MUST)。このフィールドはダウングレード攻撃に対する保護のみを提供することに注意してください。この攻撃では、この TLV のサポートを必要とする EAP のバージョンが両側で必要となります。
For TEAPv1, this version number MUST be set to one (1).
TEAPv1 の場合、このバージョン番号は 1 に設定する必要があります。
Flags
フラグ
The Flags field is four bits. Defined values include:
Flags フィールドは 4 ビットです。定義された値には次のものが含まれます。
1
1
EMSK Compound MAC is present
EMSK 化合物 MAC が存在します
2
2
MSK Compound MAC is present
MSK 化合物 MAC が存在します
3
3
Both EMSK and MSK Compound MAC are present
EMSK と MSK の両方の化合物 MAC が存在します
All other values of the Flags field are invalid.
Flags フィールドの他の値はすべて無効です。
Sub-Type
サブタイプ
The Sub-Type field is four bits. Defined values include:
Sub-Type フィールドは 4 ビットです。定義された値には次のものが含まれます。
0
0
Binding Request
バインディングリクエスト
1
1
Binding Response
結合応答
All other values of the Sub-Type field are invalid.
Sub-Type フィールドの他の値はすべて無効です。
Nonce
ノンス
The Nonce field is 32 octets. It contains a 256-bit nonce that is temporally unique, used for Compound MAC key derivation at each end. The nonce in a request MUST have its least significant bit set to zero (0), and the nonce in a response MUST have the same value as the request nonce except the least significant bit MUST be set to one (1).
Nonce フィールドは 32 オクテットです。これには、時間的に一意な 256 ビットのノンスが含まれており、各エンドでの複合 MAC キーの導出に使用されます。リクエストのノンスは、その最下位ビットがゼロ (0) に設定されなければならず、応答のノンスは、最下位ビットが 1 に設定されなければならないことを除いて、リクエストのノンスと同じ値を持たなければなりません (MUST)。
EMSK Compound MAC
EMSK コンパウンド MAC
The EMSK Compound MAC field is 20 octets. This can be the Server MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the MAC is described in Section 6.3.
EMSK 複合 MAC フィールドは 20 オクテットです。これは、サーバー MAC (B1_MAC) またはクライアント MAC (B2_MAC) です。MAC の計算についてはセクション 6.3 で説明されています。
Note that this field is always 20 octets in length. Any larger MAC is simply truncated. All validations or comparisons MUST be done on the truncated value.
このフィールドの長さは常に 20 オクテットであることに注意してください。それより大きな MAC は単純に切り捨てられます。すべての検証または比較は、切り捨てられた値に対して実行する必要があります。
MSK Compound MAC
MSK コンパウンド MAC
The MSK Compound MAC field is 20 octets. This can be the Server MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the MAC is described in Section 6.3.
MSK 複合 MAC フィールドは 20 オクテットです。これは、サーバー MAC (B1_MAC) またはクライアント MAC (B2_MAC) です。MAC の計算についてはセクション 6.3 で説明されています。
Note that this field is always 20 octets in length. Any larger MAC is simply truncated. All validations or comparisons MUST be done on the truncated value.
このフィールドの長さは常に 20 オクテットであることに注意してください。それより大きな MAC は単純に切り捨てられます。すべての検証または比較は、切り捨てられた値に対して実行する必要があります。
The Basic-Password-Auth-Req TLV is used by the authentication server to request a username and password from the peer. It contains an optional user prompt message for the request. The peer is expected to obtain the username and password and send them in a Basic-Password-Auth-Resp TLV.
Basic-Password-Auth-Req TLV は、認証サーバーがピアにユーザー名とパスワードを要求するために使用されます。これには、リクエストに対するオプションのユーザー プロンプト メッセージが含まれます。ピアはユーザー名とパスワードを取得し、Basic-Password-Auth-Resp TLV で送信することが期待されます。
The Basic-Password-Auth-Req TLV is defined as follows:
Basic-Password-Auth-Req TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prompt ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必須、1 に設定します
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
13 - Basic-Password-Auth-Req TLV
13 - 基本パスワード認証要求 TLV
Length
長さ
variable
変数
Prompt
プロンプト
optional user prompt message in UTF-8 [RFC3629] format
UTF-8 [RFC3629] 形式のオプションのユーザー プロンプト メッセージ
The Basic-Password-Auth-Resp TLV is used by the peer to respond to a Basic-Password-Auth-Req TLV with a username and password. The TLV contains a username and password. The username and password are in UTF-8 [RFC3629] format.
Basic-Password-Auth-Resp TLV は、ピアが Basic-Password-Auth-Req TLV にユーザー名とパスワードで応答するために使用されます。TLV にはユーザー名とパスワードが含まれています。ユーザー名とパスワードは UTF-8 [RFC3629] 形式です。
The Basic-Password-Auth-Resp TLV is defined as follows:
Basic-Password-Auth-Resp TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Userlen | Username
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Username ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Passlen | Password
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Password ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必須、1 に設定します
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
14 - Basic-Password-Auth-Resp TLV
14 - 基本パスワード認証応答 TLV
Length
長さ
variable
変数
Userlen
ユーザーレン
Length of Username field in octets.
ユーザー名フィールドの長さ (オクテット単位)。
The value of Userlen MUST NOT be zero.
Userlen の値はゼロであってはなりません。
Username
ユーザー名
Username in UTF-8 [RFC3629] format.
UTF-8 [RFC3629] 形式のユーザー名。
The content of Username SHOULD follow the guidelines set in [RFC9427], Section 3.1.
ユーザー名の内容は、[RFC9427] セクション 3.1 で設定されたガイドラインに従う必要があります (SHOULD)。
Passlen
パスレン
Length of Password field in octets.
パスワードフィールドの長さ（オクテット単位）。
The value of Passlen MUST NOT be zero.
Passlen の値はゼロであってはなりません。
Password
パスワード
Password in UTF-8 [RFC3629] format.
UTF-8 [RFC3629] 形式のパスワード。
Note that there is no requirement that passwords be humanly readable. Octets in a passwords may have values less than 0x20, including 0x00.
パスワードは人間が判読できる必要はないことに注意してください。パスワード内のオクテットには、0x00 を含む 0x20 未満の値が含まれる場合があります。
The PKCS#7 TLV is used by the EAP server to deliver certificate(s) to the peer. The format consists of a certificate or certificate chain in binary DER encoding [X.690] in a degenerate Certificates Only PKCS#7 SignedData Content as defined in [RFC5652].
PKCS#7 TLV は、ピアに証明書を配信するために EAP サーバーによって使用されます。この形式は、[RFC5652] で定義されている縮退証明書のみの PKCS#7 SignedData コンテンツ内のバイナリ DER エンコード [X.690] の証明書または証明書チェーンで構成されます。
When used in response to a Trusted-Server-Root TLV request from the peer, the EAP server MUST send the PKCS#7 TLV inside a Trusted-Server-Root TLV. When used in response to a PKCS#10 certificate enrollment request from the peer, the EAP server MUST send the PKCS#7 TLV without a Trusted-Server-Root TLV. The PKCS#7 TLV is always marked as optional, which cannot be responded to with a NAK TLV. TEAP implementations that support the Trusted-Server-Root TLV or the PKCS#10 TLV MUST support this TLV. Peers MUST NOT assume that the certificates in a PKCS#7 TLV are in any order.
ピアからの信頼されたサーバー ルート TLV 要求に応答して使用される場合、EAP サーバーは信頼されたサーバー ルート TLV 内で PKCS#7 TLV を送信しなければなりません (MUST)。ピアからの PKCS#10 証明書登録要求への応答として使用される場合、EAP サーバーは Trusted-Server-Root TLV なしで PKCS#7 TLV を送信しなければなりません (MUST)。PKCS#7 TLV は常にオプションとしてマークされており、NAK TLV で応答することはできません。Trusted-Server-Root TLV または PKCS#10 TLV をサポートする TEAP 実装は、この TLV をサポートしなければなりません (MUST)。ピアは、PKCS#7 TLV 内の証明書が任意の順序であると想定してはなりません (MUST NOT)。
TEAP servers MAY return self-signed certificates. Peers that handle self-signed certificates or trust anchors MUST NOT implicitly trust these certificates merely due to their presence in the certificate bag. Note: Peers are advised to take great care in deciding whether to use a received certificate as a trust anchor. The authenticated nature of the tunnel in which a PKCS#7 bag is received can provide a level of authenticity to the certificates contained therein. Peers are advised to take into account the implied authority of the EAP server and to constrain the trust it can achieve through the trust anchor received in a PKCS#7 TLV.
TEAP サーバーは自己署名証明書を返してもよい (MAY)。自己署名証明書またはトラストアンカーを処理するピアは、単に証明書バッグに証明書が存在するという理由だけで、これらの証明書を暗黙的に信頼してはなりません。注: ピアは、受信した証明書をトラスト アンカーとして使用するかどうかを決定する際に細心の注意を払うことをお勧めします。PKCS#7 バッグが受信されるトンネルの認証された性質により、そこに含まれる証明書に一定レベルの信頼性を提供できます。ピアは、EAP サーバーの暗黙の権限を考慮し、PKCS#7 TLV で受信したトラスト アンカーを通じて達成できる信頼を制限することをお勧めします。
The PKCS#7 TLV is defined as follows:
PKCS#7 TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS#7 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
M
0 - Optional TLV
0 - オプションの TLV
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
15 - PKCS#7 TLV
15 - PKCS#7 TLV
Length
長さ
The length of the PKCS#7 Data field.
PKCS#7 データ フィールドの長さ。
PKCS#7 Data
PKCS#7 データ
This field contains the DER-encoded X.509 certificate or certificate chain in a Certificates-Only PKCS#7 SignedData message.
このフィールドには、証明書のみの PKCS#7 SignedData メッセージ内の DER でエンコードされた X.509 証明書または証明書チェーンが含まれます。
The PKCS#10 TLV is used by the peer to initiate the "Simple PKI" Request/Response from [RFC5272]. The format of the request is as specified in Section 6.4 of [RFC4945]. The PKCS#10 TLV is always marked as optional, which cannot be responded to with a NAK TLV.
PKCS#10 TLV は、[RFC5272] の「シンプル PKI」要求/応答を開始するためにピアによって使用されます。リクエストのフォーマットは、[RFC4945] のセクション 6.4 に規定されているとおりです。PKCS#10 TLV は常にオプションとしてマークされており、NAK TLV で応答することはできません。
The PKCS#10 TLV is defined as follows:
PKCS#10 TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS#10 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
M
0 - Optional TLV
0 - オプションの TLV
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
16 - PKCS#10 TLV
16 - PKCS#10 TLV
Length
長さ
The length of the PKCS#10 Data field.
PKCS#10 データフィールドの長さ。
PKCS#10 Data
PKCS#10 データ
This field contains the DER-encoded PKCS#10 certificate request.
このフィールドには、DER でエンコードされた PKCS#10 証明書リクエストが含まれます。
Trusted-Server-Root TLV facilitates the request and delivery of a trusted server root certificate. The Trusted-Server-Root TLV can be exchanged in regular TEAP authentication mode or provisioning mode. The Trusted-Server-Root TLV is always marked as optional and cannot be responded to with a NAK TLV. The Trusted-Server-Root TLV MUST only be sent as an Inner TLV (inside the protection of the tunnel).
Trusted-Server-Root TLV は、信頼されたサーバー ルート証明書の要求と配信を容易にします。Trusted-Server-Root TLV は、通常の TEAP 認証モードまたはプロビジョニング モードで交換できます。Trusted-Server-Root TLV は常にオプションとしてマークされており、NAK TLV で応答することはできません。Trusted-Server-Root TLV は、内部 TLV (トンネルの保護内) としてのみ送信されなければなりません (MUST)。
After the peer has determined that it has successfully authenticated the EAP server and validated the Crypto-Binding TLV, it MAY send one or more Trusted-Server-Root TLVs (marked as optional) to request the trusted server root certificates from the EAP server. The EAP server MAY send one or more root certificates with a Public Key Cryptographic System #7 (PKCS#7) TLV inside the Trusted-Server-Root TLV. The EAP server MAY also choose not to honor the request.
ピアは、EAP サーバーの認証に成功し、暗号バインディング TLV を検証したことを確認した後、EAP サーバーから信頼されたサーバーのルート証明書を要求するために、1 つ以上の信頼されたサーバー ルート TLV (オプションとしてマークされている) を送信してもよい(MAY)。EAP サーバーは、Trusted-Server-Root TLV 内の公開キー暗号化システム #7 (PKCS#7) TLV を含む 1 つ以上のルート証明書を送信してもよい(MAY)。EAP サーバーは、リクエストを受け入れないことを選択することもできます (MAY)。
The Trusted-Server-Root TLV allows the peer to send a request to the EAP server for a list of trusted roots. The server may respond with one or more root certificates in PKCS#7 [RFC2315] format.
Trusted-Server-Root TLV を使用すると、ピアは信頼されたルートのリストを求めるリクエストを EAP サーバーに送信できます。サーバーは、PKCS#7 [RFC2315] 形式の 1 つ以上のルート証明書で応答する場合があります。
If the EAP server sets the credential format to PKCS#7-Server-Certificate-Root, then the Trusted-Server-Root TLV should contain the root of the certificate chain of the certificate issued to the EAP server packaged in a PKCS#7 TLV. If the server certificate is a self-signed certificate, then the root is the self-signed certificate.
EAP サーバーが資格情報形式を PKCS#7-Server-Certificate-Root に設定する場合、Trusted-Server-Root TLV には、PKCS#7 TLV にパッケージ化されて EAP サーバーに発行された証明書の証明書チェーンのルートが含まれている必要があります。サーバー証明書が自己署名証明書の場合、ルートは自己署名証明書になります。
If the Trusted-Server-Root TLV credential format contains a value unknown to the peer, then the EAP peer should ignore the TLV.
Trusted-Server-Root TLV 資格情報形式にピアにとって不明な値が含まれている場合、EAP ピアは TLV を無視する必要があります。
The Trusted-Server-Root TLV is defined as follows:
Trusted-Server-Root TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credential-Format | Cred TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
M
0 - Optional TLV
0 - オプションの TLV
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
17 - Trusted-Server-Root TLV
17 - 信頼されたサーバー ルート TLV
Length
長さ
>=2 octets
>=2 オクテット
Credential-Format
資格情報の形式
The Credential-Format field is two octets. Values include:
Credential-Format フィールドは 2 オクテットです。値には次のものが含まれます。
1 - PKCS#7-Server-Certificate-Root
1 - PKCS#7-サーバー証明書-ルート
Cred TLVs
信用TLV
This field is of indefinite length. It contains TLVs associated with the credential format. The peer may leave this field empty when using this TLV to request server trust roots.
このフィールドの長さは無制限です。これには、資格情報形式に関連付けられた TLV が含まれます。この TLV を使用してサーバーの信頼ルートを要求する場合、ピアはこのフィールドを空のままにすることができます。
The CSR-Attributes TLV provides information from the server to the peer on how certificate signing requests should be formed. The purpose of CSR attributes is described in Section 4.5 of [RFC7030]. Servers MAY send the CSR-Attributes TLV directly after the TLS session has been established. A server MAY also send in the same message a Request-Action frame for a PKCS#10 TLV. This is an indication to the peer that the server would like the peer to renew its certificate using the parameters provided in this TLV. Servers shall construct the contents of the CSR-Attributes TLV as specified in [RFC7030], Section 4.5.2 with the exception that the DER encoding MUST NOT be encoded in base64. The base64 encoding is used in [RFC7030] because the transport protocol used there requires textual encoding. In contrast, TEAP attributes can transport arbitrary binary data.
CSR 属性 TLV は、証明書署名リクエストの形成方法に関する情報をサーバーからピアに提供します。CSR 属性の目的は、[RFC7030] のセクション 4.5 で説明されています。サーバーは、TLS セッションが確立された後に直接 CSR 属性 TLV を送信してもよい(MAY)。サーバーは、同じメッセージで PKCS#10 TLV の Request-Action フレームを送信してもよい(MAY)。これは、サーバーがこの TLV で提供されるパラメーターを使用してピアに証明書を更新することを望んでいることをピアに示します。サーバーは、DER エンコーディングが Base64 でエンコードされてはならないことを除き、[RFC7030] セクション 4.5.2 に規定されているように CSR 属性 TLV のコンテンツを構築するものとします。[RFC7030] では、そこで使用されるトランスポート プロトコルがテキスト エンコーディングを必要とするため、base64 エンコーディングが使用されます。対照的に、TEAP 属性は任意のバイナリ データを転送できます。
Servers and peers MUST follow the guidance provided in [RFC9908] when creating the CSR-Attributes TLV. Peers MAY ignore the contents of the TLV if they are unable to do so, but then servers may not process PKCS#10 certificate requests for this or any other reason.
サーバーとピアは、CSR 属性 TLV を作成するときに、[RFC9908] で提供されるガイダンスに従わなければなりません (MUST)。ピアは、それができない場合、TLV の内容を無視してもよい (MAY) が、その場合、サーバーは、この理由またはその他の理由で、PKCS#10 証明書要求を処理できない可能性がある。
The CSR-Attributes TLV is defined as follows:
CSR 属性 TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DER Encoded CSR Attributes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
M
0 - Optional TLV
0 - オプションの TLV
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
18 - CSR-Attributes
18 - CSR 属性
Length
長さ
>=2 octets
>=2 オクテット
The Identity-Hint TLV is an optional TLV that can be sent by the peer to the server at the beginning of the Phase 2 TEAP conversation. The purpose of the TLV is to provide a "hint" as to the identity or identities that the peer will be using by subsequent Inner Methods.
Identity-Hint TLV は、フェーズ 2 TEAP 会話の開始時にピアによってサーバーに送信できるオプションの TLV です。TLV の目的は、ピアが後続の内部メソッドで使用する ID に関する「ヒント」を提供することです。
The purpose of this TLV is to solve the "bootstrapping" problem for the server. In order to perform authentication, the server must choose an Inner Method. However, the server has no knowledge of what methods are supported by the peer. Without an identity hint, the server needs to propose a method and then have the peer return a response indicating that the requested method is not available. This negotiation increases the number of round trips required for TEAP to conclude with no additional benefit.
この TLV の目的は、サーバーの「ブートストラップ」問題を解決することです。認証を実行するには、サーバーは内部メソッドを選択する必要があります。ただし、サーバーはピアによってどのようなメソッドがサポートされているかを知りません。ID ヒントがない場合、サーバーはメソッドを提案し、要求されたメソッドが利用できないことを示す応答をピアに返させる必要があります。このネゴシエーションにより、TEAP が締結するまでに必要な往復回数が増加しますが、追加のメリットはありません。
When the Identity-Hint is used, the peer can signal which identities it has available, which enables the server to choose an Inner Method that is appropriate for that identity.
Identity-Hint を使用すると、ピアは利用可能な ID を通知できるため、サーバーはその ID に適した内部メソッドを選択できます。
The peer SHOULD send an Identity-Hint TLV for each Identity-Type that is available to it. For example, if the peer can do both machine and user authentication, it can send two Identity-Hint TLVs with values "host/name.example.com" (for a machine with hostname "name.example.com") and "user@example.com" (for a person with identity "user@example.com").
ピアは、利用可能な Identity-Type ごとに Identity-Hint TLV を送信する必要があります (SHOULD)。たとえば、ピアがマシン認証とユーザー認証の両方を実行できる場合、値「host/name.example.com」（ホスト名「name.example.com」のマシンの場合）と「user@example.com」（アイデンティティ「user@example.com」の個人の場合）を含む 2 つの Identity-Hint TLV を送信できます。
The contents of the Identity-Hint TLV SHOULD be in the format of an NAI [RFC7542], but we note that as given in the example above, Machine identities might not follow that format. As these identities are never used for AAA routing as discussed in [RFC7542], Section 3, the format and definition of these identities are entirely site local. Robust implementations MUST support arbitrary data in the content of this TLV, including binary octets.
Identity-Hint TLV の内容は、NAI [RFC7542] の形式である必要があります (SHOULD)。ただし、上記の例で示したように、マシン ID はその形式に従っていない可能性があることに注意してください。[RFC7542] のセクション 3 で説明されているように、これらの ID は AAA ルーティングには決して使用されないため、これらの ID の形式と定義は完全にサイトローカルです。堅牢な実装は、バイナリ オクテットを含む、この TLV のコンテンツ内の任意のデータをサポートしなければなりません (MUST)。
As the Identity-Hint TLV is a "hint", server implementations are free to ignore the hints given and do whatever is required by site-local policies.
Identity-Hint TLV は「ヒント」であるため、サーバー実装は与えられたヒントを自由に無視し、サイトローカル ポリシーで必要とされることは何でも実行できます。
The Identity-Hint TLV is used only as a guide when selecting which Inner Methods to use. This TLV has no other meaning, and it MUST NOT be used for any other purpose. Specifically, server implementations MUST NOT compare the identities given this TLV to later identities given as part of the Inner Methods. There is no issue with the hint(s) failing to match any subsequent identity that is used.
Identity-Hint TLV は、使用する内部メソッドを選択する際のガイドとしてのみ使用されます。この TLV にはそれ以外の意味はなく、他の目的に使用してはなりません。具体的には、サーバー実装は、この TLV に指定された ID を、内部メソッドの一部として指定された後の ID と比較してはなりません (MUST NOT)。ヒントがその後使用される ID と一致しなくても問題はありません。
The Identity-Hint TLV MUST NOT be used for server unauthenticated provisioning. This TLV is only used as a hint for normal authentication.
Identity-Hint TLV は、サーバーの非認証プロビジョニングに使用してはなりません (MUST NOT)。この TLV は、通常の認証のヒントとしてのみ使用されます。
The Identity-Hint TLV is defined as follows:
Identity-Hint TLV は次のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identity Hint |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
M
0 - Optional TLV
0 - オプションの TLV
R
R
Reserved, set to zero (0)
予約済み、ゼロ (0) に設定
TLV Type
TLV タイプ
19 - Identity-Hint
19 - アイデンティティのヒント
Length
長さ
>=2 octets
>=2 オクテット
To save round trips, multiple TLVs can be sent in a single TEAP packet. However, multiple EAP Payload TLVs, multiple Basic Password Authentication TLVs, or an EAP Payload TLV with a Basic Password Authentication TLV within one single TEAP packet is not supported in this version and MUST NOT be sent. If the peer or EAP server receives multiple EAP Payload TLVs, then it MUST terminate the connection with the Result TLV. The order in which TLVs are encoded in a TEAP packet does not matter. However, there is an order in which TLVs in a packet must be processed:
ラウンドトリップを節約するために、複数の TLV を 1 つの TEAP パケットで送信できます。ただし、複数の EAP ペイロード TLV、複数の基本パスワード認証 TLV、または 1 つの TEAP パケット内の基本パスワード認証 TLV を含む EAP ペイロード TLV は、このバージョンではサポートされていないため、送信してはなりません (MUST NOT)。ピアまたは EAP サーバーが複数の EAP ペイロード TLV を受信した場合、結果 TLV との接続を終了しなければなりません (MUST)。TEAP パケット内で TLV がエンコードされる順序は重要ではありません。ただし、パケット内の TLV を処理する必要がある順序があります。
1. Crypto-Binding TLV
1. 暗号バインディング TLV
2. Intermediate-Result TLV
2. 中間結果 TLV
3. Result TLV or Request-Action TLV
3. 結果TLVまたはリクエストアクションTLV
4. Identity-Type TLV
4. ID タイプ TLV
5. EAP-Payload TLV (Identity-Request) or Basic-Password-Auth-Req TLV
5. EAP ペイロード TLV (アイデンティティ要求) または基本パスワード認証要求 TLV
6. Other TLVs
6. その他のTLV
That is, cryptographic binding is checked before any result is used and identities are checked before proposing an Inner Method, as the identity may influence the chosen Inner Method.
つまり、結果が使用される前に暗号バインディングがチェックされ、選択された内部メソッドにアイデンティティが影響する可能性があるため、内部メソッドを提案する前にアイデンティティがチェックされます。
The following define the meaning of the table entries in the sections below:
以下は、以下のセクションのテーブル エントリの意味を定義します。
0
0
This TLV MUST NOT be present in the message.
この TLV はメッセージ内に存在してはなりません。
0+
0+
Zero or more instances of this TLV MAY be present in the message.
この TLV のインスタンスが 0 個以上メッセージ内に存在してもよい (MAY)。
0-1
0-1
Zero or one instance of this TLV MAY be present in the message.
この TLV のインスタンスが 0 つまたは 1 つメッセージ内に存在してもよい(MAY)。
1
1
Exactly one instance of this TLV MUST be present in the message.
この TLV のインスタンスが 1 つだけメッセージ内に存在しなければなりません (MUST)。
The following table provides a guide to which TLVs may be included in the TEAP packet outside the TLS channel, in which kind of packets, and in what quantity:
次の表は、TLS チャネル外の TEAP パケットにどの TLV が、どの種類のパケットに、どのくらいの量含まれるかを示しています。
+=========+==========+=========+=========+=================+
| Request | Response | Success | Failure | TLVs |
+=========+==========+=========+=========+=================+
| 0-1 | 0 | 0 | 0 | Authority-ID |
+---------+----------+---------+---------+-----------------+
| 0-1 | 0-1 | 0 | 0 | Identity-Type |
+---------+----------+---------+---------+-----------------+
| 0+ | 0+ | 0 | 0 | Vendor-Specific |
+---------+----------+---------+---------+-----------------+
Table 1
Outer TLVs MUST be marked as optional. Vendor TLVs inside of a Vendor-Specific TLV MUST be marked as optional when included in Outer TLVs. Outer TLVs MUST NOT be included in messages after the first two TEAP messages sent by peer and EAP-server, respectively. That is, the first EAP-server-to-peer message and first peer-to-EAP-server message. If the message is fragmented, the whole set of messages is counted as one message. If Outer TLVs are included in messages after the first two TEAP messages, they MUST be ignored.
外部 TLV はオプションとしてマークされなければなりません。ベンダー固有 TLV 内のベンダー TLV は、外部 TLV に含まれる場合、オプションとしてマークされなければなりません (MUST)。外部 TLV は、それぞれピアと EAP サーバーによって送信された最初の 2 つの TEAP メッセージの後のメッセージに含めてはなりません (MUST NOT)。つまり、最初の EAP サーバーからピアへのメッセージと最初のピアから EAP サーバーへのメッセージです。メッセージが断片化されている場合、メッセージのセット全体が 1 つのメッセージとしてカウントされます。最初の 2 つの TEAP メッセージの後のメッセージにアウター TLV が含まれている場合、それらは無視されなければなりません (MUST)。
The following table provides a guide to which Inner TLVs may be encapsulated in TLS in TEAP Phase 2, in which kind of packets, and in what quantity. The messages are as follows: Request is a TEAP Request, Response is a TEAP Response, Success is a message containing a successful Result TLV, and Failure is a message containing a failed Result TLV.
次の表は、TEAP フェーズ 2 でどの内部 TLV をどの種類のパケットにどのくらいの量で TLS にカプセル化できるかのガイドを示しています。メッセージは次のとおりです。要求は TEAP 要求、応答は TEAP 応答、成功は成功した結果 TLV を含むメッセージ、失敗は失敗した結果 TLV を含むメッセージです。
+=======+==========+=========+=========+==========================+
|Request| Response | Success | Failure | TLVs |
+=======+==========+=========+=========+==========================+
|0-1 | 0-1 | 0 | 0 | Identity-Type |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0-1 | 1 | 1 | Result |
+-------+----------+---------+---------+--------------------------+
|0+ | 0+ | 0 | 0 | NAK |
+-------+----------+---------+---------+--------------------------+
|0+ | 0+ | 0+ | 0+ | Error |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0-1 | 0 | 0 | Channel-Binding |
+-------+----------+---------+---------+--------------------------+
|0+ | 0+ | 0+ | 0+ | Vendor-Specific |
+-------+----------+---------+---------+--------------------------+
|0+ | 0+ | 0+ | 0+ | Request-Action |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0-1 | 0 | 0 | EAP-Payload |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0-1 | 0-1 | 0-1 | Intermediate-Result |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0-1 | 0-1 | 0-1 | Crypto-Binding |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0 | 0 | 0 | Basic-Password-Auth-Req |
+-------+----------+---------+---------+--------------------------+
|0 | 0-1 | 0 | 0 | Basic-Password-Auth-Resp |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0 | 0-1 | 0 | PKCS#7 |
+-------+----------+---------+---------+--------------------------+
|0 | 0-1 | 0 | 0 | PKCS#10 |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0-1 | 0-1 | 0 | Trusted-Server-Root |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0 | 0 | 0 | CSR-Attributes TLV |
+-------+----------+---------+---------+--------------------------+
|0 | 0+ | 0 | 0 | Identity-Hint TLV |
+-------+----------+---------+---------+--------------------------+
Table 2
NOTE: Vendor TLVs (included in Vendor-Specific TLVs) sent with a Result TLV MUST be marked as optional. Also, the CSR-Attributes TLV is never transmitted by the peer, and so is treated as a request in this table.
注: 結果 TLV とともに送信されるベンダー TLV (ベンダー固有 TLV に含まれる) は、オプションとしてマークされなければなりません (MUST)。また、CSR 属性 TLV はピアによって送信されることはないため、このテーブルでは要求として扱われます。
As noted in Section 1.1, TEAPv1 implementations are limited in functionality as compared to what the protocol is theoretically capable of. These limitations mean that only a small number of inner methods are fully supported by existing TEAPv1 implementations.
セクション 1.1 で述べたように、TEAPv1 の実装は、プロトコルの理論上の能力に比べて機能が制限されています。これらの制限は、少数の内部メソッドのみが既存の TEAPv1 実装で完全にサポートされていることを意味します。
While Section 6 defines the cryptographic calculations used for key derivation and crypto-binding, this section documents which Inner Methods are known to work and why those methods work. Other Inner Methods may work, but those results are likely to be implementation-specific.
セクション 6 では、キー導出と暗号バインディングに使用される暗号計算を定義しますが、このセクションでは、どの内部メソッドが機能することが知られているか、およびそれらのメソッドが機能する理由について説明します。他の内部メソッドも機能する可能性がありますが、それらの結果は実装固有である可能性があります。
We discuss the issues here without naming particular implementations or making any negative inference about them. The implementations work well enough together in limited situations. Any interoperability issues are due to the complexity and incompleteness of the definitions given in [RFC7170] and are not due to issues with any particular implementation.
ここでは、特定の実装の名前を指定したり、それらについて否定的な推論をしたりすることなく、この問題について説明します。これらの実装は、限られた状況では十分に連携して機能します。相互運用性の問題は、[RFC7170] で与えられた定義の複雑さと不完全さが原因であり、特定の実装の問題が原因ではありません。
The interoperability issues are limited to the use and derivation of the Compound MAC(s), which are derived from the inner MSK and EMSK. In short, implementations are known to derive different values for the Compound MAC(s) when more than one Inner Method provides an EMSK.
相互運用性の問題は、内部 MSK および EMSK から派生する複合 MAC の使用と派生に限定されます。つまり、複数の内部メソッドが EMSK を提供する場合、実装では複合 MAC の異なる値が導出されることが知られています。
The following Inner Methods are known to work. These methods work for both User and Machine credentials.
次の内部メソッドが機能することが知られています。これらの方法は、ユーザーとマシンの両方の資格情報に対して機能します。
* EAP-MSCHAPv2
* EAP-MSCHAPv2
* EAP-TLS
* EAP-TLS
The following combinations of Inner Methods are known to work. These methods work for any order of User and Machine credentials.
以下の内部メソッドの組み合わせが機能することが知られています。これらの方法は、ユーザーおよびマシンの資格情報の任意の順序で機能します。
* EAP-MSCHAPv2 followed by EAP-MSCHAPv2
* EAP-MSCHAPv2 の後に EAP-MSCHAPv2 が続く
* EAP-TLS followed by EAP-MSCHAPv2
* EAP-TLS の後に EAP-MSCHAPv2 が続く
The following combinations of Inner Methods are known to work when both the supplicant and authenticator ignore the EMSK Compound MAC field of the Crypto-Binding TLV. These methods work for any order of User and Machine credentials.
次の内部メソッドの組み合わせは、サプリカントとオーセンティケータの両方が暗号バインディング TLV の EMSK 複合 MAC フィールドを無視する場合に機能することが知られています。これらの方法は、ユーザーおよびマシンの資格情報の任意の順序で機能します。
* EAP-MSCHAPv2 followed by EAP-TLS
* EAP-MSCHAPv2 の後に EAP-TLS が続く
* EAP-TLS followed by EAP-TLS
* EAP-TLS の後に EAP-TLS が続く
The main reason for the limited set of Inner Methods is that the most well-known TEAP supplicant supports only EAP-MSCHAPv2 and EAP-TLS for the Inner Methods. Further, this implementation does not encode the EMSK Compound MAC field in all of the Crypto-Binding TLVs that it sends and ignores that field in all of the Crypto-Binding TLVs that it receives.
内部メソッドのセットが制限されている主な理由は、最もよく知られている TEAP サプリカントが内部メソッドに対して EAP-MSCHAPv2 と EAP-TLS のみをサポートしているためです。さらに、この実装は、送信するすべての暗号バインディング TLV の EMSK 複合 MAC フィールドをエンコードせず、受信するすべての暗号バインディング TLV のそのフィールドを無視します。
The known authenticator implementations support this client, but any other combination of Inner Methods was not tested. As a result, each authenticator implemented entirely different derivations of the EMSK Compound MAC field of the Crypto-Binding TLV due to both the complexity of the cryptographic derivations and the lack of interoperability testing. This difference was discovered only after multiple implementations had been shipping for years.
既知の認証子の実装はこのクライアントをサポートしていますが、内部メソッドの他の組み合わせはテストされていません。その結果、暗号派生の複雑さと相互運用性テストの欠如により、各認証システムは暗号バインディング TLV の EMSK 複合 MAC フィールドのまったく異なる派生を実装しました。この違いは、複数の実装が何年も出荷されてきた後に初めて発見されました。
Any attempt to change TEAPv1 to address these issues would likely result in one or more implementations being non-compliant with the updated specification. Even worse, updates to this specification would result in multiple incompatible versions of TEAPv1.
これらの問題に対処するために TEAPv1 を変更しようとすると、1 つ以上の実装が更新された仕様に準拠しなくなる可能性があります。さらに悪いことに、この仕様を更新すると、TEAPv1 の互換性のないバージョンが複数作成される可能性があります。
That approach is not acceptable.
そのアプローチは受け入れられません。
In the interest of maintaining known interoperability, this specification simply documents these issues rather than trying to correct the problem. Since the TEAP and the Crypto-Binding TLV both contain a Version field, the better path forward is to publish this specification while documenting the large caveats for TEAPv1. Any changes to the TEAP can then be done in a future TEAPv2 specification.
既知の相互運用性を維持するために、この仕様では問題の修正を試みるのではなく、単にこれらの問題を文書化します。TEAP と Crypto-Binding TLV の両方に Version フィールドが含まれているため、より良い方法は、TEAPv1 に関する大きな注意事項を文書化しながらこの仕様を公開することです。TEAP に対する変更は、将来の TEAPv2 仕様で行うことができます。
The definitions given in this section are known to work with all implementations but only for a few Inner Methods, as described above in Section 5. In the interest of avoiding additional complexity in an already complex process, those definitions are given as if they work for all possible Inner Methods.
このセクションで与えられた定義は、セクション 5 で説明したように、すべての実装で機能することが知られていますが、少数の内部メソッドに対してのみ機能します。すでに複雑なプロセスがさらに複雑になるのを避けるために、これらの定義は、考えられるすべての内部メソッドに対して機能するかのように与えられています。
We note that some interoperable implementations have been written based on these definitions, which support Inner Methods other than EAP-MSCHAPv2 and EAP-TLS. It is therefore useful to document the full operation of TEAPv1 despite the known issues. We only caution implementors that Inner Methods that are not listed above in Section 5 are likely to work with only a subset of existing TEAPv1 implementations.
いくつかの相互運用可能な実装はこれらの定義に基づいて記述されており、EAP-MSCHAPv2 と EAP-TLS 以外の内部メソッドをサポートしていることに注意してください。したがって、既知の問題があるにもかかわらず、TEAPv1 の完全な動作を文書化することは有益です。上記のセクション 5 にリストされていない内部メソッドは、既存の TEAPv1 実装のサブセットでのみ機能する可能性があることだけを実装者に警告します。
For key derivation and crypto-binding, TEAP uses the Pseudorandom Function (PRF) and MAC algorithms negotiated in the underlying TLS session. Since these algorithms depend on the TLS version and cipher suite, TEAP implementations need a mechanism to determine the version and cipher suite in use for a particular session. The implementation can then use this information to determine which PRF and MAC algorithm to use.
キーの導出と暗号バインディングには、TEAP は、基礎となる TLS セッションでネゴシエートされた擬似ランダム関数 (PRF) と MAC アルゴリズムを使用します。これらのアルゴリズムは TLS のバージョンと暗号スイートに依存するため、TEAP 実装には、特定のセッションで使用されているバージョンと暗号スイートを決定するメカニズムが必要です。実装では、この情報を使用して、どの PRF アルゴリズムと MAC アルゴリズムを使用するかを決定できます。
With TEAPv1, the TLS master secret is generated as specified in TLS. If session resumption is used, then the master secret is obtained as described in [RFC5077].
TEAPv1 では、TLS の指定に従って TLS マスター シークレットが生成されます。セッション再開が使用される場合、[RFC5077] で説明されているようにマスター シークレットが取得されます。
TEAPv1 makes use of the TLS Keying Material Exporters defined in [RFC5705] to derive the session_key_seed as follows:
TEAPv1 は、[RFC5705] で定義されている TLS キーイング マテリアル エクスポーターを利用して、次のように session_key_seed を導出します。
session_key_seed = TLS-Exporter(
"EXPORTER: teap session key seed",, 40)
No context data is used in the export process.
エクスポート プロセスではコンテキスト データは使用されません。
The session_key_seed is used by the TEAP authentication Phase 2 conversation to both cryptographically bind the Inner Method(s) to the tunnel as well as generate the resulting TEAP session keys. The other TLS keying materials are derived and used as defined in [RFC8446].
session_key_seed は、TEAP 認証フェーズ 2 会話で内部メソッドを暗号的にトンネルにバインドするだけでなく、結果の TEAP セッション キーを生成するために使用されます。他の TLS 鍵マテリアルは、[RFC8446] の定義に従って派生および使用されます。
As TEAP can run multiple Inner Methods, there needs to be a way to cryptographically bind each Inner Method to the TLS tunnel and to cryptographically bind each method to the previous one. This binding is done by deriving a number of intermediate keys and exchanging that information in the Crypto-Binding TLV.
TEAP は複数の内部メソッドを実行できるため、各内部メソッドを TLS トンネルに暗号的にバインドし、各メソッドを前のメソッドに暗号的にバインドする方法が必要です。このバインディングは、多数の中間キーを取得し、その情報を Crypto-Binding TLV で交換することによって行われます。
The key derivation is complicated by a number of factors. An inner method can derive an MSK or (as with basic passwords) not derive an MSK. An Inner Method can derive an EMSK or perhaps not derive an EMSK, or some EAP types may derive different EMSKs for the peer and the server. All of these cases must be accounted for and have recommendations made for how peers and servers can interoperate.
キーの導出は、多くの要因によって複雑になります。内部メソッドは MSK を取得することも、(基本パスワードと同様に) MSK を取得しないこともできます。内部メソッドは EMSK を導出する場合もあれば、EMSK を導出しない場合もあります。また、一部の EAP タイプはピアとサーバーに対して異なる EMSK を導出する場合もあります。これらすべてのケースを考慮し、ピアとサーバーが相互運用できる方法についての推奨事項を作成する必要があります。
There are a number of intermediate keys used to calculate the final MSK and EMSK for TEAP. We give a brief overview here in order to clarify the detailed definitions and derivations given below. As each Inner Method can derive an MSK (or not) and an EMSK (or not), there need to be separate intermediate key calculations for MSK and for EMSK. For the purposes of this overview, we just describe the derivations at a high level and state that the MSK/EMSK issue is addressed in the more detailed text below.
TEAP の最終 MSK および EMSK を計算するために使用される中間キーが多数あります。以下に示す詳細な定義と派生を明確にするために、ここで簡単な概要を説明します。各内部メソッドは MSK (または否か) と EMSK (または否か) を導出できるため、MSK と EMSK に対して個別の中間キー計算が必要です。この概要を説明する目的で、高レベルでの導出についてのみ説明し、MSK/EMSK 問題については以下のより詳細なテキストで説明することを述べます。
For each Inner Method, we derive an IMSK. This key depends on the inner key (MSK or EMSK). This IMSK is then tied to the TLS session via the TLS-PRF to derive an Inner Method Compound Key (IMCK). The IMCK is used to generate a Compound MAC key (CMK). The CMK is mixed with various data from the TEAP negotiation to create Compound MAC field of the Crypto-Binding attribute. This TLV cryptographically binds the Inner Method to the protected tunnel and to the other fields that have been negotiated. The cryptographic binding prevents on-path attacks.
内部メソッドごとに、IMSK を導出します。このキーは内部キー (MSK または EMSK) に依存します。この IMSK は、TLS-PRF を介して TLS セッションに関連付けられ、Inner Method Compound Key (IMCK) が導出されます。IMCK は、複合 MAC キー (CMK) を生成するために使用されます。CMK は、TEAP ネゴシエーションからのさまざまなデータと混合されて、Crypto-Binding 属性の Compound MAC フィールドを作成します。この TLV は、内部メソッドを保護されたトンネルおよびネゴシエートされた他のフィールドに暗号的にバインドします。暗号化バインディングにより、パス上の攻撃が防止されます。
The IMCK for this Inner Method is then mixed with keys from previous Inner Methods, beginning with the TEAP Phase 2 session_key_seed derived above, to yield a Secure IMCK (S-IMCK) for this round. The S-IMCK from the final is then used to derive the MSK and EMSK for TEAP.
次に、この内部メソッドの IMCK が、上記で導出された TEAP フェーズ 2 session_key_seed から始まる以前の内部メソッドからのキーと混合されて、このラウンドのセキュア IMCK (S-IMCK) が生成されます。最終的な S-IMCK は、TEAP の MSK と EMSK を導出するために使用されます。
We differentiate keys for Inner Methods by counting Inner Methods starting from 0 and use an index "j" to refer to an arbitrary inner method. For example, IMCK[0] is the IMCK for the first, or "0" Inner Method. While TEAPv1 is currently limited to one or two Inner Methods (j=0 or j=0,1), further updates could allow for more Inner Method exchanges.
内部メソッドを 0 から数えることによって内部メソッドのキーを区別し、インデックス "j" を使用して任意の内部メソッドを参照します。たとえば、IMCK[0] は最初の、つまり「0」の内部メソッドの IMCK です。TEAPv1 は現在、1 つまたは 2 つの内部メソッド (j=0 または j=0,1) に制限されていますが、さらなる更新により、より多くの内部メソッド交換が可能になる可能性があります。
Each Inner Method generates an IMSK that depends on the EMSK (preferred) or the MSK if it exists, or else it is all zeros. We refer to the IMSK for Inner Method "j" as IMSK[j].
各内部メソッドは、EMSK (推奨) または存在する場合は MSK に依存する IMSK を生成します。そうでない場合はすべて 0 です。内部メソッド "j" の IMSK を IMSK[j] と呼びます。
If an Inner Method supports export of an EMSK, then the IMSK SHOULD be derived from the EMSK, which is defined in [RFC5295]. The optional data parameter is not used in the derivation.
内部メソッドが EMSK のエクスポートをサポートする場合、IMSK は [RFC5295] で定義されている EMSK から派生する必要があります (SHOULD)。オプションの data パラメーターは導出では使用されません。
The above derivation is not a requirement, as some peer implementations of TEAP are also known to not derive IMSK from EMSK and to only derive IMSK from MSK. In order to be compatible with those implementations, the use of EMSK here is not made mandatory.
TEAP の一部のピア実装は、EMSK から IMSK を導出せず、MSK からのみ IMSK を導出することが知られているため、上記の導出は要件ではありません。これらの実装と互換性を持たせるために、ここでの EMSK の使用は必須ではありません。
Some EAP methods may also have the peer and server derive different EMSKs. Mandating an EMSK-based derivation there would prevent interoperability, as the Crypto-Binding TLV contents that depend on EMSK could not then be validated by either side. Those methods SHOULD NOT derive IMSK from EMSK unless the method has a way to negotiate how the EMSK is derived, along with a way to signal that both the peer and server have derived the same EMSK.
一部の EAP メソッドでは、ピアとサーバーが異なる EMSK を導出する場合もあります。そこで EMSK ベースの導出を義務付けると、EMSK に依存する Crypto-Binding TLV コンテンツをどちらの側でも検証できなくなるため、相互運用性が妨げられます。これらのメソッドは、メソッドが EMSK の導出方法をネゴシエートする方法と、ピアとサーバーの両方が同じ EMSK を導出したことを通知する方法を備えていない限り、EMSK から IMSK を導出すべきではありません (SHOULD NOT)。
It is RECOMMENDED that for those EAP methods, implementations take the simpler approach of ignoring EMSK and always derive IMSK from MSK. This approach is less secure, as IMSK no longer cryptographically binds the Inner Method to the TLS tunnel. A better solution is to suggest that deployments of TEAP SHOULD avoid such methods.
これらの EAP メソッドの実装では、EMSK を無視するというより単純なアプローチを採用し、常に MSK から IMSK を導出することが推奨されます。IMSK が内部メソッドを TLS トンネルに暗号的にバインドしないため、このアプローチは安全性が低くなります。より良い解決策は、TEAP の展開ではそのような方法を避ける必要がある (SHOULD) ことを提案することです。
The derivation of IMSK[j] from the j'th EMSK is given as follows:
j 番目の EMSK からの IMSK[j] の導出は次のように与えられます。
IMSK[j] = First 32 octets of TLS-PRF(
EMSK[j],
"TEAPbindkey@ietf.org",
0x00 | 0x00 | 0x40)
Where:
ただし：
* "|" denotes concatenation
* "|"は連結を表します
* The TLS-PRF is defined in [RFC5246] as:
* TLS-PRF は [RFC5246] で次のように定義されています。
PRF(secret, label, seed) = P_<hash>(secret, label | seed)
* The secret is the EMSK from the j'th Inner Method, the usage label used is "TEAPbindkey@ietf.org" consisting of the ASCII value for the label "TEAPbindkey@ietf.org" (without quotes), and the seed consists of the "\0" null delimiter (0x00) and 2-octet unsigned integer length of 64 octets in network byte order (0x00 | 0x40) specified in [RFC5295].
* シークレットは j 番目の内部メソッドからの EMSK で、使用ラベルはラベル「TEAPbindkey@ietf.org」の ASCII 値 (引用符なし) で構成される「TEAPbindkey@ietf.org」です。シードは「\0」ヌル区切り文字 (0x00) とネットワーク バイト オーダーで 64 オクテットの長さの 2 オクテットの符号なし整数 (0x00 |0x40) [RFC5295] で規定されています。
If an Inner Method does not support the export of EMSK but does export MSK, then the IMSK is copied from the MSK of the Inner Method. If the MSK is longer than 32 octets, the IMSK is copied from the first 32 octets and the rest of MSK is ignored. If the MSK is shorter than 32 octets, then the ISMK is copied from MSK and the remaining data in IMSK is padded with zeros to a length of 32 octets. IMSK[j] is then this derived value.
内部メソッドが EMSK のエクスポートをサポートしていないが MSK をエクスポートする場合、IMSK は内部メソッドの MSK からコピーされます。MSK が 32 オクテットより長い場合、IMSK は最初の 32 オクテットからコピーされ、残りの MSK は無視されます。MSK が 32 オクテットより短い場合は、ISMK が MSK からコピーされ、IMSK 内の残りのデータには 32 オクテットの長さになるまでゼロが埋め込まれます。IMSK[j] は、この導出された値になります。
If the Inner Method does not provide either MSK or EMSK, such as when basic password authentication is used or when no Inner Method has been run, then both MSK and IMSK[j] are set to all zeroes (i.e., IMSK[j] = MSK = 32 octets of 0x00s).
基本パスワード認証が使用されている場合、または内部メソッドが実行されていない場合など、内部メソッドが MSK または EMSK のいずれも提供しない場合、MSK と IMSK[j] は両方ともすべて 0 に設定されます (つまり、IMSK[j] = MSK = 32 オクテットの 0x00)。
Note that using an MSK of all zeroes opens up TEAP to on-path attacks as discussed in Section 8.3. It is therefore NOT RECOMMENDED to use Inner Methods that fail to generate an MSK or EMSK. These methods should only be used in conjunction with another Inner Method that does provide for MSK or EMSK generation.
セクション 8.3 で説明したように、すべてゼロの MSK を使用すると、TEAP がパス上攻撃にさらされる可能性があることに注意してください。したがって、MSK または EMSK の生成に失敗する内部メソッドを使用することは推奨されません。これらのメソッドは、MSK または EMSK の生成を提供する別の内部メソッドと組み合わせてのみ使用する必要があります。
It is also RECOMMENDED that TEAP peers order Inner Methods such that methods that generate EMSKs are performed before methods that do not generate EMSKs. Ordering Inner Methods in this manner ensures that the first Inner Method detects any on-path attackers, and any subsequent Inner Method used is therefore secure.
また、EMSK を生成するメソッドが EMSK を生成しないメソッドの前に実行されるように、TEAP ピアが内部メソッドを順序付けることも推奨されます。この方法で内部メソッドを順序付けると、最初の内部メソッドがパス上の攻撃者を確実に検出するため、その後に使用される内部メソッドはすべて安全になります。
For example, Phase 2 could perform both machine authentication using EAP-TLS, followed by user authentication via the Basic Password Authentication TLVs. In that case, the use of EAP-TLS would allow an attacker to be detected before the users' password was sent.
たとえば、フェーズ 2 では、EAP-TLS を使用したマシン認証と、それに続く基本パスワード認証 TLV によるユーザー認証の両方を実行できます。この場合、EAP-TLS を使用すると、ユーザーのパスワードが送信される前に攻撃者を検出できるようになります。
However, it is possible that the peer and server sides might not have the same capability to export EMSK. In order to maintain maximum flexibility while prevent downgrading attack, the following mechanism is in place.
ただし、ピア側とサーバー側に EMSK をエクスポートするための同じ機能がない可能性があります。ダウングレード攻撃を防止しながら最大限の柔軟性を維持するために、次のメカニズムが導入されています。
Once IMSK[j] has been determined, it is mixed via the TLS-PRF with the key S-IMCK[j-1] from a previous round. That mixing derives a new key IMCK[j]. This key is then used to derive both S-IMCK[j] for this round and CMK[j] for this round.
IMSK[j] が決定されると、TLS-PRF を介して前のラウンドの鍵 S-IMCK[j-1] と混合されます。この混合により、新しい鍵 IMCK[j] が導出されます。次に、このキーは、このラウンドの S-IMCK[j] とこのラウンドの CMK[j] の両方を導出するために使用されます。
The derivation of S-IMCK is as follows:
S-IMCK の導出は次のとおりです。
S-IMCK[0] = session_key_seed
For j = 1 to n-1 do
IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1],
"Inner Methods Compound Keys",
IMSK[j])
S-IMCK[j] = first 40 octets of IMCK[j]
CMK[j] = last 20 octets of IMCK[j]
where TLS-PRF is the PRF (described above) negotiated as part of TLS handshake [RFC5246]. The value j refers to a corresponding Inner Method 1 through n. The special value of S-IMCK[0] is used to bootstrap the calculations and can be done as soon as the TLS connection is established and before any inner methods are run.
ここで、TLS-PRF は、TLS ハンドシェイク [RFC5246] の一部としてネゴシエートされた PRF (前述) です。値 j は、対応する内部メソッド 1 ～ n を参照します。S-IMCK[0] の特別な値は計算のブートストラップに使用され、TLS 接続が確立されるとすぐに、内部メソッドが実行される前に実行できます。
In practice, the requirement to use either MSK or EMSK means that an implementation MUST track two independent derivations of IMCK[j], one that depends on the MSK and another that depends on EMSK. That is, we have both values derived from MSK:
実際には、MSK または EMSK のいずれかを使用するという要件は、実装が IMCK[j] の 2 つの独立した導出 (MSK に依存するものと EMSK に依存するもの) を追跡しなければならないことを意味します。つまり、両方の値が MSK から導出されます。
* IMSK_MSK[j]
* IMSK_MSK[j]
* S-IMCK_MSK[j]
* S-IMCK_MSK[j]
* CMK_MSK[j]
* CMK_MSK[j]
and then also values derived from EMSK:
次に、EMSK から導出された値も表示されます。
* IMSK_EMSK[j]
* IMSK_EMSK[j]
* S-IMCK_EMSK[j]
* S-IMCK_EMSK[j]
* CMK_EMSK[j]
* CMK_EMSK[j]
At the conclusion of a successful exchange of Crypto-Binding TLVs, a single S-IMCK[j] is selected based on which Compound MAC value was included in the Crypto-Binding TLV from the client. If EMSK Compound MAC was included, S-IMCK[j] is taken from S-IMCK_EMSK[j]. Otherwise, S-IMCK[j] is taken from S-IMCK_MSK[j].
暗号バインディング TLV の交換が成功すると、クライアントからの暗号バインディング TLV にどの複合 MAC 値が含まれているかに基づいて、単一の S-IMCK[j] が選択されます。EMSK Compound MAC が含まれている場合、S-IMCK[j] は S-IMCK_EMSK[j] から取得されます。それ以外の場合、S-IMCK[j]は S-IMCK_MSK[j]から取得されます。
In order to further secure TEAP, implementations can take steps to increase their security by carefully ordering Inner Methods. Where multiple Inner Methods are used, implementations SHOULD choose an ordering so that the first Inner Method used is one that derives EMSK.
TEAP の安全性をさらに高めるために、実装では内部メソッドを慎重に順序付けすることでセキュリティを強化する措置を講じることができます。複数の内部メソッドが使用される場合、実装は最初に使用される内部メソッドが EMSK を導出するような順序を選択する必要があります (SHOULD)。
For an EAP server, it can select the first Inner Method to be one that derives EMSK. Since ordering of Inner Methods is not otherwise important in EAP, any chosen order is supported by the peer that receives this request.
EAP サーバーの場合、EMSK を導出する最初の内部メソッドを選択できます。EAP では内部メソッドの順序はそれほど重要ではないため、選択された順序はすべて、この要求を受信するピアによってサポートされます。
For an EAP peer, it can choose its response to a server's request for a particular type of authentication. The peer can ignore that request and return an Inner Method that derives EMSK. Again, since the ordering of Inner Methods is not otherwise important in EAP, any chosen order is supported by the server that receives this response. Once the more secure authentication has succeed, the server then requests the other type of authentication and the peer can respond with the chosen type of authentication.
EAP ピアの場合、特定の種類の認証に対するサーバーの要求に対する応答を選択できます。ピアはその要求を無視して、EMSK を導出する内部メソッドを返すことができます。繰り返しますが、内部メソッドの順序は EAP では重要ではないため、選択された順序は、この応答を受信するサーバーによってサポートされます。より安全な認証が成功すると、サーバーは他のタイプの認証を要求し、ピアは選択されたタイプの認証で応答できます。
Implementations can also provide configuration flags, policies, or documented recommendations that control the type of Inner Methods used or verify their order. These configurations allow implementations and administrators to control their security exposure to on-path attackers.
実装では、使用される内部メソッドのタイプを制御したり、その順序を検証したりする構成フラグ、ポリシー、または文書化された推奨事項を提供することもできます。これらの構成により、実装と管理者は、パス上の攻撃者に対するセキュリティの露出を制御できます。
Implementations can permit administrators to configure TEAP so that the following security checks are enforced:
実装では、管理者が次のセキュリティ チェックが強制されるように TEAP を構成できます。
* Verifying that the first Inner Method used is one that derives EMSK. If this is not done, a fatal error can be returned.
* 使用された最初の内部メソッドが EMSK を導出するメソッドであることを確認します。これを行わないと、致命的なエラーが返される可能性があります。
* Verifying that if any Inner Method derives EMSK, the received Crypto-Binding TLV for that method contains an EMSK Compound MAC. If an EMSK has been derived and no EMSK Compound MAC is seen, a fatal error can be returned.
* いずれかの内部メソッドが EMSK を導出する場合、そのメソッドに対して受信した暗号バインディング TLV に EMSK 複合 MAC が含まれていることを確認します。EMSK が導出されていて、EMSK 複合 MAC が見つからない場合は、致命的なエラーが返される可能性があります。
The goal of these suggestions is to enforce the use of the EMSK Compound MAC to protect the TEAP session from on-path attackers. If these suggestions are not enforced, then the TEAP session is vulnerable.
これらの提案の目的は、EMSK 複合 MAC の使用を強制して、パス上の攻撃者から TEAP セッションを保護することです。これらの提案が強制されない場合、TEAP セッションは脆弱になります。
Most of these suggestions are not normative, as some existing implementations are known to not follow them. Instead, these suggestions are here to inform new implementors, along with administrators, of the issues surrounding this subject.
一部の既存の実装はそれらに従っていないことが知られているため、これらの提案のほとんどは規範的なものではありません。代わりに、これらの提案は、管理者とともに新しい実装者に、この主題を取り巻く問題について知らせるためにここにあります。
After an Inner Method has been completed successfully and the inner keys have been derived, the server sends a Crypto-Binding TLV to the peer. If the Inner Method has failed, the server does not send a Crypto-Binding TLV.
内部メソッドが正常に完了し、内部キーが導出された後、サーバーは暗号バインディング TLV をピアに送信します。内部メソッドが失敗した場合、サーバーは暗号バインディング TLV を送信しません。
The peer verifies the Crypto-Binding TLV by applying the rules defined in Section 4.2.13. If verification passes, the peer responds with its own Crypto-Binding TLV, which the server in turn verifies. If at any point verification fails, the party that makes this determination terminates the session.
ピアは、セクション 4.2.13 で定義されたルールを適用して、暗号バインディング TLV を検証します。検証に合格すると、ピアは独自の暗号バインディング TLV で応答し、サーバーがそれを検証します。いずれかの時点で検証が失敗した場合、この決定を行った当事者はセッションを終了します。
The Crypto-Binding TLV is normally sent in conjunction with other TLVs that indicate intermediate or final results or that begin negotiation of a new Inner Method. This negotiation does not otherwise affect the Crypto-Binding TLV.
暗号バインディング TLV は通常、中間結果または最終結果を示す、または新しい内部メソッドのネゴシエーションを開始する他の TLV と組み合わせて送信されます。このネゴシエーションは、それ以外の場合、暗号バインディング TLV には影響しません。
While Section 4.2.13 defines that the Compound MAC fields exist in the Crypto-Binding TLV, it does not describe the derivation and management of those fields. This derivation is complex and is therefore located here along with the other key derivations.
セクション 4.2.13 では、複合 MAC フィールドが暗号バインディング TLV に存在することを定義していますが、それらのフィールドの導出と管理については説明していません。この導出は複雑であるため、他の主要な導出とともにここに配置されます。
The following text defines how the server and peer compute, send, and then verify the Compound MAC fields Crypto-Binding TLV. Depending on the Inner Method and site policy, the Crypto-Binding TLV can contain only an MSK Compound MAC (Flags=2), only the EMSK Compound MAC (Flags=2), or both Compound MACs (Flags=3). Each party to the TEAP session follows its own set of procedures to compute and verify the Compound MAC fields.
次のテキストは、サーバーとピアが複合 MAC フィールドの暗号バインディング TLV を計算、送信、検証する方法を定義します。内部メソッドとサイト ポリシーに応じて、暗号バインディング TLV には MSK 複合 MAC (Flags=2) のみ、EMSK 複合 MAC (Flags=2) のみ、または両方の複合 MAC (Flags=3) を含めることができます。TEAP セッションの各当事者は、独自の一連の手順に従って複合 MAC フィールドを計算および検証します。
The determination of the contents of the Crypto-Binding TLV is done separately for each Inner Method. If at any point the verification of a Compound MAC fails, the determining party returns a fatal error as described in Section 3.9.3.
Crypto-Binding TLV の内容の決定は、内部メソッドごとに個別に行われます。いずれかの時点で複合 MAC の検証が失敗した場合、決定者はセクション 3.9.3 で説明されているように致命的エラーを返します。
We presume that each peer and server have site policies that may or may not require the use of the MSK Compound MAC and/or the EMSK Compound MAC. These policies can be enforced globally for all Inner Methods, or they can be enforced separately on each Inner Method. These policies could be enabled automatically when the EAP method is known to always generate an EMSK and could otherwise be configurable.
各ピアおよびサーバーには、MSK 複合 MAC および/または EMSK 複合 MAC の使用を必要とするサイト ポリシーがあると想定されます。これらのポリシーは、すべての内部メソッドに対してグローバルに適用することも、各内部メソッドに対して個別に適用することもできます。これらのポリシーは、EAP メソッドが常に EMSK を生成することがわかっている場合には自動的に有効にすることができ、それ以外の場合は構成可能にすることができます。
The server initiates crypto-binding by determining which Compound MAC(s) to use, computing their value(s), placing the resulting Compound MAC(s) into the Crypto-Binding TLV, and then sending it to the peer.
サーバーは、使用する複合 MAC を決定し、その値を計算し、結果の複合 MAC を暗号バインディング TLV に配置してピアに送信することにより、暗号バインディングを開始します。
Then, the steps taken by the server are as follows:
その後、サーバーが実行する手順は次のとおりです。
* If the Inner Method is known to generate only MSK, or if the server's policy is to not use EMSK Compound MACs:
* 内部メソッドが MSK のみを生成することがわかっている場合、またはサーバーのポリシーが EMSK 複合 MAC を使用しないことである場合:
- The server computes the MSK Compound MAC using the MSK of the Inner Method. The server does not use the EMSK Compound MAC field (Flags=2).
- サーバーは、内部メソッドの MSK を使用して MSK 複合 MAC を計算します。サーバーは EMSK 複合 MAC フィールド (Flags=2) を使用しません。
Otherwise, the EMSK is available.
それ以外の場合は、EMSK を使用できます。
* If the server's policy permits the use of the MSK Compound MAC:
* サーバーのポリシーで MSK 複合 MAC の使用が許可されている場合:
- The sender computes the MSK Compound MAC along with the EMSK Compound MAC (Flags=3).
- 送信者は、EMSK 複合 MAC (Flags=3) とともに MSK 複合 MAC を計算します。
Otherwise, the server's policy does not allow the use of the MSK Compound MAC:
それ以外の場合、サーバーのポリシーにより MSK 複合 MAC の使用が許可されません。
- The server computes only the EMSK Compound MAC (Flags=1).
- サーバーは EMSK 複合 MAC (Flags=1) のみを計算します。
The peer verifies the Crypto-Binding TLV it receives from the server. It then replies with its own crypto-binding response by determining which Compound MAC(s) to use, computing their value(s), placing the resulting Compound MAC(s) into the Crypto-Binding TLV, and then sending it to the server. The result of this process is either a fatal error or one or more Compound MACs that are placed in the Crypto-Binding TLV and sent to the server.
ピアは、サーバーから受信した暗号バインディング TLV を検証します。次に、使用する複合 MAC を決定し、その値を計算し、結果の複合 MAC を暗号バインディング TLV に配置して、サーバーに送信することにより、独自の暗号バインディング応答で応答します。このプロセスの結果は、致命的なエラーか、暗号バインディング TLV に配置されてサーバーに送信される 1 つ以上の複合 MAC になります。
Then, the steps taken by the peer are as follows:
次に、ピアが実行する手順は次のとおりです。
* If the peer site policy requires the use of the EMSK Compound MAC:
* ピア サイト ポリシーで EMSK 複合 MAC の使用が必要な場合:
- The peer checks if the Flags field indicates the presence of the EMSK Compound MAC (Flags=1 or 3). If the Flags field has any other value, the peer returns a fatal error.
- ピアは、Flags フィールドが EMSK 複合 MAC (Flags=1 または 3) の存在を示しているかどうかを確認します。Flags フィールドに他の値がある場合、ピアは致命的なエラーを返します。
- The peer checks if the Inner Method has derived an EMSK. If not, the peer returns a fatal error.
- ピアは、内部メソッドが EMSK を導出したかどうかを確認します。そうでない場合、ピアは致命的なエラーを返します。
Otherwise, the peer site policy does not require the use of the EMSK Compound MAC and the EMSK may or may not exist.
それ以外の場合、ピア サイト ポリシーは EMSK 複合 MAC の使用を必要とせず、EMSK は存在する場合と存在しない場合があります。
* If the Inner Method is known to generate only MSK and not EMSK:
* 内部メソッドが EMSK ではなく MSK のみを生成することがわかっている場合:
- The peer checks if the Flags field indicates that only the MSK Compound MAC exists (Flags=2). If the Flags field has any other value, the peer returns a fatal error.
- ピアは、Flags フィールドが MSK 複合 MAC のみが存在することを示しているかどうかを確認します (Flags=2)。Flags フィールドに他の値がある場合、ピアは致命的なエラーを返します。
Otherwise, the MSK exists, the EMSK may or may not exist, and the peer allows the use of the EMSK Compound MAC. The peer may have received one or two Compound MACs (Flags=1,2,3). Any Compound MAC that is present is verified. No further action is taken by the peer if a particular Compound MAC is not present. No further action is taken by the peer if an unexpected Compound MAC is present.
それ以外の場合、MSK は存在し、EMSK は存在する場合と存在しない可能性があり、ピアは EMSK 複合 MAC の使用を許可します。ピアは 1 つまたは 2 つの複合 MAC (フラグ = 1、2、3) を受信した可能性があります。Any Compound MAC that is present is verified.特定の複合 MAC が存在しない場合、ピアはそれ以上のアクションを実行しません。予期しない複合 MAC が存在する場合、ピアはそれ以上のアクションを実行しません。
Note that due to earlier validation of the Flags field (Section 4.2.13), at least one Compound MAC must now exist (Flags=1,2,3).
Flags フィールド (セクション 4.2.13) の以前の検証により、少なくとも 1 つの複合 MAC が存在する必要があることに注意してください (Flags=1、2、3)。
* If the peer has received an MSK Compound MAC, it verifies it and returns a fatal error if verification fails.
* ピアが MSK 複合 MAC を受信した場合、それを検証し、検証が失敗した場合は致命的なエラーを返します。
* If EMSK is available and the peer has received an EMSK Compound MAC, it verifies it and returns a fatal error if verification fails.
* EMSK が使用可能で、ピアが EMSK 複合 MAC を受信している場合、ピアはそれを検証し、検証が失敗した場合は致命的なエラーを返します。
The peer creates a crypto-binding response by determining which Compound MAC(s) to use, computing their value(s), placing the resulting Compound MAC(s) into the Crypto-Binding TLV, and then sending it to the server.
ピアは、使用する複合 MAC を決定し、その値を計算し、結果の複合 MAC を暗号バインディング TLV に配置して、サーバーに送信することにより、暗号バインディング応答を作成します。
The steps taken by the peer are then as follows.
ピアが実行する手順は次のとおりです。
* If the peer received an MSK Compound MAC from the server:
* ピアがサーバーから MSK 複合 MAC を受信した場合:
- Since the MSK always exists, this step is always possible. The peer computes the MSK Compound MAC for the response (Flags=2).
- MSK は常に存在するため、このステップはいつでも可能です。ピアは応答の MSK 複合 MAC を計算します (Flags=2)。
* If the peer site policy requires the use of the EMSK Compound MAC:
* ピア サイト ポリシーで EMSK 複合 MAC の使用が必要な場合:
- The preceding steps taken by the peer ensures that the EMSK exists and the server had sent an EMSK Compound MAC. The peer computes the EMSK Compound MAC for the response. The Flags field is updated (Flags=1,3).
- ピアが実行した前述の手順により、EMSK が存在し、サーバーが EMSK 複合 MAC を送信したことが確認されます。ピアは、応答の EMSK 複合 MAC を計算します。Flags フィールドが更新されます (Flags=1,3)。
Otherwise, if the EMSK exists:
それ以外の場合、EMSK が存在する場合:
- The peer computes the EMSK Compound MAC for the response. The Flags field is updated (Flags=1,3).
- ピアは、応答の EMSK 複合 MAC を計算します。Flags フィールドが更新されます (Flags=1,3)。
The server processes the response from the peer via the following steps:
サーバーは、次の手順に従ってピアからの応答を処理します。
* If the server site policy requires the use of the EMSK Compound MAC:
* サーバー サイト ポリシーで EMSK 複合 MAC の使用が必要な場合:
- The server checks if the Flags field indicates the presence of the EMSK Compound MAC (Flags=1 or 3). If the Flags field has any other value, the server returns a fatal error.
- サーバーは、Flags フィールドが EMSK 複合 MAC (Flags=1 または 3) の存在を示しているかどうかを確認します。Flags フィールドに他の値がある場合、サーバーは致命的なエラーを返します。
- The server checks if the Inner Method has derived an EMSK. If not, the server returns a fatal error.
- サーバーは、内部メソッドが EMSK を導出したかどうかを確認します。そうでない場合、サーバーは致命的なエラーを返します。
* If the Inner Method is known to generate only MSK and not EMSK:
* 内部メソッドが EMSK ではなく MSK のみを生成することがわかっている場合:
- The server checks if the Flags field indicates that only the MSK Compound MAC exists (Flags=2). If the Flags field has any other value, the server returns a fatal error.
- サーバーは、Flags フィールドが MSK 複合 MAC のみが存在することを示しているかどうかを確認します (Flags=2)。Flags フィールドに他の値がある場合、サーバーは致命的なエラーを返します。
Otherwise, the MSK exists and the EMSK may or may not exist. The server may have received one or two Compound MACs (Flags=1,2,3). Any Compound MAC that is present is verified. No further action is taken by the server if a particular Compound MAC is not present. No further action is taken by the server if an unexpected Compound MAC is present.
それ以外の場合は、MSK が存在し、EMSK が存在する場合と存在しない場合があります。サーバーは 1 つまたは 2 つの複合 MAC (フラグ = 1、2、3) を受信した可能性があります。存在するすべての複合 MAC が検証されます。特定の複合 MAC が存在しない場合、サーバーはそれ以上のアクションを実行しません。予期しない複合 MAC が存在する場合、サーバーはそれ以上のアクションを実行しません。
* If the server has received an MSK Compound MAC, it verifies it and returns a fatal error if verification fails.
* サーバーが MSK 複合 MAC を受信した場合、それを検証し、検証が失敗した場合は致命的なエラーを返します。
* If EMSK is available and the server has received an EMSK Compound MAC, it verifies it and returns a fatal error if verification fails.
* EMSK が使用可能で、サーバーが EMSK 複合 MAC を受信した場合、サーバーはそれを検証し、検証が失敗した場合は致命的なエラーを返します。
Once the above steps have concluded, the server either continues authentication with another Inner Method or it returns a Result TLV.
上記の手順が完了すると、サーバーは別の内部メソッドで認証を続行するか、結果 TLV を返します。
In earlier drafts of this document, the descriptions of the key derivations had issues that were only discovered after TEAP had been widely implemented. These issues need to be documented in order to enable interoperable implementations.
このドキュメントの初期の草案では、キー導出の説明に問題があり、TEAP が広く実装された後でのみ発見されました。相互運用可能な実装を可能にするために、これらの問題を文書化する必要があります。
As noted above, some inner EAP methods derive MSK but do not derive EMSK. When there is no EMSK, it is therefore not possible to derive IMCK_EMSK[j] from it. The choice of multiple implementations was then to simply define:
上で述べたように、一部の内部 EAP メソッドは MSK を導出しますが、EMSK は導出しません。したがって、EMSK がない場合、EMSK から IMCK_EMSK[j] を導出することはできません。複数の実装の選択は、単に以下を定義することでした。
IMCK_EMSK[j] = IMCK_EMSK[j - 1]
This definition can be trivially implemented by simply keeping a cached copy of IMCK_EMSK in a data structure. If EMSK is available, IMCK_EMCK is updated from it via the TLS-PRF function as defined above. If EMSK is not available, then the IMCK_EMSK value is unmodified.
この定義は、IMCK_EMSK のキャッシュされたコピーをデータ構造内に保持するだけで簡単に実装できます。EMSK が利用可能な場合、上で定義したように、TLS-PRF 関数を介して、EMSK_EMCK がそこから更新されます。EMSK が使用できない場合、IMCK_EMSK 値は変更されません。
This behavior was not explicitly anticipated by earlier drafts of this document. It instead appears to be an accidental outcome of implementing the derivations above with the limitation of a missing EMSK. This behavior is explicitly called out here in the interest of fully documenting TEAP.
この動作は、このドキュメントの以前の草案では明示的に予想されていませんでした。むしろ、EMSK が欠落しているという制限を伴う上記の導出を実装したことによる偶然の結果であるように見えます。TEAP を完全に文書化するために、この動作はここで明示的に呼び出されます。
Another unintended consequence is in the calculation of the Crypto-Binding TLV. That TLV includes compound MACs that depend on the MSK and EMSK of the current authentication method. Where the current method does not provide an EMSK, the Crypto-Binding TLV does not include a compound MAC that depends on the EMSK. Where the current method does not provide an MSK, the Crypto-Binding TLV includes a compound MAC that depends on a special "all zero" IMSK as discussed earlier.
もう 1 つの意図しない結果は、暗号バインディング TLV の計算にあります。その TLV には、現在の認証方法の MSK および EMSK に依存する複合 MAC が含まれています。現在の方法で EMSK が提供されない場合、Crypto-Binding TLV には EMSK に依存する複合 MAC が含まれません。現在の方法が MSK を提供しない場合、暗号バインディング TLV には、前述したように特別な「オール ゼロ」IMSK に依存する複合 MAC が含まれます。
The result of this definition is that the final Crypto-Binding TLV in an inner TEAP exchange may not include a compound MAC that depends on EMSK, even if earlier EAP methods in the Phase 2 exchange provided an EMSK. This result likely has negative effects on security, though the full impact is unknown at the time of writing this document.
この定義の結果、フェーズ 2 交換の以前の EAP メソッドが EMSK を提供していたとしても、内部 TEAP 交換の最終的な暗号バインディング TLV には、EMSK に依存する複合 MAC が含まれない可能性があります。この結果はセキュリティに悪影響を及ぼす可能性がありますが、このドキュメントの執筆時点では完全な影響は不明です。
These design flaws have nonetheless resulted in multiple interoperable implementations. We note that these implementations seem to support only EAP-TLS and the EAP-FAST-MSCHAPv2 variant of EAP-MSCHAPv2. Other inner EAP methods may work by accident but are not likely to work by design. For this document, we can only ensure that the behavior of TEAPv1 is fully documented, even if that behavior was an unintended consequence of unclear text in earlier versions of this specification.
それにもかかわらず、これらの設計上の欠陥により、複数の相互運用可能な実装が実現されました。これらの実装は、EAP-TLS と EAP-MSCHAPv2 の EAP-FAST-MSCHAPv2 バリアントのみをサポートしているようであることに注意してください。他の内部 EAP メソッドは偶然機能する可能性がありますが、設計どおりに機能する可能性は高くありません。この文書では、TEAPv1 の動作が完全に文書化されていることを確認することしかできません。たとえその動作が、この仕様の以前のバージョンにおける不明瞭なテキストの意図しない結果であったとしてもです。
We expect that these issues will be addressed in a future revision of TEAP.
これらの問題は、TEAP の将来の改訂版で解決されることを期待しています。
For Inner Methods that generate keying material, further protection against on-path attacks is provided through cryptographically binding keying material established by both TEAP Phase 1 and TEAP Phase 2 conversations. After each successful inner EAP authentication, EAP EMSK and/or MSKs are cryptographically combined with key material from TEAP Phase 1 to generate a CMK. The CMK is used to calculate the Compound MAC as part of the Crypto-Binding TLV described in Section 4.2.13, which helps provide assurance that the same entities are involved in all communications in TEAP. During the calculation of the Compound MAC, the MAC field is filled with zeros.
キーイング マテリアルを生成する内部メソッドの場合、TEAP フェーズ 1 と TEAP フェーズ 2 の両方の会話によって確立された暗号化バインディング キーイング マテリアルを通じて、パス上の攻撃に対するさらなる保護が提供されます。内部 EAP 認証が成功するたびに、EAP EMSK および/または MSK が TEAP フェーズ 1 のキー素材と暗号的に結合されて、CMK が生成されます。CMK は、セクション 4.2.13 で説明されている暗号バインディング TLV の一部として複合 MAC を計算するために使用され、同じエンティティが TEAP のすべての通信に関与していることを保証するのに役立ちます。複合 MAC の計算中、MAC フィールドはゼロで埋められます。
The Compound MAC computation is as follows:
複合 MAC の計算は次のとおりです。
Compound MAC = the first 20 octets of MAC( CMK[n], BUFFER )
where n is the number of the last successfully executed inner method, MAC is the MAC function negotiated in TLS (e.g., TLS 1.2 in [RFC5246]), and BUFFER is created after concatenating these fields in the following order:
ここで、n は最後に正常に実行された内部メソッドの番号、MAC は TLS ([RFC5246] の TLS 1.2 など) でネゴシエートされた MAC 関数、BUFFER はこれらのフィールドを次の順序で連結した後に作成されます。
1. The entire Crypto-Binding TLV attribute with both the EMSK and MSK Compound MAC fields zeroed out.
1. EMSK および MSK 複合 MAC フィールドの両方がゼロに設定された暗号バインディング TLV 属性全体。
2. The EAP Type sent by the other party in the first TEAP message, which MUST be TEAP, encoded as one octet of 0x37.
2. 最初の TEAP メッセージで相手によって送信された EAP タイプ (TEAP でなければなりません)。0x37 の 1 オクテットとしてエンコードされます。
3. All the Outer TLVs from the first TEAP message sent by the EAP server to the peer. If a single TEAP message is fragmented into multiple TEAP packets, then the Outer TLVs in all the fragments of that message MUST be included.
3. EAP サーバーによってピアに送信された最初の TEAP メッセージからのすべてのアウター TLV。単一の TEAP メッセージが複数の TEAP パケットにフラグメント化される場合、そのメッセージのすべてのフラグメントにアウター TLV が含まれなければなりません (MUST)。
4. All the Outer TLVs from the first TEAP message sent by the peer to the EAP server. If a single TEAP message is fragmented into multiple TEAP packets, then the Outer TLVs in all the fragments of that message MUST be included.
4. ピアによって EAP サーバーに送信された最初の TEAP メッセージからのすべてのアウター TLV。単一の TEAP メッセージが複数の TEAP パケットにフラグメント化される場合、そのメッセージのすべてのフラグメントにアウター TLV が含まれなければなりません (MUST)。
If no Inner Method is run, then no MSK or EMSK will be generated. If an IMSK needs to be generated, then the MSK and therefore the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets of 0x00s).
内部メソッドが実行されない場合、MSK または EMSK は生成されません。IMSK を生成する必要がある場合、MSK、したがって IMSK はすべて 0 に設定されます (つまり、IMSK = MSK = 32 オクテットの 0x00)。
Note that there is no boundary marker between the fields in steps (3) and (4). However, the server calculates the compound MAC using the Outer TLVs it sent and the Outer TLVs it received from the peer. On the other side, the peer calculates the compound MAC using the outer TLVs it sent and the Outer TLVs it received from the server. As a result, any modification in transit of the Outer TLVs will be detected because the two sides will calculate different values for the compound MAC.
手順 (3) と (4) のフィールドの間に境界マーカーがないことに注意してください。ただし、サーバーは、送信したアウター TLV とピアから受信したアウター TLV を使用して複合 MAC を計算します。一方、ピアは、送信した外部 TLV とサーバーから受信した外部 TLV を使用して複合 MAC を計算します。その結果、両側で複合 MAC の異なる値が計算されるため、アウター TLV の転送中の変更が検出されます。
If no key-generating Inner Method is run, then no MSK or EMSK will be generated. If an IMSK needs to be generated, then the MSK and therefore the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets of 0x00s)
キーを生成する内部メソッドが実行されない場合、MSK または EMSK は生成されません。IMSK を生成する必要がある場合、MSK がすべて 0 に設定され、したがって IMSK もすべて 0 に設定されます (つまり、IMSK = MSK = 32 オクテットの 0x00)。
TEAP authentication assures the MSK and EMSK output from running TEAP are the combined result of all Inner Methods by generating an IMCK. The IMCK is mutually derived by the peer and the server as described in Section 6.2 by combining the MSKs from Inner Methods with key material from TEAP Phase 1. The resulting MSK and EMSK are generated from the final ("n"th) Inner Method, as part of the IMCK[n] key hierarchy via the following derivation:
TEAP 認証は、IMCK を生成することにより、実行中の TEAP からの MSK および EMSK 出力がすべての内部メソッドの結合結果であることを保証します。IMCK は、セクション 6.2 で説明されているように、内部メソッドの MSK と TEAP フェーズ 1 のキー素材を組み合わせることで、ピアとサーバーによって相互に導出されます。 結果として得られる MSK と EMSK は、次の導出を介して、IMCK[n] キー階層の一部として、最終 (「n」番目) の内部メソッドから生成されます。
MSK = the first 64 octets of TLS-PRF(S-IMCK[n],
"Session Key Generating Function")
EMSK = the first 64 octets of TLS-PRF(S-IMCK[n],
"Extended Session Key Generating Function")
The secret is S-IMCK[n], where n is the number of the last generated S-IMCK[j] from Section 6.2. The label is the ASCII value for the string without quotes. The seed is empty (0 length) and is omitted from the derivation.
秘密は S-IMCK[n] です。ここで、n はセクション 6.2 で最後に生成された S-IMCK[j] の番号です。ラベルは、引用符のない文字列の ASCII 値です。シードは空 (長さ 0) であり、導出から省略されます。
The EMSK is typically only known to the TEAP peer and server and is not provided to a third party. The derivation of additional keys and transportation of these keys to a third party are outside the scope of this document.
EMSK は通常、TEAP ピアとサーバーのみに知られており、サードパーティには提供されません。追加のキーの導出と、これらのキーのサードパーティへの転送については、このドキュメントの範囲外です。
If no Inner Method has created an MSK or EMSK, the MSK and EMSK will be generated directly from the session_key_seed meaning S-IMCK[0] = session_key_seed.
内部メソッドが MSK または EMSK を作成していない場合、MSK および EMSK は session_key_seed から直接生成されます。これは、S-IMCK[0] = session_key_seed を意味します。
As we noted above, not all Inner Methods generate both MSK and EMSK, so we have to maintain two independent derivations of S-IMCK[j], one for each of MSK[j] and EMSK[j]. The final derivation using S-IMCK[n] must choose only one of these keys.
上で述べたように、すべての内部メソッドが MSK と EMSK の両方を生成するわけではないため、MSK[j] と EMSK[j] ごとに 1 つずつ、S-IMCK[j] の 2 つの独立した導出を維持する必要があります。S-IMCK[n] を使用した最終的な導出では、これらのキーの 1 つだけを選択する必要があります。
If the Crypto-Binding TLV contains an EMSK compound MAC, then the derivation is taken from the S-IMCK_EMSK[n]. Otherwise, it is taken from the S-IMCK_MSK[n].
暗号バインディング TLV に EMSK 複合 MAC が含まれている場合、派生は S-IMCK_EMSK[n] から取得されます。それ以外の場合は、S-IMCK_MSK[n] から取得されます。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the TEAP protocol in accordance with [BCP26].
このセクションは、[BCP26] に準拠した TEAP プロトコルに関連する値の登録に関する Internet Assigned Numbers Authority (IANA) へのガイダンスを提供します。
Except as noted below, IANA has updated the "Tunnel Extensible Authentication Protocol (TEAP) Parameters" registry to change the Reference field in all tables from [RFC7170] to RFC 9930.
以下に記載されている場合を除き、IANA は「Tunnel Extensible Authentication Protocol (TEAP) Parameters」レジストリを更新し、すべてのテーブルの Reference フィールドを [RFC7170] から RFC 9930 に変更しました。
IANA has updated the references in the "TEAP TLV Types" registry from [RFC7170] to RFC 9930 and added TLV 18 and TLV 19 to the registry. The Unassigned values then begin at 20 instead of at 18.
IANA は、「TEAP TLV Types」レジストリの参照を [RFC7170] から RFC 9930 に更新し、TLV 18 と TLV 19 をレジストリに追加しました。この場合、未割り当ての値は 18 ではなく 20 から始まります。
+==========+====================+===========+
| Value | Description | Reference |
+==========+====================+===========+
| 18 | CSR-Attributes TLV | RFC 9930 |
+----------+--------------------+-----------+
| 19 | Identity-Hint TLV | RFC 9930 |
+----------+--------------------+-----------+
| 20-16383 | Unassigned |
+----------+--------------------------------+
Table 3
IANA has closed the "TEAP PAC TLV (value 11) PAC Attribute Type Codes" and "TEAP PAC TLV (value 11) PAC-Type Type Codes" registries to new registrations and updated those registries with the following note:
IANA は、「TEAP PAC TLV (値 11) PAC 属性タイプ コード」および「TEAP PAC TLV (値 11) PAC-Type Type Codes」レジストリの新規登録を終了し、次の注記を付けてこれらのレジストリを更新しました。
This registry has been closed. See RFC 9930.
このレジストリは閉鎖されました。RFC 9930 を参照してください。
IANA has updated the "TEAP Error TLV (value 5) Error Codes" registry to add the following entries:
IANA は、「TEAP エラー TLV (値 5) エラー コード」レジストリを更新して、次のエントリを追加しました。
+=======+=========================================+===========+
| Value | Description | Reference |
+=======+=========================================+===========+
| 1032 | Inner Method not supported | RFC 9930 |
+-------+-----------------------------------------+-----------+
| 2003 | The Crypto-Binding TLV is invalid | RFC 9930 |
| | (Version, or Received-Ver, or Sub-Type) | |
+-------+-----------------------------------------+-----------+
| 2004 | The first Inner Method did not derive | RFC 9930 |
| | EMSK | |
+-------+-----------------------------------------+-----------+
| 2005 | The Crypto-Binding TLV did not include | RFC 9930 |
| | a required MSK Compound MAC | |
+-------+-----------------------------------------+-----------+
| 2006 | The MSK Compound MAC fails verification | RFC 9930 |
+-------+-----------------------------------------+-----------+
| 2007 | The Crypto-Binding TLV did not include | RFC 9930 |
| | a required EMSK Compound MAC | |
+-------+-----------------------------------------+-----------+
| 2008 | The EMSK Compound MAC fails | RFC 9930 |
| | verification | |
+-------+-----------------------------------------+-----------+
| 2009 | The EMSK Compound MAC exists, but the | RFC 9930 |
| | Inner Method did not derive EMSK | |
+-------+-----------------------------------------+-----------+
Table 4
IANA has updated the "TLS Exporter Labels" registry to change the Reference field for Value "EXPORTER: teap session key seed" as follows:
IANA は、「TLS エクスポーター ラベル」レジストリを更新して、値「EXPORTER: ティープ セッション キー シード」の参照フィールドを次のように変更しました。
+==================+=========+=============+===========+
| Value | DTLS-OK | Recommended | Reference |
+==================+=========+=============+===========+
| EXPORTER: teap | N | Y | RFC 9930 |
| session key seed | | | |
+------------------+---------+-------------+-----------+
Table 5
IANA has updated the "User Specific Root Keys (USRK) Key Labels" registry to change the Reference field for Value "TEAPbindkey@ietf.org" as follows:
IANA は、「User Specific Root Keys (USRK) Key Labels」レジストリを更新し、値「TEAPbindkey@ietf.org」の参照フィールドを次のように変更しました。
+======================+==========================+===========+
| Label | Description | Reference |
+======================+==========================+===========+
| TEAPbindkey@ietf.org | TEAP binding usage label | RFC 9930 |
+----------------------+--------------------------+-----------+
Table 6
IANA has updated the "Method Types" registry to change the Reference field for Value "55" as follows:
IANA は、「メソッド タイプ」レジストリを更新して、値「55」の参照フィールドを次のように変更しました。
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 55 | TEAP | RFC 9930 |
+-------+-------------+-----------+
Table 7
TEAP is designed with a focus on wireless media, where the medium itself is inherent to eavesdropping. Whereas in wired media an attacker would have to gain physical access to the wired medium, wireless media enables anyone to capture information as it is transmitted over the air, enabling passive attacks. Thus, physical security can not be assumed, and security vulnerabilities are far greater. The threat model used for the security evaluation of TEAP is defined in EAP [RFC3748].
TEAP は、無線メディアに焦点を当てて設計されており、無線メディア自体には盗聴の危険性がつきものです。有線メディアでは、攻撃者は有線メディアに物理的にアクセスする必要がありますが、無線メディアでは、無線で送信される情報を誰でも取得できるため、受動的攻撃が可能になります。したがって、物理的なセキュリティを想定することはできず、セキュリティの脆弱性ははるかに大きくなります。TEAP のセキュリティ評価に使用される脅威モデルは EAP [RFC3748] で定義されています。
As a whole, TEAP provides message and integrity protection by establishing a secure tunnel for protecting the inner method(s). The confidentiality and integrity protection is defined by TLS and provides the same security strengths afforded by TLS employing a strong entropy shared master secret. The integrity of the key generating Inner Methods executed within the TEAP tunnel is verified through the calculation of the Crypto-Binding TLV. This ensures that the tunnel endpoints are the same as the inner method endpoints.
全体として、TEAP は内部メソッドを保護するための安全なトンネルを確立することにより、メッセージと整合性の保護を提供します。機密性と整合性の保護は TLS によって定義され、強力なエントロピー共有マスター シークレットを使用する TLS によって提供されるのと同じセキュリティ強度を提供します。TEAP トンネル内で実行されるキー生成内部メソッドの整合性は、Crypto-Binding TLV の計算を通じて検証されます。これにより、トンネルのエンドポイントが内部メソッドのエンドポイントと同じになることが保証されます。
Where server unauthenticated provisioning is performed, TEAP requires that the inner provisioning method provide for both peer and server authentication.
サーバー非認証プロビジョニングが実行される場合、TEAP では、内部プロビジョニング方式がピア認証とサーバー認証の両方を提供する必要があります。
As is true for any negotiated EAP, EAP NAK messages used to suggest an alternate EAP authentication method are sent unprotected and, as such, are subject to spoofing. During unprotected EAP method negotiation, NAK packets may be interjected as active attacks to bid-down to a weaker form of authentication, such as EAP-MD5 (which only provides one-way authentication and does not derive a key). Both the peer and server should have a method selection policy that prevents them from negotiating down to weaker methods. Inner method negotiation resists attacks because it is protected by the mutually authenticated TLS tunnel established. Selection of TEAP as an authentication method does not limit the potential inner methods, so TEAP should be selected when available.
ネゴシエートされた EAP の場合と同様、代替 EAP 認証方法を提案するために使用される EAP NAK メッセージは保護されずに送信されるため、スプーフィングの対象となります。保護されていない EAP 方式のネゴシエーション中に、NAK パケットがアクティブな攻撃として挿入され、EAP-MD5 (一方向認証のみを提供し、キーを導出しない) などの弱い認証形式に入札される可能性があります。ピアとサーバーの両方に、より弱いメソッドへのネゴシエーションを防ぐメソッド選択ポリシーが必要です。内部メソッド ネゴシエーションは、確立された相互認証された TLS トンネルによって保護されるため、攻撃に耐性があります。認証方法として TEAP を選択しても、潜在的な内部メソッドは制限されないため、利用可能な場合は TEAP を選択する必要があります。
An attacker cannot readily determine the Inner Method used, except perhaps by traffic analysis. It is also important that peer implementations limit the use of credentials with an unauthenticated or unauthorized server.
攻撃者は、おそらくトラフィック分析による場合を除いて、使用されている内部メソッドを容易に判断することはできません。ピア実装が、未認証または無許可のサーバーでの資格情報の使用を制限することも重要です。
Separation of the TEAP Phase 1 from the Phase 2 conversation is NOT RECOMMENDED. Allowing the Phase 1 conversation to be terminated at a different server than the Phase 2 conversation can introduce vulnerabilities if there is not a proper trust relationship and protection for the protocol between the two servers. Some vulnerabilities include:
TEAP フェーズ 1 をフェーズ 2 の会話から分離することは推奨されません。フェーズ 1 の会話をフェーズ 2 の会話とは異なるサーバーで終了できるようにすると、2 つのサーバー間に適切な信頼関係とプロトコルの保護が存在しない場合、脆弱性が発生する可能性があります。一部の脆弱性には次のようなものがあります。
* Loss of identity protection
* ID 保護の喪失
* Offline dictionary attacks
* オフライン辞書攻撃
* Lack of policy enforcement
* ポリシーの施行の欠如
* On-path active attacks (as described in [RFC7029])
* パス上のアクティブ攻撃 ([RFC7029] に記載)
There may be cases where a trust relationship exists between the Phase 1 and Phase 2 servers, such as on a campus or between two offices within the same company, where there is no danger in revealing the inner identity and credentials of the peer to entities between the two servers. In these cases, using a proxy solution without end-to-end protection of TEAP MAY be used. The TEAP encrypting/decrypting gateway MUST, at a minimum, provide support for IPsec, TLS, or similar protection in order to provide confidentiality for the portion of the conversation between the gateway and the EAP server. In addition, separation of the TEAP servers and Inner servers allows for crypto-binding based on the Inner Method MSK to be thwarted as described in [RFC7029]. If the Inner Method derives an EMSK, then this threat is mitigated as TEAP uses the Crypto-Binding TLV to tie the inner EMSK to the TLS session via the TLS-PRF, as described above in Section 6.
キャンパス内や同じ会社内の 2 つのオフィス間など、フェーズ 1 サーバーとフェーズ 2 サーバーの間に信頼関係が存在する場合があり、その場合、2 つのサーバー間のピアツーエンティティの内部 ID や資格情報が漏洩する危険はありません。このような場合、TEAP のエンドツーエンド保護のないプロキシ ソリューションを使用してもよい(MAY)。TEAP 暗号化/復号化ゲートウェイは、ゲートウェイと EAP サーバー間の会話部分の機密性を確保するために、少なくとも IPsec、TLS、または同様の保護のサポートを提供しなければなりません (MUST)。さらに、TEAP サーバーと内部サーバーを分離することで、[RFC7029] で説明されているように、内部メソッド MSK に基づく暗号バインディングを阻止できます。内部メソッドが EMSK を導出する場合、セクション 6 で説明したように、TEAP が暗号バインディング TLV を使用して TLS-PRF 経由で内部 EMSK を TLS セッションに結び付けるため、この脅威は軽減されます。
On the other hand, if the Inner Method is not deriving EMSK, as with password authentication or unauthenticated provisioning, then this threat still exists. Implementations therefore need to limit the use of Inner Methods as discussed above in Section 3.6.5
一方、パスワード認証や未認証プロビジョニングのように、内部メソッドが EMSK を導出していない場合、この脅威は依然として存在します。したがって、実装では、セクション 3.6.5 で説明したように、内部メソッドの使用を制限する必要があります。
TEAP addresses the known deficiencies and weaknesses in some EAP authentication methods. By employing a shared secret between the peer and server to establish a secured tunnel, TEAP enables:
TEAP は、一部の EAP 認証方法の既知の欠陥と弱点に対処します。TEAP では、ピアとサーバーの間で共有秘密を使用して安全なトンネルを確立することで、次のことが可能になります。
* Per-packet confidentiality and integrity protection
* パケットごとの機密性と完全性の保護
* User identity protection
* ユーザーIDの保護
* Better support for notification messages
* 通知メッセージのサポートの向上
* Protected Inner Method negotiation, including EAP methods
* 保護された内部メソッドのネゴシエーション (EAP メソッドを含む)
* Sequencing of Inner Methods, including EAP methods
* EAP メソッドを含む内部メソッドのシーケンス
* Strong mutually derived MSKs
* 強力な相互派生 MSK
* Acknowledged success/failure indication
* 承認済みの成功/失敗の表示
* Faster re-authentications through session resumption
* セッション再開による再認証の高速化
* Mitigation of offline dictionary attacks
* オフライン辞書攻撃の軽減
* Mitigation of on-path attacks
* 経路上攻撃の軽減
* Mitigation of some denial-of-service attacks
* 一部のサービス拒否攻撃の軽減
It should be noted that in TEAP, as in many other authentication protocols, a denial-of-service attack can be mounted by adversaries sending erroneous traffic to disrupt the protocol. This is a problem in many authentication or key agreement protocols and is therefore noted for TEAP as well.
TEAP では、他の多くの認証プロトコルと同様に、敵対者が誤ったトラフィックを送信してプロトコルを妨害することによってサービス拒否攻撃を仕掛けられる可能性があることに注意してください。これは多くの認証プロトコルや鍵共有プロトコルで問題となるため、TEAP でも同様に注目されています。
TEAP was designed with a focus on protected Inner Methods that typically rely on weak credentials, such as password-based secrets. To that extent, the TEAP authentication mitigates several vulnerabilities, such as offline dictionary attacks, by protecting the weak credential-based Inner Method. The protection is based on strong cryptographic algorithms in TLS to provide message confidentiality and integrity. The keys derived for the protection relies on strong random challenges provided by both peer and server as well as an established key with strong entropy. Implementations should follow the recommendation in [RFC4086] when generating random numbers.
TEAP は、通常、パスワード ベースのシークレットなどの弱い資格情報に依存する、保護された内部メソッドに焦点を当てて設計されました。その点で、TEAP 認証は、弱い資格情報ベースの内部メソッドを保護することで、オフライン辞書攻撃などのいくつかの脆弱性を軽減します。この保護は、TLS の強力な暗号化アルゴリズムに基づいており、メッセージの機密性と整合性が提供されます。保護のために導出されるキーは、ピアとサーバーの両方によって提供される強力なランダム チャレンジと、強力なエントロピーを持つ確立されたキーに依存します。乱数を生成する場合、実装は [RFC4086] の推奨事項に従う必要があります。
The initial identity request response exchange is sent in cleartext outside the protection of TEAP. Typically, the NAI [RFC7542] in the identity response is useful only for the realm of information that is used to route the authentication requests to the right EAP server. This means that the identity response may contain an anonymous identity and just contain realm information. In other cases, the identity exchange may be eliminated altogether if there are other means for establishing the destination realm of the request. In no case should an intermediary place any trust in the identity information in the identity response since it is unauthenticated and may not have any relevance to the authenticated identity. TEAP implementations should not attempt to compare any identity disclosed in the initial cleartext EAP Identity response packet with those Identities authenticated in Phase 2.
最初の ID 要求応答の交換は、TEAP の保護の外で平文で送信されます。通常、ID 応答内の NAI [RFC7542] は、認証要求を適切な EAP サーバーにルーティングするために使用される情報の領域でのみ役立ちます。これは、アイデンティティ応答には匿名のアイデンティティが含まれ、レルム情報のみが含まれる可能性があることを意味します。リクエストの宛先レルムを確立するための他の手段がある場合には、アイデンティティ交換が完全に削除される場合もあります。ID 応答内の ID 情報は認証されておらず、認証された ID と関連性がない可能性があるため、いかなる場合でも仲介者はその ID 情報を信頼してはなりません。TEAP 実装は、最初の平文 EAP ID 応答パケットで開示された ID を、フェーズ 2 で認証された ID と比較しようとしてはなりません。
When the server is authenticated, identity request/response exchanges sent after the TEAP tunnel is established are protected from modification and eavesdropping by attackers. For server unauthenticated provisioning, the outer TLS session provides little security, and the provisioning method must provide this protection instead.
サーバーが認証されると、TEAP トンネルの確立後に送信される ID 要求/応答の交換は、攻撃者による変更や盗聴から保護されます。サーバーの非認証プロビジョニングの場合、外部 TLS セッションはほとんどセキュリティを提供しないため、代わりにプロビジョニング メソッドがこの保護を提供する必要があります。
When a client certificate is sent outside of the TLS tunnel in Phase 1, the peer MUST include Identity-Type as an Outer TLV in order to signal the type of identity which that client certificate is for. Further, when a client certificate is sent outside of the TLS tunnel, the server MUST proceed with Phase 2. If there is no Phase 2 data, then the EAP server MUST reject the session.
フェーズ 1 でクライアント証明書が TLS トンネルの外部に送信される場合、ピアは、そのクライアント証明書が対象とする ID のタイプを通知するために、Identity-Type をアウター TLV として含めなければなりません (MUST)。さらに、クライアント証明書が TLS トンネルの外に送信される場合、サーバーはフェーズ 2 に進む必要があります。フェーズ 2 データがない場合、EAP サーバーはセッションを拒否しなければなりません。
Issues related to confidentiality of a client certificate are discussed above in Section 3.4.1
クライアント証明書の機密性に関連する問題については、上記のセクション 3.4.1 で説明しています。
Note that the Phase 2 data could simply be a Result TLV with value Success, along with a Crypto-Binding TLV. This Phase 2 data serves as a protected success indication as discussed in [RFC9190], Section 2.1.1
フェーズ 2 データは、単純に値が Success の結果 TLV と暗号バインディング TLV である可能性があることに注意してください。このフェーズ 2 データは、[RFC9190] セクション 2.1.1 で説明されているように、保護された成功の指標として機能します。
TEAP was designed with a focus on protected Inner Methods that typically rely on weak credentials, such as password-based secrets. TEAP mitigates offline dictionary attacks by allowing the establishment of a mutually authenticated encrypted TLS tunnel providing confidentiality and integrity to protect the weak credential-based Inner Method.
TEAP は、通常、パスワード ベースのシークレットなどの弱い資格情報に依存する、保護された内部メソッドに焦点を当てて設計されました。TEAP は、相互認証された暗号化 TLS トンネルの確立を許可することでオフライン辞書攻撃を軽減し、脆弱な資格情報ベースの内部メソッドを保護するための機密性と整合性を提供します。
TEAP mitigates dictionary attacks by permitting Inner Methods, such as EAP-pwd, that are not vulnerable to dictionary attacks.
TEAP は、辞書攻撃に対して脆弱ではない EAP-pwd などの内部メソッドを許可することで、辞書攻撃を軽減します。
TEAP implementations can mitigate online "brute force" dictionary attempts by limiting the number of failed authentication attempts for a particular identity.
TEAP 実装では、特定の ID に対する認証試行の失敗回数を制限することで、オンラインの「ブルート フォース」辞書の試行を軽減できます。
TEAP provides protection from on-path attacks in a few ways:
TEAP は、次のいくつかの方法でパス上の攻撃から保護します。
1. By using a certificates or a session ticket to mutually authenticate the peer and server during TEAP authentication Phase 1 establishment of a secure TLS tunnel.
1. 証明書またはセッション チケットを使用して、TEAP 認証フェーズ 1 の安全な TLS トンネルの確立中にピアとサーバーを相互認証します。
2. When the TLS tunnel is not secured, by using the keys generated by the Inner Method (if the Inner Methods are key generating) in the crypto-binding exchange and in the generation of the key material exported by the Inner Method described in Section 6.
2. TLS トンネルがセキュリティで保護されていない場合、暗号バインディング交換およびセクション 6 で説明されている内部メソッドによってエクスポートされる鍵マテリアルの生成で、内部メソッドによって生成された鍵 (内部メソッドが鍵生成の場合) を使用します。
TEAP crypto-binding does not guarantee protection from on-path attacks if the client allows a connection to an untrusted server, such as in the case where the client does not properly validate the server's certificate. If the TLS cipher suite derives the master secret solely from the contribution of secret data from one side of the conversation (such as cipher suites based on RSA key transport), then an attacker who can convince the client to connect and engage in authentication can impersonate the client to another server even if a strong Inner Method is executed within the tunnel. If the TLS cipher suite derives the master secret from the contribution of secrets from both sides of the conversation (such as in cipher suites based on Diffie-Hellman), then crypto-binding can detect an attacker in the conversation if a strong Inner Method is used.
クライアントがサーバーの証明書を適切に検証しない場合など、クライアントが信頼できないサーバーへの接続を許可する場合、TEAP 暗号バインディングはパス上の攻撃からの保護を保証しません。TLS 暗号スイートが、会話の一方の側からの秘密データの提供のみからマスター シークレットを導出する場合 (RSA キー トランスポートに基づく暗号スイートなど)、クライアントに接続して認証を実行させることができる攻撃者は、たとえ強力な内部メソッドがトンネル内で実行されていたとしても、クライアントを別のサーバーに偽装することができます。TLS 暗号スイートが会話の両側からのシークレットの貢献からマスター シークレットを導出する場合 (Diffie-Hellman に基づく暗号スイートなど)、強力な内部メソッドが使用されていれば、暗号バインディングによって会話内の攻撃者を検出できます。
TEAP crypto-binding does not guarantee protection from on-path attacks when the client does not verify the server, and the Inner Method does not produce an EMSK. The only way to close this vulnerability is to define TEAPv2, which would then have different crypto-binding derivations.
クライアントがサーバーを検証せず、インナー メソッドが EMSK を生成しない場合、TEAP 暗号化バインディングはパス上の攻撃からの保護を保証しません。この脆弱性を解決する唯一の方法は、TEAPv2 を定義することです。TEAPv2 には、異なる暗号バインディングの派生が含まれます。
EAP Success and EAP Failure packets are, in general, sent in cleartext and may be forged by an attacker without detection. Forged EAP Failure packets can be used to attempt to convince an EAP peer to disconnect. Forged EAP Success packets may be used to attempt to convince a peer that authentication has succeeded, even though the authenticator has not authenticated itself to the peer.
EAP 成功パケットと EAP 失敗パケットは通常、平文で送信され、攻撃者によって検出されずに偽造される可能性があります。偽造 EAP 失敗パケットは、EAP ピアに切断を説得するために使用できます。偽の EAP 成功パケットは、オーセンティケータがピアに対して自身を認証していない場合でも、認証が成功したことをピアに納得させようとするために使用される場合があります。
By providing message confidentiality and integrity, TEAP provides protection against these attacks. Once the peer and authentication server (AS) initiate the TEAP authentication Phase 2, compliant TEAP implementations MUST silently discard all cleartext EAP messages, unless both the TEAP peer and server have indicated success or failure using a protected mechanism. Protected mechanisms include the TLS alert mechanism and the protected termination mechanism described in Section 3.6.6.
TEAP は、メッセージの機密性と整合性を提供することで、これらの攻撃に対する保護を提供します。ピアと認証サーバー (AS) が TEAP 認証フェーズ 2 を開始すると、TEAP ピアとサーバーの両方が保護されたメカニズムを使用して成功または失敗を示した場合を除き、準拠した TEAP 実装はすべての平文 EAP メッセージをサイレントに破棄しなければなりません (MUST)。保護されたメカニズムには、セクション 3.6.6 で説明されている TLS アラート メカニズムと保護された終了メカニズムが含まれます。
The success/failure decisions within the TEAP tunnel indicate the final decision of the TEAP authentication conversation. After a success/failure result has been indicated by a protected mechanism, the TEAP peer can process unprotected EAP Success and EAP Failure messages; however, the peer MUST ignore any unprotected EAP Success or Failure messages where the result does not match the result of the protected mechanism.
TEAP トンネル内の成功/失敗の決定は、TEAP 認証会話の最終決定を示します。保護されたメカニズムによって成功/失敗の結果が示された後、TEAP ピアは保護されていない EAP 成功メッセージと EAP 失敗メッセージを処理できます。ただし、ピアは、結果が保護されたメカニズムの結果と一致しない、保護されていない EAP 成功または失敗メッセージを無視しなければなりません (MUST)。
To abide by [RFC3748], the server sends a cleartext EAP Success or EAP Failure packet to terminate the EAP conversation. However, since EAP Success and EAP Failure packets are not retransmitted, the final packet may be lost. While a TEAP-protected EAP Success or EAP Failure packet should not be a final packet in a TEAP conversation, it may occur based on the conditions stated above, so an EAP peer should not rely upon the unprotected EAP Success and Failure messages.
[RFC3748] に従うために、サーバーは平文の EAP 成功または EAP 失敗パケットを送信して、EAP 会話を終了します。ただし、EAP Success パケットと EAP Failure パケットは再送されないため、最終パケットが失われる可能性があります。TEAP で保護された EAP 成功または EAP 失敗パケットは TEAP 会話の最後のパケットであってはなりませんが、上記の条件に基づいて発生する可能性があるため、EAP ピアは保護されていない EAP 成功および失敗メッセージに依存すべきではありません。
TEAP can carry cleartext passwords in the Basic-Password-Auth-Resp TLV. Implementations should take care to protect this data. For example, passwords should not normally be logged, and password data should be securely scrubbed from memory when it is no longer needed.
TEAP は、Basic-Password-Auth-Resp TLV でクリアテキスト パスワードを伝送できます。実装では、このデータの保護に注意する必要があります。たとえば、通常はパスワードをログに記録すべきではなく、パスワード データが不要になった場合はメモリから安全に消去する必要があります。
Due to the complexity of TEAP, and the long time between [RFC7170] and any substantial implementation, there are many accidental or unintended behaviors in the protocol.
TEAP の複雑さ、および [RFC7170] から実質的な実装までに長い時間がかかるため、プロトコルには多くの偶発的または意図しない動作が存在します。
The first one is that EAP-FAST-MSCHAPv2 is used instead of EAP-MSCHAPv2. While [RFC7170] defined TEAP to use EAP-MSCHAPv2, an early implementor or implementors instead used EAP-FAST-MSCHAPv2. The choice for this document was either to define a new version of TEAP that used EAP-MSCHAPv2 or instead to document implemented behavior. The choice taken here was to document running code.
1 つ目は、EAP-MSCHAPv2 の代わりに EAP-FAST-MSCHAPv2 が使用されることです。[RFC7170] は EAP-MSCHAPv2 を使用するように TEAP を定義しましたが、初期の実装者は代わりに EAP-FAST-MSCHAPv2 を使用しました。このドキュメントの選択は、EAP-MSCHAPv2 を使用する新しいバージョンの TEAP を定義するか、代わりに実装された動作を文書化するかのどちらかでした。ここで選択されたのは、実行中のコードを文書化することでした。
The issues discussed in Section 6.2.5 could have security impacts, but no analysis has been performed. The choice of using a special "all zero" IMSK in Section 6.2 was made for simplicity but could also have negative security impacts.
セクション 6.2.5 で説明されている問題はセキュリティに影響を与える可能性がありますが、分析は行われていません。セクション 6.2 で特別な「オールゼロ」IMSK を使用するという選択は、簡素化のために行われましたが、セキュリティに悪影響を与える可能性もあります。
The definition of the Crypto-Binding TLV means that the final Crypto-Binding TLV values might not depend on all previous values of MSK and EMSK. This limitation could have negative security impacts, but again, no analysis has been performed.
Crypto-Binding TLV の定義は、最終的な Crypto-Binding TLV 値が MSK および EMSK の以前のすべての値に依存しない可能性があることを意味します。この制限はセキュリティに悪影響を与える可能性がありますが、やはり分析は行われていません。
We suggest that the TEAP be revised to TEAP version 2, which could address these issues. There are proposals at this time to better derive the various keying materials and cryptographic binding derivations. However, in the interest of documenting running code, we are publishing this document with the acknowledgment that there are improvements to be made.
これらの問題に対処できるように、TEAP を TEAP バージョン 2 に改訂することをお勧めします。現時点では、さまざまなキーイングマテリアルと暗号バインディングの導出をより適切に導出する提案があります。ただし、実行中のコードを文書化するという観点から、改善の余地があることを認識してこのドキュメントを公開します。
Certain authentication protocols that use a challenge/response mechanism rely on challenge material that is not generated by the authentication server; therefore, the material may require special handling. For EAP-TTLS, these challenges are defined in [RFC5281], Section 11.1.
チャレンジ/レスポンス メカニズムを使用する特定の認証プロトコルは、認証サーバーによって生成されないチャレンジ マテリアルに依存します。したがって、材料には特別な取り扱いが必要な場合があります。EAP-TTLS の場合、これらの課題は [RFC5281] のセクション 11.1 で定義されています。
In EAP-MSCHAPv2, the authenticator issues a challenge to the supplicant. Then, the supplicant hashes the challenge with the password and forwards the response to the authenticator. The response also includes a Peer-Challenge, which is created by the supplicant. Since the challenge is random, it is not associated with the TLS tunnel and the protocol may be susceptible to a replay attack.
EAP-MSCHAPv2 では、オーセンティケータはサプリカントにチャレンジを発行します。次に、サプリカントはパスワードを使用してチャレンジをハッシュし、応答を認証者に転送します。応答には、サプリカントによって作成されたピアチャレンジも含まれます。チャレンジはランダムであるため、TLS トンネルに関連付けられておらず、プロトコルはリプレイ攻撃の影響を受けやすい可能性があります。
The Crypto-Binding TLV provides protection against intermediaries, but it does not provide protection against a replay attack. We suggest that any TEAPv2 specification correct this issue.
Crypto-Binding TLV は仲介者に対する保護を提供しますが、リプレイ攻撃に対する保護は提供しません。TEAPv2 仕様でこの問題を修正することをお勧めします。
This section provides the needed security claim requirement for EAP [RFC3748].
このセクションでは、EAP [RFC3748] に必要なセキュリティ要求要件を提供します。
Auth. mechanism:
認証。機構：
Certificate-based, shared-secret-based, and various tunneled authentication mechanisms.
証明書ベース、共有秘密ベース、およびさまざまなトンネル認証メカニズム。
Cipher Suite negotiation:
暗号スイートのネゴシエーション:
Yes
はい
Mutual authentication:
相互認証:
Yes
はい
Integrity protection:
完全性保護:
Yes. Any method executed within the TEAP tunnel is integrity protected. The cleartext EAP headers outside the tunnel are not integrity protected. Server unauthenticated provisioning provides its own protection mechanisms.
はい。TEAP トンネル内で実行されるメソッドはすべて整合性が保護されます。トンネル外部の平文 EAP ヘッダーは整合性が保護されていません。サーバー非認証プロビジョニングは、独自の保護メカニズムを提供します。
Replay protection:
リプレイ保護:
Yes
はい
Confidentiality:
機密保持:
Yes
はい
Key derivation:
キーの導出:
Yes
はい
Key strength:
主な強み:
See Note 1 below.
以下の注 1 を参照してください。
Dictionary attack prot.:
辞書攻撃防御:
See Note 2 below.
以下の注 2 を参照してください。
Fast reconnect:
高速再接続:
Yes
はい
Cryptographic binding:
暗号バインディング:
Yes
はい
Session independence:
セッションの独立性:
Yes
はい
Fragmentation:
断片化:
Yes
はい
Key Hierarchy:
主要な階層:
Yes
はい
Channel binding:
チャネルバインディング:
Yes
はい
Notes:
注:
* Note 1. [BCP86] offers advice on appropriate key sizes. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [NIST-SP-800-57]. [RFC3766], Section 6 advises use of the following required RSA or Diffie-Hellman (DH) module and Digital Signature Algorithm (DSA) subgroup size in bits for a given level of attack resistance in bits. Based on the table below, a 2048-bit RSA key is required to provide 112-bit equivalent key strength:
* 注 1. [BCP86] は、適切な鍵サイズに関するアドバイスを提供します。米国国立標準技術研究所 (NIST) も、[NIST-SP-800-57] で適切な鍵サイズに関するアドバイスを提供しています。[RFC3766] のセクション 6 は、ビット単位で指定されたレベルの攻撃耐性を得るために、次の必須の RSA または Diffie-Hellman (DH) モジュールとデジタル署名アルゴリズム (DSA) サブグループ サイズ (ビット単位) を使用することを推奨しています。以下の表に基づくと、112 ビットと同等の鍵強度を提供するには、2048 ビット RSA 鍵が必要です。
+==========================+===================+==============+
| Attack Resistance (bits) | RSA or DH Modulus | DSA subgroup |
| | size (bits) | size (bits) |
+==========================+===================+==============+
| 70 | 947 | 129 |
+--------------------------+-------------------+--------------+
| 80 | 1228 | 148 |
+--------------------------+-------------------+--------------+
| 90 | 1553 | 167 |
+--------------------------+-------------------+--------------+
| 100 | 1926 | 186 |
+--------------------------+-------------------+--------------+
| 150 | 4575 | 284 |
+--------------------------+-------------------+--------------+
| 200 | 8719 | 383 |
+--------------------------+-------------------+--------------+
| 250 | 14596 | 482 |
+--------------------------+-------------------+--------------+
Table 8
* Note 2. TEAP protects against offline dictionary attacks when secure Inner Methods are used. TEAP protects against online dictionary attacks by limiting the number of failed authentications for a particular identity.
* 注 2. 安全な内部メソッドが使用されている場合、TEAP はオフライン辞書攻撃から保護します。TEAP は、特定の ID に対する認証失敗の数を制限することにより、オンライン辞書攻撃から保護します。
[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>.
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985,
DOI 10.17487/RFC2985, November 2000,
<https://www.rfc-editor.org/info/rfc2985>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
[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>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[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>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation of Root Keys from an
Extended Master Session Key (EMSK)", RFC 5295,
DOI 10.17487/RFC5295, August 2008,
<https://www.rfc-editor.org/info/rfc5295>.
[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>.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
<https://www.rfc-editor.org/info/rfc5746>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<https://www.rfc-editor.org/info/rfc5929>.
[RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-
Binding Support for Extensible Authentication Protocol
(EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012,
<https://www.rfc-editor.org/info/rfc6677>.
[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>.
[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>.
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
[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>.
[RFC9427] DeKok, A., "TLS-Based Extensible Authentication Protocol
(EAP) Types for Use with TLS 1.3", RFC 9427,
DOI 10.17487/RFC9427, June 2023,
<https://www.rfc-editor.org/info/rfc9427>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[RFC9908] Richardson, M., Ed., Friel, O., von Oheimb, D., and D.
Harkins, "Clarification and Enhancement of the CSR
Attributes Definition in RFC 7030", RFC 9908,
DOI 10.17487/RFC9908, January 2026,
<https://www.rfc-editor.org/info/rfc9908>.
[BCP26] Best Current Practice 26,
<https://www.rfc-editor.org/info/bcp26>.
At the time of writing, this BCP comprises the following:
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>.
[BCP86] Best Current Practice 86,
<https://www.rfc-editor.org/info/bcp86>.
At the time of writing, this BCP comprises the following:
Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, April 2004,
<https://www.rfc-editor.org/info/rfc3766>.
[IEEE.802-1X.2020]
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, February
2020, <https://doi.org/10.1109/IEEESTD.2020.9018454>.
[KAMATH] Kamath, V. and A. Palekar, "Microsoft EAP CHAP
Extensions", Work in Progress, Internet-Draft, draft-
kamath-pppext-eap-mschapv2-02, 19 June 2007,
<https://datatracker.ietf.org/doc/html/draft-kamath-
pppext-eap-mschapv2-02>.
[MSCHAP] Microsoft Corporation, "Master Session Key (MSK)
Derivation", 23 April 2024, <https://learn.microsoft.com/
en-us/openspecs/windows_protocols/ms-chap/5a860bf5-2aeb-
485b-82ee-fac1e8e6b76f>.
[NIST-SP-800-57]
Barker, E., "Recommendation for Key Management: Part 1 -
General", NIST SP 800-57 Part 1 Rev. 5,
DOI 10.6028/NIST.SP.800-57pt1r5, May 2020,
<https://doi.org/10.6028/NIST.SP.800-57pt1r5>.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP)", 24 June 2021,
<https://learn.microsoft.com/en-
us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4-
beec-fb367325c0f9>.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
<https://www.rfc-editor.org/info/rfc2315>.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579,
DOI 10.17487/RFC3579, September 2003,
<https://www.rfc-editor.org/info/rfc3579>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, DOI 10.17487/RFC4017, March
2005, <https://www.rfc-editor.org/info/rfc4017>.
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
Extensible Authentication Protocol (EAP) Application",
RFC 4072, DOI 10.17487/RFC4072, August 2005,
<https://www.rfc-editor.org/info/rfc4072>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and
Attributes Supporting Authentication in Point-to-Point
Protocol (PPP) and Wireless Local Area Networks (WLAN)",
RFC 4334, DOI 10.17487/RFC4334, February 2006,
<https://www.rfc-editor.org/info/rfc4334>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[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>.
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945,
DOI 10.17487/RFC4945, August 2007,
<https://www.rfc-editor.org/info/rfc4945>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, DOI 10.17487/RFC4962, July 2007,
<https://www.rfc-editor.org/info/rfc4962>.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, DOI 10.17487/RFC5247, August 2008,
<https://www.rfc-editor.org/info/rfc5247>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<https://www.rfc-editor.org/info/rfc5272>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[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>.
[RFC5421] Cam-Winget, N. and H. Zhou, "Basic Password Exchange
within the Flexible Authentication via Secure Tunneling
Extensible Authentication Protocol (EAP-FAST)", RFC 5421,
DOI 10.17487/RFC5421, March 2009,
<https://www.rfc-editor.org/info/rfc5421>.
[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>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[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>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6124] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An
EAP Authentication Method Based on the Encrypted Key
Exchange (EKE) Protocol", RFC 6124, DOI 10.17487/RFC6124,
February 2011, <https://www.rfc-editor.org/info/rfc6124>.
[RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP:
Time-Based One-Time Password Algorithm", RFC 6238,
DOI 10.17487/RFC6238, May 2011,
<https://www.rfc-editor.org/info/rfc6238>.
[RFC6678] Hoeper, K., Hanna, S., Zhou, H., and J. Salowey, Ed.,
"Requirements for a Tunnel-Based Extensible Authentication
Protocol (EAP) Method", RFC 6678, DOI 10.17487/RFC6678,
July 2012, <https://www.rfc-editor.org/info/rfc6678>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<https://www.rfc-editor.org/info/rfc6961>.
[RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible
Authentication Protocol (EAP) Mutual Cryptographic
Binding", RFC 7029, DOI 10.17487/RFC7029, October 2013,
<https://www.rfc-editor.org/info/rfc7029>.
[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>.
[RFC7299] Housley, R., "Object Identifier Registry for the PKIX
Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014,
<https://www.rfc-editor.org/info/rfc7299>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.
[RFC8146] Harkins, D., "Adding Support for Salted Password Databases
to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017,
<https://www.rfc-editor.org/info/rfc8146>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[X.690] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", February 2021,
<https://www.itu.int/rec/T-REC-X.690>.
This section evaluates all tunnel-based EAP method requirements described in [RFC6678] against TEAP version 1.
このセクションでは、[RFC6678] に記載されているすべてのトンネルベースの EAP メソッド要件を TEAP バージョン 1 に対して評価します。
TEAPv1 meets this requirement by being compliant with [RFC3748], [RFC4017], [RFC5247], and [RFC4962]. It is also compliant with the "cryptographic algorithm agility" requirement by leveraging TLS 1.2 for all cryptographic algorithm negotiation.
TEAPv1 は、[RFC3748]、[RFC4017]、[RFC5247]、および [RFC4962] に準拠することでこの要件を満たします。また、すべての暗号アルゴリズムのネゴシエーションに TLS 1.2 を活用することで、「暗号アルゴリズムの俊敏性」要件にも準拠しています。
TEAPv1 meets this requirement by mandating TLS version 1.2 support as defined in Section 3.2.
TEAPv1 は、セクション 3.2 で定義されているように TLS バージョン 1.2 のサポートを義務付けることで、この要件を満たしています。
TEAPv1 meets this requirement by using TLS to provide protected cipher suite negotiation.
TEAPv1 は、TLS を使用して保護された暗号スイートのネゴシエーションを提供することで、この要件を満たしています。
TEAPv1 meets this requirement by mandating cipher suites as defined in Section 3.2.
TEAPv1 は、セクション 3.2 で定義されている暗号スイートを義務付けることで、この要件を満たしています。
TEAPv1 meets this requirement by mandating cipher suites that only include cipher suites that use strong cryptographic algorithms. They do not include cipher suites providing mutually anonymous authentication or static Diffie-Hellman cipher suites as defined in Section 3.2.
TEAPv1 は、強力な暗号アルゴリズムを使用する暗号スイートのみを含む暗号スイートを義務付けることで、この要件を満たしています。これらには、相互匿名認証を提供する暗号スイートや、セクション 3.2 で定義されている静的な Diffie-Hellman 暗号スイートは含まれません。
TEAPv1 meets this requirement by using TLS to provide sufficient replay protection.
TEAPv1 は、TLS を使用して十分なリプレイ保護を提供することで、この要件を満たしています。
TEAPv1 meets this requirement by allowing TLS extensions, such as TLS Certificate Status Request extension [RFC6066] and SessionTicket extension [RFC5077], to be used during TLS tunnel establishment.
TEAPv1 は、TLS 証明書ステータス要求拡張 [RFC6066] やセッションチケット拡張 [RFC5077] などの TLS 拡張を TLS トンネルの確立中に使用できるようにすることで、この要件を満たします。
TEAPv1 meets this requirement by establishment of the TLS tunnel and protection identities specific to the Inner Method. In addition, the peer certificate can be sent confidentially (i.e., encrypted).
TEAPv1 は、TLS トンネルと内部方式に固有の保護 ID を確立することにより、この要件を満たします。さらに、ピア証明書は秘密裏に (つまり暗号化して) 送信できます。
TEAPv1 meets this requirement by mandating support of TLS session resumption as defined in Section 3.5.1 and TLS session resumption using the methods defined in [RFC9190].
TEAPv1 は、セクション 3.5.1 で定義されている TLS セッション再開のサポートと、[RFC9190] で定義されている方法を使用した TLS セッション再開のサポートを義務付けることで、この要件を満たしています。
TEAPv1 meets this requirement by leveraging fragmentation support provided by TLS as defined in Section 3.10.
TEAPv1 は、セクション 3.10 で定義されているように、TLS によって提供される断片化サポートを活用することで、この要件を満たします。
TEAPv1 meets this requirement by including the TEAP version number received in the computation of the Crypto-Binding TLV as defined in Section 4.2.13.
TEAPv1 は、セクション 4.2.13 で定義されているように、暗号バインディング TLV の計算に受信した TEAP バージョン番号を含めることによって、この要件を満たします。
TEAPv1 meets this requirement by using an extensible TLV data layer inside the tunnel as defined in Section 4.2.
TEAPv1 は、セクション 4.2 で定義されているように、トンネル内で拡張可能な TLV データ層を使用することでこの要件を満たします。
TEAPv1 meets this requirement by allowing multiple TLVs to be sent in a single EAP request or response packet, while maintaining the half-duplex operation typical of EAP.
TEAPv1 は、EAP の典型的な半二重動作を維持しながら、複数の TLV を単一の EAP 要求または応答パケットで送信できるようにすることで、この要件を満たしています。
TEAPv1 meets this requirement by having a mandatory bit in each TLV to indicate whether it is mandatory to support or not as defined in Section 4.2.
TEAPv1 は、セクション 4.2 で定義されているように、サポートが必須かどうかを示す必須ビットを各 TLV に持つことで、この要件を満たしています。
TEAPv1 meets this requirement by having a Vendor-Specific TLV to allow vendors to define their own attributes as defined in Section 4.2.8.
TEAPv1 は、セクション 4.2.8 で定義されているようにベンダーが独自の属性を定義できるようにするベンダー固有の TLV を備えていることで、この要件を満たしています。
TEAPv1 meets this requirement by having a Result TLV to exchange the final result of the TEAP authentication so both the peer and server have a synchronized state as defined in Section 4.2.4.
TEAPv1 は、TEAP 認証の最終結果を交換するための Result TLV を持つことでこの要件を満たします。これにより、ピアとサーバーの両方がセクション 4.2.4 で定義されている同期状態になります。
TEAPv1 meets this requirement by supporting UTF-8 format in the Basic-Password-Auth-Req TLV as defined in Section 4.2.14 and the Basic-Password-Auth-Resp TLV as defined in Section 4.2.15.
TEAPv1 は、セクション 4.2.14 で定義されている Basic-Password-Auth-Req TLV およびセクション 4.2.15 で定義されている Basic-Password-Auth-Resp TLV で UTF-8 形式をサポートすることで、この要件を満たしています。
TEAPv1 meets this requirement by having a Channel-Binding TLV to exchange the EAP channel-binding data as defined in Section 4.2.7.
TEAPv1 は、セクション 4.2.7 で定義されているように、チャネル バインディング TLV を使用して EAP チャネル バインディング データを交換することで、この要件を満たします。
TEAPv1 meets this requirement by running the password authentication inside a protected TLS tunnel.
TEAPv1 は、保護された TLS トンネル内でパスワード認証を実行することでこの要件を満たします。
TEAPv1 meets this requirement by mandating authentication of the server before establishment of the protected TLS and then running inner password authentication as defined in Section 3.2.
TEAPv1 は、保護された TLS の確立前にサーバーの認証を義務付け、その後、セクション 3.2 で定義されている内部パスワード認証を実行することで、この要件を満たしています。
TEAPv1 meets this requirement by supporting TLS Certificate Status Request extension [RFC6066] during tunnel establishment.
TEAPv1 は、トンネル確立中に TLS Certificate Status Request 拡張 [RFC6066] をサポートすることで、この要件を満たします。
TEAPv1 meets this requirement by supporting UTF-8 format in Basic-Password-Auth-Req TLV as defined in Section 4.2.14 and Basic-Password-Auth-Resp TLV as defined in Section 4.2.15.
TEAPv1 は、セクション 4.2.14 で定義されている Basic-Password-Auth-Req TLV およびセクション 4.2.15 で定義されている Basic-Password-Auth-Resp TLV で UTF-8 形式をサポートすることで、この要件を満たしています。
TEAPv1 meets this requirement by supporting Identity-Type TLV as defined in Section 4.2.3 to indicate whether the authentication is for a user or a machine.
TEAPv1 は、認証がユーザーに対するものであるかマシンに対するものであるかを示すセクション 4.2.3 で定義されている Identity-Type TLV をサポートすることで、この要件を満たしています。
TEAPv1 meets this requirement by supporting multiple Basic-Password-Auth-Req TLV and Basic-Password-Auth-Resp TLV exchanges within a single EAP authentication, which allows "housekeeping"" functions such as password change.
TEAPv1 は、単一の EAP 認証内で複数の Basic-Password-Auth-Req TLV および Basic-Password-Auth-Resp TLV 交換をサポートすることでこの要件を満たします。これにより、パスワード変更などの「ハウスキーピング」機能が可能になります。
TEAPv1 meets this requirement by supporting inner EAP method negotiation within the protected TLS tunnel.
TEAPv1 は、保護された TLS トンネル内で内部 EAP メソッドのネゴシエーションをサポートすることで、この要件を満たします。
TEAPv1 meets this requirement by supporting inner EAP method chaining within protected TLS tunnels as defined in Section 3.6.2.
TEAPv1 は、セクション 3.6.2 で定義されているように、保護された TLS トンネル内で内部 EAP メソッド チェーンをサポートすることで、この要件を満たしています。
TEAPv1 meets this requirement by supporting cryptographic binding of the inner EAP method keys with the keys derived from the TLS tunnel as defined in Section 4.2.13.
TEAPv1 は、セクション 4.2.13 で定義されているように、内部 EAP メソッド キーと TLS トンネルから派生したキーとの暗号化バインディングをサポートすることで、この要件を満たします。
TEAPv1 meets this requirement by supporting the Request-Action TLV as defined in Section 4.2.9 to allow a peer to initiate another inner EAP method.
TEAPv1 は、セクション 4.2.9 で定義されているリクエストアクション TLV をサポートし、ピアが別の内部 EAP メソッドを開始できるようにすることで、この要件を満たしています。
TEAPv1 meets this requirement by supporting the Identity-Type TLV as defined in Section 4.2.3 to indicate whether the authentication is for a user or a machine.
TEAPv1 は、セクション 4.2.3 で定義されているように、認証がユーザーに対するものであるかマシンに対するものであるかを示す Identity-Type TLV をサポートすることで、この要件を満たしています。
This document is a new standard tunnel EAP method based on revision of EAP-FAST version 1 [RFC4851] that contains improved flexibility, particularly for negotiation of cryptographic algorithms. The major changes are:
この文書は、EAP-FAST バージョン 1 [RFC4851] のリビジョンに基づく新しい標準トンネル EAP 方式であり、特に暗号アルゴリズムのネゴシエーションに関して柔軟性が向上しています。主な変更点は次のとおりです。
1. The EAP method name has been changed from EAP-FAST to TEAP; this change thus requires that a new EAP Type be assigned.
1. EAP メソッド名が EAP-FAST から TEAP に変更されました。したがって、この変更では、新しい EAP タイプを割り当てる必要があります。
2. This version of TEAP MUST support TLS 1.2 [RFC5246]. TLS 1.1 and earlier MUST NOT be used with TEAP.
2. このバージョンの TEAP は TLS 1.2 [RFC5246] をサポートしなければなりません。TLS 1.1 以前は TEAP と一緒に使用してはなりません。
3. The key derivation now makes use of TLS keying material exporters [RFC5705] and the PRF and hash function negotiated in TLS. This is to simplify implementation and better support cryptographic algorithm agility.
3. 鍵の導出では、TLS 鍵マテリアル エクスポーター [RFC5705] と、TLS でネゴシエートされた PRF およびハッシュ関数が使用されるようになりました。これは、実装を簡素化し、暗号化アルゴリズムの俊敏性をより適切にサポートするためです。
4. TEAP is in full conformance with the SessionTicket extension [RFC5077].
4. TEAP は、SessionTicket 拡張 [RFC5077] に完全に準拠しています。
5. Support is provided for passing optional Outer TLVs in the first two message exchanges, in addition to the Authority-ID TLV data in EAP-FAST.
5. EAP-FAST の Authority-ID TLV データに加えて、最初の 2 つのメッセージ交換でオプションのアウター TLV を渡すためのサポートが提供されます。
6. Basic password authentication on the TLV level has been added in addition to the existing inner EAP method.
6. 既存の内部 EAP 方式に加えて、TLV レベルの基本パスワード認証が追加されました。
7. Additional TLV types have been defined to support EAP channel binding and metadata. They are the Identity-Type TLV and Channel-Binding TLVs, defined in Section 4.2.
7. EAP チャネル バインディングとメタデータをサポートするために、追加の TLV タイプが定義されています。これらは、セクション 4.2 で定義されている ID タイプ TLV とチャネル バインディング TLV です。
The following exchanges show a successful TEAP authentication with basic password authentication. The conversation will appear as follows:
次のやり取りは、基本パスワード認証による TEAP 認証の成功を示しています。会話は次のように表示されます。
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
TLS channel established
(messages sent within the TLS channel)
<- Basic-Password-Auth-Req TLV, Challenge
Basic-Password-Auth-Resp TLV, Response with both
username and password) ->
optional additional exchanges (new pin mode,
password change, etc.) ...
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Crypto-Binding TLV(Response),
Result TLV (Success) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
The following exchanges show a failed TEAP authentication due to wrong user credentials. The conversation will appear as follows:
次のやり取りは、間違ったユーザー資格情報が原因で TEAP 認証が失敗したことを示しています。会話は次のように表示されます。
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
TLS channel established
(messages sent within the TLS channel)
<- Basic-Password-Auth-Req TLV, Challenge
Basic-Password-Auth-Resp TLV, Response with both
username and password) ->
<- Intermediate-Result TLV (Failure),
Result TLV (Failure)
Intermediate-Result TLV (Failure),
Result TLV (Failure) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Failure
In the case within TEAP Phase 1 where an abbreviated TLS handshake is tried, fails, and falls back to the certificate-based full TLS handshake, the conversation will appear as follows:
TEAP フェーズ 1 内で短縮 TLS ハンドシェイクが試行され、失敗し、証明書ベースの完全な TLS ハンドシェイクにフォールバックする場合、会話は次のようになります。
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route
the authentication request to EAP server, instead of the
full user identity.
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello with
SessionTicket extension)->
// If the server rejects the session resumption,
it falls through to the full TLS handshake.
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
EAP-Payload TLV[EAP-Request/
Identity])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel.
EAP-Payload TLV
[EAP-Response/Identity (MyID2)]->
// identity protected by TLS.
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
// Method X exchanges followed by Protected Termination
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Crypto-Binding TLV (Response),
Result TLV (Success) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
In the case where a certificate-based TLS handshake occurs within TEAP Phase 1 and client certificate authentication and identity privacy is desired (and therefore TLS renegotiation is being used to transmit the peer credentials in the protected TLS tunnel), the conversation will appear as follows for TLS 1.2:
証明書ベースの TLS ハンドシェイクが TEAP フェーズ 1 内で発生し、クライアント証明書の認証とアイデンティティ プライバシーが必要な場合 (したがって、保護された TLS トンネルでピア資格情報を送信するために TLS 再ネゴシエーションが使用されている場合)、会話は TLS 1.2 では次のようになります。
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route
the authentication request to EAP server, instead of the
full user identity.
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_key_exchange,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
EAP-Payload TLV[EAP-Request/
Identity])
// TLS channel established
(EAP Payload messages sent within the TLS channel)
// peer sends TLS client_hello to request TLS renegotiation
TLS client_hello ->
<- TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done
[TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished ->
<- TLS change_cipher_spec,
TLS finished,
Crypto-Binding TLV (Request),
Result TLV (Success)
Crypto-Binding TLV (Response),
Result TLV (Success)) ->
//TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
In the case where TEAP fragmentation is required, the conversation will appear as follows:
TEAP フラグメンテーションが必要な場合、会話は次のようになります。
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
(Fragment 1: L, M bits set)
EAP-Response/
EAP-Type=TEAP, V=1 ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(Fragment 2: M bit set)
EAP-Response/
EAP-Type=TEAP, V=1 ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(Fragment 3)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished)
(Fragment 1: L, M bits set)->
<- EAP-Request/
EAP-Type=TEAP, V=1
EAP-Response/
EAP-Type=TEAP, V=1
(Fragment 2)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
[EAP-Payload TLV[
EAP-Request/Identity]])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel.
EAP-Payload TLV
[EAP-Response/Identity (MyID2)]->
// identity protected by TLS.
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
// Method X exchanges followed by Protected Termination
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Crypto-Binding TLV (Response),
Result TLV (Success) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
When TEAP is negotiated with a sequence of EAP method X followed by method Y, the conversation will occur as follows:
TEAP が EAP メソッド X に続いてメソッド Y のシーケンスでネゴシエートされると、会話は次のように行われます。
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
Identity-Type TLV,
EAP-Payload TLV[
EAP-Request/Identity])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel
Identity_Type TLV
EAP-Payload TLV
[EAP-Response/Identity] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
// Optional additional X Method exchanges...
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X]->
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Request),
Identity-Type TLV,
EAP-Payload TLV[
EAP-Request/Identity])
// Compound MAC calculated using keys generated from
EAP method X and the TLS tunnel.
// Next EAP conversation started (with EAP-Request/Identity)
after successful completion of previous method X. The
Intermediate-Result and Crypto-Binding TLVs are sent in
the next packet to minimize round trips.
Intermediate Result TLV (Success),
Crypto-Binding TLV (Response),
EAP-Payload TLV [EAP-Response/Identity (MyID2)] ->
// Optional additional EAP method Y exchanges...
<- EAP Payload TLV [
EAP-Type=Y]
EAP Payload TLV
[EAP-Type=Y] ->
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Crypto-Binding TLV (Response),
Result TLV (Success) ->
// Compound MAC calculated using keys generated from EAP
methods X and Y and the TLS tunnel. Compound keys are
generated using keys generated from EAP methods X and Y
and the TLS tunnel.
// TLS channel torn down (messages sent in cleartext)
<- EAP-Success
The following exchanges show a failed crypto-binding validation. The conversation will appear as follows:
次の交換は、暗号化バインディングの検証が失敗したことを示しています。会話は次のように表示されます。
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS Client Key Exchange
TLS change_cipher_spec,
TLS finished)
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec
TLS finished)
EAP-Payload TLV[
EAP-Request/Identity])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel.
EAP-Payload TLV/
EAP Identity Response ->
<- EAP Payload TLV, EAP-Request,
(EAP-FAST-MSCHAPV2, Challenge)
EAP Payload TLV, EAP-Response,
(EAP-FAST-MSCHAPV2, Response) ->
<- EAP Payload TLV, EAP-Request,
(EAP-FAST-MSCHAPV2, Success Request)
EAP Payload TLV, EAP-Response,
(EAP-FAST-MSCHAPV2, Success Response) ->
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Result TLV (Failure)
Error TLV with
(Error Code = 2001) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-Failure
When TEAP is negotiated with a sequence of EAP methods followed by a Vendor-Specific TLV exchange, the conversation will occur as follows:
TEAP が一連の EAP メソッドとその後にベンダー固有の TLV 交換を使用してネゴシエートされると、会話は次のように行われます。
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
EAP-Payload TLV[
EAP-Request/Identity])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel.
EAP-Payload TLV
[EAP-Response/Identity] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X]->
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Request),
Vendor-Specific TLV,
// Vendor-Specific TLV exchange started after successful
completion of previous method X. The Intermediate-Result
and Crypto-Binding TLVs are sent with Vendor-Specific TLV
in next packet to minimize round trips.
// Compound MAC calculated using keys generated from
EAP method X and the TLS tunnel.
Intermediate Result TLV (Success),
Crypto-Binding TLV (Response),
Vendor-Specific TLV ->
// Optional additional Vendor-Specific TLV exchanges...
<- Vendor-Specific TLV
Vendor-Specific TLV ->
<- Result TLV (Success)
Result TLV (Success) ->
// TLS channel torn down (messages sent in cleartext)
<- EAP-Success
In the case where the peer is authenticated during Phase 1 and the server sends back a Result TLV but the peer wants to request another Inner Method, the conversation will appear as follows:
フェーズ 1 でピアが認証され、サーバーが結果 TLV を送り返すが、ピアが別の内部メソッドを要求する場合、会話は次のようになります。
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route
the authentication request to EAP server, instead of the
full user identity. TLS client certificate is also sent.
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
[TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
Crypto-Binding TLV (Request),
Result TLV (Success))
// TLS channel established
(TLV Payload messages sent within the TLS channel)
Crypto-Binding TLV(Response),
Request-Action TLV
(Status=Failure, Action=Negotiate-EAP)->
<- EAP-Payload TLV
[EAP-Request/Identity]
EAP-Payload TLV
[EAP-Response/Identity] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X]->
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate Result TLV (Success),
Crypto-Binding TLV (Response),
Result TLV (Success)) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
The following exchanges show a successful TEAP authentication with basic password authentication and channel binding using a Request-Action TLV. The conversation will appear as follows:
次の交換は、基本的なパスワード認証とリクエスト/アクション TLV を使用したチャネル バインディングによる TEAP 認証の成功を示しています。会話は次のように表示されます。
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
TLS channel established
(messages sent within the TLS channel)
<- Basic-Password-Auth-Req TLV, Challenge
Basic-Password-Auth-Resp TLV, Response with both
username and password) ->
optional additional exchanges (new pin mode,
password change, etc.) ...
<- Crypto-Binding TLV (Request),
Result TLV (Success),
Crypto-Binding TLV(Response),
Request-Action TLV
(Status=Failure, Action=Process TLV,
TLV=Channel-Binding TLV)->
<- Channel-Binding TLV (Response),
Result TLV (Success),
Result TLV (Success) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
The following exchanges show the peer sending a PKCS#10 TLV and server replying with a PKCS7 TLV. The exchange below assumes that the EAP peer is authenticated in Phase 1, either via bidirectional certificate exchange or some other TLS method such as a proof of knowledge (TLS-POK). The conversation will appear as follows:
次の交換は、ピアが PKCS#10 TLV を送信し、サーバーが PKCS7 TLV で応答することを示しています。以下の交換では、EAP ピアがフェーズ 1 で、双方向の証明書交換または知識証明 (TLS-POK) などの他の TLS 方式のいずれかを介して認証されることを前提としています。会話は次のように表示されます。
,----. ,-------.
|Peer| |AuthSrv|
`-+--' `---+---'
| EAP-Request / Identity |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response / Identity (MYID1) |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| EAP-Request/EAP-Type=TEAP, |
| V=1(TEAP Start, |
| S bit set, |
| Authority-ID) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, |
| V=1(TLS client_hello) |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| EAP-Request/ EAP-Type=TEAP, |
| V=1(TLS server_hello, |
| TLS certificate, |
| TLS certificate_request, |
| TLS finished) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, |
| V=1(TLS change_cipher_spec, |
| TLS certificate, |
| TLS finished) TLS channel established |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| Send Request-Action TLV |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| Send PKCS10 TLV |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| Sign the CSR and send PKCS7 TLV Intermediate-Result|
| TLV request(Success), |
| Crypto-Binding TLV(Request), |
| Result TLV(Success) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| Intermediate-Result TLV response(Success), |
| Crypto-Binding TLV(Response), |
| Result TLV(Success) |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| EAP Success |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
The following exchanges show a failure scenario. The conversation will appear as follows:
次のやりとりは、失敗のシナリオを示しています。会話は次のように表示されます。
,----. ,-------.
|Peer| |AuthSrv|
`-+--' `---+---'
| EAP-Request / Identity |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response / Identity (MYID1) |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP-Request/EAP-Type=TEAP, V=1 |
| (TEAP Start, S bit set, Authority-ID) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, V=1(TLS client_hello) |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP-Request/ EAP-Type=TEAP, V=1 |
| (TLS server_hello,(TLS change_cipher_spec, TLS finished)|
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, V=1 |
| (TLS change_cipher_spec, |
| TLS finished) |
| TLS channel established |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| Request-Action TLV |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| Bad PKCS10 TLV |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| Intermediate-Result TLV request(Failure), |
| Result TLV(Failure) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| Intermediate-Result TLV response(Failure), |
| Result TLV(Failure) |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP Failure |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
The following exchanges show a scenario where the client certificate is sent in Phase 1 and no additional authentication or provisioning is performed in Phase 2. The conversation will appear as follows:
次のやり取りは、クライアント証明書がフェーズ 1 で送信され、フェーズ 2 では追加の認証やプロビジョニングが実行されないシナリオを示しています。会話は次のようになります。
,----. ,-------.
|Peer| |AuthSrv|
`-+--' `---+---'
| EAP-Request / Identity |
| <- - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response / Identity (MYID1) |
| - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP-Request/EAP-Type=TEAP, |
| V=1(TEAP Start, |
| S bit set, |
| Authority-ID) |
| <- - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, |
| V=1(TLS client_hello) |
| - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP-Request/ EAP-Type=TEAP, |
| V=1(TLS server_hello, |
| TLS certificate, |
| TLS certificate_request, |
| TLS change_cipher_spec, |
| TLS finished) |
| <- - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, |
| V=1(TLS certificate, |
| TLS change_cipher_spec, |
| TLS finished) TLS channel established |
| - - - - - - - - - - - - - - - - - - - - ->
| |
| Crypto-Binding TLV(Request), |
| Result TLV(Success) |
| <- - - - - - - - - - - - - - - - - - - - -
| |
| Crypto-Binding TLV(Response), |
| Result TLV(Success) |
| - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP Success |
| <- - - - - - - - - - - - - - - - - - - - -
Alan DeKok was added as an editor.
アラン・デコックが編集者として追加されました。
The document was converted to Markdown from the [RFC7170] text output.
ドキュメントは [RFC7170] テキスト出力から Markdown に変換されました。
Any formatting changes from [RFC7170] may have resulted from changing from XML to Markdown as the source file when editing the draft.
[RFC7170] によるフォーマットの変更は、ドラフト編集時にソース ファイルとして XML から Markdown に変更された結果である可能性があります。
The IANA Considerations section was replaced with a note to change the IANA registry references to this document.
「IANA の考慮事項」セクションは、このドキュメントへの IANA レジストリの参照を変更するための注記に置き換えられました。
A new section was added to explain that the inner EAP-MSCHAPv2 derivation follows EAP-FAST. This is the largest technical change from the previous revision of this document and follows existing implementations.
内部 EAP-MSCHAPv2 派生が EAP-FAST に従うことを説明する新しいセクションが追加されました。これは、このドキュメントの前の改訂版からの最大の技術的変更であり、既存の実装を踏襲しています。
Many small changes have been made throughout the document to correct inconsistencies and to address mistakes. At a high level:
不一致を修正し、間違いに対処するために、ドキュメント全体に多くの小さな変更が加えられています。高いレベルで:
* All open errata have been addressed.
* 未解決の正誤表はすべて解決されました。
* A new term "Inner Method" has been defined.
* 新しい用語「インナーメソッド」が定義されました。
* The definitions and derivation of IMSK, S-IMCK, etc. have been corrected and clarified.
* IMSK、S-IMCKなどの定義と導出が修正され、明確になりました。
* The diagrams in Appendix C have been updated to match the TEAP state machine.
* 付録 C の図は、TEAP ステート マシンに合わせて更新されました。
All uses of the PAC were removed. It had not been implemented, and there were no plans by implementors to use it.
PAC の使用はすべて削除されました。これはまだ実装されておらず、実装者による使用の計画もありませんでした。
Text was added on recommendations for inner and outer identities.
内部および外部のアイデンティティに関する推奨事項に関するテキストが追加されました。
Section 6.2.5 was added late in the document life cycle in order to document accidental behavior that could result in interoperability issues.
セクション 6.2.5 は、相互運用性の問題を引き起こす可能性のある偶発的な動作を文書化するために、ドキュメントのライフサイクルの後半に追加されました。
Nearly all of the text in this document was taken directly from [RFC7170]. We are grateful to the original authors and reviewers for that document. The acknowledgments given here are only for the changes that resulted in this document.
この文書のほぼすべてのテキストは [RFC7170] から直接取得したものです。この文書の原著者と査読者に感謝します。ここでの謝辞は、このドキュメントに生じた変更のみを対象としています。
Alexander Clouter provided substantial and detailed technical feedback on nearly every aspect of the specification. The corrections in this document are based on his work.
Alexander Clouter は、仕様のほぼすべての側面について、実質的かつ詳細な技術フィードバックを提供しました。この文書の修正は彼の著作に基づいています。
We wish to thank the many reviewers and commenters in the EMU WG, including Eliot Lear, Joe Salowey, Heikki Vatiainen, Bruno Pereria Vidal, and Michael Richardson. Many corner cases and edge conditions were caught and corrected as a result of their feedback.
Eliot Lear、Joe Salowey、Heikki Vatiainen、Bruno Pereria Vidal、Michael Richardson を含む、EMU WG の多くの査読者やコメント投稿者に感謝します。フィードバックの結果、多くのコーナーケースやエッジ状態が発見され、修正されました。
Jouni Malinin initially pointed out the issues with [RFC7170]. Those comments resulted in substantial discussion on the EMU WG mailing list, and eventually this document. Jouni also made substantial contributions in analyzing corner cases, which resulted in the text in Section 6.2.5.
Jouni Malinin は当初、[RFC7170] の問題を指摘しました。これらのコメントは、EMU WG メーリング リストでの実質的な議論につながり、最終的にはこの文書が作成されました。Jouni はまた、コーナーケースの分析でも多大な貢献をし、その結果がセクション 6.2.5 の文章につながりました。
Han Zhou
Joseph Salowey
Email: joe@salowey.net
Nancy Cam-Winget
Email: ncamwing@cisco.com
Steve Hanna
Email: steve.hanna@infineon.com
Alan DeKok (editor)
Email: alan.dekok@inkbridge.io