Internet Engineering Task Force (IETF) G. Richards
Request for Comments: 6560 RSA, The Security Division of EMC
Category: Standards Track April 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) G. Richards
Request for Comments: 6560 RSA, The Security Division of EMC
Category: Standards Track April 2012
ISSN: 2070-1721
One-Time Password (OTP) Pre-Authentication
一次性密码（OTP）预认证
Abstract
摘要
The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One-Time Password (OTP) authentication.
Kerberos协议提供了一个使用预认证数据交换对客户机进行认证的框架。本文档介绍如何使用此框架执行一次性密码（OTP）身份验证。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6560.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6560.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人可能没有授予IETF信托允许的权利
modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
在IETF标准过程之外修改此类材料。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Overall Design .............................................3
1.3. Conventions Used in This Document ..........................4
2. Usage Overview ..................................................4
2.1. OTP Mechanism Support ......................................4
2.2. Pre-Authentication .........................................4
2.3. PIN Change .................................................5
2.4. Resynchronization ..........................................6
3. Pre-Authentication Protocol Details .............................6
3.1. Initial Client Request .....................................6
3.2. KDC Challenge ..............................................7
3.3. Client Response ............................................9
3.4. Verifying the Pre-Authentication Data .....................13
3.5. Confirming the Reply Key Change ...........................15
3.6. Reply Key Generation ......................................15
4. OTP Kerberos Message Types .....................................17
4.1. PA-OTP-CHALLENGE ..........................................17
4.2. PA-OTP-REQUEST ............................................21
4.3. PA-OTP-PIN-CHANGE .........................................25
5. IANA Considerations ............................................26
6. Security Considerations ........................................27
6.1. Man-in-the-Middle Attacks .................................27
6.2. Reflection ................................................28
6.3. Denial-of-Service Attacks .................................28
6.4. Replay ....................................................29
6.5. Brute-Force Attack ........................................29
6.6. FAST Facilities ...........................................30
8. Acknowledgments ................................................30
8. References .....................................................31
8.1. Normative References ......................................31
8.2. Informative References ....................................32
Appendix A. ASN.1 Module ....................................... 33
Appendix B. Examples of OTP Pre-Authentication Exchanges ........ 36
B.1. Four-Pass Authentication ................................. 36
B.2. Two-Pass Authentication ................................. 38
B.3. PIN Change ............................................... 40
B.4. Resynchronization ....................................... 41
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Overall Design .............................................3
1.3. Conventions Used in This Document ..........................4
2. Usage Overview ..................................................4
2.1. OTP Mechanism Support ......................................4
2.2. Pre-Authentication .........................................4
2.3. PIN Change .................................................5
2.4. Resynchronization ..........................................6
3. Pre-Authentication Protocol Details .............................6
3.1. Initial Client Request .....................................6
3.2. KDC Challenge ..............................................7
3.3. Client Response ............................................9
3.4. Verifying the Pre-Authentication Data .....................13
3.5. Confirming the Reply Key Change ...........................15
3.6. Reply Key Generation ......................................15
4. OTP Kerberos Message Types .....................................17
4.1. PA-OTP-CHALLENGE ..........................................17
4.2. PA-OTP-REQUEST ............................................21
4.3. PA-OTP-PIN-CHANGE .........................................25
5. IANA Considerations ............................................26
6. Security Considerations ........................................27
6.1. Man-in-the-Middle Attacks .................................27
6.2. Reflection ................................................28
6.3. Denial-of-Service Attacks .................................28
6.4. Replay ....................................................29
6.5. Brute-Force Attack ........................................29
6.6. FAST Facilities ...........................................30
8. Acknowledgments ................................................30
8. References .....................................................31
8.1. Normative References ......................................31
8.2. Informative References ....................................32
Appendix A. ASN.1 Module ....................................... 33
Appendix B. Examples of OTP Pre-Authentication Exchanges ........ 36
B.1. Four-Pass Authentication ................................. 36
B.2. Two-Pass Authentication ................................. 38
B.3. PIN Change ............................................... 40
B.4. Resynchronization ....................................... 41
This document describes a Flexible Authentication Secure Tunneling (FAST) [RFC6113] factor that allows One-Time Password (OTP) values to be used in the Kerberos V5 [RFC4120] pre-authentication in a manner that does not require use of the user's Kerberos password. The system is designed to work with different types of OTP algorithms such as time-based OTPs [RFC2808], counter-based tokens [RFC4226] and challenge-response systems such as [RFC2289]. It is also designed to work with tokens that are electronically connected to the user's computer via means such as a USB interface.
本文档描述了一个灵活的身份验证安全隧道（FAST）[RFC6113]因素，该因素允许在Kerberos V5[RFC4120]预身份验证中以不需要使用用户Kerberos密码的方式使用一次性密码（OTP）值。该系统设计用于不同类型的OTP算法，如基于时间的OTP[RFC2808]、基于计数器的令牌[RFC4226]和质询响应系统，如[RFC2289]。它还设计用于通过USB接口等方式与用户计算机进行电子连接的令牌。
This FAST factor provides the following facilities (as defined in [RFC6113]): client-authentication, replacing-reply-key, and KDC-authentication. It does not provide the strengthening-reply-key facility.
此快速因素提供以下功能（如[RFC6113]中所定义）：客户端身份验证、替换应答密钥和KDC身份验证。它不提供增强应答键功能。
This proposal is partially based upon previous work on integrating single-use authentication mechanisms into Kerberos [HORENEZ004].
本提案部分基于先前关于将一次性身份验证机制集成到Kerberos中的工作[Hornez004]。
This proposal supports four- and two-pass variants. In the four-pass system, the client sends the Key Distribution Center (KDC) an initial AS-REQ, and the KDC responds with a KRB-ERROR containing pre-authentication data that includes a random nonce. The client then encrypts the nonce and returns it to the KDC in a second AS-REQ. Finally, the KDC returns the AS-REP. In the two-pass variant, the client encrypts a timestamp rather than a nonce from the KDC, and the encrypted data is sent to the KDC in the initial AS-REQ. The two-pass system can be used in cases where the client can determine in advance that OTP pre-authentication is supported by the KDC, which OTP key should be used and the encryption parameters required by the KDC.
此方案支持四通道和两通道变体。在四通系统中，客户机向密钥分发中心（KDC）发送初始AS-REQ，KDC使用包含随机非随机数的预认证数据的KRB-ERROR进行响应。然后，客户端加密nonce，并在第二个AS-REQ中将其返回给KDC。最后，KDC返回AS-REP。在双过程变量中，客户机加密来自KDC的时间戳而不是nonce，并且加密数据在初始AS-REQ中发送到KDC。在客户端可以提前确定KDC支持OTP预认证、应使用哪个OTP密钥以及KDC所需的加密参数的情况下，可以使用双通道系统。
In both systems, in order to create the message sent to the KDC, the client must generate the OTP value and two keys: the classic Reply Key used to decrypt the KDC's reply and a key to encrypt the data sent to the KDC. In most cases, the OTP value will be used in the key generation, but in order to support algorithms where the KDC cannot obtain the value (e.g., [RFC2289]), the system supports the option of including the OTP value in the request along with the encrypted nonce. In addition, in order to support situations where the KDC is unable to obtain the plaintext OTP value, the system also supports the use of hashed OTP values in the key derivation.
在这两个系统中，为了创建发送到KDC的消息，客户端必须生成OTP值和两个密钥：用于解密KDC应答的经典应答密钥和用于加密发送到KDC的数据的密钥。在大多数情况下，OTP值将用于密钥生成，但为了支持KDC无法获得该值的算法（例如，[RFC2289]），系统支持将OTP值与加密的nonce一起包含在请求中的选项。此外，为了支持KDC无法获得明文OTP值的情况，系统还支持在密钥派生中使用哈希OTP值。
The pre-authentication data sent from the client to the KDC is sent within the encrypted data provided by the FAST pre-authentication data type of the AS-REQ. The KDC then obtains the OTP value, generates the same keys, and verifies the pre-authentication data by decrypting the nonce. If the verification succeeds, then it confirms knowledge of the Reply Key by using it to encrypt data in the AS-REP.
从客户端发送到KDC的预认证数据在AS-REQ的FAST预认证数据类型提供的加密数据内发送。KDC然后获得OTP值，生成相同的密钥，并通过解密nonce来验证预认证数据。如果验证成功，则通过使用应答密钥加密AS-REP中的数据来确认对应答密钥的了解。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document assumes familiarity with the Kerberos pre-authentication framework [RFC6113] and so freely uses terminology and notation from that document.
本文档假定您熟悉Kerberos预认证框架[RFC6113]，因此可以自由使用该文档中的术语和符号。
The word padata is used as shorthand for pre-authentication data.
padata一词用作预认证数据的简写。
As described above, this document describes a generic system for supporting different OTP mechanisms in Kerberos pre-authentication. To ensure interoperability, all implementations of this specification SHOULD provide a mechanism (e.g., a provider interface) to add or remove support for a particular OTP mechanism.
如上所述，本文档描述了在Kerberos预身份验证中支持不同OTP机制的通用系统。为了确保互操作性，本规范的所有实现都应提供一种机制（例如，提供者接口），以添加或删除对特定OTP机制的支持。
The approach uses pre-authentication data in AS-REQ, AS-REP, and KRB-ERROR messages.
该方法在AS-REQ、AS-REP和KRB-ERROR消息中使用预认证数据。
In the four-pass system, the client begins by sending an initial AS-REQ to the KDC that may contain pre-authentication data such as the standard Kerberos password data. The KDC will then determine, in an implementation dependent fashion, whether OTP authentication is required and if it is, it will respond with a KRB-ERROR message containing a PA-OTP-CHALLENGE (see Section 4.1) in the PA-DATA.
在四通道系统中，客户端首先向KDC发送初始AS-REQ，该初始AS-REQ可能包含预认证数据，如标准Kerberos密码数据。然后，KDC将以依赖于实现的方式确定是否需要OTP身份验证，如果需要，KDC将以包含PA-DATA中PA-OTP-CHALLENGE（见第4.1节）的KRB-ERROR消息进行响应。
The PA-OTP-CHALLENGE will contain a KDC-generated nonce, a list of hash algorithm identifiers, and an iteration count if hashed OTP values are used (see Section 3.6) and OPTIONAL information on how the OTP should be generated by the client. The client will then generate the OTP value and two keys: a Client Key to encrypt the KDC's nonce and a Reply Key used to decrypt the KDC's reply.
PA-OTP-CHALLENGE将包含KDC生成的nonce、哈希算法标识符列表和迭代计数（如果使用哈希OTP值）（参见第3.6节），以及关于客户端应如何生成OTP的可选信息。然后，客户端将生成OTP值和两个密钥：用于加密KDC的nonce的客户端密钥和用于解密KDC的应答的应答密钥。
As described in Section 5.4.1 of [RFC6113], the FAST system uses an Armor Key to set up an encrypted tunnel for use by FAST factors. As described in Section 3.6 of this document, the Client Key and Reply Key will be generated from the Armor Key and the OTP value, unless the OTP algorithm does not allow the KDC to obtain the OTP value. If hash algorithm identifiers were included in the PA-OTP-CHALLENGE, then the client will use the hash of the OTP value rather than the plaintext value in the key generation. Both keys will have the same encryption type as the Armor Key.
如[RFC6113]第5.4.1节所述，FAST系统使用装甲密钥设置加密隧道，供FAST factors使用。如本文件第3.6节所述，客户机密钥和回复密钥将由Armor密钥和OTP值生成，除非OTP算法不允许KDC获得OTP值。如果哈希算法标识符包括在PA-OTP-CHALLENGE中，那么客户端将在密钥生成中使用OTP值的哈希而不是明文值。这两个密钥将具有与Armor密钥相同的加密类型。
The generated Client Key will be used to encrypt the nonce received from the KDC. The encrypted value along with optional information on how the OTP was generated are then sent to the KDC in a PA-OTP-REQUEST (see Section 4.2) encrypted within the armored-data of a PA-FX-FAST-REQUEST PA-DATA element of a second AS-REQ.
生成的客户端密钥将用于加密从KDC接收的nonce。加密值以及关于如何生成OTP的可选信息随后在PA-OTP-REQUEST（见第4.2节）中发送给KDC，该PA-OTP-REQUEST在第二个AS-REQ的PA-FX-FAST-REQUEST PA-data元素的铠装数据中加密。
In the two-pass system, the client sends the PA-OTP-REQUEST in the initial AS-REQ instead of sending it in response to a PA-OTP-CHALLENGE returned by the KDC. Since no challenge is received from the KDC, the client includes an encrypted timestamp in the request rather than the encrypted KDC nonce.
在双通道系统中，客户机在初始AS-REQ中发送PA-OTP-REQUEST，而不是响应KDC返回的PA-OTP-CHALLENGE发送请求。由于没有收到来自KDC的质询，因此客户端在请求中包含加密的时间戳，而不是加密的KDC nonce。
In both cases, on receipt of a PA-OTP-REQUEST, the KDC generates the keys in the same way as the client, and uses the generated Client Key to verify the pre-authentication by decrypting the encrypted data sent by the client (either nonce or timestamp). If the validation succeeds, then the KDC will authenticate itself to the client and confirm that the Reply Key has been updated by using the generated Reply Key in the AS-REP response.
在这两种情况下，在收到PA-OTP-REQUEST时，KDC以与客户端相同的方式生成密钥，并使用生成的客户端密钥通过解密客户端发送的加密数据（nonce或timestamp）来验证预认证。如果验证成功，那么KDC将向客户机验证自己，并通过在AS-REP响应中使用生成的应答密钥确认应答密钥已更新。
Most OTP tokens involve the use of a Personal Identification Number (PIN) in the generation of the OTP value. This PIN value will be combined with the value generated by the token to produce the final OTP value that will be used in this protocol.
大多数OTP代币在生成OTP值时使用个人识别号（PIN）。该PIN值将与令牌生成的值相结合，以生成将在此协议中使用的最终OTP值。
If, following successful validation of a PA-OTP-REQUEST in an AS-REQ, the KDC determines that the user's PIN has expired and needs to change, then it SHOULD respond with a KRB-ERROR of type KDC_ERR_PIN_EXPIRED. It MAY include formatting information on the PIN in a PA-OTP-PIN-CHANGE (see Section 4.3) encrypted within the armored-data of the PA-FX-FAST-REPLY PA-DATA element.
如果在AS-REQ中成功验证PA-OTP-REQUEST后，KDC确定用户的PIN已过期且需要更改，则应以KDC_ERR_PIN_expired类型的KRB-ERROR进行响应。它可能包括PA-FX-FAST-REPLY PA-data元素的铠装数据中加密的PA-OTP-PIN-CHANGE（见第4.3节）中PIN的格式信息。
KDC_ERR_PIN_EXPIRED 96
KDC_ERR_PIN_已过期96
If the PIN change is to be handled by a PIN-change service, then it is assumed that authentication to that service will succeed if the PIN has expired.
如果PIN更改由PIN更改服务处理，则假定如果PIN已过期，则对该服务的身份验证将成功。
If the user's PIN has not expired but has been changed, then the KDC MAY return the new value to the client in a PA-OTP-PIN-CHANGE encrypted within the armored-data of the PA-FX-FAST-REPLY PA-DATA element of the AS-REP. Similarly, if a PIN change is not required, then the KDC MAY return a PA-OTP-PIN-CHANGE to inform the client of the current PIN's expiration time.
如果用户的PIN未过期但已被更改，则KDC可以在AS-REP的PA-FX-FAST-REPLY PA-data元素的铠装数据中加密PA-OTP-PIN-CHANGE将新值返回给客户端。同样，如果不需要更改PIN，然后KDC可以返回PA-OTP-PIN-CHANGE以通知客户当前PIN的过期时间。
It is possible with time- and event-based tokens that the OTP server will lose synchronization with the current token state. For example, event-based tokens may drift since the counter on the token is incremented every time the token is used, but the counter on the server is only incremented on an authentication. Similarly, the clocks on time-based tokens may drift.
使用基于时间和事件的令牌时，OTP服务器可能会丢失与当前令牌状态的同步。例如，基于事件的令牌可能会漂移，因为每次使用令牌时令牌上的计数器都会递增，但服务器上的计数器仅在身份验证时递增。类似地，基于时间的令牌上的时钟可能会漂移。
Methods to recover from this type of situation are OTP algorithm-specific but may involve the client sending a sequence of OTP values to allow the server to further validate the correct position in its search window (see Section 7.4 of [RFC4226] for an example).
从这种情况中恢复的方法是特定于OTP算法的，但可能涉及客户端发送一系列OTP值，以允许服务器进一步验证其搜索窗口中的正确位置（示例参见[RFC4226]第7.4节）。
If, when processing a PA-OTP-REQUEST, the pre-authentication validation fails for this reason, then the KDC MAY return a KRB-ERROR message. The KRB-ERROR message MAY contain a PA-OTP-CHALLENGE in the PA-DATA with a single otp-tokenInfo representing the token used in the initial authentication attempt but with the "nextOTP" flag set. If this flag is set, then the client SHOULD re-try the authentication using an OTP value generated using the token in the "state" after that used in the failed authentication attempt, for example, using the next time interval or counter value.
如果在处理PA-OTP请求时，预认证验证因此失败，那么KDC可能会返回KRB-ERROR消息。KRB-ERROR消息可能在PA-DATA中包含PA-OTP-CHALLENGE，其中单个OTP tokenInfo表示初始身份验证尝试中使用的令牌，但设置了“nextOTP”标志。如果设置了此标志，则客户端应使用OTP值重新尝试身份验证，OTP值是使用令牌在失败身份验证尝试中使用的OTP值之后的“状态”生成的，例如，使用下一个时间间隔或计数器值。
In the four-pass mode, the client begins by sending an initial AS-REQ, possibly containing other pre-authentication data. If the KDC determines that OTP-based pre-authentication is required and the request does not contain a PA-OTP-REQUEST, then it will respond as described in Section 3.2.
在四次通过模式下，客户端首先发送初始AS-REQ，可能包含其他预认证数据。如果KDC确定需要基于OTP的预认证，且请求不包含PA-OTP-request，则其将按照第3.2节所述进行响应。
If the client has all the necessary information, it MAY use the two-pass system by constructing a PA-OTP-REQUEST as described in Section 3.3 and including it in the initial request.
如果客户拥有所有必要的信息，则可通过按照第3.3节所述构造PA-OTP-REQUEST并将其包含在初始请求中来使用双通道系统。
If the user is required to authenticate using an OTP, then the KDC SHALL respond to the initial AS-REQ with a KRB-ERROR (as described in Section 2.2 of [RFC6113]), with a PA-OTP-CHALLENGE contained within the enc-fast-rep of the armored-data of a PA-FX-FAST-REPLY encrypted under the current Armor Key as described in [RFC6113].
如果要求用户使用OTP进行身份验证，则KDC应使用KRB错误（如[RFC6113]第2.2节所述）响应初始AS-REQ，并使用包含在enc fast代表中的PA-FX-fast-REPLY铠装数据的PA-OTP-CHALLENGE，PA-FX-fast-REPLY按照[RFC6113]中所述的当前铠装密钥进行加密。
If the OTP mechanism is to be carried out as an individual mechanism, then the PA-OTP-CHALLENGE SHALL be carried within the padata of the KrbFastResponse. Alternatively, if the OTP mechanism is required as part of an authentication set, then the PA-OTP-CHALLENGE SHALL be carried within a PA-AUTHENTICATION-SET-ELEM as described in Section 5.3 of [RFC6113].
如果OTP机制将作为单独机制执行，则PA-OTP-CHALLENGE应在KrbFastResponse的padata内执行。或者，如果OTP机制是认证集的一部分，则PA-OTP-CHALLENGE应在[RFC6113]第5.3节所述的PA-authentication-set-ELEM中进行。
The PA-OTP-CHALLENGE SHALL contain a nonce value to be returned encrypted in the client's PA-OTP-REQUEST. This nonce string MUST contain a randomly chosen component at least as long as the Armor Key length (see [RFC4086] for an in-depth discussion of randomness). In order to allow it to maintain any state necessary to verify the returned nonce, the KDC SHOULD use the mechanism described in Section 5.2 of [RFC6113].
PA-OTP-CHALLENGE应包含在客户的PA-OTP-REQUEST中加密返回的nonce值。此nonce字符串必须包含随机选择的组件，其长度至少与Armor密钥长度相同（有关随机性的深入讨论，请参见[RFC4086]）。为了使KDC能够保持验证返回的nonce所需的任何状态，KDC应使用[RFC6113]第5.2节中描述的机制。
The KDC MAY use the otp-service field to assist the client in locating the OTP token to be used by identifying the purpose of the authentication. For example, the otp-service field could assist a user in identifying the token to be used when a user has multiple OTP tokens that are used for different purposes. If the token is a connected device, then these values SHOULD be an exact octet-level match for the values present on the target token.
KDC可以使用otp服务字段来帮助客户端通过识别认证的目的来定位要使用的otp令牌。例如，当用户有多个用于不同目的的otp令牌时，otp服务字段可以帮助用户识别要使用的令牌。如果令牌是连接的设备，则这些值应与目标令牌上的值完全匹配。
The KDC SHALL include a sequence of one or more otp-tokenInfo elements containing information on the token or tokens that the user can use for the authentication and how the OTP value is to be generated using those tokens. If a single otp-tokenInfo element is included, then only a single token is acceptable by the KDC, and any OTP value generated by the client MUST be generated according to the information contained within that element. If more than one otp-tokenInfo element is included, then the OTP value MUST be generated according to the information contained within one of those elements.
KDC应包括一个或多个otp令牌信息元素的序列，其中包含用户可用于认证的一个或多个令牌的信息，以及如何使用这些令牌生成otp值。如果包含单个otp tokenInfo元素，那么KDC只接受单个令牌，并且必须根据该元素中包含的信息生成客户端生成的任何otp值。如果包含多个otp tokenInfo元素，则必须根据其中一个元素中包含的信息生成otp值。
The KDC MAY include the otp-vendor field in an otp-tokenInfo to identify the vendor of the token that can be used in the authentication request in order to assist the client in locating that token.
KDC可以在otp令牌信息中包括otp vendor字段，以识别可在认证请求中使用的令牌的供应商，以便帮助客户端定位该令牌。
If the KDC is able to obtain the OTP values for the token, then the OTP value SHOULD be used in the key generation as described in Section 3.6; therefore, the KDC SHOULD set the "must-encrypt-nonce" flag in the otp-tokenInfo. If the KDC is unable to obtain the OTP values for the token, then the "must-encrypt-nonce" flag MUST NOT be set. If the flag is not set, then the OTP value will be returned by the client in the otp-value field of the PA-OTP-REQUEST and so, if returning of OTP values in this way does not conform to KDC policy, then the KDC SHOULD NOT include the otp-tokenInfo for that token in the PA-OTP-CHALLENGE.
如果KDC能够获得令牌的OTP值，则OTP值应在密钥生成中使用，如第3.6节所述；因此，KDC应该在otp令牌信息中设置“必须加密nonce”标志。如果KDC无法获取令牌的OTP值，则不得设置“必须加密nonce”标志。如果未设置该标志，则客户端将在PA-OTP-REQUEST的OTP值字段中返回OTP值，因此，如果以这种方式返回OTP值不符合KDC策略，则KDC不应在PA-OTP-CHALLENGE中包含该令牌的OTP令牌信息。
If the KDC requires that hashed OTPs be used in the key generation as described in Section 3.6 (for example, it is only able to obtain hashed OTP values for the token), then it MUST include the supported hash algorithms in order of preference in the supportedHashAlg of the otp-KeyInfo and the minimum value of the iteration count in the iterationCount element.
如果KDC要求在密钥生成中使用散列OTP，如第3.6节所述（例如，它只能获得令牌的散列OTP值），然后，它必须按照优先顺序在otp KeyInfo的supportedHashAlg中包含受支持的哈希算法，并在iterationCount元素中包含迭代计数的最小值。
Since the OTP mechanism described in this document is replacing the Reply Key, the classic shared-key system cannot be relied upon to allow the client to verify the KDC. Therefore, as described in Section 3.4 of [RFC6113], some other mechanism must be provided to support this. If the OTP value is used in the Reply Key generation, then the client and KDC have a shared key and KDC-authentication is provided by the KDC using the Reply Key generated from the OTP value. However, if the OTP value is sent in the otp-value element of the PA-OTP-REQUEST, then there is no such shared key and the OTP mechanism does not provide KDC-authentication. Therefore, if the OTP mechanism is not being used in an environment where KDC-authentication is being provided by other means (e.g., by the use of a host-key-based Armor Key), then the KDC MUST NOT include any otp-tokenInfo elements in the PA-OTP-CHALLENGE that do not have the "must-encrypt-nonce" flag set.
由于本文档中描述的OTP机制正在替换应答密钥，因此不能依赖经典共享密钥系统来允许客户端验证KDC。因此，如[RFC6113]第3.4节所述，必须提供一些其他机制来支持这一点。如果在应答密钥生成中使用OTP值，则客户端和KDC具有共享密钥，KDC使用从OTP值生成的应答密钥提供KDC身份验证。但是，如果OTP值在PA-OTP-REQUEST的OTP值元素中发送，则不存在此类共享密钥，并且OTP机制不提供KDC身份验证。因此，如果OTP机制未在通过其他方式（例如，通过使用基于主机密钥的Armor密钥）提供KDC认证的环境中使用，则KDC不得在PA-OTP-CHALLENGE中包含任何未设置“必须加密nonce”标志的OTP令牌信息元素。
If the OTP for a token is to be generated using a server-generated challenge, then the value of the challenge SHALL be included in the otp-challenge field of the otp-tokenInfo for that token. If the token is a connected device and the OTP is to be generated by combining the challenge with the token's current state (e.g., time), then the "combine" flag SHALL be set within the otp-tokenInfo containing the challenge.
如果要使用服务器生成的质询生成令牌的OTP，则质询的值应包含在该令牌的OTP tokenInfo的OTP质询字段中。如果令牌是连接的设备，并且OTP将通过将质询与令牌的当前状态（例如，时间）相结合来生成，则应在包含质询的OTP令牌信息中设置“合并”标志。
If the KDC can determine which OTP token key (the seed value on the token used to generate the OTP) is to be used, then the otp-tokenID field MAY be included in the otp-tokenInfo to pass that value to the client.
如果KDC可以确定要使用哪个OTP令牌密钥（用于生成OTP的令牌上的种子值），则OTP令牌ID字段可以包括在OTP令牌信息中，以将该值传递给客户端。
The otp-algID field MAY be included in an otp-tokenInfo to identify the algorithm that should be used in the OTP calculation for that token. For example, it could be used when a user has been issued with multiple tokens that support different algorithms.
otp algID字段可包括在otp令牌信息中，以识别该令牌的otp计算中应使用的算法。例如，当向用户发出支持不同算法的多个令牌时，可以使用它。
If the KDC can determine that an OTP token that can be used by the user does not require the client to collect a PIN, then it SHOULD set the "do-not-collect-pin" flag in the otp-tokenInfo representing that token. If the KDC can determine that the token requires the client to collect a PIN, then it SHOULD set the "collect-pin" flag. If the KDC is unable to determine whether or not the client should collect a PIN, then the "collect-pin" and "do-not-collect-pin" flags MUST NOT be set.
如果KDC可以确定用户可以使用的OTP令牌不需要客户端收集PIN，那么它应该在表示该令牌的OTP令牌信息中设置“不收集PIN”标志。如果KDC可以确定令牌需要客户端收集PIN，那么它应该设置“收集PIN”标志。如果KDC无法确定客户端是否应收集PIN，则不得设置“收集PIN”和“不收集PIN”标志。
If the KDC requires the PIN of an OTP token to be returned to it separately, then it SHOULD set the "separate-pin-required" flag in the otp-KeyInfo representing that token.
如果KDC要求将OTP令牌的PIN单独返回给它，那么它应该在表示该令牌的OTP KeyInfo中设置“需要单独的PIN”标志。
If the KDC requires that the OTPs generated by the token have a Luhn check digit appended, as defined in [ISOIEC7812], then it MUST set the "check-digit" flag. This flag only applies if the format of the OTP is decimal; therefore, the otp-format field, if present, MUST have the value of "decimal".
如果KDC要求令牌生成的OTP附加Luhn校验位，如[ISOIEC7812]中所定义，则必须设置“校验位”标志。仅当OTP的格式为十进制时，此标志才适用；因此，otp格式字段（如果存在）的值必须为“十进制”。
Finally, in order to support connected tokens that can generate OTP values of varying lengths or formats, the KDC MAY include the desired otp-length and format of the OTP in the otp-length and otp-format fields of an otp-tokenInfo.
最后，为了支持能够生成不同长度或格式的OTP值的连接令牌，KDC可以在OTP令牌信息的OTP长度和OTP格式字段中包括期望的OTP长度和OTP格式。
The client response SHALL be sent to the KDC as a PA-OTP-REQUEST included within the enc-fast-req of the armored-data within a PA-FX-FAST-REQUEST encrypted under the current Armor Key as described in [RFC6113].
客户响应应作为PA-OTP请求发送给KDC，该请求包含在按照[RFC6113]中所述的当前铠装密钥加密的PA-FX-fast请求中的铠装数据的enc fast req中。
In order to generate its response, the client MUST generate an OTP value. If the PA-OTP-CHALLENGE contained one or more otp-tokenInfo elements, then the OTP value MUST be based on the information contained within one of those elements.
为了生成响应，客户端必须生成OTP值。如果PA-OTP-CHALLENGE包含一个或多个OTP tokenInfo元素，则OTP值必须基于其中一个元素中包含的信息。
The otp-service, otp-vendor, otp-tokenID, otp-length, otp-format, and otp-algID elements of the PA-OTP-CHALLENGE are provided by the KDC to assist the client in locating the correct token to use, but the use of the above fields will depend on the type of token.
KDC提供PA-otp-CHALLENGE的otp服务、otp供应商、otp令牌ID、otp长度、otp格式和otp algID元素，以帮助客户定位要使用的正确令牌，但上述字段的使用将取决于令牌的类型。
If the token is a disconnected device, then the values of otp-service and otp-vendor MAY be displayed to the user in order to help the user select the correct token, and the values of otp-algID, otp-tokenID, otp-length, and otp-format MAY be ignored.
如果令牌是断开连接的设备，则可以向用户显示otp服务和otp供应商的值，以帮助用户选择正确的令牌，并且可以忽略otp algID、otp令牌ID、otp长度和otp格式的值。
If the token is a connected device, then these values, if present, SHOULD be used by the client to locate the correct token. When the token is connected, clients MUST support matching based on a binary comparison of the otp-vendor and otp-service strings when comparing the values against those present on the token. Clients MAY have other comparisons including normalization insensitive comparisons to try and find the right token. The values of otp-vendor and otp-service MAY be displayed to prompt the user if the correct token is not found.
如果令牌是连接的设备，则客户端应使用这些值（如果存在）来定位正确的令牌。连接令牌时，客户端在将值与令牌上的值进行比较时，必须支持基于otp供应商和otp服务字符串的二进制比较的匹配。客户端可能会进行其他比较，包括不区分标准化的比较，以尝试找到正确的令牌。如果找不到正确的令牌，可能会显示otp供应商和otp服务的值以提示用户。
If the "nextOTP" flag is set in the otp-tokenInfo from the PA-OTP-CHALLENGE, then the OTP value MUST be generated from the next token state rather than that used in the previous PA-OTP-REQUEST for that token. The "nextOTP" flag MUST also be set in the new PA-OTP-REQUEST.
如果PA-otp-CHALLENGE的otp令牌信息中设置了“nextOTP”标志，则必须从下一个令牌状态生成otp值，而不是在该令牌的前一个PA-otp-REQUEST中使用的值。还必须在新的PA-OTP-REQUEST中设置“nextOTP”标志。
If the "collect-pin" flag is set, then the token requires a PIN to be collected by the client. If the "do-not-collect-pin" flag is set in the otp-tokenInfo from the PA-OTP-CHALLENGE, then the token represented by the otp-tokenInfo does not require a PIN to be collected by the client as part of the OTP value. If neither of the "collect-pin" nor "do-not-collect-pin" flags are set, then PIN requirements of the token are unspecified. If both flags are set, then the client SHALL regard the request as invalid.
如果设置了“收集pin”标志，则令牌要求客户端收集pin。如果PA-otp-CHALLENGE的otp令牌信息中设置了“不收集pin”标志，则otp令牌信息表示的令牌不需要客户端收集pin作为otp值的一部分。如果未设置“收集pin”或“不收集pin”标志，则未指定令牌的pin要求。如果设置了两个标志，则客户端应将请求视为无效。
If the "separate-pin-required" flag is set, then any PIN collected by the client MUST be included as a UTF-8 string in the otp-pin of the PA-OTP-REQUEST.
如果设置了“需要单独的pin”标志，则客户端收集的任何pin必须作为UTF-8字符串包含在PA-otp-REQUEST的otp pin中。
If the token is a connected device, then how the PIN is used to generate the OTP value will depend on the type of device. However, if the token is a disconnected device, then it will depend on the "separate-pin-required" flag. If the flag is not set, then the OTP value MUST be generated by appending the PIN with the value from the token entered by the user and, if the flag is set, then the OTP value MUST be the value from the token.
如果令牌是连接的设备，那么如何使用PIN生成OTP值将取决于设备的类型。但是，如果令牌是断开连接的设备，则它将取决于“需要单独的pin”标志。如果未设置该标志，则必须通过将PIN与用户输入的令牌中的值附加在一起来生成OTP值，如果设置了该标志，则OTP值必须是令牌中的值。
The clients SHOULD NOT normalize the PIN value or any OTP value collected from the user or returned by a connected token in any way.
客户端不应规范化从用户收集的PIN值或任何OTP值，或以任何方式由连接的令牌返回的值。
If the "check-digit" flag is set, then any OTP values SHOULD be decimal and have a Luhn check digit appended [ISOIEC7812]. If the token is disconnected, then the Client MAY ignore this flag; if the token is connected, then the Client MUST enforce it. The Client MUST regard the request as invalid, if otp-format is present and set to any value other than "decimal".
如果设置了“校验位”标志，则任何OTP值都应为十进制，并附加一个Luhn校验位[ISOIEC7812]。如果令牌断开连接，则客户端可以忽略此标志；如果令牌已连接，则客户端必须强制执行该令牌。如果存在otp格式并将其设置为除“十进制”以外的任何值，则客户端必须将请求视为无效。
If an otp-challenge is present in the otp-tokenInfo selected by the client from the PA-OTP-CHALLENGE, then the OTP value for the token MUST be generated based on a challenge, if the token is capable of accepting a challenge. The client MAY ignore the provided challenge if and only if the token is not capable of including a challenge in the OTP calculation.
如果客户端从PA-otp-CHARGE中选择的otp令牌信息中存在otp质询，则必须根据质询生成令牌的otp值（如果令牌能够接受质询）。当且仅当令牌不能在OTP计算中包括质询时，客户端可以忽略所提供的质询。
If the "combine" flag is not set in the otp-tokenInfo of the PA-OTP-CHALLENGE, then the OTP SHALL be calculated based only the challenge and not the internal state (e.g., time or counter) of the token. If the "combine" flag is set, then the OTP SHALL be calculated using both the internal state and the provided challenge, if that value is obtainable by the client. If the flag is set but otp-challenge is not present, then the client SHALL regard the request as invalid.
如果PA-otp-CHARGE的otp令牌信息中未设置“联合”标志，则otp应仅基于该质询而非令牌的内部状态（例如，时间或计数器）进行计算。如果设置了“合并”标志，则应使用内部状态和提供的质询计算OTP（如果客户可以获得该值）。如果设置了标志，但otp质询不存在，则客户端应将请求视为无效。
If token is a connected device, then the use of the challenge will depend on the type of device but will involve passing the challenge and the value of the "combine" flag in a token-specific manner to the token, along with a PIN if collected and the values of otp-length and otp-format if specified, in order to obtain the OTP value. If the token is disconnected, then the challenge MUST be displayed to the user and the value of the "combine" flag MAY be ignored by the client.
如果令牌是连接的设备，则质询的使用将取决于设备的类型，但将涉及以令牌特定的方式将质询和“组合”标志的值以及PIN（如果收集）和otp长度和otp格式（如果指定）的值一起传递给令牌，以获得otp值。如果令牌断开连接，则必须向用户显示质询，并且客户端可能会忽略“combine”标志的值。
If the OTP value was generated using a challenge that was not sent by the KDC, then the challenge SHALL be included in the otp-challenge of the PA-OTP-REQUEST. If the OTP was generated by combining a challenge (either received from the KDC or generated by the client) with the token state, then the "combine" flag SHALL be set in the PA-OTP-REQUEST.
如果OTP值是使用KDC未发送的质询生成的，则质询应包括在PA-OTP-REQUEST的OTP质询中。如果OTP是通过将质询（从KDC接收或由客户端生成）与令牌状态相结合而生成的，则应在PA-OTP-REQUEST中设置“合并”标志。
If the "must-encrypt-nonce" flag is set in the otp-tokenInfo, then the OTP value MUST be used to generate the Client Key and Reply Key as described in Section 3.6 and MUST NOT be included in the otp-value field of the PA-OTP-REQUEST. If the flag is not set, then the OTP value MUST be included in the otp-value field of the PA-OTP-REQUEST and MUST NOT be used in the key derivation. In this case, the Client Key and Reply Key SHALL be the same as the Armor Key as described in Section 3.6; so, if the returning of OTP values in this way does not conform to local policy on the client (for example, if KDC-Authentication is required and is not being provided by other means), then it SHOULD NOT use the token for authentication.
如果otp令牌信息中设置了“必须加密nonce”标志，则otp值必须用于生成第3.6节所述的客户端密钥和应答密钥，并且不得包含在PA-otp-REQUEST的otp值字段中。如果未设置该标志，则OTP值必须包含在PA-OTP-REQUEST的OTP值字段中，并且不得用于密钥派生。在这种情况下，客户机密钥和应答密钥应与第3.6节所述的铠装密钥相同；因此，如果以这种方式返回OTP值不符合客户机上的本地策略（例如，如果需要KDC身份验证且未通过其他方式提供），则不应使用令牌进行身份验证。
If the supportedHashAlg and iterationCount elements are included in the otp-tokenInfo, then the client MUST use hashed OTP values in the generation of the Reply Key and Client Key as described in Section 3.6. The client MUST select the first algorithm from the list that it supports and the AlgorithmIdentifer [RFC5280] selected MUST be placed in the hashAlg element of the PA-OTP-REQUEST. However, if none of the algorithm identifiers conform to local policy restrictions, then the authentication attempt MUST NOT proceed using that token. If the value of iterationCount does not conform to local policy on the client, then the client MAY use a larger value, but MUST NOT use a lower value. The value of the iteration count used by the client MUST be returned in the PA-OTP-REQUEST sent to the KDC.
如果otp令牌信息中包含supportedHashAlg和iterationCount元素，则客户端必须在生成回复密钥和客户端密钥时使用哈希otp值，如第3.6节所述。客户端必须从其支持的列表中选择第一个算法，并且选择的算法标识符[RFC5280]必须放在PA-OTP-REQUEST的hashAlg元素中。但是，如果没有任何算法标识符符合本地策略限制，则身份验证尝试不得使用该令牌继续进行。如果iterationCount的值不符合客户端上的本地策略，则客户端可以使用较大的值，但不能使用较小的值。客户端使用的迭代计数值必须在发送给KDC的PA-OTP-REQUEST中返回。
If hashed OTP values are used, then the nonce generated by the client MUST be as long as the longest key length of the symmetric key types that it supports and MUST be chosen randomly (see [RFC4086]). The nonce MUST be included in the PA-OTP-REQUEST, along with the hash algorithm and iteration count used in the nonce, hashAlg, and iterationCount fields of the PA-OTP-REQUEST. These fields MUST NOT be included if hashed OTP values were not used. It is RECOMMENDED that the iteration count used by the client be chosen in such a way that it is computationally infeasible/unattractive for an attacker to brute-force search for the given OTP.
如果使用散列OTP值，则客户端生成的nonce必须与它支持的对称密钥类型的最长密钥长度相同，并且必须随机选择（请参见[RFC4086]）。nonce必须包括在PA-OTP-REQUEST中，以及在PA-OTP-REQUEST的nonce、hashAlg和iterationCount字段中使用的哈希算法和迭代计数。如果未使用哈希OTP值，则不得包含这些字段。建议选择客户端使用的迭代计数，使攻击者对给定OTP进行暴力搜索在计算上不可行/不具吸引力。
The PA-OTP-REQUEST returned by the client SHOULD include information on the generated OTP value reported by the OTP token when available to the client. The otp-time and otp-counter fields of the PA-OTP-REQUEST SHOULD be used to return the time and counter values used by the token if available to the client. The otp-format field MAY be used to report the format of the generated OTP. This field SHOULD be used if a token can generate OTP values in multiple formats. The otp-algID field SHOULD be used by the client to report the algorithm used in the OTP calculation, and the otp-tokenID SHOULD be used to report the identifier of the OTP token key used if the information is known to the client.
客户端返回的PA-OTP-REQUEST应包括OTP令牌报告的生成OTP值的信息（当客户端可用时）。PA-otp-REQUEST的otp时间和otp计数器字段应用于返回令牌使用的时间和计数器值（如果客户端可用）。otp格式字段可用于报告生成的otp的格式。如果令牌可以生成多种格式的OTP值，则应使用此字段。客户机应使用otp algID字段报告otp计算中使用的算法，如果客户机知道信息，则应使用otp令牌ID报告所用otp令牌密钥的标识符。
If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE that contained an otp-vendor field in the selected otp-tokenInfo, then the otp-vendor field of the PA-OTP-REQUEST MUST be set to the same value. If no otp-vendor field was provided by the KDC, then the field SHOULD be set to the vendor identifier of the token if known to the client.
如果发送PA-OTP-REQUEST是为了响应PA-OTP-CHALLENGE，该PA-OTP-CHALLENGE在所选OTP令牌信息中包含OTP供应商字段，则PA-OTP-REQUEST的OTP供应商字段必须设置为相同的值。如果KDC未提供otp供应商字段，则该字段应设置为令牌的供应商标识符（如果客户已知）。
The generated Client Key is used by the client to encrypt data to be included in the encData of the PA-OTP-REQUEST to allow the KDC to authenticate the user. The key usage for this encryption is KEY_USAGE_OTP_REQUEST.
客户端使用生成的客户端密钥加密要包含在PA-OTP-REQUEST的encData中的数据，以允许KDC对用户进行身份验证。此加密的密钥用法是密钥用法OTP请求。
o If the PA-OTP-REQUEST is being generated in response to a PA-OTP-CHALLENGE returned by the KDC, then the client SHALL encrypt a PA-OTP-ENC-REQUEST containing the value of nonce from the PA-OTP-CHALLENGE using the same encryption type as the Armor Key.
o 如果PA-OTP-REQUEST是为了响应KDC返回的PA-OTP-CHALLENGE而生成的，则客户端应使用与Armor密钥相同的加密类型加密包含PA-OTP-CHALLENGE的nonce值的PA-OTP-ENC-REQUEST。
o If the PA-OTP-REQUEST is not in response to a PA-OTP-CHALLENGE, then the client SHALL encrypt a PA-ENC-TS-ENC containing the current time as in the encrypted timestamp pre-authentication mechanism [RFC4120].
o 如果PA-OTP-REQUEST未响应PA-OTP-CHALLENGE，则客户端应加密PA-ENC-TS-ENC，其中包含加密时间戳预认证机制中的当前时间[RFC4120]。
If the client is working in two-pass mode and so, is not responding to an initial KDC challenge, then the values of the iteration count and hash algorithms cannot be obtained from that challenge. The client SHOULD use any values obtained from a previous PA-OTP-CHALLENGE or, if no values are available, it MAY use initial configured values.
如果客户机在双过程模式下工作，因此没有响应初始KDC质询，则无法从该质询中获得迭代计数和哈希算法的值。客户应使用从先前PA-OTP-CHALLENGE获得的任何值，或者，如果没有可用值，则可以使用初始配置值。
The KDC validates the pre-authentication data by generating the Client Key and Reply Key in the same way as the client and using the generated Client Key to decrypt the value of encData from the PA-OTP-REQUEST. The generated Reply Key is used to encrypt data in the AS-REP.
KDC以与客户端相同的方式生成客户端密钥和应答密钥，并使用生成的客户端密钥解密PA-OTP-REQUEST中的encData值，从而验证预认证数据。生成的应答密钥用于加密AS-REP中的数据。
If the otp-value field is included in the PA-OTP-REQUEST, then the KDC MUST use that value unless the OTP method is required to support KDC-authentication (see Section 3.2). If the otp-value is not included in the PA-OTP-REQUEST, then the KDC will need to generate or obtain the OTP value.
如果PA-otp-REQUEST中包含otp值字段，则KDC必须使用该值，除非需要otp方法来支持KDC身份验证（见第3.2节）。如果PA-otp-REQUEST中未包含otp值，则KDC将需要生成或获取otp值。
If the otp-pin field is present in the PA-OTP-REQUEST, then the PIN value has to be value provided by the client. The KDC SHOULD SASLPrep (Stringprep Profile for User Names and Passwords) [RFC4013] the value in lookup mode before comparison.
如果PA-otp-REQUEST中存在otp pin字段，则pin值必须是客户端提供的值。在比较之前，KDC应该在查找模式下使用SASLPrep（用户名和密码的Stringprep配置文件）[RFC4013]值。
It should be noted that it is anticipated that, as improved string comparison technologies are standardized, the processing done by the KDC will change, but efforts will be made to maintain as much compatibility with SASLprep as possible.
应该注意的是，随着改进的字符串比较技术的标准化，KDC完成的处理将发生变化，但将尽可能努力保持与SASLprep的兼容性。
If the otp-challenge field is present, then the OTP was calculated using that challenge. If the "combine" flag is also set, then the OTP was calculated using the challenge and the token's current state.
如果存在otp质询字段，则使用该质询计算otp。如果还设置了“combine”标志，则使用质询和令牌的当前状态计算OTP。
It is RECOMMENDED that the KDC act upon the values of otp-time, otp-counter, otp-format, otp-algID, and otp-tokenID if they are present in the PA-OTP-REQUEST. If the KDC receives a request containing these values, but cannot act upon them, then they MAY be ignored.
建议KDC根据otp时间、otp计数器、otp格式、otp algID和otp令牌ID（如果它们存在于PA-otp-REQUEST中）的值进行操作。如果KDC接收到包含这些值的请求，但无法对其采取行动，则可能会忽略这些值。
The KDC generates the Client Key and Reply Key as described in Section 3.6 from the OTP value using the nonce, hash algorithm, and iteration count if present in the PA-OTP-REQUEST. The KDC MUST fail the request with KDC_ERR_INVALID_HASH_ALG, if the KDC requires hashed OTP values and the hashAlg field was not present in the PA-OTP-REQUEST or if the value of this field does not conform to local KDC policy. Similarly, the KDC MUST fail the request with KDC_ERR_INVALID_ITERATION_COUNT, if the value of the iterationCount included in the PA-OTP-REQUEST does not conform to local KDC policy or is less than that specified in the PA-OTP-CHALLENGE. In addition, the KDC MUST fail the authentication request with KDC_ERR_PIN_REQUIRED, if it requires a separate PIN to the OTP value and an otp-pin was not included in the PA-OTP-REQUEST. The above error codes are defined as follows:
KDC使用nonce、哈希算法和迭代计数（如果PA-OTP-REQUEST中存在）从OTP值生成第3.6节所述的客户机密钥和应答密钥。如果KDC需要哈希OTP值，并且PA-OTP-request中不存在哈希字段，或者如果此字段的值不符合本地KDC策略，则KDC必须使用KDC_ERR_INVALID_HASH_ALG使请求失败。类似地，如果PA-OTP-request中包含的iterationCount值不符合本地KDC策略或小于PA-OTP-CHALLENGE中指定的值，KDC必须使用KDC_ERR_INVALID_ITERATION_COUNT使请求失败。此外，如果KDC需要OTP值的单独PIN，并且PA-OTP-request中未包含OTP PIN，则KDC必须在需要KDC_ERR_PIN_的情况下使身份验证请求失败。上述错误代码定义如下：
KDC_ERR_INVALID_HASH_ALG 94 KDC_ERR_INVALID_ITERATION_COUNT 95 KDC_ERR_PIN_REQUIRED 97
KDC_ERR_INVALID_HASH_ALG 94 KDC_ERR_INVALID_迭代_COUNT 95需要KDC_ERR_PIN_97
The generated Client Key is then used to decrypt the encData from the PA-OTP-REQUEST. If the client response was sent as a result of a PA-OTP-CHALLENGE, then the decrypted data will be a PA-OTP-ENC-REQUEST and the client authentication MUST fail with KDC_ERR_PREAUTH_FAILED if the nonce value from the PA-OTP-ENC-REQUEST is not the same as the nonce value sent in the PA-OTP-CHALLENGE. If the response was not sent as a result of a PA-OTP-CHALLENGE, then the decrypted value will be a PA-ENC-TS-ENC, and the authentication process will be the same as with classic encrypted timestamp pre-authentication [RFC4120].
生成的客户端密钥随后用于解密PA-OTP-REQUEST中的加密数据。如果客户端响应是作为PA-OTP-CHALLENGE的结果发送的，则解密的数据将是PA-OTP-ENC-REQUEST，并且如果PA-OTP-ENC-REQUEST中的nonce值与PA-OTP-CHALLENGE中发送的nonce值不同，则客户端身份验证必须失败，KDC_ERR_PREAUTH_失败。如果响应不是由于PA-OTP-质询而发送的，则解密的值将是PA-ENC-TS-ENC，且认证过程将与经典加密时间戳预认证相同[RFC4120]。
The KDC MUST fail the request with KDC_ERR_ETYPE_NOSUPP, if the encryption type used by the client in the encData does not conform to KDC policy.
如果客户端在encData中使用的加密类型不符合KDC策略，KDC必须使用KDC_ERR_ETYPE_NOSUPP使请求失败。
If authentication fails due to the hash algorithm, iteration count, or encryption type used by the client, then the KDC SHOULD return a PA-OTP-CHALLENGE with the required values in the error response. If the authentication fails due to the token state on the server is no longer being synchronized with the token used, then the KDC MAY return a PA-OTP-CHALLENGE with the "nextOTP" flag set as described in Section 2.4.
如果由于客户端使用的哈希算法、迭代计数或加密类型而导致身份验证失败，那么KDC应该在错误响应中返回一个PA-OTP-CHALLENGE，其中包含所需的值。如果由于服务器上的令牌状态不再与所使用的令牌同步而导致身份验证失败，则KDC可能会返回PA-OTP-CHALLENGE，并按照第2.4节所述设置“nextOTP”标志。
If, during the authentication process, the KDC determines that the user's PIN has been changed, then it SHOULD include a PA-OTP-PIN-CHANGE in the response, as described in Section 2.3, containing the new PIN value. The KDC MAY also include the new PIN's expiration time and the expiration time of the OTP account within the last-req field of the PA-OTP-PIN-CHANGE. (These fields can be used by the KDC to handle cases where the account related to the user's OTP token has a different expiration time to the user's Kerberos account.) If the KDC determines that the user's PIN or OTP account are about to expire, it MAY return a PA-OTP-PIN-CHANGE with that information. Finally, if the KDC determines that the user's PIN has expired, then it SHOULD return a KRB-ERROR of type KDC_ERR_PIN_EXPIRED as described in Section 2.3
如果在认证过程中，KDC确定用户的PIN已更改，则应在响应中包括PA-OTP-PIN更改，如第2.3节所述，包含新的PIN值。KDC还可以在PA-OTP-PIN-CHANGE的最后一个req字段中包括新PIN的到期时间和OTP帐户的到期时间。（KDC可以使用这些字段来处理与用户的OTP令牌相关的帐户与用户的Kerberos帐户的过期时间不同的情况。）如果KDC确定用户的PIN或OTP帐户即将过期，它可能会返回带有该信息的PA-OTP-PIN-CHANGE。最后，如果KDC确定用户的PIN已过期，则应返回KDC_ERR_PIN_expired类型的KRB-ERROR，如第2.3节所述
If the pre-authentication data was successfully verified, then, in order to support mutual authentication, the KDC SHALL respond to the client's PA-OTP-REQUEST by using the generated Reply Key to encrypt the data in the AS-REP. The client then uses its generated Reply Key to decrypt the encrypted data and MUST NOT continue with the authentication process, if decryption is not successful.
如果成功验证了预认证数据，则为了支持相互认证，KDC应使用生成的回复密钥对AS-REP中的数据进行加密，以响应客户的PA-OTP请求。然后，客户使用其生成的回复密钥对加密数据进行解密，如果解密不成功，则不得继续验证过程。
In order to authenticate the user, the client and KDC need to generate two encryption keys:
为了对用户进行身份验证，客户端和KDC需要生成两个加密密钥：
o The Client Key to be used by the client to encrypt and by the KDC to decrypt the encData in the PA-OTP-REQUEST.
o 客户端用于加密和KDC用于解密PA-OTP-REQUEST中的加密数据的客户端密钥。
o The Reply Key to be used in the standard manner by the KDC to encrypt data in the AS-REP.
o KDC以标准方式用于加密AS-REP中数据的应答密钥。
The method used to generate the two keys will depend on the OTP algorithm.
用于生成两个密钥的方法将取决于OTP算法。
o If the OTP value is included in the otp-value of the PA-OTP-REQUEST, then the two keys SHALL be the same as the Armor Key (defined in [RFC6113]).
o 如果OTP值包含在PA-OTP-REQUEST的OTP值中，则两个键应与铠装键相同（定义见[RFC6113]）。
o If the OTP value is not included in the otp-value of the PA-OTP-REQUEST, then the two keys SHALL be derived from the Armor Key and the OTP value as described below.
o 如果OTP值未包含在PA-OTP-REQUEST的OTP值中，则两个键应根据装甲键和OTP值推导，如下所述。
If the OTP value is not included in the PA-OTP-REQUEST, then the Reply Key and Client Key SHALL be generated using the KRB-FX-CF2 algorithm from [RFC6113] as follows:
如果PA-OTP-REQUEST中未包含OTP值，则应使用[RFC6113]中的KRB-FX-CF2算法生成回复密钥和客户端密钥，如下所示：
Client Key = KRB-FX-CF2(K1, K2, O1, O2)
Reply Key = KRB-FX-CF2(K1, K2, O3, O4)
Client Key = KRB-FX-CF2(K1, K2, O1, O2)
Reply Key = KRB-FX-CF2(K1, K2, O3, O4)
The octet string parameters, O1, O2, O3, and O4 shall be the ASCII string "OTPComb1", "OTPComb2", "OTPComb3", and "OTPComb4" as shown below:
八位字节字符串参数O1、O2、O3和O4应为ASCII字符串“OTPComb1”、“OTPComb2”、“OTPComb3”和“OTPComb4”，如下所示：
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x31}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x32}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x33}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x34}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x31}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x32}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x33}
{0x4f, 0x54, 0x50, 0x43, 0x6f, 0x6d, 0x62, 0x34}
The first input key, K1, SHALL be the Armor Key and so, as described in Section 5.1 of [RFC6113], the enctypes of the generated Client Key and Reply Key will be the same as the enctype of Armor Key. The second input key, K2, shall be derived from the OTP value using string-to-key (defined in [RFC3961]) as described below.
第一个输入密钥K1应为Armor密钥，因此，如[RFC6113]第5.1节所述，生成的客户端密钥和回复密钥的enctype与Armor密钥的enctype相同。第二个输入键K2应使用字符串到键（在[RFC3961]中定义）从OTP值导出，如下所述。
If the hash of the OTP value is to be used, then K2 SHALL be derived as follows:
如果要使用OTP值的散列，则K2应按如下公式推导：
o An initial hash value, H, is generated:
o 生成初始散列值H：
H = hash(realm|nonce|OTP)
H=散列（领域|当前| OTP）
Where:
哪里：
* "|" denotes concatenation. * hash is the hash algorithm selected by the client. * realm is the name of the server's realm as carried in the realm field of the AS-REQ (not including the tag and length from the DER encoding). * nonce is the value of the random nonce value generated by the client and carried in the nonce field of the PA-OTP-REQUEST (not including the tag and length from the DER encoding). * If the OTP format is decimal, hexadecimal, or alphanumeric, then OTP is the value of the OTP generated as described in Section 3.3 with SASLprep [RFC4013] applied in lookup mode; otherwise, it is the unnormalized OTP value.
* “|”表示串联。*哈希是客户端选择的哈希算法。*realm是as-REQ领域字段中携带的服务器领域名称（不包括DER编码中的标记和长度）。*nonce是客户端生成的随机nonce值的值，并携带在PA-OTP-REQUEST的nonce字段中（不包括来自DER编码的标记和长度）。*如果OTP格式为十进制、十六进制或字母数字，则OTP是按照第3.3节所述生成的OTP值，SASLprep[RFC4013]应用于查找模式；否则，它是非标准化的OTP值。
o The initial hash value is then hashed iterationCount-1 times to produce a final hash value, H' (where iterationCount is the value from the PA-OTP-REQUEST).
o 然后对初始散列值进行散列iterationCount-1次，以生成最终散列值H'（其中iterationCount是来自PA-OTP-REQUEST的值）。
H' = hash(hash(...(iterationCount-1 times)...(H)))
H' = hash(hash(...(iterationCount-1 times)...(H)))
o The value of K2 is then derived from the Base64 [RFC2045] encoding of this final hash value.
o K2的值随后从该最终散列值的Base64[rfc245]编码中导出。
K2 = string-to-key(Base64(H')|"Krb-preAuth")
K2 = string-to-key(Base64(H')|"Krb-preAuth")
If the hash value is not used, then K2 SHALL be derived from the base64 encoding of the OTP value.
如果未使用哈希值，则应根据OTP值的base64编码推导K2。
K2 = string-to-key(Base64(OTP)|"Krb-preAuth")
K2 = string-to-key(Base64(OTP)|"Krb-preAuth")
The enctype used for string-to-key SHALL be that of the Armor Key and the salt and any additional parameters for string-to-key MAY be provided by the KDC in the PA-OTP-CHALLENGE. If the salt and string-to-key parameters are not provided, then the default values defined for the particular enctype SHALL be used.
用于串到键的enctype应为铠装键和salt的enctype，串到键的任何附加参数可由KDC在PA-OTP-CHARGE中提供。如果未提供salt和字符串到键参数，则应使用为特定类型定义的默认值。
If the strengthen-key is present in KrbFastResponse, then it is combined with the Reply Key to generate the final AS-REQ as described in [RFC6113]. The strengthen-key does not influence the Client Key.
如果强化密钥存在于KrbFastResponse中，则它将与应答密钥组合以生成最终AS-REQ，如[RFC6113]中所述。强化密钥不影响客户端密钥。
The padata-type PA-OTP-CHALLENGE is returned by the KDC to the client in the enc-fast-rep of a PA-FX-FAST-REPLY in the PA-DATA of a KRB-ERROR when OTP pre-authentication is required. The corresponding padata-value field contains the Distinguished Encoding Rules (DER) [X.680] and [X.690] encoding of a PA-OTP-CHALLENGE containing a server-generated nonce and information for the client on how to generate the OTP.
当需要OTP预认证时，KDC将padata类型PA-OTP-CHALLENGE通过KRB-ERROR的PA-DATA中PA-FX-fast-rep的enc fast rep返回给客户端。对应的padata值字段包含PA-OTP-CHALLENGE的可分辨编码规则（DER）[X.680]和[X.690]编码，其中包含服务器生成的nonce以及客户端如何生成OTP的信息。
PA-OTP-CHALLENGE 141
PA-OTP-141
PA-OTP-CHALLENGE ::= SEQUENCE {
nonce [0] OCTET STRING,
otp-service [1] UTF8String OPTIONAL,
otp-tokenInfo [2] SEQUENCE (SIZE(1..MAX)) OF
OTP-TOKENINFO,
salt [3] KerberosString OPTIONAL,
s2kparams [4] OCTET STRING OPTIONAL,
...
PA-OTP-CHALLENGE ::= SEQUENCE {
nonce [0] OCTET STRING,
otp-service [1] UTF8String OPTIONAL,
otp-tokenInfo [2] SEQUENCE (SIZE(1..MAX)) OF
OTP-TOKENINFO,
salt [3] KerberosString OPTIONAL,
s2kparams [4] OCTET STRING OPTIONAL,
...
}
}
OTP-TOKENINFO ::= SEQUENCE {
flags [0] OTPFlags,
otp-vendor [1] UTF8String OPTIONAL,
otp-challenge [2] OCTET STRING (SIZE(1..MAX))
OPTIONAL,
otp-length [3] Int32 OPTIONAL,
otp-format [4] OTPFormat OPTIONAL,
otp-tokenID [5] OCTET STRING OPTIONAL,
otp-algID [6] AnyURI OPTIONAL,
supportedHashAlg [7] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
iterationCount [8] Int32 OPTIONAL,
...
}
OTP-TOKENINFO ::= SEQUENCE {
flags [0] OTPFlags,
otp-vendor [1] UTF8String OPTIONAL,
otp-challenge [2] OCTET STRING (SIZE(1..MAX))
OPTIONAL,
otp-length [3] Int32 OPTIONAL,
otp-format [4] OTPFormat OPTIONAL,
otp-tokenID [5] OCTET STRING OPTIONAL,
otp-algID [6] AnyURI OPTIONAL,
supportedHashAlg [7] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
iterationCount [8] Int32 OPTIONAL,
...
}
OTPFormat ::= INTEGER {
decimal(0),
hexadecimal(1),
alphanumeric(2),
binary(3),
base64(4)
}
OTPFormat ::= INTEGER {
decimal(0),
hexadecimal(1),
alphanumeric(2),
binary(3),
base64(4)
}
OTPFlags ::= KerberosFlags
-- reserved(0),
-- nextOTP(1),
-- combine(2),
-- collect-pin(3),
-- do-not-collect-pin(4),
-- must-encrypt-nonce (5),
-- separate-pin-required (6),
-- check-digit (7)
OTPFlags ::= KerberosFlags
-- reserved(0),
-- nextOTP(1),
-- combine(2),
-- collect-pin(3),
-- do-not-collect-pin(4),
-- must-encrypt-nonce (5),
-- separate-pin-required (6),
-- check-digit (7)
nonce A KDC-supplied nonce value to be encrypted by the client in the PA-OTP-REQUEST. This nonce string MUST contain a randomly chosen component at least as long as the Armor Key length.
nonce KDC提供的nonce值，由客户端在PA-OTP-REQUEST中加密。此nonce字符串必须包含随机选择的组件，其长度至少与密钥长度相同。
otp-service Use of this field is OPTIONAL, but MAY be used by the KDC to assist the client to locate the appropriate OTP tokens to be used. For example, this field could be used when a user has multiple OTP tokens for different purposes.
此字段的otp服务使用是可选的，但KDC可能会使用此字段来帮助客户端定位要使用的适当otp令牌。例如，当用户有多个OTP令牌用于不同目的时，可以使用此字段。
otp-tokenInfo This element MUST be included, and it is a sequence of one or more OTP-TOKENINFO objects containing information on the token or tokens that the user can use for the authentication and how the OTP value is to be generated using those tokens. If a single OTP-TOKENINFO object is included, then only a single token is acceptable by the KDC and any OTP value generated by the client MUST be generated according to the information contained within that element. If more than one OTP-TOKENINFO object is included, then the OTP value MUST be generated according to the information contained within one of those objects.
otp tokenInfo必须包含此元素，它是一个或多个otp-tokenInfo对象的序列，包含用户可用于身份验证的一个或多个令牌的信息，以及如何使用这些令牌生成otp值。如果包含单个OTP-TOKENINFO对象，则KDC只接受单个令牌，并且必须根据该元素中包含的信息生成客户端生成的任何OTP值。如果包含多个OTP-TOKENINFO对象，则必须根据其中一个对象中包含的信息生成OTP值。
flags If the "nextOTP" flag is set, then the OTP SHALL be based on the next token "state" rather than the one used in the previous authentication. As an example, for a time-based token, this means the next time slot and for an event-based token, this could mean the next counter value. If the "nextOTP" flag is set, then there MUST only be a single otp-tokenInfo element in the PA-OTP-CHALLENGE.
标志如果设置了“nextOTP”标志，则OTP应基于下一个令牌“状态”，而不是先前认证中使用的令牌。例如，对于基于时间的令牌，这意味着下一个时隙，对于基于事件的令牌，这可能意味着下一个计数器值。如果设置了“nextOTP”标志，则PA-otp-CHALLENGE中只能有一个otp tokenInfo元素。
The "combine" flag controls how the challenge included in otp-challenge shall be used. If the flag is set, then OTP SHALL be calculated using the challenge from otp-challenge and the internal token state (e.g., time or counter). If the "combine" flag is not set, then the OTP SHALL be calculated based only on the challenge. If the flag is set and otp-challenge is not present, then the request SHALL be regarded as invalid.
“联合”标志控制如何使用otp质询中包含的质询。如果设置了标志，则应使用来自OTP质询的质询和内部令牌状态（例如，时间或计数器）计算OTP。如果未设置“联合收割机”标志，则应仅根据质询计算OTP。如果设置了标志且otp质询不存在，则该请求应视为无效。
If the "do-not-collect-pin" flag is set, then the token represented by the current otp-tokenInfo does not require a PIN to be collected as part of the OTP. If the "collect-pin" flag is set, then the token requires a PIN. If neither flag is set, then whether or not a PIN is required is unspecified. The flags are mutually exclusive and so both flags MUST NOT be set, or the client MUST regard the request as invalid.
如果设置了“不收集pin”标志，则当前otp tokenInfo表示的令牌不需要收集pin作为otp的一部分。如果设置了“收集pin”标志，则令牌需要pin。如果未设置任何标志，则未指定是否需要PIN。这些标志是互斥的，因此不能同时设置这两个标志，否则客户端必须将请求视为无效。
If the "must-encrypt-nonce" flag is set, then the OTP value MUST NOT be included in the otp-value field of the PA-OTP-REQUEST, but instead the OTP value MUST be used in the generation of the Reply Key and Client Key as described in Section 3.6.
如果设置了“必须加密nonce”标志，则OTP值不得包含在PA-OTP-REQUEST的OTP值字段中，而是必须在生成应答密钥和客户端密钥时使用OTP值，如第3.6节所述。
If the "separate-pin-required" flag is set, then the PIN collected by the client SHOULD NOT be used in the generation of the OTP value and SHOULD be returned in the otp-pin field of the PA-OTP-REQUEST.
如果设置了“需要单独的pin”标志，则客户端收集的pin不应用于生成OTP值，而应在PA-OTP-REQUEST的OTP pin字段中返回。
The "check-digit" flag controls whether or not the OTP values generated by the token need to include a Luhn check digit [ISOIEC7812]. If the token is disconnected, then the Client MAY ignore this flag; if this flag is set and the token is connected, then the OTP MUST be a decimal with a check digit appended.
“校验位”标志控制令牌生成的OTP值是否需要包括Luhn校验位[ISOIEC7812]。如果令牌断开连接，则客户端可以忽略此标志；如果设置了此标志且令牌已连接，则OTP必须是一个附加了校验位的十进制数。
otp-vendor Use of this field is OPTIONAL, but MAY be used by the KDC to identify the vendor of the OTP token to be used.
otp供应商使用此字段是可选的，但KDC可以使用此字段来标识要使用的otp令牌的供应商。
otp-challenge The otp-challenge is used by the KDC to send a challenge value for use in the OTP calculation. The challenge is an OPTIONAL octet string that SHOULD be uniquely generated for each request in which it is present. When the challenge is not present, the OTP will be calculated on the current token state only. The client MAY ignore a provided challenge if and only if the OTP token the client is interacting with is not capable of including a challenge in the OTP calculation. In this case, KDC policies will determine whether or not to accept a provided OTP value.
otp质询KDC使用otp质询发送质询值以用于otp计算。质询是一个可选的八位字节字符串，它应该为存在质询的每个请求唯一地生成。当质询不存在时，将仅根据当前令牌状态计算OTP。当且仅当客户端与之交互的OTP令牌不能在OTP计算中包括质询时，客户端可以忽略提供的质询。在这种情况下，KDC策略将决定是否接受提供的OTP值。
otp-length Use of this field is OPTIONAL, but MAY be used by the KDC to specify the desired length of the generated OTP. For example, this field could be used when a token is capable of producing OTP values of different lengths. If the format of the OTP is 'decimal', 'hexidecimal', or 'alphanumeric', then this value indicates the desired length in digits/characters; if the OTP format is 'binary', then this value indicates the desired length in octets; and if the OTP format is 'base64', then this value indicates the desired length of the unencoded OTP value in octets.
otp长度使用此字段是可选的，但KDC可以使用此字段指定所生成otp的所需长度。例如，当令牌能够产生不同长度的OTP值时，可以使用此字段。如果OTP的格式为“十进制”、“十六进制”或“字母数字”，则该值以数字/字符表示所需的长度；如果OTP格式为“二进制”，则该值表示所需的八位字节长度；如果OTP格式为“base64”，则该值表示未编码OTP值的期望长度（以八位字节为单位）。
otp-format Use of this field is OPTIONAL, but MAY be used by the KDC to specify the desired format of the generated OTP value. For example, this field could be used when a token is capable of producing OTP values of different formats.
此字段的otp格式使用是可选的，但KDC可以使用它来指定生成的otp值的所需格式。例如，当令牌能够生成不同格式的OTP值时，可以使用此字段。
otp-tokenID Use of this field is OPTIONAL, but MAY be used by the KDC to identify which token key should be used for the authentication. For example, this field could be used when a user has been issued multiple token keys by the same server.
此字段的otp tokenID使用是可选的，但KDC可以使用它来标识应该使用哪个令牌密钥进行身份验证。例如，当同一服务器向用户颁发了多个令牌密钥时，可以使用此字段。
otp-algID Use of this field is OPTIONAL, but MAY be used by the KDC to identify the algorithm to use when generating the OTP. The value of this field MUST be a URI [RFC3986] and SHOULD be obtained from the Portable Symmetric Key Container (PSKC) algorithm registry [RFC6030].
otp algID此字段的使用是可选的，但KDC可以使用它来确定生成otp时要使用的算法。此字段的值必须是URI[RFC3986]，并且应从可移植对称密钥容器（PSKC）算法注册表[RFC6030]中获取。
supportedHashAlg If present, then a hash of the OTP value MUST be used in the key derivation rather than the plain text value. Each AlgorithmIdentifier identifies a hash algorithm that is supported by the KDC in decreasing order of preference. The client MUST select the first algorithm from the list that it supports. Support for SHA-256 by both the client and KDC is REQUIRED. The AlgorithmIdentifier selected by the client MUST be placed in the hashAlg element of the PA-OTP-REQUEST.
supportedHashAlg如果存在，则在密钥派生中必须使用OTP值的哈希，而不是纯文本值。每个AlgorithmIdentifier按偏好的降序标识KDC支持的哈希算法。客户端必须从其支持的列表中选择第一个算法。需要客户端和KDC对SHA-256的支持。客户端选择的算法标识符必须放在PA-OTP-REQUEST的hashAlg元素中。
iterationCount The minimum value of the iteration count to be used by the client when hashing the OTP value. This value MUST be present if supportedHashAlg is present and otherwise MUST NOT be present. If the value of this element does not conform to local policy on the client, then the client MAY use a larger value but MUST NOT use a lower value. The value of the iteration count used by the client MUST be returned in the PA-OTP-REQUEST sent to the KDC.
iterationCount对OTP值进行哈希运算时，客户端要使用的迭代计数的最小值。如果supportedHashAlg存在，则此值必须存在，否则不得存在。如果此元素的值不符合客户端上的本地策略，则客户端可以使用较大的值，但不能使用较小的值。客户端使用的迭代计数值必须在发送给KDC的PA-OTP-REQUEST中返回。
salt The salt value to be used in string-to-key when used to calculate the keys as described in Section 3.6.
salt当用于计算第3.6节中所述的键时，在字符串到键中使用的salt值。
s2kparams Any additional parameters required by string-to-key as described in Section 3.6.
s2kparams第3.6节中所述的字符串到键所需的任何附加参数。
The padata-type PA-OTP-REQUEST is sent by the client to the KDC in the KrbFastReq padata of a PA-FX-FAST-REQUEST that is included in the PA-DATA of an AS-REQ. The corresponding padata-value field contains the DER encoding of a PA-OTP-REQUEST.
padata类型PA-OTP-REQUEST由客户端发送至AS-REQ的PA-FX-FAST-REQUEST的KrbFastReq padata中的KDC，该请求包含在AS-REQ的PA-DATA中。相应的padata值字段包含PA-OTP-REQUEST的DER编码。
The message contains pre-authentication data encrypted by the client using the generated Client Key and optional information on how the OTP was generated. It may also, optionally, contain the generated OTP value.
该消息包含由客户端使用生成的客户端密钥加密的预认证数据，以及关于如何生成OTP的可选信息。它还可以选择性地包含生成的OTP值。
PA-OTP-REQUEST 142
PA-OTP-REQUEST 142
PA-OTP-REQUEST ::= SEQUENCE {
flags [0] OTPFlags,
nonce [1] OCTET STRING OPTIONAL,
encData [2] EncryptedData,
-- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
-- Key usage of KEY_USAGE_OTP_REQUEST
hashAlg [3] AlgorithmIdentifier OPTIONAL,
iterationCount [4] Int32 OPTIONAL,
otp-value [5] OCTET STRING OPTIONAL,
otp-pin [6] UTF8String OPTIONAL,
otp-challenge [7] OCTET STRING (SIZE(1..MAX)) OPTIONAL,
otp-time [8] KerberosTime OPTIONAL,
otp-counter [9] OCTET STRING OPTIONAL,
otp-format [10] OTPFormat OPTIONAL,
otp-tokenID [11] OCTET STRING OPTIONAL,
otp-algID [12] AnyURI OPTIONAL,
otp-vendor [13] UTF8String OPTIONAL,
...
}
PA-OTP-REQUEST ::= SEQUENCE {
flags [0] OTPFlags,
nonce [1] OCTET STRING OPTIONAL,
encData [2] EncryptedData,
-- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
-- Key usage of KEY_USAGE_OTP_REQUEST
hashAlg [3] AlgorithmIdentifier OPTIONAL,
iterationCount [4] Int32 OPTIONAL,
otp-value [5] OCTET STRING OPTIONAL,
otp-pin [6] UTF8String OPTIONAL,
otp-challenge [7] OCTET STRING (SIZE(1..MAX)) OPTIONAL,
otp-time [8] KerberosTime OPTIONAL,
otp-counter [9] OCTET STRING OPTIONAL,
otp-format [10] OTPFormat OPTIONAL,
otp-tokenID [11] OCTET STRING OPTIONAL,
otp-algID [12] AnyURI OPTIONAL,
otp-vendor [13] UTF8String OPTIONAL,
...
}
KEY_USAGE_OTP_REQUEST 45
密钥使用OTP请求45
PA-OTP-ENC-REQUEST ::= SEQUENCE {
nonce [0] OCTET STRING,
...
}
PA-OTP-ENC-REQUEST ::= SEQUENCE {
nonce [0] OCTET STRING,
...
}
flags This field MUST be present.
标记此字段必须存在。
If the "nextOTP" flag is set, then the OTP was calculated based on the next token "state" rather than the current one. This flag MUST be set if and only if it was set in a corresponding PA-OTP-CHALLENGE.
如果设置了“nextOTP”标志，则OTP是基于下一个令牌“状态”而不是当前令牌计算的。当且仅当该标志在相应的PA-OTP-CHARGE中设置时，必须设置该标志。
If the "combine" flag is set, then the OTP was calculated based on a challenge and the token state.
如果设置了“combine”标志，则根据质询和令牌状态计算OTP。
No other OTPFlag bits are applicable and MUST be ignored by the KDC.
其他OTPFlag位不适用，KDC必须忽略。
nonce This field MUST be present if a hashed OTP value was used as input to string-to-key (see Section 3.6) and MUST NOT be present otherwise. If present, it MUST contain the nonce value generated by the client and used in the generation of hashed OTP values as
nonce如果散列OTP值用作字符串到键的输入（参见第3.6节），则此字段必须存在，否则不得存在。如果存在，它必须包含客户端生成的nonce值，并在生成哈希OTP值时使用
described in Section 3.6. This nonce string MUST be as long as the longest key length of the symmetric key types that the client supports and MUST be chosen randomly.
如第3.6节所述。此nonce字符串的长度必须与客户端支持的对称密钥类型的最长密钥长度相同，并且必须随机选择。
encData This field MUST be present and MUST contain the pre-authentication data encrypted under the Client Key with a key usage of KEY_USAGE_OTP_REQUEST. If the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE, then this MUST contain a PA-OTP-ENC-REQUEST with the nonce from the PA-OTP-CHALLENGE. If no challenge was received, then this MUST contain a PA-ENC-TS-ENC.
encData此字段必须存在，并且必须包含在客户端密钥下加密的预身份验证数据，密钥用法为Key\u usage\u OTP\u请求。如果PA-OTP-REQUEST是由于PA-OTP-CHALLENGE而发送的，那么它必须包含一个PA-OTP-ENC-REQUEST，其nonce来自PA-OTP-CHALLENGE。如果未收到质询，则该质询必须包含PA-ENC-TS-ENC。
hashAlg This field MUST be present if a hashed OTP value was used as input to string-to-key (see Section 3.6) and MUST NOT be present otherwise. If present, it MUST contain the AlgorithmIdentifier of the hash algorithm used. If the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE, then the AlgorithmIdentifer MUST be the first one supported by the client from the supportedHashAlg of the PA-OTP-CHALLENGE.
如果哈希OTP值被用作字符串到键的输入（参见第3.6节），则该字段必须存在，否则不得存在。如果存在，它必须包含所用哈希算法的算法标识符。如果PA-OTP-REQUEST作为PA-OTP-CHALLENGE的结果发送，则算法标识符必须是客户端从PA-OTP-CHALLENGE的supportedHashAlg支持的第一个标识符。
iterationCount This field MUST be present if a hashed OTP value was used as input to string-to-key (see Section 3.6) and MUST NOT be present otherwise. If present, it MUST contain the iteration count used when hashing the OTP value. If the PA-OTP-REQUEST is sent as a result of a PA-OTP-CHALLENGE, then the value MUST NOT be less that specified in the PA-OTP-CHALLENGE.
iterationCount如果哈希OTP值被用作字符串到键的输入（参见第3.6节），则此字段必须存在，否则不得存在。如果存在，它必须包含散列OTP值时使用的迭代计数。如果PA-OTP-REQUEST是由于PA-OTP-CHALLENGE而发送的，则该值不得小于PA-OTP-CHALLENGE中规定的值。
otp-value The generated OTP value. This value MUST NOT be present if the "must-encrypt-nonce" flag was set in the PA-OTP-CHALLENGE.
otp值生成的otp值。如果PA-OTP-CHALLENGE中设置了“必须加密当前”标志，则该值不得存在。
otp-pin The OTP PIN value entered by the user. This value MUST NOT be present unless the "separate-pin-required" flag was set in the PA-OTP-CHALLENGE.
otp pin用户输入的otp pin值。除非在PA-OTP-CHARGE中设置了“需要单独的pin”标志，否则不得出现该值。
otp-challenge Value used by the client in the OTP calculation. It MUST be sent to the KDC if and only if the value would otherwise be unknown to the KDC (for example, the token- or client-modified or generated challenge).
客户在otp计算中使用的otp质询值。当且仅当KDC不知道该值（例如，令牌或客户端修改或生成的质询）时，必须将其发送给KDC。
otp-time This field MAY be included by the client to carry the time value as reported by the OTP token. Use of this element is OPTIONAL, but it MAY be used by a client to simplify the OTP calculations carried out by the KDC. It is RECOMMENDED that the KDC act upon this value if it is present in the request and it is capable of using it in the generation of the OTP value.
otp时间客户机可能会包括此字段，以携带otp令牌报告的时间值。此元素的使用是可选的，但客户可以使用它来简化KDC执行的OTP计算。如果请求中存在该值，并且KDC能够在生成OTP值时使用该值，则建议KDC根据该值进行操作。
otp-counter This field MAY be included by the client to carry the token counter value, as reported by the OTP token. Use of this element is OPTIONAL, but it MAY be used by a client to simplify the OTP calculations carried out by the KDC. It is RECOMMENDED that the KDC act upon this value if it is present in the request and it is capable of using it in the generation of the OTP value.
otp计数器该字段可由客户端包含，以携带otp令牌报告的令牌计数器值。此元素的使用是可选的，但客户可以使用它来简化KDC执行的OTP计算。如果请求中存在该值，并且KDC能够在生成OTP值时使用该值，则建议KDC根据该值进行操作。
otp-format This field MAY be used by the client to send the format of the generated OTP as reported by the OTP token. Use of this element is OPTIONAL, but it MAY be used by the client to simplify the OTP calculations carried out by the KDC. It is RECOMMENDED that the KDC act upon this value, if it is present in the request and it is capable of using it in the generation of the OTP value.
otp格式客户端可使用此字段发送otp令牌报告的生成otp的格式。此元素的使用是可选的，但客户可以使用它来简化KDC执行的OTP计算。如果请求中存在该值，并且KDC能够在生成OTP值时使用该值，则建议KDC根据该值进行操作。
otp-tokenID This field MAY be used by the client to send the identifier of the token key used, as reported by the OTP token. Use of this field is OPTIONAL, but MAY be used by the client to simplify the authentication process by identifying a particular token key associated with the user. It is RECOMMENDED that the KDC act upon this value, if it is present in the request and it is capable of using it in the generation of the OTP value.
otp令牌ID客户端可使用此字段发送otp令牌报告的所用令牌密钥的标识符。此字段的使用是可选的，但客户端可以通过标识与用户关联的特定令牌密钥来简化身份验证过程。如果请求中存在该值，并且KDC能够在生成OTP值时使用该值，则建议KDC根据该值进行操作。
otp-algID This field MAY be used by the client to send the identifier of the OTP algorithm used, as reported by the OTP token. Use of this element is OPTIONAL, but it MAY be used by the client to simplify the OTP calculations carried out by the KDC. It is RECOMMENDED that the KDC act upon this value, if it is present in the request and it is capable of using it in the generation of the OTP value. The value of this field MUST be a URI [RFC3986] and SHOULD be obtained from the PSKC algorithm registry [RFC6030].
otp algID客户端可使用此字段发送otp令牌报告的所用otp算法的标识符。此元素的使用是可选的，但客户可以使用它来简化KDC执行的OTP计算。如果请求中存在该值，并且KDC能够在生成OTP值时使用该值，则建议KDC根据该值进行操作。此字段的值必须是URI[RFC3986]，并且应从PSKC算法注册表[RFC6030]中获取。
otp-vendor If the PA-OTP-REQUEST is being sent in response to a PA-OTP-CHALLENGE that contained an otp-vendor field in the selected otp-tokenInfo, then this field MUST be set to the same value; otherwise, this field SHOULD be set to the vendor identifier of the token, if known to the client. It is RECOMMENDED that the KDC act upon this value if it is present in the request and it is capable of using it in the generation of the OTP value.
otp供应商如果PA-otp-REQUEST是为了响应PA-otp-CHALLENGE而发送的，该PA-otp-CHALLENGE在所选otp令牌信息中包含otp供应商字段，则该字段必须设置为相同的值；否则，该字段应设置为令牌的供应商标识符（如果客户端知道）。如果请求中存在该值，并且KDC能够在生成OTP值时使用该值，则建议KDC根据该值进行操作。
The padata-type PA-OTP-PIN-CHANGE is returned by the KDC in the enc-fast-rep of a PA-FX-FAST-REPLY in the AS-REP if the user must change their PIN, if the user's PIN has been changed, or to notify the user of the PIN's expiry time.
如果用户必须更改其PIN，如果用户的PIN已更改，或通知用户PIN的到期时间，则KDC将在AS-rep中PA-FX-fast-rep的enc fast rep中返回padata类型PA-OTP-PIN-CHANGE。
The corresponding padata-value field contains the DER encoding of a PA-OTP-PIN-CHANGE.
对应的padata值字段包含PA-OTP-PIN-CHANGE的DER编码。
PA-OTP-PIN-CHANGE 144
PA-OTP-PIN-CHANGE 144
PA-OTP-PIN-CHANGE ::= SEQUENCE {
flags [0] PinFlags,
pin [1] UTF8String OPTIONAL,
minLength [2] INTEGER OPTIONAL,
maxLength [3] INTEGER OPTIONAL,
last-req [4] LastReq OPTIONAL,
format [5] OTPFormat OPTIONAL,
...
}
PA-OTP-PIN-CHANGE ::= SEQUENCE {
flags [0] PinFlags,
pin [1] UTF8String OPTIONAL,
minLength [2] INTEGER OPTIONAL,
maxLength [3] INTEGER OPTIONAL,
last-req [4] LastReq OPTIONAL,
format [5] OTPFormat OPTIONAL,
...
}
PinFlags ::= KerberosFlags
-- reserved(0),
-- systemSetPin(1),
-- mandatory(2)
PinFlags ::= KerberosFlags
-- reserved(0),
-- systemSetPin(1),
-- mandatory(2)
flags The "systemSetPin" flag is used to indicate the type of PIN change that is taking place. If the flag is set, then the user's PIN has been changed for the user by the system. If the flag is not set, then the user's PIN needs to be changed by the user.
标志“systemSetPin”标志用于指示正在发生的管脚更改类型。如果设置了该标志，则系统已更改该用户的PIN。如果未设置标志，则用户需要更改用户的PIN。
If the "systemSetPin" flag is not set and the "mandatory" flag is set, then user PIN change is required before the next authentication using the current OTP token. If the "mandatory" flag is not set, then the user PIN change is optional. If the
如果未设置“systemSetPin”标志且设置了“强制”标志，则需要在使用当前OTP令牌进行下一次身份验证之前更改用户PIN。如果未设置“强制”标志，则用户PIN更改是可选的。如果
"systemSetPin" flag is set, then the "mandatory" flag has no meaning and SHOULD be ignored by the client.
如果设置了“systemSetPin”标志，则“强制”标志没有任何意义，客户端应忽略该标志。
pin The pin field is used to carry a new PIN value. If the "systemSetPin" flag is set, then the pin field is used to carry the new PIN value set for the user and MUST be present. If the "systemSetPin" flag is not set, then use of this field is OPTIONAL and MAY be used to carry a system-generated PIN that MAY be used by the user when changing the PIN.
引脚引脚字段用于携带新的引脚值。如果设置了“systemSetPin”标志，则pin字段用于携带为用户设置的新pin值，并且必须存在。如果未设置“systemSetPin”标志，则此字段的使用是可选的，可用于携带系统生成的PIN，用户可在更改PIN时使用该PIN。
minLength and maxLength Use of the minLength and maxLength fields is OPTIONAL. If the "systemSetPin" flag is not set, then these fields MAY be included to pass restrictions on the size of the user-selected PIN.
minLength和maxLength使用minLength和maxLength字段是可选的。如果未设置“systemSetPin”标志，则可能会包括这些字段，以通过对用户选择的PIN大小的限制。
last-req Use of the last-req field (as defined in Section 5.4.2 of [RFC4120])) is OPTIONAL, but MAY be included with an lr-type of 6 to carry PIN expiration information.
最后一个req字段的最后一个req使用（如[RFC4120]第5.4.2节中所定义）是可选的，但可以包括在lr类型6中，以携带PIN到期信息。
* If the "systemSetPin" flag is set, then the expiration time MUST be that of the new system-set PIN.
* 如果设置了“systemSetPin”标志，则过期时间必须是新系统设置PIN的过期时间。
* If the "systemSetPin" flag is not set, then the expiration time MUST be that of the current PIN of the token used in the authentication.
* 如果未设置“systemSetPin”标志，则过期时间必须是身份验证中使用的令牌的当前PIN的过期时间。
The element MAY also be included with an lr-type of 7 to indicate when the OTP account will expire.
该元素也可以包含在lr类型7中，以指示OTP帐户何时到期。
format The format element MAY be included by the KDC to carry format restrictions on the new PIN.
格式KDC可能包括格式元素，以对新PIN进行格式限制。
* If the "systemSetPin" flag is set, then the element MUST describe the format of the new system-generated PIN.
* 如果设置了“systemSetPin”标志，则元素必须描述新系统生成的PIN的格式。
* If the "systemSetPin" flag is not set, then the element MUST describe restrictions on any new user-generated PIN.
* 如果未设置“systemSetPin”标志，则元素必须描述对任何新用户生成的PIN的限制。
The OTP algorithm identifier URIs used as otp-algID values in the PA-OTP-CHALLENGE described in Section 4.1 and the PA-OTP-REQUEST described in Section 4.2 have been registered in the "Algorithm URI Registry and Related PSKC Profiles" registry [RFC6030].
第4.1节中描述的PA-OTP-CHALLENGE中用作OTP algID值的OTP算法标识符URI和第4.2节中描述的PA-OTP-REQUEST已在“算法URI注册表和相关PSKC配置文件”注册表中注册[RFC6030]。
The following pre-authentication types are defined in this document:
本文档中定义了以下预认证类型：
PA-OTP-CHALLENGE 141 PA-OTP-REQUEST 142 PA-OTP-PIN-CHANGE 144
PA-OTP-CHALLENGE 141 PA-OTP-REQUEST 142 PA-OTP-PIN-CHANGE 144
Note that PA-OTP-CONFIRM (143) has been marked as OBSOLETE per this document.
注意，根据本文件，PA-OTP-CONFIRM（143）已标记为已过时。
These values are currently registered in a registry created by [RFC6113], but the entries have been updated to refer to this document.
这些值当前已在[RFC6113]创建的注册表中注册，但已更新条目以引用此文档。
The following error codes and key usage values are defined in this document:
本文档中定义了以下错误代码和关键用法值：
KDC_ERR_INVALID_HASH_ALG 94 KDC_ERR_INVALID_ITERATION_COUNT 95 KDC_ERR_PIN_EXPIRED 96 KDC_ERR_PIN_REQUIRED 97 KEY_USAGE_OTP_REQUEST 45
KDC_ERR_INVALID_HASH_ALG 94 KDC_ERR_INVALID_ITERATION_COUNT 95 KDC_ERR_PIN_过期96 KDC_ERR_PIN_所需97键使用情况OTP_请求45
These values are currently not managed by IANA and have not been accounted for. There is currently work in progress [LHA10] to define IANA registries and a registration process for these values.
这些值目前不由IANA管理，也没有被考虑在内。目前正在[LHA10]定义IANA注册和这些值的注册过程。
In the system described in this document, the OTP pre-authentication protocol is tunneled within the FAST Armor channel provided by the pre-authentication framework. As described in [ASNINY02], tunneled protocols are potentially vulnerable to man-in-the-middle (MITM) attacks if the outer tunnel is compromised, and it is generally considered good practice in such cases to bind the inner encryption to the outer tunnel.
在本文档中描述的系统中，OTP预认证协议在预认证框架提供的快速装甲通道中进行隧道传输。如[ASNINY02]所述，如果外部隧道受损，隧道协议可能容易受到中间人（MITM）攻击，在这种情况下，将内部加密绑定到外部隧道通常被认为是良好的做法。
In order to mitigate against such attacks, the proposed system uses the outer Armor Key in the derivation of the inner Client and Reply keys and so achieves crypto-binding to the outer channel.
为了抵御此类攻击，该系统在派生内部客户端和应答密钥时使用外部装甲密钥，从而实现与外部信道的加密绑定。
As described in Section 5.4 of [RFC6113], FAST can use an anonymous Ticket-Granting Ticket (TGT) obtained using anonymous Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) [RFC6112] [RFC4556] as the Armor Key. However, the current anonymous PKINIT proposal is open to MITM attacks since the attacker
如[RFC6113]第5.4节所述，FAST可以使用匿名公钥加密获得的匿名票证授予票证（TGT）作为密钥，用于Kerberos（PKINIT）[RFC6112][RFC4556]中的初始身份验证。但是，当前的匿名PKINIT方案会受到MITM攻击，因为攻击者
can choose a session key such that the session key between the MITM and the real KDC is the same as the session key between the client and the MITM.
可以选择会话密钥，以便MITM和真实KDC之间的会话密钥与客户机和MITM之间的会话密钥相同。
As described in Section 3.6, if the OTP value is not being sent to the KDC, then the Armor Key is used along with the OTP value in the generation of the Client Key and Reply Key. If the Armor Key is known, then the only entropy remaining in the key generation is provided by the OTP value. If the OTP algorithm requires that the OTP value be sent to the KDC, then it is sent encrypted within the tunnel provided by the FAST Armor and so, is exposed to the attacker if the attacker has the Armor Key.
如第3.6节所述，如果OTP值未发送给KDC，则在生成客户机密钥和回复密钥时，会将Armor密钥与OTP值一起使用。如果已知装甲密钥，则密钥生成中剩余的唯一熵由OTP值提供。如果OTP算法要求将OTP值发送到KDC，那么它将在FAST Armor提供的隧道内加密发送，因此，如果攻击者拥有Armor密钥，它将暴露给攻击者。
Therefore, unless the identity of the KDC has been verified, anonymous PKINIT SHALL NOT be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security considerations should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values.
因此，除非已验证KDC的身份，否则匿名PKINIT不得与要求向KDC发送OTP值的OTP算法一起使用。此外，在将匿名PKINIT与其他算法（如OTP值较短的算法）一起使用之前，应仔细考虑安全因素。
Careful consideration should also be made if host key armor is used to provide the KDC-authentication facility with OTP algorithms where the OTP value is sent within the otp-value field of the PA-OTP-REQUEST since compromised host keys would allow an attacker to impersonate the KDC.
如果主机密钥护甲用于向KDC身份验证设施提供OTP算法，其中OTP值在PA-OTP-REQUEST的OTP值字段内发送，则还应仔细考虑，因为泄露的主机密钥将允许攻击者模拟KDC。
The four-pass system described above is a challenge-response protocol, and such protocols are potentially vulnerable to reflection attacks. No such attacks are known at this point, but to help mitigate against such attacks, the system uses different keys to encrypt the client and server nonces.
上述四通道系统是一种质询-响应协议，此类协议可能容易受到反射攻击。目前还不知道此类攻击，但为了帮助抵御此类攻击，系统使用不同的密钥加密客户端和服务器的nonce。
The protocol supports the use of an iteration count in the generation of the Client and Reply keys, and the client can send the number of iterations used as part of the PA-OTP-REQUEST. This could open the KDC up to a denial-of-service attack if a large value for the iteration count was specified by the attacker. It is therefore, particularly important that, as described in Section 3.4, the KDC reject any authentication requests where the iteration count is above a maximum value specified by local policy.
该协议支持在生成客户端和应答密钥时使用迭代计数，并且客户端可以发送作为PA-OTP-REQUEST的一部分使用的迭代次数。如果攻击者指定了较大的迭代计数值，这可能会使KDC遭受拒绝服务攻击。因此，特别重要的是，如第3.4节所述，KDC拒绝迭代计数高于本地策略指定的最大值的任何身份验证请求。
In the four-pass version of this protocol, the client encrypts a KDC-generated nonce, so replay can be detected by the KDC. The two-pass version of the protocol does not involve a server nonce; the client instead encrypts a timestamp, and therefore is not protected from replay in this way, but it will instead require some other mechanism, such as an OTP-server-based system or a timestamp-based replay cache on the KDC.
在该协议的四次传递版本中，客户端加密KDC生成的nonce，因此KDC可以检测到重播。协议的两次传递版本不涉及服务器nonce；相反，客户端加密时间戳，因此不会以这种方式防止重播，但它将需要一些其他机制，例如基于OTP服务器的系统或KDC上基于时间戳的重播缓存。
As described in Section 5.2 of [RFC6113], a client cannot be certain that it will use the same KDC for all messages in a conversation. Therefore, the client cannot assume that the PA-OTP-REQUEST will be sent to the same KDC that issued the PA-OTP-CHALLENGE. In order to support this, a KDC implementing this protocol requires a means of sharing session state. However, doing this does introduce the possibility of a replay attack where the same response is sent to multiple KDCs.
如[RFC6113]第5.2节所述，客户机无法确定它将对会话中的所有消息使用相同的KDC。因此，客户端不能假设PA-OTP-REQUEST将被发送到发出PA-OTP-CHALLENGE的同一KDC。为了支持这一点，实现该协议的KDC需要一种共享会话状态的方法。但是，这样做确实会引入重播攻击的可能性，即向多个KDC发送相同的响应。
In the case of time- or event-based tokens or server-generated challenges, protection against replay may be provided by the OTP server being used if that server is capable of keeping track of the last used value. This protection therefore relies upon the assumption that the OTP server being used in this protocol is either not redundant or involves a commit protocol to synchronize between replicas. If this does not hold for an OTP server being used, then the system may be vulnerable to replay attacks.
在基于时间或事件的令牌或服务器生成的质询的情况下，如果所使用的OTP服务器能够跟踪最后使用的值，则该服务器可以提供防止重播的保护。因此，这种保护依赖于这样一种假设，即此协议中使用的OTP服务器不是冗余的，或者涉及一个提交协议来在副本之间进行同步。如果这对正在使用的OTP服务器不适用，则系统可能容易受到重播攻击。
However, OTP servers may not be able to detect replay of OTPs generated using only a client-generated challenge; since, the KDC would not be able to detect replay in two-pass mode, it is recommended that the use of OTPs generated from only a client-generated challenge (that is, not in combination with some other factor such as time) should not be supported in two-pass mode.
但是，OTP服务器可能无法检测仅使用客户端生成的质询生成的OTP的重播；由于KDC无法在双通道模式下检测重播，因此建议在双通道模式下不支持使用仅由客户端生成的质询生成的OTP（即，不与时间等其他因素结合使用）。
A compromised or hostile KDC may be able to obtain the OTP value used by the client via a brute-force attack. If the OTP value is short, then the KDC could iterate over the possible OTP values until a Client Key is generated that can decrypt the encData sent in the PA-OTP-REQUEST.
受损或恶意KDC可能通过暴力攻击获得客户端使用的OTP值。如果OTP值较短，则KDC可以迭代可能的OTP值，直到生成可以解密PA-OTP-REQUEST中发送的数据的客户端密钥。
As described in Section 3.6, an iteration count can be used in the generation of the Client Key and the value of the iteration count can be controlled by local client policy. Use of this iteration count can make it computationally infeasible/unattractive for an attacker to brute-force search for the given OTP within the lifetime of that OTP.
如第3.6节所述，迭代计数可用于生成客户端密钥，且迭代计数的值可由本地客户端策略控制。使用此迭代计数会使攻击者在给定OTP的生存期内强行搜索该OTP在计算上不可行/不具吸引力。
If PINs contain international characters, similar looking or similar functioning characters may be mapped together. For example, the combined and decomposed forms of accented characters will typically be treated the same. Users who attempt to exploit artifacts of international characters to improve the strength of their PINs may experience false positives in the sense that PINs they intended to be distinct are not actually distinct. This decision was made in order to improve usability across the widest variety of input methods. Users can choose other methods to add strength to PINs.
如果PIN包含国际字符，则可以将外观相似或功能相似的字符映射在一起。例如，重音字符的组合形式和分解形式通常将被视为相同。试图利用国际字符的人工制品来提高其PIN强度的用户可能会遇到误报，因为他们想要区分的PIN实际上并不明显。做出这一决定是为了提高各种输入法的可用性。用户可以选择其他方法为销添加强度。
The secret used to generate the OTP is known only to the client and the KDC, so successful decryption of the encrypted nonce by the KDC authenticates the user. If the OTP value is used in the Reply Key generation, then successful decryption of the encrypted nonce by the client proves that the expected KDC replied. The Reply Key is replaced by either a key generated from the OTP and Armor Key or by the Armor Key. This FAST factor therefore, provides the following facilities: client-authentication, replacing-reply-key, and, depending on the OTP algorithm, KDC-authentication.
用于生成OTP的秘密仅为客户端和KDC所知，因此KDC对加密的nonce的成功解密验证了用户的身份。如果在应答密钥生成中使用OTP值，则客户端对加密的nonce成功解密证明预期KDC已应答。应答密钥由OTP和Armor密钥生成的密钥或Armor密钥替换。因此，这个快速因素提供了以下功能：客户端身份验证、替换应答密钥，以及根据OTP算法，KDC身份验证。
Many significant contributions were made to this document by RSA employees, but special thanks go to Magnus Nystrom, John Linn, Richard Zhang, Piers Bowness, Robert Philpott, Robert Polansky, and Boris Khoutorski.
RSA员工对本文档做出了许多重要贡献，但特别感谢Magnus Nystrom、John Linn、Richard Zhang、Piers Bowness、Robert Philpott、Robert Polansky和Boris Khoutorski。
Many valuable suggestions were also made by members of the Kerberos Working Group, but special thanks go to Larry Zhu, Jeffrey Hutzelman, Tim Alsop, Henry Hotz, Nicolas Williams, Sam Hartman, Frank Cusak, Simon Josefsson, Greg Hudson, and Linus Nordberg.
Kerberos工作组成员也提出了许多宝贵的建议，但特别感谢拉里·朱、杰弗里·哈泽尔曼、蒂姆·阿尔索普、亨利·霍茨、尼古拉斯·威廉姆斯、萨姆·哈特曼、弗兰克·库萨克、西蒙·约瑟夫松、格雷格·哈德森和莱纳斯·诺德伯格。
I would also like to thank Tim Alsop and Srinivas Cheruku of CyberSafe for many valuable review comments.
我还要感谢CyberSafe的Tim Alsop和Srinivas Cheruku提供了许多有价值的评论。
[ISOIEC7812] ISO, "ISO/IEC 7812-1:2006 Identification cards -- Identification of issuers -- Part 1: Numbering system", October 2006, <http://www.iso.org/iso/iso_catalogue/ catalogue_tc/catalogue_detail.htm?csnumber=39698>.
[ISOIEC7812]ISO，“ISO/IEC 7812-1:2006识别卡——发卡机构的识别——第1部分：编号系统”，2006年10月<http://www.iso.org/iso/iso_catalogue/ catalog\u tc/catalog\u detail.htm？csnumber=39698>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3961]Raeburn，K.，“Kerberos 5的加密和校验和规范”，RFC 3961，2005年2月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga，K.，“SASLprep：用户名和密码的Stringprep配置文件”，RFC40113，2005年2月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
[RFC4556]Zhu，L.和B.Tung，“Kerberos中初始身份验证的公钥加密（PKINIT）”，RFC 45562006年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for Kerberos", RFC 6112, April 2011.
[RFC6112]Zhu，L.，Leach，P.，和S.Hartman，“Kerberos的匿名性支持”，RFC 6112，2011年4月。
[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for Kerberos Pre-Authentication", RFC 6113, April 2011.
[RFC6113]Hartman，S.和L.Zhu，“Kerberos预认证的通用框架”，RFC 6113，2011年4月。
[X.680] ITU-T, "Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.", July 2002.
[X.680]ITU-T，“建议X.680（2002）| ISO/IEC 8824-1:2002，信息技术——抽象语法符号一（ASN.1）：基本符号规范”，2002年7月。
[X.690] ITU-T, "Recommendation X.690 (2008) | ISO/IEC 8825-1:2008, X.690 : Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", December 2008.
[X.690]ITU-T，“建议X.690（2008）| ISO/IEC 8825-1:2008，X.690：信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，2008年12月。
[ASNINY02] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in Tunneled Authentication Protocols", Cryptology ePrint Archive Report 2002/163, November 2002.
[ASNINY02]Asokan，N.，Niemi，V.，和K.Nyberg，“隧道认证协议中的中间人”，密码学EPRIT存档报告2002/163，2002年11月。
[HORENEZ004] Horstein, K., Renard, K., Neuman, C., and G. Zorn, "Integrating Single-use Authentication Mechanisms with Kerberos", Work in Progress, July 2004.
[Hornez004]Horstein，K.，Renard，K.，Neuman，C.，和G.Zorn，“将单次使用身份验证机制与Kerberos集成”，正在进行的工作，2004年7月。
[LHA10] Hornquist Astrand, L., "Kerberos number registry to IANA", Work in Progress, March 2010.
[LHA10]Hornquist Astrand，L.，“IANA的Kerberos号码注册”，正在进行的工作，2010年3月。
[RFC2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time Password System", STD 61, RFC 2289, February 1998.
[RFC2289]Haller，N.，Metz，C.，Nesser，P.，和M.Straw，“一次性密码系统”，STD 61，RFC 2289，1998年2月。
[RFC2808] Nystrom, M., "The SecurID(r) SASL Mechanism", RFC 2808, April 2000.
[RFC2808]Nystrom，M.，“SecurID（r）SASL机制”，RFC2808，2000年4月。
[RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, December 2005.
[RFC4226]M'Raihi，D.，Bellare，M.，Hoornaert，F.，Naccache，D.，和O.Ranen，“HOTP：基于HMAC的一次性密码算法”，RFC 42262005年12月。
[RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric Key Container (PSKC)", RFC 6030, October 2010.
[RFC6030]Hoyer，P.，Pei，M.和S.Machani，“便携式对称密钥容器（PSKC）”，RFC 603012010年10月。
OTPKerberos
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
OTPKerberos
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
进口
KerberosTime, KerberosFlags, EncryptionKey, Int32,
EncryptedData, LastReq, KerberosString
FROM KerberosV5Spec2 {iso(1) identified-organization(3)
dod(6) internet(1) security(5)
kerberosV5(2) modules(4) krb5spec2(2)}
-- as defined in RFC 4120.
AlgorithmIdentifier
FROM PKIX1Explicit88 { iso (1) identified-organization (3)
dod (6) internet (1)
security (5) mechanisms (5) pkix (7)
id-mod (0) id-pkix1-explicit (18) };
-- As defined in RFC 5280.
KerberosTime, KerberosFlags, EncryptionKey, Int32,
EncryptedData, LastReq, KerberosString
FROM KerberosV5Spec2 {iso(1) identified-organization(3)
dod(6) internet(1) security(5)
kerberosV5(2) modules(4) krb5spec2(2)}
-- as defined in RFC 4120.
AlgorithmIdentifier
FROM PKIX1Explicit88 { iso (1) identified-organization (3)
dod (6) internet (1)
security (5) mechanisms (5) pkix (7)
id-mod (0) id-pkix1-explicit (18) };
-- As defined in RFC 5280.
PA-OTP-CHALLENGE ::= SEQUENCE {
nonce [0] OCTET STRING,
otp-service [1] UTF8String OPTIONAL,
otp-tokenInfo [2] SEQUENCE (SIZE(1..MAX)) OF
OTP-TOKENINFO,
salt [3] KerberosString OPTIONAL,
s2kparams [4] OCTET STRING OPTIONAL,
...
}
PA-OTP-CHALLENGE ::= SEQUENCE {
nonce [0] OCTET STRING,
otp-service [1] UTF8String OPTIONAL,
otp-tokenInfo [2] SEQUENCE (SIZE(1..MAX)) OF
OTP-TOKENINFO,
salt [3] KerberosString OPTIONAL,
s2kparams [4] OCTET STRING OPTIONAL,
...
}
OTP-TOKENINFO ::= SEQUENCE {
flags [0] OTPFlags,
otp-vendor [1] UTF8String OPTIONAL,
otp-challenge [2] OCTET STRING (SIZE(1..MAX))
OPTIONAL,
otp-length [3] Int32 OPTIONAL,
otp-format [4] OTPFormat OPTIONAL,
otp-tokenID [5] OCTET STRING OPTIONAL,
otp-algID [6] AnyURI OPTIONAL,
supportedHashAlg [7] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
iterationCount [8] Int32 OPTIONAL,
...
}
OTP-TOKENINFO ::= SEQUENCE {
flags [0] OTPFlags,
otp-vendor [1] UTF8String OPTIONAL,
otp-challenge [2] OCTET STRING (SIZE(1..MAX))
OPTIONAL,
otp-length [3] Int32 OPTIONAL,
otp-format [4] OTPFormat OPTIONAL,
otp-tokenID [5] OCTET STRING OPTIONAL,
otp-algID [6] AnyURI OPTIONAL,
supportedHashAlg [7] SEQUENCE OF AlgorithmIdentifier
OPTIONAL,
iterationCount [8] Int32 OPTIONAL,
...
}
OTPFormat ::= INTEGER {
decimal(0),
OTPFormat ::= INTEGER {
decimal(0),
hexadecimal(1), alphanumeric(2), binary(3), base64(4) }
十六进制（1）、字母数字（2）、二进制（3）、base64（4）}
OTPFlags ::= KerberosFlags
-- reserved(0),
-- nextOTP(1),
-- combine(2),
-- collect-pin(3),
-- do-not-collect-pin(4),
-- must-encrypt-nonce (5),
-- separate-pin-required (6),
-- check-digit (7)
OTPFlags ::= KerberosFlags
-- reserved(0),
-- nextOTP(1),
-- combine(2),
-- collect-pin(3),
-- do-not-collect-pin(4),
-- must-encrypt-nonce (5),
-- separate-pin-required (6),
-- check-digit (7)
PA-OTP-REQUEST ::= SEQUENCE {
flags [0] OTPFlags,
nonce [1] OCTET STRING OPTIONAL,
encData [2] EncryptedData,
-- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
-- Key usage of KEY_USAGE_OTP_REQUEST
hashAlg [3] AlgorithmIdentifier OPTIONAL,
iterationCount [4] Int32 OPTIONAL,
otp-value [5] OCTET STRING OPTIONAL,
otp-pin [6] UTF8String OPTIONAL,
otp-challenge [7] OCTET STRING (SIZE(1..MAX)) OPTIONAL,
otp-time [8] KerberosTime OPTIONAL,
otp-counter [9] OCTET STRING OPTIONAL,
otp-format [10] OTPFormat OPTIONAL,
otp-tokenID [11] OCTET STRING OPTIONAL,
otp-algID [12] AnyURI OPTIONAL,
otp-vendor [13] UTF8String OPTIONAL,
...
}
PA-OTP-REQUEST ::= SEQUENCE {
flags [0] OTPFlags,
nonce [1] OCTET STRING OPTIONAL,
encData [2] EncryptedData,
-- PA-OTP-ENC-REQUEST or PA-ENC-TS-ENC
-- Key usage of KEY_USAGE_OTP_REQUEST
hashAlg [3] AlgorithmIdentifier OPTIONAL,
iterationCount [4] Int32 OPTIONAL,
otp-value [5] OCTET STRING OPTIONAL,
otp-pin [6] UTF8String OPTIONAL,
otp-challenge [7] OCTET STRING (SIZE(1..MAX)) OPTIONAL,
otp-time [8] KerberosTime OPTIONAL,
otp-counter [9] OCTET STRING OPTIONAL,
otp-format [10] OTPFormat OPTIONAL,
otp-tokenID [11] OCTET STRING OPTIONAL,
otp-algID [12] AnyURI OPTIONAL,
otp-vendor [13] UTF8String OPTIONAL,
...
}
PA-OTP-ENC-REQUEST ::= SEQUENCE {
nonce [0] OCTET STRING,
...
}
PA-OTP-ENC-REQUEST ::= SEQUENCE {
nonce [0] OCTET STRING,
...
}
PA-OTP-PIN-CHANGE ::= SEQUENCE {
flags [0] PinFlags,
pin [1] UTF8String OPTIONAL,
minLength [2] INTEGER OPTIONAL,
maxLength [3] INTEGER OPTIONAL,
last-req [4] LastReq OPTIONAL,
format [5] OTPFormat OPTIONAL,
PA-OTP-PIN-CHANGE ::= SEQUENCE {
flags [0] PinFlags,
pin [1] UTF8String OPTIONAL,
minLength [2] INTEGER OPTIONAL,
maxLength [3] INTEGER OPTIONAL,
last-req [4] LastReq OPTIONAL,
format [5] OTPFormat OPTIONAL,
... }
... }
PinFlags ::= KerberosFlags
-- reserved(0),
-- systemSetPin(1),
-- mandatory(2)
PinFlags ::= KerberosFlags
-- reserved(0),
-- systemSetPin(1),
-- mandatory(2)
AnyURI ::= UTF8String
(CONSTRAINED BY {
-- MUST be a valid URI in accordance with IETF RFC 2396
})
AnyURI ::= UTF8String
(CONSTRAINED BY {
-- MUST be a valid URI in accordance with IETF RFC 2396
})
END
终止
This section is non-normative.
本节是非规范性的。
In this mode, the client sends an initial AS-REQ to the KDC that does not contain a PA-OTP-REQUEST and the KDC responds with a KRB-ERROR containing a PA-OTP-CHALLENGE.
在此模式下，客户端向KDC发送初始AS-REQ，该初始AS-REQ不包含PA-OTP-REQUEST，KDC以包含PA-OTP-CHALLENGE的KRB-ERROR响应。
In this example, the user has been issued with a connected, time-based token, and the KDC requires hashed OTP values in the key generation with SHA-384 as the preferred hash algorithm and a minimum of 1024 iterations. The local policy on the client supports SHA-256 and requires 100,000 iterations of the hash of the OTP value.
在此示例中，已向用户发出连接的、基于时间的令牌，并且KDC在密钥生成中要求散列OTP值，其中SHA-384作为首选散列算法，并且至少需要1024次迭代。客户端上的本地策略支持SHA-256，需要对OTP值的哈希进行100000次迭代。
The basic sequence of steps involved is as follows:
所涉及步骤的基本顺序如下：
1. The client obtains the user name of the user.
1. 客户端获取用户的用户名。
2. The client sends an initial AS-REQ to the KDC that does not contain a PA-OTP-REQUEST.
2. 客户端向不包含PA-OTP-REQ请求的KDC发送初始AS-REQ。
3. The KDC determines that the user identified by the AS-REQ requires OTP authentication.
3. KDC确定AS-REQ标识的用户需要OTP身份验证。
4. The KDC constructs a PA-OTP-CHALLENGE as follows:
4. KDC构建了一个PA-OTP-CHALLENGE，如下所示：
nonce A randomly generated value.
nonce随机生成的值。
otp-service A string that can be used by the client to assist the user in locating the correct token.
otp服务客户端可以使用的字符串，以帮助用户定位正确的令牌。
otp-tokenInfo Information about how the OTP should be generated from the token.
otp令牌信息关于如何从令牌生成otp的信息。
flags must-encrypt-nonce and collect-pin bits set
标志必须加密nonce并收集设置的pin位
supportedHashAlg AlgorithmIdentifiers for SHA-384, SHA-256, and SHA-1
SHA-384、SHA-256和SHA-1支持的Hashalg算法标识符
iterationCount 1024
迭代计数1024
5. The KDC returns a KRB-ERROR with an error code of KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.
5. KDC返回KRB-ERROR，错误代码为KDC_ERR_PREAUTH_REQUIRED，电子数据中的PA-OTP-CHALLENGE。
6. The client displays the value of otp-service and prompts the user to connect the token.
6. 客户端显示otp服务的值，并提示用户连接令牌。
7. The client collects a PIN from the user.
7. 客户端从用户处收集PIN。
8. The client obtains the current OTP value from the token using the PIN and records the time as reported by the token.
8. 客户端使用PIN从令牌获取当前OTP值，并记录令牌报告的时间。
9. The client generates the Client Key and Reply Key as described in Section 3.6 using SHA-256 from the list of algorithms sent by the KDC, the iteration count of 100,000 as required by local policy, and a randomly generated nonce.
9. 客户端使用KDC发送的算法列表中的SHA-256、本地策略要求的100000次迭代计数以及随机生成的nonce，生成第3.6节所述的客户端密钥和应答密钥。
10. The client constructs a PA-OTP-REQUEST as follows:
10. 客户端按照如下方式构造PA-OTP-REQUEST：
flags 0
标志0
nonce The randomly generated value.
nonce随机生成的值。
encData An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted under the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and the encryption type of the Armor Key. The PA-OTP-ENC-REQUEST contains the nonce from the PA-OTP-CHALLENGE.
encData一种加密数据，包含在客户机密钥下加密的PA-OTP-ENC-REQUEST，密钥用法为Key_usage_OTP_REQUEST，加密类型为Armor密钥。PA-OTP-ENC-REQUEST包含来自PA-OTP-CHALLENGE的nonce。
hashAlg SHA-256
hashAlg SHA-256
iterationCount 100,000
迭代计数100000
otp-time The time used in the OTP calculation as reported by the OTP token.
otp时间otp令牌报告的otp计算中使用的时间。
11. The client encrypts the PA-OTP-REQUEST within the enc-fast-req of a PA-FX-FAST-REQUEST.
11. 客户端在PA-FX-fast-REQUEST的enc fast req中加密PA-OTP-REQUEST。
12. The client sends an AS-REQ to the KDC containing the PA-FX-FAST-REQUEST within the padata.
12. 客户端向KDC发送AS-REQ，其中包含padata中的PA-FX-FAST-REQUEST。
13. The KDC validates the padata in the PA-OTP-REQUEST by performing the following steps:
13. KDC通过执行以下步骤验证PA-OTP-REQUEST中的padata：
* Generates the Client Key and Reply Key from the OTP value for the user identified in the AS-REQ, using an iteration count of 100,000, a hash algorithm of SHA-256, and the nonce as specified in the PA-OTP-REQUEST.
* 使用100000的迭代计数、SHA-256的哈希算法和PA-OTP-REQUEST中指定的nonce，从AS-REQ中标识的用户的OTP值生成客户机密钥和应答密钥。
* Uses the generated Client Key to decrypt the PA-OTP-ENC-REQUEST in the encData of the PA-OTP-REQUEST.
* 使用生成的客户端密钥对PA-OTP-REQUEST的encData中的PA-OTP-ENC-REQUEST进行解密。
* Authenticates the user by comparing the nonce value from the decrypted PA-OTP-ENC-REQUEST to that sent in the corresponding PA-OTP-CHALLENGE.
* 通过将解密的PA-OTP-ENC-REQUEST中的nonce值与相应的PA-OTP-CHALLENGE中发送的nonce值进行比较，对用户进行身份验证。
14. The KDC constructs a TGT for the user.
14. KDC为用户构造一个TGT。
15. The KDC returns an AS-REP to the client, encrypted using the Reply Key, containing the TGT and padata with the PA-FX-FAST-REPLY.
15. KDC向客户端返回一个AS-REP，使用应答密钥加密，其中包含带有PA-FX-FAST-Reply的TGT和padata。
16.
16
The client authenticates the KDC and verifies the Reply Key change. The client uses the generated Reply Key to decrypt the encrypted data in the AS-REP.
客户端验证KDC并验证应答密钥更改。客户端使用生成的应答密钥对AS-REP中的加密数据进行解密。
In this mode, the client includes a PA-OTP-REQUEST within a PA-FX-FAST-REQUEST padata of the initial AS-REQ sent to the KDC.
在此模式下，客户机在发送至KDC的初始AS-REQ的PA-FX-FAST-REQUEST padata中包含PA-OTP-REQUEST。
In this example, the user has been issued a hand-held token, so, none of the OTP generation parameters (otp-length, etc.) are included in the PA-OTP-REQUEST. The KDC does not require hashed OTP values in the key generation.
在该示例中，已向用户发出手持令牌，因此，在PA-OTP-REQUEST中不包括任何OTP生成参数（OTP长度等）。KDC在密钥生成中不需要哈希OTP值。
It is assumed that the client has been configured with the following information or has obtained it from a previous PA-OTP-CHALLENGE.
假设客户机已配置了以下信息，或已从先前的PA-OTP-CHALLENGE中获得该信息。
o The OTP value must not be carried in the otp-value.
o OTP值不得包含在OTP值中。
o The hashed OTP values are not required.
o 哈希OTP值不是必需的。
The basic sequence of steps involved is as follows:
所涉及步骤的基本顺序如下：
1. The client obtains the user name and OTP value from the user.
1. 客户端从用户处获取用户名和OTP值。
2. The client generates the Client Key and Reply Key using unhashed OTP values as described in Section 3.6.
2. 如第3.6节所述，客户端使用未删除的OTP值生成客户端密钥和应答密钥。
3. The client constructs a PA-OTP-REQUEST as follows:
3. 客户端按照如下方式构造PA-OTP-REQUEST：
flags 0
标志0
encData An EncryptedData containing a PA-ENC-TS-ENC encrypted under the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and an encryption type of the Armor Key. The PA-ENC-TS-ENC contains the current client time.
encData一种加密数据，包含在客户机密钥下加密的PA-ENC-TS-ENC，密钥使用为Key\u usage\u OTP\u请求，加密类型为Armor密钥。PA-ENC-TS-ENC包含当前客户端时间。
4. The client encrypts the PA-OTP-REQUEST within the enc-fast-req of a PA-FX-FAST-REQUEST.
4. 客户端在PA-FX-fast-REQUEST的enc fast req中加密PA-OTP-REQUEST。
5. The client sends an AS-REQ to the KDC containing the PA-FX-FAST-REQUEST within the padata.
5. 客户端向KDC发送AS-REQ，其中包含padata中的PA-FX-FAST-REQUEST。
6. The KDC validates the padata by performing the following steps:
6. KDC通过执行以下步骤验证padata：
* Generates the Client Key and Reply Key from the unhashed OTP value for the user identified in the AS-REQ.
* 根据AS-REQ中标识的用户的未删除OTP值生成客户端密钥和应答密钥。
* Uses the generated Client Key to decrypt the PA-ENC-TS-ENC in the encData of the PA-OTP-REQUEST.
* 使用生成的客户端密钥对PA-OTP-REQUEST的encData中的PA-ENC-TS-ENC进行解密。
* Authenticates the user using the timestamp in the standard manner.
* 以标准方式使用时间戳对用户进行身份验证。
7. The KDC constructs a TGT for the user.
7. KDC为用户构造一个TGT。
8. The KDC returns an AS-REP to the client, encrypted using the Reply Key, containing the TGT and padata with the PA-FX-FAST-REPLY.
8. KDC向客户端返回一个AS-REP，使用应答密钥加密，其中包含带有PA-FX-FAST-Reply的TGT和padata。
9. The client authenticates the KDC and verifies the key change. The client uses the generated Reply Key to decrypt the encrypted data in the AS-REP.
9. 客户端验证KDC并验证密钥更改。客户端使用生成的应答密钥对AS-REP中的加密数据进行解密。
This exchange follows from the point where the KDC receives the PA-OTP-REQUEST from the client in the examples in Appendix B.1 and Appendix B.2. During the validation of the pre-authentication data (whether encrypted nonce or encrypted timestamp), the KDC determines that the user's PIN has expired and so, must be changed. The KDC therefore, includes a PA-OTP-PIN-CHANGE in the AS-REP.
在附录B.1和附录B.2中的示例中，KDC从客户处接收PA-OTP-REQUEST开始进行交换。在验证预认证数据期间（无论是加密的nonce还是加密的时间戳），KDC确定用户的PIN已过期，因此必须更改。因此，KDC在AS-REP中包括PA-OTP-PIN变更。
In this example, the KDC does not generate PIN values for the user but requires that the user generate a new PIN that is between 4 and 8 characters in length. The actual PIN change is handled by a PIN change service.
在本例中，KDC不为用户生成PIN值，但要求用户生成长度在4到8个字符之间的新PIN。实际的PIN更改由PIN更改服务处理。
The basic sequence of steps involved is as follows:
所涉及步骤的基本顺序如下：
1. The client constructs and sends a PA-OTP-REQUEST to the KDC as described in the previous examples.
1. 客户端构造PA-OTP-REQUEST并将其发送到KDC，如前面的示例所述。
2. The KDC validates the pre-authentication data and authenticates the user as in the previous examples but determines that the user's PIN has expired.
2. KDC验证预身份验证数据并像前面的示例中那样对用户进行身份验证，但确定用户的PIN已过期。
3. The KDC constructs a PA-OTP-PIN-CHANGE as follows:
3. KDC构建PA-OTP-PIN-CHANGE，如下所示：
flags 0 minLength 4 maxLength 8
标志0最小长度4最大长度8
4. The KDC encrypts the PA-OTP-PIN-CHANGE within the enc-fast-rep of a PA-FX-FAST-REPLY.
4. KDC在PA-FX-fast-REPLY的enc fast代表中加密PA-OTP-PIN变更。
5. The KDC returns a KRB-ERROR to the client of type KDC_ERR_PIN_EXPIRED with padata containing the PA-FX-FAST-REPLY.
5. KDC将KRB-ERROR返回给KDC_ERR_PIN_类型的客户机，其中padata包含PA-FX-FAST-REPLY。
6. The client authenticates to the PIN change service and changes the user's PIN.
6. 客户端验证PIN更改服务并更改用户的PIN。
7. The client sends a second AS-REQ to the KDC containing a PA-OTP-REQUEST constructed using the new PIN.
7. 客户端向KDC发送第二个AS-REQ，其中包含使用新PIN构造的PA-OTP-REQ。
8. The KDC responds with an AS-REP containing a TGT.
8. KDC使用包含TGT的AS-REP进行响应。
This exchange follows from the point where the KDC receives the PA-OTP-REQUEST from the client. During the validation of the pre-authentication data (whether encrypted nonce or encrypted timestamp), the KDC determines that the local record of the token's state needs to be resynchronized with the token. The KDC therefore, includes a KRB-ERROR containing a PA-OTP-CHALLENGE with the "nextOTP" flag set.
此交换从KDC从客户端接收PA-OTP-REQUEST的点开始。在验证预认证数据期间（无论是加密的nonce还是加密的时间戳），KDC确定令牌状态的本地记录需要与令牌重新同步。因此，KDC包含一个KRB-ERROR，其中包含设置了“nextOTP”标志的PA-OTP-CHALLENGE。
The sequence of steps below follows is a variation of the four pass examples shown in Appendix B.1 but the same process would also work in the two-pass case.
下面的步骤顺序是附录B.1中所示四次通过示例的变体，但同样的过程也适用于两次通过的情况。
1. The client constructs and sends a PA-OTP-REQUEST to the KDC as described in the previous examples.
1. 客户端构造PA-OTP-REQUEST并将其发送到KDC，如前面的示例所述。
2. The KDC validates the pre-authentication data and authenticates the user as in the previous examples, but determines that user's token requires resynchronizing.
2. KDC验证预身份验证数据并像前面的示例中那样对用户进行身份验证，但确定用户的令牌需要重新同步。
3. KDC constructs a PA-OTP-CHALLENGE as follows:
3. KDC构建了一个PA-OTP-CHALLENGE，如下所示：
nonce A randomly generated value.
nonce随机生成的值。
otp-service Set to a string that can be used by the client to assist the user in locating the correct token.
otp服务设置为一个字符串，客户端可以使用该字符串帮助用户定位正确的令牌。
otp-tokenInfo Information about how the OTP should be generated from the token.
otp令牌信息关于如何从令牌生成otp的信息。
flags must-encrypt-nonce, collect-pin, and nextOTP bits set
标志必须加密nonce、collect pin和nextOTP位集
supportedHashAlg AlgorithmIdentifiers for SHA-256 and SHA-1
SHA-256和SHA-1支持的Hashalg算法标识符
iterationCount 1024
迭代计数1024
4. KDC returns a KRB-ERROR with an error code of KDC_ERR_PREAUTH_REQUIRED and the PA-OTP-CHALLENGE in the e-data.
4. KDC返回KRB-ERROR，错误代码为KDC_ERR_PREAUTH_REQUIRED，电子数据中的PA-OTP-CHALLENGE。
5. The client obtains the next OTP value from the token and records the time as reported by the token.
5. 客户端从令牌获取下一个OTP值，并记录令牌报告的时间。
6. The client generates the Client Key and Reply Key as described in Section 3.6 using SHA-256 from the list of algorithms sent by the KDC, the iteration count of 100,000 as required by local policy, and a randomly generated nonce.
6. 客户端使用KDC发送的算法列表中的SHA-256、本地策略要求的100000次迭代计数以及随机生成的nonce，生成第3.6节所述的客户端密钥和应答密钥。
7. The client constructs a PA-OTP-REQUEST as follows:
7. 客户端按照如下方式构造PA-OTP-REQUEST：
flags nextOTP bit set
标志nextOTP位集
nonce The randomly generated value.
nonce随机生成的值。
encData An EncryptedData containing a PA-OTP-ENC-REQUEST encrypted under the Client Key with a key usage of KEY_USAGE_OTP_REQUEST and the encryption type of the Armor Key. The PA-OTP-ENC-REQUEST contains the nonce from the PA-OTP-CHALLENGE.
encData一种加密数据，包含在客户机密钥下加密的PA-OTP-ENC-REQUEST，密钥用法为Key_usage_OTP_REQUEST，加密类型为Armor密钥。PA-OTP-ENC-REQUEST包含来自PA-OTP-CHALLENGE的nonce。
hashAlg SHA-256
hashAlg SHA-256
iterationCount 100,000
迭代计数100000
otp-time The time used in the OTP calculation as reported by the OTP token.
otp时间otp令牌报告的otp计算中使用的时间。
8. The client encrypts the PA-OTP-REQUEST within the enc-fast-req of a PA-FX-FAST-REQUEST.
8. 客户端在PA-FX-fast-REQUEST的enc fast req中加密PA-OTP-REQUEST。
9. The client sends an AS-REQ to the KDC containing the PA-FX-FAST-REQUEST within the padata.
9. 客户端向KDC发送AS-REQ，其中包含padata中的PA-FX-FAST-REQUEST。
10. The authentication process now proceeds as with the classic sequence.
10. 认证过程现在与经典序列一样进行。
Author's Address
作者地址
Gareth Richards RSA, The Security Division of EMC RSA House Western Road Bracknell, Berkshire RG12 1RT UK
Gareth Richards RSA，EMC RSA House Western Road Bracknell的安全部门，伯克希尔RG12 1RT英国
EMail: gareth.richards@rsa.com
EMail: gareth.richards@rsa.com