Internet Engineering Task Force (IETF) S. Emery
Request for Comments: 6542 Oracle
Updates: 4121 March 2012
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Emery
Request for Comments: 6542 Oracle
Updates: 4121 March 2012
Category: Standards Track
ISSN: 2070-1721
Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility
Kerberos版本5通用安全服务应用程序接口（GSS-API）通道绑定哈希灵活性
Abstract
摘要
Currently, channel bindings are implemented using an MD5 hash in the Kerberos Version 5 Generic Security Service Application Programming Interface (GSS-API) mechanism (RFC 4121). This document updates RFC 4121 to allow channel bindings using algorithms negotiated based on Kerberos crypto framework as defined in RFC 3961. In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange message, extensions are defined to allow future protocol extensions.
目前，通道绑定是在Kerberos版本5通用安全服务应用程序编程接口（GSS-API）机制（RFC 4121）中使用MD5哈希实现的。本文档更新了RFC 4121，以允许使用基于RFC 3961中定义的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/rfc6542.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6542.
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 to this document. Code Components extracted from this document must
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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许可证中所述的担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Channel Binding Hash Agility ....................................2
3.1. Structure of the Exts Field ................................3
3.2. The Channel Binding Extension ..............................4
4. Security Considerations .........................................4
5. IANA Considerations .............................................4
6. Acknowledgments .................................................5
7. References ......................................................5
7.1. Normative References .......................................5
7.2. Informative References .....................................5
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Channel Binding Hash Agility ....................................2
3.1. Structure of the Exts Field ................................3
3.2. The Channel Binding Extension ..............................4
4. Security Considerations .........................................4
5. IANA Considerations .............................................4
6. Acknowledgments .................................................5
7. References ......................................................5
7.1. Normative References .......................................5
7.2. Informative References .....................................5
With the recently discovered weaknesses in the MD5 hash algorithm (see [RFC6151]), there is a need to use stronger hash algorithms. The Kerberos Version 5 Generic Security Service Application Programming Interface (GSS-API) mechanism [RFC4121] uses MD5 to calculate channel binding verifiers. This document specifies an update to the mechanism that allows it to create channel binding information based on negotiated algorithms. This will allow deploying new algorithms incrementally without breaking interoperability with older implementations when new attacks arise in the future.
鉴于最近发现的MD5哈希算法的弱点（参见[RFC6151]），需要使用更强的哈希算法。Kerberos版本5通用安全服务应用程序编程接口（GSS-API）机制[RFC4121]使用MD5计算通道绑定验证器。本文档指定了对机制的更新，该机制允许它基于协商算法创建通道绑定信息。这将允许增量部署新算法，而不会在将来出现新攻击时破坏与旧实现的互操作性。
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 term "little-endian order" is used for brevity to refer to the least-significant-octet-first encoding, while the term "big-endian order" is used for the most-significant-octet-first encoding.
术语“小端顺序”用于简洁，以表示最低有效八位字节优先编码，而术语“大端顺序”用于最高有效八位字节优先编码。
When generating a channel binding verifier, Bnd, a hash is computed from the channel binding fields. Initiators MUST populate the Bnd field in order to maintain interoperability with existing acceptors. In addition, initiators MUST populate the extension field (Exts) defined below.
生成通道绑定验证器Bnd时，将从通道绑定字段计算哈希值。发起者必须填充Bnd字段，以保持与现有接受者的互操作性。此外，启动器必须填充下面定义的扩展字段（Exts）。
The 0x8003 GSS checksum has the same structure described in [RFC4121] except that the Exts field is now defined; the entire structure of the 0x8003 checksum, including the now defined Exts field, follows:
0x8003 GSS校验和与[RFC4121]中描述的结构相同，只是现在定义了Exts字段；0x8003校验和的整个结构，包括现在定义的Exts字段，如下所示：
Octet Name Description
-----------------------------------------------------------------
0..3 Lgth Number of octets in Bnd field, represented
in little-endian order; currently contains
hex value 10 00 00 00 (16).
4..19 Bnd Channel binding information, as described in
Section 4.1.1.2 of [RFC4121].
20..23 Flags Four-octet context-establishment flags in
little-endian order as described in Section
4.1.1.1 of [RFC4121].
24..25 DlgOpt The delegation option identifier (=1) in
little-endian order [optional]. This field
and the next two fields are present if and
only if GSS_C_DELEG_FLAG is set as described
in Section 4.1.1.1 of [RFC4121].
26..27 Dlgth The length of the Deleg field in
little-endian order [optional].
28..(n-1) Deleg KRB_CRED message (n = Dlgth + 28) [optional].
n..last Exts Extensions.
Octet Name Description
-----------------------------------------------------------------
0..3 Lgth Number of octets in Bnd field, represented
in little-endian order; currently contains
hex value 10 00 00 00 (16).
4..19 Bnd Channel binding information, as described in
Section 4.1.1.2 of [RFC4121].
20..23 Flags Four-octet context-establishment flags in
little-endian order as described in Section
4.1.1.1 of [RFC4121].
24..25 DlgOpt The delegation option identifier (=1) in
little-endian order [optional]. This field
and the next two fields are present if and
only if GSS_C_DELEG_FLAG is set as described
in Section 4.1.1.1 of [RFC4121].
26..27 Dlgth The length of the Deleg field in
little-endian order [optional].
28..(n-1) Deleg KRB_CRED message (n = Dlgth + 28) [optional].
n..last Exts Extensions.
where Exts is the concatenation of zero, one, or more individual extensions, each of which consists of the following, in order:
其中Exts是零个、一个或多个单独扩展的串联，每个扩展按顺序由以下内容组成：
type -- big-endian-order unsigned integer, 32 bits, which contains the type of extension length -- big-endian-order unsigned integer, 32 bits, which contains the length, in octets, of the extension data encoded as an array of octets immediately following this field data -- octet string of extension information
type--big-endian顺序无符号整数，32位，它包含扩展长度的类型--big-endian顺序无符号整数，32位，它包含扩展数据的长度（以八位字节为单位），该扩展数据编码为紧跟在该字段数据之后的八位字节数组--扩展信息的八位字节字符串
If multiple extensions are present, then there MUST be at most one instance of a given extension type.
如果存在多个扩展，那么给定扩展类型最多只能有一个实例。
When channel binding is used, the Exts MUST include the following extension:
使用通道绑定时，Exts必须包括以下扩展：
data-type 0x00000000
数据类型0x00000000
data-value
数据值
The output obtained by applying the Kerberos V get_mic operation [RFC3961] with key usage number 43 to the channel binding data as described in [RFC4121], Section 4.1.1.2 (using get_mic instead of MD5). The key used is the sub-session key from the authenticator, if it is present; otherwise, the key used is the session key from the ticket. The get_mic algorithm is chosen as the "required checksum mechanism" for the encryption type of the key used.
如[RFC4121]第4.1.1.2节所述，通过将密钥使用编号为43的Kerberos V get_mic操作[RFC3961]应用于通道绑定数据而获得的输出（使用get_mic而不是MD5）。使用的密钥是来自认证器的子会话密钥（如果存在）；否则，使用的密钥是票据中的会话密钥。对于所用密钥的加密类型，选择get_mic算法作为“必需的校验和机制”。
Initiators that are unwilling to use an MD5 hash of the channel bindings MUST set the Bnd field to sixteen octets of hex value FF.
不愿意使用通道绑定MD5散列的启动器必须将Bnd字段设置为十六个八位字节的十六进制值FF。
With this mechanism, initiators get no indication as to whether the acceptors check or ignore channel bindings.
使用这种机制，启动器不会得到关于接受方是否检查或忽略通道绑定的指示。
It is up to the application whether or not to enforce the use of channel bindings. [RFC5056] and [RFC5554] give guidance for application developers on channel binding usage.
是否强制使用通道绑定取决于应用程序。[RFC5056]和[RFC5554]为应用程序开发人员提供有关通道绑定使用的指导。
IANA has created a new top-level registry titled "Kerberos V GSS-API Mechanism Parameters," separate from the existing Kerberos parameters registry. Within this registry, IANA has created a sub-registry of "Kerberos V GSS-API Mechanism Extension Types" with four-field entries (Type Number, Type Name, Description, and Reference) and, initially, a single registration: 0x00000000, "Channel Binding MIC," "Extension for the verifier of the channel bindings," [RFC6542].
IANA创建了一个新的顶级注册表，名为“Kerberos V GSS-API机制参数”，与现有的Kerberos参数注册表分离。在这个注册表中，IANA创建了一个“Kerberos V GSS-API机制扩展类型”的子注册表，其中包含四个字段条目（类型编号、类型名称、描述和引用）以及一个初始注册：0x00000000、“通道绑定MIC”、“通道绑定验证器扩展”[RFC6542]。
Using the guidelines for allocation as described in [RFC5226], type number assignments are as follows:
使用[RFC5226]中所述的分配指南，类型编号分配如下：
0x00000000 - 0x000003FF IETF Review
0x00000000-0x000003FF IETF审查
0x00000400 - 0xFFFFF3FF Specification Required
0x00000400-需要0xFFFFF3FF规范
0xFFFFF400 - 0xFFFFFFFF Private Use
0xFFFFF400-0xFFFFFFFF专用
The author would like to thank Larry Zhu, Nicolas Williams, Sam Hartman, Jeffrey Hutzelman, and Simon Josefsson for their help in reviewing and providing valuable feedback on this document.
作者要感谢Larry Zhu、Nicolas Williams、Sam Hartman、Jeffrey Hutzelman和Simon Josefsson在审查本文件并提供宝贵反馈方面提供的帮助。
[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月。
[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月。
[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月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，2007年11月。
[RFC5554] Williams, N., "Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings", RFC 5554, May 2009.
[RFC5554]Williams，N.“用于通道绑定的通用安全服务应用程序接口（GSS-API）的澄清和扩展”，RFC 5554，2009年5月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 61512011年3月。
Author's Address
作者地址
Shawn Emery Oracle 500 Eldorado Blvd, Building 1 Broomfield, CO 80021 USA
美国科罗拉多州布鲁姆菲尔德市埃尔多拉多大道500号1号楼Shawn Emery Oracle 80021
EMail: shawn.emery@oracle.com
EMail: shawn.emery@oracle.com