Internet Engineering Task Force (IETF) J. Altman
Request for Comments: 5929 Secure Endpoints
Category: Standards Track N. Williams
ISSN: 2070-1721 Oracle
L. Zhu
Microsoft Corporation
July 2010
Internet Engineering Task Force (IETF) J. Altman
Request for Comments: 5929 Secure Endpoints
Category: Standards Track N. Williams
ISSN: 2070-1721 Oracle
L. Zhu
Microsoft Corporation
July 2010
Channel Bindings for TLS
TLS的通道绑定
Abstract
摘要
This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding).
根据RFC 5056（通道绑定），本文档定义了传输层安全性（TLS）的三种通道绑定类型：TLS unique、TLS server Endpoint和TLS unique for telnet。
Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry.
请注意，根据实施经验，本文档更改了通道绑定类型IANA注册表中“tls unique”通道绑定类型的原始定义。
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/rfc5929.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5929.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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
2. Conventions Used in This Document ...............................3
3. The 'tls-unique' Channel Binding Type ...........................3
3.1. Description ................................................3
3.2. Registration ...............................................4
4. The 'tls-server-end-point' Channel Binding Type .................5
4.1. Description ................................................5
4.2. Registration ...............................................6
5. The 'tls-unique-for-telnet' Channel Binding Type ................6
5.1. Description ................................................7
5.2. Registration ...............................................7
6. Applicability of TLS Channel Binding Types ......................7
7. Required Application Programming Interfaces ....................10
8. Description of Backwards-Incompatible Changes Made
Herein to 'tls-unique' .........................................10
9. IANA Considerations ............................................11
10. Security Considerations .......................................11
10.1. Cryptographic Algorithm Agility ..........................12
10.2. On Disclosure of Channel Bindings Data by
Authentication Mechanisms ................................12
11. References ....................................................13
11.1. Normative References .....................................13
11.2. Informative References ...................................14
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. The 'tls-unique' Channel Binding Type ...........................3
3.1. Description ................................................3
3.2. Registration ...............................................4
4. The 'tls-server-end-point' Channel Binding Type .................5
4.1. Description ................................................5
4.2. Registration ...............................................6
5. The 'tls-unique-for-telnet' Channel Binding Type ................6
5.1. Description ................................................7
5.2. Registration ...............................................7
6. Applicability of TLS Channel Binding Types ......................7
7. Required Application Programming Interfaces ....................10
8. Description of Backwards-Incompatible Changes Made
Herein to 'tls-unique' .........................................10
9. IANA Considerations ............................................11
10. Security Considerations .......................................11
10.1. Cryptographic Algorithm Agility ..........................12
10.2. On Disclosure of Channel Bindings Data by
Authentication Mechanisms ................................12
11. References ....................................................13
11.1. Normative References .....................................13
11.2. Informative References ...................................14
Subsequent to the publication of "On Channel Bindings" [RFC5056], three channel binding types for Transport Layer Security (TLS) were proposed, reviewed, and added to the IANA channel binding type registry, all in accordance with [RFC5056]. Those channel binding types are: 'tls-unique', 'tls-server-end-point', and 'tls-unique-for-telnet'. It has become desirable to have these channel binding types re-registered through an RFC so as to make it easier to reference them, and to correct them to describe actual implementations. This document does just that. The authors of those three channel binding types have transferred, or have indicated that they will transfer, "ownership" of those channel binding types to the IESG.
在发布“通道绑定上”[RFC5056]之后，提出了三种传输层安全（TLS）通道绑定类型，并对其进行了审查，并将其添加到IANA通道绑定类型注册表中，所有这些都符合[RFC5056]。这些通道绑定类型是：“tls unique”、“tls server end point”和“tls unique for telnet”。希望通过RFC重新注册这些通道绑定类型，以便更容易地引用它们，并更正它们以描述实际实现。本文件正是这样做的。这三种通道绑定类型的作者已将或表示将把这些通道绑定类型的“所有权”转让给IESG。
We also provide some advice on the applicability of these channel binding types, as well as advice on when to use which. Additionally, we provide an abstract API that TLS implementors should provide, by which to obtain channel bindings data for a TLS connection.
我们还提供了一些关于这些通道绑定类型的适用性的建议，以及关于何时使用哪种类型的建议。此外，我们还提供了TLS实现者应该提供的抽象API，通过该API可以获取TLS连接的通道绑定数据。
WARNING: it turns out that the first implementor implemented and deployed something rather different than what was described in the IANA registration for 'tls-unique'. Subsequently, it was decided that we should adopt that form of 'tls-unique'. This means that this document makes a backwards-incompatible change to 'tls-unique'. See Section 8 for more details.
警告：事实证明，第一个实现者实现并部署了与IANA注册中描述的“tls unique”不同的内容。随后，我们决定采用这种形式的“tls独特”。这意味着本文档对“tls unique”进行了向后不兼容的更改。详见第8节。
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]中所述进行解释。
IANA updated the registration of the 'tls-unique' channel binding type to match the description below. There are material and substantial changes from the original registration, both in the description as well as registration meta-data (such as registration ownership).
IANA更新了“tls唯一”通道绑定类型的注册，以匹配以下描述。与原始注册相比，在描述和注册元数据（如注册所有权）方面都有重大和实质性的变化。
Description: The first TLS Finished message sent (note: the Finished struct, not the TLS record layer message containing it) in the most recent TLS handshake of the TLS connection being bound to (note: TLS connection, not session, so that the channel binding is specific to each connection regardless of whether session resumption is used). If TLS renegotiation takes place before the channel binding
描述：在要绑定到的TLS连接的最新TLS握手中发送的第一条TLS完成消息（注意：TLS连接，而不是会话，因此通道绑定特定于每个连接，无论是否使用会话恢复）。如果TLS重新协商在通道绑定之前发生
operation, then the first TLS Finished message sent of the latest/ inner-most TLS connection is used. Note that for full TLS handshakes, the first Finished message is sent by the client, while for abbreviated TLS handshakes (session resumption), the first Finished message is sent by the server.
操作，则使用最新/最内部TLS连接发送的第一条TLS完成消息。请注意，对于完整TLS握手，第一条完成的消息由客户端发送，而对于缩写TLS握手（会话恢复），第一条完成的消息由服务器发送。
WARNING: The definition, security, and interoperability considerations of this channel binding type have changed since the original registration. Implementors should read the document that last updated this registration for more information.
警告：自原始注册以来，此通道绑定类型的定义、安全性和互操作性注意事项已更改。实施者应阅读上次更新此注册的文档以了解更多信息。
Interoperability note:
互操作性说明：
This definition of 'tls-unique' means that a channel's bindings data may change over time, which in turn creates a synchronization problem should the channel's bindings data change between the time that the client initiates authentication with channel binding and the time that the server begins to process the client's first authentication message. If that happens, the authentication attempt will fail spuriously.
“tls unique”的定义意味着通道的绑定数据可能会随时间而变化，如果在客户机使用通道绑定启动身份验证和服务器开始处理客户机的第一条身份验证消息之间，通道的绑定数据发生变化，则这反过来会产生同步问题。如果发生这种情况，身份验证尝试将错误地失败。
Based on the fact that while servers may request TLS renegotiation, only clients may initiate it, this synchronization problem can be avoided by clients and servers as follows: server applications MUST NOT request TLS renegotiation during phases of the application protocol during which application-layer authentication occurs. Client applications SHOULD NOT initiate TLS renegotiation between the start and completion of authentication.
由于服务器可以请求TLS重新协商，但只有客户端可以启动，因此客户端和服务器可以通过以下方式避免此同步问题：服务器应用程序不得在应用程序层身份验证发生期间的应用程序协议阶段请求TLS重新协商。客户端应用程序不应在开始和完成身份验证之间启动TLS重新协商。
The rationale for making the server behavior a requirement while the client behavior is only a recommendation is that there typically exist TLS APIs for requesting renegotiation on the server side of a TLS connection, while many client TLS stacks do not provide fine-grained control over when TLS renegotiation occurs.
当客户机行为只是一项建议时，将服务器行为作为一项要求的基本原理是，通常存在用于在TLS连接的服务器端请求重新协商的TLS API，而许多客户机TLS堆栈不提供对何时发生TLS重新协商的细粒度控制。
Application protocols SHOULD be designed in such a way that a server would never need to request TLS renegotiation immediately before or during application-layer authentication.
应用程序协议的设计应确保服务器在应用程序层身份验证之前或期间不需要立即请求TLS重新协商。
o Channel binding unique prefix: tls-unique
o 通道绑定唯一前缀：tls unique
o Channel binding type: unique
o 通道绑定类型：唯一
o Channel type: TLS [RFC5246]
o 信道类型：TLS[RFC5246]
o Published specification: <RFC 5929>
o 已发布规范：<RFC 5929>
o Channel binding is secret: no
o 通道绑定是秘密：否
o Description: <See specification>
o 说明：<参见规范>
o Intended usage: COMMON
o 预期用途：普通
o Person and email address to contact for further information: Larry Zhu (larry.zhu@microsoft.com), Nicolas Williams (Nicolas.Williams@oracle.com).
o 联系人和电子邮件地址以获取更多信息：Larry Zhu（Larry。zhu@microsoft.com)，Nicolas Williams（Nicolas。Williams@oracle.com).
o Owner/Change controller name and email address: IESG.
o 所有者/变更控制器名称和电子邮件地址：IESG。
o Expert reviewer name and contact information: IETF TLS WG (tls@ietf.org, failing that, ietf@ietf.org)
o 专家评审人姓名和联系方式：IETF TLS WG(tls@ietf.org，否则，ietf@ietf.org)
o Note: see the published specification for advice on the applicability of this channel binding type.
o 注：有关此通道绑定类型适用性的建议，请参阅已发布的规范。
IANA updated the registration of the 'tls-server-end-point' channel binding type to match the description below. Note that the only material changes from the original registration are: the "owner" (now the IESG), the contacts, the published specification, and a note indicating that the published specification should be consulted for applicability advice. References were added to the description. All other fields of the registration are copied here for the convenience of readers.
IANA更新了“tls服务器端点”通道绑定类型的注册，以匹配以下描述。请注意，与原始注册相比，唯一的实质性变更是：“所有者”（现在的IESG）、联系人、发布的规范以及表明应参考发布的规范以获得适用性建议的注释。说明中添加了引用。为方便读者，此处复制了注册的所有其他字段。
Description: The hash of the TLS server's certificate [RFC5280] as it appears, octet for octet, in the server's Certificate message. Note that the Certificate message contains a certificate_list, in which the first element is the server's certificate.
描述：TLS服务器证书[RFC5280]的哈希值，在服务器的证书消息中以八位字节表示。请注意，证书消息包含一个证书列表，其中第一个元素是服务器的证书。
The hash function is to be selected as follows:
哈希函数的选择如下所示：
o if the certificate's signatureAlgorithm uses a single hash function, and that hash function is either MD5 [RFC1321] or SHA-1 [RFC3174], then use SHA-256 [FIPS-180-3];
o 如果证书的signatureAlgorithm使用单个哈希函数，并且该哈希函数是MD5[RFC1321]或SHA-1[RFC3174]，则使用SHA-256[FIPS-180-3]；
o if the certificate's signatureAlgorithm uses a single hash function and that hash function neither MD5 nor SHA-1, then use the hash function associated with the certificate's signatureAlgorithm;
o 如果证书的signatureAlgorithm使用单个哈希函数，且该哈希函数既不是MD5也不是SHA-1，则使用与证书的signatureAlgorithm关联的哈希函数；
o if the certificate's signatureAlgorithm uses no hash functions or uses multiple hash functions, then this channel binding type's channel bindings are undefined at this time (updates to is channel binding type may occur to address this issue if it ever arises).
o 如果证书的signatureAlgorithm不使用哈希函数或使用多个哈希函数，则此通道绑定类型的通道绑定此时未定义（如果出现此问题，可能会更新到is通道绑定类型以解决此问题）。
The reason for using a hash of the certificate is that some implementations need to track the channel binding of a TLS session in kernel-mode memory, which is often at a premium.
使用证书哈希的原因是，一些实现需要在内核模式内存中跟踪TLS会话的通道绑定，这通常是非常昂贵的。
o Channel binding unique prefix: tls-server-end-point
o 通道绑定唯一前缀：tls服务器端点
o Channel binding type: end-point
o 通道绑定类型：端点
o Channel type: TLS [RFC5246]
o 信道类型：TLS[RFC5246]
o Published specification: <RFC 5929>
o 已发布规范：<RFC 5929>
o Channel binding is secret: no
o 通道绑定是秘密：否
o Description: <See specification>
o 说明：<参见规范>
o Intended usage: COMMON
o 预期用途：普通
o Person and email address to contact for further information: Larry Zhu (larry.zhu@microsoft.com), Nicolas Williams (Nicolas.Williams@oracle.com).
o 联系人和电子邮件地址以获取更多信息：Larry Zhu（Larry。zhu@microsoft.com)，Nicolas Williams（Nicolas。Williams@oracle.com).
o Owner/Change controller name and email address: IESG.
o 所有者/变更控制器名称和电子邮件地址：IESG。
o Expert reviewer name and contact information: IETF TLS WG (tls@ietf.org, failing that, ietf@ietf.org)
o 专家评审人姓名和联系方式：IETF TLS WG(tls@ietf.org，否则，ietf@ietf.org)
o Note: see the published specification for advice on the applicability of this channel binding type.
o 注：有关此通道绑定类型适用性的建议，请参阅已发布的规范。
IANA updated the registration of the 'tls-unique-for-telnet' channel binding type to match the description below. Note that the only material changes from the original registration are: the "owner" (now the IESG), the contacts, the published specification, and a note indicating that the published specification should be consulted for applicability advice. The description is also clarified. We also moved the security considerations notes to the security considerations section of this document. All other fields of the registration are copied here for the convenience of readers.
IANA更新了“tls unique for telnet”通道绑定类型的注册，以匹配以下描述。请注意，与原始注册相比，唯一的实质性变更是：“所有者”（现在的IESG）、联系人、发布的规范以及表明应参考发布的规范以获得适用性建议的注释。还澄清了描述。我们还将安全注意事项移至本文档的安全注意事项部分。为方便读者，此处复制了注册的所有其他字段。
Description: There is a proposal for adding a "StartTLS" extension to TELNET, and a channel binding extension for the various TELNET AUTH mechanisms whereby each side sends the other a "checksum" (MAC -- message authentication code) of their view of the channel's bindings. The client uses the TLS Finished messages (note: the Finished struct) sent by the client and server, each concatenated in that order and in their clear text form, of the first TLS handshake to which the connection is being bound. The server does the same but in the opposite concatenation order (server, then client).
描述：有人建议向TELNET添加一个“StartTLS”扩展，并为各种TELNET身份验证机制添加一个通道绑定扩展，其中每一方向另一方发送其通道绑定视图的“校验和”（MAC——消息身份验证码）。客户机使用由客户机和服务器发送的TLS完成消息（注意：完成的结构），每个消息都以明文形式按顺序连接到连接绑定到的第一次TLS握手。服务器执行相同的操作，但连接顺序相反（服务器，然后是客户端）。
o Channel binding unique prefix: tls-unique-for-telnet
o 通道绑定唯一前缀：telnet的tls唯一
o Channel binding type: unique
o 通道绑定类型：唯一
o Channel type: TLS [RFC5246]
o 信道类型：TLS[RFC5246]
o Published specification: <RFC 5929>
o 已发布规范：<RFC 5929>
o Channel binding is secret: no
o 通道绑定是秘密：否
o Description: <See specification>
o 说明：<参见规范>
o Intended usage: COMMON
o 预期用途：普通
o Person and email address to contact for further information: Jeff Altman (jaltman@secure-endpoints.com), Nicolas Williams (Nicolas.Williams@oracle.com).
o 联系人和电子邮件地址以获取更多信息：Jeff Altman(jaltman@secure-endpoints.com），Nicolas Williams（Nicolas。Williams@oracle.com).
o Owner/Change controller name and email address: IESG.
o 所有者/变更控制器名称和电子邮件地址：IESG。
o Expert reviewer name and contact information: IETF TLS WG (tls@ietf.org, failing that, ietf@ietf.org)
o 专家评审人姓名和联系方式：IETF TLS WG(tls@ietf.org，否则，ietf@ietf.org)
o Note: see the published specification for advice on the applicability of this channel binding type.
o 注：有关此通道绑定类型适用性的建议，请参阅已发布的规范。
The 'tls-unique-for-telnet' channel binding type is only applicable to TELNET [RFC0854] and is available for all TLS connections.
“tls unique for telnet”通道绑定类型仅适用于telnet[RFC0854]，可用于所有tls连接。
The 'tls-unique' channel binding type is available for all TLS connections, while 'tls-server-end-point' is only available when TLS cipher suites with server certificates are used, specifically: cipher
“tls unique”通道绑定类型可用于所有tls连接，而“tls server end point”仅在使用带有服务器证书的tls cipher套件时可用，特别是：cipher
suites that use the Certificate handshake message, which typically involve the use of PKIX [RFC5280]. For example, 'tls-server-end-point' is available when using TLS ciphers suites such as (this is not an exhaustive list):
使用证书握手消息的套件，通常涉及使用PKIX[RFC5280]。例如，“tls服务器端点”在使用tls密码套件时可用，例如（这不是一个详尽的列表）：
o TLS_DHE_DSS_WITH_*
o TLS_DHE_DSS_与_*
o TLS_DHE_RSA_WITH_*
o TLS_DHE_RSA_与_*
o TLS_DH_DSS_WITH_*
o TLS_DH_DSS__*
o TLS_DH_RSA_WITH_*
o TLS_DH_RSA_带_*
o TLS_ECDHE_ECDSA_WITH_*
o 带的TLS_ECDHE_ECDSA__*
o TLS_ECDHE_RSA_WITH_*
o TLS_ECDHE_RSA__*
o TLS_ECDH_ECDSA_WITH_*
o TLS_ECDH_ECDSA_带_*
o TLS_ECDH_RSA_WITH_*
o TLS_ECDH_RSA_带_*
o TLS_RSA_PSK_WITH_*
o TLS_RSA_PSK__*
o TLS_RSA_WITH_*
o TLS_RSA_带_*
o TLS_SRP_SHA_DSS_WITH_*
o TLS_SRP_SHA_DSS_与_*
o TLS_SRP_SHA_RSA_WITH_*
o TLS_SRP_SHA_RSA_与_*
but is not available when using TLS cipher suites such as (this is not an exhaustive list):
但在使用TLS密码套件时不可用，例如（这不是一个详尽的列表）：
o TLS_DHE_PSK_WITH_*
o 带_*
o TLS_DH_anon_WITH_*
o 带_*
o TLS_ECDHE_PSK_WITH_*
o 带_*
o TLS_ECDH_anon_WITH_*
o 在ECDH和anon之间_*
o TLS_KRB5_WITH_*
o TLS_KRB5_带_*
o TLS_PSK_WITH_*
o TLS_PSK_和_*
o TLS_SRP_SHA_WITH_*
o TLS_SRP_SHA_与_*
'tls-server-end-point' is also not applicable for use with OpenPGP server certificates [RFC5081] [RFC4880] (since these don't use the Certificate handshake message).
“tls服务器端点”也不适用于OpenPGP服务器证书[RFC5081][RFC4880]（因为这些证书不使用证书握手消息）。
Therefore, 'tls-unique' is applicable to more contexts than 'tls-server-end-point'. However, 'tls-server-end-point' may be used with existing TLS server-side proxies ("concentrators") without modification to the proxies, whereas 'tls-unique' may require firmware or software updates to server-side proxies. Therefore there may be cases where 'tls-server-end-point' may interoperate but where 'tls-unique' may not.
因此，“tls unique”适用于比“tls服务器端点”更多的上下文。但是，“tls服务器端点”可与现有tls服务器端代理（“集中器”）一起使用，而无需修改代理，而“tls unique”可能需要对服务器端代理进行固件或软件更新。因此，可能存在“tls服务器端点”可以互操作但“tls唯一”不能互操作的情况。
Also, authentication mechanisms may arise that depend on channel bindings to contribute entropy, in which case unique channel bindings would always have to be used in preference to end-point channel bindings. At this time there are no such mechanisms, though one such SASL mechanism has been proposed. Whether such mechanisms should be allowed is out of scope for this document.
此外，可能会出现依赖于通道绑定来贡献熵的身份验证机制，在这种情况下，必须始终优先使用唯一的通道绑定，而不是端点通道绑定。目前还没有这样的机制，尽管已经提出了这样一种SASL机制。是否应允许此类机制超出本文件的范围。
For many applications, there may be two or more potentially applicable TLS channel binding types. Existing security frameworks (such as the GSS-API [RFC2743] or the SASL [RFC4422] GS2 framework [RFC5801]) and security mechanisms generally do not support negotiation of channel binding types. Therefore, application peers need to agree a priori as to what channel binding type to use (or agree to rules for deciding what channel binding type to use).
对于许多应用程序，可能有两种或更多潜在适用的TLS通道绑定类型。现有的安全框架（如GSS-API[RFC2743]或SASL[RFC4422]GS2框架[RFC5801]）和安全机制通常不支持通道绑定类型的协商。因此，应用程序对等方需要就要使用的通道绑定类型事先达成一致（或者就决定要使用的通道绑定类型的规则达成一致）。
The specifics of whether and how to negotiate channel binding types are beyond the scope of this document. However, it is RECOMMENDED that application protocols making use of TLS channel bindings, use 'tls-unique' exclusively, except, perhaps, where server-side proxies are common in deployments of an application protocol. In the latter case an application protocol MAY specify that 'tls-server-end-point' channel bindings must be used when available, with 'tls-unique' being used when 'tls-server-end-point' channel bindings are not available. Alternatively, the application may negotiate which channel binding type to use, or may make the choice of channel binding type configurable.
是否和如何协商通道绑定类型的细节超出了本文档的范围。但是，建议使用TLS通道绑定的应用程序协议仅使用“TLS unique”，除非在应用程序协议的部署中服务器端代理很常见。在后一种情况下，应用程序协议可能指定在可用时必须使用“tls server end point”通道绑定，而在“tls server end point”通道绑定不可用时使用“tls unique”。或者，应用程序可以协商使用哪个通道绑定类型，或者可以使通道绑定类型的选择可配置。
Specifically, application protocol specifications MUST indicate at least one mandatory to implement channel binding type, MAY specify a negotiation protocol, MAY allow for out-of-band negotiation or configuration, and SHOULD have a preference for 'tls-unique' over 'tls-server-end-point'.
具体而言，应用程序协议规范必须指明至少一种强制实现通道绑定类型，可以指定协商协议，可以允许带外协商或配置，并且应该优先选择“tls唯一”而不是“tls服务器端点”。
TLS implementations supporting the use of 'tls-unique' and/or 'tls-unique-for-telnet' channel binding types MUST provide application programming interfaces by which applications (clients and servers both) may obtain the channel bindings for a TLS connection. Such interfaces may be expressed in terms of extracting the channel bindings data for a given connection and channel binding type. Alternatively, the implementor may provide interfaces by which to obtain the initial client Finished message, the initial server Finished message, and/or the server certificate (in a form that matches the description of the 'tls-server-end-point' channel binding type). In the latter case, the application has to have knowledge of the channel binding type descriptions from this document. This document takes no position on which form these application programming interfaces must take.
支持使用“TLS unique”和/或“TLS unique for telnet”通道绑定类型的TLS实现必须提供应用程序编程接口，通过这些接口，应用程序（客户端和服务器）可以获得TLS连接的通道绑定。这种接口可以表示为提取给定连接和通道绑定类型的通道绑定数据。或者，实现者可以提供接口，通过这些接口获取初始客户端完成消息、初始服务器完成消息和/或服务器证书（以与“tls服务器端点”通道绑定类型描述匹配的形式）。在后一种情况下，应用程序必须了解本文档中的通道绑定类型描述。本文档不确定这些应用程序编程接口必须采用何种形式。
TLS implementations supporting TLS renegotiation SHOULD provide APIs that allow applications to control when renegotiation can take place. For example, a TLS client implementation may provide a "callback" interface to indicate that the server requested renegotiation, but may not start renegotiation until the application calls a function to indicate that now is a good time to renegotiate.
支持TLS重新协商的TLS实现应提供允许应用程序控制何时可以进行重新协商的API。例如，TLS客户端实现可以提供一个“回调”接口来指示服务器请求重新协商，但在应用程序调用一个函数来指示现在是重新协商的好时机之前，可能不会开始重新协商。
8. Description of Backwards-Incompatible Changes Made Herein to 'tls-unique'
8. 此处对“tls unique”所做的向后不兼容更改的说明
The original description of 'tls-unique' read as follows:
“tls unique”的原始描述如下：
|OLD| Description: The client's TLS Finished message (note: the
|OLD| Finished struct) from the first handshake of the connection
|OLD| (note: connection, not session, so that the channel binding
|OLD| is specific to each connection regardless of whether session
|OLD| resumption is used).
|OLD| Description: The client's TLS Finished message (note: the
|OLD| Finished struct) from the first handshake of the connection
|OLD| (note: connection, not session, so that the channel binding
|OLD| is specific to each connection regardless of whether session
|OLD| resumption is used).
Original 'tls-unique' description
原始“tls唯一”说明
In other words: the client's Finished message from the first handshake of a connection, regardless of whether that handshake was a full or abbreviated handshake, and regardless of how many subsequent handshakes (renegotiations) might have followed.
换句话说：客户端完成的消息来自连接的第一次握手，不管该握手是完整握手还是缩写握手，也不管随后可能进行了多少次握手（重新协商）。
As explained in Section 1, this is no longer the description of 'tls-unique', and the new description is not backwards compatible with the original except in the case of TLS connections where: a) only one handshake has taken place before application-layer authentication, and b) that one handshake was a full handshake.
如第1节所述，这不再是“tls unique”的描述，并且新的描述与原始描述不向后兼容，但tls连接的情况除外：a）在应用层身份验证之前仅发生了一次握手，b）一次握手是完全握手。
This change has a number of implications:
这一变化有许多影响：
o Backwards-incompatibility. It is possible that some implementations of the original 'tls-unique' channel binding type have been deployed. We know of at least one TLS implementation that exports 'tls-unique' channel bindings with the original semantics, but we know of no deployed application using the same. Implementations of the original and new 'tls-unique' channel binding type will only interoperate when: a) full TLS handshakes are used, and b) TLS renegotiation is not used.
o 向后不兼容。可能已经部署了原始“tls unique”通道绑定类型的一些实现。我们知道至少有一个TLS实现使用原始语义导出“TLS unique”通道绑定，但我们知道没有部署使用相同语义的应用程序。原始和新的“tls唯一”通道绑定类型的实现只有在以下情况下才能进行互操作：a）使用完整的tls握手，b）不使用tls重新协商。
o Security considerations -- see Section 10.
o 安全注意事项——参见第10节。
o Interoperability considerations. As described in Section 3, the new definition of the 'tls-unique' channel binding type has an interoperability problem that may result in spurious authentication failures unless the application implements one or both of the techniques described in that section.
o 互操作性考虑。如第3节所述，“tls唯一”通道绑定类型的新定义存在互操作性问题，可能导致虚假身份验证失败，除非应用程序实现该节所述的一种或两种技术。
IANA updated three existing channel binding type registrations. See the rest of this document.
IANA更新了三个现有的通道绑定类型注册。请参阅本文档的其余部分。
The Security Considerations sections of [RFC5056], [RFC5246], and [RFC5746] apply to this document.
[RFC5056]、[RFC5246]和[RFC5746]中的安全注意事项部分适用于本文件。
The TLS Finished messages (see Section 7.4.9 of [RFC5246]) are known to both endpoints of a TLS connection and are cryptographically bound to it. For implementations of TLS that correctly handle renegotiation [RFC5746], each handshake on a TLS connection is bound to the preceding handshake, if any. Therefore, the TLS Finished messages can be safely used as a channel binding provided that the authentication mechanism doing the channel binding conforms to the requirements in [RFC5056]. Applications utilizing 'tls-unique' channel binding with TLS implementations without support for secure renegotiation [RFC5746] MUST ensure that ChangeCipherSpec has been used in any and all renegotiations prior to application-layer authentication, and MUST discard any knowledge learned from the server prior to the completion of application-layer authentication.
TLS完成的消息（见[RFC5246]第7.4.9节）为TLS连接的两个端点所知，并以加密方式绑定到它。对于正确处理重新协商的TLS实现[RFC5746]，TLS连接上的每次握手都绑定到前面的握手（如果有）。因此，只要进行通道绑定的认证机制符合[RFC5056]中的要求，TLS完成的消息可以安全地用作通道绑定。在不支持安全重新协商的情况下，利用tls实现的“tls unique”通道绑定的应用程序[RFC5746]必须确保在应用层身份验证之前的任何和所有重新协商中都使用了ChangeCipherSpec，并且必须在完成应用层身份验证之前放弃从服务器学到的任何知识。
The server certificate, when present, is also cryptographically bound to the TLS connection through its use in key transport and/or authentication of the server (either by dint of its use in key transport, by its use in signing key agreement, or by its use in key
服务器证书（如果存在）还通过在密钥传输和/或服务器身份验证中的使用（通过在密钥传输中的使用、在密钥协议签名中的使用或在密钥协议中的使用）以加密方式绑定到TLS连接
agreement). Therefore, the server certificate is suitable as an end-point channel binding as described in [RFC5056].
协议）。因此，服务器证书适合用作[RFC5056]中所述的端点通道绑定。
The 'tls-unique' and 'tls-unique-for-telnet' channel binding types do not add any use of cryptography beyond that used by TLS itself. Therefore, these two channel binding types add no considerations with respect to cryptographic algorithm agility.
“tls unique”和“tls unique for telnet”通道绑定类型在tls本身使用的加密技术之外不添加任何加密技术的使用。因此，这两种通道绑定类型不考虑密码算法的灵活性。
The 'tls-server-end-point' channel binding type consists of a hash of a server certificate. The reason for this is to produce manageably small channel binding data, as some implementations will be using kernel-mode memory (which is typically scarce) to store these. This use of a hash algorithm is above and beyond TLS's use of cryptography, therefore the 'tls-server-end-point' channel binding type has a security consideration with respect to hash algorithm agility. The algorithm to be used, however, is derived from the server certificate's signature algorithm as described in Section 4.1; to recap: use SHA-256 if the certificate signature algorithm uses MD5 or SHA-1, else use whatever hash function the certificate uses (unless the signature algorithm uses no hash functions or more than one hash function, in which case 'tls-server-end-point' is undefined). The construction of 'tls-server-end-point' channel bindings is not directly hash-agile (since no negotiation of hash function is provided for), but it is hash-agile nonetheless. The hash agility of 'tls-server-end-point' channel bindings derives from PKIX and TLS.
“tls服务器端点”通道绑定类型由服务器证书的哈希组成。这样做的原因是生成可管理的小通道绑定数据，因为一些实现将使用内核模式内存（通常很少）来存储这些数据。这种散列算法的使用超出了TLS对加密的使用，因此“TLS服务器端点”通道绑定类型在散列算法灵活性方面具有安全考虑。但是，要使用的算法是从第4.1节中描述的服务器证书的签名算法派生出来的；重述：如果证书签名算法使用MD5或SHA-1，则使用SHA-256，否则使用证书使用的任何哈希函数（除非签名算法不使用哈希函数或使用多个哈希函数，在这种情况下，“tls服务器端点”未定义）。“tls服务器端点”通道绑定的构造不是直接哈希敏捷的（因为没有提供哈希函数的协商），但是它是哈希敏捷的。“tls服务器端点”通道绑定的哈希灵活性源自PKIX和tls。
Current proposals for randomized signatures algorithms [RHASH] [NIST-SP.800-106.2009] use hash functions in their construction -- a single hash function in each algorithm. Therefore, the 'tls-server-end-point' channel binding type should be available even in cases where new signatures algorithms are used that are based on current randomized hashing proposals (but we cannot guarantee this, of course).
目前关于随机签名算法的建议[RHASH][NIST-SP.800-106.2009]在其构造中使用哈希函数——每个算法中使用一个哈希函数。因此，“tls服务器端点”通道绑定类型即使在使用基于当前随机哈希建议的新签名算法的情况下也应该可用（当然，我们不能保证这一点）。
10.2. On Disclosure of Channel Bindings Data by Authentication Mechanisms
10.2. 通过身份验证机制公开通道绑定数据
When these channel binding types were first considered, one issue that some commenters were concerned about was the possible impact on the security of the TLS channel, of disclosure of the channel bindings data by authentication mechanisms. This can happen, for example, when an authentication mechanism transports the channel bindings data, with no confidentiality protection, over other transports (for example, in communicating with a trusted third party), or when the TLS channel provides no confidentiality
当首次考虑这些通道绑定类型时，一些评论者担心的一个问题是认证机制披露通道绑定数据可能对TLS通道的安全性产生的影响。例如，当身份验证机制通过其他传输（例如，在与受信任的第三方通信时）在没有保密保护的情况下传输通道绑定数据时，或者当TLS通道不提供保密性时，可能会发生这种情况
protection and the authentication mechanism does not protect the confidentiality of the channel bindings data. This section considers that concern.
保护和身份验证机制不保护通道绑定数据的机密性。本节考虑这一关切。
When the TLS connection uses a cipher suite that does not provide confidentiality protection, the TLS Finished messages will be visible to eavesdroppers, regardless of what the authentication mechanism does. The same is true of the server certificate which, in any case, is generally visible to eavesdroppers. Therefore we must consider our choices of TLS channel bindings here to be safe to disclose by definition -- if that were not the case, then TLS with cipher suites that don't provide confidentiality protection would be unsafe. Furthermore, the TLS Finished message construction depends on the security of the TLS PRF, which in turn needs to be resistant to key recovery attacks, and we think that it is, as it is based on HMAC, and the master secret is, well, secret (and the result of key exchange).
当TLS连接使用不提供机密性保护的密码套件时，无论身份验证机制做什么，窃听者都可以看到TLS完成的消息。服务器证书也是如此，在任何情况下，窃听者通常都可以看到服务器证书。因此，我们必须考虑到TLS信道绑定的选择在这里是安全的，如果不是这样的话，那么不提供保密保护的加密套件的TLS将是不安全的。此外，TLS完成的消息构造取决于TLS PRF的安全性，而TLS PRF又需要抵抗密钥恢复攻击，我们认为它是基于HMAC的，并且主密钥是机密的（以及密钥交换的结果）。
Note too that in the case of an attempted active man-in-the-middle attack, the attacker will already possess knowledge of the TLS Finished messages for both inbound and outbound TLS channels (which will differ, given that the attacker cannot force them to be the same). No additional information is obtained by the attacker from the authentication mechanism's disclosure of channel bindings data -- the attacker already has it, even when cipher suites providing confidentiality protection are provided.
还要注意的是，在尝试中间人主动攻击的情况下，攻击者将已经知道入站和出站TLS通道的TLS完成消息（这将有所不同，因为攻击者无法强制它们相同）。攻击者不会从身份验证机制披露的通道绑定数据中获得任何其他信息——即使提供了提供机密性保护的密码套件，攻击者也已经获得了这些信息。
None of the channel binding types defined herein produce channel bindings data that must be kept secret. Moreover, none of the channel binding types defined herein can be expected to be private (known only to the end-points of the channel), except that the unique TLS channel binding types can be expected to be private when a cipher suite that provides confidentiality protection is used to protect the Finished message exchanges and the application data records containing application-layer authentication messages.
此处定义的任何通道绑定类型都不会生成必须保密的通道绑定数据。此外，本文定义的信道绑定类型中没有一个是私有的（仅信道端点知道），但是，当使用提供机密性保护的密码套件来保护完成的消息交换和包含应用层身份验证消息的应用程序数据记录时，唯一的TLS通道绑定类型可能是私有的。
[FIPS-180-3] United States of America, National Institute of Standards and Technology, "Secure Hash Standard", Federal Information Processing Standard (FIPS) 180-3, October 2008.
[FIPS-180-3]美利坚合众国国家标准和技术研究所，“安全哈希标准”，联邦信息处理标准（FIPS）180-3，2008年10月。
[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月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，2007年11月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010.
[RFC5746]Rescorla，E.，Ray，M.，Dispensa，S.，和N.Oskov，“传输层安全（TLS）重新协商指示扩展”，RFC 57462010年2月。
[NIST-SP.800-106.2009] National Institute of Standards and Technology, "NIST Special Publication 800- 106: Randomized Hashing for Digital Signatures", February 2009.
[NIST-SP.800-106.2009]国家标准与技术研究所，“NIST特别出版物800-106：数字签名的随机哈希”，2009年2月。
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC0854]Postel，J.和J.Reynolds，“Telnet协议规范”，STD 8，RFC 854，1983年5月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[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月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]Eastlake，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，2001年9月。
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]Melnikov，A.，Ed.，和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 48802007年11月。
[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 5081, November 2007.
[RFC5081]Mavrogiannopoulos，N.，“使用OpenPGP密钥进行传输层安全（TLS）认证”，RFC 5081，2007年11月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", RFC 5801, July 2010.
[RFC5801]Josefsson，S.和N.Williams，“在简单身份验证和安全层（SASL）中使用通用安全服务应用程序接口（GSS-API）机制：GS2机制系列”，RFC 58012010年7月。
[RHASH] Halevi, S. and H. Krawczyk, "Strengthening Digital Signatures via Randomized Hashing", Work in Progress, October 2007.
[RHASH]Halevi，S.和H.Krawczyk，“通过随机散列加强数字签名”，正在进行的工作，2007年10月。
Authors' Addresses
作者地址
Jeff Altman Secure Endpoints 255 W 94TH ST PHB New York, NY 10025 US
Jeff Altman安全端点255 W美国纽约州纽约市第94街PHB邮编10025
EMail: jaltman@secure-endpoints.com
EMail: jaltman@secure-endpoints.com
Nicolas Williams Oracle 5300 Riata Trace Ct Austin, TX 78727 US
Nicolas Williams Oracle 5300 Riata Trace Ct德克萨斯州奥斯汀78727美国
EMail: Nicolas.Williams@oracle.com
EMail: Nicolas.Williams@oracle.com
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Larry Zhu微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: larry.zhu@microsoft.com
EMail: larry.zhu@microsoft.com