TLS Working Group P. Urien Internet Draft Telecom ParisTech Intended status: Informational December 12, 2008 Expires: June 12, 2009 TLS Key Generation draft-urien-tls-keygen-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). All rights reserved. Abstract The TLS protocol is widely deployed and used over the Internet. Client and server nodes compute a set of keys called the key-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. Urien Expires June 2009 [Page 1] TLS Key Generation December 2008 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. Table of Contents Copyright Notice................................................... 1 Abstract........................................................... 1 Conventions used in this document.................................. 2 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 Intellectual Property Statement................................... 10 Disclaimer of Validity............................................ 10 Copyright Statement............................................... 10 Acknowledgment.................................................... 10 Urien Expires June 2009 [Page 2] TLS Key Generation December 2008 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 key-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 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 June 2009 [Page 3] TLS Key Generation December 2008 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 June 2009 [Page 4] TLS Key Generation December 2008 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 June 2009 [Page 5] TLS Key Generation December 2008 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 June 2009 [Page 6] TLS Key Generation December 2008 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 June 2009 [Page 7] TLS Key Generation December 2008 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 June 2009 [Page 8] TLS Key Generation December 2008 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 June 2009 [Page 9] TLS Key Generation December 2008 Authors' Addresses Pascal Urien Telecom ParisTech 37/39 rue Dareau, 75014 Paris, France Email: Pascal.Urien@enst.fr Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Urien Expires June 2009 [Page 10] TLS Key Generation December 2008 Funding for the RFC Editor function is currently provided by the Internet Society. Urien Expires June 2009 [Page 11]