TLS Working Group P. Urien Internet Draft Telecom ParisTech Intended status: Informational June 18, 2008 Expires: December 18, 2008 TLS Key Generation draft-urien-tls-keygen-00.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 December, 2008. 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 December 2008 [Page 1] TLS Key Generation June 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 Function (KDF)....................................6 4 IANA Considerations..............................................7 5 Security Considerations..........................................7 6 References.......................................................7 6.1 Normative References........................................7 6.2 Informative References......................................8 Authors' Addresses.................................................8 Intellectual Property Statement....................................8 Disclaimer of Validity.............................................8 Copyright Statement................................................9 Acknowledgment.....................................................9 Urien Expires December 2008 [Page 2] TLS Key Generation June 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 distribution infrastructures, able to generate and to deliver cryptographic keys required by multiple protocols. 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 an additional Key Distribution Function (KDF) in order to deliver a set of cryptographic keys according to the relation, Keys = KDF(master-secret, client-random, server-random, "key expansion"). However 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 December 2008 [Page 3] TLS Key Generation June 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 relation: Keys = KDF(master-secret, client-random, server-random, "key expansion") 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 according to cryptographic algorithms negotiated between client and server, and identified by the CipherSuite parameter. Urien Expires December 2008 [Page 4] TLS Key Generation June 2008 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, "key expansion") 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. The 'V' (Vendor-Specific) bit indicates whether the optional Vendor- ID field is present. Urien Expires December 2008 [Page 5] TLS Key Generation June 2008 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 Function (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). Urien Expires December 2008 [Page 6] TLS Key Generation June 2008 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 set to "key expansion". 4 IANA Considerations 5 Security Considerations 6 References 6.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 Urien Expires December 2008 [Page 7] TLS Key Generation June 2008 6.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 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 Urien Expires December 2008 [Page 8] TLS Key Generation June 2008 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 Funding for the RFC Editor function is currently provided by the Internet Society. Urien Expires December 2008 [Page 9]