| Transport Layer Security | D. Thakore |
| Internet-Draft | CableLabs |
| Intended status: Informational | July 13, 2013 |
| Expires: January 14, 2014 |
Transport Layer Security (TLS) Authorization Using DTCP Certificate
draft-dthakore-tls-authz-04
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 [RFC5878]. 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 RFC4680. This authorization data type extension is in support of devices containing DTCP certificates, issued by the Digital Transmission Licensing Administrator [DTLA].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
The Transport Layer Security (TLS) protocol (TLS1.0 [RFC2246], TLS1.1 [RFC4346], 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.
A substantial number of deployed consumer electronics devices such as televisions, tablets, game consoles, set-top boxes and other multimedia devices contain [DTLA] issued Digital Transmission Content Protection [DTCP] certificates. These DTCP certificates enable secure transmission of premium audio-visual 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)
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 or 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 EC-DSA [DTCP] signature.
DTCP-enabled consumer electronics devices (eg. televisions, game consoles) use DTCP certificates for secure transmission of audio-visual content. The Authentication and Key Exchange (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 audio-visual 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 re-use 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 RFC 2119 [RFC2119].
DTCP certificates issued by [DTLA] to DTLA-compliant devices come in three general variations (see [DTCP], Section 4.2.3.1)
The mechanism specified in this document allows only Format 1 and Format 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.
Figure 1 illustrates the exchange of SupplementalData message during the TLS handshake as specified in [RFC4680] and is repeated here for convenience:
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.
TLS handshake message exchange with Supplemental Data
Figure 1
enum {
client_authz(7), server_authz(8), (65535)
} ExtensionType;
[RFC5878] defines two authorization extension types that are used in the ClientHello and ServerHello messages and are repeated below for convenience: [RFC5878] also establishes a registry that is maintained by IANA for registering 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 [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.
The DTCP Authorization type definition in the TLS Authorization Data Formats registry is:
dtcp_authorization(TBA);
Note to RFC Editor: Please populate the number assigned by IANA
The DTCP Authorization data is used when the AuthzDataFormat type is dtcp_authorization. The syntax of the authorization data is:
struct {
opaque random_bytes[32];
} RandomNonce;
digitally-signed struct {
RandomNonce nonce;
uint16 DTCPCert_length;
opaque DTCPCert<1..2^24-1>;
uint16 ASN.1Cert_length;
opaque ASN.1Cert<0..2^24-1>;
} DigitallySignedData;
struct {
DigitallySignedData certs;
opaque signature[40];
} dtcp_authz_data;
RandomNonce is generated by the server and consists of 32 bytes generated by a high quality secure random number generator. The RandomNonce helps detect replay attacks.
DTCPCert is the sender's DTCP certificate, see Section 4.2.3.1 of the DTCP Specification [DTCP]
ASN.1Cert is the sender's certificate used to establish the TLS session, i.e., sent in the Certificate or ClientCertificate message using the Certificate structure defined in Section 7.4.2 of [RFC5246].
If the ASN.1Cert is not being sent, the ASN.1Cert_length MUST be zero.
DigitallySignedData - contains the RandomNonce, DTCP Certificate and the optional ASN.1 Certificate. This is then followed by the digital signature covering the RandomNonce, 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 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 the certs field.
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.
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 include its DTCP Certificate in the dtcp_authz_data message. If the client wants to cryptographically tie its dtcp_authz_data with the TLS session, then the client includes the ASN.1 Certificate used to establish the TLS session (certificate in the ClientCertificate message) in the ASN.1Cert field in dtcp_authz_data.
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 Section 3.1 in the extension_data field to specify the format of the dtcp_authorization data. A server always generates and populates 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 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 TLS session being established.
Based on the usage rules in the sections above, Figure 2 [dtcp_sd_exchange] below provides one possible TLS message exchange where the client sends its DTCP Certificate to the server within the dtcp_authz_data message.
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 Random nonce generated by server
D1 Contains dtcp_authz_data populated with the following
{(N1, DTCP Cert, Client X.509 Cert) Signature over all elements}
* 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.
Figure 2
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:
unsupported_extension:
During processing of dtcp_authorization, a client uses this
when it receives a server hello message that does not indicate
support for both client_authz and server_authz extension.
This message is always fatal.
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.
This document proposes a new entry to be registered in the IANA-maintained TLS Authorization Data Formats registry for dtcp_authorization(TBA). 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.
Note to RFC Editor: Please populate the number assigned by IANA in TBA above.
This document specifies a TLS authorization data extension that allows TLS clients and servers to exchange DTCP certificates during a TLS handshake exchange. The dtcp_authorizaton data as specified in this document carries the DTCP Certificate that identified the associated device. Given that it is anticipated by DTCP to be shared in the open (e.g., similar to its usage in AKE), this document does not add any additional security threats (e.g., confidentiality). Further its integrity is ensured by the TLS protocol. Hence 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.
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 [sd_double_exchange], 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 server's support for authz extensions which will result in SupplementalData being exchanged.
This double handshake mechanism is 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 performing a double handshake.
It should be noted that for 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.
Double Handshake to protect Supplemental Data
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
Finally, implementers should also reference [DTCP] and [DTCP-IP] for more information regarding DTCP certificates, their usage and associated security considerations.
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 [RFC4680], [RFC5878] and [RFC6042].
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2246] | Dierks, T. and C. Allen, "The TLS Protocol Version 1.0 ", RFC 2246, January 1999. |
| [RFC4346] | Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1 ", RFC 4346, April 2006. |
| [RFC5246] | Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2 ", RFC 5246, August 2008. |
| [RFC5746] | Rescorla, E., Ray, M., Dispensa, S. and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension ", RFC 5746, February 2010. |
| [RFC4680] | Santesson, S., "TLS Handshake Message for Supplemental Data", September 2006. |
| [RFC5878] | Brown, M. and R. Housley, "Transport Layer Security (TLS) Authorization Extensions ", RFC 5878, May 2010. |
| [DTCP] | Digital Transmission Licensing Administrator, "Digital Transmission Content Protection", . |
| [DTCP-IP] | Digital Transmission Licensing Administrator, "DTCP Volume 1 Supplement E", . |
| [RFC2629] | Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. |
| [RFC3552] | Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. |
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. |
| [DTLA] | Digital Transmission Licensing Administrator, "DTLA", . |
| [RFC2818] | Rescorla, E., "HTTP over TLS", RFC 2818, May 2000. |
| [RFC5077] | Salowey, J. and P. Eronen, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008. |
| [RFC6042] | Keromytis, A., "Transport Layer Security (TLS) Authorization Using KeyNote ", RFC 6042, October 2010. |
This becomes an Appendix.