[要約] RFC 7562は、デジタルトランスミッションコンテンツ保護（DTCP）証明書を使用したTransport Layer Security (TLS) 認証に関するものです。この文書の目的は、DTCP証明書を用いてTLSセッションの相互認証を行う方法を定義することにあります。これは、特にデジタルコンテンツの保護と配信に関連するアプリケーションで利用されます。関連するRFCには、TLSを定義するRFC 5246や、他の認証方法を定義するRFCが含まれますが、RFC 7562は特にDTCP証明書を用いた認証に焦点を当てています。
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ハンドシェイクメッセージで交換されます。この承認データタイプの拡張は、Digital Transmission Licensing Administrator（DTLA）によって発行されたDTCP証明書を含むデバイスをサポートしています。 。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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）プロトコルでの使用とは無関係に使用されます。この通信により、クライアント、サーバー、またはその両方が特定のアクションを実行したり、特定のサービスを提供したりできます。クライアント/サーバーによる承認決定の実際のセマンティクスは、このドキュメントの範囲を超えています。 X.509証明書ではないDTCP証明書は、楕円曲線デジタル署名アルゴリズム（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- 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対応の家庭用電化製品（テレビ、ゲームコンソールなど）は、DTCP証明書を使用して、視聴覚コンテンツを安全に送信します。 [DTCP]で定義されたAKEプロトコルは、DTCP証明書の交換に使用され、DTCP証明書の情報に基づいてデバイスを識別および認証できるようにします。ただし、これらのDTCP対応デバイスは、オーディオビジュアルコンテンツを送信および再生する機能とは異なる追加機能（HTML5ユーザーエージェントまたはWeb対応アプリケーションなど）を提供します。このドキュメントで概説されているメカニズムにより、DTCP対応の家電デバイスは、インターネット経由でサービスにアクセスするときに、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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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証明書には、3つの一般的なバリエーションがあります（[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によって生成された一意のDeviceIDとデバイス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の証明書には、一意のDeviceIDと、DTLAによって生成されたデバイス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.
このドキュメントで指定されているメカニズムでは、証明書に関連付けられたEC-DSA秘密キーを使用する必要があるため、補足データメッセージで交換できるのはフォーマット1および2のDTCP証明書のみです。
Figure 1 illustrates the exchange of the SupplementalData message during the TLS handshake as specified in [RFC4680] (repeated here for convenience):
図1は、[RFC4680]で指定されているTLSハンドシェイク中のSupplementalDataメッセージの交換を示しています（便宜上、ここで繰り返します）。
Client Server
クライアントサーバー
ClientHello (with extensions) -------->
ServerHello(with extensions)
SupplementalData*
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
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：SupplementalDataを使用した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メッセージで使用される2つの認証拡張タイプを定義しており、便宜上以下に繰り返されています。
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, 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.
クライアントは、ClientHelloメッセージのclient_authzおよびserver_authz拡張を使用して、SupplementalDataメッセージでクライアント認証データを送信し、サーバー認証データを受信することをそれぞれ示します。サーバーは、ServerHelloメッセージで同様の方法で拡張機能を使用します。 [RFC5878]は、承認データ形式を登録するためにIANAによって維持されるレジストリも確立します。このドキュメントでは、client_authz拡張とserver_authz拡張の両方に新しい認証データタイプを定義し、クライアントとサーバーがSupplementalDataメッセージで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は、client_authzおよび/またはserver_authzタイプでネゴシエートされるauthz_dataメッセージを伝送するときの補足データメッセージの構文を指定します。このドキュメントでは、DTCP認証データを送信するときにauthz_dataメッセージで使用される新しい認証データ形式を定義しています。
The DTCP Authorization type definition in the TLS Authorization Data Formats registry is:
TLS Authorization Data FormatsレジストリのDTCP認可タイプ定義は次のとおりです。
dtcp_authorization(66);
dtcp_authorization（66）;
The DTCP Authorization Data is used when the AuthzDataFormat type is dtcp_authorization. The syntax of the authorization data is:
DTCP許可データは、AuthzDataFormatタイプがdtcp_authorizationの場合に使用されます。承認データの構文は次のとおりです。
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;
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 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.
RandomNonceはサーバーによって生成され、高品質で安全な乱数ジェネレーターによって生成された32バイトで構成されます。クライアントは常に、サーバーが生成したRandomNonceをdtcp_authz_data構造体で送り返します。 RandomNonceは、サーバーがリプレイ攻撃を検出するのに役立ちます。クライアントは、dtcp_authz_data構造体のASN.1証明書をTLSハンドシェイクの証明書メッセージで受信した証明書に関連付けることにより、リプレイアタックを検出できるため、クライアントに個別のナンスは必要ありません。
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で定義された証明書構造を使用して、証明書またはClientCertificateメッセージで送信されます。
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.
[RFC5246]のセクション4.3で指定されているように、DTCPCertとASN.1Certは可変長のベクトルです。したがって、実際の長さは、バイトストリーム内のベクトルの内容に先行します。 ASN.1Certが送信されない場合、ASN.1Cert_lengthはゼロでなければなりません。
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_dataには、RandomNonce、DTCP証明書、およびオプションのASN.1証明書が含まれています。次に、RandomNonce、DTCP証明書、およびASN.1証明書（存在する場合）をカバーするデジタル署名が続きます。署名は、DTCP証明書に関連付けられた秘密鍵を使用し、[DTCP]のセクション4.4で指定されている署名アルゴリズムとハッシュアルゴリズムを使用して生成されます。この署名は、送信者による秘密鍵の所有の証拠を提供します。独自のDTCP証明書を送信する送信者は、このフィールドに入力する必要があります。署名フィールドの長さは、[DTCP]のセクション4.4で指定されている署名アルゴリズムとハッシュアルゴリズムによって決定されるため、dtcp_authz_data構造体で明示的にエンコードされません（たとえば、長さは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_authorizationデータをサーバーと交換したいという希望を示すときに、client_authzとserver_authzの両方の拡張を拡張クライアントのhelloメッセージに含めます。さらに、クライアントは、セクション3.1で指定されたAuthzDataFormatタイプをextension_dataフィールドに含めて、許可データのフォーマットを指定します。
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 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_dataを送信する前に、サーバーのdtcp_authz_dataを受信します。独自のdtcp_authz_dataメッセージを送信するとき、クライアントはサーバーのdtcp_authz_dataメッセージで受信したものと同じRandomNonceを含めます。クライアントは、DTCP証明書をdtcp_authz_dataメッセージに含める必要があります。クライアントは、dtcp_authz_dataのASN.1CertフィールドにASN.1証明書（ClientCertificateメッセージ内の証明書）を含めて、TLSセッションの確立に使用されるASN.1Cert（つまり、ClientCertificateメッセージで送信される）とdtcp_authz_dataを暗号で結び付けることができます（MAY）。 ）。
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_authorizationデータをクライアントと交換したいという希望を示すと、拡張サーバーのhelloメッセージのclient_authzとserver_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.
さらに、サーバーは、セクション3.1で指定されたAuthzDataFormatタイプをextension_dataフィールドに含めて、dtcp_authorizationデータのフォーマットを指定します。クライアントは、TLSハンドシェイク中にASN.1証明書を含む場合と含まない場合があります。ただし、サーバーはSupplementalDataメッセージの送信時にそのことを認識しません。したがって、サーバーはdtcp_authz_dataメッセージにRandomNonceを生成して入力する必要があります。クライアントのhelloメッセージにdtcp_authorizationタイプのclient_authz拡張とserver_authz拡張の両方が含まれていない場合、サーバーはそのhelloメッセージにdtcp_authorizationデータのサポートを含めてはなりません（MUST NOT）。サーバーは、dtcp_authz_dataメッセージにDTCP証明書を含めることができます。サーバーがDTCP証明書を送信しない場合は、dtcp_authz_dataメッセージでRandomNonceのみを送信します。サーバーにDTCP証明書が含まれている場合は、サーバーの証明書（TLS証明書メッセージで送信されたもの）をcertsフィールドに含めて、確立されているTLSセッションで使用されるASN.1証明書とdtcp_authz_dataを暗号で結び付ける必要があります。これは、クライアントがリプレイ攻撃を検出するのにも役立ちます。
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は、クライアントがDTCP証明書をdtcp_authz_dataメッセージ内のサーバーに送信する、可能な1つのTLSメッセージ交換を提供します。
Client Server
クライアントサーバー
ClientHello (with extensions) -------->
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
N1 Indicates a Random nonce generated by server
N1はサーバーによって生成されたランダムなナンスを示します
D1 Contains dtcp_authz_data populated with the following {(N1, DTCP Cert, Client X.509 Cert) Signature over all elements}
D1には、次の{（N1、DTCP Cert、Client X.509 Cert）Signature over all elements}が入力されたdtcp_authz_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 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 Alertメッセージを再利用し、[RFC5878]で指定されているようにAlertLevelsを再利用します。さらに、次のAlertDescription値は、dtcp_authorization処理のエラーを報告するために使用されます。
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: 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.
unsupported_extension：dtcp_authorizationの処理中に、クライアントは、client_authzまたはserver_authzのどちらか一方のみでdtcp_authorizationのサポートが含まれているサーバーhelloメッセージを受信すると、これを使用します。このメッセージは常に致命的です。注：dtcp_authorization拡張機能を完全に省略したり、client_authzおよびserver_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_authorizationの処理中に、クライアントまたはサーバーは、dtcp_authorizationデータで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.
このドキュメントには、danaが管理する「TLS Authorization Data Formats」レジストリに登録されているdtcp_authorization（66）のエントリが含まれています。このレジストリは[RFC5878]で定義されており、2つの範囲を定義しています。1つはIETFレビュー、もう1つは仕様が必要です。 dtcp_authorizationの値は、[RFC5226] Specification Requiredを介して割り当てる必要があります。このドキュメントで定義されている拡張機能はデータトランスポート層セキュリティ（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_authorizationデータには、関連するデバイスを識別するDTCP証明書が含まれています。 TLSセッションを確立するために使用されるX.509証明書をdtcp_authorizationデータに含めることで、アプリケーションはそれらを暗号で結び付けることができます。ただし、TLSクライアントはX.509証明書を使用する必要はありません（所有していない場合もあります）。この場合、dtcp_authorizationデータ交換は中間者（MITM）攻撃を受ける傾向があります。このような状況では、TLSサーバーは、DTCP証明書に依存するアプリケーション機能へのアクセスを拒否するか、ダブルハンドシェイクを使用する必要があります。 [RFC5746]で説明されているように、ダブルハンドシェイクメカニズムはTLS MITM再ネゴシエーションの脆弱性に対しても脆弱です。この脆弱性に対処するために、クライアントとサーバーは、dtcp_authorizationデータを交換するときに、[RFC5746]で指定されているsecure_renegotiation拡張を使用する必要があります。さらに、再ネゴシエーションは、Triple Handshakeエクスプロイトに対しても脆弱です。これを軽減するために、サーバーは、再ネゴシエーション時に、最初のハンドシェイクで使用されたものと同じ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]など）により、SupplementalDataの交換が失敗する可能性があることに注意してください。
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_authorizationデータは、他の補足データまたは他のいくつかの許可データとともに運ばれる場合があり、その情報には追加の保護が必要になる場合があります。最後に、実装者は、DTCP証明書、その使用法、および関連するセキュリティの考慮事項の詳細について、[DTCP]および[DTCP-IP]も参照する必要があります。
[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、「The TLS Protocol Version 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、「The Transport Layer Security（TLS）Protocol Version 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、「The Transport Layer Security（TLS）Protocol Version 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、「Transport Layer Security（TLS）Renegotiation Indication Extension」、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、「Transport Layer Security（TLS）Authorization Extensions」、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、「Datagram Transport Layer Security Version 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] 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-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] 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>。
[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、「RFCで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] Digital Transmission Licensing Administrator、「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。、「HTTP Over TLS」、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、「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>。
[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。、「Transport Layer Security（TLS）Authorization Using KeyNote」、RFC 6042、DOI 10.17487 / RFC6042、2010年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ハンドシェイクの交換中にDTCP証明書を交換できるようにするTLS承認データ拡張を指定します。補足データに機密情報が含まれている場合、[RFC4680]で説明されているダブルハンドシェイク技術を使用して、補足データ情報を保護できます。 [RFC4680]で指定されているダブルハンドシェイクは、クライアントがセットアップされているTLSセッションのコンテキストを知っており、必要に応じて認証拡張機能を使用することを前提としています。図3は、クライアントがdtcp_authz_dataを交換できるサーバーと通信することをアプリオリに認識していない場合に対処するダブルハンドシェイクのバリエーションを示しています（https接続の場合は一般的。[RFC2818]を参照）。図3では、クライアントのhelloメッセージにclient_authzおよびserver_authz拡張が含まれています。サーバーは、authz拡張のサポートを示さないことにより、最初のハンドシェイクでクライアントとの暗号化されたTLSセッションを確立するだけです。サーバーは、HelloRequestを送信して2番目のハンドシェイクを開始します。 2番目のハンドシェイクには、authz拡張に対するサーバーのサポートが含まれます。これにより、SupplementalDataが交換されます。
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.
または、サーバーが最初のハンドシェイクと2番目のハンドシェイクの両方で認証拡張機能を送信するダブルハンドシェイクを実行することもできます。最初のハンドシェイクで受信した情報に応じて、サーバーは2番目のハンドシェイクが必要かどうかを判断できます。
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
* Indicates optional or situation-dependent messages.
* オプションまたは状況依存のメッセージを示します。
Figure 3: Double Handshake to Protect SupplementalData
図3：SupplementalDataを保護するためのダブルハンドシェイク
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.
著者は、マークブラウン、ショーンターナー、スマンスチャナバサッパ、議長（EKR、ジョーサロウェイ）、およびこのドキュメントの1つ以上の改訂についてフィードバックとコメントを提供した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 Cable Television Laboratories、Inc. 858 Coal Creek Circle Louisville、CO 80023アメリカ合衆国
Email: d.thakore@cablelabs.com