Network Working Group N. Williams
Request for Comments: 4402 Sun
Category: Standards Track February 2006
Network Working Group N. Williams
Request for Comments: 4402 Sun
Category: Standards Track February 2006
A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism
Kerberos V通用安全服务应用程序接口（GSS-API）机制的伪随机函数（PRF）
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context.
本文档基于为Kerberos V加密框架定义的伪随机函数（PRF），为通用安全服务应用程序接口（GSS-API）的Kerberos V机制定义了伪随机函数（PRF），用于为给定Kerberos V GSS-API安全上下文的应用程序协议设置密钥。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Kerberos V GSS Mechanism PRF ....................................2
3. IANA Considerations .............................................3
4. Security Considerations .........................................3
5. Normative References ............................................4
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Kerberos V GSS Mechanism PRF ....................................2
3. IANA Considerations .............................................3
4. Security Considerations .........................................3
5. Normative References ............................................4
This document specifies the Kerberos V GSS-API mechanism's [RFC4121] pseudo-random function corresponding to [RFC4401]. The function is a "PRF+" style construction. For more information see [RFC4401], [RFC2743], [RFC2744], and [RFC4121].
本文档指定了与[RFC4401]对应的Kerberos V GSS-API机制的[RFC4121]伪随机函数。该功能为“PRF+”式结构。有关更多信息，请参阅[RFC4401]、[RFC2743]、[RFC2744]和[RFC4121]。
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 GSS-API PRF [RFC4401] function for the Kerberos V mechanism [RFC4121] shall be the output of a PRF+ function based on the encryption type's PRF function keyed with the negotiated session key of the security context corresponding to the 'prf_key' input parameter of GSS_Pseudo_random().
Kerberos V机制[RFC4121]的GSS-API PRF[RFC4401]函数应是基于加密类型的PRF函数的PRF+函数的输出，该函数使用与GSS_Pseudo_random（）的“PRF_key”输入参数相对应的安全上下文的协商会话密钥进行键控。
This PRF+ MUST be keyed with the key indicated by the 'prf_key' input parameter as follows:
必须使用“PRF_键”输入参数指示的键输入该PRF+，如下所示：
o GSS_C_PRF_KEY_FULL -- use the sub-session key asserted by the acceptor, if any, or the sub-session asserted by the initiator, if any, or the Ticket's session key
o GSS_C_PRF_KEY_FULL——使用由接受者断言的子会话密钥（如果有），或由发起方断言的子会话密钥（如果有），或票据的会话密钥
o GSS_C_PRF_KEY_PARTIAL -- use the sub-session key asserted by the initiator, if any, or the Ticket's session key
o GSS_C_PRF_KEY_PARTIAL——使用发起者声明的子会话密钥（如果有）或票据的会话密钥
The PRF+ function is a simple counter-based extension of the Kerberos V pseudo-random function [RFC3961] for the encryption type of the security context's keys:
PRF+函数是Kerberos V伪随机函数[RFC3961]的一个简单的基于计数器的扩展，用于安全上下文密钥的加密类型：
PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
Tn = pseudo-random(K, n || S)
Tn=伪随机（K，n|S）
where '||' is the concatenation operator, 'n' is encoded as a network byte order 32-bit unsigned binary number, truncate(L, S) truncates the input octet string S to length L, and pseudo-random() is the Kerberos V pseudo-random function [RFC3961].
其中“| |”是串联运算符，“n”被编码为网络字节顺序32位无符号二进制数，truncate（L，S）将输入八位字符串S截断为长度L，pseudo-random（）是Kerberos V伪随机函数[RFC3961]。
The maximum output size of the Kerberos V mechanism's GSS-API PRF then is, necessarily, 2^32 times the output size of the pseudo-random() function for the encryption type of the given key.
Kerberos V机制的GSS-API PRF的最大输出大小必然是给定密钥加密类型的pseudo-random（）函数输出大小的2^32倍。
When the input size is longer than 2^14 octets as per [RFC4401] and exceeds an implementation's resources, then the mechanism MUST return GSS_S_FAILURE and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status code.
根据[RFC4401]的规定，当输入大小超过2^14个八位字节并超过实现的资源时，该机制必须返回GSS_s_FAILURE和GSS_KRB5_s_KG_input_TOO_作为次要状态代码。
This document has no IANA considerations currently. If and when a relevant IANA registry of GSS-API symbols and constants is created, then the GSS_KRB5_S_KG_INPUT_TOO_LONG minor status code should be added to such a registry.
本文件目前没有IANA考虑事项。如果创建了GSS-API符号和常量的相关IANA注册表，则应将GSS_KRB5_S_KG_INPUT_TOO_LONG次要状态代码添加到该注册表中。
Kerberos V encryption types' PRF functions use a key derived from contexts' session keys and should preserve the forward security properties of the mechanisms' key exchanges.
Kerberos V加密类型的PRF函数使用从上下文会话密钥派生的密钥，并应保留机制密钥交换的前向安全属性。
Legacy Kerberos V encryption types may be weak, particularly the single-DES encryption types.
遗留Kerberos V加密类型可能很弱，尤其是单一DES加密类型。
See also [RFC4401] for generic security considerations of GSS_Pseudo_random().
有关GSS_Pseudo_random（）的一般安全注意事项，请参见[RFC4401]。
See also [RFC3961] for generic security considerations of the Kerberos V cryptographic framework.
有关Kerberos V加密框架的一般安全注意事项，请参见[RFC3961]。
Use of Ticket session keys, rather than sub-session keys, when initiators and acceptors fail to assert sub-session keys, is dangerous as ticket reuse can lead to key reuse; therefore, initiators should assert sub-session keys always, and acceptors should assert sub-session keys at least when initiators fail to do so.
当发起者和接受者无法断言子会话密钥时，使用票据会话密钥而不是子会话密钥是危险的，因为票据重用可能导致密钥重用；因此，发起者应该始终声明子会话密钥，而接受者应该至少在发起者未能声明子会话密钥时声明子会话密钥。
The computational cost of computing this PRF+ may vary depending on the Kerberos V encryption types being used, but generally the computation of this PRF+ gets more expensive as the input and output octet string lengths grow (note that the use of a counter in the PRF+ construction allows for parallelization). This means that if an application can be tricked into providing very large input octet strings and requesting very long output octet strings, then that may constitute a denial of service attack on the application; therefore, applications SHOULD place appropriate limits on the size of any input octet strings received from their peers without integrity protection.
计算此PRF+的计算成本可能因使用的Kerberos V加密类型而异，但通常，随着输入和输出八位字节字符串长度的增长，此PRF+的计算成本会变得更高（请注意，在PRF+构造中使用计数器允许并行化）。这意味着，如果一个应用程序被诱骗提供非常大的输入八位字节字符串并请求非常长的输出八位字节字符串，那么这可能构成对该应用程序的拒绝服务攻击；因此，应用程序应在没有完整性保护的情况下，对从对等方接收的任何输入八位字节字符串的大小进行适当限制。
[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月。
[RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.
[RFC2744]Wray，J.，“通用安全服务API第2版：C-绑定”，RFC 2744，2000年1月。
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3961]Raeburn，K.，“Kerberos 5的加密和校验和规范”，RFC 3961，2005年2月。
[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月。
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)", RFC 4401, February 2006.
[RFC4401]Williams，N.，“通用安全服务应用程序接口（GSS-API）的伪随机函数（PRF）API扩展”，RFC4401，2006年2月。
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 Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。