Network Working Group B. Aboba
Request for Comments: 3748 Microsoft
Obsoletes: 2284 L. Blunk
Category: Standards Track Merit Network, Inc
J. Vollbrecht
Vollbrecht Consulting LLC
J. Carlson
Sun
H. Levkowetz, Ed.
ipUnplugged
June 2004
Network Working Group B. Aboba
Request for Comments: 3748 Microsoft
Obsoletes: 2284 L. Blunk
Category: Standards Track Merit Network, Inc
J. Vollbrecht
Vollbrecht Consulting LLC
J. Carlson
Sun
H. Levkowetz, Ed.
ipUnplugged
June 2004
Extensible Authentication Protocol (EAP)
可扩展身份验证协议（EAP）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this.
本文档定义了可扩展身份验证协议（EAP），这是一个支持多种身份验证方法的身份验证框架。EAP通常直接在数据链路层上运行，如点对点协议（PPP）或IEEE 802，而不需要IP。EAP为重复消除和重传提供了自己的支持，但依赖于较低层的排序保证。EAP本身不支持碎片化；然而，个别EAP方法可能支持这一点。
This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A.
本文件废除了RFC 2284。附录A中提供了本文件与RFC 2284之间的变更摘要。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . 6
2. Extensible Authentication Protocol (EAP). . . . . . . . . . . 7
2.1. Support for Sequences . . . . . . . . . . . . . . . . . 9
2.2. EAP Multiplexing Model. . . . . . . . . . . . . . . . . 10
2.3. Pass-Through Behavior . . . . . . . . . . . . . . . . . 12
2.4. Peer-to-Peer Operation. . . . . . . . . . . . . . . . . 14
3. Lower Layer Behavior. . . . . . . . . . . . . . . . . . . . . 15
3.1. Lower Layer Requirements. . . . . . . . . . . . . . . . 15
3.2. EAP Usage Within PPP. . . . . . . . . . . . . . . . . . 18
3.2.1. PPP Configuration Option Format. . . . . . . . . 18
3.3. EAP Usage Within IEEE 802 . . . . . . . . . . . . . . . 19
3.4. Lower Layer Indications . . . . . . . . . . . . . . . . 19
4. EAP Packet Format . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Request and Response. . . . . . . . . . . . . . . . . . 21
4.2. Success and Failure . . . . . . . . . . . . . . . . . . 23
4.3. Retransmission Behavior . . . . . . . . . . . . . . . . 26
5. Initial EAP Request/Response Types. . . . . . . . . . . . . . 27
5.1. Identity. . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. Notification. . . . . . . . . . . . . . . . . . . . . . 29
5.3. Nak . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.1. Legacy Nak . . . . . . . . . . . . . . . . . . . 31
5.3.2. Expanded Nak . . . . . . . . . . . . . . . . . . 32
5.4. MD5-Challenge . . . . . . . . . . . . . . . . . . . . . 35
5.5. One-Time Password (OTP) . . . . . . . . . . . . . . . . 36
5.6. Generic Token Card (GTC). . . . . . . . . . . . . . . . 37
5.7. Expanded Types. . . . . . . . . . . . . . . . . . . . . 38
5.8. Experimental. . . . . . . . . . . . . . . . . . . . . . 40
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
6.1. Packet Codes. . . . . . . . . . . . . . . . . . . . . . 41
6.2. Method Types. . . . . . . . . . . . . . . . . . . . . . 41
7. Security Considerations . . . . . . . . . . . . . . . . . . . 42
7.1. Threat Model. . . . . . . . . . . . . . . . . . . . . . 42
7.2. Security Claims . . . . . . . . . . . . . . . . . . . . 43
7.2.1. Security Claims Terminology for EAP Methods. . . 44
7.3. Identity Protection . . . . . . . . . . . . . . . . . . 46
7.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . 47
7.5. Packet Modification Attacks . . . . . . . . . . . . . . 48
7.6. Dictionary Attacks. . . . . . . . . . . . . . . . . . . 49
7.7. Connection to an Untrusted Network. . . . . . . . . . . 49
7.8. Negotiation Attacks . . . . . . . . . . . . . . . . . . 50
7.9. Implementation Idiosyncrasies . . . . . . . . . . . . . 50
7.10. Key Derivation. . . . . . . . . . . . . . . . . . . . . 51
7.11. Weak Ciphersuites . . . . . . . . . . . . . . . . . . . 53
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . 6
2. Extensible Authentication Protocol (EAP). . . . . . . . . . . 7
2.1. Support for Sequences . . . . . . . . . . . . . . . . . 9
2.2. EAP Multiplexing Model. . . . . . . . . . . . . . . . . 10
2.3. Pass-Through Behavior . . . . . . . . . . . . . . . . . 12
2.4. Peer-to-Peer Operation. . . . . . . . . . . . . . . . . 14
3. Lower Layer Behavior. . . . . . . . . . . . . . . . . . . . . 15
3.1. Lower Layer Requirements. . . . . . . . . . . . . . . . 15
3.2. EAP Usage Within PPP. . . . . . . . . . . . . . . . . . 18
3.2.1. PPP Configuration Option Format. . . . . . . . . 18
3.3. EAP Usage Within IEEE 802 . . . . . . . . . . . . . . . 19
3.4. Lower Layer Indications . . . . . . . . . . . . . . . . 19
4. EAP Packet Format . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Request and Response. . . . . . . . . . . . . . . . . . 21
4.2. Success and Failure . . . . . . . . . . . . . . . . . . 23
4.3. Retransmission Behavior . . . . . . . . . . . . . . . . 26
5. Initial EAP Request/Response Types. . . . . . . . . . . . . . 27
5.1. Identity. . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. Notification. . . . . . . . . . . . . . . . . . . . . . 29
5.3. Nak . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.1. Legacy Nak . . . . . . . . . . . . . . . . . . . 31
5.3.2. Expanded Nak . . . . . . . . . . . . . . . . . . 32
5.4. MD5-Challenge . . . . . . . . . . . . . . . . . . . . . 35
5.5. One-Time Password (OTP) . . . . . . . . . . . . . . . . 36
5.6. Generic Token Card (GTC). . . . . . . . . . . . . . . . 37
5.7. Expanded Types. . . . . . . . . . . . . . . . . . . . . 38
5.8. Experimental. . . . . . . . . . . . . . . . . . . . . . 40
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
6.1. Packet Codes. . . . . . . . . . . . . . . . . . . . . . 41
6.2. Method Types. . . . . . . . . . . . . . . . . . . . . . 41
7. Security Considerations . . . . . . . . . . . . . . . . . . . 42
7.1. Threat Model. . . . . . . . . . . . . . . . . . . . . . 42
7.2. Security Claims . . . . . . . . . . . . . . . . . . . . 43
7.2.1. Security Claims Terminology for EAP Methods. . . 44
7.3. Identity Protection . . . . . . . . . . . . . . . . . . 46
7.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . 47
7.5. Packet Modification Attacks . . . . . . . . . . . . . . 48
7.6. Dictionary Attacks. . . . . . . . . . . . . . . . . . . 49
7.7. Connection to an Untrusted Network. . . . . . . . . . . 49
7.8. Negotiation Attacks . . . . . . . . . . . . . . . . . . 50
7.9. Implementation Idiosyncrasies . . . . . . . . . . . . . 50
7.10. Key Derivation. . . . . . . . . . . . . . . . . . . . . 51
7.11. Weak Ciphersuites . . . . . . . . . . . . . . . . . . . 53
7.12. Link Layer. . . . . . . . . . . . . . . . . . . . . . . 53
7.13. Separation of Authenticator and Backend Authentication
Server. . . . . . . . . . . . . . . . . . . . . . . . . 54
7.14. Cleartext Passwords . . . . . . . . . . . . . . . . . . 55
7.15. Channel Binding . . . . . . . . . . . . . . . . . . . . 55
7.16. Protected Result Indications. . . . . . . . . . . . . . 56
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.1. Normative References. . . . . . . . . . . . . . . . . . 59
9.2. Informative References. . . . . . . . . . . . . . . . . 60
Appendix A. Changes from RFC 2284. . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 67
7.12. Link Layer. . . . . . . . . . . . . . . . . . . . . . . 53
7.13. Separation of Authenticator and Backend Authentication
Server. . . . . . . . . . . . . . . . . . . . . . . . . 54
7.14. Cleartext Passwords . . . . . . . . . . . . . . . . . . 55
7.15. Channel Binding . . . . . . . . . . . . . . . . . . . . 55
7.16. Protected Result Indications. . . . . . . . . . . . . . 56
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.1. Normative References. . . . . . . . . . . . . . . . . . 59
9.2. Informative References. . . . . . . . . . . . . . . . . 60
Appendix A. Changes from RFC 2284. . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 67
This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this.
本文档定义了可扩展身份验证协议（EAP），这是一个支持多种身份验证方法的身份验证框架。EAP通常直接在数据链路层上运行，如点对点协议（PPP）或IEEE 802，而不需要IP。EAP为重复消除和重传提供了自己的支持，但依赖于较低层的排序保证。EAP本身不支持碎片化；然而，个别EAP方法可能支持这一点。
EAP may be used on dedicated links, as well as switched circuits, and wired as well as wireless links. To date, EAP has been implemented with hosts and routers that connect via switched circuits or dial-up lines using PPP [RFC1661]. It has also been implemented with switches and access points using IEEE 802 [IEEE-802]. EAP encapsulation on IEEE 802 wired media is described in [IEEE-802.1X], and encapsulation on IEEE wireless LANs in [IEEE-802.11i].
EAP可用于专用链路、交换电路以及有线和无线链路。迄今为止，EAP已经通过使用PPP[RFC1661]通过交换电路或拨号线连接的主机和路由器实现。它还通过使用IEEE 802[IEEE-802]的交换机和接入点实现。[IEEE-802.1X]中描述了IEEE 802有线媒体上的EAP封装，而[IEEE-802.11i]中描述了IEEE无线局域网上的EAP封装。
One of the advantages of the EAP architecture is its flexibility. EAP is used to select a specific authentication mechanism, typically after the authenticator requests more information in order to determine the specific authentication method to be used. Rather than requiring the authenticator to be updated to support each new authentication method, EAP permits the use of a backend authentication server, which may implement some or all authentication methods, with the authenticator acting as a pass-through for some or all methods and peers.
EAP体系结构的优点之一是它的灵活性。EAP用于选择特定的认证机制，通常在认证者请求更多信息以确定要使用的特定认证方法之后。EAP不要求更新认证器以支持每个新的认证方法，而是允许使用后端认证服务器，该服务器可以实现一些或所有认证方法，认证器充当一些或所有方法和对等方的传递。
Within this document, authenticator requirements apply regardless of whether the authenticator is operating as a pass-through or not. Where the requirement is meant to apply to either the authenticator or backend authentication server, depending on where the EAP authentication is terminated, the term "EAP server" will be used.
在本文件中，无论验证器是否作为传递操作，验证器要求均适用。如果要求适用于认证器或后端认证服务器，则根据EAP认证终止的位置，将使用术语“EAP服务器”。
In this document, several words are used to signify the requirements of the specification. 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]中所述进行解释。
This document frequently uses the following terms:
本文件经常使用以下术语：
authenticator The end of the link initiating EAP authentication. The term authenticator is used in [IEEE-802.1X], and has the same meaning in this document.
authenticator发起EAP身份验证的链接的末尾。术语验证器在[IEEE-802.1X]中使用，在本文件中具有相同的含义。
peer The end of the link that responds to the authenticator. In [IEEE-802.1X], this end is known as the Supplicant.
对等响应身份验证器的链接的末端。在[IEEE-802.1X]中，此端称为“请求者”。
Supplicant The end of the link that responds to the authenticator in [IEEE-802.1X]. In this document, this end of the link is called the peer.
在[IEEE-802.1X]中响应身份验证器的链路端。在本文档中，链接的这一端称为对等端。
backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE-802.1X].
后端身份验证服务器后端身份验证服务器是向身份验证者提供身份验证服务的实体。使用时，此服务器通常为身份验证程序执行EAP方法。此术语也在[IEEE-802.1X]中使用。
AAA Authentication, Authorization, and Accounting. AAA protocols with EAP support include RADIUS [RFC3579] and Diameter [DIAM-EAP]. In this document, the terms "AAA server" and "backend authentication server" are used interchangeably.
AAA身份验证、授权和记帐。支持EAP的AAA协议包括RADIUS[RFC3579]和DIAME[DIAME-EAP]。在本文档中，术语“AAA服务器”和“后端身份验证服务器”可以互换使用。
Displayable Message This is interpreted to be a human readable string of characters. The message encoding MUST follow the UTF-8 transformation format [RFC2279].
可显示消息这被解释为人类可读的字符串。消息编码必须遵循UTF-8转换格式[RFC2279]。
EAP server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server.
EAP服务器与对等方终止EAP身份验证方法的实体。在不使用后端身份验证服务器的情况下，EAP服务器是身份验证程序的一部分。在认证器以直通模式操作的情况下，EAP服务器位于后端认证服务器上。
Silently Discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the event, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.
静默丢弃这意味着实现在不进行进一步处理的情况下丢弃数据包。实现应该提供记录事件的能力，包括静默丢弃的数据包的内容，并且应该在统计计数器中记录事件。
Successful Authentication In the context of this document, "successful authentication" is an exchange of EAP messages, as a result of which the authenticator decides to allow access by the peer, and the peer decides to use this access. The authenticator's decision typically involves both authentication and authorization aspects; the peer may successfully authenticate to the authenticator, but access may be denied by the authenticator due to policy reasons.
成功身份验证在本文档的上下文中，“成功身份验证”是EAP消息的交换，其结果是认证者决定允许对等方访问，而对等方决定使用此访问。认证者的决定通常涉及认证和授权两个方面；对等方可以成功地向验证器进行身份验证，但由于策略原因，身份验证器可能会拒绝访问。
Message Integrity Check (MIC) A keyed hash function used for authentication and integrity protection of data. This is usually called a Message Authentication Code (MAC), but IEEE 802 specifications (and this document) use the acronym MIC to avoid confusion with Medium Access Control.
消息完整性检查（MIC）：一种密钥哈希函数，用于数据的身份验证和完整性保护。这通常称为消息认证码（MAC），但IEEE 802规范（以及本文档）使用缩写词MIC，以避免与介质访问控制混淆。
Cryptographic Separation Two keys (x and y) are "cryptographically separate" if an adversary that knows all messages exchanged in the protocol cannot compute x from y or y from x without "breaking" some cryptographic assumption. In particular, this definition allows that the adversary has the knowledge of all nonces sent in cleartext, as well as all predictable counter values used in the protocol. Breaking a cryptographic assumption would typically require inverting a one-way function or predicting the outcome of a cryptographic pseudo-random number generator without knowledge of the secret state. In other words, if the keys are cryptographically separate, there is no shortcut to compute x from y or y from x, but the work an adversary must do to perform this computation is equivalent to performing an exhaustive search for the secret state value.
密码学分离如果知道协议中交换的所有消息的对手在不“打破”某些密码学假设的情况下无法从y计算x或从x计算y，则两个密钥（x和y）是“密码学分离的”。特别是，该定义允许对手了解以明文发送的所有nonce，以及协议中使用的所有可预测计数器值。打破密码假设通常需要反转单向函数或在不知道秘密状态的情况下预测密码伪随机数生成器的结果。换句话说，如果密钥以密码学的方式分开，则没有从y计算x或从x计算y的快捷方式，但对手必须执行此计算的工作相当于对秘密状态值执行穷举搜索。
Master Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 octets in length. In existing implementations, a AAA server acting as an EAP server transports the MSK to the authenticator.
主会话密钥（MSK）是在EAP对等方和服务器之间派生并通过EAP方法导出的密钥材料。MSK的长度至少为64个八位字节。在现有的实现中，充当EAP服务器的AAA服务器将MSK传输到验证器。
Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is not shared with the authenticator or any other third party. The EMSK is reserved for future uses that are not defined yet.
扩展主会话密钥（EMSK）：由EAP方法导出的EAP客户端和服务器之间派生的附加密钥材料。EMSK的长度至少为64个八位字节。EMSK不与认证者或任何其他第三方共享。EMSK保留用于尚未定义的未来用途。
Result indications A method provides result indications if after the method's last message is sent and received:
结果指示如果在发送和接收方法的最后一条消息后：
1) The peer is aware of whether it has authenticated the server, as well as whether the server has authenticated it.
1) 对等方知道它是否对服务器进行了身份验证，以及服务器是否对其进行了身份验证。
2) The server is aware of whether it has authenticated the peer, as well as whether the peer has authenticated it.
2) 服务器知道它是否对对等方进行了身份验证，以及对等方是否对其进行了身份验证。
In the case where successful authentication is sufficient to authorize access, then the peer and authenticator will also know if the other party is willing to provide or accept access. This may not always be the case. An authenticated peer may be denied access due to lack of authorization (e.g., session limit) or other reasons. Since the EAP exchange is run between the peer and the server, other nodes (such as AAA proxies) may also affect the authorization decision. This is discussed in more detail in Section 7.16.
在成功的身份验证足以授权访问的情况下，对等方和身份验证方还将知道另一方是否愿意提供或接受访问。情况可能并非总是如此。由于缺乏授权（例如，会话限制）或其他原因，经过身份验证的对等方可能被拒绝访问。由于EAP交换在对等方和服务器之间运行，其他节点（如AAA代理）也可能影响授权决策。第7.16节对此进行了更详细的讨论。
EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED.
EAP设计用于IP层连接可能不可用的网络访问身份验证。不建议将EAP用于其他目的，如批量数据传输。
Since EAP does not require IP connectivity, it provides just enough support for the reliable transport of authentication protocols, and no more.
由于EAP不需要IP连接，因此它仅为认证协议的可靠传输提供了足够的支持，仅此而已。
EAP is a lock-step protocol which only supports a single packet in flight. As a result, EAP cannot efficiently transport bulk data, unlike transport protocols such as TCP [RFC793] or SCTP [RFC2960].
EAP是一种锁步协议，它只支持飞行中的单个数据包。因此，EAP无法有效地传输大容量数据，这与TCP[RFC793]或SCTP[RFC2960]等传输协议不同。
While EAP provides support for retransmission, it assumes ordering guarantees provided by the lower layer, so out of order reception is not supported.
虽然EAP提供对重传的支持，但它假定由较低层提供订购保证，因此不支持无序接收。
Since EAP does not support fragmentation and reassembly, EAP authentication methods generating payloads larger than the minimum EAP MTU need to provide fragmentation support.
由于EAP不支持碎片和重组，因此产生大于最小EAP MTU的有效负载的EAP身份验证方法需要提供碎片支持。
While authentication methods such as EAP-TLS [RFC2716] provide support for fragmentation and reassembly, the EAP methods defined in this document do not. As a result, if the EAP packet size exceeds the EAP MTU of the link, these methods will encounter difficulties.
虽然EAP-TLS[RFC2716]等身份验证方法提供了对碎片和重组的支持，但本文档中定义的EAP方法并不支持。因此，如果EAP数据包大小超过链路的EAP MTU，这些方法将遇到困难。
EAP authentication is initiated by the server (authenticator), whereas many authentication protocols are initiated by the client (peer). As a result, it may be necessary for an authentication algorithm to add one or two additional messages (at most one roundtrip) in order to run over EAP.
EAP身份验证由服务器（验证器）启动，而许多身份验证协议由客户端（对等方）启动。因此，身份验证算法可能需要添加一个或两个附加消息（最多一个往返）以在EAP上运行。
Where certificate-based authentication is supported, the number of additional roundtrips may be much larger due to fragmentation of certificate chains. In general, a fragmented EAP packet will require as many round-trips to send as there are fragments. For example, a certificate chain 14960 octets in size would require ten round-trips to send with a 1496 octet EAP MTU.
在支持基于证书的身份验证的情况下，由于证书链的碎片化，额外的往返次数可能会大得多。一般来说，一个支离破碎的EAP数据包将需要尽可能多的往返发送。例如，大小为14960个八位字节的证书链需要十次往返才能使用1496个八位字节的EAP MTU发送。
Where EAP runs over a lower layer in which significant packet loss is experienced, or where the connection between the authenticator and authentication server experiences significant packet loss, EAP methods requiring many round-trips can experience difficulties. In these situations, use of EAP methods with fewer roundtrips is advisable.
当EAP运行在经历了显著分组丢失的较低层上时，或者当认证器和认证服务器之间的连接经历了显著分组丢失时，需要多次往返的EAP方法可能会遇到困难。在这些情况下，建议使用往返次数较少的EAP方法。
The EAP authentication exchange proceeds as follows:
EAP身份验证交换过程如下：
[1] The authenticator sends a Request to authenticate the peer. The Request has a Type field to indicate what is being requested. Examples of Request Types include Identity, MD5-challenge, etc. The MD5-challenge Type corresponds closely to the CHAP authentication protocol [RFC1994]. Typically, the authenticator will send an initial Identity Request; however, an initial Identity Request is not required, and MAY be bypassed. For example, the identity may not be required where it is determined by the port to which the peer has connected (leased lines,
[1] 身份验证器发送一个请求以对对等方进行身份验证。请求有一个类型字段，用于指示请求的内容。请求类型的示例包括标识、MD5质询等。MD5质询类型与CHAP身份验证协议[RFC1994]密切对应。通常，认证器将发送初始身份请求；但是，不需要初始身份请求，可以绕过该请求。例如，如果标识由对等方连接的端口（租用线路）确定，则可能不需要标识，
dedicated switch or dial-up ports), or where the identity is obtained in another fashion (via calling station identity or MAC address, in the Name field of the MD5-Challenge Response, etc.).
专用交换机或拨号端口），或者以另一种方式获得身份（通过呼叫站身份或MAC地址，在MD5质询响应的名称字段中，等等）。
[2] The peer sends a Response packet in reply to a valid Request. As with the Request packet, the Response packet contains a Type field, which corresponds to the Type field of the Request.
[2] 对等方发送一个响应包来响应一个有效的请求。与请求数据包一样，响应数据包包含一个类型字段，该字段对应于请求的类型字段。
[3] The authenticator sends an additional Request packet, and the peer replies with a Response. The sequence of Requests and Responses continues as long as needed. EAP is a 'lock step' protocol, so that other than the initial Request, a new Request cannot be sent prior to receiving a valid Response. The authenticator is responsible for retransmitting requests as described in Section 4.1. After a suitable number of retransmissions, the authenticator SHOULD end the EAP conversation. The authenticator MUST NOT send a Success or Failure packet when retransmitting or when it fails to get a response from the peer.
[3] 验证器发送一个额外的请求包，对等方回复一个响应。请求和响应的顺序会根据需要持续多久。EAP是一种“锁定步骤”协议，因此除了初始请求之外，在接收到有效响应之前不能发送新请求。认证者负责重新传输第4.1节所述的请求。在适当次数的重新传输之后，认证者应结束EAP对话。当重新传输或无法从对等方获得响应时，身份验证程序不得发送成功或失败数据包。
[4] The conversation continues until the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests), in which case the authenticator implementation MUST transmit an EAP Failure (Code 4). Alternatively, the authentication conversation can continue until the authenticator determines that successful authentication has occurred, in which case the authenticator MUST transmit an EAP Success (Code 3).
[4] 对话将继续，直到验证器无法对对等方进行身份验证（对一个或多个请求的不可接受响应），在这种情况下，验证器实现必须传输EAP故障（代码4）。或者，认证对话可以继续，直到认证者确定已成功进行认证，在这种情况下，认证者必须发送EAP成功（代码3）。
Advantages:
优势：
o The EAP protocol can support multiple authentication mechanisms without having to pre-negotiate a particular one.
o EAP协议可以支持多种认证机制，而无需预先协商特定的认证机制。
o Network Access Server (NAS) devices (e.g., a switch or access point) do not have to understand each authentication method and MAY act as a pass-through agent for a backend authentication server. Support for pass-through is optional. An authenticator MAY authenticate local peers, while at the same time acting as a pass-through for non-local peers and authentication methods it does not implement locally.
o 网络访问服务器（NAS）设备（例如，交换机或接入点）不必了解每种身份验证方法，并且可以充当后端身份验证服务器的传递代理。对传递的支持是可选的。身份验证器可以对本地对等点进行身份验证，同时充当非本地对等点和它不在本地实现的身份验证方法的传递。
o Separation of the authenticator from the backend authentication server simplifies credentials management and policy decision making.
o 将身份验证程序与后端身份验证服务器分离简化了凭据管理和策略决策。
Disadvantages:
缺点：
o For use in PPP, EAP requires the addition of a new authentication Type to PPP LCP and thus PPP implementations will need to be modified to use it. It also strays from the previous PPP authentication model of negotiating a specific authentication mechanism during LCP. Similarly, switch or access point implementations need to support [IEEE-802.1X] in order to use EAP.
o 为了在PPP中使用，EAP需要在PPP LCP中添加新的身份验证类型，因此需要修改PPP实现以使用它。它还偏离了以前的PPP认证模型，即在LCP期间协商特定的认证机制。类似地，交换机或接入点实现需要支持[IEEE-802.1X]才能使用EAP。
o Where the authenticator is separate from the backend authentication server, this complicates the security analysis and, if needed, key distribution.
o 如果验证器与后端身份验证服务器分离，这会使安全分析和密钥分发（如果需要）变得复杂。
An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However, the peer and authenticator MUST utilize only one authentication method (Type 4 or greater) within an EAP conversation, after which the authenticator MUST send a Success or Failure packet.
EAP对话可以使用一系列方法。这方面的一个常见示例是一个身份请求，后跟一个EAP身份验证方法，如MD5质询。但是，对等方和身份验证方必须在EAP对话中仅使用一种身份验证方法（类型4或更高），然后身份验证方必须发送成功或失败数据包。
Once a peer has sent a Response of the same Type as the initial Request, an authenticator MUST NOT send a Request of a different Type prior to completion of the final round of a given method (with the exception of a Notification-Request) and MUST NOT send a Request for an additional method of any Type after completion of the initial authentication method; a peer receiving such Requests MUST treat them as invalid, and silently discard them. As a result, Identity Requery is not supported.
一旦对等方发送了与初始请求相同类型的响应，在完成给定方法的最后一轮之前，验证器不得发送不同类型的请求（通知请求除外）并且在初始认证方法完成后，不得发送任何类型的附加方法的请求；接收此类请求的对等方必须将它们视为无效，并默默地丢弃它们。因此，不支持身份重新查询。
A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request after an initial non-Nak Response has been sent. Since spoofed EAP Request packets may be sent by an attacker, an authenticator receiving an unexpected Nak SHOULD discard it and log the event.
在发送初始非Nak响应后，对等方不得发送Nak（遗留或扩展）以响应请求。由于攻击者可能发送伪造的EAP请求数据包，因此接收到意外Nak的身份验证程序应丢弃该数据包并记录该事件。
Multiple authentication methods within an EAP conversation are not supported due to their vulnerability to man-in-the-middle attacks (see Section 7.4) and incompatibility with existing implementations.
EAP对话中的多种身份验证方法不受支持，因为它们容易受到中间人攻击（参见第7.4节），并且与现有实现不兼容。
Where a single EAP authentication method is utilized, but other methods are run within it (a "tunneled" method), the prohibition against multiple authentication methods does not apply. Such "tunneled" methods appear as a single authentication method to EAP. Backward compatibility can be provided, since a peer not supporting a "tunneled" method can reply to the initial EAP-Request with a Nak
如果使用单个EAP身份验证方法，但在其中运行其他方法（“隧道”方法），则禁止使用多个身份验证方法不适用。这种“隧道式”方法似乎是EAP的单一身份验证方法。可以提供向后兼容性，因为不支持“隧道”方法的对等方可以使用Nak回复初始EAP请求
(legacy or expanded). To address security vulnerabilities, "tunneled" methods MUST support protection against man-in-the-middle attacks.
（遗留的或扩展的）。为了解决安全漏洞，“隧道式”方法必须支持对中间人攻击的保护。
Conceptually, EAP implementations consist of the following components:
从概念上讲，EAP实施由以下组件组成：
[a] Lower layer. The lower layer is responsible for transmitting and receiving EAP frames between the peer and authenticator. EAP has been run over a variety of lower layers including PPP, wired IEEE 802 LANs [IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11], UDP (L2TP [RFC2661] and IKEv2 [IKEv2]), and TCP [PIC]. Lower layer behavior is discussed in Section 3.
[a] 下层。下层负责在对等方和认证方之间发送和接收EAP帧。EAP已在各种较低层上运行，包括PPP、有线IEEE 802局域网[IEEE-802.1X]、IEEE 802.11无线局域网[IEEE-802.11]、UDP（L2TP[RFC2661]和IKEv2[IKEv2]）和TCP[PIC]。第3节讨论了下层行为。
[b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements duplicate detection and retransmission, and delivers and receives EAP messages to and from the EAP peer and authenticator layers.
[b] EAP层。EAP层通过较低层接收和发送EAP分组，实现重复检测和重传，并向EAP对等层和认证器层发送和接收EAP消息。
[c] EAP peer and authenticator layers. Based on the Code field, the EAP layer demultiplexes incoming EAP packets to the EAP peer and authenticator layers. Typically, an EAP implementation on a given host will support either peer or authenticator functionality, but it is possible for a host to act as both an EAP peer and authenticator. In such an implementation both EAP peer and authenticator layers will be present.
[c] EAP对等和身份验证层。基于代码字段，EAP层将传入的EAP数据包解复用到EAP对等层和认证器层。通常，给定主机上的EAP实现将支持对等或身份验证程序功能，但主机可以同时充当EAP对等和身份验证程序。在这种实现中，将同时存在EAP对等层和认证器层。
[d] EAP method layers. EAP methods implement the authentication algorithms and receive and transmit EAP messages via the EAP peer and authenticator layers. Since fragmentation support is not provided by EAP itself, this is the responsibility of EAP methods, which are discussed in Section 5.
[d] EAP方法层。EAP方法实现认证算法，并通过EAP对等层和认证器层接收和发送EAP消息。由于EAP本身不提供碎片支持，这是EAP方法的责任，第5节将对此进行讨论。
The EAP multiplexing model is illustrated in Figure 1 below. Note that there is no requirement that an implementation conform to this model, as long as the on-the-wire behavior is consistent with it.
EAP多路复用模型如下图1所示。请注意，只要在线行为与此模型一致，就不要求实现符合此模型。
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| EAP method| EAP method| | EAP method| EAP method|
| Type = X | Type = Y | | Type = X | Type = Y |
| V | | | ^ | |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| EAP ! Peer layer | | EAP ! Auth. layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| EAP ! layer | | EAP ! layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| Lower ! layer | | Lower ! layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
! !
! Peer ! Authenticator
+------------>-------------+
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| EAP method| EAP method| | EAP method| EAP method|
| Type = X | Type = Y | | Type = X | Type = Y |
| V | | | ^ | |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| EAP ! Peer layer | | EAP ! Auth. layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| EAP ! layer | | EAP ! layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| Lower ! layer | | Lower ! layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
! !
! Peer ! Authenticator
+------------>-------------+
Figure 1: EAP Multiplexing Model
图1:EAP多路复用模型
Within EAP, the Code field functions much like a protocol number in IP. It is assumed that the EAP layer demultiplexes incoming EAP packets according to the Code field. Received EAP packets with Code=1 (Request), 3 (Success), and 4 (Failure) are delivered by the EAP layer to the EAP peer layer, if implemented. EAP packets with Code=2 (Response) are delivered to the EAP authenticator layer, if implemented.
在EAP中，代码字段的功能非常类似于IP中的协议号。假设EAP层根据代码字段对传入的EAP分组进行解复用。接收到的代码为1（请求）、3（成功）和4（失败）的EAP数据包由EAP层发送到EAP对等层（如果实现）。代码为2（响应）的EAP数据包被传送到EAP认证器层（如果实现）。
Within EAP, the Type field functions much like a port number in UDP or TCP. It is assumed that the EAP peer and authenticator layers demultiplex incoming EAP packets according to their Type, and deliver them only to the EAP method corresponding to that Type. An EAP method implementation on a host may register to receive packets from the peer or authenticator layers, or both, depending on which role(s) it supports.
在EAP中，类型字段的功能非常类似于UDP或TCP中的端口号。假设EAP对等层和认证器层根据传入EAP数据包的类型对其进行解复用，并仅将其传送到对应于该类型的EAP方法。主机上的EAP方法实现可注册以接收来自对等层或认证器层或两者的数据包，具体取决于其支持的角色。
Since EAP authentication methods may wish to access the Identity, implementations SHOULD make the Identity Request and Response accessible to authentication methods (Types 4 or greater), in addition to the Identity method. The Identity Type is discussed in Section 5.1.
由于EAP身份验证方法可能希望访问身份，因此除了身份验证方法外，实现还应使身份验证方法（类型4或更高）可以访问身份请求和响应。第5.1节讨论了标识类型。
A Notification Response is only used as confirmation that the peer received the Notification Request, not that it has processed it, or displayed the message to the user. It cannot be assumed that the contents of the Notification Request or Response are available to another method. The Notification Type is discussed in Section 5.2.
通知响应仅用于确认对等方已收到通知请求，而不是确认对等方已对其进行处理，或向用户显示消息。不能假定通知请求或响应的内容可用于其他方法。第5.2节讨论了通知类型。
Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes of method negotiation. Peers respond to an initial EAP Request for an unacceptable Type with a Nak Response (Type 3) or Expanded Nak Response (Type 254). It cannot be assumed that the contents of the Nak Response(s) are available to another method. The Nak Type(s) are discussed in Section 5.3.
Nak（类型3）或扩展Nak（类型254）用于方法协商。对等方使用Nak响应（类型3）或扩展Nak响应（类型254）对不可接受类型的初始EAP请求进行响应。不能假设Nak响应的内容可用于其他方法。第5.3节讨论了Nak类型。
EAP packets with Codes of Success or Failure do not include a Type field, and are not delivered to an EAP method. Success and Failure are discussed in Section 4.2.
带有成功或失败代码的EAP数据包不包含类型字段，并且不会传递给EAP方法。第4.2节讨论了成功与失败。
Given these considerations, the Success, Failure, Nak Response(s), and Notification Request/Response messages MUST NOT be used to carry data destined for delivery to other EAP methods.
考虑到这些因素，不得使用成功、失败、Nak响应和通知请求/响应消息来携带要传递给其他EAP方法的数据。
When operating as a "pass-through authenticator", an authenticator performs checks on the Code, Identifier, and Length fields as described in Section 4.1. It forwards EAP packets received from the peer and destined to its authenticator layer to the backend authentication server; packets received from the backend authentication server destined to the peer are forwarded to it.
当作为“直通式验证器”运行时，验证器对代码、标识符和长度字段进行检查，如第4.1节所述。它将从对等方接收并发送到其认证器层的EAP数据包转发到后端认证服务器；从后端身份验证服务器接收到的数据包将转发给对等方。
A host receiving an EAP packet may only do one of three things with it: act on it, drop it, or forward it. The forwarding decision is typically based only on examination of the Code, Identifier, and Length fields. A pass-through authenticator implementation MUST be capable of forwarding EAP packets received from the peer with Code=2 (Response) to the backend authentication server. It also MUST be capable of receiving EAP packets from the backend authentication server and forwarding EAP packets of Code=1 (Request), Code=3 (Success), and Code=4 (Failure) to the peer.
接收EAP数据包的主机只能对其执行三种操作之一：对其进行操作、丢弃或转发。转发决策通常仅基于对代码、标识符和长度字段的检查。直通身份验证程序实现必须能够将从对等方接收的代码为2（响应）的EAP数据包转发到后端身份验证服务器。它还必须能够从后端身份验证服务器接收EAP数据包，并将代码=1（请求）、代码=3（成功）和代码=4（失败）的EAP数据包转发给对等方。
Unless the authenticator implements one or more authentication methods locally which support the authenticator role, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision. Where the authenticator supports local authentication methods, it MAY examine the Type field to determine whether to act on the packet itself or forward it. Compliant pass-through authenticator implementations MUST by default forward EAP packets of any Type.
除非验证器在本地实现一个或多个支持验证器角色的身份验证方法，否则EAP方法层头字段（类型、类型数据）不会作为转发决策的一部分进行检查。在认证器支持本地认证方法的情况下，它可以检查类型字段以确定是对数据包本身采取行动还是转发数据包。默认情况下，兼容的直通身份验证程序实现必须转发任何类型的EAP数据包。
EAP packets received with Code=1 (Request), Code=3 (Success), and Code=4 (Failure) are demultiplexed by the EAP layer and delivered to the peer layer. Therefore, unless a host implements an EAP peer layer, these packets will be silently discarded. Similarly, EAP packets received with Code=2 (Response) are demultiplexed by the EAP layer and delivered to the authenticator layer. Therefore, unless a host implements an EAP authenticator layer, these packets will be silently discarded. The behavior of a "pass-through peer" is undefined within this specification, and is unsupported by AAA protocols such as RADIUS [RFC3579] and Diameter [DIAM-EAP].
接收到的代码为1（请求）、代码为3（成功）和代码为4（失败）的EAP数据包由EAP层解复用并传送到对等层。因此，除非主机实现EAP对等层，否则这些数据包将被静默丢弃。类似地，通过代码=2（响应）接收的EAP分组由EAP层解复用并传送到认证器层。因此，除非主机实现EAP认证器层，否则这些数据包将被静默丢弃。本规范中未定义“直通对等机”的行为，AAA协议（如RADIUS[RFC3579]和DIAME[DIAME-EAP]）不支持该行为。
The forwarding model is illustrated in Figure 2.
转发模型如图2所示。
Peer Pass-through Authenticator Authentication Server
对等传递身份验证服务器
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
|EAP method | |EAP method |
| V | | ^ |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | |EAP | EAP | | | ! |
| ! | |Peer | Auth.| EAP Auth. | | ! |
|EAP ! peer| | | +-----------+ | |EAP !Auth.|
| ! | | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|EAP !layer| | EAP !layer| EAP !layer | |EAP !layer|
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP |
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
! ! ! !
! ! ! !
+-------->--------+ +--------->-------+
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
|EAP method | |EAP method |
| V | | ^ |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | |EAP | EAP | | | ! |
| ! | |Peer | Auth.| EAP Auth. | | ! |
|EAP ! peer| | | +-----------+ | |EAP !Auth.|
| ! | | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|EAP !layer| | EAP !layer| EAP !layer | |EAP !layer|
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP |
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
! ! ! !
! ! ! !
+-------->--------+ +--------->-------+
Figure 2: Pass-through Authenticator
图2：直通式验证器
For sessions in which the authenticator acts as a pass-through, it MUST determine the outcome of the authentication solely based on the Accept/Reject indication sent by the backend authentication server; the outcome MUST NOT be determined by the contents of an EAP packet sent along with the Accept/Reject indication, or the absence of such an encapsulated EAP packet.
对于身份验证程序充当传递的会话，它必须仅基于后端身份验证服务器发送的接受/拒绝指示来确定身份验证的结果；结果不得由随接受/拒绝指示一起发送的EAP数据包的内容或不存在此类封装的EAP数据包来确定。
Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction (depending on the capabilities of the lower layer). Both ends of the link may act as authenticators and peers at the same time. In this case, it is necessary for both ends to implement EAP authenticator and peer layers. In addition, the EAP method implementations on both peers must support both authenticator and peer functionality.
由于EAP是一种对等协议，独立和同时的身份验证可能在相反的方向上进行（取决于较低层的能力）。链路的两端可以同时充当验证器和对等方。在这种情况下，两端都需要实现EAP认证器和对等层。此外，两个对等方上的EAP方法实现必须同时支持身份验证程序和对等方功能。
Although EAP supports peer-to-peer operation, some EAP implementations, methods, AAA protocols, and link layers may not support this. Some EAP methods may support asymmetric authentication, with one type of credential being required for the peer and another type for the authenticator. Hosts supporting peer-to-peer operation with such a method would need to be provisioned with both types of credentials.
尽管EAP支持对等操作，但某些EAP实现、方法、AAA协议和链路层可能不支持这种操作。一些EAP方法可能支持非对称身份验证，对等方需要一种类型的凭证，验证器需要另一种类型的凭证。使用这种方法支持对等操作的主机需要使用这两种类型的凭据进行配置。
For example, EAP-TLS [RFC2716] is a client-server protocol in which distinct certificate profiles are typically utilized for the client and server. This implies that a host supporting peer-to-peer authentication with EAP-TLS would need to implement both the EAP peer and authenticator layers, support both peer and authenticator roles in the EAP-TLS implementation, and provision certificates appropriate for each role.
例如，EAP-TLS[RFC2716]是一种客户机-服务器协议，其中不同的证书配置文件通常用于客户机和服务器。这意味着使用EAP-TLS支持对等身份验证的主机需要实现EAP对等和身份验证程序层，在EAP-TLS实现中支持对等和身份验证程序角色，并提供适合每个角色的证书。
AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DIAM-EAP] only support "pass-through authenticator" operation. As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access-Request encapsulating an EAP-Request, Success, or Failure packet with an Access-Reject. There is therefore no support for "pass-through peer" operation.
AAA协议，如RADIUS/EAP[RFC3579]和Diameter EAP[DIAME-EAP]仅支持“直通认证器”操作。如[RFC3579]第2.6.2节所述，RADIUS服务器响应访问请求，该请求封装了EAP请求、成功或失败数据包，并带有访问拒绝。因此，不支持“通过对等”操作。
Even where a method is used which supports mutual authentication and result indications, several considerations may dictate that two EAP authentications (one in each direction) are required. These include:
即使使用了支持相互认证和结果指示的方法，也可能需要考虑两个EAP认证（每个方向一个）。这些措施包括：
[1] Support for bi-directional session key derivation in the lower layer. Lower layers such as IEEE 802.11 may only support uni-directional derivation and transport of transient session keys. For example, the group-key handshake defined in [IEEE-802.11i] is uni-directional, since in IEEE 802.11 infrastructure mode, only the Access Point (AP) sends multicast/broadcast traffic. In IEEE 802.11 ad hoc mode, where either peer may send multicast/broadcast traffic, two uni-directional group-key
[1] 在底层支持双向会话密钥派生。较低层（如IEEE 802.11）可能仅支持瞬时会话密钥的单向派生和传输。例如，[IEEE-802.11i]中定义的组密钥握手是单向的，因为在IEEE 802.11基础设施模式中，只有接入点（AP）发送多播/广播流量。在IEEE 802.11 ad hoc模式中，任何一个对等方都可以发送多播/广播流量，两个单向组密钥
exchanges are required. Due to limitations of the design, this also implies the need for unicast key derivations and EAP method exchanges to occur in each direction.
交换是必需的。由于设计的限制，这也意味着需要在每个方向上进行单播密钥派生和EAP方法交换。
[2] Support for tie-breaking in the lower layer. Lower layers such as IEEE 802.11 ad hoc do not support "tie breaking" wherein two hosts initiating authentication with each other will only go forward with a single authentication. This implies that even if 802.11 were to support a bi-directional group-key handshake, then two authentications, one in each direction, might still occur.
[2] 在下层为断开连接提供支撑。较低的层（如IEEE 802.11 ad hoc）不支持“断开连接”，其中两台主机彼此启动身份验证，但只进行一次身份验证。这意味着，即使802.11支持双向组密钥握手，也可能会发生两次身份验证，每个方向一次。
[3] Peer policy satisfaction. EAP methods may support result indications, enabling the peer to indicate to the EAP server within the method that it successfully authenticated the EAP server, as well as for the server to indicate that it has authenticated the peer. However, a pass-through authenticator will not be aware that the peer has accepted the credentials offered by the EAP server, unless this information is provided to the authenticator via the AAA protocol. The authenticator SHOULD interpret the receipt of a key attribute within an Accept packet as an indication that the peer has successfully authenticated the server.
[3] 同伴政策满意度。EAP方法可支持结果指示，使对等方能够向方法内的EAP服务器指示其已成功认证EAP服务器，并使服务器指示其已认证对等方。但是，除非通过AAA协议将此信息提供给认证者，否则直通认证者不会意识到对等方已接受EAP服务器提供的凭据。身份验证器应将接收到的Accept数据包中的密钥属性解释为对等方已成功对服务器进行身份验证的指示。
However, it is possible that the EAP peer's access policy was not satisfied during the initial EAP exchange, even though mutual authentication occurred. For example, the EAP authenticator may not have demonstrated authorization to act in both peer and authenticator roles. As a result, the peer may require an additional authentication in the reverse direction, even if the peer provided an indication that the EAP server had successfully authenticated to it.
然而，在初始EAP交换期间，EAP对等方的访问策略可能未得到满足，即使发生了相互认证。例如，EAP验证器可能未证明有权同时在对等角色和验证器角色中进行操作。结果，对等方可能需要反向的附加认证，即使对等方提供了EAP服务器已成功向其认证的指示。
EAP makes the following assumptions about lower layers:
EAP对下层做出以下假设：
[1] Unreliable transport. In EAP, the authenticator retransmits Requests that have not yet received Responses so that EAP does not assume that lower layers are reliable. Since EAP defines its own retransmission behavior, it is possible (though undesirable) for retransmission to occur both in the lower layer and the EAP layer when EAP is run over a reliable lower layer.
[1] 不可靠的运输。在EAP中，认证器重新传输尚未收到响应的请求，以便EAP不认为较低层是可靠的。由于EAP定义了其自身的重传行为，因此当EAP在可靠的较低层上运行时，重传可能（尽管不希望）发生在较低层和EAP层中。
Note that EAP Success and Failure packets are not retransmitted. Without a reliable lower layer, and with a non-negligible error rate, these packets can be lost, resulting in timeouts. It is therefore desirable for implementations to improve their resilience to loss of EAP Success or Failure packets, as described in Section 4.2.
请注意，EAP成功和失败数据包不会重新传输。如果没有可靠的下层，并且错误率不可忽略，这些数据包可能会丢失，从而导致超时。因此，如第4.2节所述，实现需要提高其对EAP成功或失败数据包丢失的恢复能力。
[2] Lower layer error detection. While EAP does not assume that the lower layer is reliable, it does rely on lower layer error detection (e.g., CRC, Checksum, MIC, etc.). EAP methods may not include a MIC, or if they do, it may not be computed over all the fields in the EAP packet, such as the Code, Identifier, Length, or Type fields. As a result, without lower layer error detection, undetected errors could creep into the EAP layer or EAP method layer header fields, resulting in authentication failures.
[2] 低层错误检测。虽然EAP并不认为较低层是可靠的，但它确实依赖于较低层的错误检测（例如，CRC、校验和、MIC等）。EAP方法可能不包括MIC，或者如果它们包括MIC，则可能不会对EAP数据包中的所有字段（例如代码、标识符、长度或类型字段）进行计算。因此，如果没有下层错误检测，未检测到的错误可能会潜入EAP层或EAP方法层头字段，从而导致身份验证失败。
For example, EAP TLS [RFC2716], which computes its MIC over the Type-Data field only, regards MIC validation failures as a fatal error. Without lower layer error detection, this method, and others like it, will not perform reliably.
例如，EAP TLS[RFC2716]仅通过类型数据字段计算其MIC，将MIC验证失败视为致命错误。如果没有低层错误检测，这种方法和其他类似方法将无法可靠地执行。
[3] Lower layer security. EAP does not require lower layers to provide security services such as per-packet confidentiality, authentication, integrity, and replay protection. However, where these security services are available, EAP methods supporting Key Derivation (see Section 7.2.1) can be used to provide dynamic keying material. This makes it possible to bind the EAP authentication to subsequent data and protect against data modification, spoofing, or replay. See Section 7.1 for details.
[3] 低层安全。EAP不需要较低层来提供安全服务，如每包机密性、身份验证、完整性和重播保护。然而，在这些安全服务可用的情况下，支持密钥派生的EAP方法（见第7.2.1节）可用于提供动态密钥材料。这使得将EAP身份验证绑定到后续数据并防止数据修改、欺骗或重播成为可能。详见第7.1节。
[4] Minimum MTU. EAP is capable of functioning on lower layers that provide an EAP MTU size of 1020 octets or greater.
[4] 最小MTU。EAP能够在提供1020个八位字节或更大EAP MTU大小的较低层上运行。
EAP does not support path MTU discovery, and fragmentation and reassembly is not supported by EAP, nor by the methods defined in this specification: Identity (1), Notification (2), Nak Response (3), MD5-Challenge (4), One Time Password (5), Generic Token Card (6), and expanded Nak Response (254) Types.
EAP不支持路径MTU发现，EAP和本规范中定义的方法不支持碎片和重组：标识（1）、通知（2）、Nak响应（3）、MD5质询（4）、一次性密码（5）、通用令牌卡（6）和扩展Nak响应（254）类型。
Typically, the EAP peer obtains information on the EAP MTU from the lower layers and sets the EAP frame size to an appropriate value. Where the authenticator operates in pass-through mode, the authentication server does not have a direct way of determining the EAP MTU, and therefore relies on the authenticator to provide it with this information, such as via the Framed-MTU attribute, as described in [RFC3579], Section 2.4.
通常，EAP对等方从较低层获取关于EAP MTU的信息，并将EAP帧大小设置为适当的值。在认证器以直通模式运行的情况下，认证服务器没有确定EAP MTU的直接方法，因此依赖认证器向其提供此信息，如[RFC3579]第2.4节所述，例如通过帧MTU属性。
While methods such as EAP-TLS [RFC2716] support fragmentation and reassembly, EAP methods originally designed for use within PPP where a 1500 octet MTU is guaranteed for control frames (see [RFC1661], Section 6.1) may lack fragmentation and reassembly features.
虽然EAP-TLS[RFC2716]等方法支持分段和重新组装，但最初设计用于PPP的EAP方法可能缺少分段和重新组装功能，在PPP中，1500八位组MTU可保证用于控制帧（见[RFC1661]，第6.1节）。
EAP methods can assume a minimum EAP MTU of 1020 octets in the absence of other information. EAP methods SHOULD include support for fragmentation and reassembly if their payloads can be larger than this minimum EAP MTU.
在没有其他信息的情况下，EAP方法可以假定最小EAP MTU为1020个八位字节。EAP方法应包括对碎片和重新组装的支持，前提是其有效载荷可能大于此最小EAP MTU。
EAP is a lock-step protocol, which implies a certain inefficiency when handling fragmentation and reassembly. Therefore, if the lower layer supports fragmentation and reassembly (such as where EAP is transported over IP), it may be preferable for fragmentation and reassembly to occur in the lower layer rather than in EAP. This can be accomplished by providing an artificially large EAP MTU to EAP, causing fragmentation and reassembly to be handled within the lower layer.
EAP是一种锁步协议，这意味着在处理碎片和重新组装时存在一定的低效性。因此，如果较低层支持分段和重新组装（例如，在通过IP传输EAP的情况下），分段和重新组装最好发生在较低层而不是EAP中。这可以通过向EAP提供一个人工大的EAP MTU来实现，从而在较低层内处理碎片和重新组装。
[5] Possible duplication. Where the lower layer is reliable, it will provide the EAP layer with a non-duplicated stream of packets. However, while it is desirable that lower layers provide for non-duplication, this is not a requirement. The Identifier field provides both the peer and authenticator with the ability to detect duplicates.
[5] 可能重复。在较低层可靠的情况下，它将向EAP层提供不重复的数据包流。然而，虽然较低的层提供不重复是可取的，但这不是一个要求。标识符字段为对等方和身份验证方提供了检测重复项的能力。
[6] Ordering guarantees. EAP does not require the Identifier to be monotonically increasing, and so is reliant on lower layer ordering guarantees for correct operation. EAP was originally defined to run on PPP, and [RFC1661] Section 1 has an ordering requirement:
[6] 订购保证。EAP不要求标识符是单调递增的，因此它依赖于较低层的排序保证来实现正确的操作。EAP最初定义为在PPP上运行，[RFC1661]第1节有一项订购要求：
"The Point-to-Point Protocol is designed for simple links which transport packets between two peers. These links provide full-duplex simultaneous bi-directional operation, and are assumed to deliver packets in order."
点对点协议是为在两个对等点之间传输数据包的简单链路而设计的。这些链路提供全双工同时双向操作，并假定按顺序传送数据包
Lower layer transports for EAP MUST preserve ordering between a source and destination at a given priority level (the ordering guarantee provided by [IEEE-802]).
EAP的较低层传输必须以给定的优先级（由[IEEE-802]提供的排序保证）保持源和目标之间的排序。
Reordering, if it occurs, will typically result in an EAP authentication failure, causing EAP authentication to be re-run. In an environment in which reordering is likely, it is therefore expected that EAP authentication failures will be common. It is RECOMMENDED that EAP only be run over lower layers that provide ordering guarantees; running EAP over raw IP or UDP transport is
如果发生重新排序，通常会导致EAP身份验证失败，从而导致重新运行EAP身份验证。因此，在可能重新排序的环境中，EAP身份验证失败是常见的。建议EAP仅在提供订购保证的较低层上运行；在原始IP或UDP传输上运行EAP是非常困难的
NOT RECOMMENDED. Encapsulation of EAP within RADIUS [RFC3579] satisfies ordering requirements, since RADIUS is a "lockstep" protocol that delivers packets in order.
不推荐。RADIUS[RFC3579]中EAP的封装满足订购要求，因为RADIUS是一种按顺序交付数据包的“锁步”协议。
In order to establish communications over a point-to-point link, each end of the PPP link first sends LCP packets to configure the data link during the Link Establishment phase. After the link has been established, PPP provides for an optional Authentication phase before proceeding to the Network-Layer Protocol phase.
为了在点到点链路上建立通信，PPP链路的每一端首先发送LCP分组以在链路建立阶段配置数据链路。链路建立后，PPP在进入网络层协议阶段之前提供可选的身份验证阶段。
By default, authentication is not mandatory. If authentication of the link is desired, an implementation MUST specify the Authentication Protocol Configuration Option during the Link Establishment phase.
默认情况下，身份验证不是强制性的。如果需要对链路进行身份验证，则实现必须在链路建立阶段指定身份验证协议配置选项。
If the identity of the peer has been established in the Authentication phase, the server can use that identity in the selection of options for the following network layer negotiations.
如果在身份验证阶段已建立对等方的身份，则服务器可以在为以下网络层协商选择选项时使用该身份。
When implemented within PPP, EAP does not select a specific authentication mechanism at the PPP Link Control Phase, but rather postpones this until the Authentication Phase. This allows the authenticator to request more information before determining the specific authentication mechanism. This also permits the use of a "backend" server which actually implements the various mechanisms while the PPP authenticator merely passes through the authentication exchange. The PPP Link Establishment and Authentication phases, and the Authentication Protocol Configuration Option, are defined in The Point-to-Point Protocol (PPP) [RFC1661].
当在PPP内实施时，EAP不会在PPP链路控制阶段选择特定的认证机制，而是将其推迟到认证阶段。这允许验证器在确定特定的身份验证机制之前请求更多信息。这还允许使用“后端”服务器，该服务器实际上实现了各种机制，而PPP认证器仅通过认证交换。PPP链路建立和认证阶段以及认证协议配置选项在点对点协议（PPP）[RFC1661]中定义。
A summary of the PPP Authentication Protocol Configuration Option format to negotiate EAP follows. The fields are transmitted from left to right.
下面是协商EAP的PPP认证协议配置选项格式的摘要。字段从左向右传输。
Exactly one EAP packet is encapsulated in the Information field of a PPP Data Link Layer frame where the protocol field indicates type hex C227 (PPP EAP).
PPP数据链路层帧的信息字段中封装了一个EAP数据包，其中协议字段指示hex C227（PPP EAP）类型。
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 | Length | Authentication Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Length | Authentication Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
3
3.
Length
长
4
4.
Authentication Protocol
认证协议
C227 (Hex) for Extensible Authentication Protocol (EAP)
用于可扩展身份验证协议（EAP）的C227（十六进制）
The encapsulation of EAP over IEEE 802 is defined in [IEEE-802.1X]. The IEEE 802 encapsulation of EAP does not involve PPP, and IEEE 802.1X does not include support for link or network layer negotiations. As a result, within IEEE 802.1X, it is not possible to negotiate non-EAP authentication mechanisms, such as PAP or CHAP [RFC1994].
在[IEEE-802.1X]中定义了EAP在IEEE 802上的封装。EAP的IEEE 802封装不涉及PPP，IEEE 802.1X不支持链路或网络层协商。因此，在IEEE 802.1X中，不可能协商非EAP身份验证机制，如PAP或CHAP[RFC1994]。
The reliability and security of lower layer indications is dependent on the lower layer. Since EAP is media independent, the presence or absence of lower layer security is not taken into account in the processing of EAP messages.
下层显示的可靠性和安全性取决于下层。由于EAP是媒体独立的，因此在处理EAP消息时不考虑是否存在较低层安全性。
To improve reliability, if a peer receives a lower layer success indication as defined in Section 7.2, it MAY conclude that a Success packet has been lost, and behave as if it had actually received a Success packet. This includes choosing to ignore the Success in some circumstances as described in Section 4.2.
为了提高可靠性，如果对等方接收到第7.2节中定义的较低层成功指示，它可能会得出成功数据包已丢失的结论，并表现为它实际上已接收到成功数据包。这包括在第4.2节所述的某些情况下选择忽略成功。
A discussion of some reliability and security issues with lower layer indications in PPP, IEEE 802 wired networks, and IEEE 802.11 wireless LANs can be found in the Security Considerations, Section 7.12.
关于PPP、IEEE 802有线网络和IEEE 802.11无线局域网中下层指示的一些可靠性和安全问题的讨论，请参见第7.12节的安全注意事项。
After EAP authentication is complete, the peer will typically transmit and receive data via the authenticator. It is desirable to provide assurance that the entities transmitting data are the same ones that successfully completed EAP authentication. To accomplish
EAP认证完成后，对等方通常将通过认证器发送和接收数据。希望提供传输数据的实体与成功完成EAP认证的实体相同的保证。完成
this, it is necessary for the lower layer to provide per-packet integrity, authentication and replay protection, and to bind these per-packet services to the keys derived during EAP authentication. Otherwise, it is possible for subsequent data traffic to be modified, spoofed, or replayed.
这就需要下层提供每包完整性、身份验证和重播保护，并将这些每包服务绑定到EAP身份验证期间派生的密钥。否则，后续数据通信可能会被修改、欺骗或重播。
Where keying material for the lower layer ciphersuite is itself provided by EAP, ciphersuite negotiation and key activation are controlled by the lower layer. In PPP, ciphersuites are negotiated within ECP so that it is not possible to use keys derived from EAP authentication until the completion of ECP. Therefore, an initial EAP exchange cannot be protected by a PPP ciphersuite, although EAP re-authentication can be protected.
如果较低层密码套件的密钥材料本身由EAP提供，则密码套件协商和密钥激活由较低层控制。在PPP中，密码套件在ECP中协商，因此在ECP完成之前，不可能使用从EAP身份验证派生的密钥。因此，虽然可以保护EAP重新身份验证，但PPP密码套件无法保护初始EAP交换。
In IEEE 802 media, initial key activation also typically occurs after completion of EAP authentication. Therefore an initial EAP exchange typically cannot be protected by the lower layer ciphersuite, although an EAP re-authentication or pre-authentication exchange can be protected.
在IEEE 802媒体中，初始密钥激活通常也发生在EAP身份验证完成之后。因此，虽然可以保护EAP重新认证或预认证交换，但初始EAP交换通常不能由较低层密码套件保护。
A summary of the EAP packet format is shown below. The fields are transmitted from left to right.
EAP数据包格式的摘要如下所示。字段从左向右传输。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Code
密码
The Code field is one octet and identifies the Type of EAP packet. EAP Codes are assigned as follows:
代码字段是一个八位字节，用于标识EAP数据包的类型。EAP代码分配如下：
1 Request 2 Response 3 Success 4 Failure
1请求2响应3成功4失败
Since EAP only defines Codes 1-4, EAP packets with other codes MUST be silently discarded by both authenticators and peers.
由于EAP仅定义代码1-4，因此认证者和对等方都必须悄悄地丢弃带有其他代码的EAP数据包。
Identifier
标识符
The Identifier field is one octet and aids in matching Responses with Requests.
标识符字段是一个八位字节，有助于将响应与请求匹配。
Length
长
The Length field is two octets and indicates the length, in octets, of the EAP packet including the Code, Identifier, Length, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored upon reception. A message with the Length field set to a value larger than the number of received octets MUST be silently discarded.
长度字段是两个八位字节，以八位字节表示EAP数据包的长度，包括代码、标识符、长度和数据字段。长度字段范围之外的八位字节应视为数据链路层填充，在接收时必须忽略。长度字段设置为大于接收的八位字节数的消息必须以静默方式丢弃。
Data
数据
The Data field is zero or more octets. The format of the Data field is determined by the Code field.
数据字段为零个或多个八位字节。数据字段的格式由代码字段决定。
Description
描述
The Request packet (Code field set to 1) is sent by the authenticator to the peer. Each Request has a Type field which serves to indicate what is being requested. Additional Request packets MUST be sent until a valid Response packet is received, an optional retry counter expires, or a lower layer failure indication is received.
认证器将请求数据包（代码字段设置为1）发送给对等方。每个请求都有一个类型字段，用于指示请求的内容。必须发送额外的请求数据包，直到收到有效的响应数据包、可选重试计数器过期或收到较低层故障指示。
Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish them from new Requests. The content of the data field is dependent on the Request Type. The peer MUST send a Response packet in reply to a valid Request packet. Responses MUST only be sent in reply to a valid Request and never be retransmitted on a timer.
必须使用相同的标识符值发送重新传输的请求，以便将其与新请求区分开来。数据字段的内容取决于请求类型。对等方必须发送一个响应数据包以响应有效的请求数据包。响应只能作为对有效请求的响应而发送，决不能在计时器上重新传输。
If a peer receives a valid duplicate Request for which it has already sent a Response, it MUST resend its original Response without reprocessing the Request. Requests MUST be processed in the order that they are received, and MUST be processed to their completion before inspecting the next Request.
如果对等方收到一个有效的重复请求，并且已经发送了响应，那么它必须在不重新处理该请求的情况下重新发送其原始响应。请求必须按照接收顺序进行处理，并且必须在检查下一个请求之前处理到完成。
A summary of the Request and Response packet format follows. The fields are transmitted from left to right.
下面是请求和响应数据包格式的摘要。字段从左向右传输。
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 | Type-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 | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
密码
1 for Request 2 for Response
1请求2响应
Identifier
标识符
The Identifier field is one octet. The Identifier field MUST be the same if a Request packet is retransmitted due to a timeout while waiting for a Response. Any new (non-retransmission) Requests MUST modify the Identifier field.
标识符字段是一个八位字节。如果在等待响应时由于超时而重新传输请求数据包，则标识符字段必须相同。任何新的（非重传）请求都必须修改标识符字段。
The Identifier field of the Response MUST match that of the currently outstanding Request. An authenticator receiving a Response whose Identifier value does not match that of the currently outstanding Request MUST silently discard the Response.
响应的标识符字段必须与当前未完成请求的标识符字段匹配。接收标识符值与当前未完成请求的标识符值不匹配的响应的身份验证器必须以静默方式放弃该响应。
In order to avoid confusion between new Requests and retransmissions, the Identifier value chosen for each new Request need only be different from the previous Request, but need not be unique within the conversation. One way to achieve this is to start the Identifier at an initial value and increment it for each new Request. Initializing the first Identifier with a random number rather than starting from zero is recommended, since it makes sequence attacks somewhat more difficult.
为了避免新请求和重新传输之间的混淆，为每个新请求选择的标识符值只需要与前一个请求不同，但不需要在会话中是唯一的。实现这一点的一种方法是在初始值处启动标识符，并为每个新请求递增它。建议使用随机数初始化第一个标识符，而不是从零开始，因为这会使序列攻击更加困难。
Since the Identifier space is unique to each session, authenticators are not restricted to only 256 simultaneous authentication conversations. Similarly, with re-authentication, an EAP conversation might continue over a long period of time, and is not limited to only 256 roundtrips.
由于标识符空间对于每个会话都是唯一的，因此身份验证程序不限于256个同步身份验证会话。类似地，通过重新认证，EAP对话可能会持续很长一段时间，并且不限于256次往返。
Implementation Note: The authenticator is responsible for retransmitting Request messages. If the Request message is obtained from elsewhere (such as from a backend authentication server), then the authenticator will need to save a copy of the Request in order to accomplish this. The peer is responsible for detecting and handling duplicate Request messages before processing them in any way, including passing them on to an outside party. The authenticator is also responsible for discarding Response messages with a non-matching
实现说明：验证器负责重新传输请求消息。如果请求消息是从其他地方（例如从后端身份验证服务器）获得的，则身份验证程序将需要保存请求的副本以完成此操作。对等方负责在以任何方式处理重复请求消息之前检测和处理它们，包括将它们传递给外部方。验证器还负责丢弃具有不匹配的响应消息
Identifier value before acting on them in any way, including passing them on to the backend authentication server for verification. Since the authenticator can retransmit before receiving a Response from the peer, the authenticator can receive multiple Responses, each with a matching Identifier. Until a new Request is received by the authenticator, the Identifier value is not updated, so that the authenticator forwards Responses to the backend authentication server, one at a time.
标识符值，然后再以任何方式对其进行操作，包括将其传递到后端身份验证服务器进行验证。由于认证器可以在从对等方接收响应之前重新传输，因此认证器可以接收多个响应，每个响应都具有匹配的标识符。在验证器接收到新请求之前，不会更新标识符值，以便验证器将响应转发给后端身份验证服务器，每次一个响应。
Length
长
The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Type-Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and MUST be ignored upon reception. A message with the Length field set to a value larger than the number of received octets MUST be silently discarded.
长度字段是两个八位字节，表示EAP数据包的长度，包括代码、标识符、长度、类型和类型数据字段。长度字段范围之外的八位字节应视为数据链路层填充，在接收时必须忽略。长度字段设置为大于接收的八位字节数的消息必须以静默方式丢弃。
Type
类型
The Type field is one octet. This field indicates the Type of Request or Response. A single Type MUST be specified for each EAP Request or Response. An initial specification of Types follows in Section 5 of this document.
类型字段是一个八位字节。此字段指示请求或响应的类型。必须为每个EAP请求或响应指定一种类型。本文件第5节给出了类型的初始规范。
The Type field of a Response MUST either match that of the Request, or correspond to a legacy or Expanded Nak (see Section 5.3) indicating that a Request Type is unacceptable to the peer. A peer MUST NOT send a Nak (legacy or expanded) in response to a Request, after an initial non-Nak Response has been sent. An EAP server receiving a Response not meeting these requirements MUST silently discard it.
响应的类型字段必须与请求的类型字段相匹配，或者对应于旧的或扩展的Nak（参见第5.3节），表明对等方不能接受请求类型。在发送初始非Nak响应后，对等方不得发送Nak（遗留或扩展）响应请求。接收到不符合这些要求的响应的EAP服务器必须自动放弃该响应。
Type-Data
类型数据
The Type-Data field varies with the Type of Request and the associated Response.
类型数据字段随请求类型和相关响应而变化。
The Success packet is sent by the authenticator to the peer after completion of an EAP authentication method (Type 4 or greater) to indicate that the peer has authenticated successfully to the authenticator. The authenticator MUST transmit an EAP packet with the Code field set to 3 (Success). If the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests), then after unsuccessful completion of the EAP method in progress, the implementation MUST transmit an EAP packet with the
在EAP身份验证方法（类型4或更高）完成后，认证者将成功数据包发送给对等方，以指示对等方已成功地向认证者进行身份验证。认证器必须发送代码字段设置为3（成功）的EAP数据包。如果验证器无法对对等方进行身份验证（对一个或多个请求的不可接受响应），则在执行中的EAP方法未成功完成后，实现必须使用
Code field set to 4 (Failure). An authenticator MAY wish to issue multiple Requests before sending a Failure response in order to allow for human typing mistakes. Success and Failure packets MUST NOT contain additional data.
代码字段设置为4（失败）。验证器可能希望在发送失败响应之前发出多个请求，以便允许人为键入错误。成功和失败数据包不得包含其他数据。
Success and Failure packets MUST NOT be sent by an EAP authenticator if the specification of the given method does not explicitly permit the method to finish at that point. A peer EAP implementation receiving a Success or Failure packet where sending one is not explicitly permitted MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" Success packet (a Success packet sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending a Success packet prior to conclusion of the EAP method conversation.
如果给定方法的规范未明确允许该方法在该点完成，则EAP验证器不得发送成功和失败数据包。接收成功或失败数据包的对等EAP实现在不明确允许发送数据包的情况下必须以静默方式放弃该数据包。默认情况下，EAP对等方必须以静默方式丢弃“屏蔽”成功数据包（连接后立即发送的成功数据包）。这确保了流氓身份验证程序将无法在EAP方法对话结束之前发送成功数据包，从而绕过相互身份验证。
Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance as described in this note. See also Section 3.4 for guidance on the processing of lower layer success and failure indications.
实现说明：由于未确认成功和失败数据包，因此它们不会被身份验证程序重新传输，并且可能会丢失。对等方必须考虑本说明中所述的这种情况。有关下层成功和失败指示的处理指南，另见第3.4节。
As described in Section 2.1, only a single EAP authentication method is allowed within an EAP conversation. EAP methods may implement result indications. After the authenticator sends a failure result indication to the peer, regardless of the response from the peer, it MUST subsequently send a Failure packet. After the authenticator sends a success result indication to the peer and receives a success result indication from the peer, it MUST subsequently send a Success packet.
如第2.1节所述，EAP对话中只允许使用单个EAP身份验证方法。EAP方法可实现结果指示。在认证器向对等方发送故障结果指示后，无论对等方的响应如何，它必须随后发送故障数据包。认证器向对等方发送成功结果指示并从对等方接收成功结果指示后，它必须随后发送成功数据包。
On the peer, once the method completes unsuccessfully (that is, either the authenticator sends a failure result indication, or the peer decides that it does not want to continue the conversation, possibly after sending a failure result indication), the peer MUST terminate the conversation and indicate failure to the lower layer. The peer MUST silently discard Success packets and MAY silently discard Failure packets. As a result, loss of a Failure packet need not result in a timeout.
在对等方上，一旦方法完成失败（即，身份验证方发送失败结果指示，或对等方决定不想继续对话，可能在发送失败结果指示后），对等方必须终止对话并向较低层指示失败。对等方必须以静默方式丢弃成功数据包，也可以以静默方式丢弃失败数据包。因此，失败数据包的丢失不必导致超时。
On the peer, after success result indications have been exchanged by both sides, a Failure packet MUST be silently discarded. The peer MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and that authentication concluded successfully.
在对等机上，双方交换成功结果指示后，必须悄悄地丢弃失败数据包。在没有接收到EAP成功的情况下，对等方可以断定EAP成功分组丢失并且认证成功结束。
If the authenticator has not sent a result indication, and the peer is willing to continue the conversation, the peer waits for a Success or Failure packet once the method completes, and MUST NOT silently discard either of them. In the event that neither a Success nor Failure packet is received, the peer SHOULD terminate the conversation to avoid lengthy timeouts in case the lost packet was an EAP Failure.
如果身份验证器没有发送结果指示，并且对等方愿意继续对话，则对等方在方法完成后等待成功或失败数据包，并且不能默默地丢弃其中任何一个。如果既没有收到成功数据包，也没有收到失败数据包，则对等方应终止对话，以避免在丢失的数据包是EAP故障的情况下出现长时间超时。
If the peer attempts to authenticate to the authenticator and fails to do so, the authenticator MUST send a Failure packet and MUST NOT grant access by sending a Success packet. However, an authenticator MAY omit having the peer authenticate to it in situations where limited access is offered (e.g., guest access). In this case, the authenticator MUST send a Success packet.
如果对等方尝试向身份验证器进行身份验证但失败，则身份验证器必须发送失败数据包，并且不得通过发送成功数据包来授予访问权限。然而，在提供有限访问（例如，来宾访问）的情况下，验证器可以省略让对等方对其进行身份验证。在这种情况下，验证器必须发送一个成功数据包。
Where the peer authenticates successfully to the authenticator, but the authenticator does not send a result indication, the authenticator MAY deny access by sending a Failure packet where the peer is not currently authorized for network access.
当对等方成功地向认证方进行认证，但认证方未发送结果指示时，认证方可通过发送对等方当前未被授权进行网络访问的故障包来拒绝访问。
A summary of the Success and Failure packet format is shown below. The fields are transmitted from left to right.
成功和失败数据包格式的摘要如下所示。字段从左向右传输。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
密码
3 for Success 4 for Failure
3代表成功4代表失败
Identifier
标识符
The Identifier field is one octet and aids in matching replies to Responses. The Identifier field MUST match the Identifier field of the Response packet that it is sent in response to.
标识符字段是一个八位字节，有助于将回复与响应进行匹配。标识符字段必须与响应数据包的标识符字段匹配，该响应数据包是作为响应发送的。
Length
长
4
4.
Because the authentication process will often involve user input, some care must be taken when deciding upon retransmission strategies and authentication timeouts. By default, where EAP is run over an unreliable lower layer, the EAP retransmission timer SHOULD be dynamically estimated. A maximum of 3-5 retransmissions is suggested.
由于身份验证过程通常涉及用户输入，因此在决定重传策略和身份验证超时时必须小心。默认情况下，如果EAP在不可靠的较低层上运行，则应动态估计EAP重传计时器。建议最多3-5次重传。
When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as within [PIC]), the authenticator retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. The peer may still maintain a timeout value so as to avoid waiting indefinitely for a Request.
当在可靠的较低层上运行时（例如，EAP over ISAKMP/TCP，如[PIC]中），验证器重传计时器应设置为无限值，以便在EAP层上不会发生重传。对等方仍然可以保持超时值，以避免无限期地等待请求。
Where the authentication process requires user input, the measured round trip times may be determined by user responsiveness rather than network characteristics, so that dynamic RTO estimation may not be helpful. Instead, the retransmission timer SHOULD be set so as to provide sufficient time for the user to respond, with longer timeouts required in certain cases, such as where Token Cards (see Section 5.6) are involved.
在认证过程需要用户输入的情况下，测量的往返时间可以由用户响应性而不是网络特征来确定，因此动态RTO估计可能没有帮助。相反，应设置重传计时器，以便为用户提供足够的响应时间，在某些情况下，如涉及令牌卡（见第5.6节）时，需要更长的超时时间。
In order to provide the EAP authenticator with guidance as to the appropriate timeout value, a hint can be communicated to the authenticator by the backend authentication server (such as via the RADIUS Session-Timeout attribute).
为了向EAP验证器提供有关适当超时值的指导，可以通过后端身份验证服务器（例如通过RADIUS会话超时属性）向验证器发送提示。
In order to dynamically estimate the EAP retransmission timer, the algorithms for the estimation of SRTT, RTTVAR, and RTO described in [RFC2988] are RECOMMENDED, including use of Karn's algorithm, with the following potential modifications:
为了动态估计EAP重传计时器，推荐[RFC2988]中描述的SRTT、RTTVAR和RTO估计算法，包括使用Karn算法，并进行以下可能的修改：
[a] In order to avoid synchronization behaviors that can occur with fixed timers among distributed systems, the retransmission timer is calculated with a jitter by using the RTO value and randomly adding a value drawn between -RTOmin/2 and RTOmin/2. Alternative calculations to create jitter MAY be used. These MUST be pseudo-random. For a discussion of pseudo-random number generation, see [RFC1750].
[a] 为了避免分布式系统中固定计时器可能出现的同步行为，通过使用RTO值并随机添加在-RTOmin/2和RTOmin/2之间绘制的值，使用抖动计算重传计时器。可以使用替代计算来创建抖动。这些必须是伪随机的。有关伪随机数生成的讨论，请参阅[RFC1750]。
[b] When EAP is transported over a single link (as opposed to over the Internet), smaller values of RTOinitial, RTOmin, and RTOmax MAY be used. Recommended values are RTOinitial=1 second, RTOmin=200ms, and RTOmax=20 seconds.
[b] 当EAP通过单个链路传输时（与通过互联网传输相反），可以使用较小的RTO初始值、RTO最小值和RTO最大值。建议值为RTO初始值=1秒，RTO最小值=200ms，RTO最大值=20秒。
[c] When EAP is transported over a single link (as opposed to over the Internet), estimates MAY be done on a per-authenticator basis, rather than a per-session basis. This enables the retransmission estimate to make the most use of information on link-layer behavior.
[c] 当EAP通过单个链路（而不是通过Internet）传输时，可以根据每个验证器进行估计，而不是根据每个会话进行估计。这使得重传估计能够最大限度地利用链路层行为的信息。
[d] An EAP implementation MAY clear SRTT and RTTVAR after backing off the timer multiple times, as it is likely that the current SRTT and RTTVAR are bogus in this situation. Once SRTT and RTTVAR are cleared, they should be initialized with the next RTT sample taken as described in [RFC2988] equation 2.2.
[d] EAP实现可能会在多次退出计时器后清除SRTT和RTTVAR，因为在这种情况下，当前SRTT和RTTVAR很可能是假的。清除SRTT和RTTVAR后，应使用[RFC2988]等式2.2中所述的下一个RTT样本对其进行初始化。
This section defines the initial set of EAP Types used in Request/ Response exchanges. More Types may be defined in future documents. The Type field is one octet and identifies the structure of an EAP Request or Response packet. The first 3 Types are considered special case Types.
本节定义了请求/响应交换中使用的EAP类型的初始集合。将来的文档中可能会定义更多类型。类型字段是一个八位字节，用于标识EAP请求或响应数据包的结构。前3种类型被视为特殊情况类型。
The remaining Types define authentication exchanges. Nak (Type 3) or Expanded Nak (Type 254) are valid only for Response packets, they MUST NOT be sent in a Request.
其余类型定义身份验证交换。Nak（类型3）或扩展Nak（类型254）仅对响应数据包有效，不得在请求中发送。
All EAP implementations MUST support Types 1-4, which are defined in this document, and SHOULD support Type 254. Implementations MAY support other Types defined here or in future RFCs.
所有EAP实施必须支持本文档中定义的类型1-4，并且应支持类型254。实现可能支持此处或未来RFC中定义的其他类型。
1 Identity 2 Notification 3 Nak (Response only) 4 MD5-Challenge 5 One Time Password (OTP) 6 Generic Token Card (GTC) 254 Expanded Types 255 Experimental use
1身份2通知3 Nak（仅响应）4 MD5质询5一次性密码（OTP）6通用令牌卡（GTC）254扩展类型255实验使用
EAP methods MAY support authentication based on shared secrets. If the shared secret is a passphrase entered by the user, implementations MAY support entering passphrases with non-ASCII characters. In this case, the input should be processed using an appropriate stringprep [RFC3454] profile, and encoded in octets using UTF-8 encoding [RFC2279]. A preliminary version of a possible stringprep profile is described in [SASLPREP].
EAP方法可能支持基于共享机密的身份验证。如果共享机密是用户输入的密码短语，则实现可能支持输入带有非ASCII字符的密码短语。在这种情况下，应使用适当的stringprep[RFC3454]配置文件处理输入，并使用UTF-8编码[RFC2279]以八位字节进行编码。[SASLPREP]中描述了可能的stringprep配置文件的初步版本。
Description
描述
The Identity Type is used to query the identity of the peer. Generally, the authenticator will issue this as the initial Request. An optional displayable message MAY be included to prompt the peer in the case where there is an expectation of interaction with a user. A Response of Type 1 (Identity) SHOULD be sent in Response to a Request with a Type of 1 (Identity).
标识类型用于查询对等方的标识。通常，身份验证器会将此作为初始请求发出。可以包括可选的可显示消息，以在期望与用户交互的情况下提示对等方。应发送类型为1（标识）的响应以响应类型为1（标识）的请求。
Some EAP implementations piggy-back various options into the Identity Request after a NUL-character. By default, an EAP implementation SHOULD NOT assume that an Identity Request or Response can be larger than 1020 octets.
一些EAP实现在NUL字符后将各种选项背负到标识请求中。默认情况下，EAP实现不应假定身份请求或响应可以大于1020个八位字节。
It is RECOMMENDED that the Identity Response be used primarily for routing purposes and selecting which EAP method to use. EAP Methods SHOULD include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response. Identity Requests and Responses are sent in cleartext, so an attacker may snoop on the identity, or even modify or spoof identity exchanges. To address these threats, it is preferable for an EAP method to include an identity exchange that supports per-packet authentication, integrity and replay protection, and confidentiality. The Identity Response may not be the appropriate identity for the method; it may have been truncated or obfuscated so as to provide privacy, or it may have been decorated for routing purposes. Where the peer is configured to only accept authentication methods supporting protected identity exchanges, the peer MAY provide an abbreviated Identity Response (such as omitting the peer-name portion of the NAI [RFC2486]). For further discussion of identity protection, see Section 7.3.
建议标识响应主要用于路由目的和选择要使用的EAP方法。EAP方法应包括用于获取身份的方法特定机制，以便它们不必依赖身份响应。身份请求和响应以明文形式发送，因此攻击者可以窥探身份，甚至修改或欺骗身份交换。为了解决这些威胁，EAP方法最好包括支持每包身份验证、完整性和重播保护以及机密性的身份交换。标识响应可能不是该方法的适当标识；它可能已被截断或模糊，以提供隐私，或者可能已被装饰用于路由目的。在对等方被配置为仅接受支持受保护的身份交换的认证方法的情况下，对等方可以提供缩写的身份响应（例如省略NAI[RFC2486]的对等方名称部分）。有关身份保护的进一步讨论，请参见第7.3节。
Implementation Note: The peer MAY obtain the Identity via user input. It is suggested that the authenticator retry the Identity Request in the case of an invalid Identity or authentication failure to allow for potential typos on the part of the user. It is suggested that the Identity Request be retried a minimum of 3 times before terminating the authentication. The Notification Request MAY be used to indicate an invalid authentication attempt prior to transmitting a new Identity Request (optionally, the failure MAY be indicated within the message of the new Identity Request itself).
实施说明：对等方可通过用户输入获得身份。建议身份验证人在身份无效或身份验证失败的情况下重试身份验证请求，以允许用户可能出现打字错误。建议在终止身份验证之前，至少重试身份验证请求3次。通知请求可用于在发送新身份请求之前指示无效的认证尝试（可选地，可在新身份请求本身的消息中指示失败）。
Type
类型
1
1.
Type-Data
类型数据
This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where the Request contains a null, only the portion of the field prior to the null is displayed. If the Identity is unknown, the Identity Response field should be zero bytes in length. The Identity Response field MUST NOT be null terminated. In all cases, the length of the Type-Data field is derived from the Length field of the Request/Response packet.
此字段可能包含请求中的可显示消息，其中包含UTF-8编码的ISO 10646字符[RFC2279]。如果请求包含null，则仅显示null之前的字段部分。如果标识未知，则标识响应字段的长度应为零字节。标识响应字段不能以null结尾。在所有情况下，类型数据字段的长度都源自请求/响应数据包的长度字段。
Security Claims (see Section 7.2):
担保索赔（见第7.2节）：
Auth. mechanism: None
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: N/A
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No
Auth. mechanism: None
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: N/A
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No
Description
描述
The Notification Type is optionally used to convey a displayable message from the authenticator to the peer. An authenticator MAY send a Notification Request to the peer at any time when there is no outstanding Request, prior to completion of an EAP authentication method. The peer MUST respond to a Notification Request with a Notification Response unless the EAP authentication method specification prohibits the use of Notification messages. In any case, a Nak Response MUST NOT be sent in response to a Notification Request. Note that the default maximum length of a Notification Request is 1020 octets. By default, this leaves at most 1015 octets for the human readable message.
通知类型可选地用于将可显示消息从验证器传送到对等方。在EAP认证方法完成之前，当没有未完成的请求时，认证者可以随时向对等方发送通知请求。对等方必须使用通知响应响应来响应通知请求，除非EAP身份验证方法规范禁止使用通知消息。在任何情况下，不得发送Nak响应以响应通知请求。请注意，通知请求的默认最大长度为1020个八位字节。默认情况下，这将为人类可读的消息保留最多1015个八位字节。
An EAP method MAY indicate within its specification that Notification messages must not be sent during that method. In this case, the peer MUST silently discard Notification Requests from the point where an initial Request for that Type is answered with a Response of the same Type.
EAP方法可在其规范内指示在该方法期间不得发送通知消息。在这种情况下，对等方必须在该类型的初始请求得到相同类型的响应时，以静默方式放弃通知请求。
The peer SHOULD display this message to the user or log it if it cannot be displayed. The Notification Type is intended to provide an acknowledged notification of some imperative nature, but it is not an error indication, and therefore does not change the state of the peer. Examples include a password with an expiration time that is about to expire, an OTP sequence integer which is nearing 0, an authentication failure warning, etc. In most circumstances, Notification should not be required.
对等方应向用户显示此消息，如果无法显示，则应记录此消息。通知类型旨在提供某种命令性质的已确认通知，但它不是错误指示，因此不会更改对等方的状态。示例包括到期时间即将到期的密码、接近0的OTP序列整数、身份验证失败警告等。在大多数情况下，不需要通知。
Type
类型
2
2.
Type-Data
类型数据
The Type-Data field in the Request contains a displayable message greater than zero octets in length, containing UTF-8 encoded ISO 10646 characters [RFC2279]. The length of the message is determined by the Length field of the Request packet. The message MUST NOT be null terminated. A Response MUST be sent in reply to the Request with a Type field of 2 (Notification). The Type-Data field of the Response is zero octets in length. The Response should be sent immediately (independent of how the message is displayed or logged).
请求中的类型数据字段包含长度大于零个八位字节的可显示消息，其中包含UTF-8编码的ISO 10646字符[RFC2279]。消息的长度由请求数据包的长度字段确定。消息不能以null结尾。必须使用类型字段2（通知）发送响应以答复请求。响应的类型数据字段的长度为零个八位字节。应立即发送响应（与消息的显示或记录方式无关）。
Security Claims (see Section 7.2):
担保索赔（见第7.2节）：
Auth. mechanism: None
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: N/A
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No
Auth. mechanism: None
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: N/A
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No
Description
描述
The legacy Nak Type is valid only in Response messages. It is sent in reply to a Request where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains one or more authentication Types desired by the Peer. Type zero (0) is used to indicate that the sender has no viable alternatives, and therefore the authenticator SHOULD NOT send another Request after receiving a Nak Response containing a zero value.
传统Nak类型仅在响应消息中有效。当所需的身份验证类型不可接受时，将发送该消息以响应请求。认证类型编号为4及以上。响应包含对等方所需的一种或多种身份验证类型。类型0（0）用于指示发送方没有可行的替代方案，因此身份验证程序在收到包含零值的Nak响应后不应发送另一个请求。
Since the legacy Nak Type is valid only in Responses and has very limited functionality, it MUST NOT be used as a general purpose error indication, such as for communication of error messages, or negotiation of parameters specific to a particular EAP method.
由于传统Nak类型仅在响应中有效，且功能非常有限，因此不得将其用作通用错误指示，例如用于错误消息的通信或特定EAP方法的参数协商。
Code
密码
2 for Response.
2.答复。
Identifier
标识符
The Identifier field is one octet and aids in matching Responses with Requests. The Identifier field of a legacy Nak Response MUST match the Identifier field of the Request packet that it is sent in response to.
标识符字段是一个八位字节，有助于将响应与请求匹配。遗留Nak响应的标识符字段必须与发送该响应的请求数据包的标识符字段匹配。
Length
长
>=6
>=6
Type
类型
3
3.
Type-Data
类型数据
Where a peer receives a Request for an unacceptable authentication Type (4-253,255), or a peer lacking support for Expanded Types receives a Request for Type 254, a Nak Response (Type 3) MUST be sent. The Type-Data field of the Nak Response (Type 3) MUST contain one or more octets indicating the desired authentication Type(s), one octet per Type, or the value zero (0) to indicate no proposed alternative. A peer supporting Expanded Types that
当对等方接收到不可接受的身份验证类型（4-253255）的请求，或不支持扩展类型的对等方接收到254类型的请求时，必须发送Nak响应（类型3）。Nak响应（类型3）的类型数据字段必须包含一个或多个表示所需身份验证类型的八位字节、每种类型一个八位字节或值零（0），以表示没有建议的替代方案。支持扩展类型的对等机
receives a Request for an unacceptable authentication Type (4-253, 255) MAY include the value 254 in the Nak Response (Type 3) to indicate the desire for an Expanded authentication Type. If the authenticator can accommodate this preference, it will respond with an Expanded Type Request (Type 254).
接收对不可接受的认证类型（4-253255）的请求，可在Nak响应（类型3）中包括值254，以指示对扩展认证类型的期望。如果验证器可以适应此首选项，它将以扩展类型请求（类型254）进行响应。
Security Claims (see Section 7.2):
担保索赔（见第7.2节）：
Auth. mechanism: None
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: N/A
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No
Auth. mechanism: None
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: N/A
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No
Description
描述
The Expanded Nak Type is valid only in Response messages. It MUST be sent only in reply to a Request of Type 254 (Expanded Type) where the authentication Type is unacceptable. The Expanded Nak Type uses the Expanded Type format itself, and the Response contains one or more authentication Types desired by the peer, all in Expanded Type format. Type zero (0) is used to indicate that the sender has no viable alternatives. The general format of the Expanded Type is described in Section 5.7.
扩展的Nak类型仅在响应消息中有效。只有在验证类型不可接受的254（扩展类型）类型的请求中，才能发送该请求。扩展的Nak类型使用扩展的类型格式本身，并且响应包含对等方所需的一个或多个身份验证类型，所有这些类型都采用扩展的类型格式。类型零（0）用于表示发送方没有可行的替代方案。第5.7节描述了扩展类型的一般格式。
Since the Expanded Nak Type is valid only in Responses and has very limited functionality, it MUST NOT be used as a general purpose error indication, such as for communication of error messages, or negotiation of parameters specific to a particular EAP method.
由于扩展的Nak类型仅在响应中有效，且功能非常有限，因此不得将其用作通用错误指示，例如用于错误消息的通信或特定EAP方法的参数协商。
Code
密码
2 for Response.
2.答复。
Identifier
标识符
The Identifier field is one octet and aids in matching Responses with Requests. The Identifier field of an Expanded Nak Response MUST match the Identifier field of the Request packet that it is sent in response to.
标识符字段是一个八位字节，有助于将响应与请求匹配。扩展Nak响应的标识符字段必须与发送该响应的请求数据包的标识符字段匹配。
Length
长
>=20
>=20
Type
类型
254
254
Vendor-Id
供应商Id
0 (IETF)
0（IETF）
Vendor-Type
供应商类型
3 (Nak)
3（Nak）
Vendor-Data
供应商数据
The Expanded Nak Type is only sent when the Request contains an Expanded Type (254) as defined in Section 5.7. The Vendor-Data field of the Nak Response MUST contain one or more authentication Types (4 or greater), all in expanded format, 8 octets per Type, or the value zero (0), also in Expanded Type format, to indicate no proposed alternative. The desired authentication Types may include a mixture of Vendor-Specific and IETF Types. For example, an Expanded Nak Response indicating a preference for OTP (Type 5), and an MIT (Vendor-Id=20) Expanded Type of 6 would appear as follows:
仅当请求包含第5.7节中定义的扩展类型（254）时，才会发送扩展Nak类型。Nak响应的供应商数据字段必须包含一个或多个身份验证类型（4个或更多），全部采用扩展格式，每种类型8个八位字节，或者也采用扩展类型格式的值零（0），以表示没有建议的替代方案。期望的认证类型可以包括特定于供应商的和IETF类型的混合。例如，表示对OTP（类型5）偏好的扩展Nak响应和MIT（供应商Id=20）扩展类型6将如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Identifier | Length=28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 (Nak) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 (OTP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 20 (MIT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Identifier | Length=28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 (Nak) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 (OTP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 20 (MIT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An Expanded Nak Response indicating a no desired alternative would appear as follows:
一个扩展的Nak响应表明没有期望的替代方案，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Identifier | Length=20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 (Nak) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (No alternative) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Identifier | Length=20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 (Nak) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (No alternative) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Claims (see Section 7.2):
担保索赔（见第7.2节）：
Auth. mechanism: None
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: N/A
Fast reconnect: No
Crypt. binding: N/A
Auth. mechanism: None
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: N/A
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A Fragmentation: No Channel binding: No
会话独立性：不适用碎片：无通道绑定：无
Description
描述
The MD5-Challenge Type is analogous to the PPP CHAP protocol [RFC1994] (with MD5 as the specified algorithm). The Request contains a "challenge" message to the peer. A Response MUST be sent in reply to the Request. The Response MAY be either of Type 4 (MD5-Challenge), Nak (Type 3), or Expanded Nak (Type 254). The Nak reply indicates the peer's desired authentication Type(s). EAP peer and EAP server implementations MUST support the MD5- Challenge mechanism. An authenticator that supports only pass-through MUST allow communication with a backend authentication server that is capable of supporting MD5-Challenge, although the EAP authenticator implementation need not support MD5-Challenge itself. However, if the EAP authenticator can be configured to authenticate peers locally (e.g., not operate in pass-through), then the requirement for support of the MD5-Challenge mechanism applies.
MD5质询类型类似于PPP CHAP协议[RFC1994]（MD5是指定的算法）。请求包含对对等方的“质询”消息。必须发送响应以响应请求。响应可以是类型4（MD5挑战）、Nak（类型3）或扩展Nak（类型254）。Nak应答指示对等方所需的身份验证类型。EAP对等和EAP服务器实现必须支持MD5质询机制。仅支持直通的身份验证程序必须允许与能够支持MD5质询的后端身份验证服务器通信，尽管EAP身份验证程序实现本身不需要支持MD5质询。但是，如果EAP验证器可以配置为在本地对对等方进行身份验证（例如，不在直通模式下运行），则MD5质询机制的支持要求适用。
Note that the use of the Identifier field in the MD5-Challenge Type is different from that described in [RFC1994]. EAP allows for retransmission of MD5-Challenge Request packets, while [RFC1994] states that both the Identifier and Challenge fields MUST change each time a Challenge (the CHAP equivalent of the MD5-Challenge Request packet) is sent.
请注意，MD5质询类型中标识符字段的使用与[RFC1994]中描述的不同。EAP允许重新传输MD5质询请求数据包，而[RFC1994]指出，每次发送质询（相当于MD5质询请求数据包的CHAP）时，标识符和质询字段都必须更改。
Note: [RFC1994] treats the shared secret as an octet string, and does not specify how it is entered into the system (or if it is handled by the user at all). EAP MD5-Challenge implementations MAY support entering passphrases with non-ASCII characters. See Section 5 for instructions how the input should be processed and encoded into octets.
注意：[RFC1994]将共享机密视为八位字节字符串，不指定如何将其输入系统（或是否由用户处理）。EAP MD5质询实现可能支持输入带有非ASCII字符的密码短语。有关如何处理输入并将其编码为八位字节的说明，请参见第5节。
Type
类型
4
4.
Type-Data
类型数据
The contents of the Type-Data field is summarized below. For reference on the use of these fields, see the PPP Challenge Handshake Authentication Protocol [RFC1994].
类型数据字段的内容总结如下。有关这些字段使用的参考，请参阅PPP质询握手认证协议[RFC1994]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Claims (see Section 7.2):
担保索赔（见第7.2节）：
Auth. mechanism: Password or pre-shared key.
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: No
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No
Auth. mechanism: Password or pre-shared key.
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: No
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No
Description
描述
The One-Time Password system is defined in "A One-Time Password System" [RFC2289] and "OTP Extended Responses" [RFC2243]. The Request contains an OTP challenge in the format described in [RFC2289]. A Response MUST be sent in reply to the Request. The Response MUST be of Type 5 (OTP), Nak (Type 3), or Expanded Nak (Type 254). The Nak Response indicates the peer's desired authentication Type(s). The EAP OTP method is intended for use with the One-Time Password system only, and MUST NOT be used to provide support for cleartext passwords.
一次性密码系统在“一次性密码系统”[RFC2289]和“OTP扩展响应”[RFC2243]中定义。该请求包含[RFC2289]中所述格式的OTP质询。必须发送响应以响应请求。响应必须是类型5（OTP）、Nak（类型3）或扩展Nak（类型254）。Nak响应指示对等方所需的身份验证类型。EAP OTP方法仅用于一次性密码系统，不得用于支持明文密码。
Type
类型
5
5.
Type-Data
类型数据
The Type-Data field contains the OTP "challenge" as a displayable message in the Request. In the Response, this field is used for the 6 words from the OTP dictionary [RFC2289]. The messages MUST NOT be null terminated. The length of the field is derived from the Length field of the Request/Reply packet.
类型数据字段包含OTP“质询”，作为请求中的可显示消息。在响应中，此字段用于OTP字典[RFC2289]中的6个单词。消息不能以null结尾。该字段的长度来自请求/应答数据包的长度字段。
Note: [RFC2289] does not specify how the secret pass-phrase is entered by the user, or how the pass-phrase is converted into octets. EAP OTP implementations MAY support entering passphrases with non-ASCII characters. See Section 5 for instructions on how the input should be processed and encoded into octets.
注意：[RFC2289]未指定用户如何输入密码短语，或密码短语如何转换为八位字节。EAP OTP实现可能支持输入带有非ASCII字符的密码短语。有关如何处理输入并将其编码为八位字节的说明，请参见第5节。
Security Claims (see Section 7.2):
担保索赔（见第7.2节）：
Auth. mechanism: One-Time Password
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: Yes
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: No
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No
Auth. mechanism: One-Time Password
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: Yes
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: No
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No
Description
描述
The Generic Token Card Type is defined for use with various Token Card implementations which require user input. The Request contains a displayable message and the Response contains the Token Card information necessary for authentication. Typically, this would be information read by a user from the Token card device and entered as ASCII text. A Response MUST be sent in reply to the Request. The Response MUST be of Type 6 (GTC), Nak (Type 3), or Expanded Nak (Type 254). The Nak Response indicates the peer's desired authentication Type(s). The EAP GTC method is intended for use with the Token Cards supporting challenge/response
通用令牌卡类型定义用于需要用户输入的各种令牌卡实现。请求包含可显示的消息，响应包含身份验证所需的令牌卡信息。通常，这将是用户从令牌卡设备读取的信息，并作为ASCII文本输入。必须发送响应以响应请求。响应必须是类型6（GTC）、Nak（类型3）或扩展Nak（类型254）。Nak响应指示对等方所需的身份验证类型。EAP GTC方法旨在与支持质询/响应的令牌卡一起使用
authentication and MUST NOT be used to provide support for cleartext passwords in the absence of a protected tunnel with server authentication.
在没有带服务器身份验证的受保护隧道的情况下，身份验证和不能用于提供对明文密码的支持。
Type
类型
6
6.
Type-Data
类型数据
The Type-Data field in the Request contains a displayable message greater than zero octets in length. The length of the message is determined by the Length field of the Request packet. The message MUST NOT be null terminated. A Response MUST be sent in reply to the Request with a Type field of 6 (Generic Token Card). The Response contains data from the Token Card required for authentication. The length of the data is determined by the Length field of the Response packet.
请求中的类型数据字段包含长度大于零个八位字节的可显示消息。消息的长度由请求数据包的长度字段确定。消息不能以null结尾。必须使用类型字段6（通用令牌卡）发送响应以响应请求。响应包含身份验证所需的令牌卡数据。数据的长度由响应数据包的长度字段确定。
EAP GTC implementations MAY support entering a response with non-ASCII characters. See Section 5 for instructions how the input should be processed and encoded into octets.
EAP GTC实现可能支持输入带有非ASCII字符的响应。有关如何处理输入并将其编码为八位字节的说明，请参见第5节。
Security Claims (see Section 7.2):
担保索赔（见第7.2节）：
Auth. mechanism: Hardware token.
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: No
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No
Auth. mechanism: Hardware token.
Ciphersuite negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key derivation: No
Key strength: N/A
Dictionary attack prot.: No
Fast reconnect: No
Crypt. binding: N/A
Session independence: N/A
Fragmentation: No
Channel binding: No
Description
描述
Since many of the existing uses of EAP are vendor-specific, the Expanded method Type is available to allow vendors to support their own Expanded Types not suitable for general usage.
由于EAP的许多现有用途都是特定于供应商的，因此扩展方法类型可用于允许供应商支持其自己的扩展类型，这些扩展类型不适合一般用途。
The Expanded Type is also used to expand the global Method Type space beyond the original 255 values. A Vendor-Id of 0 maps the original 255 possible Types onto a space of 2^32-1 possible Types. (Type 0 is only used in a Nak Response to indicate no acceptable alternative).
扩展类型还用于将全局方法类型空间扩展到原始255个值之外。供应商Id为0时，将原始的255种可能类型映射到2^32-1种可能类型的空间中。（类型0仅在Nak响应中使用，表示没有可接受的替代方案）。
An implementation that supports the Expanded attribute MUST treat EAP Types that are less than 256 equivalently, whether they appear as a single octet or as the 32-bit Vendor-Type within an Expanded Type where Vendor-Id is 0. Peers not equipped to interpret the Expanded Type MUST send a Nak as described in Section 5.3.1, and negotiate a more suitable authentication method.
支持扩展属性的实现必须等效地处理小于256的EAP类型，无论它们是作为单个八位字节显示，还是作为供应商Id为0的扩展类型中的32位供应商类型。未配备解释扩展类型的对等方必须按照第5.3.1节所述发送Nak，并协商更合适的认证方法。
A summary of the Expanded Type format is shown below. The fields are transmitted from left to right.
下面显示了扩展类型格式的摘要。字段从左向右传输。
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 | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
254 for Expanded Type
254表示扩展类型
Vendor-Id
供应商Id
The Vendor-Id is 3 octets and represents the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as allocated by IANA. A Vendor-Id of zero is reserved for use by the IETF in providing an expanded global EAP Type space.
供应商Id为3个八位字节，表示供应商的SMI网络管理私有企业代码（按网络字节顺序），由IANA分配。IETF在提供扩展的全局EAP类型空间时保留零供应商Id。
Vendor-Type
供应商类型
The Vendor-Type field is four octets and represents the vendor-specific method Type.
供应商类型字段是四个八位字节，表示供应商特定的方法类型。
If the Vendor-Id is zero, the Vendor-Type field is an extension and superset of the existing namespace for EAP Types. The first 256 Types are reserved for compatibility with single-octet EAP Types that have already been assigned or may be assigned in the future. Thus, EAP Types from 0 through 255 are semantically identical, whether they appear as single octet EAP Types or as
如果供应商Id为零，则供应商类型字段是EAP类型的现有命名空间的扩展和超集。前256个类型保留为与已分配或将来可能分配的单八位组EAP类型兼容。因此，从0到255的EAP类型在语义上是相同的，无论它们是作为单个八位组EAP类型还是作为
Vendor-Types when Vendor-Id is zero. There is one exception to this rule: Expanded Nak and Legacy Nak packets share the same Type, but must be treated differently because they have a different format.
供应商Id为零时的供应商类型。此规则有一个例外：扩展Nak和旧Nak数据包共享相同的类型，但必须区别对待，因为它们具有不同的格式。
Vendor-Data
供应商数据
The Vendor-Data field is defined by the vendor. Where a Vendor-Id of zero is present, the Vendor-Data field will be used for transporting the contents of EAP methods of Types defined by the IETF.
供应商数据字段由供应商定义。如果供应商Id为零，则供应商数据字段将用于传输IETF定义类型的EAP方法的内容。
Description
描述
The Experimental Type has no fixed format or content. It is intended for use when experimenting with new EAP Types. This Type is intended for experimental and testing purposes. No guarantee is made for interoperability between peers using this Type, as outlined in [RFC3692].
实验类型没有固定的格式或内容。它旨在用于试验新的EAP类型。此类型用于实验和测试目的。如[RFC3692]所述，不保证使用此类型的对等机之间的互操作性。
Type
类型
255
255
Type-Data
类型数据
Undefined
未定义
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the EAP protocol, in accordance with BCP 26, [RFC2434].
本节根据BCP 26、[RFC2434]，为互联网分配号码管理局（IANA）提供有关EAP协议相关值注册的指南。
There are two name spaces in EAP that require registration: Packet Codes and method Types.
EAP中有两个名称空间需要注册：数据包代码和方法类型。
EAP is not intended as a general-purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to authentication.
EAP不是一个通用协议，分配不应用于与身份验证无关的目的。
The following terms are used here with the meanings defined in BCP 26: "name space", "assigned value", "registration".
以下术语的含义见BCP 26：“名称空间”、“赋值”、“注册”。
The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IETF Consensus", "Standards Action".
此处使用以下政策，其含义见BCP 26：“私人使用”、“先到先得”、“专家评审”、“所需规范”、“IETF共识”、“标准行动”。
For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. The intention is that any allocation will be accompanied by a published RFC. But in order to allow for the allocation of values prior to the RFC being approved for publication, the Designated Expert can approve allocations once it seems clear that an RFC will be published. The Designated expert will post a request to the EAP WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the EAP WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation, and in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable should be provided.
对于需要咨询指定专家的注册请求，IESG区域负责人应任命指定专家。其目的是，任何分配都将附带公布的RFC。但为了允许在批准发布RFC之前分配值，一旦确定RFC将发布，指定专家可以批准分配。指定专家将向EAP工作组邮件列表（或区域总监指定的继任者）发出请求，以征求意见和审查，包括互联网草案。在30天内，指定专家将批准或拒绝注册请求，并向EAP工作组邮件列表或其继任者发布决定通知，同时通知IANA。拒绝通知必须以解释为理由，在可能的情况下，应提供具体建议，说明如何修改请求以使其成为可接受的请求。
Packet Codes have a range from 1 to 255, of which 1-4 have been allocated. Because a new Packet Code has considerable impact on interoperability, a new Packet Code requires Standards Action, and should be allocated starting at 5.
数据包代码的范围为1到255，其中1到4个已分配。因为新的数据包代码对互操作性有相当大的影响，所以新的数据包代码需要标准操作，并且应该从5开始分配。
The original EAP method Type space has a range from 1 to 255, and is the scarcest resource in EAP, and thus must be allocated with care. Method Types 1-45 have been allocated, with 20 available for re-use. Method Types 20 and 46-191 may be allocated on the advice of a Designated Expert, with Specification Required.
原始EAP方法类型空间的范围为1到255，是EAP中最稀缺的资源，因此必须小心分配。已分配方法类型1-45，其中20种可重复使用。方法类型20和46-191可根据指定专家的建议进行分配，并需要规范。
Allocation of blocks of method Types (more than one for a given purpose) should require IETF Consensus. EAP Type Values 192-253 are reserved and allocation requires Standards Action.
方法类型块的分配（给定目的不止一个）应要求IETF一致同意。EAP类型值192-253是保留的，分配需要标准操作。
Method Type 254 is allocated for the Expanded Type. Where the Vendor-Id field is non-zero, the Expanded Type is used for functions specific only to one vendor's implementation of EAP, where no interoperability is deemed useful. When used with a Vendor-Id of zero, method Type 254 can also be used to provide for an expanded IETF method Type space. Method Type values 256-4294967295 may be allocated after Type values 1-191 have been allocated, on the advice of a Designated Expert, with Specification Required.
方法类型254分配给扩展类型。如果供应商Id字段为非零，则扩展类型仅用于特定于一个供应商EAP实现的功能，其中互操作性被视为无效。当与零供应商Id一起使用时，方法类型254也可用于提供扩展的IETF方法类型空间。方法类型值256-4294967295可在类型值1-191分配后，根据指定专家的建议，按照要求的规范进行分配。
Method Type 255 is allocated for Experimental use, such as testing of new EAP methods before a permanent Type is allocated.
方法类型255分配用于实验用途，例如在分配永久类型之前测试新的EAP方法。
This section defines a generic threat model as well as the EAP method security claims mitigating those threats.
本节定义了通用威胁模型以及缓解这些威胁的EAP方法安全声明。
It is expected that the generic threat model and corresponding security claims will used to define EAP method requirements for use in specific environments. An example of such a requirements analysis is provided in [IEEE-802.11i-req]. A security claims section is required in EAP method specifications, so that EAP methods can be evaluated against the requirements.
预计通用威胁模型和相应的安全声明将用于定义特定环境中使用的EAP方法要求。[IEEE-802.11i-req]中提供了此类需求分析的示例。EAP方法规范中需要一个安全声明部分，以便根据要求对EAP方法进行评估。
EAP was developed for use with PPP [RFC1661] and was later adapted for use in wired IEEE 802 networks [IEEE-802] in [IEEE-802.1X]. Subsequently, EAP has been proposed for use on wireless LAN networks and over the Internet. In all these situations, it is possible for an attacker to gain access to links over which EAP packets are transmitted. For example, attacks on telephone infrastructure are documented in [DECEPTION].
EAP是为与PPP[RFC1661]一起使用而开发的，后来在[IEEE-802.1X]中被改编为用于有线IEEE 802网络[IEEE-802]。随后，EAP被提议用于无线LAN网络和Internet。在所有这些情况下，攻击者都有可能访问EAP数据包传输的链路。例如，对电话基础设施的攻击记录在[欺骗]中。
An attacker with access to the link may carry out a number of attacks, including:
具有链接访问权限的攻击者可能会实施多种攻击，包括：
[1] An attacker may try to discover user identities by snooping authentication traffic.
[1] 攻击者可能试图通过窥探身份验证流量来发现用户身份。
[2] An attacker may try to modify or spoof EAP packets.
[2] 攻击者可能试图修改或欺骗EAP数据包。
[3] An attacker may launch denial of service attacks by spoofing lower layer indications or Success/Failure packets, by replaying EAP packets, or by generating packets with overlapping Identifiers.
[3] 攻击者可以通过欺骗下层指示或成功/失败数据包、重播EAP数据包或生成具有重叠标识符的数据包来发起拒绝服务攻击。
[4] An attacker may attempt to recover the pass-phrase by mounting an offline dictionary attack.
[4] 攻击者可能试图通过发起脱机字典攻击来恢复密码短语。
[5] An attacker may attempt to convince the peer to connect to an untrusted network by mounting a man-in-the-middle attack.
[5] 攻击者可能试图通过发起中间人攻击来说服对等方连接到不受信任的网络。
[6] An attacker may attempt to disrupt the EAP negotiation in order cause a weak authentication method to be selected.
[6] 攻击者可能试图中断EAP协商，以便选择弱身份验证方法。
[7] An attacker may attempt to recover keys by taking advantage of weak key derivation techniques used within EAP methods.
[7] 攻击者可能试图利用EAP方法中使用的弱密钥派生技术来恢复密钥。
[8] An attacker may attempt to take advantage of weak ciphersuites subsequently used after the EAP conversation is complete.
[8] 攻击者可能试图利用EAP对话完成后随后使用的弱密码套件。
[9] An attacker may attempt to perform downgrading attacks on lower layer ciphersuite negotiation in order to ensure that a weaker ciphersuite is used subsequently to EAP authentication.
[9] 攻击者可能试图对较低层密码套件协商执行降级攻击，以确保随后使用较弱的密码套件进行EAP身份验证。
[10] An attacker acting as an authenticator may provide incorrect information to the EAP peer and/or server via out-of-band mechanisms (such as via a AAA or lower layer protocol). This includes impersonating another authenticator, or providing inconsistent information to the peer and EAP server.
[10] 充当身份验证器的攻击者可能通过带外机制（例如通过AAA或较低层协议）向EAP对等方和/或服务器提供不正确的信息。这包括模拟另一个验证器，或向对等服务器和EAP服务器提供不一致的信息。
Depending on the lower layer, these attacks may be carried out without requiring physical proximity. Where EAP is used over wireless networks, EAP packets may be forwarded by authenticators (e.g., pre-authentication) so that the attacker need not be within the coverage area of an authenticator in order to carry out an attack on it or its peers. Where EAP is used over the Internet, attacks may be carried out at an even greater distance.
根据较低的层，这些攻击可以在不需要物理接近的情况下执行。在通过无线网络使用EAP的情况下，EAP分组可由认证器转发（例如，预认证），以便攻击者不必在认证器的覆盖区域内对其或其对等方进行攻击。在互联网上使用EAP的情况下，攻击可能会在更远的距离进行。
In order to clearly articulate the security provided by an EAP method, EAP method specifications MUST include a Security Claims section, including the following declarations:
为了清楚地阐明EAP方法提供的安全性，EAP方法规范必须包括安全声明部分，包括以下声明：
[a] Mechanism. This is a statement of the authentication technology: certificates, pre-shared keys, passwords, token cards, etc.
[a] 机械装置这是认证技术的声明：证书、预共享密钥、密码、令牌卡等。
[b] Security claims. This is a statement of the claimed security properties of the method, using terms defined in Section 7.2.1: mutual authentication, integrity protection, replay protection, confidentiality, key derivation, dictionary attack resistance, fast reconnect, cryptographic binding. The Security Claims section of an EAP method specification SHOULD provide justification for the claims that are made. This can be accomplished by including a proof in an Appendix, or including a reference to a proof.
[b] 担保索赔。这是使用第7.2.1节中定义的术语声明方法的安全属性：相互认证、完整性保护、重播保护、机密性、密钥派生、字典攻击抵抗、快速重新连接、加密绑定。EAP方法规范的“安全声明”部分应为提出的声明提供理由。这可以通过在附录中包含证据或引用证据来实现。
[c] Key strength. If the method derives keys, then the effective key strength MUST be estimated. This estimate is meant for potential users of the method to determine if the keys produced are strong enough for the intended application.
[c] 关键力量。如果该方法导出键，则必须估计有效键强度。此估计值用于该方法的潜在用户，以确定生成的密钥是否足以满足预期应用。
The effective key strength SHOULD be stated as a number of bits, defined as follows: If the effective key strength is N bits, the best currently known methods to recover the key (with non-negligible probability) require, on average, an effort comparable to 2^(N-1) operations of a typical block cipher. The statement SHOULD be accompanied by a short rationale, explaining how this number was derived. This explanation SHOULD include the parameters required to achieve the stated key strength based on current knowledge of the algorithms.
有效密钥强度应表示为比特数，定义如下：如果有效密钥强度为N比特，则当前已知的恢复密钥的最佳方法（概率不可忽略）平均需要与典型分组密码的2^（N-1）操作相当的工作量。声明应附有一个简短的理由，解释这个数字是如何得出的。该解释应包括根据当前算法知识达到规定关键强度所需的参数。
(Note: Although it is difficult to define what "comparable effort" and "typical block cipher" exactly mean, reasonable approximations are sufficient here. Refer to e.g. [SILVERMAN] for more discussion.)
（注：虽然很难定义“可比努力”和“典型分组密码”的确切含义，但这里的合理近似值就足够了。更多讨论请参考[SILVERMAN]
The key strength depends on the methods used to derive the keys. For instance, if keys are derived from a shared secret (such as a password or a long-term secret), and possibly some public information such as nonces, the effective key strength is limited by the strength of the long-term secret (assuming that the derivation procedure is computationally simple). To take another example, when using public key algorithms, the strength of the symmetric key depends on the strength of the public keys used.
关键点强度取决于用于导出关键点的方法。例如，如果密钥是从共享秘密（例如密码或长期秘密）和可能的一些公共信息（例如nonce）派生的，则有效密钥强度受到长期秘密强度的限制（假设派生过程在计算上很简单）。再举一个例子，当使用公钥算法时，对称密钥的强度取决于所使用的公钥的强度。
[d] Description of key hierarchy. EAP methods deriving keys MUST either provide a reference to a key hierarchy specification, or describe how Master Session Keys (MSKs) and Extended Master Session Keys (EMSKs) are to be derived.
[d] 密钥层次结构的描述。派生密钥的EAP方法必须提供对密钥层次结构规范的引用，或者描述如何派生主会话密钥（MSK）和扩展主会话密钥（EMSK）。
[e] Indication of vulnerabilities. In addition to the security claims that are made, the specification MUST indicate which of the security claims detailed in Section 7.2.1 are NOT being made.
[e] 漏洞指示。除已提出的担保声明外，规范必须指明第7.2.1节中详述的哪些担保声明未提出。
These terms are used to describe the security properties of EAP methods:
这些术语用于描述EAP方法的安全属性：
Protected ciphersuite negotiation This refers to the ability of an EAP method to negotiate the ciphersuite used to protect the EAP conversation, as well as to integrity protect the negotiation. It does not refer to the ability to negotiate the ciphersuite used to protect data.
受保护的密码套件协商这是指EAP方法协商用于保护EAP会话的密码套件以及保护协商完整性的能力。它不是指协商用于保护数据的密码套件的能力。
Mutual authentication This refers to an EAP method in which, within an interlocked exchange, the authenticator authenticates the peer and the peer authenticates the authenticator. Two independent one-way methods, running in opposite directions do not provide mutual authentication as defined here.
相互认证这指的是一种EAP方法，在这种方法中，在联锁交换中，认证者对对等方进行认证，对等方对认证者进行认证。在相反方向上运行的两个独立的单向方法不提供此处定义的相互身份验证。
Integrity protection This refers to providing data origin authentication and protection against unauthorized modification of information for EAP packets (including EAP Requests and Responses). When making this claim, a method specification MUST describe the EAP packets and fields within the EAP packet that are protected.
完整性保护这是指提供数据源身份验证和保护，防止未经授权修改EAP数据包的信息（包括EAP请求和响应）。在提出此声明时，方法规范必须描述受保护的EAP数据包和EAP数据包内的字段。
Replay protection This refers to protection against replay of an EAP method or its messages, including success and failure result indications.
重播保护这是指防止重播EAP方法或其消息的保护，包括成功和失败结果指示。
Confidentiality This refers to encryption of EAP messages, including EAP Requests and Responses, and success and failure result indications. A method making this claim MUST support identity protection (see Section 7.3).
机密性这是指EAP消息的加密，包括EAP请求和响应，以及成功和失败结果指示。提出此声明的方法必须支持身份保护（参见第7.3节）。
Key derivation This refers to the ability of the EAP method to derive exportable keying material, such as the Master Session Key (MSK), and Extended Master Session Key (EMSK). The MSK is used only for further key derivation, not directly for protection of the EAP conversation or subsequent data. Use of the EMSK is reserved.
密钥派生这是指EAP方法派生可导出密钥材料的能力，例如主会话密钥（MSK）和扩展主会话密钥（EMSK）。MSK仅用于进一步的密钥派生，而不是直接用于保护EAP会话或后续数据。保留EMSK的使用权。
Key strength If the effective key strength is N bits, the best currently known methods to recover the key (with non-negligible probability) require, on average, an effort comparable to 2^(N-1) operations of a typical block cipher.
密钥强度如果有效密钥强度为N位，则当前已知的恢复密钥的方法（概率不可忽略）平均需要与典型分组密码的2^（N-1）操作相当的工作量。
Dictionary attack resistance Where password authentication is used, passwords are commonly selected from a small set (as compared to a set of N-bit keys), which raises a concern about dictionary attacks. A method may be said to provide protection against dictionary attacks if, when it uses a password as a secret, the method does not allow an offline attack that has a work factor based on the number of passwords in an attacker's dictionary.
字典攻击抵抗在使用密码身份验证的情况下，密码通常从一个小集合中选择（与一组N位密钥相比），这引起了对字典攻击的关注。如果一种方法在使用密码作为秘密时，不允许离线攻击，而离线攻击的工作系数基于攻击者字典中的密码数，则可以说该方法提供了字典攻击防护。
Fast reconnect The ability, in the case where a security association has been previously established, to create a new or refreshed security association more efficiently or in a smaller number of round-trips.
快速重新连接—在以前已建立安全关联的情况下，能够更高效地或以较少的往返次数创建新的或刷新的安全关联。
Cryptographic binding The demonstration of the EAP peer to the EAP server that a single entity has acted as the EAP peer for all methods executed within a tunnel method. Binding MAY also imply that the EAP server demonstrates to the peer that a single entity has acted as the EAP server for all methods executed within a tunnel method. If executed correctly, binding serves to mitigate man-in-the-middle vulnerabilities.
加密绑定EAP对等点到EAP服务器的演示，即单个实体已充当隧道方法内执行的所有方法的EAP对等点。绑定还可能意味着EAP服务器向对等方演示单个实体已充当隧道方法中执行的所有方法的EAP服务器。如果执行正确，绑定可以缓解中间人漏洞。
Session independence The demonstration that passive attacks (such as capture of the EAP conversation) or active attacks (including compromise of the MSK or EMSK) does not enable compromise of subsequent or prior MSKs or EMSKs.
会话独立性—证明被动攻击（如捕获EAP会话）或主动攻击（包括MSK或EMSK的泄露）不能泄露后续或先前的MSK或EMSK。
Fragmentation This refers to whether an EAP method supports fragmentation and reassembly. As noted in Section 3.1, EAP methods should support fragmentation and reassembly if EAP packets can exceed the minimum MTU of 1020 octets.
碎片这是指EAP方法是否支持碎片和重新组装。如第3.1节所述，如果EAP数据包可以超过1020个八位字节的最小MTU，则EAP方法应支持分段和重新组装。
Channel binding The communication within an EAP method of integrity-protected channel properties such as endpoint identifiers which can be compared to values communicated via out of band mechanisms (such as via a AAA or lower layer protocol).
通道绑定完整性保护通道属性（如端点标识符）的EAP方法内的通信，端点标识符可与通过带外机制（如通过AAA或较低层协议）传输的值进行比较。
Note: This list of security claims is not exhaustive. Additional properties, such as additional denial-of-service protection, may be relevant as well.
注：本担保索赔清单并非详尽无遗。其他属性（如其他拒绝服务保护）也可能与此相关。
An Identity exchange is optional within the EAP conversation. Therefore, it is possible to omit the Identity exchange entirely, or to use a method-specific identity exchange once a protected channel has been established.
在EAP对话中，身份交换是可选的。因此，可以完全省略标识交换，或者在建立受保护通道后使用特定于方法的标识交换。
However, where roaming is supported as described in [RFC2607], it may be necessary to locate the appropriate backend authentication server before the authentication conversation can proceed. The realm portion of the Network Access Identifier (NAI) [RFC2486] is typically
但是，在[RFC2607]中描述的支持漫游的情况下，可能需要在身份验证对话继续之前找到适当的后端身份验证服务器。网络访问标识符（NAI）[RFC2486]的领域部分通常是
included within the EAP-Response/Identity in order to enable the authentication exchange to be routed to the appropriate backend authentication server. Therefore, while the peer-name portion of the NAI may be omitted in the EAP-Response/Identity where proxies or relays are present, the realm portion may be required.
包含在EAP响应/标识中，以便能够将身份验证交换路由到相应的后端身份验证服务器。因此，虽然在存在代理或中继器的EAP响应/标识中可以省略NAI的对等名称部分，但是可能需要领域部分。
It is possible for the identity in the identity response to be different from the identity authenticated by the EAP method. This may be intentional in the case of identity privacy. An EAP method SHOULD use the authenticated identity when making access control decisions.
标识响应中的标识可能与EAP方法认证的标识不同。在身份隐私的情况下，这可能是故意的。EAP方法在做出访问控制决策时应使用经过身份验证的标识。
Where EAP is tunneled within another protocol that omits peer authentication, there exists a potential vulnerability to a man-in-the-middle attack. For details, see [BINDING] and [MITM].
如果EAP被隧道在另一个忽略对等身份验证的协议中，则存在中间人攻击的潜在漏洞。有关详细信息，请参见[BINDING]和[MITM]。
As noted in Section 2.1, EAP does not permit untunneled sequences of authentication methods. Were a sequence of EAP authentication methods to be permitted, the peer might not have proof that a single entity has acted as the authenticator for all EAP methods within the sequence. For example, an authenticator might terminate one EAP method, then forward the next method in the sequence to another party without the peer's knowledge or consent. Similarly, the authenticator might not have proof that a single entity has acted as the peer for all EAP methods within the sequence.
如第2.1节所述，EAP不允许未删减的认证方法序列。如果允许一系列EAP身份验证方法，则对等方可能无法证明该序列中的所有EAP方法都有一个实体作为身份验证方。例如，身份验证器可能会终止一个EAP方法，然后将序列中的下一个方法转发给另一方，而无需对等方知道或同意。类似地，身份验证器可能无法证明单个实体已充当序列中所有EAP方法的对等方。
Tunneling EAP within another protocol enables an attack by a rogue EAP authenticator tunneling EAP to a legitimate server. Where the tunneling protocol is used for key establishment but does not require peer authentication, an attacker convincing a legitimate peer to connect to it will be able to tunnel EAP packets to a legitimate server, successfully authenticating and obtaining the key. This allows the attacker to successfully establish itself as a man-in-the-middle, gaining access to the network, as well as the ability to decrypt data traffic between the legitimate peer and server.
在另一个协议中通过隧道传输EAP使流氓EAP身份验证程序能够通过隧道传输EAP到合法服务器进行攻击。当隧道协议用于密钥建立但不需要对等身份验证时，攻击者说服合法对等方连接到该协议将能够将EAP数据包隧道到合法服务器，从而成功地验证和获取密钥。这使得攻击者能够成功地将自己建立为中间人，获得对网络的访问权，并能够解密合法对等方和服务器之间的数据通信。
This attack may be mitigated by the following measures:
可通过以下措施减轻此攻击：
[a] Requiring mutual authentication within EAP tunneling mechanisms.
[a] 需要EAP隧道机制内的相互认证。
[b] Requiring cryptographic binding between the EAP tunneling protocol and the tunneled EAP methods. Where cryptographic binding is supported, a mechanism is also needed to protect against downgrade attacks that would bypass it. For further details on cryptographic binding, see [BINDING].
[b] 需要EAP隧道协议和隧道EAP方法之间的加密绑定。在支持加密绑定的情况下，还需要一种机制来防止绕过它的降级攻击。有关加密绑定的更多详细信息，请参阅[binding]。
[c] Limiting the EAP methods authorized for use without protection, based on peer and authenticator policy.
[c] 基于对等方和身份验证方策略，限制授权使用且不受保护的EAP方法。
[d] Avoiding the use of tunnels when a single, strong method is available.
[d] 当有单一的、强有力的方法可用时，避免使用隧道。
While EAP methods may support per-packet data origin authentication, integrity, and replay protection, support is not provided within the EAP layer.
虽然EAP方法可能支持每包数据源身份验证、完整性和重播保护，但EAP层中不提供支持。
Since the Identifier is only a single octet, it is easy to guess, allowing an attacker to successfully inject or replay EAP packets. An attacker may also modify EAP headers (Code, Identifier, Length, Type) within EAP packets where the header is unprotected. This could cause packets to be inappropriately discarded or misinterpreted.
由于标识符只有一个八位组，因此很容易猜测，从而允许攻击者成功注入或重放EAP数据包。攻击者还可以修改EAP数据包中未受保护的EAP头（代码、标识符、长度、类型）。这可能导致数据包被不适当地丢弃或误解。
To protect EAP packets against modification, spoofing, or replay, methods supporting protected ciphersuite negotiation, mutual authentication, and key derivation, as well as integrity and replay protection, are recommended. See Section 7.2.1 for definitions of these security claims.
为了保护EAP数据包免受修改、欺骗或重播，建议使用支持受保护密码套件协商、相互认证和密钥派生以及完整性和重播保护的方法。这些担保债权的定义见第7.2.1节。
Method-specific MICs may be used to provide protection. If a per-packet MIC is employed within an EAP method, then peers, authentication servers, and authenticators not operating in pass-through mode MUST validate the MIC. MIC validation failures SHOULD be logged. Whether a MIC validation failure is considered a fatal error or not is determined by the EAP method specification.
方法特定的MIC可用于提供保护。如果EAP方法中采用了每包MIC，则未在直通模式下运行的对等方、身份验证服务器和身份验证程序必须验证该MIC。应记录MIC验证失败。MIC验证失败是否被视为致命错误取决于EAP方法规范。
It is RECOMMENDED that methods providing integrity protection of EAP packets include coverage of all the EAP header fields, including the Code, Identifier, Length, Type, and Type-Data fields.
建议提供EAP数据包完整性保护的方法包括覆盖所有EAP头字段，包括代码、标识符、长度、类型和类型数据字段。
Since EAP messages of Types Identity, Notification, and Nak do not include their own MIC, it may be desirable for the EAP method MIC to cover information contained within these messages, as well as the header of each EAP message.
由于标识、通知和Nak类型的EAP消息不包括它们自己的MIC，因此EAP方法MIC可能需要覆盖这些消息中包含的信息以及每个EAP消息的报头。
To provide protection, EAP also may be encapsulated within a protected channel created by protocols such as ISAKMP [RFC2408], as is done in [IKEv2] or within TLS [RFC2246]. However, as noted in Section 7.4, EAP tunneling may result in a man-in-the-middle vulnerability.
为了提供保护，EAP还可以封装在由诸如ISAKMP[RFC2408]等协议创建的受保护信道中，如在[IKEv2]或TLS[RFC2246]中所做的。然而，如第7.4节所述，EAP隧道可能导致中间人脆弱性。
Existing EAP methods define message integrity checks (MICs) that cover more than one EAP packet. For example, EAP-TLS [RFC2716] defines a MIC over a TLS record that could be split into multiple fragments; within the FINISHED message, the MIC is computed over previous messages. Where the MIC covers more than one EAP packet, a MIC validation failure is typically considered a fatal error.
现有的EAP方法定义覆盖多个EAP数据包的消息完整性检查（MIC）。例如，EAP-TLS[RFC2716]定义了可拆分为多个片段的TLS记录上的MIC；在完成的消息中，将根据以前的消息计算MIC。当MIC覆盖多个EAP数据包时，MIC验证失败通常被视为致命错误。
Within EAP-TLS [RFC2716], a MIC validation failure is treated as a fatal error, since that is what is specified in TLS [RFC2246]. However, it is also possible to develop EAP methods that support per-packet MICs, and respond to verification failures by silently discarding the offending packet.
在EAP-TLS[RFC2716]中，MIC验证失败被视为致命错误，因为这是TLS[RFC2246]中规定的错误。然而，也可以开发支持每包MIC的EAP方法，并通过默默地丢弃有问题的包来响应验证失败。
In this document, descriptions of EAP message handling assume that per-packet MIC validation, where it occurs, is effectively performed as though it occurs before sending any responses or changing the state of the host which received the packet.
在本文档中，EAP消息处理的描述假设每个数据包的MIC验证（发生在哪里）被有效地执行，就好像它发生在发送任何响应或改变接收数据包的主机的状态之前一样。
Password authentication algorithms such as EAP-MD5, MS-CHAPv1
[RFC2433], and Kerberos V [RFC1510] are known to be vulnerable to
dictionary attacks. MS-CHAPv1 vulnerabilities are documented in
[PPTPv1]; MS-CHAPv2 vulnerabilities are documented in [PPTPv2];
Kerberos vulnerabilities are described in [KRBATTACK], [KRBLIM], and
[KERB4WEAK].
Password authentication algorithms such as EAP-MD5, MS-CHAPv1
[RFC2433], and Kerberos V [RFC1510] are known to be vulnerable to
dictionary attacks. MS-CHAPv1 vulnerabilities are documented in
[PPTPv1]; MS-CHAPv2 vulnerabilities are documented in [PPTPv2];
Kerberos vulnerabilities are described in [KRBATTACK], [KRBLIM], and
[KERB4WEAK].
In order to protect against dictionary attacks, authentication methods resistant to dictionary attacks (as defined in Section 7.2.1) are recommended.
为了防止字典攻击，建议使用抗字典攻击的身份验证方法（如第7.2.1节所定义）。
If an authentication algorithm is used that is known to be vulnerable to dictionary attacks, then the conversation may be tunneled within a protected channel in order to provide additional protection. However, as noted in Section 7.4, EAP tunneling may result in a man-in-the-middle vulnerability, and therefore dictionary attack resistant methods are preferred.
如果使用了已知易受字典攻击的身份验证算法，则可以在受保护的通道中对会话进行隧道传输，以提供额外的保护。然而，如第7.4节所述，EAP隧道可能导致中间人漏洞，因此首选字典攻击抵抗方法。
With EAP methods supporting one-way authentication, such as EAP-MD5, the peer does not authenticate the authenticator, making the peer vulnerable to attack by a rogue authenticator. Methods supporting mutual authentication (as defined in Section 7.2.1) address this vulnerability.
使用支持单向身份验证的EAP方法（如EAP-MD5），对等方不会对身份验证方进行身份验证，从而使对等方容易受到恶意身份验证方的攻击。支持相互认证的方法（如第7.2.1节所定义）解决了此漏洞。
In EAP there is no requirement that authentication be full duplex or that the same protocol be used in both directions. It is perfectly
在EAP中，不要求认证是全双工的，也不要求在两个方向上使用相同的协议。这是完美的
acceptable for different protocols to be used in each direction. This will, of course, depend on the specific protocols negotiated. However, in general, completing a single unitary mutual authentication is preferable to two one-way authentications, one in each direction. This is because separate authentications that are not bound cryptographically so as to demonstrate they are part of the same session are subject to man-in-the-middle attacks, as discussed in Section 7.4.
可接受在每个方向使用的不同协议。当然，这将取决于谈判的具体协议。然而，一般来说，完成单个单一的相互认证比两个单向认证（每个方向一个）更可取。这是因为，如第7.4节所述，未以加密方式绑定以证明它们是同一会话的一部分的单独身份验证会受到中间人攻击。
In a negotiation attack, the attacker attempts to convince the peer and authenticator to negotiate a less secure EAP method. EAP does not provide protection for Nak Response packets, although it is possible for a method to include coverage of Nak Responses within a method-specific MIC.
在协商攻击中，攻击者试图说服对等方和身份验证方协商不太安全的EAP方法。EAP不为Nak响应分组提供保护，尽管方法可以在特定于方法的MIC内包括Nak响应的覆盖。
Within or associated with each authenticator, it is not anticipated that a particular named peer will support a choice of methods. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set. Instead, for each named peer, there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method.
在每个验证器内或与之相关联的验证器中，预计特定的命名对等方不会支持方法的选择。这会使对等方容易受到攻击，这些攻击会协商集合中最不安全的方法。相反，对于每个命名的对等方，应该有一个用于验证该对等方名称的方法的指示。如果对等方需要在不同的情况下使用不同的身份验证方法，那么应该使用不同的身份，每个身份都只标识一种身份验证方法。
The interaction of EAP with lower layers such as PPP and IEEE 802 are highly implementation dependent.
EAP与较低层（如PPP和IEEE 802）的交互高度依赖于实现。
For example, upon failure of authentication, some PPP implementations do not terminate the link, instead limiting traffic in Network-Layer Protocols to a filtered subset, which in turn allows the peer the opportunity to update secrets or send mail to the network administrator indicating a problem. Similarly, while an authentication failure will result in denied access to the controlled port in [IEEE-802.1X], limited traffic may be permitted on the uncontrolled port.
例如，在身份验证失败时，一些PPP实现不会终止链路，而是将网络层协议中的通信量限制为过滤子集，这反过来允许对等方有机会更新机密或向网络管理员发送指示问题的邮件。类似地，虽然身份验证失败将导致对[IEEE-802.1X]中受控端口的访问被拒绝，但在非受控端口上可能允许有限的通信量。
In EAP there is no provision for retries of failed authentication. However, in PPP the LCP state machine can renegotiate the authentication protocol at any time, thus allowing a new attempt. Similarly, in IEEE 802.1X the Supplicant or Authenticator can re-authenticate at any time. It is recommended that any counters used for authentication failure not be reset until after successful authentication, or subsequent termination of the failed link.
在EAP中，没有关于重试失败的身份验证的规定。然而，在PPP中，LCP状态机可以随时重新协商身份验证协议，从而允许新的尝试。类似地，在IEEE 802.1X中，请求者或认证者可以随时重新认证。建议在成功验证或随后终止失败链接之前，不要重置用于验证失败的任何计数器。
It is possible for the peer and EAP server to mutually authenticate and derive keys. In order to provide keying material for use in a subsequently negotiated ciphersuite, an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets. EAP Methods deriving keys MUST provide for mutual authentication between the EAP peer and the EAP Server.
对等服务器和EAP服务器可以相互验证并派生密钥。为了提供在随后协商的密码套件中使用的密钥材料，支持密钥派生的EAP方法必须导出至少64个八位字节的主会话密钥（MSK）和至少64个八位字节的扩展主会话密钥（EMSK）。派生密钥的EAP方法必须提供EAP对等方和EAP服务器之间的相互身份验证。
The MSK and EMSK MUST NOT be used directly to protect data; however, they are of sufficient size to enable derivation of a AAA-Key subsequently used to derive Transient Session Keys (TSKs) for use with the selected ciphersuite. Each ciphersuite is responsible for specifying how to derive the TSKs from the AAA-Key.
MSK和EMSK不得直接用于保护数据；但是，它们的大小足以派生AAA密钥，该AAA密钥随后用于派生临时会话密钥（TSK），以与所选密码套件一起使用。每个密码套件负责指定如何从AAA密钥派生TSK。
The AAA-Key is derived from the keying material exported by the EAP method (MSK and EMSK). This derivation occurs on the AAA server. In many existing protocols that use EAP, the AAA-Key and MSK are equivalent, but more complicated mechanisms are possible (see [KEYFRAME] for details).
AAA密钥来自EAP方法导出的密钥材料（MSK和EMSK）。此派生发生在AAA服务器上。在许多使用EAP的现有协议中，AAA密钥和MSK是等效的，但可能存在更复杂的机制（有关详细信息，请参阅[KEYFRAME]）。
EAP methods SHOULD ensure the freshness of the MSK and EMSK, even in cases where one party may not have a high quality random number generator. A RECOMMENDED method is for each party to provide a nonce of at least 128 bits, used in the derivation of the MSK and EMSK.
EAP方法应确保MSK和EMSK的新鲜度，即使在一方可能没有高质量随机数生成器的情况下。推荐的方法是为各方提供至少128位的nonce，用于MSK和EMSK的推导。
EAP methods export the MSK and EMSK, but not Transient Session Keys so as to allow EAP methods to be ciphersuite and media independent. Keying material exported by EAP methods MUST be independent of the ciphersuite negotiated to protect data.
EAP方法导出MSK和EMSK，但不导出临时会话密钥，以便允许EAP方法独立于密码套件和媒体。EAP方法导出的密钥材料必须独立于为保护数据而协商的密码套件。
Depending on the lower layer, EAP methods may run before or after ciphersuite negotiation, so that the selected ciphersuite may not be known to the EAP method. By providing keying material usable with any ciphersuite, EAP methods can used with a wide range of ciphersuites and media.
根据较低的层，EAP方法可能在密码套件协商之前或之后运行，因此EAP方法可能不知道所选密码套件。通过提供可用于任何密码套件的键控材料，EAP方法可用于各种密码套件和介质。
In order to preserve algorithm independence, EAP methods deriving keys SHOULD support (and document) the protected negotiation of the ciphersuite used to protect the EAP conversation between the peer and server. This is distinct from the ciphersuite negotiated between the peer and authenticator, used to protect data.
为了保持算法独立性，派生密钥的EAP方法应支持（并记录）用于保护对等方和服务器之间EAP会话的密码套件的受保护协商。这与对等方和身份验证方之间协商的用于保护数据的密码套件不同。
The strength of Transient Session Keys (TSKs) used to protect data is ultimately dependent on the strength of keys generated by the EAP method. If an EAP method cannot produce keying material of sufficient strength, then the TSKs may be subject to a brute force
用于保护数据的临时会话密钥（TSK）的强度最终取决于EAP方法生成的密钥的强度。如果EAP方法无法产生足够强度的键控材料，则TSK可能会受到蛮力的影响
attack. In order to enable deployments requiring strong keys, EAP methods supporting key derivation SHOULD be capable of generating an MSK and EMSK, each with an effective key strength of at least 128 bits.
袭击为了支持需要强密钥的部署，支持密钥派生的EAP方法应该能够生成MSK和EMSK，每种方法的有效密钥强度至少为128位。
Methods supporting key derivation MUST demonstrate cryptographic separation between the MSK and EMSK branches of the EAP key hierarchy. Without violating a fundamental cryptographic assumption (such as the non-invertibility of a one-way function), an attacker recovering the MSK or EMSK MUST NOT be able to recover the other quantity with a level of effort less than brute force.
支持密钥派生的方法必须证明EAP密钥层次结构的MSK和EMSK分支之间的加密分离。在不违反基本密码假设（例如单向函数的不可逆性）的情况下，恢复MSK或EMSK的攻击者必须不能以低于蛮力的努力水平恢复其他数量。
Non-overlapping substrings of the MSK MUST be cryptographically separate from each other, as defined in Section 7.2.1. That is, knowledge of one substring MUST NOT help in recovering some other substring without breaking some hard cryptographic assumption. This is required because some existing ciphersuites form TSKs by simply splitting the AAA-Key to pieces of appropriate length. Likewise, non-overlapping substrings of the EMSK MUST be cryptographically separate from each other, and from substrings of the MSK.
如第7.2.1节所定义，MSK的非重叠子字符串必须以加密方式彼此分离。也就是说，一个子串的知识不能有助于在不打破某些硬密码假设的情况下恢复其他子串。这是必需的，因为一些现有密码套件通过简单地将AAA密钥拆分为适当长度的片段来形成TSK。同样，EMSK的非重叠子串必须以密码方式彼此分离，并且和MSK的子串分离。
The EMSK is reserved for future use and MUST remain on the EAP peer and EAP server where it is derived; it MUST NOT be transported to, or shared with, additional parties, or used to derive any other keys. (This restriction will be relaxed in a future document that specifies how the EMSK can be used.)
EMSK保留供将来使用，并且必须保留在其派生的EAP对等和EAP服务器上；不得将其传输给其他方或与其他方共享，或用于派生任何其他密钥。（这一限制将在未来的文件中放宽，该文件规定了如何使用EMSK。）
Since EAP does not provide for explicit key lifetime negotiation, EAP peers, authenticators, and authentication servers MUST be prepared for situations in which one of the parties discards the key state, which remains valid on another party.
由于EAP不提供明确的密钥生存期协商，因此EAP对等方、身份验证方和身份验证服务器必须为其中一方放弃密钥状态的情况做好准备，该状态在另一方仍然有效。
This specification does not provide detailed guidance on how EAP methods derive the MSK and EMSK, how the AAA-Key is derived from the MSK and/or EMSK, or how the TSKs are derived from the AAA-Key.
本规范未提供有关EAP方法如何派生MSK和EMSK、AAA密钥如何派生自MSK和/或EMSK、TSK如何派生自AAA密钥的详细指导。
The development and validation of key derivation algorithms is difficult, and as a result, EAP methods SHOULD re-use well established and analyzed mechanisms for key derivation (such as those specified in IKE [RFC2409] or TLS [RFC2246]), rather than inventing new ones. EAP methods SHOULD also utilize well established and analyzed mechanisms for MSK and EMSK derivation. Further details on EAP Key Derivation are provided within [KEYFRAME].
密钥推导算法的开发和验证是困难的，因此，EAP方法应该重新使用已建立和分析的密钥推导机制（如IKE[RFC2409]或TLS[RFC2246]中规定的机制），而不是发明新的机制。EAP方法还应利用成熟且经过分析的MSK和EMSK推导机制。[KEYFRAME]中提供了有关EAP密钥派生的更多详细信息。
If after the initial EAP authentication, data packets are sent without per-packet authentication, integrity, and replay protection, an attacker with access to the media can inject packets, "flip bits" within existing packets, replay packets, or even hijack the session completely. Without per-packet confidentiality, it is possible to snoop data packets.
如果在初始EAP身份验证之后，发送数据包时没有每个数据包的身份验证、完整性和重播保护，则具有媒体访问权限的攻击者可以在现有数据包中注入数据包、“翻转位”、重播数据包，甚至完全劫持会话。如果没有每个数据包的保密性，就有可能窥探数据包。
To protect against data modification, spoofing, or snooping, it is recommended that EAP methods supporting mutual authentication and key derivation (as defined by Section 7.2.1) be used, along with lower layers providing per-packet confidentiality, authentication, integrity, and replay protection.
为了防止数据修改、欺骗或窥探，建议使用支持相互认证和密钥派生（如第7.2.1节所定义）的EAP方法，以及提供每包机密性、认证、完整性和重播保护的较低层。
Additionally, if the lower layer performs ciphersuite negotiation, it should be understood that EAP does not provide by itself integrity protection of that negotiation. Therefore, in order to avoid downgrading attacks which would lead to weaker ciphersuites being used, clients implementing lower layer ciphersuite negotiation SHOULD protect against negotiation downgrading.
此外，如果较低层执行密码套件协商，则应理解EAP本身不提供该协商的完整性保护。因此，为了避免降级攻击，这将导致使用较弱的密码套件，实现较低层密码套件协商的客户端应防止协商降级。
This can be done by enabling users to configure which ciphersuites are acceptable as a matter of security policy, or the ciphersuite negotiation MAY be authenticated using keying material derived from the EAP authentication and a MIC algorithm agreed upon in advance by lower-layer peers.
这可以通过使用户能够配置哪些密码套件作为安全策略是可接受的来实现，或者可以使用来自EAP认证的密钥材料和较低层对等方事先同意的MIC算法来认证密码套件协商。
There are reliability and security issues with link layer indications in PPP, IEEE 802 LANs, and IEEE 802.11 wireless LANs:
PPP、IEEE 802 LAN和IEEE 802.11无线LAN中的链路层指示存在可靠性和安全性问题：
[a] PPP. In PPP, link layer indications such as LCP-Terminate (a link failure indication) and NCP (a link success indication) are not authenticated or integrity protected. They can therefore be spoofed by an attacker with access to the link.
[a] 购买力平价。在PPP中，诸如LCP Terminate（链路故障指示）和NCP（链路成功指示）等链路层指示未经身份验证或完整性保护。因此，具有链接访问权限的攻击者可以欺骗它们。
[b] IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames are not authenticated or integrity protected. They can therefore be spoofed by an attacker with access to the link.
[b] IEEE 802。IEEE 802.1X EAPOL启动和EAPOL注销帧未经过身份验证或完整性保护。因此，具有链接访问权限的攻击者可以欺骗它们。
[c] IEEE 802.11. In IEEE 802.11, link layer indications include Disassociate and Deauthenticate frames (link failure indications), and the first message of the 4-way handshake (link success indication). These messages are not authenticated or integrity protected, and although they are not forwardable, they are spoofable by an attacker within range.
[c] IEEE 802.11。在IEEE 802.11中，链路层指示包括解除关联和取消验证帧（链路故障指示）以及4路握手的第一条消息（链路成功指示）。这些消息未经身份验证或完整性保护，尽管它们不可转发，但在攻击范围内可被攻击者伪造。
In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3 unicast data frames, and are therefore forwardable. This implies that while EAPOL-Start and EAPOL-Logoff messages may be authenticated and integrity protected, they can be spoofed by an authenticated attacker far from the target when "pre-authentication" is enabled.
在IEEE 802.11中，IEEE 802.1X数据帧可以作为第3类单播数据帧发送，因此是可转发的。这意味着，虽然EAPOL启动和EAPOL注销消息可能经过身份验证并受到完整性保护，但在启用“预身份验证”时，经过身份验证的攻击者可能会在远离目标的地方欺骗这些消息。
In IEEE 802.11, a "link down" indication is an unreliable indication of link failure, since wireless signal strength can come and go and may be influenced by radio frequency interference generated by an attacker. To avoid unnecessary resets, it is advisable to damp these indications, rather than passing them directly to the EAP. Since EAP supports retransmission, it is robust against transient connectivity losses.
在IEEE 802.11中，“链路断开”指示是链路故障的不可靠指示，因为无线信号强度可能来来往往，并可能受到攻击者产生的射频干扰的影响。为避免不必要的复位，建议抑制这些指示，而不是将其直接传递给EAP。由于EAP支持重传，因此它对瞬时连接丢失具有鲁棒性。
It is possible for the EAP peer and EAP server to mutually authenticate and derive a AAA-Key for a ciphersuite used to protect subsequent data traffic. This does not present an issue on the peer, since the peer and EAP client reside on the same machine; all that is required is for the client to derive the AAA-Key from the MSK and EMSK exported by the EAP method, and to subsequently pass a Transient Session Key (TSK) to the ciphersuite module.
EAP对等方和EAP服务器可以相互认证并为用于保护后续数据流量的密码套件派生AAA密钥。这不会在对等机上出现问题，因为对等机和EAP客户端位于同一台机器上；客户端只需从EAP方法导出的MSK和EMSK中导出AAA密钥，然后将临时会话密钥（TSK）传递给密码套件模块。
However, in the case where the authenticator and authentication server reside on different machines, there are several implications for security.
但是，在身份验证程序和身份验证服务器驻留在不同机器上的情况下，存在几个安全问题。
[a] Authentication will occur between the peer and the authentication server, not between the peer and the authenticator. This means that it is not possible for the peer to validate the identity of the authenticator that it is speaking to, using EAP alone.
[a] 身份验证将发生在对等方和身份验证服务器之间，而不是对等方和身份验证程序之间。这意味着，对等方不可能单独使用EAP来验证与之对话的身份验证者的身份。
[b] As discussed in [RFC3579], the authenticator is dependent on the AAA protocol in order to know the outcome of an authentication conversation, and does not look at the encapsulated EAP packet (if one is present) to determine the outcome. In practice, this implies that the AAA protocol spoken between the authenticator and authentication server MUST support per-packet authentication, integrity, and replay protection.
[b] 如[RFC3579]中所述，认证器依赖于AAA协议以了解认证对话的结果，并且不查看封装的EAP数据包（如果存在）以确定结果。实际上，这意味着身份验证程序和身份验证服务器之间的AAA协议必须支持每包身份验证、完整性和重播保护。
[c] After completion of the EAP conversation, where lower layer security services such as per-packet confidentiality, authentication, integrity, and replay protection will be enabled, a secure association protocol SHOULD be run between the peer and authenticator in order to provide mutual authentication between
[c] EAP对话完成后，将启用低层安全服务，如每包机密性、身份验证、完整性和重播保护，应在对等方和身份验证方之间运行安全关联协议，以便在对等方和身份验证方之间提供相互身份验证
the peer and authenticator, guarantee liveness of transient session keys, provide protected ciphersuite and capabilities negotiation for subsequent data, and synchronize key usage.
对等方和身份验证器，保证临时会话密钥的活跃性，为后续数据提供受保护的密码套件和协商功能，并同步密钥使用。
[d] A AAA-Key derived from the MSK and/or EMSK negotiated between the peer and authentication server MAY be transmitted to the authenticator. Therefore, a mechanism needs to be provided to transmit the AAA-Key from the authentication server to the authenticator that needs it. The specification of the AAA-key derivation, transport, and wrapping mechanisms is outside the scope of this document. Further details on AAA-Key Derivation are provided within [KEYFRAME].
[d] 从对等方和认证服务器之间协商的MSK和/或EMSK导出的AAA密钥可被发送到认证器。因此，需要提供一种机制来将AAA密钥从认证服务器传输到需要它的认证者。AAA密钥派生、传输和包装机制的规范不在本文档的范围内。[KEYFRAME]中提供了有关AAA密钥派生的更多详细信息。
This specification does not define a mechanism for cleartext password authentication. The omission is intentional. Use of cleartext passwords would allow the password to be captured by an attacker with access to a link over which EAP packets are transmitted.
本规范未定义明文密码验证机制。遗漏是故意的。使用明文密码将允许攻击者通过访问EAP数据包传输的链路捕获密码。
Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not provide confidentiality, EAP packets may be subsequently encapsulated for transport over the Internet where they may be captured by an attacker.
由于封装EAP的协议（如RADIUS[RFC3579]）可能无法提供机密性，因此EAP数据包可能随后被封装以在互联网上传输，攻击者可能会在互联网上捕获这些数据包。
As a result, cleartext passwords cannot be securely used within EAP, except where encapsulated within a protected tunnel with server authentication. Some of the same risks apply to EAP methods without dictionary attack resistance, as defined in Section 7.2.1. For details, see Section 7.6.
因此，明文密码不能在EAP中安全使用，除非封装在具有服务器身份验证的受保护隧道中。如第7.2.1节所述，一些相同的风险适用于无字典攻击抵抗能力的EAP方法。有关详细信息，请参见第7.6节。
It is possible for a compromised or poorly implemented EAP authenticator to communicate incorrect information to the EAP peer and/or server. This may enable an authenticator to impersonate another authenticator or communicate incorrect information via out-of-band mechanisms (such as via a AAA or lower layer protocol).
被破坏或实施不当的EAP验证器有可能向EAP对等方和/或服务器传递不正确的信息。这可能使验证器能够模拟另一验证器，或通过带外机制（例如通过AAA或较低层协议）传递不正确的信息。
Where EAP is used in pass-through mode, the EAP peer typically does not verify the identity of the pass-through authenticator, it only verifies that the pass-through authenticator is trusted by the EAP server. This creates a potential security vulnerability.
在通过模式下使用EAP的情况下，EAP对等方通常不验证通过身份验证器的身份，它只验证通过身份验证器是否受EAP服务器的信任。这会造成潜在的安全漏洞。
Section 4.3.7 of [RFC3579] describes how an EAP pass-through authenticator acting as a AAA client can be detected if it attempts to impersonate another authenticator (such by sending incorrect NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
[RFC3579]第4.3.7节描述了当EAP直通身份验证程序试图模拟另一身份验证程序时（例如通过发送错误的NAS标识符[RFC2865]、NAS IP地址[RFC2865]或NAS-IPv6-Address），如何检测充当AAA客户端的EAP直通身份验证程序
[RFC3162] attributes via the AAA protocol). However, it is possible for a pass-through authenticator acting as a AAA client to provide correct information to the AAA server while communicating misleading information to the EAP peer via a lower layer protocol.
[RFC3162]属性（通过AAA协议）。然而，作为AAA客户端的直通认证器可以向AAA服务器提供正确的信息，同时通过较低层协议向EAP对等方传送误导性信息。
For example, it is possible for a compromised authenticator to utilize another authenticator's Called-Station-Id or NAS-Identifier in communicating with the EAP peer via a lower layer protocol, or for a pass-through authenticator acting as a AAA client to provide an incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA server via the AAA protocol.
例如，在通过较低层协议与EAP对等方通信时，受损认证方可能利用另一认证方的被叫站Id或NAS标识符，或者作为AAA客户端的直通认证方可能提供不正确的对等呼叫站Id[RFC2865][RFC3580]通过AAA协议连接到AAA服务器。
In order to address this vulnerability, EAP methods may support a protected exchange of channel properties such as endpoint identifiers, including (but not limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162].
为了解决此漏洞，EAP方法可能支持受保护的信道属性交换，例如端点标识符，包括（但不限于）：被叫站Id[RFC2865][RFC3580]、主叫站Id[RFC2865][RFC3580]、NAS标识符[RFC2865]、NAS IP地址[RFC2865]和NAS-IPv6-address[RFC3162]。
Using such a protected exchange, it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method. Where discrepancies are found, these SHOULD be logged; additional actions MAY also be taken, such as denying access.
使用这种受保护的交换，可以将认证器通过带外机制提供的信道属性与EAP方法内交换的信道属性相匹配。如果发现差异，应记录这些差异；还可以采取其他措施，例如拒绝访问。
Within EAP, Success and Failure packets are neither acknowledged nor integrity protected. Result indications improve resilience to loss of Success and Failure packets when EAP is run over lower layers which do not support retransmission or synchronization of the authentication state. In media such as IEEE 802.11, which provides for retransmission, as well as synchronization of authentication state via the 4-way handshake defined in [IEEE-802.11i], additional resilience is typically of marginal benefit.
在EAP中，成功和失败数据包既不被确认，也不受完整性保护。当EAP在不支持重新传输或身份验证状态同步的较低层上运行时，结果指示提高了对成功和失败数据包丢失的恢复能力。在诸如IEEE 802.11这样的媒体中，它提供了重传，以及通过[IEEE-802.11i]中定义的4路握手来同步认证状态，额外的弹性通常是边际效益。
Depending on the method and circumstances, result indications can be spoofable by an attacker. A method is said to provide protected result indications if it supports result indications, as well as the "integrity protection" and "replay protection" claims. A method supporting protected result indications MUST indicate which result indications are protected, and which are not.
根据方法和情况，攻击者可能会伪造结果指示。如果一种方法支持结果指示以及“完整性保护”和“重放保护”声明，则该方法可以提供受保护的结果指示。支持受保护结果指示的方法必须指明哪些结果指示受保护，哪些不受保护。
Protected result indications are not required to protect against rogue authenticators. Within a mutually authenticating method, requiring that the server authenticate to the peer before the peer will accept a Success packet prevents an attacker from acting as a rogue authenticator.
不需要受保护的结果指示来防止流氓身份验证程序。在相互身份验证方法中，要求服务器在对等方接受成功数据包之前向对等方进行身份验证，以防止攻击者充当恶意身份验证者。
However, it is possible for an attacker to forge a Success packet after the server has authenticated to the peer, but before the peer has authenticated to the server. If the peer were to accept the forged Success packet and attempt to access the network when it had not yet successfully authenticated to the server, a denial of service attack could be mounted against the peer. After such an attack, if the lower layer supports failure indications, the authenticator can synchronize state with the peer by providing a lower layer failure indication. See Section 7.12 for details.
但是，攻击者有可能在服务器向对等方进行身份验证之后，但在对等方向服务器进行身份验证之前伪造成功数据包。如果对等方接受伪造的成功数据包，并在其尚未成功通过服务器身份验证时尝试访问网络，则可能对对等方发起拒绝服务攻击。在这种攻击之后，如果较低层支持故障指示，则认证器可以通过提供较低层故障指示来与对等方同步状态。详见第7.12节。
If a server were to authenticate the peer and send a Success packet prior to determining whether the peer has authenticated the authenticator, an idle timeout can occur if the authenticator is not authenticated by the peer. Where supported by the lower layer, an authenticator sensing the absence of the peer can free resources.
如果服务器在确定对等方是否已对验证器进行身份验证之前对对等方进行身份验证并发送成功数据包，则如果对等方未对验证器进行身份验证，则可能会发生空闲超时。在较低层支持的情况下，检测到缺少对等方的认证器可以释放资源。
In a method supporting result indications, a peer that has authenticated the server does not consider the authentication successful until it receives an indication that the server successfully authenticated it. Similarly, a server that has successfully authenticated the peer does not consider the authentication successful until it receives an indication that the peer has authenticated the server.
在支持结果指示的方法中，已认证服务器的对等者不认为认证成功，直到它接收到服务器成功认证它的指示。类似地，已经成功认证对等体的服务器不认为认证成功，直到它接收到对等体已经验证服务器的指示。
In order to avoid synchronization problems, prior to sending a success result indication, it is desirable for the sender to verify that sufficient authorization exists for granting access, though, as discussed below, this is not always possible.
为了避免同步问题，在发送成功结果指示之前，发送方需要验证是否存在足够的授权来授予访问权限，尽管如下文所述，这并不总是可能的。
While result indications may enable synchronization of the authentication result between the peer and server, this does not guarantee that the peer and authenticator will be synchronized in terms of their authorization or that timeouts will not occur. For example, the EAP server may not be aware of an authorization decision made by a AAA proxy; the AAA server may check authorization only after authentication has completed successfully, to discover that authorization cannot be granted, or the AAA server may grant access but the authenticator may be unable to provide it due to a temporary lack of resources. In these situations, synchronization may only be achieved via lower layer result indications.
虽然结果指示可以使对等方和服务器之间的身份验证结果同步，但这并不保证对等方和身份验证方将在其授权方面同步，或者不会发生超时。例如，EAP服务器可能不知道由AAA代理作出的授权决定；AAA服务器可以仅在认证成功完成后检查授权，以发现无法授予授权，或者AAA服务器可以授予访问权限，但认证者可能由于暂时缺乏资源而无法提供访问权限。在这些情况下，只能通过较低层的结果指示来实现同步。
Success indications may be explicit or implicit. For example, where a method supports error messages, an implicit success indication may be defined as the reception of a specific message without a preceding error message. Failures are typically indicated explicitly. As described in Section 4.2, a peer silently discards a Failure packet received at a point where the method does not explicitly permit this
成功的迹象可能是明确的或隐含的。例如，在方法支持错误消息的情况下，隐式成功指示可定义为在没有先前错误消息的情况下接收特定消息。通常会明确指出故障。如第4.2节所述，对等方在方法不明确允许的情况下，悄悄地丢弃接收到的故障数据包
to be sent. For example, a method providing its own error messages might require the peer to receive an error message prior to accepting a Failure packet.
待发送。例如，提供自身错误消息的方法可能要求对等方在接受失败数据包之前接收错误消息。
Per-packet authentication, integrity, and replay protection of result indications protects against spoofing. Since protected result indications require use of a key for per-packet authentication and integrity protection, methods supporting protected result indications MUST also support the "key derivation", "mutual authentication", "integrity protection", and "replay protection" claims.
结果指示的每包身份验证、完整性和重播保护可防止欺骗。由于受保护的结果指示需要使用密钥进行每包身份验证和完整性保护，因此支持受保护结果指示的方法还必须支持“密钥派生”、“相互身份验证”、“完整性保护”和“重播保护”声明。
Protected result indications address some denial-of-service vulnerabilities due to spoofing of Success and Failure packets, though not all. EAP methods can typically provide protected result indications only in some circumstances. For example, errors can occur prior to key derivation, and so it may not be possible to protect all failure indications. It is also possible that result indications may not be supported in both directions or that synchronization may not be achieved in all modes of operation.
受保护的结果指示解决了由于欺骗成功和失败数据包而导致的一些拒绝服务漏洞，尽管并非全部。EAP方法通常只能在某些情况下提供受保护的结果指示。例如，错误可能发生在密钥派生之前，因此可能无法保护所有故障指示。也可能在两个方向上都不支持结果指示，或者在所有操作模式下都无法实现同步。
For example, within EAP-TLS [RFC2716], in the client authentication handshake, the server authenticates the peer, but does not receive a protected indication of whether the peer has authenticated it. In contrast, the peer authenticates the server and is aware of whether the server has authenticated it. In the session resumption handshake, the peer authenticates the server, but does not receive a protected indication of whether the server has authenticated it. In this mode, the server authenticates the peer and is aware of whether the peer has authenticated it.
例如，在EAP-TLS[RFC2716]中，在客户端身份验证握手中，服务器对对等方进行身份验证，但不接收对等方是否已对其进行身份验证的受保护指示。相反，对等方对服务器进行身份验证，并知道服务器是否对其进行了身份验证。在会话恢复握手中，对等方对服务器进行身份验证，但不会收到服务器是否已对其进行身份验证的受保护指示。在此模式下，服务器对对等方进行身份验证，并知道对等方是否对其进行了身份验证。
This protocol derives much of its inspiration from Dave Carrel's AHA document, as well as the PPP CHAP protocol [RFC1994]. Valuable feedback was provided by Yoshihiro Ohba of Toshiba America Research, Jari Arkko of Ericsson, Sachin Seth of Microsoft, Glen Zorn of Cisco Systems, Jesse Walker of Intel, Bill Arbaugh, Nick Petroni and Bryan Payne of the University of Maryland, Steve Bellovin of AT&T Research, Paul Funk of Funk Software, Pasi Eronen of Nokia, Joseph Salowey of Cisco, Paul Congdon of HP, and members of the EAP working group.
该协议的大部分灵感来自Dave Carrel的AHA文档以及PPP CHAP协议[RFC1994]。东芝美国研究公司的Yoshihiro Ohba、爱立信的JARI ARKO、微软的Sachin Seth、思科系统公司的Glen Zorn、英特尔的Jesse Walker、Bill Arbaugh、Nick Petroni和Bryan Payne的马里兰大学、诺基亚的芬克软件公司的AT&T研究所提供了有价值的反馈。思科的Joseph Salowey、惠普的Paul Congdon以及EAP工作组的成员。
The use of Security Claims sections for EAP methods, as required by Section 7.2 and specified for each EAP method described in this document, was inspired by Glen Zorn through [EAP-EVAL].
根据第7.2节的要求以及本文件中所述的每种EAP方法的规定，对EAP方法使用安全索赔章节是受Glen Zorn通过[EAP-EVAL]的启发。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[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月。
[RFC2243] Metz, C., "OTP Extended Responses", RFC 2243, November 1997.
[RFC2243]Metz，C.，“OTP扩展响应”，RFC 2243，1997年11月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2279]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time Password System", RFC 2289, February 1998.
[RFC2289]Haller，N.，Metz，C.，Nesser，P.和M.Straw，“一次性密码系统”，RFC 2289，1998年2月。
[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月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[IEEE-802] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Overview and Architecture", IEEE Standard 802, 1990.
[IEEE-802]电气和电子工程师协会，“局域网和城域网：概述和体系结构”，IEEE标准802，1990年。
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001.
[IEEE-802.1X]电气和电子工程师协会，“局域网和城域网：基于端口的网络访问控制”，IEEE标准802.1X，2001年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510]Kohl，J.和B.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年9月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]Eastlake，D.，Crocker，S.和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.，Allen，C.，Treese，W.，Karlton，P.，Freier，A.和P.Kocher，“TLS协议版本1.0”，RFC 2246，1999年1月。
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2284]Blunk，L.和J.Vollbrecht，“PPP可扩展认证协议（EAP）”，RFC 2284，1998年3月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486]Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
[RFC2408] Maughan, D., Schneider, M. and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408]Maughan，D.，Schneider，M.和M.Schertler，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.
[RFC2433]Zorn，G.和S.Cobb，“微软PPP CHAP扩展”，RFC 2433，1998年10月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607]Aboba，B.和J.Vollbrecht，“漫游中的代理链接和策略实施”，RFC 2607，1999年6月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[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月。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162]Aboba，B.，Zorn，G.和D.Mitton，“RADIUS和IPv6”，RFC 3162，2001年8月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化弦的准备（“stringprep”）”，RFC 3454，2002年12月。
[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月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580]Congdon，P.，Aboba，B.，Smith，A.，Zorn，G.和J.Roese，“IEEE 802.1X远程认证拨入用户服务（RADIUS）使用指南”，RFC 35802003年9月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[DECEPTION] Slatalla, M. and J. Quittner, "Masters of Deception", Harper-Collins, New York, 1995.
[欺骗]Slatalla，M.和J.Quittner，“欺骗大师”，哈珀·柯林斯，纽约，1995年。
[KRBATTACK] Wu, T., "A Real-World Analysis of Kerberos Password Security", Proceedings of the 1999 ISOC Network and Distributed System Security Symposium, http://www.isoc.org/isoc/conferences/ndss/99/ proceedings/papers/wu.pdf.
[KRBATTACK]Wu，T.，“Kerberos密码安全的真实世界分析”，1999年ISOC网络和分布式系统安全研讨会论文集，http://www.isoc.org/isoc/conferences/ndss/99/ 会议记录/论文/wu.pdf。
[KRBLIM] Bellovin, S. and M. Merrit, "Limitations of the Kerberos authentication system", Proceedings of the 1991 Winter USENIX Conference, pp. 253-267, 1991.
[KRBLIM]Bellovin，S.和M.Merrit，“Kerberos身份验证系统的局限性”，1991年冬季USENIX会议记录，第253-267页，1991年。
[KERB4WEAK] Dole, B., Lodin, S. and E. Spafford, "Misplaced trust: Kerberos 4 session keys", Proceedings of the Internet Society Network and Distributed System Security Symposium, pp. 60-70, March 1997.
[KERB4WEAK]Dole，B.，Lodin，S.和E.Spafford，“错位信任：Kerberos 4会话密钥”，《互联网社会网络和分布式系统安全研讨会论文集》，第60-70页，1997年3月。
[PIC] Aboba, B., Krawczyk, H. and Y. Sheffer, "PIC, A Pre-IKE Credential Provisioning Protocol", Work in Progress, October 2002.
[PIC]Aboba，B.，Krawczyk，H.和Y.Sheffer，“PIC，一种IKE之前的凭证提供协议”，正在进行的工作，2002年10月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, January 2004.
[IKEv2]Kaufman，C.，“因特网密钥交换（IKEv2）协议”，正在进行的工作，2004年1月。
[PPTPv1] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's Point-to- Point Tunneling Protocol", Proceedings of the 5th ACM Conference on Communications and Computer Security, ACM Press, November 1998.
[PPTPv1]Schneier，B.和Mudge，“微软点对点隧道协议的密码分析”，第五届ACM通信和计算机安全会议记录，ACM出版社，1998年11月。
[IEEE-802.11] Institute of Electrical and Electronics Engineers, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11, 1999.
[IEEE-802.11]电气和电子工程师协会，“无线局域网介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.111999。
[SILVERMAN] Silverman, Robert D., "A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths", RSA Laboratories Bulletin 13, April 2000 (Revised November 2001), http://www.rsasecurity.com/rsalabs/bulletins/ bulletin13.html.
[SILVERMAN]SILVERMAN，Robert D.，“对称和非对称密钥长度的基于成本的安全分析”，RSA实验室公告13，2000年4月（2001年11月修订），http://www.rsasecurity.com/rsalabs/bulletins/ bulletin13.html。
[KEYFRAME] Aboba, B., "EAP Key Management Framework", Work in Progress, October 2003.
[KEYFRAME]Aboba，B.，“EAP密钥管理框架”，正在进行的工作，2003年10月。
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep profile for user names and passwords", Work in Progress, March 2004.
[SASLPREP]Zeilenga，K.，“SASLPREP:Stringprep用户名和密码配置文件”，正在进行的工作，2004年3月。
[IEEE-802.11i] Institute of Electrical and Electronics Engineers, "Unapproved Draft Supplement to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", IEEE Draft 802.11i (work in progress), 2003.
[IEEE-802.11i]电气和电子工程师协会，“系统间电信和信息交换标准未经批准的补充草案-局域网/城域网特定要求-第11部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范：增强安全规范”，IEEE 802.11i草案（正在进行的工作），2003年。
[DIAM-EAP] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", Work in Progress, February 2004.
[DIAM-EAP]Eronen，P.，Hiller，T.和G.Zorn，“Diameter可扩展认证协议（EAP）应用程序”，正在进行的工作，2004年2月。
[EAP-EVAL] Zorn, G., "Specifying Security Claims for EAP Authentication Types", Work in Progress, October 2002.
[EAP-EVAL]Zorn，G.，“为EAP认证类型指定安全声明”，正在进行的工作，2002年10月。
[BINDING] Puthenkulam, J., "The Compound Authentication Binding Problem", Work in Progress, October 2003.
[BINDING]Puthenkulam，J.，“复合认证绑定问题”，正在进行的工作，2003年10月。
[MITM] Asokan, N., Niemi, V. and K. Nyberg, "Man-in-the-Middle in Tunneled Authentication Protocols", IACR ePrint Archive Report 2002/163, October 2002, <http://eprint.iacr.org/2002/163>.
[MITM]Asokan，N.，Niemi，V.和K.Nyberg，“隧道认证协议中的中间人”，IACR ePrint存档报告2002/163，2002年10月<http://eprint.iacr.org/2002/163>.
[IEEE-802.11i-req] Stanley, D., "EAP Method Requirements for Wireless LANs", Work in Progress, February 2004.
[IEEE-802.11i-req]Stanley，D.，“无线局域网的EAP方法要求”，正在进行的工作，2004年2月。
[PPTPv2] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)", CQRE 99, Springer-Verlag, 1999, pp. 192-203.
[PPTPv2]Schneier，B.和Mudge，“微软PPTP认证扩展的密码分析（MS-CHAPv2）”，CQRE 99，Springer Verlag，1999，第192-203页。
This section lists the major changes between [RFC2284] and this document. Minor changes, including style, grammar, spelling, and editorial changes are not mentioned here.
本节列出了[RFC2284]与本文件之间的主要变更。此处未提及包括样式、语法、拼写和编辑更改在内的细微更改。
o The Terminology section (Section 1.2) has been expanded, defining more concepts and giving more exact definitions.
o 术语部分（第1.2节）已经扩展，定义了更多的概念并给出了更准确的定义。
o The concepts of Mutual Authentication, Key Derivation, and Result Indications are introduced and discussed throughout the document where appropriate.
o 在适当的情况下，在整个文档中介绍和讨论了相互认证、密钥派生和结果指示的概念。
o In Section 2, it is explicitly specified that more than one exchange of Request and Response packets may occur as part of the EAP authentication exchange. How this may be used and how it may not be used is specified in detail in Section 2.1.
o 在第2节中，明确规定，作为EAP认证交换的一部分，可以进行一次以上的请求和响应数据包交换。第2.1节详细说明了如何使用和如何不使用。
o Also in Section 2, some requirements have been made explicit for the authenticator when acting in pass-through mode.
o 同样在第2节中，对认证者在传递模式下的行为提出了明确的要求。
o An EAP multiplexing model (Section 2.2) has been added to illustrate a typical implementation of EAP. There is no requirement that an implementation conform to this model, as long as the on-the-wire behavior is consistent with it.
o 添加了EAP多路复用模型（第2.2节），以说明EAP的典型实现。只要在线行为与此模型一致，就不要求实现符合此模型。
o As EAP is now in use with a variety of lower layers, not just PPP for which it was first designed, Section 3 on lower layer behavior has been added.
o 由于EAP现在用于各种较低层，而不仅仅是它最初设计的PPP，因此增加了关于较低层行为的第3节。
o In the description of the EAP Request and Response interaction (Section 4.1), both the behavior on receiving duplicate requests, and when packets should be silently discarded has been more exactly specified. The implementation notes in this section have been substantially expanded.
o 在EAP请求和响应交互的描述（第4.1节）中，对接收重复请求的行为以及何时应该静默丢弃数据包进行了更精确的说明。本节中的实施说明已大幅扩展。
o In Section 4.2, it has been clarified that Success and Failure packets must not contain additional data, and the implementation note has been expanded. A subsection giving requirements on processing of success and failure packets has been added.
o 在第4.2节中，已经澄清了成功和失败数据包不得包含额外数据，并且扩展了实施说明。增加了一个小节，给出了处理成功和失败数据包的要求。
o Section 5 on EAP Request/Response Types lists two new Type values: the Expanded Type (Section 5.7), which is used to expand the Type value number space, and the Experimental Type. In the Expanded Type number space, the new Expanded Nak (Section 5.3.2) Type has been added. Clarifications have been made in the description of most of the existing Types. Security claims summaries have been added for authentication methods.
o 关于EAP请求/响应类型的第5节列出了两个新的类型值：用于扩展类型值编号空间的扩展类型（第5.7节）和实验类型。在扩展类型编号空间中，添加了新的扩展Nak（第5.3.2节）类型。在大多数现有类型的说明中进行了澄清。已为身份验证方法添加了安全声明摘要。
o In Sections 5, 5.1, and 5.2, a requirement has been added such that fields with displayable messages should contain UTF-8 encoded ISO 10646 characters.
o 在第5、5.1和5.2节中，增加了一项要求，即具有可显示消息的字段应包含UTF-8编码的ISO 10646字符。
o It is now required in Section 5.1 that if the Type-Data field of an Identity Request contains a NUL-character, only the part before the null is displayed. RFC 2284 prohibits the null termination of the Type-Data field of Identity messages. This rule has been relaxed for Identity Request messages and the Identity Request Type-Data field may now be null terminated.
o 第5.1节现在要求，如果身份请求的类型数据字段包含NUL字符，则仅显示null之前的部分。RFC 2284禁止标识消息的类型数据字段以null结尾。对于标识请求消息，此规则已放宽，标识请求类型数据字段现在可能以null结尾。
o In Section 5.5, support for OTP Extended Responses [RFC2243] has been added to EAP OTP.
o 在第5.5节中，EAP OTP中增加了对OTP扩展响应[RFC2243]的支持。
o An IANA Considerations section (Section 6) has been added, giving registration policies for the numbering spaces defined for EAP.
o 增加了IANA注意事项部分（第6节），给出了为EAP定义的编号空间的注册策略。
o The Security Considerations (Section 7) have been greatly expanded, giving a much more comprehensive coverage of possible threats and other security considerations.
o 安全考虑（第7节）已大大扩展，更全面地涵盖了可能的威胁和其他安全考虑。
o In Section 7.5, text has been added on method-specific behavior, providing guidance on how EAP method-specific integrity checks should be processed. Where possible, it is desirable for a method-specific MIC to be computed over the entire EAP packet, including the EAP layer header (Code, Identifier, Length) and EAP method layer header (Type, Type-Data).
o 在第7.5节中，增加了有关方法特定行为的文本，为如何处理EAP方法特定完整性检查提供了指导。在可能的情况下，希望在整个EAP分组上计算特定于方法的MIC，包括EAP层报头（代码、标识符、长度）和EAP方法层报头（类型、类型数据）。
o In Section 7.14 the security risks involved in use of cleartext passwords with EAP are described.
o 第7.14节描述了在EAP中使用明文密码所涉及的安全风险。
o In Section 7.15 text has been added relating to detection of rogue NAS behavior.
o 在第7.15节中，添加了与检测恶意NAS行为相关的文本。
Authors' Addresses
作者地址
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
伯纳德·阿博巴微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 706 6605
Fax: +1 425 936 6605
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 6605
EMail: bernarda@microsoft.com
Larry J. Blunk Merit Network, Inc 4251 Plymouth Rd., Suite 2000 Ann Arbor, MI 48105-2785 USA
美国密歇根州安阿伯市普利茅斯路4251号2000室拉里·J·布伦克美德网络公司，邮编：48105-2785
Phone: +1 734-647-9563
Fax: +1 734-647-3185
EMail: ljb@merit.edu
Phone: +1 734-647-9563
Fax: +1 734-647-3185
EMail: ljb@merit.edu
John R. Vollbrecht Vollbrecht Consulting LLC 9682 Alice Hill Drive Dexter, MI 48130 USA
美国密苏里州德克斯特市爱丽丝山大道9682号，邮编：48130
EMail: jrv@umich.edu
EMail: jrv@umich.edu
James Carlson Sun Microsystems, Inc 1 Network Drive Burlington, MA 01803-2757 USA
美国马萨诸塞州伯灵顿市网络大道1号詹姆斯·卡尔森太阳微系统公司01803-2757
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com
Henrik Levkowetz ipUnplugged AB Arenavagen 33 Stockholm S-121 28 SWEDEN
Henrik Levkowetz AB Arenavagen 33斯德哥尔摩S-121 28瑞典
Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com
Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。