Network Working Group N. Williams Request for Comments: 5179 Sun Category: Standards Track May 2008
Network Working Group N. Williams Request for Comments: 5179 Sun Category: Standards Track May 2008
Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism
Kerberos V GSS机制的通用安全服务应用程序接口(GSS-API)基于域的服务名称映射
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。
Abstract
摘要
This document describes the mapping of Generic Security Service Application Program Interface (GSS-API) domain-name-based service principal names onto Kerberos V principal names.
本文档描述了基于通用安全服务应用程序接口(GSS-API)域名的服务主体名称到Kerberos V主体名称的映射。
Table of Contents
目录
1. Domain-Based Names for the Kerberos V GSS-API Mechanism . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . . 2 3. Internationalization Considerations . . . . . . . . . . . . . . 2 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 6. Normative References . . . . . . . . . . . . . . . . . . . . . 3
1. Domain-Based Names for the Kerberos V GSS-API Mechanism . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . . 2 3. Internationalization Considerations . . . . . . . . . . . . . . 2 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 6. Normative References . . . . . . . . . . . . . . . . . . . . . 3
In accordance with [RFC5178], this document provides the mechanism-specific details needed to implement GSS-API [RFC2743] domain-based service names with the Kerberos V GSS-API mechanism [RFC4121].
根据[RFC5178],本文档提供了使用Kerberos V GSS-API机制[RFC4121]实现GSS-API[RFC2743]基于域的服务名称所需的特定于机制的详细信息。
GSS_C_NT_DOMAINBASED_SERVICE name SHOULD be mapped to Kerberos V principal names as follows:
GSS_C_NT_基于域的_服务名称应映射到Kerberos V主体名称,如下所示:
o the <service> name becomes the first (0th) component of the Kerberos V principal name;
o <service>名称成为Kerberos V主体名称的第一(0)个组件;
o the <hostname> becomes the second component of the Kerberos V principal name;
o <hostname>成为Kerberos V主体名称的第二个组件;
o the <domain> name becomes the third component of the Kerberos V principal name;
o <domain>名称成为Kerberos V主体名称的第三个组件;
o the realm of the resulting principal name is that which corresponds to the domain name, treated as a hostname.
o 结果主体名称的领域是与域名相对应的领域,被视为主机名。
The same name canonicalization considerations and methods as used elsewhere in the Kerberos V GSS-API mechanism [RFC4121] and Kerberos V [RFC4120] in general apply here.
Kerberos V GSS-API机制[RFC4121]和Kerberos V[RFC4120]中其他地方使用的相同名称规范化注意事项和方法通常适用于此处。
Implementations SHOULD use a Kerberos V name-type of NTT-SRVT-HST-DOMAIN (which has the value 12) but MAY use NT-UNKNOWN instead.
实现应该使用Kerberos V名称类型NTT-SRVT-HST-DOMAIN(其值为12),但可以使用NT-UNKNOWN。
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]中所述进行解释。
It is unclear, at this time, how best to address internationalization of Kerberos V domain-based principal names. This is because the Kerberos V core protocol internationalization project is incomplete.
目前还不清楚如何最好地解决Kerberos V基于域的主体名称的国际化问题。这是因为Kerberos V核心协议国际化项目不完整。
However, clearly the best way to interoperate when using Kerberos V domain-based principal names is to use ACE-encoded internationalized domain names [RFC3490] for the hostname and domain name slots of a Kerberos V domain-based principal name. Therefore Kerberos V GSS-API mechanism implementations MUST do just that.
但是,显然,在使用Kerberos V基于域的主体名称时,最好的互操作方式是使用ACE编码的国际化域名[RFC3490]作为Kerberos V基于域的主体名称的主机名和域名插槽。因此,Kerberos V GSS-API机制实现必须做到这一点。
o The domain-based name, of generic form, "ldap@foo.example@ds1.foo.example" may map to a Kerberos V principal name like: "ldap/ds1.foo.example/ foo.example@FOO.EXAMPLE"
o 基于域的通用名称,”ldap@foo.example@“ds1.foo.example”可能映射到Kerberos V主体名称,如:“ldap/ds1.foo.example/foo”。example@FOO.EXAMPLE"
o The domain-based name, of generic form, "kadmin@foo.example@kdc1.foo.example" may map to a Kerberos V principal name like: "kadmin/kdc1.foo.example/ foo.example@FOO.EXAMPLE"
o 基于域的通用名称,”kadmin@foo.example@kdc1.foo.example“可以映射到Kerberos V主体名称,如:“kadmin/kdc1.foo.example/foo”。example@FOO.EXAMPLE"
See [RFC5178].
见[RFC5178]。
It is important for the security of protocols using the Kerberos V GSS-API mechanism and domain-based names, that the realm of domain-based principal names be derived from the hostname, rather than the domain name slots of the input domain-based name string.
对于使用Kerberos V GSS-API机制和基于域的名称的协议的安全性来说,基于域的主体名称的领域必须从主机名派生,而不是从输入的基于域的名称字符串的域名槽派生。
[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月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]Linn,J.,“通用安全服务应用程序接口版本2,更新1”,RFC 2743,2000年1月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom,P.,Hoffman,P.,和A.Costello,“应用程序中的域名国际化(IDNA)”,RFC 34902003年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月。
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
[RFC4121]Zhu,L.,Jaganathan,K.,和S.Hartman,“Kerberos版本5通用安全服务应用程序接口(GSS-API)机制:版本2”,RFC 41212005年7月。
[RFC5178] Williams, N. and A. Melnikov, "Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type", RFC 5178, May 2008.
[RFC5178]Williams,N.和A.Melnikov,“通用安全服务应用程序接口(GSS-API)国际化和基于域的服务名称和名称类型”,RFC 5178,2008年5月。
Author's Address
作者地址
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct. Austin, TX 78727 US
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct。德克萨斯州奥斯汀78727美国
EMail: Nicolas.Williams@sun.com
EMail: Nicolas.Williams@sun.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有(C)IETF信托基金(2008年)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供,贡献者、他/她所代表或赞助的组织(如有)、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.