Internet Engineering Task Force (IETF) L. Zhu
Request for Comments: 8062 P. Leach
Obsoletes: 6112 Microsoft Corporation
Updates: 4120, 4121, 4556 S. Hartman
Category: Standards Track Hadron Industries
ISSN: 2070-1721 S. Emery, Ed.
Oracle
February 2017
Internet Engineering Task Force (IETF) L. Zhu
Request for Comments: 8062 P. Leach
Obsoletes: 6112 Microsoft Corporation
Updates: 4120, 4121, 4556 S. Hartman
Category: Standards Track Hadron Industries
ISSN: 2070-1721 S. Emery, Ed.
Oracle
February 2017
Anonymity Support for Kerberos
Kerberos的匿名性支持
Abstract
摘要
This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. This document obsoletes RFC 6112 and reclassifies that document as Historic. RFC 6112 contained errors, and the protocol described in that specification is not interoperable with any known implementation. This specification describes a protocol that interoperates with multiple implementations.
本文档定义了对Kerberos协议的扩展，以允许Kerberos客户机安全地与Kerberos应用程序服务通信，而无需显示其身份，或只显示其Kerberos领域。它还定义了一些扩展，允许Kerberos客户端获得匿名凭据，而无需向Kerberos密钥分发中心（KDC）透露其身份。本文档更新了RFCs 4120、4121和4556。本文件淘汰RFC 6112，并将该文件重新分类为历史文件。RFC 6112包含错误，该规范中描述的协议无法与任何已知实现进行互操作。本规范描述了与多个实现互操作的协议。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8062.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8062.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow 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
1.1. Changes since RFC 6112 . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
4.1. Anonymity Support in AS Exchange . . . . . . . . . . . . 6
4.1.1. Anonymous PKINIT . . . . . . . . . . . . . . . . . . 7
4.2. Anonymity Support in TGS Exchange . . . . . . . . . . . . 8
4.3. Subsequent Exchanges and Protocol Actions Common to AS
and TGS for Anonymity Support . . . . . . . . . . . . . . 10
5. Interoperability Requirements . . . . . . . . . . . . . . . . 11
6. GSS-API Implementation Notes . . . . . . . . . . . . . . . . 11
7. PKINIT Client Contribution to the Ticket Session Key . . . . 12
7.1. Combining Two Protocol Keys . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Changes since RFC 6112 . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
4.1. Anonymity Support in AS Exchange . . . . . . . . . . . . 6
4.1.1. Anonymous PKINIT . . . . . . . . . . . . . . . . . . 7
4.2. Anonymity Support in TGS Exchange . . . . . . . . . . . . 8
4.3. Subsequent Exchanges and Protocol Actions Common to AS
and TGS for Anonymity Support . . . . . . . . . . . . . . 10
5. Interoperability Requirements . . . . . . . . . . . . . . . . 11
6. GSS-API Implementation Notes . . . . . . . . . . . . . . . . 11
7. PKINIT Client Contribution to the Ticket Session Key . . . . 12
7.1. Combining Two Protocol Keys . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
In certain situations, the Kerberos [RFC4120] client may wish to authenticate a server and/or protect communications without revealing the client's own identity. For example, consider an application that provides read access to a research database and that permits queries by arbitrary requesters. A client of such a service might wish to authenticate the service, to establish trust in the information received from it, but might not wish to disclose the client's identity to the service for privacy reasons.
在某些情况下，Kerberos[RFC4120]客户机可能希望对服务器进行身份验证和/或保护通信，而不泄露客户机自己的身份。例如，考虑一个应用程序，它提供对研究数据库的读取访问，并允许由任意请求者进行查询。此类服务的客户可能希望验证该服务，以建立对从该服务收到的信息的信任，但出于隐私原因，可能不希望向该服务披露客户的身份。
Extensions to Kerberos are specified in this document by which a client can authenticate the Key Distribution Center (KDC) and request an anonymous ticket. The client can use the anonymous ticket to authenticate the server and protect subsequent client-server communications.
本文档中指定了Kerberos扩展，客户机可以通过该扩展对密钥分发中心（KDC）进行身份验证并请求匿名票证。客户端可以使用匿名票证对服务器进行身份验证，并保护后续的客户端-服务器通信。
By using the extensions defined in this specification, the client can request an anonymous ticket where the client may reveal the client's identity to the client's own KDC, or the client can hide the client's identity completely by using anonymous Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) as defined in Section 4.1. Using the returned anonymous ticket, the client remains
通过使用本规范中定义的扩展，客户机可以请求匿名票证，其中客户机可以向客户机自己的KDC透露客户机的身份，或者客户机可以完全隐藏客户机的身份，如第4.1节所定义的，通过使用匿名公钥加密进行Kerberos（PKINIT）中的初始身份验证。使用返回的匿名票证，客户端将保持
anonymous in subsequent Kerberos exchanges thereafter to KDCs on the cross-realm authentication path and to the server with which it communicates.
在随后的Kerberos交换中，通过跨域身份验证路径向KDC和与其通信的服务器发送匿名消息。
In this specification, the client realm in the anonymous ticket is the anonymous realm name when anonymous PKINIT is used to obtain the ticket. The client realm is the client's real realm name if the client is authenticated using the client's long-term keys. Note that a membership in a realm can imply a member of the community represented by the realm.
在本规范中，当使用匿名PKINIT获取票据时，匿名票据中的客户机领域是匿名领域名称。如果使用客户机的长期密钥对客户机进行身份验证，则客户机领域是客户机的真实领域名称。请注意，领域中的成员资格可能意味着该领域所代表的社区的成员。
The interaction with Generic Security Service Application Program Interface (GSS-API) is described after the protocol description.
协议描述后描述了与通用安全服务应用程序接口（GSS-API）的交互。
This specification replaces [RFC6112] to correct technical errors in that specification. RFC 6112 is classified as Historic; implementation of RFC 6112 is NOT RECOMMENDED. All known implementations comply with this specification and not RFC 6112.
本规范取代[RFC6112]以纠正该规范中的技术错误。RFC 6112被归类为历史记录；不建议实施RFC 6112。所有已知的实现都符合本规范，而不是RFC 6112。
In Section 7, the pepper2 string "KeyExchange" used in RFC 6112 is corrected to appear in all capital letters to comply with the string actually used by implementations.
在第7节中，RFC 6112中使用的pepper2字符串“KeyExchange”被更正为以所有大写字母显示，以符合实现实际使用的字符串。
The requirement for the anonymous option to be used when an anonymous ticket is used in a Ticket-Granting Service (TGS) request is reduced from a MUST to a SHOULD. At least one implementation does not require this; it is not necessary that both the anonymous option and anonymous ticket be used as an indicator of request type.
在票证授予服务（TGS）请求中使用匿名票证时使用匿名选项的要求从必须减少到应该。至少有一个实现不需要这样做；匿名选项和匿名票证都不必用作请求类型的指示符。
The authorization data type name "AD-INITIAL-VERIFIED-CAS" used in RFC 6112 is corrected to appear as "AD_INITIAL_VERIFIED_CAS" in this document.
RFC 6112中使用的授权数据类型名称“AD-INITIAL-VERIFIED-CAS”在本文档中更正为“AD_INITIAL_VERIFIED_CAS”。
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]中所述进行解释。
The anonymous Kerberos realm name is defined as a well-known realm name based on [RFC6111], and the value of this well-known realm name is the literal "WELLKNOWN:ANONYMOUS".
匿名Kerberos领域名称定义为基于[RFC6111]的知名领域名称，该知名领域名称的值为文字“WELLKNOWN:anonymous”。
The anonymous Kerberos principal name is defined as a well-known Kerberos principal name based on [RFC6111]. The value of the name-type field is KRB_NT_WELLKNOWN [RFC6111], and the value of the name-string field is a sequence of two KerberosString components: "WELLKNOWN" and "ANONYMOUS".
匿名Kerberos主体名称定义为基于[RFC6111]的知名Kerberos主体名称。名称类型字段的值是KRB_NT_WELLKNOWN[RFC6111]，名称字符串字段的值是两个KerberosString组件的序列：“WELLKNOWN”和“ANONYMOUS”。
The anonymous ticket flag is defined as bit 16 (with the first bit being bit 0) in the TicketFlags:
匿名票证标志在票证标签中定义为第16位（第一位为第0位）：
TicketFlags ::= KerberosFlags
-- anonymous(16)
-- TicketFlags and KerberosFlags are defined in [RFC4120]
TicketFlags ::= KerberosFlags
-- anonymous(16)
-- TicketFlags and KerberosFlags are defined in [RFC4120]
This is a new ticket flag that is used to indicate that a ticket is an anonymous one.
这是一个新的票证标志，用于指示票证是匿名票证。
An anonymous ticket is a ticket that has all of the following properties:
匿名票证是具有以下所有属性的票证：
o The cname field contains the anonymous Kerberos principal name.
o cname字段包含匿名Kerberos主体名称。
o The crealm field contains the client's realm name or the anonymous realm name.
o crealm字段包含客户端的领域名称或匿名领域名称。
o The anonymous ticket contains no information that can reveal the client's identity. However, the ticket may contain the client realm, intermediate realms on the client's authentication path, and authorization data that may provide information related to the client's identity. For example, an anonymous principal that is identifiable only as being in a particular group of users can be implemented using authorization data. Such authorization data, if included in the anonymous ticket, would disclose that the client is a member of the group observed.
o 匿名票证不包含任何可以透露客户身份的信息。然而，票据可能包含客户端领域、客户端身份验证路径上的中间领域以及可能提供与客户端身份相关信息的授权数据。例如，可以使用授权数据实现仅可识别为在特定用户组中的匿名主体。这种授权数据，如果包含在匿名票据中，将披露该客户是被观察组的成员。
o The anonymous ticket flag is set.
o 已设置匿名票证标志。
The anonymous KDC option is defined as bit 16 (with the first bit being bit 0) in the KDCOptions:
匿名KDC选项在KDC选项中定义为第16位（第一位为第0位）：
KDCOptions ::= KerberosFlags
-- anonymous(16)
-- KDCOptions and KerberosFlags are defined in [RFC4120]
KDCOptions ::= KerberosFlags
-- anonymous(16)
-- KDCOptions and KerberosFlags are defined in [RFC4120]
As described in Section 4, the anonymous KDC option is set to request an anonymous ticket in an Authentication Service (AS) request or a Ticket-Granting Service (TGS) request.
如第4节所述，匿名KDC选项设置为在身份验证服务（As）请求或票证授予服务（TGS）请求中请求匿名票证。
In order to request an anonymous ticket, the client sets the anonymous KDC option in an AS request or a TGS request.
为了请求匿名票证，客户端在AS请求或TGS请求中设置匿名KDC选项。
The rest of this section is organized as follows: it first describes protocol actions specific to AS exchanges, then it describes those of TGS exchanges. These are then followed by the description of protocol actions common to both AS and TGS and those in subsequent exchanges.
本节的其余部分组织如下：首先描述特定于as交换的协议操作，然后描述TGS交换的协议操作。然后介绍AS和TGS以及后续交换中常见的协议操作。
The client requests an anonymous ticket by setting the anonymous KDC option in an AS exchange.
客户端通过在AS exchange中设置匿名KDC选项来请求匿名票证。
The Kerberos client can use the client's long-term keys, the client's X.509 certificates [RFC4556], or any other pre-authentication data to authenticate to the KDC and request an anonymous ticket in an AS exchange where the client's identity is known to the KDC.
Kerberos客户端可以使用客户端的长期密钥、客户端的X.509证书[RFC4556]或任何其他预身份验证数据向KDC进行身份验证，并在KDC已知客户端身份的AS交换中请求匿名票证。
If the client in the AS request is anonymous, the anonymous KDC option MUST be set in the request. Otherwise, the KDC MUST return a KRB-ERROR message with the code KDC_ERR_BADOPTION.
如果AS请求中的客户端是匿名的，则必须在请求中设置匿名KDC选项。否则，KDC必须返回带有代码KDC_ERR_选项的KRB-ERROR消息。
If the client is anonymous and the KDC does not have a key to encrypt the reply (this can happen when, for example, the KDC does not support PKINIT [RFC4556]), the KDC MUST return an error message with the code KDC_ERR_NULL_KEY [RFC4120].
如果客户端是匿名的，并且KDC没有加密回复的密钥（例如，当KDC不支持PKINIT[RFC4556]时，可能会发生这种情况），KDC必须返回一条错误消息，代码为KDC_ERR_NULL_key[RFC4120]。
When policy allows, the KDC issues an anonymous ticket. If the client name in the request is the anonymous principal, the client realm (crealm) in the reply is the anonymous realm; otherwise, the client realm is the realm of the AS. As specified by [RFC4120], the client name and the client realm in the EncTicketPart of the reply MUST match with the corresponding client name and the client realm of the KDC reply; the client MUST use the client name and the client realm returned in the KDC-REP in subsequent message exchanges when using the obtained anonymous ticket.
在策略允许的情况下，KDC会发出匿名票证。如果请求中的客户端名称是匿名主体，则回复中的客户端域（crealm）是匿名域；否则，客户端领域就是AS的领域。根据[RFC4120]的规定，回复的EncTicketPart中的客户端名称和客户端域必须与KDC回复的相应客户端名称和客户端域匹配；当使用获得的匿名票证时，客户端必须在后续消息交换中使用KDC-REP中返回的客户端名称和客户端域。
The KDC MUST NOT reveal the client's identity in the authorization data of the returned ticket when populating the authorization data in a returned anonymous ticket.
当在返回的匿名票据中填充授权数据时，KDC不得在返回票据的授权数据中透露客户的身份。
The AD_INITIAL_VERIFIED_CAS authorization data, as defined in [RFC4556], contains the issuer name of the client certificate. This authorization is not applicable and MUST NOT be present in the returned anonymous ticket when anonymous PKINIT is used. When the
[RFC4556]中定义的AD_INITIAL_VERIFIED_CAS授权数据包含客户端证书的颁发者名称。当使用匿名PKINIT时，此授权不适用，且不得出现在返回的匿名票证中。当
client is authenticated (i.e., anonymous PKINIT is not used), if it is undesirable to disclose such information about the client's identity, the AD_INITIAL_VERIFIED_CAS authorization data SHOULD be removed from the returned anonymous ticket.
客户端经过身份验证（即不使用匿名PKINIT），如果不希望披露有关客户端身份的此类信息，则应从返回的匿名票据中删除AD_INITIAL_VERIFIED_CAS授权数据。
The client can use the client's key to mutually authenticate with the KDC and request an anonymous Ticket-Granting Ticket (TGT) in the AS request. In that case, the reply key is selected as normal, according to Section 3.1.3 of [RFC4120].
客户端可以使用客户端的密钥与KDC相互验证，并在AS请求中请求匿名票证授予票证（TGT）。在这种情况下，根据[RFC4120]第3.1.3节，应答密钥被选择为正常。
This sub-section defines anonymous PKINIT.
本小节定义了匿名PKINIT。
As described earlier in this section, the client can request an anonymous ticket by authenticating to the KDC using the client's identity; alternatively, without revealing the client's identity to the KDC, the Kerberos client can request an anonymous ticket as follows: the client sets the client name as the anonymous principal in the AS exchange and provides PA_PK_AS_REQ pre-authentication data [RFC4556] where the signerInfos field of the SignedData [RFC5652] of the PA_PK_AS_REQ is empty, and the certificates field is absent. Because the anonymous client does not have an associated asymmetric key pair, the client MUST choose the Diffie-Hellman key agreement method by filling in the Diffie-Hellman domain parameters in the clientPublicValue [RFC4556]. This use of the anonymous client name in conjunction with PKINIT is referred to as "anonymous PKINIT". If anonymous PKINIT is used, the realm name in the returned anonymous ticket MUST be the anonymous realm.
如本节前面所述，客户端可以通过使用客户端的身份向KDC进行身份验证来请求匿名票证；或者，在不向KDC透露客户机身份的情况下，Kerberos客户机可以请求匿名票证，如下所示：客户机将客户机名称设置为as交换中的匿名主体，并提供PA_pku_as_REQ预身份验证数据[RFC4556]，其中SignedData的signerInfos字段[RFC5652]PA_PK_AS_REQ的字段为空，且证书字段不存在。由于匿名客户端没有关联的非对称密钥对，因此客户端必须通过在clientPublicValue[RFC4556]中填写Diffie-Hellman域参数来选择Diffie-Hellman密钥协商方法。将匿名客户端名称与PKINIT结合使用称为“匿名PKINIT”。如果使用匿名PKINIT，则返回的匿名票证中的域名必须是匿名域名。
Upon receiving the anonymous PKINIT request from the client, the KDC processes the request, according to Section 3.1.2 of [RFC4120]. The KDC skips the checks for the client's signature and the client's public key (such as the verification of the binding between the client's public key and the client name) but performs otherwise applicable checks and proceeds as normal, according to [RFC4556]. For example, the AS MUST check if the client's Diffie-Hellman domain parameters are acceptable. The Diffie-Hellman key agreement method MUST be used and the reply key is derived according to Section 3.2.3.1 of [RFC4556]. If the clientPublicValue is not present in the request, the KDC MUST return a KRB-ERROR with the code KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556]. If all goes well, an anonymous ticket is generated, according to Section 3.1.3 of [RFC4120], and PA_PK_AS_REP [RFC4556] pre-authentication data is included in the KDC reply, according to [RFC4556]. If the KDC does not have an asymmetric key pair, it MAY reply anonymously or reject the authentication attempt. If the KDC replies anonymously, the
根据[RFC4120]第3.1.2节，KDC从客户端接收到匿名PKINIT请求后，处理该请求。根据[RFC4556]，KDC跳过对客户端签名和客户端公钥的检查（例如验证客户端公钥和客户端名称之间的绑定），但执行其他适用的检查并正常进行。例如，AS必须检查客户机的Diffie-Hellman域参数是否可接受。必须使用Diffie-Hellman密钥协商方法，并根据[RFC4556]第3.2.3.1节推导应答密钥。如果请求中不存在clientPublicValue，KDC必须返回KRB错误，代码为KDC_ERR_PUBLIC_KEY_ENCRYPTION_not_SUPPORTED[RFC4556]。如果一切顺利，将根据[RFC4120]第3.1.3节生成匿名票据，根据[RFC4556]，KDC回复中将包含PA_PK_AS_REP[RFC4556]预认证数据。如果KDC没有非对称密钥对，它可以匿名回复或拒绝身份验证尝试。如果KDC匿名回复，则
signerInfos field of the SignedData [RFC5652] of PA_PK_AS_REP in the reply is empty, and the certificates field is absent. The server name in the anonymous KDC reply contains the name of the TGS.
回复中PA_PK_AS_REP的SignedData[RFC5652]的signerInfos字段为空，且证书字段不存在。匿名KDC回复中的服务器名称包含TGS的名称。
Upon receipt of the KDC reply that contains an anonymous ticket and PA_PK_AS_REP [RFC4556] pre-authentication data, the client can then authenticate the KDC based on the KDC's signature in the PA_PK_AS_REP. If the KDC's signature is missing in the KDC reply (the reply is anonymous), the client MUST reject the returned ticket if it cannot authenticate the KDC otherwise.
在收到包含匿名票证和PA_PK_AS_REP[RFC4556]预身份验证数据的KDC回复后，客户端可以基于PA_PK_AS_REP中的KDC签名对KDC进行身份验证。如果KDC回复中缺少KDC签名（回复为匿名），如果客户端无法对KDC进行身份验证，则必须拒绝返回的票证。
A KDC that supports anonymous PKINIT MUST indicate the support of PKINIT, according to Section 3.4 of [RFC4556]. In addition, such a KDC MUST indicate support for anonymous PKINIT by including a padata element of padata-type PA_PKINIT_KX and empty padata-value when including PA-PK-AS-REQ in an error reply.
根据[RFC4556]第3.4节，支持匿名PKINIT的KDC必须表明支持PKINIT。此外，当在错误回复中包含PA-PK-AS-REQ时，此类KDC必须通过包含padata类型PA_PKINIT_KX的padata元素和空padata值来指示对匿名PKINIT的支持。
When included in a KDC error, PA_PKINIT_KX indicates support for anonymous PKINIT. As discussed in Section 7, when included in an AS-REP, PA_PKINIT_KX proves that the KDC and client both contributed to the session key for any use of Diffie-Hellman key agreement with PKINIT.
当包含在KDC错误中时，PA_PKINIT_KX表示支持匿名PKINIT。如第7节所述，当包含在As-REP中时，PA_PKINIT_KX证明KDC和客户端都为会话密钥提供了与PKINIT的Diffie-Hellman密钥协议的任何使用。
Note that in order to obtain an anonymous ticket with the anonymous realm name, the client MUST set the client name as the anonymous principal in the request when requesting an anonymous ticket in an AS exchange. Anonymous PKINIT is the only way via which an anonymous ticket with the anonymous realm as the client realm can be generated in this specification.
请注意，为了获得具有匿名域名称的匿名票证，在as exchange中请求匿名票证时，客户端必须将客户端名称设置为请求中的匿名主体。匿名PKINIT是在本规范中生成匿名域作为客户端域的匿名票据的唯一方法。
The client requests an anonymous ticket by setting the anonymous KDC option in a TGS exchange, and in that request, the client can use a normal Ticket-Granting Ticket (TGT) with the client's identity, an anonymous TGT, or an anonymous cross-realm TGT. If the client uses a normal TGT, the client's identity is known to the TGS.
客户端通过在TGS交换中设置匿名KDC选项来请求匿名票证，在该请求中，客户端可以使用具有客户端身份的普通票证授予票证（TGT）、匿名TGT或匿名跨域TGT。如果客户端使用普通TGT，则TGS知道客户端的身份。
Note that the client can completely hide the client's identity in an AS exchange using anonymous PKINIT, as described in the previous section.
请注意，客户端可以使用匿名PKINIT在AS exchange中完全隐藏客户端的身份，如前一节所述。
If the ticket in the PA-TGS-REQ of the TGS request is an anonymous one, the anonymous KDC option SHOULD be set in the request.
如果TGS请求的PA-TGS-REQ中的票证是匿名票证，则应在请求中设置匿名KDC选项。
When policy allows, the KDC issues an anonymous ticket. If the ticket in the TGS request is an anonymous one, the client name and the client realm are copied from that ticket; otherwise, the ticket in the TGS request is a normal ticket, the returned anonymous ticket contains the client name as the anonymous principal and the client realm as the true realm of the client. In all cases, according to [RFC4120], the client name and the client realm in the EncTicketPart of the reply MUST match with the corresponding client name and the client realm of the anonymous ticket in the reply; the client MUST use the client name and the client realm returned in the KDC-REP in subsequent message exchanges when using the obtained anonymous ticket.
在策略允许的情况下，KDC会发出匿名票证。如果TGS请求中的票据是匿名票据，则从该票据复制客户端名称和客户端域；否则，TGS请求中的票据是普通票据，返回的匿名票据包含作为匿名主体的客户端名称和作为客户端真实域的客户端域。在所有情况下，根据[RFC4120]，回复EncTicketPart中的客户端名称和客户端域必须与回复中匿名票证的相应客户端名称和客户端域匹配；当使用获得的匿名票证时，客户端必须在后续消息交换中使用KDC-REP中返回的客户端名称和客户端域。
The TGS MUST NOT reveal the client's identity in the authorization data of the returned ticket. When propagating authorization data in the ticket or in the enc-authorization-data field of the request, the TGS MUST ensure that the client confidentiality is not violated in the returned anonymous ticket. The TGS MUST process the authorization data recursively, according to Section 5.2.6 of [RFC4120], beyond the container levels such that all embedded authorization elements are interpreted. The TGS SHOULD NOT populate identity-based authorization data into an anonymous ticket in that such authorization data typically reveals the client's identity. The specification of a new authorization data type MUST specify the processing rules of the authorization data when an anonymous ticket is returned. If there is no processing rule defined for an authorization data element or the authorization data element is unknown, the TGS MUST process it when an anonymous ticket is returned as follows:
TGS不得在退回票据的授权数据中透露客户身份。在票据或请求的enc授权数据字段中传播授权数据时，TGS必须确保在返回的匿名票据中不违反客户端机密性。TGS必须根据[RFC4120]第5.2.6节的规定，在容器级别之外递归处理授权数据，以便解释所有嵌入式授权元素。TGS不应将基于身份的授权数据填充到匿名票据中，因为此类授权数据通常会显示客户的身份。新授权数据类型的规范必须指定返回匿名票证时授权数据的处理规则。如果没有为授权数据元素定义处理规则，或者授权数据元素未知，则TGS必须在返回匿名票证时按如下方式处理它：
o If the authorization data element may reveal the client's identity, it MUST be removed unless otherwise specified.
o 如果授权数据元素可能显示客户的身份，除非另有规定，否则必须将其删除。
o If the authorization data element that could reveal the client's identity is intended to restrict the use of the ticket or limit the rights otherwise conveyed in the ticket, it cannot be removed in order to hide the client's identity. In this case, the authentication attempt MUST be rejected, and the TGS MUST return an error message with the code KDC_ERR_POLICY. Note this is applicable to both critical and optional authorization data.
o 如果可能显示客户身份的授权数据元素旨在限制票据的使用或限制票据中以其他方式传递的权利，则不能删除该数据元素以隐藏客户身份。在这种情况下，必须拒绝身份验证尝试，并且TGS必须返回带有代码KDC_ERR_策略的错误消息。注：这适用于关键和可选授权数据。
o If the authorization data element is unknown, the TGS MAY remove it, or transfer it into the returned anonymous ticket, or reject the authentication attempt, based on local policy for that authorization data type unless otherwise specified. If there is no policy defined for a given unknown authorization data type, the authentication MUST be rejected. The error code is KDC_ERR_POLICY when the authentication is rejected.
o 如果授权数据元素未知，TGS可以根据该授权数据类型的本地策略将其删除，或将其传输到返回的匿名票证中，或拒绝身份验证尝试，除非另有规定。如果没有为给定的未知授权数据类型定义策略，则必须拒绝身份验证。当身份验证被拒绝时，错误代码为KDC_ERR_POLICY。
The AD_INITIAL_VERIFIED_CAS authorization data, as defined in [RFC4556], contains the issuer name of the client certificate. If it is undesirable to disclose such information about the client's identity, the AD_INITIAL_VERIFIED_CAS authorization data SHOULD be removed from an anonymous ticket.
[RFC4556]中定义的AD_INITIAL_VERIFIED_CAS授权数据包含客户端证书的颁发者名称。如果不希望披露有关客户身份的此类信息，则应从匿名票据中删除AD_INITIAL_VERIFIED_CAS授权数据。
The TGS encodes the name of the previous realm into the transited field, according to Section 3.3.3.2 of [RFC4120]. Based on local policy, the TGS MAY omit the previous realm, if the cross-realm TGT is an anonymous one, in order to hide the authentication path of the client. The unordered set of realms in the transited field, if present, can reveal which realm may potentially be the realm of the client or the realm that issued the anonymous TGT. The anonymous Kerberos realm name MUST NOT be present in the transited field of a ticket. The true name of the realm that issued the anonymous ticket MAY be present in the transited field of a ticket.
根据[RFC4120]第3.3.3.2节，TGS将前一领域的名称编码到传输字段中。基于本地策略，如果跨域TGT是匿名的，TGS可能会忽略前一个域，以隐藏客户端的身份验证路径。transited字段中无序的领域集（如果存在）可以显示哪个领域可能是客户端的领域或发布匿名TGT的领域。票证的传输字段中不得存在匿名Kerberos领域名称。发出匿名票证的领域的真实名称可能出现在票证的transited字段中。
4.3. Subsequent Exchanges and Protocol Actions Common to AS and TGS for Anonymity Support
4.3. AS和TGS通用的用于匿名支持的后续交换和协议操作
In both AS and TGS exchanges, the realm field in the KDC request is always the realm of the target KDC, not the anonymous realm when the client requests an anonymous ticket.
在AS和TGS交换中，KDC请求中的领域字段始终是目标KDC的领域，而不是客户端请求匿名票证时的匿名领域。
Absent other information, the KDC MUST NOT include any identifier in the returned anonymous ticket that could reveal the client's identity to the server.
如果没有其他信息，KDC不得在返回的匿名票证中包含任何可能向服务器透露客户端身份的标识符。
Unless anonymous PKINIT is used, if a client requires anonymous communication, then the client MUST check to make sure that the ticket in the reply is actually anonymous by checking the presence of the anonymous ticket flag in the flags field of the EncKDCRepPart. This is because KDCs ignore unknown KDC options. A KDC that does not understand the anonymous KDC option will not return an error but will instead return a normal ticket.
除非使用匿名PKINIT，否则如果客户端需要匿名通信，则客户端必须通过检查EncKDCRepPart的flags字段中是否存在匿名票证标志来检查以确保回复中的票证实际上是匿名的。这是因为KDC忽略未知的KDC选项。不理解匿名KDC选项的KDC将不会返回错误，而是返回正常的票证。
The subsequent client and server communications then proceed as described in [RFC4120].
随后，按照[RFC4120]中的说明继续进行客户端和服务器通信。
Note that the anonymous principal name and realm are only applicable to the client in Kerberos messages, and the server cannot be anonymous in any Kerberos message per this specification.
请注意，匿名主体名称和领域仅适用于Kerberos消息中的客户端，并且根据此规范，服务器在任何Kerberos消息中都不能是匿名的。
A server accepting an anonymous service ticket may assume that subsequent requests using the same ticket originate from the same client. Requests with different tickets are likely to originate from different clients.
接受匿名服务票证的服务器可能会假定使用相同票证的后续请求来自同一客户端。具有不同票证的请求可能来自不同的客户端。
Upon receipt of an anonymous ticket, the transited policy check is performed in the same way as that of a normal ticket if the client's realm is not the anonymous realm; if the client realm is the anonymous realm, absent other information, any realm in the authentication path is allowed by the cross-realm policy check.
收到匿名票证后，如果客户端的域不是匿名域，则以与普通票证相同的方式执行传输策略检查；如果客户端领域是匿名领域，并且没有其他信息，则跨领域策略检查允许身份验证路径中的任何领域。
Conforming implementations MUST support the anonymous principal with a non-anonymous realm, and they MAY support the anonymous principal with the anonymous realm using anonymous PKINIT.
一致性实现必须支持具有非匿名领域的匿名主体，并且可以使用匿名PKINIT支持具有匿名领域的匿名主体。
GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to represent the anonymous identity. In addition, Section 2.1.1 of [RFC1964] defines the single string representation of a Kerberos principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME. The anonymous principal with the anonymous realm corresponds to the GSS-API anonymous principal. A principal with the anonymous principal name and a non-anonymous realm is an authenticated principal; hence, such a principal does not correspond to the anonymous principal in GSS-API with the GSS_C_NT_ANONYMOUS name type. The [RFC1964] name syntax for GSS_KRB5_NT_PRINCIPAL_NAME MUST be used for importing the anonymous principal name with a non-anonymous realm name and for displaying and exporting these names. In addition, this syntax must be used along with the name type GSS_C_NT_ANONYMOUS for displaying and exporting the anonymous principal with the anonymous realm.
GSS-API定义名称\u type GSS\u C\u NT\u ANONYMOUS[RFC2743]来表示匿名身份。此外，[RFC1964]的第2.1.1节定义了Kerberos主体名称的单字符串表示形式，名称为\u type GSS\u KRB5\u NT\u principal\u name。具有匿名域的匿名主体对应于GSS-API匿名主体。具有匿名主体名称和非匿名域的主体是经过身份验证的主体；因此，这样的主体不对应于GSS-API中具有GSS_C_NT_匿名名称类型的匿名主体。GSS_KRB5_NT_PRINCIPAL_name的[RFC1964]名称语法必须用于导入具有非匿名域名的匿名主体名称以及显示和导出这些名称。此外，此语法必须与名称类型GSS_C_NT_ANONYMOUS一起使用，以显示和导出匿名域中的匿名主体。
At the GSS-API [RFC2743] level, an initiator/client requests the use of an anonymous principal with the anonymous realm by asserting the "anonymous" flag when calling GSS_Init_Sec_Context(). The GSS-API implementation MAY provide implementation-specific means for requesting the use of an anonymous principal with a non-anonymous realm.
在GSS-API[RFC2743]级别，发起方/客户端在调用GSS_Init_Sec_Context（）时，通过断言“匿名”标志，请求在匿名域中使用匿名主体。GSS-API实现可以提供特定于实现的方法，用于请求在非匿名领域中使用匿名主体。
GSS-API does not know or define "anonymous credentials", so the (printable) name of the anonymous principal will rarely be used by or relevant for the initiator/client. The printable name is relevant for the acceptor/server when performing an authorization decision based on the initiator name that is returned from the acceptor side upon the successful security context establishment.
GSS-API不知道或定义“匿名凭证”，因此匿名主体的（可打印）名称很少被启动器/客户端使用或与之相关。当基于成功建立安全上下文后从接收方返回的启动器名称执行授权决策时，可打印名称与接收方/服务器相关。
A GSS-API initiator MUST carefully check the resulting context attributes from the initial call to GSS_Init_Sec_Context() when requesting anonymity, because (as in the GSS-API tradition and for backwards compatibility) anonymity is just another optional context attribute. It could be that the mechanism doesn't recognize the attribute at all or that anonymity is not available for some other reasons -- and in that case, the initiator MUST NOT send the initial security context token to the acceptor, because it will likely reveal the initiator's identity to the acceptor, something that can rarely be "undone".
当请求匿名性时，GSS-API启动器必须仔细检查对GSS_Init_Sec_context（）的初始调用产生的上下文属性，因为（与GSS-API传统和向后兼容性一样）匿名性只是另一个可选的上下文属性。可能是机制根本无法识别该属性，或者由于某些其他原因，匿名性不可用——在这种情况下，发起方不得将初始安全上下文令牌发送给接受方，因为它可能会向接受方透露发起方的身份，而这是很少可以“撤消”的。
Portable initiators are RECOMMENDED to use default credentials whenever possible and request anonymity only through the input anon_req_flag [RFC2743] to GSS_Init_Sec_Context().
建议便携式启动器尽可能使用默认凭据，并且仅通过GSS_Init_Sec_Context（）的输入anon_req_标志[RFC2743]请求匿名性。
The definition in this section was motivated by protocol analysis of anonymous PKINIT (defined in this document) in building secure channels [RFC6113] and subsequent channel bindings [RFC5056]. In order to enable applications of anonymous PKINIT to form secure channels, all implementations of anonymous PKINIT need to meet the requirements of this section. There is otherwise no connection to the rest of this document.
本节中的定义源于在构建安全通道[RFC6113]和后续通道绑定[RFC5056]中对匿名PKINIT（在本文档中定义）的协议分析。为了使匿名PKINIT的应用程序能够形成安全通道，匿名PKINIT的所有实现都需要满足本节的要求。除此之外，与本文档的其余部分没有任何联系。
PKINIT is useful for constructing secure channels. To ensure that an active attacker cannot create separate channels to the client and KDC with the same known key, it is desirable that neither the KDC nor the client unilaterally determine the ticket session key. The specific reason why the ticket session key is derived jointly is discussed at the end of this section. To achieve that end, a KDC conforming to this definition MUST encrypt a randomly generated key, called the "KDC contribution key", in the PA_PKINIT_KX padata (defined next in this section). The KDC contribution key is then combined with the reply key to form the ticket session key of the returned ticket. These two keys are combined using the KRB-FX-CF2 operation defined in Section 7.1, where K1 is the KDC contribution key, K2 is the reply key, the input pepper1 is US-ASCII [ANSI.X3-4] string "PKINIT", and the input pepper2 is US-ASCII string "KEYEXCHANGE".
PKINIT对于构建安全通道非常有用。为了确保活动攻击者无法使用相同的已知密钥创建到客户端和KDC的单独通道，KDC和客户端都不需要单方面确定票据会话密钥。本节末尾将讨论联合派生票证会话密钥的具体原因。为了达到这一目的，符合此定义的KDC必须加密PA_PKINIT_KX padata（本节下文定义）中随机生成的密钥，称为“KDC贡献密钥”。然后，KDC贡献密钥与应答密钥组合，形成返回票证的票证会话密钥。使用第7.1节中定义的KRB-FX-CF2操作组合这两个键，其中K1是KDC贡献键，K2是应答键，输入pepper1是US-ASCII[ANSI.X3-4]字符串“PKINIT”，输入pepper2是US-ASCII字符串“KEYEXCHANGE”。
PA_PKINIT_KX 147
-- padata for PKINIT that contains an encrypted
-- KDC contribution key.
PA_PKINIT_KX 147
-- padata for PKINIT that contains an encrypted
-- KDC contribution key.
PA-PKINIT-KX ::= EncryptedData -- EncryptionKey
-- Contains an encrypted key randomly
-- generated by the KDC (known as the KDC contribution key).
-- Both EncryptedData and EncryptionKey are defined in [RFC4120]
PA-PKINIT-KX ::= EncryptedData -- EncryptionKey
-- Contains an encrypted key randomly
-- generated by the KDC (known as the KDC contribution key).
-- Both EncryptedData and EncryptionKey are defined in [RFC4120]
The PA_PKINIT_KX padata MUST be included in the KDC reply when anonymous PKINIT is used; it SHOULD be included if PKINIT is used with the Diffie-Hellman key exchange but the client is not anonymous; it MUST NOT be included otherwise (e.g., when PKINIT is used with the public key encryption as the key exchange).
当使用匿名PKINIT时，必须在KDC回复中包含PA_PKINIT_KX padata；如果PKINIT与Diffie-Hellman密钥交换一起使用，但客户端不是匿名的，则应包括该信息；在其他情况下，不得将其包括在内（例如，当PKINIT与公钥加密一起用作密钥交换时）。
The padata-value field of the PA-PKINIT-KX type padata contains the DER [X.680] [X.690] encoding of the Abstract Syntax Notation One (ASN.1) type PA-PKINIT-KX. The PA-PKINIT-KX structure is an EncryptedData. The cleartext data being encrypted is the DER-encoded KDC contribution key randomly generated by the KDC. The encryption key is the reply key, and the key usage number is KEY_USAGE_PA_PKINIT_KX (44).
PA-PKINIT-KX类型padata的padata值字段包含抽象语法符号1（ASN.1）类型PA-PKINIT-KX的DER[X.680][X.690]编码。PA-PKINIT-KX结构是加密数据。被加密的明文数据是由KDC随机生成的DER编码的KDC贡献密钥。加密密钥是应答密钥，密钥使用号是密钥使用量帕密钥单位KX（44）。
The client then decrypts the KDC contribution key and verifies that the ticket session key in the returned ticket is the combined key of the KDC contribution key and the reply key as described above. A conforming client MUST reject anonymous PKINIT authentication if the PA_PKINIT_KX padata is not present in the KDC reply or if the ticket session key of the returned ticket is not the combined key of the KDC contribution key and the reply key when PA-PKINIT-KX is present in the KDC reply.
然后，客户端解密KDC贡献密钥，并验证返回的票证中的票证会话密钥是KDC贡献密钥和回复密钥的组合密钥，如上所述。如果KDC回复中不存在PA-PKINIT-KX padata，或者当KDC回复中存在PA-PKINIT-KX时，返回票据的票据会话密钥不是KDC贡献密钥和回复密钥的组合密钥，则一致性客户端必须拒绝匿名PKINIT身份验证。
This protocol provides a binding between the party that generated the session key and the Diffie-Hellman exchange used to generate the reply key. Hypothetically, if the KDC did not use PA-PKINIT-KX, the client and KDC would perform a Diffie-Hellman key exchange to determine a shared key, and that key would be used as a reply key. The KDC would then generate a ticket with a session key encrypting the reply with the Diffie-Helman agreement. A man-in-the-middle (MITM) attacker would just decrypt the session key and ticket using the Diffie-Hellman key from the attacker-KDC Diffie-Hellman exchange and re-encrypt it using the key from the attacker-client Diffie-Hellman exchange, while keeping a copy of the session key and ticket. This protocol binds the ticket to the Diffie-Hellman exchange and prevents the MITM attack by requiring the session key to be created in a way that can be verified by the client.
此协议在生成会话密钥的一方和用于生成应答密钥的Diffie-Hellman交换之间提供绑定。假设，如果KDC不使用PA-PKINIT-KX，客户端和KDC将执行Diffie-Hellman密钥交换以确定共享密钥，并且该密钥将用作应答密钥。然后KDC将生成一个带有会话密钥的票证，该会话密钥使用Diffie-Helman协议对回复进行加密。中间人（MITM）攻击者只需使用来自攻击者KDC Diffie-Hellman exchange的Diffie-Hellman密钥解密会话密钥和票据，并使用来自攻击者客户端Diffie-Hellman exchange的密钥重新加密，同时保留会话密钥和票据的副本。该协议将票据绑定到Diffie-Hellman交换，并通过要求以可由客户端验证的方式创建会话密钥来防止MITM攻击。
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.
这里，计数器值1、2、3等被编码为一个八位整数。伪随机（）操作由协议密钥的类型指定。PRF+（）使用计数器为生成的密钥指定的加密类型生成random-to-key（）[RFC3961]函数所需的足够位；不需要的位从尾部移除。
Since KDCs ignore unknown options, a client requiring anonymous communication needs to make sure that the returned ticket is actually anonymous. This is because a KDC that does not understand the anonymous option would not return an anonymous ticket.
由于KDC忽略未知选项，因此需要匿名通信的客户端需要确保返回的票证实际上是匿名的。这是因为不理解匿名选项的KDC不会返回匿名票证。
By using the mechanism defined in this specification, the client does not reveal the client's identity to the server, but the client's identity may be revealed to the KDC of the server principal (when the server principal is in a different realm than that of the client) and any KDC on the cross-realm authentication path. The Kerberos client MUST verify the ticket being used is indeed anonymous before communicating with the server, otherwise, the client's identity may be revealed unintentionally.
通过使用本规范中定义的机制，客户机不会向服务器透露客户机的身份，但可以向服务器主体的KDC（当服务器主体位于与客户机不同的领域时）和跨领域身份验证路径上的任何KDC透露客户机的身份。Kerberos客户端必须在与服务器通信之前验证所使用的票据是否确实是匿名的，否则，客户端的身份可能会被无意中泄露。
In cases where specific server principals must not have access to the client's identity (for example, an anonymous poll service), the KDC can define the server-principal-specific policy that ensures any normal service ticket can NEVER be issued to any of these server principals.
在特定服务器主体不能访问客户端身份（例如，匿名轮询服务）的情况下，KDC可以定义特定于服务器主体的策略，以确保任何正常服务票证都不能颁发给这些服务器主体。
If the KDC that issued an anonymous ticket were to maintain records of the association of identities to an anonymous ticket, then someone obtaining such records could breach the anonymity. Additionally, the implementations of most (for now all) KDCs respond to requests at the time that they are received. Traffic analysis on the connection to the KDC will allow an attacker to match client identities to anonymous tickets issued. Because there are plaintext parts of the tickets that are exposed on the wire, such matching by a third-party observer is relatively straightforward. A service that is authenticated by the anonymous principals may be able to infer the identity of the client by examining and linking quasi-static protocol information such as the IP address from which a request is received or by linking multiple uses of the same anonymous ticket.
如果签发匿名票证的KDC要维护身份与匿名票证关联的记录，那么获得此类记录的人可能会破坏匿名性。此外，大多数（现在是全部）KDC的实现在收到请求时响应请求。对KDC连接的流量分析将允许攻击者将客户端身份与发出的匿名票证相匹配。由于票据的明文部分暴露在网络上，因此由第三方观察者进行匹配相对简单。由匿名主体认证的服务可以通过检查和链接准静态协议信息（例如从其接收请求的IP地址）或者通过链接相同匿名票证的多个使用来推断客户端的身份。
Two mechanisms, the FAST facility with the hide-client-names option in [RFC6113] and the Kerberos5 starttls option [RFC6251], protect the client identity so that an attacker would never be able to observe the client identity sent to the KDC. Transport- or network-layer security between the client and the server will help prevent tracking of a particular ticket to link a ticket to a user. In addition, clients can limit how often a ticket is reused to minimize ticket linking.
两种机制，即[RFC6113]中带有隐藏客户端名称选项的FAST工具和[RFC6251]中的Kerberos5 starttls选项，用于保护客户端身份，从而使攻击者永远无法观察发送到KDC的客户端身份。客户端和服务器之间的传输层或网络层安全性将有助于防止跟踪特定票证以将票证链接到用户。此外，客户端可以限制票据的重复使用频率，以最小化票据链接。
The client's real identity is not revealed when the client is authenticated as the anonymous principal. Application servers MAY reject the authentication in order to, for example, prevent information disclosure or as part of Denial-of-Service (DoS) prevention. Application servers MUST avoid accepting anonymous credentials in situations where they must record the client's identity, for example, when there must be an audit trail.
当客户端作为匿名主体进行身份验证时，不会显示客户端的真实身份。应用服务器可能会拒绝身份验证，例如，为了防止信息泄露或作为拒绝服务（DoS）预防的一部分。应用程序服务器必须避免在必须记录客户端身份的情况下接受匿名凭据，例如，必须有审核跟踪。
This document defines an 'anonymous' Kerberos well-known name and an 'anonymous' Kerberos well-known realm based on [RFC6111]. IANA has updated these two entries in the "Well-Known Kerberos Principal Names" and "Well-Known Kerberos Realm Names" registries, respectively, to refer to this document.
本文档基于[RFC6111]定义了一个“匿名”Kerberos已知名称和一个“匿名”Kerberos已知领域。IANA分别更新了“已知Kerberos主体名称”和“已知Kerberos领域名称”注册表中的这两个条目，以引用本文档。
In addition, IANA has updated the reference for PA_PKINIT_KX (147) in the "Pre-authentication and Typed Data" registry to refer to this document.
此外，IANA还更新了“预认证和键入数据”注册表中的PA_PKINIT_KX（147）参考，以参考本文件。
[ANSI.X3-4] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3-4, 1986.
[ANSI.X3-4]美国国家标准协会，“编码字符集-信息交换用7位美国标准代码”，ANSI X3-41986。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, DOI 10.17487/RFC1964, June 1996, <http://www.rfc-editor.org/info/rfc1964>.
[RFC1964]Linn，J.，“Kerberos版本5 GSS-API机制”，RFC 1964，DOI 10.17487/RFC1964，1996年6月<http://www.rfc-editor.org/info/rfc1964>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, DOI 10.17487/RFC2743, January 2000, <http://www.rfc-editor.org/info/rfc2743>.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，DOI 10.17487/RFC2743，2000年1月<http://www.rfc-editor.org/info/rfc2743>.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 2005, <http://www.rfc-editor.org/info/rfc3961>.
[RFC3961]Raeburn，K.，“Kerberos 5的加密和校验和规范”，RFC 3961，DOI 10.17487/RFC3961，2005年2月<http://www.rfc-editor.org/info/rfc3961>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <http://www.rfc-editor.org/info/rfc4120>.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC 4120，DOI 10.17487/RFC4120，2005年7月<http://www.rfc-editor.org/info/rfc4120>.
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, DOI 10.17487/RFC4556, June 2006, <http://www.rfc-editor.org/info/rfc4556>.
[RFC4556]Zhu，L.和B.Tung，“Kerberos中初始身份验证的公钥加密（PKINIT）”，RFC 4556，DOI 10.17487/RFC4556，2006年6月<http://www.rfc-editor.org/info/rfc4556>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 5652，DOI 10.17487/RFC5652，2009年9月<http://www.rfc-editor.org/info/rfc5652>.
[RFC6111] Zhu, L., "Additional Kerberos Naming Constraints", RFC 6111, DOI 10.17487/RFC6111, April 2011, <http://www.rfc-editor.org/info/rfc6111>.
[RFC6111]Zhu，L.“附加Kerberos命名约束”，RFC 6111，DOI 10.17487/RFC6111，2011年4月<http://www.rfc-editor.org/info/rfc6111>.
[RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for Kerberos", RFC 6112, DOI 10.17487/RFC6112, April 2011, <http://www.rfc-editor.org/info/rfc6112>.
[RFC6112]Zhu，L.，Leach，P.，和S.Hartman，“Kerberos的匿名性支持”，RFC 6112，DOI 10.17487/RFC6112，2011年4月<http://www.rfc-editor.org/info/rfc6112>.
[X.680] International Telecommunications Union, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation", ITU-T Recommendation X.680, ISO/IEC International Standard 8824-1:1998, 1997.
[X.680]国际电信联盟，“信息技术-抽象语法符号1（ASN.1）：基本符号规范”，ITU-T建议X.680，ISO/IEC国际标准8824-1:1998，1997。
[X.690] International Telecommunications Union, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC International Standard 8825-1:1998, 1997.
[X.690]国际电信联盟，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，ISO/IEC国际标准8825-1:1998，1997。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, <http://www.rfc-editor.org/info/rfc5056>.
[RFC5056]Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，DOI 10.17487/RFC5056，2007年11月<http://www.rfc-editor.org/info/rfc5056>.
[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for Kerberos Pre-Authentication", RFC 6113, DOI 10.17487/RFC6113, April 2011, <http://www.rfc-editor.org/info/rfc6113>.
[RFC6113]Hartman，S.和L.Zhu，“Kerberos预认证的通用框架”，RFC 6113，DOI 10.17487/RFC6113，2011年4月<http://www.rfc-editor.org/info/rfc6113>.
[RFC6251] Josefsson, S., "Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol", RFC 6251, DOI 10.17487/RFC6251, May 2011, <http://www.rfc-editor.org/info/rfc6251>.
[RFC6251]Josefsson，S.，“在传输层安全（TLS）协议上使用Kerberos版本5”，RFC 6251，DOI 10.17487/RFC6251，2011年5月<http://www.rfc-editor.org/info/rfc6251>.
Acknowledgments
致谢
JK Jaganathan helped edit early draft revisions of RFC 6112.
JK Jaganathan帮助编辑RFC 6112的早期修订草案。
Clifford Neuman contributed the core notions of this document.
Clifford Neuman提出了本文件的核心概念。
Ken Raeburn reviewed the document and provided suggestions for improvements.
Ken Raeburn审查了该文件并提出了改进建议。
Martin Rex wrote the text for the GSS-API considerations.
Martin Rex为GSS-API考虑事项编写了文本。
Nicolas Williams reviewed the GSS-API considerations section and suggested ideas for improvements.
Nicolas Williams回顾了GSS-API注意事项部分，并提出了改进意见。
Sam Hartman and Nicolas Williams were great champions of this work.
萨姆·哈特曼和尼古拉斯·威廉姆斯是这项工作的伟大捍卫者。
Miguel Garcia and Phillip Hallam-Baker reviewed the document and provided helpful suggestions.
米格尔·加西亚（Miguel Garcia）和菲利普·哈勒姆·贝克（Phillip Hallam Baker）审查了该文件，并提供了有益的建议。
In addition, the following individuals made significant contributions: Jeffrey Altman, Tom Yu, Chaskiel M. Grundman, Love Hornquist Astrand, Jeffrey Hutzelman, and Olga Kornievskaia.
此外，以下个人做出了重大贡献：杰弗里·奥尔特曼、汤姆·余、查斯基尔·格朗德曼、洛夫·霍恩奎斯特·阿斯特兰、杰弗里·哈泽尔曼和奥尔加·科尔尼夫斯卡亚。
Greg Hudson and Robert Sparks provided helpful text in this document.
Greg Hudson和Robert Sparks在本文档中提供了有用的文本。
Authors' Addresses
作者地址
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 United States of America
Larry Zhu微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
Email: larry.zhu@microsoft.com
Email: larry.zhu@microsoft.com
Paul Leach Microsoft Corporation One Microsoft Way Redmond, WA 98052 United States of America
Paul Leach微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
Email: pauljleach@msn.com
Email: pauljleach@msn.com
Sam Hartman Hadron Industries
山姆·哈特曼强子工业公司
Email: hartmans-ietf@mit.edu
Email: hartmans-ietf@mit.edu
Shawn Emery (editor) Oracle
尚恩·埃默里（编辑）甲骨文
Email: shawn.emery@gmail.com
Email: shawn.emery@gmail.com