Independent Submission D. Thakore
Request for Comments: 7562 CableLabs
Category: Informational July 2015
ISSN: 2070-1721
Independent Submission D. Thakore
Request for Comments: 7562 CableLabs
Category: Informational July 2015
ISSN: 2070-1721
Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates
使用数字传输内容保护（DTCP）证书的传输层安全（TLS）授权
Abstract
摘要
This document specifies the use of Digital Transmission Content Protection (DTCP) certificates as an authorization data type in the authorization extension for the Transport Layer Security (TLS) protocol. This is in accordance with the guidelines for authorization extensions as specified in RFC 5878. As with other TLS extensions, this authorization data can be included in the client and server hello messages to confirm that both parties support the desired authorization data types. If supported by both the client and the server, DTCP certificates are exchanged in the supplemental data TLS handshake message as specified in RFC 4680. This authorization data type extension is in support of devices containing DTCP certificates issued by the Digital Transmission Licensing Administrator (DTLA).
本文档规定在传输层安全（TLS）协议的授权扩展中使用数字传输内容保护（DTCP）证书作为授权数据类型。这符合RFC 5878中规定的授权扩展指南。与其他TLS扩展一样，此授权数据可以包含在客户端和服务器hello消息中，以确认双方都支持所需的授权数据类型。如果客户端和服务器都支持DTCP，则按照RFC 4680中的规定，在补充数据TLS握手消息中交换DTCP证书。此授权数据类型扩展支持包含数字传输授权管理员（DTLA）颁发的DTCP证书的设备。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc7562.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7562.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Applicability Statement ....................................3
1.2. Conventions ................................................4
2. Overview ........................................................4
2.1. Overview of DTCP Certificates ..............................4
2.2. Overview of SupplementalData Handshake .....................5
2.3. Overview of Authorization Extensions .......................5
2.4. Overview of SupplementalData Usage for Authorization .......6
3. DTCP Authorization Data Format ..................................6
3.1. DTCP Authorization Type ....................................6
3.2. DTCP Authorization Data ....................................6
3.3. Usage Rules for Clients to Exchange DTCP
Authorization Data .........................................7
3.4. Usage Rules for Servers to Exchange DTCP
Authorization Data .........................................8
3.5. TLS Message Exchange with dtcp_authz_data ..................8
3.6. Alert Messages .............................................9
4. IANA Considerations ............................................10
5. Security Considerations ........................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................12
Appendix A. Alternate Double Handshake Example ....................13
Acknowledgements ..................................................15
Author's Address ..................................................15
1. Introduction ....................................................3
1.1. Applicability Statement ....................................3
1.2. Conventions ................................................4
2. Overview ........................................................4
2.1. Overview of DTCP Certificates ..............................4
2.2. Overview of SupplementalData Handshake .....................5
2.3. Overview of Authorization Extensions .......................5
2.4. Overview of SupplementalData Usage for Authorization .......6
3. DTCP Authorization Data Format ..................................6
3.1. DTCP Authorization Type ....................................6
3.2. DTCP Authorization Data ....................................6
3.3. Usage Rules for Clients to Exchange DTCP
Authorization Data .........................................7
3.4. Usage Rules for Servers to Exchange DTCP
Authorization Data .........................................8
3.5. TLS Message Exchange with dtcp_authz_data ..................8
3.6. Alert Messages .............................................9
4. IANA Considerations ............................................10
5. Security Considerations ........................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................12
Appendix A. Alternate Double Handshake Example ....................13
Acknowledgements ..................................................15
Author's Address ..................................................15
The Transport Layer Security (TLS) protocol (see TLS 1.0 [RFC2246], TLS 1.1 [RFC4346], and TLS1 .2 [RFC5246]) is being used in an ever increasing variety of operational environments, the most common among which is its use in securing HTTP traffic [RFC2818]. [RFC5878] introduces extensions that enable TLS to operate in environments where authorization information needs to be exchanged between the client and the server before any protected data is exchanged. The use of these TLS authorization extensions is especially attractive since it allows the client and server to determine the type of protected data to exchange based on the authorization information received in the extensions.
传输层安全（TLS）协议（见TLS 1.0[RFC2246]、TLS 1.1[RFC4346]和TLS1.2[RFC5246]）正在越来越多的操作环境中使用，其中最常见的是用于保护HTTP流量[RFC2818]。[RFC5878]引入了扩展，使TLS能够在需要在客户端和服务器之间交换授权信息，然后再交换任何受保护数据的环境中运行。使用这些TLS授权扩展特别有吸引力，因为它允许客户端和服务器根据扩展中接收的授权信息确定要交换的受保护数据的类型。
A substantial number of deployed consumer electronics devices, such as televisions, tablets, game consoles, set-top boxes, and other multimedia devices, contain Digital Transmission Content Protection [DTCP] certificates issued by [DTLA]. These DTCP certificates enable secure transmission of premium audiovisual content between devices over various types of links (e.g., DTCP over IP [DTCP-IP]). These DTCP certificates can also be used to verify device functionality (e.g., supported device features).
大量已部署的消费电子设备（如电视、平板电脑、游戏机、机顶盒和其他多媒体设备）包含[DTLA]颁发的数字传输内容保护[DTCP]证书。这些DTCP证书能够通过各种类型的链路（例如，DTCP over IP[DTCP-IP]）在设备之间安全传输优质视听内容。这些DTCP证书还可用于验证设备功能（例如，支持的设备功能）。
This document describes the format and necessary identifiers to exchange DTCP certificates within the supplemental data message (see [RFC4680]) while negotiating a TLS session. The DTCP certificates are then used independent of their use for content protection (e.g., to verify supported features) and the corresponding DTCP Authentication and Key Exchange (AKE) protocol. This communication allows either the client, the server, or both to perform certain actions or provide specific services. The actual semantics of the authorization decision by the client/server are beyond the scope of this document. The DTCP certificate, which is not an X.509 certificate, can be cryptographically tied to the X.509 certificate being used during the TLS tunnel establishment by an Elliptic Curve Digital Signature Algorithm (EC-DSA) [DTCP] signature.
本文档描述了在协商TLS会话时，在补充数据消息（参见[RFC4680]）内交换DTCP证书的格式和必要标识符。然后，DTCP证书独立于其用于内容保护（例如，验证支持的功能）和相应的DTCP身份验证和密钥交换（AKE）协议而使用。此通信允许客户端、服务器或两者执行某些操作或提供特定服务。客户机/服务器授权决策的实际语义超出了本文的范围。DTCP证书不是X.509证书，可以通过椭圆曲线数字签名算法（EC-DSA）[DTCP]签名以加密方式与TLS隧道建立期间使用的X.509证书绑定。
DTCP-enabled consumer electronics devices (e.g., televisions, game consoles) use DTCP certificates for secure transmission of audiovisual content. The AKE protocol defined in [DTCP] is used to exchange DTCP certificates and allows a device to be identified and authenticated based on the information in the DTCP certificate. However, these DTCP-enabled devices offer additional functionality (e.g., via HTML5 User Agents or web-enabled applications) that is distinct from its capability to transmit and play audiovisual content. The mechanism outlined in this document allows a DTCP-
支持DTCP的消费电子设备（如电视机、游戏机）使用DTCP证书安全传输视听内容。[DTCP]中定义的AKE协议用于交换DTCP证书，并允许根据DTCP证书中的信息识别和验证设备。然而，这些支持DTCP的设备提供了与传输和播放视听内容不同的附加功能（例如，通过HTML5用户代理或支持web的应用程序）。本文档中概述的机制允许DTCP-
enabled consumer electronics device to authenticate and authorize using its DTCP certificate when accessing services over the internet; for example, web applications on televisions that can enable value-added services. This is anticipated to be very valuable since there are a considerable number of such devices. The reuse of well-known web security will also keep such communication consistent with existing standards and best practices.
使消费电子设备能够在通过互联网访问服务时使用其DTCP证书进行身份验证和授权；例如，电视上的web应用程序可以实现增值服务。这是非常有价值的，因为有相当数量的此类设备。重用著名的web安全性也将使此类通信与现有标准和最佳实践保持一致。
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]中所述进行解释。
DTCP certificates issued by [DTLA] to DTLA-compliant devices come in three general variations (see Section 4.2.3.1 of [DTCP]):
[DTLA]向符合DTLA标准的设备颁发的DTCP证书有三种一般变体（见[DTCP]第4.2.3.1节）：
o Restricted Authentication device certificate format (Format 0): Typically issued to devices with limited computation resources.
o 受限身份验证设备证书格式（格式0）：通常颁发给计算资源有限的设备。
o Baseline Full Authentication device certificate format (Format 1): This is the most commonly issued certificate format. Format 1 certificates include a unique DeviceID and device EC-DSA public/ private key pair generated by the DTLA. (See Section 4.3 of [DTCP]).
o 基线完全身份验证设备证书格式（格式1）：这是最常用的证书格式。格式1证书包括由DTLA生成的唯一设备ID和设备EC-DSA公钥/私钥对。（见[DTCP]第4.3节）。
o Extended Full Authentication device certificate format (Format 2): This is issued to devices that possess additional functions (e.g., additional channel ciphers, specific device properties). The presence of these additional functions is indicated by the device capability mask as specified in Section 4.2.3.2 of [DTCP]. Format 2 certificates also include a unique DeviceID and device EC-DSA public/private key pair generated by the DTLA (see Section 4.3 of [DTCP]).
o 扩展完全身份验证设备证书格式（格式2）：该格式颁发给具有附加功能（例如，附加通道密码、特定设备属性）的设备。这些附加功能的存在由[DTCP]第4.2.3.2节规定的设备能力掩码表示。格式2证书还包括由DTLA生成的唯一设备ID和设备EC-DSA公钥/私钥对（见[DTCP]第4.3节）。
The mechanism specified in this document allows only Formats 1 and 2 DTCP certificates to be exchanged in the supplemental data message since it requires the use of the EC-DSA private key associated with the certificate.
本文档中指定的机制仅允许在补充数据消息中交换格式1和格式2 DTCP证书，因为它需要使用与证书相关联的EC-DSA私钥。
Figure 1 illustrates the exchange of the SupplementalData message during the TLS handshake as specified in [RFC4680] (repeated here for convenience):
图1说明了[RFC4680]中指定的TLS握手期间的补充数据消息交换（此处重复以方便起见）：
Client Server
客户端服务器
ClientHello (with extensions) -------->
ClientHello (with extensions) -------->
ServerHello(with extensions)
SupplementalData*
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
ServerHello(with extensions)
SupplementalData*
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
SupplementalData*
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
SupplementalData*
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* Indicates optional or situation-dependent messages that are not always sent.
* 指示并非始终发送的可选消息或情况相关消息。
[] Indicates that ChangeCipherSpec is an independent TLS protocol content type; it is not a TLS handshake message.
[]表示ChangeCipherSpec是独立的TLS协议内容类型；这不是TLS握手消息。
Figure 1: TLS Handshake Message Exchange with SupplementalData
图1：使用补充数据的TLS握手消息交换
[RFC5878] defines two authorization extension types that are used in the ClientHello and ServerHello messages and are repeated below for convenience:
[RFC5878]定义了在ClientHello和ServerHello消息中使用的两种授权扩展类型，为方便起见，在下面重复：
enum {
client_authz(7), server_authz(8), (65535)
} ExtensionType;
enum {
client_authz(7), server_authz(8), (65535)
} ExtensionType;
A client uses the client_authz and server_authz extensions in the ClientHello message to indicate that it will send client authorization data and receive server authorization data,
客户端使用ClientHello消息中的client_authz和server_authz扩展来指示它将发送客户端授权数据并接收服务器授权数据，
respectively, in the SupplementalData messages. A server uses the extensions in a similar manner in its ServerHello message. [RFC5878] also establishes a registry that is maintained by IANA to register authorization data formats. This document defines a new authorization data type for both the client_authz and server_authz extensions and allows the client and server to exchange DTCP certificates in the SupplementalData message.
分别在补充数据信息中。服务器在其ServerHello消息中以类似的方式使用扩展。[RFC5878]还建立了一个由IANA维护的注册表，用于注册授权数据格式。本文档为客户端授权和服务器授权扩展定义了新的授权数据类型，并允许客户端和服务器在补充数据消息中交换DTCP证书。
Section 3 of [RFC5878] specifies the syntax of the supplemental data message when carrying the authz_data message that is negotiated in the client_authz and/or server_authz types. This document defines a new authorization data format that is used in the authz_data message when sending DTCP Authorization Data.
[RFC5878]的第3节规定了在承载客户端和/或服务器端authz类型中协商的authz_数据消息时，补充数据消息的语法。本文档定义了一种新的授权数据格式，该格式在发送DTCP授权数据时用于authz_数据消息。
The DTCP Authorization type definition in the TLS Authorization Data Formats registry is:
TLS授权数据格式注册表中的DTCP授权类型定义为：
dtcp_authorization(66);
dtcp_授权（66）；
The DTCP Authorization Data is used when the AuthzDataFormat type is dtcp_authorization. The syntax of the authorization data is:
当AuthzDataFormat类型为DTCP\U授权时，将使用DTCP授权数据。授权数据的语法为：
struct {
opaque random_bytes[32];
} RandomNonce;
struct {
opaque random_bytes[32];
} RandomNonce;
struct {
opaque RandomNonce nonce;
opaque DTCPCert<0..2^24-1>;
opaque ASN.1Cert<0..2^24-1>;
opaque signature<0..2^16-1>;
} dtcp_authz_data;
struct {
opaque RandomNonce nonce;
opaque DTCPCert<0..2^24-1>;
opaque ASN.1Cert<0..2^24-1>;
opaque signature<0..2^16-1>;
} dtcp_authz_data;
RandomNonce is generated by the server and consists of 32 bytes generated by a high-quality, secure random number generator. The client always sends back the server-generated RandomNonce in its dtcp_authz_data structure. The RandomNonce helps the server in detecting replay attacks. A client can detect replay attacks by
RandomNonce由服务器生成，由高质量、安全的随机数生成器生成的32个字节组成。客户端总是在其dtcp_authz_数据结构中发回服务器生成的随机数。随机数帮助服务器检测重播攻击。客户端可以通过以下方式检测重播攻击：
associating the ASN.1 certificate in the dtcp_authz_data structure with the certificate received in the Certificate message of the TLS handshake, so a separate nonce for the client is not required.
将dtcp_authz_数据结构中的ASN.1证书与TLS握手的证书消息中接收的证书相关联，因此不需要为客户端提供单独的nonce。
DTCPCert is the sender's DTCP certificate. See Section 4.2.3.1 of the DTCP Specification [DTCP].
DTCPCert是发送方的DTCP证书。见DTCP规范[DTCP]第4.2.3.1节。
ASN.1Cert is the sender's certificate used to establish the TLS session, i.e., it is sent in the Certificate or ClientCertificate message using the Certificate structure defined in Section 7.4.2 of [RFC5246].
ASN.1Cert是用于建立TLS会话的发送方证书，即使用[RFC5246]第7.4.2节中定义的证书结构在证书或客户端证书消息中发送。
The DTCPCert and ASN.1Cert are variable-length vectors as specified in Section 4.3 of [RFC5246]. Hence, the actual length precedes the vector's contents in the byte stream. If the ASN.1Cert is not being sent, the ASN.1Cert_length MUST be zero.
DTCPCert和ASN.1Cert是[RFC5246]第4.3节中规定的可变长度向量。因此，实际长度先于字节流中向量的内容。如果未发送ASN.1Cert，则ASN.1Cert_长度必须为零。
dtcp_authz_data contains the RandomNonce, the DTCP certificate, and the optional ASN.1 certificate. This is then followed by the digital signature covering the RandomNonce, the DTCP certificate, and the ASN.1 certificate (if present). The signature is generated using the private key associated with the DTCP certificate and using the Signature Algorithm and Hash Algorithm as specified in Section 4.4 of [DTCP]. This signature provides proof of the possession of the private key by the sender. A sender sending its own DTCP certificate MUST populate this field. The length of the signature field is determined by the Signature Algorithm and Hash Algorithm as specified in Section 4.4 of [DTCP], and so it is not explicitly encoded in the dtcp_authz_data structure (e.g., the length will be 40 bytes for a SHA1+ECDSA algorithm combination).
dtcp_authz_数据包含随机数、dtcp证书和可选的ASN.1证书。然后是数字签名，包括随机数、DTCP证书和ASN.1证书（如果存在）。使用与DTCP证书相关联的私钥以及[DTCP]第4.4节中规定的签名算法和哈希算法生成签名。此签名提供发送方拥有私钥的证据。发送自己的DTCP证书的发件人必须填写此字段。签名字段的长度由[DTCP]第4.4节中规定的签名算法和哈希算法确定，因此未在DTCP_authz_数据结构中明确编码（例如，对于SHA1+ECDSA算法组合，长度将为40字节）。
A client includes both the client_authz and server_authz extensions in the extended client hello message when indicating its desire to exchange dtcp_authorization data with the server. Additionally, the client includes the AuthzDataFormat type specified in Section 3.1 in the extension_data field to specify the format of the authorization data.
当客户机表示希望与服务器交换dtcp_授权数据时，它在扩展客户机hello消息中同时包含客户机_authz和服务器_authz扩展。此外，客户机在extension_数据字段中包含第3.1节中指定的AuthzDataFormat类型，以指定授权数据的格式。
A client will receive the server's dtcp_authz_data before it sends its own dtcp_authz_data. When sending its own dtcp_authz_data message, the client includes the same RandomNonce that it receives in the server's dtcp_authz_data message. Clients MUST include its DTCP certificate in the dtcp_authz_data message. A client MAY include its ASN.1 certificate (certificate in the ClientCertificate message) in
客户端将在发送自己的dtcp_authz_数据之前接收服务器的dtcp_authz_数据。当发送自己的dtcp_authz_数据消息时，客户机包含它在服务器的dtcp_authz_数据消息中接收到的相同随机数。客户端必须在DTCP_authz_数据消息中包含其DTCP证书。客户端可以将其ASN.1证书（ClientCertificate消息中的证书）包含在
the ASN.1Cert field of the dtcp_authz_data to cryptographically tie the dtcp_authz_data with its ASN.1Cert being used to establish the TLS session (i.e., sent in the ClientCertificate message).
dtcp_authz_数据的ASN.1Cert字段以加密方式将dtcp_authz_数据与其用于建立TLS会话的ASN.1Cert联系起来（即，在ClientCertificate消息中发送）。
A server responds with both the client_authz and server_authz extensions in the extended server hello message when indicating its desire to exchange dtcp_authorization data with the client.
当服务器表示希望与客户机交换dtcp_授权数据时，服务器会在扩展服务器hello消息中响应客户机_authz和服务器_authz扩展。
Additionally, the server includes the AuthzDataFormat type specified in Section 3.1 in the extension_data field to specify the format of the dtcp_authorization data. A client may or may not include an ASN.1 certificate during the TLS handshake. However, the server will not know that at the time of sending the SupplementalData message. Hence, a server MUST generate and populate the RandomNonce in the dtcp_authz_data message. If the client's hello message does not contain both the client_authz and server_authz extensions with dtcp_authorization type, the server MUST NOT include support for dtcp_authorization data in its hello message. A server MAY include its DTCP certificate in the dtcp_authz_data message. If the server does not send a DTCP certificate, it will send only the RandomNonce in its dtcp_authz_data message. If the server includes its DTCP certificate, it MUST also include its server certificate (sent in the TLS Certificate message) in the certs field to cryptographically tie its dtcp_authz_data with the ASN.1 certificate used in the TLS session being established. This also helps the client in detecting replay attacks.
此外，服务器在extension_数据字段中包含第3.1节中指定的AuthzDataFormat类型，以指定dtcp_授权数据的格式。在TLS握手过程中，客户端可能包括也可能不包括ASN.1证书。但是，在发送补充数据消息时，服务器将不知道这一点。因此，服务器必须在dtcp_authz_数据消息中生成并填充随机数。如果客户端的hello消息不同时包含具有dtcp_授权类型的client_authz和server_authz扩展，则服务器不得在其hello消息中包含对dtcp_授权数据的支持。服务器可以在DTCP_authz_数据消息中包含其DTCP证书。如果服务器不发送DTCP证书，它将只发送其DTCP_authz_数据消息中的随机数。如果服务器包含其DTCP证书，则它还必须在certs字段中包含其服务器证书（在TLS证书消息中发送），以加密方式将其DTCP_authz_数据与正在建立的TLS会话中使用的ASN.1证书联系起来。这也有助于客户端检测重播攻击。
Based on the usage rules in the sections above, Figure 2 provides one possible TLS message exchange where the client sends its DTCP certificate to the server within the dtcp_authz_data message.
根据以上各节中的使用规则，图2提供了一种可能的TLS消息交换，其中客户端在DTCP_authz_数据消息中向服务器发送其DTCP证书。
Client Server
客户端服务器
ClientHello (with extensions) -------->
ClientHello (with extensions) -------->
ServerHello(with extensions)
SupplementalData(with Nonce N1)
Certificate
ServerKeyExchange*
CertificateRequest
<-------- ServerHelloDone
ServerHello(with extensions)
SupplementalData(with Nonce N1)
Certificate
ServerKeyExchange*
CertificateRequest
<-------- ServerHelloDone
SupplementalData(with Data D1)
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
SupplementalData(with Data D1)
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
N1 Indicates a Random nonce generated by server
N1表示服务器生成的随机nonce
D1 Contains dtcp_authz_data populated with the following {(N1, DTCP Cert, Client X.509 Cert) Signature over all elements}
D1包含dtcp_authz_数据，填充了以下{（N1，dtcp证书，客户端X.509证书）对所有元素的签名}
* Indicates optional or situation-dependent messages that are not always sent.
* 指示并非始终发送的可选消息或情况相关消息。
[] Indicates that ChangeCipherSpec is an independent TLS protocol content type; it is not a TLS handshake message.
[]表示ChangeCipherSpec是独立的TLS协议内容类型；这不是TLS握手消息。
Figure 2: DTCP SupplementalData Exchange
图2:DTCP补充数据交换
This document reuses TLS Alert messages for any errors that arise during authorization processing and reuses the AlertLevels as specified in [RFC5878]. Additionally, the following AlertDescription values are used to report errors in dtcp_authorization processing:
本文档针对授权处理过程中出现的任何错误重用TLS警报消息，并按照[RFC5878]中的规定重用警报级别。此外，以下AlertDescription值用于报告dtcp_授权处理中的错误：
unsupported_extension: During processing of dtcp_authorization, a client uses this when it receives a server hello message that includes support for dtcp_authorization in only one of client_authz or server_authz but not in both the extensions. This message is always fatal. Note:
不支持的\u扩展：在处理dtcp\u授权的过程中，客户端在接收到服务器hello消息时使用此消息，该消息仅在客户端\u authz或服务器\u authz中的一个扩展中包含对dtcp\u授权的支持，但不在两个扩展中。这个消息总是致命的。注:
Completely omitting the dtcp_authorization extension and/or omitting the client_authz and server_authz completely is allowed and should not constitute the reason that this alert is sent.
允许完全忽略dtcp_授权扩展和/或完全忽略客户端_authz和服务器_authz，这不应构成发送此警报的原因。
certificate_unknown: During processing of dtcp_authorization, a client or server uses this when it has received an X.509 certificate in the dtcp_authorization data and that X.509 certificate does not match the certificate sent in the corresponding ClientCertificate or Certificate message.
certificate_unknown：在处理dtcp_授权的过程中，当客户端或服务器在dtcp_授权数据中收到X.509证书且X.509证书与相应的ClientCertificate或certificate消息中发送的证书不匹配时，客户端或服务器将使用该证书。
This document includes an entry registered in the IANA-maintained "TLS Authorization Data Formats" registry for dtcp_authorization(66). This registry is defined in [RFC5878] and defines two ranges: one is IETF Review, and the other is Specification Required. The value for dtcp_authorization should be assigned via [RFC5226] Specification Required. The extension defined in this document is compatible with Data Transport Layer Security (DTLS) [RFC6347], and the registry assignment has been marked "Y" for DTLS-OK.
本文件包括在IANA维护的dtcp_授权“TLS授权数据格式”注册表中注册的条目（66）。该注册表在[RFC5878]中定义，并定义了两个范围：一个是IETF审查，另一个是规范要求。dtcp_授权值应通过所需的[RFC5226]规范进行分配。本文档中定义的扩展与数据传输层安全性（DTLS）[RFC6347]兼容，对于DTLS-OK，注册表分配已标记为“Y”。
The dtcp_authorization data, as specified in this document, carries the DTCP certificate that identifies the associated device. Inclusion of the X.509 certificate being used to establish a TLS Session in the dtcp_authorization data allows an application to cryptographically tie them. However, a TLS Client is not required to use (and may not possess) an X.509 certificate. In this case, the dtcp_authorization data exchange is prone to a man-in-the-middle (MITM) attack. In such situations, a TLS server MUST deny access to the application features dependent on the DTCP certificate or use a double handshake. The double handshake mechanism is also vulnerable to the TLS MITM Renegotiation exploit as explained in [RFC5746]. In order to address this vulnerability, clients and servers MUST use the secure_renegotiation extension as specified in [RFC5746] when exchanging dtcp_authorization data. Additionally, the renegotiation is also vulnerable to the Triple Handshake exploit. To mitigate this, servers MUST use the same ASN.1 certificate during renegotiation as the one used in the initial handshake.
如本文件所述，dtcp_授权数据携带识别相关设备的dtcp证书。将用于在dtcp_授权数据中建立TLS会话的X.509证书包括在内，允许应用程序以加密方式将其绑定。但是，TLS客户端不需要使用（也可能不拥有）X.509证书。在这种情况下，dtcp_授权数据交换容易受到中间人（MITM）攻击。在这种情况下，TLS服务器必须拒绝访问依赖于DTCP证书的应用程序功能，或者使用双重握手。如[RFC5746]中所述，双握手机制也容易受到TLS MITM重新协商漏洞的攻击。为了解决此漏洞，客户端和服务器在交换dtcp_授权数据时必须使用[RFC5746]中指定的安全_重新协商扩展。此外，重新协商也容易受到三重握手攻击。为了缓解这种情况，服务器在重新协商期间必须使用与初始握手中使用的证书相同的ASN.1证书。
It should be noted that for the double handshake to succeed, any extension (e.g., TLS Session Ticket [RFC5077]) that results in the TLS handshake sequence being modified may result in failure to exchange SupplementalData.
应注意，为了使双握手成功，导致修改TLS握手序列的任何扩展（例如，TLS会话票证[RFC5077]）都可能导致交换补充数据失败。
Additionally, the security considerations specified in [RFC5878] and [RFC5246] apply to the extension specified in this document. In addition, the dtcp_authorization data may be carried along with other supplemental data or some other authorization data and that information may require additional protection. Finally, implementers should also reference [DTCP] and [DTCP-IP] for more information regarding DTCP certificates, their usage, and associated security considerations.
此外，[RFC5878]和[RFC5246]中规定的安全注意事项适用于本文件中规定的扩展。此外，dtcp_授权数据可能与其他补充数据或一些其他授权数据一起携带，并且该信息可能需要额外的保护。最后，实现者还应参考[DTCP]和[DTCP-IP]以了解有关DTCP证书、其用法和相关安全注意事项的更多信息。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, <http://www.rfc-editor.org/info/rfc2246>.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，DOI 10.17487/RFC2246，1999年1月<http://www.rfc-editor.org/info/rfc2246>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, <http://www.rfc-editor.org/info/rfc4346>.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，DOI 10.17487/RFC4346，2006年4月<http://www.rfc-editor.org/info/rfc4346>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[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, <http://www.rfc-editor.org/info/rfc5746>.
[RFC5746]Rescorla，E.，Ray，M.，Dispensa，S.，和N.Oskov，“传输层安全（TLS）重新协商指示扩展”，RFC 5746，DOI 10.17487/RFC5746，2010年2月<http://www.rfc-editor.org/info/rfc5746>.
[RFC4680] Santesson, S., "TLS Handshake Message for Supplemental Data", RFC 4680, DOI 10.17487/RFC4680, October 2006, <http://www.rfc-editor.org/info/rfc4680>.
[RFC4680]Santesson，S.，“补充数据的TLS握手信息”，RFC 4680，DOI 10.17487/RFC4680，2006年10月<http://www.rfc-editor.org/info/rfc4680>.
[RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) Authorization Extensions", RFC 5878, DOI 10.17487/RFC5878, May 2010, <http://www.rfc-editor.org/info/rfc5878>.
[RFC5878]Brown，M.和R.Housley，“传输层安全（TLS）授权扩展”，RFC 5878，DOI 10.17487/RFC5878，2010年5月<http://www.rfc-editor.org/info/rfc5878>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[DTCP] Digital Transmission Licensing Administrator, "Digital Transmission Content Protection Specification", Volume 1, Informational Version, <http://www.dtcp.com/documents/dtcp/ info-20130605-dtcp-v1-rev-1-7-ed2.pdf>.
[DTCP]数字传输许可管理员，“数字传输内容保护规范”，第1卷，信息版<http://www.dtcp.com/documents/dtcp/ info-20130605-dtcp-v1-rev-1-7-ed2.pdf>。
[DTCP-IP] Digital Transmission Licensing Administrator, "Mapping DTCP to IP", Volume 1, Supplement E, Informational Version, <http://www.dtcp.com/documents/dtcp/ info-20130605-dtcp-v1se-ip-rev-1-4-ed3.pdf>.
[DTCP-IP]数字传输许可管理员，“将DTCP映射到IP”，第1卷，补编E，信息版<http://www.dtcp.com/documents/dtcp/ info-20130605-dtcp-v1se-ip-rev-1-4-ed3.pdf>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[DTLA] Digital Transmission Licensing Administrator, "DTLA", <http://www.dtcp.com>.
[DTLA]数字传输许可管理员，“DTLA”<http://www.dtcp.com>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，DOI 10.17487/RFC5077，2008年1月<http://www.rfc-editor.org/info/rfc5077>.
[RFC6042] Keromytis, A., "Transport Layer Security (TLS) Authorization Using KeyNote", RFC 6042, DOI 10.17487/RFC6042, October 2010, <http://www.rfc-editor.org/info/rfc6042>.
[RFC6042]Keromytis，A.，“使用KeyNote的传输层安全（TLS）授权”，RFC 6042，DOI 10.17487/RFC604220010年10月<http://www.rfc-editor.org/info/rfc6042>.
This document specifies a TLS authorization data extension that allows TLS clients and servers to exchange DTCP certificates during a TLS handshake exchange. In cases where the supplemental data contains sensitive information, the double handshake technique described in [RFC4680] can be used to provide protection for the supplemental data information. The double handshake specified in [RFC4680] assumes that the client knows the context of the TLS session that is being set up and uses the authorization extensions as needed. Figure 3 illustrates a variation of the double handshake that addresses the case where the client may not have a priori knowledge that it will be communicating with a server capable of exchanging dtcp_authz_data (typical for https connections; see [RFC2818]). In Figure 3, the client's hello messages includes the client_authz and server_authz extensions. The server simply establishes an encrypted TLS session with the client in the first handshake by not indicating support for any authz extensions. The server initiates a second handshake by sending a HelloRequest. The second handshake will include the server's support for authz extensions, which will result in SupplementalData being exchanged.
本文档指定了TLS授权数据扩展，该扩展允许TLS客户端和服务器在TLS握手交换期间交换DTCP证书。在补充数据包含敏感信息的情况下，[RFC4680]中描述的双握手技术可用于为补充数据信息提供保护。[RFC4680]中指定的双重握手假设客户端知道正在设置的TLS会话的上下文，并根据需要使用授权扩展。图3说明了双握手的一种变体，它解决了客户端可能不知道它将与能够交换dtcp_authz_数据的服务器通信的情况（典型的https连接；请参见[RFC2818]）。在图3中，客户机的hello消息包括client_authz和server_authz扩展。服务器只是在第一次握手时与客户机建立加密的TLS会话，不表示支持任何authz扩展。服务器通过发送HelloRequest启动第二次握手。第二次握手将包括服务器对authz扩展的支持，这将导致交换补充数据。
Alternately, it is also possible to do a double handshake where the server sends the authorization extensions during both the first and the second handshake. Depending on the information received in the first handshake, the server can decide whether or not a second handshake is needed.
或者，也可以进行双重握手，其中服务器在第一次和第二次握手期间发送授权扩展。根据第一次握手中接收到的信息，服务器可以决定是否需要第二次握手。
Client Server
客户端服务器
ClientHello (w/ extensions) --------> |0
ServerHello (no authz extensions) |0
Certificate* |0
ServerKeyExchange* |0
CertificateRequest* |0
<-------- ServerHelloDone |0
Certificate* |0
ClientKeyExchange |0
CertificateVerify* |0
[ChangeCipherSpec] |0
Finished --------> |1
[ChangeCipherSpec] |0
<-------- Finished |1
<-------- HelloRequest |1
ClientHello (w/ extensions) --------> |1
ServerHello (w/ extensions) |1
SupplementalData* |1
Certificate* |1
ServerKeyExchange* |1
CertificateRequest* |1
<-------- ServerHelloDone |1
SupplementalData* |1
Certificate* |1
ClientKeyExchange |1
CertificateVerify* |1
[ChangeCipherSpec] |1
Finished --------> |2
[ChangeCipherSpec] |1
<-------- Finished |2
Application Data <-------> Application Data |2
ClientHello (w/ extensions) --------> |0
ServerHello (no authz extensions) |0
Certificate* |0
ServerKeyExchange* |0
CertificateRequest* |0
<-------- ServerHelloDone |0
Certificate* |0
ClientKeyExchange |0
CertificateVerify* |0
[ChangeCipherSpec] |0
Finished --------> |1
[ChangeCipherSpec] |0
<-------- Finished |1
<-------- HelloRequest |1
ClientHello (w/ extensions) --------> |1
ServerHello (w/ extensions) |1
SupplementalData* |1
Certificate* |1
ServerKeyExchange* |1
CertificateRequest* |1
<-------- ServerHelloDone |1
SupplementalData* |1
Certificate* |1
ClientKeyExchange |1
CertificateVerify* |1
[ChangeCipherSpec] |1
Finished --------> |2
[ChangeCipherSpec] |1
<-------- Finished |2
Application Data <-------> Application Data |2
* Indicates optional or situation-dependent messages.
* 指示可选或与情况相关的消息。
Figure 3: Double Handshake to Protect SupplementalData
图3：双重握手以保护补充数据
Acknowledgements
致谢
The author wishes to thank Mark Brown, Sean Turner, Sumanth Channabasappa, and the Chairs (EKR, Joe Saloway) and members of the TLS Working Group who provided feedback and comments on one or more revisions of this document.
作者要感谢Mark Brown、Sean Turner、Sumanth Channabasappa、主席（EKR、Joe Saloway）和TLS工作组成员，他们就本文件的一个或多个修订提供了反馈和意见。
This document derives its structure and much of its content from [RFC4680], [RFC5878], and [RFC6042].
本文档的结构和大部分内容源自[RFC4680]、[RFC5878]和[RFC6042]。
Author's Address
作者地址
D. Thakore Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, CO 80023 United States
D.Thakore有线电视实验室，公司地址：美国科罗拉多州路易斯维尔市煤溪圈858号，邮编：80023
Email: d.thakore@cablelabs.com
Email: d.thakore@cablelabs.com