Network Working Group M. Nystroem
Request for Comments: 4793 RSA Security
Category: Informational February 2007
Network Working Group M. Nystroem
Request for Comments: 4793 RSA Security
Category: Informational February 2007
The EAP Protected One-Time Password Protocol (EAP-POTP)
受EAP保护的一次性密码协议（EAP-POTP）
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes a general Extensible Authentication Protocol (EAP) method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens with direct electronic interfaces to their associated clients. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet Key Exchange Protocol Version 2 (IKEv2).
本文档描述了一种适用于一次性密码（OTP）令牌的通用可扩展身份验证协议（EAP）方法，并为具有直接电子接口的令牌及其相关客户端提供了特殊优势。该方法可用于在利用EAP的协议（例如PPP、IEEE 802.1X和Internet密钥交换协议版本2（IKEv2））中提供单边或相互认证以及密钥材料。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Background .................................................4
1.3. Rationale behind the Design ................................4
1.4. Relationship with EAP Methods in RFC 3748 ..................5
2. Conventions Used in This Document ...............................5
3. Authentication Model ............................................5
4. Description of the EAP-POTP Method ..............................6
4.1. Overview ...................................................6
4.2. Version Negotiation ........................................9
4.3. Cryptographic Algorithm Negotiation .......................10
4.4. Session Resumption ........................................11
4.5. Key Derivation and Session Identifiers ....................13
4.6. Error Handling and Result Indications .....................13
4.7. Use of the EAP Notification Method ........................14
4.8. Protection against Brute-Force Attacks ....................14
4.9. MAC Calculations in EAP-POTP ..............................16
4.9.1. Introduction .......................................16
4.9.2. MAC Calculation ....................................16
4.9.3. Message Hash Algorithm .............................16
4.9.4. Design Rationale ...................................17
4.9.5. Implementation Considerations ......................17
4.10. EAP-POTP Packet Format ...................................17
4.11. EAP-POTP TLV Objects .....................................20
4.11.1. Version TLV .......................................20
4.11.2. Server-Info TLV ...................................21
4.11.3. OTP TLV ...........................................23
4.11.4. NAK TLV ...........................................33
4.11.5. New PIN TLV .......................................35
4.11.6. Confirm TLV .......................................38
4.11.7. Vendor-Specific TLV ...............................41
4.11.8. Resume TLV ........................................43
4.11.9. User Identifier TLV ...............................46
4.11.10. Token Key Identifier TLV .........................47
4.11.11. Time Stamp TLV ...................................48
4.11.12. Counter TLV ......................................49
4.11.13. Challenge TLV ....................................50
4.11.14. Keep-Alive TLV ...................................51
4.11.15. Protected TLV ....................................52
4.11.16. Crypto Algorithm TLV .............................54
5. EAP Key Management Framework Considerations ....................57
6. Security Considerations ........................................57
6.1. Security Claims ...........................................57
6.2. Passive and Active Attacks ................................58
6.3. Denial-of-Service Attacks .................................59
6.4. The Use of Pepper .........................................59
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Background .................................................4
1.3. Rationale behind the Design ................................4
1.4. Relationship with EAP Methods in RFC 3748 ..................5
2. Conventions Used in This Document ...............................5
3. Authentication Model ............................................5
4. Description of the EAP-POTP Method ..............................6
4.1. Overview ...................................................6
4.2. Version Negotiation ........................................9
4.3. Cryptographic Algorithm Negotiation .......................10
4.4. Session Resumption ........................................11
4.5. Key Derivation and Session Identifiers ....................13
4.6. Error Handling and Result Indications .....................13
4.7. Use of the EAP Notification Method ........................14
4.8. Protection against Brute-Force Attacks ....................14
4.9. MAC Calculations in EAP-POTP ..............................16
4.9.1. Introduction .......................................16
4.9.2. MAC Calculation ....................................16
4.9.3. Message Hash Algorithm .............................16
4.9.4. Design Rationale ...................................17
4.9.5. Implementation Considerations ......................17
4.10. EAP-POTP Packet Format ...................................17
4.11. EAP-POTP TLV Objects .....................................20
4.11.1. Version TLV .......................................20
4.11.2. Server-Info TLV ...................................21
4.11.3. OTP TLV ...........................................23
4.11.4. NAK TLV ...........................................33
4.11.5. New PIN TLV .......................................35
4.11.6. Confirm TLV .......................................38
4.11.7. Vendor-Specific TLV ...............................41
4.11.8. Resume TLV ........................................43
4.11.9. User Identifier TLV ...............................46
4.11.10. Token Key Identifier TLV .........................47
4.11.11. Time Stamp TLV ...................................48
4.11.12. Counter TLV ......................................49
4.11.13. Challenge TLV ....................................50
4.11.14. Keep-Alive TLV ...................................51
4.11.15. Protected TLV ....................................52
4.11.16. Crypto Algorithm TLV .............................54
5. EAP Key Management Framework Considerations ....................57
6. Security Considerations ........................................57
6.1. Security Claims ...........................................57
6.2. Passive and Active Attacks ................................58
6.3. Denial-of-Service Attacks .................................59
6.4. The Use of Pepper .........................................59
6.5. The Race Attack ...........................................60
7. IANA Considerations ............................................60
7.1. General ...................................................60
7.2. Cryptographic Algorithm Identifier Octets .................61
8. Intellectual Property Considerations ...........................61
9. Acknowledgments ................................................61
10. References ....................................................62
10.1. Normative References .....................................62
10.2. Informative References ...................................62
Appendix A. Profile of EAP-POTP for RSA SecurID ...................64
Appendix B. Examples of EAP-POTP Exchanges ........................65
B.1. Basic Mode, Unilateral Authentication .....................65
B.2. Basic Mode, Session Resumption ............................66
B.3. Mutual Authentication without Session Resumption ..........67
B.4. Mutual Authentication with Transfer of Pepper .............69
B.5. Failed Mutual Authentication ..............................70
B.6. Session Resumption ........................................71
B.7. Failed Session Resumption .................................73
B.8. Mutual Authentication, and New PIN Requested ..............75
B.9. Use of Next OTP Mode ......................................78
Appendix C. Use of the MPPE-Send/Receive-Key RADIUS Attributes ....80
C.1. Introduction ..............................................80
C.2. MPPE Key Attribute Population .............................80
Appendix D. Key Strength Considerations ...........................80
D.1. Introduction ..............................................80
D.2. Example 1: 6-Digit One-Time Passwords .....................81
D.3. Example 2: 8-Digit One-Time Passwords .....................81
6.5. The Race Attack ...........................................60
7. IANA Considerations ............................................60
7.1. General ...................................................60
7.2. Cryptographic Algorithm Identifier Octets .................61
8. Intellectual Property Considerations ...........................61
9. Acknowledgments ................................................61
10. References ....................................................62
10.1. Normative References .....................................62
10.2. Informative References ...................................62
Appendix A. Profile of EAP-POTP for RSA SecurID ...................64
Appendix B. Examples of EAP-POTP Exchanges ........................65
B.1. Basic Mode, Unilateral Authentication .....................65
B.2. Basic Mode, Session Resumption ............................66
B.3. Mutual Authentication without Session Resumption ..........67
B.4. Mutual Authentication with Transfer of Pepper .............69
B.5. Failed Mutual Authentication ..............................70
B.6. Session Resumption ........................................71
B.7. Failed Session Resumption .................................73
B.8. Mutual Authentication, and New PIN Requested ..............75
B.9. Use of Next OTP Mode ......................................78
Appendix C. Use of the MPPE-Send/Receive-Key RADIUS Attributes ....80
C.1. Introduction ..............................................80
C.2. MPPE Key Attribute Population .............................80
Appendix D. Key Strength Considerations ...........................80
D.1. Introduction ..............................................80
D.2. Example 1: 6-Digit One-Time Passwords .....................81
D.3. Example 2: 8-Digit One-Time Passwords .....................81
This document describes an Extensible Authentication Protocol (EAP) [1] method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens that are electronically connected to a user's computer, e.g., through a USB interface. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP [10], IEEE 802.1X [11], and IKEv2 [12].
本文档描述了一种适用于一次性密码（OTP）令牌的可扩展认证协议（EAP）[1]方法，并为通过USB接口以电子方式连接到用户计算机的令牌提供了特殊优势。该方法可用于在利用EAP的协议（如PPP[10]、IEEE 802.1X[11]和IKEv2[12]）中提供单边或相互认证以及密钥材料。
A One-Time Password (OTP) token may be a handheld hardware device, a hardware device connected to a personal computer through an electronic interface such as USB, or a software module resident on a personal computer, which generates one-time passwords that may be used to authenticate a user towards some service. This document describes an EAP method intended to meet the needs of organizations wishing to use OTP tokens in an interoperable manner to authenticate users over EAP. The method is designed to be independent of particular OTP algorithms and to meet the requirements on modern EAP methods (see [13]).
一次性密码（OTP）令牌可以是手持硬件设备、通过诸如USB的电子接口连接到个人计算机的硬件设备或驻留在个人计算机上的软件模块，其生成一次性密码，该一次性密码可用于向某个服务认证用户。本文档描述了一种EAP方法，旨在满足希望以互操作方式使用OTP令牌通过EAP对用户进行身份验证的组织的需求。该方法旨在独立于特定的OTP算法，并满足现代EAP方法的要求（见[13]）。
The basic variant of this method provides client authentication only. This mode is only to be used within a secured tunnel. A more advanced variant provides mutual authentication, integrity protection of the exchange, protection against eavesdroppers, and establishment of authenticated keying material. Both variants allow for fast session resumption.
此方法的基本变体仅提供客户端身份验证。此模式仅在安全隧道内使用。更高级的变体提供了相互身份验证、交换的完整性保护、防止窃听，以及建立经过身份验证的密钥材料。这两种变体都允许快速恢复会话。
While this document also includes a profile of the general method for the RSA SecurID(TM) mechanism, it is described in terms of general constructions. It is therefore intended that the document will also serve as a framework for use with other OTP algorithms.
虽然本文档还包括RSA SecurID（TM）机制的一般方法概要，但它是根据一般构造进行描述的。因此，本文件还将作为与其他OTP算法一起使用的框架。
Note: The term "OTP" as used herein shall not be confused with the EAP OTP method defined in [1].
注：此处使用的术语“OTP”不得与[1]中定义的EAP OTP方法混淆。
EAP-POTP has been designed with the intent that its messages and data elements be easily parsed by EAP implementations. This makes it easier to programmatically use the EAP method in the peer and the authenticator, reducing the need for user interactions and allowing for local generation of user prompts, when needed. In contrast, the Generic Token Card (GTC) method from [1], which uses text strings
EAP-POTP的设计目的是使其消息和数据元素易于被EAP实现解析。这使得在对等方和身份验证器中以编程方式使用EAP方法变得更容易，减少了用户交互的需要，并允许在需要时本地生成用户提示。相比之下，[1]中的通用令牌卡（GTC）方法使用文本字符串
generated by the EAP server, is intended to be interpreted and acted upon by humans. Furthermore, EAP-POTP allows for mutual authentication and establishment of keying material, which GTC does not. To retain the generic nature of GTC, the EAP-POTP method has been designed to support a wide range of OTP algorithms, with profiling expected for specific such algorithms. This document provides a profile of EAP-POTP for RSA SecurID tokens.
由EAP服务器生成，旨在由人类进行解释和操作。此外，EAP-POTP允许相互认证和建立密钥材料，而GTC不允许。为了保持GTC的通用性，EAP-POTP方法被设计为支持范围广泛的OTP算法，并预期对特定的此类算法进行分析。本文档提供了RSA SecurID令牌的EAP-POTP配置文件。
The EAP OTP method defined in [1], which builds on [14], is an example of a particular OTP algorithm and is not related to the EAP method defined in this document, other than that a profile of EAP-POTP may be created for the OTP algorithm from [14].
[1]中定义的EAP OTP方法建立在[14]的基础上，是特定OTP算法的一个示例，与本文档中定义的EAP方法无关，除了可以从[14]中为OTP算法创建EAP-POTP配置文件之外。
The Generic Token Card EAP method defined in [1] is intended to work with a variety of OTP algorithms. The same is true for EAP-POTP, the EAP method defined herein. Advantages of profiling a particular OTP algorithm for use with EAP-POTP, compared to using EAP GTC, are described in Section 1.3.
[1]中定义的通用令牌卡EAP方法适用于各种OTP算法。本文定义的EAP方法EAP-POTP也是如此。与使用EAP GTC相比，分析用于EAP-POTP的特定OTP算法的优势在第1.3节中描述。
The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY", in this document are to be interpreted as described in RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“应”、“不得”、“应”、“不应”、“建议”和“可”应按照RFC 2119[2]中的说明进行解释。
The EAP-POTP method provides user authentication as defined below. Additionally, it may provide mutual authentication (authenticating the EAP server to the EAP client) and establish keying material.
EAP-POTP方法提供如下定义的用户身份验证。此外，它可以提供相互认证（向EAP客户端认证EAP服务器）并建立密钥材料。
There are basically three entities in the authentication method described here:
这里描述的身份验证方法基本上有三个实体：
o A client, or "peer", using EAP terminology, acting on behalf of a user possessing an OTP token;
o 使用EAP术语代表拥有OTP令牌的用户的客户端或“对等方”；
o A server, or "authenticator", using EAP terminology, to which the user needs to authenticate; and
o 使用EAP术语的服务器或“认证器”，用户需要对其进行认证；和
o A backend authentication server, providing an authentication service to the authenticator.
o 后端身份验证服务器，为身份验证程序提供身份验证服务。
The term "EAP server" is used here with the same meaning as in [1]. Any protocol used between the authenticator and the backend authentication server is outside the scope of this document, although
此处使用的术语“EAP服务器”与[1]中的含义相同。身份验证程序和后端身份验证服务器之间使用的任何协议都不在本文档的范围内，尽管
RADIUS [15] is a typical choice. It is assumed that the EAP client and the peer are located on the same host, and hence only the term "peer" is used in the following for these entities.
半径[15]是典型的选择。假定EAP客户机和对等机位于同一主机上，因此以下仅对这些实体使用术语“对等机”。
The EAP-POTP method assumes the use of a shared secret key, or "seed", which is known both by the user and the backend authentication server. The secret seed is stored on an OTP token that the user possesses, as well as on the authentication server.
EAP-POTP方法假定使用共享密钥或“种子”，用户和后端身份验证服务器都知道该密钥。秘密种子存储在用户拥有的OTP令牌以及身份验证服务器上。
In its most basic variant, the EAP-POTP method provides only one Service (namely, user authentication) where the user provides information to the authentication server so that the server can authenticate the user. A more advanced variant provides mutual authentication, protection against eavesdropping, and establishment of authenticated keying material.
在其最基本的变体中，EAP-POTP方法仅提供一种服务（即用户身份验证），其中用户向身份验证服务器提供信息，以便服务器能够对用户进行身份验证。一种更高级的变体提供了相互身份验证、防止窃听和建立经过身份验证的密钥材料。
Note: Since the EAP-POTP method is general in nature, the term "POTP-X" is used below as a placeholder for an EAP method type identifier, identifying the use of a particular OTP algorithm with EAP-POTP. As an example, in the case of using RSA SecurID tokens within EAP-POTP, the EAP method type shall be 32 (see Appendix A).
注：由于EAP-POTP方法在本质上是通用的，下面使用术语“POTP-X”作为EAP方法类型标识符的占位符，用于标识特定OTP算法与EAP-POTP的使用。例如，在EAP-POTP中使用RSA SecurID令牌的情况下，EAP方法类型应为32（见附录A）。
A typical EAP-POTP authentication is performed as follows (Appendix B provides more detailed examples):
典型的EAP-POTP认证如下所示（附录B提供了更详细的示例）：
a. The optional EAP Identity Request/Response is exchanged, as per RFC 3748 [1]. An identity provided here may alleviate the need for a "User Identifier" or a "Token Key Identifier" triplet (TLV), defined below, later in the exchange.
a. 根据RFC 3748[1]，交换可选的EAP身份请求/响应。此处提供的标识可减轻对“用户标识符”或“令牌密钥标识符”三元组（TLV）的需要，该三元组定义如下，稍后在交换中定义。
b. The EAP server sends an EAP-Request of type POTP-X with a Version TLV. The Version TLV indicates the highest and lowest version of this method supported by the server. The EAP server typically also includes an OTP TLV in the EAP-Request. The OTP TLV instructs the peer to respond with the current OTP (possibly in protected form), and may contain a challenge and some other information, like server policies. The EAP server should also include a Server-Info TLV in the request, and must do so if it supports session resumption. The Server-Info TLV identifies the authentication server, contains an identifier for this (new) session, and may be used by the peer to find an already existing session with the EAP server.
b. EAP服务器发送类型为POTP-X且版本为TLV的EAP请求。版本TLV表示服务器支持的此方法的最高和最低版本。EAP服务器通常还包括EAP请求中的OTP TLV。OTP TLV指示对等方使用当前OTP（可能是受保护的形式）进行响应，并且可能包含质询和一些其他信息，如服务器策略。EAP服务器还应在请求中包含服务器信息TLV，如果它支持会话恢复，则必须这样做。服务器信息TLV标识身份验证服务器，包含此（新）会话的标识符，对等方可以使用它查找与EAP服务器的已存在会话。
c. The peer responds with an EAP-Response of type Nak (3) if it does not support POTP-X or if it does not support a version of this method that is also supported by the server, as indicated in the server's Version TLV.
c. 如果对等方不支持POTP-X，或者不支持服务器也支持的此方法的版本（如服务器版本TLV中所示），则对等方将使用Nak（3）类型的EAP响应进行响应。
If the peer supports a version of this method that is also supported by the EAP server, the peer generates an EAP-Response of type POTP-X as follows:
如果对等方支持EAP服务器也支持的此方法的版本，则对等方将生成POTP-X类型的EAP响应，如下所示：
* First, it generates a Version TLV, which indicates the peer's highest supported version within the range of versions offered by the server. This Version TLV will be part of the EAP-Response to the EAP server.
* 首先，它生成一个版本TLV，它指示对等方在服务器提供的版本范围内受支持的最高版本。此版本TLV将是EAP对EAP服务器响应的一部分。
* Next, if the peer's highest supported version equals that of the EAP server, and the EAP server sent a Server-Info TLV, the peer checks if it has a saved session with the EAP server. If an existing session with the server is found, and session resumption is possible (the Server-Info TLV may explicitly disallow it), the peer calculates new session keys (if the session is a protected-mode session) and responds with a Resume TLV and the Version TLV.
* 接下来，如果对等方支持的最高版本与EAP服务器的版本相同，并且EAP服务器发送了服务器信息TLV，则对等方将检查是否保存了与EAP服务器的会话。如果找到与服务器的现有会话，并且可以恢复会话（服务器信息TLV可能会明确禁止），对等方将计算新会话密钥（如果会话是受保护模式会话），并使用恢复TLV和版本TLV进行响应。
* Otherwise, if the peer's highest supported version equals that of the EAP server, and the received EAP-Request message contains an OTP TLV, the peer requests (possibly through user interaction) the OTP token to calculate a one-time password based on the information in the received EAP-Request message (which could, for example, carry a challenge), the current token state (e.g., token time), a shared secret (the "seed"), and a user-provided PIN (note that, depending on the OTP token type, some of the information in the EAP-Request may not be used in the OTP calculation, and the PIN may be optional too). If the received OTP TLV has the P bit set (see below), the peer then combines the token-provided OTP with other information, and provides the combined data to a key derivation function. The key derivation function generates several keys, of which one is used to calculate a Message Authentication Code (MAC) on the received message, together with some other information. The resulting MAC, together with some additional information, is then placed in an OTP TLV (with the P bit set) that is sent in a response to the EAP server, together with the Version TLV. If the P bit is not set in the received OTP TLV, the peer instead inserts the calculated OTP value directly in an OTP TLV, which then is sent to the EAP server together with the Version TLV.
* 否则，如果对等方的最高支持版本等于EAP服务器的版本，并且接收到的EAP请求消息包含OTP TLV，则对等方请求（可能通过用户交互）OTP令牌，以基于接收到的EAP请求消息中的信息（例如，可能携带质询）计算一次性密码，当前令牌状态（例如，令牌时间）、共享秘密（“种子”）和用户提供的PIN（注意，根据OTP令牌类型，EAP请求中的一些信息可能不会用于OTP计算，PIN也可能是可选的）。如果接收到的OTP TLV设置了P位（见下文），则对等方将OTP提供的令牌与其他信息组合，并将组合的数据提供给密钥派生函数。密钥派生函数生成多个密钥，其中一个用于计算接收到的消息上的消息认证码（MAC）以及一些其他信息。生成的MAC以及一些附加信息随后被放置在OTP TLV（带有P位集）中，该OTP TLV与版本TLV一起作为响应发送给EAP服务器。如果未在接收到的OTP TLV中设置P位，则对等方会将计算出的OTP值直接插入OTP TLV中，然后将OTP TLV与版本TLV一起发送到EAP服务器。
* Finally, if the peer's highest supported version differs from the server's, or if the server did not provide any TLVs besides the Version TLV in its initial request, the peer just sends back the generated Version TLV as an EAP-Response to the EAP server.
* 最后，如果对等方支持的最高版本与服务器的不同，或者如果服务器在其初始请求中没有提供除版本TLV之外的任何TLV，则对等方只将生成的版本TLV作为EAP响应发送回EAP服务器。
d. If the EAP server receives an EAP-Response of type Nak (3), the session negotiation failed and the EAP server may try with another EAP method. Otherwise, the EAP server checks the peer's supported version. If the peer did not support the highest version supported by the server, the server will send a new EAP-Request with TLVs adjusted for that version. Otherwise, assuming the EAP server did send additional TLVs in its initial EAP-Request, the EAP server will attempt to authenticate the peer based on the response provided in c). Depending on the result of this authentication, the EAP server may do one of the following:
d. 如果EAP服务器接收到Nak（3）类型的EAP响应，则会话协商失败，EAP服务器可以尝试使用其他EAP方法。否则，EAP服务器将检查对等方支持的版本。如果对等方不支持服务器支持的最高版本，服务器将发送一个新的EAP请求，其中TLV针对该版本进行了调整。否则，假设EAP服务器在其初始EAP请求中确实发送了额外的TLV，EAP服务器将尝试根据c）中提供的响应对对等方进行身份验证。根据此身份验证的结果，EAP服务器可以执行以下操作之一：
* send a new EAP-Request of type POTP-X to the peer indicating that session resumption was not possible, and ask for a new OTP (this would be the case when the peer responded with a Resume TLV, and the session indicated in the Resume TLV was not valid),
* 向对等方发送类型为POTP-X的新EAP请求，表明无法恢复会话，并请求新的OTP（当对等方响应恢复TLV，且恢复TLV中指示的会话无效时，会出现这种情况），
* send a new EAP-Request of type POTP-X to the peer (e.g., to ask for the next OTP),
* 向对等方发送POTP-X类型的新EAP请求（例如，请求下一个OTP），
* accept the authentication (and send an EAP-Request message containing a Confirm TLV to the peer if the received response has the P bit set or was a successful attempt at a protected-mode session resumption; otherwise, send an EAP-Success message to the peer), or
* 接受身份验证（如果接收到的响应设置了P位或成功尝试恢复受保护模式会话，则向对等方发送包含确认TLV的EAP请求消息；否则，向对等方发送EAP成功消息），或
* fail the authentication (and send an EAP-Failure message -- possibly preceded by an EAP-Request message of type Notification (2) -- to the peer).
* 身份验证失败（并向对等方发送一条EAP失败消息（前面可能有一条通知（2）类型的EAP请求消息）。
e. If the peer receives an EAP-Success or an EAP-Failure message the protocol run is finished. If the peer receives an EAP-Request of type Notification, it responds as specified by RFC 3748 [1]. If the peer receives an EAP-Request of type POTP-X with a Confirm TLV, it attempts to authenticate the EAP server using the provided data. If the authentication is successful, the peer responds with an EAP-Response of type POTP-X with a Confirm TLV. If it is unsuccessful, the peer responds with an empty EAP-Response of type POTP-X. If the peer receives an EAP-Request of type POTP-X containing some other TLVs, it continues as specified in c) above (though no version negotiation will take place in this case) or as described for those TLVs.
e. 如果对等方收到EAP成功或EAP失败消息，则协议运行完成。如果对等方收到通知类型的EAP请求，它将按照RFC 3748[1]的规定进行响应。如果对等方收到带有确认TLV的POTP-X类型的EAP请求，它将尝试使用提供的数据对EAP服务器进行身份验证。如果认证成功，对等方将使用POTP-X类型的EAP响应和确认TLV进行响应。如果不成功，对等方将以POTP-X类型的空EAP响应进行响应。如果对等方接收到包含其他TLV的POTP-X类型的EAP请求，则它将按照上述c）中的规定继续（尽管在这种情况下不会进行版本协商）或按照这些TLV的说明继续。
f. When an EAP server, which has sent an EAP-Request of type POTP-X with a Confirm TLV, receives an EAP-Response of type POTP-X with a Confirm TLV present, it can proceed in one of two ways: If it has detected that there is a need to send additional EAP-Requests of type POTP-X, it shall enter a "protected state", where, from then on, all POTP-X TLVs must be encrypted and integrity-protected before being sent (at this point, the parties shall have calculated a master session key as described in Section 4.5). One reason to continue the POTP-X conversation after exchange of the Confirm TLV could be that the user needs to update her OTP PIN; hence, the EAP server needs to send a New PIN TLV. At that point, the handshake is back at step c) above (except for the version negotiation and the protection of all TLVs). If there is no need to send additional EAP-Request packets, the EAP server shall instead send an EAP-Success method to the peer to indicate successful protocol completion. The EAP server may not continue the conversation unless it indicates its intent to do so in the Confirm TLV.
f. 当发送了带有确认TLV的POTP-X类型EAP请求的EAP服务器接收到带有确认TLV的POTP-X类型EAP响应时，它可以通过以下两种方式之一继续：如果它检测到需要发送额外的POTP-X类型EAP请求，它应进入“受保护状态”，从那时起，所有POTP-X TLV在发送前必须进行加密和完整性保护（此时，双方应已计算出第4.5节所述的主会话密钥）。交换确认TLV后继续POTP-X对话的一个原因可能是用户需要更新她的OTP PIN；因此，EAP服务器需要发送新的PIN TLV。此时，握手返回到上面的步骤c）（版本协商和所有TLV的保护除外）。如果不需要发送额外的EAP请求数据包，EAP服务器应改为向对等方发送EAP成功方法，以指示协议成功完成。EAP服务器可能不会继续对话，除非它在确认TLV中表明其意图。
An EAP server, which has sent an EAP-Request of type POTP-X with a Confirm TLV and receives an EAP-Response of type POTP-X, which is empty (i.e., does not contain any TLVs), shall respond with an EAP-Failure and terminate the handshake.
已发送带有确认TLV的POTP-X类型EAP请求并接收POTP-X类型EAP响应（为空（即不包含任何TLV））的EAP服务器应响应EAP故障并终止握手。
As implied by the description, steps c) through f) may be carried out a number of times before completion of the exchange. One example of this is when the authentication server initially requests an OTP, accepts the response from the peer, performs an (intermediary) Confirm TLV exchange, requests the peer to select a new PIN, and finally asks the peer to authenticate with an OTP based on the new PIN (which again will be followed with a final Confirm TLV exchange).
如说明书所暗示的，步骤c）到f）可以在交换完成之前执行多次。这方面的一个示例是，身份验证服务器最初请求OTP，接受来自对等方的响应，执行（中间）确认TLV交换，请求对等方选择新PIN，最后请求对等方基于新PIN向OTP进行身份验证（随后将再次进行最终确认TLV交换）。
The EAP-POTP method provides a version negotiation mechanism that enables implementations to be backward compatible with previous versions of the protocol. This specification documents the EAP-POTP protocol version 1. Version negotiation proceeds as follows:
EAP-POTP方法提供了一种版本协商机制，使实现与协议的早期版本向后兼容。本规范记录了EAP-POTP协议版本1。版本谈判进行如下：
a. In the first EAP-Request of type POTP-X, the EAP server MUST send a Version TLV in which it sets the "Highest" field to its highest supported version number, and the "Lowest" field to its lowest supported version number. The EAP server MAY include other TLV triplets, as described below, that are compatible with the "Highest" supported version number to optimize the number of round-trips in the case of a peer supporting the server's "Highest" version number.
a. 在POTP-X类型的第一个EAP请求中，EAP服务器必须发送一个版本TLV，其中它将“最高”字段设置为其支持的最高版本号，“最低”字段设置为其支持的最低版本号。EAP服务器可以包括其他TLV三元组，如下所述，它们与支持的“最高”版本号兼容，以在对等方支持服务器的“最高”版本号的情况下优化往返次数。
b. If the peer supports a version of the protocol that falls within the range of versions indicated by the EAP server, it MUST respond with an EAP-Response of type POTP-X that contains a Version TLV with the "Highest" field set to the highest version supported by the peer. The peer MUST also respond to any TLV triplets included in the EAP-Request, if it supported the "Highest" supported version indicated in the server's Version TLV.
b. 如果对等方支持的协议版本在EAP服务器指示的版本范围内，则必须使用POTP-X类型的EAP响应进行响应，该响应包含版本TLV，且“最高”字段设置为对等方支持的最高版本。对等方还必须响应EAP请求中包含的任何TLV三元组，如果它支持服务器TLV版本中指示的“最高”支持版本。
The EAP peer MUST respond with an EAP-Response of type Nak (3) if it does not support a version that falls within the range of versions indicated by the EAP server. This will allow the EAP server to use another EAP method for peer authentication.
如果EAP对等方不支持在EAP服务器指示的版本范围内的版本，则必须使用Nak（3）类型的EAP响应进行响应。这将允许EAP服务器使用另一种EAP方法进行对等身份验证。
c. When the EAP server receives an EAP-Response containing a Version TLV from the peer, but the "Highest" supported version field in the TLV differs from the "Highest" supported version field sent by the EAP server, or when the version is the same as the one originally proposed by the EAP server, but the EAP server did not include any TLV triplets in the initial request, the EAP server sends a new EAP-Request of type POTP-X with the negotiated version and TLV triplets as desired and described herein.
c. 当EAP服务器从对等方接收到包含版本TLV的EAP响应，但TLV中的“最高”支持版本字段与EAP服务器发送的“最高”支持版本字段不同时，或者当版本与EAP服务器最初建议的版本相同时，但是EAP服务器在初始请求中不包括任何TLV三元组，EAP服务器发送一个新的POTP-X类型的EAP请求，其中包含协商版本和本文所述的TLV三元组。
The version negotiation procedure guarantees that the EAP peer and server will agree to the highest version supported by both parties. If version negotiation fails, use of EAP-POTP will not be possible, and another mutually acceptable EAP method will need to be negotiated if authentication is to proceed.
版本协商过程保证EAP对等方和服务器将同意双方支持的最高版本。如果版本协商失败，将无法使用EAP-POTP，如果要继续进行身份验证，则需要协商另一种双方均可接受的EAP方法。
The EAP-POTP version field may be modified in transit by an attacker. It is therefore important that EAP entities only accept EAP-POTP versions according to an explicit policy.
攻击者可能会在传输过程中修改EAP-POTP版本字段。因此，根据明确的政策，EAP实体只接受EAP-POTP版本是很重要的。
Cryptographic algorithms are negotiated through the use of the Crypto Algorithm TLV. EAP-POTP provides a default digest algorithm (SHA-256) [3], a default encryption algorithm (AES-CBC) [4] , and a default MAC algorithm (HMAC) [5], and these algorithms MUST be supported by all EAP-POTP implementations. An EAP server that does not want to make use of any other algorithms than the default ones need not send a Crypto Algorithm TLV. An EAP server that does want to negotiate use of some other algorithms MUST send the Crypto Algorithm TLV in the initial EAP-Request of type POTP-X that also contains an OTP TLV with the P bit set. The TLV MUST NOT be present in any other EAP-Request in the session. (The two exceptions to this are 1) if the client attempted a session resumption that failed and therefore did not evaluate a sent Crypto Algorithm TLV, or 2) if the
通过使用加密算法TLV协商加密算法。EAP-POTP提供默认摘要算法（SHA-256）[3]、默认加密算法（AES-CBC）[4]和默认MAC算法（HMAC）[5]，所有EAP-POTP实现都必须支持这些算法。不希望使用默认算法以外的任何其他算法的EAP服务器不需要发送加密算法TLV。确实希望协商使用某些其他算法的EAP服务器必须在POTP-X类型的初始EAP请求中发送加密算法TLV，该请求还包含具有P位集的OTP TLV。TLV不得出现在会话中的任何其他EAP请求中。（这有两个例外情况：1）如果客户端尝试的会话恢复失败，因此没有评估发送的加密算法TLV，或2）如果
Crypto Algorithm TLV was part of the initial message from the EAP server, and the client negotiated another EAP-POTP version than the highest one supported by the EAP server. When either of these cases apply, the server MUST include the Crypto Algorithm TLV in the first EAP-Request that also contains an OTP TLV with the P bit set subsequent to the failed session resumption / protocol version negotiation.) In the Crypto Algorithm TLV, the EAP server suggests some combination of digest, encryption, and MAC algorithms. (If the server only wants to negotiate a particular class of algorithms, then suggestions for the other classes need not be present, since the default applies.)
加密算法TLV是来自EAP服务器的初始消息的一部分，客户端协商的EAP-POTP版本不是EAP服务器支持的最高版本。当上述任一情况适用时，服务器必须在第一个EAP请求中包含加密算法TLV，该请求还包含OTP TLV，在失败的会话恢复/协议版本协商之后设置了P位。）在加密算法TLV中，EAP服务器建议采用摘要、加密和MAC算法的某种组合。（如果服务器只想协商某一特定类别的算法，则不需要提供其他类别的建议，因为默认设置适用。）
The peer MUST include a Crypto Algorithm TLV in an EAP-Response if and only if an EAP-Request of type POTP-X has been received containing a Crypto Algorithm TLV, it was legal for that EAP-Request to contain a Crypto Algorithm TLV, the peer does not try to resume an existing session, and the peer and the EAP server agree on at least one algorithm not being the default one. If the peer does not supply a value for a particular class of algorithms in a responding Crypto Algorithm TLV, then the default algorithm applies for that class. When resuming an existing session (see the next section), there is no need for the peer to negotiate since the session already is associated with a set of algorithms. Servers MUST fail a session (i.e., send an EAP-Failure) if they receive an EAP-Response TLV containing both a Resume TLV and a Crypto Algorithm TLV.
对等方必须在EAP响应中包含加密算法TLV如果且仅当收到包含加密算法TLV的POTP-X类型EAP请求时，该EAP请求包含加密算法TLV是合法的，对等方不会尝试恢复现有会话，对等方和EAP服务器同意至少一种算法不是默认算法。如果对等方未为响应加密算法TLV中的特定算法类提供值，则默认算法适用于该类。恢复现有会话时（请参阅下一节），对等方无需进行协商，因为会话已与一组算法关联。如果服务器收到包含恢复TLV和加密算法TLV的EAP响应TLV，则必须使会话失败（即发送EAP失败）。
Clearly, EAP servers and peers MUST NOT suggest any other algorithms than the ones their policy allows them to use. Policies may also restrict what combinations of cryptographic algorithms are acceptable.
显然，EAP服务器和对等方不得建议其策略允许使用的算法以外的任何其他算法。密码策略的组合也可能会限制可接受的密码策略。
This method makes use of session identifiers and server identifiers to allow for improved efficiency in the case where a peer repeatedly attempts to authenticate to an EAP server within a short period of time. This capability is particularly useful for support of wireless roaming.
该方法利用会话标识符和服务器标识符，以便在对等方在短时间内重复尝试向EAP服务器进行身份验证的情况下提高效率。此功能对于支持无线漫游特别有用。
In order to help the peer find a session associated with the EAP server, an EAP server that supports session resumption MUST send a Server-Info TLV containing a server identifier in its initial EAP-Request of type POTP-X that also contains an OTP TLV. The identifier may then be used by the peer for lookup purposes.
为了帮助对等方找到与EAP服务器相关联的会话，支持会话恢复的EAP服务器必须发送一个服务器信息TLV，该信息TLV在其POTP-X类型的初始EAP请求中包含一个服务器标识符，该请求也包含一个OTP TLV。然后该标识符可由对等方用于查找目的。
It is left to the peer whether or not to attempt to continue a previous session, thus shortening the negotiation. Typically, the peer's decision will be made based on the time elapsed since the
是否尝试继续上一个会话将留给对等方，从而缩短协商时间。通常，对等方的决定将基于自事件发生以来经过的时间做出
previous authentication attempt to that EAP server. If the peer decides to attempt to resume a session with the EAP server, it sends a Resume TLV identifying the chosen session and other contents, as described below, to the EAP server.
以前对该EAP服务器的身份验证尝试。如果对等方决定尝试恢复与EAP服务器的会话，它将向EAP服务器发送一个恢复TLV，标识所选会话和其他内容，如下所述。
Based on the session identifier chosen by the peer, and the time elapsed since the previous authentication, the EAP server will decide whether to allow the session resumption, or continue with a new session.
根据对等方选择的会话标识符以及自上次身份验证以来经过的时间，EAP服务器将决定是允许会话恢复，还是继续新会话。
o If the EAP server is willing to resume a previously established session, it MUST authenticate the peer based on the contents of the Resume TLV. If the authentication succeeds, the handshake will continue in one of two ways:
o 如果EAP服务器愿意恢复先前建立的会话，则必须根据恢复TLV的内容对对等方进行身份验证。如果身份验证成功，握手将以以下两种方式之一继续：
* If the session is a protected-mode session, then the server MUST respond with a request containing a Confirm TLV. If the Confirm TLV authenticates the EAP server, then the peer responds with an empty Confirm TLV, to which the EAP server responds with an EAP-Success message. If the Confirm TLV does not authenticate the EAP server, the peer responds with an empty EAP-Response of type POTP-X.
* 如果会话是受保护模式会话，则服务器必须响应包含确认TLV的请求。如果确认TLV对EAP服务器进行身份验证，则对等方将使用空的确认TLV进行响应，EAP服务器将使用EAP成功消息对其进行响应。如果Confirm TLV未对EAP服务器进行身份验证，则对等方将以POTP-X类型的空EAP响应进行响应。
* If the session is not a protected-mode session, i.e., it is a session created from a basic-mode peer authentication, then the server MUST respond with an EAP-Success message.
* 如果会话不是受保护模式会话，即，它是从基本模式对等身份验证创建的会话，则服务器必须使用EAP成功消息进行响应。
If the authentication of the peer fails, the EAP server SHOULD send another EAP-Request containing an OTP TLV and a Server-Info TLV with the N bit set to indicate that no session resumption is possible. The EAP server MAY also send an EAP-Failure message, possibly preceded by an EAP-Request of type Notification (2), in which case, the EAP run will terminate.
如果对等身份验证失败，EAP服务器应发送另一个EAP请求，其中包含OTP TLV和服务器信息TLV，并设置N位，以指示不可能恢复会话。EAP服务器还可能发送EAP失败消息，之前可能会有通知（2）类型的EAP请求，在这种情况下，EAP运行将终止。
o If the EAP server is not willing or able to resume a previously established session, it will respond with another EAP-Request containing an OTP TLV and a Server-Info TLV with the N bit set (indicating no session resumption).
o 如果EAP服务器不愿意或不能恢复先前建立的会话，它将用另一个包含OTP TLV和设置了N位的服务器信息TLV的EAP请求进行响应（表示没有会话恢复）。
Sessions SHOULD NOT be maintained longer than the security of the exchange which created the session permits. For example, if it is estimated that an attacker could be successful in brute-force searching for the OTP in 24 hours, then EAP-POTP session lifetimes should be clearly less than this value.
会话的维持时间不应超过创建会话的exchange的安全性许可的时间。例如，如果估计攻击者可以在24小时内成功地对OTP进行暴力搜索，则EAP-POTP会话寿命应明显小于此值。
The EAP-POTP method described herein makes use of a key derivation function denoted "PBKDF2". PBKDF2 is described in [6], Section 5.2. The PBKDF2 PRF SHALL be set to the negotiated MAC algorithm. The default MAC algorithm, which MUST be supported, is HMAC-SHA256. HMAC is defined in [5], and SHA-256 is defined in [3]. HMAC-SHA256 is the HMAC construct from [5] with SHA-256 as the hash function H. The output length of HMAC-SHA256, when used as a PRF for PBKDF2, shall be 32 octets (i.e., the full output length).
本文描述的EAP-POTP方法利用表示为“PBKDF2”的密钥派生函数。PBKDF2如第5.2节[6]所述。PBKDF2 PRF应设置为协商MAC算法。必须支持的默认MAC算法是HMAC-SHA256。[5]中定义了HMAC，而[3]中定义了SHA-256。HMAC-SHA256是[5]中的HMAC构造，其中SHA-256作为哈希函数H。HMAC-SHA256的输出长度，当用作PBKDF2的PRF时，应为32个八位字节（即完整输出长度）。
The output from PBKDF2 as described here will consist of five keys (see Section 4.11.3 for details on how to calculate these keys):
此处描述的PBKDF2输出将包括五个键（有关如何计算这些键的详细信息，请参见第4.11.3节）：
o K_MAC, a MAC key used for mutual authentication and integrity protection,
o K_MAC，用于相互认证和完整性保护的MAC密钥，
o K_ENC, an encryption key used to protect certain data during the authentication,
o K_ENC，一种加密密钥，用于在身份验证过程中保护某些数据，
o SRK, a session resumption key only used for session resumption purposes,
o SRK，仅用于会话恢复目的的会话恢复密钥，
o MSK, a Master Session Key, as defined in [1], and
o MSK，如[1]中所定义的主会话密钥，以及
o EMSK, an Extended Master Session Key, also as defined in [1].
o EMSK，扩展主会话密钥，也如[1]中所定义。
For the default algorithms, K_MAC, K_ENC, and SRK SHALL be 16 octets. For other cases, the key lengths will be as determined by the negotiated algorithms. The MSK and the EMSK SHALL each be 64 octets, in conformance with [1]. Therefore, in the case of default algorithms, the "dkLen" parameter from Section 5.2 of [6] SHALL be set to 176 (the combined length of K_MAC, K_ENC, SRK, MSK, and EMSK).
对于默认算法，K_MAC、K_ENC和SRK应为16个八位字节。对于其他情况，密钥长度将由协商算法确定。MSK和EMSK应分别为64个八位字节，符合[1]。因此，在默认算法的情况下，[6]第5.2节中的“dkLen”参数应设置为176（K_MAC、K_ENC、SRK、MSK和EMSK的组合长度）。
[1] and [16] define usage of the MSK and the EMSK . For a particular use case, see also Appendix C.
[1] 以及[16]定义MSK和EMSK的用法。对于特定用例，另请参见附录C。
EAP does not allow for the sending of an EAP-Response of type Nak (3) within a method after the initial EAP-Request and EAP-Response pair of that particular method has been exchanged (see [1], Section 2.1). Instead, when a peer is unable to continue an EAP-POTP session, the peer MAY respond to an outstanding EAP-Request by sending an empty EAP-Response of type POTP-X rather than immediately terminating the conversation. This allows the EAP server to log the cause of the error.
在交换特定方法的初始EAP请求和EAP响应对后，EAP不允许在方法内发送Nak（3）类型的EAP响应（见[1]，第2.1节）。相反，当对等方无法继续EAP-POTP会话时，对等方可以通过发送POTP-X类型的空EAP响应来响应未完成的EAP请求，而不是立即终止会话。这允许EAP服务器记录错误原因。
To ensure that the EAP server receives the empty EAP-Response, the peer SHOULD wait for the EAP server to reply before terminating the conversation. The EAP server MUST reply with an EAP-Failure.
为确保EAP服务器接收到空的EAP响应，对等方应在终止对话之前等待EAP服务器回复。EAP服务器必须回复EAP故障。
When EAP-POTP is run in protected mode, the exchange of the Confirm TLV (Section 4.11.6) serves as a success result indication; when the peer receives a Confirm TLV, it knows that the EAP server has successfully authenticated it. Similarly, when the EAP server receives the Confirm TLV response from the peer, it knows that the peer has authenticated it. In protected mode, the peer will not accept an EAP-Success packet unless it has received and validated a Confirm TLV. The Confirm TLV sent from the EAP server to the peer is a "protected result indication" as defined in [1], as it is integrity protected and cannot be replayed. The Confirm TLV sent from the peer to the EAP server is, however, not a protected result indication. An empty EAP-POTP response sent from the peer to the EAP server serves as a failure result indication.
当EAP-POTP在保护模式下运行时，确认TLV（第4.11.6节）的交换作为成功结果指示；当对等方收到确认TLV时，它知道EAP服务器已成功对其进行身份验证。类似地，当EAP服务器从对等方接收到确认TLV响应时，它知道对等方已经对其进行了身份验证。在受保护模式下，对等方将不接受EAP成功数据包，除非它已接收并验证确认TLV。从EAP服务器发送到对等方的确认TLV是[1]中定义的“受保护结果指示”，因为它受完整性保护，无法重放。但是，从对等方发送到EAP服务器的确认TLV不是受保护的结果指示。从对等方发送到EAP服务器的空EAP-POTP响应用作故障结果指示。
Except where explicitly allowed in the following, the EAP Notification method MUST NOT be used within an EAP-POTP session. The EAP Notification method MAY be used within an EAP-POTP session in the following situations:
除非以下明确允许，否则EAP通知方法不得在EAP-POTP会话中使用。在以下情况下，EAP通知方法可在EAP-POTP会话中使用：
o The EAP server MAY send an EAP-Request of type Notification (2) when it has received an EAP-Response containing an OTP TLV and is unable to authenticate the user. In this case, once the EAP-Response of type Notification is received, the EAP server MAY retry the authentication and send a new EAP-Request containing an OTP TLV, or it MAY fail the session and send an EAP-Failure message.
o 当EAP服务器收到包含OTP TLV的EAP响应并且无法对用户进行身份验证时，可以发送类型为通知（2）的EAP请求。在这种情况下，一旦接收到通知类型的EAP响应，EAP服务器可能会重试身份验证并发送包含OTP TLV的新EAP请求，或者它可能会使会话失败并发送EAP失败消息。
o The EAP server MAY send an EAP-Request of type Notification (2) when it has received an unacceptable New PIN TLV. In this case, once the EAP-Response of type Notification is received, the EAP server MAY retry the PIN update and send a new EAP-Request with a New PIN TLV, or it MAY fail the session and send an EAP-Failure message.
o EAP服务器在接收到不可接受的新PIN TLV时，可能会发送类型为通知（2）的EAP请求。在这种情况下，一旦收到类型为Notification的EAP响应，EAP服务器可能会重试PIN更新并使用新PIN TLV发送新的EAP请求，或者可能会使会话失败并发送EAP失败消息。
Since OTPs may be relatively short, it is important to slow down an attacker sufficiently so that it is economically unattractive to brute-force search for an OTP, given an observed EAP-POTP handshake in protected mode. One way to do this is to do a high number of iterated hashes in the PBKDF2 function. Another is for the client to include a value ("pepper") unknown to the attacker in the hash
由于OTP可能相对较短，因此重要的是要充分减慢攻击者的速度，以便在保护模式下观察到EAP-POTP握手的情况下，暴力搜索OTP在经济上不具吸引力。一种方法是在PBKDF2函数中执行大量迭代哈希。另一种是客户端在散列中包含攻击者未知的值（“pepper”）
computation. Whereas a traditional "salt" value normally is sent in the clear, this "pepper" value will not be sent in the clear, but may instead be transferred to the EAP server in encrypted form. In practice, the procedure is as follows:
计算传统的“salt”值通常以明文形式发送，而该“pepper”值不会以明文形式发送，而是可以加密形式传输到EAP服务器。在实践中，程序如下：
a. The EAP server indicates in its OTP TLV whether it supports pepper searching. Additionally, it may indicate to the peer that a new pepper shall be chosen.
a. EAP服务器在其OTP TLV中指示是否支持pepper搜索。此外，它可能向同行表明应选择新的辣椒。
b. If the peer supports the use of pepper, the peer checks whether it already has established a shared pepper with this server:
b. 如果对等方支持使用pepper，则对等方将检查是否已与此服务器建立共享pepper：
If it does have a pepper stored for this server, and the server did not indicate that a new pepper shall be generated, then it uses the existing pepper value, as specified in Section 4.11.3 below, to calculate an OTP TLV response. In this case, the iteration count shall be kept to a minimum, as the security of the scheme is provided through the pepper, and efficiency otherwise is lost.
如果它确实为此服务器存储了一个pepper，并且服务器没有指示应生成一个新pepper，则它使用现有pepper值（如下文第4.11.3节所述）来计算OTP TLV响应。在这种情况下，迭代次数应保持在最小值，因为方案的安全性是通过pepper提供的，否则将失去效率。
If the peer does not have a pepper stored for this server, but the server indicated support for pepper searching, or the server indicated that a new pepper shall be generated, then the peer generates a random and uniformly distributed pepper of sufficient length (the maximum length supported by the server is provided in the server's OTP TLV), and includes the new pepper in the PBKDF2 computation.
如果对等方没有为此服务器存储辣椒，但服务器表示支持辣椒搜索，或服务器表示应生成新辣椒，则对等方生成足够长度的随机均匀分布辣椒（服务器支持的最大长度在服务器的OTP TLV中提供），并在PBKDF2计算中包含新的pepper。
If the peer does not have a pepper stored for this server, and the server did not indicate support for pepper searching, then a pepper will not be used in the response computation.
如果对等方没有为此服务器存储pepper，并且服务器没有表示支持pepper搜索，则响应计算中将不会使用pepper。
Clearly, if the peer itself does not support the use of pepper, then a pepper will not be used in the response computation.
显然，如果对等方本身不支持使用pepper，那么响应计算中将不会使用pepper。
c. The EAP server may, in its subsequent Confirm TLV, provide a pepper to the peer for later use. In this case, the pepper will be substantially longer than a peer-chosen pepper, and encrypted with a key derived from the PBKDF2 computation.
c. EAP服务器可在其随后的确认TLV中向对等方提供一个pepper以供以后使用。在这种情况下，pepper将比对等方选择的pepper长很多，并使用从PBKDF2计算派生的密钥进行加密。
The above procedure allows for pepper updates to be initiated by either side, e.g., based on policy. Since the pepper can be seen as a MAC key, its lifetime should be limited.
上述程序允许任何一方启动pepper更新，例如，基于策略。由于pepper可以被看作是一个MAC密钥，所以它的生命周期应该是有限的。
An EAP server that is not capable of storing pepper values for each user it is authenticating may still support the use of pepper; the cost for this will be the extra computation time to do pepper searches. This cost is still substantially lower than the cost for
不能为其正在认证的每个用户存储pepper值的EAP服务器可能仍然支持pepper的使用；这样做的代价是进行pepper搜索所需的额外计算时间。这一成本仍然大大低于生产成本
an attacker, however, since the server already knows the underlying OTP.
但是，由于服务器已经知道底层OTP，因此攻击者可能会受到攻击。
In protected mode, EAP-POTP uses MACs for authentication purposes, as well as to ensure the integrity of protocol sessions. This section defines how the MACs are calculated and the rationale for the design.
在保护模式下，EAP-POTP使用MAC进行身份验证，并确保协议会话的完整性。本节定义了MAC的计算方式和设计原理。
In protected mode, and when resuming a previous session, rather than sending authenticating credentials (such as one-time passwords or shared keys) directly, evidence of knowledge of the credentials is sent. This evidence is a MAC on the hash of (certain parts of) EAP-POTP messages exchanged so far in a session using a key K_MAC:
在受保护模式下，当恢复上一个会话时，将发送凭据知识的证据，而不是直接发送身份验证凭据（例如一次性密码或共享密钥）。该证据是迄今为止在会话中使用密钥K_MAC交换的EAP-POTP消息（某些部分）散列上的MAC：
mac = MAC(K_MAC, msg_hash(msg_1, msg_2, ..., msg_n))
mac = MAC(K_MAC, msg_hash(msg_1, msg_2, ..., msg_n))
where
哪里
"MAC" is the negotiated MAC algorithm, "K_MAC" is a key derived as specified in Section 4.5, and "msg_hash(msg_1, msg_2, ..., msg_n)" is the message hash defined below of messages msg_1, msg_2, ..., msg_n.
“MAC”是协商MAC算法，“K_MAC”是根据第4.5节规定派生的密钥，“msg_散列（msg_1，msg_2，…，msg_n）”是下文定义的消息msg_1，msg_2，…，msg_n的消息散列。
To compute a message hash for the MAC, given a sequence of EAP messages msg_1, msg_2, ..., msg_n, the following operations shall be carried out:
为了计算MAC的消息散列，给定EAP消息msg_1、msg_2、…、msg_n的序列，应执行以下操作：
a. Re-transmitted messages are removed from the sequence of messages.
a. 重新传输的消息将从消息序列中删除。
Note: The resulting sequence of messages must be an alternating sequence of EAP Request and EAP Response messages.
注意：产生的消息序列必须是EAP请求和EAP响应消息的交替序列。
b. The contents (i.e., starting with the EAP "Type" field and excluding the EAP "Code", "Identifier", and "Length" fields) of each message, msg_1, msg_2, ..., msg_n, is concatenated together.
b. 每条消息msg_1、msg_2、…、msg_n的内容（即，从EAP“Type”字段开始，不包括EAP“Code”、“Identifier”和“Length”字段）连接在一起。
c. User identifier TLVs MUST NOT be included in the hash (this is to allow for a backend service that does not know about individual user names), i.e., any such TLV is removed from the message in which it appeared.
c. 散列中不得包含用户标识符TLV（这是为了允许后端服务不知道单个用户名），也就是说，任何此类TLV都将从其出现的消息中删除。
d. The resulting string is hashed using the negotiated hash algorithm.
d. 使用协商哈希算法对结果字符串进行哈希。
The reason for excluding the "Identifier" field is that the actual, transmitted "Identifier" field is not always known to the EAP method layer. The reason for excluding the "Length" field is to allow the possibility for an intermediary to remove or replace a Username TLV (e.g., for anonymity or service reasons) before passing a received response on to an authentication server. While this on the surface may appear as bad security practice, it may in practice only result in denial of service, something which always may be achieved by an attacker able to modify messages in transit. By excluding the "Code" field, the hash is simply calculated on applicable sent and received message contents. Excluding the "Code" field is regarded as harmless since the hash is to be made on the sequence of POTP-X messages, all having alternating (known) Code values, namely 1 (Request) and 2 (Response).
排除“标识符”字段的原因是EAP方法层并不总是知道实际传输的“标识符”字段。排除“长度”字段的原因是允许中介在将接收到的响应传递给身份验证服务器之前删除或替换用户名TLV（例如，出于匿名或服务原因）。虽然这表面上看起来可能是一种糟糕的安全做法，但实际上可能只会导致拒绝服务，攻击者可以通过修改传输中的消息来实现这一点。通过排除“Code”字段，只需根据适用的已发送和已接收消息内容计算哈希值。排除“代码”字段被认为是无害的，因为散列将在POTP-X消息序列上进行，所有消息都具有交替（已知）代码值，即1（请求）和2（响应）。
To save on storage space, each EAP entity may partially hash messages as they are sent and received (e.g., HashInit(); HashUpdate(message 1); ...; HashUpdate(message n-1); HashFinal(message n)). This reduces the amount of state needed for this purpose to the internal state required for the negotiated hash algorithm.
为了节省存储空间，每个EAP实体可以在发送和接收消息时部分散列消息（例如，HashInit（）；HashUpdate（消息1）；…；HashUpdate（消息n-1）；HashFinal（消息n））。这将为此目的所需的状态量减少到协商哈希算法所需的内部状态。
A summary of the EAP-POTP packet format is shown below. The fields are transmitted from left to right.
EAP-POTP数据包格式的摘要如下所示。字段从左向右传输。
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 | Reserved | TLV-based EAP-POTP message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved | TLV-based EAP-POTP message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
密码
1 - Request
1-请求
2 - Response
2-回应
Identifier
标识符
The Identifier field is 1 octet and aids in matching responses with requests. For a more detailed description of this field and how to use it, see [1].
标识符字段为1个八位字节，有助于将响应与请求匹配。有关此字段及其使用方法的更详细说明，请参见[1]。
Length
长
The Length field is 2 octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, Version, Flags, and TLV-based EAP-POTP message fields.
长度字段为2个八位字节，表示EAP数据包的长度，包括代码、标识符、长度、类型、版本、标志和基于TLV的EAP-POTP消息字段。
Type
类型
Identifies use of a particular OTP algorithm with EAP-POTP.
识别特定OTP算法在EAP-POTP中的使用。
Reserved
含蓄的
This octet is reserved for future use. It SHALL be set to zero for this version. Recipients SHALL ignore this octet for this version of EAP-POTP.
此八位字节保留供将来使用。对于该版本，应将其设置为零。对于此版本的EAP-POTP，收件人应忽略此八位字节。
TLV-based EAP-POTP message
基于TLV的EAP-POTP报文
This field will contain 0, 1, or more Type-Length-Value triplets defined as follows (this is similar to the EAP-TLV TLVs defined in PEAPv2 [17], and the explanation of the generic fields is borrowed from that document).
此字段将包含以下定义的0、1或更多类型长度值三元组（类似于PEAPv2[17]中定义的EAP-TLV TLV，对通用字段的解释从该文档中借用）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Non-mandatory TLV
0-非强制性TLV
1 - Mandatory TLV
1-强制性TLV
The TLVs within EAP POTP-X are used to carry parameters between the EAP peer and the EAP server. An EAP peer may not necessarily implement all the TLVs supported by an EAP server, and to allow for interoperability, a special TLV allows an EAP server to discover if a TLV is supported by the EAP peer.
EAP POTP-X中的TLV用于在EAP对等方和EAP服务器之间传输参数。EAP对等方可能不一定实现EAP服务器支持的所有TLV，为了实现互操作性，特殊TLV允许EAP服务器发现EAP对等方是否支持TLV。
The mandatory bit in a TLV indicates that if the peer or server does not support the TLV, it MUST send a NAK TLV in response; all other TLVs in the message MUST be ignored. If an EAP peer or server finds an unsupported TLV that is marked as non-mandatory (i.e., optional), it MUST NOT send a NAK TLV on this ground only.
TLV中的强制位表示，如果对等方或服务器不支持TLV，则必须发送NAK TLV作为响应；必须忽略消息中的所有其他TLV。如果EAP对等方或服务器发现标记为非强制性（即可选）的不受支持的TLV，则不得仅以此为理由发送NAK TLV。
The mandatory bit does not imply that the peer or server is required to understand the contents of the TLV. The appropriate response to a supported TLV with content that is not understood is defined by the specification of the particular TLV.
强制位并不意味着对等方或服务器需要理解TLV的内容。特定TLV的规范定义了对具有不可理解内容的受支持TLV的适当响应。
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of the EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
The following TLV types are defined for use with EAP-POTP:
以下TLV类型定义用于EAP-POTP：
0 - Reserved for future use 1 - Version 2 - Server-Info 3 - OTP 4 - NAK 5 - New PIN 6 - Confirm 7 - Vendor-Specific 8 - Resume 9 - User Identifier 10 - Token Key Identifier 11 - Time Stamp 12 - Counter 13 - Keep-Alive 14 - Protected 15 - Crypto Algorithm 16 - Challenge
0-保留供将来使用1-版本2-服务器信息3-OTP 4-NAK 5-新PIN 6-确认7-特定供应商8-简历9-用户标识符10-令牌密钥标识符11-时间戳12-计数器13-保持活动14-受保护15-加密算法16-质询
These TLVs are defined in the following. With the exception of the NAK TLV, a particular TLV type MUST NOT appear more than once in a message of type POTP-X.
这些TLV定义如下。除NAK TLV外，特定TLV类型在POTP-X类型的消息中不得出现多次。
Length
长
The length of the Value field in octets.
值字段的长度（以八位字节为单位）。
Value
价值
The value of the TLV.
TLV的值。
The Version TLV carries information about the supported EAP-POTP method version.
TLV版本包含有关支持的EAP-POTP方法版本的信息。
This TLV MUST be present in the initial EAP-Request of type POTP-X from the EAP server and in the initial response of type POTP-X from the peer. It MUST NOT be present in any subsequent EAP-Request or EAP-Response in the session. The Version TLV MUST be supported by all peers, and all EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV. The version negotiation procedure is described in detail in Section 4.2.
该TLV必须出现在EAP服务器发出的POTP-X类型的初始EAP请求和对等方发出的POTP-X类型的初始响应中。它不得出现在会话中的任何后续EAP请求或EAP响应中。TLV版本必须得到所有对等方和所有符合本规范的EAP服务器的支持，并且不得使用NAK TLV进行响应。第4.2节详细描述了版本协商程序。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Highest | Lowest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Highest | Lowest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1-强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
1
1.
Length
长
3 in EAP-Requests, 2 in EAP-Responses
EAP请求中有3个，EAP响应中有2个
Reserved
含蓄的
Reserved for future use. This octet MUST be set to zero for this version. Recipients SHALL ignore this octet for this version of EAP-POTP.
保留供将来使用。对于此版本，此八位字节必须设置为零。对于此版本的EAP-POTP，收件人应忽略此八位字节。
Highest
最高
This field contains an unsigned integer representing the highest protocol version supported by the sender. If a value provided by a peer to an EAP server falls between the server's "Highest" and "Lowest" supported version (inclusive), then that value will be the negotiated version for the authentication session.
此字段包含一个无符号整数，表示发送方支持的最高协议版本。如果EAP服务器的对等方提供的值介于服务器支持的“最高”和“最低”版本（含）之间，则该值将是认证会话的协商版本。
Lowest
最低的
This field contains an unsigned integer representing the lowest version acceptable by the EAP server. The field MUST be present in an EAP-Request. The field MUST NOT be present in an EAP-Response. A peer SHALL respond to an EAP-Request of type POTP-X with an EAP-Response of type Nak (3) if the peer's highest supported version is lower than the value of this field.
此字段包含一个无符号整数，表示EAP服务器可接受的最低版本。该字段必须出现在EAP请求中。该字段不得出现在EAP响应中。如果对等方支持的最高版本低于此字段的值，则对等方应使用Nak（3）类型的EAP响应响应POTP-X类型的EAP请求。
This document defines version 1 of the protocol. Therefore, EAP server implementations conforming to this document SHALL set the "Highest" field to 1. Peer implementations conforming to this document SHALL set the "Highest" field to 1.
本文件定义了协议的第1版。因此，符合本文件要求的EAP服务器实施应将“最高”字段设置为1。符合本文件要求的同行实施应将“最高”字段设置为1。
The Server-Info TLV carries information about the EAP server and the session (when applicable). It provides one piece in the framework for fast session resumption.
服务器信息TLV携带有关EAP服务器和会话的信息（如果适用）。它为快速会话恢复提供了一个框架。
This TLV SHOULD always be present in an EAP-Request of type POTP-X that also carries an OTP TLV, as long as the peer has not been authenticated, and MUST be present in such a request if the server supports session resumption. It MUST NOT be present in any other EAP-Request of type POTP-X or in any EAP-Response packets. This TLV type MUST be supported by all peers conforming to this specification and MUST NOT be responded to with a NAK TLV (this is not to say that all peers need to support session resumption, only that they cannot respond to this TLV with a NAK TLV).
该TLV应始终存在于POTP-X类型的EAP请求中，该请求还携带OTP TLV，只要对等方未通过身份验证，并且如果服务器支持会话恢复，则该TLV必须存在于该请求中。它不得出现在POTP-X类型的任何其他EAP请求或任何EAP响应数据包中。此TLV类型必须由符合本规范的所有对等方支持，并且不得使用NAK TLV响应（这并不是说所有对等方都需要支持会话恢复，只是他们不能使用NAK TLV响应此TLV）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |N| Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sess.Id (cont.)| Nonce ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |N| Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sess.Id (cont.)| Nonce ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1-强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
2
2.
Length
长
25 + length of Server Identifier field
25+服务器标识符字段的长度
Reserved
含蓄的
Reserved for future use. All 7 bits MUST be set to zero for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。此版本的所有7位必须设置为零。对于此版本的EAP-POTP，收件人应忽略此位。
N
N
The N bit signals that the peer MUST NOT attempt to resume any session it has stored associated with this server.
N位表示对等方不得尝试恢复其存储的与此服务器关联的任何会话。
Session Identifier
会话标识
An 8-octet identifier for the session about to be negotiated. Note that, in the case of session resumption, this session identifier will not be used (the session identifier for the resumed session will continue to be used).
将要协商的会话的8个八位字节标识符。请注意，在会话恢复的情况下，将不使用此会话标识符（将继续使用恢复会话的会话标识符）。
Nonce
暂时
A 16-octet nonce chosen by the server. During session resumption, this nonce is used when calculating new K_ENC, K_MAC, SRK, MSK, and EMSK keys as specified below.
服务器选择的16个八位字节的nonce。在会话恢复期间，在计算新的K_ENC、K_MAC、SRK、MSK和EMSK密钥时使用此nonce，如下所述。
Server Identifier
服务器标识符
An identifier for the authentication server. The peer MAY use this identifier to search for a stored session associated with this server, or to associate the session to be negotiated with the server. The value of the identifier SHOULD be chosen so as to reduce the risk of collisions with other EAP server identifiers as much as possible. One possibility is to use the DNS name of the EAP server. The identifier MAY also be used by the peer to select a suitable key on the OTP token (when there are multiple keys available).
身份验证服务器的标识符。对等方可以使用此标识符搜索与此服务器关联的存储会话，或者将要与服务器协商的会话关联起来。应选择标识符的值，以尽可能降低与其他EAP服务器标识符发生冲突的风险。一种可能是使用EAP服务器的DNS名称。对等方还可以使用该标识符在OTP令牌上选择合适的密钥（当存在多个可用密钥时）。
The identifier MUST NOT be longer than 128 octets. The identifier SHALL be a UTF-8 [7] encoded string of printable characters (without any terminating NULL character).
标识符的长度不得超过128个八位字节。标识符应为UTF-8[7]编码的可打印字符字符串（无任何终止空字符）。
In an EAP-Request, the OTP TLV is used to request an OTP (or a value derived from an OTP) from the peer. In an EAP-Response, the OTP TLV carries an OTP or a value derived from an OTP.
在EAP请求中，OTP TLV用于向对等方请求OTP（或从OTP派生的值）。在EAP响应中，OTP TLV携带OTP或源自OTP的值。
This TLV type MUST be supported by all peers and all EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV. The OTP TLV MUST NOT be present in an EAP-Request of type POTP-X that contains a New PIN TLV. Further, the OTP TLV MUST NOT be present in an EAP-Response of type POTP-X unless the preceding EAP-Request of type POTP-X contained an OTP TLV and it was valid for it to do so. Finally, an OTP TLV MUST NOT be present in an EAP-Response of type POTP-X that also contains a Resume TLV. The OTP TLV is defined as follows:
符合本规范的所有对等方和所有EAP服务器必须支持此TLV类型，并且不得使用NAK TLV响应。OTP TLV不得出现在包含新PIN TLV的POTP-X类型EAP请求中。此外，OTP TLV不得出现在POTP-X类型的EAP响应中，除非前面的POTP-X类型的EAP请求包含OTP TLV并且这样做是有效的。最后，OTP TLV不得出现在也包含恢复TLV的POTP-X类型EAP响应中。OTP TLV的定义如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |A|P|C|N|T|E|S| Pepper Length |Iteration Count|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Iteration Count (cont.) | Auth. Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |A|P|C|N|T|E|S| Pepper Length |Iteration Count|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Iteration Count (cont.) | Auth. Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1-强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
3
3.
Length
长
7 + length of Authentication Data field
7+验证数据字段的长度
Reserved
含蓄的
Reserved for future use. All 9 bits SHALL be set to zero (0) for this version. Recipients SHALL ignore these bits for this version of EAP-POTP.
保留供将来使用。对于该版本，所有9位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略这些位。
A
A.
The A bit MUST be set in an EAP-Request if and only if the request immediately follows an EAP-Response of type POTP-X containing a New PIN TLV (see Section 4.11.5), and the new PIN in the response was accepted by the EAP server. In this case, the A bit signals that the EAP-server has accepted the PIN, and that the peer SHALL use the newly established PIN when calculating the response (when applicable). The A bit MUST NOT be set if the S bit is set. If a request has both the S bit and the A bit set, the peer SHALL regard the request as invalid, and return an empty POTP-X EAP-Response message.
当且仅当请求紧跟在包含新PIN TLV的POTP-X类型EAP响应之后（见第4.11.5节），且EAP服务器接受响应中的新PIN时，必须在EAP请求中设置A位。在这种情况下，A位表示EAP服务器已接受PIN，并且对等方在计算响应时应使用新建立的PIN（如果适用）。如果设置了S位，则不得设置A位。如果请求同时设置了S位和a位，则对等方应将该请求视为无效，并返回空POTP-X EAP响应消息。
In an EAP-Response, the A bit, when set, indicates that the OTP was calculated with the use of the newly selected user PIN. The A bit MUST be set in a response if and only if the EAP-Request which triggered the response contained an OTP TLV with the A bit set.
在EAP响应中，设置A位时，表示OTP是使用新选择的用户PIN计算的。当且仅当触发响应的EAP请求包含设置了A位的OTP TLV时，必须在响应中设置A位。
P
P
In an EAP-Request, the P bit indicates that the OTP in the response MUST be protected. Use of this bit also indicates that mutual authentication will take place, as well as generation of keying material. It is RECOMMENDED to always set the P bit. If a peer receives an EAP-Request with an OTP TLV that does not have the P bit set, and the peer's policy dictates protected mode, the peer MUST respond with an empty POTP-X EAP-Response message. All peers MUST support protected mode.
在EAP请求中，P位表示必须保护响应中的OTP。使用该位还表明将进行相互认证，并生成密钥材料。建议始终设置P位。如果对等方接收到EAP请求，且OTP TLV未设置P位，且对等方的策略指示保护模式，则对等方必须使用空POTP-X EAP响应消息进行响应。所有对等方必须支持受保护模式。
In an EAP-Response, this bit indicates that the provided OTP has been protected (see below). The P bit MUST be set in a response (and hence the OTP MUST be protected) if and only if the EAP-Request that triggered the response contained an OTP TLV with the P bit set.
在EAP响应中，该位表示提供的OTP已受到保护（见下文）。当且仅当触发响应的EAP请求包含设置了P位的OTP TLV时，必须在响应中设置P位（因此必须保护OTP）。
In an 802.1x EAP over LAN (EAPOL) environment (this includes wireless LAN environments), the P bit MUST be set, or, alternatively, the EAP-POTP method MUST be carried out inside an authenticated tunnel that provides a cryptographic binding with inner EAP methods such as the one provided by PEAPv2 [17].
在802.1x EAP over LAN（EAPOL）环境（包括无线LAN环境）中，必须设置P位，或者，EAP-POTP方法必须在经过身份验证的隧道内执行，该隧道提供与内部EAP方法（如PEAPv2提供的方法）的加密绑定[17]。
C
C
The C bit carries meaning only when the OTP algorithm in question makes use of server challenges. For other OTP algorithms, the C bit SHALL always be set to zero.
只有当所讨论的OTP算法利用服务器挑战时，C位才有意义。对于其他OTP算法，C位应始终设置为零。
In an EAP-Request, the C bit ("Combine") indicates that the OTP SHALL be calculated using both the provided challenge and internal state (e.g., current token time). The OTP SHALL be calculated based only on the provided challenge (and the shared secret) if the C bit is not set, and a challenge is present. The returned OTP SHALL always be calculated based on the peer's current state (and the shared secret) if no challenge is present. If the C bit is set but no challenge is provided, the peer SHALL regard the request as invalid, and return an empty POTP-X EAP-Response message.
在EAP请求中，C位（“组合”）表示OTP应使用提供的质询和内部状态（例如，当前令牌时间）来计算。如果未设置C位且存在质询，则仅根据提供的质询（和共享秘密）计算OTP。如果不存在质询，则返回的OTP应始终基于对等方的当前状态（和共享秘密）进行计算。如果设置了C位但未提供质询，则对等方应将请求视为无效，并返回一条空的POTP-X EAP响应消息。
In an EAP response, this bit indicates that the provided OTP has been calculated using a provided challenge and the token state. The C bit MUST be set in a response if and only if the EAP-Request that triggered the response contained an OTP TLV with the C bit set and a challenge.
在EAP响应中，此位表示已使用提供的质询和令牌状态计算提供的OTP。当且仅当触发响应的EAP请求包含设置了C位的OTP TLV和质询时，必须在响应中设置C位。
N
N
In an EAP-Request, the N bit, when set, indicates that the OTP to calculate SHALL be based on the next token "state", and not the current one. As an example, for a time-based token, this means the next time slot. For an event-based token, this could mean the next counter value, if counter values are used. This bit will normally not be set in initial EAP-Request messages, but may be set in subsequent ones. Further, the N bit carries no meaning in an EAP-Request if a challenge is present and the C bit is not set, and SHALL be set to 0, in this case. If a request that has the N bit set also contains a challenge, but does not have the C bit set, the peer SHALL regard the request as invalid, and return an empty POTP-X EAP-Response message. Note that setting the N bit in an EAP-Request will normally advance the internal state of the token.
在EAP请求中，当设置N位时，表示要计算的OTP应基于下一个令牌“状态”，而不是当前令牌。例如，对于基于时间的令牌，这意味着下一个时隙。对于基于事件的令牌，如果使用计数器值，这可能意味着下一个计数器值。该位通常不会在初始EAP请求消息中设置，但可以在后续消息中设置。此外，如果存在质询且未设置C位，则N位在EAP请求中没有意义，并且在这种情况下应设置为0。如果设置了N位的请求也包含质询，但未设置C位，则对等方应将该请求视为无效，并返回空的POTP-X EAP响应消息。请注意，在EAP请求中设置N位通常会提升令牌的内部状态。
In an EAP-Response, the N bit, when set, indicates that the OTP was calculated based on the next token "state" (as explained above), and not the current one. The N bit MUST be set in a response if and only if the EAP-Request that triggered the response contained an OTP TLV with the N bit set.
在EAP响应中，设置N位时，表示OTP是基于下一个令牌“状态”（如上所述）而不是当前令牌“状态”计算的。当且仅当触发响应的EAP请求包含设置了N位的OTP TLV时，必须在响应中设置N位。
T
T
The T bit only carries meaning for OTP methods normally incorporating a user PIN in the OTP computation.
T位仅对OTP计算中通常包含用户PIN的OTP方法具有意义。
In an EAP-Request, the T bit, when set, indicates that the OTP to calculate MUST NOT include a user PIN.
在EAP请求中，设置T位时，表示要计算的OTP不得包括用户PIN。
In an EAP-Response, the T bit, when set, indicates that the OTP was calculated without the use of a user PIN. The T bit MUST be set in a response if and only if the EAP-Request that triggered the response contained an OTP TLV with the T bit set. Note that client policy may prohibit PIN-less calculations; in these cases, the client MAY respond with an empty POTP-X EAP response message.
在EAP响应中，设置T位时，表示OTP是在不使用用户PIN的情况下计算的。当且仅当触发响应的EAP请求包含设置了T位的OTP TLV时，必须在响应中设置T位。请注意，客户端策略可能禁止无针计算；在这些情况下，客户端可能会使用空的POTP-X EAP响应消息进行响应。
E
E
In an EAP-Request, the E bit, when set, indicates that the peer MUST NOT use any stored pepper value associated with this server in the PBKDF2 computation. Rather, it MUST generate a new pepper (if supported by the peer) and/or use the iteration count parameter to protect the OTP (if the server's Max Pepper Length is 0, then the peer MUST rely on the iteration count only to protect the OTP). This bit will usually not be set in initial EAP-Request messages, but may be set in subsequent ones, e.g., if the server, upon receipt of an OTP TLV with a pepper identifier, detects that it does not have a pepper with that identifier in storage. This bit carries no meaning, and MUST be set to zero, when the P bit is not set. If a request has the E bit set but not the P bit, a peer SHALL regard the request as invalid, and return an empty POTP-X EAP-Response message.
在EAP请求中，设置E位时，表示对等方不得在PBKDF2计算中使用与此服务器关联的任何存储值。相反，它必须生成新的pepper（如果对等方支持）和/或使用迭代计数参数来保护OTP（如果服务器的最大pepper长度为0，则对等方必须仅依赖迭代计数来保护OTP）。该位通常不会在初始EAP请求消息中设置，但可以在后续消息中设置，例如，如果服务器在接收到带有pepper标识符的OTP TLV时检测到其存储器中没有带有该标识符的pepper。当P位未设置时，该位没有意义，必须设置为零。如果请求设置了E位而没有P位，则对等方应将该请求视为无效，并返回空的POTP-X EAP响应消息。
In an EAP-Response, the E bit indicates that the response has been calculated without use of any stored pepper value.
在EAP响应中，E位表示已在不使用任何存储值的情况下计算响应。
S
s
In an EAP-Request, the S bit ("Same"), when set, indicates that the peer SHOULD calculate its response based on the same OTP value as was used for the preceding response. This bit MAY be set when the EAP server has received an OTP TLV from the peer protected with a pepper, of which the server is no longer in possession. Since the server has not attempted validation of the provided data, there is no need for the EAP peer to retrieve a new OTP value. This bit carries no meaning, and MUST be set to zero, when the E bit is not set. A peer SHALL regard a request where the S bit is set, but not the E bit, as invalid, and return an empty POTP-X EAP-Response message. Further, the S bit MUST NOT be set when the A bit also is set; see above.
在EAP请求中，S位（“相同”）在设置时表示对等方应基于与前一响应相同的OTP值来计算其响应。当EAP服务器从受pepper保护的对等方接收到OTP TLV时，可以设置此位，该对等方不再拥有该服务器。由于服务器未尝试验证提供的数据，因此EAP对等方无需检索新的OTP值。当未设置E位时，该位没有意义，必须设置为零。对等方应将设置了S位而不是E位的请求视为无效，并返回空POTP-X EAP响应消息。此外，当还设置了A位时，不能设置S位；见上文。
In an EAP-Response, the S bit is never set.
在EAP响应中，从不设置S位。
Pepper Length
辣椒长度
This octet SHALL be present if and only if the P bit is set. When present, it contains an unsigned integer, having a value between 0 and 255 (inclusive). In an EAP-Request, the integer represents the maximum length (in bits) of a client-generated pepper the server is prepared to search for. Peers MUST NOT generate peppers longer than this value. If the value is set to zero, it means the peer MUST NOT generate a pepper for the PBKDF2 calculation. In an EAP-Response, it indicates the length of the used pepper.
当且仅当设置了P位时，该八位组才存在。当存在时，它包含一个无符号整数，其值介于0和255（含0和255）之间。在EAP请求中，整数表示服务器准备搜索的客户端生成的数据的最大长度（以位为单位）。同级生成的Pepper的时间不得超过此值。如果该值设置为零，则表示对等方不得为PBKDF2计算生成pepper。在EAP响应中，它表示所用胡椒的长度。
Iteration Count
迭代计数
These 4 octets SHALL be present if and only if the P bit is set. When present, they contain an unsigned, 4-octet integer in network byte order. In an EAP-Request, the integer represents the maximum iteration count the peer may use in the PBKDF2 computation. Peers MUST NOT use iteration counts higher than this value. In an EAP-Response, it indicates the actual iteration count used.
当且仅当设置了P位时，应存在这4个八位字节。当存在时，它们包含一个网络字节顺序的无符号4八位整数。在EAP请求中，整数表示对等方可在PBKDF2计算中使用的最大迭代计数。对等方不得使用高于此值的迭代计数。在EAP响应中，它指示使用的实际迭代计数。
Note regarding the Pepper Length and Iteration Count parameters: A peer MUST compare these policy parameters provided by the EAP server with local policy and MUST NOT continue the handshake if use of the EAP server's suggested parameters would result in a lower security than the client's acceptable policy. If the security given by the EAP server's provided policy parameters surpasses the security level given by the peer's local policy, the client SHOULD use the server's parameters (subject to reason - active attackers could otherwise mount simple denial-of-service attacks against peers or servers, e.g., by providing unreasonably high values for the iteration count). Note that the server-provided parameters only apply to the case where the peer cannot use or does not have a previously provided server-provided pepper. If a peer cannot continue the handshake due to the server's policy being unacceptable, it MUST return an empty POTP-X EAP-Response message.
关于Pepper长度和迭代计数参数的注意事项：对等方必须将EAP服务器提供的这些策略参数与本地策略进行比较，并且如果使用EAP服务器的建议参数将导致低于客户端可接受策略的安全性，则不得继续握手。如果EAP服务器提供的策略参数提供的安全性超过对等方本地策略提供的安全性级别，则客户端应使用服务器参数（根据原因-主动攻击者可能会对对等方或服务器发起简单的拒绝服务攻击，例如，通过提供不合理的高迭代计数值）。请注意，服务器提供的参数仅适用于对等方无法使用或没有先前提供的服务器提供的参数的情况。如果对等方由于服务器的策略不可接受而无法继续握手，则必须返回空的POTP-X EAP响应消息。
Authentication Data
认证数据
EAP-Request: In an EAP-Request, the Authentication Data field, when present, contains an optional "challenge". The challenge is an octet string that SHOULD be uniquely generated for each request in which it is present (i.e., it is a "nonce"), and SHOULD be 8 octets or longer. To avoid fragmentation (i.e., EAP messages longer than the minimum EAP MTU size; see [1]), the challenge MUST NOT be longer than 64 octets. When the challenge is not present, the OTP will be calculated on the current token state only. The peer MAY ignore a provided challenge if and only if the OTP token the peer is interacting with is not capable of including a challenge in the OTP calculation. In this case, EAP server policies will determine whether or not to accept a provided OTP value.
EAP请求：在EAP请求中，身份验证数据字段（如果存在）包含可选的“质询”。质询是一个八位字节字符串，它应该为存在它的每个请求唯一地生成（即，它是一个“nonce”），并且应该是8个八位字节或更长。为避免碎片（即EAP消息长度超过最小EAP MTU大小；请参见[1]），质询长度不得超过64个八位字节。当质询不存在时，将仅根据当前令牌状态计算OTP。当且仅当对等方与之交互的OTP令牌不能在OTP计算中包括质询时，对等方可以忽略提供的质询。在这种情况下，EAP服务器策略将决定是否接受提供的OTP值。
EAP-Response: The following applies to the Authentication Data field in an EAP-Response:
EAP响应：以下内容适用于EAP响应中的身份验证数据字段：
* When the P bit is not set, the peer SHALL directly place the OTP value calculated by the token in the Authentication Data field. In this case, the EAP server MUST NOT send a Confirm
* 当未设置P位时，对等方应直接将令牌计算的OTP值放入认证数据字段中。在这种情况下，EAP服务器不得发送确认消息
TLV upon successful authentication of the peer (instead, it sends an EAP-Success message).
成功验证对等方后的TLV（而是发送EAP成功消息）。
* When the P bit is set, the peer SHALL populate this field as follows. After the token has calculated the OTP value, the peer SHALL compute:
* 设置P位时，对等方应按如下方式填充此字段。令牌计算OTP值后，对等方应计算：
K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(otp, salt | pepper | auth_id, iteration_count, key_length)
K|U MAC | K|U ENC | MSK | EMSK | SRK=PBKDF2（otp、盐|胡椒|认证id、迭代次数、密钥长度）
where
哪里
"|" denotes concatenation,
“|”表示串联，
"otp" is the already computed OTP value,
“otp”是已计算的otp值，
"salt" is a 16-octet nonce,
“salt”是一个16个八位组的符号，
"pepper" is an optional nonce (at most, 255 bits long, and, if necessary, padded to be a multiple of 8 bits long; see below) included to complicate the task of finding a matching "otp" value for an attacker,
“pepper”是一个可选的nonce（最多255位长，如有必要，填充为8位长的倍数；见下文），用于使攻击者查找匹配的“otp”值的任务复杂化，
"auth_id" is an identifier (at most, 255 octets in length) for the authenticator (i.e., the network access server) as reported by lower layers and as specified below,
“auth_id”是认证器（即网络访问服务器）的标识符（长度最多255个八位字节），由较低层报告，如下所述：，
"iteration_count" is an iteration count chosen such that the computation time on the peer is acceptable (based on the server's indicated policy and the peer's local policy), while an attacker, having observed the response and initiating a search for a matching OTP, will be sufficiently slowed down. The "iteration_count" value MUST be chosen to provide a suitable level of protection (e.g., at least 100,000) unless a server-provided pepper is being used, in which case, it SHOULD be 1.
“iteration_count”是一种迭代计数，它的选择应确保对等方上的计算时间是可接受的（基于服务器的指示策略和对等方的本地策略），而攻击者在观察到响应并开始搜索匹配的OTP后，其速度将大大减慢。必须选择“迭代计数”值以提供适当的保护级别（例如，至少100000），除非正在使用服务器提供的值，在这种情况下，该值应为1。
"key_length" is the combined length of the desired key material, in octets. When the default algorithms are used, key_length is 176.
“密钥长度”是所需密钥材料的组合长度，以八位字节为单位。使用默认算法时，密钥长度为176。
The "pepper" values are only included in PBKDF2 calculations and are never sent to EAP servers (though the peers do send their length, in bits). The purpose of the pepper values are, as mentioned above, to slow down an attacker's search for a matching OTP, while not slowing down the peer (which iterated hashes do). If the pepper has been generated by the peer, and the chosen pepper length in bits is not a
“pepper”值仅包含在PBKDF2计算中，不会发送到EAP服务器（尽管对等方确实发送其长度，以位为单位）。如上所述，pepper值的目的是减慢攻击者对匹配OTP的搜索速度，同时不会减慢对等方的搜索速度（迭代哈希就是这样做的）。如果pepper是由对等方生成的，并且选择的pepper长度（以位为单位）不是
multiple of 8, then the pepper value SHALL be padded to the left, with '0' bits to the nearest multiple of 8 before being used in the PBKDF2 calculation. This is to ensure the input to the calculation consists only of whole octets. As an example, if the chosen pepper length is 4, the pepper value will be padded to the left, with 4 '0' bits to form an octet before being used in the PBKDF2 calculation.
乘以8，则pepper值应向左填充，在用于PBKDF2计算之前，将“0”位精确到8的倍数。这是为了确保计算的输入只包含整个八位字节。例如，如果选择的pepper长度为4，则pepper值将向左填充，在用于PBKDF2计算之前，使用4个“0”位形成八位字节。
When pepper is used, it is RECOMMENDED that the length of the pepper and the iteration count are chosen in such a way that it is computationally infeasible/unattractive for an attacker to brute-force search for the given OTP within the lifetime of that OTP.
使用pepper时，建议选择pepper的长度和迭代计数，使攻击者在该OTP的生存期内对给定OTP进行暴力搜索在计算上不可行/不具吸引力。
As mentioned previously, a peer MUST NOT include a newly generated pepper value in the PBKDF2 computation if the server did not indicate its support for pepper searching in this session. If the server did not indicate support for pepper searching, then the PBKDF2 computation MUST be carried out with a sufficiently higher number of iterations so as to compensate for the lack of pepper (see further Appendix D).
如前所述，如果服务器在此会话中未表示支持pepper搜索，则对等方不得在PBKDF2计算中包含新生成的pepper值。如果服务器未表示支持pepper搜索，则必须以足够高的迭代次数执行PBKDF2计算，以弥补pepper搜索的不足（详见附录D）。
A server may, in an earlier session, have transferred a pepper value to the peer in a Confirm TLV (see below). When this is the case, and the peer still has that pepper value stored for this server, the peer MUST NOT generate a new pepper but MUST, instead, use this transferred pepper value in the PBKDF2 calculations. The only exception to this is when a local policy (e.g., timer) dictates that the peer must switch to a new pepper (and the server indicated support for pepper searching).
在早期会话中，服务器可能已在确认TLV中将pepper值传输给对等方（见下文）。在这种情况下，并且对等方仍为此服务器存储了pepper值，则对等方不得生成新pepper，而是必须在PBKDF2计算中使用此传输的pepper值。唯一的例外是当本地策略（例如计时器）规定对等方必须切换到新的pepper（并且服务器指示支持pepper搜索）时。
The following applies to the auth_id component:
以下内容适用于auth_id组件：
- For dial-up, "auth_id" SHALL be either the empty string or the phone number called by the peer. The phone number SHALL be specified in the form of a URL conformant with RFC 3966 [8], e.g., "tel:+16175550101". Processing of received phone numbers SHALL be conformant with RFC 3966 (this assumes that "tel" URIs will be shorter than 256 octets, which would normally be the case).
- 对于拨号，“auth_id”应为空字符串或对等方呼叫的电话号码。电话号码应以符合RFC 3966[8]的URL形式指定，例如，“电话：+16175550101”。接收到的电话号码的处理应符合RFC 3966（这假设“电话”URI将短于256个八位字节，通常情况下是这样）。
- For use with IEEE 802.1X, "auth_id" SHALL be either the empty string or the MAC address of the authenticator in canonical binary format (6 octets).
- 与IEEE 802.1X一起使用时，“auth_id”应为空字符串或标准二进制格式（6个八位字节）认证器的MAC地址。
- For IP-based EAP, "auth_id" SHALL be either the empty string or the IPv4 or IPv6 address of the authenticator as seen by the peer and in binary format (4 or 16 octets, respectively). As an example, the IPv4 address "192.0.2.5" would be represented as (in hex) C0 00 02 05, whereas the IPv6 address "2001:DB8::101" would be represented as (in hex) 20 01 0D B8 00 00 00 00 00 00 00 00 00 00 01 01.
- 对于基于IP的EAP，“auth_id”应为空字符串或对等方看到的身份验证器的IPv4或IPv6地址，并采用二进制格式（分别为4或16个八位字节）。例如，IPv4地址“192.0.2.5”将表示为（十六进制）C000 02 05，而IPv6地址“2001:DB8:：101”将表示为（十六进制）20 01 0D B8 00 01 01。
Note: Use of the authenticator's identifying information within the computation aids in protection against man-in-the-middle attacks, where a rogue authenticator seeks to intercept and forward the Authentication Data in order to impersonate the peer at a legitimate authenticator (but see also the discussion around spoofed authenticator addresses in Section 6). For these reasons, a peer SHOULD NOT set the auth_id component to the empty string unless it is unable to learn the identifying information of the authenticator. In these cases, the EAP server's policy will determine whether or not the session may continue.
注意：在计算中使用验证器的标识信息有助于防止中间人攻击，其中恶意验证器试图拦截并转发身份验证数据，以便在合法验证器上模拟对等方（但也请参见第6节中有关伪造身份验证程序地址的讨论）。出于这些原因，对等方不应将身份验证id组件设置为空字符串，除非它无法了解身份验证程序的标识信息。在这些情况下，EAP服务器的策略将确定会话是否可以继续。
As an example, when otp = "12345678", salt = 0x54434534543445435465768789099880, pepper is not used, auth_id = "192.0.2.5", iteration_count = 2000 (decimal), and key_length = 176 (decimal), the input to the PBKDF2 calculation will be (first two parameters in hex, line wrap for readability):
当salt=0x45u=decimal时，将使用两个参数（例如，pB5445u=todecimal，todecimal-count=0x45u），并且在第一行中不使用todecimal（例如，todecimal=pb5454u，todecimal.45u）：
(3132333435363738, 54434534543445435465768789099880 | c0000205, 2000, 176)
（31323334353633738544345345434454335465768789099880 | C00002052000176）
As described, when the default algorithms are used, K_MAC is the first 16 octets of the output from PBKDF2, K_ENC the next 16 octets, MSK the following 64 octets, EMSK the next 64 octets, and SRK the final 16 octets. Using K_MAC, the peer calculates:
如上所述，当使用默认算法时，K_MAC是PBKDF2输出的前16个八位字节，K_ENC是下16个八位字节，MSK是下64个八位字节，EMSK是下64个八位字节，SRK是最后16个八位字节。使用K_MAC，对等方计算：
mac = MAC(K_MAC, msg_hash(msg_1, msg_2, ..., msg_n))
mac = MAC(K_MAC, msg_hash(msg_1, msg_2, ..., msg_n))
as specified in Section 4.9 and where msg_1, msg_2, ..., msg_n is a sequence of all EAP messages of type POTP-X exchanged so far in this session, as sent and received by the peer (for the peer's initial MAC, it will typically be just one message: the EAP server's initial EAP-Request of type POTP-X).
如第4.9节所述，其中msg_1、msg_2、…，msg_n是在该会话中迄今为止交换的所有POTP-X类型EAP消息的序列，由对等方发送和接收（对于对等方的初始MAC，它通常仅为一条消息：EAP服务器的POTP-X类型初始EAP请求）。
The peer then places the first 16 octets of "mac" in the Authentication Data field, followed by the "salt" value, followed by one octet representing the length of the "auth_id" value in octets, followed by the actual "auth_id" value in binary form, and optionally followed by a pepper identifier (only when the peer made use of a pepper value previously provided by the EAP server). Pepper identifiers, when present, are always 4 octets. All variables SHALL be present in the form they were input to the PBKDF2 algorithm. This will result in the Authentication Data field being 33 + (length of auth_id in octets) + (4, for pepper identifier, when present) octets in length.
然后，对等方将“mac”的前16个八位字节放在身份验证数据字段中，后跟“salt”值，后跟一个八位字节，表示“auth_id”值的长度（以八位字节为单位），后跟二进制形式的实际“auth_id”值，并可选地后跟一个pepper标识符（仅当对等方使用EAP服务器先前提供的pepper值时）。pepper标识符（当存在时）始终为4个八位字节。所有变量应以输入PBKDF2算法的形式存在。这将导致身份验证数据字段为33+（身份验证id的长度以八位字节为单位）+（4，对于胡椒标识符，如果存在）长度为八位字节。
Continuing the previous example, the Authentication Data field will be populated with (in hex, line wrap for readability):
继续上一个示例，身份验证数据字段将填充（十六进制，换行以便于阅读）：
< 16 octets of mac > | 54434534543445435465768789099880 | 04 | c0000205
mac的<16个八位字节>| 5443453454344535465768789099880 | 04 | c0000205
Note: Since in this case (i.e., when the P bit is set) successful authentication of the peer by the EAP server will be followed by the transmission of an EAP-Request of type POTP-X containing a Confirm TLV for mutual authentication, the peer MUST save either all the input parameters to the PBKDF2 computation or the keys K_MAC, K_ENC, SRK, MSK, and EMSK (recommended, since they will be used later). This is because the peer cannot be guaranteed to be able to generate the same OTP value again. For the same reason (the Confirm-TLV from the EAP server), the peer MUST also store either the hash of the contents of the sent EAP-Response or the EAP-Response itself (but see the note above about not including any User Identifier TLVs in the hash computation).
注意：由于在这种情况下（即，当设置P位时），EAP服务器成功认证对等方之后将传输类型为POTP-X的EAP请求，其中包含用于相互认证的确认TLV，因此对等方必须将所有输入参数保存到PBKDF2计算或密钥K_MAC、K_ENC、SRK、MSK，和EMSK（推荐，因为它们将在以后使用）。这是因为不能保证对等方能够再次生成相同的OTP值。出于同样的原因（来自EAP服务器的确认TLV），对等方还必须存储发送的EAP响应内容的哈希或EAP响应本身（但请参阅上面关于在哈希计算中不包括任何用户标识符TLV的说明）。
Given a set of possible OTP values, the authentication server verifies an authentication request from the peer by computing
给定一组可能的OTP值，身份验证服务器通过计算验证来自对等方的身份验证请求
K_MAC' | K_ENC' | MSK' | EMSK' | SRK' = PBKDF2 (otp', salt | pepper' | auth_id, iteration_count, key_length)
K|MAC'| K|ENC'| MSK'| EMSK'| SRK'=PBKDF2（otp'，salt | pepper'| auth|id，迭代次数，键长）
for each possible OTP value otp' and each possible pepper value pepper' , and the provided values for salt, authenticator identity, and iteration count, as well as the applicable key length (default: 176). Note: Doing the computation for each possible pepper value implements the pepper search mentioned elsewhere in this document. Note also that the EAP server may accept more than one OTP value
对于每个可能的OTP值OTP'和每个可能的pepper值pepper'，以及为salt、验证器标识和迭代计数提供的值，以及适用的密钥长度（默认值：176）。注意：对每个可能的pepper值进行计算将实现本文档其他地方提到的pepper搜索。还要注意，EAP服务器可以接受多个OTP值
at a given time, e.g., due to clock drift in the token. If the given pepper length is not a multiple of 8, each tested pepper value will be padded to the left to the nearest multiple of 8, in the same manner as was done by the peer. If the server already shares a secret pepper value with this peer, then obviously there will only be one possible pepper value, and the server will find it based on the pepper_identifier provided by the peer. The server SHALL send a new EAP-Request of type POTP-X with an OTP TLV with the E bit set if the peer provided a pepper identifier unknown to the server.
在给定时间，例如，由于令牌中的时钟漂移。如果给定的胡椒长度不是8的倍数，则每个测试胡椒值将以与对等方相同的方式向左填充至最接近的8的倍数。如果服务器已经与该对等方共享了一个秘密pepper值，那么显然只有一个可能的pepper值，服务器将根据对等方提供的pepper\u标识符找到它。如果对等方提供了服务器未知的PEPER标识符，则服务器应发送一个新的POTP-X类型的EAP请求，并带有设置了E位的OTP TLV。
For each K_MAC', the EAP server computes
对于每个K_MAC’，EAP服务器计算
mac' = MAC(K_MAC', msg_hash(msg_1', msg_2', ..., msg_n'))
mac' = MAC(K_MAC', msg_hash(msg_1', msg_2', ..., msg_n'))
where MAC is the negotiated MAC algorithm, msg_hash is the message hash algorithm defined in Section 4.9, and msg_1', msg_2', ... msg_n' are the same messages on which the peer calculated its message hash, but this time, as sent and received by the EAP server. If the first 16 octets of mac' matches the first 16 octets in the Authentication Data field of the EAP-Response in question, and the provided authenticator identity is acceptable (e.g., matches the EAP server's view of the authenticator's identity), then the peer is authenticated.
其中MAC是协商MAC算法，msg_哈希是第4.9节中定义的消息哈希算法，msg_1'，msg_2'。。。msg_n'是对等方计算其消息哈希的相同消息，但这次是EAP服务器发送和接收的消息。如果mac’的前16个八位字节与所述EAP响应的认证数据字段中的前16个八位字节匹配，并且提供的认证者身份是可接受的（例如，与EAP服务器的认证者身份视图匹配），则对等方被认证。
If the authentication is successful, the authentication server then attempts to authenticate itself to the peer by use of the Confirm TLV (see below). If the authentication fails, the EAP server MAY send another EAP-Request of type POTP-X containing an OTP TLV to the peer, or it MAY send an EAP-Failure message (in both cases, possibly preceded by an EAP-Request of type Notification).
如果身份验证成功，则身份验证服务器将尝试使用确认TLV（见下文）向对等方进行身份验证。如果认证失败，EAP服务器可以向对等方发送另一个包含OTP TLV的POTP-X类型的EAP请求，或者它可以发送EAP失败消息（在这两种情况下，可能都是在通知类型的EAP请求之前）。
Presence of this TLV indicates that the peer did not support a received TLV with the M bit set. This TLV may occur 0, 1, or more times in an EAP-Response of type POTP-X. Each occurrence flags the non-support of a particular received TLV.
此TLV的存在表示对等方不支持设置了M位的接收TLV。该TLV可能在POTP-X类型的EAP响应中出现0、1或更多次。每次出现都会标记不支持特定接收的TLV。
The NAK TLV MUST be supported by all peers and all EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV. Receipt of a NAK TLV by an EAP server MAY cause an authentication to fail, and the EAP server to send an EAP-Failure message to the peer.
NAK TLV必须得到符合本规范的所有对等方和所有EAP服务器的支持，并且不得使用NAK TLV进行响应。EAP服务器接收到NAK TLV可能导致身份验证失败，并且EAP服务器向对等方发送EAP失败消息。
Note: The definition of the NAK TLV herein matches the definition made in [17], and has the same type number. Field descriptions are copied from that document, with some minor modifications.
注：本文中NAK TLV的定义与[17]中的定义相匹配，并且具有相同的型号。字段描述是从该文档复制的，只做了一些小的修改。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK-Type | TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK-Type | TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1-强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
4
4.
Length
长
6 + cumulative total length of embedded TLVs
6+嵌入式TLV的累计总长度
Vendor-Id
供应商Id
The Vendor-Id field is 4 octets, and contains the Vendor-Id of the TLV that was not supported. The high-order octet is 0 and the low-order 3 octets are the Structure of Management Information (SMI) Network Management Private Enterprise Code of the Vendor in network byte order. The Vendor-Id field MUST be zero for TLVs that are not Vendor-Specific TLVs. For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI code.
供应商Id字段为4个八位字节，包含不受支持的TLV的供应商Id。高阶八位字节为0，低阶三位八位字节为供应商管理信息（SMI）网络管理私有企业代码的网络字节顺序结构。对于非特定于供应商的TLV，供应商Id字段必须为零。对于特定于供应商的TLV，供应商ID必须设置为SMI代码。
NAK-Type
NAK型
The type of the unsupported TLV. The TLV MUST have been included in the most recently received EAP message.
不受支持的TLV的类型。TLV必须包含在最近收到的EAP消息中。
TLVs
阈限值
This field contains a list of TLVs, each of which MUST NOT have the mandatory bit set. These optional TLVs can be used in the future to communicate why the offending TLV was determined to be unsupported.
每个TLV字段必须包含一个非必填的位。将来可以使用这些可选TLV来传达为什么确定不支持有问题的TLV。
In an EAP-Request, the New PIN TLV is used to request a new user PIN from the peer. The EAP server MAY provide a new PIN, as described below. In an EAP-Response, the New PIN TLV carries a chosen new user PIN. This TLV may be used by an EAP server when policy dictates that the peer (user) needs to change a PIN associated with the OTP Token.
在EAP请求中，新PIN TLV用于从对等方请求新用户PIN。EAP服务器可以提供新的PIN，如下所述。在EAP响应中，新PIN TLV携带选定的新用户PIN。当策略规定对等方（用户）需要更改与OTP令牌关联的PIN时，EAP服务器可以使用此TLV。
This TLV type SHOULD be supported by peers and EAP servers conforming to this specification. The New PIN TLV MUST NOT be sent by an EAP server unless the peer has been authenticated. If the peer was authenticated in protected mode, then the New PIN TLV MUST NOT be present in an EAP-Request until after the exchange of the Confirm TLV (i.e., until after mutual authentication has occurred and keys are in place to protect the TLV). The New PIN TLV MUST be sent by a peer if and only if the EAP-Request that triggered the response contained a New PIN TLV, it was valid for the EAP server to send such a TLV in that request, and the TLV is supported by the peer.
符合本规范的对等方和EAP服务器应支持此TLV类型。除非对等方已通过身份验证，否则EAP服务器不得发送新的PIN TLV。如果对等方在受保护模式下进行了身份验证，则在交换确认TLV之前（即，在发生相互身份验证且密钥到位以保护TLV之前），新PIN TLV不得出现在EAP请求中。当且仅当触发响应的EAP请求包含新的PIN TLV时，新PIN TLV必须由对等方发送，EAP服务器在该请求中发送此类TLV是有效的，并且对等方支持TLV。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Q|A| PIN Length | PIN ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Min. PIN Length|Max. PIN Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Q|A| PIN Length | PIN ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Min. PIN Length|Max. PIN Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1-强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
5
5.
Length
长
2 + length of the PIN field (as specified in the PIN Length field) + (0, 1, or 2)
2+引脚字段的长度（按照引脚长度字段中的规定）+（0、1或2）
Note: The final term above is - 0 if none of the optional Min. / Max. PIN Length fields is present in the TLV, - 1 if only the Min. PIN Length field is present in the TLV, - 2 if both of these optional fields are present in the TLV.
注：如果TLV中不存在可选的最小/最大引脚长度字段，则上述最后一项为-0；如果TLV中仅存在最小引脚长度字段，则为-1；如果TLV中同时存在这两个可选字段，则为-2。
Reserved
含蓄的
Reserved for future use. All six bits SHALL be set to zero for this version. Recipients SHALL ignore these bits for this version of EAP-POTP.
保留供将来使用。对于该版本，所有六位应设置为零。对于此版本的EAP-POTP，收件人应忽略这些位。
Q
Q
The Q bit, when set in an EAP-Request, indicates that an accompanying PIN is required, i.e., the peer (user) is not free to choose another PIN. When the Q bit is set, there MUST be an accompanying PIN and the provided PIN MUST be used in subsequent OTP generations. A peer SHALL respond with an empty POTP-X EAP-Response message if the Q bit is set but there is not any accompanying PIN. When the Q bit is not set, any provided PIN is suggested only, and the peer is free to choose another PIN, subject to local policy.
当在EAP请求中设置Q位时，表示需要附带PIN，即对等方（用户）不能自由选择其他PIN。当设置Q位时，必须有一个附带的管脚，并且提供的管脚必须在后续OTP生成中使用。如果设置了Q位但没有任何伴随PIN，则对等方应使用空POTP-X EAP响应消息进行响应。未设置Q位时，仅建议提供任何PIN，对等方可根据本地政策自由选择其他PIN。
The Q bit carries no meaning, and SHALL be set to zero, in an EAP-Response.
在EAP响应中，Q位没有意义，应设置为零。
A
A.
This bit allows methods that distinguish between two different PIN types (e.g., decimal vs. alphanumeric) to designate whether the augmented set is to be used (when set) or not (when not set). The A bit carries no meaning, and SHALL be set to zero, in an EAP-Response.
该位允许使用区分两种不同引脚类型（例如，十进制与字母数字）的方法来指定是否使用扩充集（设置时）或不使用扩充集（未设置时）。A位没有意义，在EAP响应中应设置为零。
PIN Length
销长
This field contains an unsigned integer representing the length of the provided PIN (this implies that the maximum length of a PIN will be 255 octets).
此字段包含一个无符号整数，表示所提供管脚的长度（这意味着管脚的最大长度为255个八位字节）。
PIN
大头针
In an EAP-Request, subject to the setting of the Q bit, the PIN field MAY be empty. If empty, the peer (user) will need to choose a PIN subject to local and (any) provided policy. When the PIN field is not empty, it MUST consist of UTF-8 encoded printable characters without a terminating NULL character.
在EAP请求中，根据Q位的设置，PIN字段可能为空。如果为空，对等方（用户）将需要根据本地和（任何）提供的策略选择PIN。当PIN字段不为空时，它必须由UTF-8编码的可打印字符组成，不带终止空字符。
In an EAP-Response, the PIN value SHALL consist of a UTF-8 encoded string of printable characters without a terminating NULL character.
在EAP响应中，PIN值应由UTF-8编码的可打印字符字符串组成，无终止空字符。
The peer accepts a PIN suggested by the EAP server by replying with the same PIN, but MAY replace it with another one, depending on the server's setting of the Q bit. The length of the PIN is application-dependent, as are any other requirements for the PIN, e.g., allowed characters. The peer MUST be prepared to receive a repeated request for a new PIN, as described above, if the EAP server, for some reason does not accept the received PIN. Such a request MAY be preceded by an EAP-Request of type Notification (2) providing information to the user about the reason for the rejection. Mechanisms for transferring knowledge about PIN requirements from the EAP server to the peer (beyond those specified for this TLV, such as maximal and minimal PIN length) are outside the scope of this document. However, some information MAY be provided in notification messages transferred from the EAP server to the peer, as per above.
对等方通过使用相同的PIN进行回复来接受EAP服务器建议的PIN，但可以使用另一个PIN进行替换，具体取决于服务器的Q位设置。PIN的长度取决于应用程序，以及PIN的任何其他要求，例如允许的字符。如上所述，如果EAP服务器出于某种原因不接受接收到的PIN，则对等方必须准备好接收对新PIN的重复请求。这种请求之前可以是通知（2）类型的EAP请求，向用户提供关于拒绝原因的信息。将有关PIN要求的知识从EAP服务器传输到对等方的机制（超出为此TLV指定的机制，如最大和最小PIN长度）不在本文档的范围内。然而，如上所述，可以在从EAP服务器传输到对等方的通知消息中提供一些信息。
Min. PIN Length
最小销长度
This field MAY be present in an EAP-Request. This field MUST NOT be present in an EAP-Response. It SHALL be interpreted as an unsigned integer in network byte order representing the minimum length allowed for a new PIN.
此字段可能出现在EAP请求中。EAP响应中不得出现此字段。应将其解释为网络字节顺序的无符号整数，表示新管脚允许的最小长度。
Max. PIN Length
最大销长度
This field MUST NOT be present in an EAP-Request unless the Min. PIN Length field is present, in which case it MAY be present. The field MUST NOT be present in an EAP-Response. It SHALL be interpreted as an unsigned integer in network byte order representing the maximum length allowed for a new PIN. The value of this field, when present, MUST be equal to, or larger than, the value of the Min. PIN Length field.
该字段不得出现在EAP请求中，除非存在最小PIN长度字段，在这种情况下，该字段可能存在。该字段不得出现在EAP响应中。应将其解释为网络字节顺序的无符号整数，表示新管脚允许的最大长度。此字段的值（如果存在）必须等于或大于最小引脚长度字段的值。
Presence of this TLV in a request indicates that the EAP server has successfully authenticated the peer and now attempts to authenticate itself to the peer. Presence of this TLV in a response indicates that the peer successfully authenticated the EAP server, and that calculated keys (K_MAC, K_ENC, MSK, EMSK, and SRK) now become available for use.
请求中存在此TLV表示EAP服务器已成功对对等方进行身份验证，并且现在尝试向对等方进行自身身份验证。响应中出现此TLV表示对等方成功验证了EAP服务器，并且计算出的密钥（K_MAC、K_ENC、MSK、EMSK和SRK）现在可供使用。
The Confirm TLV MUST NOT appear together with any other TLV in an EAP-Request message of type POTP-X and MUST NOT be sent unless the peer has been authenticated through an OTP TLV with the P bit set or through a Resume TLV for which the underlying session was established in protected mode. The Confirm TLV MUST be present in an EAP-Response if and only if the request that triggered the response contained a Confirm TLV, it was legal for it to do so, and the Confirm TLV authenticated the EAP server to the peer. If the peer was not able to authenticate the server, then it MUST send an empty (i.e., no TLVs present) EAP-Response of type POTP-X.
确认TLV不得与任何其他TLV一起出现在POTP-X类型的EAP请求消息中，并且不得发送，除非对等方已通过设置了P位的OTP TLV或通过在保护模式下为其建立基础会话的恢复TLV进行了身份验证。当且仅当触发响应的请求包含确认TLV时，确认TLV必须出现在EAP响应中，确认TLV这样做是合法的，并且确认TLV向对等方验证了EAP服务器。如果对等方无法对服务器进行身份验证，则必须发送POTP-X类型的空（即不存在TLV）EAP响应。
An EAP server MUST send an EAP-Success message after receiving an EAP-Response of type POTP-X containing a valid Confirm TLV, sent in response to an EAP-Request containing a Confirm TLV where the C bit was not set. A peer MUST NOT accept an EAP-Success message when it has sent an OTP TLV with the P bit set unless it has received an acceptable Confirm TLV from the EAP server.
EAP服务器必须在收到包含有效确认TLV的POTP-X类型EAP响应后发送EAP成功消息，该EAP响应是针对包含未设置C位的确认TLV的EAP请求而发送的。对等方在发送设置了P位的OTP TLV时不得接受EAP成功消息，除非它从EAP服务器接收到可接受的确认TLV。
This TLV type MUST be supported by all peers and EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV.
符合本规范的所有对等方和EAP服务器必须支持此TLV类型，并且不得使用NAK TLV响应。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |C| Authentication Data ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pepper Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Pepper ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |C| Authentication Data ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pepper Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Pepper ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1-强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
6
6.
Length
长
17 or 37 + length of IV in requests, 1 in responses.
17或37+请求中的IV长度，响应中的1。
Reserved
含蓄的
Reserved for future use. These 7 bits SHALL be set to zero (0) for this version. Recipients SHALL ignore these bits for this version of EAP-POTP.
保留供将来使用。对于该版本，这7位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略这些位。
C
C
The C bit, when set in an EAP-Request, indicates that the EAP server intends to send more EAP-Requests of type POTP-X in this session, after receipt of a Confirm TLV from the peer.
当在EAP请求中设置C位时，表示EAP服务器打算在收到来自对等方的确认TLV后，在此会话中发送更多POTP-X类型的EAP请求。
The C bit carries no meaning in EAP-Responses, and MUST NOT be set within them.
C位在EAP响应中没有意义，并且不得在EAP响应中设置。
Note: An EAP-Response containing a Confirm TLV, sent in response to an EAP-Request containing a Confirm TLV that did not have the C bit set, MUST be followed by an EAP-Success message from the EAP server concluding the handshake. However, when the C bit was set in an EAP-Request, the EAP server MAY send another EAP-Request (containing, for example, a New PIN TLV wrapped in a Protected TLV) rather than an EAP-Success message. Therefore, peers MUST NOT assume that the only EAP message following an EAP-Response of type POTP-X containing a Confirm TLV is EAP-Success. The C bit gives EAP servers a way to indicate their intent to follow the Confirm TLV with more requests, and allows the peer's state machine to adapt to this.
注意：包含确认TLV的EAP响应是为了响应包含未设置C位的确认TLV的EAP请求而发送的，之后必须有来自EAP服务器的结束握手的EAP成功消息。但是，当在EAP请求中设置了C位时，EAP服务器可能会发送另一个EAP请求（例如，包含封装在受保护TLV中的新PIN TLV），而不是EAP成功消息。因此，对等方不得假设包含确认TLV的POTP-X类型EAP响应之后的唯一EAP消息是EAP Success。C位为EAP服务器提供了一种方法，表明它们打算通过更多请求遵循Confirm TLV，并允许对等方的状态机适应这种情况。
Authentication Data
认证数据
EAP-Request:
EAP请求：
In a request, this field consists of the first 16 octets of (see also Section 4.11.3):
在请求中，该字段由以下内容的前16个八位字节组成（另见第4.11.3节）：
mac_a = MAC(K_MAC', msg_hash(trig_msg))
mac_a = MAC(K_MAC', msg_hash(trig_msg))
where
哪里
MAC is the negotiated MAC algorithm,
MAC是协商的MAC算法，
"K_MAC'" has been calculated as described in Section 4.11.3 or (in the case of session resumption) Section 4.11.8, and
“K_MAC'”已按照第4.11.3节或（在会话恢复的情况下）第4.11.8节的规定计算，以及
"msg_hash" is the message hash algorithm defined in Section 4.9, and "trig_msg" the latest EAP-Response of type POTP-X received from the peer (the one which triggered this request).
“msg_hash”是第4.9节中定义的消息哈希算法，“trig_msg”是从对等方（触发此请求的一方）收到的POTP-X类型的最新EAP响应。
Given a saved or recomputed value for K_MAC, the peer authenticates the EAP server by computing
给定K_MAC的保存或重新计算值，对等方通过计算对EAP服务器进行身份验证
mac'' = MAC(K_MAC, msg_hash(trig_msg'))
mac'' = MAC(K_MAC, msg_hash(trig_msg'))
where "msg_hash(trig_msg')" is the peer's hash of the EAP-Response message that it sent to the server (and that the server calculated its message hash on). If the first 16 octets of mac'' matches the first 16 octets in the Authentication Data field of the EAP-Request in question, then the EAP server is authenticated.
其中，“msg_hash（trig_msg'）”是对等方发送给服务器的EAP响应消息的散列（并且服务器计算了其消息散列）。如果mac“”的前16个八位字节与相关EAP请求的身份验证数据字段中的前16个八位字节相匹配，则EAP服务器已通过身份验证。
EAP-Response:
EAP响应：
Not used in this version, and SHALL NOT be present in EAP-Responses.
本版本中未使用，且不应出现在EAP响应中。
Pepper Identifier
胡椒标识
In an EAP-Request, the truncated MAC MAY optionally be followed by an encrypted pepper and its identifier. This initial, 4-octet field identifies a pepper generated by the server.
在EAP请求中，截断的MAC可以可选地后跟加密的pepper及其标识符。这个初始的4-octet字段标识服务器生成的一个pepper。
For this version of EAP-POTP, this field SHALL NOT be present in EAP-Responses.
对于此版本的EAP-POTP，此字段不应出现在EAP响应中。
IV (Initialization Vector)
IV（初始化向量）
An initialization vector for the encryption. The length of the vector is dependent on the negotiated encryption algorithm. For example, for AES-CBC, it SHALL be 16 octets. The IV is only present if a pepper is present, and the negotiated encryption algorithm makes use of an IV. This field SHALL NOT be present in EAP-Response messages for this version of EAP-POTP.
加密的初始化向量。向量的长度取决于协商的加密算法。例如，对于AES-CBC，应为16个八位字节。仅当存在胡椒时，IV才存在，协商加密算法使用IV。对于此版本的EAP-POTP，此字段不应出现在EAP响应消息中。
Encrypted Pepper
加密胡椒
When present in an EAP-Request, this will be a uniformly distributed and randomly chosen 16-octet pepper generated by the EAP server and encrypted with the negotiated encryption algorithm, using K_ENC as the encryption key and possibly (depending on the encryption algorithm) using an IV (stored in the IV field). This field MUST be present if and only if the Pepper Identifier field is present.
当存在于EAP请求中时，这将是由EAP服务器生成并使用协商加密算法加密的均匀分布和随机选择的16个八位组，使用K_ENC作为加密密钥，并可能（取决于加密算法）使用IV（存储在IV字段中）。当且仅当Pepper标识符字段存在时，此字段必须存在。
EAP servers are RECOMMENDED to include a freshly generated encrypted pepper (and a corresponding Pepper Identifier) in every Confirm TLV.
建议EAP服务器在每个确认TLV中包含一个新生成的加密pepper（以及相应的pepper标识符）。
This field SHALL NOT be present in EAP-Response messages for this version of EAP-POTP.
此字段不应出现在此版本的EAP-POTP的EAP响应消息中。
When a new pepper is generated by the server and transferred in encrypted form to the peer, then this new pepper value will be stored in the EAP server upon receipt of the Confirm TLV from the peer, and SHOULD be stored with its identifier and associated with the EAP server and the current user in the peer upon receipt of the EAP-Success message. If the peer already had a pepper stored for the EAP server, it SHALL replace it with the newly received one.
当服务器生成新的pepper并以加密形式传输到对等方时，该新pepper值将在从对等方收到确认TLV后存储在EAP服务器中，并应在收到EAP成功消息后与其标识符一起存储，并与EAP服务器和对等方中的当前用户相关联。如果对等方已经为EAP服务器存储了一个pepper，则应将其替换为新收到的pepper。
The Vendor-Specific TLV is available to allow vendors to support their own extended attributes not suitable for general usage. A Vendor-Specific TLV can contain one or more inner TLVs, referred to as Vendor TLVs. The TLV-type of a Vendor TLV will be defined by the vendor. All the Vendor TLVs inside a single Vendor-Specific TLV SHALL belong to the same vendor.
特定于供应商的TLV可用于允许供应商支持其自身不适合一般用途的扩展属性。特定于供应商的TLV可以包含一个或多个内部TLV，称为供应商TLV。供应商TLV的TLV类型将由供应商定义。单个供应商特定TLV内的所有供应商TLV应属于同一供应商。
This TLV type MAY be sent by EAP servers, as well as by peers, and MUST be supported by all entities conforming to this specification. Conforming implementations may not support specific Vendor TLVs inside a Vendor-Specific TLV, however. They MAY, in this case, respond to the Vendor TLVs with a NAK TLV containing the appropriate Vendor-ID and Vendor TLV type.
该TLV类型可由EAP服务器以及对等方发送，并且必须由符合本规范的所有实体支持。但是，一致性实施可能不支持特定供应商TLV中的特定供应商TLV。在这种情况下，他们可以使用包含适当供应商ID和供应商TLV类型的NAK TLV响应供应商TLV。
The presence of a Vendor-Specific TLV in an EAP-Request or EAP-Response of type POTP-X MUST NOT violate any existing rules for coexistence of TLVs in such requests or responses. If it does, then it will result in an EAP-Failure (when the peer made the violation) or an empty EAP-POTP response (when the EAP-server made the violation). It is left to the definition of specific Vendor-Specific TLVs to further constrain when they are allowed to appear. In
POTP-X类型的EAP请求或EAP响应中存在供应商特定的TLV不得违反此类请求或响应中TLV共存的任何现有规则。如果是，则将导致EAP失败（当对等方违反时）或EAP-POTP响应为空（当EAP服务器违反时）。由特定供应商特定TLV的定义来进一步约束何时允许它们出现。在里面
particular, EAP-POTP implementations may have policies that completely disallow use of the Vendor-Specific TLV before protected mode mutual authentication has occurred (since the Protected TLV, Section 4.11.15, then can be used to protect all TLVs).
特别是，EAP-POTP实施可能具有完全禁止在发生保护模式相互认证之前使用供应商特定TLV的策略（因为第4.11.15节中的受保护TLV可用于保护所有TLV）。
Note: This TLV type has the same definition and TLV type number as the Vendor-Specific TLV in [17], and the description of it is largely borrowed from that document.
注：该TLV类型与[17]中的供应商特定TLV具有相同的定义和TLV类型编号，其描述主要借鉴该文件。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1-强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
7
7.
Length
长
4 + cumulative total length of inner Vendor TLVs
4+内部供应商TLV的累计总长度
Vendor-ID
供应商ID
The Vendor-Id field is 4 octets. The high-order octet SHALL be set to 0, and the low-order 3 octets SHALL be set to the SMI Network Management Private Enterprise Code (see [18]) of the Vendor in network byte order.
供应商Id字段为4个八位字节。高阶八位字节应设置为0，低阶三位八位字节应按网络字节顺序设置为供应商的SMI网络管理私有企业代码（见[18]）。
Vendor TLVs
供应商TLV
This field shall contain vendor-specific TLVs, in a format defined by the vendor. To avoid fragmentation (i.e., EAP messages longer than the minimum EAP MTU size), the field SHOULD NOT be longer than 256 octets.
该字段应包含供应商指定的TLV，格式由供应商定义。为避免碎片（即EAP消息长度超过最小EAP MTU大小），字段长度不应超过256个八位字节。
To ensure interoperability when an EAP entity (peer or server) from vendor A sends a vendor-specific TLV that is not understood by the recipient EAP entity from vendor B, the vendor A entity SHALL, upon receipt of the NAK TLV from the recipient, refrain from usage of the vendor-specific TLV in question for the rest of the handshake, and MUST NOT fail the session due to the receipt of the NAK TLV for the Vendor TLV (i.e., it SHALL continue as if the vendor-specific TLV had not been sent). Additionally, all implementations conformant with this document SHOULD allow use of vendor-specific extensions to be turned off via configuration.
为确保供应商A的EAP实体（对等方或服务器）从供应商B发送接收方EAP实体不理解的供应商特定TLV时的互操作性，供应商A实体应在收到接收方的NAK TLV后，在握手的剩余时间内避免使用有问题的供应商特定TLV，并且不得因收到供应商TLV的NAK TLV而使会话失败（即，它应继续，如同未发送供应商特定TLV一样）。此外，符合本文档的所有实现应允许通过配置关闭供应商特定扩展的使用。
The Resume TLV MAY be sent by a peer to an authentication server to attempt session resumption.
恢复TLV可由对等方发送到认证服务器以尝试会话恢复。
This TLV type MUST only be sent in response to an EAP-Request of type POTP-X containing a Server-Info TLV allowing session resumption. The Resume TLV MUST be supported by all EAP servers that send a Server-Info TLV allowing session resumption.
此TLV类型只能在响应POTP-X类型的EAP请求时发送，该请求包含允许会话恢复的服务器信息TLV。所有发送允许会话恢复的服务器信息TLV的EAP服务器都必须支持恢复TLV。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sess.Id (cont.)| Authentication Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sess.Id (cont.)| Authentication Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Non-mandatory TLV
0-非强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
8
8.
Length
长
45
45
Reserved
含蓄的
Reserved for future use. This octet SHALL be set to zero (0) for this version. Recipients SHALL ignore this octet for this version of EAP-POTP.
保留供将来使用。对于该版本，该八位字节应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此八位字节。
Session Identifier
会话标识
An 8-octet identifier for the session the peer is trying to resume.
对等方尝试恢复的会话的8个八位字节标识符。
Authentication Data
认证数据
Upon receipt of the Server-Info TLV, and if the N bit is not set, the peer searches for any stored sessions associated with the server identified by the Server Name field. If a stored session is found, the peer generates a random, 16-octet nonce, "c_nonce", and calculates:
收到服务器信息TLV后，如果未设置N位，对等方将搜索与服务器名称字段标识的服务器相关联的任何存储会话。如果找到存储的会话，对等方将生成一个随机的16个八位字节的nonce，“c_nonce”，并计算：
K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(base_key, c_nonce | s_nonce, iteration_count, key_length)
K|u MAC | K|u ENC | MSK | EMSK | SRK=PBKDF2（基本密钥、当前时间、迭代计数、密钥长度）
where
哪里
"|" denotes concatenation,
“|”表示串联，
"base_key" is either the current SRK for the session (if the session was created in protected mode) or the OTP used when the session was created (if the session was created in basic mode),
“基本密钥”是会话的当前SRK（如果会话是在保护模式下创建的）或创建会话时使用的OTP（如果会话是在基本模式下创建的），
"c_nonce" is the generated 16-octet nonce,
“c_nonce”是生成的16个八位字节的nonce，
"s_nonce" is the server nonce from the Server-Info TLV,
“s_nonce”是服务器信息TLV中的服务器nonce，
"iteration_count" is the iteration count as determined by local policy, and
“迭代计数”是由本地策略确定的迭代计数，并且
"key_length" is the combined length of the desired key material, in octets. When the default algorithms are used, key_length is 176.
“密钥长度”是所需密钥材料的组合长度，以八位字节为单位。使用默认算法时，密钥长度为176。
The iteration count need only be 1 (one) when resuming a session established in protected mode, but MUST be chosen to provide a suitable level of protection when resuming a session established in basic mode (see also Section 4.11.3).
在恢复以受保护模式建立的会话时，迭代计数只需为1（一），但必须选择为在恢复以基本模式建立的会话时提供适当的保护级别（另请参见第4.11.3节）。
Note: Session resumption for basic mode MUST only be carried out in a server-authenticated and protected tunnel that also provides a cryptographic binding for inner EAP methods.
注意：基本模式的会话恢复只能在经过身份验证和保护的服务器隧道中执行，该隧道还为内部EAP方法提供加密绑定。
The peer then calculates:
然后，对等方计算：
mac = MAC(K_MAC, msg_hash(resume_req))
mac = MAC(K_MAC, msg_hash(resume_req))
where
哪里
"MAC" is the negotiated MAC algorithm, and
“MAC”是协商MAC算法，并且
"msg_hash(resume_req) is the message hash algorithm defined in Section 4.9 applied on resume_req, the EAP server's EAP-Request of type POTP-X containing the Server-Info TLV that allowed session resumption.
“msg_hash（resume_req）是第4.9节中定义的消息哈希算法，应用于resume_req，即EAP服务器的POTP-X类型EAP请求，其中包含允许会话恢复的服务器信息TLV。
The peer then places the first 16 octets of the MAC value, followed by the c_nonce value, followed by the iteration count value (as a 4-byte unsigned integer in network byte order), in the Authentication Data field. As an example, when c_nonce = 0x2b3b1b12babdebebfb43bd7bdfbeb8df and iteration_count = 1, the Authentication Data field will be populated with (in hex):
然后，对等方将MAC值的前16个八位字节、c_nonce值、迭代计数值（按网络字节顺序为4字节无符号整数）放入身份验证数据字段。例如，当c_nonce=0x2B3B12BADBEBBFB43BD7BDBFBEB8DF且迭代计数=1时，身份验证数据字段将填充（十六进制）：
< 16 octets of mac > | 2b3b1b12babdebebfb43bd7bdfbeb8df | 00000001
mac的<16个八位字节>| 2B3B1B12BADBEBBB43BD7BDDFBEB8DF | 0000000 1
The server authenticates the peer by performing the corresponding calculations. If the authentication is successful, the server MUST send an EAP-Request of type POTP-X containing a Confirm TLV to the peer. If the authentication fails, the server MUST either send an EAP-Request of type POTP-X containing an OTP TLV and a Server-Info TLV, where the Server-Info TLV indicates that session resumption is not possible, or send an EAP-Failure.
服务器通过执行相应的计算对对等方进行身份验证。如果身份验证成功，服务器必须向对等方发送POTP-X类型的EAP请求，其中包含确认TLV。如果身份验证失败，服务器必须发送POTP-X类型的EAP请求，其中包含OTP TLV和服务器信息TLV，其中服务器信息TLV指示无法恢复会话，或者发送EAP失败。
When resuming in basic mode, all calculated keys SHALL be discarded after the MAC has been calculated and verified. When resuming in protected mode, the new SRK will replace the stored SRK, and the new MSK and EMSK will be exported upon successful completion of the method.
在基本模式下恢复时，应在计算和验证MAC后丢弃所有计算出的密钥。在保护模式下恢复时，新的SRK将替换存储的SRK，并且在成功完成该方法后将导出新的MSK和EMSK。
The User Identifier TLV carries an identifier, typically the username, for the holder of the OTP token used to generate the OTP.
用户标识符TLV携带用于生成OTP的OTP令牌的持有者的标识符，通常是用户名。
At least one of the User Identifier TLV and the Token Key Identifier TLV SHOULD be present in the session's first EAP-Response of type POTP-X that also carries an OTP TLV unless a suitable identity has been provided in a preceding EAP-Response of type Identity (1) or is determined by some other means (see [1], Section 2). Use of the User Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED even when an EAP-Response of type Identity (1) has been sent. If a peer sends both a User Identifier TLV and a Token Key Identifier TLV, then the EAP server SHALL interpret the Token Key Identifier TLV as specifying a particular token key for the given user. The EAP server MUST respond with an EAP-Failure if it cannot find a token key for the provided user.
用户标识符TLV和令牌密钥标识符TLV中的至少一个应该出现在会话的POTP-X类型的第一个EAP响应中，该响应也携带OTP TLV，除非在先前的标识（1）类型的EAP响应中提供了合适的标识，或者通过一些其他方式确定（参见[1]，第2节）。即使发送了类型为Identity（1）的EAP响应，也建议使用用户标识符TLV和/或令牌密钥标识符TLV。如果对等方同时发送用户标识符TLV和令牌密钥标识符TLV，则EAP服务器应将令牌密钥标识符TLV解释为指定给定用户的特定令牌密钥。如果EAP服务器找不到所提供用户的令牌密钥，则必须响应EAP故障。
This TLV type is sent by peers and MUST be supported by all EAP servers conforming to this specification. The User Identifier TLV MUST NOT be present in a response that does not also carry an OTP TLV.
此TLV类型由对等方发送，并且必须由符合本规范的所有EAP服务器支持。用户标识符TLV不得出现在不携带OTP TLV的响应中。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1-强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
9
9
Length
长
Length of User Identifier, >= 1
用户标识符的长度，>=1
User Identifier
用户标识符
The value SHALL be an UTF-8 encoded string representing the holder of the token (MUST NOT be NULL-terminated). The string MUST be less than 128 octets in length.
该值应为表示令牌持有者的UTF-8编码字符串（不得以NULL结尾）。字符串长度必须小于128个八位字节。
The Token Key Identifier TLV carries an identifier for the token key used to generate the OTP.
令牌密钥标识符TLV携带用于生成OTP的令牌密钥的标识符。
At least one of the User Identifier TLV and the Token Key Identifier TLV SHOULD be present in the session's first EAP-Response of type POTP-X, which also carries the OTP TLV unless a suitable identity has been provided in a preceding EAP-Response of type Identity (1) or is determined by some other means (see [1], Section 2). Use of the User Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED even when an EAP-Response of type Identity (1) has been sent. If a peer sends both a User Identifier TLV and a Token Key Identifier TLV, then the EAP server SHALL interpret the Token Key Identifier TLV as specifying a particular token key for the given user. The EAP server MUST respond with an EAP-Failure if it cannot find a token key corresponding to the provided token key identifier.
用户标识符TLV和令牌密钥标识符TLV中的至少一个应存在于会话的POTP-X类型的第一EAP响应中，该响应也携带OTP TLV，除非在先前的标识（1）类型的EAP响应中提供了合适的标识或通过某些其他方式确定（参见[1]，第2节）。即使发送了类型为Identity（1）的EAP响应，也建议使用用户标识符TLV和/或令牌密钥标识符TLV。如果对等方同时发送用户标识符TLV和令牌密钥标识符TLV，则EAP服务器应将令牌密钥标识符TLV解释为指定给定用户的特定令牌密钥。如果EAP服务器找不到与所提供的令牌密钥标识符相对应的令牌密钥，则必须以EAP故障响应。
This TLV type is sent by peers and MUST be supported by all EAP servers conforming to this specification. The Token Key Identifier TLV MUST NOT be present in a response that does not also carry an OTP TLV.
此TLV类型由对等方发送，并且必须由符合本规范的所有EAP服务器支持。令牌密钥标识符TLV不得出现在不携带OTP TLV的响应中。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Key Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Key Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1-强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
10
10
Length
长
Length of Token Key Identifier, >= 1
令牌密钥标识符的长度，>=1
Token Key Identifier
令牌密钥标识符
An identifier for the OTP token key used to generate the OTP. The field MUST be less than 128 octets in length.
用于生成OTP的OTP令牌密钥的标识符。字段长度必须小于128个八位字节。
The Time Stamp TLV MAY be sent by peers to simplify authentications. When present, it carries the time as reported by the OTP Token.
时间戳TLV可由对等方发送以简化认证。当存在时，它携带OTP令牌报告的时间。
An EAP server conformant with this specification SHOULD support (i.e., recognize) this TLV, but need not be able to process or act on it. An EAP server that does not support this TLV, but receives an EAP-Response with the TLV present, MAY ignore the value. The Time Stamp TLV MUST NOT be present in any EAP-Responses of type POTP-X other than those that also carries an OTP TLV.
符合本规范的EAP服务器应支持（即，识别）该TLV，但不需要能够处理或操作该TLV。不支持此TLV但接收到存在TLV的EAP响应的EAP服务器可能会忽略该值。时间戳TLV不得出现在POTP-X类型的任何EAP响应中，也携带OTP TLV的响应除外。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Non-mandatory TLV
0-非强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
11
11
Length
长
Length of Time Stamp field, >= 20 (depending on precision)
时间戳字段的长度，>=20（取决于精度）
Time Stamp
时间戳
The time, as reported by the OTP token, at which the OTP used for the accompanying OTP TLV was calculated. The field SHALL contain a UTF-8 encoded value of the XML simple type "dateTime", with time zone information and precision down to at least seconds, e.g., "2004-06-16T15:20:02Z".
OTP令牌报告的计算用于伴随OTP TLV的OTP的时间。该字段应包含一个XML简单类型为“dateTime”的UTF-8编码值，时区信息和精度至少为秒，例如，“2004-06-16T15:20:02Z”。
The Counter TLV MAY be sent by peers to simplify authentications. When present, it carries the token counter value, as reported by the OTP Token.
计数器TLV可由对等方发送以简化认证。当存在时，它携带OTP令牌报告的令牌计数器值。
An EAP server conformant with this specification SHOULD support (i.e., recognize) this TLV, but need not be able to process or act on it. An EAP server that does not support this TLV, but receives an EAP-Response with the TLV present, MAY ignore the value. The Counter TLV MUST NOT be present in any EAP-Responses of type POTP-X other than those that also carries an OTP TLV.
符合本规范的EAP服务器应支持（即，识别）该TLV，但不需要能够处理或操作该TLV。不支持此TLV但接收到存在TLV的EAP响应的EAP服务器可能会忽略该值。计数器TLV不得出现在任何POTP-X型EAP响应中，但也携带OTP TLV的响应除外。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Non-mandatory TLV
0-非强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
12
12
Length
长
Length of Counter field, >= 1 (depending on precision)
计数器字段的长度，>=1（取决于精度）
Counter
柜台
The counter value, as reported by the OTP token, at which the OTP used for the accompanying OTP TLV was calculated. The counter value SHALL be represented as an unsigned integer in network-byte order, e.g., a counter value of 1030 may be sent as the 2 octets (in hex) 04 06.
OTP令牌报告的计数器值，在该值处计算用于伴随OTP TLV的OTP。计数器值应以网络字节顺序表示为无符号整数，例如，1030的计数器值可作为2个八位字节（十六进制）04 06发送。
The Challenge TLV carries the challenge used by the token to calculate the OTP, as reported by the token to the peer. The Challenge TLV MUST be sent by a peer if and only if the challenge otherwise would be unknown to the EAP server (e.g., the token or peer modified a received challenge or generated its own challenge).
质询TLV携带令牌用于计算OTP的质询，该质询由令牌向对等方报告。当且仅当EAP服务器不知道质询时（例如，令牌或对等方修改了接收的质询或生成了自己的质询），质询TLV必须由对等方发送。
An EAP server conformant with this specification SHOULD support (i.e., recognize) this TLV, but need not be able to process or act on it. An EAP server that does not support this TLV, but receives an EAP-Response with the TLV present, MAY ignore the value. The Challenge TLV MUST NOT be present in any EAP-Responses of type POTP-X other than those that also carry an OTP TLV.
符合本规范的EAP服务器应支持（即，识别）该TLV，但不需要能够处理或操作该TLV。不支持此TLV但接收到存在TLV的EAP响应的EAP服务器可能会忽略该值。挑战TLV不得出现在任何POTP-X型EAP响应中，也携带OTP TLV的响应除外。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Non-mandatory TLV
0-非强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
16
16
Length
长
Length of Challenge field, >= 1
挑战字段的长度，>=1
Challenge
挑战
The challenge value that was used to calculate the OTP used for the accompanying OTP TLV.
用于计算用于随附OTP TLV的OTP的质询值。
The Keep-Alive is used to avoid EAP-POTP timeouts.
保持活动状态用于避免EAP-POTP超时。
The Keep-Alive TLV MAY be sent by a peer to avoid timeouts when the peer has received an EAP-Request containing an OTP TLV or a New PIN TLV and is waiting for a response from the user.
当对等方已经接收到包含OTP TLV或新PIN TLV的EAP请求并且正在等待来自用户的响应时，保持活动TLV可以由对等方发送以避免超时。
An EAP-Request containing a Keep-Alive TLV MUST be sent by an EAP server when the server receives an EAP-Response containing a Keep-Alive TLV, and the server has an outstanding request that did not contain a Keep-Alive TLV. In this situation, the server does not need to re-transmit its latest outstanding request, but, due to the synchronous nature of EAP, it needs to send another request. Re-transmission of the latest outstanding request could be confusing for the peer since the request would get a new Identifier value. The Keep-Alive TLV MAY also be sent by an EAP server when the server detects that its processing time will exceed some locally configured threshold and may cause a network timeout. In this case, the peer MUST respond with an EAP-Response containing a Keep-Alive TLV.
当服务器接收到包含保持活动TLV的EAP响应时，包含保持活动TLV的EAP请求必须由EAP服务器发送，并且服务器具有未完成的请求，该请求不包含保持活动TLV。在这种情况下，服务器不需要重新传输其最新未完成的请求，但由于EAP的同步性质，它需要发送另一个请求。重新传输最新未完成的请求可能会让对等方感到困惑，因为该请求将获得一个新的标识符值。当EAP服务器检测到其处理时间将超过某些本地配置的阈值并可能导致网络超时时，保持活动TLV也可能由EAP服务器发送。在这种情况下，对等方必须使用包含保持活动TLV的EAP响应进行响应。
This TLV type MUST be supported by all peers and all EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV. The Keep-Alive TLV MUST NOT be sent in any other situations than the ones described above. The Keep-Alive TLV MUST NOT be sent together with any other TLVs defined herein. Implementations SHOULD also follow recommendations made in Section 4.3 of [1].
符合本规范的所有对等方和所有EAP服务器必须支持此TLV类型，并且不得使用NAK TLV响应。除上述情况外，不得在任何其他情况下发送Keep Alive TLV。保持活动TLV不得与此处定义的任何其他TLV一起发送。实施还应遵循[1]第4.3节中提出的建议。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1-强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
13
13
Length
长
0
0
The Protected TLV SHALL be used to encrypt individual or multiple TLVs after successful exchange of the Confirm TLV (i.e., as soon as calculated keys have been confirmed). The Protected TLV therefore wraps "ordinary" TLVs.
在成功交换确认TLV后（即，一旦计算出的密钥得到确认），应使用受保护TLV对单个或多个TLV进行加密。因此，受保护的TLV包裹“普通”TLV。
This TLV type may be sent by EAP servers as well as by peers and MUST be supported by all peers conforming to this specification. It SHOULD be supported by all EAP servers conforming to this specification (it need not be supported if a server never will have a need to continue a POTP-X conversation after exchange of the Confirm TLV).
此TLV类型可由EAP服务器以及对等方发送，并且必须由符合本规范的所有对等方支持。符合本规范的所有EAP服务器都应支持该协议（如果服务器在交换确认TLV后不再需要继续POTP-X对话，则不需要支持该协议）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1-强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
14
14
Length
长
>32
>32
Message Authentication Code (MAC)
消息身份验证码（MAC）
This field integrity-protects the TLV. The MAC SHALL be calculated over the IV and the Encrypted TLVs field in the following manner:
该字段完整性保护TLV。应按照以下方式在IV和加密TLV字段上计算MAC：
mac = MAC(K_MAC, iv | encrypted_tlvs)
mac=mac（K|U mac，iv|加密|TLV）
where
哪里
MAC is the negotiated MAC algorithm, "iv" is the IV field's value, and "encrypted_tlvs" is the value of the Encrypted TLVs field. The first 16 octets of the MAC is placed in the Message Authentication Code field.
MAC是协商MAC算法，“iv”是iv字段的值，“encrypted_tlvs”是加密tlvs字段的值。MAC的前16个八位字节放在消息验证码字段中。
Recipients MUST verify the MAC. If the verification fails, the conversation SHALL be terminated (i.e., peers send an empty POTP-X EAP-Response message, and EAP servers send an EAP-Failure message possibly preceded by an EAP-Request of type Notification).
收件人必须验证MAC。如果验证失败，对话将被终止（即，对等方发送一条空的POTP-X EAP响应消息，EAP服务器发送一条EAP失败消息，之前可能有一个通知类型的EAP请求）。
IV
四、
An initialization vector for the encryption; see below. The length of the vector is dependent on the negotiated encryption algorithm, e.g., for AES-CBC, it shall be 16 octets. For some encryption algorithms, there may not be any initialization vector. An IV, when present, shall be randomly chosen and non-predictable.
用于加密的初始化向量；见下文。向量的长度取决于协商加密算法，例如，对于AES-CBC，它应为16个八位字节。对于某些加密算法，可能没有任何初始化向量。如果存在IV，则应随机选择且不可预测。
Encrypted TLVs
加密TLV
This field SHALL contain one or more encrypted POTP-X TLVs. The encryption algorithm SHALL be as negotiated; use K_ENC as the encryption key, and use the IV field as the initialization vector
该字段应包含一个或多个加密的POTP-X TLV。加密算法应与协商一致；使用K_ENC作为加密密钥，使用IV字段作为初始化向量
(when applicable), to encrypt the concatenation of all the TLVs to be protected.
（适用时）加密所有要保护的TLV的连接。
The Crypto Algorithm TLV allows for negotiation of cryptographic algorithms. Cryptographic Algorithm negotiation is described in detail in Section 4.3.
加密算法TLV允许协商加密算法。第4.3节详细描述了密码算法协商。
This TLV MUST be present in the initial EAP-Request of type POTP-X that also carries an OTP TLV indicating protected mode, assuming the EAP server wants to negotiate use of any other algorithms than the default ones. It MAY also be present in an EAP-Request of type POTP-X that carries an OTP TLV that is sent as a result of a failed session resumption (in this case, the peer has not yet responded to this TLV), or when the Crypto Algorithm TLV was part of the initial message from the EAP server, and the client negotiated another EAP-POTP version than the highest one supported by the EAP server. The Crypto Algorithm TLV MUST NOT be present in any other EAP-Requests. Further, the Crypto Algorithm TLV MUST NOT be present in an EAP-Response of type POTP-X unless the preceding EAP-Request also contained it, and it was legal for it to do so. This TLV MUST be supported by all peers and all EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV.
假设EAP服务器希望协商使用默认算法以外的任何其他算法，则该TLV必须出现在POTP-X类型的初始EAP请求中，该请求还携带一个指示受保护模式的OTP TLV。它也可能出现在POTP-X类型的EAP请求中，该请求携带OTP TLV，该OTP TLV是由于会话恢复失败而发送的（在这种情况下，对等方尚未响应该TLV），或者当加密算法TLV是来自EAP服务器的初始消息的一部分时，并且客户端协商了EAP服务器支持的最高版本以外的另一个EAP-POTP版本。加密算法TLV不得出现在任何其他EAP请求中。此外，加密算法TLV不得出现在POTP-X类型的EAP响应中，除非前面的EAP请求也包含它，并且这样做是合法的。该TLV必须由符合本规范的所有对等方和所有EAP服务器支持，并且不得使用NAK TLV进行响应。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Hash Alg.Length| Hash Algorithms ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Encr.Alg.Length| Encryption Algorithms ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MAC Alg. Length| MAC Algorithms ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Hash Alg.Length| Hash Algorithms ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Encr.Alg.Length| Encryption Algorithms ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MAC Alg. Length| MAC Algorithms ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
1 - Mandatory TLV
1-强制性TLV
R
R
Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP.
保留供将来使用。对于该版本，该位应设置为零（0）。对于此版本的EAP-POTP，收件人应忽略此位。
TLV Type
TLV型
15
15
Length
长
>=4 (at least one class of algorithms and one algorithm for that class needs to be present)
>=4（至少需要一类算法和该类的一种算法）
Reserved
含蓄的
Reserved for future use. This octet MUST be set to zero for this version. Recipients SHALL ignore this octet for this version of EAP-POTP.
保留供将来使用。对于此版本，此八位字节必须设置为零。对于此版本的EAP-POTP，收件人应忽略此八位字节。
Hash Alg. Length
哈希Alg。长
The length of the Hash Algorithms field in octets.
哈希算法字段的长度（以八位字节为单位）。
Hash Algorithms
散列算法
Each octet pair of this field represents a hash algorithm as follows. An EAP server MAY supply several suggestions for hash algorithms. Each algorithm MUST appear only once. The algorithms SHALL be supplied in order of priority. Peers MUST supply, at most, one algorithm (if none is present, the default applies). The defined values are:
该字段的每个八位字节对表示如下的哈希算法。EAP服务器可以为哈希算法提供若干建议。每个算法只能出现一次。应按优先顺序提供算法。对等方最多必须提供一个算法（如果不存在，则默认值适用）。定义的值为：
Value
Octet 1 Octet 2 Hash algorithm
------- ------- ----------------------------------
0x00 0x00 Reserved
0x00 0x01 SHA-1
0x00 0x02 SHA-224
0x00 0x03 SHA-256 (default)
0x00 0x04 SHA-384
0x00 0x05 SHA-512
0x80 - Vendor-specific (or experimental)
Value
Octet 1 Octet 2 Hash algorithm
------- ------- ----------------------------------
0x00 0x00 Reserved
0x00 0x01 SHA-1
0x00 0x02 SHA-224
0x00 0x03 SHA-256 (default)
0x00 0x04 SHA-384
0x00 0x05 SHA-512
0x80 - Vendor-specific (or experimental)
As indicated, values 0x8000 and higher are for proprietary vendor-specific algorithms. Values in the range 0x0006 - 0x7fff are to be assigned through IANA; see Section 7.
如图所示，0x8000及更高的值用于专有的供应商特定算法。0x0006-0x7fff范围内的值通过IANA分配；见第7节。
Encr Alg. Length
附件Alg。长
The length of the Encryption Algorithms field in octets.
加密算法字段的长度（以八位字节为单位）。
Encryption Algorithms
加密算法
Each octet pair of this field represents an encryption algorithm as follows. An EAP server MAY supply several suggestions for encryption algorithms. Each algorithm MUST appear only once. The algorithms SHALL be supplied in order of priority. Peers MUST supply, at most, one algorithm (if none is present, the default applies). The defined values are:
此字段的每个八位字节对表示一个加密算法，如下所示。EAP服务器可能会为加密算法提供一些建议。每个算法只能出现一次。应按优先顺序提供算法。对等方最多必须提供一个算法（如果不存在，则默认值适用）。定义的值为：
Value
Octet 1 Octet 2 Encryption algorithm
------- ------- ------------------------
0x00 0x00 Reserved
0x00 0x01 AES-CBC (default) with 128-bit keys and 16-octet IVs
0x00 0x02 3DES-CBC with 112-bit keys and 8-octet IVs
0x80 - Vendor-specific
Value
Octet 1 Octet 2 Encryption algorithm
------- ------- ------------------------
0x00 0x00 Reserved
0x00 0x01 AES-CBC (default) with 128-bit keys and 16-octet IVs
0x00 0x02 3DES-CBC with 112-bit keys and 8-octet IVs
0x80 - Vendor-specific
As indicated, values 0x8000 and higher are for vendor-specific proprietary algorithms. Values in the range 0x0003 - 0x7fff are to be assigned through IANA; see Section 7.
如图所示，0x8000及更高的值用于特定于供应商的专有算法。0x0003-0x7fff范围内的值通过IANA分配；见第7节。
MAC Alg. Length
麦克·阿尔格。长
The length of the MAC Algorithms field in octets.
MAC算法字段的长度（以八位字节为单位）。
MAC Algorithms
MAC算法
Each octet pair of this field represents a MAC algorithm as follows. An EAP server MAY supply several suggestions for MAC algorithms. Each algorithm MUST appear only once. The algorithms SHALL be supplied in order of priority. Peers MUST supply, at most, one algorithm (if none is present, the default applies). The defined values are:
该字段的每个八位组对表示如下的MAC算法。EAP服务器可以为MAC算法提供若干建议。每个算法只能出现一次。应按优先顺序提供算法。对等方最多必须提供一个算法（如果不存在，则默认值适用）。定义的值为：
Value
Octet 1 Octet 2 MAC algorithm
------- ------- -----------------
0x00 0x00 Reserved
0x00 0x01 HMAC (default)
0x80 - Vendor-specific
Value
Octet 1 Octet 2 MAC algorithm
------- ------- -----------------
0x00 0x00 Reserved
0x00 0x01 HMAC (default)
0x80 - Vendor-specific
As indicated, values 0x8000 and higher are for vendor-specific proprietary algorithms. Values in the range 0x0002 - 0x7fff are to be assigned through IANA; see Section 7.
如图所示，0x8000及更高的值用于特定于供应商的专有算法。0x0002-0x7fff范围内的值通过IANA分配；见第7节。
When HMAC is negotiated, the hash algorithm used for HMAC SHALL be the negotiated hash algorithm.
协商HMAC时，HMAC使用的哈希算法应为协商的哈希算法。
In line with recommendations made in [16], EAP-POTP defines the following identifiers to be associated with generated key material:
根据[16]中的建议，EAP-POTP定义了与生成的关键材料相关的以下标识符：
Peer-ID: The combined contents of the User Identifier TLV and the Token Key Identifier TLV.
对等ID：用户标识符TLV和令牌密钥标识符TLV的组合内容。
Server-ID: The contents of the Server Identifier field of the Server-Info TLV.
服务器ID：服务器信息TLV的服务器标识符字段的内容。
Method-ID: The identifier of the established session (i.e., the contents of the Session Identifier field of the Server-Info TLV that defined the session).
方法ID：已建立会话的标识符（即，定义会话的服务器信息TLV的会话标识符字段的内容）。
In conformance with RFC 3748 [1], the following security claims are made for the EAP-POTP method:
根据RFC 3748[1]，对EAP-POTP方法提出以下安全声明：
Authentication mechanism: Generic OTP Ciphersuite negotiation: Yes (No in basic variant) Mutual authentication: Yes (No in basic variant) Integrity protection: Yes (No in basic variant) Replay protection: Yes (see below) Confidentiality: Only in the OTP protection variant, and then only OTP values and any information sent after exchange of the Confirm TLV Key derivation: Yes (No in basic variant) Key strength: Depends on size of OTP value, strength of underlying shared secret, strength and characteristics of OTP algorithm, pepper length, iteration count, and whether the method is used within a tunnel such as PEAPv2. For some illustrative examples, and a further discussion of this, see Appendix D. Dictionary attack prot.: N/A (Human-selected passwords not used) Fast reconnect: Yes Crypt. binding: N/A (EAP-POTP is not a tunnel method) Session independence: Yes Fragmentation: N/A (Packets shall not exceed MTU of 1020) Channel binding: Yes (No in basic variant) Acknowledged S/F: Yes State Synchronization: Yes (No in basic variant)
认证机制：通用OTP密码套件协商：是（基本变体中为否）相互认证：是（基本变体中为否）完整性保护：是（基本变体中为否）重播保护：是（见下文）机密性：仅在OTP保护变体中，然后只有OTP值和交换确认TLV密钥后发送的任何信息派生：是（基本变体中为否）密钥强度：取决于OTP值的大小、底层共享秘密的强度、OTP算法的强度和特性、pepper长度、迭代计数、，以及该方法是否在PEAPv2等隧道内使用。有关一些示例以及对此的进一步讨论，请参见附录D。字典攻击保护：N/a（未使用人工选择的密码）快速重新连接：Yes Crypt。绑定：N/A（EAP-POTP不是隧道方法）会话独立性：是分段：N/A（数据包不得超过1020的MTU）通道绑定：是（基本变体中为否）已确认S/F：是状态同步：是（基本变体中为否）
The basic variant (i.e., when the protection of OTPs and mutual authentication is not used) of this EAP method does not provide session privacy, session integrity, server authentication, or protection from active attacks. In particular, man-in-the-middle attacks, where an attacker acts as an authenticator in order to acquire a valid OTP, are possible.
此EAP方法的基本变体（即，未使用OTP保护和相互身份验证时）不提供会话隐私、会话完整性、服务器身份验证或主动攻击保护。特别是，中间人攻击是可能的，其中攻击者充当身份验证器以获取有效的OTP。
Similarly, the basic variant of this EAP method does not protect against session hijacking taking place after authentication. Nor does it, in itself, protect against replay attacks, where the attacker gains access by replaying a previous valid request, but see also the next subsection. When PIN codes are transmitted, they are sent without protection and are also subject to replay attacks.
类似地，此EAP方法的基本变体不能防止在身份验证后发生会话劫持。它本身也不能防止重播攻击，即攻击者通过重播以前的有效请求获得访问权限，但请参见下一小节。当PIN码被传输时，它们在没有保护的情况下被发送，并且还会受到重播攻击。
In order to protect against these attacks, the peer MUST only use the basic variant of this method over a server-authenticated and confidentiality-protected connection. This can be achieved via use of, PEAPv2 [17], for example.
为了防止这些攻击，对等方必须仅在经过服务器身份验证且受机密性保护的连接上使用此方法的基本变体。例如，这可以通过使用PEAPv2[17]来实现。
When the OTP protection variant is used, however, the EAP method provides privacy for OTPs and new PINs, negotiation of cryptographic algorithms, mutual authentication, and protection against replay attacks and protocol version downgrades. It also provides protection against man-in-the-middle attacks, not due to the infeasibility for a man-in-the-middle to solve for a valid OTP given an OTP TLV, but due to the computational expense of finding the OTP in the limited time period during which it is valid (this is mainly true for tokens, including the current time in their OTP calculations, or when a sent challenge has a certain lifetime). It should be noted, however, that a retrieved OTP, even if "old" and invalid, still may divulge some information about the user's PIN. Clearly, this is also true for the basic variant. Implementations of this EAP method, where user PINs are sent with OTPs, are therefore RECOMMENDED to ensure regular user PIN changes, regardless of whether the protected variant or the basic variant is employed.
然而，当使用OTP保护变体时，EAP方法为OTP和新PIN提供隐私、加密算法协商、相互认证以及防止重播攻击和协议版本降级。它还提供了针对中间人攻击的保护，这不是因为中间人无法解决给定OTP TLV的有效OTP，而是因为在有限的时间段内找到OTP是有效的，这需要计算费用（这主要适用于令牌，包括其OTP计算中的当前时间，或者当发送的质询具有特定生存期时）。但是，应该注意，检索到的OTP，即使是“旧的”和无效，仍然可能泄露有关用户PIN的一些信息。显然，对于基本变体也是如此。因此，建议使用此EAP方法（用户PIN与OTP一起发送），以确保定期更改用户PIN，而不管是使用受保护的变体还是基本变体。
It should also be noted that, while it is possible for a rogue access point, e.g., to clone MAC addresses, and hence mount a man-in-the-middle attack, such an access point will not be able to calculate the session keys MSK and EMSK. This demonstrates the importance of using the derived key material properly to protect a subsequent session.
还应注意，尽管流氓接入点（例如，克隆MAC地址）有可能因此发起中间人攻击，但此类接入点将无法计算会话密钥MSK和EMSK。这说明了正确使用派生密钥材料以保护后续会话的重要性。
Protected mode protects against version downgrade attacks due to the HMAC both parties transmit in this mode. As described, each party calculates the HMAC on sent and received EAP-POTP handshake messages. If an attacker were to modify a Version TLV, this would be reflected
受保护模式可防止由于双方在此模式下传输HMAC而导致的版本降级攻击。如上所述，各方在发送和接收的EAP-POTP握手消息上计算HMAC。如果TLV被反射，则攻击者将修改此版本
in a difference between the calculated MACs (since the recipient of the Version TLV received a different value than the sender sent). Unless the attacker knows K_MAC, he cannot calculate the correct MAC, and hence the difference will be detected.
计算的MAC之间的差异（因为TLV版本的收件人收到的值与发送的发件人的值不同）。除非攻击者知道K_MAC，否则他无法计算正确的MAC，因此会检测到差异。
The OTP protection variant also protects against session hijacking, if the derived key material is used (directly or indirectly) to protect a subsequent session. For these reasons, use of the OTP protection variant is RECOMMENDED.
如果派生密钥材料（直接或间接）用于保护后续会话，OTP保护变体还可以防止会话劫持。出于这些原因，建议使用OTP保护变体。
However, it should be noted that not even the OTP protection variant provides privacy for user names and/or token key identifiers. EAP-POTP MUST be used within a secure tunnel such as the one provided by PEAPv2 [17] if privacy for these parameters is required.
然而，应注意的是，即使OTP保护变体也不能为用户名和/或令牌密钥标识符提供隐私。如果需要这些参数的隐私，则EAP-POTP必须在安全隧道内使用，如PEAPv2[17]提供的隧道。
When resuming sessions created in the basic variant (which MUST only take place within a protected tunnel), the peer is authenticated by demonstrating knowledge of not just a valid session identifier, but also the OTP used when the session was created. Server nonces prevent replay attacks, but there still remains some likelihood of an attacker guessing the correct combination of session identifier and OTP value. Assuming OTPs with entropy about 32 bits, this means that the likelihood of succeeding with such an attack is about 1/2^48 due to the birthday paradox. Servers allowing session resumption for the basic variant MUST protect against such attacks, e.g., by keeping track of the rate of failed resumption attempts.
当恢复在基本变体中创建的会话（只能在受保护的隧道中进行）时，通过证明不仅知道有效的会话标识符，而且知道创建会话时使用的OTP，对对等方进行身份验证。服务器当前值可防止重播攻击，但攻击者仍有可能猜测会话标识符和OTP值的正确组合。假设OTP的熵约为32位，这意味着由于生日悖论，成功进行此类攻击的可能性约为1/2^48。允许基本变体会话恢复的服务器必须防止此类攻击，例如，跟踪恢复尝试失败的速率。
An active attacker may replace the iteration count value in OTP TLVs sent by the peer to slow down an authentication server. Authentication servers SHOULD protect against this, e.g., by disregarding OTP TLVs with an iteration count value higher than some number that is preset or dynamically set (depending on load).
主动攻击者可能会替换对等方发送的OTP TLV中的迭代计数值，以降低身份验证服务器的速度。身份验证服务器应对此进行保护，例如，忽略迭代计数值高于预设或动态设置的某个数字（取决于负载）的OTP TLV。
As described in Section 4.8, the use of pepper will slow down an attacker's search for a matching OTP. The ability to transfer a pepper value in encrypted form from the EAP server to the peer means that, even though there may be an initial computational cost for the EAP server to authenticate the peer, subsequent authentications will be efficient, while at the same time more secure, since a pre-shared, 128-bit-long pepper value will not be easily found by an attacker. An attacker, observing an EAP-Request containing an OTP TLV calculated using a pepper chosen by the peer, may, however, depending on available resources, be able to successfully attack that particular EAP-POTP session, since it most likely will be based on a
如第4.8节所述，使用pepper会减慢攻击者搜索匹配OTP的速度。将加密形式的pepper值从EAP服务器传输到对等方的能力意味着，即使EAP服务器对对等方进行身份验证可能需要初始计算成本，但后续身份验证将是有效的，同时更安全，因为预共享，攻击者不容易找到128位长的pepper值。然而，攻击者在观察到包含OTP TLV的EAP请求时，可能会根据可用资源成功地攻击该特定EAP-POTP会话，因为该会话很可能是基于
relatively short pepper value or only an iteration count. Once the correct OTP has been found, eavesdropping on the EAP server's Confirm TLV will potentially give the attacker access to the longer, server-provided pepper for the remaining lifetime of that pepper value. For this reason, initial exchanges with EAP servers SHOULD occur in a secure environment (e.g., in a PEAPv2 tunnel offering cryptographic binding with inner EAP methods). If initial exchanges do not occur in a secure environment, the iteration count MUST be significantly higher than for messages where a pre-shared pepper is used. The lifetime of the shared pepper must also be calculated with this in mind. Finally, the peer and the EAP server MUST store the pepper value securely and associated with the user.
相对较短的值或仅迭代计数。一旦找到正确的OTP，在EAP服务器的Confirm TLV上进行窃听可能会让攻击者在该pepper值的剩余生命周期内访问更长的服务器提供的pepper。因此，与EAP服务器的初始交换应在安全环境中进行（例如，在提供内部EAP方法加密绑定的PEAPv2隧道中）。如果初始交换不是在安全环境中进行的，则迭代次数必须明显高于使用预共享的消息的次数。共享辣椒的寿命也必须考虑到这一点。最后，对等方和EAP服务器必须安全地存储pepper值并与用户关联。
In the case of fragmentation of EAP messages, it is possible (in the basic variant of this method) for an attacker to listen to most of an OTP, guess the remainder, and then race the legitimate user to complete the authentication. Conforming backend authentication server implementations MUST protect against this race condition. One defense against this attack is outlined below and borrowed from [14]; implementations MAY use this approach or MAY select an alternative defense. Note that the described defense relies on the user providing the identity in response to an initial Identity EAP-Request.
在EAP消息分段的情况下，攻击者可能（在该方法的基本变体中）侦听OTP的大部分内容，猜测其余部分，然后与合法用户竞争以完成身份验证。一致性后端身份验证服务器实现必须针对此竞争条件进行保护。针对这种攻击的一种防御措施概述如下，并借鉴了[14]；实施可以使用这种方法，也可以选择替代防御。注意，所描述的防御依赖于用户响应初始标识EAP请求而提供标识。
One possible defense is to prevent a user from starting multiple simultaneous authentication sessions. This means that once the legitimate user has initiated authentication, an attacker would be blocked until the first authentication process has completed. In this approach, a timeout is necessary to thwart a denial-of-service attack.
一种可能的防御措施是防止用户同时启动多个身份验证会话。这意味着，一旦合法用户启动了身份验证，攻击者将被阻止，直到第一个身份验证过程完成。在这种方法中，需要超时来阻止拒绝服务攻击。
This document is a description of a general EAP method for OTP tokens. It also defines EAP method 32 as a profile of the general method. Extending the set of EAP-POTP TLVs or the set of EAP-POTP cryptographic algorithms shall be seen as revisions of the protocol and hence shall require an RFC that updates or obsoletes this document.
本文档描述了OTP令牌的通用EAP方法。它还将EAP方法32定义为通用方法的概要。扩展EAP-POTP TLV集或EAP-POTP加密算法集应视为对协议的修订，因此需要更新或废弃本文件的RFC。
A new registry for EAP-POTP cryptographic algorithm identifier octets has been created. The initial contents of this registry are as specified in Section 4.11.16.
已创建EAP-POTP加密算法标识符八位字节的新注册表。本登记册的初始内容如第4.11.16节所述。
Assignment of new values for hash algorithms, encryption algorithms, and MAC algorithms in the Crypto Algorithm TLV MUST be done through IANA with "Specification Required" and "IESG Approval" (see [9] for the meaning of these terms).
加密算法TLV中散列算法、加密算法和MAC算法的新值的分配必须通过IANA完成，并具有“所需规范”和“IESG批准”（这些术语的含义见[9]）。
RSA, RSA Security, and SecurID are either registered trademarks or trademarks of RSA Security Inc. in the United States and/or other countries. The names of other products and services mentioned may be the trademarks of their respective owners.
RSA、RSA Security和SecurID是RSA Security Inc.在美国和/或其他国家/地区的注册商标或商标。提及的其他产品和服务的名称可能是其各自所有者的商标。
This document was improved by comments from, and discussion with, a number of RSA Security employees. Simon Josefsson drafted the initial versions of an RSA SecurID EAP method while working for RSA Laboratories. The inspiration for the TLV-type of information exchange comes from [17]. Special thanks to Oliver Tavakoli of Funk Software who provided numerous useful comments and suggestions, Randy Chou of Aruba Networks for good suggestions in the session resumption area, and Jim Burns of Meetinghouse who provided inspiration for the Protected TLV. Thanks also to the IESG reviewers, Pasi Eronen, David Black, and Uri Blumenthal, for insightful comments that helped to improve the document, and to Alfred Hoenes for a thorough editorial review.
许多RSA Security员工的评论和讨论改进了本文档。Simon Josefsson在为RSA实验室工作时起草了RSA SecurID EAP方法的初始版本。TLV类型信息交换的灵感来自[17]。特别感谢Funk软件公司的Oliver Tavakoli提供了大量有用的意见和建议，阿鲁巴网络公司的Randy Chou在会议恢复区域提供了良好的建议，Meetinghouse公司的Jim Burns为受保护的TLV提供了灵感。还要感谢IESG的评论员帕西·埃隆、大卫·布莱克和乌里·布卢门塔尔的富有洞察力的评论，这些评论有助于改进该文件，并感谢阿尔弗雷德·霍恩斯的全面编辑评论。
[1] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[1] Blunk，L.，Vollbrecht，J.，Aboba，B.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 37482004年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, February 2004.
[3] 国家标准与技术研究所，“安全哈希标准”，FIPS 180-22004年2月。
[4] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197, November 2001.
[4] 国家标准与技术研究所，“高级加密标准（AES）规范”，FIPS 197，2001年11月。
[5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[5] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[6] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[6] Kaliski，B.，“PKCS#5：基于密码的加密规范2.0版”，RFC 28982000年9月。
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[7] Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[8] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[8] Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
[9] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，RFC 2434，1998年10月。
[10] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[10] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[11] The Institute of Electrical and Electronics Engineers, Inc., "IEEE Standard for Local and metropolitan area networks -- Port-Based Network Access Control", IEEE 802.1X-2001, July 2001.
[11] 电气和电子工程师协会，“局域网和城域网的IEEE标准——基于端口的网络访问控制”，IEEE 802.1X-2001，2001年7月。
[12] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[12] Kaufman，C.，编辑，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[13] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[13] Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 4017，2005年3月。
[14] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time Password System", STD 61, RFC 2289, February 1998.
[14] Haller，N.，Metz，C.，Nesser，P.，和M.Straw，“一次性密码系统”，STD 61，RFC 2289，1998年2月。
[15] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[15] Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[16] Aboba, B., Simon, D., Eronen, P., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, October 2006.
[16] Aboba，B.，Simon，D.，Eronen，P.，和H.Levkowetz，编辑，“可扩展认证协议（EAP）密钥管理框架”，正在进行的工作，2006年10月。
[17] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
[17] Palekar，A.，Simon，D.，Zorn，G.，Salowey，J.，Zhou，H.，和S.Josefsson，“受保护的EAP协议（PEAP）版本2”，正在进行的工作，2004年10月。
[18] Internet Assigned Numbers Authority, "Private Enterprise Numbers", December 2006.
[18] 互联网分配号码管理局，“私营企业号码”，2006年12月。
[19] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[19] Zorn，G.“微软供应商特定半径属性”，RFC 2548，1999年3月。
Note: The RSA SecurID product is a hardware token card (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication.
注意：RSA SecurID产品是RSA Security Inc.生产的硬件令牌卡（或其软件仿真），用于最终用户身份验证。
The EAP method type identifier for the RSA SecurID profile of EAP-POTP is 32.
EAP-POTP的RSA SecurID配置文件的EAP方法类型标识符为32。
Peers and EAP servers implementing the SecurID profile of EAP-POTP SHALL conform to all EAP-POTP normative requirements in this Document. In addition, the New PIN TLV and the Protected TLV MUST be supported by peers.
实施EAP-POTP SecurID配置文件的对等方和EAP服务器应符合本文件中的所有EAP-POTP规范要求。此外，新的引脚TLV和受保护的TLV必须由对等方支持。
This appendix is non-normative. In the examples, "V1", "V2", "V3", etc., stand for arbitrary values of the correct type.
本附录为非规范性附录。在示例中，“V1”、“V2”、“V3”等表示正确类型的任意值。
This mode should only be used within a secured tunnel. The peer identifies itself with a User Identifier TLV.
此模式只能在安全隧道内使用。对等方使用用户标识符TLV标识自己。
Peer EAP server
对等EAP服务器
<- EAP-Request Type=Identity
<-EAP请求类型=标识
EAP-Response -> Type=Identity
EAP响应->类型=标识
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Version TLV: Highest=0,Lowest=0
版本TLV：最高=0，最低=0
OTP TLV:
P=0,C=0,N=0,T=0,E=0,R=0
OTP TLV:
P=0,C=0,N=0,T=0,E=0,R=0
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Version TLV: Highest=0
版本TLV:最高=0
OTP TLV:
P=0,C=0,N=0,T=0,E=0,R=0
Authentication Data=V1
OTP TLV:
P=0,C=0,N=0,T=0,E=0,R=0
Authentication Data=V1
User Identifier TLV: User Identifier=V2
用户标识符TLV:用户标识符=V2
<- EAP-Success
<-EAP成功
This example illustrates successful resumption of a basic mode session. It must be carried out only in a protected tunnel.
此示例演示了基本模式会话的成功恢复。只能在受保护的隧道内进行。
Peer EAP server
对等EAP服务器
<- EAP-Request Type=Identity
<-EAP请求类型=标识
EAP-Response -> Type=Identity
EAP响应->类型=标识
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Version TLV: Highest=0,Lowest=0
版本TLV：最高=0，最低=0
OTP TLV:
P=0,C=0,N=0,T=0,E=0,R=0
OTP TLV:
P=0,C=0,N=0,T=0,E=0,R=0
Server-Info TLV: N=0 Session Identifier=V1 Server Identifier=V2 Nonce=V3 EAP-Response -> Type=OTP-X
服务器信息TLV:N=0会话标识符=V1服务器标识符=V2当前值=V3 EAP响应->类型=OTP-X
Version TLV: Highest=0
版本TLV:最高=0
Resume TLV: Session Identifier=V4 (indicating earlier, basic mode, session) Authentication Data=V5
Resume TLV:Session Identifier=V4（指示早期的基本模式、会话）身份验证数据=V5
<- EAP-Success
<-EAP成功
In this case, the peer uses the token key identifier, in addition to the user identifier. The initial EAP-Identity exchange may also provide user information, or may be restricted to only general domain information. Pepper is not used, but will be used in a subsequent session since the server provides the peer with an encrypted pepper in its Confirm TLV. Absence of the Crypto Algorithm TLV indicates use of default cryptographic algorithms.
在这种情况下，对等方除了使用用户标识符外，还使用令牌密钥标识符。初始EAP身份交换还可以提供用户信息，或者可能仅限于一般域信息。Pepper未使用，但将在后续会话中使用，因为服务器在其Confirm TLV中向对等方提供加密的Pepper。缺少加密算法TLV表示使用默认加密算法。
Peer EAP server
对等EAP服务器
<- EAP-Request Type=Identity
<-EAP请求类型=标识
EAP-Response -> Type=Identity
EAP响应->类型=标识
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Version TLV: Highest=0,Lowest=0
版本TLV：最高=0，最低=0
Server-Info TLV: N=0 Session Identifier=V1 Server Identifier=V2 Nonce=V3
服务器信息TLV:N=0会话标识符=V1服务器标识符=V2当前值=V3
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=0
Iteration Count=V4
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=0
Iteration Count=V4
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Version TLV: Highest=0
版本TLV:最高=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=0
Iteration Count=V4
Authentication Data=V5
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=0
Iteration Count=V4
Authentication Data=V5
User Identifier TLV: User Identifier=V6
用户标识符TLV:User Identifier=V6
Token Key Identifier TLV: Token Key Identifier=V7
令牌密钥标识符TLV:令牌密钥标识符=V7
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Confirm TLV: C=0 Authentication Data=V8 Pepper Identifier=V9 Encrypted Pepper=V10
确认TLV:C=0身份验证数据=V8 Pepper标识符=V9加密Pepper=V10
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Confirm TLV: (no data)
确认TLV：（无数据）
<- EAP-Success
<-EAP成功
The difference between this example and the previous one is that the peer makes use of an existing pepper in the PBKDF2 computation. The EAP server provides a new pepper to the peer in the Confirm TLV. Note that the peer had not been able to use a pepper in the response calculation unless it had found the existing pepper, since the server specified a maximum (new) pepper length of zero.
此示例与前一个示例的区别在于，对等方在PBKDF2计算中使用了现有的pepper。EAP服务器向Confirm TLV中的对等方提供新的pepper。请注意，对等方无法在响应计算中使用pepper，除非它找到了现有pepper，因为服务器指定的最大（新）pepper长度为零。
Peer EAP server
对等EAP服务器
<- EAP-Request Type=Identity
<-EAP请求类型=标识
EAP-Response -> Type=Identity
EAP响应->类型=标识
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Version TLV: Highest=0,Lowest=0
版本TLV：最高=0，最低=0
Server-Info TLV: N=0 Session Identifier=V1 Server Identifier=V2 Nonce=V3
服务器信息TLV:N=0会话标识符=V1服务器标识符=V2当前值=V3
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=0
Iteration Count=V4
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=0
Iteration Count=V4
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Version TLV: Highest=0
版本TLV:最高=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V5
Iteration Count=V6
Authentication Data=V7
(includes a pepper identifier)
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V5
Iteration Count=V6
Authentication Data=V7
(includes a pepper identifier)
User Identifier TLV: User Identifier=V8
用户标识符TLV:User Identifier=V8
Token Key Identifier TLV: Token Key Identifier=V9
令牌密钥标识符TLV:令牌密钥标识符=V9
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Confirm TLV: C=0 Authentication Data=V10 Pepper Identifier=V11 Encrypted Pepper=V12
确认TLV:C=0身份验证数据=V10辣椒标识符=V11加密辣椒=V12
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Confirm TLV: (no data)
确认TLV：（无数据）
<- EAP-Success B.5. Failed Mutual Authentication
<-EAP成功B.5。相互身份验证失败
This example differs from the previous one in that the peer is not able to authenticate the server. Therefore, it sends an empty EAP-Response of type POTP-X, which the EAP server acknowledges by responding with an EAP-Failure. Pepper is not used.
此示例与前一个示例的不同之处在于，对等方无法对服务器进行身份验证。因此，它发送类型为POTP-X的空EAP响应，EAP服务器通过响应EAP故障来确认该响应。胡椒粉不用。
Peer EAP server
对等EAP服务器
<- EAP-Request Type=Identity
<-EAP请求类型=标识
EAP-Response -> Type=Identity
EAP响应->类型=标识
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Version TLV: Highest=0,Lowest=0
版本TLV：最高=0，最低=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5
服务器信息TLV:N=0会话标识符=V3服务器标识符=V4当前值=V5
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Version TLV: Highest=0
版本TLV:最高=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
Authentication Data=V6
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
Authentication Data=V6
User Identifier TLV: User Identifier=V7
用户标识符TLV:User Identifier=V7
Token Key Identifier TLV: Token Key Identifier=V8
令牌密钥标识符TLV：令牌密钥标识符=V8
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Confirm TLV: C=0 Authentication Data=V9
确认TLV:C=0身份验证数据=V9
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
(no data)
（无数据）
<- EAP-Failure
<-EAP故障
This example illustrates successful session resumption.
此示例演示了成功的会话恢复。
Peer EAP server
对等EAP服务器
<- EAP-Request Type=Identity
<-EAP请求类型=标识
EAP-Response -> Type=Identity
EAP响应->类型=标识
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Version TLV: Highest=0,Lowest=0
版本TLV：最高=0，最低=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5
服务器信息TLV:N=0会话标识符=V3服务器标识符=V4当前值=V5
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Version TLV: Highest=0
版本TLV:最高=0
Resume TLV: Session Identifier=V6 (indicating earlier, protected mode, session) Authentication Data=V7
Resume TLV:Session Identifier=V6（指示早期的受保护模式，会话）身份验证数据=V7
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Confirm TLV: C=0 Authentication Data=V8
确认TLV:C=0身份验证数据=V8
EAP-Response -> Type=OTP-X Confirm TLV: (no data)
EAP响应->类型=OTP-X确认TLV：（无数据）
<- EAP-Success
<-EAP成功
This example illustrates a failed session resumption, followed by a complete mutual authentication. The user is identified through the User Identifier TLV. The client is able to reuse an older pepper. The server sends a new pepper for subsequent use in its Confirm TLV. The server suggests some non-default cryptographic algorithms, but the client only supports the default ones.
此示例演示了失败的会话恢复，然后是完整的相互身份验证。通过用户标识符TLV识别用户。客户可以重复使用旧胡椒。服务器发送一个新的pepper，以供后续在其Confirm TLV中使用。服务器建议一些非默认的加密算法，但客户端只支持默认的加密算法。
Peer EAP server
对等EAP服务器
<- EAP-Request Type=Identity
<-EAP请求类型=标识
EAP-Response -> Type=Identity
EAP响应->类型=标识
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Version TLV: Highest=0,Lowest=0
版本TLV：最高=0，最低=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5
服务器信息TLV:N=0会话标识符=V3服务器标识符=V4当前值=V5
Crypto Algorithm TLV: Hash Alg. Length=V6 Hash Algorithms=V7 Encr. Alg. Length=V8 Encr. Algorithms=V9 MAC Alg. Length=V10 MAC Algorithms=V11
加密算法TLV:Hash Alg。长度=V6哈希算法=V7 Encr。阿尔格。长度=V8 Encr。算法=V9 MAC Alg。长度=V10 MAC算法=V11
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Version TLV: Highest=0
版本TLV:最高=0
Resume TLV: Session Identifier=V12 (indicating earlier session) Authentication Data=V13
会话数据=V12，表示会话恢复
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V14
Iteration Count=V15
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V14
Iteration Count=V15
Server-Info TLV: N=1 (no resumption) Session Identifier=V3 Server Identifier=V4 Nonce=V16
服务器信息TLV:N=1（无恢复）会话标识符=V3服务器标识符=V4 Nonce=V16
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
OTP TLV:
P=1,C=0,N=1,T=1,E=0,R=0
Pepper Length=V17
Iteration Count=V18
Authentication Data=V19 (with pepper identifier)
OTP TLV:
P=1,C=0,N=1,T=1,E=0,R=0
Pepper Length=V17
Iteration Count=V18
Authentication Data=V19 (with pepper identifier)
User Identifier TLV: User Identifier=V20
用户标识符TLV:用户标识符=V20
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Confirm TLV: C=0 Authentication Data=V21 Pepper Identifier=V22 Encrypted Pepper=V23 EAP-Response -> Type=OTP-X
确认TLV:C=0身份验证数据=V21 Pepper标识符=V22加密Pepper=V23 EAP响应->类型=OTP-X
Confirm TLV: (no data)
确认TLV：（无数据）
<- EAP-Success
<-EAP成功
B.8. Mutual Authentication, and New PIN Requested.
B.8. 相互验证，并请求新PIN。
In this example, the user is also requested to select a new PIN. The new PIN is allowed to be alphanumeric, and must be at least 6 characters long. The user selects another PIN than the one suggested by the server. The token key is identified through a combination of the user identifier and the token key identifier. While waiting for the user input, to avoid network timeouts, the peer sends an EAP-Response containing a Keep-Alive TLV to the EAP server. The EAP server responds by sending an EAP-Request containing a Keep-Alive TLV back to the peer. Note that all TLVs exchanged after the Confirm TLV exchange are wrapped in the Protected TLV. Absence of the Crypto Algorithm TLV indicates use of default cryptographic algorithms.
在此示例中，还要求用户选择一个新PIN。新PIN允许为字母数字，且长度必须至少为6个字符。用户选择的PIN与服务器建议的PIN不同。令牌密钥通过用户标识符和令牌密钥标识符的组合来识别。在等待用户输入时，为了避免网络超时，对等方向EAP服务器发送包含保持活动TLV的EAP响应。EAP服务器通过将包含保持活动TLV的EAP请求发送回对等方进行响应。请注意，在确认TLV交换后交换的所有TLV都包装在受保护的TLV中。缺少加密算法TLV表示使用默认加密算法。
Peer EAP server
对等EAP服务器
<- EAP-Request Type=Identity
<-EAP请求类型=标识
EAP-Response -> Type=Identity
EAP响应->类型=标识
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Version TLV: Highest=0,Lowest=0
版本TLV：最高=0，最低=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5
服务器信息TLV:N=0会话标识符=V3服务器标识符=V4当前值=V5
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Version TLV: Highest=0
版本TLV:最高=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V6
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V6
Iteration Count=V7 Authentication Data=V8 (with pepper identifier)
迭代计数=V7身份验证数据=V8（带pepper标识符）
User Identifier TLV: User Identifier=V9
用户标识符TLV:用户标识符=V9
Token Key Identifier TLV: Token Key Identifier=V10
令牌密钥标识符TLV:令牌密钥标识符=V10
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Confirm TLV: C=1 Authentication Data=V11
确认TLV:C=1身份验证数据=V11
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Confirm TLV: (no data)
确认TLV：（无数据）
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Protected TLV:
MAC=V12
IV=V13
Encrypted TLVs=V14
(Contains:
New PIN TLV:
Q=0,A=1
PIN=V15
Min. PIN Length=6)
Protected TLV:
MAC=V12
IV=V13
Encrypted TLVs=V14
(Contains:
New PIN TLV:
Q=0,A=1
PIN=V15
Min. PIN Length=6)
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Protected TLV: MAC=V16 IV=V17 Encrypted TLVs=V18 (Contains: Keep-Alive TLV: (no data))
受保护的TLV:MAC=V16 IV=V17加密的TLV=V18（包含：保持活动TLV:（无数据））
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Protected TLV: MAC=V19 IV=V20 Encrypted TLVs=V21 (Contains: Keep-Alive TLV: (no data))
受保护的TLV:MAC=V19 IV=V20加密的TLV=V21（包含：保持活动TLV:（无数据））
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Protected TLV:
MAC=V22
IV=V23
Encrypted TLVs=V24
(Contains:
New PIN TLV:
Q=0,A=0
PIN=V25)
Protected TLV:
MAC=V22
IV=V23
Encrypted TLVs=V24
(Contains:
New PIN TLV:
Q=0,A=0
PIN=V25)
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Protected TLV:
MAC=V26
IV=V27
Encrypted TLVs=V28
(Contains:
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2)
Protected TLV:
MAC=V26
IV=V27
Encrypted TLVs=V28
(Contains:
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2)
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Protected TLV
MAC=V29
IV=V30
Encrypted TLVs=V31
(Contains:
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V6
Iteration Count=V7
Authentication Data=V31)
Protected TLV
MAC=V29
IV=V30
Encrypted TLVs=V31
(Contains:
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V6
Iteration Count=V7
Authentication Data=V31)
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Protected TLV MAC=V32 IV=V33 Encrypted TLVs=V34 (Contains: Confirm TLV: C=0 Authentication Data=V35)
受保护的TLV MAC=V32 IV=V33加密的TLV=V34（包含：确认TLV:C=0身份验证数据=V35）
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Protected TLV MAC=V36 IV=V37 Encrypted TLVs=V38 (Contains: Confirm TLV: (no data))
受保护的TLV MAC=V36 IV=V37加密的TLV=V38（包含：确认TLV:（无数据））
<- EAP-Success
<-EAP成功
In this example, the peer is requested to provide a second OTP to the EAP server.
在此示例中，请求对等方向EAP服务器提供第二个OTP。
Peer EAP server
对等EAP服务器
<- EAP-Request Type=Identity
<-EAP请求类型=标识
EAP-Response -> Type=Identity
EAP响应->类型=标识
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Version TLV: Highest=0,Lowest=0
版本TLV：最高=0，最低=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
Server-Info TLV: N=0 Session Identifier=V3 Server Identifier=V4 Nonce=V5
服务器信息TLV:N=0会话标识符=V3服务器标识符=V4当前值=V5
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Version TLV: Highest=0
版本TLV:最高=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V6
Iteration Count=V7
Authentication Data=V8
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V6
Iteration Count=V7
Authentication Data=V8
User Identifier TLV: User Identifier=V9
用户标识符TLV:用户标识符=V9
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
OTP TLV:
P=1,C=0,N=1,T=1,E=0,R=0
Pepper Length=V1
Iteration Count=V2
OTP TLV:
P=1,C=0,N=1,T=1,E=0,R=0
Pepper Length=V1
Iteration Count=V2
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
OTP TLV:
P=1,C=0,N=1,T=1,E=0,R=0
Pepper Length=V6
Iteration Count=V7
Authentication Data=V10
OTP TLV:
P=1,C=0,N=1,T=1,E=0,R=0
Pepper Length=V6
Iteration Count=V7
Authentication Data=V10
<- EAP-Request Type=OTP-X
<-EAP请求类型=OTP-X
Confirm TLV: C=0 Authentication Data=V11
确认TLV:C=0身份验证数据=V11
EAP-Response -> Type=OTP-X
EAP响应->类型=OTP-X
Confirm TLV: (no data)
确认TLV：（无数据）
<- EAP-Success
<-EAP成功
Appendix C. Use of the MPPE-Send/Receive-Key RADIUS Attributes
附录C.MPPE发送/接收密钥半径属性的使用
This section describes how to populate the MPPE-Send-Key and the MPPE-Receive-Key RADIUS attributes defined in [19], using an MSK established in EAP-POTP.
本节介绍如何使用EAP-POTP中建立的MSK填充[19]中定义的MPPE发送密钥和MPPE接收密钥半径属性。
Once the EAP-POTP MSK has been generated, it is used as follows to populate the MPPE-Send-Key and the MPPE-Receive-Key attributes:
生成EAP-POTP MSK后，它将按如下方式用于填充MPPE发送密钥和MPPE接收密钥属性：
Use the initial 32 octets of the MSK as the value for the "Key" sub-field in the plaintext "String" field of the MPPE-Send-Key attribute, and use the final 32 octets of the MSK as the "Key" sub-field in the plaintext "String" field of the MPPE-Receive-Key attribute (Note: "Send" and "Receive" here refer to the Authenticator; for the peer, they are reversed).
使用MSK的初始32个八位字节作为MPPE发送密钥属性的明文“字符串”字段中的“密钥”子字段的值，并使用MSK的最后32个八位字节作为MPPE接收密钥属性的明文“字符串”字段中的“密钥”子字段（注：“发送”和“接收”这里指的是验证器；对于对等方，它们是反向的）。
As described in Section 6, the strength of keys generated in EAP-POTP protected mode depends on a number of factors. This appendix provides examples of actual key strengths achieved under various assumptions.
如第6节所述，在EAP-POTP保护模式下生成的密钥的强度取决于许多因素。本附录提供了在各种假设下实现的实际关键优势的示例。
It should be noted that, while some of the examples indicate that the strength of generated keys is relatively weak, the strength applies only to those EAP-POTP sessions between a peer and an EAP server that do not share a pepper. Once a pepper, provided by an EAP server to a peer, has been established, future sessions using this pepper will provide full-strength keys.
应当注意，虽然一些示例表明生成密钥的强度相对较弱，但该强度仅适用于对等方和不共享密钥的EAP服务器之间的EAP-POTP会话。一旦EAP服务器向对等方提供了pepper，使用该pepper的未来会话将提供全强度密钥。
In this example we assume the following:
在本例中，我们假设如下：
OTPs are six decimal digits long;
OTP的长度为六位小数；
4-digit PINs are added to generated OTPs; and
将4位管脚添加到生成的OTP中；和
OTP hardening (iteration count and pepper searching combined) effectively adds 10 bits of entropy. One way of achieving this without use of pepper searching is to have the iteration count in PBKDF2 set to 1,000,000.
OTP强化（迭代计数和胡椒搜索相结合）有效地增加了10位熵。在不使用pepper搜索的情况下实现这一点的一种方法是将PBKDF2中的迭代计数设置为1000000。
The effective key strength then becomes roughly:
然后，有效关键强度大致变为：
log_2(10**6) + log_2(10**4) + log_2(2**10) = 43 bits
log_2(10**6) + log_2(10**4) + log_2(2**10) = 43 bits
The above assumes that the entropy of the underlying shared secret is >43 bits and that there are no other weaknesses in the OTP algorithm.
以上假设底层共享秘密的熵大于43位，并且OTP算法中没有其他弱点。
In this example we assume the following:
在本例中，我们假设如下：
OTPs are eight decimal digits long;
OTP的长度为八位小数；
4-character alphanumeric PINs are added to generated OTPs; and
将4个字符的字母数字管脚添加到生成的OTP中；和
OTP hardening (iteration count and pepper searching combined) effectively adds 10 bits of entropy.
OTP强化（迭代计数和胡椒搜索相结合）有效地增加了10位熵。
The effective key strength then becomes roughly:
然后，有效关键强度大致变为：
log_2(10**8) + log_2(26**4) + log_2(2**10) = 55 bits
log_2(10**8) + log_2(26**4) + log_2(2**10) = 55 bits
The above assumes that the entropy of the underlying shared secret is >55 bits and that there are no other weaknesses in the OTP algorithm.
以上假设底层共享秘密的熵大于55位，并且OTP算法中没有其他弱点。
Author's Address
作者地址
Magnus Nystroem RSA Security
Magnus Nystroem RSA安全
EMail: magnus@rsa.com
EMail: magnus@rsa.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。