Network Working Group T. Clancy
Request for Comments: 4746 LTS
Category: Informational W. Arbaugh
UMD
November 2006
Network Working Group T. Clancy
Request for Comments: 4746 LTS
Category: Informational W. Arbaugh
UMD
November 2006
Extensible Authentication Protocol (EAP) Password Authenticated Exchange
可扩展身份验证协议（EAP）密码验证交换
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines an Extensible Authentication Protocol (EAP) method called EAP-PAX (Password Authenticated eXchange). This method is a lightweight shared-key authentication protocol with optional support for key provisioning, key management, identity protection, and authenticated data exchange.
本文档定义了一种称为EAP-PAX（密码认证交换）的可扩展认证协议（EAP）方法。此方法是一种轻量级共享密钥身份验证协议，可选支持密钥提供、密钥管理、身份保护和经过身份验证的数据交换。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Language Requirements ......................................3
1.2. Terminology ................................................3
2. Overview ........................................................5
2.1. PAX_STD Protocol ...........................................6
2.2. PAX_SEC Protocol ...........................................7
2.3. Authenticated Data Exchange ................................9
2.4. Key Derivation ............................................10
2.5. Verification Requirements .................................11
2.6. PAX Key Derivation Function ...............................12
3. Protocol Specification .........................................13
3.1. Header Specification ......................................13
3.1.1. Op-Code ............................................13
3.1.2. Flags ..............................................14
1. Introduction ....................................................2
1.1. Language Requirements ......................................3
1.2. Terminology ................................................3
2. Overview ........................................................5
2.1. PAX_STD Protocol ...........................................6
2.2. PAX_SEC Protocol ...........................................7
2.3. Authenticated Data Exchange ................................9
2.4. Key Derivation ............................................10
2.5. Verification Requirements .................................11
2.6. PAX Key Derivation Function ...............................12
3. Protocol Specification .........................................13
3.1. Header Specification ......................................13
3.1.1. Op-Code ............................................13
3.1.2. Flags ..............................................14
3.1.3. MAC ID .............................................14
3.1.4. DH Group ID ........................................14
3.1.5. Public Key ID ......................................15
3.1.6. Mandatory to Implement .............................15
3.2. Payload Formatting ........................................16
3.3. Authenticated Data Exchange (ADE) .........................18
3.4. Integrity Check Value (ICV) ...............................19
4. Security Considerations ........................................19
4.1. Server Certificates .......................................20
4.2. Server Security ...........................................20
4.3. EAP Security Claims .......................................21
4.3.1. Protected Ciphersuite Negotiation ..................21
4.3.2. Mutual Authentication ..............................21
4.3.3. Integrity Protection ...............................21
4.3.4. Replay Protection ..................................21
4.3.5. Confidentiality ....................................21
4.3.6. Key Derivation .....................................21
4.3.7. Key Strength .......................................22
4.3.8. Dictionary Attack Resistance .......................22
4.3.9. Fast Reconnect .....................................22
4.3.10. Session Independence ..............................22
4.3.11. Fragmentation .....................................23
4.3.12. Channel Binding ...................................23
4.3.13. Cryptographic Binding .............................23
4.3.14. Negotiation Attack Prevention .....................23
5. IANA Considerations ............................................23
6. Acknowledgments ................................................24
7. References .....................................................24
7.1. Normative References ......................................24
7.2. Informative References ....................................25
Appendix A. Key Generation from Passwords ........................ 27
Appendix B. Implementation Suggestions ........................... 27
B.1. WiFi Enterprise Network ................................... 27
B.2. Mobile Phone Network ...................................... 28
3.1.3. MAC ID .............................................14
3.1.4. DH Group ID ........................................14
3.1.5. Public Key ID ......................................15
3.1.6. Mandatory to Implement .............................15
3.2. Payload Formatting ........................................16
3.3. Authenticated Data Exchange (ADE) .........................18
3.4. Integrity Check Value (ICV) ...............................19
4. Security Considerations ........................................19
4.1. Server Certificates .......................................20
4.2. Server Security ...........................................20
4.3. EAP Security Claims .......................................21
4.3.1. Protected Ciphersuite Negotiation ..................21
4.3.2. Mutual Authentication ..............................21
4.3.3. Integrity Protection ...............................21
4.3.4. Replay Protection ..................................21
4.3.5. Confidentiality ....................................21
4.3.6. Key Derivation .....................................21
4.3.7. Key Strength .......................................22
4.3.8. Dictionary Attack Resistance .......................22
4.3.9. Fast Reconnect .....................................22
4.3.10. Session Independence ..............................22
4.3.11. Fragmentation .....................................23
4.3.12. Channel Binding ...................................23
4.3.13. Cryptographic Binding .............................23
4.3.14. Negotiation Attack Prevention .....................23
5. IANA Considerations ............................................23
6. Acknowledgments ................................................24
7. References .....................................................24
7.1. Normative References ......................................24
7.2. Informative References ....................................25
Appendix A. Key Generation from Passwords ........................ 27
Appendix B. Implementation Suggestions ........................... 27
B.1. WiFi Enterprise Network ................................... 27
B.2. Mobile Phone Network ...................................... 28
EAP-PAX (Password Authenticated eXchange) is an Extensible Authentication Protocol (EAP) method [RFC3748] designed for authentication using a shared key. It makes use of two separate subprotocols, PAX_STD and PAX_SEC. PAX_STD is a simple, lightweight protocol for mutual authentication using a shared key, supporting Authenticated Data Exchange (ADE). PAX_SEC complements PAX_STD by providing support for shared-key provisioning and identity protection using a server-side public key.
EAP-PAX（密码认证交换）是一种可扩展认证协议（EAP）方法[RFC3748]，设计用于使用共享密钥进行认证。它使用了两个单独的子工具，即PAX_STD和PAX_SEC。PAX_STD是一个简单、轻量级的协议，用于使用共享密钥进行相互身份验证，支持身份验证数据交换（ADE）。PAX_SEC通过使用服务器端公钥提供对共享密钥供应和身份保护的支持，对PAX_STD进行了补充。
The idea motivating EAP-PAX is a desire for device authentication bootstrapped by a simple Personal Identification Number (PIN). If a weak key is used or a expiration period has elapsed, the authentication server forces a key update. Rather than using a symmetric key exchange, the client and server perform a Diffie-Hellman key exchange, which provides forward secrecy.
激发EAP-PAX的想法是希望通过简单的个人识别码（PIN）引导设备认证。如果使用了弱密钥或过期，身份验证服务器将强制密钥更新。客户端和服务器不使用对称密钥交换，而是执行Diffie-Hellman密钥交换，这提供了前向保密性。
Since implementing a Public Key Infrastructure (PKI) can be cumbersome, PAX_SEC defines multiple client security policies, selectable based on one's threat model. In the weakest mode, PAX_SEC allows the use of raw public keys completely eliminating the need for a PKI. In the strongest mode, PAX_SEC requires that EAP servers use certificates signed by a trusted Certification Authority (CA). In the weaker modes, during provisioning PAX_SEC is vulnerable to a man-in-the-middle dictionary attack. In the strongest mode, EAP-PAX is provably secure under the Random Oracle model.
由于实现公钥基础设施（PKI）可能很麻烦，PAX_SEC定义了多个客户端安全策略，可根据个人的威胁模型进行选择。在最薄弱的模式下，PAX_SEC允许使用原始公钥，完全不需要PKI。在最强模式下，PAX_SEC要求EAP服务器使用由可信证书颁发机构（CA）签名的证书。在较弱的模式下，在配置PAX_SEC期间，PAX_SEC容易受到中间人字典攻击。在最强模式下，EAP-PAX在随机Oracle模型下是可证明安全的。
EAP-PAX supports the generation of strong key material; mutual authentication; resistance to desynchronization, dictionary, and man-in-the-middle attacks; ciphersuite extensibility with protected negotiation; identity protection; and the authenticated exchange of data, useful for implementing channel binding. These features satisfy the EAP method requirements for wireless LANs [RFC4017], making EAP-PAX ideal for wireless environments such as IEEE 802.11 [IEEE.80211].
EAP-PAX支持生成强关键材料；相互认证；抵抗去同步、字典和中间人攻击；具有受保护协商的ciphersuite可扩展性；身份保护；以及经过身份验证的数据交换，对于实现通道绑定非常有用。这些特性满足无线局域网[RFC4017]的EAP方法要求，使EAP-PAX成为无线环境（如IEEE 802.11[IEEE.80211]）的理想选择。
In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
在本文件中，使用了几个词来表示规范的要求。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section describes the various variables and functions used in the EAP-PAX protocol. They will be referenced frequently in later sections.
本节介绍EAP-PAX协议中使用的各种变量和函数。它们将在后面的章节中经常引用。
Variables:
变量：
CID User-supplied client ID, specified as a Network Access Identifier (NAI) [RFC4282], restricted to 65535 octets
CID用户提供的客户端ID，指定为网络访问标识符（NAI）[RFC4282]，限制为65535个八位字节
g public Diffie-Hellman generator, typically the integer 2 [RFC2631]
g公共Diffie-Hellman生成器，通常为整数2[RFC2631]
M 128-bit random integer generated by the server
服务器生成的M 128位随机整数
N 128-bit random integer generated by the client
N客户端生成的128位随机整数
X 256-bit random integer generated by the server
X服务器生成的256位随机整数
Y 256-bit random integer generated by the client
由客户端生成的Y 256位随机整数
Keys:
钥匙：
AK authentication key shared between the client and EAP server
客户端和EAP服务器之间共享的AK身份验证密钥
AK' new authentication key generated during a key update
AK“密钥更新期间生成的新身份验证密钥
CertPK EAP server's certificate containing public key PK
CertPK EAP服务器包含公钥PK的证书
CK Confirmation Key generated from the MK and used during authentication to prove knowledge of AK
CK确认密钥由MK生成，并在身份验证期间用于证明了解AK
EMSK Extended Master Session Key also generated from the MK and containing additional keying material
EMSK扩展主会话密钥也由MK生成，包含额外的密钥材料
IV Initialization Vector used to seed ciphers; exported to the authenticator
IV用于为密码设定种子的初始化向量；导出到验证器
MID Method ID used to construct the EAP Session ID and consequently name all the exported keys [IETF.KEY]
MID方法ID用于构造EAP会话ID，并因此命名所有导出的密钥[IETF.KEY]
MK Master Key between the client and EAP server from which all other EAP method session keys are derived
从中派生所有其他EAP方法会话密钥的客户端和EAP服务器之间的MK主密钥
MSK Master Session Key generated from the MK and exported by the EAP method to the authenticator
从MK生成并由EAP方法导出到身份验证器的MSK主会话密钥
PK EAP server's public key
PK EAP服务器的公钥
Operations:
操作：
enc_X(Y) encryption of message Y with public key X
enc_X（Y）使用公钥X加密消息Y
MAC_X(Y) keyed message authentication code computed over message Y with symmetric key X
使用对称密钥X在消息Y上计算的MAC_X（Y）密钥消息认证码
PAX-KDF-W(X, Y, Z) PAX Key Derivation Function computed using secret X, identifier Y, and seed Z, and producing W octets of output
PAX-KDF-W（X，Y，Z）使用秘密X、标识符Y和种子Z计算的PAX密钥派生函数，并生成W个八位组的输出
|| string or binary data concatenation
||字符串或二进制数据连接
The EAP framework [RFC3748] defines four basic steps that occur during the execution of an EAP conversation between client and server. The first phase, discovery, is handled by the underlying link-layer protocol. The authentication phase is defined here. The key distribution and secure association phases are handled differently depending on the underlying protocol, and are not discussed in this document.
EAP框架[RFC3748]定义了在客户端和服务器之间执行EAP会话期间发生的四个基本步骤。第一阶段，发现，由底层链路层协议处理。这里定义了身份验证阶段。密钥分发和安全关联阶段的处理方式根据基础协议的不同而有所不同，本文档中不进行讨论。
+--------+ +--------+
| | EAP-Request/Identity | |
| CLIENT |<------------------------------------| SERVER |
| | | |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-PAX (STD or SEC) | |
| |<----------------------------------->| |
| | ... ... | |
| |<----------------------------------->| |
| | | |
| | EAP-Success or EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
+--------+ +--------+
| | EAP-Request/Identity | |
| CLIENT |<------------------------------------| SERVER |
| | | |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-PAX (STD or SEC) | |
| |<----------------------------------->| |
| | ... ... | |
| |<----------------------------------->| |
| | | |
| | EAP-Success or EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 1: EAP-PAX Packet Exchanges
图1:EAP-PAX数据包交换
There are two distinct subprotocols that can be executed. The first, PAX_STD, is used during typical authentications. The second, PAX_SEC, provides more secure features such as key provisioning and identity protection.
可以执行两个不同的子程序。第一种是PAX_STD，用于典型的身份验证。第二个是PAX_SEC，它提供了更安全的功能，如密钥提供和身份保护。
PAX_STD and PAX_SEC have two modes of operation. When an AK update is being performed, the client and server exchange Diffie-Hellman exponents g^X and g^Y, which are computed modulo prime P or over an elliptic curve multiplicative group. When no update is being performed, and only session keys are being derived, X and Y are exchanged. Using Diffie-Hellman during the key update provides forward secrecy, and secure key derivation when a weak provisioned key is used.
PAX_STD和PAX_SEC有两种运行模式。在执行AK更新时，客户端和服务器交换Diffie-Hellman指数g^X和g^Y，这两个指数由模素数P或椭圆曲线乘法组计算得出。当不执行更新且仅导出会话密钥时，将交换X和Y。在密钥更新期间使用Diffie Hellman可提供前向保密性，并在使用弱配置密钥时提供安全的密钥派生。
The main deployment difference between PAX_STD and PAX_SEC is that PAX_SEC requires a server-side public key. More specifically, that means a private key known only to the server with corresponding public key being transmitted to the client during each PAX_SEC session. For every authentication, the client is required to compute computationally intensive public-key operations. PAX_STD, on the other hand, uses purely symmetric operations, other than a possible Diffie-Hellman exchange.
PAX_STD和PAX_SEC之间的主要部署区别在于PAX_SEC需要服务器端公钥。更具体地说，这意味着只有服务器知道的私钥，并且在每个PAX_SEC会话期间将相应的公钥传输给客户端。对于每个身份验证，客户端都需要计算计算密集型公钥操作。另一方面，PAX_STD使用纯对称操作，而不是可能的Diffie-Hellman交换。
Each of the protocols is now defined.
现在定义了每个协议。
PAX_STD is a simple nonce-based authentication using the strong long-term key. The client and server each exchange 256 bits of random data, which is used to seed the PAX-KDF for generation of session keys. The randomly exchanged data in the protocol differs depending on whether a key update is being performed. If no key update is being performed, then let:
PAX_STD是一种使用强长期密钥的简单的基于时态的身份验证。客户端和服务器分别交换256位随机数据，这些数据用于为PAX-KDF种子，以生成会话密钥。协议中随机交换的数据根据是否正在执行密钥更新而有所不同。如果未执行密钥更新，则让：
o A = X o B = Y o E = X || Y
o A=x0b=y0e=X | | Y
Thus, A and B are 256-bit values and E is their 512-bit concatenation. To provide forward secrecy and security, let the following be true when a key update is being performed:
因此，A和B是256位值，E是它们的512位串联。要提供前向保密性和安全性，请在执行密钥更新时满足以下条件：
o A = g^X o B = g^Y o E = g^(XY)
o A=g^X o B=g^Y o E=g^（XY）
Here A and B are Diffie-Hellman exponents whose length is determined by the Diffie-Hellman group size. The value A is data transmitted
这里A和B是Diffie-Hellman指数，其长度由Diffie-Hellman群大小决定。值A是传输的数据
from the server to the client, and B is data transmitted from the client to the server. The value E is the entropy computed by each that is used in Section 2.4 to perform key derivation.
从服务器传输到客户机，B是从客户机传输到服务器的数据。值E是由第2.4节中用于执行密钥推导的每个人计算的熵。
The full protocol is as follows:
完整协议如下：
o PAX_STD-1 : client <- server : A o PAX_STD-2 : client -> server : B, CID, MAC_CK(A, B, CID), [optional ADE] o PAX_STD-3 : client <- server : MAC_CK(B, CID), [optional ADE] o PAX-ACK : client -> server : [optional ADE]
o PAX_STD-1:客户端<-服务器：A o PAX_STD-2:客户端->服务器：B，CID，MAC_CK（A，B，CID），[可选ADE]o PAX_STD-3:客户端<-服务器：MAC_CK（B，CID），[可选ADE]o PAX-ACK:客户端->服务器：[可选ADE]
See Section 2.3 for more information on the ADE component, and Section 2.4 for the key derivation process, including derivation of CK.
有关ADE组件的更多信息，请参见第2.3节，关键推导过程，包括CK推导，请参见第2.4节。
PAX_SEC is the high-security protocol designed to provide identity protection and support for provisioning. PAX_SEC requires a server-side public key, and public-key operations for every authentication.
PAX_SEC是一种高安全性协议，旨在为资源调配提供身份保护和支持。PAX_SEC需要服务器端公钥，并且每次身份验证都需要公钥操作。
PAX_SEC can be performed with and without key update. Let A, B, and E be defined as in the previous section.
PAX_SEC可以在有和没有密钥更新的情况下执行。让A、B和E的定义如前一节所述。
The exchanges for PAX_SEC are as follows:
PAX_SEC的交易如下：
o PAX_SEC-1 : client <- server : M, PK or CertPK o PAX_SEC-2 : client -> server : Enc_PK(M, N, CID) o PAX_SEC-3 : client <- server : A, MAC_N(A, CID) o PAX_SEC-4 : client -> server : B, MAC_CK(A, B, CID), [optional ADE] o PAX_SEC-5 : client <- server : MAC_CK(B, CID), [optional ADE] o PAX-ACK : client -> server : [optional ADE]
o PAX_SEC-1:客户端<-服务器：M，PK或CertPK o PAX_SEC-2:客户端->服务器：Enc_PK（M，N，CID）o PAX_SEC-3:客户端<-服务器：A，MAC_N（A，CID）o PAX_SEC-4:客户端->服务器：B，MAC_CK（A，B，CID），[可选ADE]o PAX_SEC-5:客户端<-服务器：MAC_CK（B，CID），[可选ADE]o PAX-ACK:客户端->服务器：[可选ADE]
See Section 2.3 for more information on the ADE component, and Section 2.4 for the key derivation process, including derivation of CK.
有关ADE组件的更多信息，请参见第2.3节，关键推导过程，包括CK推导，请参见第2.4节。
Use of CertPK is optional in PAX_SEC; however, careful consideration should be given before omitting the CertPK. The following table describes the risks involved when using PAX_SEC without a certificate.
在PAX_SEC中，CertPK的使用是可选的；但是，在省略CertPK之前，应仔细考虑。下表描述了在没有证书的情况下使用PAX_SEC所涉及的风险。
Certificate | Provisioning | Identity
Mode | | Protection
==================+=====================+======================
No Certificate | MiTM offline | ID reveal attack
| dictionary attack |
------------------+---------------------+---------------------
Self-Signed | MiTM offline | ID reveal attack
Certificate | dictionary attack |
------------------+---------------------+---------------------
Certificate/PK | MiTM offline | ID reveal attack
Caching | dictionary attack | during first auth
------------------+---------------------+---------------------
CA-Signed | secure mutual | secure mutual
Certificate | authentication | authentication
Certificate | Provisioning | Identity
Mode | | Protection
==================+=====================+======================
No Certificate | MiTM offline | ID reveal attack
| dictionary attack |
------------------+---------------------+---------------------
Self-Signed | MiTM offline | ID reveal attack
Certificate | dictionary attack |
------------------+---------------------+---------------------
Certificate/PK | MiTM offline | ID reveal attack
Caching | dictionary attack | during first auth
------------------+---------------------+---------------------
CA-Signed | secure mutual | secure mutual
Certificate | authentication | authentication
Figure 2: Table of Different Security Modes
图2：不同安全模式表
When using PAX_SEC to support provisioning with a weak key, use of a CA-signed certificate is RECOMMENDED. When not using a CA-signed certificate, the initial authentication is vulnerable to an offline man-in-the-middle (MiTM) dictionary attack.
使用PAX_SEC支持使用弱密钥进行配置时，建议使用CA签名的证书。不使用CA签名的证书时，初始身份验证容易受到脱机中间人（MiTM）字典攻击。
When using PAX_SEC to support identity protection, use of either a CA-signed certificate or key caching is RECOMMENDED. Caching involves a client recording the public key of the EAP server and verifying its consistency between sessions, similar to Secure SHell (SSH) Protocol [RFC4252]. Otherwise, an attacker can spoof an EAP server during a session and gain knowledge of a client's identity.
使用PAX_SEC支持身份保护时，建议使用CA签名的证书或密钥缓存。缓存涉及客户端记录EAP服务器的公钥并验证会话之间的一致性，类似于Secure SHell（SSH）协议[RFC4252]。否则，攻击者可以在会话期间欺骗EAP服务器并获得客户机身份信息。
Whenever certificates are used, clients MUST validate that the certificate's extended key usage, KeyPurposeID, is either "eapOverPPP" or "eapOverLAN" [RFC3280][RFC4334]. If the underlying EAP transport protocol is known, then the client MUST differentiate between these values. For example, an IEEE 802.11 supplicant SHOULD require KeyPurposeID == eapOverLAN. By not distinguishing, a client could accept as valid an unauthorized server certificate.
无论何时使用证书，客户端都必须验证证书的扩展密钥用法KeyPurposeID是否为“eapOverPP”或“eapOverLAN”[RFC3280][RFC4334]。如果基础EAP传输协议已知，则客户端必须区分这些值。例如，IEEE 802.11请求者应要求KeyPurposeID==EAPOVERAN。通过不区分，客户端可以接受未经授权的服务器证书作为有效证书。
When using EAP-PAX with Wireless LAN, clients SHOULD validate that the certificate's wlanSSID extension matches the SSID of the network to which it is currently authenticating.
将EAP-PAX与无线LAN一起使用时，客户端应验证证书的wlanSSID扩展是否与其当前正在验证的网络的SSID匹配。
In order to facilitate discussion of packet validations, three client security policies for PAX_SEC are defined.
为了便于讨论数据包验证，定义了PAX_SEC的三种客户端安全策略。
open Clients support both use of PK and CertPK. If CertPK is used, the client MUST validate the KeyPurposeID.
开放客户端支持PK和CertPK的使用。如果使用CertPK，客户端必须验证KeyPurposeID。
caching Clients save PK for each EAP server the first time it encounters the server, and SHOULD NOT authenticate to EAP servers whose public key has been changed. If CertPK is used, the client MUST validate the KeyPurposeID.
缓存客户端在第一次遇到服务器时为每个EAP服务器保存PK，并且不应向其公钥已更改的EAP服务器进行身份验证。如果使用CertPK，客户端必须验证KeyPurposeID。
strict In strict mode, clients require servers to present a valid certificate signed by a trusted CA. As with the other modes, the KeyPurposeID MUST be validated.
严格在严格模式下，客户端要求服务器提供由可信CA签名的有效证书。与其他模式一样，必须验证KeyPurposeID。
Servers SHOULD support the PAX_SEC mode of operation, and SHOULD support both the use of PK and CertPK with PAX_SEC. Clients MUST support PAX_SEC, and MUST be capable of accepting both raw public keys and certificates from the server. Local security policy will define which forms of key or certificate authentications are permissible. Default configurations SHOULD require a minimum of the caching security policy, and MAY require strict.
服务器应支持PAX_SEC操作模式，并应支持在PAX_SEC中使用PK和CertPK。客户端必须支持PAX_SEC，并且必须能够接受来自服务器的原始公钥和证书。本地安全策略将定义允许的密钥或证书身份验证形式。默认配置应该至少需要缓存安全策略，并且可能需要严格的安全策略。
The ability to perform key management on the AK is built in to EAP-PAX through the use of AK'. However, key management of the server public key is beyond the scope of this document. If self-signed certificates are used, the deployers should be aware that expired certificates may be difficult to replace when the caching security mode is used.
AK-PAX内置的AK管理功能是通过EAP来执行的。但是，服务器公钥的密钥管理超出了本文档的范围。如果使用自签名证书，部署人员应该知道，在使用缓存安全模式时，过期的证书可能很难替换。
See Section 4 for further discussion on security considerations.
有关安全注意事项的进一步讨论，请参见第4节。
Messages PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and PAX_ACK contain optional component ADE. This component is used to convey authenticated data between the client and server during the authentication.
消息PAX_STD-2、PAX_STD-3、PAX_SEC-4、PAX_SEC-5和PAX_ACK包含可选组件ADE。此组件用于在身份验证期间在客户端和服务器之间传输经过身份验证的数据。
The Authenticated Data Exchanged (ADE) can be used in a variety of ways, including the implementation of channel bindings. Channel bindings allow link-layer network properties to be securely validated by the EAP client and server during the authentication session.
身份验证数据交换（ADE）可以以多种方式使用，包括通道绑定的实现。通道绑定允许EAP客户端和服务器在身份验证会话期间安全地验证链路层网络属性。
It is important to note that ADE is not encrypted, so any data included will not be confidential. However, since these packets are all protected by the Integrity Check Value (ICV), authenticity is guaranteed.
请务必注意，ADE未加密，因此包含的任何数据都不会保密。但是，由于这些数据包都受到完整性检查值（ICV）的保护，因此可以保证真实性。
The ADE element consists of an arbitrary number of subelements, each with length and type specified. If the number and size of subelements is too large, packet fragmentation will be necessary. Vendor-specific options are supported. See Section 3.3.
ADE元素由任意数量的子元素组成，每个子元素都指定了长度和类型。如果子元素的数量和大小过大，则需要数据包分段。支持特定于供应商的选项。见第3.3节。
Note that more than 1.5 round-trips may be necessary to execute a particular authenticated protocol within EAP-PAX. In this case, instead of sending an EAP-Success after receiving the PAX_ACK, the server can continue sending PAX_ACK messages with attached elements. The client responds to these PAX_ACK messages with PAX_ACK messages possibly containing more ADE elements. Such an execution could look something like the following:
请注意，在EAP-PAX中执行特定的认证协议可能需要1.5次以上的往返。在这种情况下，服务器可以继续发送带有附加元素的PAX_ACK消息，而不是在收到PAX_ACK后发送EAP Success。客户端使用可能包含更多ADE元素的PAX_ACK消息响应这些PAX_ACK消息。这样的执行可能类似于以下内容：
+--------+ +--------+
| | PAX_STD-1 | |
| |<------------------------------------| |
| | PAX_STD-2(ADE[1]) | |
| |------------------------------------>| |
| | PAX_STD-3(ADE[2]) | |
| |<------------------------------------| |
| | PAX_ACK(ADE[3]) | |
| |------------------------------------>| |
| | PAX_ACK(ADE[4]) | |
| |<------------------------------------| |
| | | |
| | ... | |
| | | |
| | PAX_ACK(ADE[i]) | |
| |------------------------------------>| |
| | PAX_ACK(ADE[i+1]) | |
| |<------------------------------------| |
| | | |
| | ... | |
| | | |
| | EAP-Success or EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
+--------+ +--------+
| | PAX_STD-1 | |
| |<------------------------------------| |
| | PAX_STD-2(ADE[1]) | |
| |------------------------------------>| |
| | PAX_STD-3(ADE[2]) | |
| |<------------------------------------| |
| | PAX_ACK(ADE[3]) | |
| |------------------------------------>| |
| | PAX_ACK(ADE[4]) | |
| |<------------------------------------| |
| | | |
| | ... | |
| | | |
| | PAX_ACK(ADE[i]) | |
| |------------------------------------>| |
| | PAX_ACK(ADE[i+1]) | |
| |<------------------------------------| |
| | | |
| | ... | |
| | | |
| | EAP-Success or EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 3: Extended Diagram of EAP-PAX Packet Exchanges
图3:EAP-PAX数据包交换扩展图
Keys are derived independently of which authentication mechanism was used. The process uses the entropy value E computed as described above. Session and authentication keys are computed as follows:
密钥独立于使用的身份验证机制而派生。该过程使用如上所述计算的熵值E。会话和身份验证密钥的计算如下：
o AK' = PAX-KDF-16(AK, "Authentication Key", E) o MK = PAX-KDF-16(AK, "Master Key", E)
o AK'=PAX-KDF-16（AK，“认证密钥”，E）o MK=PAX-KDF-16（AK，“主密钥”，E）
o CK = PAX-KDF-16(MK, "Confirmation Key", E) o ICK = PAX-KDF-16(MK, "Integrity Check Key", E) o MID = PAX-KDF-16(MK, "Method ID", E) o MSK = PAX-KDF-64(MK, "Master Session Key", E) o EMSK = PAX-KDF-64(MK, "Extended Master Session Key", E) o IV = PAX-KDF-64(0x00^16, "Initialization Vector", E)
o CK=PAX-KDF-16（MK，“确认密钥”，E）o ICK=PAX-KDF-16（MK，“完整性检查密钥”，E）o MID=PAX-KDF-16（MK，“方法ID”，E）o MSK=PAX-KDF-64（MK，“主会话密钥”，E）o EMSK=PAX-KDF-64（MK，“扩展主会话密钥”，E）o IV=PAX-KDF-64（0x00^16，“初始化向量”，E）
The IV is computed using a 16-octet NULL key. The value of AK' is only used to replace AK if a key update is being performed. The EAP Method ID is represented in ASCII as 32 hexadecimal characters without any octet delimiters such as colons or dashes.
IV使用16个八位组的空密钥计算。AK'的值仅用于在执行密钥更新时替换AK。EAP方法ID在ASCII中表示为32个十六进制字符，没有任何八位分隔符，如冒号或破折号。
The EAP Key Management Framework [IETF.KEY] recommends specification of key names and scope. The EAP-PAX Method-ID is the MID value computed as described above. The EAP peer name is the CID value exchanged in PAX_STD-2 and PAX_SEC-2. The EAP server name is an empty string.
EAP密钥管理框架[IETF.Key]建议指定密钥名称和范围。EAP-PAX方法ID是如上所述计算的中间值。EAP对等名称是在PAX_STD-2和PAX_SEC-2中交换的CID值。EAP服务器名称为空字符串。
In order for EAP-PAX to be secure, MACs must be properly verified each step of the way. Any packet with an ICV (see Section 3.4) that fails validation must be silently discarded. After ICV validation, the following checks must be performed:
为了确保EAP-PAX的安全，必须在每一步对MAC进行正确验证。任何ICV（见第3.4节）未通过验证的数据包都必须以静默方式丢弃。ICV验证后，必须进行以下检查：
PAX_STD-2 The server MUST validate the included MAC, as it serves to authenticate the client to the server. If this validation fails, the server MUST send an EAP-Failure message.
PAX_STD-2服务器必须验证包含的MAC，因为它用于向服务器验证客户端。如果验证失败，服务器必须发送EAP失败消息。
PAX_STD-3 The client MUST validate the included MAC, as it serves to authenticate the server to the client. If this validation fails, the client MUST send an EAP-Failure message.
PAX_STD-3客户端必须验证包含的MAC，因为它用于向客户端验证服务器。如果验证失败，客户端必须发送EAP失败消息。
PAX_SEC-1 The client MUST validate PK or CertPK in a manner specified by its local security policy (see Section 2.2). If this validation fails, the client MUST send an EAP-Failure message.
PAX_SEC-1客户必须按照其本地安全策略规定的方式验证PK或CertPK（见第2.2节）。如果验证失败，客户端必须发送EAP失败消息。
PAX_SEC-2 The server MUST verify that the decrypted value of M matches the value transmitted in PAX_SEC-1. If this validation fails, the server MUST send an EAP-Failure message.
PAX_SEC-2服务器必须验证解密的M值是否与PAX_SEC-1中传输的值匹配。如果验证失败，服务器必须发送EAP失败消息。
PAX_SEC-3 The client MUST validate the included MAC, as it serves to prevent replay attacks. If this validation fails, the client MUST send an EAP-Failure message.
PAX_SEC-3客户端必须验证包含的MAC，因为它用于防止重播攻击。如果验证失败，客户端必须发送EAP失败消息。
PAX_SEC-4 The server MUST validate the included MAC, as it serves to authenticate the client to the server. If this validation fails, the server MUST send an EAP-Failure message.
PAX_SEC-4服务器必须验证包含的MAC，因为它用于向服务器验证客户端。如果验证失败，服务器必须发送EAP失败消息。
PAX_SEC-5 The client MUST validate the included MAC, as it serves to authenticate the server to the client. If this validation fails, the client MUST send an EAP-Failure message.
PAX_SEC-5客户端必须验证包含的MAC，因为它用于向客户端验证服务器。如果验证失败，客户端必须发送EAP失败消息。
PAX-ACK If PAX-ACK is received in response to a message fragment, the receiver continues the protocol execution. If PAX-ACK is received in response to PAX_STD-3 or PAX_SEC-5, then the server MUST send an EAP-Success message. This indicates a successful execution of PAX.
PAX-ACK如果收到PAX-ACK以响应消息片段，则接收方继续协议执行。如果收到PAX-ACK以响应PAX_STD-3或PAX_SEC-5，则服务器必须发送EAP成功消息。这表明PAX的成功执行。
The PAX-KDF is a secure key derivation function used to generate various keys from the provided entropy and shared key.
PAX-KDF是一个安全密钥派生函数，用于根据提供的熵和共享密钥生成各种密钥。
PAX-KDF-W(X, Y, Z)
PAX-KDF-W（X，Y，Z）
W length, in octets, of the desired output X secret key used to protect the computation Y public identifier for the key being derived Z exchanged entropy used to seed the KDF
所需输出X密钥的W长度（以八位字节为单位），用于保护所导出密钥的计算Y公共标识符Z交换熵，用于为KDF种子
Let's define some variables and functions:
让我们定义一些变量和函数：
o M_i = MAC_X(Y || Z || i), where i is an 8-bit unsigned integer o L = ceiling(W/16) o F(A, B) = first A octets of binary data B
o M|i=MAC|X（Y | | Z | | i），其中i是8位无符号整数o L=F（A，B）的上限（W/16）=二进制数据B的第一个八位字节
We define PAX-KDF-W(X, Y, Z) = F(W, M_1 || M_2 || ... || M_L).
我们定义PAX-KDF-W（X，Y，Z）=F（W，M|u 1 | | M|u 2 | | | | M|L）。
Consequently for the two values of W used in this document, we have:
因此，对于本文件中使用的两个W值，我们有：
o PAX-KDF-16(X, Y, Z) = MAC_X(Y || Z || 0x01) o PAX-KDF-64(X, Y, Z) = MAC_X(Y || Z || 0x01) || MAC_X(Y || Z || 0x02) || MAC_X(Y || Z || 0x03) || MAC_X(Y || Z || 0x04)
o PAX-KDF-16（X，Y，Z）=MAC|X（Y | Z | 0x01）o PAX-KDF-64（X，Y，Z）=MAC|X（Y | Z | 0x01）| MAC|X（Y | Z | 0x02）| MAC ux（Y | Z | 0x03）| MAC ux（Y | 0x04）
The MAC used in the PRF is extensible and is the same MAC used in the rest of the protocol. It is specified in the EAP-PAX header.
PRF中使用的MAC是可扩展的，与协议其余部分中使用的MAC相同。它在EAP-PAX标题中指定。
In this section, the packet format and content for the EAP-PAX messages are defined.
在本节中，定义了EAP-PAX消息的数据包格式和内容。
EAP-PAX packets have the following structure:
EAP-PAX数据包具有以下结构：
--- bit offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | OP-Code | Flags | MAC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH Group ID | Public Key ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ICV ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- bit offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | OP-Code | Flags | MAC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH Group ID | Public Key ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ICV ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EAP-PAX Packet Structure
图4:EAP-PAX数据包结构
The Code, Identifier, Length, and Type fields are all part of the EAP header, and defined in [RFC3748]. IANA has allocated EAP Method Type 46 for EAP-PAX; thus, the Type field in the EAP header MUST be 46.
代码、标识符、长度和类型字段都是EAP标头的一部分，并在[RFC3748]中定义。IANA已为EAP-PAX分配了EAP方法类型46；因此，EAP头中的类型字段必须为46。
The OP-Code field is one of the following values:
OP Code字段是以下值之一：
o 0x01 : PAX_STD-1
o 0x02 : PAX_STD-2
o 0x03 : PAX_STD-3
o 0x11 : PAX_SEC-1
o 0x12 : PAX_SEC-2
o 0x13 : PAX_SEC-3
o 0x14 : PAX_SEC-4
o 0x01 : PAX_STD-1
o 0x02 : PAX_STD-2
o 0x03 : PAX_STD-3
o 0x11 : PAX_SEC-1
o 0x12 : PAX_SEC-2
o 0x13 : PAX_SEC-3
o 0x14 : PAX_SEC-4
o 0x15 : PAX_SEC-5 o 0x21 : PAX-ACK
o 0x15:PAX_SEC-5 o 0x21:PAX-ACK
The flags field is broken up into 8 bits each representing a binary flag. The field is defined as the Logical OR of the following values:
flags字段分为8位，每个位表示一个二进制标志。该字段定义为以下值的逻辑OR：
o 0x01 : more fragments (MF)
o 0x02 : certificate enabled (CE)
o 0x04 : ADE Included (AI)
o 0x08 - 0x80 : reserved
o 0x01 : more fragments (MF)
o 0x02 : certificate enabled (CE)
o 0x04 : ADE Included (AI)
o 0x08 - 0x80 : reserved
The MF flag is set if the current packet required fragmentation, and further fragments need to be transmitted. If a packet does not require fragmentation, the MF flag is not set.
如果当前数据包需要分段，并且需要传输更多的分段，则设置MF标志。如果数据包不需要分段，则不设置MF标志。
When a payload requires fragmentation, each fragment is transmitted, and the receiving party responds with a PAX-ACK packet for each received fragment.
当有效负载需要分段时，每个分段都会被发送，接收方会针对每个接收到的分段发送一个PAX-ACK数据包进行响应。
When using PAX_STD, the CE flag MUST be zero. When using PAX_SEC, the CE flag MUST be set if PAX_SEC-1 includes CertPK. It MUST NOT be set if PAX_SEC-1 includes PK. If CE is set in PAX_SEC-1, it MUST be set in PAX_SEC-2, PAX_SEC-3, PAX_SEC-4, and PAX_SEC-5. If either party detects an inconsistent value of the CE flag, he MUST send an EAP-Failure message and discontinue the session.
使用PAX_标准时，CE标志必须为零。使用PAX_SEC时，如果PAX_SEC-1包含CertPK，则必须设置CE标志。如果PAX_SEC-1包含PK，则不得设置该参数。如果CE设置在PAX_SEC-1中，则必须在PAX_SEC-2、PAX_SEC-3、PAX_SEC-4和PAX_SEC-5中设置。如果任何一方检测到CE标志值不一致，他必须发送EAP失败消息并中断会话。
The AI flag indicates the presence of an ADE element. AI MUST only be set on packets PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and PAX_ACK if an ADE element is included. On packets of other types, ADE elements MUST be silently discarded as they cannot be authenticated.
AI标志表示存在ADE元素。如果包含ADE元素，则只能在数据包PAX_STD-2、PAX_STD-3、PAX_SEC-4、PAX_SEC-5和PAX_ACK上设置AI。在其他类型的数据包上，ADE元素必须以静默方式丢弃，因为它们无法进行身份验证。
The MAC field specifies the cryptographic hash used to generate the keyed hash value. The following are currently supported:
MAC字段指定用于生成键控哈希值的加密哈希。目前支持以下各项：
o 0x01 : HMAC_SHA1_128 [FIPS198] [FIPS180] o 0x02 : HMAC_SHA256_128 [FIPS180]
o 0x01:HMAC_SHA1_128[FIPS198][FIPS180]o 0x02:HMAC_SHA256_128[FIPS180]
The Diffie-Hellman group field specifies the group used in the Diffie-Hellman computations. The following are currently supported:
Diffie-Hellman组字段指定Diffie-Hellman计算中使用的组。目前支持以下各项：
o 0x00 : NONE (iff not performing a key update)
o 0x01 : 2048-bit MODP Group (IANA DH Group 14) [RFC3526]
o 0x02 : 3072-bit MODP Group (IANA DH Group 15) [RFC3526]
o 0x03 : NIST ECC Group P-256 [FIPS186]
o 0x00 : NONE (iff not performing a key update)
o 0x01 : 2048-bit MODP Group (IANA DH Group 14) [RFC3526]
o 0x02 : 3072-bit MODP Group (IANA DH Group 15) [RFC3526]
o 0x03 : NIST ECC Group P-256 [FIPS186]
If no key update is being performed, the DH Group ID field MUST be zero. Otherwise, the DH Group ID field MUST NOT be zero.
如果未执行密钥更新，则DH组ID字段必须为零。否则，DH组ID字段不能为零。
The Public Key ID field specifies the cipher used to encrypt the client's EAP-Response in PAX_SEC-2.
公钥ID字段指定用于加密PAX_SEC-2中客户端EAP响应的密码。
The following are currently supported:
目前支持以下各项：
o 0x00 : NONE (if using PAX_STD)
o 0x01 : RSAES-OAEP [RFC3447]
o 0x02 : RSA-PKCS1-V1_5 [RFC3447]
o 0x03 : El-Gamal Over NIST ECC Group P-256 [FIPS186]
o 0x00 : NONE (if using PAX_STD)
o 0x01 : RSAES-OAEP [RFC3447]
o 0x02 : RSA-PKCS1-V1_5 [RFC3447]
o 0x03 : El-Gamal Over NIST ECC Group P-256 [FIPS186]
If PAX_STD is being executed, the Public Key ID field MUST be zero. If PAX_SEC is being executed, the Public Key ID field MUST NOT be zero.
如果正在执行PAX_STD，则公钥ID字段必须为零。如果正在执行PAX_SEC，则公钥ID字段不得为零。
When using RSAES-OAEP, the hash algorithm and mask generation algorithm used SHALL be the MAC specified by the MAC ID, keyed using an all-zero key. The label SHALL be null.
当使用RSAES-OAEP时，使用的哈希算法和掩码生成算法应为MAC ID指定的MAC，并使用全零密钥进行键控。标签应为空。
The RSA-based schemes specified here do not dictate the length of the public keys. DER encoding rules will specify the key size in the key or certificate [X.690]. Key sizes SHOULD be used that reflect the desired level of security.
此处指定的基于RSA的方案不指定公钥的长度。DER编码规则将指定密钥或证书中的密钥大小[X.690]。应使用反映所需安全级别的密钥大小。
The following ciphersuite is mandatory to implement and achieves roughly 112 bits of security:
以下密码套件是实现和实现大约112位安全性所必需的：
o HMAC_SHA1_128 o IANA DH Group 14 (2048 bits) o RSA-PKCS1-V1_5 (RECOMMEND 2048-bit public key)
o HMAC_SHA1_128 o IANA DH组14（2048位）o RSA-PKCS1-V1_5（建议使用2048位公钥）
The following ciphersuite is RECOMMENDED and achieves 128 bits of security:
建议使用以下密码套件并实现128位的安全性：
o HMAC_SHA256_128 o IANA DH Group 15 (3072 bits) o RSAES-OAEP (RECOMMEND 3072-bit public key)
o HMAC_SHA256_128 o IANA DH组15（3072位）o RSAES-OAEP（推荐3072位公钥）
This section describes how to format the payload field. Depending on the packet type, different values are transmitted. Sections 2.1 and 2.2 define the fields, and in what order they are to be concatenated. For simplicity and since many field lengths can vary with the ciphersuite, each value is prepended with a 2-octet length value encoded as an integer as described below. This length field MUST equal the length in octets of the subsequent value field.
本节介绍如何格式化有效负载字段。根据数据包类型，传输不同的值。第2.1节和第2.2节定义了字段，以及字段的连接顺序。为简单起见，由于许多字段长度可能随密码套件的不同而变化，因此每个值前面都有一个编码为整数的2-octet长度值，如下所述。此长度字段必须等于后续值字段的长度（以八位字节为单位）。
--- octet offset --->
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---------------------
|len| value ....
+---+--------
--- octet offset --->
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---------------------
|len| value ....
+---+--------
Figure 5: Length Encoding for Data Elements
图5：数据元素的长度编码
All integer values are stored as octet arrays in network-byte order, with the most significant octet first. Integers are padded on the most significant end to reach octet boundaries.
所有整数值都以网络字节顺序存储为八位字节数组，最重要的八位字节排在第一位。整数填充在最有效的一端，以达到八位字节边界。
Public keys and certificates SHALL be in X.509 format [RFC3280] encoded using the Distinguished Encoding Rules (DER) format [X.690].
公钥和证书应采用X.509格式[RFC3280]，并使用可分辨编码规则（DER）格式[X.690]进行编码。
Strings are not null-terminated and are encoded using UTF-8. Binary data, such as message authentication codes, are transmitted as-is.
字符串不以null结尾，并使用UTF-8编码。二进制数据（如消息身份验证码）按原样传输。
MACs are computed by concatenating the specified values in the specified order. Note that for MACs, length fields are not included, though the resulting MAC will itself have a length field. Values are encoded as described above, except that no length field is specified.
MAC是通过按指定顺序连接指定值来计算的。请注意，对于MAC，不包括长度字段，尽管生成的MAC本身将有一个长度字段。值的编码如上所述，但未指定长度字段。
To illustrate this process, an example is presented. What follows is the encoding of the payload for PAX_STD-2. The three basic steps will be computing the MAC, forming the payload, and encrypting the payload.
为了说明这个过程，给出了一个例子。下面是PAX_STD-2的有效载荷编码。这三个基本步骤将是计算MAC、形成有效负载和加密有效负载。
To create the MAC, we first need to form the buffer that will be MACed. For this example, assume that no key update is being done and HMAC_SHA1_128 is used such that the result will be a 16-octet value.
要创建MAC，我们首先需要形成缓冲区，缓冲区将被浸渍。对于本例，假设没有进行密钥更新，并且使用HMAC_SHA1_128，结果将是16个八位组的值。
--- octet offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-octet integer A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-octet integer B |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... variable length CID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- octet offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-octet integer A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-octet integer B |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... variable length CID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
||
||
CK --> MAC
||
\/
||
||
CK --> MAC
||
\/
--- octet offset --->
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-octet MAC output |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- octet offset --->
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-octet MAC output |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example Encoding of PAX_STD-2 MAC Data
图6:PAX_STD-2 MAC数据编码示例
With this, we can now create the encoded payload:
有了它，我们现在可以创建编码的有效负载：
--- octet offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|32 | 32-octet integer B
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L | |
+-+-+-+-+ +
| |
... L-octet CID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|16 | MAC computed above |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- octet offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|32 | 32-octet integer B
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L | |
+-+-+-+-+ +
| |
... L-octet CID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|16 | MAC computed above |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Example Encoding of PAX_STD-2 Packet
图7:PAX_STD-2数据包编码示例
These 52+L octets are then attached to the packet as the payload. The ICV is then computed by MACing the packet headers and payload, and appended after the payload (see Section 3.4).
然后将这些52+L八位字节作为有效负载连接到数据包。然后，通过标记数据包头和有效载荷来计算ICV，并附加在有效载荷之后（参见第3.4节）。
This section describes the formatting of the ADE elements. ADE elements can only occur on packets of type PAX_STD-2, PAX_STD-3, PAX_SEC-4, PAX_SEC-5, and PAX_ACK. Values included in other packets MUST be silently ignored.
本节介绍ADE元素的格式。ADE元素只能出现在PAX_STD-2、PAX_STD-3、PAX_SEC-4、PAX_SEC-5和PAX_ACK类型的数据包上。必须以静默方式忽略其他数据包中包含的值。
The ADE element is preceded by its 2-octet length L. Each subelement has first a 2-octet length Li followed by a 2-octet type Ti. The entire ADE element looks as follows:
ADE元素的前面是其2-八位组长度L。每个子元素首先有一个2-八位组长度Li，然后是一个2-八位组类型Ti。整个ADE元素如下所示：
--- octet offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L |L1 |T1 | |
+-+-+-+-+-+-+ +
| |
... subADE-1, type T1, length L1 ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |L2 |T2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... subADE-2, type T2, length L2 ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | more subADE elements... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- octet offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L |L1 |T1 | |
+-+-+-+-+-+-+ +
| |
... subADE-1, type T1, length L1 ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |L2 |T2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... subADE-2, type T2, length L2 ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | more subADE elements... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Encoding of ADE Components
图8:ADE组件的编码
The following type values have been allocated:
已分配以下类型值：
o 0x01 : Vendor Specific o 0x02 : Client Channel Binding Data o 0x03 : Server Channel Binding Data
o 0x01:特定于供应商的o 0x02:客户端通道绑定数据o 0x03:服务器通道绑定数据
The first three octets of a subADE utilizing type code 0x01 must be the vendor's Enterprise Number [RFC3232] as registered with IANA. The format for such a subADE is as follows:
使用类型代码0x01的子节点的前三个八位字节必须是在IANA注册的供应商企业编号[RFC3232]。此类子节点的格式如下所示：
--- octet offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Li | 1 | ENi | |
+-+-+-+-+-+-+-+ +
| |
... subADE-i, type Vendor Specific, length Li, vendor ENi ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--- octet offset --->
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Li | 1 | ENi | |
+-+-+-+-+-+-+-+ +
| |
... subADE-i, type Vendor Specific, length Li, vendor ENi ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Encoding of Vendor-specific ADE
图9：供应商特定ADE的编码
Channel binding subADEs have yet to be defined. Future IETF documents will specify the format for these subADE fields.
通道绑定子节点尚未定义。未来的IETF文件将指定这些子节点字段的格式。
The ICV is computed as the MAC over the entire EAP packet, including the EAP header, the EAP-PAX header, and the EAP-PAX payload. The MAC is keyed using the 16-octet ICK, using the MAC type specified by the MAC ID in the EAP-PAX header. For packets of type PAX_STD-1, PAX_SEC-1, PAX_SEC-2, and PAX_SEC-3, where the MK has not yet been derived, the MAC is keyed using a zero-octet NULL key.
ICV被计算为整个EAP分组上的MAC，包括EAP报头、EAP-PAX报头和EAP-PAX有效载荷。使用EAP-PAX报头中MAC ID指定的MAC类型，使用16个八位组ICK键控MAC。对于尚未导出MK的PAX_STD-1、PAX_SEC-1、PAX_SEC-2和PAX_SEC-3类型的数据包，使用零八位组空密钥对MAC进行键控。
If the ICV field is incorrect, the receiver MUST silently discard the packet.
如果ICV字段不正确，则接收方必须无声地丢弃数据包。
Any authentication protocol, especially one geared for wireless environments, must assume that adversaries have many capabilities. In general, one must assume that all messages between the client and server are delivered via the adversary. This allows passive attackers to eavesdrop on all traffic, while active attackers can modify data in any way before delivery.
任何认证协议，尤其是针对无线环境的认证协议，都必须假设对手具有多种能力。通常，必须假设客户端和服务器之间的所有消息都是通过对手传递的。这使得被动攻击者能够窃听所有通信量，而主动攻击者可以在传输前以任何方式修改数据。
In this section, we discuss the security properties and requirements of EAP-PAX with respect to this threat model. Also note that the security of PAX can be proved using under the Random Oracle model.
在本节中，我们将讨论EAP-PAX关于此威胁模型的安全属性和要求。使用Oracle的随机模型也可以证明PAX的安全性。
PAX_SEC can be used in several configurations. It can be used with or without a server-side certificate. Section 2.2 details the possible modes and the resulting security risk.
PAX_SEC可用于多种配置。它可以与服务器端证书一起使用，也可以不与服务器端证书一起使用。第2.2节详细说明了可能的模式和由此产生的安全风险。
When using PAX_SEC for identity protection and not using a CA-signed certificate, an attacker can convince a client to reveal his username. To achieve this, an attacker can simply forge a PAX_SEC-1 message and send it to the client. The client would respond with a PAX_SEC-2 message containing his encrypted username. The attacker can then use his associated private key to decrypt the client's username. Use of key caching can reduce the risk of identity revelation by allowing clients to detect when the EAP server to which they are accustom has a different public key.
当使用PAX_SEC进行身份保护而不使用CA签名的证书时，攻击者可以说服客户端显示其用户名。为此，攻击者只需伪造PAX_SEC-1消息并将其发送给客户端即可。客户将以包含其加密用户名的PAX_SEC-2消息进行响应。然后，攻击者可以使用其关联的私钥解密客户端的用户名。使用密钥缓存可以通过允许客户端检测他们所习惯的EAP服务器何时具有不同的公钥来降低身份泄露的风险。
When provisioning with PAX_SEC and not using a CA-signed certificate, an attacker could first forge a PAX_SEC-1 message and send it to the client. The client would respond with a PAX_SEC-2 message. Using the decrypted value of N, an attacker could forge a PAX_SEC-3 message. Once the client responds with a PAX_SEC-4 message, an attacker can guess values of the weak AK and compute CK = PAX-KDF(AK, "Confirmation Key", g^XY). Given enough time, the attacker can obtain both the old AK and new AK' and forge a responding PAX_SEC-5.
当使用PAX_SEC进行配置而不使用CA签名的证书时，攻击者可以首先伪造PAX_SEC-1消息并将其发送给客户端。客户将以PAX_SEC-2消息回应。使用解密值N，攻击者可以伪造PAX_SEC-3消息。一旦客户端响应PAX_SEC-4消息，攻击者就可以猜测弱AK的值并计算CK=PAX-KDF（AK，“确认键”，g^XY）。如果有足够的时间，攻击者可以获得旧AK和新AK，并伪造一个响应PAX_SEC-5。
In order to maintain a reasonable security policy, the server should manage five pieces of information concerning each user, most obviously, the username and current key. In addition, the server must keep a bit that indicates whether the current key is weak. Weak keys must be updated prior to key derivation. Also, the server should track the date of last key update. To implement the coarse-grained forward secrecy, the authentication key must be updated on a regular basis, and this field can be used to expire keys. Last, the server should track the previous key, to prevent attacks where an adversary desynchronizes the key state by interfering with PAX-ACK packets. See Appendix B for more suggested implementation strategies that prevent key desynchronization attacks.
为了维护合理的安全策略，服务器应该管理关于每个用户的五条信息，最明显的是用户名和当前密钥。此外，服务器必须保留一个指示当前密钥是否弱的位。弱密钥必须在密钥派生之前更新。此外，服务器应跟踪上次密钥更新的日期。为了实现粗粒度的前向保密，必须定期更新身份验证密钥，并且此字段可用于使密钥过期。最后，服务器应跟踪上一个密钥，以防止攻击者通过干扰PAX-ACK数据包来取消密钥状态同步的攻击。有关防止密钥去同步攻击的更多建议实施策略，请参见附录B。
Since the client keys are stored in plaintext on the server, special care should be given to the overall security of the authentication server. An operating system-level attack yielding root access to an intruder would result in the compromise of all client credentials.
由于客户端密钥以明文形式存储在服务器上，因此应特别注意身份验证服务器的整体安全性。允许入侵者进行root访问的操作系统级攻击将导致所有客户端凭据受损。
This section describes EAP-PAX in terms of specific security terminology as required by [RFC3748].
本节根据[RFC3748]要求的特定安全术语描述EAP-PAX。
In the initial packet from the server, the server specifies the ciphersuite in the packet header. The server is in total control of the ciphersuite; thus, a client not supporting the specified ciphersuite will not be able to authenticate. In addition, each client's local security policy should specify secure ciphersuites the client will accept. The ciphersuite specified in PAX_STD-1 and PAX_SEC-1 MUST remain the same in successive packets within the same authentication session. Since later packets are covered by an ICV keyed with the ICK, the server can verify that the originally transmitted ciphersuite was not altered by an adversary.
在来自服务器的初始数据包中，服务器在数据包头中指定密码套件。服务器完全控制密码套件；因此，不支持指定密码套件的客户端将无法进行身份验证。此外，每个客户端的本地安全策略应指定客户端将接受的安全密码套件。PAX_STD-1和PAX_SEC-1中指定的密码套件在同一身份验证会话中的连续数据包中必须保持相同。由于后来的数据包由ICK键控的ICV覆盖，服务器可以验证最初传输的密码套件是否未被对手更改。
Both PAX_STD and PAX_SEC authenticate the client and the server, and consequently achieve explicit mutual authentication.
PAX_STD和PAX_SEC都对客户端和服务器进行身份验证，从而实现显式的相互身份验证。
The ICV described in Section 3.4 provides integrity protection once the integrity check key has been derived. The header values in the unprotected packets can be verified when an ICV is received later in the session.
第3.4节中描述的ICV在完整性检查密钥导出后提供完整性保护。在会话稍后接收到ICV时，可以验证未受保护数据包中的报头值。
EAP-PAX is inherently designed to avoid replay attacks by cryptographically binding each packet to the previous one. Also the EAP sequence number is covered by the ICV to further strengthen resistance to replay attacks.
EAP-PAX固有的设计目的是通过加密方式将每个数据包绑定到前一个数据包来避免重播攻击。ICV还覆盖了EAP序列号，以进一步增强对重播攻击的抵抗力。
With identity protection enabled, PAX_SEC provides full confidentiality.
启用身份保护后，PAX_SEC将提供完全保密性。
Session keys are derived using the PAX-KDF and fresh entropy supplied by both the client and the server. Since the key hierarchy is derived from the shared password, only someone with knowledge of that password or the capability of guessing it is capable of deriving the
会话密钥是使用客户端和服务器提供的PAX-KDF和新鲜熵导出的。由于密钥层次结构是从共享密码派生的，因此只有了解该密码或能够猜出该密码的人才能派生密钥层次结构
session keys. One of the main benefits of PAX_SEC is that it allows you to bootstrap a strong shared secret using a weak password while preventing offline dictionary attacks.
会话密钥。PAX_SEC的主要好处之一是，它允许您使用弱密码引导强共享秘密，同时防止脱机字典攻击。
Authentication keys are 128 bits. The key generation is protected by a Diffie-Hellman key exchange. It is believed that a 3000-bit MODP public-key scheme is roughly equivalent [RFC3766] to a 128-bit symmetric-key scheme. Consequently, EAP-PAX requires the use of a Diffie-Hellman group with modulus larger than 3000. Also, the exponent used as the private DH parameter must be at least twice as large as the key eventually generated. Consequently, EAP-PAX uses 256-bit DH exponents. Thus, the authentication keys contain the full 128 bits of security.
身份验证密钥为128位。密钥生成由Diffie-Hellman密钥交换保护。据信，3000位MODP公钥方案大致相当于[RFC3766]128位对称密钥方案。因此，EAP-PAX需要使用模量大于3000的Diffie-Hellman群。此外，用作私有DH参数的指数必须至少是最终生成的密钥的两倍大。因此，EAP-PAX使用256位DH指数。因此，认证密钥包含完整的128位安全性。
Future ciphersuites defined for EAP-PAX MUST contain a minimum of 128 bits of security.
为EAP-PAX定义的未来密码套件必须至少包含128位安全性。
EAP-PAX is resistant to dictionary attacks, except for the case where a weak password is initially used and the server is not using a certificate for authentication. See Section 4.1 for more information on resistance to dictionary attacks.
EAP-PAX可抵抗字典攻击，但初始使用弱密码且服务器未使用证书进行身份验证的情况除外。有关抵抗字典攻击的更多信息，请参见第4.1节。
Although a specific fast reconnection option is not included, execution of PAX_STD requires very little computation time and is therefore bound primarily by the latency of the Authentication, Authorization, and Accounting (AAA) server.
尽管不包括特定的快速重新连接选项，但PAX_STD的执行只需要很少的计算时间，因此主要受身份验证、授权和计费（AAA）服务器的延迟限制。
This protocol easily achieves backward secrecy through, among other things, use of the PAX-KDF. Given a current session key, attackers can discover neither the entropy used to generate it nor the key used to encrypt that entropy as it was transmitted across the network.
该协议通过使用PAX-KDF等方式轻松实现后向保密。给定当前会话密钥，攻击者既不能发现用于生成该密钥的熵，也不能发现用于加密该熵的密钥，因为该熵是通过网络传输的。
This protocol has coarse-grained forward secrecy. Compromised session keys are only useful on data for that session, and one cannot derive AK from them. If an attacker can discover AK, that value can only be used to compromise session keys derived using that AK. Reasonably frequent password updates will help mitigate such attacks.
该协议具有粗粒度的前向保密性。泄露的会话密钥仅对该会话的数据有用，不能从中派生AK。如果攻击者能够发现AK，则该值只能用于泄露使用该AK派生的会话密钥。合理频繁的密码更新将有助于缓解此类攻击。
Session keys are independently generated using fresh nonces for each session, and therefore the sessions are independent.
会话密钥是使用每个会话的新nonce独立生成的，因此会话是独立的。
Fragmentation and reassembly is supported through the fragmentation flag in the header.
通过标头中的分段标志支持分段和重新组装。
EAP-PAX can be extended to support channel bindings through the use of its subADE fields.
EAP-PAX可以通过使用其子节点字段进行扩展以支持通道绑定。
EAP-PAX does not include any cryptographic binding. This is relevant only for tunneled methods.
EAP-PAX不包括任何加密绑定。这仅与隧道方法相关。
EAP is susceptible to an attack where an attacker uses NAKs to convince an EAP client and server to use a less secure method, and can be prevented using method-specific integrity protection on NAK messages. Since EAP-PAX does not have suitable keys derived for this integrity protection at the beginning of a PAX conversation, this is not included.
EAP容易受到攻击者使用NAK说服EAP客户端和服务器使用不太安全的方法的攻击，并且可以通过对NAK消息使用特定于方法的完整性保护来防止这种攻击。由于EAP-PAX在PAX对话开始时没有为此完整性保护派生的合适密钥，因此不包括此项。
This document requires IANA to maintain the namespace for the following header fields: MAC ID, DH Group ID, Public Key ID, and ADE type. The initial namespace populations are as follows.
本文档要求IANA维护以下标题字段的名称空间：MAC ID、DH组ID、公钥ID和ADE类型。初始命名空间填充如下所示。
MAC ID Namespace:
MAC ID命名空间：
o 0x01 : HMAC_SHA1_128 o 0x02 : HMAC_SHA256_128
o 0x01:HMAC_SHA1_128 o 0x02:HMAC_SHA256_128
DH Group ID Namespace:
DH组ID命名空间：
o 0x00 : NONE
o 0x01 : IANA DH Group 14
o 0x02 : IANA DH Group 15
o 0x03 : NIST ECC Group P-256
o 0x00 : NONE
o 0x01 : IANA DH Group 14
o 0x02 : IANA DH Group 15
o 0x03 : NIST ECC Group P-256
Public Key ID Namespace:
公钥ID命名空间：
o 0x00 : NONE
o 0x01 : RSAES-OAEP
o 0x02 : RSA-PKCS1-V1_5
o 0x03 : El-Gamal Over NIST ECC Group P-256
o 0x00 : NONE
o 0x01 : RSAES-OAEP
o 0x02 : RSA-PKCS1-V1_5
o 0x03 : El-Gamal Over NIST ECC Group P-256
ADE Type Namespace:
ADE类型命名空间：
o 0x01 : Vendor Specific o 0x02 : Client Channel Binding Data o 0x03 : Server Channel Binding Data
o 0x01:特定于供应商的o 0x02:客户端通道绑定数据o 0x03:服务器通道绑定数据
Allocation of values for these namespaces shall be reviewed by a Designated Expert appointed by the IESG. The Designated Expert will post a request to the EAP WG mailing list (or a successor designated by the Designated Expert) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision to the EAP WG mailing list or its successor, as well as informing IANA. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable.
这些名称空间的值分配应由IESG指定的专家审查。指定专家将向EAP工作组邮件列表（或指定专家指定的继任者）发出请求，征求意见和审查，包括互联网草案。在30天内，指定专家将批准或拒绝注册请求，并向EAP工作组邮件列表或其继任者发布决定通知，同时通知IANA。拒绝通知必须有理由作出解释，并在可能的情况下，就如何修改请求以使其成为可接受的请求提出具体建议。
The authors would like to thank Jonathan Katz for discussion with respect to provable security, Bernard Aboba for technical guidance, Jari Arkko for his expert review, and Florent Bersani for feedback and suggestions. Finally, the authors would like to thank the Defense Information Systems Agency for initially funding this work.
作者要感谢Jonathan Katz关于可证明安全性的讨论、Bernard Aboba的技术指导、Jari Arkko的专家评论以及Florent Bersani的反馈和建议。最后，作者要感谢国防信息系统局最初资助这项工作。
[FIPS180] National Institute for Standards and Technology, "Secure Hash Standard", Federal Information Processing Standard 180-2, August 2002.
[FIPS180]国家标准和技术研究所，“安全哈希标准”，联邦信息处理标准180-2，2002年8月。
[FIPS186] National Institute for Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standard 186, May 1994.
[FIPS186]国家标准与技术研究所，“数字签名标准（DSS）”，联邦信息处理标准186，1994年5月。
[FIPS198] National Institute for Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", Federal Information Processing Standard 198, March 2002.
[FIPS198]国家标准与技术研究所，“密钥散列消息认证码（HMAC）”，联邦信息处理标准198，2002年3月。
[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月。
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232]Reynolds，J.，“分配号码：RFC 1700被在线数据库取代”，RFC 3232，2002年1月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman群”，RFC 3526，2003年5月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[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月。
[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月。
[X.690] International Telecommunications Union, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", Data Networks and Open System Communication Recommendation X.690, July 2002.
[X.690]国际电信联盟，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，数据网络和开放系统通信建议X.690，2002年7月。
[IETF.KEY] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. Levkowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress.
[IETF.KEY]Aboba，B.，Simon，D.，Arkko，J.，Eronen，P.，和H.Levkowetz，“可扩展认证协议（EAP）密钥管理框架”，正在进行中。
[IEEE.80211] 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-1997, 1997.
[IEEE.80211]电气和电子工程师协会，“信息技术-系统间的电信和信息交换-局域网和城域网-特定要求第11部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.11-1997，1997。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631]Rescorla，E.，“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[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月。
[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月。
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[RFC4252]Ylonen，T.和C.Lonvick，“安全外壳（SSH）认证协议”，RFC 4252，2006年1月。
If a 128-bit key is not available to bootstrap the authentication process, then one must be generated from some sort of weak preshared key. Note that the security of the hashing process is unimportant, as long as it does not significantly decrease the password's entropy. Resistance to dictionary attacks is provided by PAX_SEC. Consequently, computing the SHA-1 of the password and truncating the output to 128 bits is RECOMMENDED as a means of converting a weak password to a key for provisioning.
如果无法使用128位密钥引导身份验证过程，则必须从某种弱预共享密钥生成一个密钥。请注意，哈希过程的安全性并不重要，只要它不会显著降低密码的熵。PAX_SEC提供对字典攻击的抵抗能力。因此，建议计算密码的SHA-1并将输出截断为128位，作为将弱密码转换为密钥以进行配置的一种方法。
When using other preshared credentials, such as a Kerberos Data Encryption Standard (DES) key, or an MD4-hashed Microsoft Challenge Handshake Authentication Protocol (MSCHAP) password, to provision clients, these keys SHOULD still be put through SHA-1 before being used. This serves to protect the credentials from possible compromise, and also keeps things uniform. As an example, consider provisioning using an existing Kerberos credential. The initial key computation could be SHA1_128(string2key(password)). The KDC, storing string2key(password), would also be able to compute this initial key value.
当使用其他预共享凭据（如Kerberos数据加密标准（DES）密钥或MD4哈希Microsoft质询握手身份验证协议（MSCHAP）密码）来配置客户端时，这些密钥在使用前仍应通过SHA-1。这有助于保护凭据不受可能的危害，并保持一致性。例如，考虑使用现有的Kerberos凭据进行配置。初始密钥计算可以是SHA1_128（string2key（password））。存储string2key（密码）的KDC也能够计算这个初始键值。
In this section, two implementation strategies are discussed. The first describes how best to implement and deploy EAP-PAX in an enterprise network for IEEE 802.11i authentication. The second describes how to use EAP-PAX for device authentication in a 3G-style mobile phone network.
在本节中，将讨论两种实现策略。第一部分描述了如何在企业网络中实现和部署EAP-PAX以实现IEEE 802.11i认证。第二部分描述了如何在3G风格的移动电话网络中使用EAP-PAX进行设备认证。
For the purposes of this section, a wireless enterprise network is defined to have the following characteristics:
在本节中，无线企业网络定义为具有以下特征：
o Users wish to obtain network access through IEEE 802.11 access points.
o 用户希望通过IEEE 802.11接入点获得网络接入。
o Users can possibly have multiple devices (laptops, PDAs, etc.) they wish to authenticate.
o 用户可能有多个设备（笔记本电脑、PDA等）要进行身份验证。
o A preexisting authentication framework already exists, for example, a Microsoft Active Directory domain or a Kerberos realm.
o 现有的身份验证框架已经存在，例如，Microsoft Active Directory域或Kerberos域。
Two of the biggest challenges in an enterprise WiFi network is key provisioning and support for multiple devices. Consequently, it is recommended that the client's Network Access Identifier (NAI) have
企业WiFi网络面临的两个最大挑战是关键的资源调配和对多个设备的支持。因此，建议客户端的网络访问标识符（NAI）具有
the format username/KID@realm, where KID is a key ID that can be used to distinguish between different devices.
用户名的格式/KID@realm，其中KID是可用于区分不同设备的密钥ID。
The client's supplicant can use a variety of sources to automatically generate the KID. Two of the better choices would likely be the computer's NETBIOS name, or local Ethernet adapter's MAC address. The wireless adapter's address may be a suboptimal choice, as the user may only have one PCCARD adapter for multiple systems.
客户的请求者可以使用各种来源自动生成KID。其中两个更好的选择可能是计算机的NETBIOS名称或本地以太网适配器的MAC地址。无线适配器的地址可能是次优选择，因为对于多个系统，用户可能只有一个PCCARD适配器。
With an authentication system already in place, there is a natural choice for the provisioned key. Clients can authenticate using their preexisting password. When the server is presented with a new KID, it can create a new key record on the server and use the user's current password as the provisioned key. For example, for Active Directory, the supplicant could use Microsoft's NtPasswordHash function to generate a key verifiable by the server. It is suggested that this key then be fed through SHA1_128 before being used in a non-Microsoft authentication protocol.
在认证系统已经就位的情况下，自然可以选择提供的密钥。客户端可以使用其预先存在的密码进行身份验证。当服务器显示一个新的KID时，它可以在服务器上创建一个新的密钥记录，并使用用户的当前密码作为配置的密钥。例如，对于Active Directory，请求者可以使用Microsoft的NtPasswordHash函数生成可由服务器验证的密钥。建议在用于非Microsoft身份验证协议之前，先通过SHA1_128提供此密钥。
After a key update, the server should keep track of both the old and new authentication keys. When two keys exist, the server should attempt to use both to validate the MACs on transmitted packets. Once a client successfully authenticates using the new key, the server should discard the old key. This prevents desynchronization attacks.
密钥更新后，服务器应跟踪新旧身份验证密钥。当存在两个密钥时，服务器应尝试使用这两个密钥来验证传输数据包上的MAC。一旦客户端成功使用新密钥进行身份验证，服务器应丢弃旧密钥。这可以防止去同步攻击。
In a mobile phone system, we no longer need to worry about supporting multiple keys per identity. Presumably, each mobile device has a unique identity. However, if multiple devices per identity are desired, a method similar to that presented in Section B.1 could be used.
在移动电话系统中，我们不再需要担心每个身份支持多个密钥。据推测，每个移动设备都有一个唯一的标识。但是，如果每个标识需要多个设备，则可以使用类似于第B.1节所述的方法。
Provisioning could easily be accomplished by issuing customers a 6- digit PIN they could type into their phone's keypad.
通过向客户发放一个6位PIN码，他们可以在手机键盘上输入，就可以很容易地实现资源调配。
Authors' Addresses
作者地址
T. Charles Clancy DoD Laboratory for Telecommunications Sciences 8080 Greenmeade Drive College Park, MD 20740 USA
T.Charles Clancy国防部电信科学实验室8080美国马里兰州格林米德大道学院公园20740
EMail: clancy@ltsnet.net
EMail: clancy@ltsnet.net
William A. Arbaugh University of Maryland Department of Computer Science College Park, MD 20742 USA
威廉·A·阿博马里兰大学MD分校计算机科学系，美国20742
EMail: waa@cs.umd.edu
EMail: waa@cs.umd.edu
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。