Internet Engineering Task Force (IETF) S. Hartman, Ed.
Request for Comments: 6806 Painless Security
Updates: 4120 K. Raeburn
Category: Standards Track MIT
ISSN: 2070-1721 L. Zhu
Microsoft Corporation
November 2012
Internet Engineering Task Force (IETF) S. Hartman, Ed.
Request for Comments: 6806 Painless Security
Updates: 4120 K. Raeburn
Category: Standards Track MIT
ISSN: 2070-1721 L. Zhu
Microsoft Corporation
November 2012
Kerberos Principal Name Canonicalization and Cross-Realm Referrals
Kerberos主体名称规范化和跨域引用
Abstract
摘要
This memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm Ticket-Granting Ticket (TGT) to another realm on the referral path. The clients will use this referral information to reach the realm of the target principal and then receive the ticket. This memo also provides a mechanism for verifying that a request has not been tampered with in transit. This memo updates RFC 4120.
此备忘录记录了当客户端没有关于用户或服务领域的详细配置信息时，Kerberos密钥分发中心（KDC）响应客户端对Kerberos票证的请求的方法。KDC将通过将引用错误或跨域票证授予票证（TGT）返回到引用路径上的另一个域来处理对其他域中主体的请求。客户端将使用此转介信息到达目标主体的领域，然后接收票据。此备忘录还提供了一种机制，用于验证请求在传输过程中未被篡改。本备忘录更新了RFC 4120。
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/rfc6806.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6806.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
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.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Requesting a Referral . . . . . . . . . . . . . . . . . . . . 4
4. Realm Organization Model . . . . . . . . . . . . . . . . . . . 5
4.1. Trust Assumptions . . . . . . . . . . . . . . . . . . . . 5
5. Enterprise Principal Name Type . . . . . . . . . . . . . . . . 6
6. Name Canonicalization . . . . . . . . . . . . . . . . . . . . 7
7. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 9
8. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 10
9. Cross-Realm Routing . . . . . . . . . . . . . . . . . . . . . 11
10. Caching Information . . . . . . . . . . . . . . . . . . . . . 11
11. Negotiation of FAST and Detecting Modified Requests . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13.1. Shared-Password Case . . . . . . . . . . . . . . . . . . . 16
13.2. Pre-Authentication Data . . . . . . . . . . . . . . . . . 16
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
15.1. Normative References . . . . . . . . . . . . . . . . . . . 17
15.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Compatibility with Earlier Implementations of
Name Canonicalization . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Requesting a Referral . . . . . . . . . . . . . . . . . . . . 4
4. Realm Organization Model . . . . . . . . . . . . . . . . . . . 5
4.1. Trust Assumptions . . . . . . . . . . . . . . . . . . . . 5
5. Enterprise Principal Name Type . . . . . . . . . . . . . . . . 6
6. Name Canonicalization . . . . . . . . . . . . . . . . . . . . 7
7. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 9
8. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 10
9. Cross-Realm Routing . . . . . . . . . . . . . . . . . . . . . 11
10. Caching Information . . . . . . . . . . . . . . . . . . . . . 11
11. Negotiation of FAST and Detecting Modified Requests . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13.1. Shared-Password Case . . . . . . . . . . . . . . . . . . . 16
13.2. Pre-Authentication Data . . . . . . . . . . . . . . . . . 16
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
15.1. Normative References . . . . . . . . . . . . . . . . . . . 17
15.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Compatibility with Earlier Implementations of
Name Canonicalization . . . . . . . . . . . . . . . . 18
Current implementations of the Kerberos Authentication Service (AS) and Ticket-Granting Service (TGS) protocols, as defined in [RFC4120], use principal names constructed from a known user or service name and realm. A service name is typically constructed from a name of the service and the DNS host name of the computer that is providing the service. Many existing deployments of Kerberos use a single Kerberos realm where all users and services would be using the same realm. However, in an environment where there are multiple Kerberos realms, the client needs to be able to determine what realm a particular user or service is in before making an AS or TGS request. Traditionally, this requires client configuration to make this possible.
[RFC4120]中定义的Kerberos身份验证服务（AS）和票证授予服务（TGS）协议的当前实现使用由已知用户或服务名称和领域构造的主体名称。服务名称通常由服务名称和提供服务的计算机的DNS主机名构成。许多现有的Kerberos部署使用单个Kerberos领域，其中所有用户和服务都将使用同一领域。但是，在存在多个Kerberos领域的环境中，客户机需要能够在发出AS或TGS请求之前确定特定用户或服务所在的领域。传统上，这需要客户端配置才能实现。
When having to deal with multiple realms, users are forced to know what realm they are in before they can obtain a Ticket-Granting Ticket (TGT) with an AS request. However, in many cases, the user would like to use a more familiar name that is not directly related to the realm of their Kerberos principal name. A good example of this is an email name in the style described in [RFC5322]. This document describes a mechanism that would allow a user to specify a user principal name that is an alias for the user's Kerberos principal name. In practice, this would be the name that the user specifies to obtain a TGT from a Kerberos KDC. The user principal name no longer has a direct relationship with the Kerberos principal or realm. Thus, the administrator is able to move the user's principal to other realms without the user having to know that it happened.
当必须处理多个领域时，用户必须知道他们所处的领域，然后才能通过AS请求获得票证授予票证（TGT）。但是，在许多情况下，用户希望使用与其Kerberos主体名称领域没有直接关系的更熟悉的名称。一个很好的例子是采用[RFC5322]中所述样式的电子邮件名称。本文档描述了一种机制，允许用户指定用户主体名称，该名称是用户Kerberos主体名称的别名。实际上，这是用户指定从Kerberos KDC获取TGT的名称。用户主体名称不再与Kerberos主体或领域有直接关系。因此，管理员能够将用户的主体移动到其他领域，而用户不必知道它发生了。
Once a TGT has been obtained, the user would like to be able to access services in any Kerberos realm for which there is an authentication path from the realm of their principal. To do this requires that the client be able to determine what realm the target service principal is in before making the TGS request. Current implementations of Kerberos typically have a table that maps DNS host names to corresponding Kerberos realms. The user-supplied host name or its domain component is looked up in this table (often using the result of some form of host name lookup performed with insecure DNS queries, in violation of [RFC4120]). The corresponding realm is then used to complete the target service principal name. Even if insecure DNS queries were not used, managing this table is problematic.
一旦获得TGT，用户希望能够访问任何Kerberos领域中的服务，其中有来自其主体领域的身份验证路径。要做到这一点，客户机必须能够在发出TGS请求之前确定目标服务主体所在的领域。当前的Kerberos实现通常有一个将DNS主机名映射到相应Kerberos领域的表。在此表中查找用户提供的主机名或其域组件（通常使用不安全DNS查询执行的某种形式的主机名查找结果，违反[RFC4120]）。然后使用相应的领域来完成目标服务主体名称。即使未使用不安全的DNS查询，管理此表也是有问题的。
This traditional mechanism requires that each client have very detailed configuration information about the hosts that are providing services and their corresponding realms. Having client-side configuration information can be very costly from an administration point of view -- especially if there are many realms and computers in the environment.
这种传统的机制要求每个客户机都有关于提供服务的主机及其相应领域的非常详细的配置信息。从管理的角度来看，拥有客户端配置信息的成本非常高——特别是在环境中有许多领域和计算机的情况下。
This memo proposes a solution for these problems and simplifies administration by minimizing the configuration information needed on each computer using Kerberos. Specifically, it describes a mechanism to allow the KDC to handle canonicalization of names, provide for principal aliases for users and services, and allow the KDC to determine the trusted realm authentication path by being able to generate referrals to other realms in order to locate principals.
本备忘录针对这些问题提出了一个解决方案，并通过最小化使用Kerberos的每台计算机上所需的配置信息来简化管理。具体地说，它描述了一种机制，允许KDC处理名称的规范化，为用户和服务提供主体别名，并允许KDC通过生成对其他领域的引用来确定可信领域身份验证路径，以便定位主体。
Two kinds of KDC referrals are introduced in this memo:
本备忘录中介绍了两种KDC转介：
1. Client referrals, in which the client doesn't know which realm contains a user account.
1. 客户端引用，客户端不知道哪个领域包含用户帐户。
2. Server referrals, in which the client doesn't know which realm contains a server account.
2. 服务器引用，客户端不知道哪个领域包含服务器帐户。
These two types of referrals introduce new opportunities for an attacker. In order to avoid these attacks, a mechanism is provided to protect the integrity of the request between the client and KDC. This mechanism complements the Flexible Authentication Secure Tunnels (FAST) facility provided in [RFC6113]. A mechanism is provided to negotiate the availability of FAST. Among other benefits, this can be used to protect errors generated by the referral process.
这两种类型的转介为攻击者带来了新的机会。为了避免这些攻击，提供了一种机制来保护客户端和KDC之间请求的完整性。该机制补充了[RFC6113]中提供的灵活身份验证安全隧道（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]中所述进行解释。
In order to request referrals as defined in later sections, the Kerberos client MUST explicitly request the "canonicalize" KDC option (bit 15) [RFC4120] for the AS-REQ or TGS-REQ. This flag indicates to the KDC that the client is prepared to receive a reply that contains a principal name other than the one requested.
为了请求后面章节中定义的引用，Kerberos客户端必须明确请求as-REQ或TGS-REQ的“规范化”KDC选项（第15位）[RFC4120]。此标志向KDC指示客户机准备接收包含主体名称而非请求名称的回复。
KDCOptions ::= KerberosFlags
-- canonicalize (15)
-- other KDCOptions values omitted
KDCOptions ::= KerberosFlags
-- canonicalize (15)
-- other KDCOptions values omitted
When sending names with the "canonicalize" KDC option, the client should expect that names in the KDC's reply MAY be different than the name in the request. A referral TGT is a cross-realm TGT that is returned with the server name of the ticket being different from the server name in the request [RFC4120].
当使用“canonicalize”KDC选项发送名称时，客户机应该期望KDC回复中的名称可能与请求中的名称不同。引用TGT是一种跨域TGT，返回时票证的服务器名称与请求[RFC4120]中的服务器名称不同。
This memo assumes that the world of principals is arranged on multiple levels: the realm, the enterprise, and the world. A KDC may issue tickets for any principal in its realm or cross-realm tickets for realms with which it has a direct cross-realm relationship. The KDC also has access to a trusted name service that can resolve any name from within its enterprise into a realm closer along the authentication path to the service. This trusted name service removes the need to use an untrusted DNS lookup for name resolution.
本备忘录假设主体世界被安排在多个层次上：领域、企业和世界。KDC可以为其领域中的任何主体颁发票证，也可以为与其有直接跨领域关系的领域颁发跨领域票证。KDC还可以访问受信任的名称服务，该服务可以将其企业内的任何名称解析为更靠近该服务的身份验证路径的领域。此受信任的名称服务消除了使用不受信任的DNS查找进行名称解析的需要。
For example, consider the following configuration, where lines indicate cross-realm relationships:
例如，考虑以下配置，其中行表示跨域关系：
EXAMPLE.COM
/ \
/ \
ADMIN.EXAMPLE.COM DEV.EXAMPLE.COM
EXAMPLE.COM
/ \
/ \
ADMIN.EXAMPLE.COM DEV.EXAMPLE.COM
In this configuration, all users in the EXAMPLE.COM enterprise could have principal names, such as alice@EXAMPLE.COM, with the same realm portion. In addition, servers at EXAMPLE.COM should be able to have DNS host names from any DNS domain independent of what Kerberos realm their principals reside in.
在此配置中，EXAMPLE.COM企业中的所有用户都可以有主体名称，例如alice@EXAMPLE.COM，具有相同的领域部分。此外，EXAMPLE.COM上的服务器应该能够拥有来自任何DNS域的DNS主机名，而与它们的主体所在的Kerberos域无关。
Two realms participate in any cross-realm relationship: an issuing realm issues a cross-realm ticket, and a consuming realm uses this ticket. There is a degree of trust of the issuing realm by the consuming realm implied by this relationship. Whenever a service in the consuming realm permits an authentication path containing the issuing realm, that service trusts the issuing realm to accurately represent the identity of the authenticated principal and any information about the transited path. If the consuming realm's KDC sets the transited policy checked flag, the KDC is making the same trust assumption that a service would.
两个领域参与任何跨领域关系：一个发布领域发布跨领域票证，一个消费领域使用该票证。这种关系所隐含的消费领域对发行领域有一定程度的信任。每当消费领域中的服务允许包含发布领域的身份验证路径时，该服务就会信任发布领域来准确地表示经过身份验证的主体的身份以及有关传输路径的任何信息。如果消费领域的KDC设置transited policy checked标志，则KDC将做出与服务相同的信任假设。
This trust is transitive across a multi-hop authentication path. The service's realm trusts each hop along the authentication path closer to the client to accurately represent the authenticated identity and to accurately represent transited information. Any KDC along this path could impersonate the client.
此信任可通过多跳身份验证路径传递。服务的领域信任靠近客户端的身份验证路径上的每个跃点，以准确表示经过身份验证的身份并准确表示传输的信息。沿此路径的任何KDC都可以模拟客户端。
KDC-signed or -issued authorization data often implies additional trust. The implications of such trust from a security and operational standpoint is an ongoing topic of discussion during the
KDC签署或发布的授权数据通常意味着额外的信任。从安全和操作的角度来看，这种信任的影响是本次会议期间持续讨论的一个主题
development of this specification. As such, such discussion is out of scope for this memo.
本规范的制定。因此，此类讨论超出了本备忘录的范围。
Administrators have several tools to limit trust caused by cross-realm relationships. A service or KDC can control what authentication paths are acceptable. For example, if a given realm is not permitted on the authentication path for a particular client, then that realm cannot affect trust placed in that client principal. Consuming realms can exercise significant control by deciding what principals to place on an access-control list. If no client using a given issuing realm in authentication paths is permitted to access a resource, then that issuing realm is not trusted in access decisions regarding that resource.
管理员有几种工具来限制跨领域关系引起的信任。服务或KDC可以控制哪些身份验证路径是可接受的。例如，如果特定客户端的身份验证路径上不允许给定域，则该域不会影响对该客户端主体的信任。消费领域可以通过决定在访问控制列表中放置哪些主体来实施重要的控制。如果不允许在身份验证路径中使用给定颁发域的客户端访问资源，则该颁发域在有关该资源的访问决策中不受信任。
Creating a cross-realm relationship implies relatively little inherent trust in the issuing realm. Significant trust only applies as principals dependent on that issuing realm are given access to resources. However, two deployment characteristics may increase the trust implied by the initial cross-realm relationship. First, a number of realms provide access to any principal to some resources. Access decisions involving these resources involve a degree of trust in all issuing realms in the transited graph. Secondly, many realms do not constrain the set of principals to which users of that realm may grant access. In these realms, creating a cross-realm relationship delegates the decision to trust that realm to users of the consuming realm. In this situation, creating the cross-realm relationship is the primary trust decision point under the administrator's control.
创建跨领域关系意味着对发布领域的内在信任相对较少。重要信任仅在依赖于发布领域的主体被授予对资源的访问权限时适用。但是，两个部署特征可能会增加初始跨领域关系所隐含的信任。首先，许多领域提供了对某些资源的任何主体的访问。涉及这些资源的访问决策涉及传输图中所有发布领域的信任度。其次，许多领域不限制该领域的用户可以授予访问权限的主体集。在这些领域中，创建跨领域关系将信任该领域的决策委托给消费领域的用户。在这种情况下，创建跨领域关系是管理员控制下的主要信任决策点。
The NT-ENTERPRISE type principal name contains one component, a string of realm-defined content, which is intended to be used as an alias for another principal name in some realm in the enterprise. It is used for conveying the alias name, not for the real principal names within the realms, and thus is only useful when name canonicalization is requested.
NT-ENTERPRISE类型主体名称包含一个组件，一个领域定义内容的字符串，用于作为企业中某个领域中另一个主体名称的别名。它用于传递别名，而不是域内的真实主体名称，因此只有在请求名称规范化时才有用。
The intent is to allow unification of email and security principal names. For example, all users at EXAMPLE.COM may have a client principal name of the form "joe@EXAMPLE.COM", even though the principals are contained in multiple realms. This global name is again an alias for the true client principal name, which indicates what realm contains the principal. Thus, accounts "alice" in the realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log on as "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM".
其目的是允许电子邮件和安全主体名称的统一。例如，example.COM上的所有用户可能都有以下形式的客户端主体名称“joe@EXAMPLE.COM“，即使主体包含在多个领域中。此全局名称也是真实客户端主体名称的别名，它指示包含主体的领域。因此，域DEV.EXAMPLE.COM中的帐户“alice”和ADMIN.EXAMPLE.COM中的帐户“bob”可以“登录”alice@EXAMPLE.COM“和”bob@EXAMPLE.COM".
This utilizes a new principal name type, as the KDC-REQ message only contains a single client realm (crealm) field, and the realm portion of this name corresponds to the Kerberos realm with which the request is made. Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a single component in the client name field of the AS-REQ message, with a name type of NT-ENTERPRISE [RFC4120] (and the local realm name). The KDC will recognize this name type and then transform the requested name into the true principal name if the client account resides in the local realm. The true principal name can have a name type different from the requested name type. Typically, the true principal name will be an NT-PRINCIPAL [RFC4120].
这利用了一种新的主体名称类型，因为KDC-REQ消息只包含一个客户机领域（crealm）字段，并且该名称的领域部分对应于发出请求的Kerberos领域。因此，整个名称”alice@EXAMPLE.COM“作为as-REQ消息的客户端名称字段中的单个组件传输，名称类型为NT-ENTERPRISE[RFC4120]（和本地领域名称）。如果客户机帐户位于本地域中，KDC将识别此名称类型，然后将请求的名称转换为真实的主体名称。真正的主体名称可以具有与请求的名称类型不同的名称类型。通常，真正的主体名称将是NT主体[RFC4120]。
A service or account may have multiple principal names. For example, if a host is known by multiple names, host-based services on it may be known by multiple names in order to prevent the client from needing a secure directory service to determine the correct host name to use. In order to avoid the need to update the host whenever a new alias is created, the KDC may provide the mapping information to the client in the credential acquisition process.
一个服务或帐户可能有多个主体名称。例如，如果一个主机有多个名称，那么基于该主机的服务可能有多个名称，以防止客户端需要安全目录服务来确定要使用的正确主机名。为了避免在创建新别名时需要更新主机，KDC可以在凭证获取过程中向客户端提供映射信息。
If the "canonicalize" KDC option is set, then the KDC MAY change the client and server principal names and types in the AS response and ticket returned from those in the request. Names MUST NOT be changed in the response to a TGS request, although it is common for KDCs to maintain a set of aliases for service principals. Regardless of which alias a client requests, the same service key is used. However, in the TGS request, the client receives a ticket for the alias requested. Services MUST NOT make distinctions based on which alias is in the issued ticket, because the service name in a ticket is not cryptographically protected and can be changed by parties other than the KDC.
如果设置了“canonicalize”KDC选项，那么KDC可能会更改AS响应中的客户机和服务器主体名称和类型以及从请求中返回的票证。在响应TGS请求时不得更改名称，尽管KDC通常会为服务主体维护一组别名。无论客户端请求哪个别名，都使用相同的服务密钥。但是，在TGS请求中，客户端会收到所请求别名的票证。服务不得基于发出的票据中的别名进行区分，因为票据中的服务名称不受加密保护，可以由KDC以外的其他方更改。
For example, the AS request may specify a client name of "bob@ EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC option set, and the KDC will return with a client name of "104567" as an NT-UID [RFC4120].
例如，AS请求可以将客户机名称“bob@example.COM”指定为设置了“canonicalize”KDC选项的NT-ENTERPRISE名称，并且KDC将以客户机名称“104567”作为NT-UID返回[RFC4120]。
(It is assumed that the client discovers whether the KDC supports the NT-ENTERPRISE name type via out-of-band mechanisms.)
（假设客户端通过带外机制发现KDC是否支持NT-ENTERPRISE名称类型。）
See Section 11 for a mechanism to detect modification of the request between the client and KDC. However, for the best protection, Flexible Authentication Secure Tunneling (FAST) [RFC6113] or another mechanism that protects the entire KDC exchange SHOULD be used. Clients MAY reject responses from a KDC where the client or server name is changed if the KDC does not support such a mechanism.
有关检测客户端和KDC之间请求修改的机制，请参见第11节。但是，为了获得最佳保护，应使用灵活的身份验证安全隧道（FAST）[RFC6113]或其他保护整个KDC交换的机制。如果KDC不支持这种机制，则客户机可能会拒绝来自更改了客户机或服务器名称的KDC的响应。
Clients SHOULD reject an AS response that changes the server name unless the response is protected by such a mechanism or the new server name is one explicitly expected by the client. For example, many clients permit the realm name to be changed in an AS response, even if the response is not protected. See Section 13 for a discussion of the tradeoffs in allowing unprotected responses.
客户机应拒绝更改服务器名称的AS响应，除非该响应受到此类机制的保护，或者新服务器名称是客户机明确期望的名称。例如，许多客户端允许在AS响应中更改域名，即使响应没有受到保护。有关允许无保护响应的权衡的讨论，请参见第13节。
In order to permit authorization decisions to be made based on aliases as well as the canonicalized form of a principal name, the KDC MAY include the following authorization data element, wrapped in AD-KDC-ISSUED, in the initial credentials and copy it from a ticket-granting ticket into additional credentials:
为了允许基于别名以及主体名称的规范化形式做出授权决策，KDC可以在初始凭证中包含以下授权数据元素（包装为AD-KDC-ISTED），并将其从票据授予票据复制到附加凭证中：
AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number 80 --
login-aliases [0] SEQUENCE (SIZE (1..MAX)) OF PrincipalName,
...
}
AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number 80 --
login-aliases [0] SEQUENCE (SIZE (1..MAX)) OF PrincipalName,
...
}
The login-aliases field lists one or more of the aliases the principal is known by.
登录别名字段列出主体已知的一个或多个别名。
In addition to permitting authorization based on aliases, this permits user-to-user exchanges where the party receiving the authenticator knows the other party only by an alias. The recipient of such an authenticator SHOULD check the AD-LOGIN-ALIAS names, if present, in addition to the normal client name field, against the identity of the party with which it wishes to authenticate; either should be allowed to match. (Note that this is not backwards compatible with [RFC4120]; if the server side of the user-to-user exchange does not support this extension and does not know the true principal name, authentication may fail if the alias is sought in the client name field.)
除了允许基于别名的授权外，这还允许用户对用户交换，其中接收验证器的一方仅通过别名知道另一方。除了正常的客户机名称字段外，此类身份验证人的接收人还应检查AD-LOGIN-ALIAS名称（如果存在）是否与其希望进行身份验证的一方的身份相符；任何一个都应该被允许匹配。（请注意，这与[RFC4120]不向后兼容；如果用户对用户exchange的服务器端不支持此扩展，并且不知道真正的主体名称，则如果在“客户端名称”字段中查找别名，身份验证可能会失败。）
The use of AD-KDC-ISSUED authorization data elements in cross-realm cases has not been well explored at this writing; hence, we will only specify the inclusion of this data in the one-realm case. The AD-LOGIN-ALIAS information SHOULD be dropped in the general cross-realm case. However, a realm MAY implement a policy of accepting and re-signing (wrapping in a new AD-KDC-ISSUED element) alias information provided by certain trusted realms in the cross-realm ticket-granting service.
在跨领域案例中使用AD-KDC发布的授权数据元素在本文中没有得到很好的探讨；因此，我们将只指定在一个领域案例中包含此数据。在一般跨领域情况下，应删除AD-LOGIN-ALIAS信息。但是，域可以实现一种策略，即接受和重新签名（包装在新的AD-KDC发布元素中）由跨域票证授予服务中的某些受信任域提供的别名信息。
The canonical principal name for an alias MUST NOT be in the form of a ticket-granting service name, as (in a case of server name canonicalization) that would be construed as a case of cross-realm referral, described below.
别名的规范主体名称不得采用票证授予服务名称的形式，因为（在服务器名称规范化的情况下）将被解释为跨领域引用的情况，如下所述。
The simplest form of ticket referral is for a user requesting a ticket using an AS-REQ. In this case, the client machine will send the AS-REQ to a convenient realm trusted to map principals, for example, the realm of the client machine. In the case of the name alice@EXAMPLE.COM, the client MAY optimistically choose to send the request to EXAMPLE.COM. The realm in the AS-REQ is always the name of the realm that the request is for, as specified in [RFC4120].
票证引用的最简单形式是用户使用AS-REQ请求票证。在这种情况下，客户机将AS-REQ发送到一个方便的领域，该领域受信任以映射主体，例如，客户机的领域。就名字而言alice@EXAMPLE.COM，客户端可以乐观地选择将请求发送到EXAMPLE.COM。AS-REQ中的域始终是请求所针对的域的名称，如[RFC4120]中所述。
The KDC will try to lookup the name in its local account database. If the account is present in the realm of the request, it SHOULD return a KDC reply with the appropriate ticket.
KDC将尝试在其本地帐户数据库中查找该名称。如果该帐户存在于请求的域中，它应该返回一个带有相应票证的KDC回复。
If the account is not present in the realm specified in the request and the "canonicalize" KDC option is set, the KDC may look up the client principal name using some kind of name service or directory service. If this lookup is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120]. If the lookup is successful, it MUST return an error KDC_ERR_WRONG_REALM [RFC4120]; in the error message, the crealm field will contain either the true realm of the client or another realm that MAY have better information about the client's true realm. The client MUST NOT use the cname returned in this error message.
如果帐户不在请求中指定的领域中，并且设置了“规范化”KDC选项，KDC可以使用某种名称服务或目录服务查找客户机主体名称。如果此查找不成功，它必须返回错误KDC_ERR_C_PRINCIPAL_UNKNOWN[RFC4120]。如果查找成功，它必须返回一个错误KDC_ERR_error_error_REALM[RFC4120]；在错误消息中，crealm字段将包含客户机的真实领域，或者包含关于客户机真实领域的更好信息的另一个领域。客户端不得使用此错误消息中返回的cname。
If the client receives a KDC_ERR_WRONG_REALM error, it will issue a new AS request with the same client principal name used to generate the first AS request to the realm specified by the realm field of the Kerberos error message corresponding to the first request. (The client realm name will be updated in the new request to refer to this new realm.) The client SHOULD repeat these steps until it finds the true realm of the client. To avoid infinite referral loops, an implementation should limit the number of referrals. A suggested limit is 5 referrals before giving up.
如果客户端接收到KDC_ERR_error_error_REALM错误，它将向与第一个请求对应的Kerberos错误消息的REALM字段指定的领域发出一个新的AS请求，该请求具有用于生成第一个AS请求的相同客户端主体名称。（客户端领域名称将在新请求中更新，以引用此新领域。）客户端应重复这些步骤，直到找到客户端的真实领域。为了避免无限的引用循环，实现应该限制引用的数量。建议的限制是在放弃之前推荐5次。
Since the same client name is sent to the referring and referred-to realms, both realms must recognize the same client names. In particular, the referring realm cannot (usefully) define principal name aliases that the referred-to realm will not know.
由于相同的客户端名称被发送到引用域和被引用域，因此两个域必须识别相同的客户端名称。特别是，引用领域不能（有效地）定义被引用领域不知道的主体名称别名。
The true principal name of the client, returned in AS-REP, can be validated in a subsequent TGS message exchange where its value is communicated back to the KDC via the authenticator in the PA-TGS-REQ padata [RFC4120]. However, this requires trusting the referred-to realm's KDCs. Clients should limit the referral mappings they will accept to realms trusted via some local policy. Some possible factors that might be taken into consideration for such a policy might include:
在AS-REP中返回的客户机的真实主体名称可以在随后的TGS消息交换中进行验证，在该交换中，其值通过PA-TGS-REQ padata[RFC4120]中的验证器传回KDC。然而，这需要信任所引用领域的KDC。客户端应将其接受的引用映射限制为通过某些本地策略信任的领域。此类政策可能考虑的一些因素可能包括：
o Any realm indicated by the local KDC if the returned KRB-ERROR message is protected by some additional means, for example, FAST
o 如果返回的KRB-ERROR消息受到某些附加手段（例如FAST）的保护，则本地KDC指示的任何领域
o A list of realms configured by an administrator
o 由管理员配置的领域列表
o Any realm accepted by the user when explicitly prompted
o 明确提示时用户接受的任何领域
One common approach for limiting the realms from which referrals are accepted is to limit referrals to realms that can construct an authentication path back to the service principal of the local machine. This tends to work well when realms are generally within an organization and all realms that can form an authentication path back to the local machine have some reasonable level of mapping trust. Deployments involving more complex trust, for example, high probability of malicious realms, are likely to need more complex policy and MAY need to prompt the user before accepting some referrals.
限制接受转介的领域的一种常见方法是将转介限制到可以构造回本地机器的服务主体的身份验证路径的领域。当领域通常位于一个组织内，并且可以形成回本地机器的身份验证路径的所有领域都具有某种合理的映射信任级别时，这种方法往往可以很好地工作。涉及更复杂的信任（例如，恶意领域的高概率）的部署可能需要更复杂的策略，并且可能需要在接受某些推荐之前提示用户。
There is currently no provision for changing the client name in a client referral response.
目前没有关于在客户转介响应中更改客户名称的规定。
The primary difference in server referrals is that the KDC returns a referral TGT rather than an error message as is done in the client referrals.
服务器引用的主要区别在于KDC返回一个引用TGT，而不是像在客户端引用中那样返回一条错误消息。
If the "canonicalize" flag in the KDC options is set and the KDC doesn't find the principal locally, either as a regular principal or as an alias for another local principal, the KDC MAY return a cross-realm ticket-granting ticket to the next hop on the trust path towards a realm that may be able to resolve the principal name.
如果在KDC选项中设置了“canonicalize”标志，并且KDC在本地找不到主体（作为常规主体或作为另一个本地主体的别名），KDC可能会将跨域票证授予票证返回到信任路径上的下一个跃点，该跃点可能会解析主体名称。
The client will use this referral information to request a chain of cross-realm ticket-granting tickets until it reaches the realm of the server, and can then expect to receive a valid service ticket.
客户机将使用此引用信息请求跨域票证授予票证链，直到到达服务器的域，然后可以期望收到有效的服务票证。
However, an implementation should limit the number of referrals that it processes to avoid infinite referral loops. A suggested limit is 5 referrals before giving up.
然而，一个实现应该限制它处理的引用的数量，以避免无限的引用循环。建议的限制是在放弃之前推荐5次。
The client may cache the mapping of the requested name to the name of the next realm to use and the principal name to ask for (see Section 10).
客户端可以缓存请求的名称到下一个要使用的域的名称和要请求的主体名称的映射（参见第10节）。
Here is an example of a client requesting a service ticket for a service in realm DEV.EXAMPLE.COM where the client is in ADMIN.EXAMPLE.COM.
下面是一个示例，客户机请求realm DEV.example.COM中服务的服务票证，其中客户机位于ADMIN.example.COM中。
+NC = Canonicalize KDCOption set
C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM
S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM
C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM
S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM
C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM
S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM
+NC = Canonicalize KDCOption set
C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM
S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM
C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM
S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM
C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM
S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM
Note that any referral or alias processing of the server name in user-to-user authentication should use the same data as client name canonicalization or referral. Otherwise, the name used by one user to log in may not be useable by another for user-to-user authentication to the first.
请注意，在用户对用户身份验证中，服务器名称的任何引用或别名处理都应使用与客户端名称规范化或引用相同的数据。否则，一个用户登录时使用的名称可能无法由另一个用户用于第一个用户的用户对用户身份验证。
RFC 4120 permits a KDC to return a closer referral ticket when a cross-realm TGT is requested. This specification extends this behavior when the canonicalize flag is set. When this flag is set, a KDC MAY return a TGT for a realm closer to the service for any service as discussed in the previous section. When a client follows such a referral, it includes the realm of the referred-to realm in the generated request.
RFC4120允许KDC在请求跨领域TGT时返回更接近的推荐票证。当设置规范化标志时，此规范扩展了此行为。设置此标志后，KDC可能会为任何服务返回一个更接近服务的领域的TGT，如前一节所述。当客户机遵循这种引用时，它会在生成的请求中包含所引用领域的领域。
When the canonicalize flag is not set, the rules defined in RFC 4120 apply.
未设置规范化标志时，将应用RFC 4120中定义的规则。
It is possible that the client may wish to get additional credentials for the same service principal, perhaps with different authorization-data restrictions or other changed attributes. The return of a server referral from a KDC can be taken as an indication that the requested principal does not currently exist in the local realm. Clearly, it would reduce network traffic if the clients could cache that information and use it when acquiring the second set of credentials for a service, rather than always having to recheck with the local KDC to see if the name has been created locally.
客户机可能希望获得同一服务主体的附加凭证，可能具有不同的授权数据限制或其他更改的属性。从KDC返回服务器引用可以被视为请求的主体当前不存在于本地域中的指示。显然，如果客户端可以缓存该信息并在获取服务的第二组凭据时使用该信息，而不是总是必须与本地KDC重新检查名称是否已在本地创建，则会减少网络流量。
When the TGT expires, the previously returned referral from the local KDC should be considered invalid, and the local KDC must be asked again for information for the desired service principal name. (Note that the client may get back multiple referral TGTs from the local KDC to the same remote realm, with different lifetimes. The lifetime
当TGT过期时，先前从本地KDC返回的引用应被视为无效，并且必须再次向本地KDC询问所需服务主体名称的信息。（注意，客户端可能会从本地KDC返回多个引用TGT到同一个远程领域，使用不同的生存期。生存期
information SHOULD be properly associated with the requested service principal names. Simply having another TGT for the same remote realm does not extend the validity of previously acquired information about one service principal name.)
信息应与请求的服务主体名称正确关联。简单地为同一远程领域使用另一个TGT并不能扩展先前获取的关于一个服务主体名称的信息的有效性。）
Accordingly, KDC authors and maintainers should consider what factors (e.g., DNS alias lifetimes) they may or may not wish to incorporate into credential expiration times in cases of referrals.
因此，KDC的作者和维护者应该考虑哪些因素（例如，DNS别名寿命），它们可能或可能不希望合并到凭证期满的情况下，在转介的情况下。
Implementations of this specification MUST support the FAST negotiation mechanism described in this section. This mechanism provides detection of KDC requests modified by an attacker when those requests result in a reply instead of an error. In addition, this mechanism provides a secure way to detect if a KDC supports FAST.
本规范的实现必须支持本节中描述的快速协商机制。当攻击者修改KDC请求导致回复而不是错误时，此机制可检测这些请求。此外，该机制提供了一种安全的方法来检测KDC是否支持FAST。
Clients conforming to this specification MUST send new pre-authentication data of type PA-REQ-ENC-PA-REP (149) in all AS requests and MAY send this padata type in TGS requests. The value of this padata item SHOULD be empty and its value MUST be ignored by a receiving KDC. Sending this padata item indicates support for this negotiation mechanism. KDCs conforming to this specification must always set the ticket flag enc-pa-rep (15) in all the issued tickets. This ticket flag indicates KDC support for the mechanism.
符合本规范的客户机必须在所有AS请求中发送PA-REQ-ENC-PA-REP（149）类型的新预认证数据，并且可以在TGS请求中发送此padata类型。此padata项的值应为空，接收KDC必须忽略其值。发送此padata项表示支持此协商机制。符合本规范的KDC必须始终在所有已发行票据中设置票据标志enc pa rep（15）。此票证标志表示KDC对该机制的支持。
The KDC response [RFC4120] is extended to support an additional field containing encrypted pre-authentication data.
KDC响应[RFC4120]被扩展以支持包含加密预认证数据的附加字段。
EncKDCRepPart ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] UInt32,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm,
sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL,
encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
}
EncKDCRepPart ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] UInt32,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm,
sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL,
encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
}
The encrypted-pa-data element MUST be absent unless either the "canonicalize" KDC option is set or the PA-REQ-ENC-PA-REP padata item is sent.
除非设置了“规范化”KDC选项或发送了pa-REQ-ENC-pa-REP padata项，否则必须缺少加密的pa数据元素。
If the PA-REQ-ENC-PA-REP padata item is sent in the request, then the KDC MUST include a PA-REQ-ENC-PA-REP padata item in the encrypted-pa-data item of any generated KDC reply. The PA-REQ-ENC-PA-REP pa-data value contains the checksum computed over the type AS-REQ or TGS-REQ in the request. The checksum key is the reply key and the checksum type is the required checksum type for the encryption type of the reply key, and the key usage number is KEY_USAGE_AS_REQ (56). If the KDC supports FAST, then the KDC MUST include a padata of type PA-FX-FAST in any encrypted-pa-data sequence it generates. The padata item MUST be empty on sending, and the contents of the padata item MUST be ignored on receiving.
如果在请求中发送PA-REQ-ENC-PA-REP padata项，则KDC必须在任何生成的KDC回复的加密PA数据项中包含PA-REQ-ENC-PA-REP padata项。PA-REQ-ENC-PA-REP PA数据值包含根据请求中的AS-REQ或TGS-REQ类型计算的校验和。校验和密钥是应答密钥，校验和类型是应答密钥的加密类型所需的校验和类型，密钥使用编号是密钥\u用法\u AS_REQ（56）。如果KDC支持FAST，则KDC必须在其生成的任何加密PA数据序列中包含PA-FX-FAST类型的padata。padata项在发送时必须为空，在接收时必须忽略padata项的内容。
A client MUST reject a response for which it sent PA-REQ-ENC-PA-REP if the ENC-PA-REP ticket flag is set and the PA-REQ-ENC-PA-REP padata item is absent or the checksum is not successfully verified.
如果设置了ENC-PA-REP票证标志且PA-REQ-ENC-PA-REP padata项不存在或校验和未成功验证，则客户端必须拒绝其发送PA-REQ-ENC-PA-REP的响应。
PA-REQ-ENC-PA-REP has been registered in the Kerveros "Pre-authentication and Typed Data" registry <http://www.iana.org/assignments/kerberos-parameters>.
PA-REQ-ENC-PA-REP已在Kerveros“预认证和键入数据”注册表中注册<http://www.iana.org/assignments/kerberos-parameters>.
For the AS exchange case, it is important that the logon mechanism not trust a name that has not been used to authenticate the user. For example, the name that the user enters as part of a logon exchange may not be the name that the user authenticates as, given that the KDC_ERR_WRONG_REALM error may have been returned. The relevant Kerberos naming information for logon (if any) is the client name and client realm in the service ticket targeted at the workstation obtained using the user's initial TGT. That is, rather than trusting the client name in the AS response, a workstation SHOULD perform an AP-REQ authentication against itself as a service and use the client name in the ticket issued for its service by the KDC.
对于AS exchange情况，登录机制不信任未用于验证用户身份的名称是很重要的。例如，用户作为登录交换的一部分输入的名称可能不是用户身份验证的名称，因为可能已返回KDC_ERR_error_error_REALM错误。登录的相关Kerberos命名信息（如果有）是使用用户的初始TGT获得的针对工作站的服务票证中的客户端名称和客户端域。也就是说，工作站不应信任AS响应中的客户端名称，而应针对其自身作为服务执行AP-REQ身份验证，并在KDC为其服务发出的票证中使用客户端名称。
How the client name and client realm are mapped into a local account for logon is a local matter, but the client logon mechanism MUST use additional information such as the client realm and/or authorization attributes from the service ticket presented to the workstation by the user when mapping the logon credentials to a local account on the workstation.
如何将客户端名称和客户端域映射到本地帐户进行登录是一个本地问题，但是，在将登录凭据映射到工作站上的本地帐户时，客户端登录机制必须使用用户提供给工作站的服务票证中的其他信息，例如客户端领域和/或授权属性。
Not all fields in a KDC reply defined by RFC 4120 are protected. None of the fields defined in RFC 4120 for AS request are protected, and some information in a TGS request may not be protected. The referrals mechanism creates several opportunities for attack because
并非RFC4120定义的KDC应答中的所有字段都受保护。RFC 4120中为AS请求定义的字段均不受保护，TGS请求中的某些信息可能不受保护。转介机制会造成多个攻击机会，因为
of these unprotected fields. FAST [RFC6113] can be used to completely mitigate these issues by protecting both the KDC request and response. However, FAST requires that a client obtain an armor ticket before authenticating. Not all realms permit all clients to obtain armor tickets. Also, while it is expected to be uncommon, a client might wish to use name canonicalization while obtaining an armor ticket. The mechanism described in Section 11 detects modification of the request between the KDC and client, mitigating some attacks.
在这些未受保护的字段中。FAST[RFC6113]可以通过保护KDC请求和响应来完全缓解这些问题。但是，FAST要求客户机在进行身份验证之前获得armor票证。并非所有领域都允许所有客户机获得装甲罚单。此外，虽然这可能并不常见，但客户机可能希望在获取armor票证时使用名称规范化。第11节中描述的机制检测KDC和客户端之间请求的修改，从而减轻一些攻击。
There is a widely deployed base of implementations that use name canonicalization or server referrals that use neither the negotiation mechanism nor FAST. So, implementations may be faced with only the limited protection afforded by RFC 4120, by the negotiation mechanism discussed in this document, or by FAST. All three situations are important to consider from a security standpoint.
有许多广泛部署的实现使用名称规范化或服务器引用，这些实现既不使用协商机制也不使用FAST。因此，实现可能只面临RFC 4120、本文档中讨论的协商机制或FAST提供的有限保护。从安全的角度来看，这三种情况都是很重要的。
An attacker cannot mount a downgrade attack against a client. The negotiation mechanism described in this document is securely indicated by the presence of a ticket flag. So, a client will detect if the facility was available but not used. It is possible for an attacker to strip the indication that a client supports the negotiation facility. The client will learn from the response that this happened, but the KDC will not learn that the client is attacked. So, for a single round-trip Kerberos exchange, the KDC may believe the exchange was successful when the client detects an attack. Packet loss or client failure can produce a similar result; this is not a significant vulnerability. The negotiation facility described in this document securely indicates the presence of FAST. So, if a client wishes to use FAST when it is available, an attacker cannot force the client to downgrade away from FAST. An attacker MAY be able to prevent a client from obtaining an armor ticket, for example, by responding to a request for anonymous Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) with an error response.
攻击者无法对客户端发起降级攻击。本文件中描述的协商机制通过票证标志的存在安全地表示。因此，客户端将检测设备是否可用但未使用。攻击者可能会删除客户端支持协商功能的指示。客户端将从响应中了解到发生了这种情况，但KDC不会了解到客户端受到了攻击。因此，对于单个往返Kerberos交换，当客户端检测到攻击时，KDC可能认为交换成功。数据包丢失或客户端故障可能会产生类似的结果；这不是一个重要的漏洞。本文件中描述的协商设施安全地表明FAST的存在。因此，如果客户端希望在FAST可用时使用FAST，则攻击者无法强制客户端从FAST降级。攻击者可以阻止客户端获取armor票证，例如，通过使用错误响应响应Kerberos（PKINIT）中用于初始身份验证的匿名公钥加密请求。
If FAST is used, then the communications between the client and KDC are protected. However, name canonicalization places a new responsibility for mapping principals onto the KDC. This can increase the number of KDCs involved in an authentication, which adds additional trusted third parties to the exchange.
如果使用FAST，则客户端和KDC之间的通信将受到保护。然而，名称规范化赋予了将主体映射到KDC的新职责。这可能会增加身份验证中涉及的KDC数量，从而为exchange添加更多受信任的第三方。
If only the negotiation mechanism is used, then the request from the client to the KDC is protected, but not all of the response is protected. In particular, the client name is not protected; the ticket is also not protected. An attacker can potentially modify these fields. Modification of the client name will result in a denial of service. When the client attempts to authenticate to a
如果只使用协商机制，那么从客户端到KDC的请求将受到保护，但不是所有响应都受到保护。特别是，客户端名称不受保护；票也不受保护。攻击者可能会修改这些字段。修改客户端名称将导致拒绝服务。当客户端尝试向
service (including the TGS), it constructs an AP-REQ message. This message includes a client name that MUST match the client name in the ticket according to RFC 4120. Thus, if the client name is changed, the resulting ticket will fail when used. This is undesirable because the authentication is separated from the later failure, which may confuse problem determination. If the ticket is replaced with another ticket, then later authentication to a service will fail because the client will not know the session key for the other ticket. If the ticket is simply modified, then authentication to a service will fail as with RFC 4120. More significant attacks are possible if a KDC violates the requirements of RFC 4120 and issues two tickets with the same session key, or if a service violates the requirements of RFC 4120 and does not check the client name against that in the ticket.
服务（包括TGS），它构造AP-REQ消息。根据RFC 4120，此消息包含的客户端名称必须与票据中的客户端名称匹配。因此，如果更改了客户端名称，则使用时生成的票证将失败。这是不可取的，因为身份验证与后面的失败是分离的，这可能会混淆问题的确定。如果用另一个票证替换该票证，则稍后对服务的身份验证将失败，因为客户端将不知道另一个票证的会话密钥。如果只是修改票据，那么对服务的身份验证将失败，与RFC4120一样。如果KDC违反RFC 4120的要求并发出两个具有相同会话密钥的票据，或者如果服务违反RFC 4120的要求且未对照票据中的客户机名称检查客户机名称，则可能发生更严重的攻击。
There is an additional attack possible when FAST is not used against KDC_ERR_WRONG_REALM. Since this is an error response, not an AS response, it is not protected by the negotiation mechanism. Thus, an attacker may be able to convince a client to authenticate to a realm other than the one intended. If an attacker is off-path, this may give the attacker an advantage in attacking the client's credentials. Also, see the discussion of shared passwords below.
当FAST不用于KDC_ERR_Error_领域时，可能会有额外的攻击。因为这是一个错误响应，而不是AS响应，所以它不受协商机制的保护。因此，攻击者可能能够说服客户机对预期域以外的域进行身份验证。如果攻击者不在路径上，这可能会使攻击者在攻击客户端凭据时获得优势。另外，请参阅下面关于共享密码的讨论。
More serious attacks are possible if no protection beyond RFC 4120 is used. In this case, neither the client name nor the service name is protected between the client and KDC. In the general case, if an attacker changes the client name, then authentication will fail because the client will not have the right credentials (password, certificate, or other) to authenticate as the user selected by the attacker. However, see the discussion of shared passwords below. Changing the server name can be a very significant attack. For example, if a user is authenticating in order to send some confidential information, then the attacker could gain this information by directing the user to a server under the attacker's control. The server name in the response is protected by RFC 4120, but not the one in the request. Fortunately, users are typically authenticating to the "krbtgt" service in an AS exchange. Clients that permit changes to the server name when no protection beyond RFC 4120 is in use SHOULD carefully restrict what service names are acceptable. One critical case to consider is the password-changing service. When a user authenticates to change their password, they use an AS authentication directly to the password-changing service. Clients MUST restrict service name changes sufficiently that the client ends up talking to the correct password-changing service.
如果没有使用RFC 4120以外的保护，则可能发生更严重的攻击。在这种情况下，客户端和KDC之间既不保护客户端名称也不保护服务名称。在一般情况下，如果攻击者更改客户端名称，则身份验证将失败，因为客户端将不具有作为攻击者选择的用户进行身份验证的正确凭据（密码、证书或其他）。但是，请参见下面关于共享密码的讨论。更改服务器名称可能是一种非常严重的攻击。例如，如果用户正在进行身份验证以发送一些机密信息，那么攻击者可以通过将用户定向到攻击者控制下的服务器来获取这些信息。响应中的服务器名受RFC 4120保护，但请求中的服务器名不受保护。幸运的是，用户通常在AS exchange中对“krbtgt”服务进行身份验证。在使用RFC 4120以外的保护时，允许更改服务器名称的客户端应仔细限制可接受的服务名称。需要考虑的一个关键问题是密码更改服务。当用户通过身份验证来更改其密码时，他们将直接使用AS身份验证来更改密码服务。客户端必须充分限制服务名称的更改，以便客户端最终与正确的密码更改服务对话。
A special case to examine is when the user is known (or correctly suspected) to use the same password for multiple accounts. A man-in-the-middle attacker can either alter the request on its way to the KDC, changing the client principal name, or reply to the client with a response previously sent by the KDC in response to a request from the attacker. The response received by the client can then be decrypted by the user, though if the default "salt" generated from the principal name is used to produce the user's key, a PA-ETYPE-INFO or PA-ETYPE-INFO2 preauth record may need to be added or altered by the attacker to cause the client software to generate the key needed for the message it will receive. None of this requires the attacker to know the user's password, and without further checking, this could cause the user to unknowingly use the wrong credentials.
需要检查的特殊情况是，已知（或正确怀疑）用户对多个帐户使用相同的密码。中间人攻击者可以在发送到KDC的过程中更改请求，更改客户端主体名称，或者使用KDC先前发送的响应回复客户端，以响应攻击者的请求。然后，用户可以对客户端接收到的响应进行解密，但如果使用主体名称生成的默认“salt”生成用户密钥，攻击者可能需要添加或更改PA-ETYPE-INFO或PA-ETYPE-INFO2预授权记录，以使客户端软件生成它将接收的消息所需的密钥。所有这些都不要求攻击者知道用户的密码，如果不进一步检查，这可能会导致用户在不知不觉中使用错误的凭据。
In normal operation as described in [RFC4120], a generated AP-REQ message includes in the Authenticator field a copy of the client's idea of its own principal name. If this differs from the name in the KDC-generated ticket, the application server will reject the message.
在[RFC4120]中所述的正常操作中，生成的AP-REQ消息在验证器字段中包括客户端对其自身主体名称的想法的副本。如果这与KDC生成的票证中的名称不同，应用程序服务器将拒绝该消息。
With client name canonicalization as described in this document, the client may get its principal name from the response from the KDC. Using the wrong credentials may provide an advantage to an attacker. For example, if a client uses one principal for administrative operations and one for less privileged operation, an attacker may coerce a client into using the wrong privilege to either cause some later operation to succeed or fail.
通过本文档中描述的客户机名称规范化，客户机可以从KDC的响应中获得其主体名称。使用错误的凭据可能会为攻击者提供优势。例如，如果客户端使用一个主体进行管理操作，另一个主体进行权限较低的操作，则攻击者可能会强制客户端使用错误的权限，以导致以后的操作成功或失败。
In cases of credential renewal, forwarding, or validation, if credentials are sent to the KDC that are not an initial ticket-granting ticket for the client's home realm, the encryption key used to protect the TGS exchange is one known to a third party (namely, the service for which the credential was issued). Consequently, in such an exchange, the protection described earlier may be compromised by the service. This is not generally believed to be a problem. If it is, some form of explicit TGS armor could be added to FAST.
在凭据续订、转发或验证的情况下，如果向KDC发送的凭据不是客户端主域的初始票据授予票据，则用于保护TGS交换的加密密钥是第三方已知的密钥（即为其颁发凭据的服务）。因此，在这样的交换中，前面描述的保护可能会被服务破坏。一般认为这不是一个问题。如果是，可以在FAST中添加某种形式的显式TGS装甲。
John Brezak, Mike Swift, and Jonathan Trostle wrote the initial version of this document.
John Brezak、Mike Swift和Jonathan Trostle编写了本文档的初始版本。
Karthik Jaganathan contributed to earlier versions.
Karthik Jaganathan为早期版本做出了贡献。
Sam Hartman's work on this document was funded by the MIT Kerberos Consortium.
Sam Hartman在本文档上的工作由麻省理工学院Kerberos财团资助。
[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月。
[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月。
[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for Kerberos Pre-Authentication", RFC 6113, April 2011.
[RFC6113]Hartman，S.和L.Zhu，“Kerberos预认证的通用框架”，RFC 6113，2011年4月。
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
[RFC4556]Zhu，L.和B.Tung，“Kerberos中初始身份验证的公钥加密（PKINIT）”，RFC 45562006年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation of Crossrealm Referral Handling in the MIT Kerberos Client", Network and Distributed System Security Symposium, February 2001.
[XPR]Trostle，J.，Kosinovsky，I.，和M.Swift，“MIT Kerberos客户端中跨领域引用处理的实现”，网络和分布式系统安全研讨会，2001年2月。
Appendix A. Compatibility with Earlier Implementations of Name Canonicalization
附录A.与名称规范化早期实现的兼容性
The Microsoft Windows 2000 and Windows 2003 releases included an earlier form of name-canonicalization [XPR]. Here are the differences:
Microsoft Windows 2000和Windows 2003版本包括一种早期形式的名称规范化[XPR]。区别如下：
1) Windows include an additional encrypted padata element. The preauth data type definition in the encrypted preauth data is as follows:
1) Windows包含一个额外的加密padata元素。加密的预授权数据中的预授权数据类型定义如下：
PA-SVR-REFERRAL-INFO 20
PA-SVR-转诊-INFO 20
PA-SVR-REFERRAL-DATA ::= SEQUENCE {
referred-name [1] PrincipalName OPTIONAL,
referred-realm [0] Realm
}}
PA-SVR-REFERRAL-DATA ::= SEQUENCE {
referred-name [1] PrincipalName OPTIONAL,
referred-realm [0] Realm
}}
The referred-principal is never sent. The referred-realm is included in TGS replies and includes the realm name of the realm to which the client is referred. This information is redundant with the realm in the second component of the returned TGT.
引用的主体从未被发送。引用的领域包括在TGS回复中，并包括客户端引用的领域的领域名称。此信息与返回的TGT的第二个组件中的域是冗余的。
2) When PKINIT [RFC4556] is used, the NT-ENTERPRISE client name is encoded as a Subject Alternative Name (SAN) extension [RFC5280] in the client's X.509 certificate. The type of the otherName field for this SAN extension is AnotherName [RFC5280]. The type-id field of the type AnotherName is id-ms-sc-logon-upn (1.3.6.1.4.1.311.20.2.3), and the value field of the type AnotherName is a KerberosString [RFC4120]. The value of this KerberosString type is the single component in the name-string [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
2) 当使用PKINIT[RFC4556]时，NT-ENTERPRISE客户端名称在客户端的X.509证书中编码为主体替代名称（SAN）扩展[RFC5280]。此SAN扩展的otherName字段的类型为另一个名称[RFC5280]。类型AnotherName的类型id字段为id ms sc logon upn（1.3.6.1.4.1.311.20.2.3），类型AnotherName的值字段为KerberosString[RFC4120]。此KerberosString类型的值是对应NT-ENTERPRISE名称类型的名称字符串[RFC4120]序列中的单个组件。
In Microsoft's current implementation through the use of global catalogs, any domain in one forest is reachable from any other domain in the same forest or another trusted forest with 3 or less referrals. A forest is a collection of realms with hierarchical trust relationships: there can be multiple trust trees in a forest; each child and parent realm pair and each root realm pair have bidirectional transitive direct trust between them.
在Microsoft当前通过使用全局编录实现的情况下，一个林中的任何域都可以从同一个林中的任何其他域或另一个受信任林中的任何其他域通过3个或更少的引用进行访问。森林是具有层次信任关系的领域集合：森林中可以有多个信任树；每个子域和父域对以及每个根域对之间都有双向可传递的直接信任。
While we might want to permit multiple aliases to exist and even be reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only one NT-ENTERPRISE alias to exist, so this question had not previously arisen.
虽然我们可能希望允许存在多个别名，甚至在AD-LOGIN-ALIAS中报告，但Microsoft实现只允许存在一个NT-ENTERPRISE别名，因此以前没有出现过这个问题。
Authors' Addresses
作者地址
Sam Hartman (editor) Painless Security
山姆·哈特曼（编辑）无痛安全
EMail: hartmans-ietf@mit.edu
EMail: hartmans-ietf@mit.edu
Kenneth Raeburn Massachusetts Institute of Technology
肯尼斯·雷伯恩麻省理工学院
EMail: raeburn@mit.edu
EMail: raeburn@mit.edu
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Larry Zhu微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: lzhu@microsoft.com
EMail: lzhu@microsoft.com