Internet Engineering Task Force (IETF) A. Popov, Ed.
Request for Comments: 8471 M. Nystroem
Category: Standards Track Microsoft Corp.
ISSN: 2070-1721 D. Balfanz
Google Inc.
J. Hodges
Kings Mountain Systems
October 2018
Internet Engineering Task Force (IETF) A. Popov, Ed.
Request for Comments: 8471 M. Nystroem
Category: Standards Track Microsoft Corp.
ISSN: 2070-1721 D. Balfanz
Google Inc.
J. Hodges
Kings Mountain Systems
October 2018
The Token Binding Protocol Version 1.0
令牌绑定协议版本1.0
Abstract
摘要
This document specifies version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time.
本文档指定令牌绑定协议的版本1.0。令牌绑定协议允许客户端/服务器应用程序创建跨越多个TLS会话和连接的长期、唯一可识别的TLS绑定。然后，应用程序能够以加密方式将安全令牌绑定到TLS层，从而防止令牌导出和重放攻击。为了保护隐私，令牌绑定标识符仅通过TLS传输，用户可随时重置。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8471.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8471.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Token Binding Protocol Overview . . . . . . . . . . . . . . . 4
3. Token Binding Protocol Message . . . . . . . . . . . . . . . 5
3.1. TokenBinding.tokenbinding_type . . . . . . . . . . . . . 6
3.2. TokenBinding.tokenbindingid . . . . . . . . . . . . . . . 7
3.3. TokenBinding.signature . . . . . . . . . . . . . . . . . 7
3.4. TokenBinding.extensions . . . . . . . . . . . . . . . . . 9
4. Establishing a Token Binding . . . . . . . . . . . . . . . . 9
4.1. Client Processing Rules . . . . . . . . . . . . . . . . . 9
4.2. Server Processing Rules . . . . . . . . . . . . . . . . . 10
5. Bound Security Token Creation and Validation . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Token Binding Key Parameters Registry . . . . . . . . . . 11
6.2. Token Binding Types Registry . . . . . . . . . . . . . . 12
6.3. Token Binding Extensions Registry . . . . . . . . . . . . 13
6.4. Registration of Token Binding TLS Exporter Label . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Security Token Replay . . . . . . . . . . . . . . . . . . 14
7.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 14
7.3. Token Binding Key-Sharing between Applications . . . . . 14
7.4. Triple Handshake Vulnerability in TLS 1.2 and Older TLS
Versions . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Token Binding Protocol Overview . . . . . . . . . . . . . . . 4
3. Token Binding Protocol Message . . . . . . . . . . . . . . . 5
3.1. TokenBinding.tokenbinding_type . . . . . . . . . . . . . 6
3.2. TokenBinding.tokenbindingid . . . . . . . . . . . . . . . 7
3.3. TokenBinding.signature . . . . . . . . . . . . . . . . . 7
3.4. TokenBinding.extensions . . . . . . . . . . . . . . . . . 9
4. Establishing a Token Binding . . . . . . . . . . . . . . . . 9
4.1. Client Processing Rules . . . . . . . . . . . . . . . . . 9
4.2. Server Processing Rules . . . . . . . . . . . . . . . . . 10
5. Bound Security Token Creation and Validation . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Token Binding Key Parameters Registry . . . . . . . . . . 11
6.2. Token Binding Types Registry . . . . . . . . . . . . . . 12
6.3. Token Binding Extensions Registry . . . . . . . . . . . . 13
6.4. Registration of Token Binding TLS Exporter Label . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Security Token Replay . . . . . . . . . . . . . . . . . . 14
7.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 14
7.3. Token Binding Key-Sharing between Applications . . . . . 14
7.4. Triple Handshake Vulnerability in TLS 1.2 and Older TLS
Versions . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Servers often generate various security tokens (e.g., HTTP cookies, OAuth tokens [RFC6749]) for applications to present when accessing protected resources. In general, any party in possession of bearer security tokens gains access to certain protected resource(s). Attackers take advantage of this by exporting bearer tokens from a user's application connections or machines, presenting them to application servers, and impersonating authenticated users. The idea of Token Binding is to prevent such attacks by cryptographically binding application security tokens to the underlying TLS layer [RFC5246]. (Note: This document deals with TLS 1.2 and therefore refers to RFC 5246 (which has been obsoleted by RFC 8446); [TOKENBIND-TLS13] addresses Token Binding in TLS 1.3.)
服务器通常会生成各种安全令牌（例如HTTP cookies、OAuth令牌[RFC6749]），供应用程序在访问受保护资源时显示。通常，拥有无记名安全令牌的任何一方都可以访问某些受保护的资源。攻击者通过从用户的应用程序连接或计算机导出承载令牌、将其呈现给应用程序服务器以及模拟经过身份验证的用户来利用此漏洞。令牌绑定的思想是通过加密方式将应用程序安全令牌绑定到底层TLS层来防止此类攻击[RFC5246]。（注：本文件涉及TLS 1.2，因此参考RFC 5246（已被RFC 8446淘汰）；[TOKENBIND-TLS13]解决了TLS 1.3中的令牌绑定。）
A Token Binding is established by a User Agent generating a private-public key pair (possibly within a secure hardware module, such as a Trusted Platform Module) per target server, providing the public key to the server, and proving possession of the corresponding private key, on every TLS connection to the server. The proof of possession involves signing the Exported Keying Material (EKM) [RFC5705] from the TLS connection with the private key. The corresponding public key is included in the Token Binding identifier structure (described in Section 3.2 ("TokenBinding.tokenbindingid")). Token Bindings are long-lived, i.e., they encompass multiple TLS connections and TLS sessions between a given client and server. To protect privacy, Token Binding IDs are never conveyed over insecure connections and can be reset by the user at any time, e.g., when clearing browser cookies.
令牌绑定由用户代理建立，该用户代理为每个目标服务器生成私钥对（可能在安全硬件模块内，如可信平台模块内），向服务器提供公钥，并在与服务器的每个TLS连接上证明拥有相应的私钥。占有证明涉及使用私钥签署TLS连接导出的密钥材料（EKM）[RFC5705]。相应的公钥包含在令牌绑定标识符结构中（如第3.2节（“TokenBinding.tokenbindingid”）所述）。令牌绑定是长期存在的，即它们包含给定客户端和服务器之间的多个TLS连接和TLS会话。为了保护隐私，令牌绑定ID永远不会通过不安全的连接传输，用户可以在任何时候（例如，在清除浏览器cookie时）重置。
When issuing a security token to a client that supports Token Binding, a server includes the client's Token Binding ID (or its cryptographic hash) in the token. Later on, when a client presents a security token containing a Token Binding ID, the server verifies that the ID in the token matches the ID of the Token Binding established with the client. In the case of a mismatch, the server rejects the token (details are application specific).
向支持令牌绑定的客户端发出安全令牌时，服务器会在令牌中包含客户端的令牌绑定ID（或其加密哈希）。稍后，当客户端提供包含令牌绑定ID的安全令牌时，服务器将验证令牌中的ID是否与与客户端建立的令牌绑定ID匹配。在不匹配的情况下，服务器拒绝令牌（详细信息是特定于应用程序的）。
In order to successfully export and replay a bound security token, an attacker needs to also be able to use the client's private key; this is hard to do if the key is specially protected, e.g., generated in a secure hardware module.
为了成功导出和重放绑定的安全令牌，攻击者还需要能够使用客户端的私钥；如果密钥受到特殊保护（例如，在安全硬件模块中生成），则很难做到这一点。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
In the course of a TLS handshake, a client and server can use the Token Binding negotiation TLS extension [RFC8472] to negotiate the Token Binding protocol version and the parameters (signature algorithm, length) of the Token Binding key. This negotiation does not require additional round trips.
在TLS握手过程中，客户端和服务器可以使用令牌绑定协商TLS扩展[RFC8472]协商令牌绑定协议版本和令牌绑定密钥的参数（签名算法、长度）。此谈判不需要额外的往返行程。
Version 1.0 of the Token Binding protocol is represented by TB_ProtocolVersion.major = 1 and TB_ProtocolVersion.minor = 0 in the Token Binding negotiation TLS extension; see [RFC8472] ("Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation").
令牌绑定协议的1.0版本由令牌绑定协商TLS扩展中的TB_ProtocolVersion.major=1和TB_ProtocolVersion.minor=0表示；请参阅[RFC8472]（“令牌绑定协议协商的传输层安全性（TLS）扩展”）。
The Token Binding protocol consists of one message sent by the client to the server, proving possession of one or more client-generated asymmetric private keys. This message is not sent if the Token Binding negotiation has been unsuccessful. The Token Binding message is sent with the application protocol data over TLS.
令牌绑定协议由客户端发送到服务器的一条消息组成，证明拥有一个或多个客户端生成的非对称私钥。如果令牌绑定协商失败，则不会发送此消息。令牌绑定消息通过TLS与应用程序协议数据一起发送。
A server receiving the Token Binding message verifies that the key parameters in the message match the Token Binding parameters negotiated (e.g., via [RFC8472]) and then validates the signatures contained in the Token Binding message. If either of these checks fails, the server rejects the binding, along with all associated bound tokens. Otherwise, the Token Binding is successfully established with the ID contained in the Token Binding message.
接收令牌绑定消息的服务器验证消息中的关键参数是否与协商的令牌绑定参数匹配（例如，通过[RFC8472]），然后验证令牌绑定消息中包含的签名。如果这些检查中的任何一个失败，服务器将拒绝绑定以及所有关联的绑定令牌。否则，将使用令牌绑定消息中包含的ID成功建立令牌绑定。
When a server supporting the Token Binding protocol receives a bound token, the server compares the Token Binding ID in the token with the Token Binding ID established with the client. If the bound token is received on a TLS connection without a Token Binding or if the Token Binding IDs do not match, the token is rejected.
当支持令牌绑定协议的服务器接收到绑定令牌时，服务器会将令牌中的令牌绑定ID与客户端建立的令牌绑定ID进行比较。如果在没有令牌绑定的TLS连接上接收绑定令牌，或者如果令牌绑定ID不匹配，则拒绝该令牌。
This document defines the format of the Token Binding protocol message, the process of establishing a Token Binding, the format of the Token Binding ID, and the process of validating a bound token. [RFC8472] describes the negotiation of the Token Binding protocol and key parameters. [RFC8473] ("Token Binding over HTTP") explains how the Token Binding message is encapsulated within HTTP/1.1 messages
本文档定义了令牌绑定协议消息的格式、建立令牌绑定的过程、令牌绑定ID的格式以及验证绑定令牌的过程。[RFC8472]描述令牌绑定协议和关键参数的协商。[RFC8473]（“HTTP上的令牌绑定”）解释了令牌绑定消息如何封装在HTTP/1.1消息中
[RFC7230] or HTTP/2 messages [RFC7540]. [RFC8473] also describes Token Binding between multiple communicating parties: User Agent, Identity Provider, and Relying Party.
[RFC7230]或HTTP/2消息[RFC7540]。[RFC8473]还描述了多个通信方之间的令牌绑定：用户代理、身份提供者和依赖方。
The Token Binding message is sent by the client to prove possession of one or more private keys held by the client. This message MUST be sent if the client and server successfully negotiated the use of the Token Binding protocol (e.g., via [RFC8472] or a different mechanism) and MUST NOT be sent otherwise. This message MUST be sent in the client's first application protocol message. This message MAY also be sent in subsequent application protocol messages, proving possession of additional private keys held by the same client; this information can be used to facilitate Token Binding between more than two communicating parties. For example, [RFC8473] specifies an encapsulation of the Token Binding message in HTTP application protocol messages, as well as scenarios involving more than two communicating parties.
令牌绑定消息由客户端发送，以证明拥有客户端持有的一个或多个私钥。如果客户端和服务器成功协商使用令牌绑定协议（例如，通过[RFC8472]或其他机制），则必须发送此消息，否则不得发送此消息。此消息必须在客户端的第一条应用程序协议消息中发送。该消息也可以在随后的应用协议消息中发送，以证明拥有由同一客户端持有的额外私钥；此信息可用于促进两个以上通信方之间的令牌绑定。例如，[RFC8473]指定HTTP应用程序协议消息中令牌绑定消息的封装，以及涉及两个以上通信方的场景。
The Token Binding message format is defined using the TLS presentation language (see Section 4 of [RFC5246]):
令牌绑定消息格式使用TLS表示语言定义（见[RFC5246]第4节）：
enum {
rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255)
} TokenBindingKeyParameters;
enum {
rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2), (255)
} TokenBindingKeyParameters;
struct {
opaque modulus<1..2^16-1>;
opaque publicexponent<1..2^8-1>;
} RSAPublicKey;
struct {
opaque modulus<1..2^16-1>;
opaque publicexponent<1..2^8-1>;
} RSAPublicKey;
struct {
opaque point <1..2^8-1>;
} TB_ECPoint;
struct {
opaque point <1..2^8-1>;
} TB_ECPoint;
struct {
TokenBindingKeyParameters key_parameters;
uint16 key_length; /* Length (in bytes) of the following
TokenBindingID.TokenBindingPublicKey */
select (key_parameters) {
case rsa2048_pkcs1.5:
case rsa2048_pss:
RSAPublicKey rsapubkey;
case ecdsap256:
TB_ECPoint point;
} TokenBindingPublicKey;
} TokenBindingID;
struct {
TokenBindingKeyParameters key_parameters;
uint16 key_length; /* Length (in bytes) of the following
TokenBindingID.TokenBindingPublicKey */
select (key_parameters) {
case rsa2048_pkcs1.5:
case rsa2048_pss:
RSAPublicKey rsapubkey;
case ecdsap256:
TB_ECPoint point;
} TokenBindingPublicKey;
} TokenBindingID;
enum {
(255) /* No initial TB_ExtensionType registrations */
} TB_ExtensionType;
enum {
(255) /* No initial TB_ExtensionType registrations */
} TB_ExtensionType;
struct {
TB_ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} TB_Extension;
struct {
TB_ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} TB_Extension;
enum {
provided_token_binding(0), referred_token_binding(1), (255)
} TokenBindingType;
enum {
provided_token_binding(0), referred_token_binding(1), (255)
} TokenBindingType;
struct {
TokenBindingType tokenbinding_type;
TokenBindingID tokenbindingid;
opaque signature<64..2^16-1>; /* Signature over the concatenation
of tokenbinding_type,
key_parameters, and EKM */
TB_Extension extensions<0..2^16-1>;
} TokenBinding;
struct {
TokenBindingType tokenbinding_type;
TokenBindingID tokenbindingid;
opaque signature<64..2^16-1>; /* Signature over the concatenation
of tokenbinding_type,
key_parameters, and EKM */
TB_Extension extensions<0..2^16-1>;
} TokenBinding;
struct {
TokenBinding tokenbindings<132..2^16-1>;
} TokenBindingMessage;
struct {
TokenBinding tokenbindings<132..2^16-1>;
} TokenBindingMessage;
The Token Binding message consists of a series of TokenBinding structures, each containing the type of the Token Binding, the TokenBindingID, and a signature using the Token Binding key, optionally followed by TB_Extension structures.
令牌绑定消息由一系列令牌绑定结构组成，每个结构包含令牌绑定的类型、令牌绑定ID和使用令牌绑定密钥的签名（可选地后跟TB_扩展结构）。
This document defines two Token Binding types:
本文档定义了两种令牌绑定类型：
o provided_token_binding - used to establish a Token Binding when connecting to a server.
o 提供的令牌绑定-用于在连接到服务器时建立令牌绑定。
o referred_token_binding - used when requesting tokens that are intended to be presented to a different server.
o referenced_token_binding-在请求要呈现给不同服务器的令牌时使用。
[RFC8473] describes a use case for referred_token_binding where Token Bindings are established between multiple communicating parties: User Agent, Identity Provider, and Relying Party. The User Agent sends referred_token_binding to the Identity Provider in order to prove possession of the Token Binding key it uses with the Relying
[RFC8473]描述了引用的令牌绑定的用例，其中令牌绑定在多个通信方（用户代理、身份提供者和依赖方）之间建立。用户代理向身份提供者发送引用的令牌绑定，以证明其拥有与依赖方一起使用的令牌绑定密钥
Party. The Identity Provider can then bind the token it is supplying (for presentation to the Relying Party) to the Token Binding ID contained in referred_token_binding.
政党然后，身份提供者可以将其提供的令牌（用于呈现给依赖方）绑定到引用的令牌绑定中包含的令牌绑定ID。
An implementation MUST ignore any unknown Token Binding types.
实现必须忽略任何未知的令牌绑定类型。
The ID of the Token Binding established as a result of Token Binding message processing contains the identifier of the negotiated key parameters, the length (in bytes) of the Token Binding public key, and the Token Binding public key itself. The Token Binding ID can be obtained from the TokenBinding structure by discarding the Token Binding type, signature, and extensions.
作为令牌绑定消息处理的结果而建立的令牌绑定的ID包含协商密钥参数的标识符、令牌绑定公钥的长度（以字节为单位）以及令牌绑定公钥本身。通过丢弃令牌绑定类型、签名和扩展，可以从令牌绑定结构获得令牌绑定ID。
When rsa2048_pkcs1.5 or rsa2048_pss is used, RSAPublicKey.modulus and RSAPublicKey.publicexponent contain the modulus and exponent of a 2048-bit RSA public key represented in big-endian format, with leading zero bytes omitted.
使用rsa2048_pkcs1.5或rsa2048_pss时，RSAPublicKey.module和RSAPublicKey.publicexponent包含以大端格式表示的2048位RSA公钥的模和指数，前导零字节省略。
When ecdsap256 is used, TB_ECPoint.point contains the X coordinate followed by the Y coordinate of a Curve P-256 key. The X and Y coordinates are unsigned 32-byte integers encoded in big-endian format, preserving any leading zero bytes. Future specifications may define Token Binding keys using other elliptic curves with their corresponding signature and point formats.
使用ecdsap256时，TB_ECPoint.point包含曲线P-256关键点的X坐标和Y坐标。X和Y坐标是以big-endian格式编码的无符号32字节整数，保留任何前导零字节。未来的规范可能会使用其他椭圆曲线及其相应的签名和点格式来定义令牌绑定密钥。
Token Binding protocol implementations SHOULD make Token Binding IDs available to the application as opaque byte sequences, so that applications do not rely on a particular Token Binding ID structure. For example, server applications will use Token Binding IDs when generating and verifying bound tokens.
令牌绑定协议实现应使令牌绑定ID作为不透明字节序列提供给应用程序，以便应用程序不依赖于特定的令牌绑定ID结构。例如，服务器应用程序在生成和验证绑定令牌时将使用令牌绑定ID。
When rsa2048_pkcs1.5 is used, TokenBinding.signature contains the signature generated using the RSASSA-PKCS1-v1_5 signature scheme defined in [RFC8017] with SHA256 [FIPS.180-4.2015] as the hash function.
使用rsa2048_pkcs1.5时，TokenBinding.signature包含使用[RFC8017]中定义的RSASSA-pkcs1-v1_5签名方案生成的签名，其中SHA256[FIPS.180-4.2015]作为哈希函数。
When rsa2048_pss is used, TokenBinding.signature contains the signature generated using the RSA Probabilistic Signature Scheme (RSASSA-PSS) defined in [RFC8017] with SHA256 as the hash function. MGF1 with SHA256 MUST be used as the mask generation function (MGF), and the salt length MUST equal 32 bytes.
使用rsa2048_pss时，TokenBinding.signature包含使用[RFC8017]中定义的RSA概率签名方案（RSASSA-pss）生成的签名，其中SHA256作为哈希函数。带有SHA256的MGF1必须用作掩码生成函数（MGF），salt长度必须等于32字节。
When ecdsap256 is used, TokenBinding.signature contains a pair of 32-byte integers, R followed by S, generated with the Elliptic Curve
使用ecdsap256时，TokenBinding.signature包含一对由椭圆曲线生成的32字节整数，R后跟S
Digital Signature Algorithm (ECDSA) using Curve P-256 and SHA256 as defined in [FIPS.186-4.2013] and [ANSI.X9-62.2005]. R and S are encoded in big-endian format, preserving any leading zero bytes.
使用[FIPS.186-4.2013]和[ANSI.X9-62.2005]中定义的曲线P-256和SHA256的数字签名算法（ECDSA）。R和S以big-endian格式编码，保留任何前导零字节。
The signature is computed over the byte string representing the concatenation of:
签名是在表示以下连接的字节字符串上计算的：
o The TokenBindingType value contained in the TokenBinding.tokenbinding_type field,
o TokenBinding.TokenBinding_type字段中包含的TokenBindingType值，
o The TokenBindingKeyParameters value contained in the TokenBindingID.key_parameters field, and
o TokenBindingID.key_参数字段中包含的TokenBindingKeyParameters值，以及
o The EKM value obtained from the current TLS connection.
o 从当前TLS连接获得的EKM值。
Please note that TLS 1.2 and earlier versions support renegotiation, which produces a new TLS master secret for the same connection, with the associated session keys and EKM value. TokenBinding.signature MUST be a signature of the EKM value derived from the TLS master secret that produced the session keys encrypting the TLS application_data record(s) containing this TokenBinding. Such use of the current EKM for the TLS connection makes replay of bound tokens within renegotiated TLS sessions detectable but requires the application to synchronize Token Binding message generation and verification with the TLS handshake state.
请注意，TLS 1.2和早期版本支持重新协商，这将为同一连接生成一个新的TLS主密钥，以及相关的会话密钥和EKM值。TokenBinding.signature必须是从TLS主密钥派生的EKM值的签名，该主密钥生成对包含此TokenBinding的TLS应用程序_数据记录进行加密的会话密钥。对TLS连接使用当前EKM使得在重新协商的TLS会话中可以检测到绑定令牌的重播，但是需要应用程序将令牌绑定消息的生成和验证与TLS握手状态同步。
Specifications defining the use of Token Binding with application protocols, such as Token Binding over HTTP [RFC8473], MAY prohibit the use of TLS renegotiation in combination with Token Binding, obviating the need for such synchronization. Alternatively, such specifications need to define (1) a way to determine which EKM value corresponds to a given TokenBindingMessage and (2) a mechanism that prevents a TokenBindingMessage from being split across TLS renegotiation boundaries due to TLS message fragmentation; see Section 6.2.1 of [RFC5246]. Note that application-layer messages conveying a TokenBindingMessage may cross renegotiation boundaries in ways that make processing difficult.
定义令牌绑定与应用程序协议的使用的规范，例如HTTP上的令牌绑定[RFC8473]，可能会禁止将TLS重新协商与令牌绑定结合使用，从而避免此类同步的需要。或者，此类规范需要定义（1）确定哪个EKM值对应于给定TokenBindingMessage的方法，以及（2）防止TokenBindingMessage由于TLS消息碎片而跨TLS重新协商边界拆分的机制；见[RFC5246]第6.2.1节。请注意，传递TokenBindingMessage的应用层消息可能会以使处理变得困难的方式跨越重新协商边界。
The EKM is obtained using the keying material exporters for TLS as defined in [RFC5705], by supplying the following input values:
通过提供以下输入值，使用[RFC5705]中定义的TLS键控材料导出器获得EKM：
o Label: The ASCII string "EXPORTER-Token-Binding" with no terminating NUL.
o 标签：ASCII字符串“EXPORTER Token Binding”，不带终止NUL。
o Context value: No application context supplied.
o 上下文值：未提供应用程序上下文。
o Length: 32 bytes.
o 长度：32字节。
A Token Binding message may optionally contain a series of TB_Extension structures, each consisting of an extension_type and extension_data. The structure and meaning of extension_data depends on the specific extension_type.
令牌绑定消息可以选择性地包含一系列TB_扩展结构，每个结构由扩展_类型和扩展_数据组成。扩展_数据的结构和含义取决于特定的扩展_类型。
Initially, no extension types are defined (see Section 6.3 ("Token Binding Extensions Registry")). One of the possible uses of extensions envisioned at the time of this writing is attestation: cryptographic proof that allows the server to verify that the Token Binding key is hardware bound. The definitions of such Token Binding protocol extensions are outside the scope of this specification.
最初，没有定义扩展类型（请参阅第6.3节（“令牌绑定扩展注册表”））。在撰写本文时所设想的扩展的一个可能用途是认证：密码证明，它允许服务器验证令牌绑定密钥是硬件绑定的。此类令牌绑定协议扩展的定义不在本规范的范围内。
The client MUST include at least one TokenBinding structure in the Token Binding message. When a provided_token_binding is included, the key parameters used in a provided_token_binding MUST match those negotiated with the server (e.g., via [RFC8472] or a different mechanism).
客户端必须在令牌绑定消息中至少包含一个令牌绑定结构。当包含所提供的_令牌_绑定时，所提供的_令牌_绑定中使用的关键参数必须与服务器协商的参数匹配（例如，通过[RFC8472]或其他机制）。
The client MUST generate and store Token Binding keys in a secure manner that prevents key export. In order to prevent cooperating servers from linking user identities, the scope of the Token Binding keys MUST NOT be broader than the scope of the tokens, as defined by the application protocol.
客户端必须以防止密钥导出的安全方式生成和存储令牌绑定密钥。为了防止协作服务器链接用户标识，令牌绑定密钥的范围不得超过应用程序协议定义的令牌范围。
When the client needs to send a referred_token_binding to the Identity Provider, the client SHALL construct the referred TokenBinding structure in the following manner:
当客户端需要向身份提供者发送引用的令牌绑定时，客户端应按照以下方式构造引用的令牌绑定结构：
o Set TokenBinding.tokenbinding_type to referred_token_binding.
o 将TokenBinding.TokenBinding_类型设置为referenced_token_binding。
o Set TokenBinding.tokenbindingid to the Token Binding ID used with the Relying Party.
o 将TokenBinding.tokenbindingid设置为依赖方使用的令牌绑定ID。
o Generate TokenBinding.signature, using the EKM value of the TLS connection to the Identity Provider, the Token Binding key established with the Relying Party, and the signature algorithm indicated by the associated key parameters. Note that these key parameters may differ from the key parameters negotiated with the Identity Provider.
o 使用到身份提供者的TLS连接的EKM值、与依赖方建立的令牌绑定密钥以及相关密钥参数指示的签名算法生成TokenBinding.signature。请注意，这些关键参数可能不同于与身份提供者协商的关键参数。
Conveying referred Token Bindings in this fashion allows the Identity Provider to verify that the client controls the Token Binding key used with the Relying Party.
以这种方式传递引用的令牌绑定允许身份提供者验证客户端是否控制与依赖方一起使用的令牌绑定密钥。
The triple handshake vulnerability in TLS 1.2 and older TLS versions affects the security of the Token Binding protocol, as described in Section 7 ("Security Considerations"). Therefore, the server MUST NOT negotiate the use of the Token Binding protocol with these TLS versions, unless the server also negotiates the extended master secret TLS extension [RFC7627] and the renegotiation indication TLS extension [RFC5746].
TLS 1.2和旧版本TLS中的三重握手漏洞会影响令牌绑定协议的安全性，如第7节（“安全注意事项”）所述。因此，服务器不得与这些TLS版本协商令牌绑定协议的使用，除非服务器还协商扩展主密钥TLS扩展[RFC7627]和重新协商指示TLS扩展[RFC5746]。
If the use of the Token Binding protocol was not negotiated but the client sends a Token Binding message, the server MUST reject any contained bindings.
如果未协商令牌绑定协议的使用，但客户端发送令牌绑定消息，则服务器必须拒绝任何包含的绑定。
If the Token Binding type is "provided_token_binding", the server MUST verify that the signature algorithm (including an elliptic curve in the case of ECDSA) and key length in the Token Binding message match those negotiated with this client (e.g., via [RFC8472] or a different mechanism). In the case of a mismatch, the server MUST reject the binding. Token Bindings of type "referred_token_binding" may use different key parameters than those negotiated with this client.
如果令牌绑定类型为“提供的令牌绑定”，则服务器必须验证令牌绑定消息中的签名算法（在ECDSA的情况下包括椭圆曲线）和密钥长度是否与与此客户端协商的签名算法和密钥长度相匹配（例如，通过[RFC8472]或其他机制）。如果不匹配，服务器必须拒绝绑定。类型为“referred_Token_binding”的令牌绑定可能使用与此客户端协商的密钥参数不同的密钥参数。
If the Token Binding message does not contain at least one TokenBinding structure or if a signature contained in any TokenBinding structure is invalid, the server MUST reject the binding.
如果令牌绑定消息不包含至少一个令牌绑定结构，或者如果任何令牌绑定结构中包含的签名无效，则服务器必须拒绝绑定。
Servers MUST ignore any unknown extensions. Initially, no extension types are defined (see Section 6.3 ("Token Binding Extensions Registry")).
服务器必须忽略任何未知的扩展。最初，没有定义扩展类型（请参阅第6.3节（“令牌绑定扩展注册表”））。
If all checks defined above have passed successfully, the Token Binding between this client and server is established. The Token Binding ID(s) conveyed in the Token Binding message can be provided to the server-side application. The application may then use the Token Binding IDs for bound security token creation and validation; see Section 5.
如果上面定义的所有检查都已成功通过，则将在此客户端和服务器之间建立令牌绑定。令牌绑定消息中传递的令牌绑定ID可以提供给服务器端应用程序。然后，应用程序可以使用令牌绑定id来创建和验证绑定的安全令牌；见第5节。
If a Token Binding is rejected, any associated bound tokens presented on the current TLS connection MUST also be rejected by the server. The effect of this is application specific, e.g., failing requests, a requirement for the client to re-authenticate and present a different token, or connection termination.
如果令牌绑定被拒绝，则服务器也必须拒绝当前TLS连接上显示的任何关联绑定令牌。这种情况的影响是特定于应用程序的，例如，请求失败、客户端需要重新验证并提供不同的令牌或连接终止。
Security tokens can be bound to the TLS layer in a variety of ways, e.g., by embedding the Token Binding ID or its cryptographic hash in the token or by maintaining a database mapping tokens to Token Binding IDs. The specific method of generating bound security tokens is defined by the application and is beyond the scope of this document. Note that applicable security considerations are outlined in Section 7.
安全令牌可以以多种方式绑定到TLS层，例如，通过在令牌中嵌入令牌绑定ID或其加密散列，或者通过维护将令牌映射到令牌绑定ID的数据库。生成绑定安全令牌的具体方法由应用程序定义，超出了本文档的范围。请注意，第7节概述了适用的安全注意事项。
Either or both clients and servers MAY create bound security tokens. For example, HTTPS servers employing Token Binding for securing their HTTP cookies will bind these cookies. In the case of a server-initiated challenge-response protocol employing Token Binding and TLS, the client can, for example, incorporate the Token Binding ID within the signed object it returns, thus binding the object.
客户端和服务器中的一个或两个可以创建绑定的安全令牌。例如，使用令牌绑定保护HTTP cookie的HTTPS服务器将绑定这些cookie。在采用令牌绑定和TLS的服务器发起的质询-响应协议的情况下，客户端可以例如将令牌绑定ID合并到其返回的签名对象中，从而绑定该对象。
Upon receipt of a security token, the server attempts to retrieve Token Binding ID information from the token and from the TLS connection with the client. Application-provided policy determines whether to honor non-bound (bearer) tokens. If the token is bound and a Token Binding has not been established for the client connection, the server MUST reject the token. If the Token Binding ID for the token does not match the Token Binding ID established for the client connection, the server MUST reject the token.
收到安全令牌后，服务器尝试从令牌和与客户端的TLS连接检索令牌绑定ID信息。应用程序提供的策略确定是否接受非绑定（不承载）令牌。如果令牌已绑定，但尚未为客户端连接建立令牌绑定，则服务器必须拒绝该令牌。如果令牌的令牌绑定ID与为客户端连接建立的令牌绑定ID不匹配，则服务器必须拒绝该令牌。
This section establishes a new IANA registry titled "Token Binding Protocol" with subregistries "Token Binding Key Parameters", "Token Binding Types", and "Token Binding Extensions". It also registers a new TLS exporter label in the "TLS Exporter Labels" registry.
本节建立了一个名为“令牌绑定协议”的新IANA注册表，其中包含子区域“令牌绑定密钥参数”、“令牌绑定类型”和“令牌绑定扩展”。它还在“TLS exporter Labels”注册表中注册新的TLS exporter标签。
This document establishes a subregistry for identifiers of Token Binding key parameters titled "Token Binding Key Parameters" under the "Token Binding Protocol" registry.
本文件为“令牌绑定协议”注册表下标题为“令牌绑定密钥参数”的令牌绑定密钥参数的标识符建立了一个子区域。
Entries in this registry require the following fields:
此注册表中的条目需要以下字段：
o Value: The octet value that identifies a set of Token Binding key parameters (0-255).
o Value：标识一组令牌绑定密钥参数（0-255）的八位字节值。
o Description: The description of the Token Binding key parameters.
o 描述：令牌绑定密钥参数的描述。
o Reference: A reference to a specification that defines the Token Binding key parameters.
o 引用：对定义令牌绑定密钥参数的规范的引用。
This registry operates under the "Specification Required" policy as defined in [RFC8126]. The designated expert will require the inclusion of a reference to a permanent and readily available specification that enables the creation of interoperable implementations using the identified set of Token Binding key parameters.
该注册表按照[RFC8126]中定义的“所需规范”策略运行。指定的专家将要求包含对永久和现成规范的引用，该规范允许使用标识的令牌绑定密钥参数集创建可互操作的实现。
An initial set of registrations for this registry follows:
此注册表的初始注册集如下所示：
Value: 0 Description: rsa2048_pkcs1.5 Specification: This document
值：0说明：rsa2048_pkcs1.5规范：本文件
Value: 1 Description: rsa2048_pss Specification: This document
值：1说明：rsa2048_pss规范：本文件
Value: 2 Description: ecdsap256 Specification: This document
值：2说明：ecdsap256规格：本文档
This document establishes a subregistry for Token Binding type identifiers titled "Token Binding Types" under the "Token Binding Protocol" registry.
本文档为“令牌绑定协议”注册表下标题为“令牌绑定类型”的令牌绑定类型标识符建立了子目录。
Entries in this registry require the following fields:
此注册表中的条目需要以下字段：
o Value: The octet value that identifies the Token Binding type (0-255).
o Value：标识令牌绑定类型的八位字节值（0-255）。
o Description: The description of the Token Binding type.
o 描述：令牌绑定类型的描述。
o Reference: A reference to a specification that defines the Token Binding type.
o 引用：对定义令牌绑定类型的规范的引用。
This registry operates under the "Specification Required" policy as defined in [RFC8126]. The designated expert will require the inclusion of a reference to a permanent and readily available specification that enables the creation of interoperable implementations using the identified Token Binding type.
该注册表按照[RFC8126]中定义的“所需规范”策略运行。指定的专家将要求包含对永久性且随时可用的规范的引用，该规范允许使用标识的令牌绑定类型创建可互操作的实现。
An initial set of registrations for this registry follows:
此注册表的初始注册集如下所示：
Value: 0 Description: provided_token_binding Specification: This document
值：0说明：提供的\u令牌\u绑定规范：此文档
Value: 1 Description: referred_token_binding Specification: This document
值：1说明：引用\u标记\u绑定规范：本文档
This document establishes a subregistry for Token Binding extensions titled "Token Binding Extensions" under the "Token Binding Protocol" registry.
本文档为“令牌绑定协议”注册表下名为“令牌绑定扩展”的令牌绑定扩展建立了一个子域。
Entries in this registry require the following fields:
此注册表中的条目需要以下字段：
o Value: The octet value that identifies the Token Binding extension (0-255).
o Value：标识令牌绑定扩展的八位字节值（0-255）。
o Description: The description of the Token Binding extension.
o 描述：令牌绑定扩展的描述。
o Reference: A reference to a specification that defines the Token Binding extension.
o 引用：对定义令牌绑定扩展的规范的引用。
This registry operates under the "Specification Required" policy as defined in [RFC8126]. The designated expert will require the inclusion of a reference to a permanent and readily available specification that enables the creation of interoperable implementations using the identified Token Binding extension. This document creates no initial registrations in the "Token Binding Extensions" registry.
该注册表按照[RFC8126]中定义的“所需规范”策略运行。指定的专家将要求包含对永久和现成规范的引用，该规范允许使用标识的令牌绑定扩展创建可互操作的实现。本文档不会在“令牌绑定扩展”注册表中创建初始注册。
This document adds the following registration in the "TLS Exporter Labels" registry:
本文件在“TLS出口商标签”注册表中添加了以下注册：
Value: EXPORTER-Token-Binding DTLS-OK: Y Recommended: Y Reference: This document
值：导出器令牌绑定DTLS-OK:Y建议：Y参考：本文档
The goal of the Token Binding protocol is to prevent attackers from exporting and replaying security tokens and from thereby impersonating legitimate users and gaining access to protected resources. Bound tokens can be replayed by malware present in User Agents; this may be undetectable to a server. However, in order to export bound tokens to other machines and successfully replay them, attackers also need to export corresponding Token Binding private keys. Token Binding private keys are therefore high-value assets and SHOULD be strongly protected, ideally by generating them in a hardware security module that prevents key export.
令牌绑定协议的目标是防止攻击者导出和重放安全令牌，从而模拟合法用户并获得对受保护资源的访问。绑定令牌可被用户代理中的恶意软件重放；服务器可能无法检测到这一点。但是，为了将绑定的令牌导出到其他机器并成功重放它们，攻击者还需要导出相应的令牌绑定私钥。因此，令牌绑定私钥是高价值资产，应该得到强有力的保护，最好是在防止密钥导出的硬件安全模块中生成它们。
The manner in which a token is bound to the TLS layer is defined by the application and is beyond the scope of this document. However, the resulting bound token needs to be integrity-protected, so that an attacker cannot remove the binding or substitute a Token Binding ID of their choice without detection.
令牌绑定到TLS层的方式由应用程序定义，超出了本文档的范围。但是，生成的绑定令牌需要受到完整性保护，因此攻击者无法在未经检测的情况下删除绑定或替换其选择的令牌绑定ID。
The Token Binding protocol does not prevent cooperating clients from sharing a bound token. A client could intentionally export a bound token with the corresponding Token Binding private key or perform signatures using this key on behalf of another client.
令牌绑定协议不阻止协作客户端共享绑定令牌。客户机可以故意导出具有相应令牌绑定私钥的绑定令牌，或者代表另一个客户机使用此密钥执行签名。
The Token Binding protocol MUST be negotiated using a mechanism that prevents downgrade attacks. For example, [RFC8472] specifies a TLS extension for Token Binding negotiation. TLS detects handshake message modification by active attackers; therefore, it is not possible for an attacker to remove or modify the "token_binding" extension without breaking the TLS handshake. The signature algorithm and key length used in the TokenBinding of type "provided_token_binding" MUST match the negotiated parameters.
令牌绑定协议必须使用防止降级攻击的机制进行协商。例如，[RFC8472]为令牌绑定协商指定TLS扩展。TLS检测主动攻击者修改握手消息；因此，攻击者不可能在不破坏TLS握手的情况下删除或修改“令牌绑定”扩展。“提供的令牌绑定”类型的令牌绑定中使用的签名算法和密钥长度必须与协商参数匹配。
Existing systems provide a variety of platform-specific mechanisms for certain applications to share tokens, e.g., to enable "single sign-on" scenarios. For these scenarios to keep working with bound tokens, the applications that are allowed to share tokens will need to also share Token Binding keys. Care must be taken to restrict the sharing of Token Binding keys to the same group(s) of applications that shares the same tokens.
现有系统为某些应用程序提供了各种特定于平台的机制来共享令牌，例如启用“单点登录”场景。为了让这些场景继续使用绑定令牌，允许共享令牌的应用程序还需要共享令牌绑定密钥。必须注意将令牌绑定密钥的共享限制在共享相同令牌的应用程序组中。
The Token Binding protocol relies on the TLS exporters [RFC5705] to associate a TLS connection with a Token Binding. The triple handshake attack [TRIPLE-HS] is a known vulnerability in TLS 1.2 and older TLS versions, allowing the attacker to synchronize keying material between TLS connections. The attacker can then successfully replay bound tokens. For this reason, the Token Binding protocol MUST NOT be negotiated with these TLS versions, unless the extended master secret TLS extension [RFC7627] and the renegotiation indication TLS extension [RFC5746] have also been negotiated.
令牌绑定协议依赖TLS导出器[RFC5705]将TLS连接与令牌绑定相关联。三重握手攻击[triple-HS]是TLS 1.2和旧TLS版本中的一个已知漏洞，允许攻击者在TLS连接之间同步密钥材料。然后，攻击者可以成功重放绑定令牌。因此，令牌绑定协议不得与这些TLS版本协商，除非已协商扩展主密钥TLS扩展[RFC7627]和重新协商指示TLS扩展[RFC5746]。
The Token Binding protocol uses persistent, long-lived Token Binding IDs. To protect privacy, Token Binding IDs are never transmitted in clear text and can be reset by the user at any time, e.g., when clearing browser cookies. Some applications offer a special privacy mode where they don't store or use tokens supplied by the server, e.g., "in private" browsing. When operating in this special privacy mode, applications SHOULD use newly generated Token Binding keys and delete them when exiting this mode; otherwise, they SHOULD NOT negotiate Token Binding at all.
令牌绑定协议使用持久、长寿命的令牌绑定ID。为了保护隐私，令牌绑定ID永远不会以明文形式传输，用户可以随时重置，例如，在清除浏览器cookie时。一些应用程序提供了一种特殊的隐私模式，在这种模式下，它们不存储或使用服务器提供的令牌，例如“私下”浏览。当在这种特殊的隐私模式下运行时，应用程序应使用新生成的令牌绑定密钥，并在退出这种模式时将其删除；否则，他们根本不应该协商令牌绑定。
In order to prevent cooperating servers from linking user identities, the scope of the Token Binding keys MUST NOT be broader than the scope of the tokens, as defined by the application protocol.
为了防止协作服务器链接用户标识，令牌绑定密钥的范围不得超过应用程序协议定义的令牌范围。
A server can use tokens and Token Binding IDs to track clients. Client applications that automatically limit the lifetime or scope of tokens to maintain user privacy SHOULD apply the same validity time and scope limits to Token Binding keys.
服务器可以使用令牌和令牌绑定ID来跟踪客户端。自动限制令牌生命周期或范围以维护用户隐私的客户端应用程序应将相同的有效时间和范围限制应用于令牌绑定密钥。
[ANSI.X9-62.2005] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, November 2005.
[ANSI.X9-62.2005]美国国家标准协会，“金融服务业的公钥加密：椭圆曲线数字签名算法（ECDSA）”，ANSI X9.62，2005年11月。
[FIPS.180-4.2015] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.
[FIPS.180-4.2015]国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS 180-4，DOI 10.6028/NIST.FIPS.180-42015年8月<https://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>。
[FIPS.186-4.2013] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <https://nvlpubs.nist.gov/nistpubs/fips/ nist.fips.186-4.pdf>.
[FIPS.186-4.2013]国家标准与技术研究所，“数字签名标准（DSS）”，FIPS 186-4，DOI 10.6028/NIST.FIPS.186-42013年7月<https://nvlpubs.nist.gov/nistpubs/fips/ nist.fips.186-4.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5705]Rescorla，E.“传输层安全（TLS）关键材料导出器”，RFC 5705，DOI 10.17487/RFC5705，2010年3月<https://www.rfc-editor.org/info/rfc5705>.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, <https://www.rfc-editor.org/info/rfc5746>.
[RFC5746]Rescorla，E.，Ray，M.，Dispensa，S.，和N.Oskov，“传输层安全（TLS）重新协商指示扩展”，RFC 5746，DOI 10.17487/RFC5746，2010年2月<https://www.rfc-editor.org/info/rfc5746>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540]Belshe，M.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本2（HTTP/2）”，RFC 7540，DOI 10.17487/RFC7540，2015年5月<https://www.rfc-editor.org/info/rfc7540>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, <https://www.rfc-editor.org/info/rfc7627>.
[RFC7627]Bhargavan，K.，Ed.，Delignat Lavaud，A.，Pironti，A.，Langley，A.，和M.Ray，“传输层安全（TLS）会话哈希和扩展主秘密扩展”，RFC 7627，DOI 10.17487/RFC7627，2015年9月<https://www.rfc-editor.org/info/rfc7627>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation", RFC 8472, DOI 10.17487/RFC8472, October 2018, <https://www.rfc-editor.org/info/rfc8472>.
[RFC8472]Popov，A.，Ed.，Nystroem，M.，和D.Balfanz，“令牌绑定协议协商的传输层安全（TLS）扩展”，RFC 8472，DOI 10.17487/RFC8472，2018年10月<https://www.rfc-editor.org/info/rfc8472>.
[RFC8473] Popov, A., Nystroem, M., Balfanz, D., Ed., Harper, N., and J. Hodges, "Token Binding over HTTP", RFC 8473, DOI 10.17487/RFC8473, October 2018, <https://www.rfc-editor.org/info/rfc8473>.
[RFC8473]Popov，A.，Nystroem，M.，Balfanz，D.，Ed.，Harper，N.，和J.Hodges，“HTTP上的令牌绑定”，RFC 8473，DOI 10.17487/RFC8473，2018年10月<https://www.rfc-editor.org/info/rfc8473>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.
[RFC6749]Hardt，D.，Ed.“OAuth 2.0授权框架”，RFC 6749，DOI 10.17487/RFC6749，2012年10月<https://www.rfc-editor.org/info/rfc6749>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[RFC8017]Moriarty，K.，Ed.，Kaliski，B.，Jonsson，J.，和A.Rusch，“PKCS#1:RSA加密规范版本2.2”，RFC 8017，DOI 10.17487/RFC8017，2016年11月<https://www.rfc-editor.org/info/rfc8017>.
[TOKENBIND-TLS13] Harper, N., "Token Binding for Transport Layer Security (TLS) Version 1.3 Connections", Work in Progress, draft-ietf-tokbind-tls13-01, May 2018.
[TOKENBIND-TLS13]哈珀，N.，“传输层安全（TLS）连接的令牌绑定版本1.3”，正在进行中，草稿-ietf-tokbind-TLS13-01，2018年5月。
[TRIPLE-HS] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P. Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", IEEE Symposium on Security and Privacy, DOI 10.1109/SP.2014.14, May 2014.
[TRIPLE-HS]Bhargavan，K.，Delignat Lavaud，A.，Fournet，C.，Pironti，A.，和P.Strub，“三重握手和切饼干器：通过TLS破坏和修复认证”，IEEE安全和隐私研讨会，DOI 10.1109/SP.2014.14，2014年5月。
Acknowledgements
致谢
This document incorporates comments and suggestions offered by Eric Rescorla, Gabriel Montenegro, Martin Thomson, Vinod Anupam, Anthony Nadalin, Michael B. Jones, Bill Cox, Nick Harper, Brian Campbell, Benjamin Kaduk, Alexey Melnikov, and others.
本文件包含Eric Rescorla、Gabriel Montegon、Martin Thomson、Vinod Anupam、Anthony Nadalin、Michael B.Jones、Bill Cox、Nick Harper、Brian Campbell、Benjamin Kaduk、Alexey Melnikov和其他人提出的意见和建议。
This document was produced under the chairmanship of John Bradley and Leif Johansson. The area directors included Eric Rescorla, Kathleen Moriarty, and Stephen Farrell.
本文件由约翰·布拉德利和莱夫·约翰逊主持编写。区域主管包括Eric Rescorla、Kathleen Moriarty和Stephen Farrell。
Authors' Addresses
作者地址
Andrei Popov (editor) Microsoft Corp. United States of America
Andrei Popov（编辑）美利坚合众国微软公司
Email: andreipo@microsoft.com
Email: andreipo@microsoft.com
Magnus Nystroem Microsoft Corp. United States of America
Magnus Nystroem微软公司美利坚合众国
Email: mnystrom@microsoft.com
Email: mnystrom@microsoft.com
Dirk Balfanz Google Inc. United States of America
Dirk Balfanz谷歌公司美利坚合众国
Email: balfanz@google.com
Email: balfanz@google.com
Jeff Hodges Kings Mountain Systems United States of America
Jeff Hodges Kings Mountain Systems美利坚合众国
Email: Jeff.Hodges@KingsMountain.com
Email: Jeff.Hodges@KingsMountain.com