Internet Engineering Task Force D. Thakore Internet-Draft CableLabs Intended status: Informational October 15, 2012 Expires: April 18, 2013 Transport Layer Security (TLS) Authorization Using DTCP Certificate draft-dthakore-tls-authz-00 Abstract 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. Status of this Memo 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 April 18, 2013. Copyright Notice Copyright (c) 2012 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. Thakore Expires April 18, 2013 [Page 1] Internet-Draft TLS Auth Using DTCP October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Overview of Supplemental Data handshake . . . . . . . . . . 3 2.2. Overview of authorization extensions . . . . . . . . . . . 4 2.3. Overview of Supplemental Data usage for authorization . . . 5 3. DTCP Authorization Data Format . . . . . . . . . . . . . . . . 5 3.1. DTCP Authorization Type . . . . . . . . . . . . . . . . . . 5 3.2. DTCP Authorization Data . . . . . . . . . . . . . . . . . . 6 3.3. Usage rules for clients to exchange DTCP Authorization data . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Usage rules for servers to exchange DTCP Authorization data . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Alert Messages . . . . . . . . . . . . . . . . . . . . . . 7 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Thakore Expires April 18, 2013 [Page 2] Internet-Draft TLS Auth Using DTCP October 2012 1. Introduction The Transport Layer Security (TLS) protocol (TLS1.0 [RFC2246], TLS1.1 [RFC4346], TLS1.2 [RFC5246]) is being used in an increasing variety of operational environments, the most common among which is its use in securing HTTP traffic ([RFC2818]). RFC 5878 [AUTHZ] 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, settop boxes and other multimedia devices contain Digital Transmission Licensing Administrator [DTLA] issued Digital Transmission Content Protection [DTCP] certificates. These certificates are used for link protection over various types of links like DTCP over IP [DTCP-IP] to securely transmit premium audio visual content between devices. These DTCP certificates can also be used to verify device functionality, other than link protection. This document describes the format and necessary identifiers to exchange DTCP certificates inside a TLS exchange. This credential exchange allows a client and/or server to perform certain actions or provide specific services. The DTCP certificate is cryptographically tied to the X.509 certificate being used during the TLS tunnel establishment by an EC-DSA [DTCP] signature. 1.1. Conventions 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]. 2. Overview 2.1. Overview of Supplemental Data handshake Figure 1 (Figure 1) illustrates the exchange of SupplementalData message during the TLS handshake as specified in RFC4680 [SuppData] and is repeated here for convenience. Thakore Expires April 18, 2013 [Page 3] Internet-Draft TLS Auth Using DTCP October 2012 TLS handshake message exchange with SupplementalData [SuppData] 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. Figure 1 2.2. Overview of authorization extensions RFC5878 [AUTHZ] defines two authorization extension types that are used in the ClientHello and ServerHello messages and are repeated below for convenience. enum { client_authz(7), server_authz(8), (65535) } ExtensionType; Thakore Expires April 18, 2013 [Page 4] Internet-Draft TLS Auth Using DTCP October 2012 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 [AUTHZ] 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. 2.3. Overview of Supplemental Data usage for authorization Section 3 of RFC5878 [AUTHZ] 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. enum { authz_data(16386), (65535) } SupplementalDataType; struct { SupplementalDataType supplemental_data_type; select(SupplementalDataType) { case authz_data: AuthorizationData; } } SupplementalData; This document defines a new authorization data format that is used in the authz_data message when sending DTCP Authorization data. 3. DTCP Authorization Data Format 3.1. DTCP Authorization Type The DTCP Authorization type definition in the TLS Authorization Data Formats registry is: dtcp_authorization(TBA); Thakore Expires April 18, 2013 [Page 5] Internet-Draft TLS Auth Using DTCP October 2012 3.2. DTCP Authorization Data 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: struct { opaque random_bytes[32]; } RandomNonce; struct { opaque ASN.1 Cert<1..2^24-1>; opaque DTCP Cert<1..2^24-1>; } DigitallySigned; struct { RandomNonce nonce; DigitallySigned certs; } dtcp_authz_data; The ASN.1 Certificate in the structure above MUST be the same as the sender's certificate that will be sent in the Certificate or ClientCertificate message. RandomNonce - consists of 32 bytes generated by a secure random number generator. The dtcp_authz_data message MUST always contain a RandomNonce. DigitallySigned - contains the tuple {ASN.1 Certificate, DTCP Certificate} followed by the digital signature generated using the private key associated with the DTCP certificate using an Elleptic Curve Digital Signature Algorithm (EC-DSA) as specified in [DTCP]. The sender SHALL include this in the dtcp_authz_data message only when it is sending its own DTCP Certificate. 3.3. Usage rules for clients to exchange DTCP Authorization data 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 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 Thakore Expires April 18, 2013 [Page 6] Internet-Draft TLS Auth Using DTCP October 2012 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. 3.4. Usage rules for servers to exchange DTCP Authorization data 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 Section 3.1 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. 3.5. Alert Messages This document reuses TLS Alert messages for any errors that arise during authorization processing, while preserving the AlertLevels as specified in [AUTHZ]. Additionally the following AlertDescription values SHALL be used to report errors in dlna_authorization processing: unsupported_extension: In dtcp_authorization processing a client uses this when it receives a server hello message that indicates support for only one of client_authz or server_authz extension. 4. Acknowledgements This document derives its structure and much of its content from [SuppData], [AUTHZ] and [RFC6042]. 5. IANA Considerations This document requires a new entry in the IANA-maintained TLS Authorization Data Formats registry, dtcp_authorization(TBA). This registry is defined in [AUTHZ]. Thakore Expires April 18, 2013 [Page 7] Internet-Draft TLS Auth Using DTCP October 2012 6. Security Considerations There are no security considerations beyond those discussed in [DTCP], [DTCP-IP] and [AUTHZ]. 7. References 7.1. Normative References [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 Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [SuppData] Santesson, S., "TLS Handshake Message for Supplemental Data", September 2006, . [AUTHZ] 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", . 7.2. Informative References [RFC2629] Rose, M., "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. Thakore Expires April 18, 2013 [Page 8] Internet-Draft TLS Auth Using DTCP October 2012 [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-09 (work in progress), March 2008. [DTLA] Digital Transmission Licensing Administrator, "DTLA", . [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000, . [RFC6042] Keromytis, A., "Transport Layer Security (TLS) Authorization Using KeyNote", RFC 6042, October 2010, . Appendix A. Additional Stuff This becomes an Appendix. Author's Address Darshak Thakore Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, CO 80023 USA Email: d.thakore@cablelabs.com Thakore Expires April 18, 2013 [Page 9]