TLS Working Group P. Urien Internet Draft Telecom ParisTech Intended status: Informational June, 2009 Expires: December, 2009 TLS Key Generation draft-urien-tls-keygen-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract The TLS protocol is widely deployed and used over the Internet. Client and server nodes compute a set of keys called the keys-block, according to a pseudo random function (PRF). This draft proposes a keying infrastructure based on the TLS protocol. It suggests defining an additional Key Distribution Function (KDF) in order to deliver a set of cryptographic keys. In a peer to peer mode keys are directly produced as inputs of the KDF functions. For centralized architectures they are delivered through containers, secured with keys derived from the KDF function. Conventions used in this document 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. Urien Expires December 2009 [Page 1] TLS Key Generation June 2009 Table of Contents Abstract........................................................... 1 Conventions used in this document.................................. 1 1 Introduction..................................................... 3 2 Basic Exchanges.................................................. 4 2.1 Full handshake.............................................. 4 2.2 Abbreviated Handshake....................................... 4 2.3 AVP Container............................................... 5 2.4 Data encryption and integrity............................... 6 3 Key Derivation Functions (KDF)................................... 6 3.1 TLS PRF function............................................ 6 3.2 HMAC KDF.................................................... 7 3.3 NIST compatible KDF......................................... 7 3.3.1 PRF functions ........................................ 7 3.3.2 KDF functions ........................................ 8 4 Use cases........................................................ 8 4.1 Hierarchical Model for Content/Service Protection........... 8 5 IANA Considerations.............................................. 9 6 Security Considerations.......................................... 9 7 References....................................................... 9 7.1 Normative References........................................ 9 7.2 Informative References...................................... 9 Authors' Addresses................................................ 10 Full Copyright Statement.......................................... 10 Urien Expires December 2009 [Page 2] TLS Key Generation June 2009 1 Introduction The TLS protocol [TLS 1.0] [TLS 1.1] [TLS 1.2] is widely deployed and used over the Internet. Client and server nodes compute a set of keys called the keys-block, according to a pseudo random function (PRF) and two random values client-random and server-random, respectively produced by these entities. There is an increasing need in the Internet to set up efficient keys distribution infrastructures, able to generate and to deliver cryptographic material required by multiple applications, as illustrated by section 6. This draft proposes a keying infrastructure based on the TLS protocol. Full or abbreviated handshakes are performed according to the TLS specification. We suggest defining additional Key Distribution Functions (KDFi) in order to deliver a set of cryptographic keys according to the relation, Keys = KDFi(master-secret, client-random, server-random, other- information). Particular KDF MAY be negotiated by the client according to specific TLS extensions [TLS-EXT] or dedicated cipher suites. In a peer to peer mode keys are directly produced as inputs of the KDF functions, this mode of operation is for example quite suitable for distributed architecture, in which networks nodes are typically equipped with X509 certificates and RSA keys. On the other hand, centralized architectures deliver keys from a unique server to remotely managed nodes. In this later case cryptographic keys MUST be delivered through application data, according to cipher suites negotiated during the TLS handshake, but working with keys computed with the KDF function. Urien Expires December 2009 [Page 3] TLS Key Generation June 2009 2 Basic Exchanges 2.1 Full handshake The full handshake mode is a four ways handshake that performs one way or mutual authentication between client and server entities. A master secret is computed by both parties, and each of them proves its knowledge of such value by Finished messages, which are protected according to cryptographic algorithms negotiated between client and server, and identified by the CipherSuite parameter. Client Server (A) ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- (B) ServerHelloDone (C) Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- (D) Finished <-------- (E) *AVP Container *Optional Figure 1. Full handshake In the peer to peer mode, keys are computed according to the selected KDF procedure and its associated information: Keys = KDF(master-secret, client-random, server-random, other- information) In centralized architecture, an AVP attribute conveys a set of keys, protected according to cryptographic algorithms pointed by the CipherSuite parameter, but dealing with keys produced by the KDF function. 2.2 Abbreviated Handshake The abbreviated handshake mode is a three ways handshake that performs a mutual authentication between client and server entities, which share the knowledge of a previous master secret. Each of them proves this assumption by Finished messages, which are protected Urien Expires December 2009 [Page 4] TLS Key Generation June 2009 according to cryptographic algorithms negotiated between client and server, and identified by the CipherSuite parameter. Client Server (A) ClientHello --------> ServerHello [ChangeCipherSpec] <-------- (B) Finished (C) [ChangeCipherSpec] Finished --------> <------- (D) *AVPs Container *Optional Figure 2. Abbreviated handshake In the peer to peer mode, keys are computing according to the relation: Keys = KDF(master-secret, client-random, server-random, other- information) In centralized architecture, an AVP attributes conveys a set of keys, protected according to cryptographic algorithms pointed by the CipherSuite parameter, but using keys produced by the KDF function. 2.3 AVP Container 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M r r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Length + Data | | | Optional padding bytes + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. AVP Container The AVP format is imported from the [TTLS] document. The AVP Code is four octets and, combined with the Vendor-ID field if present, identifies the attribute (i.e. the container structure) uniquely. Urien Expires December 2009 [Page 5] TLS Key Generation June 2009 The 'V' (Vendor-Specific) bit indicates whether the optional Vendor- ID field is present. The 'M' (Mandatory) bit indicates whether support of the AVP is required. If this bit is set to 0, this indicates that the AVP may be safely ignored if the receiving party does not understand or support it. The 'r' (reserved) bits are unused and MUST be set to 0 by the sender and MUST be ignored by the receiver. The AVP Length field is three octets, and indicates the length of this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID (if present) and Data. Data Length is two octets and indicates the size of data without padding bytes. According to selected cryptographic algorithms padding byte MAY be added in order to get a length compatible with ciphered blocs. 2.4 Data encryption and integrity Cryptographic keys (Kc and Ki), used by encryption algorithms (Kc) and MAC procedures (Ki), are derived according to TLS specifications, by use KDF in place of the TLS PRF function. A message M is concatenated to L null bytes, where L is the output length (in bytes) of the HMAC procedure, and optional padding bytes. If a cipher bloc algorithm is used, then the total length MUST be a multiple of the bloc size. M1 = M || 0:L || Pad* A HMAC is computed over M1 MAC = HMAC(Ki, M1) A M2 message is built, M2 = M || MAC || Pad* This M2 message is encrypted in order to produce the data field Data = {M2}Kc 3 Key Derivation Functions (KDF) 3.1 TLS PRF function In [TLS extractor] it is suggested to use the TLS PRF function, according to the relation: Urien Expires December 2009 [Page 6] TLS Key Generation June 2009 KDF= PRF(master_secret, label, client-random || server-random || context-value-length || context-value) 3.2 HMAC KDF We suggest using a HMAC based instantiation for KDF, as introduced in [HMAC KDF]. The HMAC procedure is identical to the MAC algorithm negotiated during the handshake session (e.g. HMAC-MD5, HMAC-SHA1, HMAC- SHA256). Notations. - The first argument to a keyed function denotes the key, the value K is the key to PRF and x its input. - The symbol || denotes concatenation. - Given two numbers N and n the symbol N:n represents the value N written as n-bit integer. - L is the length in bits, of this output value delivers by the HMAC procedure Pseudo Random Key = PRK = HMAC(client-random || server-random, master-secret) Keying material, whose length in bits is D, required D/L operations. First is expressed as K(1) = HMAC(PRK, 0:L || KeyLabel || 0:32), Further operations (whose number is i) are computed according to K(i+1) = HMAC(PRK, K(i)|| KeyLabel || i:32), where KeyLabel is an ASCII string. 3.3 NIST compatible KDF 3.3.1 PRF functions The [NIST KDF] standard proposes two candidates for PRF functions: - PRF = HMAC(s,x), and - PRF = CMAC(s,x) Where s is a seed (a secret key in this draft context) and x an input data (a stream of bytes) Urien Expires December 2009 [Page 7] TLS Key Generation June 2009 We suggest to compute s according to [HMAC KDF] s = PRK = HMAC(client-random || server-random, master-secret) 3.3.2 KDF functions Two methods are proposed by the [NIST KDF] standard: - KDF in counter mode, and - KDF in feedback mode KDF functions are based on PRF using the PRK key and additional data such as - The length (L) of the generated cryptographic material, - The Label (a binary string) of the derived keying material, - The Context (a binary string) of the derived keying material (for example identities of parties who want to compute/use this key) KDF = PRF(PRK, f(L, Label, context)) 4 Use cases 4.1 Hierarchical Model for Content/Service Protection The ETSI 102 474 standard [TS 102.474] introduces a hierarchical model for content/service protection mechanisms, targeting digital IP datacast over video broadcasting. This scheme is a nice illustration of a centralized architecture, in which cryptographic keys are securely pushed from head-ends towards terminal devices. Each terminal device holds a Right Encryption Key (REK). This cryptographic material is used in conjunction with Keys Management protocol (KMM) in order to push from head-ends to terminals Services Rights Keys (SEK). In turn the Key Stream Message (KSM) protocol, associated to the SEK key, transport Traffic Encryption Keys (TEK) from head-ends to terminals. At last, clear content is encrypted with TEK, and is broadcasted from head-ends to terminals As an illustration the TLS protocol MAY be used in order to collect the SEK keys. The REK cryptographic material can be instantiated either by a terminal certificate (authenticated by a Certificate- Verify message) or by a pre-shared key [RFC 4279]. A SEK key is securely pushed and transported in an AVP container. Urien Expires December 2009 [Page 8] TLS Key Generation June 2009 5 IANA Considerations 6 Security Considerations 7 References 7.1 Normative References [TLS 1.0] Dierks, T., C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999 [TLS 1.1] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006 [TLS 1.2] Dierks, T., Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.1", draft-ietf-tls-rfc4346-bis-10.txt, March 2008 [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D, Mikkelsen, J, Wright, T., "Transport Layer Security (TLS) Extensions", RFC 4346, April 2006 [RFC 4279] P. Eronen, H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS"), RFC 4279, December 2005. [NIST KDF] Lily Chen, "Recommendation for Key Derivation Using Pseudorandom Functions" NIST Special Publication 800-108. [TS 102.474] ETSI TS 102 474 V1.1.1 (2007-11), Technical Specification, Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Service Purchase and Protection. [CMAC] NIST SP 800-38B, "Recommendation for Block Cipher Modes of Operation - The CMAC Mode for Authentication", May 2005. [HMAC] FIPS 198-1, "The Keyed-Hash Message Authentication Code (HMAC) ", Revision expected to be published in 2008. [TLS extractor] "Keying Material Extractors for Transport Layer Security (TLS) ", draft-ietf-tls-extractor-03.txt, November 2008 7.2 Informative References [TTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0)", draft-funk-eap-ttls-v0-05.txt April 2008 [HMAC-KDF] Krawczyk, H, "On Extract-then-Expand Key Derivation Functions and an HMAC-based KDF", http://www.ee.technion.ac.il/~hugo/kdf/, March 2008 Urien Expires December 2009 [Page 9] TLS Key Generation June 2009 Authors' Addresses Pascal Urien Telecom ParisTech 37/39 rue Dareau, 75014 Paris, France Email: Pascal.Urien@enst.fr Full Copyright Statement Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires December 2009 Urien Expires December 2009 [Page 10]