Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 6113 Painless Security
Updates: 4120 L. Zhu
Category: Standards Track Microsoft Corporation
ISSN: 2070-1721 April 2011
Internet Engineering Task Force (IETF) S. Hartman
Request for Comments: 6113 Painless Security
Updates: 4120 L. Zhu
Category: Standards Track Microsoft Corporation
ISSN: 2070-1721 April 2011
A Generalized Framework for Kerberos Pre-Authentication
Kerberos预认证的通用框架
Abstract
摘要
Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a facility called pre-authentication. Pre-authentication mechanisms can use this facility to extend the Kerberos protocol and prove the identity of a principal.
Kerberos是一种协议，用于验证开放网络上主体（例如工作站用户或网络服务器）的身份。Kerberos协议提供了一种称为预身份验证的功能。预身份验证机制可以使用此功能扩展Kerberos协议并证明主体的身份。
This document describes a more formal model for this facility. The model describes what state in the Kerberos request a pre-authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact.
本文档描述了该设施的更正式模型。该模型描述了预身份验证机制可能更改的Kerberos请求中的状态。它还描述了在同一请求中使用的多个预身份验证机制将如何交互。
This document also provides common tools needed by multiple pre-authentication mechanisms. One of these tools is a secure channel between the client and the key distribution center with a reply key strengthening mechanism; this secure channel can be used to protect the authentication exchange and thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm.
本文档还提供了多个预认证机制所需的通用工具。其中一个工具是客户端和密钥分发中心之间的安全通道，具有应答密钥增强机制；此安全通道可用于保护身份验证交换，从而消除脱机字典攻击。使用这些工具，链接多个身份验证机制、利用不同的密钥管理系统或支持新的密钥协商算法相对简单。
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/rfc6113.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6113.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Conventions and Terminology Used in This Document ..........5
1.2. Conformance Requirements ...................................5
2. Model for Pre-Authentication ....................................6
2.1. Information Managed by the Pre-Authentication Model ........7
2.2. Initial Pre-Authentication Required Error ..................9
2.3. Client to KDC .............................................10
2.4. KDC to Client .............................................11
3. Pre-Authentication Facilities ..................................12
3.1. Client Authentication Facility ............................13
3.2. Strengthening Reply Key Facility ..........................13
3.3. Replace Reply Key Facility ................................14
3.4. KDC Authentication Facility ...............................15
4. Requirements for Pre-Authentication Mechanisms .................15
4.1. Protecting Requests/Responses .............................16
5. Tools for Use in Pre-Authentication Mechanisms .................17
5.1. Combining Keys ............................................17
5.2. Managing States for the KDC ...............................19
5.3. Pre-Authentication Set ....................................20
5.4. Definition of Kerberos FAST Padata ........................23
5.4.1. FAST Armors ........................................24
5.4.2. FAST Request .......................................26
5.4.3. FAST Response ......................................30
5.4.4. Authenticated Kerberos Error Messages Using
Kerberos FAST ......................................33
5.4.5. Outer and Inner Requests ...........................34
5.4.6. The Encrypted Challenge FAST Factor ................34
5.5. Authentication Strength Indication ........................36
6. Assigned Constants .............................................37
6.1. New Errors ................................................37
6.2. Key Usage Numbers .........................................37
6.3. Authorization Data Elements ...............................37
6.4. New PA-DATA Types .........................................37
7. IANA Considerations ............................................38
7.1. Pre-Authentication and Typed Data .........................38
7.2. Fast Armor Types ..........................................40
7.3. FAST Options ..............................................40
8. Security Considerations ........................................41
9. Acknowledgements ...............................................42
10. References ....................................................43
10.1. Normative References .....................................43
10.2. Informative References ...................................43
Appendix A. Test Vectors for KRB-FX-CF2 ...........................45
Appendix B. ASN.1 Module ..........................................46
1. Introduction ....................................................4
1.1. Conventions and Terminology Used in This Document ..........5
1.2. Conformance Requirements ...................................5
2. Model for Pre-Authentication ....................................6
2.1. Information Managed by the Pre-Authentication Model ........7
2.2. Initial Pre-Authentication Required Error ..................9
2.3. Client to KDC .............................................10
2.4. KDC to Client .............................................11
3. Pre-Authentication Facilities ..................................12
3.1. Client Authentication Facility ............................13
3.2. Strengthening Reply Key Facility ..........................13
3.3. Replace Reply Key Facility ................................14
3.4. KDC Authentication Facility ...............................15
4. Requirements for Pre-Authentication Mechanisms .................15
4.1. Protecting Requests/Responses .............................16
5. Tools for Use in Pre-Authentication Mechanisms .................17
5.1. Combining Keys ............................................17
5.2. Managing States for the KDC ...............................19
5.3. Pre-Authentication Set ....................................20
5.4. Definition of Kerberos FAST Padata ........................23
5.4.1. FAST Armors ........................................24
5.4.2. FAST Request .......................................26
5.4.3. FAST Response ......................................30
5.4.4. Authenticated Kerberos Error Messages Using
Kerberos FAST ......................................33
5.4.5. Outer and Inner Requests ...........................34
5.4.6. The Encrypted Challenge FAST Factor ................34
5.5. Authentication Strength Indication ........................36
6. Assigned Constants .............................................37
6.1. New Errors ................................................37
6.2. Key Usage Numbers .........................................37
6.3. Authorization Data Elements ...............................37
6.4. New PA-DATA Types .........................................37
7. IANA Considerations ............................................38
7.1. Pre-Authentication and Typed Data .........................38
7.2. Fast Armor Types ..........................................40
7.3. FAST Options ..............................................40
8. Security Considerations ........................................41
9. Acknowledgements ...............................................42
10. References ....................................................43
10.1. Normative References .....................................43
10.2. Informative References ...................................43
Appendix A. Test Vectors for KRB-FX-CF2 ...........................45
Appendix B. ASN.1 Module ..........................................46
The core Kerberos specification [RFC4120] treats pre-authentication data (padata) as an opaque typed hole in the messages to the key distribution center (KDC) that may influence the reply key used to encrypt the KDC reply. This generality has been useful: pre-authentication data is used for a variety of extensions to the protocol, many outside the expectations of the initial designers. However, this generality makes designing more common types of pre-authentication mechanisms difficult. Each mechanism needs to specify how it interacts with other mechanisms. Also, tasks such as combining a key with the long-term secrets or proving the identity of the user are common to multiple mechanisms. Where there are generally well-accepted solutions to these problems, it is desirable to standardize one of these solutions so mechanisms can avoid duplication of work. In other cases, a modular approach to these problems is appropriate. The modular approach will allow new and better solutions to common pre-authentication problems to be used by existing mechanisms as they are developed.
核心Kerberos规范[RFC4120]将预身份验证数据（padata）视为发送给密钥分发中心（KDC）的消息中的不透明类型漏洞，这可能会影响用于加密KDC应答的应答密钥。这种通用性很有用：预认证数据用于协议的各种扩展，许多超出了初始设计者的期望。然而，这种通用性使得设计更常见类型的预认证机制变得困难。每个机制都需要指定它如何与其他机制交互。此外，将密钥与长期秘密相结合或证明用户身份等任务对于多种机制来说都是常见的。如果对这些问题有普遍接受的解决方案，则最好将其中一种解决方案标准化，这样机制就可以避免重复工作。在其他情况下，采用模块化方法解决这些问题是合适的。模块化方法将允许现有机制在开发过程中使用新的、更好的解决常见预认证问题的解决方案。
This document specifies a framework for Kerberos pre-authentication mechanisms. It defines the common set of functions that pre-authentication mechanisms perform as well as how these functions affect the state of the request and reply. In addition, several common tools needed by pre-authentication mechanisms are provided. Unlike [RFC3961], this framework is not complete -- it does not describe all the inputs and outputs for the pre-authentication mechanisms. Pre-authentication mechanism designers should try to be consistent with this framework because doing so will make their mechanisms easier to implement. Kerberos implementations are likely to have plug-in architectures for pre-authentication; such architectures are likely to support mechanisms that follow this framework plus commonly used extensions. This framework also facilitates combining multiple pre-authentication mechanisms, each of which may represent an authentication factor, into a single multi-factor pre-authentication mechanism.
本文档指定了Kerberos预身份验证机制的框架。它定义了预认证机制执行的一组通用函数，以及这些函数如何影响请求和应答的状态。此外，还提供了预认证机制所需的几种常用工具。与[RFC3961]不同，该框架并不完整——它没有描述预认证机制的所有输入和输出。预认证机制设计者应该尝试与此框架保持一致，因为这样做将使其机制更易于实现。Kerberos实现可能具有用于预身份验证的插件体系结构；这种体系结构可能支持遵循此框架的机制以及常用的扩展。该框架还便于将多个预认证机制（每个预认证机制可能代表一个认证因子）组合到单个多因子预认证机制中。
One of these common tools is the flexible authentication secure tunneling (FAST) padata type. FAST provides a protected channel between the client and the key distribution center (KDC), and it can optionally deliver key material used to strengthen the reply key within the protected channel. Based on FAST, pre-authentication mechanisms can extend Kerberos with ease, to support, for example, password-authenticated key exchange (PAKE) protocols with zero-knowledge password proof (ZKPP) [EKE] [IEEE1363.2]. Any pre-authentication mechanism can be encapsulated in the FAST messages as defined in Section 5.4. A pre-authentication type carried within FAST is called a "FAST factor". Creating a FAST factor is the
这些常用工具之一是灵活的身份验证安全隧道（FAST）padata类型。FAST在客户端和密钥分发中心（KDC）之间提供了一个受保护的通道，并且它可以选择性地在受保护的通道内交付用于增强应答密钥的密钥材料。基于FAST，预认证机制可以轻松地扩展Kerberos，以支持例如具有零知识密码证明（ZKPP）[EKE][IEEE1363.2]的密码认证密钥交换（PAKE）协议。任何预认证机制都可以封装在第5.4节定义的FAST消息中。FAST中携带的预认证类型称为“FAST因素”。创造一个快速因素是关键
easiest path to create a new pre-authentication mechanism. FAST factors are significantly easier to analyze from a security standpoint than other pre-authentication mechanisms.
创建新预验证机制的最简单路径。与其他预认证机制相比，从安全角度分析FAST因素要容易得多。
Mechanism designers should design FAST factors, instead of new pre-authentication mechanisms outside of FAST.
机制设计者应该设计FAST因素，而不是FAST之外的新的预认证机制。
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 should be read only after reading the documents describing the Kerberos cryptography framework [RFC3961] and the core Kerberos protocol [RFC4120]. This document may freely use terminology and notation from these documents without reference or further explanation.
只有在阅读了描述Kerberos加密框架[RFC3961]和核心Kerberos协议[RFC4120]的文档后，才能阅读本文档。本文件可自由使用这些文件中的术语和符号，无需参考或进一步解释。
The word padata is used as a shorthand for pre-authentication data.
padata一词用作预认证数据的简写。
A conversation is the set of all authentication messages exchanged between the client and the client's Authentication Service (AS) in order to authenticate the client principal. A conversation as defined here consists of all messages that are necessary to complete the authentication between the client and the client's AS. In the Ticket Granting Service (TGS) exchange, a conversation consists of the request message and the reply message. The term conversation is defined here for both AS and TGS for convenience of discussion. See Section 5.2 for specific rules on the extent of a conversation in the AS-REQ case. Prior to this framework, implementations needed to use implementation-specific heuristics to determine the extent of a conversation.
对话是客户端和客户端的身份验证服务（AS）之间交换的所有身份验证消息的集合，以便对客户端主体进行身份验证。此处定义的对话包括完成客户端和客户端as之间的身份验证所需的所有消息。在票证授予服务（TGS）交换中，会话由请求消息和回复消息组成。为了便于讨论，这里为AS和TGS定义了术语对话。有关AS-REQ情况下对话范围的具体规则，请参见第5.2节。在此框架之前，实现需要使用特定于实现的启发式方法来确定对话的范围。
If the KDC reply in an AS exchange is verified, the KDC is authenticated by the client. In this document, verification of the KDC reply is used as a synonym of authentication of the KDC.
如果验证了AS交换中的KDC应答，则KDC将由客户端进行身份验证。在本文档中，KDC回复的验证被用作KDC身份验证的同义词。
This section summarizes the mandatory-to-implement subset of this specification as a convenience to implementors. The actual requirements and their context are stated in the body of the document.
本节总结了实现本规范子集的必要步骤，以方便实现者。实际需求及其背景在本文件正文中有说明。
Clients conforming to this specification MUST support the padata defined in Section 5.2.
符合本规范的客户必须支持第5.2节中定义的padata。
Conforming implementations MUST support Kerberos FAST padata (Section 5.4). Conforming implementations MUST implement the FX_FAST_ARMOR_AP_REQUEST armor type.
一致性实现必须支持Kerberos FAST padata（第5.4节）。一致性实施必须实施FX\u FAST\u装甲\u AP\u请求装甲类型。
Conforming implementations MUST support the encrypted challenge FAST factor (Section 5.4.6).
一致性实施必须支持加密质询快速因子（第5.4.6节）。
When a Kerberos client wishes to obtain a ticket, it sends an initial Authentication Service (AS) request to the KDC. If pre-authentication is required but not being used, then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error [RFC4120]. Alternatively, if the client knows what pre-authentication to use, it MAY optimize away a round trip and send an initial request with padata included in the initial request. If the client includes the padata computed using the wrong pre-authentication mechanism or incorrect keys, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no indication of what padata should have been included. In that case, the client MUST retry with no padata and examine the error data of the KDC_ERR_PREAUTH_REQUIRED error. If the KDC includes pre-authentication information in the accompanying error data of KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data and then retry.
当Kerberos客户机希望获得票据时，它会向KDC发送初始身份验证服务（AS）请求。如果需要预验证但未使用，则KDC将以KDC_ERR_PREAUTH_required error[RFC4120]响应。或者，如果客户机知道要使用什么样的预身份验证，它可以优化往返，并发送初始请求，初始请求中包含padata。如果客户端包含使用错误的预验证机制或不正确的密钥计算的padata，KDC可能返回KDC_ERR_PREAUTH_FAILED，而不指示应该包含哪些padata。在这种情况下，客户端必须在没有padata的情况下重试，并检查KDC_ERR_PREAUTH_REQUIRED错误的错误数据。如果KDC在附带的KDC_ERR_PREAUTH_FAILED错误数据中包含预身份验证信息，则客户端应处理错误数据，然后重试。
The conventional KDC maintains no state between two requests; subsequent requests may even be processed by a different KDC. On the other hand, the client treats a series of exchanges with KDCs as a single conversation. Each exchange accumulates state and hopefully brings the client closer to a successful authentication.
传统的KDC在两个请求之间不保持状态；后续请求甚至可以由不同的KDC处理。另一方面，客户机将与KDC的一系列交换视为单个对话。每次交换都会累积状态，并有望使客户端更接近成功的身份验证。
These models for state management are in apparent conflict. For many of the simpler pre-authentication scenarios, the client uses one round trip to find out what mechanisms the KDC supports. Then, the next request contains sufficient pre-authentication for the KDC to be able to return a successful reply. For these simple scenarios, the client only sends one request with pre-authentication data and so the conversation is trivial. For more complex conversations, the KDC needs to provide the client with a cookie to include in future requests to capture the current state of the authentication session. Handling of multiple round-trip mechanisms is discussed in Section 5.2.
这些国家管理模式显然存在冲突。对于许多简单的预认证场景，客户机使用一次往返来了解KDC支持哪些机制。然后，下一个请求包含足够的预身份验证，以便KDC能够返回成功的回复。对于这些简单的场景，客户端只发送一个带有预身份验证数据的请求，因此对话很简单。对于更复杂的对话，KDC需要向客户端提供cookie，以便在将来的请求中包含cookie，以捕获身份验证会话的当前状态。第5.2节讨论了多个往返机制的处理。
This framework specifies the behavior of Kerberos pre-authentication mechanisms used to identify users or to modify the reply key used to encrypt the KDC reply. The PA-DATA typed hole may be used to carry extensions to Kerberos that have nothing to do with proving the
此框架指定用于标识用户或修改用于加密KDC应答的应答密钥的Kerberos预身份验证机制的行为。PA-DATA类型的孔可以用来携带对Kerberos的扩展，这些扩展与证明
identity of the user or establishing a reply key. Such extensions are outside the scope of this framework. However, mechanisms that do accomplish these goals should follow this framework.
用户的标识或建立应答密钥。此类扩展超出了本框架的范围。然而，实现这些目标的机制应该遵循这个框架。
This framework specifies the minimum state that a Kerberos implementation needs to maintain while handling a request in order to process pre-authentication. It also specifies how Kerberos implementations process the padata at each step of the AS request process.
此框架指定Kerberos实现在处理请求以处理预身份验证时需要维护的最低状态。它还指定Kerberos实现如何在AS请求过程的每个步骤中处理padata。
The following information is maintained by the client and KDC as each request is being processed:
在处理每个请求时，客户端和KDC都会维护以下信息：
o The reply key used to encrypt the KDC reply
o 用于加密KDC应答的应答密钥
o How strongly the identity of the client has been authenticated
o 客户端的身份验证的强度
o Whether the reply key has been used in this conversation
o 此对话中是否使用了应答密钥
o Whether the reply key has been replaced in this conversation
o 此对话中是否已替换应答密钥
o Whether the origin of the KDC reply can be verified by the client (i.e., whether the KDC is authenticated to the client)
o 客户机是否可以验证KDC回复的来源（即，KDC是否经过客户机的身份验证）
Conceptually, the reply key is initially the long-term key of the principal. However, principals can have multiple long-term keys because of support for multiple encryption types, salts, and string2key parameters. As described in Section 5.2.7.5 of the Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify the client what types of keys are available. Thus, in full generality, the reply key in the pre-authentication model is actually a set of keys. At the beginning of a request, it is initialized to the set of long-term keys advertised in the PA-ETYPE-INFO2 element on the KDC. If multiple reply keys are available, the client chooses which one to use. Thus, the client does not need to treat the reply key as a set. At the beginning of a request, the client picks a key to use.
从概念上讲，应答密钥最初是主体的长期密钥。但是，由于支持多种加密类型、SALT和string2key参数，主体可以具有多个长期密钥。如Kerberos协议[RFC4120]第5.2.7.5节所述，KDC发送PA-ETYPE-INFO2通知客户机哪些类型的密钥可用。因此，在完全通用的情况下，预认证模型中的应答密钥实际上是一组密钥。在请求开始时，它被初始化为KDC上PA-ETYPE-INFO2元素中公布的一组长期密钥。如果有多个应答密钥可用，客户端将选择使用哪一个。因此，客户端不需要将应答密钥视为一个集合。在请求开始时，客户端选择要使用的密钥。
KDC implementations MAY choose to offer only one key in the PA-ETYPE-INFO2 element. Since the KDC already knows the client's list of supported enctypes from the request, no interoperability problems are
KDC实现可以选择在PA-ETYPE-INFO2元素中只提供一个键。由于KDC已经从请求中知道客户端支持的EncType列表，因此不存在互操作性问题
created by choosing a single possible reply key. This way, the KDC implementation avoids the complexity of treating the reply key as a set.
通过选择单个可能的应答键创建。这样，KDC实现避免了将应答密钥作为一个集合处理的复杂性。
When the padata in the request are verified by the KDC, then the client is known to have that key; therefore, the KDC SHOULD pick the same key as the reply key.
当KDC验证请求中的padata时，就知道客户机拥有该密钥；因此，KDC应该选择与应答密钥相同的密钥。
At the beginning of handling a message on both the client and the KDC, the client's identity is not authenticated. A mechanism may indicate that it has successfully authenticated the client's identity. It is useful to keep track of this information on the client in order to know what pre-authentication mechanisms should be used. The KDC needs to keep track of whether the client is authenticated because the primary purpose of pre-authentication is to authenticate the client identity before issuing a ticket. The handling of authentication strength using various authentication mechanisms is discussed in Section 5.5.
在开始处理客户机和KDC上的消息时，客户机的身份没有经过身份验证。一个机制可能表明它已经成功地验证了客户端的身份。跟踪客户机上的这些信息非常有用，以便了解应该使用什么样的预身份验证机制。KDC需要跟踪客户机是否经过身份验证，因为预身份验证的主要目的是在发出票据之前对客户机身份进行身份验证。第5.5节讨论了使用各种身份验证机制处理身份验证强度。
Initially, the reply key is not used. A pre-authentication mechanism that uses the reply key to encrypt or checksum some data in the generation of new keys MUST indicate that the reply key is used. This state is maintained by the client and the KDC to enforce the security requirement stated in Section 3.3 that the reply key SHOULD NOT be replaced after it is used.
最初，不使用应答密钥。在生成新密钥时，使用应答密钥对某些数据进行加密或校验和的预身份验证机制必须表明使用了应答密钥。该状态由客户端和KDC维护，以强制执行第3.3节中规定的安全要求，即应答密钥在使用后不应被替换。
Initially, the reply key is not replaced. If a mechanism implements the Replace Reply Key facility discussed in Section 3.3, then the state MUST be updated to indicate that the reply key has been replaced. Once the reply key has been replaced, knowledge of the reply key is insufficient to authenticate the client. The reply key is marked as replaced in exactly the same situations as the KDC reply is marked as not being verified to the client principal. However, while mechanisms can verify the KDC reply to the client, once the reply key is replaced, then the reply key remains replaced for the remainder of the conversation.
最初，应答密钥不会被替换。如果机制实现了第3.3节中讨论的替换应答密钥功能，则必须更新状态以指示应答密钥已被替换。一旦替换了应答密钥，对应答密钥的了解就不足以对客户端进行身份验证。在与KDC应答被标记为未向客户端主体验证的情况完全相同的情况下，应答密钥被标记为已替换。然而，尽管机制可以验证KDC对客户端的回复，但一旦替换了回复密钥，则在会话的其余部分，回复密钥仍会被替换。
Without pre-authentication, the client knows that the KDC reply is authentic and has not been modified because it is encrypted in a long-term key of the client. Only the KDC and the client know that key. So, at the start of a conversation, the KDC reply is presumed to be verified using the client's long-term key. It should be noted that in this document, verifying the KDC reply means authenticating the KDC, and these phrases are used interchangeably. Any pre-authentication mechanism that sets a new reply key not based on the principal's long-term secret MUST either verify the KDC reply some other way or indicate that the reply is not verified. If a mechanism indicates that the reply is not verified, then the client
如果没有预身份验证，客户机知道KDC回复是真实的，并且没有被修改，因为它是在客户机的长期密钥中加密的。只有KDC和客户机知道该密钥。因此，在对话开始时，KDC回复被假定为使用客户端的长期密钥进行验证。应该注意，在本文档中，验证KDC应答意味着验证KDC，并且这些短语可以互换使用。任何不基于主体的长期机密设置新回复密钥的预认证机制都必须以其他方式验证KDC回复，或者指示未验证回复。如果某个机制指示未验证回复，则客户端
implementation MUST return an error unless a subsequent mechanism verifies the reply. The KDC needs to track this state so it can avoid generating a reply that is not verified.
除非后续机制验证回复，否则实现必须返回错误。KDC需要跟踪此状态，以避免生成未经验证的回复。
In this specification, KDC verification/authentication refers to the level of authentication of the KDC to the client provided by RFC 4120. There is a stronger form of KDC verification that, while sometimes important in Kerberos deployments, is not addressed in this specification: the typical Kerberos request does not provide a way for the client machine to know that it is talking to the correct KDC. Someone who can inject packets into the network between the client machine and the KDC and who knows the password that the user will give to the client machine can generate a KDC reply that will decrypt properly. So, if the client machine needs to authenticate that the user is in fact the named principal, then the client machine needs to do a TGS request for itself as a service. Some pre-authentication mechanisms may provide a way for the client machine to authenticate the KDC. Examples of this include signing the reply that can be verified using a well-known public key or providing a ticket for the client machine as a service.
在本规范中，KDC验证/身份验证是指由RFC 4120提供的KDC对客户端的身份验证级别。有一种更强大的KDC验证形式，虽然在Kerberos部署中有时很重要，但在本规范中没有提到：典型的Kerberos请求不能让客户机知道它正在与正确的KDC通信。能够将数据包注入客户机和KDC之间的网络，并且知道用户将给客户机的密码的人可以生成一个KDC回复，该回复将正确解密。因此，如果客户机需要验证用户实际上是命名主体，那么客户机需要将自身作为服务执行TGS请求。一些预认证机制可以为客户机提供对KDC进行认证的方法。这方面的示例包括对可以使用已知公钥验证的回复进行签名，或者为客户端计算机提供票证作为服务。
Typically, a client starts a conversation by sending an initial request with no pre-authentication. If the KDC requires pre-authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message. After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code, the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED (defined in Section 5.2) for pre-authentication configurations that use multi-round-trip mechanisms; see Section 2.4 for details of that case.
通常，客户机通过发送初始请求启动对话，而无需预验证。如果KDC需要预身份验证，则返回KDC_ERR_PREAUTH_REQUIRED消息。在第一次回复KDC_ERR_PREAUTH_REQUIRED错误代码后，KDC返回错误代码KDC_ERR_MORE_PREAUTH_DATA_REQUIRED（在第5.2节中定义），用于使用多往返机制的预认证配置；有关该情况的详细信息，请参见第2.4节。
The KDC needs to choose which mechanisms to offer the client. The client needs to be able to choose what mechanisms to use from the first message. For example, consider the KDC that will accept mechanism A followed by mechanism B or alternatively the single mechanism C. A client that supports A and C needs to know that it should not bother trying A.
KDC需要选择向客户机提供哪些机制。客户机需要能够从第一条消息中选择要使用的机制。例如，考虑KDC将接受机制A，接着是机制B，或者是单个机制C。支持A和C的客户端需要知道它不应该费心尝试A。
Mechanisms can either be sufficient on their own or can be part of an authentication set -- a group of mechanisms that all need to successfully complete in order to authenticate a client. Some mechanisms may only be useful in authentication sets; others may be useful alone or in authentication sets. For the second group of mechanisms, KDC policy dictates whether the mechanism will be part of an authentication set, offered alone, or both. For each mechanism that is offered alone (even if it is also offered in an authentication set), the KDC includes the pre-authentication type ID
机制本身就足够了，也可以是身份验证集的一部分——一组机制，所有这些机制都需要成功完成才能对客户端进行身份验证。某些机制可能仅在身份验证集中有用；另一些可能单独或在身份验证集中有用。对于第二组机制，KDC策略规定该机制是作为身份验证集的一部分、单独提供还是同时提供。对于单独提供的每个机制（即使它也在身份验证集中提供），KDC包括预身份验证类型ID
of the mechanism in the padata sequence returned in the KDC_ERR_PREAUTH_REQUIRED error. Mechanisms that are only offered as part of an authentication set are not directly represented in the padata sequence returned in the KDC_ERR_PREAUTH_REQUIRED error, although they are represented in the PA-AUTHENTICATION-SET sequence.
KDC_ERR_PREAUTH_REQUIRED error中返回的padata序列中的机制。仅作为身份验证集的一部分提供的机制不会直接在KDC_ERR_PREAUTH_REQUIRED error中返回的padata序列中表示，尽管它们在PA-authentication-set序列中表示。
The KDC SHOULD NOT send data that is encrypted in the long-term password-based key of the principal. Doing so has the same security exposures as the Kerberos protocol without pre-authentication. There are few situations where the KDC needs to expose cipher text encrypted in a weak key before the client has proven knowledge of that key, and where pre-authentication is desirable.
KDC不应发送在主体的长期基于密码的密钥中加密的数据。这样做与Kerberos协议具有相同的安全性暴露，而无需预身份验证。在很少的情况下，KDC需要在客户机证明知道弱密钥之前公开加密在弱密钥中的密码文本，并且需要进行预认证。
This description assumes that a client has already received a KDC_ERR_PREAUTH_REQUIRED from the KDC. If the client performs optimistic pre-authentication, then the client needs to guess values for the information it would normally receive from that error response or use cached information obtained in prior interactions with the KDC.
此描述假设客户机已从KDC接收到所需的KDC_ERR_PREAUTH_。如果客户端执行乐观预身份验证，那么客户端需要猜测它通常从错误响应中接收的信息的值，或者使用在先前与KDC交互中获得的缓存信息。
The client starts by initializing the pre-authentication state as specified. It then processes the padata in the KDC_ERR_PREAUTH_REQUIRED.
客户端通过初始化指定的预身份验证状态启动。然后，它处理所需KDC_ERR_PREAUTH_中的padata。
When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the client MAY ignore any padata it chooses unless doing so violates a specification to which the client conforms. Clients conforming to this specification MUST NOT ignore the padata defined in Section 5.2. Clients SHOULD choose one authentication set or mechanism that could lead to authenticating the user and ignore other such mechanisms. However, this rule does not affect the processing of padata unrelated to this framework; clients SHOULD process such padata normally. Since the list of mechanisms offered by the KDC is in the decreasing preference order, clients typically choose the first mechanism or authentication set that the client can usefully perform. If a client chooses to ignore padata, it MUST NOT process the padata, allow the padata to affect the pre-authentication state, or respond to the padata.
在处理对KDC_ERR_PREAUTH_REQUIRED的响应时，客户机可以忽略其选择的任何padata，除非这样做违反了客户机遵守的规范。符合本规范的客户不得忽略第5.2节中定义的padata。客户端应选择一个可能导致对用户进行身份验证的身份验证集或机制，而忽略其他此类机制。但是，此规则不影响与此框架无关的padata的处理；客户应正常处理此类padata。由于KDC提供的机制列表的优先顺序是递减的，因此客户机通常选择客户机可以有效执行的第一个机制或身份验证集。如果客户端选择忽略padata，则它不得处理padata、允许padata影响预验证状态或响应padata。
For each instance of padata the client chooses to process, the client processes the padata and modifies the pre-authentication state as required by that mechanism.
对于客户端选择处理的每个padata实例，客户端处理padata并根据该机制的要求修改预验证状态。
After processing the padata in the KDC error, the client generates a new request. It processes the pre-authentication mechanisms in the order in which they will appear in the next request, updating the state as appropriate. The request is sent when it is complete.
在处理KDC错误中的padata后，客户机生成一个新请求。它按照预认证机制在下一个请求中出现的顺序处理预认证机制，并根据需要更新状态。请求完成后发送。
When a KDC receives an AS request from a client, it needs to determine whether it will respond with an error or an AS reply. There are many causes for an error to be generated that have nothing to do with pre-authentication; they are discussed in the core Kerberos specification.
当KDC从客户端接收到AS请求时，它需要确定是以错误响应还是以AS应答响应。产生错误的原因很多，与预认证无关；核心Kerberos规范中讨论了它们。
From the standpoint of evaluating the pre-authentication, the KDC first starts by initializing the pre-authentication state. If a PA-FX-COOKIE pre-authentication data item is present, it is processed first; see Section 5.2 for a definition. It then processes the padata in the request. As mentioned in Section 2.3, the KDC MAY ignore padata that are inappropriate for the configuration and MUST ignore padata of an unknown type. The KDC MUST NOT ignore padata of types used in previous messages. For example, if a KDC issues a KDC_ERR_PREAUTH_REQUIRED error including padata of type x, then the KDC cannot ignore padata of type x received in an AS-REQ message from the client.
从评估预认证的角度来看，KDC首先初始化预认证状态。如果存在PA-FX-COOKIE预认证数据项，则首先对其进行处理；定义见第5.2节。然后处理请求中的padata。如第2.3节所述，KDC可以忽略不适合配置的padata，并且必须忽略未知类型的padata。KDC不能忽略以前消息中使用的类型的padata。例如，如果KDC发出KDC_ERR_PREAUTH_REQUIRED错误，包括x类型的padata，则KDC不能忽略从客户端AS-REQ消息中接收到的x类型的padata。
At this point, the KDC decides whether it will issue an error or a reply. Typically, a KDC will issue a reply if the client's identity has been authenticated to a sufficient degree.
此时，KDC决定是发出错误还是发出回复。通常，如果客户机的身份已被验证到足够的程度，KDC将发出回复。
In the case of a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error, the KDC first starts by initializing the pre-authentication state. Then, it processes any padata in the client's request in the order provided by the client. Mechanisms that are not understood by the KDC are ignored. Next, it generates padata for the error response, modifying the pre-authentication state appropriately as each mechanism is processed. The KDC chooses the order in which it will generate padata (and thus the order of padata in the response), but it needs to modify the pre-authentication state consistently with the choice of order. For example, if some mechanism establishes an authenticated client identity, then the subsequent mechanisms in the generated response receive this state as input. After the padata are generated, the error response is sent. Typically, the errors with the code KDC_ERR_MORE_PREAUTH_DATA_REQUIRED in a conversation will include KDC state, as discussed in Section 5.2.
在KDC_ERR_MORE_PREAUTH_DATA_REQUIRED错误的情况下，KDC首先初始化预身份验证状态。然后，它按照客户机提供的顺序处理客户机请求中的任何padata。KDC不理解的机制被忽略。接下来，它为错误响应生成padata，在处理每个机制时适当地修改预认证状态。KDC选择生成padata的顺序（以及响应中padata的顺序），但它需要根据顺序的选择一致地修改预认证状态。例如，如果某个机制建立了经过身份验证的客户机标识，那么生成的响应中的后续机制将接收该状态作为输入。生成padata后，将发送错误响应。通常，会话中所需的代码KDC_ERR_MORE_PREAUTH_DATA_的错误将包括KDC状态，如第5.2节所述。
To generate a final reply, the KDC generates the padata modifying the pre-authentication state as necessary. Then, it generates the final response, encrypting it in the current pre-authentication reply key.
为了生成最终回复，KDC生成padata，并根据需要修改预认证状态。然后，它生成最终响应，在当前预认证回复密钥中对其进行加密。
Pre-authentication mechanisms can be thought of as providing various conceptual facilities. This serves two useful purposes. First, mechanism authors can choose only to solve one specific small problem. It is often useful for a mechanism designed to offer key management not to directly provide client authentication but instead to allow one or more other mechanisms to handle this need. Secondly, thinking about the abstract services that a mechanism provides yields a minimum set of security requirements that all mechanisms providing that facility must meet. These security requirements are not complete; mechanisms will have additional security requirements based on the specific protocol they employ.
预认证机制可以被认为是提供了各种概念设施。这有两个有用的目的。首先，机制作者只能选择解决一个特定的小问题。设计用于提供密钥管理的机制通常不直接提供客户端身份验证，而是允许一个或多个其他机制处理此需求。其次，考虑一个机制提供的抽象服务会产生一组最小的安全需求，所有提供该功能的机制都必须满足这些需求。这些安全要求不完整；机制将根据其使用的特定协议有额外的安全要求。
A mechanism is not constrained to only offering one of these facilities. While such mechanisms can be designed and are sometimes useful, many pre-authentication mechanisms implement several facilities. It is often easier to construct a secure, simple solution by combining multiple facilities in a single mechanism than by solving the problem in full generality. Even when mechanisms provide multiple facilities, they need to meet the security requirements for all the facilities they provide. If the FAST factor approach is used, it is likely that one or a small number of facilities can be provided by a single mechanism without complicating the security analysis.
机制不限于仅提供其中一种设施。虽然这种机制可以设计，有时也很有用，但许多预认证机制实现了几种功能。通过将多个功能组合到一个机制中来构造安全、简单的解决方案通常比通过完全通用性来解决问题更容易。即使机制提供多个设施，它们也需要满足它们提供的所有设施的安全要求。如果使用快速因素方法，则可能通过单一机制提供一个或少数设施，而不会使安全分析复杂化。
According to Kerberos extensibility rules (Section 1.5 of the Kerberos specification [RFC4120]), an extension MUST NOT change the semantics of a message unless a recipient is known to understand that extension. Because a client does not know that the KDC supports a particular pre-authentication mechanism when it sends an initial request, a pre-authentication mechanism MUST NOT change the semantics of the request in a way that will break a KDC that does not understand that mechanism. Similarly, KDCs MUST NOT send messages to clients that affect the core semantics unless the client has indicated support for the message.
根据Kerberos可扩展性规则（Kerberos规范[RFC4120]第1.5节），除非已知收件人理解该扩展，否则扩展不得更改消息的语义。由于客户端在发送初始请求时不知道KDC支持特定的预身份验证机制，因此预身份验证机制不得以破坏不理解该机制的KDC的方式更改请求的语义。类似地，KDC不得向影响核心语义的客户机发送消息，除非客户机表示支持该消息。
The only state in this model that would break the interpretation of a message is changing the expected reply key. If one mechanism changed the reply key and a later mechanism used that reply key, then a KDC that interpreted the second mechanism but not the first would fail to interpret the request correctly. In order to avoid this problem, extensions that change core semantics are typically divided into two parts. The first part proposes a change to the core semantic -- for example, proposes a new reply key. The second part acknowledges that the extension is understood and that the change takes effect. Section 3.2 discusses how to design mechanisms that modify the reply key to be split into a proposal and acceptance without requiring
此模型中唯一会破坏消息解释的状态是更改预期的应答密钥。如果一种机制更改了应答键，而后来的机制使用了该应答键，那么解释第二种机制而不是第一种机制的KDC将无法正确解释请求。为了避免这个问题，改变核心语义的扩展通常分为两部分。第一部分提出了对核心语义的修改——例如，提出了一个新的应答键。第二部分承认扩展已被理解，变更已生效。第3.2节讨论了如何设计机制来修改回复密钥，以便在不需要任何请求的情况下将其拆分为提案和接受
additional round trips to use the new reply key in subsequent pre-authentication. Other changes in the state described in Section 2.1 can safely be ignored by a KDC that does not understand a mechanism. Mechanisms that modify the behavior of the request outside the scope of this framework need to carefully consider the Kerberos extensibility rules to avoid similar problems.
在后续预验证中使用新应答密钥的额外往返。不了解机制的KDC可以安全地忽略第2.1节中描述的其他状态变化。在该框架的范围之外修改请求行为的机制需要仔细考虑Kerberos扩展性规则，以避免类似的问题。
The Client Authentication facility proves the identity of a user to the KDC before a ticket is issued. Examples of mechanisms implementing this facility include the encrypted timestamp facility, defined in Section 5.2.7.2 of the Kerberos specification [RFC4120]. Mechanisms that provide this facility are expected to mark the client as authenticated.
客户端身份验证功能在发出票据之前向KDC证明用户的身份。实现此功能的机制示例包括加密时间戳功能，该功能在Kerberos规范[RFC4120]第5.2.7.2节中定义。提供此功能的机制预期会将客户端标记为已验证。
Mechanisms implementing this facility SHOULD require the client to prove knowledge of the reply key before transmitting a successful KDC reply. Otherwise, an attacker can intercept the pre-authentication exchange and get a reply to attack. One way of proving the client knows the reply key is to implement the Replace Reply Key facility along with this facility. The Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) mechanism [RFC4556] implements Client Authentication alongside Replace Reply Key.
实现此功能的机制应该要求客户端在传输成功的KDC应答之前证明知道应答密钥。否则，攻击者可以拦截预身份验证交换并获得攻击回复。证明客户机知道应答密钥的一种方法是与此功能一起实现Replace reply key功能。Kerberos（PKINIT）机制中用于初始身份验证的公钥加密[RFC4556]在替换应答密钥的同时实现客户端身份验证。
If the reply key has been replaced, then mechanisms such as encrypted-timestamp that rely on knowledge of the reply key to authenticate the client MUST NOT be used.
如果应答密钥已被替换，则不得使用依赖应答密钥知识对客户端进行身份验证的加密时间戳等机制。
Particularly when dealing with keys based on passwords, it is desirable to increase the strength of the key by adding additional secrets to it. Examples of sources of additional secrets include the results of a Diffie-Hellman key exchange or key bits from the output of a smart card [KRB-WG.SAM]. Typically, these additional secrets can be first combined with the existing reply key and then converted to a protocol key using tools defined in Section 5.1.
特别是在处理基于密码的密钥时，希望通过向密钥添加额外的秘密来增加密钥的强度。其他秘密来源的示例包括Diffie-Hellman密钥交换的结果或智能卡输出的密钥位[KRB-WG.SAM]。通常，这些额外的秘密可以首先与现有的应答密钥组合，然后使用第5.1节中定义的工具转换为协议密钥。
Typically, a mechanism implementing this facility will know that the other side of the exchange supports the facility before the reply key is changed. For example, a mechanism might need to learn the certificate for a KDC before encrypting a new key in the public key belonging to that certificate. However, if a mechanism implementing this facility wishes to modify the reply key before knowing that the other party in the exchange supports the mechanism, it proposes modifying the reply key. The other party then includes a message indicating that the proposal is accepted if it is understood and
通常，实现此功能的机制在更改应答密钥之前会知道exchange的另一端支持此功能。例如，一种机制可能需要先学习KDC的证书，然后再加密属于该证书的公钥中的新密钥。但是，如果实现此功能的机制希望在知道exchange中的另一方支持该机制之前修改回复密钥，则会建议修改回复密钥。然后，另一方包括一条信息，表明如果该提案被理解和接受，则该提案被接受
meets policy. In many cases, it is desirable to use the new reply key for client authentication and for other facilities. Waiting for the other party to accept the proposal and actually modify the reply key state would add an additional round trip to the exchange. Instead, mechanism designers are encouraged to include a typed hole for additional padata in the message that proposes the reply key change. The padata included in the typed hole are generated assuming the new reply key. If the other party accepts the proposal, then these padata are considered as an inner level. As with the outer level, one authentication set or mechanism is typically chosen for client authentication, along with auxiliary mechanisms such as KDC cookies, and other mechanisms are ignored. When mechanisms include such a container, the hint provided for use in authentication sets (as defined in Section 5.3) MUST contain a sequence of inner mechanisms along with hints for those mechanisms. The party generating the proposal can determine whether the padata were processed based on whether the proposal for the reply key is accepted.
符合政策。在许多情况下，希望将新的应答密钥用于客户端身份验证和其他设施。等待另一方接受建议并实际修改回复键状态将为交换增加额外的往返。相反，建议机制设计者在建议应答密钥更改的消息中包含一个用于额外padata的键入孔。键入的孔中包含的padata是使用新的应答键生成的。如果另一方接受该提议，则这些padata将被视为内部级别。与外部级别一样，通常为客户端身份验证选择一个身份验证集或机制，以及辅助机制（如KDC Cookie），而忽略其他机制。当机制包括这样一个容器时，为在身份验证集中使用而提供的提示（如第5.3节所定义）必须包含一系列内部机制以及这些机制的提示。生成建议的一方可以根据回复密钥的建议是否被接受来确定是否处理了padata。
The specific formats of the proposal message, including where padata are included, is a matter for the mechanism specification. Similarly, the format of the message accepting the proposal is mechanism specific.
建议消息的具体格式（包括padata的位置）由机制规范决定。同样，接受提议的消息的格式是特定于机制的。
Mechanisms implementing this facility and including a typed hole for additional padata MUST checksum that padata using a keyed checksum or encrypt the padata. This requirement protects against modification of the contents of the typed hole. By modifying these contents, an attacker might be able to choose which mechanism is used to authenticate the client, or to convince a party to provide text encrypted in a key that the attacker had manipulated. It is important that mechanisms strengthen the reply key enough that using it to checksum padata is appropriate.
实现此功能并包含用于附加padata的键入孔的机制必须使用键控校验和对padata进行校验和或加密padata。此要求可防止修改类型孔的内容。通过修改这些内容，攻击者可以选择使用哪种机制对客户端进行身份验证，或者说服一方提供加密的文本，该文本是攻击者操纵的密钥。重要的是，机制应充分加强应答密钥，以便使用它对padata进行校验和。
The Replace Reply Key facility replaces the key in which a successful AS reply will be encrypted. This facility can only be used in cases where knowledge of the reply key is not used to authenticate the client. The new reply key MUST be communicated to the client and the KDC in a secure manner. This facility MUST NOT be used if there can be a man-in-the-middle between the client and the KDC. Mechanisms implementing this facility MUST mark the reply key as replaced in the pre-authentication state. Mechanisms implementing this facility MUST either provide a mechanism to verify the KDC reply to the client or mark the reply as unverified in the pre-authentication state. Mechanisms implementing this facility SHOULD NOT be used if a previous mechanism has used the reply key.
“替换答复密钥”功能将替换成功的AS答复将在其中加密的密钥。此功能只能在应答密钥的知识不用于对客户端进行身份验证的情况下使用。新的应答密钥必须以安全的方式传递给客户端和KDC。如果客户机和KDC之间可能有人在中间，则不得使用此功能。实现此功能的机制必须在预身份验证状态中将应答密钥标记为已替换。实现此功能的机制必须提供验证KDC对客户端的回复的机制，或者在预身份验证状态中将回复标记为未验证。如果以前的机制使用了应答密钥，则不应使用实现此功能的机制。
As with the Strengthening Reply Key facility, Kerberos extensibility rules require that the reply key not be changed unless both sides of the exchange understand the extension. In the case of this facility, it will likely be the case for both sides to know that the facility is available by the time that the new key is available to be used. However, mechanism designers can use a container for padata in a proposal message, as discussed in Section 3.2, if appropriate.
与增强应答密钥功能一样，Kerberos扩展性规则要求除非交换双方都理解该扩展，否则不得更改应答密钥。在该设施的情况下，双方可能会在新钥匙可用时知道该设施可用。但是，如第3.2节所述，如果合适，机制设计者可以在提案消息中使用padata容器。
This facility verifies that the reply comes from the expected KDC. In traditional Kerberos, the KDC and the client share a key, so if the KDC reply can be decrypted, then the client knows that a trusted KDC responded. Note that the client machine cannot trust the client unless the machine is presented with a service ticket for it (typically, the machine can retrieve this ticket by itself). However, if the reply key is replaced, some mechanism is required to verify the KDC. Pre-authentication mechanisms providing this facility allow a client to determine that the expected KDC has responded even after the reply key is replaced. They mark the pre-authentication state as having been verified.
此工具验证回复是否来自预期的KDC。在传统的Kerberos中，KDC和客户机共享一个密钥，因此如果KDC应答可以被解密，那么客户机就知道受信任的KDC应答了。请注意，除非向客户机提供服务票证，否则客户机无法信任客户机（通常，机器可以自己检索此票证）。但是，如果替换了应答密钥，则需要某种机制来验证KDC。提供此功能的预身份验证机制允许客户端确定预期KDC已响应，即使在替换应答密钥之后也是如此。它们将预认证状态标记为已验证。
This section lists requirements for specifications of pre-authentication mechanisms.
本节列出了预认证机制规范的要求。
For each message in the pre-authentication mechanism, the specification describes the pa-type value to be used and the contents of the message. The processing of the message by the sender and recipient is also specified. This specification needs to include all modifications to the pre-authentication state.
对于预认证机制中的每条消息，规范描述了要使用的pa类型值和消息的内容。还指定了发件人和收件人对邮件的处理。本规范需要包括对预认证状态的所有修改。
Generally, mechanisms have a message that can be sent in the error data of the KDC_ERR_PREAUTH_REQUIRED error message or in an authentication set. If the client needs information, such as trusted certificate authorities, in order to determine if it can use the mechanism, then this information should be in that message. In addition, such mechanisms should also define a pa-hint to be included in authentication sets. Often, the same information included in the padata-value is appropriate to include in the pa-hint (as defined in Section 5.3).
通常，机制有一条消息，可以在KDC_ERR_PREAUTH_REQUIRED错误消息的错误数据中或在身份验证集中发送。如果客户机需要信息（如可信证书颁发机构）以确定是否可以使用该机制，则该信息应包含在该消息中。此外，此类机制还应定义要包含在身份验证集中的pa提示。通常，padata值中包含的相同信息适合包含在pa提示中（定义见第5.3节）。
In order to ease security analysis, the mechanism specification should describe what facilities from this document are offered by the mechanism. For each facility, the security considerations section of the mechanism specification should show that the security
为了便于安全性分析，机制规范应该描述该机制提供了本文档中的哪些功能。对于每个设施，机制规范的安全注意事项部分应显示
requirements of that facility are met. This requirement is applicable to any FAST factor that provides authentication information.
满足该设施的要求。此要求适用于提供身份验证信息的任何FAST因素。
Significant problems have resulted in the specification of Kerberos protocols because much of the KDC exchange is not protected against alteration. The security considerations section should discuss unauthenticated plaintext attacks. It should either show that plaintext is protected or discuss what harm an attacker could do by modifying the plaintext. It is generally acceptable for an attacker to be able to cause the protocol negotiation to fail by modifying plaintext. More significant attacks should be evaluated carefully.
Kerberos协议的规范中出现了一些重大问题，因为大部分KDC交换都没有得到保护以防止更改。安全注意事项部分应讨论未经验证的明文攻击。它应该显示明文受到保护，或者讨论攻击者通过修改明文可能造成的伤害。攻击者通过修改明文导致协议协商失败通常是可以接受的。应仔细评估更重要的攻击。
As discussed in Section 5.2, there is no guarantee that a client will use the same KDCs for all messages in a conversation. The mechanism specification needs to show why the mechanism is secure in this situation. The hardest problem to deal with, especially for challenge/response mechanisms is to make sure that the same response cannot be replayed against two KDCs while allowing the client to talk to any KDC.
如第5.2节所述，不能保证客户机会对会话中的所有消息使用相同的KDC。机制规范需要说明为什么机制在这种情况下是安全的。最难处理的问题，特别是对于质询/响应机制，是确保在允许客户端与任何KDC对话的同时，不能对两个KDC重放相同的响应。
Mechanism designers SHOULD protect cleartext portions of pre-authentication data. Various denial-of-service attacks and downgrade attacks against Kerberos are possible unless plaintexts are somehow protected against modification. An early design goal of Kerberos Version 5 [RFC4120] was to avoid encrypting more of the authentication exchange than was required. (Version 4 doubly-encrypted the encrypted part of a ticket in a KDC reply, for example). This minimization of encryption reduces the load on the KDC and busy servers. Also, during the initial design of Version 5, the existence of legal restrictions on the export of cryptography made it desirable to minimize of the number of uses of encryption in the protocol. Unfortunately, performing this minimization created numerous instances of unauthenticated security-relevant plaintext fields.
机制设计者应该保护预认证数据的明文部分。除非明文受到某种程度的保护以防修改，否则可能会发生针对Kerberos的各种拒绝服务攻击和降级攻击。Kerberos版本5[RFC4120]的早期设计目标是避免加密比所需更多的身份验证交换。（例如，版本4对KDC回复中票据的加密部分进行双重加密）。这种加密最小化减少了KDC和繁忙服务器上的负载。此外，在第5版的初步设计期间，由于存在对密码输出的法律限制，因此希望尽量减少协议中使用加密的次数。不幸的是，执行此最小化创建了许多未经验证的安全相关明文字段的实例。
Mechanisms MUST guarantee that by the end of a successful authentication exchange, both the client and the KDC have verified all the plaintext sent by the other party. If there is more than one round trip in the exchange, mechanisms MUST additionally guarantee that no individual messages were reordered or replayed from a previous exchange. Strategies for accomplishing this include using message authentication codes (MACs) to protect the plaintext as it is sent including some form of nonce or cookie to allow for the chaining of state from one message to the next or exchanging a MAC of the entire conversation after a key is established.
机制必须保证在成功的身份验证交换结束时，客户端和KDC都已验证了另一方发送的所有明文。如果在交换中有多个往返，则机制还必须保证没有单个消息从以前的交换重新排序或重播。实现这一点的策略包括使用消息认证码（MAC）在发送明文时保护明文，包括某种形式的nonce或cookie，以允许将状态从一条消息链接到下一条消息，或在建立密钥后交换整个会话的MAC。
Mechanism designers need to provide a strategy for updating cryptographic algorithms, such as defining a new pre-authentication type for each algorithm or taking advantage of the client's list of supported RFC 3961 encryption types to indicate the client's support for cryptographic algorithms.
机制设计者需要提供更新密码算法的策略，例如为每个算法定义新的预认证类型，或者利用客户端支持的RFC 3961加密类型列表来指示客户端对密码算法的支持。
Primitives defined in [RFC3961] are RECOMMENDED for integrity protection and confidentiality. Mechanisms based on these primitives are crypto-agile as the result of using [RFC3961] along with [RFC4120]. The advantage afforded by crypto-agility is the ability to incrementally deploy a fix specific to a particular algorithm thus avoid a multi-year standardization and deployment cycle, when real attacks do arise against that algorithm.
建议使用[RFC3961]中定义的原语进行完整性保护和保密。由于使用[RFC3961]和[RFC4120]，基于这些原语的机制是加密灵活的。加密灵活性提供的优势是能够增量部署特定于特定算法的修复程序，从而避免了多年的标准化和部署周期（当针对该算法的实际攻击确实发生时）。
Note that data used by FAST factors (defined in Section 5.4) is encrypted in a protected channel; thus, they do not share the un-authenticated-text issues with mechanisms designed as full-blown pre-authentication mechanisms.
注意，FAST factors（第5.4节中定义）使用的数据在受保护信道中加密；因此，它们不会与设计为成熟的预认证机制的机制共享未经认证的文本问题。
This section describes common tools needed by multiple pre-authentication mechanisms. By using these tools, mechanism designers can use a modular approach to specify mechanism details and ease security analysis.
本节介绍多个预认证机制所需的常用工具。通过使用这些工具，机制设计者可以使用模块化方法来指定机制细节并简化安全性分析。
Frequently, a weak key needs to be combined with a stronger key before use. For example, passwords are typically limited in size and insufficiently random: therefore, it is desirable to increase the strength of the keys based on passwords by adding additional secrets. An additional source of secrecy may come from hardware tokens.
通常，使用前需要将弱密钥与强密钥组合。例如，密码的大小通常是有限的，随机性不够：因此，希望通过添加额外的秘密来增加基于密码的密钥的强度。另一个保密来源可能来自硬件令牌。
This section provides standard ways to combine two keys into one.
本节提供了将两个键组合为一个键的标准方法。
KRB-FX-CF1() is defined to combine two passphrases.
KRB-FX-CF1（）定义为组合两个密码短语。
KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
KRB-FX-CF1(x, y) := x || y
KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string)
KRB-FX-CF1(x, y) := x || y
Where || denotes concatenation. The strength of the final key is roughly the total strength of the individual keys being combined, assuming that the string_to_key() function [RFC3961] uses all its input evenly.
其中| |表示串联。假设string_to_key（）函数[RFC3961]均匀地使用其所有输入，则最后一个键的强度大致等于被组合的各个键的总强度。
An example usage of KRB-FX-CF1() is when a device provides random but short passwords, the password is often combined with a personal identification number (PIN). The password and the PIN can be combined using KRB-FX-CF1().
KRB-FX-CF1（）的一个示例用法是，当设备提供随机但简短的密码时，密码通常与个人识别码（PIN）结合使用。可以使用KRB-FX-CF1（）组合密码和PIN。
KRB-FX-CF2() combines two protocol keys based on the pseudo-random() function defined in [RFC3961].
KRB-FX-CF2（）基于[RFC3961]中定义的伪随机（）函数组合两个协议密钥。
Given two input keys, K1 and K2, where K1 and K2 can be of two different enctypes, the output key of KRB-FX-CF2(), K3, is derived as follows:
给定两个输入键K1和K2，其中K1和K2可以是两种不同的类型，KRB-FX-CF2（）的输出键K3的推导如下：
KRB-FX-CF2(protocol key, protocol key, octet string, octet string) -> (protocol key)
KRB-FX-CF2（协议密钥、协议密钥、八位字节字符串、八位字节字符串）->（协议密钥）
PRF+(K1, pepper1) -> octet-string-1
PRF+(K2, pepper2) -> octet-string-2
KRB-FX-CF2(K1, K2, pepper1, pepper2) :=
random-to-key(octet-string-1 ^ octet-string-2)
PRF+(K1, pepper1) -> octet-string-1
PRF+(K2, pepper2) -> octet-string-2
KRB-FX-CF2(K1, K2, pepper1, pepper2) :=
random-to-key(octet-string-1 ^ octet-string-2)
Where ^ denotes the exclusive-OR operation. PRF+() is defined as follows:
其中^表示异或运算。PRF+（）的定义如下：
PRF+(protocol key, octet string) -> (octet string)
PRF+(protocol key, octet string) -> (octet string)
PRF+(key, shared-info) := pseudo-random( key, 1 || shared-info ) || pseudo-random( key, 2 || shared-info ) || pseudo-random( key, 3 || shared-info ) || ...
PRF+（键，共享信息）：=伪随机（键，1 | |共享信息）| |伪随机（键，2 | |共享信息）| |伪随机（键，3 | |共享信息）|。。。
Here the counter value 1, 2, 3, and so on are encoded as a one-octet integer. The pseudo-random() operation is specified by the enctype of the protocol key. PRF+() uses the counter to generate enough bits as needed by the random-to-key() [RFC3961] function for the encryption type specified for the resulting key; unneeded bits are removed from the tail. Unless otherwise specified, the resulting enctype of KRB-FX-CF2 is the enctype of k1. The pseudo-random() operation is the RFC 3961 pseudo-random() operation for the corresponding input key; the random-to-key() operation is the RFC 3961 random-to-key operation for the resulting key.
这里，计数器值1、2、3等被编码为一个八位整数。伪随机（）操作由协议密钥的类型指定。PRF+（）使用计数器为生成的密钥指定的加密类型生成random-to-key（）[RFC3961]函数所需的足够位；不需要的位从尾部移除。除非另有规定，否则KRB-FX-CF2的结果enctype为k1的enctype。pseudo-random（）操作是对应输入密钥的RFC 3961 pseudo-random（）操作；random-to-key（）操作是对结果密钥的RFC 3961 random-to-key操作。
Mechanism designers MUST specify the values for the input parameter pepper1 and pepper2 when combining two keys using KRB-FX-CF2(). The pepper1 and pepper2 MUST be distinct so that if the two keys being combined are the same, the resulting key is not a trivial key.
当使用KRB-FX-CF2（）组合两个键时，机构设计者必须指定输入参数pepper1和pepper2的值。pepper1和pepper2必须是不同的，这样，如果组合的两个键是相同的，则生成的键不是普通键。
Kerberos KDCs are stateless in that there is no requirement that clients will choose the same KDC for the second request in a conversation. Proxies or other intermediate nodes may also influence KDC selection. So, each request from a client to a KDC must include sufficient information that the KDC can regenerate any needed state. This is accomplished by giving the client a potentially long opaque cookie in responses to include in future requests in the same conversation. The KDC MAY respond that a conversation is too old and needs to restart by responding with a KDC_ERR_PREAUTH_EXPIRED error.
Kerberos KDC是无状态的，因为不要求客户端为会话中的第二个请求选择相同的KDC。代理或其他中间节点也可能影响KDC选择。因此，从客户机到KDC的每个请求都必须包含足够的信息，以便KDC能够重新生成任何需要的状态。这是通过在响应中为客户机提供一个可能很长的不透明cookie来实现的，以便在同一会话中的未来请求中包含该cookie。KDC可能会用KDC_ERR_PREAUTH_EXPIRED错误响应对话太旧，需要重新启动。
KDC_ERR_PREAUTH_EXPIRED 90
KDC_ERR_PREAUTH_过期90
When a client receives this error, the client SHOULD abort the existing conversation, and restart a new one.
当客户端收到此错误时，客户端应中止现有对话，并重新启动新对话。
An example, where more than one message from the client is needed, is when the client is authenticated based on a challenge/response scheme. In that case, the KDC needs to keep track of the challenge issued for a client authentication request.
例如，当客户机基于质询/响应方案进行身份验证时，需要来自客户机的多条消息。在这种情况下，KDC需要跟踪针对客户端身份验证请求发出的质询。
The PA-FX-COOKIE padata type is defined in this section to facilitate state management in the AS exchange. These padata are sent by the KDC when the KDC requires state for a future transaction. The client includes this opaque token in the next message in the conversation. The token may be relatively large; clients MUST be prepared for tokens somewhat larger than the size of all messages in a conversation.
本节中定义了PA-FX-COOKIE padata类型，以便于AS exchange中的状态管理。当KDC需要未来事务的状态时，这些padata由KDC发送。客户端在会话的下一条消息中包含此不透明令牌。代币可能相对较大；客户端必须准备好使用比会话中所有消息的大小稍大的令牌。
PA-FX-COOKIE 133 -- Stateless cookie that is not tied to a specific KDC.
PA-FX-COOKIE 133——未绑定到特定KDC的无状态COOKIE。
The corresponding padata-value field [RFC4120] contains an opaque token that will be echoed by the client in its response to an error from the KDC.
对应的padata值字段[RFC4120]包含一个不透明令牌，客户端将在响应KDC错误时回显该令牌。
The cookie token is generated by the KDC and transmitted in a PA-FX-COOKIE pre-authentication data item of a KRB-ERROR message. The client MUST copy the exact cookie encapsulated in a PA-FX-COOKIE data element into the next message of the same conversation. The content of the cookie field is a local matter of the KDC. As a result, it is not generally possible to mix KDC implementations from different vendors in the same realm. However, the KDC MUST construct the cookie token in such a manner that a malicious client cannot subvert the authentication process by manipulating the token. The KDC implementation needs to consider expiration of tokens, key rollover, and other security issues in token design. The content of the cookie
cookie令牌由KDC生成，并在KRB错误消息的PA-FX-cookie预认证数据项中传输。客户端必须将封装在PA-FX-cookie数据元素中的确切cookie复制到同一对话的下一条消息中。cookie字段的内容是KDC的本地内容。因此，通常不可能在同一领域中混合使用来自不同供应商的KDC实现。但是，KDC必须以这样的方式构造cookie令牌：恶意客户端不能通过操纵令牌来破坏身份验证过程。KDC实现需要考虑令牌的到期、密钥翻转以及令牌设计中的其他安全问题。cookie的内容
field is likely specific to the pre-authentication mechanisms used to authenticate the client. If a client authentication response can be replayed to multiple KDCs via the PA-FX-COOKIE mechanism, an expiration in the cookie is RECOMMENDED to prevent the response being presented indefinitely. Implementations need to consider replay both of an entire conversation and of messages within a conversation when designing what information is stored in a cookie and how pre-authentication mechanisms are implemented.
字段可能特定于用于对客户端进行身份验证的预身份验证机制。如果客户端身份验证响应可以通过PA-FX-COOKIE机制重播到多个KDC，则建议在COOKIE中过期，以防止响应无限期地呈现。在设计cookie中存储什么信息以及如何实现预认证机制时，需要考虑整个会话和会话中的消息的重放。
If at least one more message for a mechanism or a mechanism set is expected by the KDC, the KDC returns a KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error with a PA-FX-COOKIE to identify the conversation with the client, according to Section 2.2. The cookie is not expected to stay constant for a conversation: the KDC is expected to generate a new cookie for each message.
根据第2.2节的规定，如果KDC预期一个机制或一个机制集至少还有一条消息，KDC将返回一个KDC_ERR_more_PREAUTH_DATA_REQUIRED错误和PA-FX-COOKIE，以识别与客户端的对话。对于会话，cookie不应保持不变：KDC应为每条消息生成一个新的cookie。
KDC_ERR_MORE_PREAUTH_DATA_REQUIRED 91
KDC_ERR_需要更多预授权_数据_91
A client MAY throw away the state associated with a conversation and begin a new conversation by discarding its state and not including a cookie in the first message of a conversation. KDCs that comply with this specification MUST include a cookie in a response when the client can continue the conversation. In particular, a KDC MUST include a cookie in a KDC_ERR_PREAUTH_REQUIRED or KDC_ERR_MORE_PREAUTH_DATA_REQUIRED. KDCs SHOULD include a cookie in errors containing additional information allowing a client to retry. One reasonable strategy for meeting these requirements is to always include a cookie in KDC errors.
客户端可能会丢弃与会话相关联的状态，并通过丢弃其状态和在会话的第一条消息中不包含cookie来开始新的会话。当客户端可以继续对话时，符合此规范的KDC必须在响应中包含cookie。特别是，KDC必须在KDC_ERR_PREAUTH_REQUIRED或KDC_ERR_MORE_PREAUTH_DATA_REQUIRED中包含cookie。KDC应该在错误中包含cookie，该cookie包含允许客户端重试的附加信息。满足这些要求的一个合理策略是在KDC错误中始终包含cookie。
A KDC MAY indicate that it is terminating a conversation by not including a cookie in a response. When FAST is used, clients can assume that the absence of a cookie means that the KDC is ending the conversation. Similarly, if a cookie is seen at all during a conversation, clients MAY assume that the absence of a cookie in a future message means that the KDC is ending the conversation. Clients also need to deal with KDCs, prior to this specification, that do not include cookies; if neither cookies nor FAST are used in a conversation, the absence of a cookie is not a strong indication that the KDC is terminating the conversation.
KDC可能通过在响应中不包含cookie来表示它正在终止对话。当使用FAST时，客户端可以假定缺少cookie意味着KDC正在结束对话。类似地，如果在对话过程中看到cookie，客户端可能会认为未来消息中没有cookie意味着KDC正在结束对话。在本规范之前，客户还需要处理不包括cookie的KDC；如果在对话中既不使用cookie也不使用FAST，则缺少cookie并不表示KDC正在终止对话。
If all mechanisms in a group need to successfully complete in order to authenticate a client, the client and the KDC SHOULD use the PA-AUTHENTICATION-SET padata element.
如果组中的所有机制都需要成功完成才能对客户端进行身份验证，则客户端和KDC应使用PA-AUTHENTICATION-SET-padata元素。
PA-AUTHENTICATION-SET 134
PA-AUTHENTICATION-SET 134
A PA-AUTHENTICATION-SET padata element contains the ASN.1 DER encoding of the PA-AUTHENTICATION-SET structure:
PA-AUTHENTICATION-SET padata元素包含PA-AUTHENTICATION-SET结构的ASN.1 DER编码：
PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
pa-type [0] Int32,
-- same as padata-type.
pa-hint [1] OCTET STRING OPTIONAL,
pa-value [2] OCTET STRING OPTIONAL,
...
}
PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
pa-type [0] Int32,
-- same as padata-type.
pa-hint [1] OCTET STRING OPTIONAL,
pa-value [2] OCTET STRING OPTIONAL,
...
}
The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure contains the corresponding value of padata-type in PA-DATA [RFC4120]. Associated with the pa-type is a pa-hint, which is an octet string specified by the pre-authentication mechanism. This hint may provide information for the client that helps it determine whether the mechanism can be used. For example, a public-key mechanism might include the certificate authorities it trusts in the hint info. Most mechanisms today do not specify hint info; if a mechanism does not specify hint info, the KDC MUST NOT send a hint for that mechanism. To allow future revisions of mechanism specifications to add hint info, clients MUST ignore hint info received for mechanisms that the client believes do not support hint info. The pa-value element of the PA-AUTHENTICATION-SET-ELEM sequence is included to carry the first padata-value from the KDC to the client. If the client chooses this authentication set, then the client MUST process this pa-value. The pa-value element MUST be absent for all but the first entry in the authentication set. Clients MUST ignore the pa-value for the second and following entries in the authentication set.
pa-AUTHENTICATION-SET-ELEM结构的pa类型字段包含pa-DATA[RFC4120]中padata类型的对应值。与pa类型关联的是pa提示，它是预认证机制指定的八位字节字符串。此提示可为客户端提供信息，帮助其确定是否可以使用该机制。例如，公钥机制可能在提示信息中包含它信任的证书颁发机构。今天的大多数机制都没有指定提示信息；如果机制未指定提示信息，KDC不得发送该机制的提示。为了允许机制规范的未来修订添加提示信息，客户端必须忽略客户端认为不支持提示信息的机制收到的提示信息。pa-AUTHENTICATION-SET-ELEM序列的pa-value元素用于将第一个padata值从KDC传送到客户端。如果客户端选择此身份验证集，则客户端必须处理此pa值。除了身份验证集中的第一个条目外，所有条目都必须缺少pa value元素。客户端必须忽略身份验证集中第二个和以下条目的pa值。
If the client chooses an authentication set, then its first AS-REQ message MUST contain a PA-AUTH-SET-SELECTED padata element. This element contains the encoding of the PA-AUTHENTICATION-SET sequence received from the KDC corresponding to the authentication set that is chosen. The client MUST use the same octet values received from the KDC; it cannot re-encode the sequence. This allows KDCs to use bit-wise comparison to identify the selected authentication set. Permitting bit-wise comparison may limit the ability to use certain pre-authentication mechanisms that generate a dynamic challenge in an authentication set with optimistic selection of an authentication set. As with other optimistic pre-authentication failures, the KDC MAY return KDC_ERR_PREAUTH_FAILED with a new list of pre-authentication mechanisms (including authentication sets) if optimistic pre-authentication fails. The PA-AUTH-SET-SELECTED padata element MUST come before any padata elements from the authentication set in the padata sequence in the AS-REQ message. The client MAY
如果客户端选择验证集，则其第一条AS-REQ消息必须包含PA-AUTH-set-SELECTED padata元素。此元素包含从KDC接收的PA-AUTHENTICATION-SET序列的编码，该序列对应于所选的验证集。客户端必须使用从KDC接收的相同八位字节值；它无法重新编码序列。这允许KDC使用逐位比较来标识所选的身份验证集。允许逐位比较可能会限制使用某些预认证机制的能力，这些机制在认证集中生成动态质询，并对认证集进行乐观选择。与其他乐观预身份验证失败一样，如果乐观预身份验证失败，KDC可能会返回KDC_ERR_PREAUTH_FAILED以及新的预身份验证机制列表（包括身份验证集）。PA-AUTH-SET-SELECTED padata元素必须位于AS-REQ消息中padata序列中验证集的任何padata元素之前。客户可以
cache authentication sets from prior messages and use them to construct an optimistic initial AS-REQ. If the KDC receives a PA-AUTH-SET-SELECTED padata element that does not correspond to an authentication set that it would offer, then the KDC returns the KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET error. The e-data in this error contains a sequence of padata just as for the KDC_ERR_PREAUTH_REQUIRED error.
缓存先前消息中的身份验证集，并使用它们构造乐观初始AS-REQ。如果KDC收到的PA-AUTH-SET-SELECTED padata元素与它将提供的身份验证集不对应，则KDC返回KDC_ERR_PREAUTH_BAD_authentication_SET错误。此错误中的电子数据包含padata序列，与KDC_ERR_PREAUTH_REQUIRED错误一样。
PA-AUTH-SET-SELECTED 135 KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
PA-AUTH-SET-选择135 KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92
The PA-AUTHENTICATION-SET appears only in the first message from the KDC to the client. In particular, the client MAY fail if the authentication mechanism sets change as the conversation progresses. Clients MAY assume that the hints provided in the authentication set contain enough information that the client knows what user interface elements need to be displayed during the entire authentication conversation. Exceptional circumstances, such as expired passwords or expired accounts, may require that additional user interface be displayed. Mechanism designers need to carefully consider the design of their hints so that the client has this information. This way, clients can construct necessary dialogue boxes or wizards based on the authentication set and can present a coherent user interface. Current standards for user interfaces do not provide an acceptable experience when the client has to ask additional questions later in the conversation.
PA-AUTHENTICATION-SET仅出现在从KDC发送到客户端的第一条消息中。特别是，如果身份验证机制设置随着会话的进行而更改，则客户端可能会失败。客户机可能认为身份验证集中提供的提示包含足够的信息，客户机知道在整个身份验证对话期间需要显示哪些用户界面元素。特殊情况（如过期密码或过期帐户）可能需要显示其他用户界面。机制设计者需要仔细考虑其提示的设计，以便客户机拥有这些信息。通过这种方式，客户机可以基于身份验证集构建必要的对话框或向导，并提供一致的用户界面。当前的用户界面标准不能提供一种可接受的体验，当客户必须在稍后的对话中提出其他问题时。
When indicating which sets of pre-authentication mechanisms are supported, the KDC includes a PA-AUTHENTICATION-SET padata element for each pre-authentication mechanism set.
当指示支持哪些预认证机制集时，KDC为每个预认证机制集包括一个PA-authentication-SET padata元素。
The client sends the padata-value for the first mechanism it picks in the pre-authentication set, when the first mechanism completes, the client and the KDC will proceed with the second mechanism, and so on until all mechanisms complete successfully. The PA-FX-COOKIE, as defined in Section 5.2, MUST be sent by the KDC. One reason for this requirement is so that the conversation can continue if the conversation involves multiple KDCs. KDCs MUST support clients that do not include a cookie because they optimistically choose an authentication set, although they MAY always return a KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET and include a cookie in that message. Clients that support PA-AUTHENTICATION-SET MUST support PA-FX-COOKIE.
客户端发送它在预身份验证集中拾取的第一个机制的padata值，当第一个机制完成时，客户端和KDC将继续执行第二个机制，依此类推，直到所有机制成功完成。第5.2节中定义的PA-FX-COOKIE必须由KDC发送。此要求的一个原因是，如果会话涉及多个KDC，则会话可以继续。KDC必须支持不包含cookie的客户端，因为它们乐观地选择身份验证集，尽管它们可能总是返回KDC_ERR_PREAUTH_BAD_authentication_集并在该消息中包含cookie。支持PA-AUTHENTICATION-SET的客户端必须支持PA-FX-COOKIE。
Before the authentication succeeds and a ticket is returned, the message that the client sends is an AS-REQ and the message that the KDC sends is a KRB-ERROR message. The error code in the KRB-ERROR message from the KDC is KDC_ERR_MORE_PREAUTH_DATA_REQUIRED as defined
在身份验证成功并返回票据之前，客户端发送的消息是AS-REQ，KDC发送的消息是KRB-ERROR消息。来自KDC的KRB-error消息中的错误代码是定义所需的KDC_ERR_MORE_PREAUTH_DATA_
in Section 5.2 and the accompanying e-data contains the DER encoding of ASN.1 type METHOD-DATA. The KDC includes the padata elements in the METHOD-DATA. If there are no padata, the e-data field is absent in the KRB-ERROR message.
第5.2节和随附的电子数据包含ASN.1类型方法数据的DER编码。KDC在METHOD-DATA中包含padata元素。如果没有padata，则KRB错误消息中不存在e-data字段。
If the client sends the last message for a given mechanism, then the KDC sends the first message for the next mechanism. If the next mechanism does not start with a KDC-side challenge, then the KDC includes a padata item with the appropriate pa-type and an empty pa-data.
如果客户端为给定机制发送最后一条消息，那么KDC将为下一个机制发送第一条消息。如果下一个机制不是以KDC端质询开始的，那么KDC将包含一个具有适当pa类型的padata项和一个空pa数据。
If the KDC sends the last message for a particular mechanism, the KDC also includes the first padata for the next mechanism.
如果KDC发送特定机制的最后一条消息，KDC还包括下一个机制的第一个padata。
As described in [RFC4120], Kerberos is vulnerable to offline dictionary attacks. An attacker can request an AS-REP and try various passwords to see if they can decrypt the resulting ticket. RFC 4120 provides the encrypted timestamp pre-authentication method that ameliorates the situation somewhat by requiring that an attacker observe a successful authentication. However, stronger security is desired in many environments. The Kerberos FAST pre-authentication padata defined in this section provides a tool to significantly reduce vulnerability to offline dictionary attacks. When combined with encrypted challenge, FAST requires an attacker to mount a successful man-in-the-middle attack to observe ciphertext. When combined with host keys, FAST can even protect against active attacks. FAST also provides solutions to common problems for pre-authentication mechanisms such as binding of the request and the reply and freshness guarantee of the authentication. FAST itself, however, does not authenticate the client or the KDC; instead, it provides a typed hole to allow pre-authentication data be tunneled. A pre-authentication data element used within FAST is called a "FAST factor". A FAST factor captures the minimal work required for extending Kerberos to support a new pre-authentication scheme.
如[RFC4120]所述，Kerberos容易受到脱机字典攻击。攻击者可以请求AS-REP并尝试各种密码，以查看是否可以解密生成的票据。RFC 4120提供了加密的时间戳预认证方法，该方法通过要求攻击者观察成功的认证，在一定程度上改善了这种情况。但是，在许多环境中需要更强的安全性。本节中定义的Kerberos快速预认证padata提供了一种工具，可显著降低脱机字典攻击的漏洞。当与加密挑战相结合时，FAST要求攻击者发起成功的中间人攻击以观察密文。当与主机密钥结合使用时，FAST甚至可以抵御主动攻击。FAST还为预认证机制的常见问题提供了解决方案，如请求的绑定、认证的回复和新鲜度保证。然而，FAST本身并不验证客户端或KDC；相反，它提供了一个类型化的洞，允许对预认证数据进行隧道传输。FAST中使用的预认证数据元素称为“FAST因子”。快速因素捕获了扩展Kerberos以支持新的预身份验证方案所需的最小工作量。
A FAST factor MUST NOT be used outside of FAST unless its specification explicitly allows so. The typed holes in FAST messages can also be used as generic holes for other padata that are not intended to prove the client's identity, or establish the reply key.
除非其规范明确允许，否则不得在FAST之外使用FAST因子。FAST消息中的键入孔也可以用作其他padata的通用孔，这些padata不用于证明客户端身份或建立应答密钥。
New pre-authentication mechanisms SHOULD be designed as FAST factors, instead of full-blown pre-authentication mechanisms.
新的预认证机制应设计为快速因素，而不是成熟的预认证机制。
FAST factors that are pre-authentication mechanisms MUST meet the requirements in Section 4.
作为预认证机制的FAST因素必须满足第4节的要求。
FAST employs an armoring scheme. The armor can be a Ticket Granting Ticket (TGT) obtained by the client's machine using the host keys to pre-authenticate with the KDC, or an anonymous TGT obtained based on anonymous PKINIT [RFC6112] [RFC4556].
FAST采用装甲方案。装甲可以是客户机使用主机密钥通过KDC预认证获得的票据授予票据（TGT），也可以是基于匿名PKINIT[RFC6112][RFC4556]获得的匿名TGT。
The rest of this section describes the types of armors and the syntax of the messages used by FAST. Conforming implementations MUST support Kerberos FAST padata.
本节的其余部分描述了装甲的类型和FAST使用的消息语法。一致性实现必须支持Kerberos FAST padata。
Any FAST armor scheme MUST provide a fresh armor key for each conversation. Clients and KDCs can assume that if a message is encrypted and integrity protected with a given armor key, then it is part of the conversation using that armor key.
任何快速装甲方案都必须为每次对话提供新的装甲密钥。客户机和KDC可以假设，如果消息是用给定的armor密钥加密和完整性保护的，那么它就是使用该armor密钥的对话的一部分。
All KDCs in a realm MUST support FAST if FAST is offered by any KDC as a pre-authentication mechanism.
如果任何KDC都提供FAST作为预认证机制，则领域中的所有KDC都必须支持FAST。
An armor key is used to encrypt pre-authentication data in the FAST request and the response. The KrbFastArmor structure is defined to identify the armor key. This structure contains the following two fields: the armor-type identifies the type of armors and the armor-value is an OCTET STRING that contains the description of the armor scheme and the armor key.
armor密钥用于加密FAST请求和响应中的预认证数据。KrbFastArmor结构的定义是为了识别装甲钥匙。此结构包含以下两个字段：装甲类型标识装甲类型，装甲值是一个八位字符串，其中包含装甲方案和装甲密钥的描述。
KrbFastArmor ::= SEQUENCE {
armor-type [0] Int32,
-- Type of the armor.
armor-value [1] OCTET STRING,
-- Value of the armor.
...
}
KrbFastArmor ::= SEQUENCE {
armor-type [0] Int32,
-- Type of the armor.
armor-value [1] OCTET STRING,
-- Value of the armor.
...
}
The value of the armor key is a matter of the armor type specification. Only one armor type is defined in this document.
装甲密钥的值取决于装甲类型规范。本文件中仅定义了一种装甲类型。
FX_FAST_ARMOR_AP_REQUEST 1
FX\U快速装甲\U AP\U请求1
The FX_FAST_ARMOR_AP_REQUEST armor is based on Kerberos tickets.
FX\u FAST\u ARMOR\u AP\u请求护甲基于Kerberos票据。
Conforming implementations MUST implement the FX_FAST_ARMOR_AP_REQUEST armor type. If a FAST KDC receives an unknown armor type it MUST respond with KDC_ERR_PREAUTH_FAILED.
一致性实施必须实施FX\u FAST\u装甲\u AP\u请求装甲类型。如果快速KDC接收到未知装甲类型，它必须以KDC_ERR_PREAUTH_FAILED响应。
An armor type may be appropriate for use in armoring AS requests, armoring TGS requests, or both. TGS armor types MUST authenticate the client to the KDC, typically by binding the TGT sub-session key
装甲类型可能适用于按要求装甲、TGS要求装甲或两者兼而有之。TGS armor类型必须向KDC验证客户端，通常是通过绑定TGT子会话密钥
to the armor key. As discussed below, it is desirable for AS armor types to authenticate the KDC to the client, but this is not required.
到装甲钥匙。如下所述，As装甲类型需要向客户机验证KDC，但这不是必需的。
FAST implementations MUST maintain state about whether the armor mechanism authenticates the KDC. If it does not, then a FAST factor that authenticates the KDC MUST be used if the reply key is replaced.
FAST实现必须维护装甲机制是否对KDC进行身份验证的状态。如果没有，则在替换应答密钥时，必须使用验证KDC的快速因子。
This is a ticket-based armoring scheme. The armor-type is FX_FAST_ARMOR_AP_REQUEST, the armor-value contains an ASN.1 DER encoded AP-REQ. The ticket in the AP-REQ is called an armor ticket or an armor TGT. The subkey field in the AP-REQ MUST be present. The armor key is defined by the following function:
这是一个基于票据的装甲方案。护甲类型为FX\U FAST\U护甲\U AP\U请求，护甲值包含ASN.1 DER编码的AP-REQ。AP-REQ中的票据称为装甲票据或装甲TGT。AP-REQ中的子键字段必须存在。装甲钥匙由以下功能定义：
armor_key = KRB-FX-CF2( subkey, ticket_session_key, "subkeyarmor", "ticketarmor" )
armor_key=KRB-FX-CF2（子键、票证会话键、“子键armor”、“票证管理员”）
The 'ticket_session_key' is the session key from the ticket in the ap-req. The 'subkey' is the ap-req subkey. This construction guarantees that both the KDC (through the session key) and the client (through the subkey) contribute to the armor key.
“票证会话密钥”是ap req中票证的会话密钥。“子项”是ap req子项。这种构造保证KDC（通过会话密钥）和客户机（通过子密钥）都对armor密钥作出贡献。
The server name field of the armor ticket MUST identify the TGS of the target realm. Here are three common ways in the decreasing preference order how an armor TGT SHOULD be obtained:
armor票证的服务器名称字段必须标识目标领域的TGS。以下是按递减优先顺序获得装甲TGT的三种常见方法：
1. If the client is authenticating from a host machine whose Kerberos realm has an authentication path to the client's realm, the host machine obtains a TGT by using the host keys. If the client's realm is different than the realm of the local host, the machine then obtains a cross-realm TGT to the client's realm as the armor ticket. Otherwise, the host's primary TGT is the armor ticket.
1. 如果客户端正在从其Kerberos域具有到客户端域的身份验证路径的主机进行身份验证，则主机将使用主机密钥获得TGT。如果客户机的领域不同于本地主机的领域，那么机器将获得一个到客户机领域的跨领域TGT作为armor票证。否则，主机的主TGT就是装甲票。
2. If the client's host machine cannot obtain a host ticket strictly based on RFC 4120, but the KDC has an asymmetric signing key whose binding with the expected KDC can be verified by the client, the client can use anonymous PKINIT [RFC6112] [RFC4556] to authenticate the KDC and obtain an anonymous TGT as the armor ticket. The armor ticket can also be a cross-realm TGT obtained based on the initial primary TGT obtained using anonymous PKINIT with KDC authentication.
2. 如果客户机的主机无法严格根据RFC 4120获得主机票证，但KDC具有非对称签名密钥，该密钥与预期KDC的绑定可由客户机验证，则客户机可以使用匿名PKINIT[RFC6112][RFC4556]对KDC进行身份验证，并获得匿名TGT作为armor票证。armor票证也可以是基于使用匿名PKINIT和KDC身份验证获得的初始主TGT获得的跨域TGT。
3. Otherwise, the client uses anonymous PKINIT to get an anonymous TGT without KDC authentication and that TGT is the armor ticket. Note that this mode of operation is vulnerable to man-in-the-
3. 否则，客户端将使用匿名PKINIT获得匿名TGT，而无需KDC身份验证，并且TGT是armor票证。请注意，这种操作模式很容易受到现场人员的攻击-
middle attacks at the time of obtaining the initial anonymous armor TGT.
在获得初始匿名护甲TGT时进行中间攻击。
If anonymous PKINIT is used to obtain the armor ticket, the KDC cannot know whether its signing key can be verified by the client; hence, the KDC MUST be marked as unverified from the KDC's point of view while the client could be able to authenticate the KDC by verifying the KDC's signing key is bound with the expected KDC. The client needs to carefully consider the risk and benefit tradeoffs associated with active attacks before exposing cipher text encrypted using the user's long-term secrets when the armor does not authenticate the KDC.
如果使用匿名PKINIT获取armor票证，KDC无法知道其签名密钥是否可以被客户端验证；因此，从KDC的角度来看，KDC必须标记为未验证，而客户端可以通过验证KDC的签名密钥是否与预期的KDC绑定来验证KDC。当铠甲不验证KDC时，客户端需要仔细考虑与主动攻击相关联的风险和利益权衡，然后使用用户的长期机密来加密加密文本。
The TGS MUST reject a request if there is an AD-fx-fast-armor (71) element in the authenticator of the pa-tgs-req padata or if the ticket in the authenticator of a pa-tgs-req contains the AD-fx-fast-armor authorization data element. These tickets and authenticators MAY be used as FAST armor tickets but not to obtain a ticket via the TGS. This authorization data is used in a system where the encryption of the user's pre-authentication data is performed in an unprivileged user process. A privileged process can provide to the user process a host ticket, an authenticator for use with that ticket, and the sub-session key contained in the authenticator. In order for the host process to ensure that the host ticket is not accidentally or intentionally misused, (i.e., the user process might use the host ticket to authenticate as the host), it MUST include a critical authorization data element of the type AD-fx-fast-armor when providing the authenticator or in the enc-authorization-data field of the TGS request used to obtain the TGT. The corresponding ad-data field of the AD-fx-fast-armor element is empty.
如果pa TGS req padata的验证器中存在AD fx fast armor（71）元素，或者pa TGS req的验证器中的票据包含AD fx fast armor授权数据元素，TGS必须拒绝请求。这些票据和验证器可以用作快速装甲票据，但不能通过TGS获得票据。该授权数据用于在非特权用户进程中执行用户预认证数据加密的系统中。特权进程可以向用户进程提供主机票证、与该票证一起使用的验证器以及验证器中包含的子会话密钥。为了使主机进程确保主机票证不会被意外或故意滥用（即，用户进程可能使用主机票证作为主机进行身份验证），在提供验证器时，或在用于获取TGT的TGS请求的enc授权数据字段中，必须包含AD fx fast armor类型的关键授权数据元素。ad fx快速装甲元素对应的ad数据字段为空。
This armor type is only valid for AS requests; implicit armor, described below in TGS processing, is the only supported way to establish an armor key for the TGS at this time.
此装甲类型仅对AS请求有效；隐式装甲（在TGS处理中描述）是目前为TGS建立装甲密钥的唯一受支持的方法。
A padata type PA-FX-FAST is defined for the Kerberos FAST pre-authentication padata. The corresponding padata-value field [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST-REQUEST. As with all pre-authentication types, the KDC SHOULD advertise PA-FX-FAST in a PREAUTH_REQUIRED error. KDCs MUST send the advertisement of PA-FX-FAST with an empty pa-value. Clients MUST ignore the pa-value of PA-FX-FAST in an initial PREAUTH_REQUIRED error. FAST is not expected to be used in an authentication set: clients will typically use FAST padata if available and this decision should not depend on what other pre-authentication methods are available. As such, no pa-hint is defined for FAST at this time.
为Kerberos FAST预认证padata定义了padata类型PA-FX-FAST。相应的padata值字段[RFC4120]包含ASN.1类型PA-FX-FAST-REQUEST的DER编码。与所有预认证类型一样，KDC应在预认证要求的错误中公布PA-FX-FAST。KDC必须发送带有空PA值的PA-FX-FAST广告。在初始预授权要求错误中，客户必须忽略pa-FX-FAST的pa值。FAST预计不会在身份验证集中使用：如果可用，客户端通常会使用FAST padata，并且此决定不应取决于可用的其他预身份验证方法。因此，目前没有为FAST定义pa提示。
PA-FX-FAST 136 -- Padata type for Kerberos FAST
PA-FX-FAST 136--Kerberos FAST的Padata类型
PA-FX-FAST-REQUEST ::= CHOICE {
armored-data [0] KrbFastArmoredReq,
...
}
PA-FX-FAST-REQUEST ::= CHOICE {
armored-data [0] KrbFastArmoredReq,
...
}
KrbFastArmoredReq ::= SEQUENCE {
armor [0] KrbFastArmor OPTIONAL,
-- Contains the armor that identifies the armor key.
-- MUST be present in AS-REQ.
req-checksum [1] Checksum,
-- For AS, contains the checksum performed over the type
-- KDC-REQ-BODY for the req-body field of the KDC-REQ
-- structure;
-- For TGS, contains the checksum performed over the type
-- AP-REQ in the PA-TGS-REQ padata.
-- The checksum key is the armor key, the checksum
-- type is the required checksum type for the enctype of
-- the armor key, and the key usage number is
-- KEY_USAGE_FAST_REQ_CHKSUM.
enc-fast-req [2] EncryptedData, -- KrbFastReq --
-- The encryption key is the armor key, and the key usage
-- number is KEY_USAGE_FAST_ENC.
...
}
KrbFastArmoredReq ::= SEQUENCE {
armor [0] KrbFastArmor OPTIONAL,
-- Contains the armor that identifies the armor key.
-- MUST be present in AS-REQ.
req-checksum [1] Checksum,
-- For AS, contains the checksum performed over the type
-- KDC-REQ-BODY for the req-body field of the KDC-REQ
-- structure;
-- For TGS, contains the checksum performed over the type
-- AP-REQ in the PA-TGS-REQ padata.
-- The checksum key is the armor key, the checksum
-- type is the required checksum type for the enctype of
-- the armor key, and the key usage number is
-- KEY_USAGE_FAST_REQ_CHKSUM.
enc-fast-req [2] EncryptedData, -- KrbFastReq --
-- The encryption key is the armor key, and the key usage
-- number is KEY_USAGE_FAST_ENC.
...
}
KEY_USAGE_FAST_REQ_CHKSUM 50 KEY_USAGE_FAST_ENC 51
密钥使用快速请求CHKSUM 50密钥使用快速ENC 51
The PA-FX-FAST-REQUEST structure contains a KrbFastArmoredReq type. The KrbFastArmoredReq encapsulates the encrypted padata.
PA-FX-FAST-REQUEST结构包含KrbFastArmoredReq类型。KrbFastArmoredReq封装了加密的padata。
The enc-fast-req field contains an encrypted KrbFastReq structure. The armor key is used to encrypt the KrbFastReq structure, and the key usage number for that encryption is KEY_USAGE_FAST_ENC.
enc fast req字段包含加密的KrbFastReq结构。armor密钥用于加密KrbFastReq结构，该加密的密钥使用编号为key_usage_FAST_ENC。
The armor key is selected as follows:
装甲关键点的选择如下所示：
o In an AS request, the armor field in the KrbFastArmoredReq structure MUST be present and the armor key is identified according to the specification of the armor type.
o 在AS请求中，KrbFastArmoredReq结构中的装甲字段必须存在，并且根据装甲类型的规范识别装甲密钥。
o There are two possibilities for armor for a TGS request. If the ticket presented in the PA-TGS-REQ authenticator is a TGT, then the client SHOULD NOT include the armor field in the Krbfastreq and a subkey MUST be included in the PA-TGS-REQ authenticator. In this case, the armor key is the same armor key that would be computed if the TGS-REQ authenticator was used in an FX_FAST_ARMOR_AP_REQUEST armor. Clients MAY present a non-TGT in the PA-TGS-REQ authenticator and omit the armor field, in which case the armor key is the same that would be computed if the authenticator were used in an FX_FAST_ARMOR_AP_REQUEST armor. This is the only case where a ticket other than a TGT can be used to establish an armor key; even though the armor key is computed the same as an FX_FAST_ARMOR_AP_REQUEST, a non-TGT cannot be used as an armor ticket in FX_FAST_ARMOR_AP_REQUEST. Alternatively, a client MAY use an armor type defined in the future for use with the TGS request.
o TGS请求的装甲有两种可能。如果PA-TGS-REQ验证器中显示的票据是TGT，则客户端不应在Krbfastreq中包含armor字段，并且必须在PA-TGS-REQ验证器中包含子密钥。在这种情况下，如果TGS-REQ验证器用于FX_FAST_armor_AP_请求armor，则计算的armor密钥与armor密钥相同。客户端可能会在PA-TGS-REQ验证器中显示非TGT，并忽略armor字段，在这种情况下，armor密钥与在FX\u FAST\u armor\u AP\u请求armor中使用验证器时计算的密钥相同。这是唯一可以使用TGT以外的票证建立装甲密钥的情况；即使装甲密钥的计算方法与FX\U FAST\U armor\U AP\U请求相同，但非TGT不能用作FX\U FAST\U armor\U AP\U请求中的装甲票证。或者，客户机可以使用将来定义的装甲类型，用于TGS请求。
The req-checksum field contains a checksum computed differently for AS and TGS. For an AS-REQ, it is performed over the type KDC-REQ-BODY for the req-body field of the KDC-REQ structure of the containing message; for a TGS-REQ, it is performed over the type AP-REQ in the PA-TGS-REQ padata of the TGS request. The checksum key is the armor key, and the checksum type is the required checksum type for the enctype of the armor key per [RFC3961]. This checksum MUST be a keyed checksum and it is included in order to bind the FAST padata to the outer request. A KDC that implements FAST will ignore the outer request, but including a checksum is relatively cheap and may prevent confusing behavior.
req校验和字段包含为AS和TGS以不同方式计算的校验和。对于AS-REQ，在包含消息的KDC-REQ结构的REQ BODY字段的KDC-REQ-BODY类型上执行；对于TGS-REQ，在TGS请求的PA-TGS-REQ padata中的AP-REQ类型上执行。校验和密钥是铠装密钥，校验和类型是[RFC3961]规定的铠装密钥enctype所需的校验和类型。该校验和必须是键控校验和，并且包含该校验和是为了将FAST padata绑定到外部请求。实现FAST的KDC将忽略外部请求，但包含校验和相对便宜，可以防止混淆行为。
The KrbFastReq structure contains the following information:
KrbFastReq结构包含以下信息：
KrbFastReq ::= SEQUENCE {
fast-options [0] FastOptions,
-- Additional options.
padata [1] SEQUENCE OF PA-DATA,
-- padata typed holes.
req-body [2] KDC-REQ-BODY,
-- Contains the KDC request body as defined in Section
-- 5.4.1 of [RFC4120].
-- This req-body field is preferred over the outer field
-- in the KDC request.
...
}
KrbFastReq ::= SEQUENCE {
fast-options [0] FastOptions,
-- Additional options.
padata [1] SEQUENCE OF PA-DATA,
-- padata typed holes.
req-body [2] KDC-REQ-BODY,
-- Contains the KDC request body as defined in Section
-- 5.4.1 of [RFC4120].
-- This req-body field is preferred over the outer field
-- in the KDC request.
...
}
The fast-options field indicates various options that are to modify the behavior of the KDC. The following options are defined:
“快速选项”字段指示要修改KDC行为的各种选项。定义了以下选项：
FastOptions ::= KerberosFlags
-- reserved(0),
-- hide-client-names(1),
FastOptions ::= KerberosFlags
-- reserved(0),
-- hide-client-names(1),
Bits Name Description
-----------------------------------------------------------------
0 RESERVED Reserved for future expansion of this
field.
1 hide-client-names Requesting the KDC to hide client
names in the KDC response, as
described next in this section.
16 kdc-follow-referrals reserved [REFERRALS].
Bits Name Description
-----------------------------------------------------------------
0 RESERVED Reserved for future expansion of this
field.
1 hide-client-names Requesting the KDC to hide client
names in the KDC response, as
described next in this section.
16 kdc-follow-referrals reserved [REFERRALS].
Bits 1 through 15 inclusive (with bit 1 and bit 15 included) are critical options. If the KDC does not support a critical option, it MUST fail the request with KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS, and there is no accompanying e-data defined in this document for this error code. Bit 16 and onward (with bit 16 included) are non-critical options. KDCs conforming to this specification ignore unknown non-critical options.
第1位到第15位（包括第1位和第15位）是关键选项。如果KDC不支持关键选项，则必须使用KDC_ERR_UNKNOWN_critical_FAST_选项使请求失败，并且本文档中没有为该错误代码定义随附的电子数据。位16及以上（包括位16）为非关键选项。符合本规范的KDC忽略未知的非关键选项。
KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS 93
KDC_错误_未知_关键_快速_选项93
The hide-client-names Option
隐藏客户端名称选项
The Kerberos response defined in [RFC4120] contains the client identity in cleartext. This makes traffic analysis straightforward. The hide-client-names option is designed to complicate traffic analysis. If the hide-client-names option is set, the KDC implementing PA-FX-FAST MUST identify the client as the anonymous principal [RFC6112] in the KDC reply and the error response. Hence, this option is set by the client if it wishes to conceal the client identity in the KDC response. A conforming KDC ignores the client principal name in the outer KDC-REQ-BODY field, and identifies the client using the cname and crealm fields in the req-body field of the KrbFastReq structure.
[RFC4120]中定义的Kerberos响应包含明文形式的客户机标识。这使得流量分析变得简单明了。隐藏客户端名称选项旨在使流量分析复杂化。如果设置了隐藏客户端名称选项，则实现PA-FX-FAST的KDC必须在KDC回复和错误响应中将客户端标识为匿名主体[RFC6112]。因此，如果客户端希望在KDC响应中隐藏客户端标识，则该选项由客户端设置。一致性KDC忽略外部KDC-REQ-BODY字段中的客户机主体名称，并使用KrbFastReq结构的REQ BODY字段中的cname和crealm字段标识客户机。
The kdc-follow-referrals Option
kdc跟随转介选项
This option is reserved for [REFERRALS].
此选项保留给[转介]。
The padata field contains a list of PA-DATA structures as described in Section 5.2.7 of [RFC4120]. These PA-DATA structures can contain FAST factors. They can also be used as generic typed-holes to contain data not intended for proving the client's identity or establishing a reply key, but for protocol extensibility. If the KDC supports the PA-FX-FAST-REQUEST padata, unless otherwise specified, the client MUST place any padata that is otherwise in the outer KDC request body into this field. In a TGS request, PA-TGS-REQ padata is not included in this field and it is present in the outer KDC request body.
padata字段包含[RFC4120]第5.2.7节所述的PA数据结构列表。这些PA数据结构可以包含快速因素。它们还可以用作泛型类型的孔，以包含不用于证明客户端身份或建立应答密钥的数据，而是用于协议扩展性的数据。如果KDC支持PA-FX-FAST-REQUEST padata，除非另有规定，否则客户端必须将外部KDC请求正文中的任何padata放入此字段。在TGS请求中，PA-TGS-REQ padata不包括在该字段中，它存在于外部KDC请求正文中。
The KDC-REQ-BODY in the FAST structure is used in preference to the KDC-REQ-BODY outside of the FAST pre-authentication. The outer KDC-REQ-BODY structure SHOULD be filled in for backwards compatibility with KDCs that do not support FAST. A conforming KDC ignores the outer KDC-REQ-BODY field in the KDC request. Pre-authentication data methods such as [RFC4556] that include a checksum of the KDC-REQ-BODY should checksum the KDC-REQ-BODY in the FAST structure.
FAST结构中的KDC-REQ-BODY优先于FAST预认证之外的KDC-REQ-BODY使用。应填写外部KDC-REQ-BODY结构，以便与不支持FAST的KDC向后兼容。一致性KDC忽略KDC请求中的外部KDC-REQ-BODY字段。包括KDC-REQ-BODY校验和的预认证数据方法（如[RFC4556]）应校验FAST结构中的KDC-REQ-BODY。
In a TGS request, a client MAY include the AD-fx-fast-used authdata either in the pa-tgs-req authenticator or in the authorization data in the pa-tgs-req ticket. If the KDC receives this authorization data but does not find a FAST padata, then it MUST return KRB_APP_ERR_MODIFIED.
在TGS请求中，客户端可以在pa TGS req认证器中或pa TGS req票证中的授权数据中包括AD fx fast used authdata。如果KDC收到此授权数据但未找到FAST padata，则必须返回KRB_APP_ERR_MODIFIED。
The KDC that supports the PA-FX-FAST padata MUST include a PA-FX-FAST padata element in the KDC reply. In the case of an error, the PA-FX-FAST padata is included in the KDC responses according to Section 5.4.4.
支持PA-FX-FAST padata的KDC必须在KDC回复中包含PA-FX-FAST padata元素。如果出现错误，根据第5.4.4节，PA-FX-FAST padata包含在KDC响应中。
The corresponding padata-value field [RFC4120] for the PA-FX-FAST in the KDC response contains the DER encoding of the ASN.1 type PA-FX-FAST-REPLY.
KDC响应中PA-FX-FAST对应的padata值字段[RFC4120]包含ASN.1类型PA-FX-FAST-REPLY的DER编码。
PA-FX-FAST-REPLY ::= CHOICE {
armored-data [0] KrbFastArmoredRep,
...
}
PA-FX-FAST-REPLY ::= CHOICE {
armored-data [0] KrbFastArmoredRep,
...
}
KrbFastArmoredRep ::= SEQUENCE {
enc-fast-rep [0] EncryptedData, -- KrbFastResponse --
-- The encryption key is the armor key in the request, and
-- the key usage number is KEY_USAGE_FAST_REP.
...
}
KEY_USAGE_FAST_REP 52
KrbFastArmoredRep ::= SEQUENCE {
enc-fast-rep [0] EncryptedData, -- KrbFastResponse --
-- The encryption key is the armor key in the request, and
-- the key usage number is KEY_USAGE_FAST_REP.
...
}
KEY_USAGE_FAST_REP 52
The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep structure. The KrbFastArmoredRep structure encapsulates the padata in the KDC reply in the encrypted form. The KrbFastResponse is encrypted with the armor key used in the corresponding request, and the key usage number is KEY_USAGE_FAST_REP.
PA-FX-FAST-REPLY结构包含KrbFastArmoredRep结构。KrbFastArmoredRep结构以加密形式封装KDC应答中的padata。KrbFastResponse使用相应请求中使用的armor密钥进行加密，密钥使用编号为key_usage_FAST_REP。
The Kerberos client MUST support a local policy that rejects the response if PA-FX-FAST-REPLY is not included in the response. Clients MAY also support policies that fall back to other mechanisms or that do not use pre-authentication when FAST is unavailable. It is important to consider the potential downgrade attacks when deploying such a policy.
Kerberos客户端必须支持一个本地策略，如果响应中不包含PA-FX-FAST-REPLY，该策略将拒绝响应。客户端还可能支持退回到其他机制的策略，或者在FAST不可用时不使用预身份验证的策略。在部署这样的策略时，考虑潜在的降级攻击是很重要的。
The KrbFastResponse structure contains the following information:
KrbFastResponse结构包含以下信息：
KrbFastResponse ::= SEQUENCE {
padata [0] SEQUENCE OF PA-DATA,
-- padata typed holes.
strengthen-key [1] EncryptionKey OPTIONAL,
-- This, if present, strengthens the reply key for AS and
-- TGS. MUST be present for TGS.
-- MUST be absent in KRB-ERROR.
finished [2] KrbFastFinished OPTIONAL,
-- Present in AS or TGS reply; absent otherwise.
nonce [3] UInt32,
-- Nonce from the client request.
...
}
KrbFastResponse ::= SEQUENCE {
padata [0] SEQUENCE OF PA-DATA,
-- padata typed holes.
strengthen-key [1] EncryptionKey OPTIONAL,
-- This, if present, strengthens the reply key for AS and
-- TGS. MUST be present for TGS.
-- MUST be absent in KRB-ERROR.
finished [2] KrbFastFinished OPTIONAL,
-- Present in AS or TGS reply; absent otherwise.
nonce [3] UInt32,
-- Nonce from the client request.
...
}
The padata field in the KrbFastResponse structure contains a list of PA-DATA structures as described in Section 5.2.7 of [RFC4120]. These PA-DATA structures are used to carry data advancing the exchange specific for the FAST factors. They can also be used as generic typed-holes for protocol extensibility. Unless otherwise specified, the KDC MUST include any padata that are otherwise in the outer KDC-REP or KDC-ERROR structure into this field. The padata field in the KDC reply structure outside of the PA-FX-FAST-REPLY structure typically includes only the PA-FX-FAST-REPLY padata.
KrbFastResponse结构中的padata字段包含[RFC4120]第5.2.7节所述的PA数据结构列表。这些PA-DATA结构用于传输数据，以促进特定于FAST因素的交换。它们还可以用作协议扩展性的泛型类型孔。除非另有规定，否则KDC必须将外部KDC-REP或KDC-ERROR结构中的任何padata包含在此字段中。PA-FX-FAST-reply结构之外的KDC应答结构中的padata字段通常仅包括PA-FX-FAST-reply padata。
The strengthen-key field provides a mechanism for the KDC to strengthen the reply key. If set, the strengthen-key value MUST be randomly generated to have the same etype as that of the reply key before being strengthened, and then the reply key is strengthened after all padata items are processed. Let padata-reply-key be the reply key after padata processing.
强化密钥字段为KDC提供了一种机制来强化应答密钥。如果设置，则必须随机生成强化密钥值，使其在强化之前具有与应答密钥相同的etype，然后在处理所有padata项后强化应答密钥。将padata reply key设为padata处理后的应答密钥。
reply-key = KRB-FX-CF2(strengthen-key, padata-reply-key, "strengthenkey", "replykey")
回复键=KRB-FX-CF2（强化键、padata回复键、“强化键”、“回复键”）
The strengthen-key field MAY be set in an AS reply; it MUST be set in a TGS reply; it must be absent in an error reply. The strengthen key is required in a TGS reply so that an attacker cannot remove the FAST PADATA from a TGS reply, causing the KDC to appear not to support FAST.
可以在AS应答中设置加强键字段；它必须在TGS回复中设置；在错误回复中必须没有。TGS回复中需要强化密钥，因此攻击者无法从TGS回复中删除FAST PADATA，从而导致KDC看起来不支持FAST。
The finished field contains a KrbFastFinished structure. It is filled by the KDC in the final message in the conversation. This field is present in an AS-REP or a TGS-REP when a ticket is returned, and it is not present in an error reply.
finished字段包含一个KrbFastFinished结构。它由KDC在对话的最后一条消息中填充。返回票证时，此字段出现在AS-REP或TGS-REP中，并且在错误回复中不存在。
The KrbFastFinished structure contains the following information:
KrbFastFinished结构包含以下信息：
KrbFastFinished ::= SEQUENCE {
timestamp [0] KerberosTime,
usec [1] Microseconds,
-- timestamp and usec represent the time on the KDC when
-- the reply was generated.
crealm [2] Realm,
cname [3] PrincipalName,
-- Contains the client realm and the client name.
ticket-checksum [4] Checksum,
-- checksum of the ticket in the KDC-REP using the armor
-- and the key usage is KEY_USAGE_FAST_FINISH.
-- The checksum type is the required checksum type
-- of the armor key.
...
}
KEY_USAGE_FAST_FINISHED 53
KrbFastFinished ::= SEQUENCE {
timestamp [0] KerberosTime,
usec [1] Microseconds,
-- timestamp and usec represent the time on the KDC when
-- the reply was generated.
crealm [2] Realm,
cname [3] PrincipalName,
-- Contains the client realm and the client name.
ticket-checksum [4] Checksum,
-- checksum of the ticket in the KDC-REP using the armor
-- and the key usage is KEY_USAGE_FAST_FINISH.
-- The checksum type is the required checksum type
-- of the armor key.
...
}
KEY_USAGE_FAST_FINISHED 53
The timestamp and usec fields represent the time on the KDC when the reply ticket was generated, these fields have the same semantics as the corresponding identically named fields in Section 5.6.1 of [RFC4120]. The client MUST use the KDC's time in these fields thereafter when using the returned ticket. The client need not confirm that the timestamp returned is within allowable clock skew: the armor key guarantees that the reply is fresh. The client MAY trust the timestamp returned.
timestamp和usec字段表示生成回复票证时KDC上的时间，这些字段与[RFC4120]第5.6.1节中相应的同名字段具有相同的语义。在使用返回的票证时，客户机必须在这些字段中使用KDC的时间。客户机不需要确认返回的时间戳是否在允许的时钟偏移范围内：armor密钥保证回复是新的。客户端可能信任返回的时间戳。
The cname and crealm fields identify the authenticated client. If facilities described in [REFERRALS] are used, the authenticated client may differ from the client in the FAST request.
cname和crealm字段标识经过身份验证的客户端。如果使用[REFERRALS]中描述的设施，则经过身份验证的客户端可能与FAST请求中的客户端不同。
The ticket-checksum is a checksum of the issued ticket. The checksum key is the armor key, and the checksum type is the required checksum type of the enctype of that key, and the key usage number is KEY_USAGE_FAST_FINISHED.
票证校验和是已发行票证的校验和。校验和密钥是护甲密钥，校验和类型是该密钥的enctype所需的校验和类型，密钥使用编号是key\u usage\u FAST\u FINISHED。
When FAST padata is included, the PA-FX-COOKIE padata as defined in Section 5.2 MUST be included in the padata sequence in the KrbFastResponse sequence if the KDC expects at least one more message from the client in order to complete the authentication.
当包含FAST padata时，如果KDC希望至少有一条来自客户端的消息来完成身份验证，则第5.2节中定义的PA-FX-COOKIE padata必须包含在KrbFastResponse序列中的padata序列中。
The nonce field in the KrbFastResponse contains the value of the nonce field in the KDC-REQ of the corresponding client request and it binds the KDC response with the client request. The client MUST verify that this nonce value in the reply matches with that of the request and reject the KDC reply otherwise. To prevent the response from one message in a conversation from being replayed to a request in another message, clients SHOULD use a new nonce for each message in a conversation.
KrbFastrResponse中的nonce字段包含相应客户端请求的KDC-REQ中的nonce字段的值，并将KDC响应与客户端请求绑定。客户端必须验证应答中的nonce值是否与请求的值匹配，否则拒绝KDC应答。为了防止会话中一条消息的响应被重播到另一条消息中的请求，客户端应该为会话中的每条消息使用新的nonce。
If the Kerberos FAST padata was included in the request, unless otherwise specified, the e-data field of the KRB-ERROR message [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA [RFC4120] and a PA-FX-FAST is included in the METHOD-DATA. The KDC MUST include all the padata elements such as PA-ETYPE-INFO2 and padata elements that indicate acceptable pre-authentication mechanisms [RFC4120] in the KrbFastResponse structure.
如果请求中包含Kerberos FAST padata，除非另有规定，否则KRB-ERROR消息[RFC4120]的e-data字段包含METHOD-data[RFC4120]类型的ASN.1 DER编码，并且PA-FX-FAST包含在METHOD-data中。KDC必须包括所有padata元素，如PA-ETYPE-INFO2和padata元素，这些元素指示KrbFastResponse结构中可接受的预认证机制[RFC4120]。
The KDC MUST also include a PA-FX-ERROR padata item in the KRBFastResponse structure. The padata-value element of this sequence is the ASN.1 DER encoding of the type KRB-ERROR. The e-data field MUST be absent in the PA-FX-ERROR padata. All other fields should be the same as the outer KRB-ERROR. The client ignores the outer error and uses the combination of the padata in the KRBFastResponse and the error information in the PA-FX-ERROR.
KDC还必须在KRBFastResponse结构中包含PA-FX-ERROR padata项。此序列的padata value元素是KRB-ERROR类型的ASN.1 DER编码。PA-FX-ERROR padata中必须缺少电子数据字段。所有其他字段应与外部KRB-ERROR相同。客户端将忽略外部错误，并使用KRBFastResponse中的padata和PA-FX-error中的错误信息的组合。
PA-FX-ERROR 137
PA-FX-137错误
If the Kerberos FAST padata is included in the request but not included in the error reply, it is a matter of the local policy on the client to accept the information in the error message without integrity protection. However, the client SHOULD process the KDC errors as the result of the KDC's inability to accept the AP_REQ armor and potentially retry another request with a different armor when applicable. The Kerberos client MAY process an error message without a PA-FX-FAST-REPLY, if that is only intended to return better error information to the application, typically for trouble-shooting purposes.
如果请求中包含Kerberos FAST padata，但错误回复中不包含Kerberos FAST padata，则接受错误消息中的信息而不进行完整性保护是客户端的本地策略问题。但是，由于KDC无法接受AP_REQ铠装，客户机应处理KDC错误，并可能在适用时使用不同的铠装重试另一个请求。Kerberos客户端可能会在不使用PA-FX-FAST-REPLY的情况下处理错误消息，如果这只是为了向应用程序返回更好的错误信息，通常是为了解决问题。
In the cases where the e-data field of the KRB-ERROR message is expected to carry a TYPED-DATA [RFC4120] element, that information should be transmitted in a pa-data element within the KRBFastResponse
在KRB错误消息的e-data字段预计携带类型化数据[RFC4120]元素的情况下，该信息应在KRBFastResponse内的pa数据元素中传输
structure. The padata-type is the same as the data-type would be in the typed data element and the padata-value is the same as the data-value. As discussed in Section 7, data-types and padata-types are drawn from the same namespace. For example, the TD_TRUSTED_CERTIFIERS structure is expected to be in the KRB-ERROR message when the error code is KDC_ERR_CANT_VERIFY_CERTIFICATE [RFC4556].
结构padata类型与类型化数据元素中的数据类型相同，padata值与数据值相同。如第7节所述，数据类型和padata类型来自同一名称空间。例如，当错误代码为KDC_ERR_CANT_VERIFY_CERTIFICATE[RFC4556]时，TD_TRUSTED_CERTIFIERS结构应位于KRB-ERROR消息中。
Typically, a client will know that FAST is being used before a request containing PA-FX-FAST is sent. So, the outer AS request typically only includes one pa-data item: PA-FX-FAST. The client MAY include additional pa-data, but the KDC MUST ignore the outer request body and any padata besides PA-FX-FAST if and only if PA-FX-FAST is processed. In the case of the TGS request, the outer request should include PA-FX-FAST and PA-TGS-REQ.
通常，客户机会在发送包含PA-FX-FAST的请求之前知道FAST正在使用。因此，外部AS请求通常只包括一个pa数据项：pa-FX-FAST。客户机可能包括其他pa数据，但KDC必须忽略外部请求主体和除pa-FX-FAST之外的任何padata，前提是且仅当处理了pa-FX-FAST。对于TGS请求，外部请求应包括PA-FX-FAST和PA-TGS-REQ。
When an AS generates a response, all padata besides PA-FX-FAST should be included in PA-FX-FAST. The client MUST ignore other padata outside of PA-FX-FAST.
AS生成响应时，除PA-FX-FAST外的所有padata都应包含在PA-FX-FAST中。客户必须忽略PA-FX-FAST之外的其他padata。
The encrypted challenge FAST factor authenticates a client using the client's long-term key. This factor works similarly to the encrypted timestamp pre-authentication option described in [RFC4120]. The word "challenge" is used instead of "timestamp" because while the timestamp is used as an initial challenge, if the KDC and client do not have synchronized time, then the KDC can provide updated time to the client to use as a challenge. The client encrypts a structure containing a timestamp in the challenge key. The challenge key used by the client to send a message to the KDC is KRB-FX-CF2(armor_key,long_term_key, "clientchallengearmor", "challengelongterm"). The challenge key used by the KDC encrypting to the client is KRB-FX-CF2(armor_key, long_term_key, "kdcchallengearmor", "challengelongterm"). Because the armor key is fresh and random, the challenge key is fresh and random. The only purpose of the timestamp is to limit the validity of the authentication so that a request cannot be replayed. A client MAY base the timestamp on the KDC time in a KDC error and need not maintain accurate time synchronization itself. If a client bases its time on an untrusted source, an attacker may trick the client into producing an authentication request that is valid at some future time. The attacker may be able to use this authentication request to make it appear that a client has authenticated at that future time. If ticket-based armor is used, then the lifetime of the ticket will limit the window in which an attacker can make the client appear to
加密的质询快速因子使用客户端的长期密钥对客户端进行身份验证。该因子的工作原理与[RFC4120]中描述的加密时间戳预认证选项类似。使用“质询”一词代替“时间戳”，因为当时间戳用作初始质询时，如果KDC和客户端没有同步的时间，则KDC可以向客户端提供更新的时间以用作质询。客户端加密质询密钥中包含时间戳的结构。客户端用于向KDC发送消息的质询密钥为KRB-FX-CF2（armor_密钥、long_term_密钥、“ClientChallengerMor”、“ChallengelLongterm”）。KDC加密客户端使用的质询密钥是KRB-FX-CF2（armor_密钥、long_term_密钥、“KDCCchallengeArmor”、“challengelongterm”）。因为护甲钥匙是新的和随机的，所以挑战钥匙是新的和随机的。时间戳的唯一目的是限制身份验证的有效性，以便无法重播请求。客户机可以基于KDC错误中的KDC时间来设置时间戳，并且不需要保持准确的时间同步。如果客户端的时间基于不受信任的源，攻击者可能会诱使客户端在将来某个时间生成有效的身份验证请求。攻击者可能能够使用此身份验证请求使客户端在未来某个时间进行身份验证。如果使用了基于票据的防护，则票据的生存期将限制攻击者使客户端出现在其中的窗口
have authenticated. For many situations, the ability of an attacker to cause a client to appear to have authenticated is not a significant concern; the ability to avoid requiring time synchronization on clients is more valuable.
已验证。在许多情况下，攻击者使客户机看起来已通过身份验证的能力并不重要；避免在客户机上要求时间同步的能力更有价值。
The client sends a padata of type PA-ENCRYPTED-CHALLENGE. The corresponding padata-value contains the DER encoding of ASN.1 type EncryptedChallenge.
客户端发送PA-ENCRYPTED-CHALLENGE类型的padata。对应的padata值包含ASN.1类型EncryptedChallenge的DER编码。
EncryptedChallenge ::= EncryptedData
-- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
EncryptedChallenge ::= EncryptedData
-- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
PA-ENCRYPTED-CHALLENGE 138 KEY_USAGE_ENC_CHALLENGE_CLIENT 54 KEY_USAGE_ENC_CHALLENGE_KDC 55
PA-ENCRYPTED-CHALLENGE 138密钥使用密钥挑战客户端54密钥使用密钥挑战KDC 55
The client includes some timestamp reasonably close to the KDC's current time and encrypts it in the challenge key in a PA-ENC-TS-ENC structure (see Section 5.2.7.2 in RFC 4120). Clients MAY use the current time; doing so prevents the exposure where an attacker can cause a client to appear to authenticate in the future. The client sends the request including this factor.
客户机包括一些合理接近KDC当前时间的时间戳，并在PA-ENC-TS-ENC结构的质询密钥中对其进行加密（参见RFC 4120中的第5.2.7.2节）。客户可以使用当前时间；这样做可以防止攻击者可能导致客户端出现在将来进行身份验证的情况。客户端发送包含此因素的请求。
On receiving an AS-REQ containing the PA-ENCRYPTED-CHALLENGE FAST factor, the KDC decrypts the timestamp. If the decryption fails the KDC SHOULD return KDC_ERR_PREAUTH_FAILED, including PA-ETYPE-INFO2 in the KRBFastResponse in the error. The KDC confirms that the timestamp falls within its current clock skew returning KRB_APP_ERR_SKEW if not. The KDC then SHOULD check to see if the encrypted challenge is a replay. The KDC MUST NOT consider two encrypted challenges replays simply because the timestamps are the same; to be a replay, the ciphertext MUST be identical. Allowing clients to reuse timestamps avoids requiring that clients maintain state about which timestamps have been used.
在接收到包含PA加密质询快速因子的AS-REQ时，KDC解密时间戳。如果解密失败，KDC应返回KDC_ERR_PREAUTH_FAILED，包括错误中KRBFastResponse中的PA-ETYPE-INFO2。KDC确认时间戳在其当前时钟偏移范围内，如果没有，则返回KRB_APP_ERR_skew。然后KDC应该检查加密的质询是否是重播。KDC不能考虑两个加密的挑战重放，因为时间戳是相同的；要重播，密文必须相同。允许客户端重用时间戳避免了要求客户端维护已使用时间戳的状态。
If the KDC accepts the encrypted challenge, it MUST include a padata element of type PA-ENCRYPTED-CHALLENGE. The KDC encrypts its current time in the challenge key. The KDC MUST strengthen the reply key before issuing a ticket. The client MUST check that the timestamp decrypts properly. The client MAY check that the timestamp is within the window of acceptable clock skew for the client. The client MUST NOT require that the timestamp be identical to the timestamp in the issued credentials or the returned message.
如果KDC接受加密质询，它必须包含PA-encrypted-challenge类型的padata元素。KDC在质询密钥中加密其当前时间。KDC必须在发出票据之前增强应答密钥。客户端必须检查时间戳是否正确解密。客户机可以检查时间戳是否在客户机可接受的时钟偏移窗口内。客户端不得要求时间戳与已颁发的凭据或返回消息中的时间戳相同。
The encrypted challenge FAST factor provides the following facilities: Client Authentication and KDC Authentication. This FAST factor also takes advantage of the FAST facility to strengthen the reply key. It does not provide the Replace Reply Key facility. The Security Considerations section of this document provides an explanation why the security requirements are met.
加密质询快速因子提供以下功能：客户端身份验证和KDC身份验证。此快速因素还利用FAST功能来增强应答密钥。它不提供替换应答密钥功能。本文件的“安全注意事项”部分解释了满足安全要求的原因。
The encrypted challenge FAST factor can be useful in an authentication set. No pa-hint is defined because the only information needed by this mechanism is information contained in the PA-ETYPE-INFO2 pre-authentication data. KDCs are already required to send PA-ETYPE-INFO2. If KDCs were not required to send PA-ETYPE-INFO2 then that information would need to be part of a hint for encrypted challenge.
加密的质询快速因子在身份验证集中很有用。未定义pa提示，因为此机制所需的唯一信息是pa-ETYPE-INFO2预身份验证数据中包含的信息。KDC已经被要求发送PA-ETYPE-INFO2。如果KDC不需要发送PA-ETYPE-INFO2，那么该信息将需要成为加密质询提示的一部分。
Conforming implementations MUST support the encrypted challenge FAST factor.
一致性实现必须支持加密质询快速因子。
Implementations that have pre-authentication mechanisms offering significantly different strengths of client authentication MAY choose to keep track of the strength of the authentication used as an input into policy decisions. For example, some principals might require strong pre-authentication, while less sensitive principals can use relatively weak forms of pre-authentication like encrypted timestamp.
具有提供显著不同的客户端身份验证强度的预身份验证机制的实现可以选择跟踪身份验证的强度，并将其用作策略决策的输入。例如，某些主体可能需要强预身份验证，而不太敏感的主体可以使用相对较弱的预身份验证形式，如加密的时间戳。
An AuthorizationData data type AD-Authentication-Strength is defined for this purpose.
为此，定义了AuthorizationData数据类型AD身份验证强度。
AD-authentication-strength 70
广告认证强度70
The corresponding ad-data field contains the DER encoding of the pre-authentication data set as defined in Section 5.3. This set contains all the pre-authentication mechanisms that were used to authenticate the client. If only one pre-authentication mechanism was used to authenticate the client, the pre-authentication set contains one element. Unless otherwise specified, the hint and value fields of the members of this sequence MUST be empty. In order to permit mechanisms to carry additional information about strength in these fields in the future, clients and application servers MUST ignore non-empty hint and value fields for mechanisms unless the implementation is updated with the interpretation of these fields for a given pre-authentication mechanism in this authorization element.
相应的ad数据字段包含第5.3节中定义的预认证数据集的DER编码。此集合包含用于对客户端进行身份验证的所有预身份验证机制。如果只使用一个预身份验证机制对客户端进行身份验证，则预身份验证集包含一个元素。除非另有规定，否则此序列成员的提示和值字段必须为空。为了允许机制在将来携带关于这些字段强度的附加信息，客户端和应用程序服务器必须忽略机制的非空提示和值字段，除非使用此授权元素中给定预认证机制的这些字段的解释来更新实现。
The AD-authentication-strength element MUST be included in the AD-KDC-ISSUED container so that the KDC integrity protects its contents. This element can be ignored if it is unknown to the receiver.
AD身份验证强度元素必须包含在AD-KDC发布的容器中，以便KDC完整性保护其内容。如果接收器不知道该元素，则可以忽略该元素。
The pre-authentication framework and FAST involve using a number of Kerberos protocol constants. This section lists protocol constants first introduced in this specification drawn from registries not managed by IANA. Many of these registries would best be managed by IANA; that is a known issue that is out of scope for this document. The constants described in this section have been accounted for and will appear in the next revision of the Kerberos core specification or in a document creating IANA registries.
预认证框架和FAST涉及使用大量Kerberos协议常量。本节列出了本规范中首次引入的协议常量，这些常量来自非IANA管理的注册表。其中许多登记处最好由IANA管理；这是一个已知问题，超出了本文档的范围。本节中描述的常量已经过说明，将出现在下一版本的Kerberos核心规范或创建IANA注册表的文档中。
Section 7 creates IANA registries for a different set of constants used by the extensions described in this document.
第7节为本文档中描述的扩展所使用的一组不同的常量创建IANA注册表。
KDC_ERR_PREAUTH_EXPIRED 90 KDC_ERR_MORE_PREAUTH_DATA_REQUIRED 91 KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92 KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS 93
KDC_ERR_PREAUTH_过期90 KDC_ERR_MORE_PREAUTH_DATA_REQUIRED 91 KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92 KDC_ERR_UNKNOWN_CRITICAL_FAST_选项93
KEY_USAGE_FAST_REQ_CHKSUM 50 KEY_USAGE_FAST_ENC 51 KEY_USAGE_FAST_REP 52 KEY_USAGE_FAST_FINISHED 53 KEY_USAGE_ENC_CHALLENGE_CLIENT 54 KEY_USAGE_ENC_CHALLENGE_KDC 55
密钥使用率快速请求CHKSUM 50密钥使用率快速加密51密钥使用率快速加密代表52密钥使用率快速加密完成53密钥使用率加密挑战客户端54密钥使用率加密挑战KDC 55
AD-authentication-strength 70 AD-fx-fast-armor 71 AD-fx-fast-used 72
广告认证强度70 AD fx fast装甲71 AD fx fast使用72
PA-FX-COOKIE 133 PA-AUTHENTICATION-SET 134 PA-AUTH-SET-SELECTED 135 PA-FX-FAST 136 PA-FX-ERROR 137 PA-ENCRYPTED-CHALLENGE 138
PA-FX-COOKIE 133 PA-AUTHENTICATION-SET 134 PA-AUTH-SET-SELECTED 135 PA-FX-FAST 136 PA-FX-ERROR 137 PA-ENCRYPTED-CHALLENGE 138
This document creates a number of IANA registries. These registries are all located under Kerberos Parameters on http://www.iana.org. See [RFC5226] for descriptions of the registration policies used in this section.
本文档创建了许多IANA注册中心。这些注册表都位于上的Kerberos参数下http://www.iana.org. 有关本节中使用的注册策略的说明，请参见[RFC5226]。
RFC 4120 defines pre-authentication data, which can be included in a KDC request or response in order to authenticate the client or extend the protocol. In addition, it defines Typed-Data, which is an extension mechanism for errors. Both pre-authentication data and typed data are carried as a 32-bit signed integer along with an octet string. The encoding of typed data and pre-authentication data is slightly different. However, the types for pre-authentication data and typed-data are drawn from the same namespace. By convention, registrations starting with TD- are typed data and registrations starting with PA- are pre-authentication data. It is important that these data types be drawn from the same namespace, because some errors where it would be desirable to include typed data require the e-data field to be formatted as pre-authentication data.
RFC 4120定义了预认证数据，这些数据可以包括在KDC请求或响应中，以便认证客户端或扩展协议。此外，它还定义了类型化数据，这是错误的扩展机制。预认证数据和类型化数据都作为32位有符号整数和八位字节字符串携带。类型化数据和预验证数据的编码略有不同。但是，预身份验证数据和类型化数据的类型来自同一名称空间。按照惯例，以TD开头的注册是类型化数据，以PA开头的注册是预认证数据。从同一名称空间中提取这些数据类型是很重要的，因为某些需要包含类型化数据的错误需要将e-data字段格式化为预验证数据。
When Kerberos FAST is used, pre-authentication data encoding is always used.
使用Kerberos FAST时，始终使用预身份验证数据编码。
There is one apparently conflicting registration between typed data and pre-authentication data. PA-GET-FROM-TYPED-DATA and TD-PADATA are both assigned the value 22. However, this registration is simply a mechanism to include an element of the other encoding. The use of both should be deprecated.
在类型化数据和预认证数据之间存在一个明显冲突的注册。PA-GET-FROM-TYPED-DATA和TD-PADATA都被赋值为22。然而，这种注册只是一种包含其他编码元素的机制。不应同时使用这两种方法。
This document creates a registry for pre-authentication and typed data. The registration procedures are as follows. Expert review for pre-authentication mechanisms designed to authenticate users, KDCs, or establish the reply key. The expert first determines that the purpose of the method is to authenticate clients, KDCs, or to establish the reply key. If so, expert review is appropriate. The expert evaluates the security and interoperability of the specification.
此文档为预验证和键入的数据创建注册表。登记程序如下。专家评审用于验证用户、KDC或建立应答密钥的预验证机制。专家首先确定该方法的目的是验证客户端、KDC或建立应答密钥。如果是这样，专家审查是适当的。专家评估规范的安全性和互操作性。
IETF review is required if the expert believes that the pre-authentication method is broader than these three areas. Pre-authentication methods that change the Kerberos state machine or otherwise make significant changes to the Kerberos protocol should be Standards Track RFCs. A concern that a particular method needs to be a Standards Track RFC may be raised as an objection during IETF review.
如果专家认为预认证方法比这三个领域更广泛，则需要进行IETF审查。更改Kerberos状态机或以其他方式对Kerberos协议进行重大更改的预身份验证方法应该是标准跟踪RFC。在IETF审查期间，可能会提出一个问题，即特定方法需要成为标准跟踪RFC。
Several of the registrations indicated below were made at a time when the Kerberos protocol was less mature and do not meet the current requirements for this registry. These registrations are included in order to accurately document what is known about the use of these protocol code points and to avoid conflicts.
下面指出的几个注册是在Kerberos协议不太成熟且不满足此注册表的当前要求时进行的。包括这些注册是为了准确记录关于这些协议代码点使用的已知信息，并避免冲突。
Type Value Reference
----------------------------------------------------------------------
PA-TGS-REQ 1 [RFC4120]
PA-ENC-TIMESTAMP 2 [RFC4120]
PA-PW-SALT 3 [RFC4120]
[reserved] 4 [RFC6113]
PA-ENC-UNIX-TIME 5 (deprecated) [RFC4120]
PA-SANDIA-SECUREID 6 [RFC4120]
PA-SESAME 7 [RFC4120]
PA-OSF-DCE 8 [RFC4120]
PA-CYBERSAFE-SECUREID 9 [RFC4120]
PA-AFS3-SALT 10 [RFC4120] [RFC3961]
PA-ETYPE-INFO 11 [RFC4120]
PA-SAM-CHALLENGE 12 [KRB-WG.SAM]
PA-SAM-RESPONSE 13 [KRB-WG.SAM]
PA-PK-AS-REQ_OLD 14 [PK-INIT-1999]
PA-PK-AS-REP_OLD 15 [PK-INIT-1999]
PA-PK-AS-REQ 16 [RFC4556]
PA-PK-AS-REP 17 [RFC4556]
PA-PK-OCSP-RESPONSE 18 [RFC4557]
PA-ETYPE-INFO2 19 [RFC4120]
PA-USE-SPECIFIED-KVNO 20 [RFC4120]
PA-SVR-REFERRAL-INFO 20 [REFERRALS]
PA-SAM-REDIRECT 21 [KRB-WG.SAM]
PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) [RFC4120]
TD-PADATA 22 (embeds padata) [RFC4120]
PA-SAM-ETYPE-INFO 23 (sam/otp) [KRB-WG.SAM]
PA-ALT-PRINC 24 (crawdad@fnal.gov) [HW-AUTH]
PA-SERVER-REFERRAL 25 [REFERRALS]
PA-SAM-CHALLENGE2 30 (kenh@pobox.com) [KRB-WG.SAM]
PA-SAM-RESPONSE2 31 (kenh@pobox.com) [KRB-WG.SAM]
PA-EXTRA-TGT 41 Reserved extra TGT [RFC6113]
TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS
TD-KRB-PRINCIPAL 102 PrincipalName
TD-KRB-REALM 103 Realm
TD-TRUSTED-CERTIFIERS 104 [RFC4556]
TD-CERTIFICATE-INDEX 105 [RFC4556]
TD-APP-DEFINED-ERROR 106 Application specific [RFC6113]
TD-REQ-NONCE 107 INTEGER [RFC6113]
TD-REQ-SEQ 108 INTEGER [RFC6113]
TD_DH_PARAMETERS 109 [RFC4556]
TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY]
Type Value Reference
----------------------------------------------------------------------
PA-TGS-REQ 1 [RFC4120]
PA-ENC-TIMESTAMP 2 [RFC4120]
PA-PW-SALT 3 [RFC4120]
[reserved] 4 [RFC6113]
PA-ENC-UNIX-TIME 5 (deprecated) [RFC4120]
PA-SANDIA-SECUREID 6 [RFC4120]
PA-SESAME 7 [RFC4120]
PA-OSF-DCE 8 [RFC4120]
PA-CYBERSAFE-SECUREID 9 [RFC4120]
PA-AFS3-SALT 10 [RFC4120] [RFC3961]
PA-ETYPE-INFO 11 [RFC4120]
PA-SAM-CHALLENGE 12 [KRB-WG.SAM]
PA-SAM-RESPONSE 13 [KRB-WG.SAM]
PA-PK-AS-REQ_OLD 14 [PK-INIT-1999]
PA-PK-AS-REP_OLD 15 [PK-INIT-1999]
PA-PK-AS-REQ 16 [RFC4556]
PA-PK-AS-REP 17 [RFC4556]
PA-PK-OCSP-RESPONSE 18 [RFC4557]
PA-ETYPE-INFO2 19 [RFC4120]
PA-USE-SPECIFIED-KVNO 20 [RFC4120]
PA-SVR-REFERRAL-INFO 20 [REFERRALS]
PA-SAM-REDIRECT 21 [KRB-WG.SAM]
PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) [RFC4120]
TD-PADATA 22 (embeds padata) [RFC4120]
PA-SAM-ETYPE-INFO 23 (sam/otp) [KRB-WG.SAM]
PA-ALT-PRINC 24 (crawdad@fnal.gov) [HW-AUTH]
PA-SERVER-REFERRAL 25 [REFERRALS]
PA-SAM-CHALLENGE2 30 (kenh@pobox.com) [KRB-WG.SAM]
PA-SAM-RESPONSE2 31 (kenh@pobox.com) [KRB-WG.SAM]
PA-EXTRA-TGT 41 Reserved extra TGT [RFC6113]
TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS
TD-KRB-PRINCIPAL 102 PrincipalName
TD-KRB-REALM 103 Realm
TD-TRUSTED-CERTIFIERS 104 [RFC4556]
TD-CERTIFICATE-INDEX 105 [RFC4556]
TD-APP-DEFINED-ERROR 106 Application specific [RFC6113]
TD-REQ-NONCE 107 INTEGER [RFC6113]
TD-REQ-SEQ 108 INTEGER [RFC6113]
TD_DH_PARAMETERS 109 [RFC4556]
TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY]
TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY]
PA-PAC-REQUEST 128 [MS-KILE]
PA-FOR_USER 129 [MS-KILE]
PA-FOR-X509-USER 130 [MS-KILE]
PA-FOR-CHECK_DUPS 131 [MS-KILE]
PA-AS-CHECKSUM 132 [MS-KILE]
PA-FX-COOKIE 133 [RFC6113]
PA-AUTHENTICATION-SET 134 [RFC6113]
PA-AUTH-SET-SELECTED 135 [RFC6113]
PA-FX-FAST 136 [RFC6113]
PA-FX-ERROR 137 [RFC6113]
PA-ENCRYPTED-CHALLENGE 138 [RFC6113]
PA-OTP-CHALLENGE 141 (gareth.richards@rsa.com) [OTP-PREAUTH]
PA-OTP-REQUEST 142 (gareth.richards@rsa.com) [OTP-PREAUTH]
PA-OTP-CONFIRM 143 (gareth.richards@rsa.com) [OTP-PREAUTH]
PA-OTP-PIN-CHANGE 144 (gareth.richards@rsa.com) [OTP-PREAUTH]
PA-EPAK-AS-REQ 145 (sshock@gmail.com) [RFC6113]
PA-EPAK-AS-REP 146 (sshock@gmail.com) [RFC6113]
PA_PKINIT_KX 147 [RFC6112]
PA_PKU2U_NAME 148 [PKU2U]
PA-SUPPORTED-ETYPES 165 [MS-KILE]
PA-EXTENDED_ERROR 166 [MS-KILE]
TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY]
PA-PAC-REQUEST 128 [MS-KILE]
PA-FOR_USER 129 [MS-KILE]
PA-FOR-X509-USER 130 [MS-KILE]
PA-FOR-CHECK_DUPS 131 [MS-KILE]
PA-AS-CHECKSUM 132 [MS-KILE]
PA-FX-COOKIE 133 [RFC6113]
PA-AUTHENTICATION-SET 134 [RFC6113]
PA-AUTH-SET-SELECTED 135 [RFC6113]
PA-FX-FAST 136 [RFC6113]
PA-FX-ERROR 137 [RFC6113]
PA-ENCRYPTED-CHALLENGE 138 [RFC6113]
PA-OTP-CHALLENGE 141 (gareth.richards@rsa.com) [OTP-PREAUTH]
PA-OTP-REQUEST 142 (gareth.richards@rsa.com) [OTP-PREAUTH]
PA-OTP-CONFIRM 143 (gareth.richards@rsa.com) [OTP-PREAUTH]
PA-OTP-PIN-CHANGE 144 (gareth.richards@rsa.com) [OTP-PREAUTH]
PA-EPAK-AS-REQ 145 (sshock@gmail.com) [RFC6113]
PA-EPAK-AS-REP 146 (sshock@gmail.com) [RFC6113]
PA_PKINIT_KX 147 [RFC6112]
PA_PKU2U_NAME 148 [PKU2U]
PA-SUPPORTED-ETYPES 165 [MS-KILE]
PA-EXTENDED_ERROR 166 [MS-KILE]
FAST armor types are defined in Section 5.4.1. A FAST armor type is a signed 32-bit integer. FAST armor types are assigned by standards action.
第5.4.1节定义了快速装甲类型。快速装甲类型是有符号32位整数。快速装甲类型由标准行动分配。
Type Name Description
------------------------------------------------------------
0 Reserved.
1 FX_FAST_ARMOR_AP_REQUEST Ticket armor using an ap-req.
Type Name Description
------------------------------------------------------------
0 Reserved.
1 FX_FAST_ARMOR_AP_REQUEST Ticket armor using an ap-req.
A FAST request includes a set of bit flags to indicate additional options. Bits 0-15 are critical; other bits are non-critical. Assigning bits greater than 31 may require special support in implementations. Assignment of FAST options requires standards action.
FAST请求包括一组位标志，用于指示其他选项。位0-15是关键的；其他位是非关键位。在实现中，分配大于31的位可能需要特殊支持。快速选项的分配需要标准操作。
Type Name Description
-------------------------------------------------------------------
0 RESERVED Reserved for future expansion of this
field.
1 hide-client-names Requesting the KDC to hide client
names in the KDC response
16 kdc-follow-referrals Reserved.
Type Name Description
-------------------------------------------------------------------
0 RESERVED Reserved for future expansion of this
field.
1 hide-client-names Requesting the KDC to hide client
names in the KDC response
16 kdc-follow-referrals Reserved.
The kdc-referrals option in the Kerberos FAST padata requests the KDC to act as the client to follow referrals. This can overload the KDC. To limit the damages of denial of service using this option, KDCs MAY restrict the number of simultaneous active requests with this option for any given client principal.
Kerberos FAST padata中的kdc referrals选项请求kdc充当客户机来跟踪引用。这会使KDC过载。为了使用此选项限制拒绝服务造成的损害，KDCs可以使用此选项限制任何给定客户端主体的同时活动请求数。
Regarding the facilities provided by the Encrypted Challenge FAST factor, the challenge key is derived from the client secrets and because the client secrets are known only to the client and the KDC, the verification of the EncryptedChallenge structure proves the client's identity, the verification of the EncryptedChallenge structure in the KDC reply proves that the expected KDC responded. Therefore, the Encrypted Challenge FAST factor as a pre-authentication mechanism offers the following facilities: Client Authentication and KDC Authentication. There is no un-authenticated cleartext introduced by the Encrypted Challenge FAST factor.
关于加密质询快速因素提供的设施，质询密钥源自客户机密，并且由于客户机密仅为客户和KDC所知，因此对EncryptedChallenge结构的验证证明了客户的身份，对KDC应答中EncryptedChallenge结构的验证证明预期KDC已响应。因此，作为预身份验证机制的加密质询快速因素提供了以下功能：客户端身份验证和KDC身份验证。不存在加密质询快速因子引入的未经身份验证的明文。
FAST provides an encrypted tunnel over which pre-authentication conversations can take place. In addition, FAST optionally authenticates the KDC to the client. It is the responsibility of FAST factors to authenticate the client to the KDC. Care MUST be taken to design FAST factors such that they are bound to the conversation. If this is not done, a man-in-the-middle may be able to cut&paste a FAST factor from one conversation to another. The easiest way to do this is to bind each FAST factor to the armor key that is guaranteed to be unique for each conversation.
FAST提供了一个加密的隧道，通过该隧道可以进行预身份验证对话。此外，FAST还可以选择向客户端验证KDC。FAST factors负责向KDC验证客户端。必须注意设计快速因素，使其与对话相关联。如果不这样做，中间的一个人可能能够将一个快速因素从一个对话剪切粘贴到另一个对话。最简单的方法是将每个FAST factor绑定到armor密钥，该密钥保证每个对话都是唯一的。
The anonymous PKINIT mode for obtaining an armor ticket does not always authenticate the KDC to the client before the conversation begins. Tracking the KDC verified state guarantees that by the end of the conversation, the client has authenticated the KDC. However, FAST factor designers need to consider the implications of using their factor when the KDC has not yet been authenticated. If this proves problematic in an environment, then the particular FAST factor should not be used with anonymous PKINIT.
用于获取armor票证的匿名PKINIT模式并不总是在对话开始之前向客户端验证KDC。跟踪KDC验证状态可以保证在会话结束时，客户端已经对KDC进行了身份验证。然而，当KDC尚未被认证时，快速因子设计者需要考虑使用其因子的含义。如果这在环境中被证明是有问题的，那么特定的快速因素不应该与匿名PKINIT一起使用。
Existing pre-authentication mechanisms are believed to be at least as secure when used with FAST as they are when used outside of FAST.
现有的预认证机制被认为在与FAST一起使用时至少与在FAST之外使用时一样安全。
One part of this security is making sure that when pre-authentication methods checksum the request, they checksum the inner request rather than the outer request. If the mechanism checksummed the outer request, a man-in-the-middle could observe it outside a FAST tunnel and then cut&paste it into a FAST exchange where the inner rather than outer request would be used to select attributes of the issued ticket. Such attacks would typically invalidate auditing information or create a situation where the client and KDC disagree about what ticket is issued. However, such attacks are unlikely to allow an attacker who would not be able to authenticate as a principal to do so. Even so, FAST is believed to defend against these attacks in existing legacy mechanism. However, since there is no standard for how legacy mechanisms bind the request to the pre-authentication or provide integrity protection, security analysis can be difficult. In some cases, FAST may significantly improve the integrity protection of legacy mechanisms.
这种安全性的一部分是确保当预认证方法对请求进行校验和时，它们对内部请求而不是外部请求进行校验和。如果该机制对外部请求进行校验和，中间的人可以在快速通道外观察它，然后将其剪切并粘贴到一个快速交换中，在该交换中，将使用内部而不是外部请求来选择已发行票据的属性。此类攻击通常会使审核信息无效，或造成客户机和KDC对发出的票据不一致的情况。但是，此类攻击不太可能允许无法作为主体进行身份验证的攻击者进行身份验证。即使如此，FAST被认为可以在现有的遗留机制中抵御这些攻击。但是，由于没有关于遗留机制如何将请求绑定到预身份验证或提供完整性保护的标准，因此安全性分析可能很困难。在某些情况下，FAST可以显著提高遗留机制的完整性保护。
The security of the TGS exchange depends on authenticating the client to the KDC. In the AS exchange, this is done using pre-authentication data or FAST factors. In the TGS exchange, this is done by presenting a TGT and by using the session (or sub-session) key in constructing the request. Because FAST uses a request body in the inner request, encrypted in the armor key, rather than the request body in the outer request, it is critical that establishing the armor key be tied to the authentication of the client to the KDC. If this is not done, an attacker could manipulate the options requested in the TGS request, for example, requesting a ticket with different validity or addresses. The easiest way to bind the armor key to the authentication of the client to the KDC is for the armor key to depend on the sub-session key of the TGT. This is done with the implicit TGS armor supported by this specification. Future armor types designed for use with the TGS MUST either bind their armor keys to the TGT or provide another mechanism to authenticate the client to the KDC.
TGS交换的安全性取决于向KDC验证客户端。在AS交换中，这是使用预验证数据或FAST因素来完成的。在TGS交换中，这是通过呈现TGT并在构造请求时使用会话（或子会话）键来完成的。由于FAST在内部请求中使用一个请求体，并在armor密钥中加密，而不是在外部请求中使用请求体，因此建立armor密钥必须与客户端对KDC的身份验证相关联。如果不这样做，攻击者可能会操纵TGS请求中请求的选项，例如，请求具有不同有效性或地址的票证。将armor密钥绑定到KDC客户端身份验证的最简单方法是armor密钥依赖于TGT的子会话密钥。这是通过本规范支持的隐式TGS装甲实现的。设计用于TGS的未来装甲类型必须将其装甲密钥绑定到TGT，或者提供另一种机制来向KDC验证客户端。
Sam Hartman would like to thank the MIT Kerberos Consortium for its funding of his time on this project.
Sam Hartman感谢麻省理工学院Kerberos财团为他在该项目上花费的时间提供资金。
Several suggestions from Jeffrey Hutzelman based on early revisions of this documents led to significant improvements of this document.
Jeffrey Hutzelman根据本文件早期修订提出的几项建议导致了本文件的重大改进。
The proposal to ask one KDC to chase down the referrals and return the final ticket is based on requirements in [CROSS].
要求一个KDC追踪转介并返回最终票证的建议基于[CROSS]中的要求。
Joel Weber had a proposal for a mechanism similar to FAST that created a protected tunnel for Kerberos pre-authentication.
Joel Weber提出了一个类似FAST的机制，为Kerberos预身份验证创建了一个受保护的隧道。
Srinivas Cheruku and Greg Hudson provided valuable review comments.
Srinivas Cheruku和Greg Hudson提供了宝贵的审查意见。
[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月。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年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月。
[ALG-AGILITY] Astrand, L. and L. Zhu, "PK-INIT algorithm agility", Work in Progress, August 2008.
[ALG-AGILITY]Astrand，L.和L.Zhu，“PK-INIT算法敏捷性”，正在进行的工作，2008年8月。
[CROSS] Sakane, S., Zrelli, S., and M. Ishiyama , "Problem statement on the cross-realm operation of Kerberos in a specific system", Work in Progress, July 2007.
[CROSS]Sakane，S.，Zrelli，S.，和M.Ishiyama，“特定系统中Kerberos跨领域操作的问题陈述”，正在进行的工作，2007年7月。
[EKE] Bellovin, S. and M. Merritt, "Augmented Encrypted Key Exchange: A Password-Based Protocol Secure Against Dictionary Attacks and Password File Compromise, Proceedings of the 1st ACM Conference on Computer and Communications Security, ACM Press.", November 1993.
[EKE]Bellovin，S.和M.Merritt，“增强加密密钥交换：防止字典攻击和密码文件泄露的基于密码的协议，第一届ACM计算机和通信安全会议记录，ACM出版社”，1993年11月。
[HW-AUTH] Crawford, M., "Passwordless Initial Authentication to Kerberos by Hardware Preauthentication", Work in Progress, October 2006.
[HW-AUTH]Crawford，M.，“通过硬件预身份验证对Kerberos进行无密码初始身份验证”，正在进行的工作，2006年10月。
[IEEE1363.2] IEEE, "IEEE P1363.2: Password-Based Public-Key Cryptography", 2004.
[IEEE1363.2]IEEE，“IEEE P1363.2：基于密码的公钥密码术”，2004年。
[KRB-WG.SAM] Hornstein, K., Renard, K., Neuman, C., and G. Zorn, "Integrating Single-use Authentication Mechanisms with Kerberos", Work in Progress, July 2004.
[KRB-WG.SAM]Hornstein，K.，Renard，K.，Neuman，C.，和G.Zorn，“将单次使用身份验证机制与Kerberos集成”，正在进行的工作，2004年7月。
[MS-KILE] Microsoft, "Kerberos Protocol Extensions", <http:// msdn.microsoft.com/en-us/library/cc206927.aspx>.
[MS-KILE]微软，“Kerberos协议扩展”，<http://msdn.Microsoft.com/en-us/library/cc206927.aspx>。
[OTP-PREAUTH] Richards, G., "OTP Pre-authentication", Work in Progress, February 2011.
[OTP-PREAUTH]Richards，G.，“OTP预认证”，正在进行的工作，2011年2月。
[PK-INIT-1999] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, J., and J. Trostle, "Public Key Cryptography for Initial Authentication in Kerberos", Work in Progress, July 1999.
[PK-INIT-1999]Tung，B.，Neuman，C.，Hur，M.，Medvinsky，A.，Medvinsky，S.，Wray，J.，和J.Trostle，“Kerberos中用于初始身份验证的公钥加密”，正在进行的工作，1999年7月。
[PKU2U] Zhu, L., Altman, J., and N. Williams, "Public Key Cryptography Based User-to-User Authentication - (PKU2U)", Work in Progress, November 2008.
[PKU2U]Zhu，L.，Altman，J.，和N.Williams，“基于公钥密码的用户对用户身份验证（PKU2U）”，正在进行的工作，2008年11月。
[REFERRALS] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm Referrals", Work in Progress, March 2011.
[转介]Hartman，S.，Ed.，Raeburn，K.，和L.Zhu，“Kerberos主体名称规范化和KDC生成的跨领域转介”，正在进行的工作，2011年3月。
[RFC4557] Zhu, L., Jaganathan, K., and N. Williams, "Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4557, June 2006.
[RFC4557]Zhu，L.，Jaganathan，K.，和N.Williams，“在线证书状态协议（OCSP）支持Kerberos（PKINIT）初始身份验证的公钥加密”，RFC 4557，2006年6月。
This informative appendix presents test vectors for the KRB-FX-CF2 function. Test vectors are presented for several encryption types. In all cases, the first key (k1) is the result of string-to-key("key1", "key1", default_parameters) and the second key (k2) is the result of string-to-key("key2", "key2", default_parameters). Both keys are of the same enctype. The presented test vector is the hexadecimal encoding of the key produced by KRB-FX-CF2(k1, k2, "a", "b"). The peppers are one-octet ASCII strings.
本资料性附录介绍了KRB-FX-CF2功能的测试向量。给出了几种加密类型的测试向量。在所有情况下，第一个键（k1）是字符串到键（“键1”、“键1”，默认_参数）的结果，第二个键（k2）是字符串到键（“键2”、“键2”，默认_参数）的结果。两个键的类型相同。给出的测试向量是由KRB-FX-CF2生成的密钥的十六进制编码（k1，k2，“a”，“b”）。peppers是一个八位ASCII字符串。
In performing interoperability testing, there was significant ambiguity surrounding [RFC3961] pseudo-random operations. These test vectors assume that the AES pseudo-random operation is aes-ecb(trunc128(sha-1(input))) where trunc128 truncates its input to 128 bits. The 3DES pseudo-random operation is assumed to be des3-cbc(trunc128(sha-1(input))). The DES pseudo-random operation is assumed to be des-cbc(md5(input)). As specified in RFC 4757, the RC4 pseudo-random operation is hmac-sha1(input).
在执行互操作性测试时，[RFC3961]伪随机操作存在明显的模糊性。这些测试向量假设AES伪随机操作是AES ecb（trunc128（sha-1（输入）），其中trunc128将其输入截断为128位。假设3DES伪随机操作为des3 cbc（trunc128（sha-1（输入）））。DES伪随机操作被假定为DES cbc（md5（输入））。按照RFC 4757的规定，RC4伪随机操作为hmac-sha1（输入）。
Interoperability testing also demonstrated ambiguity surrounding the DES random-to-key operation. The random-to-key operation is assumed to be distribute 56 bits into high-7-bits of 8 octets and generate parity.
互操作性测试还证明了DES随机键操作的模糊性。假设随机键操作将56位分配到8个八位字节的高7位，并生成奇偶校验。
These test vectors were produced with revision 22359 of the MIT Kerberos sources. The AES 256 and AES 128 test vectors have been confirmed by multiple other implementors. The RC4 test vectors have been confirmed by one other implementor. The DES and triple DES test vectors have not been confirmed.
这些测试向量是根据MIT Kerberos源的22359版本生成的。AES 256和AES 128测试向量已由多个其他实现者确认。RC4测试向量已由另一个实施者确认。DES和三重DES测试向量尚未确认。
aes 128 (enctype 17): 97df97e4b798b29eb31ed7280287a92a
AES256 (enctype 18): 4d6ca4e629785c1f01baf55e2e548566
b9617ae3a96868c337cb93b5e72b1c7b
DES (enctype 1): 43bae3738c9467e6
3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01
RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672
aes 128 (enctype 17): 97df97e4b798b29eb31ed7280287a92a
AES256 (enctype 18): 4d6ca4e629785c1f01baf55e2e548566
b9617ae3a96868c337cb93b5e72b1c7b
DES (enctype 1): 43bae3738c9467e6
3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01
RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672
KerberosPreauthFramework {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) preauth-framework(3)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
KerberosPreauthFramework {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) preauth-framework(3)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum, Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY, Microseconds, KerberosFlags, UInt32 FROM KerberosV5Spec2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) modules(4) krb5spec2(2) }; -- as defined in RFC 4120.
将KerberosTime、PrincipalName、Realm、EncryptionKey、Checksum、Int32、EncryptedData、PA-ENC-TS-ENC、PA-DATA、KDC-REQ-BODY、微秒、KerberosFlags、UInt32从KerberosV5Spec2{iso（1）确定的组织（3）国防部（6）互联网（1）安全（5）kerberosV5（2）模块（4）krb5spec2（2）}；--如RFC 4120中所定义。
PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM
PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
pa-type [0] Int32,
-- same as padata-type.
pa-hint [1] OCTET STRING OPTIONAL,
pa-value [2] OCTET STRING OPTIONAL,
...
}
PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE {
pa-type [0] Int32,
-- same as padata-type.
pa-hint [1] OCTET STRING OPTIONAL,
pa-value [2] OCTET STRING OPTIONAL,
...
}
KrbFastArmor ::= SEQUENCE {
armor-type [0] Int32,
-- Type of the armor.
armor-value [1] OCTET STRING,
-- Value of the armor.
...
}
KrbFastArmor ::= SEQUENCE {
armor-type [0] Int32,
-- Type of the armor.
armor-value [1] OCTET STRING,
-- Value of the armor.
...
}
PA-FX-FAST-REQUEST ::= CHOICE {
armored-data [0] KrbFastArmoredReq,
...
}
PA-FX-FAST-REQUEST ::= CHOICE {
armored-data [0] KrbFastArmoredReq,
...
}
KrbFastArmoredReq ::= SEQUENCE {
armor [0] KrbFastArmor OPTIONAL,
-- Contains the armor that identifies the armor key.
-- MUST be present in AS-REQ.
req-checksum [1] Checksum,
-- For AS, contains the checksum performed over the type
-- KDC-REQ-BODY for the req-body field of the KDC-REQ
-- structure;
-- For TGS, contains the checksum performed over the type
KrbFastArmoredReq ::= SEQUENCE {
armor [0] KrbFastArmor OPTIONAL,
-- Contains the armor that identifies the armor key.
-- MUST be present in AS-REQ.
req-checksum [1] Checksum,
-- For AS, contains the checksum performed over the type
-- KDC-REQ-BODY for the req-body field of the KDC-REQ
-- structure;
-- For TGS, contains the checksum performed over the type
-- AP-REQ in the PA-TGS-REQ padata.
-- The checksum key is the armor key, the checksum
-- type is the required checksum type for the enctype of
-- the armor key, and the key usage number is
-- KEY_USAGE_FAST_REQ_CHKSUM.
enc-fast-req [2] EncryptedData, -- KrbFastReq --
-- The encryption key is the armor key, and the key usage
-- number is KEY_USAGE_FAST_ENC.
...
}
-- AP-REQ in the PA-TGS-REQ padata.
-- The checksum key is the armor key, the checksum
-- type is the required checksum type for the enctype of
-- the armor key, and the key usage number is
-- KEY_USAGE_FAST_REQ_CHKSUM.
enc-fast-req [2] EncryptedData, -- KrbFastReq --
-- The encryption key is the armor key, and the key usage
-- number is KEY_USAGE_FAST_ENC.
...
}
KrbFastReq ::= SEQUENCE {
fast-options [0] FastOptions,
-- Additional options.
padata [1] SEQUENCE OF PA-DATA,
-- padata typed holes.
req-body [2] KDC-REQ-BODY,
-- Contains the KDC request body as defined in Section
-- 5.4.1 of [RFC4120].
-- This req-body field is preferred over the outer field
-- in the KDC request.
...
}
KrbFastReq ::= SEQUENCE {
fast-options [0] FastOptions,
-- Additional options.
padata [1] SEQUENCE OF PA-DATA,
-- padata typed holes.
req-body [2] KDC-REQ-BODY,
-- Contains the KDC request body as defined in Section
-- 5.4.1 of [RFC4120].
-- This req-body field is preferred over the outer field
-- in the KDC request.
...
}
FastOptions ::= KerberosFlags
-- reserved(0),
-- hide-client-names(1),
-- kdc-follow-referrals(16)
FastOptions ::= KerberosFlags
-- reserved(0),
-- hide-client-names(1),
-- kdc-follow-referrals(16)
PA-FX-FAST-REPLY ::= CHOICE {
armored-data [0] KrbFastArmoredRep,
...
}
PA-FX-FAST-REPLY ::= CHOICE {
armored-data [0] KrbFastArmoredRep,
...
}
KrbFastArmoredRep ::= SEQUENCE {
enc-fast-rep [0] EncryptedData, -- KrbFastResponse --
-- The encryption key is the armor key in the request, and
-- the key usage number is KEY_USAGE_FAST_REP.
...
}
KrbFastArmoredRep ::= SEQUENCE {
enc-fast-rep [0] EncryptedData, -- KrbFastResponse --
-- The encryption key is the armor key in the request, and
-- the key usage number is KEY_USAGE_FAST_REP.
...
}
KrbFastResponse ::= SEQUENCE {
padata [0] SEQUENCE OF PA-DATA,
-- padata typed holes.
strengthen-key [1] EncryptionKey OPTIONAL,
-- This, if present, strengthens the reply key for AS and
-- TGS. MUST be present for TGS
-- MUST be absent in KRB-ERROR.
KrbFastResponse ::= SEQUENCE {
padata [0] SEQUENCE OF PA-DATA,
-- padata typed holes.
strengthen-key [1] EncryptionKey OPTIONAL,
-- This, if present, strengthens the reply key for AS and
-- TGS. MUST be present for TGS
-- MUST be absent in KRB-ERROR.
finished [2] KrbFastFinished OPTIONAL,
-- Present in AS or TGS reply; absent otherwise.
nonce [3] UInt32,
-- Nonce from the client request.
...
}
finished [2] KrbFastFinished OPTIONAL,
-- Present in AS or TGS reply; absent otherwise.
nonce [3] UInt32,
-- Nonce from the client request.
...
}
KrbFastFinished ::= SEQUENCE {
timestamp [0] KerberosTime,
usec [1] Microseconds,
-- timestamp and usec represent the time on the KDC when
-- the reply was generated.
crealm [2] Realm,
cname [3] PrincipalName,
-- Contains the client realm and the client name.
ticket-checksum [4] Checksum,
-- checksum of the ticket in the KDC-REP using the armor
-- and the key usage is KEY_USAGE_FAST_FINISH.
-- The checksum type is the required checksum type
-- of the armor key.
...
}
KrbFastFinished ::= SEQUENCE {
timestamp [0] KerberosTime,
usec [1] Microseconds,
-- timestamp and usec represent the time on the KDC when
-- the reply was generated.
crealm [2] Realm,
cname [3] PrincipalName,
-- Contains the client realm and the client name.
ticket-checksum [4] Checksum,
-- checksum of the ticket in the KDC-REP using the armor
-- and the key usage is KEY_USAGE_FAST_FINISH.
-- The checksum type is the required checksum type
-- of the armor key.
...
}
EncryptedChallenge ::= EncryptedData
-- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
END
EncryptedChallenge ::= EncryptedData
-- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
END
Authors' Addresses
作者地址
Sam Hartman Painless Security
山姆·哈特曼无痛安全
EMail: hartmans-ietf@mit.edu
EMail: hartmans-ietf@mit.edu
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Larry Zhu微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: larry.zhu@microsoft.com
EMail: larry.zhu@microsoft.com