Transport Layer Security (TLS) Authorization Using DTCP Certificate

Transport Layer Security (TLS) Authorization Using DTCP Certificate Cable Television Laboratories, Inc.

858 Coal Creek Circle Louisville CO 80023 USA d.thakore@cablelabs.com

Security Transport Layer Security TLS SupplementalData DTCP This document specifies the use of DTCP certificate as an authorization extension in the Transport Layer Security Handshake Protocol, according to guidelines in RFC 5878. Extensions carried in the client and server Hello messages confirm that both parties support the desired authorization data types. Then if supported by both the client and server, DTCP certificates are exchanged in the supplemental data handshake TLS handshake message as specified in RFC4680.

The Transport Layer Security (TLS) protocol (TLS1.0, TLS1.1, TLS1.2) is being used in an increasing variety of operational environments, the most common among which is its use in securing HTTP traffic (). RFC 5878 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 can allow the client and server to determine the type of protected data to exchange based on the authorization information received in the extensions. A number of consumer electronics devices such as TV's, tablets, game consoles, set-top boxes and other multimedia devices contain Digital Transmission Licensing Administrator issued Digital Transmission Content Protection certificates. These certificates are used for link protection over various types of links like DTCP over IP to securely transmit premium audio-visual content between devices. These DTCP certificates can also be used to verify device functionality, besides being used to protect audio-visual content. This document describes the format and necessary identifiers to exchange DTCP certificates within the supplemental data message (see ) while negotiating a TLS exchange. The DTCP certificates are then used for authorization independent of its use for content protection and the corresponding DTCP Authentication and Key Exchange (AKE) protocol. This authorization allows a client and/or server 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 can be cryptographically tied to the X.509 certificate being used during the TLS tunnel establishment by an EC-DSA signature.

As mentioned above, the primary use of DTCP Certificates in consumer electronics devices (eg. TV's) is for secure transmission of audio-visual content. The Authentication and Key Exchange (AKE) protocol defined in 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 devices also have additional functionality (eg. HTML5 User Agents, web enabled apps) that is distinct from its capability to transmit and play audio-visual content. The mechanism outlined in this document allows a device to authenticate and authorize itself using its DTCP Certificate when accessing services over the internet (eg. web app on a TV accessing some service over HTTPS). This allows reusing an already provisioned credential for different services that are delivered over TLS.

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 RFC 2119.

DTCP certificates are issued by for compliant devices and come in three general variations (see Section 4.2.3.1 of the DTCP Specification) Typically issued to devices with limited computation resources. This is the most commonly issued certificate format. Format 1 certificates include a unique Device ID and device EC-DSA public/private key pair generated by the DTLA. (See Section 4.3 of DTCP) This is issued to devices that possess additional functions (eg. 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 the DTCP specification. Format 2 certificates also include a unique Device ID and device EC-DSA public/private key pair generated by the DTLA. (See Section 4.3 of DTCP) The mechanism specified in this document allows only Format 1 and Format 2 type 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.

Figure 1 illustrates the exchange of SupplementalData message during the TLS handshake as specified in RFC4680 and is repeated here for convenience.

TLS handshake message exchange with SupplementalData 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. ]]>

RFC5878 defines two authorization extension types that are used in the ClientHello and ServerHello messages and are repeated below for convenience.

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 for registering authorization data formats. This document defines a new authorization data type that is used in both the client_authz and server_authz extensions and allows the client and server to exchange DTCP certificates in the SupplementalData message.

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. The syntax is repeated here for convenience.

This document defines a new authorization data format that is used in the authz_data message when sending DTCP Authorization data.

The DTCP Authorization type definition in the TLS Authorization Data Formats registry is:

The DTCP Authorization data SHALL be sent in the authz_data message when the authorization data type is dtcp_authorization. The syntax of the authorization data is:

; [[opaque ASN.1Cert<1..2^24-1>]]; opaque signature<1..2^16-1>; } DigitallySigned; struct { RandomNonce nonce; [[DigitallySigned certs]]; } dtcp_authz_data; ]]> RandomNonce - consists of 32 bytes generated by a secure random number generator. The dtcp_authz_data message MUST always contain a RandomNonce to avoid replay attacks. If the ASN.1 Certificate is being sent in the structure above, it MUST be the same as the sender's certificate that will be sent in the Certificate or ClientCertificate message. DigitallySigned - contains the DTCP Certificate and the optional ASN.1 Certificate. This is then followed by a digital signature covering the DTCP Certificate and the ASN.1 certificate if it is present. The signature is generated using the private key associated with the DTCP certificate using an Elliptic Curve Digital Signature Algorithm (EC-DSA) as specified in . This signature provides proof of the possession of the private key by the sender. A sender sending its own DTCP Certificate MUST populate the certs field.

A client MUST include 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 MUST use the authorization data type specified in in the extension_data field to specify the format of the authorization 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 MUST use the same RandomNonce that it received in the server's dtcp_authz_data message. A client MAY include its ASN.1 Certificate in the certs field to cryptographically tie its dtcp_authz_data with the TLS session being established.

A server MUST respond 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. Additionally the server MUST use the authorization data type specified in in the extension_data field to specify the format of the dtcp_authorization data. 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 SHALL NOT include support for dtcp_authorization data in its hello message. A server MAY include its ASN.1 Certificate in the certs field to cryptographically tie its dtcp_authz_data with the TLS session being established.

This document reuses TLS Alert messages for any errors that arise during authorization processing, while preserving the AlertLevels as specified in . Additionally the following AlertDescription values SHALL be used to report errors in dtcp_authorization processing:

This document derives its structure and much of its content from , and .

This document requires a new entry in the IANA-maintained TLS Authorization Data Formats registry, dtcp_authorization(TBA). This registry is defined in .

In cases where the SupplementalData information is sensitive, the double handshake technique described in can be used to provide protection for the SupplementalData information. The double handshake specified in assumes that the client knows the context of the TLS session that is being set up and uses the authorization extensions as needed. 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 usages based on ). In Figure 2 below client's Hello messages always include support for the client_authz and server_authz extensions. The server simply establishes an encrypted TLS tunnel 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 server's support for authz extensions which will result in SupplementalData being exchanged. The double handshake mechanism is vulnerable to the TLS MITM Renegotiation exploit as explained in . In order to address this vulnerability, clients and servers MUST use the secure_renegotiation extension as specified in when performing a double handshake.

&RFC2119; The TLS Protocol Version 1.0 Certicom

tdierks@certicom.com

Certicom

callen@certicom.com

The TLS Protocol Version 1.1 The TLS Protocol Version 1.2 Transport Layer Security (TLS) Renegotiation Indication Extension TLS Handshake Message for Supplemental Data Microsoft Transport Layer Security (TLS) Authorization Extensions RedPhone Security Vigil Security Digital Transmission Content Protection Digital Transmission Licensing Administrator DTCP Volume 1 Supplement E Digital Transmission Licensing Administrator &RFC2629; &RFC3552; &RFC5226; DTLA Digital Transmission Licensing Administrator HTTP over TLS RTFM, Inc. Transport Layer Security (TLS) Authorization Using KeyNote Columbia University

This becomes an Appendix.