Internet Engineering Task Force (IETF) L. Zhu
Request for Comments: 6111 Microsoft Corporation
Updates: 4120 April 2011
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) L. Zhu
Request for Comments: 6111 Microsoft Corporation
Updates: 4120 April 2011
Category: Standards Track
ISSN: 2070-1721
Additional Kerberos Naming Constraints
其他Kerberos命名约束
Abstract
摘要
This document defines new naming constraints for well-known Kerberos principal names and well-known Kerberos realm names.
本文档为知名的Kerberos主体名称和知名的Kerberos领域名称定义了新的命名约束。
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/rfc6111.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6111.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 ....................................................2
2. Conventions Used in This Document ...............................3
3. Definitions .....................................................3
3.1. Well-Known Kerberos Principal Names ........................3
3.2. Well-Known Kerberos Realm Names ............................4
4. Security Considerations .........................................5
5. Acknowledgements ................................................6
6. IANA Considerations .............................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Definitions .....................................................3
3.1. Well-Known Kerberos Principal Names ........................3
3.2. Well-Known Kerberos Realm Names ............................4
4. Security Considerations .........................................5
5. Acknowledgements ................................................6
6. IANA Considerations .............................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
Occasionally, protocol designers need to designate a Kerberos principal name or a Kerberos realm name to have a special meaning other than identifying a particular instance. An example is that the anonymous principal name and the anonymous realm name are defined for the Kerberos anonymity support [RFC6112]. This anonymity name pair conveys no more meaning than that the client's identity is not disclosed. In the case of the anonymity support, it is critical that deployed Kerberos implementations that do not support anonymity fail the authentication if the anonymity name pair is used; therefore, no access is granted accidentally to a principal who's name happens to match with that of the anonymous identity.
协议设计者有时需要指定Kerberos主体名称或Kerberos领域名称，以使其具有除标识特定实例之外的特殊含义。例如，为Kerberos匿名性支持定义了匿名主体名称和匿名领域名称[RFC6112]。这个匿名名称对所传达的意义并不比不披露客户身份更大。在支持匿名性的情况下，如果使用匿名名称对，则不支持匿名性的已部署Kerberos实现的身份验证失败是至关重要的；因此，不会意外地将访问权限授予与匿名身份的名称匹配的主体。
However, Kerberos, as defined in [RFC4120], does not have such reserved names. As such, protocol designers have resolved to use names that are exceedingly unlikely to have been used to avoid collision. Even if a registry were set up to avoid collision of new implementations, there is no guarantee for deployed implementations preventing accidental reuse of names that can lead to access being granted unexpectedly.
但是，[RFC4120]中定义的Kerberos没有此类保留名称。因此，协议设计者已决定使用极不可能用于避免冲突的名称。即使注册中心的设置是为了避免新实现的冲突，也不能保证部署的实现能够防止意外重用可能导致意外授予访问权限的名称。
The Kerberos realm name in [RFC4120] has a reserved name space although no specific name is defined and the criticality of unknown reserved realm names is not specified.
[RFC4120]中的Kerberos领域名称具有保留名称空间，但未定义特定名称，也未指定未知保留领域名称的重要性。
This document remedies these issues by defining well-known Kerberos names and the protocol behavior when a well-known name is used but not supported.
本文档通过定义已知的Kerberos名称以及使用已知名称但不受支持时的协议行为来解决这些问题。
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 this section, well-known names are defined for both the Kerberos principal name and the Kerberos realm name.
在本节中，将为Kerberos主体名称和Kerberos领域名称定义众所周知的名称。
A new name type KRB_NT_WELLKNOWN is defined for well-known principal names. The Kerberos principal name is defined in Section 6.2 of [RFC4120].
为已知的主体名称定义了新的名称类型KRB_NT_WELLKNOWN。Kerberos主体名称在[RFC4120]的第6.2节中定义。
KRB_NT_WELLKNOWN 11
韩国著名的11
A well-known principal name MUST have at least two or more KerberosString components, and the first component MUST be the string literal "WELLKNOWN".
众所周知的主体名称必须至少有两个或多个KerberosString组件，并且第一个组件必须是字符串文字“WELLKNOWN”。
If a well-known principal name is used as the client principal name or the server principal name but not supported, the Authentication Service (AS) [RFC4120] and the application server MUST reject the authentication attempt. Similarly, the Ticket Granting Service (TGS) [RFC4120] MAY reject the authentication attempt if a well-known principal name is used as the client principal name but not supported, and SHOULD reject the authentication attempt if a well-known principal name is used as the server principal name but not supported. These rules were designed to allow incremental updates and ease migration. More specifically, if a well-known principal is accepted in one realm, it is desirable to allow the cross-realm Ticket Granting Ticket (TGT) to work when not all of the realms in the cross-realm authentication path are updated; if the server principal with an identically named well-known name was created before the Key Distribution Center (KDC) is updated, it might be acceptable to allow authentication to work within a reasonably limited time window. However, unless otherwise specified, if a well-
如果已知主体名称用作客户端主体名称或服务器主体名称但不受支持，则身份验证服务（as）[RFC4120]和应用程序服务器必须拒绝身份验证尝试。类似地，如果已知主体名称用作客户端主体名称但不受支持，则票据授予服务（TGS）[RFC4120]可以拒绝身份验证尝试，如果已知主体名称用作服务器主体名称但不受支持，则应拒绝身份验证尝试。这些规则旨在允许增量更新并简化迁移。更具体地说，如果在一个领域中接受了已知主体，则希望在跨领域认证路径中的并非所有领域都被更新时允许跨领域票证授予票证（TGT）工作；如果在更新密钥分发中心（KDC）之前创建了具有相同名称的服务器主体，则允许身份验证在合理限制的时间窗口内工作是可以接受的。但是，除非另有规定，如果-
known principal name is used but not supported in any other places of Kerberos messages, authentication MUST fail. The error code is KRB_AP_ERR_PRINCIPAL_UNKNOWN, and there is no accompanying error data defined in this document for this error.
已使用已知主体名称，但Kerberos消息的任何其他位置都不支持该名称，身份验证必须失败。错误代码为KRB_AP_ERR_PRINCIPAL_UNKNOWN，本文档中没有为该错误定义的伴随错误数据。
KRB_AP_ERR_PRINCIPAL_UNKNOWN 82
-- A well-known Kerberos principal name is used but not
-- supported.
KRB_AP_ERR_PRINCIPAL_UNKNOWN 82
-- A well-known Kerberos principal name is used but not
-- supported.
Section 6.1 of [RFC4120] defines the "other" style of realm name, a new realm type WELLKNOWN is defined as a name of type "other", with the NAMETYPE part filled in with the string literal "WELLKNOWN".
[RFC4120]第6.1节定义了领域名称的“其他”样式，新的领域类型WELLKNOWN被定义为类型“其他”的名称，NAMETYPE部分用字符串文字“WELLKNOWN”填充。
other: WELLKNOWN:realm-name
其他：广为人知：域名
This name type is designated for well-known Kerberos realms.
此名称类型是为众所周知的Kerberos领域指定的。
The AS and the application server MUST reject the authentication attempt if a well-known realm name is used as the client realm or the server realm but not supported. The TGS [RFC4120] MAY reject the authentication attempt if a well-known realm name is used as the client realm but not supported, and it SHOULD reject the authentication attempt if a well-known realm name is used as the server realm but not supported. Unless otherwise specified, if a well-known realm name is used but not supported in any other places of Kerberos messages, authentication MUST fail. The error code is KRB_AP_ERR_REALM_UNKNOWN, and there is no accompanying error data defined in this document for this error.
如果已知领域名称用作客户端领域或服务器领域但不受支持，则AS和应用程序服务器必须拒绝身份验证尝试。如果已知领域名称用作客户端领域但不受支持，TGS[RFC4120]可能会拒绝身份验证尝试；如果已知领域名称用作服务器领域但不受支持，TGS[RFC4120]应该拒绝身份验证尝试。除非另有规定，否则如果使用了已知的领域名称，但Kerberos消息的任何其他位置都不支持该名称，则身份验证必须失败。错误代码为KRB_AP_ERR_REALM_UNKNOWN，并且本文档中没有为该错误定义附带的错误数据。
KRB_AP_ERR_REALM_UNKNOWN 83
-- A well-known Kerberos realm name is used but not
-- supported.
KRB_AP_ERR_REALM_UNKNOWN 83
-- A well-known Kerberos realm name is used but not
-- supported.
Unless otherwise specified, all principal names involving a well-known realm name are reserved, and if a reserved principal name is used but not supported, and if the authentication is rejected, the error code MUST be KRB_AP_ERR_PRINCIPAL_RESERVED.
除非另有规定，否则所有涉及已知领域名称的主体名称都是保留的，如果使用了保留的主体名称但不受支持，并且如果身份验证被拒绝，则错误代码必须为KRB_AP_ERR_principal_reserved。
KRB_AP_ERR_PRINCIPAL_RESERVED 84
-- A reserved Kerberos principal name is used but not
-- supported.
KRB_AP_ERR_PRINCIPAL_RESERVED 84
-- A reserved Kerberos principal name is used but not
-- supported.
There is no accompanying error data defined in this document for this error.
本文档中没有为此错误定义的附带错误数据。
According to Section 3.3.3.2 of [RFC4120], the TGS MUST add the name of the previous realm into the transited field of the returned ticket. Typically, well-known realms are defined to carry special meanings, and they are not used to refer to intermediate realms in the client's authentication path. Consequently, unless otherwise specified, the TGS MUST NOT encode a well-known Kerberos realm name into the transited field [RFC4120] of a ticket, and parties checking the transited realm path MUST reject a transited realm path that includes a well-known realm. In the case of KDCs checking the transited realm path, this means that the TRANSITED-POLICY-CHECKED flag MUST NOT be set in the resulting ticket. Aside from the hierarchical meaning of a null subfield, the DOMAIN-X500-COMPRESS encoding for transited realms [RFC4120] treats realm names as strings, although it is optimized for domain style and X.500 realm names; hence, the DOMAIN-X500-COMPRESS encoding can be used when the client realm or the server realm is reserved or when a reserved realm is in the transited field. However, if the client's realm is a well-known realm, the abbreviation forms [RFC4120] that build on the preceding name cannot be used at the start of the transited encoding. The null-subfield form (e.g., encoding ending with ",") [RFC4120] could not be used next to a well-known realm, including potentially at the beginning and end where the client and server realm names, respectively, are filled in.
根据[RFC4120]第3.3.3.2节，TGS必须将前一领域的名称添加到返回票证的transited字段中。通常，众所周知的领域被定义为具有特殊含义，并且它们不用于指代客户端身份验证路径中的中间领域。因此，除非另有规定，否则TGS不得将已知的Kerberos领域名称编码到票证的传输字段[RFC4120]中，并且检查传输领域路径的各方必须拒绝包含已知领域的传输领域路径。在KDCs检查transited realm路径的情况下，这意味着不能在结果票证中设置transited-POLICY-CHECKED标志。除了空子字段的层次含义外，transited realms的DOMAIN-X500-COMPRESS编码[RFC4120]将领域名称视为字符串，尽管它针对域名样式和X.500领域名称进行了优化；因此，当客户机域或服务器域被保留时，或者当保留域在transited字段中时，可以使用DOMAIN-X500-COMPRESS编码。但是，如果客户机的领域是众所周知的领域，则在转换编码开始时不能使用基于前面名称的缩写形式[RFC4120]。空子字段形式（例如，编码以“，”[RFC4120]结尾）不能在已知领域旁边使用，包括可能在分别填写客户端和服务器领域名称的开头和结尾。
It is possible to have a name collision with well-known names because Kerberos, as defined in [RFC4120], does not reserve names that have special meanings; accidental reuse of names MUST be avoided. If a well-known name is not supported, authentication MUST fail as specified in Section 3. Otherwise, access can be granted unintentionally, resulting in a security weakness. Consider, for example, a KDC that supports this specification but not the anonymous authentication described in [RFC6112]. Assume further that the KDC allows a principal to be created named identically to the anonymous principal. If that principal were created and given access to resources, then anonymous users might inadvertently gain access to those resources if the KDC supports anonymous authentication at some future time. Similar issues may occur with other well-known names. By requiring that KDCs reject authentication with unknown well-known names, we minimize these concerns.
可能会与已知名称发生名称冲突，因为[RFC4120]中定义的Kerberos不保留具有特殊含义的名称；必须避免意外重复使用名称。如果不支持已知名称，则身份验证必须失败，如第3节所述。否则，可能会无意中授予访问权限，从而导致安全漏洞。例如，考虑一个支持此规范的KDC，而不是在[RCF6112]中描述的匿名身份验证。进一步假设KDC允许创建与匿名主体同名的主体。如果创建了该主体并授予其对资源的访问权，那么如果KDC在将来某个时候支持匿名身份验证，则匿名用户可能会无意中获得对这些资源的访问权。其他知名品牌也可能出现类似问题。通过要求KDC拒绝使用未知的已知名称进行身份验证，我们可以最大限度地减少这些顾虑。
If a well-known name was created before the KDC is updated to conform to this specification, it SHOULD be renamed. The provisioning code that manages account creation MUST be updated to disallow creation of principals with unsupported well-known names.
如果在更新KDC以符合此规范之前创建了一个已知名称，则应将其重命名。必须更新管理帐户创建的设置代码，以禁止使用不受支持的已知名称创建主体。
The initial document was mostly based on the author's conversation with Clifford Newman and Sam Hartman.
最初的文件主要基于作者与Clifford Newman和Sam Hartman的对话。
Jeffrey Hutzelman, Ken Raeburn, and Stephen Hanna provided helpful suggestions for improvements to early revisions of this document.
Jeffrey Hutzelman、Ken Raeburn和Stephen Hanna为本文档早期修订的改进提供了有益的建议。
This document provides the framework for defining well-known Kerberos names and Kerberos realms. Two new IANA registries have been created to contain well-known Kerberos principal names and Kerberos realm names that are defined based on this document. The evaluation policy for each is "Specification Required", as specified in [RFC5226].
本文档提供了定义众所周知的Kerberos名称和Kerberos领域的框架。已经创建了两个新的IANA注册中心，其中包含基于本文档定义的著名Kerberos主体名称和Kerberos领域名称。根据[RFC5226]中的规定，每项评估政策均为“要求规范”。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for Kerberos", RFC 6112, April 2011.
[RFC6112]Zhu，L.，Leach，P.，和S.Hartman，“Kerberos的匿名性支持”，RFC 6112，2011年4月。
Author's Address
作者地址
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Larry Zhu微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: lzhu@microsoft.com
EMail: lzhu@microsoft.com