Network Working Group B. Aboba
Request for Comments: 5247 D. Simon
Updates: 3748 Microsoft Corporation
Category: Standards Track P. Eronen
Nokia
August 2008
Network Working Group B. Aboba
Request for Comments: 5247 D. Simon
Updates: 3748 Microsoft Corporation
Category: Standards Track P. Eronen
Nokia
August 2008
Extensible Authentication Protocol (EAP) Key Management Framework
可扩展身份验证协议（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）。本备忘录的分发不受限制。
Abstract
摘要
The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied.
RFC 3748中定义的可扩展身份验证协议（EAP）支持可扩展网络访问身份验证。本文件规定了EAP密钥层次结构，并为EAP认证算法生成的密钥材料和参数（称为“方法”）的传输和使用提供了一个框架。它还提供了详细的系统级安全分析，描述了满足RFC 4962中描述的密钥管理准则的条件。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
1.2. Terminology ................................................3
1.3. Overview ...................................................7
1.4. EAP Key Hierarchy .........................................10
1.5. Security Goals ............................................15
1.6. EAP Invariants ............................................16
2. Lower-Layer Operation ..........................................20
2.1. Transient Session Keys ....................................20
2.2. Authenticator and Peer Architecture .......................22
2.3. Authenticator Identification ..............................23
2.4. Peer Identification .......................................27
2.5. Server Identification .....................................29
3. Security Association Management ................................31
3.1. Secure Association Protocol ...............................32
3.2. Key Scope .................................................35
3.3. Parent-Child Relationships ................................35
3.4. Local Key Lifetimes .......................................37
3.5. Exported and Calculated Key Lifetimes .....................37
3.6. Key Cache Synchronization .................................40
3.7. Key Strength ..............................................40
3.8. Key Wrap ..................................................41
4. Handoff Vulnerabilities ........................................41
4.1. EAP Pre-Authentication ....................................43
4.2. Proactive Key Distribution ................................44
4.3. AAA Bypass ................................................46
5. Security Considerations ........................................50
5.1. Peer and Authenticator Compromise .........................51
5.2. Cryptographic Negotiation .................................53
5.3. Confidentiality and Authentication ........................54
5.4. Key Binding ...............................................59
5.5. Authorization .............................................60
5.6. Replay Protection .........................................63
5.7. Key Freshness .............................................64
5.8. Key Scope Limitation ......................................66
5.9. Key Naming ................................................66
5.10. Denial-of-Service Attacks ................................67
6. References .....................................................68
6.1. Normative References ......................................68
6.2. Informative References ....................................68
Acknowledgments ...................................................74
Appendix A - Exported Parameters in Existing Methods ..............75
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
1.2. Terminology ................................................3
1.3. Overview ...................................................7
1.4. EAP Key Hierarchy .........................................10
1.5. Security Goals ............................................15
1.6. EAP Invariants ............................................16
2. Lower-Layer Operation ..........................................20
2.1. Transient Session Keys ....................................20
2.2. Authenticator and Peer Architecture .......................22
2.3. Authenticator Identification ..............................23
2.4. Peer Identification .......................................27
2.5. Server Identification .....................................29
3. Security Association Management ................................31
3.1. Secure Association Protocol ...............................32
3.2. Key Scope .................................................35
3.3. Parent-Child Relationships ................................35
3.4. Local Key Lifetimes .......................................37
3.5. Exported and Calculated Key Lifetimes .....................37
3.6. Key Cache Synchronization .................................40
3.7. Key Strength ..............................................40
3.8. Key Wrap ..................................................41
4. Handoff Vulnerabilities ........................................41
4.1. EAP Pre-Authentication ....................................43
4.2. Proactive Key Distribution ................................44
4.3. AAA Bypass ................................................46
5. Security Considerations ........................................50
5.1. Peer and Authenticator Compromise .........................51
5.2. Cryptographic Negotiation .................................53
5.3. Confidentiality and Authentication ........................54
5.4. Key Binding ...............................................59
5.5. Authorization .............................................60
5.6. Replay Protection .........................................63
5.7. Key Freshness .............................................64
5.8. Key Scope Limitation ......................................66
5.9. Key Naming ................................................66
5.10. Denial-of-Service Attacks ................................67
6. References .....................................................68
6.1. Normative References ......................................68
6.2. Informative References ....................................68
Acknowledgments ...................................................74
Appendix A - Exported Parameters in Existing Methods ..............75
The Extensible Authentication Protocol (EAP), defined in [RFC3748], was designed to enable extensible authentication for network access in situations in which the Internet Protocol (IP) protocol is not available. Originally developed for use with Point-to-Point Protocol (PPP) [RFC1661], it has subsequently also been applied to IEEE 802 wired networks [IEEE-802.1X], Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306], and wireless networks such as [IEEE-802.11] and [IEEE-802.16e].
[RFC3748]中定义的可扩展身份验证协议（EAP）旨在在互联网协议（IP）不可用的情况下，为网络访问启用可扩展身份验证。最初开发用于点对点协议（PPP）[RFC1661]，随后也应用于IEEE 802有线网络[IEEE-802.1X]、互联网密钥交换协议版本2（IKEv2）[RFC4306]和无线网络，如[IEEE-802.11]和[IEEE-802.16e]。
EAP is a two-party protocol spoken between the EAP peer and server. Within EAP, keying material is generated by EAP authentication algorithms, known as "methods". Part of this keying material can be used by EAP methods themselves, and part of this material can be exported. In addition to the export of keying material, EAP methods can also export associated parameters such as authenticated peer and server identities and a unique EAP conversation identifier, and can import and export lower-layer parameters known as "channel binding parameters", or simply "channel bindings".
EAP是EAP对等方和服务器之间的双向协议。在EAP中，密钥材料由EAP认证算法生成，称为“方法”。EAP方法本身可以使用此键控材质的一部分，并且可以导出此材质的一部分。除了导出密钥材料外，EAP方法还可以导出相关参数，例如经过身份验证的对等和服务器身份以及唯一的EAP会话标识符，并且可以导入和导出称为“通道绑定参数”或简称为“通道绑定”的较低层参数。
This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP methods. It also provides a detailed security analysis, describing the conditions under which the requirements described in "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management" [RFC4962] can be satisfied.
本文档规定了EAP密钥层次结构，并为EAP方法生成的密钥材料和参数的传输和使用提供了框架。它还提供了详细的安全分析，描述了满足“身份验证、授权和记帐（AAA）密钥管理指南”[RFC4962]中所述要求的条件。
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]中所述进行解释。
The terms "Cryptographic binding", "Cryptographic separation", "Key strength" and "Mutual authentication" are defined in [RFC3748] and are used with the same meaning in this document, which also frequently uses the following terms:
术语“加密绑定”、“加密分离”、“密钥强度”和“相互认证”在[RFC3748]中有定义，在本文件中具有相同的含义，本文件也经常使用以下术语：
4-Way Handshake A pairwise Authentication and Key Management Protocol (AKMP) defined in [IEEE-802.11], which confirms mutual possession of a Pairwise Master Key by two parties and distributes a Group Key.
4路握手[IEEE-802.11]中定义的成对认证和密钥管理协议（AKMP），用于确认双方相互拥有成对主密钥，并分发组密钥。
AAA Authentication, Authorization, and Accounting AAA protocols with EAP support include "RADIUS Support for EAP" [RFC3579] and "Diameter EAP Application" [RFC4072]. In this document, the terms "AAA server" and "backend authentication server" are used interchangeably.
支持EAP的AAA认证、授权和计费AAA协议包括“RADIUS支持EAP”[RFC3579]和“Diameter EAP应用程序”[RFC4072]。在本文档中，术语“AAA服务器”和“后端身份验证服务器”可以互换使用。
AAA-Key The term AAA-Key is synonymous with Master Session Key (MSK). Since multiple keys can be transported by AAA, the term is potentially confusing and is not used in this document.
AAA密钥术语AAA密钥与主会话密钥（MSK）同义。由于AAA可以传输多个密钥，因此该术语可能会引起混淆，本文档中不使用。
Authenticator The entity initiating EAP authentication.
Authenticator发起EAP身份验证的实体。
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]中使用。
Channel Binding A secure mechanism for ensuring that a subset of the parameters transmitted by the authenticator (such as authenticator identifiers and properties) are agreed upon by the EAP peer and server. It is expected that the parameters are also securely agreed upon by the EAP peer and authenticator via the lower layer if the authenticator advertised the parameters.
通道绑定一种安全机制，用于确保认证器传输的参数子集（例如认证器标识符和属性）得到EAP对等方和服务器的同意。如果认证者公布参数，则预计EAP对等方和认证者也会通过较低层安全地商定参数。
Derived Keying Material Keys derived from EAP keying material, such as Transient Session Keys (TSKs).
派生关键帧材质从EAP关键帧材质派生的关键帧，例如瞬态会话密钥（TSK）。
EAP Keying Material Keys derived by an EAP method; this includes exported keying material (MSK, Extended MSK (EMSK), Initialization Vector (IV)) as well as local keying material such as Transient EAP Keys (TEKs).
EAP键控通过EAP方法导出的材料键；这包括导出的键控材料（MSK、扩展MSK（EMSK）、初始化向量（IV））以及本地键控材料，例如瞬态EAP密钥（TEK）。
EAP Pre-Authentication The use of EAP to pre-establish EAP keying material on an authenticator prior to arrival of the peer at the access network managed by that authenticator.
EAP预认证在对等方到达由认证方管理的接入网络之前，使用EAP在认证方上预建立EAP密钥材料。
EAP Re-Authentication EAP authentication between an EAP peer and a server with whom the EAP peer shares valid unexpired EAP keying material.
EAP重新认证EAP对等方与服务器之间的EAP认证，EAP对等方与服务器共享有效的未过期EAP密钥材料。
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服务器位于后端认证服务器上。
Exported Keying Material The EAP Master Session Key (MSK), Extended Master Session Key (EMSK), and Initialization Vector (IV).
导出的密钥材料包括EAP主会话密钥（MSK）、扩展主会话密钥（EMSK）和初始化向量（IV）。
Extended Master Session Key (EMSK) Additional keying material derived between the peer and server that is exported by the EAP method. The EMSK is at least 64 octets in length and is never shared with a third party. The EMSK MUST be at least as long as the MSK in size.
扩展主会话密钥（EMSK）：通过EAP方法导出的对等方和服务器之间衍生的附加密钥材料。EMSK的长度至少为64个八位字节，并且从不与第三方共享。EMSK的大小必须至少与MSK的长度相同。
Initialization Vector (IV) A quantity of at least 64 octets, suitable for use in an initialization vector field, that is derived between the peer and EAP server. Since the IV is a known value in methods such as EAP-TLS (Transport Layer Security) [RFC5216], it cannot be used by itself for computation of any quantity that needs to remain secret. As a result, its use has been deprecated and it is OPTIONAL for EAP methods to generate it. However, when it is generated, it MUST be unpredictable.
初始化向量（IV）至少64个八位字节的数量，适用于在对等服务器和EAP服务器之间导出的初始化向量字段中使用。由于IV是EAP-TLS（传输层安全）[RFC5216]等方法中的已知值，因此它本身不能用于计算需要保密的任何数量。因此，它的使用已被弃用，EAP方法生成它是可选的。然而，当它被生成时，它必须是不可预测的。
Keying Material Unless otherwise qualified, the term "keying material" refers to EAP keying material as well as derived keying material.
键控材料除非另有规定，术语“键控材料”指EAP键控材料以及衍生键控材料。
Key Scope The parties to whom a key is available.
密钥范围-可获得密钥的各方。
Key Wrap The encryption of one symmetric cryptographic key in another. The algorithm used for the encryption is called a key wrap algorithm or a key encryption algorithm. The key used in the encryption process is called a key-encryption key (KEK).
密钥封装一个对称加密密钥在另一个对称加密密钥中的加密。用于加密的算法称为密钥包裹算法或密钥加密算法。加密过程中使用的密钥称为密钥加密密钥（KEK）。
Long-Term Credential EAP methods frequently make use of long-term secrets in order to enable authentication between the peer and server. In the case of a method based on pre-shared key authentication, the long-term credential is the pre-shared key. In the case of a public-key-based method, the long-term credential is the corresponding private key.
长期凭证EAP方法经常使用长期机密来实现对等方和服务器之间的身份验证。在基于预共享密钥认证的方法的情况下，长期凭证是预共享密钥。在基于公钥的方法的情况下，长期凭证是相应的私钥。
Lower Layer The lower layer is responsible for carrying EAP frames between the peer and authenticator.
较低层较低层负责在对等方和认证方之间承载EAP帧。
Lower-Layer Identity A name used to identify the EAP peer and authenticator within the lower layer.
下层标识用于标识下层中的EAP对等方和身份验证方的名称。
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.
主会话密钥（MSK）是在EAP对等方和服务器之间派生并通过EAP方法导出的密钥材料。MSK的长度至少为64个八位字节。
Network Access Server (NAS) A device that provides an access service for a user to a network.
网络访问服务器（NAS）为用户提供网络访问服务的设备。
Pairwise Master Key (PMK) Lower layers use the MSK in a lower-layer dependent manner. For instance, in IEEE 802.11 [IEEE-802.11], Octets 0-31 of the MSK are known as the Pairwise Master Key (PMK); the Temporal Key Integrity Protocol (TKIP) and Advanced Encryption Standard Counter Mode with CBC-MAC Protocol (AES CCMP) ciphersuites derive their Transient Session Keys (TSKs) solely from the PMK, whereas the Wired Equivalent Privacy (WEP) ciphersuite, as noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], derives its TSKs from both halves of the MSK. In [IEEE-802.16e], the MSK is truncated to 20 octets for PMK and 20 octets for PMK2.
成对主密钥（PMK）较低层以依赖于较低层的方式使用MSK。例如，在IEEE 802.11[IEEE-802.11]中，MSK的八位字节0-31被称为成对主密钥（PMK）；带有CBC-MAC协议（AES CCMP）的临时密钥完整性协议（TKIP）和高级加密标准计数器模式密码套件仅从PMK派生其瞬态会话密钥（TSK），而有线等效隐私（WEP）密码套件，如“IEEE 802.1X RADIUS使用指南”[RFC3580]所述，从MSK的两半部分导出其TSK。在[IEEE-802.16e]中，MSK被截断为PMK的20个八位字节和PMK2的20个八位字节。
Peer The entity that responds to the authenticator. In [IEEE-802.1X], this entity is known as the Supplicant.
对等响应身份验证器的实体。在[IEEE-802.1X]中，该实体称为请求者。
Security Association A set of policies and cryptographic state used to protect information. Elements of a security association include cryptographic keys, negotiated ciphersuites and other parameters, counters, sequence spaces, authorization attributes, etc.
安全关联用于保护信息的一组策略和加密状态。安全关联的元素包括加密密钥、协商密码套件和其他参数、计数器、序列空间、授权属性等。
Secure Association Protocol An exchange that occurs between the EAP peer and authenticator in order to manage security associations derived from EAP exchanges. The protocol establishes unicast and (optionally) multicast security associations, which include symmetric keys and a context for the use of the keys. An example of a Secure Association Protocol is the 4-way handshake defined within [IEEE-802.11].
安全关联协议EAP对等方和身份验证方之间发生的一种交换，用于管理从EAP交换派生的安全关联。该协议建立单播和（可选）多播安全关联，其中包括对称密钥和密钥使用的上下文。安全关联协议的一个示例是[IEEE-802.11]中定义的4路握手。
Session-Id The EAP Session-Id uniquely identifies an EAP authentication exchange between an EAP peer (as identified by the Peer-Id(s)) and server (as identified by the Server-Id(s)). For more information, see Section 1.4.
会话Id EAP会话Id唯一标识EAP对等方（由对等方Id标识）和服务器（由服务器Id标识）之间的EAP身份验证交换。有关更多信息，请参见第1.4节。
Transient EAP Keys (TEKs) Session keys that are used to establish a protected channel between the EAP peer and server during the EAP authentication exchange. The TEKs are appropriate for use with the ciphersuite negotiated between EAP peer and server for use in protecting the EAP conversation. The TEKs are stored locally by the EAP method and are not exported. Note that the ciphersuite used to set up the protected channel between the EAP peer and server during EAP authentication is unrelated to the ciphersuite used to subsequently protect data sent between the EAP peer and authenticator.
瞬态EAP密钥（TEK）会话密钥，用于在EAP身份验证交换期间在EAP对等方和服务器之间建立受保护的通道。TEK适用于EAP对等方和服务器之间协商的密码套件，用于保护EAP对话。TEK通过EAP方法本地存储，不导出。请注意，在EAP身份验证期间用于在EAP对等方和服务器之间设置受保护通道的密码套件与用于随后保护EAP对等方和身份验证方之间发送的数据的密码套件无关。
Transient Session Keys (TSKs) Keys used to protect data exchanged after EAP authentication has successfully completed using the ciphersuite negotiated between the EAP peer and authenticator.
临时会话密钥（TSK）用于保护EAP身份验证成功完成后使用EAP对等方和身份验证方之间协商的密码套件交换的数据的密钥。
Where EAP key derivation is supported, the conversation typically takes place in three phases:
在支持EAP密钥派生的情况下，对话通常分三个阶段进行：
Phase 0: Discovery Phase 1: Authentication 1a: EAP authentication 1b: AAA Key Transport (optional) Phase 2: Secure Association Protocol 2a: Unicast Secure Association 2b: Multicast Secure Association (optional)
阶段0:发现阶段1:身份验证1a:EAP身份验证1b:AAA密钥传输（可选）阶段2:安全关联协议2a:单播安全关联2b:多播安全关联（可选）
Of these phases, phase 0, 1b, and 2 are handled external to EAP. phases 0 and 2 are handled by the lower-layer protocol, and phase 1b is typically handled by a AAA protocol.
在这些阶段中，阶段0、1b和2在EAP外部处理。阶段0和2由较低层协议处理，阶段1b通常由AAA协议处理。
In the discovery phase (phase 0), peers locate authenticators and discover their capabilities. A peer can locate an authenticator providing access to a particular network, or a peer can locate an authenticator behind a bridge with which it desires to establish a Secure Association. Discovery can occur manually or automatically, depending on the lower layer over which EAP runs.
在发现阶段（阶段0），对等方定位身份验证器并发现其功能。对等方可以定位提供对特定网络的访问的身份验证器，或者对等方可以定位其希望与之建立安全关联的网桥后面的身份验证器。发现可以手动或自动进行，具体取决于EAP运行的较低层。
The authentication phase (phase 1) can begin once the peer and authenticator discover each other. This phase, if it occurs, always includes EAP authentication (phase 1a). Where the chosen EAP method supports key derivation, in phase 1a, EAP keying material is derived on both the peer and the EAP server.
身份验证阶段（阶段1）可以在对等方和身份验证方发现彼此后开始。此阶段（如果发生）始终包括EAP身份验证（阶段1a）。如果选择的EAP方法支持密钥派生，则在阶段1a中，在对等方和EAP服务器上派生EAP密钥材料。
An additional step (phase 1b) is needed in deployments that include a backend authentication server, in order to transport keying material from the backend authentication server to the authenticator. In order to obey the principle of mode independence (see Section 1.6.1), where a backend authentication server is present, all keying material needed by the lower layer is transported from the EAP server to the authenticator. Since existing TSK derivation and transport techniques depend solely on the MSK, in existing implementations, this is the only keying material replicated in the AAA key transport phase 1b.
在包括后端身份验证服务器的部署中，还需要一个附加步骤（阶段1b），以便将密钥材料从后端身份验证服务器传输到身份验证程序。为了遵守模式独立性原则（见第1.6.1节），在存在后端认证服务器的情况下，下层所需的所有密钥材料都从EAP服务器传输到认证器。由于现有的TSK派生和传输技术完全依赖于MSK，因此在现有的实现中，这是在AAA密钥传输阶段1b中复制的唯一密钥材料。
Successful completion of EAP authentication and key derivation by a peer and EAP server does not necessarily imply that the peer is committed to joining the network associated with an EAP server. Rather, this commitment is implied by the creation of a security association between the EAP peer and authenticator, as part of the Secure Association Protocol (phase 2). The Secure Association Protocol exchange (phase 2) occurs between the peer and authenticator in order to manage the creation and deletion of unicast (phase 2a) and multicast (phase 2b) security associations between the peer and authenticator. The conversation between the parties is shown in Figure 1.
对等方和EAP服务器成功完成EAP身份验证和密钥推导并不一定意味着对等方承诺加入与EAP服务器关联的网络。相反，作为安全关联协议（第2阶段）的一部分，EAP对等方和认证方之间的安全关联的创建暗示了这种承诺。安全关联协议交换（阶段2）发生在对等方和认证方之间，以便管理对等方和认证方之间单播（阶段2a）和多播（阶段2b）安全关联的创建和删除。双方之间的对话如图1所示。
EAP peer Authenticator Auth. Server
-------- ------------- ------------
|<----------------------------->| |
| Discovery (phase 0) | |
|<----------------------------->|<----------------------------->|
| EAP auth (phase 1a) | AAA pass-through (optional) |
| | |
| |<----------------------------->|
| | AAA Key transport |
| | (optional; phase 1b) |
|<----------------------------->| |
| Unicast Secure association | |
| (phase 2a) | |
| | |
|<----------------------------->| |
| Multicast Secure association | |
| (optional; phase 2b) | |
| | |
EAP peer Authenticator Auth. Server
-------- ------------- ------------
|<----------------------------->| |
| Discovery (phase 0) | |
|<----------------------------->|<----------------------------->|
| EAP auth (phase 1a) | AAA pass-through (optional) |
| | |
| |<----------------------------->|
| | AAA Key transport |
| | (optional; phase 1b) |
|<----------------------------->| |
| Unicast Secure association | |
| (phase 2a) | |
| | |
|<----------------------------->| |
| Multicast Secure association | |
| (optional; phase 2b) | |
| | |
Figure 1: Conversation Overview
图1：对话概述
Existing EAP lower layers implement phase 0, 2a, and 2b in different ways:
现有EAP较低层以不同方式实施阶段0、2a和2b：
PPP The Point-to-Point Protocol (PPP), defined in [RFC1661], does not support discovery, nor does it include a Secure Association Protocol.
PPP在[RFC1661]中定义的点对点协议（PPP）不支持发现，也不包括安全关联协议。
PPPoE PPP over Ethernet (PPPoE), defined in [RFC2516], includes support for a Discovery stage (phase 0). In this step, the EAP peer sends a PPPoE Active Discovery Initiation (PADI) packet to the broadcast address, indicating the service it is requesting. The Access Concentrator replies with a PPPoE Active Discovery Offer (PADO) packet containing its name, the service name, and an indication of the services offered by the concentrator. The discovery phase is not secured. PPPoE, like PPP, does not include a Secure Association Protocol.
[RFC2516]中定义的以太网PPPoE（PPPoE），包括对发现阶段（阶段0）的支持。在该步骤中，EAP对等方向广播地址发送PPPoE主动发现发起（PADI）分组，指示其正在请求的服务。接入集中器以包含其名称、服务名称和集中器提供的服务指示的PPPoE主动发现提供（PADO）数据包进行应答。发现阶段不安全。PPPoE和PPP一样，不包括安全关联协议。
IKEv2 Internet Key Exchange v2 (IKEv2), defined in [RFC4306], includes support for EAP and handles the establishment of unicast security associations (phase 2a). However, the establishment of multicast security associations (phase 2b) typically does not involve EAP and needs to be handled by a group key management protocol such as Group Domain of Interpretation (GDOI) [RFC3547], Group Secure Association Key Management Protocol (GSAKMP) [RFC4535], Multimedia Internet KEYing (MIKEY) [RFC3830], or Group Key Distribution Protocol (GKDP) [GKDP]. Several mechanisms have been proposed for the discovery of IPsec security gateways. [RFC2230] discusses the use of Key eXchange (KX) Resource Records (RRs) for IPsec gateway discovery; while KX RRs are supported by many Domain Name Service (DNS) server implementations, they have not yet been widely deployed. Alternatively, DNS SRV RRs [RFC2782] can be used for this purpose. Where DNS is used for gateway location, DNS security mechanisms such as DNS Security (DNSSEC) ([RFC4033], [RFC4035]), TSIG [RFC2845], and Simple Secure Dynamic Update [RFC3007] are available.
[RFC4306]中定义的IKEv2互联网密钥交换v2（IKEv2），包括对EAP的支持，并处理单播安全关联的建立（阶段2a）。然而，多播安全关联的建立（阶段2b）通常不涉及EAP，并且需要由组密钥管理协议来处理，例如组解释域（GDOI）[RFC3547]、组安全关联密钥管理协议（GSAKMP）[RFC4535]、多媒体因特网密钥（MIKEY）[RFC3830]，或组密钥分发协议（GKDP）[GKDP]。已经提出了几种用于发现IPsec安全网关的机制。[RFC2230]讨论了密钥交换（KX）资源记录（RRs）在IPsec网关发现中的使用；虽然许多域名服务（DNS）服务器实现都支持KX RRs，但它们尚未得到广泛部署。或者，DNS SRV RRs[RFC2782]可用于此目的。当DNS用于网关位置时，可以使用DNS安全机制，如DNS安全（DNSSEC）（[RFC4033]、[RFC4035]）、TSIG[RFC2845]和简单安全动态更新[RFC3007]。
IEEE 802.11 IEEE 802.11, defined in [IEEE-802.11], handles discovery via the Beacon and Probe Request/Response mechanisms. IEEE 802.11 Access Points (APs) periodically announce their Service Set Identifiers (SSIDs) as well as capabilities using Beacon frames. Stations can
IEEE 802.11[IEEE-802.11]中定义的IEEE 802.11通过信标和探测请求/响应机制处理发现。IEEE 802.11接入点（AP）定期宣布其服务集标识符（SSID）以及使用信标帧的功能。电台可以
query for APs by sending a Probe Request. Neither Beacon nor Probe Request/Response frames are secured. The 4-way handshake defined in [IEEE-802.11] enables the derivation of unicast (phase 2a) and multicast/broadcast (phase 2b) secure associations. Since the group key exchange transports a group key from the AP to the station, two 4-way handshakes can be needed in order to support peer-to-peer communications. A proof of the security of the IEEE 802.11 4-way handshake, when used with EAP-TLS, is provided in [He].
通过发送探测请求查询AP。信标和探测请求/响应帧均不安全。[IEEE-802.11]中定义的4路握手支持单播（阶段2a）和多播/广播（阶段2b）安全关联的推导。由于组密钥交换将组密钥从AP传输到站点，因此可能需要两次4向握手以支持对等通信。当与EAP-TLS一起使用时，IEEE 802.11 4路握手的安全性证明见[He]。
IEEE 802.1X IEEE 802.1X-2004, defined in [IEEE-802.1X], does not support discovery (phase 0), nor does it provide for derivation of unicast or multicast secure associations.
在[IEEE-802.1X]中定义的IEEE 802.1X IEEE 802.1X-2004不支持发现（第0阶段），也不提供单播或多播安全关联的推导。
As illustrated in Figure 2, the EAP method key derivation has, at the root, the long-term credential utilized by the selected EAP method. If authentication is based on a pre-shared key, the parties store the EAP method to be used and the pre-shared key. The EAP server also stores the peer's identity as well as additional information. This information is typically used outside of the EAP method to determine whether to grant access to a service. The peer stores information necessary to choose which secret to use for which service.
如图2所示，EAP方法密钥派生在根上具有所选EAP方法使用的长期凭证。如果身份验证基于预共享密钥，则双方存储要使用的EAP方法和预共享密钥。EAP服务器还存储对等方的身份以及其他信息。此信息通常在EAP方法之外使用，以确定是否授予对服务的访问权。对等方存储选择将哪个秘密用于哪个服务所需的信息。
If authentication is based on proof of possession of the private key corresponding to the public key contained within a certificate, the parties store the EAP method to be used and the trust anchors used to validate the certificates. The EAP server also stores the peer's identity, and the peer stores information necessary to choose which certificate to use for which service. Based on the long-term credential established between the peer and the server, methods derive two types of EAP keying material:
如果身份验证基于拥有证书中包含的公钥对应的私钥的证明，则双方存储要使用的EAP方法和用于验证证书的信任锚。EAP服务器还存储对等方的身份，对等方存储选择将哪个证书用于哪个服务所需的信息。基于对等方和服务器之间建立的长期凭证，方法派生两种类型的EAP密钥材料：
(a) Keying material calculated locally by the EAP method but not exported, such as the Transient EAP Keys (TEKs).
(a) 通过EAP方法本地计算但未导出的关键点材质，例如瞬态EAP关键点（TEK）。
(b) Keying material exported by the EAP method: Master Session Key (MSK), Extended Master Session Key (EMSK), Initialization Vector (IV).
(b) EAP方法导出的密钥材料：主会话密钥（MSK）、扩展主会话密钥（EMSK）、初始化向量（IV）。
As noted in [RFC3748] Section 7.10:
如[RFC3748]第7.10节所述：
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方法必须导出至少64个八位字节的主会话密钥（MSK）和至少64个八位字节的扩展主会话密钥（EMSK）。
EAP methods also MAY export the IV; however, the use of the IV is deprecated. The EMSK MUST NOT be provided to an entity outside the EAP server or peer, nor is it permitted to pass any quantity to an entity outside the EAP server or peer from which the EMSK could be computed without breaking some cryptographic assumption, such as inverting a one-way function.
EAP方法也可以输出IV；但是，不推荐使用IV。不得将EMSK提供给EAP服务器或对等方之外的实体，也不允许将任何数量传递给EAP服务器或对等方之外的实体，从该实体可以计算EMSK，而不破坏某些加密假设，例如反转单向函数。
EAP methods supporting key derivation and mutual authentication SHOULD export a method-specific EAP conversation identifier known as the Session-Id, as well as one or more method-specific peer identifiers (Peer-Id(s)) and MAY export one or more method-specific server identifiers (Server-Id(s)). EAP methods MAY also support the import and export of channel binding parameters. EAP method specifications developed after the publication of this document MUST define the Peer-Id, Server-Id, and Session-Id. The Peer-Id(s) and Server-Id(s), when provided, identify the entities involved in generating EAP keying material. For existing EAP methods, the Peer-Id, Server-Id, and Session-Id are defined in Appendix A.
支持密钥派生和相互认证的EAP方法应导出称为会话Id的方法特定EAP会话标识符，以及一个或多个方法特定对等标识符（对等Id），并可导出一个或多个方法特定服务器标识符（服务器Id）。EAP方法还可以支持通道绑定参数的导入和导出。本文件发布后制定的EAP方法规范必须定义对等Id、服务器Id和会话Id。提供对等Id和服务器Id时，应确定生成EAP密钥材料所涉及的实体。对于现有的EAP方法，在附录A中定义了对等Id、服务器Id和会话Id。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | TEK | |MSK, EMSK | |IV | | |
| | |Derivation | |Derivation | |Derivation | | |
| | | | | | |(Deprecated) | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | ^ | | | |
| | | | | | V
+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+
| | | | ^
| | | | Exported |
| Peer-Id(s), | channel | MSK (64+B) | IV (64B) by |
| Server-Id(s), | bindings | EMSK (64+B) | (Optional) EAP |
| Session-Id | & Result | | Method |
V V V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | TEK | |MSK, EMSK | |IV | | |
| | |Derivation | |Derivation | |Derivation | | |
| | | | | | |(Deprecated) | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | ^ | | | |
| | | | | | V
+-+-|-+-+-+-+-+-+-+-|-+-+-+-+-+-+-|-+-+-+-+-+-+-+-|-+-+-+-+ ---+
| | | | ^
| | | | Exported |
| Peer-Id(s), | channel | MSK (64+B) | IV (64B) by |
| Server-Id(s), | bindings | EMSK (64+B) | (Optional) EAP |
| Session-Id | & Result | | Method |
V V V V V
Figure 2: EAP Method Parameter Import/Export
图2:EAP方法参数导入/导出
Peer-Id
对等Id
If an EAP method that generates keys authenticates one or more method-specific peer identities, those identities are exported by the method as the Peer-Id(s). It is possible for more than one Peer-Id to be exported by an EAP method. Not all EAP methods provide a method-specific peer identity; where this is not defined, the Peer-Id is the null string. In EAP methods that do not support key generation, the Peer-Id MUST be the null string. Where an EAP method that derives keys does not provide a Peer-Id, the EAP server will not authenticate the identity of the EAP peer with which it derived keying material.
如果生成密钥的EAP方法对一个或多个特定于方法的对等身份进行身份验证，则该方法会将这些身份导出为对等Id。EAP方法可以导出多个对等Id。并非所有EAP方法都提供特定于方法的对等身份；如果未定义，则对等Id为空字符串。在不支持密钥生成的EAP方法中，对等Id必须为空字符串。如果派生密钥的EAP方法不提供对等Id，则EAP服务器将不会对其派生密钥材料的EAP对等身份进行身份验证。
Server-Id
服务器Id
If an EAP method that generates keys authenticates one or more method-specific server identities, those identities are exported by the method as the Server-Id(s). It is possible for more than one Server-Id to be exported by an EAP method. Not all EAP methods provide a method-specific server identity; where this is not defined, the Server-Id is the null string. If the EAP method does not generate keying material, the Server-Id MUST be the null string. Where an EAP method that derives keys does not provide a Server-Id, the EAP peer will not authenticate the identity of the EAP server with which it derived EAP keying material.
如果生成密钥的EAP方法对一个或多个特定于方法的服务器标识进行身份验证，则该方法会将这些标识导出为服务器Id。EAP方法可以导出多个服务器Id。并非所有EAP方法都提供特定于方法的服务器标识；如果未定义，则服务器Id为空字符串。如果EAP方法不生成键控材料，则服务器Id必须为空字符串。如果派生密钥的EAP方法不提供服务器Id，则EAP对等方将不会验证其派生EAP密钥材料的EAP服务器的身份。
Session-Id
会话Id
The Session-Id uniquely identifies an EAP session between an EAP peer (as identified by the Peer-Id) and server (as identified by the Server-Id). Where non-expanded EAP Type Codes are used (EAP Type Code not equal to 254), the EAP Session-Id is the concatenation of the single octet EAP Type Code and a temporally unique identifier obtained from the method (known as the Method-Id):
会话Id唯一标识EAP对等方（由对等方Id标识）和服务器（由服务器Id标识）之间的EAP会话。在使用非扩展EAP类型代码（EAP类型代码不等于254）的情况下，EAP会话Id是单个八位组EAP类型代码和从该方法获得的临时唯一标识符（称为方法Id）的串联：
Session-Id = Type-Code || Method-Id
会话Id=类型代码| |方法Id
Where expanded EAP Type Codes are used, the EAP Session-Id consists of the Expanded Type Code (including the Type, Vendor-Id (in network byte order) and Vendor-Type fields (in network byte order) defined in [RFC3748] Section 5.7), concatenated with a temporally unique identifier obtained from the method (Method-Id):
在使用扩展EAP类型代码的情况下，EAP会话Id由扩展类型代码（包括[RFC3748]第5.7节中定义的类型、供应商Id（网络字节顺序）和供应商类型字段（网络字节顺序））组成，并与从方法（方法Id）获得的临时唯一标识符连接：
Session-Id = 0xFE || Vendor-Id || Vendor-Type || Method-Id
会话Id=0xFE | |供应商Id | |供应商类型| |方法Id
The Method-Id is typically constructed from nonces or counters used within the EAP method exchange. The inclusion of the Type Code or Expanded Type Code in the EAP Session-Id ensures that each EAP method has a distinct Session-Id space. Since an EAP session is not bound to a particular authenticator or specific ports on the peer and authenticator, the authenticator port or identity are not included in the Session-Id.
方法Id通常由EAP方法交换中使用的nonce或计数器构造。在EAP会话Id中包含类型代码或扩展类型代码可确保每个EAP方法具有不同的会话Id空间。由于EAP会话未绑定到特定的验证器或对等和验证器上的特定端口，因此该验证器端口或标识不包括在会话Id中。
Channel Binding
通道绑定
Channel binding is the process by which lower-layer parameters are verified for consistency between the EAP peer and server. In order to avoid introducing media dependencies, EAP methods that transport channel binding parameters MUST treat this data as opaque octets. See Section 5.3.3 for further discussion.
通道绑定是验证EAP对等方和服务器之间的低层参数一致性的过程。为了避免引入媒体依赖关系，传输通道绑定参数的EAP方法必须将此数据视为不透明的八位字节。进一步讨论见第5.3.3节。
Each key created within the EAP key management framework has a name (a unique identifier), as well as a scope (the parties to whom the key is available). The scope of exported keying material and TEKs is defined by the authenticated method-specific peer identities (Peer-Id(s)) and the authenticated server identities (Server-Id(s)), where available.
在EAP密钥管理框架内创建的每个密钥都有一个名称（唯一标识符）和一个范围（密钥可用的各方）。导出的密钥材料和TEK的范围由经过身份验证的方法特定的对等身份（对等Id）和经过身份验证的服务器身份（服务器Id）定义（如果可用）。
MSK and EMSK Names The MSK and EMSK are exported by the EAP peer and EAP server, and MUST be named using the EAP Session-Id and a binary or textual indication of the EAP keying material being referred to.
MSK和EMSK名称MSK和EMSK由EAP对等方和EAP服务器导出，必须使用EAP会话Id和所引用EAP密钥材料的二进制或文本指示来命名。
PMK Name This document does not specify a naming scheme for the Pairwise Master Key (PMK). The PMK is only identified by the name of the key from which it is derived.
PMK名称本文档未指定成对主密钥（PMK）的命名方案。PMK仅由其派生的密钥的名称标识。
Note: IEEE 802.11 names the PMK for the purposes of being able to refer to it in the Secure Association Protocol; the PMK name (known as the PMKID) is based on a hash of the PMK itself as well as some other parameters (see [IEEE-802.11] Section 8.5.1.2).
注：IEEE 802.11命名PMK是为了能够在安全关联协议中引用它；PMK名称（称为PMKID）基于PMK本身的散列以及一些其他参数（参见[IEEE-802.11]第8.5.1.2节）。
TEK Name Transient EAP Keys (TEKs) MAY be named; their naming is specified in the EAP method specification.
可命名TEK名称瞬态EAP密钥（TEK）；它们的命名在EAP方法规范中指定。
TSK Name Transient Session Keys (TSKs) are typically named. Their naming is specified in the lower layer so that the correct set of TSKs can be identified for processing a given packet.
TSK名称临时会话密钥（TSK）通常是命名的。它们的命名在较低的层中指定，以便可以识别正确的TSK集来处理给定的数据包。
The goal of the EAP conversation is to derive fresh session keys between the EAP peer and authenticator that are known only to those parties, and for both the EAP peer and authenticator to demonstrate that they are authorized to perform their roles either by each other or by a trusted third party (the backend authentication server).
EAP对话的目标是在EAP对等方和身份验证方之间派生出仅为这些方所知的新会话密钥，并使EAP对等方和身份验证方都能够证明它们被授权执行各自的角色，或者由彼此授权，或者由可信的第三方（后端身份验证服务器）授权。
Completion of an EAP method exchange (phase 1a) supporting key derivation results in the derivation of EAP keying material (MSK, EMSK, TEKs) known only to the EAP peer (identified by the Peer-Id(s)) and EAP server (identified by the Server-Id(s)). Both the EAP peer and EAP server know this keying material to be fresh. The Peer-Id and Server-Id are discussed in Sections 1.4, 2.4, and 2.5 as well as in Appendix A. Key freshness is discussed in Sections 3.4, 3.5, and 5.7.
支持密钥派生的EAP方法交换（阶段1a）的完成导致仅EAP对等方（由对等方Id标识）和EAP服务器（由服务器Id标识）知道的EAP密钥材料（MSK、EMSK、TEKs）的派生。EAP对等方和EAP服务器都知道此密钥材料是新的。第1.4、2.4和2.5节以及附录A讨论了对等Id和服务器Id。第3.4、3.5和5.7节讨论了关键新鲜度。
Completion of the AAA exchange (phase 1b) results in the transport of keying material from the EAP server (identified by the Server-Id(s)) to the EAP authenticator (identified by the NAS-Identifier) without disclosure to any other party. Both the EAP server and EAP authenticator know this keying material to be fresh. Disclosure issues are discussed in Sections 3.8 and 5.3; security properties of AAA protocols are discussed in Sections 5.1 - 5.9.
AAA交换（阶段1b）的完成导致将密钥材料从EAP服务器（由服务器Id标识）传输到EAP验证器（由NAS标识符标识），而不向任何其他方披露。EAP服务器和EAP验证器都知道此密钥材料是新的。第3.8节和第5.3节讨论了披露问题；第5.1-5.9节讨论了AAA协议的安全属性。
The backend authentication server is trusted to transport keying material only to the authenticator that was established with the peer, and it is trusted to transport that keying material to no other parties. In many systems, EAP keying material established by the EAP peer and EAP server are combined with publicly available data to derive other keys. The backend authentication server is trusted to refrain from deriving these same keys or acting as a man-in-the-middle even though it has access to the keying material that is needed to do so.
后端身份验证服务器被信任只将密钥材料传输到与对等方建立的身份验证程序，并且不将密钥材料传输到其他方。在许多系统中，由EAP对等方和EAP服务器建立的EAP密钥材料与公开可用的数据相结合，以导出其他密钥。后端身份验证服务器可以避免派生这些相同的密钥或充当中间人，即使它可以访问执行此操作所需的密钥材料。
The authenticator is also a trusted party. The authenticator is trusted not to distribute keying material provided by the backend authentication server to any other parties. If the authenticator uses a key derivation function to derive additional keying material, the authenticator is trusted to distribute the derived keying material only to the appropriate party that is known to the peer, and no other party. When this approach is used, care must be taken to ensure that the resulting key management system meets all of the principles in [RFC4962], confirming that keys used to protect data are to be known only by the peer and authenticator.
身份验证器也是受信任的一方。信任验证者不会将后端身份验证服务器提供的密钥材料分发给任何其他方。如果验证器使用密钥派生函数派生额外的密钥材料，则验证器被信任仅将派生的密钥材料分发给对等方已知的适当方，而不分发给其他方。使用此方法时，必须注意确保生成的密钥管理系统符合[RFC4962]中的所有原则，确认用于保护数据的密钥仅由对等方和认证方知晓。
Completion of the Secure Association Protocol (phase 2) results in the derivation or transport of Transient Session Keys (TSKs) known only to the EAP peer (identified by the Peer-Id(s)) and authenticator (identified by the NAS-Identifier). Both the EAP peer and authenticator know the TSKs to be fresh. Both the EAP peer and authenticator demonstrate that they are authorized to perform their roles. Authorization issues are discussed in Sections 4.3.2 and 5.5; security properties of Secure Association Protocols are discussed in Section 3.1.
安全关联协议（阶段2）的完成导致仅EAP对等方（由对等方Id标识）和验证器（由NAS标识标识）知道的瞬态会话密钥（TSK）的派生或传输。EAP对等方和认证方都知道TSK是新的。EAP对等方和验证者都证明他们有权执行其角色。第4.3.2节和第5.5节讨论了授权问题；第3.1节讨论了安全关联协议的安全属性。
Certain basic characteristics, known as "EAP Invariants", hold true for EAP implementations:
某些被称为“EAP不变量”的基本特征适用于EAP实现：
Mode independence Media independence Method independence Ciphersuite independence
模式独立性媒体独立性方法独立性密码套件独立性
EAP is typically deployed to support extensible network access authentication in situations where a peer desires network access via one or more authenticators. Where authenticators are deployed standalone, the EAP conversation occurs between the peer and authenticator, and the authenticator locally implements one or more EAP methods. However, when utilized in "pass-through" mode, EAP enables the deployment of new authentication methods without requiring the development of new code on the authenticator.
EAP通常部署为在对等方希望通过一个或多个认证器进行网络访问的情况下支持可扩展网络访问认证。在独立部署身份验证程序的情况下，对等方和身份验证程序之间发生EAP对话，并且身份验证程序在本地实现一个或多个EAP方法。但是，当在“传递”模式下使用时，EAP允许部署新的身份验证方法，而无需在身份验证程序上开发新代码。
While the authenticator can implement some EAP methods locally and use those methods to authenticate local users, it can at the same time act as a pass-through for other users and methods, forwarding EAP packets back and forth between the backend authentication server and the peer. This is accomplished by encapsulating EAP packets within the Authentication, Authorization, and Accounting (AAA) protocol spoken between the authenticator and backend authentication server. AAA protocols supporting EAP include RADIUS [RFC3579] and Diameter [RFC4072].
虽然验证器可以在本地实现一些EAP方法并使用这些方法对本地用户进行身份验证，但它可以同时充当其他用户和方法的传递，在后端身份验证服务器和对等方之间来回转发EAP数据包。这是通过将EAP数据包封装在身份验证程序和后端身份验证服务器之间的身份验证、授权和计费（AAA）协议中来实现的。支持EAP的AAA协议包括RADIUS[RFC3579]和Diameter[RFC4072]。
It is a fundamental property of EAP that at the EAP method layer, the conversation between the EAP peer and server is unaffected by whether the EAP authenticator is operating in "pass-through" mode. EAP methods operate identically in all aspects, including key derivation and parameter import/export, regardless of whether or not the authenticator is operating as a pass-through.
EAP的一个基本特性是，在EAP方法层，EAP对等方和服务器之间的对话不受EAP验证器是否在“直通”模式下运行的影响。EAP方法在所有方面的操作都是相同的，包括密钥派生和参数导入/导出，而不管验证器是否作为传递进行操作。
The successful completion of an EAP method that supports key derivation results in the export of EAP keying material and parameters on the EAP peer and server. Even though the EAP peer or server can import channel binding parameters that can include the identity of the EAP authenticator, this information is treated as opaque octets. As a result, within EAP, the only relevant identities are the Peer-Id(s) and Server-Id(s). Channel binding parameters are only interpreted by the lower layer.
成功完成支持密钥派生的EAP方法将导致在EAP对等机和服务器上导出EAP密钥材料和参数。即使EAP对等方或服务器可以导入通道绑定参数，这些参数可以包括EAP验证器的标识，但这些信息被视为不透明的八位字节。因此，在EAP中，唯一相关的标识是对等Id和服务器Id。通道绑定参数仅由较低层解释。
Within EAP, the primary function of the AAA protocol is to maintain the principle of mode independence. As far as the EAP peer is concerned, its conversation with the EAP authenticator, and all consequences of that conversation, are identical, regardless of the authenticator mode of operation.
在EAP中，AAA协议的主要功能是维护模式独立性原则。就EAP对等方而言，其与EAP验证器的对话以及该对话的所有结果都是相同的，而与验证器的操作模式无关。
One of the goals of EAP is to allow EAP methods to function on any lower layer meeting the criteria outlined in [RFC3748] Section 3.1. For example, as described in [RFC3748], EAP authentication can be run over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and wireless networks such as 802.11 [IEEE-802.11] and 802.16 [IEEE-802.16e].
EAP的目标之一是允许EAP方法在满足[RFC3748]第3.1节所述标准的任何较低层上运行。例如，如[RFC3748]中所述，EAP认证可以在PPP[RFC1661]、IEEE 802有线网络[IEEE-802.1X]和无线网络（如802.11[IEEE-802.11]和802.16[IEEE-802.16e]上运行。
In order to maintain media independence, it is necessary for EAP to avoid consideration of media-specific elements. For example, EAP methods cannot be assumed to have knowledge of the lower layer over which they are transported, and cannot be restricted to identifiers associated with a particular usage environment (e.g., Medium Access Control (MAC) addresses).
为了保持媒体的独立性，EAP有必要避免考虑特定于媒体的因素。例如，不能假设EAP方法知道它们在其上传输的较低层，并且不能被限制为与特定使用环境（例如，媒体访问控制（MAC）地址）相关联的标识符。
Note that media independence can be retained within EAP methods that support channel binding or method-specific identification. An EAP method need not be aware of the content of an identifier in order to use it. This enables an EAP method to use media-specific identifiers such as MAC addresses without compromising media independence. Channel binding parameters are treated as opaque octets by EAP methods so that handling them does not require media-specific knowledge.
请注意，支持通道绑定或方法特定标识的EAP方法中可以保留媒体独立性。EAP方法不需要知道标识符的内容就可以使用它。这使得EAP方法能够在不损害媒体独立性的情况下使用媒体特定标识符，例如MAC地址。EAP方法将通道绑定参数视为不透明的八位字节，因此处理它们不需要特定于媒体的知识。
By enabling pass-through, authenticators can support any method implemented on the peer and server, not just locally implemented methods. This allows the authenticator to avoid having to implement the EAP methods configured for use by peers. In fact, since a pass-through authenticator need not implement any EAP methods at all, it cannot be assumed to support any EAP method-specific code. As noted in [RFC3748] Section 2.3:
通过启用传递，身份验证器可以支持在对等机和服务器上实现的任何方法，而不仅仅是本地实现的方法。这允许验证器避免实现为对等方使用而配置的EAP方法。事实上，由于直通身份验证器根本不需要实现任何EAP方法，因此不能假定它支持任何EAP方法特定的代码。如[RFC3748]第2.3节所述：
Compliant pass-through authenticator implementations MUST by default forward EAP packets of any Type.
默认情况下，兼容的直通身份验证程序实现必须转发任何类型的EAP数据包。
This is useful where there is no single EAP method that is both mandatory to implement and offers acceptable security for the media in use. For example, the [RFC3748] mandatory-to-implement EAP method (MD5-Challenge) does not provide dictionary attack resistance, mutual authentication, or key derivation, and as a result, is not appropriate for use in Wireless Local Area Network (WLAN) authentication [RFC4017]. However, despite this, it is possible for the peer and authenticator to interoperate as long as a suitable EAP method is supported both on the EAP peer and server.
如果没有一个EAP方法是必须实现的，并且为使用中的介质提供可接受的安全性，则此方法非常有用。例如，实现EAP方法（MD5质询）所必需的[RFC3748]不提供字典攻击抵抗、相互认证或密钥派生，因此不适合用于无线局域网（WLAN）认证[RFC4017]。然而，尽管如此，只要EAP对等方和服务器上都支持合适的EAP方法，对等方和认证方就可以进行互操作。
Ciphersuite Independence is a requirement for media independence. Since lower-layer ciphersuites vary between media, media independence requires that exported EAP keying material be large enough (with sufficient entropy) to handle any ciphersuite.
密码套件独立性是媒体独立性的要求。由于较低层密码套件在不同介质之间有所不同，介质独立性要求导出的EAP键控材料足够大（具有足够的熵）以处理任何密码套件。
While EAP methods can negotiate the ciphersuite used in protection of the EAP conversation, the ciphersuite used for the protection of the data exchanged after EAP authentication has completed is negotiated between the peer and authenticator within the lower layer, outside of EAP.
虽然EAP方法可以协商用于保护EAP会话的密码套件，但用于保护EAP身份验证完成后交换的数据的密码套件是在EAP之外的较低层内的对等方和身份验证方之间协商的。
For example, within PPP, the ciphersuite is negotiated within the Encryption Control Protocol (ECP) defined in [RFC1968], after EAP authentication is completed. Within [IEEE-802.11], the AP ciphersuites are advertised in the Beacon and Probe Responses prior to EAP authentication and are securely verified during a 4-way handshake exchange.
例如，在PPP中，在EAP身份验证完成后，在[RFC1968]中定义的加密控制协议（ECP）内协商密码套件。在[IEEE-802.11]中，AP密码套件在EAP认证之前在信标和探测响应中公布，并在4路握手交换期间安全验证。
Since the ciphersuites used to protect data depend on the lower layer, requiring that EAP methods have knowledge of lower-layer ciphersuites would compromise the principle of media independence. As a result, methods export EAP keying material that is ciphersuite independent. Since ciphersuite negotiation occurs in the lower layer, there is no need for lower-layer ciphersuite negotiation within EAP.
由于用于保护数据的密码套件依赖于较低层，因此要求EAP方法了解较低层密码套件将损害媒体独立性原则。因此，这些方法导出与密码套件无关的EAP键控材料。由于密码套件协商发生在较低层，因此EAP中不需要较低层的密码套件协商。
In order to allow a ciphersuite to be usable within the EAP keying framework, the ciphersuite specification needs to describe how TSKs suitable for use with the ciphersuite are derived from exported EAP keying material. To maintain method independence, algorithms for deriving TSKs MUST NOT depend on the EAP method, although algorithms for TEK derivation MAY be specific to the EAP method.
为了允许密码套件在EAP键控框架内可用，密码套件规范需要描述适合与密码套件一起使用的TSK是如何从导出的EAP键控材料中派生出来的。为保持方法独立性，推导TSK的算法不得依赖于EAP方法，尽管TEK推导的算法可能特定于EAP方法。
Advantages of ciphersuite-independence include:
密码套件独立性的优点包括：
Reduced update requirements Ciphersuite independence enables EAP methods to be used with new ciphersuites without requiring the methods to be updated. If EAP methods were to specify how to derive transient session keys for each ciphersuite, they would need to be updated each time a new ciphersuite is developed. In addition, backend authentication servers might not be usable with all EAP-capable authenticators, since the backend authentication server would also need to be updated each time support for a new ciphersuite is added to the authenticator.
减少了更新要求—密码套件独立性使EAP方法能够与新密码套件一起使用，而无需更新方法。如果EAP方法指定如何为每个密码套件派生临时会话密钥，则每次开发新密码套件时都需要更新这些密钥。此外，后端身份验证服务器可能无法与所有支持EAP的身份验证程序一起使用，因为每次向身份验证程序添加对新密码套件的支持时，都需要更新后端身份验证服务器。
Reduced EAP method complexity Ciphersuite independence enables EAP methods to avoid having to include ciphersuite-specific code. Requiring each EAP method to include ciphersuite-specific code for transient session key derivation would increase method complexity and result in duplicated effort.
Reduced EAP method complexity Ciphersuite independence enables EAP methods to avoid having to include ciphersuite-specific code. Requiring each EAP method to include ciphersuite-specific code for transient session key derivation would increase method complexity and result in duplicated effort.translate error, please retry
Simplified configuration Ciphersuite independence enables EAP method implementations on the peer and server to avoid having to configure ciphersuite-specific parameters. The ciphersuite is negotiated between the peer and authenticator outside of EAP. Where the authenticator operates in "pass-through" mode, the EAP server is not a party to this negotiation, nor is it involved in the data flow between the EAP peer and authenticator. As a result, the EAP server does not have knowledge of the ciphersuites and negotiation policies implemented by the peer and authenticator, nor is it aware of the ciphersuite negotiated between them. For example, since Encryption Control Protocol (ECP) negotiation occurs after authentication, when run over PPP, the EAP peer and
简化的配置Ciphersuite独立性使EAP方法在对等机和服务器上实现，从而避免必须配置特定于Ciphersuite的参数。密码套件由EAP之外的对等方和认证方协商。在认证器以“直通”模式运行的情况下，EAP服务器不是该协商的一方，也不参与EAP对等方和认证器之间的数据流。因此，EAP服务器不知道对等方和身份验证方实现的密码套件和协商策略，也不知道它们之间协商的密码套件。例如，由于加密控制协议（ECP）协商发生在身份验证之后，因此当在PPP上运行时，EAP对等方和
server cannot anticipate the negotiated ciphersuite, and therefore, this information cannot be provided to the EAP method.
服务器无法预期协商的密码套件，因此，无法将此信息提供给EAP方法。
On completion of EAP authentication, EAP keying material and parameters exported by the EAP method are provided to the lower layer and AAA layer (if present). These include the Master Session Key (MSK), Extended Master Session Key (EMSK), Peer-Id(s), Server-Id(s), and Session-Id. The Initialization Vector (IV) is deprecated, but might be provided.
EAP认证完成后，将EAP方法导出的EAP密钥材料和参数提供给下层和AAA层（如果存在）。其中包括主会话密钥（MSK）、扩展主会话密钥（EMSK）、对等Id、服务器Id和会话Id。不推荐使用初始化向量（IV），但可能会提供。
In order to preserve the security of EAP keying material derived within methods, lower layers MUST NOT export keys passed down by EAP methods. This implies that EAP keying material passed down to a lower layer is for the exclusive use of that lower layer and MUST NOT be used within another lower layer. This prevents compromise of one lower layer from compromising other applications using EAP keying material.
为了保护方法中派生的EAP密钥材料的安全性，较低层不得导出EAP方法传递的密钥。这意味着传递到较低层的EAP键控材料仅供该较低层使用，不得在另一较低层内使用。这可防止一个较低层的损坏损害使用EAP键控材料的其他应用程序。
EAP keying material provided to a lower layer MUST NOT be transported to another entity. For example, EAP keying material passed down to the EAP peer lower layer MUST NOT leave the peer; EAP keying material passed down or transported to the EAP authenticator lower layer MUST NOT leave the authenticator.
提供给下层的EAP键控材料不得运输至其他实体。例如，传递到EAP对等下层的EAP键控材料不得离开对等层；传递或传输到EAP验证器下层的EAP密钥材料不得离开验证器。
On the EAP server, keying material and parameters requested by and passed down to the AAA layer MAY be replicated to the AAA layer on the authenticator (with the exception of the EMSK). On the authenticator, the AAA layer provides the replicated keying material and parameters to the lower layer over which the EAP authentication conversation took place. This enables mode independence to be maintained.
在EAP服务器上，由AAA层请求并传递给AAA层的密钥材料和参数可以复制到认证器上的AAA层（EMSK除外）。在认证器上，AAA层向EAP认证对话发生的较低层提供复制的密钥材料和参数。这样可以保持模式独立性。
The EAP layer, as well as the peer and authenticator layers, MUST NOT modify or cache keying material or parameters (including channel bindings) passing in either direction between the EAP method layer and the lower layer or AAA layer.
EAP层以及对等层和身份验证层不得修改或缓存在EAP方法层和较低层或AAA层之间的任何方向传递的密钥材料或参数（包括通道绑定）。
Where explicitly supported by the lower layer, lower layers MAY cache keying material, including exported EAP keying material and/or TSKs; the structure of this key cache is defined by the lower layer. So as to enable interoperability, new lower-layer specifications MUST describe key caching behavior. Unless explicitly specified by the lower layer, the EAP peer, server, and authenticator MUST assume that
在较低层明确支持的情况下，较低层可以缓存键控材料，包括导出的EAP键控材料和/或TSK；该密钥缓存的结构由下层定义。为了实现互操作性，新的底层规范必须描述密钥缓存行为。除非下层明确指定，否则EAP对等方、服务器和验证器必须假定
peers and authenticators do not cache keying material. Existing EAP lower layers and AAA layers handle the generation of transient session keys and caching of EAP keying material in different ways:
对等方和身份验证器不缓存关键帧材料。现有EAP下层和AAA层以不同的方式处理临时会话密钥的生成和EAP密钥材料的缓存：
IEEE 802.1X-2004 When used with wired networks, IEEE 802.1X-2004 [IEEE-802.1X] does not support link-layer ciphersuites, and as a result, it does not provide for the generation of TSKs or caching of EAP keying material and parameters. Once EAP authentication completes, it is assumed that EAP keying material and parameters are discarded; on IEEE 802 wired networks, there is no subsequent Secure Association Protocol exchange. Perfect Forward Secrecy (PFS) is only possible if the negotiated EAP method supports this.
IEEE 802.1X-2004当与有线网络一起使用时，IEEE 802.1X-2004[IEEE-802.1X]不支持链路层密码套件，因此，它不提供TSK的生成或EAP密钥材料和参数的缓存。一旦EAP认证完成，假定EAP密钥材料和参数被丢弃；在IEEE 802有线网络上，没有后续的安全关联协议交换。只有协商EAP方法支持这一点，才能实现完全前向保密（PFS）。
PPP PPP, defined in [RFC1661], does not include support for a Secure Association Protocol, nor does it support caching of EAP keying material or parameters. PPP ciphersuites derive their TSKs directly from the MSK, as described in [RFC2716] Section 3.5. This is NOT RECOMMENDED, since if PPP were to support caching of EAP keying material, this could result in TSK reuse. As a result, once the PPP session is terminated, EAP keying material and parameters MUST be discarded. Since caching of EAP keying material is not permitted within PPP, there is no way to handle TSK re-key without EAP re-authentication. Perfect Forward Secrecy (PFS) is only possible if the negotiated EAP method supports this.
[RFC1661]中定义的PPP不支持安全关联协议，也不支持EAP密钥材料或参数的缓存。PPP密码套件直接从MSK派生其TSK，如[RFC2716]第3.5节所述。不建议这样做，因为如果PPP支持EAP键控材料的缓存，这可能会导致TSK重用。因此，一旦PPP会话终止，EAP键控材料和参数必须丢弃。由于PPP中不允许缓存EAP密钥材料，因此在没有EAP重新认证的情况下，无法处理TSK重新密钥。只有协商EAP方法支持这一点，才能实现完全前向保密（PFS）。
IKEv2 IKEv2, defined in [RFC4306], only uses the MSK for authentication purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id or Session-Id are not used. As a result, the TSKs derived by IKEv2 are cryptographically independent of the EAP keying material and re-key of IPsec SAs can be handled without requiring EAP re-authentication. Within IKEv2, it is possible to negotiate PFS, regardless of which EAP method is negotiated. IKEv2 as specified in [RFC4306] does not cache EAP keying material or parameters; once IKEv2 authentication completes, it is assumed that EAP keying material and parameters are discarded. The Session-Timeout Attribute is therefore interpreted as a limit on the VPN session time, rather than an indication of the MSK key lifetime.
[RFC4306]中定义的IKEv2 IKEv2仅将MSK用于身份验证目的，而不用于密钥派生。不使用EMSK、IV、对等Id、服务器Id或会话Id。因此，IKEv2派生的TSK在加密上独立于EAP密钥材料，并且可以在不需要EAP重新身份验证的情况下处理IPsec SAs的重新密钥。在IKEv2中，无论协商哪种EAP方法，都可以协商PFS。[RFC4306]中规定的IKEv2不缓存EAP键控材料或参数；IKEv2身份验证完成后，假定EAP密钥材料和参数被丢弃。因此，会话超时属性被解释为VPN会话时间的限制，而不是MSK密钥生存期的指示。
IEEE 802.11 IEEE 802.11 enables caching of the MSK, but not the EMSK, IV, Peer-Id, Server-Id, or Session-Id. More details about the structure of the cache are available in [IEEE-802.11]. In IEEE
IEEE 802.11 IEEE 802.11启用MSK缓存，但不启用EMSK、IV、对等Id、服务器Id或会话Id。有关缓存结构的更多详细信息，请参阅[IEEE-802.11]。在IEEE中
802.11, TSKs are derived from the MSK using a Secure Association Protocol known as the 4-way handshake, which includes a nonce exchange. This guarantees TSK freshness even if the MSK is reused. The 4-way handshake also enables TSK re-key without EAP re-authentication. PFS is only possible within IEEE 802.11 if caching is not enabled and the negotiated EAP method supports PFS.
802.11，TSK是使用称为4路握手的安全关联协议从MSK派生而来的，其中包括一个nonce交换。即使MSK被重复使用，也能保证TSK的新鲜度。4路握手还支持TSK重新密钥，而无需EAP重新身份验证。只有在未启用缓存且协商EAP方法支持PFS的情况下，才能在IEEE 802.11中实现PFS。
IEEE 802.16e IEEE 802.16e, defined in [IEEE-802.16e], supports caching of the MSK, but not the EMSK, IV, Peer-Id, Server-Id, or Session-Id. IEEE 802.16e supports a Secure Association Protocol in which TSKs are chosen by the authenticator without any contribution by the peer. The TSKs are encrypted, authenticated, and integrity protected using the MSK and are transported from the authenticator to the peer. TSK re-key is possible without EAP re-authentication. PFS is not possible even if the negotiated EAP method supports it.
IEEE 802.16e[IEEE-802.16e]中定义的IEEE 802.16e支持MSK的缓存，但不支持EMSK、IV、对等Id、服务器Id或会话Id。IEEE 802.16e支持安全关联协议，在该协议中，TSK由认证器选择，而无需对等方的任何贡献。TSK使用MSK进行加密、身份验证和完整性保护，并从身份验证程序传输到对等方。TSK重新密钥无需EAP重新身份验证。即使协商EAP方法支持PFS，也不可能实现PFS。
AAA Existing implementations and specifications for RADIUS/EAP [RFC3579] or Diameter EAP [RFC4072] do not support caching of keying material or parameters. In existing AAA clients, proxy and server implementations, exported EAP keying material (MSK, EMSK, and IV), as well as parameters and derived keys are not cached and MUST be presumed lost after the AAA exchange completes.
AAA RADIUS/EAP[RFC3579]或Diameter EAP[RFC4072]的现有实施和规范不支持键控材质或参数的缓存。在现有的AAA客户端、代理和服务器实现中，导出的EAP密钥材料（MSK、EMSK和IV）以及参数和派生密钥不会被缓存，必须假定在AAA交换完成后丢失。
In order to avoid key reuse, the AAA layer MUST delete transported keys once they are sent. The AAA layer MUST NOT retain keys that it has previously sent. For example, a AAA layer that has transported the MSK MUST delete it, and keys MUST NOT be derived from the MSK from that point forward.
为了避免密钥重用，AAA层必须在发送传输的密钥后删除它们。AAA层不得保留其先前发送的密钥。例如，已传输MSK的AAA层必须将其删除，并且不能从该点向前从MSK派生密钥。
This specification does not impose constraints on the architecture of the EAP authenticator or peer. For example, any of the authenticator architectures described in [RFC4118] can be used. As a result, lower layers need to identify EAP peers and authenticators unambiguously, without incorporating implicit assumptions about peer and authenticator architectures.
本规范不对EAP认证器或对等机的体系结构施加约束。例如，可以使用[RFC4118]中描述的任何验证器体系结构。因此，较低层需要明确地识别EAP对等方和身份验证方，而不需要合并关于对等方和身份验证方架构的隐含假设。
For example, it is possible for multiple base stations and a "controller" (e.g., WLAN switch) to comprise a single EAP authenticator. In such a situation, the "base station identity" is irrelevant to the EAP method conversation, except perhaps as an opaque blob to be used in channel binding. Many base stations can share the same authenticator identity. An EAP authenticator or peer:
例如，多个基站和“控制器”（例如，WLAN交换机）可以包括单个EAP认证器。在这种情况下，“基站标识”与EAP方法对话无关，除了可能作为用于信道绑定的不透明blob之外。许多基站可以共享相同的验证器标识。EAP验证器或对等方：
(a) can contain one or more physical or logical ports;
(b) can advertise itself as one or more "virtual" authenticators
or peers;
(c) can utilize multiple CPUs;
(d) can support clustering services for load balancing or
failover.
(a) can contain one or more physical or logical ports;
(b) can advertise itself as one or more "virtual" authenticators
or peers;
(c) can utilize multiple CPUs;
(d) can support clustering services for load balancing or
failover.
Both the EAP peer and authenticator can have more than one physical or logical port. A peer can simultaneously access the network via multiple authenticators, or via multiple physical or logical ports on a given authenticator. Similarly, an authenticator can offer network access to multiple peers, each via a separate physical or logical port. When a single physical authenticator advertises itself as multiple virtual authenticators, it is possible for a single physical port to belong to multiple virtual authenticators.
EAP对等方和验证器都可以有多个物理或逻辑端口。对等方可以通过多个验证器或通过给定验证器上的多个物理或逻辑端口同时访问网络。类似地，验证器可以通过单独的物理或逻辑端口向多个对等方提供网络访问。当单个物理验证器作为多个虚拟验证器宣传自己时，单个物理端口可能属于多个虚拟验证器。
An authenticator can be configured to communicate with more than one EAP server, each of which is configured to communicate with a subset of the authenticators. The situation is illustrated in Figure 3.
验证器可被配置为与多个EAP服务器通信，其中每个EAP服务器被配置为与验证器的子集通信。这种情况如图3所示。
The EAP method conversation is between the EAP peer and server. The authenticator identity, if considered at all by the EAP method, is treated as an opaque blob for the purpose of channel binding (see Section 5.3.3). However, the authenticator identity is important in two other exchanges - the AAA protocol exchange and the Secure Association Protocol conversation.
EAP方法对话在EAP对等方和服务器之间进行。如果EAP方法考虑认证者身份，则为了通道绑定的目的，将其视为不透明blob（参见第5.3.3节）。然而，认证者身份在另外两种交换中很重要——AAA协议交换和安全关联协议会话。
The AAA conversation is between the EAP authenticator and the backend authentication server. From the point of view of the backend authentication server, keying material and parameters are transported to the EAP authenticator identified by the NAS-Identifier Attribute. Since an EAP authenticator MUST NOT share EAP keying material or parameters with another party, if the EAP peer or backend authentication server detects use of EAP keying material and parameters outside the scope defined by the NAS-Identifier, the keying material MUST be considered compromised.
AAA对话在EAP身份验证程序和后端身份验证服务器之间进行。从后端身份验证服务器的角度来看，密钥材料和参数被传输到由NAS标识符属性标识的EAP身份验证程序。由于EAP验证器不得与另一方共享EAP密钥材料或参数，因此，如果EAP对等或后端身份验证服务器检测到在NAS标识符定义的范围之外使用EAP密钥材料和参数，则必须将密钥材料视为已泄露。
The Secure Association Protocol conversation is between the peer and the authenticator. For lower layers that support key caching, it is particularly important for the EAP peer, authenticator, and backend server to have a consistent view of the usage scope of the transported keying material. In order to enable this, it is RECOMMENDED that the Secure Association Protocol explicitly communicate the usage scope of the EAP keying material passed down to the lower layer, rather than implicitly assuming that this is defined by the authenticator and peer endpoint addresses.
安全关联协议对话在对等方和身份验证方之间进行。对于支持密钥缓存的较低层，EAP对等方、验证器和后端服务器对传输的密钥材料的使用范围具有一致的视图尤为重要。为了实现这一点，建议安全关联协议显式地将EAP密钥材料的使用范围传递给下层，而不是隐式地假设这是由验证器和对等端点地址定义的。
+-+-+-+-+
| EAP |
| Peer |
+-+-+-+-+
| | | Peer Ports
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \ Authenticator
| | | | | | | | | Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | |
| Auth1 | | Auth2 | | Auth3 |
| | | | | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | \ |
\ | \ |
\ | \ |
EAP over AAA \ | \ |
(optional) \ | \ |
\ | \ |
\ | \ |
\ | \ |
+-+-+-+-+-+ +-+-+-+-+-+ Backend
| EAP | | EAP | Authentication
| Server1 | | Server2 | Servers
+-+-+-+-+-+ +-+-+-+-+-+
+-+-+-+-+
| EAP |
| Peer |
+-+-+-+-+
| | | Peer Ports
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \ Authenticator
| | | | | | | | | Ports
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
| | | | | |
| Auth1 | | Auth2 | | Auth3 |
| | | | | |
+-+-+-+-+ +-+-+-+-+ +-+-+-+-+
\ | \ |
\ | \ |
\ | \ |
EAP over AAA \ | \ |
(optional) \ | \ |
\ | \ |
\ | \ |
\ | \ |
+-+-+-+-+-+ +-+-+-+-+-+ Backend
| EAP | | EAP | Authentication
| Server1 | | Server2 | Servers
+-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Relationship between EAP Peer, Authenticator, and Server
图3:EAP对等方、验证器和服务器之间的关系
Since an authenticator can have multiple ports, the scope of the authenticator key cache cannot be described by a single endpoint address. Similarly, where a peer can have multiple ports and sharing of EAP keying material and parameters between peer ports of the same
由于验证器可以有多个端口，因此验证器密钥缓存的范围不能用单个端点地址来描述。类似地，一个对等方可以有多个端口，并在相同端口的对等端口之间共享EAP密钥材料和参数
link type is allowed, the extent of the peer key cache cannot be communicated by using a single endpoint address. Instead, it is RECOMMENDED that the EAP peer and authenticator consistently identify themselves utilizing explicit identifiers, rather than endpoint addresses or port identifiers.
如果允许使用链接类型，则无法使用单个端点地址通信对等密钥缓存的范围。相反，建议EAP对等方和认证方使用显式标识符（而不是端点地址或端口标识符）一致地标识自己。
AAA protocols such as RADIUS [RFC3579] and Diameter [RFC4072] provide a mechanism for the identification of AAA clients; since the EAP authenticator and AAA client MUST be co-resident, this mechanism is applicable to the identification of EAP authenticators.
诸如RADIUS[RFC3579]和Diameter[RFC4072]之类的AAA协议提供了一种识别AAA客户端的机制；由于EAP验证器和AAA客户端必须是共同驻留的，因此此机制适用于EAP验证器的标识。
RADIUS [RFC2865] requires that an Access-Request packet contain one or more of the NAS-Identifier, NAS-IP-Address, and NAS-IPv6-Address attributes. Since a NAS can have more than one IP address, the NAS-Identifier Attribute is RECOMMENDED for explicit identification of the authenticator, both within the AAA protocol exchange and the Secure Association Protocol conversation.
RADIUS[RFC2865]要求访问请求数据包包含一个或多个NAS标识符、NAS IP地址和NAS-IPv6-Address属性。由于NAS可以有多个IP地址，建议使用NAS标识符属性在AAA协议交换和安全关联协议对话中明确标识身份验证程序。
Problems that can arise where the peer and authenticator implicitly identify themselves using endpoint addresses include the following:
对等方和身份验证方使用端点地址隐式标识自己时可能出现的问题包括：
(a) It is possible that the peer will not be able to determine which authenticator ports are associated with which authenticators. As a result, the EAP peer will be unable to utilize the authenticator key cache in an efficient way, and will also be unable to determine whether EAP keying material has been shared outside its authorized scope, and therefore needs to be considered compromised.
(a) 对等方可能无法确定哪些验证器端口与哪些验证器关联。因此，EAP对等方将无法有效地利用验证器密钥缓存，并且也将无法确定EAP密钥材料是否已在其授权范围之外共享，因此需要被视为已泄露。
(b) It is possible that the authenticator will not be able to determine which peer ports are associated with which peers, preventing the peer from communicating with it utilizing multiple peer ports.
(b) 验证器可能无法确定哪些对等端口与哪些对等端口相关联，从而阻止对等端口利用多个对等端口与其通信。
(c) It is possible that the peer will not be able to determine with which virtual authenticator it is communicating. For example, multiple virtual authenticators can share a MAC address, but utilize different NAS-Identifiers.
(c) 对等方可能无法确定与哪个虚拟验证器通信。例如，多个虚拟身份验证程序可以共享一个MAC地址，但使用不同的NAS标识符。
(d) It is possible that the authenticator will not be able to determine with which virtual peer it is communicating. Multiple virtual peers can share a MAC address, but utilize different Peer-Ids.
(d) 验证器可能无法确定与哪个虚拟对等方通信。多个虚拟对等方可以共享一个MAC地址，但使用不同的对等方ID。
(e) It is possible that the EAP peer and server will not be able to verify the authenticator identity via channel binding.
(e) EAP对等方和服务器可能无法通过通道绑定验证验证器身份。
For example, problems (a), (c), and (e) occur in [IEEE-802.11], which utilizes peer and authenticator MAC addresses within the 4-way handshake. Problems (b) and (d) do not occur since [IEEE-802.11] only allows a virtual peer to utilize a single port.
例如，问题（a）、（c）和（e）出现在[IEEE-802.11]中，它在4路握手中利用对等和认证器MAC地址。问题（b）和（d）不会发生，因为[IEEE-802.11]只允许虚拟对等方使用单个端口。
The following steps enable lower-layer identities to be securely verified by all parties:
以下步骤使所有各方能够安全地验证下层身份：
(f) Specify the lower-layer parameters used to identify the authenticator and peer. As noted earlier, endpoint or port identifiers are not recommended for identification of the authenticator or peer when it is possible for them to have multiple ports.
(f) 指定用于标识身份验证器和对等方的较低层参数。如前所述，当端点或端口标识符可能具有多个端口时，不建议将其用于身份验证器或对等方的标识。
(g) Communicate the lower-layer identities between the peer and authenticator within phase 0. This allows the peer and authenticator to determine the key scope if a key cache is utilized.
(g) 在阶段0内，在对等方和身份验证器之间传递下层身份。这允许对等方和身份验证器在使用密钥缓存时确定密钥范围。
(h) Communicate the lower-layer authenticator identity between the authenticator and backend authentication server within the NAS-Identifier Attribute.
(h) 在NAS标识符属性内，在身份验证程序和后端身份验证服务器之间传递下层身份验证程序标识。
(i) Include the lower-layer identities within channel bindings (if supported) in phase 1a, ensuring that they are communicated between the EAP peer and server.
(i) 在阶段1a中的通道绑定（如果支持）中包括较低层标识，确保它们在EAP对等方和服务器之间通信。
(j) Support the integrity-protected exchange of identities within phase 2a.
(j) 支持第2a阶段中受完整性保护的身份交换。
(k) Utilize the advertised lower-layer identities to enable the peer and authenticator to verify that keys are maintained within the advertised scope.
(k) 利用公布的较低层标识，使对等方和身份验证器能够验证密钥是否保持在公布的范围内。
When a single physical authenticator advertises itself as multiple virtual authenticators, if the virtual authenticators do not maintain logically separate key caches, then by authenticating to one virtual authenticator, the peer can gain access to the other virtual authenticators sharing a key cache.
当单个物理验证器作为多个虚拟验证器宣传自己时，如果虚拟验证器不维护逻辑上独立的密钥缓存，则通过对一个虚拟验证器进行身份验证，对等方可以访问共享密钥缓存的其他虚拟验证器。
For example, where a physical authenticator implements "Guest" and "Corporate Intranet" virtual authenticators, an attacker acting as a peer could authenticate with the "Guest" virtual authenticator and derive EAP keying material. If the "Guest" and "Corporate Intranet" virtual authenticators share a key cache, then the peer can utilize the EAP keying material derived for the "Guest" network to obtain access to the "Corporate Intranet" network.
例如，当物理身份验证器实现“来宾”和“企业内部网”虚拟身份验证器时，充当对等方的攻击者可以使用“来宾”虚拟身份验证器进行身份验证并派生EAP密钥材料。如果“来宾”和“公司内部网”虚拟认证器共享密钥缓存，则对等方可以利用为“来宾”网络派生的EAP密钥材料来获得对“公司内部网”网络的访问。
The following steps can be taken to mitigate this vulnerability:
可以采取以下步骤来缓解此漏洞：
(a) Authenticators are REQUIRED to cache associated authorizations along with EAP keying material and parameters and to apply authorizations to the peer on each network access, regardless of which virtual authenticator is being accessed. This ensures that an attacker cannot obtain elevated privileges even where the key cache is shared between virtual authenticators, and a peer obtains access to one virtual authenticator utilizing a key cache entry created for use with another virtual authenticator.
(a) 验证器需要缓存相关授权以及EAP密钥材料和参数，并在每次网络访问时向对等方应用授权，而不管访问哪个虚拟验证器。这确保了即使在虚拟身份验证程序之间共享密钥缓存，并且对等方利用为与另一个虚拟身份验证程序一起使用而创建的密钥缓存条目获得对一个虚拟身份验证程序的访问权限的情况下，攻击者也无法获得提升的权限。
(b) It is RECOMMENDED that physical authenticators maintain separate key caches for each virtual authenticator. This ensures that a cache entry created for use with one virtual authenticator cannot be used for access to another virtual authenticator. Since a key cache entry can no longer be shared between virtual authentications, this step provides protection beyond that offered in (a). This is valuable in situations where authorizations are not used to enforce access limitations. For example, where access is limited using a filter installed on a router rather than using authorizations provided to the authenticator, a peer can gain unauthorized access to resources by exploiting a shared key cache entry.
(b) 建议物理验证器为每个虚拟验证器维护单独的密钥缓存。这可确保为一个虚拟身份验证程序创建的缓存项不能用于访问另一个虚拟身份验证程序。由于虚拟身份验证之间无法再共享密钥缓存项，因此此步骤提供了（a）中提供的保护之外的保护。这在授权不用于强制访问限制的情况下非常有用。例如，在使用安装在路由器上的过滤器而不是使用提供给认证器的授权来限制访问的情况下，对等方可以通过利用共享密钥缓存条目来获得对资源的未经授权的访问。
(c) It is RECOMMENDED that each virtual authenticator identify itself consistently to the peer and to the backend authentication server, so as to enable the peer to verify the authenticator identity via channel binding (see Section 5.3.3).
(c) 建议每个虚拟验证器一致地向对等方和后端身份验证服务器标识自己，以便对等方能够通过通道绑定验证验证器标识（请参见第5.3.3节）。
(d) It is RECOMMENDED that each virtual authenticator identify itself distinctly, in order to enable the peer and backend authentication server to tell them apart. For example, this can be accomplished by utilizing a distinct value of the NAS-Identifier Attribute.
(d) 建议每个虚拟身份验证器清楚地标识自己，以便使对等身份验证服务器和后端身份验证服务器能够区分它们。例如，这可以通过利用NAS标识符属性的不同值来实现。
As described in [RFC3748] Section 7.3, the peer identity provided in the EAP-Response/Identity can be different from the peer identities authenticated by the EAP method. For example, the identity provided
如[RFC3748]第7.3节所述，EAP响应/标识中提供的对等身份可能不同于通过EAP方法认证的对等身份。例如，提供的标识
in the EAP-Response/Identity can be a privacy identifier as described in "The Network Access Identifier" [RFC4282] Section 2. As noted in [RFC4284], it is also possible to utilize a Network Access Identifier (NAI) for the purposes of source routing; an NAI utilized for source routing is said to be "decorated" as described in [RFC4282] Section 2.7.
在EAP响应/标识中，可以是“网络访问标识符”[RFC4282]第2节中描述的隐私标识符。如[RFC4284]中所述，还可以利用网络接入标识符（NAI）进行源路由；如[RFC4282]第2.7节所述，用于源路由的NAI被称为“装饰”。
When the EAP peer provides the Network Access Identity (NAI) within the EAP-Response/Identity, as described in [RFC3579], the authenticator copies the NAI included in the EAP-Response/Identity into the User-Name Attribute included within the Access-Request. As the Access-Request is forwarded toward the backend authentication server, AAA proxies remove decoration from the NAI included in the User-Name Attribute; the NAI included within the EAP-Response/Identity encapsulated in the Access-Request remains unchanged. As a result, when the Access-Request arrives at the backend authentication server, the EAP-Response/Identity can differ from the User-Name Attribute (which can have some or all of the decoration removed). In the absence of a Peer-Id, the backend authentication server SHOULD use the contents of the User-Name Attribute, rather than the EAP-Response/Identity, as the peer identity.
当EAP对等方在EAP响应/标识中提供网络访问标识（NAI）时，如[RFC3579]中所述，认证者将EAP响应/标识中包含的NAI复制到访问请求中包含的用户名属性中。当访问请求被转发到后端认证服务器时，AAA代理从用户名属性中包括的NAI中移除装饰；访问请求中封装的EAP响应/标识中包含的NAI保持不变。因此，当访问请求到达后端身份验证服务器时，EAP响应/标识可能不同于用户名属性（可以删除部分或全部装饰）。如果没有对等Id，后端身份验证服务器应使用用户名属性的内容，而不是EAP响应/标识作为对等标识。
It is possible for more than one Peer-Id to be exported by an EAP method. For example, a peer certificate can contain more than one peer identity; in a tunnel method, peer identities can be authenticated within both an outer and inner exchange, and these identities could be different in type and contents. For example, an outer exchange could provide a Peer-Id in the form of a Relative Distinguished Name (RDN), whereas an inner exchange could identify the peer via its NAI or MAC address. Where EAP keying material is determined solely from the outer exchange, only the outer Peer-Id(s) are exported; where the EAP keying material is determined from both the inner and outer exchanges, then both the inner and outer Peer-Id(s) are exported by the tunnel method.
EAP方法可以导出多个对等Id。例如，对等证书可以包含多个对等身份；在隧道方法中，对等身份可以在外部和内部交换中进行身份验证，并且这些身份的类型和内容可能不同。例如，外部交换可以以相对可分辨名称（RDN）的形式提供对等Id，而内部交换可以通过其NAI或MAC地址识别对等Id。如果仅从外部交换确定EAP密钥材料，则仅导出外部对等Id；如果EAP键控材料是通过内部和外部交换确定的，那么内部和外部对等Id都是通过隧道方法导出的。
It is possible for more than one Server-Id to be exported by an EAP method. For example, a server certificate can contain more than one server identity; in a tunnel method, server identities could be authenticated within both an outer and inner exchange, and these identities could be different in type and contents. For example, an outer exchange could provide a Server-Id in the form of an IP address, whereas an inner exchange could identify the server via its Fully-Qualified Domain Name (FQDN) or hostname. Where EAP keying material is determined solely from the outer exchange, only the outer Server-Id(s) are exported by the EAP method; where the EAP keying material is determined from both the inner and outer exchanges, then both the inner and outer Server-Id(s) are exported by the EAP method.
EAP方法可以导出多个服务器Id。例如，一个服务器证书可以包含多个服务器标识；在隧道方法中，服务器标识可以在外部和内部交换中进行身份验证，并且这些标识的类型和内容可能不同。例如，外部exchange可以以IP地址的形式提供服务器Id，而内部exchange可以通过其完全限定的域名（FQDN）或主机名来标识服务器。如果仅从外部交换确定EAP密钥材料，则通过EAP方法仅导出外部服务器Id；如果EAP密钥材料由内部和外部交换确定，则内部和外部服务器Id都通过EAP方法导出。
As shown in Figure 3, an authenticator can be configured to communicate with multiple EAP servers; the EAP server that an authenticator communicates with can vary according to configuration and network and server availability. While the EAP peer can assume that all EAP servers within a realm have access to the credentials necessary to validate an authentication attempt, it cannot assume that all EAP servers share persistent state.
如图3所示，验证器可以配置为与多个EAP服务器通信；验证器与之通信的EAP服务器可以根据配置、网络和服务器可用性而变化。虽然EAP对等方可以假定域中的所有EAP服务器都可以访问验证身份验证尝试所需的凭据，但不能假定所有EAP服务器共享持久状态。
Authenticators can be configured with different primary or secondary EAP servers, in order to balance the load. Also, the authenticator can dynamically determine the EAP server to which requests will be sent; in the event of a communication failure, the authenticator can fail over to another EAP server. For example, in Figure 3, Authenticator2 can be initially configured with EAP server1 as its primary backend authentication server, and EAP server2 as the backup, but if EAP server1 becomes unavailable, EAP server2 can become the primary server.
可以使用不同的主或辅助EAP服务器配置身份验证程序，以平衡负载。此外，认证器可以动态地确定将向其发送请求的EAP服务器；在通信失败的情况下，身份验证程序可以故障转移到另一个EAP服务器。例如，在图3中，Authenticator2最初可以配置为EAP server1作为其主要后端身份验证服务器，EAP server2作为备份，但如果EAP server1不可用，则EAP server2可以成为主要服务器。
In general, the EAP peer cannot direct an authentication attempt to a particular EAP server within a realm, this decision is made by AAA clients, nor can the peer determine with which EAP server it will be communicating, prior to the start of the EAP method conversation. The Server-Id is not included in the EAP-Request/Identity, and since the EAP server may be determined dynamically, it typically is not possible for the authenticator to advertise the Server-Id during the discovery phase. Some EAP methods do not export the Server-Id so that it is possible that the EAP peer will not learn with which server it was conversing after the EAP conversation completes successfully.
通常，EAP对等方无法将身份验证尝试定向到域内的特定EAP服务器，此决定由AAA客户端做出，也无法在EAP方法对话开始之前确定将与哪个EAP服务器通信。服务器Id不包括在EAP请求/标识中，并且由于EAP服务器可以动态确定，因此认证器通常不可能在发现阶段公布服务器Id。某些EAP方法不导出服务器Id，因此EAP对等方可能无法在EAP对话成功完成后了解正在与哪个服务器进行对话。
As a result, an EAP peer, on connecting to a new authenticator or reconnecting to the same authenticator, can find itself communicating with a different EAP server. Fast reconnect, defined in [RFC3748]
因此，EAP对等方在连接到新的验证器或重新连接到同一验证器时，会发现自己正在与不同的EAP服务器通信。[RFC3748]中定义的快速重新连接
Section 7.2, can fail if the EAP server with which the peer communicates is not the same one with which it initially established a security association. For example, an EAP peer attempting an EAP-TLS session resume can find that the new EAP-TLS server will not have access to the TLS Master Key identified by the TLS Session-Id, and therefore the session resumption attempt will fail, requiring completion of a full EAP-TLS exchange.
如果对等方与之通信的EAP服务器与其最初建立安全关联的EAP服务器不同，则第7.2节可能会失败。例如，尝试EAP-TLS会话恢复的EAP对等方会发现新的EAP-TLS服务器将无法访问TLS会话Id标识的TLS主密钥，因此会话恢复尝试将失败，需要完成完整的EAP-TLS交换。
EAP methods that export the Server-Id MUST authenticate the server. However, not all EAP methods supporting mutual authentication provide a non-null Server-Id; some methods only enable the EAP peer to verify that the EAP server possesses a long-term secret, but do not provide the identity of the EAP server. In this case, the EAP peer will know that an authenticator has been authorized by an EAP server, but will not confirm the identity of the EAP server. Where the EAP method does not provide a Server-Id, the peer cannot identify the EAP server with which it generated keying material. This can make it difficult for the EAP peer to identify the location of a key possessed by that EAP server.
导出服务器Id的EAP方法必须对服务器进行身份验证。然而，并非所有支持相互认证的EAP方法都提供非空的服务器Id；某些方法仅允许EAP对等方验证EAP服务器是否拥有长期机密，但不提供EAP服务器的标识。在这种情况下，EAP对等方将知道验证器已被EAP服务器授权，但不会确认EAP服务器的身份。如果EAP方法不提供服务器Id，则对等方无法识别生成密钥材料的EAP服务器。这会使EAP对等方难以识别该EAP服务器拥有的密钥的位置。
As noted in [RFC5216] Section 5.2, EAP methods supporting authentication using server certificates can determine the Server-Id from the subject or subjectAltName fields in the server certificate. Validating the EAP server identity can help the EAP peer to decide whether a specific EAP server is authorized. In some cases, such as where the certificate extensions defined in [RFC4334] are included in the server certificate, it can even be possible for the peer to verify some channel binding parameters from the server certificate.
如[RFC5216]第5.2节所述，支持使用服务器证书进行身份验证的EAP方法可以从服务器证书中的subject或subjectAltName字段确定服务器Id。验证EAP服务器标识可以帮助EAP对等方确定特定EAP服务器是否经过授权。在某些情况下，例如[RFC4334]中定义的证书扩展包含在服务器证书中，对等方甚至可以从服务器证书验证一些通道绑定参数。
It is possible for problems to arise in situations where the EAP server identifies itself differently to the EAP peer and authenticator. For example, it is possible that the Server-Id exported by EAP methods will not be identical to the Fully Qualified Domain Name (FQDN) of the backend authentication server. Where certificate-based authentication is used within RADIUS or Diameter, it is possible that the subjectAltName used in the backend authentication server certificate will not be identical to the Server-Id or backend authentication server FQDN. This is not normally an issue in EAP, as the authenticator will be unaware of the identities used between the EAP peer and server. However, this can be an issue for key caching, if the authenticator is expected to locate a backend authentication server corresponding to a Server-Id provided by an EAP peer.
在EAP服务器以不同于EAP对等方和验证器的方式标识自身的情况下，可能会出现问题。例如，EAP方法导出的服务器Id可能与后端身份验证服务器的完全限定域名（FQDN）不同。如果在RADIUS或Diameter中使用基于证书的身份验证，则后端身份验证服务器证书中使用的subjectAltName可能与服务器Id或后端身份验证服务器FQDN不同。这在EAP中通常不是问题，因为身份验证器将不知道EAP对等方和服务器之间使用的身份。但是，如果期望验证器定位与EAP对等方提供的服务器Id相对应的后端身份验证服务器，则这可能是密钥缓存的问题。
Where the backend authentication server FQDN differs from the subjectAltName in the backend authentication server certificate, it is possible that the AAA client will not be able to determine whether it is talking to the correct backend authentication server. Where
如果后端身份验证服务器FQDN与后端身份验证服务器证书中的subjectAltName不同，则AAA客户端可能无法确定它是否正在与正确的后端身份验证服务器通信。哪里
the Server-Id and backend authentication server FQDN differ, it is possible that the combination of the key scope (Peer-Id(s), Server-Id(s)) and EAP conversation identifier (Session-Id) will not be sufficient to determine where the key resides. For example, the authenticator can identify backend authentication servers by their IP address (as occurs in RADIUS), or using a Fully Qualified Domain Name (as in Diameter). If the Server-Id does not correspond to the IP address or FQDN of a known backend authentication server, then it may not be possible to locate which backend authentication server possesses the key.
服务器Id和后端身份验证服务器FQDN不同，密钥作用域（对等Id、服务器Id）和EAP会话标识符（会话Id）的组合可能不足以确定密钥驻留的位置。例如，身份验证器可以通过其IP地址（如RADIUS中所示）或使用完全限定的域名（如Diameter中所示）来识别后端身份验证服务器。如果服务器Id与已知后端身份验证服务器的IP地址或FQDN不对应，则可能无法找到哪个后端身份验证服务器拥有密钥。
EAP, as defined in [RFC3748], supports key derivation, but does not provide for the management of lower-layer security associations. Missing functionality includes:
[RFC3748]中定义的EAP支持密钥派生，但不提供底层安全关联的管理。缺少的功能包括：
(a) Security Association negotiation. EAP does not negotiate lower-layer unicast or multicast security associations, including cryptographic algorithms or traffic profiles. EAP methods only negotiate cryptographic algorithms for their own use, not for the underlying lower layers. EAP also does not negotiate the traffic profiles to be protected with the negotiated ciphersuites; in some cases the traffic to be protected can have lower-layer source and destination addresses different from the lower-layer peer or authenticator addresses.
(a) 安全协会谈判。EAP不协商较低层单播或多播安全关联，包括加密算法或流量配置文件。EAP方法只为其自身使用而协商加密算法，而不为底层使用。EAP也不使用协商的密码套件协商要保护的流量配置文件；在某些情况下，要保护的流量可以具有不同于较低层对等方或验证器地址的较低层源地址和目标地址。
(b) Re-key. EAP does not support the re-keying of exported EAP keying material without EAP re-authentication, although EAP methods can support "fast reconnect" as defined in [RFC3748] Section 7.2.1.
(b) 重调。EAP不支持在没有EAP重新认证的情况下对导出的EAP密钥材料进行重新密钥设置，尽管EAP方法可以支持[RFC3748]第7.2.1节中定义的“快速重新连接”。
(c) Key delete/install semantics. EAP does not synchronize installation or deletion of keying material on the EAP peer and authenticator.
(c) 键删除/安装语义。EAP不会在EAP对等机和验证器上同步密钥材料的安装或删除。
(d) Lifetime negotiation. EAP does not support lifetime negotiation for exported EAP keying material, and existing EAP methods also do not support key lifetime negotiation.
(d) 终身谈判。EAP不支持导出的EAP密钥材料的生存期协商，现有的EAP方法也不支持密钥生存期协商。
(e) Guaranteed TSK freshness. Without a post-EAP handshake, TSKs can be reused if EAP keying material is cached.
(e) 保证TSK新鲜度。没有EAP后握手，如果缓存EAP键控材料，则可以重用TSK。
These deficiencies are typically addressed via a post-EAP handshake known as the Secure Association Protocol.
这些缺陷通常通过称为安全关联协议的EAP后握手来解决。
Since neither EAP nor EAP methods provide for establishment of lower-layer security associations, it is RECOMMENDED that these facilities be provided within the Secure Association Protocol, including:
由于EAP和EAP方法均未规定建立下层安全关联，因此建议在安全关联协议中提供这些设施，包括：
(a) Entity Naming. A basic feature of a Secure Association Protocol is the explicit naming of the parties engaged in the exchange. Without explicit identification, the parties engaged in the exchange are not identified and the scope of the EAP keying parameters negotiated during the EAP exchange is undefined.
(a) 实体命名。安全关联协议的一个基本特征是对参与交换的各方进行显式命名。在没有明确标识的情况下，无法识别参与交换的各方，且在EAP交换期间协商的EAP密钥参数的范围未定义。
(b) Mutual proof of possession of EAP keying material. During the Secure Association Protocol, the EAP peer and authenticator MUST demonstrate possession of the keying material transported between the backend authentication server and authenticator (e.g., MSK), in order to demonstrate that the peer and authenticator have been authorized. Since mutual proof of possession is not the same as mutual authentication, the peer cannot verify authenticator assertions (including the authenticator identity) as a result of this exchange. Authenticator identity verification is discussed in Section 2.3.
(b) 拥有EAP密钥材料的相互证明。在安全关联协议期间，EAP对等方和认证方必须证明拥有在后端认证服务器和认证方（例如，MSK）之间传输的密钥材料，以便证明对等方和认证方已获得授权。由于相互占有证明与相互身份验证不同，因此对等方无法作为交换的结果验证验证者断言（包括验证者身份）。第2.3节讨论了验证者身份验证。
(c) Secure capabilities negotiation. In order to protect against spoofing during the discovery phase, ensure selection of the "best" ciphersuite, and protect against forging of negotiated security parameters, the Secure Association Protocol MUST support secure capabilities negotiation. This includes the secure negotiation of usage modes, session parameters (such as security association identifiers (SAIDs) and key lifetimes), ciphersuites and required filters, including confirmation of security-relevant capabilities discovered during phase 0. The Secure Association Protocol MUST support integrity and replay protection of all capability negotiation messages.
(c) 安全能力协商。为了在发现阶段防止欺骗，确保选择“最佳”密码套件，并防止伪造协商的安全参数，安全关联协议必须支持安全协商功能。这包括使用模式、会话参数（如安全关联标识符（SAID）和密钥生存期）、密码套件和所需过滤器的安全协商，包括确认在阶段0期间发现的安全相关功能。安全关联协议必须支持所有能力协商消息的完整性和重播保护。
(d) Key naming and selection. Where key caching is supported, it is possible for the EAP peer and authenticator to share more than one key of a given type. As a result, the Secure Association Protocol MUST explicitly name the keys used in the proof of possession exchange, so as to prevent confusion when more than one set of keying material could potentially be used as the basis for the exchange. Use of the key naming mechanism described in Section 1.4.1 is RECOMMENDED.
(d) 键命名和选择。在支持密钥缓存的情况下，EAP对等方和验证器可以共享给定类型的多个密钥。因此，安全关联协议必须明确命名占有证明交换中使用的密钥，以防止在可能使用多组密钥材料作为交换基础时出现混淆。建议使用第1.4.1节中描述的密钥命名机制。
In order to support the correct processing of phase 2 security associations, the Secure Association (phase 2) protocol MUST support the naming of phase 2 security associations and
为了支持阶段2安全关联的正确处理，安全关联（阶段2）协议必须支持阶段2安全关联的命名和
associated transient session keys so that the correct set of transient session keys can be identified for processing a given packet. The phase 2 Secure Association Protocol also MUST support transient session key activation and SHOULD support deletion so that establishment and re-establishment of transient session keys can be synchronized between the parties.
关联的临时会话密钥，以便可以识别用于处理给定数据包的正确的临时会话密钥集。第2阶段安全关联协议还必须支持临时会话密钥激活，并应支持删除，以便在双方之间同步临时会话密钥的建立和重新建立。
(e) Generation of fresh transient session keys (TSKs). Where the lower layer supports caching of keying material, the EAP peer lower layer can initiate a new session using keying material that was derived in a previous session. Were the TSKs to be derived solely from a portion of the exported EAP keying material, this would result in reuse of the session keys that could expose the underlying ciphersuite to attack.
(e) 生成新的临时会话密钥（TSK）。在较低层支持缓存键控材料的情况下，EAP对等较低层可以使用先前会话中派生的键控材料启动新会话。如果TSK仅来源于导出的EAP密钥材料的一部分，这将导致会话密钥的重用，从而使底层密码套件受到攻击。
In lower layers where caching of keying material is supported, the Secure Association Protocol phase is REQUIRED, and MUST support the derivation of fresh unicast and multicast TSKs, even when the transported keying material provided by the backend authentication server is not fresh. This is typically supported via the exchange of nonces or counters, which are then mixed with the keying material in order to generate fresh unicast (phase 2a) and possibly multicast (phase 2b) session keys. By not using exported EAP keying material directly to protect data, the Secure Association Protocol protects it against compromise.
在支持缓存密钥材料的较低层中，需要安全关联协议阶段，并且必须支持新单播和多播TSK的派生，即使后端身份验证服务器提供的传输密钥材料不新鲜。这通常通过交换nonce或计数器来支持，然后将其与键控材料混合以生成新的单播（阶段2a）和可能的多播（阶段2b）会话密钥。通过不直接使用导出的EAP密钥材料来保护数据，安全关联协议可以保护数据不受损害。
(f) Key lifetime management. This includes explicit key lifetime negotiation or seamless re-key. EAP does not support the re-keying of EAP keying material without re-authentication, and existing EAP methods do not support key lifetime negotiation. As a result, the Secure Association Protocol MAY handle the re-key and determination of the key lifetime. Where key caching is supported, secure negotiation of key lifetimes is RECOMMENDED. Lower layers that support re-key, but not key caching, may not require key lifetime negotiation. For example, a difference between IKEv1 [RFC2409] and IKEv2 [RFC4306] is that in IKEv1 SA lifetimes were negotiated; in IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and re-keying the SA when necessary.
(f) 密钥生命周期管理。这包括显式密钥生存期协商或无缝重新密钥。EAP不支持未经重新认证的EAP密钥材料的重新密钥，现有EAP方法不支持密钥生存期协商。结果，安全关联协议可以处理重密钥和密钥生存期的确定。在支持密钥缓存的情况下，建议对密钥生存期进行安全协商。支持重密钥但不支持密钥缓存的较低层可能不需要密钥生存期协商。例如，IKEv1[RFC2409]和IKEv2[RFC4306]之间的区别在于，在IKEv1中，SA寿命是协商的；在IKEv2中，SA的每一端都负责在SA上实施自己的生存期策略，并在必要时重新设置SA的密钥。
(g) Key state resynchronization. It is possible for the peer or authenticator to reboot or reclaim resources, clearing portions or all of the key cache. Therefore, key lifetime negotiation cannot guarantee that the key cache will remain synchronized, and it may not be possible for the peer to determine before attempting to use a key whether it exists within the authenticator cache. It is therefore RECOMMENDED for the EAP lower layer to provide a mechanism for key state
(g) 密钥状态重新同步。对等方或身份验证方可以重新启动或回收资源，清除部分或全部密钥缓存。因此，密钥生存期协商无法保证密钥缓存将保持同步，并且对等方可能无法在尝试使用密钥之前确定密钥是否存在于验证器缓存中。因此，建议EAP下层提供密钥状态机制
resynchronization, either via the SAP or using a lower layer indication (see [RFC3748] Section 3.4). Where the peer and authenticator do not jointly possess a key with which to protect the resynchronization exchange, secure resynchronization is not possible, and alternatives (such as an initiation of EAP re-authentication after expiration of a timer) are needed to ensure timely resynchronization.
通过SAP或使用较低层指示进行重新同步（见[RFC3748]第3.4节）。如果对等方和认证方不共同拥有用于保护重新同步交换的密钥，则不可能进行安全的重新同步，并且需要替代方案（例如在计时器过期后启动EAP重新认证）来确保及时的重新同步。
(h) Key scope synchronization. To support key scope determination, the Secure Association Protocol SHOULD provide a mechanism by which the peer can determine the scope of the key cache on each authenticator and by which the authenticator can determine the scope of the key cache on a peer. This includes negotiation of restrictions on key usage.
(h) 键作用域同步。为了支持密钥范围确定，安全关联协议应提供一种机制，通过该机制，对等方可以确定每个认证器上密钥缓存的范围，认证器可以确定对等方上密钥缓存的范围。这包括协商密钥使用的限制。
(i) Traffic profile negotiation. The traffic to be protected by a lower-layer security association will not necessarily have the same lower-layer source or destination address as the EAP peer and authenticator, and it is possible for the peer and authenticator to negotiate multiple security associations, each with a different traffic profile. Where this is the case, the profile of protected traffic SHOULD be explicitly negotiated. For example, in IKEv2 it is possible for an Initiator and Responder to utilize EAP for authentication, then negotiate a Tunnel Mode Security Association (SA), which permits passing of traffic originating from hosts other than the Initiator and Responder. Similarly, in IEEE 802.16e, a Subscriber Station (SS) can forward traffic to the Base Station (BS), which originates from the Local Area Network (LAN) to which it is attached. To enable this, Security Associations within IEEE 802.16e are identified by the Connection Identifier (CID), not by the EAP peer and authenticator MAC addresses. In both IKEv2 and IEEE 802.16e, multiple security associations can exist between the EAP peer and authenticator, each with their own traffic profile and quality of service parameters.
(i) 流量配置文件协商。要由较低层安全关联保护的通信量不一定与EAP对等方和认证方具有相同的较低层源地址或目的地地址，并且对等方和认证方可以协商多个安全关联，每个安全关联具有不同的通信量简档。在这种情况下，应明确协商受保护流量的配置文件。例如，在IKEv2中，发起方和响应方可以利用EAP进行身份验证，然后协商隧道模式安全关联（SA），该关联允许来自发起方和响应方以外的主机的流量通过。类似地，在IEEE 802.16e中，用户站（SS）可以将业务转发到基站（BS），基站（BS）源自其所连接的局域网（LAN）。为了实现这一点，IEEE 802.16e中的安全关联由连接标识符（CID）标识，而不是由EAP对等和认证器MAC地址标识。在IKEv2和IEEE 802.16e中，EAP对等方和认证方之间可以存在多个安全关联，每个安全关联都有自己的流量配置文件和服务质量参数。
(j) Direct operation. Since the phase 2 Secure Association Protocol is concerned with the establishment of security associations between the EAP peer and authenticator, including the derivation of transient session keys, only those parties have "a need to know" the transient session keys. The Secure Association Protocol MUST operate directly between the peer and authenticator and MUST NOT be passed-through to the backend authentication server or include additional parties.
(j) 直接操作。由于阶段2安全关联协议涉及EAP对等方和认证方之间的安全关联的建立，包括瞬态会话密钥的推导，因此只有那些方“需要知道”瞬态会话密钥。安全关联协议必须直接在对等方和身份验证方之间运行，并且不得传递到后端身份验证服务器或包含其他方。
(k) Bi-directional operation. While some ciphersuites only require a single set of transient session keys to protect traffic in both directions, other ciphersuites require a unique set of
(k) 双向操作。虽然某些密码套件只需要一组临时会话密钥来保护双向通信，但其他密码套件需要一组唯一的会话密钥
transient session keys in each direction. The phase 2 Secure Association Protocol SHOULD provide for the derivation of unicast and multicast keys in each direction, so as not to require two separate phase 2 exchanges in order to create a bi-directional phase 2 security association. See [RFC3748] Section 2.4 for more discussion.
每个方向上的临时会话密钥。阶段2安全关联协议应提供每个方向上单播和多播密钥的派生，以便不需要两个单独的阶段2交换来创建双向阶段2安全关联。更多讨论请参见[RFC3748]第2.4节。
Absent explicit specification within the lower layer, after the completion of phase 1b, transported keying material, and parameters are bound to the EAP peer and authenticator, but are not bound to a specific peer or authenticator port.
在较低层中没有明确的规范，在阶段1b完成后，传输的键控材料和参数绑定到EAP对等方和验证器，但不绑定到特定对等方或验证器端口。
While EAP keying material passed down to the lower layer is not intrinsically bound to particular authenticator and peer ports, TSKs MAY be bound to particular authenticator and peer ports by the Secure Association Protocol. However, a lower layer MAY also permit TSKs to be used on multiple peer and/or authenticator ports, provided that TSK freshness is guaranteed (such as by keeping replay counter state within the authenticator).
虽然向下传递到较低层的EAP密钥材料本质上不绑定到特定验证器和对等端口，但是tsk可以通过安全关联协议绑定到特定验证器和对等端口。然而，较低层还可以允许在多个对等和/或认证器端口上使用TSK，前提是保证TSK的新鲜度（例如通过在认证器内保持重播计数器状态）。
In order to further limit the key scope, the following measures are suggested:
为了进一步限制关键范围，建议采取以下措施：
(a) The lower layer MAY specify additional restrictions on key usage, such as limiting the use of EAP keying material and parameters on the EAP peer to the port over which the EAP conversation was conducted.
(a) 较低层可以指定密钥使用的附加限制，例如将EAP对等端上的EAP密钥材料和参数的使用限制为执行EAP会话的端口。
(b) The backend authentication server and authenticator MAY implement additional attributes in order to further restrict the scope of keying material. For example, in IEEE 802.11, the backend authentication server can provide the authenticator with a list of authorized Called or Calling-Station-Ids and/or SSIDs for which keying material is valid.
(b) 后端认证服务器和认证器可以实现附加属性，以便进一步限制密钥材料的范围。例如，在IEEE 802.11中，后端认证服务器可以向认证者提供密钥材料有效的授权被叫或呼叫站id和/或ssid的列表。
(c) Where the backend authentication server provides attributes restricting the key scope, it is RECOMMENDED that restrictions be securely communicated by the authenticator to the peer. This can be accomplished using the Secure Association Protocol, but also can be accomplished via the EAP method or the lower layer.
(c) 如果后端身份验证服务器提供限制密钥作用域的属性，建议身份验证程序将限制安全地传达给对等方。这可以使用安全关联协议来实现，但也可以通过EAP方法或较低层来实现。
When an EAP re-authentication takes place, new EAP keying material is exported by the EAP method. In EAP lower layers where EAP re-authentication eventually results in TSK replacement, the maximum
当EAP重新认证发生时，新的EAP密钥材料将通过EAP方法导出。在EAP较低层中，EAP重新认证最终导致TSK替换，最大
lifetime of derived keying material (including TSKs) can be less than or equal to that of EAP keying material (MSK/EMSK), but it cannot be greater.
派生键控材料（包括TSK）的寿命可以小于或等于EAP键控材料（MSK/EMSK），但不能大于。
Where TSKs are derived from or are wrapped by exported EAP keying material, compromise of that exported EAP keying material implies compromise of TSKs. Therefore, if EAP keying material is considered stale, not only SHOULD EAP re-authentication be initiated, but also replacement of child keys, including TSKs.
如果TSK源自导出的EAP键控材料或由导出的EAP键控材料包裹，则导出的EAP键控材料的折衷意味着TSK的折衷。因此，如果EAP密钥材料被视为过时，则不仅应启动EAP重新身份验证，还应更换子密钥，包括TSK。
Where EAP keying material is used only for entity authentication but not for TSK derivation (as in IKEv2), compromise of exported EAP keying material does not imply compromise of the TSKs. Nevertheless, the compromise of EAP keying material could enable an attacker to impersonate an authenticator, so that EAP re-authentication and TSK re-key are RECOMMENDED.
如果EAP密钥材料仅用于实体认证，而不用于TSK派生（如IKEv2），则导出的EAP密钥材料的泄露并不意味着TSK的泄露。然而，EAP密钥材料的泄露可能使攻击者能够模拟验证器，因此建议使用EAP重新认证和TSK重新密钥。
With respect to IKEv2, Section 5.2 of [RFC4718], "IKEv2 Clarifications and Implementation Guidelines", states:
关于IKEv2，[RFC4718]“IKEv2澄清和实施指南”第5.2节规定：
Rekeying the IKE_SA and reauthentication are different concepts in IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and resets the Message ID counters, but it does not authenticate the parties again (no AUTH or EAP payloads are involved)... This means that reauthentication also establishes new keys for the IKE_SA and CHILD_SAs. Therefore while rekeying can be performed more often than reauthentication, the situation where "authentication lifetime" is shorter than "key lifetime" does not make sense.
在IKEv2中，重新键入IKE_SA和重新验证是不同的概念。为IKE_SA重新设置密钥将为IKE_SA建立新密钥并重置消息ID计数器，但不会再次对各方进行身份验证（不涉及身份验证或EAP有效负载）。。。这意味着重新验证还为IKE_SA和CHILD_SA建立新密钥。因此，虽然可以比重新验证更频繁地执行密钥更新，但“验证生存期”短于“密钥生存期”的情况没有意义。
Child keys that are used frequently (such as TSKs that are used for traffic protection) can expire sooner than the exported EAP keying material on which they are dependent, so that it is advantageous to support re-key of child keys prior to EAP re-authentication. Note that deletion of the MSK/EMSK does not necessarily imply deletion of TSKs or child keys.
频繁使用的子密钥（例如用于流量保护的TSK）可能比它们所依赖的导出EAP密钥材料更早过期，因此在EAP重新身份验证之前支持子密钥的重新密钥是有利的。请注意，删除MSK/EMSK并不一定意味着删除TSK或子密钥。
Failure to mutually prove possession of exported EAP keying material during the Secure Association Protocol exchange need not be grounds for deletion of keying material by both parties; rate-limiting Secure Association Protocol exchanges could be used to prevent a brute force attack.
在安全关联协议交换期间未能相互证明拥有出口EAP密钥材料不必成为双方删除密钥材料的理由；速率限制安全关联协议交换可用于防止暴力攻击。
The Transient EAP Keys (TEKs) are session keys used to protect the EAP conversation. The TEKs are internal to the EAP method and are not exported. TEKs are typically created during an EAP conversation, used until the end of the conversation and then discarded. However, methods can re-key TEKs during an EAP conversation.
瞬态EAP密钥（TEK）是用于保护EAP会话的会话密钥。TEK是EAP方法内部的，不导出。TEK通常在EAP对话期间创建，使用到对话结束，然后丢弃。但是，方法可以在EAP对话期间重新设置TEK的密钥。
When using TEKs within an EAP conversation or across conversations, it is necessary to ensure that replay protection and key separation requirements are fulfilled. For instance, if a replay counter is used, TEK re-key MUST occur prior to wrapping of the counter. Similarly, TSKs MUST remain cryptographically separate from TEKs despite TEK re-keying or caching. This prevents TEK compromise from leading directly to compromise of the TSKs and vice versa.
在EAP会话内或跨会话使用TEK时，必须确保满足重播保护和密钥分离要求。例如，如果使用重播计数器，则必须在包装计数器之前执行TEK re key。同样，TSK必须在加密上与TEK分离，尽管TEK重新加密或缓存。这可防止TEK妥协直接导致TSK妥协，反之亦然。
EAP methods MAY cache local EAP keying material (TEKs) that can persist for multiple EAP conversations when fast reconnect is used [RFC3748]. For example, EAP methods based on TLS (such as EAP-TLS [RFC5216]) derive and cache the TLS Master Secret, typically for substantial time periods. The lifetime of other local EAP keying material calculated within the EAP method is defined by the method. Note that in general, when using fast reconnect, there is no guarantee that the original long-term credentials are still in the possession of the peer. For instance, a smart-card holding the private key for EAP-TLS may have been removed. EAP servers SHOULD also verify that the long-term credentials are still valid, such as by checking that certificate used in the original authentication has not yet expired.
EAP方法可缓存本地EAP密钥材料（TEK），当使用快速重新连接时，该材料可用于多个EAP对话[RFC3748]。例如，基于TLS的EAP方法（例如EAP-TLS[RFC5216]）派生并缓存TLS主密钥，通常为相当长的时间段。在EAP方法中计算的其他本地EAP键控材料的寿命由该方法定义。请注意，通常情况下，在使用快速重新连接时，无法保证原始长期凭据仍由对等方拥有。例如，持有EAP-TLS私钥的智能卡可能已被移除。EAP服务器还应验证长期凭据是否仍然有效，例如检查原始身份验证中使用的证书是否尚未过期。
The following mechanisms are available for communicating the lifetime of keying material between the EAP peer, server, and authenticator:
以下机制可用于在EAP对等方、服务器和验证器之间传递密钥材料的生命周期：
AAA protocols (backend authentication server and authenticator) Lower-layer mechanisms (authenticator and peer) EAP method-specific negotiation (peer and server)
AAA协议（后端身份验证服务器和身份验证程序）下层机制（身份验证程序和对等方）EAP方法特定协商（对等方和服务器）
Where the EAP method does not support the negotiation of the lifetime of exported EAP keying material, and a key lifetime negotiation mechanism is not provided by the lower layer, it is possible that there will not be a way for the peer to learn the lifetime of keying material. This can leave the peer uncertain of how long the authenticator will maintain keying material within the key cache. In this case the lifetime of keying material can be managed as a system parameter on the peer and authenticator; a default lifetime of 8 hours is RECOMMENDED.
如果EAP方法不支持导出EAP密钥材料的生命周期协商，并且较低层未提供密钥生命周期协商机制，则对等方可能无法了解密钥材料的生命周期。这可能使对等方无法确定身份验证器将在密钥缓存中保留密钥材料的时间。在这种情况下，键控材料的寿命可以作为对等方和验证器上的系统参数进行管理；建议默认使用寿命为8小时。
AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be used to communicate the maximum key lifetime from the backend authentication server to the authenticator.
AAA协议，如RADIUS[RFC2865]和Diameter[RFC4072]可用于将最大密钥生存期从后端身份验证服务器传送到身份验证程序。
The Session-Timeout Attribute is defined for RADIUS in [RFC2865] and for Diameter in [RFC4005]. Where EAP is used for authentication, [RFC3580] Section 3.17, indicates that a Session-Timeout Attribute sent in an Access-Accept along with a Termination-Action value of RADIUS-Request specifies the maximum number of seconds of service provided prior to EAP re-authentication.
会话超时属性在[RFC2865]中为半径定义，在[RFC4005]中为直径定义。当EAP用于身份验证时，[RFC3580]第3.17节指出，在访问接受中发送的会话超时属性以及RADIUS请求的终止操作值指定了在EAP重新身份验证之前提供的服务的最大秒数。
However, there is also a need to be able to specify the maximum lifetime of cached keying material. Where EAP pre-authentication is supported, cached keying material can be pre-established on the authenticator prior to session start and will remain there until expiration. EAP lower layers supporting caching of keying material MAY also persist that material after the end of a session, enabling the peer to subsequently resume communication utilizing the cached keying material. In these situations it can be desirable for the backend authentication server to specify the maximum lifetime of cached keying material.
但是，还需要能够指定缓存关键帧材质的最大生存期。在支持EAP预认证的情况下，可以在会话开始之前在验证器上预先建立缓存的密钥材料，并将一直保留到过期。支持键控材料缓存的EAP较低层也可以在会话结束后持久化该材料，使得对等方随后能够利用缓存的键控材料恢复通信。在这些情况下，后端身份验证服务器需要指定缓存密钥材料的最长生存期。
To accomplish this, [IEEE-802.11] overloads the Session-Timeout Attribute, assuming that it represents the maximum time after which transported keying material will expire on the authenticator, regardless of whether transported keying material is cached.
为此，[IEEE-802.11]重载会话超时属性，假设它表示传输的密钥材料在验证器上过期的最长时间，而不管传输的密钥材料是否缓存。
An IEEE 802.11 authenticator receiving transported keying material is expected to initialize a timer to the Session-Timeout value, and once the timer expires, the transported keying material expires. Whether this results in session termination or EAP re-authentication is controlled by the value of the Termination-Action Attribute. Where EAP re-authentication occurs, the transported keying material is replaced, and with it, new calculated keys are put in place. Where session termination occurs, transported and derived keying material is deleted.
接收传输的密钥材料的IEEE 802.11身份验证程序预计会将计时器初始化为会话超时值，一旦计时器过期，传输的密钥材料将过期。这是导致会话终止还是EAP重新身份验证由termination Action属性的值控制。在发生EAP重新认证的情况下，将替换传输的密钥材料，并使用它放置新的计算密钥。当会话终止时，将删除传输的和派生的键控材料。
Overloading the Session-Timeout Attribute is problematic in situations where it is necessary to control the maximum session time and key lifetime independently. For example, it might be desirable to limit the lifetime of cached keying material to 5 minutes while permitting a user once authenticated to remain connected for up to an hour without re-authenticating. As a result, in the future, additional attributes can be specified to control the lifetime of cached keys; these attributes MAY modify the meaning of the Session-Timeout Attribute in specific circumstances.
在需要独立控制最大会话时间和密钥生存期的情况下，重载会话超时属性是有问题的。例如，可能希望将缓存的密钥材料的生命周期限制为5分钟，同时允许用户在经过身份验证后保持连接长达一小时而不重新身份验证。因此，在将来，可以指定附加属性来控制缓存密钥的生存期；这些属性可能会在特定情况下修改会话超时属性的含义。
Since the TSK lifetime is often determined by authenticator resources, and the backend authentication server has no insight into the TSK derivation process by the principle of ciphersuite independence, it is not appropriate for the backend authentication server to manage any aspect of the TSK derivation process, including the TSK lifetime.
由于TSK生存期通常由验证器资源确定，并且后端身份验证服务器没有根据密码套件独立性原则洞察TSK派生过程，因此后端身份验证服务器不适合管理TSK派生过程的任何方面，包括TSK生存期。
Lower-layer mechanisms can be used to enable the lifetime of keying material to be negotiated between the peer and authenticator. This can be accomplished either using the Secure Association Protocol or within the lower-layer transport.
较低层机制可用于在对等方和认证方之间协商密钥材料的生存期。这可以使用安全关联协议或在较低层传输中实现。
Where TSKs are established as the result of a Secure Association Protocol exchange, it is RECOMMENDED that the Secure Association Protocol include support for TSK re-key. Where the TSK is taken directly from the MSK, there is no need to manage the TSK lifetime as a separate parameter, since the TSK lifetime and MSK lifetime are identical.
如果TSK是通过安全关联协议交换建立的，建议安全关联协议包括对TSK重新密钥的支持。如果TSK直接来自MSK，则无需将TSK生存期作为单独的参数进行管理，因为TSK生存期和MSK生存期是相同的。
As noted in [RFC3748] Section 7.10:
如[RFC3748]第7.10节所述：
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方法必须导出至少64个八位字节的主会话密钥（MSK）和至少64个八位字节的扩展主会话密钥（EMSK）。派生密钥的EAP方法必须提供EAP对等方和EAP服务器之间的相互身份验证。
However, EAP does not itself support the negotiation of lifetimes for exported EAP keying material such as the MSK, EMSK, and IV.
但是，EAP本身不支持导出EAP密钥材料（如MSK、EMSK和IV）的寿命协商。
While EAP itself does not support lifetime negotiation, it would be possible to specify methods that do. However, systems that rely on key lifetime negotiation within EAP methods would only function with these methods. Also, there is no guarantee that the key lifetime negotiated within the EAP method would be compatible with backend authentication server policy. In the interest of method independence and compatibility with backend authentication server implementations, management of the lifetime of keying material SHOULD NOT be provided within EAP methods.
虽然EAP本身不支持生存期协商，但可以指定这样做的方法。然而，在EAP方法中依赖密钥生存期协商的系统只能使用这些方法工作。此外，也不能保证EAP方法内协商的密钥生存期与后端身份验证服务器策略兼容。为了方法独立性和与后端身份验证服务器实现的兼容性，EAP方法中不应提供密钥材料生命周期的管理。
Key lifetime negotiation alone cannot guarantee key cache synchronization. Even where a lower-layer exchange is run immediately after EAP in order to determine the lifetime of keying material, it is still possible for the authenticator to purge all or part of the key cache prematurely (e.g., due to reboot or need to reclaim memory).
仅密钥生存期协商不能保证密钥缓存同步。即使在EAP之后立即运行较低层交换以确定密钥材料的生命周期的情况下，验证器仍然可能过早地清除全部或部分密钥缓存（例如，由于重新启动或需要回收内存）。
The lower layer can utilize the Discovery phase 0 to improve key cache synchronization. For example, if the authenticator manages the key cache by deleting the oldest key first, the relative creation time of the last key to be deleted could be advertised within the Discovery phase, enabling the peer to determine whether keying material had been prematurely expired from the authenticator key cache.
下层可以利用发现阶段0来改进密钥缓存同步。例如，如果验证器通过首先删除最旧的密钥来管理密钥缓存，则要删除的最后一个密钥的相对创建时间可以在发现阶段内公布，使得对等方能够确定密钥材料是否已经从验证器密钥缓存中提前过期。
As noted in Section 2.1, EAP lower layers determine TSKs in different ways. Where exported EAP keying material is utilized in the derivation, encryption or authentication of TSKs, it is possible for EAP key generation to represent the weakest link.
如第2.1节所述，EAP下层以不同方式确定TSK。当导出的EAP密钥材料用于TSK的派生、加密或认证时，EAP密钥生成可能代表最薄弱的环节。
In order to ensure that methods produce EAP keying material of an appropriate symmetric key strength, it is RECOMMENDED that EAP methods utilizing public key cryptography choose a public key that has a cryptographic strength providing the required level of attack resistance. This is typically provided by configuring EAP methods, since there is no coordination between the lower layer and EAP method with respect to minimum required symmetric key strength.
为了确保方法产生具有适当对称密钥强度的EAP密钥材料，建议使用公钥密码的EAP方法选择具有提供所需抗攻击等级的密码强度的公钥。这通常是通过配置EAP方法来实现的，因为较低层和EAP方法之间在所需的最小对称密钥强度方面没有协调。
Section 5 of BCP 86 [RFC3766] offers advice on the required RSA or DH module and DSA subgroup size in bits, for a given level of attack resistance in bits. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57].
BCP 86[RFC3766]的第5节提供了关于给定级别的位攻击抵抗所需的RSA或DH模块和DSA子组大小（以位为单位）的建议。国家标准与技术研究所（NIST）也在[SP800-57]中提供了关于适当键尺寸的建议。
The key wrap specified in [RFC2548], which is based on an MD5-based stream cipher, has known problems, as described in [RFC3579] Section 4.3. RADIUS uses the shared secret for multiple purposes, including per-packet authentication and attribute hiding, considerable information is exposed about the shared secret with each packet. This exposes the shared secret to dictionary attacks. MD5 is used both to compute the RADIUS Response Authenticator and the Message-Authenticator Attribute, and concerns exist relating to the security of this hash [MD5Collision].
[RFC2548]中规定的基于MD5的流密码的密钥封装存在已知问题，如[RFC3579]第4.3节所述。RADIUS将共享秘密用于多种目的，包括每个数据包的身份验证和属性隐藏，每个数据包都会公开有关共享秘密的大量信息。这会使共享秘密暴露在字典攻击中。MD5用于计算RADIUS响应验证器和消息验证器属性，存在与此哈希[MD5Collision]的安全性相关的问题。
As discussed in [RFC3579] Section 4.3, the security vulnerabilities of RADIUS are extensive, and therefore development of an alternative key wrap technique based on the RADIUS shared secret would not substantially improve security. As a result, [RFC3579] Section 4.2 recommends running RADIUS over IPsec. The same approach is taken in Diameter EAP [RFC4072], which in Section 4.1.3 defines the EAP-Master-Session-Key Attribute-Value Pair (AVP) in clear-text, to be protected by IPsec or TLS.
如[RFC3579]第4.3节所述，RADIUS存在广泛的安全漏洞，因此基于RADIUS共享秘密开发替代密钥封装技术不会显著提高安全性。因此，[RFC3579]第4.2节建议通过IPsec运行RADIUS。Diameter EAP[RFC4072]也采用了相同的方法，在第4.1.3节中，它以明文形式定义了EAP主会话密钥属性值对（AVP），由IPsec或TLS保护。
A handoff occurs when an EAP peer moves to a new authenticator. Several mechanisms have been proposed for reducing handoff latency within networks utilizing EAP. These include:
当EAP对等方移动到新的验证器时发生切换。已经提出了几种机制来减少利用EAP的网络内的切换延迟。这些措施包括：
EAP pre-authentication In EAP pre-authentication, an EAP peer pre-establishes EAP keying material with an authenticator prior to arrival. EAP pre-authentication only affects the timing of EAP authentication, but does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b) exchanges; Discovery (phase 0) and Secure Association Protocol (phase 2) exchanges occur as described in Section 1.3. As a result, the primary benefit is to enable EAP authentication to be removed from the handoff critical path, thereby reducing latency. Use of EAP pre-authentication within IEEE 802.11 is described in [IEEE-802.11] and [8021XPreAuth].
EAP预认证在EAP预认证中，EAP对等方在到达前与验证者预先建立EAP密钥材料。EAP预认证仅影响EAP认证的时间，但不会缩短或消除EAP（阶段1a）或AAA（阶段1b）交换；发现（第0阶段）和安全关联协议（第2阶段）交换如第1.3节所述进行。因此，主要的好处是能够从切换关键路径中删除EAP身份验证，从而减少延迟。[IEEE-802.11]和[8021XPreAuth]中描述了在IEEE 802.11中使用EAP预认证。
Proactive key distribution In proactive key distribution, keying material and authorizations are transported from the backend authentication server to a candidate authenticator in advance of a handoff. As a result, EAP (phase 1a) is not needed, but the Discovery (phase 0), and Secure Association Protocol exchanges (phase 2) are still necessary. Within the AAA exchange (phase 1b), authorization and key distribution functions are typically supported, but not authentication. Proactive key distribution is described in [MishraPro], [IEEE-03-084], and [HANDOFF].
主动密钥分发在主动密钥分发中，在切换之前，将密钥材料和授权从后端身份验证服务器传输到候选身份验证者。因此，不需要EAP（阶段1a），但仍然需要发现（阶段0）和安全关联协议交换（阶段2）。在AAA交换（1b阶段）中，通常支持授权和密钥分发功能，但不支持身份验证。[MishraPro]、[IEEE-03-084]和[HANDOFF]中描述了主动密钥分发。
Key caching Caching of EAP keying material enables an EAP peer to re-attach to an authenticator without requiring EAP (phase 1a) or AAA (phase 1b) exchanges. However, Discovery (phase 0) and Secure Association Protocol (phase 2) exchanges are still needed. Use of key caching within IEEE 802.11 is described in [IEEE-802.11].
EAP密钥材料的密钥缓存使EAP对等方能够重新连接到验证器，而无需进行EAP（阶段1a）或AAA（阶段1b）交换。但是，仍然需要进行发现（第0阶段）和安全关联协议（第2阶段）交换。[IEEE-802.11]中描述了在IEEE 802.11中使用密钥缓存。
Context transfer In context transfer schemes, keying material and authorizations are transferred between a previous authenticator and a new authenticator. This can occur in response to a handoff request by the EAP peer, or in advance, as in proactive key distribution. As a result, EAP (phase 1a) is eliminated, but not the Discovery (phase 0) or Secure Association Protocol exchanges (phase 2). If a secure channel can be established between the new and previous authenticator without assistance from the backend authentication server, then the AAA exchange (phase 1b) can be eliminated; otherwise, it is still needed, although it can be shortened. Context transfer protocols are described in [IEEE-802.11F] (now deprecated) and "Context Transfer Protocol (CXTP)" [RFC4067]. "Fast Authentication Methods for Handovers between IEEE 802.11 Wireless LANs" [Bargh] analyzes fast handoff techniques, including context transfer mechanisms.
上下文传输在上下文传输方案中，密钥材料和授权在以前的验证器和新的验证器之间传输。这可以在响应EAP对等方的切换请求时发生，或者在主动密钥分发中提前发生。因此，EAP（阶段1a）被消除，但发现（阶段0）或安全关联协议交换（阶段2）被消除。如果在没有后端认证服务器协助的情况下，可以在新的和以前的认证器之间建立安全通道，则可以消除AAA交换（阶段1b）；否则，它仍然是需要的，尽管它可以缩短。[IEEE-802.11F]（现已弃用）和“上下文传输协议（CXTP）”[RFC4067]中描述了上下文传输协议。“IEEE 802.11无线局域网之间切换的快速认证方法”[Bargh]分析了快速切换技术，包括上下文传输机制。
Token distribution In token distribution schemes, the EAP peer is provided with a credential, subsequently enabling it to authenticate with one or more additional authenticators. During the subsequent authentications, EAP (phase 1a) is eliminated or shortened; the Discovery (phase 0) and Secure Association Protocol exchanges (phase 2) still occur, although the latter can be shortened. If the token includes authorizations and can be validated by an authenticator without assistance from the backend authentication server, then the AAA exchange (phase 1b) can be eliminated; otherwise, it is still needed, although it can be shortened. Token-based schemes, initially proposed in early versions of IEEE 802.11i [IEEE-802.11i], are described in [Token], [Tokenk], and [SHORT-TERM].
令牌分发在令牌分发方案中，向EAP对等方提供凭证，随后使其能够使用一个或多个附加验证器进行身份验证。在随后的认证期间，消除或缩短EAP（阶段1a）；发现（阶段0）和安全关联协议交换（阶段2）仍然会发生，尽管后者可以缩短。如果令牌包括授权，并且可以由验证器在没有后端认证服务器协助的情况下进行验证，则可以消除AAA交换（阶段1b）；否则，它仍然是需要的，尽管它可以缩短。最初在IEEE 802.11i早期版本[IEEE-802.11i]中提出的基于令牌的方案在[Token]、[Tokenk]和[SHORT-TERM]中进行了描述。
The sections that follow discuss the security vulnerabilities introduced by the above schemes.
以下各节将讨论上述方案引入的安全漏洞。
EAP pre-authentication differs from a normal EAP conversation primarily with respect to the lower-layer encapsulation. For example, in [IEEE-802.11], EAP pre-authentication frames utilize a distinct Ethertype, but otherwise conforms to the encapsulation described in [IEEE-802.1X]. As a result, an EAP pre-authentication conversation differs little from the model described in Section 1.3, other than the introduction of a delay between phase 1 and phase 2.
EAP预认证与普通EAP对话的主要区别在于较低层的封装。例如，在[IEEE-802.11]中，EAP预认证帧使用不同的以太网类型，但在其他方面符合[IEEE-802.1X]中描述的封装。因此，EAP预认证对话与第1.3节中描述的模型差别不大，只是在第1阶段和第2阶段之间引入了延迟。
EAP pre-authentication relies on lower-layer mechanisms for discovery of candidate authenticators. Where discovery can provide information on candidate authenticators outside the immediate listening range, and the peer can determine whether it already possesses valid EAP keying material with candidate authenticators, the peer can avoid unnecessary EAP pre-authentications and can establish EAP keying material well in advance, regardless of the coverage overlap between authenticators. However, if the peer can only discover candidate authenticators within listening range and cannot determine whether it can reuse existing EAP keying material, then it is possible that the peer will not be able to complete EAP pre-authentication prior to connectivity loss or that it can pre-authenticate multiple times with the same authenticator, increasing backend authentication server load.
EAP预认证依赖于发现候选认证者的低层机制。如果发现可以提供直接侦听范围之外的候选认证者的信息，并且对等方可以确定其是否已经拥有具有候选认证者的有效EAP密钥材料，则对等方可以避免不必要的EAP预认证，并且可以提前很好地建立EAP密钥材料，不考虑身份验证程序之间的覆盖重叠。但是，如果对等方只能发现侦听范围内的候选身份验证方，并且无法确定是否可以重用现有的EAP密钥材料，则该对等方可能无法在连接丢失之前完成EAP预身份验证，或者可能无法使用同一身份验证方进行多次预身份验证，增加后端身份验证服务器负载。
Since a peer can complete EAP pre-authentication with an authenticator without eventually attaching to it, it is possible that phase 2 will not occur. In this case, an Accounting-Request signifying the start of service will not be sent, or will only be sent with a substantial delay after the completion of authentication.
由于对等方可以使用验证器完成EAP预认证，而无需最终附加到验证器，因此阶段2可能不会发生。在这种情况下，将不发送表示服务开始的记帐请求，或者仅在完成身份验证后在相当长的延迟时间内发送。
As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA exchange resulting from EAP pre-authentication differs little from an ordinary exchange described in "RADIUS Support for EAP" [RFC3579]. For example, since in IEEE 802.11 [IEEE-802.11] an Association exchange does not occur prior to EAP pre-authentication, the SSID is not known by the authenticator at authentication time, so that an Access-Request cannot include the SSID within the Called-Station-Id attribute as described in [RFC3580] Section 3.20.
如“IEEE 802.1X RADIUS使用指南”[RFC3580]中所述，由EAP预认证产生的AAA交换与“EAP的RADIUS支持”[RFC3579]中所述的普通交换差别不大。例如，由于在IEEE 802.11[IEEE-802.11]中，在EAP预认证之前不会发生关联交换，因此认证者在认证时不知道SSID，因此访问请求不能将SSID包括在[RFC3580]第3.20节所述的被叫站Id属性中。
Since only the absence of an SSID in the Called-Station-Id attribute distinguishes an EAP pre-authentication attempt, if the authenticator does not always include the SSID for a normal EAP authentication attempt, it is possible that the backend authentication server will not be able to determine whether a session constitutes an EAP pre-authentication attempt, potentially resulting in authorization or accounting problems. Where the number of simultaneous sessions is limited, the backend authentication server can refuse to authorize a valid EAP pre-authentication attempt or can enable the peer to engage in more simultaneous sessions than they are authorized for. Where EAP pre-authentication occurs with an authenticator which the peer never attaches to, it is possible that the backend accounting server will not be able to determine whether the absence of an Accounting-Request was due to packet loss or a session that never started.
由于只有被叫站Id属性中缺少SSID才能区分EAP预身份验证尝试，如果验证器不总是包括正常EAP身份验证尝试的SSID，后端身份验证服务器可能无法确定会话是否构成EAP预身份验证尝试，从而可能导致授权或记帐问题。当同时会话的数量有限时，后端身份验证服务器可以拒绝授权有效的EAP预身份验证尝试，或者可以使对等方参与比授权更多的同时会话。如果EAP预认证发生在对等方从未连接到的验证器上，则后端记帐服务器可能无法确定缺少记帐请求是由于数据包丢失还是由于从未启动的会话。
In order to enable pre-authentication requests to be handled more reliably, it is RECOMMENDED that AAA protocols explicitly identify EAP pre-authentication. In order to suppress unnecessary EAP pre-authentication exchanges, it is RECOMMENDED that authenticators unambiguously identify themselves as described in Section 2.3.
为了更可靠地处理预认证请求，建议AAA协议明确标识EAP预认证。为了抑制不必要的EAP预认证交换，建议认证者按照第2.3节所述明确标识自己。
In proactive key distribution schemes, the backend authentication server transports keying material and authorizations to an authenticator in advance of the arrival of the peer. The authenticators selected to receive the transported key material are selected based on past patterns of peer movement between authenticators known as the "neighbor graph". In order to reduce handoff latency, proactive key distribution schemes typically only demonstrate proof of possession of transported keying material between the EAP peer and authenticator. During a handoff, the backend authentication server is not provided with proof that the peer successfully authenticated to an authenticator; instead, the authenticator generates a stream of accounting messages without a corresponding set of authentication exchanges. As described in [MishraPro], knowledge of the neighbor graph can be established via static configuration or analysis of authentication exchanges. In
在主动式密钥分发方案中，后端身份验证服务器在对等方到达之前将密钥材料和授权传输给身份验证方。根据称为“邻居图”的验证器之间的对等移动的过去模式，选择用于接收传输的密钥材料的验证器。为了减少切换延迟，主动密钥分发方案通常仅证明EAP对等方和认证方之间拥有传输的密钥材料。在切换期间，未向后端认证服务器提供对等方成功向认证者认证的证据；相反，身份验证器生成记帐消息流，而无需相应的一组身份验证交换。如[MishraPro]所述，可以通过静态配置或身份验证交换分析来建立邻居图的知识。在里面
order to prevent corruption of the neighbor graph, new neighbor graph entries can only be created as the result of a successful EAP exchange, and accounting packets with no corresponding authentication exchange need to be verified to correspond to neighbor graph entries (e.g., corresponding to handoffs between neighbors).
为了防止邻居图损坏，新的邻居图条目只能在EAP交换成功后创建，并且需要验证没有相应身份验证交换的记帐数据包是否对应于邻居图条目（例如，对应于邻居之间的切换）。
In order to prevent compromise of one authenticator from resulting in compromise of other authenticators, cryptographic separation needs to be maintained between the keying material transported to each authenticator. However, even where cryptographic separation is maintained, an attacker compromising an authenticator can still disrupt the operation of other authenticators. As noted in [RFC3579] Section 4.3.7, in the absence of spoofing detection within the AAA infrastructure, it is possible for EAP authenticators to impersonate each other. By forging NAS identification attributes within authentication messages, an attacker compromising one authenticator could corrupt the neighbor graph, tricking the backend authentication server into transporting keying material to arbitrary authenticators. While this would not enable recovery of EAP keying material without breaking fundamental cryptographic assumptions, it could enable subsequent fraudulent accounting messages, or allow an attacker to disrupt service by increasing load on the backend authentication server or thrashing the authenticator key cache.
为了防止一个验证器的泄露导致其他验证器的泄露，需要在传输到每个验证器的密钥材料之间保持加密分离。但是，即使在保持加密分离的情况下，攻击者破坏身份验证器仍然可以中断其他身份验证器的操作。如[RFC3579]第4.3.7节所述，在AAA基础设施内没有欺骗检测的情况下，EAP验证器可以相互模拟。通过在身份验证消息中伪造NAS标识属性，攻击者破坏一个身份验证者可能会破坏邻居图，诱使后端身份验证服务器将密钥材料传输给任意身份验证者。虽然这无法在不破坏基本密码假设的情况下恢复EAP密钥材料，但它可能会导致后续欺诈性记帐消息，或允许攻击者通过增加后端身份验证服务器上的负载或破坏身份验证器密钥缓存来中断服务。
Since proactive key distribution requires the distribution of derived keying material to candidate authenticators, the effectiveness of this scheme depends on the ability of backend authentication server to anticipate the movement of the EAP peer. Since proactive key distribution relies on backend authentication server knowledge of the neighbor graph, it is most applicable to intra-domain handoff scenarios. However, in inter-domain handoff, where there can be many authenticators, peers can frequently connect to authenticators that have not been previously encountered, making it difficult for the backend authentication server to derive a complete neighbor graph.
由于主动密钥分发要求将派生密钥材料分发给候选身份验证者，因此该方案的有效性取决于后端身份验证服务器预测EAP对等方移动的能力。由于主动密钥分发依赖于后端身份验证服务器对邻居图的了解，所以它最适用于域内切换场景。然而，在域间切换中，可能有许多身份验证器，对等方可以频繁连接到以前未遇到的身份验证器，这使得后端身份验证服务器很难导出完整的邻居图。
Since proactive key distribution schemes typically require introduction of server-initiated messages as described in [RFC5176] and [HANDOFF], security issues described in [RFC5176] Section 6 are applicable, including authorization (Section 6.1) and replay detection (Section 6.3) problems.
由于主动密钥分发方案通常需要引入[RFC5176]和[HANDOFF]中所述的服务器启动消息，[RFC5176]第6节中所述的安全问题适用，包括授权（第6.1节）和重播检测（第6.3节）问题。
Fast handoff techniques that enable elimination of the AAA exchange (phase 1b) differ fundamentally from typical network access scenarios (dial-up, wired LAN, etc.) that include user authentication as well as authorization for the offered service. Where the AAA exchange (phase 1b) is omitted, authorizations and keying material are not provided by the backend authentication server, and as a result, they need to be supplied by other means. This section describes some of the implications.
能够消除AAA交换的快速切换技术（第1b阶段）与典型的网络接入场景（拨号、有线LAN等）有根本不同，后者包括用户身份验证以及所提供服务的授权。在省略AAA交换（阶段1b）的情况下，授权和密钥材料不是由后端认证服务器提供的，因此，它们需要通过其他方式提供。本节描述了其中的一些含义。
Where transported keying material is not supplied by the backend authentication server, it needs to be provided by another party authorized to access that keying material. As noted in Section 1.5, only the EAP peer, authenticator, and server are authorized to possess transported keying material. Since EAP peers do not trust each other, if the backend authentication server does not supply transported keying material to a new authenticator, it can only be provided by a previous authenticator.
如果传输的密钥资料不是由后端身份验证服务器提供的，则需要由授权访问该密钥资料的另一方提供。如第1.5节所述，只有EAP对等方、认证方和服务器有权拥有传输的密钥材料。由于EAP对等方彼此不信任，如果后端身份验证服务器不向新身份验证方提供传输的密钥材料，则只能由以前的身份验证方提供。
As noted in Section 1.5, the goal of the EAP conversation is to derive session keys known only to the peer and the authenticator. If keying material is replicated between a previous authenticator and a new authenticator, then the previous authenticator can possess session keys used between the peer and new authenticator. Also, the new authenticator can possess session keys used between the peer and the previous authenticator.
如第1.5节所述，EAP对话的目标是导出只有对等方和认证方知道的会话密钥。如果在以前的身份验证器和新身份验证器之间复制了密钥材料，那么以前的身份验证器可以拥有对等身份验证器和新身份验证器之间使用的会话密钥。此外，新的验证器可以拥有对等验证器和前一验证器之间使用的会话密钥。
If a one-way function is used to derive the keying material to be transported to the new authenticator, then the new authenticator cannot possess previous session keys without breaking a fundamental cryptographic assumption.
如果使用单向函数导出要传输到新验证器的密钥材料，则新验证器在不破坏基本密码假设的情况下无法拥有以前的会话密钥。
As a part of the authentication process, the backend authentication server determines the user's authorization profile and transmits the authorizations to the authenticator along with the transported keying material. Typically, the profile is determined based on the user identity, but a certificate presented by the user can also provide authorization information.
作为身份验证过程的一部分，后端身份验证服务器确定用户的授权配置文件，并将授权连同传输的密钥材料一起传输给身份验证程序。通常，配置文件是基于用户身份确定的，但是用户提供的证书也可以提供授权信息。
The backend authentication server is responsible for making a user authorization decision, which requires answering the following questions:
后端身份验证服务器负责做出用户授权决策，这需要回答以下问题：
(a) Is this a legitimate user of this network?
(a) 这是该网络的合法用户吗？
(b) Is the user allowed to access this network?
(b) 是否允许用户访问此网络？
(c) Is the user permitted to access this network on this day and at this time?
(c) 是否允许用户在当天和此时访问此网络？
(d) Is the user within the concurrent session limit?
(d) 用户是否在并发会话限制内？
(e) Are there any fraud, credit limit, or other concerns that could lead to access denial?
(e) 是否存在可能导致访问被拒绝的欺诈、信用限制或其他问题？
(f) If access is to be granted, what are the service parameters (mandatory tunneling, bandwidth, filters, and so on) to be provisioned for the user?
(f) 如果要授予访问权限，将为用户提供哪些服务参数（强制隧道、带宽、过滤器等）？
While the authorization decision is, in principle, simple, the distributed decision making process can add complexity. Where brokers or proxies are involved, all of the AAA entities in the chain from the authenticator to the home backend authentication server are involved in the decision. For example, a broker can deny access even if the home backend authentication server would allow it, or a proxy can add authorizations (e.g., bandwidth limits).
虽然授权决策原则上很简单，但分布式决策过程会增加复杂性。在涉及代理或代理的情况下，从验证器到家庭后端身份验证服务器的链中的所有AAA实体都参与决策。例如，即使主后端身份验证服务器允许，代理也可以拒绝访问，或者代理可以添加授权（例如，带宽限制）。
Decisions can be based on static policy definitions and profiles as well as dynamic state (e.g., time of day or concurrent session limits). In addition to the Accept/Reject decisions made by AAA entities, service parameters or constraints can be communicated to the authenticator.
决策可以基于静态策略定义和配置文件以及动态状态（例如，一天中的时间或并发会话限制）。除了AAA实体做出的接受/拒绝决策外，还可以将服务参数或约束传递给认证器。
The criteria for Accept/Reject decisions or the reasons for choosing particular authorizations are typically not communicated to the authenticator, only the final result is. As a result, the authenticator has no way to know on what the decision was based. Was a set of authorization parameters sent because this service is always provided to the user, or was the decision based on the time of day and the capabilities of the authenticator?
接受/拒绝决定的标准或选择特定授权的原因通常不会传达给认证者，只有最终结果是正确的。因此，身份验证者无法知道该决定基于什么。发送一组授权参数是因为此服务始终提供给用户，还是基于一天中的时间和验证者的能力？
When the AAA exchange (phase 1b) is bypassed, several challenges arise in ensuring correct authorization:
当绕过AAA交换（1b阶段）时，在确保正确授权方面会出现一些挑战：
Theft of service Bypassing the AAA exchange (phase 1b) SHOULD NOT enable a user to extend their network access or gain access to services they are not entitled to.
绕过AAA交换的服务盗窃（1b阶段）不应允许用户扩展其网络访问权限或获得无权访问的服务。
Consideration of network-wide state Handoff techniques SHOULD NOT render the backend authentication server incapable of keeping track of network-wide state. For example, a backend authentication server can need to keep track of simultaneous user sessions.
考虑网络范围的状态切换技术不应使后端身份验证服务器无法跟踪网络范围的状态。例如，后端身份验证服务器可能需要跟踪同步的用户会话。
Elevation of privilege Backend authentication servers often perform conditional evaluation, in which the authorizations returned in an Access-Accept message are contingent on the authenticator or on dynamic state such as the time of day. In this situation, bypassing the AAA exchange could enable unauthorized access unless the restrictions are explicitly encoded within the authorizations provided by the backend authentication server.
特权提升后端身份验证服务器通常执行条件评估，其中Access Accept消息中返回的授权取决于身份验证程序或动态状态（如时间）。在这种情况下，绕过AAA exchange可能会启用未经授权的访问，除非限制在后端身份验证服务器提供的授权中明确编码。
A handoff mechanism that provides proper authorization is said to be "correct". One condition for correctness is as follows:
提供适当授权的切换机制称为“正确”。正确性的一个条件如下：
For a handoff to be "correct" it MUST establish on the new authenticator the same authorizations as would have been created had the new authenticator completed a AAA conversation with the backend authentication server.
要使切换“正确”，必须在新身份验证程序上建立与新身份验证程序与后端身份验证服务器完成AAA对话时创建的相同授权。
A properly designed handoff scheme will only succeed if it is "correct" in this way. If a successful handoff would establish "incorrect" authorizations, it is preferable for it to fail. Where the supported services differ between authenticators, a handoff that bypasses the backend authentication server is likely to fail. Section 1.1 of [RFC2865] states:
一个适当设计的切换方案只有以这种方式“正确”时才会成功。如果成功的切换将建立“不正确”的授权，则最好失败。当认证器之间支持的服务不同时，绕过后端认证服务器的切换可能会失败。[RFC2865]第1.1节规定：
A authenticator that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a authenticator that is unable to offer ARAP service MUST NOT implement the RADIUS attributes for ARAP. A authenticator MUST treat a RADIUS access-accept authorizing an unavailable service as an access-reject instead.
未实现给定服务的验证器不得实现该服务的RADIUS属性。例如，无法提供ARAP服务的验证器不能实现ARAP的RADIUS属性。验证器必须将授权不可用服务的RADIUS访问接受视为访问拒绝。
This behavior applies to attributes that are known, but not implemented. For attributes that are unknown, Section 5 of [RFC2865] states:
此行为适用于已知但未实现的属性。对于未知属性，[RFC2865]第5节规定：
A RADIUS server MAY ignore Attributes with an unknown Type. A RADIUS client MAY ignore Attributes with an unknown Type.
RADIUS服务器可能会忽略类型未知的属性。RADIUS客户端可能会忽略类型未知的属性。
In order to perform a correct handoff, if a new authenticator is provided with RADIUS authorizations for a known but unavailable service, then it MUST process these authorizations the same way it would handle a RADIUS Access-Accept requesting an unavailable
为了执行正确的切换，如果为新验证器提供了已知但不可用服务的RADIUS授权，则它必须以处理RADIUS访问接受请求不可用服务的相同方式处理这些授权
service; this MUST cause the handoff to fail. However, if a new authenticator is provided with authorizations including unknown attributes, then these attributes MAY be ignored. The definition of a "known but unsupported service" MUST encompass requests for unavailable security services. This includes vendor-specific attributes related to security, such as those described in [RFC2548]. Although it can seem somewhat counter-intuitive, failure is indeed the "correct" result where a known but unsupported service is requested.
服务这必须导致切换失败。但是，如果向新的验证器提供了包含未知属性的授权，则这些属性可能会被忽略。“已知但不受支持的服务”的定义必须包含对不可用安全服务的请求。这包括与安全性相关的特定于供应商的属性，如[RFC2548]中所述。虽然这看起来有点违反直觉，但在请求已知但不受支持的服务时，失败确实是“正确”的结果。
Presumably, a correctly configured backend authentication server would not request that an authenticator provide a service that it does not implement. This implies that if the new authenticator were to complete a AAA conversation, it would be likely to receive different service instructions. Failure of the handoff is the desired result since it will cause the new authenticator to go back to the backend server in order to receive the appropriate service definition.
据推测，正确配置的后端身份验证服务器不会请求验证器提供其未实现的服务。这意味着，如果新的验证器要完成AAA对话，它可能会收到不同的服务指令。切换失败是期望的结果，因为它将导致新的验证器返回后端服务器以接收适当的服务定义。
Handoff mechanisms that bypass the backend authentication server are most likely to be successful when employed in a homogeneous deployment within a single administrative domain. In a heterogeneous deployment, the backend authentication server can return different authorizations depending on the authenticator making the request in order to make sure that the requested service is consistent with the authenticator capabilities. Where a backend authentication server would send different authorizations to the new authenticator than were sent to a previous authenticator, transferring authorizations between the previous authenticator and the new authenticator will result in incorrect authorization.
在单个管理域内的同构部署中使用绕过后端身份验证服务器的切换机制最有可能成功。在异构部署中，后端身份验证服务器可以根据发出请求的身份验证程序返回不同的授权，以确保请求的服务与身份验证程序功能一致。如果后端身份验证服务器向新身份验证程序发送的授权与发送给前一身份验证程序的授权不同，则在前一身份验证程序和新身份验证程序之间传输授权将导致不正确的授权。
Virtual LAN (VLAN) support is defined in [IEEE-802.1Q]; RADIUS support for dynamic VLANs is described in [RFC3580] and [RFC4675]. If some authenticators support dynamic VLANs while others do not, then attributes present in the Access-Request (such as the NAS-Port-Type, NAS-IP-Address, NAS-IPv6-Address, and NAS-Identifier) could be examined by the backend authentication server to determine when VLAN attributes will be returned, and if so, which ones. However, if the backend authenticator is bypassed, then a handoff occurring between authenticators supporting different VLAN capabilities could result in a user obtaining access to an unauthorized VLAN (e.g., a user with access to a guest VLAN being given unrestricted access to the network).
虚拟局域网（VLAN）支持在[IEEE-802.1Q]中定义；[RFC3580]和[RFC4675]中描述了对动态VLAN的RADIUS支持。如果某些验证器支持动态VLAN，而其他验证器不支持动态VLAN，则后端身份验证服务器可以检查访问请求中存在的属性（如NAS端口类型、NAS IP地址、NAS-IPv6-Address和NAS标识符），以确定何时返回VLAN属性，如果是，返回哪些属性。但是，如果绕过后端验证器，则在支持不同VLAN功能的验证器之间发生的切换可能会导致用户获得对未经授权VLAN的访问（例如，向访问来宾VLAN的用户提供对网络的无限制访问）。
Similarly, it is preferable for a handoff between an authenticator providing confidentiality and another that does not to fail, since if the handoff were successful, the user would be moved from a secure to an insecure channel without permission from the backend authentication server.
类似地，优选在提供机密性的验证器和另一个不失败的验证器之间进行切换，因为如果切换成功，用户将在没有来自后端认证服务器的许可的情况下从安全信道移动到不安全信道。
The EAP threat model is described in [RFC3748] Section 7.1. The security properties of EAP methods (known as "security claims") are described in [RFC3748] Section 7.2.1. EAP method requirements for applications such as Wireless LAN authentication are described in [RFC4017]. The RADIUS threat model is described in [RFC3579] Section 4.1, and responses to these threats are described in [RFC3579], Sections 4.2 and 4.3.
[RFC3748]第7.1节描述了EAP威胁模型。[RFC3748]第7.2.1节描述了EAP方法（称为“安全声明”）的安全属性。[RFC4017]中描述了无线LAN认证等应用的EAP方法要求。[RFC3579]第4.1节描述了RADIUS威胁模型，而[RFC3579]第4.2和4.3节描述了对这些威胁的响应。
However, in addition to threats against EAP and AAA, there are other system level threats. In developing the threat model, it is assumed that:
然而，除了针对EAP和AAA的威胁外，还有其他系统级威胁。在开发威胁模型时，假设：
All traffic is visible to the attacker. The attacker can alter, forge, or replay messages. The attacker can reroute messages to another principal. The attacker can be a principal or an outsider. The attacker can compromise any key that is sufficiently old.
攻击者可以看到所有流量。攻击者可以更改、伪造或重播消息。攻击者可以将消息重新路由到其他主体。攻击者可以是负责人或局外人。攻击者可以泄露任何足够旧的密钥。
Threats arising from these assumptions include:
这些假设产生的威胁包括：
(a) An attacker can compromise or steal an EAP peer or authenticator, in an attempt to gain access to other EAP peers or authenticators or to obtain long-term secrets.
(a) 攻击者可以破坏或窃取EAP对等方或身份验证方，以尝试访问其他EAP对等方或身份验证方，或获取长期机密。
(b) An attacker can attempt a downgrade attack in order to exploit known weaknesses in an authentication method or cryptographic algorithm.
(b) 攻击者可以尝试降级攻击，以利用身份验证方法或加密算法中的已知弱点。
(c) An attacker can try to modify or spoof packets, including Discovery or Secure Association Protocol frames, EAP or AAA packets.
(c) 攻击者可以尝试修改或欺骗数据包，包括发现或安全关联协议帧、EAP或AAA数据包。
(d) An attacker can attempt to induce an EAP peer, authenticator, or server to disclose keying material to an unauthorized party, or utilize keying material outside the context that it was intended for.
(d) 攻击者可试图诱使EAP对等方、身份验证方或服务器向未经授权的一方披露密钥材料，或在其预期的上下文之外利用密钥材料。
(e) An attacker can alter, forge, or replay packets.
(e) 攻击者可以更改、伪造或重播数据包。
(f) An attacker can cause an EAP peer, authenticator, or server to reuse a stale key. Use of stale keys can also occur unintentionally. For example, a poorly implemented backend authentication server can provide stale keying material to an authenticator, or a poorly implemented authenticator can reuse nonces.
(f) 攻击者可导致EAP对等方、身份验证方或服务器重用过期密钥。使用过期密钥也可能是无意中发生的。例如，实施不当的后端身份验证服务器可以向身份验证程序提供过时的密钥材料，或者实施不当的身份验证程序可以重用nonce。
(g) An authenticated attacker can attempt to obtain elevated privilege in order to access information that it does not have rights to.
(g) 经过身份验证的攻击者可以尝试获取提升的权限，以便访问其无权访问的信息。
(h) An attacker can attempt a man-in-the-middle attack in order to gain access to the network.
(h) 攻击者可以尝试中间人攻击以访问网络。
(i) An attacker can compromise an EAP authenticator in an effort to commit fraud. For example, a compromised authenticator can 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.
(i) 攻击者可以通过破坏EAP身份验证程序来实施欺诈。例如，受损身份验证器可通过带外机制（例如通过AAA或较低层协议）向EAP对等方和/或服务器提供不正确的信息。这包括模拟另一个验证器，或向对等服务器和EAP服务器提供不一致的信息。
(j) An attacker can launch a denial-of-service attack against the EAP peer, authenticator, or backend authentication server.
(j) 攻击者可以对EAP对等方、身份验证程序或后端身份验证服务器发起拒绝服务攻击。
In order to address these threats, [RFC4962] Section 3 describes required and recommended security properties. The sections that follow analyze the compliance of EAP methods, AAA protocols, and Secure Association Protocols with those guidelines.
为了应对这些威胁，[RFC4962]第3节描述了所需和建议的安全属性。接下来的部分将分析EAP方法、AAA协议和安全关联协议与这些准则的符合性。
Requirement: In the event that an authenticator is compromised or stolen, an attacker can gain access to the network through that authenticator, or can obtain the credentials needed for the authenticator/AAA client to communicate with one or more backend authentication servers. Similarly, if a peer is compromised or stolen, an attacker can obtain credentials needed to communicate with one or more authenticators. A mandatory requirement from [RFC4962] Section 3:
要求：如果验证器遭到破坏或被盗，攻击者可以通过该验证器访问网络，或者可以获得验证器/AAA客户端与一个或多个后端身份验证服务器通信所需的凭据。类似地，如果对等方受到攻击或被盗，攻击者可以获得与一个或多个验证器通信所需的凭据。[RFC4962]第3节的强制性要求：
Prevent the Domino effect
防止多米诺效应
Compromise of a single peer MUST NOT compromise keying material held by any other peer within the system, including session keys and long-term keys. Likewise, compromise of a single authenticator MUST NOT compromise keying material held by any other authenticator within the system. In the context of a key
单个对等方的泄露不得泄露系统内任何其他对等方持有的密钥材料，包括会话密钥和长期密钥。同样，单个验证器的泄露不得泄露系统内任何其他验证器持有的密钥材料。在密钥上下文中
hierarchy, this means that the compromise of one node in the key hierarchy must not disclose the information necessary to compromise other branches in the key hierarchy. Obviously, the compromise of the root of the key hierarchy will compromise all of the keys; however, a compromise in one branch MUST NOT result in the compromise of other branches. There are many implications of this requirement; however, two implications deserve highlighting. First, the scope of the keying material must be defined and understood by all parties that communicate with a party that holds that keying material. Second, a party that holds keying material in a key hierarchy must not share that keying material with parties that are associated with other branches in the key hierarchy.
层次结构，这意味着密钥层次结构中一个节点的泄露不得泄露泄露泄露密钥层次结构中其他分支所需的信息。显然，密钥层次结构根的折衷将折衷所有密钥；但是，一个分支中的妥协不得导致其他分支的妥协。这一要求有许多含义；然而，有两个影响值得强调。首先，所有与持有密钥材料的一方进行沟通的各方必须定义并理解密钥材料的范围。其次，在密钥层次结构中持有密钥材料的参与方不得与与密钥层次结构中其他分支关联的参与方共享该密钥材料。
Group keys are an obvious exception. Since all members of the group have a copy of the same key, compromise of any one of the group members will result in the disclosure of the group key.
组键是一个明显的例外。由于组的所有成员都有同一密钥的副本，任何一个组成员的泄露都会导致组密钥的泄露。
Some of the implications of the requirement are as follows:
该要求的一些含义如下：
Key Sharing In order to be able to determine whether keying material has been shared, it is necessary for the identity of the EAP authenticator (NAS-Identifier) to be defined and understood by all parties that communicate with it. EAP lower-layer specifications such as [IEEE-802.11], [IEEE-802.16e], [IEEE-802.1X], IKEv2 [RFC4306], and PPP [RFC1661] do not involve key sharing.
密钥共享为了能够确定是否共享了密钥材料，有必要定义EAP验证器（NAS标识符）的身份，并让与其通信的所有各方理解。EAP底层规范，如[IEEE-802.11]、[IEEE-802.16e]、[IEEE-802.1X]、IKEv2[RFC4306]和PPP[RFC1661]不涉及密钥共享。
AAA Credential Sharing AAA credentials (such as RADIUS shared secrets, IPsec pre-shared keys or certificates) MUST NOT be shared between AAA clients, since if one AAA client were compromised, this would enable an attacker to impersonate other AAA clients to the backend authentication server, or even to impersonate a backend authentication server to other AAA clients.
AAA凭据共享AAA凭据（例如RADIUS共享机密、IPsec预共享密钥或证书）不得在AAA客户端之间共享，因为如果一个AAA客户端受到攻击，这将使攻击者能够向后端身份验证服务器模拟其他AAA客户端，甚至可以向其他AAA客户端模拟后端身份验证服务器。
Compromise of Long-Term Credentials An attacker obtaining keying material (such as TSKs, TEKs, or the MSK) MUST NOT be able to obtain long-term user credentials such as pre-shared keys, passwords, or private-keys without breaking a fundamental cryptographic assumption. The mandatory requirements of [RFC4017] Section 2.2 include generation of EAP keying material, capability to generate EAP keying material with 128 bits of effective strength, resistance to dictionary attacks, shared state equivalence, and protection against man-in-the-middle attacks.
长期凭据泄露获取密钥材料（如TSK、TEK或MSK）的攻击者必须在不破坏基本密码假设的情况下才能获取长期用户凭据，如预共享密钥、密码或私钥。[RFC4017]第2.2节的强制性要求包括生成EAP键控材料、生成具有128位有效强度的EAP键控材料的能力、抗字典攻击、共享状态等价性以及防止中间人攻击。
Mandatory requirements from [RFC4962] Section 3:
[RFC4962]第3节的强制性要求：
Cryptographic algorithm independent
密码算法无关
The AAA key management protocol MUST be cryptographic algorithm independent. However, an EAP method MAY depend on a specific cryptographic algorithm. The ability to negotiate the use of a particular cryptographic algorithm provides resilience against compromise of a particular cryptographic algorithm. Algorithm independence is also REQUIRED with a Secure Association Protocol if one is defined. This is usually accomplished by including an algorithm identifier and parameters in the protocol, and by specifying the algorithm requirements in the protocol specification. While highly desirable, the ability to negotiate key derivation functions (KDFs) is not required. For interoperability, at least one suite of mandatory-to-implement algorithms MUST be selected. Note that without protection by IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865] does not meet this requirement, since the integrity protection algorithm cannot be negotiated.
AAA密钥管理协议必须独立于加密算法。然而，EAP方法可能取决于特定的密码算法。协商使用特定加密算法的能力提供了抵御特定加密算法危害的弹性。如果定义了安全关联协议，则还需要算法独立性。这通常通过在协议中包含算法标识符和参数，以及在协议规范中指定算法要求来实现。虽然非常理想，但不需要协商密钥派生函数（KDF）的能力。为了实现互操作性，必须至少选择一套实现算法的必需工具。请注意，如果没有[RFC3579]第4.2节中所述的IPsec保护，RADIUS[RFC2865]不满足此要求，因为无法协商完整性保护算法。
This requirement does not mean that a protocol must support both public-key and symmetric-key cryptographic algorithms. It means that the protocol needs to be structured in such a way that multiple public-key algorithms can be used whenever a public-key algorithm is employed. Likewise, it means that the protocol needs to be structured in such a way that multiple symmetric-key algorithms can be used whenever a symmetric-key algorithm is employed.
这一要求并不意味着协议必须同时支持公钥和对称密钥加密算法。这意味着协议的结构需要确保在使用公钥算法时可以使用多个公钥算法。同样，这意味着协议的结构需要确保在使用对称密钥算法时可以使用多个对称密钥算法。
Confirm ciphersuite selection
确认密码套件选择
The selection of the "best" ciphersuite SHOULD be securely confirmed. The mechanism SHOULD detect attempted roll-back attacks.
应安全地确认“最佳”密码套件的选择。该机制应检测尝试的回滚攻击。
EAP methods satisfying [RFC4017] Section 2.2 mandatory requirements and AAA protocols utilizing transmission-layer security are capable of addressing downgrade attacks. [RFC3748] Section 7.2.1 describes the "protected ciphersuite negotiation" security claim that refers to the ability of an EAP method to negotiate the ciphersuite used to protect the EAP method conversation, as well as to integrity protect the ciphersuite negotiation. [RFC4017] Section 2.2 requires EAP methods satisfying this security claim. Since TLS v1.2 [RFC5246] and IKEv2 [RFC4306] support negotiation of Key Derivation Functions (KDFs), EAP methods based on TLS or IKEv2 will, if properly designed,
满足[RFC4017]第2.2节强制性要求的EAP方法和利用传输层安全的AAA协议能够应对降级攻击。[RFC3748]第7.2.1节描述了“受保护的密码套件协商”安全声明，该声明涉及EAP方法协商用于保护EAP方法对话的密码套件以及完整性保护密码套件协商的能力。[RFC4017]第2.2节要求EAP方法满足此安全声明。由于TLS v1.2[RFC5246]和IKEv2[RFC4306]支持密钥派生函数（KDF）的协商，基于TLS或IKEv2的EAP方法如果设计得当，
inherit this capability. However, negotiation of KDFs is not required by RFC 4962 [RFC4962], and EAP methods based on neither TLS nor IKEv2 typically do not support KDF negotiation.
继承此功能。然而，RFC 4962[RFC4962]不要求KDF协商，基于TLS和IKEv2的EAP方法通常不支持KDF协商。
When AAA protocols utilize TLS [RFC5246] or IPsec [RFC4301] for transmission layer security, they can leverage the cryptographic algorithm negotiation support provided by IKEv2 [RFC4306] or TLS [RFC5246]. RADIUS [RFC3579] by itself does not support cryptographic algorithm negotiation and relies on MD5 for integrity protection, authentication, and confidentiality. Given the known weaknesses in MD5 [MD5Collision], this is undesirable, and can be addressed via use of RADIUS over IPsec, as described in [RFC3579] Section 4.2.
当AAA协议利用TLS[RFC5246]或IPsec[RFC4301]实现传输层安全时，它们可以利用IKEv2[RFC4306]或TLS[RFC5246]提供的加密算法协商支持。RADIUS[RFC3579]本身不支持加密算法协商，依赖MD5进行完整性保护、身份验证和机密性。鉴于MD5[MD5Collision]中的已知弱点，这是不可取的，可以通过使用IPsec上的RADIUS解决，如[RFC3579]第4.2节所述。
To ensure against downgrade attacks within lower-layer protocols, algorithm independence is REQUIRED with lower layers using EAP for key derivation. For interoperability, at least one suite of mandatory-to-implement algorithms MUST be selected. Lower-layer protocols supporting EAP for key derivation SHOULD also support secure ciphersuite negotiation as well as KDF negotiation.
为了确保在较低层协议中防止降级攻击，需要算法独立性，较低层使用EAP进行密钥推导。为了实现互操作性，必须至少选择一套实现算法的必需工具。支持EAP进行密钥派生的较低层协议还应支持安全密码套件协商以及KDF协商。
As described in [RFC1968], PPP ECP does not support secure ciphersuite negotiation. While [IEEE-802.16e] and [IEEE-802.11] support ciphersuite negotiation for protection of data, they do not support negotiation of the cryptographic primitives used within the Secure Association Protocol, such as message integrity checks (MICs) and KDFs.
如[RFC1968]所述，PPP ECP不支持安全密码套件协商。虽然[IEEE-802.16e]和[IEEE-802.11]支持加密套件协商以保护数据，但它们不支持协商安全关联协议中使用的加密原语，如消息完整性检查（MIC）和KDF。
Mandatory requirements from [RFC4962] Section 3:
[RFC4962]第3节的强制性要求：
Authenticate all parties
认证各方
Each party in the AAA key management protocol MUST be authenticated to the other parties with whom they communicate. Authentication mechanisms MUST maintain the confidentiality of any secret values used in the authentication process. When a secure association protocol is used to establish session keys, the parties involved in the secure association protocol MUST identify themselves using identities that are meaningful in the lower-layer protocol environment that will employ the session keys. In this situation, the authenticator and peer may be known by different identifiers in the AAA protocol environment and the lower-layer protocol environment, making authorization decisions difficult without a clear key scope. If the lower-layer identifier of the
AAA密钥管理协议中的每一方都必须向与其通信的其他方进行身份验证。身份验证机制必须保持身份验证过程中使用的任何秘密值的机密性。当使用安全关联协议来建立会话密钥时，安全关联协议中涉及的各方必须使用在将使用会话密钥的较低层协议环境中有意义的标识来标识自己。在这种情况下，在AAA协议环境和较低层协议环境中，验证器和对等方可能由不同的标识符知道，这使得在没有明确的密钥范围的情况下很难做出授权决策。如果是系统的较低层标识符
peer will be used to make authorization decisions, then the pair of identifiers associated with the peer MUST be authorized by the authenticator and/or the AAA server.
对等方将用于做出授权决策，那么与对等方相关联的一对标识符必须由验证器和/或AAA服务器授权。
AAA protocols, such as RADIUS [RFC2865] and Diameter [RFC3588], provide a mechanism for the identification of AAA clients; since the EAP authenticator and AAA client are always co-resident, this mechanism is applicable to the identification of EAP authenticators.
AAA协议，如RADIUS[RFC2865]和Diameter[RFC3588]，提供了识别AAA客户端的机制；由于EAP验证器和AAA客户端始终是共同驻留的，因此此机制适用于EAP验证器的标识。
When multiple base stations and a "controller" (such as a WLAN switch) comprise a single EAP authenticator, the "base station identity" is not relevant; the EAP method conversation takes place between the EAP peer and the EAP server. Also, many base stations can share the same authenticator identity. The authenticator identity is important in the AAA protocol exchange and the secure association protocol conversation.
当多个基站和“控制器”（例如WLAN交换机）包括单个EAP认证器时，“基站标识”不相关；EAP方法对话在EAP对等方和EAP服务器之间进行。此外，许多基站可以共享相同的验证器身份。认证者身份在AAA协议交换和安全关联协议会话中非常重要。
Authentication mechanisms MUST NOT employ plaintext passwords. Passwords may be used provided that they are not sent to another party without confidentiality protection.
身份验证机制不得使用明文密码。可以使用密码，前提是在没有保密保护的情况下，密码不会发送给另一方。
Keying material confidentiality and integrity
键入材料机密性和完整性
While preserving algorithm independence, confidentiality and integrity of all keying material MUST be maintained.
在保持算法独立性的同时，必须保持所有密钥材料的机密性和完整性。
Conformance to these requirements is analyzed in the sections that follow.
对这些要求的符合性将在以下章节中进行分析。
Per-packet authentication and integrity protection provides protection against spoofing attacks.
每包身份验证和完整性保护提供了针对欺骗攻击的保护。
Diameter [RFC3588] provides support for per-packet authentication and integrity protection via use of IPsec or TLS. RADIUS/EAP [RFC3579] provides for per-packet authentication and integrity protection via use of the Message-Authenticator Attribute.
Diameter[RFC3588]通过使用IPsec或TLS提供对每包身份验证和完整性保护的支持。RADIUS/EAP[RFC3579]通过使用Message Authenticator属性提供每包身份验证和完整性保护。
[RFC3748] Section 7.2.1 describes the "integrity protection" security claim and [RFC4017] Section 2.2 requires EAP methods supporting this claim.
[RFC3748]第7.2.1节描述了“完整性保护”安全声明，[RFC4017]第2.2节要求EAP方法支持该声明。
In order to prevent forgery of Secure Association Protocol frames, per-frame authentication and integrity protection is RECOMMENDED on all messages. IKEv2 [RFC4306] supports per-frame integrity
为了防止伪造安全关联协议帧，建议对所有消息进行每帧身份验证和完整性保护。IKEv2[RFC4306]支持每帧完整性
protection and authentication, as does the Secure Association Protocol defined in [IEEE-802.16e]. [IEEE-802.11] supports per-frame integrity protection and authentication on all messages within the 4-way handshake except the first message. An attack leveraging this omission is described in [Analysis].
保护和认证，以及[IEEE-802.16e]中定义的安全关联协议。[IEEE-802.11]支持对4路握手中除第一条消息外的所有消息进行每帧完整性保护和身份验证。[分析]中描述了利用此遗漏的攻击。
Both RADIUS [RFC2865] and Diameter [RFC3588] implementations are potentially vulnerable to a rogue authenticator impersonating another authenticator. While both protocols support mutual authentication between the AAA client/authenticator and the backend authentication server, the security mechanisms vary.
RADIUS[RFC2865]和Diameter[RFC3588]实现都可能容易受到恶意身份验证程序模仿其他身份验证程序的攻击。虽然这两个协议都支持AAA客户端/身份验证程序和后端身份验证服务器之间的相互身份验证，但安全机制各不相同。
In RADIUS, the shared secret used for authentication is determined by the source address of the RADIUS packet. However, when RADIUS Access-Requests are forwarded by a proxy, the NAS-IP-Address, NAS-Identifier, or NAS-IPv6-Address attributes received by the RADIUS server will not correspond to the source address. As noted in [RFC3579] Section 4.3.7, if the first-hop proxy does not check the NAS identification attributes against the source address in the Access-Request packet, it is possible for a rogue authenticator to forge NAS-IP-Address [RFC2865], NAS-IPv6-Address [RFC3162], or NAS-Identifier [RFC2865] attributes in order to impersonate another authenticator; attributes such as the Called-Station-Id [RFC2865] and Calling-Station-Id [RFC2865] can be forged as well. Among other things, this can result in messages (and transported keying material) being sent to the wrong authenticator.
在RADIUS中，用于身份验证的共享秘密由RADIUS数据包的源地址确定。但是，当代理转发RADIUS访问请求时，RADIUS服务器接收到的NAS IP地址、NAS标识符或NAS-IPv6-Address属性将与源地址不对应。如[RFC3579]第4.3.7节所述，如果第一跳代理未根据访问请求数据包中的源地址检查NAS标识属性，则恶意验证器可能伪造NAS IP地址[RFC2865]、NAS-IPv6-address[RFC3162]或NAS标识[RFC2865]属性以模拟另一个验证器；还可以伪造被叫站Id[RFC2865]和主叫站Id[RFC2865]等属性。除其他外，这可能会导致消息（和传输的密钥材料）被发送到错误的验证器。
While [RFC3588] requires use of the Route-Record AVP, this utilizes Fully Qualified Domain Names (FQDNs), so that impersonation detection requires DNS A, AAAA, and PTR Resource Records (RRs) to be properly configured. As a result, Diameter is as vulnerable to this attack as RADIUS, if not more so. [RFC3579] Section 4.3.7 recommends mechanisms for impersonation detection; to prevent access to keying material by proxies without a "need to know", it is necessary to allow the backend authentication server to communicate with the authenticator directly, such as via the redirect functionality supported in [RFC3588].
虽然[RFC3588]需要使用路由记录AVP，但它使用完全限定域名（FQDN），因此模拟检测需要正确配置DNS A、AAAA和PTR资源记录（RRs）。因此，直径与半径一样容易受到攻击，如果不是更大的话。[RFC3579]第4.3.7节建议模拟检测机制；为了防止代理在没有“需要知道”的情况下访问密钥材料，有必要允许后端身份验证服务器直接与身份验证程序通信，例如通过[RFC3588]中支持的重定向功能。
It is possible for a compromised or poorly implemented EAP authenticator to communicate incorrect information to the EAP peer and/or server. This can enable an authenticator to impersonate another authenticator or communicate incorrect information via out-of-band mechanisms (such as via AAA or the lower layer).
被破坏或实施不当的EAP验证器有可能向EAP对等方和/或服务器传递不正确的信息。这可以使验证器模拟另一验证器，或通过带外机制（例如通过AAA或较低层）传递错误信息。
Where EAP is used in pass-through mode, the EAP peer does not verify the identity of the pass-through authenticator within the EAP conversation. Within the Secure Association Protocol, the EAP peer and authenticator only demonstrate mutual possession of the transported keying material; they do not mutually authenticate. This creates a potential security vulnerability, described in [RFC3748] Section 7.15.
在通过模式下使用EAP的情况下，EAP对等方不会在EAP对话中验证通过身份验证器的身份。在安全关联协议中，EAP对等方和认证方仅证明相互拥有传输的密钥材料；它们不相互验证。这会产生一个潜在的安全漏洞，如[RFC3748]第7.15节所述。
As described in [RFC3579] Section 4.3.7, it is possible for a first-hop AAA proxy to detect a AAA client attempting to impersonate another authenticator. However, it is possible for a pass-through authenticator acting as a AAA client to provide correct information to the backend authentication server while communicating misleading information to the EAP peer via the lower layer.
如[RFC3579]第4.3.7节所述，第一跳AAA代理可能检测到AAA客户端试图模拟另一个验证器。然而，作为AAA客户端的直通认证器可以向后端认证服务器提供正确的信息，同时通过较低层向EAP对等方传递误导性信息。
For example, a compromised authenticator can utilize another authenticator's Called-Station-Id or NAS-Identifier in communicating with the EAP peer via the lower layer. Also, a pass-through authenticator acting as a AAA client can provide an incorrect peer Calling-Station-Id [RFC2865] [RFC3580] to the backend authentication server via the AAA protocol.
例如，受损认证器可以利用另一认证器的被叫站Id或NAS标识符通过较低层与EAP对等方通信。此外，作为AAA客户端的直通认证器可以通过AAA协议向后端认证服务器提供不正确的对等呼叫站Id[RFC2865][RFC3580]。
As noted in [RFC3748] Section 7.15, this vulnerability can be addressed by EAP methods that 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].
如[RFC3748]第7.15节所述，此漏洞可通过支持通道属性（如端点标识符）的受保护交换的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. Typically, the EAP method imports channel binding parameters from the lower layer on the peer, and transmits them securely to the EAP server, which exports them to the lower layer or AAA layer. However, transport can occur from EAP server to peer, or can be bi-directional. On the side of the exchange (peer or server) where channel binding is verified, the lower layer or AAA layer passes the result of the verification (TRUE or FALSE) up to the EAP method. While the verification can be done either by the peer or the server, typically only the server has the knowledge to determine the correctness of the values, as opposed to merely verifying their equality. For further discussion, see [EAP-SERVICE].
使用这种受保护的交换，可以将认证器通过带外机制提供的信道属性与EAP方法内交换的信道属性相匹配。通常，EAP方法从对等机的较低层导入通道绑定参数，并将其安全地传输到EAP服务器，后者将其导出到较低层或AAA层。但是，传输可以从EAP服务器传输到对等服务器，也可以是双向的。在验证通道绑定的交换端（对等方或服务器），较低层或AAA层将验证结果（TRUE或FALSE）传递给EAP方法。虽然验证可以由对等方或服务器完成，但通常只有服务器知道如何确定值的正确性，而不仅仅是验证值的相等性。有关进一步讨论，请参阅[EAP-SERVICE]。
It is also possible to perform channel binding without transporting data over EAP, as described in [EAP-CHANNEL]. In this approach the EAP method includes channel binding parameters in the calculation of exported EAP keying material, making it impossible for the peer and
也可以在不通过EAP传输数据的情况下执行通道绑定，如[EAP-channel]中所述。在这种方法中，EAP方法在计算导出的EAP键控材料时包括通道绑定参数，使得对等方和
authenticator to complete the Secure Association Protocol if there is a mismatch in the channel binding parameters. However, this approach can only be applied where methods generating EAP keying material are used along with lower layers that utilize EAP keying material. For example, this mechanism would not enable verification of channel binding on wired IEEE 802 networks using [IEEE-802.1X].
如果通道绑定参数不匹配，则验证程序完成安全关联协议。但是，此方法仅适用于生成EAP键控材料的方法与使用EAP键控材料的较低层一起使用的情况。例如，此机制无法使用[IEEE-802.1X]验证有线IEEE 802网络上的信道绑定。
[RFC3748] Section 7.2.1 describes the "mutual authentication" and "dictionary attack resistance" claims, and [RFC4017] requires EAP methods satisfying these claims. EAP methods complying with [RFC4017] therefore provide for mutual authentication between the EAP peer and server.
[RFC3748]第7.2.1节描述了“相互认证”和“字典攻击抵抗”声明，[RFC4017]要求EAP方法满足这些声明。因此，符合[RFC4017]的EAP方法提供了EAP对等方和服务器之间的相互认证。
[RFC3748] Section 7.2.1 also describes the "Cryptographic binding" security claim, and [RFC4017] Section 2.2 requires support for this claim. As described in [EAP-BINDING], EAP method sequences and compound authentication mechanisms can be subject to man-in-the-middle attacks. When such attacks are successfully carried out, the attacker acts as an intermediary between a victim and a legitimate authenticator. This allows the attacker to authenticate successfully to the authenticator, as well as to obtain access to the network.
[RFC3748]第7.2.1节还描述了“加密绑定”安全声明，[RFC4017]第2.2节要求支持该声明。如[EAP-BINDING]所述，EAP方法序列和复合身份验证机制可能受到中间人攻击。成功实施此类攻击后，攻击者将充当受害者和合法身份验证者之间的中间人。这使攻击者能够成功地向验证器进行身份验证，并获得对网络的访问权。
In order to prevent these attacks, [EAP-BINDING] recommends derivation of a compound key by which the EAP peer and server can prove that they have participated in the entire EAP exchange. Since the compound key MUST NOT be known to an attacker posing as an authenticator, and yet must be derived from EAP keying material, it MAY be desirable to derive the compound key from a portion of the EMSK. Where this is done, in order to provide proper key hygiene, it is RECOMMENDED that the compound key used for man-in-the-middle protection be cryptographically separate from other keys derived from the EMSK.
为了防止这些攻击，[EAP-BINDING]建议派生一个复合密钥，通过该密钥，EAP对等方和服务器可以证明他们参与了整个EAP交换。由于复合密钥不能为冒充验证者的攻击者所知，而且必须从EAP密钥材料派生，因此可能需要从EMSK的一部分派生复合密钥。在这样做的情况下，为了提供适当的密钥卫生，建议用于中间人保护的复合密钥以加密方式与来自EMSK的其他密钥分开。
Diameter [RFC3588] provides for per-packet authentication and integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also provides for per-packet authentication and integrity protection. Where the authenticator/AAA client and backend authentication server communicate directly and credible key wrap is used (see Section 3.8), this ensures that the AAA Key Transport (phase 1b) achieves its security objectives: mutually authenticating the AAA client/authenticator and backend authentication server and providing transported keying material to the EAP authenticator and to no other party.
Diameter[RFC3588]通过IPsec或TLS提供每包身份验证和完整性保护，RADIUS/EAP[RFC3579]也提供每包身份验证和完整性保护。当认证器/AAA客户端和后端认证服务器直接通信并使用可靠的密钥包装时（参见第3.8节），这将确保AAA密钥传输（阶段1b）实现其安全目标：相互验证AAA客户端/身份验证程序和后端身份验证服务器，并向EAP身份验证程序而非其他方提供传输的密钥材料。
[RFC2607] Section 7 describes the security issues occurring when the authenticator/AAA client and backend authentication server do not communicate directly. Where a AAA intermediary is present (such as a RADIUS proxy or a Diameter agent), and data object security is not used, transported keying material can be recovered by an attacker in control of the intermediary. As discussed in Section 2.1, unless the TSKs are derived independently from EAP keying material (as in IKEv2), possession of transported keying material enables decryption of data traffic sent between the peer and the authenticator to whom the keying material was transported. It also allows the AAA intermediary to impersonate the authenticator or the peer. Since the peer does not authenticate to a AAA intermediary, it has no ability to determine whether it is authentic or authorized to obtain keying material.
[RFC2607]第7节描述了身份验证程序/AAA客户端和后端身份验证服务器不直接通信时发生的安全问题。如果存在AAA中介（如RADIUS代理或Diameter代理），并且未使用数据对象安全性，则攻击者可以在控制该中介的情况下恢复传输的密钥材料。如第2.1节所述，除非TSK独立于EAP密钥材料（如IKEv2中所述），否则拥有传输的密钥材料能够解密对等方和密钥材料传输到的认证方之间发送的数据流量。它还允许AAA中介模拟验证器或对等方。由于对等方未向AAA中介机构进行身份验证，因此无法确定其是否真实或是否有权获取密钥材料。
However, as long as transported keying material or keys derived from it are only utilized by a single authenticator, compromise of the transported keying material does not enable an attacker to impersonate the peer to another authenticator. Vulnerability to compromise of a AAA intermediary can be mitigated by implementation of redirect functionality, as described in [RFC3588] and [RFC4072].
但是，只要传输的密钥材料或从其派生的密钥仅由单个验证器使用，则传输的密钥材料的泄露不会使攻击者将对等方模拟为另一验证器。如[RFC3588]和[RFC4072]中所述，通过实施重定向功能，可以缓解AAA中介的漏洞。
The Secure Association Protocol does not provide for mutual authentication between the EAP peer and authenticator, only mutual proof of possession of transported keying material. In order for the peer to verify the identity of the authenticator, mutual proof of possession needs to be combined with impersonation prevention and channel binding. Impersonation prevention (described in Section 5.3.2) enables the backend authentication server to determine that the transported keying material has been provided to the correct authenticator. When utilized along with impersonation prevention, channel binding (described in Section 5.3.3) enables the EAP peer to verify that the EAP server has authorized the authenticator to possess the transported keying material. Completion of the Secure Association Protocol exchange demonstrates that the EAP peer and the authenticator possess the transported keying material.
安全关联协议不提供EAP对等方和认证方之间的相互认证，只提供对传输的密钥材料拥有的相互证明。为了让对等方验证身份验证者的身份，需要将占有的相互证明与冒充预防和通道绑定相结合。模拟预防（如第5.3.2节所述）使后端身份验证服务器能够确定已将传输的密钥材料提供给了正确的验证者。当与模拟预防一起使用时，通道绑定（如第5.3.3节所述）使EAP对等方能够验证EAP服务器是否已授权认证方拥有传输的密钥材料。安全关联协议交换的完成表明EAP对等方和认证方拥有传输的密钥材料。
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]第3节的强制性要求：
Bind key to its context
将键绑定到其上下文
Keying material MUST be bound to the appropriate context. The context includes the following:
键控材质必须绑定到适当的上下文。上下文包括以下内容：
o The manner in which the keying material is expected to be used.
o 预期使用键控材料的方式。
o The other parties that are expected to have access to the keying material.
o 预期可以访问键控材料的其他方。
o The expected lifetime of the keying material. Lifetime of a child key SHOULD NOT be greater than the lifetime of its parent in the key hierarchy.
o 键控材质的预期寿命。子密钥的生存期不应大于密钥层次结构中其父密钥的生存期。
Any party with legitimate access to keying material can determine its context. In addition, the protocol MUST ensure that all parties with legitimate access to keying material have the same context for the keying material. This requires that the parties are properly identified and authenticated, so that all of the parties that have access to the keying material can be determined.
任何合法访问密钥材料的一方都可以确定其上下文。此外，协议必须确保合法访问密钥材料的所有各方都拥有相同的密钥材料上下文。这要求各方得到适当的识别和认证，以便能够确定能够访问密钥材料的所有各方。
The context will include the peer and NAS identities in more than one form. One (or more) name form is needed to identify these parties in the authentication exchange and the AAA protocol. Another name form may be needed to identify these parties within the lower layer that will employ the session key.
上下文将以多种形式包括对等和NAS标识。需要一个（或多个）名称表单来识别身份验证交换和AAA协议中的这些方。可能需要另一个名称表单来标识将使用会话密钥的较低层中的这些方。
Within EAP, exported keying material (MSK, EMSK,IV) is bound to the Peer-Id(s) and Server-Id(s), which are exported along with the keying material. However, not all EAP methods support authenticated server identities (see Appendix A).
在EAP中，导出的密钥材料（MSK、EMSK、IV）绑定到对等Id和服务器Id，它们与密钥材料一起导出。但是，并非所有EAP方法都支持经过身份验证的服务器标识（参见附录A）。
Within the AAA protocol, transported keying material is destined for the EAP authenticator identified by the NAS-Identifier Attribute within the request, and is for use by the EAP peer identified by the Peer-Id(s), User-Name [RFC2865], or Chargeable User Identity (CUI) [RFC4372] attributes. The maximum lifetime of the transported keying material can be provided, as discussed in Section 3.5.1. Key usage restrictions can also be included as described in Section 3.2. Key lifetime issues are discussed in Sections 3.3, 3.4, and 3.5.
在AAA协议中，传输的密钥材料发送给由请求中的NAS标识符属性标识的EAP验证器，并供由对等Id、用户名[RFC2865]或计费用户标识（CUI）[RFC4372]属性标识的EAP对等方使用。如第3.5.1节所述，可提供运输键控材料的最大使用寿命。如第3.2节所述，还可以包括密钥使用限制。第3.3、3.4和3.5节讨论了关键寿命问题。
Requirement: The Secure Association Protocol (phase 2) conversation may utilize different identifiers from the EAP conversation (phase 1a), so that binding between the EAP and Secure Association Protocol identities is REQUIRED.
要求：安全关联协议（阶段2）对话可能使用EAP对话（阶段1a）中的不同标识符，因此需要EAP和安全关联协议标识之间的绑定。
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]第3节的强制性要求：
Peer and authenticator authorization
对等和身份验证器授权
Peer and authenticator authorization MUST be performed. These entities MUST demonstrate possession of the appropriate keying material, without disclosing it. Authorization is REQUIRED
必须执行对等和身份验证程序授权。这些实体必须证明拥有适当的键控材料，而不予以披露。需要授权
whenever a peer associates with a new authenticator. The authorization checking prevents an elevation of privilege attack, and it ensures that an unauthorized authenticator is detected.
每当对等方与新身份验证器关联时。授权检查可防止权限提升攻击，并确保检测到未经授权的身份验证程序。
Authorizations SHOULD be synchronized between the peer, NAS, and backend authentication server. Once the AAA key management protocol exchanges are complete, all of these parties should hold a common view of the authorizations associated with the other parties.
应在对等、NAS和后端身份验证服务器之间同步授权。一旦AAA密钥管理协议交换完成，所有这些方都应持有与其他方相关的授权的共同视图。
In addition to authenticating all parties, key management protocols need to demonstrate that the parties are authorized to possess keying material. Note that proof of possession of keying material does not necessarily prove authorization to hold that keying material. For example, within an IEEE 802.11, the 4-way handshake demonstrates that both the peer and authenticator possess the same EAP keying material. However, by itself, this possession proof does not demonstrate that the authenticator was authorized by the backend authentication server to possess that keying material. As noted in [RFC3579] in Section 4.3.7, where AAA proxies are present, it is possible for one authenticator to impersonate another, unless each link in the AAA chain implements checks against impersonation. Even with these checks in place, an authenticator may still claim different identities to the peer and the backend authentication server. As described in [RFC3748] Section 7.15, channel binding is required to enable the peer to verify that the authenticator claim of identity is both consistent and correct.
除了认证各方之外，密钥管理协议还需要证明各方有权拥有密钥材料。请注意，拥有钥匙材料的证明并不一定证明持有该钥匙材料的授权。例如，在IEEE 802.11中，4路握手证明对等方和认证方都拥有相同的EAP密钥材料。然而，就其本身而言，该占有证明并不能证明认证者已被后端认证服务器授权拥有该密钥材料。如第4.3.7节[RFC3579]中所述，在存在AAA代理的情况下，一个验证器可以模拟另一个验证器，除非AAA链中的每个链接都对模拟进行检查。即使有了这些检查，身份验证器仍然可以向对等方和后端身份验证服务器声明不同的身份。如[RFC3748]第7.15节所述，需要进行通道绑定，以使对等方能够验证身份认证者声明的一致性和正确性。
Recommendation from [RFC4962] Section 3:
[RFC4962]第3节的建议：
Authorization restriction
授权限制
If peer authorization is restricted, then the peer SHOULD be made aware of the restriction. Otherwise, the peer may inadvertently attempt to circumvent the restriction. For example, authorization restrictions in an IEEE 802.11 environment include:
如果对等授权受到限制，则应让对等方知道该限制。否则，对等方可能无意中试图绕过限制。例如，IEEE 802.11环境中的授权限制包括：
o Key lifetimes, where the keying material can only be used for a certain period of time;
o 密钥寿命，其中密钥材料只能使用一段时间；
o SSID restrictions, where the keying material can only be used with a specific IEEE 802.11 SSID;
o SSID限制，其中键控材料只能与特定IEEE 802.11 SSID一起使用；
o Called-Station-ID restrictions, where the keying material can only be used with a single IEEE 802.11 BSSID; and
o 称为站点ID限制，其中键控材料只能与单个IEEE 802.11 BSSID一起使用；和
o Calling-Station-ID restrictions, where the keying material can only be used with a single peer IEEE 802 MAC address.
o 呼叫站ID限制，其中键控材料只能与单个对等IEEE 802 MAC地址一起使用。
As described in Section 2.3, consistent identification of the EAP authenticator enables the EAP peer to determine the scope of keying material provided to an authenticator, as well as to confirm with the backend authentication server that an EAP authenticator proving possession of EAP keying material during the Secure Association Protocol was authorized to obtain it.
如第2.3节所述，EAP认证者的一致性标识使EAP对等方能够确定提供给认证者的密钥材料的范围，以及与后端身份验证服务器确认，证明在安全关联协议期间拥有EAP密钥材料的EAP身份验证人被授权获取该材料。
Within the AAA protocol, the authorization attributes are bound to the transported keying material. While the AAA exchange provides the AAA client/authenticator with authorizations relating to the EAP peer, neither the EAP nor AAA exchanges provide authorizations to the EAP peer. In order to ensure that all parties hold the same view of the authorizations, it is RECOMMENDED that the Secure Association Protocol enable communication of authorizations between the EAP authenticator and peer.
在AAA协议中，授权属性绑定到传输的密钥材料。虽然AAA交换为AAA客户端/验证器提供了与EAP对等方相关的授权，但EAP和AAA交换均未向EAP对等方提供授权。为了确保各方持有相同的授权视图，建议安全关联协议启用EAP验证器和对等方之间的授权通信。
In lower layers where the authenticator consistently identifies itself to the peer and backend authentication server and the EAP peer completes the Secure Association Protocol exchange with the same authenticator through which it completed the EAP conversation, authorization of the authenticator is demonstrated to the peer by mutual authentication between the peer and authenticator as discussed in the previous section. Identification issues are discussed in Sections 2.3, 2.4, and 2.5 and key scope issues are discussed in Section 3.2.
在较低的层中，身份验证器始终向对等和后端身份验证服务器标识自己，EAP对等与完成EAP对话的同一身份验证器完成安全关联协议交换，如前一节所述，通过对等方和认证方之间的相互认证向对等方演示认证方的授权。第2.3、2.4和2.5节讨论了识别问题，第3.2节讨论了关键范围问题。
Where the EAP peer utilizes different identifiers within the EAP method and Secure Association Protocol conversations, peer authorization can be difficult to demonstrate to the authenticator without additional restrictions. This problem does not exist in IKEv2 where the Identity Payload is used for peer identification both within IKEv2 and EAP, and where the EAP conversation is cryptographically protected within IKEv2 binding the EAP and IKEv2 exchanges. However, within [IEEE-802.11], the EAP peer identity is not used within the 4-way handshake, so that it is necessary for the authenticator to require that the EAP peer utilize the same MAC address for EAP authentication as for the 4-way handshake.
如果EAP对等方在EAP方法和安全关联协议对话中使用不同的标识符，那么在没有附加限制的情况下，对等方授权可能难以向认证方演示。在IKEv2中不存在此问题，其中标识有效负载用于IKEv2和EAP中的对等标识，并且EAP会话在绑定EAP和IKEv2交换的IKEv2中受到加密保护。然而，在[IEEE-802.11]中，EAP对等身份不在4路握手中使用，因此认证者有必要要求EAP对等使用与4路握手相同的MAC地址进行EAP认证。
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]第3节的强制性要求：
Replay detection mechanism
重播检测机制
The AAA key management protocol exchanges MUST be replay protected, including AAA, EAP and Secure Association Protocol exchanges. Replay protection allows a protocol message recipient to discard any message that was recorded during a previous legitimate dialogue and presented as though it belonged to the current dialogue.
AAA密钥管理协议交换必须受到重播保护，包括AAA、EAP和安全关联协议交换。重播保护允许协议消息接收者丢弃在上一次合法对话期间录制并显示的任何消息，就好像它属于当前对话一样。
[RFC3748] Section 7.2.1 describes the "replay protection" security claim, and [RFC4017] Section 2.2 requires use of EAP methods supporting this claim.
[RFC3748]第7.2.1节描述了“重播保护”安全声明，[RFC4017]第2.2节要求使用支持该声明的EAP方法。
Diameter [RFC3588] provides support for replay protection via use of IPsec or TLS. "RADIUS Support for EAP" [RFC3579] protects against replay of keying material via the Request Authenticator. According to [RFC2865] Section 3:
Diameter[RFC3588]通过使用IPsec或TLS提供重播保护支持。“EAP的RADIUS支持”[RFC3579]可防止通过请求验证器重播键控材料。根据[RFC2865]第3节：
In Access-Request Packets, the Authenticator value is a 16 octet random number, called the Request Authenticator.
在访问请求数据包中，验证器值是一个16个八位组的随机数，称为请求验证器。
However, some RADIUS packets are not replay protected. In Accounting, Disconnect, and Care-of Address (CoA)-Request packets, the Request Authenticator contains a keyed Message Integrity Code (MIC) rather than a nonce. The Response Authenticator in Accounting, Disconnect, and CoA-Response packets also contains a keyed MIC whose calculation does not depend on a nonce in either the Request or Response packets. Therefore, unless an Event-Timestamp attribute is included or IPsec is used, it is possible that the recipient will not be able to determine whether these packets have been replayed. This issue is discussed further in [RFC5176] Section 6.3.
但是，某些RADIUS数据包不受重播保护。在记帐、断开连接和转交地址（CoA）-请求数据包中，请求验证器包含密钥消息完整性代码（MIC），而不是nonce。记帐、断开连接和CoA响应数据包中的响应验证器还包含一个键控麦克风，其计算不依赖于请求或响应数据包中的nonce。因此，除非包含事件时间戳属性或使用IPsec，否则接收方可能无法确定这些数据包是否已被重放。[RFC5176]第6.3节进一步讨论了该问题。
In order to prevent replay of Secure Association Protocol frames, replay protection is REQUIRED on all messages. [IEEE-802.11] supports replay protection on all messages within the 4-way handshake; IKEv2 [RFC4306] also supports this.
为了防止安全关联协议帧的重播，所有消息都需要重播保护。[IEEE-802.11]支持对4路握手中的所有消息进行重放保护；IKEv2[RFC4306]也支持这一点。
Requirement: A session key SHOULD be considered compromised if it remains in use beyond its authorized lifetime. Mandatory requirement from [RFC4962] Section 3:
要求：如果会话密钥在其授权生存期之后仍在使用，则应将其视为已被泄露。[RFC4962]第3节的强制性要求：
Strong, fresh session keys
强大、新鲜的会话密钥
While preserving algorithm independence, session keys MUST be strong and fresh. Each session deserves an independent session key. Fresh keys are required even when a long replay counter (that is, one that "will never wrap") is used to ensure that loss of state does not cause the same counter value to be used more than once with the same session key.
在保持算法独立性的同时，会话密钥必须是强且新鲜的。每个会话都需要一个独立的会话密钥。即使使用长重播计数器（即“永不换行”的计数器）来确保状态丢失不会导致同一计数器值与同一会话密钥一起使用多次，也需要使用新密钥。
Some EAP methods are capable of deriving keys of varying strength, and these EAP methods MUST permit the generation of keys meeting a minimum equivalent key strength. BCP 86 [RFC3766] offers advice on appropriate key sizes. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57].
一些EAP方法能够导出不同强度的密钥，这些EAP方法必须允许生成满足最小等效密钥强度的密钥。BCP 86[RFC3766]提供有关适当密钥大小的建议。国家标准与技术研究所（NIST）也在[SP800-57]中提供了关于适当键尺寸的建议。
A fresh cryptographic key is one that is generated specifically for the intended use. In this situation, a secure association protocol is used to establish session keys. The AAA protocol and EAP method MUST ensure that the keying material supplied as an input to session key derivation is fresh, and the secure association protocol MUST generate a separate session key for each session, even if the keying material provided by EAP is cached. A cached key persists after the authentication exchange has completed. For the AAA/EAP server, key caching can happen when state is kept on the server. For the NAS or client, key caching can happen when the NAS or client does not destroy keying material immediately following the derivation of session keys.
新加密密钥是专门为预期用途生成的密钥。在这种情况下，使用安全关联协议来建立会话密钥。AAA协议和EAP方法必须确保作为会话密钥派生输入提供的密钥材料是新的，并且安全关联协议必须为每个会话生成单独的会话密钥，即使EAP提供的密钥材料被缓存。身份验证交换完成后，缓存的密钥将持续存在。对于AAA/EAP服务器，当状态保持在服务器上时，可以进行密钥缓存。对于NAS或客户端，当NAS或客户端在会话密钥派生后没有立即销毁密钥材料时，可能会发生密钥缓存。
Session keys MUST NOT be dependent on one another. Multiple session keys may be derived from a higher-level shared secret as long as a one-time value, usually called a nonce, is used to ensure that each session key is fresh. The mechanism used to generate session keys MUST ensure that the disclosure of one session key does not aid the attacker in discovering any other session keys.
会话密钥不能相互依赖。只要使用一个一次性值（通常称为nonce）来确保每个会话密钥都是新的，就可以从更高级别的共享密钥派生多个会话密钥。用于生成会话密钥的机制必须确保一个会话密钥的泄露不会帮助攻击者发现任何其他会话密钥。
EAP, AAA, and the lower layer each bear responsibility for ensuring the use of fresh, strong session keys. EAP methods need to ensure the freshness and strength of EAP keying material provided as an input to session key derivation. [RFC3748] Section 7.10 states:
EAP、AAA和较低层各自负责确保使用新的、强大的会话密钥。EAP方法需要确保作为会话密钥派生输入提供的EAP密钥材料的新鲜度和强度。[RFC3748]第7.10节规定：
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的推导。
The contribution of nonces enables the EAP peer and server to ensure that exported EAP keying material is fresh.
nonce的贡献使EAP对等方和服务器能够确保导出的EAP密钥材料是新的。
[RFC3748] Section 7.2.1 describes the "key strength" and "session independence" security claims, and [RFC4017] requires EAP methods supporting these claims as well as methods capable of providing equivalent key strength of 128 bits or greater. See Section 3.7 for more information on key strength.
[RFC3748]第7.2.1节描述了“密钥强度”和“会话独立性”安全声明，[RFC4017]要求支持这些声明的EAP方法以及能够提供128位或更高等效密钥强度的方法。有关关键强度的更多信息，请参见第3.7节。
The AAA protocol needs to ensure that transported keying material is fresh and is not utilized outside its recommended lifetime. Replay protection is necessary for key freshness, but an attacker can deliver a stale (and therefore potentially compromised) key in a replay-protected message, so replay protection is not sufficient. As discussed in Section 3.5, the Session-Timeout Attribute enables the backend authentication server to limit the exposure of transported keying material.
AAA协议需要确保传输的密钥材料是新鲜的，并且在其建议的使用寿命之外不会被使用。重播保护对于密钥的新鲜度是必要的，但是攻击者可以在重播保护的消息中传递过时（因此可能受损）的密钥，因此重播保护是不够的。如第3.5节所述，会话超时属性使后端身份验证服务器能够限制传输的密钥材料的公开。
The EAP Session-Id, described in Section 1.4, enables the EAP peer, authenticator, and server to distinguish EAP conversations. However, unless the authenticator keeps track of EAP Session-Ids, the authenticator cannot use the Session-Id to guarantee the freshness of keying material.
第1.4节中描述的EAP会话Id使EAP对等方、身份验证方和服务器能够区分EAP会话。但是，除非验证器跟踪EAP会话Id，否则验证器无法使用会话Id来保证密钥材料的新鲜度。
The Secure Association Protocol, described in Section 3.1, MUST generate a fresh session key for each session, even if the EAP keying material and parameters provided by methods are cached, or either the peer or authenticator lack a high entropy random number generator. A RECOMMENDED method is for the peer and authenticator to each provide a nonce or counter used in session key derivation. If a nonce is used, it is RECOMMENDED that it be at least 128 bits. While [IEEE-802.11] and IKEv2 [RFC4306] satisfy this requirement, [IEEE-802.16e] does not, since randomness is only contributed from the Base Station.
第3.1节中描述的安全关联协议必须为每个会话生成新的会话密钥，即使方法提供的EAP密钥材料和参数被缓存，或者对等方或认证方缺少高熵随机数生成器。推荐的方法是对等方和身份验证方各自提供会话密钥派生中使用的nonce或计数器。如果使用nonce，建议它至少为128位。虽然[IEEE-802.11]和IKEv2[RFC4306]满足此要求，但[IEEE-802.16e]不满足此要求，因为随机性仅来自基站。
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]第3节的强制性要求：
Limit key scope
限制键范围
Following the principle of least privilege, parties MUST NOT have access to keying material that is not needed to perform their role. A party has access to a particular key if it has access to all of the secret information needed to derive it.
根据最低特权原则，各方不得访问履行其职责不需要的密钥材料。如果一方可以访问派生密钥所需的所有机密信息，则该方可以访问特定密钥。
Any protocol that is used to establish session keys MUST specify the scope for session keys, clearly identifying the parties to whom the session key is available.
用于建立会话密钥的任何协议都必须指定会话密钥的范围，明确标识会话密钥可供使用的各方。
Transported keying material is permitted to be accessed by the EAP peer, authenticator and server. The EAP peer and server derive EAP keying material during the process of mutually authenticating each other using the selected EAP method. During the Secure Association Protocol exchange, the EAP peer utilizes keying material to demonstrate to the authenticator that it is the same party that authenticated to the EAP server and was authorized by it. The EAP authenticator utilizes the transported keying material to prove to the peer not only that the EAP conversation was transported through it (this could be demonstrated by a man-in-the-middle), but that it was uniquely authorized by the EAP server to provide the peer with access to the network. Unique authorization can only be demonstrated if the EAP authenticator does not share the transported keying material with a party other than the EAP peer and server. TSKs are permitted to be accessed only by the EAP peer and authenticator (see Section 1.5); TSK derivation is discussed in Section 2.1. Since demonstration of authorization within the Secure Association Protocol exchange depends on possession of transported keying material, the backend authentication server can obtain TSKs unless it deletes the transported keying material after sending it.
EAP对等方、认证方和服务器允许访问传输的密钥材料。EAP对等方和服务器在使用所选EAP方法相互验证的过程中派生EAP密钥材料。在安全关联协议交换期间，EAP对等方利用密钥材料向认证方证明，它是向EAP服务器进行认证并由其授权的同一方。EAP验证器利用传输的密钥材料向对等方证明，EAP会话不仅是通过它传输的（这可以由中间的一个人演示），而且它是由EAP服务器唯一授权的，以向对等方提供对网络的访问。只有当EAP验证器不与EAP对等方和服务器以外的其他方共享传输的密钥材料时，才能证明唯一授权。TSK仅允许EAP对等方和认证方访问（见第1.5节）；TSK推导在第2.1节中讨论。由于安全关联协议交换中授权的演示取决于传输的密钥材料的拥有情况，因此后端身份验证服务器可以获得TSK，除非它在发送后删除传输的密钥材料。
Mandatory requirement from [RFC4962] Section 3:
[RFC4962]第3节的强制性要求：
Uniquely named keys
唯一命名的密钥
AAA key management proposals require a robust key naming scheme, particularly where key caching is supported. The key name provides a way to refer to a key in a protocol so that it is clear to all parties which key is being referenced. Objects that cannot be named cannot be managed. All keys MUST be uniquely named, and the key name MUST NOT directly or indirectly disclose the keying
AAA密钥管理方案需要一个健壮的密钥命名方案，特别是在支持密钥缓存的情况下。密钥名称提供了一种在协议中引用密钥的方法，以便各方都清楚引用哪个密钥。无法管理无法命名的对象。所有密钥必须具有唯一的名称，且密钥名称不得直接或间接透露密钥
material. If the key name is not based on the keying material, then one can be sure that it cannot be used to assist in a search for the key value.
布料如果键名称不是基于键控材质，则可以确保它不能用于协助搜索键值。
EAP key names (defined in Section 1.4.1), along with the Peer-Id(s) and Server-Id(s), uniquely identify EAP keying material, and do not directly or indirectly expose EAP keying material.
EAP密钥名称（定义见第1.4.1节）以及对等Id和服务器Id可唯一标识EAP密钥材料，且不会直接或间接公开EAP密钥材料。
Existing AAA server implementations do not distribute key names along with the transported keying material. However, Diameter EAP [RFC4072] Section 4.1.4 defines the EAP-Key-Name AVP for the purpose of transporting the EAP Session-Id. Since the EAP-Key-Name AVP is defined within the RADIUS attribute space, it can be used either with RADIUS or Diameter.
现有的AAA服务器实现不会将密钥名称与传输的密钥材料一起分发。但是，Diameter EAP[RFC4072]第4.1.4节定义了EAP密钥名称AVP，用于传输EAP会话Id。由于EAP密钥名称AVP是在RADIUS属性空间中定义的，因此可以与RADIUS或Diameter一起使用。
Since the authenticator is not provided with the name of the transported keying material by existing backend authentication server implementations, existing Secure Association Protocols do not utilize EAP key names. For example, [IEEE-802.11] supports PMK caching; to enable the peer and authenticator to determine the cached PMK to utilize within the 4-way handshake, the PMK needs to be named. For this purpose, [IEEE-802.11] utilizes a PMK naming scheme that is based on the key. Since IKEv2 [RFC4306] does not cache transported keying material, it does not need to refer to transported keying material.
由于现有后端身份验证服务器实现未向验证器提供传输的密钥材料的名称，因此现有安全关联协议不使用EAP密钥名称。例如，[IEEE-802.11]支持PMK缓存；为了使对等方和身份验证器能够确定要在4路握手中使用的缓存PMK，需要命名PMK。为此，[IEEE-802.11]利用基于密钥的PMK命名方案。由于IKEv2[RFC4306]不缓存传输的键控材料，因此它不需要引用传输的键控材料。
Key caching can result in vulnerability to denial-of-service attacks. For example, EAP methods that create persistent state can be vulnerable to denial-of-service attacks on the EAP server by a rogue EAP peer.
密钥缓存会导致易受拒绝服务攻击的漏洞。例如，创建持久状态的EAP方法可能容易受到恶意EAP对等方对EAP服务器的拒绝服务攻击。
To address this vulnerability, EAP methods creating persistent state can limit the persistent state created by an EAP peer. For example, for each peer an EAP server can choose to limit persistent state to a few EAP conversations, distinguished by the EAP Session-Id. This prevents a rogue peer from denying access to other peers.
为了解决此漏洞，创建持久状态的EAP方法可以限制EAP对等方创建的持久状态。例如，对于每个对等方，EAP服务器可以选择将持久状态限制为几个EAP会话，以EAP会话Id区分。这可以防止恶意对等方拒绝对其他对等方的访问。
Similarly, to conserve resources an authenticator can choose to limit the persistent state corresponding to each peer. This can be accomplished by limiting each peer to persistent state corresponding to a few EAP conversations, distinguished by the EAP Session-Id.
类似地，为了节省资源，验证器可以选择限制对应于每个对等方的持久状态。这可以通过将每个对等点限制为对应于几个EAP会话的持久状态来实现，这些会话由EAP会话Id区分。
Whether creation of new TSKs implies deletion of previously derived TSKs depends on the EAP lower layer. Where there is no implied deletion, the authenticator can choose to limit the number of TSKs and associated state that can be stored for each peer.
创建新的TSK是否意味着删除以前派生的TSK取决于EAP较低层。在没有隐含删除的情况下，验证器可以选择限制可为每个对等方存储的TSK和关联状态的数量。
[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月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 3748，2004年6月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962]Housley，R.和B.Aboba，“认证、授权和记帐（AAA）密钥管理指南”，BCP 132，RFC 4962，2007年7月。
[8021XPreAuth] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Public Wireless LAN Based on IEEE 802.1x Model", Proceedings of the IFIP TC6/WG6.8 Working Conference on Personal Wireless Communications, p.175-182, October 23-25, 2002.
[8021XPreAuth]Pack，S.和Y.Choi，“基于IEEE 802.1x模型的公共无线LAN中的预认证快速切换”，IFIP TC6/WG6.8个人无线通信工作会议记录，第175-182页，2002年10月23-25日。
[Analysis] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way Handshake", Proceedings of the 2004 ACM Workshop on Wireless Security, pp. 43-50, ISBN: 1-58113-925-X.
[分析]He，C.和J.Mitchell，“802.11i四路握手分析”，2004年ACM无线安全研讨会论文集，第43-50页，ISBN:1-58113-925-X。
[Bargh] Bargh, M., Hulsebosch, R., Eertink, E., Prasad, A., Wang, H. and P. Schoo, "Fast Authentication Methods for Handovers between IEEE 802.11 Wireless LANs", Proceedings of the 2nd ACM international workshop on Wireless mobile applications and services on WLAN hotspots, October, 2004.
[Bargh]Bargh，M.，Hulsebosch，R.，Eertink，E.，Prasad，A.，Wang，H.和P.Schoo，“IEEE 802.11无线局域网之间切换的快速认证方法”，第二届ACM无线移动应用和服务无线局域网热点国际研讨会论文集，2004年10月。
[GKDP] Dondeti, L., Xiang, J., and S. Rowles, "GKDP: Group Key Distribution Protocol", Work in Progress, March 2006.
[GKDP]Dondeti，L.，Xiang，J.，和S.Rowles，“GKDP：组密钥分发协议”，正在进行的工作，2006年3月。
[He] He, C., Sundararajan, M., Datta, A. Derek, A. and J. C. Mitchell, "A Modular Correctness Proof of TLS and IEEE 802.11i", ACM Conference on Computer and Communications Security (CCS '05), November, 2005.
[He]He，C.，Sundararajan，M.，Datta，A.Derek，A.和J.C.Mitchell，“TLS和IEEE 802.11i的模块正确性证明”，计算机和通信安全ACM会议（CCS'05），2005年11月。
[IEEE-802.11] Institute of Electrical and Electronics Engineers, "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11-2007, 2007.
[IEEE-802.11]电气和电子工程师协会，“信息技术-系统间的电信和信息交换-局域网和城域网-特定要求第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.11-2007，2007年。
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004, December 2004.
[IEEE-802.1X]电气和电子工程师协会，“局域网和城域网：基于端口的网络访问控制”，IEEE标准802.1X-2004，2004年12月。
[IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q-2003, January 2003.
[IEEE-802.1Q]IEEE局域网和城域网标准：虚拟桥接局域网标准草案，P802.1Q-2003，2003年1月。
[IEEE-802.11i] Institute of Electrical and Electronics Engineers, "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 802.11i/D1, 2001.
[IEEE-802.11i]电气和电子工程师协会，“系统间电信和信息交换标准的补充——LAN/MAN特定要求——第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范：增强安全性规范”，IEEE 802.11i/D1，2001年。
[IEEE-802.11F] Institute of Electrical and Electronics Engineers, "Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", IEEE 802.11F, July 2003 (now deprecated).
[IEEE-802.11F]电气和电子工程师协会，“通过支持IEEE 802.11运行的配电系统间接入点协议实现多供应商接入点互操作性的推荐做法”，IEEE 802.11F，2003年7月（现已弃用）。
[IEEE-802.16e] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks: Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems: Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operations in Licensed Bands" IEEE 802.16e, August 2005.
[IEEE-802.16e]电气和电子工程师协会，“局域网和城域网的IEEE标准：第16部分：固定和移动宽带无线接入系统的空中接口：许可频带中固定和移动组合操作的物理和介质接入控制层的修订”，IEEE 802.16e，2005年8月。
[IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Key Distribution to support fast and secure roaming", IEEE 802.11 Working Group, IEEE-03- 084r1-I, http://www.ieee802.org/11/Documents/ DocumentHolder/3-084.zip, January 2003.
[IEEE-03-084]Mishra，A.，Shin，M.，Arbaugh，W.，Lee，I.和K.Jang，“支持快速安全漫游的主动密钥分发”，IEEE 802.11工作组，IEEE-03-084r1-I，http://www.ieee802.org/11/Documents/ DocumentHolder/3-084.zip，2003年1月。
[EAP-SERVICE] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", Work in Progress, October 2005.
[EAP-SERVICE]Arkko，J.和P.Erenen，“可扩展认证协议（EAP）的认证服务信息”，正在进行的工作，2005年10月。
[SHORT-TERM] Friedman, A., Sheffer, Y., and A. Shaqed, "Short-Term Certificates", Work in Progress, June 2007.
[短期]Friedman，A.，Sheffer，Y.，和A.Shaqed，“短期证书”，在建工程，2007年6月。
[HANDOFF] Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Work in Progress, October 2003.
[移交]Arbaugh，W.和B.Aboba，“向半径的移交扩展”，正在进行的工作，2003年10月。
[EAP-CHANNEL] Ohba, Y., Parthasrathy, M., and M. Yanagiya, "Channel Binding Mechanism Based on Parameter Binding in Key Derivation", Work in Progress, June 2007.
[EAP-CHANNEL]Ohba，Y.，Parthasrathy，M.，和M.Yanagiya，“基于密钥推导中参数绑定的通道绑定机制”，正在进行的工作，2007年6月。
[EAP-BINDING] Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon, "The Compound Authentication Binding Problem", Work in Progress, October 2003.
[EAP-BINDING]Puthenkulam，J.，Lortz，V.，Palekar，A.，和D.Simon，“复合认证绑定问题”，正在进行的工作，2003年10月。
[MD5Collision] Klima, V., "Tunnels in Hash Functions: MD5 Collisions
Within a Minute", Cryptology ePrint Archive, March
2006, http://eprint.iacr.org/2006/105.pdf
[MD5Collision] Klima, V., "Tunnels in Hash Functions: MD5 Collisions
Within a Minute", Cryptology ePrint Archive, March
2006, http://eprint.iacr.org/2006/105.pdf
[MishraPro] Mishra, A., Shin, M. and W. Arbaugh, "Pro-active Key Distribution using Neighbor Graphs", IEEE Wireless Communications, vol. 11, February 2004.
[MishraPro]Mishra，A.，Shin，M.和W.Arbaugh，“使用邻居图的主动密钥分配”，IEEE无线通信，第11卷，2004年2月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[RFC1968]Meyer，G.“PPP加密控制协议（ECP）”，RFC 1968，1996年6月。
[RFC2230] Atkinson, R., "Key Exchange Delegation Record for the DNS", RFC 2230, November 1997.
[RFC2230]阿特金森，R.，“DNS的密钥交换委托记录”，RFC 2230，1997年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月。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2516]Mamakos，L.，Lidl，K.，Evarts，J.，Carrel，D.，Simone，D.，和R.Wheeler，“通过以太网传输PPP（PPPoE）的方法”，RFC 2516，1999年2月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]Zorn，G.，“微软特定于供应商的半径属性”，RFC 2548，1999年3月。
[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月。
[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月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake 3rd，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[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月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[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月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547]Baugher，M.，Weis，B.，Hardjono，T.，和H.Harney，“解释的集团领域”，RFC 3547，2003年7月。
[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月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，2004年8月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005]Calhoun，P.，Zorn，G.，Spence，D.，和D.Mitton，“Diameter网络访问服务器应用”，RFC 4005，2005年8月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 401712005年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4067] Loughney, J., Ed., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[RFC4067]Loughney，J.，Ed.，Nakhjiri，M.，Perkins，C.，和R.Koodli，“上下文传输协议（CXTP）”，RFC4067，2005年7月。
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072]Eronen，P.，Ed.，Hiller，T.，和G.Zorn，“直径可扩展认证协议（EAP）应用”，RFC 4072，2005年8月。
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005.
[RFC4118]Yang，L.，Zerfos，P.，和E.Sadot，“无线接入点控制和供应（CAPWAP）的体系结构分类”，RFC 4118，2005年6月。
[RFC4186] Haverinen, H., Ed., and J. Salowey, Ed., "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006.
[RFC4186]Haverinen，H.，Ed.，和J.Salowey，Ed.“全球移动通信系统（GSM）用户身份模块（EAP-SIM）的可扩展认证协议方法”，RFC 4186，2006年1月。
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4187]Arkko，J.和H.Haverinen，“第三代认证和密钥协议（EAP-AKA）的可扩展认证协议方法”，RFC 4187，2006年1月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, January 2006.
[RFC4284]Adrangi，F.，Lortz，V.，Bari，F.，和P.Ernen，“可扩展身份验证协议（EAP）的身份选择提示”，RFC 4284，2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006.
[RFC4372]Adrangi，F.，Lior，A.，Korhonen，J.，和J.Loughney，“收费用户身份”，RFC 4372，2006年1月。
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", RFC 4334, February 2006.
[RFC4334]Housley，R.和T.Moore，“支持点对点协议（PPP）和无线局域网（WLAN）认证的证书扩展和属性”，RFC 4334，2006年2月。
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
[RFC4535]Harney，H.，Meth，U.，Colegrove，A.，和G.Gross，“GSAKMP：组安全关联密钥管理协议”，RFC 45352006年6月。
[RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)", RFC 4763, November 2006.
[RFC4763]Vanderveen，M.和H.Soliman，“用于共享秘密身份验证和密钥建立的可扩展身份验证协议方法（EAP-SAKE）”，RFC 4763，2006年11月。
[RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006.
[RFC4675]Congdon，P.，Sanchez，M.，和B.Aboba，“虚拟LAN和优先级支持的RADIUS属性”，RFC 4675，2006年9月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
[RFC4718]Erenen，P.和P.Hoffman，“IKEv2澄清和实施指南”，RFC 4718，2006年10月。
[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", RFC 4764, January 2007.
[RFC4764]Bersani，F.和H.Tschofenig，“EAP-PSK协议：预共享密钥可扩展认证协议（EAP）方法”，RFC 4764，2007年1月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC5176]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.，和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 51762008年1月。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
[RFC5216]Simon，D.，Aboba，B.和R.Hurst，“EAP-TLS认证协议”，RFC 5216，2008年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management", Special Publication 800-57, May 2006.
[SP800-57]国家标准与技术研究所，“密钥管理建议”，特别出版物800-57，2006年5月。
[Token] Fantacci, R., Maccari, L., Pecorella, T., and F. Frosali, "A secure and performant token-based authentication for infrastructure and mesh 802.1X networks", IEEE Conference on Computer Communications, June 2006.
[Token]Fantacci，R.，Maccari，L.，Pecorella，T.，和F.Frosali，“基础设施和mesh 802.1X网络的基于令牌的安全和性能认证”，IEEE计算机通信会议，2006年6月。
[Tokenk] Ohba, Y., Das, S., and A. Duttak, "Kerberized Handover Keying: A Media-Independent Handover Key Management Architecture", Mobiarch 2007.
[Tokenk]Ohba，Y.，Das，S.，和A.Duttak，“Kerberized切换密钥：一种媒体独立的切换密钥管理架构”，Mobiarch 2007。
Acknowledgments
致谢
Thanks to Ashwin Palekar, Charlie Kaufman, and Tim Moore of Microsoft, Jari Arkko of Ericsson, Dorothy Stanley of Aruba Networks, Bob Moskowitz of TruSecure, Jesse Walker of Intel, Joe Salowey of Cisco, and Russ Housley of Vigil Security for useful feedback.
感谢微软的Ashwin Palekar、Charlie Kaufman和Tim Moore、爱立信的Jari Arkko、阿鲁巴网络的Dorothy Stanley、TruSecure的Bob Moskowitz、英特尔的Jesse Walker、思科的Joe Salowey和Vigil Security的Russ Housley提供了有用的反馈。
Appendix A - Exported Parameters in Existing Methods
附录A-现有方法中的导出参数
This Appendix specifies Session-Id, Peer-Id, Server-Id and Key-Lifetime for EAP methods that have been published prior to this specification. Future EAP method specifications MUST include a definition of the Session-Id, Peer-Id and Server-Id (could be the null string). In the descriptions that follow, all fields comprising the Session-Id are assumed to be in network byte order.
本附录规定了在本规范之前发布的EAP方法的会话Id、对等Id、服务器Id和密钥生存期。未来的EAP方法规范必须包括会话Id、对等Id和服务器Id（可以是空字符串）的定义。在下面的描述中，假设包含会话Id的所有字段都是按网络字节顺序排列的。
EAP-Identity
EAP身份
The EAP-Identity method is defined in [RFC3748]. It does not derive keys, and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length).
EAP标识方法在[RFC3748]中定义。它不派生密钥，因此不定义会话Id。对等Id和服务器Id是空字符串（零长度）。
EAP-Notification
EAP通知
The EAP-Notification method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length).
EAP通知方法在[RFC3748]中定义。它不派生密钥，因此不定义会话Id。对等Id和服务器Id为空字符串（零长度）。
EAP-MD5-Challenge
EAP-MD5-挑战
The EAP-MD5-Challenge method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length).
[RFC3748]中定义了EAP-MD5-质询方法。它不派生密钥，因此不定义会话Id。对等Id和服务器Id为空字符串（零长度）。
EAP-GTC
EAP-GTC
The EAP-GTC method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length).
[RFC3748]中定义了EAP-GTC方法。它不派生密钥，因此不定义会话Id。对等Id和服务器Id为空字符串（零长度）。
EAP-OTP
EAP-OTP
The EAP-OTP method is defined in [RFC3748]. It does not derive keys and therefore does not define the Session-Id. The Peer-Id and Server-Id are the null string (zero length).
EAP-OTP方法在[RFC3748]中有定义。它不派生密钥，因此不定义会话Id。对等Id和服务器Id为空字符串（零长度）。
EAP-AKA
EAP-AKA
EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the concatenation of the EAP Type Code (0x17) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the AUTN field in the AT_AUTN attribute:
EAP-AKA的定义见[RFC4187]。EAP-AKA会话Id是EAP类型代码（0x17）与AT_RAND属性中RAND字段内容的串联，后跟AT_AUTN属性中AUTN字段的内容：
Session-Id = 0x17 || RAND || AUTN
会话Id=0x17 | | RAND | | AUTN
The Peer-Id is the contents of the Identity field from the AT_IDENTITY attribute, using only the Actual Identity Length octets from the beginning, however. Note that the contents are used as they are transmitted, regardless of whether the transmitted identity was a permanent, pseudonym, or fast EAP re-authentication identity. The Server-Id is the null string (zero length).
对等Id是来自AT_Identity属性的Identity字段的内容，但仅使用从一开始的实际标识长度八位字节。请注意，内容在传输时使用，而不管传输的身份是永久身份、假名还是快速EAP重新认证身份。服务器Id是空字符串（零长度）。
EAP-SIM
EAP-SIM
EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the concatenation of the EAP Type Code (0x12) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the NONCE_MT field in the AT_NONCE_MT attribute:
EAP-SIM在[RFC4186]中定义。EAP-SIM会话Id是EAP类型代码（0x12）与AT_RAND属性中的RAND字段内容的串联，后跟AT_NONCE_MT属性中的NONCE_MT字段内容：
Session-Id = 0x12 || RAND || NONCE_MT
会话Id=0x12 | | RAND | | NONCE|u MT
The Peer-Id is the contents of the Identity field from the AT_IDENTITY attribute, using only the Actual Identity Length octets from the beginning, however. Note that the contents are used as they are transmitted, regardless of whether the transmitted identity was a permanent, pseudonym, or fast EAP re-authentication identity. The Server-Id is the null string (zero length).
对等Id是来自AT_Identity属性的Identity字段的内容，但仅使用从一开始的实际标识长度八位字节。请注意，内容在传输时使用，而不管传输的身份是永久身份、假名还是快速EAP重新认证身份。服务器Id是空字符串（零长度）。
EAP-PSK
EAP-PSK
EAP-PSK is defined in [RFC4764]. The EAP-PSK Session-Id is the concatenation of the EAP Type Code (0x2F) with the peer (RAND_P) and server (RAND_S) nonces:
EAP-PSK在[RFC4764]中定义。EAP-PSK会话Id是EAP类型代码（0x2F）与对等（RAND_P）和服务器（RAND_S）nonce的串联：
Session-Id = 0x2F || RAND_P || RAND_S
会话Id=0x2F | | RAND|u P | RAND|u S
The Peer-Id is the contents of the ID_P field and the Server-Id is the contents of the ID_S field.
对等Id是Id\P字段的内容，服务器Id是Id\S字段的内容。
EAP-SAKE
EAP-SAKE
EAP-SAKE is defined in [RFC4763]. The EAP-SAKE Session-Id is the concatenation of the EAP Type Code (0x30) with the contents of the RAND_S field from the AT_RAND_S attribute, followed by the contents of the RAND_P field in the AT_RAND_P attribute:
EAP-SAKE在[RFC4763]中有定义。EAP-SAKE会话Id是EAP类型代码（0x30）与AT_RAND_S属性中RAND_S字段内容的串联，后跟AT_RAND_P属性中RAND_P字段的内容：
Session-Id = 0x30 || RAND_S || RAND_P
会话Id=0x30 | | RAND|u S | RAND|u P
Note that the EAP-SAKE Session-Id is not the same as the "Session ID" parameter chosen by the Server, which is sent in the first message, and replicated in subsequent messages. The Peer-Id is contained within the value field of the AT_PEERID attribute and the Server-Id, if available, is contained in the value field of the AT_SERVERID attribute.
请注意，EAP-SAKE会话Id与服务器选择的“会话Id”参数不同，该参数在第一条消息中发送，并在后续消息中复制。对等Id包含在AT_PEERID属性的值字段中，服务器Id（如果可用）包含在AT_SERVERID属性的值字段中。
EAP-TLS
EAP-TLS
For EAP-TLS, the Peer-Id, Server-Id and Session-Id are defined in [RFC5216].
对于EAP-TLS，对等Id、服务器Id和会话Id在[RFC5216]中定义。
Authors' Addresses
作者地址
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Dan Simon Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052
Dan Simon Microsoft Research Microsoft Corporation One Microsoft Way雷德蒙德，华盛顿州，98052
EMail: dansimon@microsoft.com
Phone: +1 425 706 6711
Fax: +1 425 936 7329
EMail: dansimon@microsoft.com
Phone: +1 425 706 6711
Fax: +1 425 936 7329
Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland
Pasi Eronen诺基亚研究中心邮政信箱407 FIN-00045诺基亚集团芬兰
EMail: pasi.eronen@nokia.com
EMail: pasi.eronen@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.