Network Working Group N. Cam-Winget
Request for Comments: 4851 D. McGrew
Category: Informational J. Salowey
H. Zhou
Cisco Systems
May 2007
Network Working Group N. Cam-Winget
Request for Comments: 4851 D. McGrew
Category: Informational J. Salowey
H. Zhou
Cisco Systems
May 2007
The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)
通过安全隧道的灵活认证可扩展认证协议方法（EAP-FAST）
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server.
本文档定义了基于可扩展身份验证协议（EAP）的通过安全隧道的灵活身份验证（EAP-FAST）协议。EAP-FAST是一种EAP方法，通过使用传输层安全性（TLS）建立相互认证的隧道，实现对等方和服务器之间的安全通信。在隧道内，类型长度值（TLV）对象用于在对等方和EAP服务器之间传输与身份验证相关的数据。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Specification Requirements . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Architectural Model . . . . . . . . . . . . . . . . . . . 6
2.2. Protocol Layering Model . . . . . . . . . . . . . . . . . 7
3. EAP-FAST Protocol . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Version Negotiation . . . . . . . . . . . . . . . . . . . 8
3.2. EAP-FAST Authentication Phase 1: Tunnel Establishment . . 9
3.2.1. TLS Session Resume Using Server State . . . . . . . . 10
3.2.2. TLS Session Resume Using a PAC . . . . . . . . . . . . 10
3.2.3. Transition between Abbreviated and Full TLS
Handshake . . . . . . . . . . . . . . . . . . . . . . 12
3.3. EAP-FAST Authentication Phase 2: Tunneled
Authentication . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1. EAP Sequences . . . . . . . . . . . . . . . . . . . . 13
3.3.2. Protected Termination and Acknowledged Result
Indication . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Determining Peer-Id and Server-Id . . . . . . . . . . . . 14
3.5. EAP-FAST Session Identifier . . . . . . . . . . . . . . . 15
3.6. Error Handling . . . . . . . . . . . . . . . . . . . . . . 15
3.6.1. TLS Layer Errors . . . . . . . . . . . . . . . . . . . 15
3.6.2. Phase 2 Errors . . . . . . . . . . . . . . . . . . . . 16
3.7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 16
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. EAP-FAST Message Format . . . . . . . . . . . . . . . . . 18
4.1.1. Authority ID Data . . . . . . . . . . . . . . . . . . 20
4.2. EAP-FAST TLV Format and Support . . . . . . . . . . . . . 20
4.2.1. General TLV Format . . . . . . . . . . . . . . . . . . 21
4.2.2. Result TLV . . . . . . . . . . . . . . . . . . . . . . 22
4.2.3. NAK TLV . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.4. Error TLV . . . . . . . . . . . . . . . . . . . . . . 24
4.2.5. Vendor-Specific TLV . . . . . . . . . . . . . . . . . 25
4.2.6. EAP-Payload TLV . . . . . . . . . . . . . . . . . . . 26
4.2.7. Intermediate-Result TLV . . . . . . . . . . . . . . . 28
4.2.8. Crypto-Binding TLV . . . . . . . . . . . . . . . . . . 29
4.2.9. Request-Action TLV . . . . . . . . . . . . . . . . . . 31
4.3. Table of TLVs . . . . . . . . . . . . . . . . . . . . . . 32
5. Cryptographic Calculations . . . . . . . . . . . . . . . . . . 32
5.1. EAP-FAST Authentication Phase 1: Key Derivations . . . . . 32
5.2. Intermediate Compound Key Derivations . . . . . . . . . . 33
5.3. Computing the Compound MAC . . . . . . . . . . . . . . . . 34
5.4. EAP Master Session Key Generation . . . . . . . . . . . . 35
5.5. T-PRF . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Specification Requirements . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Architectural Model . . . . . . . . . . . . . . . . . . . 6
2.2. Protocol Layering Model . . . . . . . . . . . . . . . . . 7
3. EAP-FAST Protocol . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Version Negotiation . . . . . . . . . . . . . . . . . . . 8
3.2. EAP-FAST Authentication Phase 1: Tunnel Establishment . . 9
3.2.1. TLS Session Resume Using Server State . . . . . . . . 10
3.2.2. TLS Session Resume Using a PAC . . . . . . . . . . . . 10
3.2.3. Transition between Abbreviated and Full TLS
Handshake . . . . . . . . . . . . . . . . . . . . . . 12
3.3. EAP-FAST Authentication Phase 2: Tunneled
Authentication . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1. EAP Sequences . . . . . . . . . . . . . . . . . . . . 13
3.3.2. Protected Termination and Acknowledged Result
Indication . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Determining Peer-Id and Server-Id . . . . . . . . . . . . 14
3.5. EAP-FAST Session Identifier . . . . . . . . . . . . . . . 15
3.6. Error Handling . . . . . . . . . . . . . . . . . . . . . . 15
3.6.1. TLS Layer Errors . . . . . . . . . . . . . . . . . . . 15
3.6.2. Phase 2 Errors . . . . . . . . . . . . . . . . . . . . 16
3.7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 16
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. EAP-FAST Message Format . . . . . . . . . . . . . . . . . 18
4.1.1. Authority ID Data . . . . . . . . . . . . . . . . . . 20
4.2. EAP-FAST TLV Format and Support . . . . . . . . . . . . . 20
4.2.1. General TLV Format . . . . . . . . . . . . . . . . . . 21
4.2.2. Result TLV . . . . . . . . . . . . . . . . . . . . . . 22
4.2.3. NAK TLV . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.4. Error TLV . . . . . . . . . . . . . . . . . . . . . . 24
4.2.5. Vendor-Specific TLV . . . . . . . . . . . . . . . . . 25
4.2.6. EAP-Payload TLV . . . . . . . . . . . . . . . . . . . 26
4.2.7. Intermediate-Result TLV . . . . . . . . . . . . . . . 28
4.2.8. Crypto-Binding TLV . . . . . . . . . . . . . . . . . . 29
4.2.9. Request-Action TLV . . . . . . . . . . . . . . . . . . 31
4.3. Table of TLVs . . . . . . . . . . . . . . . . . . . . . . 32
5. Cryptographic Calculations . . . . . . . . . . . . . . . . . . 32
5.1. EAP-FAST Authentication Phase 1: Key Derivations . . . . . 32
5.2. Intermediate Compound Key Derivations . . . . . . . . . . 33
5.3. Computing the Compound MAC . . . . . . . . . . . . . . . . 34
5.4. EAP Master Session Key Generation . . . . . . . . . . . . 35
5.5. T-PRF . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
7. Security Considerations . . . . . . . . . . . . . . . . . . . 37
7.1. Mutual Authentication and Integrity Protection . . . . . . 37
7.2. Method Negotiation . . . . . . . . . . . . . . . . . . . . 38
7.3. Separation of Phase 1 and Phase 2 Servers . . . . . . . . 38
7.4. Mitigation of Known Vulnerabilities and Protocol
Deficiencies . . . . . . . . . . . . . . . . . . . . . . . 39
7.4.1. User Identity Protection and Verification . . . . . . 39
7.4.2. Dictionary Attack Resistance . . . . . . . . . . . . . 40
7.4.3. Protection against Man-in-the-Middle Attacks . . . . . 40
7.4.4. PAC Binding to User Identity . . . . . . . . . . . . . 41
7.5. Protecting against Forged Clear Text EAP Packets . . . . . 41
7.6. Server Certificate Validation . . . . . . . . . . . . . . 42
7.7. Tunnel PAC Considerations . . . . . . . . . . . . . . . . 42
7.8. Security Claims . . . . . . . . . . . . . . . . . . . . . 43
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Normative References . . . . . . . . . . . . . . . . . . . 44
9.2. Informative References . . . . . . . . . . . . . . . . . . 45
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 46
A.1. Successful Authentication . . . . . . . . . . . . . . . . 46
A.2. Failed Authentication . . . . . . . . . . . . . . . . . . 47
A.3. Full TLS Handshake using Certificate-based Ciphersuite . . 48
A.4. Client Authentication during Phase 1 with Identity
Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.5. Fragmentation and Reassembly . . . . . . . . . . . . . . . 52
A.6. Sequence of EAP Methods . . . . . . . . . . . . . . . . . 53
A.7. Failed Crypto-Binding . . . . . . . . . . . . . . . . . . 56
A.8. Sequence of EAP Method with Vendor-Specific TLV
Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 57
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 60
B.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 60
B.2. Crypto-Binding MIC . . . . . . . . . . . . . . . . . . . . 62
7. Security Considerations . . . . . . . . . . . . . . . . . . . 37
7.1. Mutual Authentication and Integrity Protection . . . . . . 37
7.2. Method Negotiation . . . . . . . . . . . . . . . . . . . . 38
7.3. Separation of Phase 1 and Phase 2 Servers . . . . . . . . 38
7.4. Mitigation of Known Vulnerabilities and Protocol
Deficiencies . . . . . . . . . . . . . . . . . . . . . . . 39
7.4.1. User Identity Protection and Verification . . . . . . 39
7.4.2. Dictionary Attack Resistance . . . . . . . . . . . . . 40
7.4.3. Protection against Man-in-the-Middle Attacks . . . . . 40
7.4.4. PAC Binding to User Identity . . . . . . . . . . . . . 41
7.5. Protecting against Forged Clear Text EAP Packets . . . . . 41
7.6. Server Certificate Validation . . . . . . . . . . . . . . 42
7.7. Tunnel PAC Considerations . . . . . . . . . . . . . . . . 42
7.8. Security Claims . . . . . . . . . . . . . . . . . . . . . 43
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Normative References . . . . . . . . . . . . . . . . . . . 44
9.2. Informative References . . . . . . . . . . . . . . . . . . 45
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 46
A.1. Successful Authentication . . . . . . . . . . . . . . . . 46
A.2. Failed Authentication . . . . . . . . . . . . . . . . . . 47
A.3. Full TLS Handshake using Certificate-based Ciphersuite . . 48
A.4. Client Authentication during Phase 1 with Identity
Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.5. Fragmentation and Reassembly . . . . . . . . . . . . . . . 52
A.6. Sequence of EAP Methods . . . . . . . . . . . . . . . . . 53
A.7. Failed Crypto-Binding . . . . . . . . . . . . . . . . . . 56
A.8. Sequence of EAP Method with Vendor-Specific TLV
Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 57
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 60
B.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 60
B.2. Crypto-Binding MIC . . . . . . . . . . . . . . . . . . . . 62
Network access solutions requiring user friendly and easily deployable secure authentication mechanisms highlight the need for strong mutual authentication protocols that enable the use of weaker user credentials. This document defines an Extensible Authentication Protocol (EAP), which consists of establishing a Transport Layer Security (TLS) tunnel using TLS 1.0 [RFC2246], TLS 1.1 [RFC4346], or a successor version of TLS, using the latest version supported by both parties. Once the tunnel is established, the protocol further exchanges data in the form of type, length, and value objects (TLV) to perform further authentication. EAP-FAST supports the TLS extension defined in [RFC4507] to support fast re-establishment of the secure tunnel without having to maintain per-session state on the server. [EAP-PROV] defines EAP-FAST-based mechanisms to provision the credential for this extension which is called a Protected Access Credential (PAC).
需要用户友好且易于部署的安全身份验证机制的网络访问解决方案突出了对强相互身份验证协议的需求，该协议允许使用较弱的用户凭据。本文档定义了可扩展身份验证协议（EAP），该协议包括使用TLS 1.0[RFC2246]、TLS 1.1[RFC4346]或TLS的后续版本（使用双方支持的最新版本）建立传输层安全（TLS）隧道。一旦建立了隧道，协议将进一步交换类型、长度和值对象（TLV）形式的数据，以执行进一步的身份验证。EAP-FAST支持[RFC4507]中定义的TLS扩展，以支持安全隧道的快速重建，而无需在服务器上维护每个会话的状态。[EAP-PROV]定义了基于EAP FAST的机制，用于为此扩展提供凭据，该扩展称为受保护访问凭据（PAC）。
EAP-FAST's design motivations included:
EAP-FAST的设计动机包括：
o Mutual authentication: an EAP server must be able to verify the identity and authenticity of the peer, and the peer must be able to verify the authenticity of the EAP server.
o 相互认证：EAP服务器必须能够验证对等方的身份和真实性，并且对等方必须能够验证EAP服务器的真实性。
o Immunity to passive dictionary attacks: many authentication protocols require a password to be explicitly provided (either as cleartext or hashed) by the peer to the EAP server; at minimum, the communication of the weak credential (e.g., password) must be immune from eavesdropping.
o 对被动字典攻击的免疫力：许多身份验证协议要求对等方向EAP服务器显式提供密码（明文或哈希）；至少，弱凭证（如密码）的通信必须免受窃听。
o Immunity to man-in-the-middle (MitM) attacks: in establishing a mutually authenticated protected tunnel, the protocol must prevent adversaries from successfully interjecting information into the conversation between the peer and the EAP server.
o 对中间人（MitM）攻击的免疫力：在建立相互认证的受保护隧道时，协议必须防止对手成功地将信息插入对等方和EAP服务器之间的对话中。
o Flexibility to enable support for most password authentication interfaces: as many different password interfaces (e.g., Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), Lightweight Directory Access Protocol (LDAP), One-Time Password (OTP), etc.) exist to authenticate a peer, the protocol must provide this support seamlessly.
o 支持大多数密码身份验证接口的灵活性：由于存在许多不同的密码接口（例如Microsoft Challenge Handshake身份验证协议（MS-CHAP）、轻量级目录访问协议（LDAP）、一次性密码（OTP）等）来对对等方进行身份验证，因此该协议必须无缝地提供此支持。
o Efficiency: specifically when using wireless media, peers will be limited in computational and power resources. The protocol must enable the network access communication to be computationally lightweight.
o 效率：特别是在使用无线媒体时，对等方的计算和电源资源将受到限制。该协议必须使网络访问通信在计算上是轻量级的。
With these motivational goals defined, further secondary design criteria are imposed:
确定了这些激励目标后，将进一步实施二级设计标准：
o Flexibility to extend the communications inside the tunnel: with the growing complexity in network infrastructures, the need to gain authentication, authorization, and accounting is also evolving. For instance, there may be instances in which multiple existing authentication protocols are required to achieve mutual authentication. Similarly, different protected conversations may be required to achieve the proper authorization once a peer has successfully authenticated.
o 扩展隧道内通信的灵活性：随着网络基础设施的日益复杂，获得身份验证、授权和记帐的需求也在不断发展。例如，可能存在需要多个现有认证协议来实现相互认证的实例。类似地，一旦对等方成功进行身份验证，可能需要不同的受保护对话来实现适当的授权。
o Minimize the authentication server's per user authentication state requirements: with large deployments, it is typical to have many servers acting as the authentication servers for many peers. It is also highly desirable for a peer to use the same shared secret to secure a tunnel much the same way it uses the username and password to gain access to the network. The protocol must facilitate the use of a single strong shared secret by the peer while enabling the servers to minimize the per user and device state it must cache and manage.
o 最小化身份验证服务器的每用户身份验证状态要求：对于大型部署，通常会有多台服务器充当多个对等方的身份验证服务器。对等方也非常希望使用相同的共享秘密来保护隧道，就像它使用用户名和密码访问网络一样。该协议必须便于对等方使用单个强共享秘密，同时使服务器能够最小化其必须缓存和管理的每个用户和设备状态。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] .
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Much of the terminology in this document comes from [RFC3748]. Additional terms are defined below:
本文档中的许多术语来自[RFC3748]。其他术语定义如下：
Protected Access Credential (PAC)
受保护访问凭据（PAC）
Credentials distributed to a peer for future optimized network authentication. The PAC consists of, at most, three components: a shared secret, an opaque element, and optionally other information. The shared secret component contains the pre-shared key between the peer and the authentication server. The opaque part is provided to the peer and is presented to the authentication server when the peer wishes to obtain access to network resources. Finally, a PAC may optionally include other information that may be useful to the peer. The opaque part of the PAC is the same type of data as the ticket in [RFC4507] and the shared secret is used to derive the TLS master secret.
分发给对等方的凭据，用于将来优化的网络身份验证。PAC最多由三部分组成：共享秘密、不透明元素和可选的其他信息。共享密钥组件包含对等方和身份验证服务器之间的预共享密钥。不透明部分提供给对等方，并在对等方希望获得对网络资源的访问时呈现给认证服务器。最后，PAC可以选择性地包括对对等方可能有用的其他信息。PAC的不透明部分与[RFC4507]中的票据类型相同，共享机密用于派生TLS主机密。
EAP-FAST is an authentication protocol similar to EAP-TLS [RFC2716] that enables mutual authentication and cryptographic context establishment by using the TLS handshake protocol. EAP-FAST allows for the established TLS tunnel to be used for further authentication exchanges. EAP-FAST makes use of TLVs to carry out the inner authentication exchanges. The tunnel is then used to protect weaker inner authentication methods, which may be based on passwords, and to communicate the results of the authentication.
EAP-FAST是一种类似于EAP-TLS[RFC2716]的身份验证协议，通过使用TLS握手协议实现相互身份验证和加密上下文建立。EAP-FAST允许将已建立的TLS隧道用于进一步的身份验证交换。EAP-FAST利用TLV进行内部认证交换。然后，隧道用于保护较弱的内部身份验证方法（可能基于密码），并传达身份验证的结果。
EAP-FAST makes use of the TLS enhancements in [RFC4507] to enable an optimized TLS tunnel session resume while minimizing server state. The secret key used in EAP-FAST is referred to as the Protected Access Credential key (or PAC-Key); the PAC-Key is used to mutually authenticate the peer and the server when securing a tunnel. The ticket is referred to as the Protected Access Credential opaque data (or PAC-Opaque). The secret key and ticket used to establish the tunnel may be provisioned through mechanisms that do not involve the TLS handshake. It is RECOMMENDED that implementations support the capability to distribute the ticket and secret key within the EAP-FAST tunnel as specified in [EAP-PROV].
EAP-FAST利用[RFC4507]中的TLS增强功能来实现优化的TLS隧道会话恢复，同时最小化服务器状态。EAP-FAST中使用的密钥称为受保护的访问凭证密钥（或PAC密钥）；在保护隧道时，PAC密钥用于相互验证对等方和服务器。票据被称为受保护访问凭证不透明数据（或PAC不透明）。用于建立隧道的密钥和票据可以通过不涉及TLS握手的机制来提供。建议实施支持[EAP-PROV]中规定的在EAP-FAST隧道内分发票据和密钥的功能。
The EAP-FAST 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 EAP-FAST, both EAP peer and EAP server derive strong session key material that can then be communicated to the network access server (NAS) for use in establishing a link layer security association.
EAP-FAST会话用于建立或恢复现有会话，以通常在对等方和网络之间建立网络连接。在成功执行EAP-FAST后，EAP对等方和EAP服务器都派生出强会话密钥材料，然后可以将其传送到网络访问服务器（NAS）以用于建立链路层安全关联。
The network architectural model for EAP-FAST usage is shown below:
EAP-FAST使用的网络架构模型如下所示：
+----------+ +----------+ +----------+ +----------+
| | | | | | | Inner |
| Peer |<---->| Authen- |<---->| EAP-FAST |<---->| Method |
| | | ticator | | server | | server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
+----------+ +----------+ +----------+ +----------+
| | | | | | | Inner |
| Peer |<---->| Authen- |<---->| EAP-FAST |<---->| Method |
| | | ticator | | server | | server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
EAP-FAST Architectural Model
EAP-FAST体系结构模型
The entities depicted above are logical entities and may or may not correspond to separate network components. For example, the EAP-FAST server and inner method server might be a single entity; the authenticator and EAP-FAST server might be a single entity; or the functions of the authenticator, EAP-FAST server, and inner method
上面描述的实体是逻辑实体，可能对应于也可能不对应于单独的网络组件。例如，EAP-FAST服务器和内部方法服务器可能是单个实体；验证器和EAP-FAST服务器可能是单个实体；或者认证器、EAP-FAST服务器和内部方法的功能
server might be combined into a single physical device. For example, typical 802.11 deployments place the Authenticator in an access point (AP) while a Radius server may provide the EAP-FAST 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 Section 7.3 provides an additional discussion of the implications of separating the EAP-FAST server from the inner method server.
服务器可以合并到单个物理设备中。例如，典型的802.11部署将验证器放置在接入点（AP）中，而Radius服务器可能提供EAP-FAST和内部方法服务器组件。上图以一般方式说明了实体之间的分工，并显示了如何构建分布式系统；然而，实际系统的实现可能更简单。安全注意事项第7.3节进一步讨论了将EAP-FAST服务器与内部方法服务器分离的含义。
EAP-FAST packets are encapsulated within EAP; EAP in turn requires a carrier protocol for transport. EAP-FAST packets encapsulate TLS, which is then used to encapsulate user authentication information. Thus, EAP-FAST messaging can be described using a layered model, where each layer encapsulates the layer above it. The following diagram clarifies the relationship between protocols:
EAP-FAST包封装在EAP中；EAP反过来需要一个用于传输的载波协议。EAP-FAST数据包封装TLS，然后用于封装用户身份验证信息。因此，EAP-FAST消息传递可以使用分层模型来描述，其中每个层封装其上的层。下图阐明了协议之间的关系：
+---------------------------------------------------------------+
| Inner EAP Method | Other TLV information |
|---------------------------------------------------------------|
| TLV Encapsulation (TLVs) |
|---------------------------------------------------------------|
| TLS |
|---------------------------------------------------------------|
| EAP-FAST |
|---------------------------------------------------------------|
| EAP |
|---------------------------------------------------------------|
| Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.) |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| Inner EAP Method | Other TLV information |
|---------------------------------------------------------------|
| TLV Encapsulation (TLVs) |
|---------------------------------------------------------------|
| TLS |
|---------------------------------------------------------------|
| EAP-FAST |
|---------------------------------------------------------------|
| EAP |
|---------------------------------------------------------------|
| Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.) |
+---------------------------------------------------------------+
Protocol Layering Model
协议分层模型
The TLV layer is a payload with Type-Length-Value (TLV) Objects defined in Section 4.2. The TLV objects are used to carry arbitrary parameters between an EAP peer and an EAP server. All conversations in the EAP-FAST protected tunnel must be encapsulated in a TLV layer.
TLV层是具有第4.2节中定义的类型长度值（TLV）对象的有效载荷。TLV对象用于在EAP对等方和EAP服务器之间传输任意参数。EAP-FAST保护隧道中的所有对话必须封装在TLV层中。
Methods for encapsulating EAP within carrier protocols are already defined. For example, IEEE 802.1X [IEEE.802-1X.2004] 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-FAST server.
已经定义了在载波协议中封装EAP的方法。例如，IEEE 802.1X[IEEE.802-1X.2004]可用于在对等方和认证器之间传输EAP；RADIUS[RFC3579]或Diameter[RFC4072]可用于在验证器和EAP-FAST服务器之间传输EAP。
EAP-FAST authentication occurs in two phases. In the first phase, EAP-FAST employs the TLS 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. The operation of the protocol, including Phase 1 and Phase 2, are the topic of this section. The format of EAP-FAST messages is given in Section 4 and the cryptographic calculations are given in Section 5.
EAP-FAST认证分两个阶段进行。在第一阶段，EAP-FAST使用TLS握手来提供经过身份验证的密钥交换并建立受保护的隧道。一旦建立了隧道，第二阶段将开始，对等方和服务器将参与进一步的对话，以建立所需的身份验证和授权策略。协议的操作，包括阶段1和阶段2，是本节的主题。EAP-FAST消息的格式见第4节，加密计算见第5节。
EAP-FAST packets contain a 3-bit version field, following the TLS Flags field, which enables EAP-FAST implementations to be backward compatible with previous versions of the protocol. This specification documents the EAP-FAST version 1 protocol; implementations of this specification MUST use a version field set to 1.
EAP-FAST数据包在TLS标志字段之后包含一个3位版本字段，该字段使EAP-FAST实现与协议的早期版本向后兼容。本规范记录了EAP-FAST第1版协议；此规范的实现必须使用设置为1的版本字段。
Version negotiation proceeds as follows:
版本谈判进行如下：
In the first EAP-Request sent with EAP type=EAP-FAST, the EAP server must set the version field to the highest supported version number.
在使用EAP type=EAP-FAST发送的第一个EAP请求中，EAP服务器必须将版本字段设置为支持的最高版本号。
If the EAP peer supports this version of the protocol, it MUST respond with an EAP-Response of EAP type=EAP-FAST, and the version number proposed by the EAP-FAST server.
如果EAP对等方支持此版本的协议，则必须使用EAP type=EAP-FAST的EAP响应以及EAP-FAST服务器建议的版本号进行响应。
If the EAP-FAST peer does not support this version, it responds with an EAP-Response of EAP type=EAP-FAST and the highest supported version number.
如果EAP-FAST对等机不支持此版本，则它将以EAP type=EAP-FAST的EAP响应和支持的最高版本号进行响应。
If the EAP-FAST server does not support the version number proposed by the EAP-FAST peer, it terminates the conversation. Otherwise the EAP-FAST conversation continues.
如果EAP-FAST服务器不支持EAP-FAST对等方建议的版本号，则会终止对话。否则，EAP-FAST对话将继续。
The version negotiation procedure guarantees that the EAP-FAST peer and server will agree to the latest version supported by both parties. If version negotiation fails, then use of EAP-FAST will not be possible, and another mutually acceptable EAP method will need to be negotiated if authentication is to proceed.
版本协商过程保证EAP-FAST对等方和服务器同意双方支持的最新版本。如果版本协商失败，则不可能使用EAP-FAST，如果要继续进行身份验证，则需要协商另一种双方均可接受的EAP方法。
The EAP-FAST version is not protected by TLS; and hence can be modified in transit. In order to detect a modification of the EAP-FAST version, the peers MUST exchange the EAP-FAST version number
EAP-FAST版本不受TLS保护；因此可以在运输过程中进行修改。为了检测EAP-FAST版本的修改，对等方必须交换EAP-FAST版本号
received during version negotiation using the Crypto-Binding TLV described in Section 4.2.8. 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 EAP-FAST version negotiation.
使用第4.2.8节中描述的加密绑定TLV在版本协商期间接收。加密绑定TLV的接收方必须验证加密绑定TLV中接收的版本与EAP-FAST版本协商中接收方发送的版本匹配。
EAP-FAST is based on the TLS handshake [RFC2246] to establish an authenticated and protected tunnel. The TLS version offered by the peer and server MUST be TLS v1.0 or later. This version of the EAP-FAST implementation MUST support the following TLS ciphersuites:
EAP-FAST基于TLS握手[RFC2246]来建立经过身份验证和保护的隧道。对等方和服务器提供的TLS版本必须是TLS v1.0或更高版本。此版本的EAP-FAST实施必须支持以下TLS密码套件：
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_与_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA [RFC3268]
TLS_RSA_与_AES_128_CBC_SHA[RFC3268]
TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC3268]
TLS_DHE_RSA_与_AES_128_CBC_SHA[RFC3268]
Other ciphersuites MAY be supported. It is RECOMMENDED that anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only be used in the context of the provisioning described in [EAP-PROV]. Care must be taken to address potential man-in-the-middle attacks when ciphersuites that do not provide authenticated tunnel establishment are used. During the EAP-FAST Phase 1 conversation the EAP-FAST endpoints MAY negotiate TLS compression.
可能支持其他密码套件。建议仅在[EAP-PROV]中所述的设置上下文中使用匿名密码套件，如TLS_DH_anon_和_AES_128_CBC_SHA。在使用不提供经过验证的隧道建立的密码套件时，必须注意解决潜在的中间人攻击。在EAP-FAST第1阶段对话期间，EAP-FAST端点可以协商TLS压缩。
The EAP server initiates the EAP-FAST conversation with an EAP request containing an EAP-FAST/Start packet. This packet includes a set Start (S) bit, the EAP-FAST version as specified in Section 3.1, and an authority identity. The TLS payload in the initial packet is empty. The authority identity (A-ID) 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 EAP-FAST the conversation continues with the peer sending an EAP-Response packet with EAP type of EAP-FAST with the Start (S) bit clear and the version as specified in Section 3.1. This message encapsulates one or more TLS records containing the TLS handshake messages. If the EAP-FAST version negotiation is successful then the EAP-FAST 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 EAP-FAST Phase 2 MAY be sent along with server-finished handshake message to reduce the number of round trips.
EAP服务器使用包含EAP-FAST/Start数据包的EAP请求启动EAP-FAST对话。该数据包包括设置的起始位、第3.1节中规定的EAP-FAST版本和授权标识。初始数据包中的TLS有效负载为空。授权标识（A-ID）用于向对等方提供服务器标识的提示，这可能有助于对等方选择要使用的适当凭据。假设对等方支持EAP-FAST，则对话将继续，对等方发送EAP类型为EAP-FAST的EAP响应数据包，起始位清除，版本如第3.1节所述。此消息封装了一个或多个包含TLS握手消息的TLS记录。如果EAP-FAST版本协商成功，则EAP-FAST对话将继续，直到EAP服务器和EAP对等方准备好进入第2阶段。当执行完整TLS握手时，EAP-FAST阶段2的第一个有效载荷可与服务器完成握手消息一起发送，以减少往返次数。
After the TLS session is established, another EAP exchange MAY occur within the tunnel to authenticate the EAP peer. EAP-FAST implementations MUST support client authentication during tunnel
TLS会话建立后，隧道内可能会发生另一个EAP交换，以对EAP对等方进行身份验证。EAP-FAST实现必须支持隧道期间的客户端身份验证
establishment using the TLS ciphersuites specified in Section 3.2. EAP-FAST implementations SHOULD also support the immediate renegotiation of a TLS session to initiate a new handshake message exchange under the protection of the current ciphersuite. This allows support for protection of the peer's identity. Note that the EAP peer does not need to authenticate as part of the TLS exchange, but can alternatively be authenticated through additional EAP exchanges carried out in Phase 2.
使用第3.2节规定的TLS密码套件建立。EAP-FAST实现还应支持立即重新协商TLS会话，以在当前密码套件的保护下启动新的握手消息交换。这允许支持保护对等方的身份。注意，EAP对等方不需要作为TLS交换的一部分进行身份验证，但也可以通过在第2阶段执行的附加EAP交换进行身份验证。
The EAP-FAST tunnel protects peer identity information from disclosure outside the tunnel. Implementations that wish to provide identity privacy for the peer identity must carefully consider what information is disclosed outside the tunnel.
EAP-FAST隧道保护对等身份信息不在隧道外泄露。希望为对等体身份提供身份隐私的实现必须仔细考虑隧道外的信息。
The following sections describe resuming a TLS session based on server-side or client-side state.
以下各节描述基于服务器端或客户端状态恢复TLS会话。
EAP-FAST session resumption is achieved in the same manner TLS achieves session resume. To support session resumption, the server and peer must minimally cache the SessionID, master secret, and ciphersuite. The peer attempts to resume a session by including a valid SessionID from a previous handshake in its ClientHello message. If the server finds a match for the SessionID and is willing to establish a new connection using the specified session state, the server will respond with the same SessionID and proceed with the EAP-FAST Authentication Phase 1 tunnel establishment based on a TLS abbreviated handshake. After a successful conclusion of the EAP-FAST Authentication Phase 1 conversation, the conversation then continues on to Phase 2.
EAP-FAST会话恢复的实现方式与TLS实现会话恢复的方式相同。为了支持会话恢复，服务器和对等方必须最低限度地缓存SessionID、mastersecret和ciphersuite。对等方试图通过在其ClientHello消息中包含来自上一次握手的有效SessionID来恢复会话。如果服务器找到SessionID的匹配项并愿意使用指定的会话状态建立新连接，则服务器将使用相同的SessionID进行响应，并基于TLS简化握手继续EAP-FAST身份验证阶段1隧道建立。EAP-FAST身份验证阶段1对话成功结束后，对话继续进行到阶段2。
EAP-FAST supports the resumption of sessions based on client-side state using techniques described in [RFC4507]. This version of EAP-FAST does not support the provisioning of a ticket through the use of the SessionTicket handshake message. Instead it supports the provisioning of a ticket called a Protected Access Credential (PAC) as described in [EAP-PROV]. Implementations may provide additional ways to provision the PAC, such as manual configuration. Since the PAC mentioned here is used for establishing the TLS Tunnel, it is more specifically referred to as the Tunnel PAC. The Tunnel PAC is a security credential provided by the EAP server to a peer and comprised of:
EAP-FAST支持使用[RFC4507]中描述的技术基于客户端状态恢复会话。此版本的EAP-FAST不支持通过使用SessionTicket握手消息来设置票证。相反，它支持如[EAP-PROV]中所述的提供称为受保护访问凭证（PAC）的票证。实现可以提供额外的方式来提供PAC，例如手动配置。由于此处提到的PAC用于建立TLS隧道，因此更具体地称为隧道PAC。隧道PAC是EAP服务器向对等方提供的安全凭证，包括：
1. PAC-Key: this is a 32-octet key used by the peer to establish the EAP-FAST Phase 1 tunnel. This key is used to derive the TLS premaster secret as described in Section 5.1. The PAC-Key is randomly generated by the EAP server to produce a strong entropy 32-octet key. The PAC-Key is a secret and MUST be treated accordingly. For example, as the PAC-Key is a separate component provisioned by the server to establish a secure tunnel, the server may deliver this component protected by a secure channel, and it must be stored securely by the peer.
1. PAC密钥：这是对等方用于建立EAP-FAST第1阶段隧道的32个八位组密钥。该密钥用于推导第5.1节所述的TLS premaster机密。PAC密钥由EAP服务器随机生成，以生成强熵32八位字节密钥。PAC密钥是一个秘密，必须进行相应的处理。例如，由于PAC密钥是由服务器提供以建立安全隧道的单独组件，因此服务器可以交付受安全通道保护的该组件，并且必须由对等方安全地存储该组件。
2. PAC-Opaque: this is a variable length field that is sent to the EAP server during the EAP-FAST Phase 1 tunnel establishment. The PAC-Opaque can only be interpreted by the EAP server to recover the required information for the server to validate the peer's identity and authentication. For example, the PAC-Opaque includes the PAC-Key and may contain the PAC's peer identity. The PAC-Opaque format and contents are specific to the PAC issuing server. The PAC-Opaque may be presented in the clear, so an attacker MUST NOT be able to gain useful information from the PAC-Opaque itself. The server issuing the PAC-Opaque must ensure it is protected with strong cryptographic keys and algorithms.
2. PAC不透明：这是一个可变长度字段，在EAP-FAST第1阶段隧道建立期间发送到EAP服务器。PAC不透明只能由EAP服务器解释，以恢复服务器验证对等方身份和身份验证所需的信息。例如，PAC不透明包含PAC密钥，并且可能包含PAC的对等身份。PAC不透明格式和内容特定于PAC发布服务器。PAC不透明可能以透明形式显示，因此攻击者不能从PAC不透明本身获取有用信息。发出PAC不透明的服务器必须确保它受到强加密密钥和算法的保护。
3. PAC-Info: this is a variable length field used to provide, at a minimum, the authority identity of the PAC issuer. Other useful but not mandatory information, such as the PAC-Key lifetime, may also be conveyed by the PAC issuing server to the peer during PAC provisioning or refreshment.
3. PAC Info：这是一个可变长度字段，用于至少提供PAC颁发者的权限标识。在PAC供应或刷新期间，PAC发布服务器还可以将其他有用但非强制性的信息（如PAC密钥生存期）传送给对等方。
The use of the PAC is based on the SessionTicket extension defined in [RFC4507]. The EAP server initiates the EAP-FAST conversation as normal. Upon receiving the A-ID from the server, the peer checks to see if it has an existing valid PAC-Key and PAC-Opaque for the server. If it does, then it obtains the PAC-Opaque and puts it in the SessionTicket extension in the ClientHello. It is RECOMMENDED in EAP-FAST that the peer include an empty Session ID in a ClientHello containing a PAC-Opaque. EAP-FAST does not currently support the SessionTicket Handshake message so an empty SessionTicket extension MUST NOT be included in the ClientHello. If the PAC-Opaque included in the SessionTicket extension is valid and the EAP server permits the abbreviated TLS handshake, it will select the ciphersuite allowed to be used from information within the PAC and finish with the abbreviated TLS handshake. If the server receives a Session ID and a PAC-Opaque in the SessionTicket extension in a ClientHello, it should place the same Session ID in the ServerHello if it is resuming a session based on the PAC-Opaque. The conversation then proceeds as described in [RFC4507] until the handshake completes or a fatal error occurs. After the abbreviated handshake completes, the peer and server are ready to commence Phase 2. Note that when a PAC is used,
PAC的使用基于[RFC4507]中定义的SessionTicket扩展。EAP服务器正常启动EAP-FAST对话。从服务器接收到A-ID后，对等方将检查它是否具有服务器的现有有效PAC密钥和PAC不透明。如果是，则获取PAC不透明并将其放入ClientHello中的SessionTicket扩展中。在EAP-FAST中，建议对等方在包含PAC的ClientHello中包含空会话ID。EAP-FAST目前不支持SessionTicket握手消息，因此ClientHello中不得包含空的SessionTicket扩展名。如果SessionTicket扩展中包含的PAC密码有效，且EAP服务器允许缩写TLS握手，则它将从PAC内的信息中选择允许使用的密码套件，并以缩写TLS握手结束。如果服务器在ClientHello中的SessionTicket扩展中接收到会话ID和PAC不透明，则如果服务器正在基于PAC不透明恢复会话，则应在ServerHello中放置相同的会话ID。然后，对话按照[RFC4507]中所述继续进行，直到握手完成或出现致命错误。在简短握手完成后，对等方和服务器准备开始第2阶段。请注意，使用PAC时，
the TLS master secret is calculated from the PAC-Key, client random, and server random as described in Section 5.1.
TLS主密钥根据PAC密钥、客户端随机密钥和服务器随机密钥计算，如第5.1节所述。
Specific details for the Tunnel PAC format, provisioning and security considerations are best described in [EAP-PROV]
有关隧道PAC格式、配置和安全注意事项的具体细节，请参见[EAP-PROV]
If session resumption based on server-side or client-side state fails, the server can gracefully fall back to a full TLS handshake. If the ServerHello received by the peer contains a empty Session ID or a Session ID that is different than in the ClientHello, the server may be falling back to a full handshake. The peer can distinguish the server's intent of negotiating full or abbreviated TLS handshake by checking the next TLS handshake messages in the server response to the ClientHello. If ChangeCipherSpec follows the ServerHello in response to the ClientHello, then the server has accepted the session resumption and intends to negotiate the abbreviated handshake. Otherwise, the server intends to negotiate the full TLS handshake. A peer can request for a new PAC to be provisioned after the full TLS handshake and mutual authentication of the peer and the server. In order to facilitate the fallback to a full handshake, the peer SHOULD include ciphersuites that allow for a full handshake and possibly PAC provisioning so the server can select one of these in case session resumption fails. An example of the transition is shown in Appendix A.
如果基于服务器端或客户端状态的会话恢复失败，服务器可以正常地退回到完全TLS握手。如果对等方收到的ServerHello包含空会话ID或与ClientHello中不同的会话ID，则服务器可能会退回到完全握手状态。对等方可以通过检查服务器对ClientHello的响应中的下一个TLS握手消息来区分服务器协商完整或缩写TLS握手的意图。如果ChangeCipherSpec跟随ServerHello响应ClientHello，则服务器已接受会话恢复，并打算协商缩短的握手。否则，服务器打算协商完整的TLS握手。对等方可以在完全TLS握手和对等方与服务器的相互认证之后请求提供新的PAC。为了便于回退到完全握手，对等方应包括允许完全握手的密码套件，以及可能的PAC配置，以便服务器在会话恢复失败时可以选择其中之一。附录A中给出了一个过渡示例。
The second portion of the EAP-FAST 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. 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 protected termination exchange described in Section 3.3.2. The TLV exchange may include the execution of zero or more EAP methods within the protected tunnel as described in Section 3.3.1. A server MAY proceed directly to the protected termination exchange if it does not wish to request further authentication from the peer. However, the peer and server must not assume that either will skip inner EAP methods or other TLV exchanges. 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 through the use of the Request-Action TLV.
EAP-FAST认证的第二部分在第1阶段成功完成后立即进行。即使对等方和身份验证者在第1阶段TLS协商中都经过身份验证，也会发生第2阶段。如果第1阶段TLS握手失败，则不得出现第2阶段。阶段2包括一系列封装在第4.2节定义的TLV对象中的请求和响应。第2阶段必须始终以第3.3.2节所述的受保护终端交换结束。TLV交换可能包括在第3.3.1节所述的受保护隧道内执行零个或多个EAP方法。如果服务器不希望从对等方请求进一步的身份验证，则可以直接进入受保护的终端交换。但是，对等方和服务器不得假设其中一方将跳过内部EAP方法或其他TLV交换。对等方可能已漫游到需要符合不同认证策略的网络，或者对等方可能通过使用请求操作TLV请求服务器采取附加操作。
EAP [RFC3748] prohibits use of multiple authentication methods within a single EAP conversation in order to limit vulnerabilities to man-in-the-middle attacks. EAP-FAST addresses man-in-the-middle attacks through support for cryptographic protection of the inner EAP exchange and cryptographic binding of the inner authentication method(s) to the protected tunnel. EAP methods are executed serially in a sequence. This version of EAP-FAST does not support initiating multiple EAP methods simultaneously in parallel. The methods need not be distinct. For example, EAP-TLS could be run twice as an inner method, first using machine credentials followed by a second instance using user credentials.
EAP[RFC3748]禁止在单个EAP会话中使用多个身份验证方法，以限制中间人攻击的漏洞。EAP-FAST通过支持内部EAP交换的加密保护和内部身份验证方法到受保护隧道的加密绑定，解决中间人攻击。EAP方法按顺序串行执行。此版本的EAP-FAST不支持同时并行启动多个EAP方法。方法不必是不同的。例如，EAP-TLS可以作为内部方法运行两次，首先使用计算机凭据，然后使用用户凭据运行第二个实例。
EAP method messages are carried within EAP-Payload TLVs defined in Section 4.2.6. If more than one method is going to be executed in the tunnel then, upon completion of a method, a 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 Section 4.2.8 and Section 5.3. The Intermediate-Result TLVs can be included with other TLVs such as EAP-Payload TLVs starting a new EAP conversation or with the Result TLV used in the protected termination exchange. In the case where only one EAP method is executed in the tunnel, the Intermediate-Result TLV MUST NOT be sent with the Result TLV. In this case, the status of the inner EAP method is represented by the final Result TLV, which also represents the result of the whole EAP-FAST conversation. This is to maintain backward compatibility with existing implementations.
EAP方法消息在第4.2.6节中定义的EAP有效载荷TLV内传输。如果要在隧道中执行多个方法，则在方法完成后，服务器必须发送指示结果的中间结果TLV。对等方必须响应指示其结果的中间结果TLV。如果结果表明成功，则中间结果TLV必须附带加密绑定TLV。第4.2.8节和第5.3节进一步讨论了加密绑定TLV。中间结果TLV可以包括在其他TLV中，例如启动新EAP会话的EAP有效负载TLV，或者包括在受保护的终端交换中使用的结果TLV中。在隧道中仅执行一个EAP方法的情况下，中间结果TLV不得与结果TLV一起发送。在这种情况下，内部EAP方法的状态由最终结果TLV表示，它也表示整个EAP-FAST对话的结果。这是为了保持与现有实现的向后兼容性。
If both peer and server indicate success, then the method is considered complete. If either indicates failure. then the method is considered failed. The result of failure of an EAP method does not always imply a failure of the overall authentication. If one authentication method fails, the server may attempt to authenticate the peer with a different method.
如果对等方和服务器都表示成功，则认为该方法已完成。如果其中一个指示失败。然后该方法被认为是失败的。EAP方法失败的结果并不总是意味着整个身份验证失败。如果一种身份验证方法失败，服务器可能会尝试使用其他方法对对等方进行身份验证。
A successful EAP-FAST Phase 2 conversation MUST always end in a successful Result TLV exchange. An EAP-FAST server may initiate the Result TLV exchange without initiating any EAP conversation in EAP-FAST Phase 2. After the final Result TLV exchange, the TLS tunnel is terminated and a clear text EAP-Success or EAP-Failure is sent by the server. The format of the Result TLV is described in Section 4.2.2.
成功的EAP-FAST第2阶段对话必须始终以成功的TLV交换结果结束。EAP-FAST服务器可以在不启动EAP-FAST阶段2中的任何EAP对话的情况下启动结果TLV交换。在TLV交换的最终结果之后，TLS隧道终止，服务器发送明文EAP Success或EAP Failure。第4.2.2节描述了结果TLV的格式。
A server initiates a successful protected termination exchange by sending a Result TLV indicating success. The server may send the Result TLV along with an Intermediate-Result TLV and a Crypto-Binding TLV. If the peer requires nothing more from the server it will respond with a Result TLV indicating success accompanied by an Intermediate-Result TLV and Crypto-Binding TLV if necessary. The server then tears down the tunnel and sends a clear text EAP-Success.
服务器通过发送指示成功的结果TLV来启动成功的受保护终止交换。服务器可以发送结果TLV以及中间结果TLV和加密绑定TLV。如果对等方不再需要来自服务器的任何内容，它将响应一个结果TLV，指示成功，并在必要时伴随一个中间结果TLV和加密绑定TLV。然后，服务器断开隧道并发送明文EAP Success。
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 be run or it wants to request a PAC), it may request further action from the server using the Request-Action TLV. The Request-Action TLV is sent along with the Result TLV indicating what EAP Success/Failure result the peer would expect if the requested action is not granted. The value of the Request-Action TLV 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，但其身份验证策略未得到满足（例如，它需要运行特定的身份验证机制或它想要请求PAC），则它可以使用请求操作TLV从服务器请求进一步的操作。请求操作TLV与结果TLV一起发送，结果TLV指示如果请求的操作未被授予，对等方将期望的EAP成功/失败结果。请求操作TLV的值指示对等方下一步要做什么。第4.2.9节定义了请求操作TLV的格式和值。
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 send the clear text EAP Success or Failure message based on the value of the peer's result 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.
在收到请求操作TLV后，服务器可以根据其策略处理该请求或忽略该请求。如果服务器忽略该请求，则继续终止隧道，并根据对等方的结果TLV的值发送明文EAP Success或Failure消息。如果服务器接受并处理请求，它将继续执行请求的操作。对话结束，结果是TLV交换。结果TLV可能包含在完成请求操作的TLV中。
Error handling for Phase 2 is discussed in Section 3.6.2.
第2阶段的错误处理在第3.6.2节中讨论。
The Peer-Id and Server-Id may be determined based on the types of credentials used during either the EAP-FAST tunnel creation or authentication.
对等Id和服务器Id可以基于EAP-FAST隧道创建或认证期间使用的凭据类型来确定。
When X.509 certificates are used for peer authentication, the Peer-Id is determined by the subject or subjectAltName fields in the peer certificate. As noted in [RFC3280] (updated by [RFC4630]):
当X.509证书用于对等身份验证时，对等Id由对等证书中的subject或subjectAltName字段确定。如[RFC3280]所述（由[RFC4630]更新）：
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.
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.
Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN).
如果不为空，则主题字段必须包含X.500可分辨名称（DN）。
If an inner EAP method is run, then the Peer-Id is obtained from the inner method.
如果运行内部EAP方法，则从内部方法获取对等Id。
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 or subjectAltName field in the server certificate defines the Server-Id.
当服务器使用X.509证书建立TLS隧道时，服务器Id以与上述对等Id类似的方式确定；e、 例如，服务器证书中的subject或subjectAltName字段定义服务器Id。
The EAP session identifier is constructed using the random values provided by the peer and server during the TLS tunnel establishment. The Session-Id is defined as follows:
EAP会话标识符是使用对等方和服务器在TLS隧道建立期间提供的随机值构造的。会话Id的定义如下：
Session-Id = 0x2B || client_random || server_random) client_random = 32 byte nonce generated by the peer server_random = 32 byte nonce generated by the server
会话Id=0x2B | | | | | |服务器|随机）客户端|随机=对等服务器生成的32字节nonce |随机=服务器生成的32字节nonce
EAP-FAST uses the following error handling rules summarized below:
EAP-FAST使用以下总结的错误处理规则：
1. Errors in the TLS layer are communicated via TLS alert messages in all phases of EAP-FAST.
1. 在EAP-FAST的所有阶段，TLS层中的错误通过TLS警报消息进行通信。
2. The Intermediate-Result TLVs carry success or failure indications of the individual EAP methods in EAP-FAST Phase 2. Errors within the EAP conversation in Phase 2 are expected to be handled by individual EAP methods.
2. 中间结果TLV带有EAP-FAST第2阶段中单个EAP方法的成功或失败指示。阶段2中EAP对话中的错误预计将由各个EAP方法处理。
3. Violations of the TLV rules are handled using Result TLVs together with Error TLVs.
3. 使用结果TLV和错误TLV处理违反TLV规则的行为。
4. Tunnel compromised errors (errors caused by Crypto-Binding failed or missing) are handled using Result TLVs and Error TLVs.
4. 隧道泄露错误（加密绑定失败或丢失导致的错误）使用结果TLV和错误TLV进行处理。
If the EAP-FAST server detects an error at any point in the TLS Handshake or the TLS layer, the server SHOULD send an EAP-FAST request encapsulating a TLS record containing the appropriate TLS alert message rather than immediately terminating the conversation so as to allow the peer to inform the user of the cause of the failure and possibly allow for a restart of the conversation. The peer MUST send an EAP-FAST response to an alert message. The EAP-Response
如果EAP-FAST服务器在TLS握手或TLS层的任何点检测到错误，服务器应发送EAP-FAST请求，封装包含适当TLS警报消息的TLS记录，而不是立即终止对话，以便允许对等方通知用户故障原因，并可能允许重新启动对话。对等方必须向警报消息发送EAP-FAST响应。EAP响应
packet sent by the peer may encapsulate a TLS ClientHello handshake message, in which case the EAP-FAST server MAY allow the EAP-FAST conversation to be restarted, or it MAY contain an EAP-FAST response with a zero-length message, in which case the server MUST terminate the conversation with an EAP-Failure packet. It is up to the EAP-FAST server whether to allow restarts, and if so, how many times the conversation can be restarted. An EAP-FAST Server implementing restart capability SHOULD impose a limit on the number of restarts, so as to protect against denial-of-service attacks.
对等方发送的数据包可以封装TLS ClientHello握手消息，在这种情况下，EAP-FAST服务器可以允许重新启动EAP-FAST对话，或者它可以包含长度为零的消息的EAP-FAST响应，在这种情况下，服务器必须使用EAP故障数据包终止对话。是否允许重启取决于EAP-FAST服务器，如果允许重启，则取决于会话可以重启多少次。实现重启功能的EAP-FAST服务器应限制重启次数，以防止拒绝服务攻击。
If the EAP-FAST peer detects an error at any point in the TLS layer, the EAP-FAST peer should send an EAP-FAST response encapsulating a TLS record containing the appropriate TLS alert message. The server may restart the conversation by sending an EAP-FAST request packet encapsulating the TLS HelloRequest handshake message. The peer may allow the EAP-FAST conversation to be restarted or it may terminate the conversation by sending an EAP-FAST response with an zero-length message.
如果EAP-FAST对等方在TLS层的任何点检测到错误，则EAP-FAST对等方应发送EAP-FAST响应，该响应封装了包含适当TLS警报消息的TLS记录。服务器可以通过发送封装TLS HelloRequest握手消息的EAP-FAST请求包来重新启动会话。对等方可以允许重新启动EAP-FAST对话，也可以通过发送长度为零的消息的EAP-FAST响应来终止对话。
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 with the appropriate error code. 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. For errors involving a tunnel compromise, the error-code is Tunnel_Compromise_Error. Upon sending a Result TLV with a fatal Error TLV the sender terminates the TLS tunnel. Note that a server will still wait for a message from the peer after it sends a failure, however the server does not need to process the contents of the response message.
在第2阶段TLV处理期间，当对等方或服务器在TLS层之外发现致命错误时，它必须发送失败的结果TLV和带有适当错误代码的错误TLV。对于涉及交换序列处理的错误，例如违反TLV规则（例如，多个EAP有效负载TLV），错误代码是意外的\u TLV\u交换的。对于涉及隧道妥协的错误，错误代码为隧道妥协错误。在发送带有致命错误TLV的结果TLV时，发送方终止TLS隧道。请注意，服务器在发送故障后仍将等待来自对等方的消息，但是服务器不需要处理响应消息的内容。
If a server receives a Result TLV of failure with a fatal Error TLV, it SHOULD send a clear text EAP-Failure. If a peer receives a Result TLV of failure, it MUST respond with a Result TLV indicating failure. If the server has sent a Result TLV of failure, it ignores the peer response, and it SHOULD send a clear text EAP-Failure.
如果服务器收到带有致命错误TLV的故障结果TLV，则应发送明文EAP failure。如果对等方收到失败的结果TLV，它必须以指示失败的结果TLV进行响应。如果服务器发送了失败的结果TLV，它将忽略对等响应，并应发送明文EAP failure。
A single TLS record may be up to 16384 octets in length, but a TLS message may span multiple TLS records, and a TLS certificate message may in principle be as long as 16 MB. This is larger than the maximum size for a message on most media types, therefore it is desirable to support fragmentation. Note that in order to protect against reassembly lockup and denial-of-service attacks, it may be desirable for an implementation to set a maximum size for one such
单个TLS记录的长度可能高达16384个八位字节，但TLS消息可能跨越多个TLS记录，原则上TLS证书消息的长度可能长达16 MB。这大于大多数媒体类型上消息的最大大小，因此需要支持分段。请注意，为了防止重组锁定和拒绝服务攻击，实现可能需要为这样的一个设置最大大小
group of TLS messages. Since a typical certificate chain is rarely longer than a few thousand octets, and no other field is likely to be anywhere near as long, a reasonable choice of maximum acceptable message length might be 64 KB. This is still a fairly large message packet size so an EAP-FAST implementation MUST provide its own support for fragmentation and reassembly.
TLS消息组。由于一个典型的证书链的长度很少超过几千个八位字节，而且没有其他字段可能接近于此长度，因此可以合理选择的最大可接受消息长度可能是64 KB。这仍然是一个相当大的消息包大小，因此EAP-FAST实现必须为碎片和重组提供自己的支持。
Since EAP is an lock-step protocol, fragmentation support can be added in a simple manner. In EAP, fragments that are lost or damaged in transit will be retransmitted, and since sequencing information is provided by the Identifier field in EAP, there is no need for a fragment offset field.
由于EAP是一种锁步协议，因此可以以简单的方式添加碎片支持。在EAP中，在传输过程中丢失或损坏的片段将被重新传输，并且由于序列信息由EAP中的标识符字段提供，因此不需要片段偏移字段。
EAP-FAST fragmentation support is provided through the addition of flag bits within the EAP-Response and EAP-Request packets, as well as a TLS Message Length field of four octets. Flags include the Length included (L), More fragments (M), and EAP-FAST Start (S) bits. The L flag is set to indicate the presence of the four-octet TLS Message Length field, and MUST be set for the first fragment of a fragmented TLS message or set of messages. The M flag is set on all but the last fragment. The S flag is set only within the EAP-FAST start message sent from the EAP server to the peer. The TLS Message Length field is four octets, and provides the total length of the TLS message or set of messages that is being fragmented; this simplifies buffer allocation.
EAP-FAST分段支持通过在EAP响应和EAP请求数据包中添加标志位以及四个八位字节的TLS消息长度字段来提供。标志包括包含的长度（L）、更多片段（M）和EAP-FAST Start（S）位。设置L标志以指示存在四个八位组的TLS消息长度字段，并且必须为分段TLS消息或消息集的第一个片段设置L标志。除最后一个片段外，所有片段都设置了M标志。S标志仅在从EAP服务器发送到对等方的EAP-FAST start消息中设置。TLS消息长度字段为四个八位字节，并提供正在分段的TLS消息或消息集的总长度；这简化了缓冲区分配。
When an EAP-FAST peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type of EAP-FAST and no data. This serves as a fragment ACK. The EAP server must wait until it receives the EAP-Response before sending another fragment. In order to prevent errors in processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer must include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value.
当EAP-FAST对等方收到设置为M位的EAP请求数据包时，它必须以EAP类型为EAP-FAST且无数据的EAP响应进行响应。这是一个片段。EAP服务器必须等到收到EAP响应后再发送另一个片段。为了防止处理片段时出错，EAP服务器必须增加EAP请求中包含的每个片段的标识符字段，并且对等方必须在EAP响应中包含的片段确认中包含此标识符值。重新传输的片段将包含相同的标识符值。
Similarly, when the EAP-FAST server receives an EAP-Response with the M bit set, it must respond with an EAP-Request with EAP-Type of EAP-FAST and no data. This serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. In order to prevent errors in the processing of fragments, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP-Response.
类似地，当EAP-FAST服务器接收到设置为M位的EAP响应时，它必须使用EAP类型为EAP-FAST且无数据的EAP请求进行响应。这是一个片段。EAP对等方必须等到收到EAP请求后再发送另一个片段。为了防止片段处理中出现错误，EAP服务器必须增加EAP请求中包含的每个片段ACK的标识符值，并且对等方必须在EAP响应中包含的后续片段中包含该标识符值。
The following sections describe the message formats used in EAP-FAST. The fields are transmitted from left to right in network byte order.
以下各节介绍EAP-FAST中使用的消息格式。字段按网络字节顺序从左向右传输。
A summary of the EAP-FAST Request/Response packet format is shown below.
EAP-FAST请求/响应数据包格式摘要如下所示。
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 | Data... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Data... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
密码
The code field is one octet in length defined as follows:
代码字段的长度为一个八位字节，定义如下：
1 Request
1请求
2 Response
2回应
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.
标识符字段是一个八位字节，有助于将响应与请求匹配。必须在每个请求数据包上更改标识符字段。响应数据包中的标识符字段必须与相应请求中的标识符字段匹配。
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, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception.
长度字段是两个八位字节，表示EAP数据包的长度，包括代码、标识符、长度、类型、标志、版本、消息长度和数据字段。长度字段范围之外的八位字节应视为数据链路层填充，在接收时应忽略。
Type
类型
43 for EAP-FAST
43适用于EAP-FAST
Flags
旗帜
0 1 2 3 4
+-+-+-+-+-+
|L M S R R|
+-+-+-+-+-+
0 1 2 3 4
+-+-+-+-+-+
|L M S R R|
+-+-+-+-+-+
L Length included; set to indicate the presence of the four-octet Message Length field
L包括长度；设置为指示存在四个八位字节的消息长度字段
M More fragments; set on all but the last fragment
更多的碎片；除最后一个片段外，设置所有片段
S EAP-FAST start; set in an EAP-FAST Start message
S EAP-快速启动；在EAP-FAST启动消息中设置
R Reserved (must be zero)
R保留（必须为零）
Ver
版本
This field contains the version of the protocol. This document describes version 1 (001 in binary) of EAP-FAST.
此字段包含协议的版本。本文件描述了EAP-FAST的第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.
消息长度字段为四个八位字节，仅当设置了L位时才存在。此字段提供可能在多个数据包的数据字段上分段的消息的总长度。
Data
数据
In the case of an EAP-FAST Start request (i.e., when the S bit is set) the Data field consists of the A-ID described in Section 4.1.1. In other cases, when the Data field is present, it consists of an encapsulated TLS packet in TLS record format. An EAP-FAST packet with Flags and Version fields, but with zero length data field, is used to indicate EAP-FAST acknowledgement for either a fragmented message, a TLS Alert message or a TLS Finished message.
在EAP快速启动请求的情况下（即，当设置S位时），数据字段由第4.1.1节中描述的A-ID组成。在其他情况下，当数据字段存在时，它由TLS记录格式的封装TLS数据包组成。带有标志和版本字段，但数据字段长度为零的EAP-FAST数据包用于表示对分段消息、TLS警报消息或TLS完成消息的EAP-FAST确认。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x04) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x04) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
The Type field is two octets. It is set to 0x0004 for Authority ID
类型字段是两个八位字节。权限ID设置为0x0004
Length
长
The Length filed is two octets, which contains the length of the ID field in octets.
长度字段是两个八位字节，其中包含以八位字节为单位的ID字段的长度。
ID
身份证件
Hint of the identity of the server. It should be unique across the deployment.
服务器标识的提示。它在整个部署中应该是唯一的。
The TLVs defined here are standard Type-Length-Value (TLV) objects. The TLV objects could be used to carry arbitrary parameters between 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 NOT send an NAK TLV for a TLV that is not marked mandatory.
EAP对等方不一定实现EAP服务器支持的所有TLV。为了实现互操作性，TLV被设计为允许EAP服务器使用NAK TLV发现EAP对等方是否支持TLV。TLV中的强制位指示是否需要TLV支持。如果对等方或服务器不支持标记为强制的TLV，则它必须在响应中发送NAK TLV，并且必须忽略消息中的所有其他TLV。如果EAP对等方或服务器发现标记为可选的不受支持的TLV，则可以忽略不受支持的TLV。它不能为未标记为强制的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上强制/可选设置的处理。符合本规范的实施必须支持以下TLV：
Result TLV NAK TLV Error TLV EAP-Payload TLV Intermediate-Result TLV Crypto-Binding TLV Request-Action TLV
结果TLV NAK TLV错误TLV EAP有效负载TLV中间结果TLV加密绑定TLV请求操作TLV
TLVs are defined as described below. The fields are transmitted from left to right.
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Optional TLV
0可选TLV
1 Mandatory TLV
1强制性TLV
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
A 14-bit field, denoting the TLV type. Allocated Types include:
14位字段，表示TLV类型。分配的类型包括：
0 Reserved
1 Reserved
2 Reserved
3 Result TLV (Section 4.2.2)
4 NAK TLV (Section 4.2.3)
5 Error TLV (Section 4.2.4)
7 Vendor-Specific TLV (Section 4.2.5)
9 EAP-Payload TLV (Section 4.2.6)
10 Intermediate-Result TLV (Section 4.2.7)
11 PAC TLV [EAP-PROV]
12 Crypto-Binding TLV (Section 4.2.8)
18 Server-Trusted-Root TLV [EAP-PROV]
19 Request-Action TLV (Section 4.2.9)
20 PKCS#7 TLV [EAP-PROV]
0 Reserved
1 Reserved
2 Reserved
3 Result TLV (Section 4.2.2)
4 NAK TLV (Section 4.2.3)
5 Error TLV (Section 4.2.4)
7 Vendor-Specific TLV (Section 4.2.5)
9 EAP-Payload TLV (Section 4.2.6)
10 Intermediate-Result TLV (Section 4.2.7)
11 PAC TLV [EAP-PROV]
12 Crypto-Binding TLV (Section 4.2.8)
18 Server-Trusted-Root TLV [EAP-PROV]
19 Request-Action TLV (Section 4.2.9)
20 PKCS#7 TLV [EAP-PROV]
Length
长
The length of the Value field in octets.
值字段的长度（以八位字节为单位）。
Value
价值
The value of the TLV.
TLV的值。
The Result TLV provides support for acknowledged success and failure messages for protected termination within EAP-FAST. 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 Section 3.3.2 and Section 3.6.2. A Result TLV indicating failure MUST NOT be accompanied by the following TLVs: NAK, EAP-Payload TLV, or Crypto-Binding TLV. The Result TLV is defined as follows:
结果TLV为EAP-FAST内受保护终端的确认成功和失败消息提供支持。如果状态字段不包含已知值之一，则对等服务器或EAP服务器必须将其视为意外\u TLV\u交换的致命错误。第3.3.2节和第3.6.2节进一步讨论了结果TLV的行为。指示故障的结果TLV不得伴随以下TLV：NAK、EAP有效负载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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 for Result TLV
结果TLV为3
Length
长
2
2.
Status
地位
The Status field is two octets. Values include:
状态字段是两个八位字节。价值包括：
1 Success
1成功
2 Failure
2失败
The NAK TLV allows a peer to detect TLVs that are not supported by the other peer. An EAP-FAST 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。EAP-FAST数据包可以包含0个或多个NAK TLV。NAK TLV不应与其他TLV一起使用。不得发送NAK 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 for 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 Code of the Vendor in network byte order. The Vendor-Id field MUST be zero for TLVs that are not Vendor-Specific TLVs.
供应商Id字段是四个八位字节，包含不受支持的TLV的供应商Id。高阶八位组为0，低阶三个八位组为供应商的管理信息（SMI）网络管理私有企业代码的结构，按网络字节顺序排列。对于非特定于供应商的TLV，供应商Id字段必须为零。
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类型字段是两个八位字节。该字段包含不受支持的TLV类型。此类型的TLV必须包含在前一个数据包中。
TLVs
阈限值
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.
此字段包含零个或多个TLV的列表，每个TLV不得设置强制位。这些可选的TLV是为了将来的扩展性，以传达为什么确定不支持有问题的TLV。
The Error TLV allows an EAP peer or server to indicate errors to the other party. An EAP-FAST 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 codes 2000-2999 represent fatal errors. A fatal Error TLV MUST be accompanied by a Result TLV indicating failure and the conversation must be terminated as described in Section 3.6.2. The Error TLV is defined as follows:
错误TLV允许EAP对等方或服务器向另一方指示错误。EAP-FAST数据包可以包含0个或多个错误TLV。错误代码字段描述错误的类型。错误代码1-999表示成功的结果（信息性消息），1000-1999表示警告，代码2000-2999表示致命错误。致命错误TLV必须伴随一个结果TLV，指示失败，并且必须按照第3.6.2节所述终止对话。错误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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 for Error TLV
5用于错误TLV
Length
长
4
4.
Error-Code
错误代码
The Error-Code field is four octets. Currently defined values for Error-Code include:
错误代码字段是四个八位字节。当前定义的错误代码值包括：
2001 Tunnel_Compromise_Error
2001年隧道泄漏错误
2002 Unexpected_TLVs_Exchanged
2002年意外的TLV交换
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 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.
特定于供应商的TLV可用于允许供应商支持其自身不适合一般用途的扩展属性。特定于供应商的TLV属性可以包含一个或多个TLV，称为供应商TLV。供应商TLV的TLV类型由供应商定义。单个供应商特定TLV内的所有供应商TLV属于同一供应商。同一消息中可能有来自不同供应商的多个供应商特定TLV。
Vendor TLVs may be optional or mandatory. Vendor TLVs sent with Result TLVs MUST be marked as optional.
供应商TLV可以是可选的，也可以是强制性的。随结果TLV一起发送的供应商TLV必须标记为可选。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 for 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 Code of the Vendor in network byte order.
供应商Id字段是四个八位字节，包含TLV的供应商Id。高阶八位字节为0，低阶三位八位字节为供应商的SMI网络管理私有企业代码，按网络字节顺序排列。
Vendor TLVs
供应商TLV
This field is of indefinite length. It contains vendor-specific TLVs, in a format defined by the vendor.
此字段的长度不定。它包含特定于供应商的TLV，格式由供应商定义。
To allow piggybacking 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:
为了允许与其他TLV搭载EAP请求或响应，定义了EAP有效负载TLV，其中包括封装的EAP数据包和可选TLV列表。提供可选TLV是为了将来的扩展性，以提供有关当前EAP身份验证的提示。消息中只允许一个EAP有效负载TLV。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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (1)
必填项，设置为（1）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
9 for 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
阈限值
This field contains a list of zero or more 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不得设置强制位。此字段的总长度等于EAP有效负载TLV的长度字段减去EAP数据包字段的EAP报头中的长度字段。
The Intermediate-Result TLV provides support for acknowledged intermediate Success and Failure messages between multiple inner EAP methods within EAP. An Intermediate-Result TLV indicating success MUST be accompanied by a Crypto-Binding TLV. 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支持EAP中多个内部EAP方法之间已确认的中间成功和失败消息。指示成功的中间结果TLV必须伴有加密绑定TLV。提供与此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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (1)
必填项，设置为（1）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
10 for Intermediate-Result TLV
中间结果TLV为10
Length
长
2 + cumulative length of the embedded associated TLVs
2+嵌入式相关TLV的累积长度
Status
地位
The Status field is two octets. Values include:
状态字段是两个八位字节。价值包括：
1 Success
1成功
2 Failure
2失败
TLVs
阈限值
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关联的TLV。此字段中的TLV不得设置强制位。
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 EAP-FAST version negotiated before TLS tunnel establishment, see Section 3.1.
加密绑定TLV用于证明对等方和服务器都参与了隧道的建立和身份验证序列。它还提供了在TLS隧道建立之前协商的EAP-FAST版本的验证，见第3.1节。
The Crypto-Binding TLV MUST be included with the Intermediate-Result TLV to perform Cryptographic Binding after each successful EAP method in a sequence of EAP methods. The Crypto-Binding TLV can be issued at other times as well.
加密绑定TLV必须包含在中间结果TLV中，以便在一系列EAP方法中的每个成功EAP方法之后执行加密绑定。加密绑定TLV也可以在其他时间发布。
The Crypto-Binding TLV is valid only if the following checks pass:
只有通过以下检查，加密绑定TLV才有效：
o The Crypto-Binding TLV version is supported
o 支持加密绑定TLV版本
o The MAC verifies correctly
o MAC验证正确
o The received version in the Crypto-Binding TLV matches the version sent by the receiver during the EAP version negotiation
o 加密绑定TLV中接收到的版本与EAP版本协商期间接收方发送的版本匹配
o The subtype is set to the correct value
o 子类型设置为正确的值
If any of the above checks fail, then the TLV is invalid. An invalid Crypto-Binding TLV is a fatal error and is handled as described in Section 3.6.2.
如果上述任何检查失败，则TLV无效。无效的加密绑定TLV是一个致命错误，按照第3.6.2节的说明进行处理。
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. | Sub-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. | Sub-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to (1)
必填项，设置为（1）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
12 for Crypto-Binding TLV
12用于加密绑定TLV
Length
长
56
56
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 EAP method is using. For an implementation compliant with this version of EAP-FAST, the version number MUST be set to 1.
版本字段是一个八位字节，设置为EAP方法使用的加密绑定TLV的版本。对于符合此版本EAP-FAST的实施，版本号必须设置为1。
Received Version
收到的版本
The Received Version field is a single octet and MUST be set to the EAP 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 Version字段是一个八位字节，必须设置为版本协商期间接收的EAP版本号。请注意，此字段仅提供针对降级攻击的保护，其中双方都需要支持此TLV的EAP版本。
Sub-Type
子类型
The Sub-Type field is one octet. Defined values include:
子类型字段是一个八位字节。定义的值包括：
0 Binding Request
0绑定请求
1 Binding Response
1结合反应
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 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 1.
Nonce字段是32个八位字节。它包含一个在时间上唯一的256位nonce，用于每一端的复合MAC密钥派生。请求中的nonce必须将其最低有效位设置为0，响应中的nonce必须与请求nonce具有相同的值，但最低有效位必须设置为1。
Compound MAC
复合MAC
The 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 5.3.
复合MAC字段为20个八位字节。这可以是服务器MAC（B1_MAC）或客户端MAC（B2_MAC）。第5.3节描述了MAC的计算。
The Request-Action TLV MAY be sent by the peer along with a Result TLV in response to a server's successful Result TLV. It allows the peer to request the EAP server to negotiate additional EAP methods or process TLVs specified in the response packet. The server MAY ignore this TLV.
请求操作TLV可由对等方连同结果TLV一起发送，以响应服务器的成功结果TLV。它允许对等方请求EAP服务器协商其他EAP方法或处理响应数据包中指定的TLV。服务器可能会忽略此TLV。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory set to one (1)
强制设置为一（1）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
19 for Request-Action TLV
19请求行动TLV
Length
长
2
2.
Action
行动
The Action field is two octets. Values include:
动作字段是两个八位字节。价值包括：
Process-TLV
过程TLV
Negotiate-EAP
谈判EAP
The following table provides a guide to which TLVs may be found in which kinds of messages, and in what quantity. The messages are as follows: Request is an EAP-FAST Request, Response is an EAP-FAST Response, Success is a message containing a successful Result TLV, and Failure is a message containing a failed Result TLV.
下表提供了在哪种类型的消息中可以找到哪些TLV以及数量的指南。消息如下：请求是EAP-FAST请求，响应是EAP-FAST响应，成功是包含成功结果TLV的消息，失败是包含失败结果TLV的消息。
Request Response Success Failure TLVs 0-1 0-1 0-1 0-1 Intermediate-Result 0-1 0-1 0 0 EAP-Payload 0-1 0-1 1 1 Result 0-1 0-1 0-1 0-1 Crypto-Binding 0+ 0+ 0+ 0+ Error 0+ 0+ 0 0 NAK 0+ 0+ 0+ 0+ Vendor-Specific [NOTE1] 0 0-1 0-1 0-1 Request-Action
请求-响应成功失败TLVs 0-10-1 0-1 0-1 0-1 0-1 0-1 0-0 EAP有效负载0-1 0-1 1 1结果0-1 0-1 0-1 0-1 0-1加密绑定0+0+0+0+0+0+0+0+0 NAK 0+0+0+0+0+0+特定于供应商的[NOTE1]0-1 0-1 0-1 0-1请求操作
[NOTE1] Vendor TLVs (included in Vendor-Specific TLVs) sent with a Result TLV MUST be marked as optional.
[注1]随结果TLV一起发送的供应商TLV（包括在供应商特定TLV中）必须标记为可选。
The following table defines the meaning of the table entries in the sections below:
下表定义了以下各节中表格条目的含义：
0 This TLV MUST NOT be present in the message.
0此TLV不能出现在消息中。
0+ Zero or more instances of this TLV MAY be present in the message.
消息中可能存在0+零个或多个此TLV实例。
0-1 Zero or one instance of this TLV MAY be present in the message.
0-1消息中可能存在此TLV的零个或一个实例。
1 Exactly one instance of this TLV MUST be present in the message.
1消息中必须正好存在此TLV的一个实例。
The EAP-FAST Authentication tunnel key is calculated similarly to the TLS key calculation with an additional 40 octets (referred to as the session_key_seed) generated. The additional session_key_seed is used in the Session Key calculation in the EAP-FAST Tunneled Authentication conversation.
EAP-FAST认证隧道密钥的计算类似于TLS密钥计算，并生成额外的40个八位组（称为会话密钥种子）。附加会话密钥种子用于EAP-FAST隧道身份验证会话中的会话密钥计算。
To generate the key material required for the EAP-FAST Authentication tunnel, the following construction from [RFC4346] is used:
为了生成EAP-FAST认证隧道所需的关键材料，使用[RFC4346]中的以下构造：
key_block = PRF(master_secret, "key expansion", server_random + client_random)
密钥块=PRF（主密钥，“密钥扩展”，服务器随机+客户端随机）
where '+' denotes concatenation.
其中“+”表示串联。
The PRF function used to generate keying material is defined by [RFC4346].
用于生成键控材质的PRF函数由[RFC4346]定义。
For example, if the EAP-FAST Authentication employs 128-bit RC4 and SHA1, the key_block is 112 octets long and is partitioned as follows:
例如，如果EAP-FAST认证采用128位RC4和SHA1，则密钥块的长度为112个八位字节，并按如下方式进行分区：
client_write_MAC_secret[20]
server_write_MAC_secret[20]
client_write_key[16]
server_write_key[16]
client_write_IV[0]
server_write_IV[0]
session_key_seed[40]
client_write_MAC_secret[20]
server_write_MAC_secret[20]
client_write_key[16]
server_write_key[16]
client_write_IV[0]
server_write_IV[0]
session_key_seed[40]
The session_key_seed is used by the EAP-FAST Authentication Phase 2 conversation to both cryptographically bind the inner method(s) to the tunnel as well as generate the resulting EAP-FAST session keys. The other quantities are used as they are defined in [RFC4346].
会话密钥种子由EAP-FAST身份验证阶段2对话使用，以加密方式将内部方法绑定到隧道，并生成生成的EAP-FAST会话密钥。其他数量按照[RFC4346]中的定义使用。
The master_secret is generated as specified in TLS unless a PAC is used to establish the TLS tunnel. When a PAC is used to establish the TLS tunnel, the master_secret is calculated from the specified client_random, server_random, and PAC-Key as follows:
除非使用PAC建立TLS隧道，否则将按照TLS中的规定生成主密钥。当使用PAC建立TLS隧道时，根据指定的客户端\u random、服务器\u random和PAC密钥计算主\u密钥，如下所示：
master_secret = T-PRF(PAC-Key, "PAC to master secret label hash", server_random + client_random, 48)
master_secret=T-PRF（PAC密钥，“PAC到master secret标签散列”，服务器随机+客户端随机，48）
where T-PRF is described in Section 5.5.
其中，第5.5节描述了T-PRF。
The session_key_seed derived as part of EAP-FAST Phase 2 is used in EAP-FAST Phase 2 to generate an Intermediate Compound Key (IMCK) used to verify the integrity of the TLS tunnel after each successful inner authentication and in the generation of Master Session Key (MSK) and Extended Master Session Key (EMSK) defined in [RFC3748]. Note that the IMCK must be recalculated after each successful inner EAP method.
作为EAP-FAST阶段2一部分派生的会话密钥种子用于EAP-FAST阶段2中生成中间复合密钥（IMCK），用于在每次成功的内部身份验证后以及在生成[RFC3748]中定义的主会话密钥（MSK）和扩展主会话密钥（EMSK）时验证TLS隧道的完整性。注意，在每次成功的内部EAP方法之后，必须重新计算IMCK。
The first step in these calculations is the generation of the base compound key, IMCK[n] from the session_key_seed and any session keys derived from the successful execution of n inner EAP methods. The inner EAP method(s) may provide Master Session Keys, MSK1..MSKn, corresponding to inner methods 1 through n. The MSK is truncated at 32 octets if it is longer than 32 octets or padded to a length of 32 octets with zeros if it is less than 32 octets. If the ith inner method does not generate an MSK, then MSKi is set to zero (e.g., MSKi = 32 octets of 0x00s). If an inner method fails, then it is not included in this calculation. The derivations of S-IMCK is as follows:
这些计算中的第一步是从会话密钥种子生成基本复合密钥IMCK[n]，以及从成功执行n个内部EAP方法派生的任何会话密钥。内部EAP方法可以提供与内部方法1到n相对应的主会话密钥MSK1..MSKn。如果八位位组的长度小于32个八位位组，则将其截断，如果八位位组的长度小于32个八位位组，则将其截断。如果第i个内部方法未生成MSK，则MSKi设置为零（例如，MSKi=0x00s的32个八位字节）。如果内部方法失败，则不包括在该计算中。S-IMCK的推导如下：
S-IMCK[0] = session_key_seed For j = 1 to n-1 do IMCK[j] = T-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", MSK[j], 60) S-IMCK[j] = first 40 octets of IMCK[j] CMK[j] = last 20 octets of IMCK[j]
S-IMCK[0]=会话密钥\u j=1到n-1的种子do-IMCK[j]=T-PRF（S-IMCK[j-1]，“内部方法复合密钥”，MSK[j]，60）S-IMCK[j]=IMCK[j]的前40个八位组CMK[j]=IMCK[j]的最后20个八位组
where T-PRF is described in Section 5.5.
其中，第5.5节描述了T-PRF。
For authentication methods that generate keying material, further protection against man-in-the-middle attacks is provided through cryptographically binding keying material established by both EAP-FAST Phase 1 and EAP-FAST Phase 2 conversations. After each successful inner EAP authentication, EAP MSKs are cryptographically combined with key material from EAP-FAST Phase 1 to generate a compound session key, CMK. The CMK is used to calculate the Compound MAC as part of the Crypto-Binding TLV described in Section 4.2.8, which helps provide assurance that the same entities are involved in all communications in EAP-FAST. During the calculation of the Compound-MAC the MAC field is filled with zeros.
对于生成密钥材料的认证方法，通过EAP-FAST第1阶段和EAP-FAST第2阶段对话建立的加密绑定密钥材料，提供了针对中间人攻击的进一步保护。在每次成功的内部EAP身份验证之后，EAP MSK将以加密方式与EAP-FAST第1阶段的密钥材料相结合，以生成复合会话密钥CMK。CMK用于计算复合MAC，作为第4.2.8节所述加密绑定TLV的一部分，这有助于确保EAP-FAST中的所有通信都涉及相同的实体。在计算复合MAC期间，MAC字段用零填充。
The Compound MAC computation is as follows:
复合MAC计算如下：
CMK = CMK[j] Compound-MAC = HMAC-SHA1( CMK, Crypto-Binding TLV )
CMK=CMK[j]化合物MAC=HMAC-SHA1（CMK，密码结合TLV）
where j is the number of the last successfully executed inner EAP method.
其中j是最后一个成功执行的内部EAP方法的编号。
EAP-FAST Authentication assures the master session key (MSK) and Extended Master Session Key (EMSK) output from the EAP method are the result of all authentication conversations by generating an Intermediate Compound Key (IMCK). The IMCK is mutually derived by the peer and the server as described in Section 5.2 by combining the MSKs from inner EAP methods with key material from EAP-FAST Phase 1. The resulting MSK and EMSK are generated as part of the IMCKn key hierarchy as follows:
EAP-FAST身份验证通过生成中间复合密钥（IMCK），确保从EAP方法输出的主会话密钥（MSK）和扩展主会话密钥（EMSK）是所有身份验证会话的结果。如第5.2节所述，通过将内部EAP方法中的MSK与EAP-FAST第1阶段中的关键材料相结合，对等方和服务器可相互派生IMCK。生成的MSK和EMSK作为IMCKn密钥层次结构的一部分生成，如下所示：
MSK = T-PRF(S-IMCK[j], "Session Key Generating Function", 64) EMSK = T-PRF(S-IMCK[j], "Extended Session Key Generating Function", 64)
MSK=T-PRF（S-IMCK[j]，“会话密钥生成函数”，64）EMSK=T-PRF（S-IMCK[j]，“扩展会话密钥生成函数”，64）
where j is the number of the last successfully executed inner EAP method.
其中j是最后一个成功执行的内部EAP方法的编号。
The EMSK is typically only known to the EAP-FAST 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 is outside the scope of this document.
EMSK通常仅为EAP-FAST对等方和服务器所知，不提供给第三方。额外密钥的推导以及这些密钥向第三方的传输不在本文档的范围内。
If no EAP methods have been negotiated inside the tunnel or no EAP methods have been successfully completed inside the tunnel, the MSK and EMSK will be generated directly from the session_key_seed meaning S-IMCK = session_key_seed.
如果在隧道内没有协商EAP方法，或者在隧道内没有成功完成EAP方法，则MSK和EMSK将直接从会话密钥种子生成，意思是S-IMCK=会话密钥种子。
EAP-FAST employs the following PRF prototype and definition:
EAP-FAST采用以下PRF原型和定义：
T-PRF = F(key, label, seed, outputlength)
T-PRF=F（键、标签、种子、输出长度）
Where label is intended to be a unique label for each different use of the T-PRF. The outputlength parameter is a two-octet value that is represented in big endian order. Also note that the seed value may be optional and may be omitted as in the case of the MSK derivation described in Section 5.4.
其中，标签旨在为T-PRF的每种不同用途提供唯一的标签。outputlength参数是以大端顺序表示的两个八位字节的值。还请注意，种子值可以是可选的，并且可以在第5.4节中描述的MSK推导的情况下省略。
To generate the desired outputlength octets of key material, the T-PRF is calculated as follows:
为了生成关键材料的所需输出长度八位字节，T-PRF的计算如下：
S = label + 0x00 + seed
T-PRF output = T1 + T2 + T3 + ... + Tn
T1 = HMAC-SHA1 (key, S + outputlength + 0x01)
T2 = HMAC-SHA1 (key, T1 + S + outputlength + 0x02)
T3 = HMAC-SHA1 (key, T2 + S + outputlength + 0x03)
Tn = HMAC-SHA1 (key, Tn-1 + S + outputlength + 0xnn)
S = label + 0x00 + seed
T-PRF output = T1 + T2 + T3 + ... + Tn
T1 = HMAC-SHA1 (key, S + outputlength + 0x01)
T2 = HMAC-SHA1 (key, T1 + S + outputlength + 0x02)
T3 = HMAC-SHA1 (key, T2 + S + outputlength + 0x03)
Tn = HMAC-SHA1 (key, Tn-1 + S + outputlength + 0xnn)
where '+' indicates concatenation. Each Ti generates 20-octets of keying material. The last Tn may be truncated to accommodate the desired length specified by outputlength.
其中“+”表示串联。每个Ti生成20个八位组的键控材料。最后一个Tn可能会被截断，以适应outputlength指定的所需长度。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the EAP-FAST protocol, in accordance with BCP 26, [RFC2434].
本节根据BCP 26、[RFC2434]，就EAP-FAST协议相关值的注册向互联网分配号码管理局（IANA）提供指导。
EAP-FAST has already been assigned the EAP Method Type number 43.
EAP-FAST已被分配EAP方法类型编号43。
The document defines a registry for EAP-FAST TLV types, which may be assigned by Specification Required as defined in [RFC2434]. Section 4.2 defines the TLV types that initially populate the registry. A summary of the EAP-FAST TLV types is given below:
本文件定义了EAP-FAST TLV类型的注册表，可根据[RFC2434]中定义的规范进行分配。第4.2节定义了最初填充注册表的TLV类型。EAP-FAST TLV类型概述如下：
0 Reserved
1 Reserved
2 Reserved
3 Result TLV
4 NAK TLV
5 Error TLV
7 Vendor-Specific TLV
9 EAP-Payload TLV
10 Intermediate-Result TLV
11 PAC TLV [EAP-PROV]
12 Crypto-Binding TLV
18 Server-Trusted-Root TLV [EAP-PROV]
19 Request-Action TLV
20 PKCS#7 TLV [EAP-PROV]
0 Reserved
1 Reserved
2 Reserved
3 Result TLV
4 NAK TLV
5 Error TLV
7 Vendor-Specific TLV
9 EAP-Payload TLV
10 Intermediate-Result TLV
11 PAC TLV [EAP-PROV]
12 Crypto-Binding TLV
18 Server-Trusted-Root TLV [EAP-PROV]
19 Request-Action TLV
20 PKCS#7 TLV [EAP-PROV]
The Error-TLV defined in Section 4.2.4 requires an error-code. EAP-FAST Error-TLV error-codes are assigned based on specifications required as defined in [RFC2434]. The initial list of error codes is as follows:
第4.2.4节中定义的错误TLV需要错误代码。EAP-FAST错误TLV错误代码是根据[RFC2434]中规定的规范分配的。错误代码的初始列表如下所示：
2001 Tunnel_Compromise_Error
2001年隧道泄漏错误
2002 Unexpected_TLVs_Exchanged
2002年意外的TLV交换
The Request-Action TLV defined in Section 4.2.9 contains an action code which is assigned on a specification required basis as defined in [RFC2434]. The initial actions defined are:
第4.2.9节中定义的请求行动TLV包含行动代码，该代码根据[RFC2434]中定义的规范要求分配。定义的初始操作包括：
1 Process-TLV
1工艺TLV
2 Negotiate-EAP
2谈判EAP
The various values under Vendor-Specific TLV are assigned by Private Use and do not need to be assigned by IANA.
供应商特定TLV下的各种值由私人使用分配，无需IANA分配。
EAP-FAST 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 EAP-FAST is defined in the EAP [RFC3748].
EAP-FAST的设计重点是无线媒体，而无线媒体本身就是窃听所固有的。而在有线媒体中，攻击者必须获得对有线媒体的物理访问；无线媒体使任何人都能够在信息通过空中传输时捕获信息，从而实现被动攻击。因此，无法假设物理安全性，安全漏洞要大得多。EAP[RFC3748]中定义了用于EAP-FAST安全评估的威胁模型。
EAP-FAST as a whole, provides message and integrity protection by establishing a secure tunnel for protecting the authentication 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 authentication methods executed within the EAP-FAST 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.
EAP-FAST作为一个整体，通过建立用于保护身份验证方法的安全隧道来提供消息和完整性保护。机密性和完整性保护由TLS定义，并提供与采用强熵共享主密钥的TLS相同的安全强度。通过计算加密绑定TLV，验证在EAP-FAST隧道内执行的密钥生成认证方法的完整性。这确保了隧道端点与内部方法端点相同。
The Result TLV is protected and conveys the true Success or Failure of EAP-FAST, and should be used as the indicator of its success or failure respectively. However, as EAP must terminate with a clear text EAP Success or Failure, a peer will also receive a clear text EAP Success or Failure. The received clear text EAP success or failure must match that received in the Result TLV; the peer SHOULD silently discard those clear text EAP Success or Failure messages that do not coincide with the status sent in the protected Result TLV.
结果TLV受到保护并传达EAP-FAST的真正成功或失败，应分别用作其成功或失败的指标。然而，由于EAP必须以明文EAP成功或失败终止，对等方也将收到明文EAP成功或失败。收到的明文EAP成功或失败必须与结果TLV中收到的一致；对等方应默默地丢弃那些与受保护结果TLV中发送的状态不一致的明文EAP成功或失败消息。
As is true for any negotiated EAP protocol, NAK packets used to suggest an alternate 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 negotiate 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 EAP-FAST as an authentication method does not limit the potential inner authentication methods, so EAP-FAST should be selected when available.
与任何协商EAP协议一样，用于建议备用身份验证方法的NAK数据包在不受保护的情况下发送，因此会受到欺骗。在无保护的EAP方法协商期间，NAK数据包可能作为主动攻击被打断，以协商到较弱的身份验证形式，例如EAP-MD5（它只提供单向身份验证，不派生密钥）。对等方和服务器都应该有一个方法选择策略，以防止它们向下协商到较弱的方法。内部方法协商抵抗攻击，因为它受到建立的相互认证的TLS隧道的保护。选择EAP-FAST作为身份验证方法并不限制潜在的内部身份验证方法，因此应在可用时选择EAP-FAST。
An attacker cannot readily determine the inner EAP 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.
攻击者无法轻易确定所使用的内部EAP方法，除非可能通过流量分析。对等实现限制未经验证或未经授权的服务器使用凭据也很重要。
Separation of the EAP-FAST 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:
不建议将EAP-FAST阶段1与阶段2对话分开。如果两台服务器之间没有适当的信任关系和协议保护，允许在与阶段2对话不同的服务器上终止阶段1对话可能会引入漏洞。一些漏洞包括：
o Loss of identity protection o Offline dictionary attacks o Lack of policy enforcement
o 身份保护丢失o脱机字典攻击o缺乏策略实施
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 EAP-FAST MAY be used. The EAP-FAST encrypting/decrypting gateway SHOULD, at a minimum, provide support for IPsec or similar protection in order to provide confidentiality for the portion of the conversation between the gateway and the EAP server.
可能存在第1阶段和第2阶段服务器之间存在信任关系的情况，例如在校园内或同一公司内的两个办公室之间，在这两个服务器之间暴露对等实体的内部身份和凭据没有危险。在这些情况下，可以使用没有EAP-FAST端到端保护的代理解决方案。EAP-FAST加密/解密网关应至少提供IPsec或类似保护的支持，以便为网关和EAP服务器之间的对话部分提供机密性。
EAP-FAST addresses the known deficiencies and weaknesses in the EAP method. By employing a shared secret between the peer and server to establish a secured tunnel, EAP-FAST enables:
EAP-FAST解决了EAP方法中的已知缺陷和弱点。通过在对等方和服务器之间使用共享秘密来建立安全隧道，EAP-FAST可实现：
o Per packet confidentiality and integrity protection o User identity protection o Better support for notification messages o Protected EAP inner method negotiation o Sequencing of EAP methods o Strong mutually derived master session keys o Acknowledged success/failure indication o Faster re-authentications through session resumption o Mitigation of dictionary attacks o Mitigation of man-in-the-middle attacks o Mitigation of some denial-of-service attacks
o 每个数据包的机密性和完整性保护o用户身份保护o更好地支持通知消息o受保护的EAP内部方法协商o EAP方法的排序o强大的相互派生的主会话密钥o已确认的成功/失败指示o通过会话恢复加快重新身份验证o缓解字典攻击o缓解中间人攻击o缓解某些拒绝服务攻击
It should be noted that with EAP-FAST, 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 EAP-FAST as well.
应该注意的是，与许多其他身份验证协议一样，EAP-FAST的对手可以发起拒绝服务攻击，发送错误流量以破坏协议。这是许多身份验证或密钥协商协议中的一个问题，因此EAP-FAST也注意到了这一点。
EAP-FAST was designed with a focus on protected authentication methods that typically rely on weak credentials, such as password-based secrets. To that extent, the EAP-FAST Authentication mitigates several vulnerabilities, such as dictionary attacks, by protecting the weak credential-based authentication 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.
EAP-FAST的设计重点是受保护的身份验证方法，这些方法通常依赖于弱凭据，例如基于密码的机密。在这种程度上，EAP-FAST身份验证通过保护基于弱凭证的身份验证方法，减轻了一些漏洞，如字典攻击。该保护基于TLS中的强加密算法，以提供消息机密性和完整性。用于保护的密钥依赖于对等方和服务器提供的强随机挑战以及具有强熵的已建立密钥。生成随机数时，实现应遵循[RFC4086]中的建议。
The initial identity request response exchange is sent in cleartext outside the protection of EAP-FAST. Typically the Network Access Identifier (NAI) [RFC4282] in the identity response is useful only for the realm 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
初始身份请求-响应交换以明文形式发送，不受EAP-FAST的保护。通常，标识响应中的网络访问标识符（NAI）[RFC4282]仅对用于将身份验证请求路由到正确的EAP服务器的领域信息有用。这意味着标识响应可能包含匿名标识，并且只包含领域信息。在其他情况下，如果存在用于建立请求的目标域的其他方法，则可以完全消除身份交换。在任何情况下，中介机构都不应信任身份响应中的身份信息，因为它
is unauthenticated an may not have any relevance to the authenticated identity. EAP-FAST implementations should not attempt to compare any identity disclosed in the initial cleartext EAP Identity response packet with those Identities authenticated in Phase 2
未经身份验证，则可能与经身份验证的身份没有任何关联。EAP-FAST实现不应尝试将初始明文EAP标识响应包中披露的任何标识与第2阶段中认证的标识进行比较
Identity request-response exchanges sent after the EAP-FAST tunnel is established are protected from modification and eavesdropping by attackers.
EAP-FAST隧道建立后发送的身份请求-响应交换受到保护，免受攻击者的修改和窃听。
Note that since TLS client certificates are sent in the clear, if identity protection is required, then it is possible for the TLS authentication to be re-negotiated 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 EAP-FAST Phase 2, the server MAY send a TLS hello_request. This allows the client to perform client authentication by sending a client_hello if it wants to, or send a no_renegotiation alert to the server indicating that it wants to continue with EAP-FAST Phase 2 instead. Assuming that the client permits renegotiation by sending a client_hello, then the server will respond with server_hello, a certificate and certificate_request messages. The client replies with certificate, client_key_exchange and certificate_verify messages. Since this re-negotiation occurs within the encrypted TLS channel, it does not reveal client certificate details. It is possible to perform certificate authentication using an EAP method (for example: EAP-TLS) within the TLS session in EAP-FAST Phase 2 instead of using TLS handshake renegotiation.
请注意，由于TLS客户端证书是以明文形式发送的，如果需要身份保护，则在第一次服务器身份验证之后，可以重新协商TLS身份验证。为了实现这一点，服务器通常不会请求服务器\u hello中的证书，然后在发送服务器\u finished消息之后，在EAP-FAST阶段2之前，服务器可能会发送TLS hello\u请求。这允许客户端通过发送客户端hello（如果愿意）来执行客户端身份验证，或者向服务器发送no_重新协商警报，指示它希望继续执行EAP-FAST阶段2。假设客户机通过发送客户机你好来允许重新协商，那么服务器将用服务器你好、证书和证书请求消息进行响应。客户端回复证书、客户端密钥交换和证书验证消息。由于此重新协商发生在加密的TLS通道内，因此不会显示客户端证书的详细信息。可以在EAP-FAST阶段2中的TLS会话中使用EAP方法（例如：EAP-TLS）执行证书身份验证，而不是使用TLS握手重新协商。
EAP-FAST was designed with a focus on protected authentication methods that typically rely on weak credentials, such as password-based secrets. EAP-FAST mitigates dictionary attacks by allowing the establishment of a mutually authenticated encrypted TLS tunnel providing confidentiality and integrity to protect the weak credential based authentication method.
EAP-FAST的设计重点是受保护的身份验证方法，这些方法通常依赖于弱凭据，例如基于密码的机密。EAP-FAST允许建立相互认证的加密TLS隧道，提供机密性和完整性，以保护基于弱凭证的认证方法，从而减轻字典攻击。
Allowing methods to be executed both with and without the protection of a secure tunnel opens up a possibility of a man-in-the-middle attack. To avoid man-in-the-middle attacks it is recommended to always deploy authentication methods with protection of EAP-FAST. EAP-FAST provides protection from man-in-the-middle attacks even if a deployment chooses to execute inner EAP methods both with and without EAP-FAST protection, EAP-FAST prevents this attack in two ways:
允许在有或没有安全隧道保护的情况下执行方法，可能会导致中间人攻击。为避免中间人攻击，建议始终部署具有EAP-FAST保护的身份验证方法。EAP-FAST提供了对中间人攻击的保护，即使部署选择在有EAP-FAST保护和无EAP-FAST保护的情况下执行内部EAP方法，EAP-FAST也可以通过两种方式防止此攻击：
1. By using the PAC-Key to mutually authenticate the peer and server during EAP-FAST Authentication Phase 1 establishment of a secure tunnel.
1. 在EAP-FAST身份验证阶段1建立安全隧道期间，使用PAC密钥对对等方和服务器进行相互身份验证。
2. By using the keys generated by the inner authentication method (if the inner methods are key generating) in the crypto-binding exchange and in the generation of the key material exported by the EAP method described in Section 5.
2. 通过在加密绑定交换和第5节所述EAP方法导出的密钥材料的生成中使用内部认证方法生成的密钥（如果内部方法生成密钥）。
A PAC may be bound to a user identity. A compliant implementation of EAP-FAST MUST validate that an identity obtained in the PAC-Opaque field matches at minimum one of the identities provided in the EAP-FAST Phase 2 authentication method. This validation provides another binding to ensure that the intended peer (based on identity) has successfully completed the EAP-FAST Phase 1 and proved identity in the Phase 2 conversations.
PAC可以绑定到用户标识。EAP-FAST的兼容实现必须验证在PAC不透明字段中获得的身份与EAP-FAST第2阶段身份验证方法中提供的至少一个身份匹配。此验证提供另一个绑定，以确保目标对等方（基于身份）已成功完成EAP-FAST第1阶段，并在第2阶段对话中验证身份。
EAP Success and EAP Failure packets are, in general, sent in clear text 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, EAP-FAST provides protection against these attacks. Once the peer and AS initiate the EAP-FAST Authentication Phase 2, compliant EAP-FAST implementations must silently discard all clear text EAP messages, unless both the EAP-FAST peer and server have indicated success or failure using a protected mechanism. Protected mechanisms include TLS alert mechanism and the protected termination mechanism described in Section 3.3.2.
通过提供消息机密性和完整性，EAP-FAST提供了针对这些攻击的保护。一旦对等方和AS启动EAP-FAST身份验证阶段2，符合要求的EAP-FAST实施必须以静默方式放弃所有明文EAP消息，除非EAP-FAST对等方和服务器都使用受保护的机制指示成功或失败。受保护机制包括第3.3.2节所述的TLS警报机制和受保护终止机制。
The success/failure decisions within the EAP-FAST tunnel indicate the final decision of the EAP-FAST authentication conversation. After a success/failure result has been indicated by a protected mechanism, the EAP-FAST 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.
EAP-FAST隧道内的成功/失败决策指示EAP-FAST身份验证对话的最终决策。在受保护机制指示成功/失败结果后，EAP-FAST对等方可以处理未受保护的EAP成功和EAP失败消息；但是，当结果与受保护机制的结果不匹配时，对等方必须忽略任何未受保护的EAP成功或失败消息。
To abide by [RFC3748], the server must send a clear text EAP Success or EAP Failure packet to terminate the EAP conversation. However, since EAP Success and EAP Failure packets are not retransmitted, the
要遵守[RFC3748]，服务器必须发送明文EAP Success或EAP Failure数据包以终止EAP对话。但是，由于EAP成功和EAP失败数据包不会被重新传输，因此
final packet may be lost. While an EAP-FAST protected EAP Success or EAP Failure packet should not be a final packet in an EAP-FAST 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.
最后的数据包可能丢失。虽然受EAP-FAST保护的EAP成功或EAP失败数据包不应是EAP-FAST对话中的最终数据包，但它可能基于上述条件发生，因此EAP对等方不应依赖未受保护的EAP成功和失败消息。
As part of the TLS negotiation, the server presents a certificate to the peer. The peer MUST verify the validity of the EAP server certificate, and SHOULD also examine the EAP server name presented in the certificate, in order to determine whether the EAP server can be trusted. Please note that in the case where the EAP authentication is remote, the EAP server will not reside on the same machine as the authenticator, and therefore the name in the EAP server's certificate cannot be expected to match that of the intended destination. In this case, a more appropriate test might be whether the EAP server's certificate is signed by a CA controlling the intended domain and whether the authenticator can be authorized by a server in that domain.
作为TLS协商的一部分，服务器向对等方提供证书。对等方必须验证EAP服务器证书的有效性，还应检查证书中显示的EAP服务器名称，以确定是否可以信任EAP服务器。请注意，如果EAP身份验证是远程的，EAP服务器将不会与身份验证程序驻留在同一台计算机上，因此EAP服务器证书中的名称不能与预期目标的名称匹配。在这种情况下，更合适的测试可能是EAP服务器的证书是否由控制预期域的CA签名，以及验证器是否可以由该域中的服务器授权。
Since the Tunnel PAC is stored by the peer, special care should be given to the overall security of the peer. The Tunnel PAC must be securely stored by the peer to prevent theft or forgery of any of the Tunnel PAC components.
由于隧道PAC由对等方存储，因此应特别注意对等方的整体安全性。隧道PAC必须由对等方安全存储，以防止任何隧道PAC组件被盗或伪造。
In particular, the peer must securely store the PAC-Key and protect it from disclosure or modification. Disclosure of the PAC-Key enables an attacker to establish the EAP-FAST tunnel; however, disclosure of the PAC-Key does not reveal the peer or server identity or compromise any other peer's PAC credentials. Modification of the PAC-Key or PAC-Opaque components of the Tunnel PAC may also lead to denial of service as the tunnel establishment will fail.
特别是，对等方必须安全地存储PAC密钥，并保护其不被泄露或修改。泄露PAC密钥使攻击者能够建立EAP-FAST隧道；但是，泄露PAC密钥不会泄露对等方或服务器身份，也不会损害任何其他对等方的PAC凭据。修改隧道PAC的PAC密钥或PAC不透明组件也可能导致拒绝服务，因为隧道建立将失败。
The PAC-Opaque component is the effective TLS ticket extension used to establish the tunnel using the techniques of [RFC4507]. Thus, the security considerations defined by [RFC4507] also apply to the PAC-Opaque.
PAC不透明组件是有效的TLS票证扩展，用于使用[RFC4507]的技术建立隧道。因此，[RFC4507]定义的安全注意事项也适用于PAC。
The PAC-Info may contain information about the Tunnel PAC such as the identity of the PAC issuer and the Tunnel PAC lifetime for use in the management of the Tunnel PAC. The PAC-Info should be securely stored by the peer to protect it from disclosure and modification.
PAC信息可能包含有关隧道PAC的信息，例如PAC颁发者的身份和隧道PAC寿命，以用于隧道PAC的管理。PAC信息应由对等方安全存储，以防止其被披露和修改。
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. Ciphersuite negotiation: Yes Mutual authentication: Yes Integrity protection: Yes, Any method executed within the EAP-FAST tunnel is integrity protected. The cleartext EAP headers outside the tunnel are not integrity protected. Replay protection: Yes Confidentiality: Yes Key derivation: Yes Key strength: See Note 1 below. Dictionary attack prot.: Yes Fast reconnect: Yes Cryptographic binding: Yes Session independence: Yes Fragmentation: Yes Key Hierarchy: Yes Channel binding: No, but TLVs could be defined for this.
Auth。机制：基于证书、基于共享秘密和各种隧道式身份验证机制。Ciphersuite协商：是相互身份验证：是完整性保护：是，EAP-FAST隧道内执行的任何方法都受完整性保护。隧道外的明文EAP标头不受完整性保护。重播保护：是保密性：是密钥派生：是密钥强度：见下面的注释1。字典攻击保护：Yes快速重新连接：Yes加密绑定：Yes会话独立性：Yes碎片：Yes密钥层次结构：Yes通道绑定：No，但是可以为此定义TLV。
Notes
笔记
1. BCP 86 [RFC3766] offers advice on appropriate key sizes. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [NIST.SP800-57]. [RFC3766] Section 5 advises use of the following required RSA or DH module and 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 128-bit equivalent key strength:
1. BCP 86[RFC3766]提供有关适当密钥大小的建议。国家标准与技术研究所（NIST）还就[NIST.SP800-57]中的适当键尺寸提供建议。[RFC3766]第5节建议使用以下要求的RSA或DH模块和DSA子组大小（以位为单位），以位为单位表示给定级别的抗攻击性。根据下表，需要2048位RSA密钥才能提供128位等效密钥强度：
Attack Resistance RSA or DH Modulus DSA subgroup
(bits) 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
Attack Resistance RSA or DH Modulus DSA subgroup
(bits) 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
The EAP-FAST design and protocol specification is based on the ideas and hard efforts of Pad Jakkahalli, Mark Krischer, Doug Smith, and Glen Zorn of Cisco Systems, Inc.
EAP-FAST设计和协议规范基于Cisco Systems，Inc.的Pad Jakkahalli、Mark Krischer、Doug Smith和Glen Zorn的想法和努力。
The TLV processing was inspired from work on the Protected Extensible Authentication Protocol version 2 (PEAPv2) with Ashwin Palekar, Dan Smith, and Simon Josefsson. Helpful review comments were provided by Russ Housley, Jari Arkko, Bernard Aboba, Ilan Frenkel, and Jeremy Steiglitz.
TLV处理的灵感来自Ashwin Palekar、Dan Smith和Simon Josefsson在受保护的可扩展身份验证协议版本2（PEAPv2）上的工作。Russ Housley、Jari Arkko、Bernard Aboba、Ilan Frenkel和Jeremy Steiglitz提供了有用的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[RFC3268]Chown，P.，“用于传输层安全（TLS）的高级加密标准（AES）密码套件”，RFC 3268，2002年6月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 4507, May 2006.
[RFC4507]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 4507，2006年5月。
[EAP-PROV] Cam-Winget, N., "Dynamic Provisioning using EAP-FAST", Work in Progress, January 2007.
[EAP-PROV]Cam Winget，N.，“使用EAP-FAST的动态资源调配”，正在进行的工作，2007年1月。
[IEEE.802-1X.2004] "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, December 2004.
[IEEE.802-1X.2004]“局域网和城域网：基于端口的网络访问控制”，IEEE标准802.1X，2004年12月。
[NIST.SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management", Special Publication 800-57, May 2006.
[NIST.SP800-57]国家标准与技术研究所，“密钥管理建议”，特别出版物800-57，2006年5月。
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[RFC2716]Aboba，B.和D.Simon，“PPP EAP TLS认证协议”，RFC 2716，1999年10月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072]Eronen，P.，Hiller，T.，和G.Zorn，“直径可扩展认证协议（EAP）应用”，RFC 4072，2005年8月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC4630] Housley, R. and S. Santesson, "Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4630, August 2006.
[RFC4630]Housley，R.和S.Santesson，“更新Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件中的DirectoryString处理”，RFC 4630，2006年8月。
In the following examples the version field in EAP Fast is always assumed to be 1. The S, M, and L bits are assumed to be 0 unless otherwise specified.
在以下示例中，EAP Fast中的版本字段始终假定为1。除非另有规定，否则S、M和L位假定为0。
The following exchanges show a successful EAP-FAST authentication with optional PAC refreshment; the conversation will appear as follows:
以下交换显示了成功的EAP-FAST身份验证和可选的PAC刷新；对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST (TLS client_hello with PAC-Opaque in SessionTicket extension)->
EAP响应/EAP-FAST（TLS客户端\u你好，在SessionTicket扩展中使用PAC不透明）->
<- EAP-Request/EAP-FAST (TLS server_hello, TLS change_cipher_spec, TLS finished)
<-EAP请求/EAP-FAST（TLS服务器\u您好，TLS更改\u密码\u规范，TLS完成）
EAP-Response/EAP-FAST (TLS change_cipher_spec, TLS finished) ->
EAP响应/EAP-FAST（TLS更改\u密码\u规范，TLS完成）->
TLS channel established (Subsequent messages sent within the TLS channel, encapsulated within EAP-FAST)
建立TLS通道（在TLS通道内发送的后续消息，封装在EAP-FAST内）
<- EAP Payload TLV
(EAP-Request/EAP-GTC(Challenge))
<- EAP Payload TLV
(EAP-Request/EAP-GTC(Challenge))
EAP Payload TLV (EAP-Response/ EAP-GTC(Response with both user name and password)) ->
EAP有效负载TLV（EAP响应/EAP-GTC（带有用户名和密码的响应））->
optional additional exchanges (new pin mode, password change etc.) ...
可选的附加交换（新pin模式、密码更改等）。。。
<- Intermediate-Result TLV (Success) Crypto-Binding TLV (Request)
<-中间结果TLV（成功）加密绑定TLV（请求）
Intermediate-Result TLV (Success) Crypto-Binding TLV(Response) ->
中间结果TLV（成功）加密绑定TLV（响应）->
<- Result TLV (Success) [Optional PAC TLV]
<-结果TLV（成功）[可选PAC TLV]
Result TLV (Success) [PAC TLV Acknowledgment] ->
结果TLV（成功）[PAC TLV确认]]>
TLS channel torn down (messages sent in clear text)
TLS通道中断（以明文发送的消息）
<- EAP-Success
<-EAP成功
The following exchanges show a failed EAP-FAST authentication due to wrong user credentials; the conversation will appear as follows:
以下交换显示由于错误的用户凭据导致EAP-FAST身份验证失败；对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/ Identity (MyID1) ->
EAP响应/标识（MyID1）->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST (TLS client_hello with PAC-Opaque in SessionTicket extension)->
EAP响应/EAP-FAST（TLS客户端\u你好，在SessionTicket扩展中使用PAC不透明）->
<- EAP-Request/EAP-FAST (TLS server_hello, TLS change_cipher_spec, TLS finished)
<-EAP请求/EAP-FAST（TLS服务器\u您好，TLS更改\u密码\u规范，TLS完成）
EAP-Response/EAP-FAST (TLS change_cipher_spec, TLS finished) ->
EAP响应/EAP-FAST（TLS更改\u密码\u规范，TLS完成）->
TLS channel established (Subsequent messages sent within the TLS channel, encapsulated within EAP-FAST)
建立TLS通道（在TLS通道内发送的后续消息，封装在EAP-FAST内）
<- EAP Payload TLV (EAP-Request/ EAP-GTC (Challenge))
<-EAP有效载荷TLV（EAP请求/EAP-GTC（挑战））
EAP Payload TLV (EAP-Response/ EAP-GTC (Response with both user name and password)) ->
EAP有效负载TLV（EAP响应/EAP-GTC（带有用户名和密码的响应））->
<- EAP Payload TLV (EAP-Request/ EAP-GTC (error message))
<-EAP有效负载TLV（EAP请求/EAP-GTC（错误消息））
EAP Payload TLV (EAP-Response/ EAP-GTC (empty data packet to acknowledge unrecoverable error)) ->
EAP有效负载TLV（EAP响应/EAP-GTC（确认不可恢复错误的空数据包））->
<- Result TLV (Failure)
<-结果TLV（故障）
Result TLV (Failure) ->
结果TLV（故障）->
TLS channel torn down (messages sent in clear text)
TLS通道中断（以明文发送的消息）
<- EAP-Failure
<-EAP故障
In the case where an abbreviated TLS handshake is tried and failed, and a fallback to certificate-based full TLS handshake occurs within EAP-FAST Phase 1, the conversation will appear as follows:
如果在EAP-FAST阶段1中尝试了一次简短的TLS握手但失败，并且出现了基于证书的完整TLS握手的回退，则对话将如下所示：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
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服务器的提示，而不是完整的用户标识。
<- EAP-Request/EAP-FAST
(S=1, A-ID)
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST (TLS client_hello with PAC-Opaque extension)->
EAP响应/EAP-FAST（TLS客户端\u你好，PAC不透明扩展）->
// Peer sends PAC-Opaque of Tunnel PAC along with a list of ciphersuites supported. If the server rejects the PAC-Opaque, it falls through to the full TLS handshake
//对等方发送隧道PAC的PAC和支持的密码套件列表。如果服务器拒绝PAC不透明，则会进行完整的TLS握手
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
// TLS channel established (Subsequent messages sent within the TLS channel, encapsulated within EAP-FAST)
//建立TLS通道（在TLS通道内发送的后续消息，封装在EAP-FAST内）
// First EAP Payload TLV is piggybacked to the TLS Finished as Application Data and protected by the TLS tunnel
//第一个EAP有效载荷TLV作为应用程序数据装载到TLS，并由TLS隧道保护
EAP-Payload-TLV (EAP-Response/Identity (MyID2))->
EAP有效负载TLV（EAP响应/标识（MyID2））->
// identity protected by TLS.
//受TLS保护的身份。
<- EAP-Payload-TLV (EAP-Request/Method X)
<-EAP有效载荷TLV（EAP请求/方法X）
EAP-Payload-TLV
(EAP-Response/Method X) ->
EAP-Payload-TLV
(EAP-Response/Method X) ->
// Method X exchanges followed by Protected Termination
//方法X交换后进行受保护端接
<- Crypto-Binding TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC), Result TLV (Success)
<-加密绑定TLV（版本=1，EAP-FAST版本=1，Nonce，CompoundMAC），结果TLV（成功）
Crypto-Binding TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC), Result-TLV (Success) ->
加密绑定TLV（版本=1，EAP-FAST版本=1，Nonce，CompoundMAC），结果TLV（成功）->
// TLS channel torn down (messages sent in clear text)
//TLS通道中断（以明文发送的消息）
<- EAP-Success
<-EAP成功
In the case where a certificate-based TLS handshake occurs within EAP-FAST Phase 1, and client certificate authentication and identity privacy is desired, the conversation will appear as follows:
如果EAP-FAST阶段1内发生基于证书的TLS握手，并且需要客户端证书身份验证和身份隐私，则对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
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服务器的提示，而不是完整的用户标识。
<- EAP-Request/EAP-FAST (S=1, A-ID) EAP-Response/EAP-FAST (TLS client_hello)-> <- EAP-Request/EAP-FAST (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) EAP-Response/EAP-FAST (TLS client_key_exchange, TLS change_cipher_spec, TLS finished) ->
<-EAP请求/EAP-FAST（S=1，A-ID）EAP响应/EAP-FAST（TLS客户端\u你好）-><-EAP请求/EAP-FAST（TLS服务器\u你好，TLS证书，[TLS服务器\u密钥交换，][TLS证书\u请求，]TLS服务器\u你好\u完成）EAP响应/EAP-FAST（TLS客户端\u密钥交换，TLS更改\u密码\u规范，TLS完成）->
<- EAP-Request/EAP-FAST (TLS change_cipher_spec, TLS finished,TLS Hello-Request)
<-EAP请求/EAP-FAST（TLS更改\u密码\u规范，TLS完成，TLS Hello请求）
// TLS channel established (Subsequent messages sent within the TLS channel, encapsulated within EAP-FAST)
//建立TLS通道（在TLS通道内发送的后续消息，封装在EAP-FAST内）
// TLS Hello-Request is piggybacked to the TLS Finished as Handshake Data and protected by the TLS tunnel
//TLS Hello请求被装载到TLS，作为握手数据完成，并受TLS隧道的保护
// Subsequent messages are protected by the TLS Tunnel
//后续消息受TLS隧道保护
EAP-Response/EAP-FAST
(TLS client_hello) ->
EAP-Response/EAP-FAST
(TLS client_hello) ->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST (TLS change_cipher_spec, TLS finished, Result TLV (Success))
<-EAP请求/EAP-FAST（TLS更改\u密码\u规范，TLS完成，结果TLV（成功））
EAP-Response/EAP-FAST
(Result-TLV (Success)) ->
EAP-Response/EAP-FAST
(Result-TLV (Success)) ->
//TLS channel torn down (messages sent in clear text)
//TLS通道中断（以明文发送的消息）
<- EAP-Success
<-EAP成功
In the case where EAP-FAST fragmentation is required, the conversation will appear as follows:
如果需要EAP-FAST分段，对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST (TLS client_hello)-> <- EAP-Request/EAP-FAST (L=1,M=1, TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,])
EAP响应/EAP-FAST（TLS客户端\你好）-><-EAP请求/EAP-FAST（L=1，M=1，TLS服务器\你好，TLS证书，[TLS服务器\密钥\交换，][TLS证书\请求，]）
EAP-Response/EAP-FAST ->
EAP-Response/EAP-FAST ->
<- EAP-Request/EAP-FAST
(M=1,
[TLS certificate_request(con't),])
EAP-Response/EAP-FAST ->
<- EAP-Request/EAP-FAST
([TLS certificate_request(con't),]
TLS server_hello_done)
EAP-Response/EAP-FAST,
(L=1,M=1,[TLS certificate,])->
<- EAP-Request/EAP-FAST
(M=1,
[TLS certificate_request(con't),])
EAP-Response/EAP-FAST ->
<- EAP-Request/EAP-FAST
([TLS certificate_request(con't),]
TLS server_hello_done)
EAP-Response/EAP-FAST,
(L=1,M=1,[TLS certificate,])->
<- EAP-Request/EAP-FAST EAP-Response/EAP-FAST ([TLS certificate(con't),] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished))-> <- EAP-Request/EAP-FAST ( TLS change_cipher_spec, TLS finished, EAP-Payload-TLV (EAP-Request/Identity))
<-EAP请求/EAP-FAST EAP响应/EAP-FAST（[TLS证书（con't），]TLS客户端密钥交换，[TLS证书验证，]TLS更改密码规范，TLS完成））-><-EAP请求/EAP-FAST（TLS更改密码规范，TLS完成，EAP有效负载TLV（EAP请求/标识））
// TLS channel established (Subsequent messages sent within the TLS channel, encapsulated within EAP-FAST)
//建立TLS通道（在TLS通道内发送的后续消息，封装在EAP-FAST内）
// First EAP Payload TLV is piggybacked to the TLS Finished as Application Data and protected by the TLS tunnel
//第一个EAP有效载荷TLV作为应用程序数据装载到TLS，并由TLS隧道保护
EAP-Payload-TLV (EAP-Response/Identity (MyID2))->
EAP有效负载TLV（EAP响应/标识（MyID2））->
// identity protected by TLS.
//受TLS保护的身份。
<- EAP-Payload-TLV (EAP-Request/Method X)
<-EAP有效载荷TLV（EAP请求/方法X）
EAP-Payload-TLV
(EAP-Response/Method X) ->
EAP-Payload-TLV
(EAP-Response/Method X) ->
// Method X exchanges followed by Protected Termination
//方法X交换后进行受保护端接
<- Crypto-Binding TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC), Result TLV (Success)
<-加密绑定TLV（版本=1，EAP-FAST版本=1，Nonce，CompoundMAC），结果TLV（成功）
Crypto-Binding TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC), Result-TLV (Success) ->
加密绑定TLV（版本=1，EAP-FAST版本=1，Nonce，CompoundMAC），结果TLV（成功）->
// TLS channel torn down (messages sent in clear text)
//TLS通道中断（以明文发送的消息）
<- EAP-Success
<-EAP成功
Where EAP-FAST is negotiated, with a sequence of EAP method X followed by method Y, the conversation will occur as follows:
在协商EAP-FAST的情况下，按照EAP方法X和方法Y的顺序，对话将如下进行：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello)->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV(
EAP-Request/Identity))
EAP-Response/EAP-FAST
(TLS client_hello)->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV(
EAP-Request/Identity))
// TLS channel established (Subsequent messages sent within the TLS channel, encapsulated within EAP-FAST)
//建立TLS通道（在TLS通道内发送的后续消息，封装在EAP-FAST内）
// First EAP Payload TLV is piggybacked to the TLS Finished as Application Data and protected by the TLS tunnel
//第一个EAP有效载荷TLV作为应用程序数据装载到TLS，并由TLS隧道保护
EAP-Payload-TLV
(EAP-Response/Identity) ->
EAP-Payload-TLV
(EAP-Response/Identity) ->
<- EAP-Payload-TLV (EAP-Request/Method X)
<-EAP有效载荷TLV（EAP请求/方法X）
EAP-Payload-TLV
(EAP-Response/Method X) ->
EAP-Payload-TLV
(EAP-Response/Method X) ->
// Optional additional X Method exchanges...
//可选的附加X方法交换。。。
<- EAP-Payload-TLV (EAP-Request/Method X)
<-EAP有效载荷TLV（EAP请求/方法X）
EAP-Payload-TLV (EAP-Response/EAP-Type X)->
EAP有效负载TLV（EAP响应/EAP类型X）->
<- Intermediate Result TLV (Success), Crypto-Binding TLV (Version=1 EAP-FAST Version=1, Nonce, CompoundMAC), EAP Payload TLV (EAP-Request/Method Y)
<-中间结果TLV（成功），加密绑定TLV（版本=1 EAP-FAST版本=1，Nonce，CompoundMAC），EAP有效负载TLV（EAP请求/方法Y）
// Next EAP conversation started after successful completion of previous method X. The Intermediate-Result and Crypto-Binding TLVs are sent in this packet to minimize round-trips. In this example, identity request is not sent before negotiating EAP-Type=Y.
//下一个EAP对话在成功完成前一个方法X后开始。中间结果和加密绑定TLV在此数据包中发送，以最小化往返。在本例中，在协商EAP Type=Y之前不发送标识请求。
// Compound MAC calculated using Keys generated from EAP methods X and the TLS tunnel.
//使用EAP方法X和TLS隧道生成的密钥计算复合MAC。
Intermediate Result TLV (Success), Crypto-Binding TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC), EAP-Payload-TLV (EAP-Response/Method Y) ->
中间结果TLV（成功），加密绑定TLV（版本=1，EAP-FAST版本=1，Nonce，CompoundMAC），EAP有效负载TLV（EAP响应/方法Y）->
// Optional additional Y Method exchanges...
//可选的附加Y方法交换。。。
<- EAP Payload TLV (EAP-Request/Method Y)
<-EAP有效载荷TLV（EAP请求/方法Y）
EAP Payload TLV
(EAP-Response/Method Y) ->
EAP Payload TLV
(EAP-Response/Method Y) ->
<- Intermediate-Result-TLV (Success), Crypto-Binding TLV (Version=1 EAP-FAST Version=1, Nonce, CompoundMAC), Result TLV (Success)
<-中间结果TLV（成功），加密绑定TLV（版本=1 EAP-FAST版本=1，Nonce，CompoundMAC），结果TLV（成功）
Intermediate-Result-TLV (Success), Crypto-Binding TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC), Result-TLV (Success) ->
中间结果TLV（成功），加密绑定TLV（版本=1，EAP-FAST版本=1，Nonce，CompoundMAC），结果TLV（成功）->
// Compound MAC calculated using Keys generated from EAP methods X and Y and the TLS tunnel. Compound Keys generated using Keys generated from EAP methods X and Y; and the TLS tunnel.
//使用EAP方法X和Y以及TLS隧道生成的密钥计算复合MAC。使用EAP方法X和Y生成的密钥生成的复合密钥；以及TLS隧道。
// TLS channel torn down (messages sent in clear text)
//TLS通道中断（以明文发送的消息）
<- EAP-Success
<-EAP成功
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-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello without
PAC-Opaque extension)->
<- EAP-Request/EAP-FAST
(TLS Server Key Exchange,
TLS Server Hello Done)
EAP-Response/EAP-FAST
(TLS Client Key Exchange,
TLS change_cipher_spec,
TLS finished)->
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello without
PAC-Opaque extension)->
<- EAP-Request/EAP-FAST
(TLS Server Key Exchange,
TLS Server Hello Done)
EAP-Response/EAP-FAST
(TLS Client Key Exchange,
TLS change_cipher_spec,
TLS finished)->
<- EAP-Request/EAP-FAST (TLS change_cipher_spec, TLS finished) EAP-Payload-TLV( EAP-Request/Identity))
<-EAP请求/EAP-FAST（TLS更改\u密码\u规范，TLS完成）EAP有效负载TLV（EAP请求/标识））
// TLS channel established (messages sent within the TLS channel)
//TLS通道已建立（在TLS通道内发送的消息）
// First EAP Payload TLV is piggybacked to the TLS Finished as Application Data and protected by the TLS tunnel
//第一个EAP有效载荷TLV作为应用程序数据装载到TLS，并由TLS隧道保护
EAP-Payload TLV
(EAP-Response/Identity) ->
EAP-Payload TLV
(EAP-Response/Identity) ->
<- EAP Payload TLV (EAP-Request/ EAP-MSCHAPV2 (Challenge))
<-EAP有效载荷TLV（EAP请求/EAP-MSCHAPV2（质询））
EAP Payload TLV (EAP-Response/ EAP-MSCHAPV2 (Response)) ->
EAP有效负载TLV（EAP响应/EAP-MSCHAPV2（响应））->
<- EAP Payload TLV (EAP-Request/ EAP-MSCHAPV2 (Success Request))
<-EAP有效载荷TLV（EAP请求/EAP-MSCHAPV2（成功请求））
EAP Payload TLV (EAP-Response/ EAP-MSCHAPV2 (Success Response)) ->
EAP有效负载TLV（EAP响应/EAP-MSCHAPV2（成功响应））->
<- Crypto-Binding TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC), Result TLV (Success)
<-加密绑定TLV（版本=1，EAP-FAST版本=1，Nonce，CompoundMAC），结果TLV（成功）
Result TLV (Failure), Error TLV (Error Code = 2001) ->
结果TLV（失败），错误TLV（错误代码=2001）->
// TLS channel torn down (messages sent in clear text)
//TLS通道中断（以明文发送的消息）
<- EAP-Failure
<-EAP故障
Where EAP-FAST is negotiated, with a sequence of EAP method followed by Vendor-Specific TLV exchange, the conversation will occur as follows:
在协商EAP-FAST时，采用一系列EAP方法，然后进行供应商特定的TLV交换，对话将按如下方式进行：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST (TLS client_hello)-> <- EAP-Request/EAP-FAST (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done)
EAP响应/EAP-FAST（TLS客户端\u hello）-><-EAP请求/EAP-FAST（TLS服务器\u hello，TLS证书，[TLS服务器\u密钥交换，][TLS证书\u请求，]TLS服务器\u hello\u完成）
EAP-Response/EAP-FAST ([TLS certificate,] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished) -> <- EAP-Request/EAP-FAST (TLS change_cipher_spec, TLS finished, EAP-Payload-TLV (EAP-Request/Identity))
EAP响应/EAP-FAST（[TLS证书，]TLS客户端密钥交换，[TLS证书验证，]TLS更改密码规范，TLS完成）-><-EAP请求/EAP-FAST（TLS更改密码规范，TLS完成，EAP有效负载TLV（EAP请求/标识））
// TLS channel established (Subsequent messages sent within the TLS channel, encapsulated within EAP-FAST)
//建立TLS通道（在TLS通道内发送的后续消息，封装在EAP-FAST内）
// First EAP Payload TLV is piggybacked to the TLS Finished as Application Data and protected by the TLS tunnel
//第一个EAP有效载荷TLV作为应用程序数据装载到TLS，并由TLS隧道保护
EAP-Payload-TLV
(EAP-Response/Identity) ->
EAP-Payload-TLV
(EAP-Response/Identity) ->
<- EAP-Payload-TLV (EAP-Request/Method X)
<-EAP有效载荷TLV（EAP请求/方法X）
EAP-Payload-TLV
(EAP-Response/Method X) ->
EAP-Payload-TLV
(EAP-Response/Method X) ->
<- EAP-Payload-TLV (EAP-Request/Method X)
<-EAP有效载荷TLV（EAP请求/方法X）
EAP-Payload-TLV (EAP-Response/Method X)->
EAP有效负载TLV（EAP响应/方法X）->
<- Intermediate Result TLV (Success), Crypto-Binding TLV (Version=1 EAP-FAST Version=1, Nonce, CompoundMAC), Vendor-Specific TLV
<-中间结果TLV（成功），加密绑定TLV（版本=1 EAP-FAST版本=1，Nonce，CompoundMAC），特定于供应商的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 this packet to minimize round-trips.
//供应商特定TLV交换在成功完成之前的方法X后开始。中间结果和加密绑定TLV与此数据包中的供应商特定TLV一起发送，以最小化往返。
// Compound MAC calculated using Keys generated from EAP methods X and the TLS tunnel.
//使用EAP方法X和TLS隧道生成的密钥计算复合MAC。
Intermediate Result TLV (Success), Crypto-Binding TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC), Vendor-Specific TLV ->
中间结果TLV（成功），加密绑定TLV（版本=1，EAP-FAST版本=1，Nonce，CompoundMAC），特定于供应商的TLV->
// Optional additional Vendor-Specific TLV exchanges...
//可选的附加供应商特定TLV交换。。。
<- Vendor-Specific TLV
<-特定于供应商的TLV
Vendor Specific TLV -> <- Result TLV (Success)
供应商特定TLV-><-结果TLV（成功）
Result-TLV (Success) ->
结果TLV（成功）->
// TLS channel torn down (messages sent in clear text)
//TLS通道中断（以明文发送的消息）
<- EAP-Success
<-EAP成功
PAC KEY:
PAC密钥：
0B 97 39 0F 37 51 78 09 81 1E FD 9C 6E 65 94 2B 63 2C E9 53 89 38 08 BA 36 0B 03 7C D1 85 E4 14
0B 97 39 0F 37 51 78 09 81 1E FD 9C 6E 65 94 2B 63 2C E9 53 89 38 08 BA 36 0B 03 7C D1 85 E4 14
Server_hello Random
服务器(随机)
3F FB 11 C4 6C BF A5 7A 54 40 DA E8 22 D3 11 D3 F7 6D E4 1D D9 33 E5 93 70 97 EB A9 B3 66 F4 2A
3F FB 11 C4 6C BF A5 7A 54 40 DA E8 22 D3 11 D3 F7 6D E4 1D D9 33 E5 93 70 97 EB A9 B3 66 F4 2A
Client_hello Random
客户你好随机
00 00 00 02 6A 66 43 2A 8D 14 43 2C EC 58 2D 2F C7 9C 33 64 BA 04 AD 3A 52 54 D6 A5 79 AD 1E 00
00 00 02 6A 66 43 2A 8D 14 43 2C EC 58 2D 2F C7 9C 33 64 BA 04 AD 3A 52 54 D6 A5 79 AD 1E 00
Master_secret = T-PRF(PAC-Key, "PAC to master secret label hash", server_random + Client_random, 48)
Master_secret=T-PRF（PAC密钥，“PAC到Master secret标签散列”，服务器随机+客户端随机，48）
4A 1A 51 2C 01 60 BC 02 3C CF BC 83 3F 03 BC 64 88 C1 31 2F 0B A9 A2 77 16 A8 D8 E8 BD C9 D2 29 38 4B 7A 85 BE 16 4D 27 33 D5 24 79 87 B1 C5 A2
4A 1A 51 2C 01 60 BC 02 3C CF BC 83 3F 03 BC 64 88 C1 31 2F 0B A9 A2 77 A8 D8 E8 BD C9 D2 29 38 4B 85 BE 16 4D 27 33 D5 24 79 87 B1 C5 A2
Key_block = PRF(Master_secret, "key expansion", server_random + Client_random)
密钥块=PRF（主密钥，“密钥扩展”，服务器随机+客户端随机）
59 59 BE 8E 41 3A 77 74 8B B2 E5 D3 60 AC 4D 35 DF FB C8 1E 9C 24 9C 8B 0E C3 1D 72 C8 84 9D 57 48 51 2E 45 97 6C 88 70 BE 5F 01 D3 64 E7 4C BB 11 24 E3 49 E2 3B CD EF 7A B3 05 39 5D 64 8A 44 11 B6 69 88 34 2E 8E 29 D6 4B 7D 72 17 59 28 05 AF F9 B7 FF 66 6D A1 96 8F 0B 5E 06 46 7A 44 84 64 C1 C8 0C 96 44 09 98 FF 92 A8 B4 C6 42 28 71
59 59 BE 8E 41 3A 77 74 8B B2 E5 D3 60 AC 4D 35 DF FB C8 1E 9C 24 9C 8B 0E C3 1D 72 C8 84 9D 57 48 51 2E 45 97 6C 88 70 BE 5F 01 D3 64 E7 4C BB 11 24 E3 49 E2 3B CD EF 7A B3 05 39 5D 64 8A 11 B6 69 88 34 2E 29 D6 4B 7 D 72 59 28 05 AF F9 B7 FF 66 6D A4 96 8F 5E 06 46 7A 44 C4 64 C1 C8 09 FF 42 A71 C6
Session Key Seed
会话密钥种子
D6 4B 7D 72 17 59 28 05 AF F9 B7 FF 66 6D A1 96 8F 0B 5E 06 46 7A 44 84 64 C1 C8 0C 96 44 09 98 FF 92 A8 B4 C6 42 28 71
D6 4B 7D 72 17 59 28 05 AF F9 B7 FF 66 6D A1 96 8F 0B 5E 06 46 7A 44 84 64 C1 C8 0C 96 44 09 98 FF 92 A8 B4 C6 42 28 71
IMCK = T-PRF(SKS, "Inner Methods Compound Keys", ISK, 60)
IMCK=T-PRF（SKS，“内部方法复合键”，ISK，60）
Note: ISK is 32 octets 0's.
注意：ISK是32个八位字节0。
16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80 4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1 18 40 7B 56 BE EA A7 C5 76 5D 8F 0B C5 07 C6 B9 04 D0 69 56 72 8B 6B B8 15 EC 57 7B
16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80 4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1 18 40 7B 56为EA A7 C5 76 5D 8F 0B C5 07 C6 B9 04 D0 69 56 72 8B B8 15 EC 57 7B
[SIMCK 1] 16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80 4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1 18 40 7B 56 BE EA A7 C5
[SIMCK 1]16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80 4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1 18 40 7B 56为EA A7 C5
MSK = T-PRF(S-IMCKn, "Session Key Generating Function", 64);
MSK=T-PRF（S-IMCKn，“会话密钥生成函数”，64）；
4D 83 A9 BE 6F 8A 74 ED 6A 02 66 0A 63 4D 2C 33 C2 DA 60 15 C6 37 04 51 90 38 63 DA 54 3E 14 B9 27 99 18 1E 07 BF 0F 5A 5E 3C 32 93 80 8C 6C 49 67 ED 24 FE 45 40 A0 59 5E 37 C2 E9 D0 5D 0A E3
4D 83 A9 BE 6F 8A 74 ED 6A 02 66 0A 63 4D 2C 33 C2 DA60 15 C6 37 04 51 90 38 DA54 3E 14 B9 27 99 18 1E 07 BF 0F 5A 5E 3C 32 93 80 8C 6C 49 67 ED 24 FE 45 40 A0 59 5E 37 C2 E9 D0 5D 0A E3
EMSK = T-PRF(S-IMCKn, "Extended Session Key Generating Function", 64);
EMSK=T-PRF（S-IMCKn，“扩展会话密钥生成函数”，64）；
3A D4 AB DB 76 B2 7F 3B EA 32 2C 2B 74 F4 28 55 EF 2D BA 78 C9 57 2F 0D 06 CD 51 7C 20 93 98 A9 76 EA 70 21 D7 0E 25 54 97 ED B2 8A F6 ED FD 0A 2A E7 A1 58 90 10 50 44 B3 82 85 DB 06 14 D2 F9
3A D4 AB DB 76 B2 7F 3B EA 32 2C 2B 74 F4 28 55 EF 2D BA 78 C9 57 2F 0D 06 CD 51 7C 20 93 98 A9 76 EA 70 21 D7 0E 25 54 97 ED B2 8A F6 ED FD 0A 2A E7 A1 58 90 10 50 44 B3 82 85 DB 06 14 D2 F9
[Compound MAC Key 1] 76 5D 8F 0B C5 07 C6 B9 04 D0 69 56 72 8B 6B B8 15 EC 57 7B
[复合MAC密钥1]76 5D 8F 0B C5 07 C6 B9 04 D0 69 56 72 8B 6B B8 15 EC 57 7B
[Crypto-Binding TLV] 80 0C 00 38 00 01 01 00 D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE 21 14 4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58 43 24 6E 30 92 17 6D CF E6 E0 69 EB 33 61 6A CC 05 C5 5B B7
[加密绑定TLV]80 0C 00 38 00 01 00 D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE 21 14 4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58 43 24 6E 30 92 17 6D CF E6 E0 69 EB 33 61 6A CC 05 C5 5B B7
[Server Nonce] D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE 21 14 4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58
[服务器当前]D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE 21 14 4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58
[Compound MAC] 43 24 6E 30 92 17 6D CF E6 E0 69 EB 33 61 6A CC 05 C5 5B B7
[化合物MAC]43 24 6E 30 92 17 6D CF E6 E0 69 EB 33 61 6A CC 05 C5 5B B7
Authors' Addresses
作者地址
Nancy Cam-Winget Cisco Systems 3625 Cisco Way San Jose, CA 95134 US
美国加利福尼亚州圣何塞市思科路3625号南希·坎·威吉思科系统公司，邮编95134
EMail: ncamwing@cisco.com
EMail: ncamwing@cisco.com
David McGrew Cisco Systems San Jose, CA 95134 US
美国加利福尼亚州圣何塞市思科系统公司David McGrew 95134
EMail: mcgrew@cisco.com
EMail: mcgrew@cisco.com
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US
美国华盛顿州西雅图第三大道2901号Joseph Salowey Cisco Systems 98121
EMail: jsalowey@cisco.com
EMail: jsalowey@cisco.com
Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US
郝州思科系统4125美国俄亥俄州汉兰达大道里奇菲尔德44286号
EMail: hzhou@cisco.com
EMail: hzhou@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。