Transport Layer Security (TLS)
Authorization Using Digital Transmission Content Protection (DTCP) CertificatesCable Television Laboratories, Inc.858 Coal Creek CircleLouisvilleCO80023United Statesd.thakore@cablelabs.com
Security
Transport Layer SecurityTLSSupplementalDataDTCP
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).
The Transport Layer Security (TLS) protocol (see TLS 1.0,
TLS 1.1, and TLS1 .2) is being used
in an ever increasing variety of operational environments, the most
common among which is its use
in securing HTTP traffic .
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.
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 certificates issued by .
These DTCP certificates enable secure transmission of premium audiovisual
content between devices over various types of links
(e.g., DTCP over IP).
These DTCP certificates can also be used to verify device
functionality (e.g., supported device features).
This document describes the format and necessary identifiers to
exchange DTCP certificates within the
supplemental data message (see ) 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)
signature.
DTCP-enabled consumer electronics devices (e.g., televisions, game consoles) use DTCP
certificates for secure transmission of audiovisual content. The 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 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.
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 .
DTCP certificates issued by to
DTLA-compliant devices come in three general variations
(see Section 4.2.3.1 of ):
Restricted Authentication device certificate format (Format 0): Typically issued to
devices with limited computation resources.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 ). 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 .
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 ).
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.
illustrates the exchange of the
SupplementalData message during the TLS handshake as specified in
(repeated here for convenience):
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.
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.
Section 3 of 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.
The DTCP Authorization type definition in the TLS Authorization Data
Formats registry is:
The DTCP Authorization Data is used when the AuthzDataFormat
type is dtcp_authorization. The syntax of the authorization data is:
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.
DTCPCert is the sender's DTCP certificate. See Section 4.2.3.1 of the DTCP Specification
.
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 .
The DTCPCert and ASN.1Cert are variable-length vectors as specified in Section 4.3 of
. 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.
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 . 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 , 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).
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 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
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).
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. Additionally, the server includes the
AuthzDataFormat type specified in 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.
Based on the usage rules in the sections above,
provides one possible
TLS message exchange where the client sends its DTCP certificate to the server
within the dtcp_authz_data message.
This document reuses TLS Alert messages for any errors that arise during
authorization processing and reuses the AlertLevels as
specified in . Additionally, the following
AlertDescription values are used to report errors in dtcp_authorization processing:
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.
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.
This document includes an entry registered in the IANA-maintained
"TLS Authorization Data Formats" registry for dtcp_authorization(66).
This registry is defined in and defines two ranges:
one is IETF Review, and the other is Specification Required. The value for
dtcp_authorization should be assigned via
Specification Required. The extension defined in this document is compatible
with Data Transport Layer Security (DTLS) , and the registry assignment has been
marked "Y" for DTLS-OK.
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 .
In order to address this vulnerability, clients and servers MUST use the
secure_renegotiation extension as specified in
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.
It should be noted that for the double handshake to succeed, any extension
(e.g., TLS Session Ticket ) that results
in the TLS handshake sequence being modified may result in failure to
exchange SupplementalData.
Additionally, the security considerations specified in
and 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
and for more information regarding DTCP
certificates, their usage, and associated security considerations.
Digital Transmission Content Protection SpecificationDigital Transmission Licensing AdministratorMapping DTCP to IPDigital Transmission Licensing AdministratorDTLADigital Transmission Licensing Administrator
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 can
be used to provide protection for the supplemental data 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 connections; see ).
In , 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.
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.
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.This document derives its structure and much of its content from
, , and .