Network Working Group D. McGrew Internet-Draft B. Weis Intended status: Standards Track Cisco Systems Expires: August 30, 2010 February 26, 2010 Key Derivation Functions and their Uses draft-irtf-cfrg-kdf-uses-00.txt Abstract This note surveys the existing designs for Key Derivation Functions (KDFs), the purposes for which they are used, and their security and usability goals. Importantly, some important protocols use KDFs for multiple purposes. We offer conclusions to guide future standards work and research on KDFs. 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/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 August 30, 2010. Copyright Notice Copyright (c) 2010 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 McGrew & Weis Expires August 30, 2010 [Page 1] Internet-Draft KDFs and their Uses February 2010 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 2. Purposes of Key Derivation Functions . . . . . . . . . . . . . 3 2.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Design Goals for KDFs . . . . . . . . . . . . . . . . . . 5 3. Protocol Independent KDFs . . . . . . . . . . . . . . . . . . 5 3.1. HKDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. NIST SP 800-108 . . . . . . . . . . . . . . . . . . . . . 5 3.3. NIST SP 800-90 . . . . . . . . . . . . . . . . . . . . . . 6 3.4. PKCS #5 . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Specific KDFs . . . . . . . . . . . . . . . . . . . . 6 4.1. NIST SP 800-56A . . . . . . . . . . . . . . . . . . . . . 6 4.2. ANSI X9.42 . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. ANSI X9.63 . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. IEEE 1363-2000 . . . . . . . . . . . . . . . . . . . . . . 7 4.5. IEEE 1363a-2004 . . . . . . . . . . . . . . . . . . . . . 7 4.6. ISO-18033-2 . . . . . . . . . . . . . . . . . . . . . . . 8 4.7. TLS Version 1.2 . . . . . . . . . . . . . . . . . . . . . 8 4.8. TLS Version 1.1 . . . . . . . . . . . . . . . . . . . . . 9 4.9. IKEv1 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.10. IKEv2: HMAC . . . . . . . . . . . . . . . . . . . . . . . 10 4.11. IKEv2: CMAC . . . . . . . . . . . . . . . . . . . . . . . 10 4.12. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.13. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.14. S/MIME DH . . . . . . . . . . . . . . . . . . . . . . . . 12 4.15. CMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.16. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.17. Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.18. OpenPGP . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Future Work . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 McGrew & Weis Expires August 30, 2010 [Page 2] Internet-Draft KDFs and their Uses February 2010 1. Introduction This section provides background and terminology. There are many different KDF designs being utilized in the Internet community and beyond. Most of these designs appear in the specification of a protocol or application, and their use is intended only for that particular protocol or application. These protocol- specific KDFs are cataloged in Section 4. There are also some KDFs that are intended for use in multiple applications or protocols; we catalog these protocol-independent KDFs in Section 3. There are different purposes for which KDFs are used, each with its own distinct security goals. We summarize these purposes in Section 2. We take a broad view of what functions can be regarded as KDFs. Some KDFs use a two-stage process. The first stage is called "extraction" and it takes a variable-length input that is random or pseudorandom, but which may not be uniformly distributed. The second stage is called "expansion", and it takes the fixed-length output of the extraction stage and generates a variable-length pseudorandom output. An extraction stage can be based on a computational assumption (such as the inability of a computationally limited attacker to find preimages of a certain function, for instance). This case is called a computational extractor. Alternatively, an extraction stage can rely on demonstrable statistical properties of some function (as done with universal hashing, for example). This case is called a statistical extractor. KDF terminology is non-uniform; they are sometimes called pseudo- random functions (PRFs). This note is motivated in part by interesting recent work on general- purpose KDFs [I-D.krawczyk-hkdf]. 1.1. 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 [RFC2119]. 2. Purposes of Key Derivation Functions The purposes for which KDFs are used can be categorized as follows. KDFs are used to: McGrew & Weis Expires August 30, 2010 [Page 3] Internet-Draft KDFs and their Uses February 2010 1. Generate one or more keys from a (uniformly random or pseudorandom) seed value. In this case, no extraction stage is needed. This use requires that the key provided as input is *uniformly* random or pseudorandom; it is not sufficient that the seed is unpredictable. 2. Generate one or more keys from a Diffie-Hellman shared secret. An extraction stage is needed, because the DH shared secret is not uniformly distributed. 3. Generate key material from a non-uniform random source. In this case, an extraction stage is needed. 4. Generate a key from a passphrase. An extraction stage is needed. In use case #2, computational extraction seems to be needed, because statistical extraction would be inefficient. In use case #3, either statistical or computational extraction could be used. KDFs designed for use case #4 usually have additional properties. Some functions dedicated to this purpose are designed to be computationally intensive in order to increase the cost of exhaustive password searching. It is easy to design a KDF suitable for use #1, because the use case matches that of a pseudorandom function. It is much trickier to design a function suitable for #2 or #3. There has been a good deal of theoretical work in this area, and it is now possible to cite some provable security results, though many of those methods are not currently used in practice (and some methods may be too inefficient to warrant use in practice). It is open to question how much effort should be exerted designing a function for use #4, considering that any system that derives secret keys from passwords will be vulnerable to dictionary attacks. 2.1. Inputs The following inputs appear in some different KDF designs: An unpredictable seed value. The length of derived keying material. A "salt" value that is different across different runs of the protocol, but which may be public information. An identifier indicating the use for which the derived keys are intended. McGrew & Weis Expires August 30, 2010 [Page 4] Internet-Draft KDFs and their Uses February 2010 An identifier indicating an entity associated with the seed value and derived key. Not all KDF designs have all of these inputs. 2.2. Design Goals for KDFs The essential goal for a KDF is security; if used properly it must meet its security goals. Ideally, it should also be robust against accidental misuse. It is desirable that a KDF design be simple. Complexity should be avoided in the specification, implementation, and the interface to the KDF. It is desirable that a KDF be reusable, that is, that a KDF design can be used across multiple applications. A protocol or application that uses a KDF should be able to easily replace the KDF that it uses; i.e. it should have KDF agility. IKE and TLS have this property to some extent. It should be easy to validate a KDF implementation as being correct. To this end, a KDF design should define test cases that can be used in known-answer tests. 3. Protocol Independent KDFs The following KDF definitions have been specified, and are used by one or more of the networking standards documented later in this memo. 3.1. HKDF The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) [I-D.krawczyk-hkdf] specifies a KDF with an optional extraction phase followed by an expansion phase. The combination of the extraction and expansion steps of HKDF is intended for use cases #2 or #3 (or even #4) whereas the expansion phase by itself is suitable for use case #1. 3.2. NIST SP 800-108 The NIST Recommendation for Key Derivation Using Pseudorandom Functions KDFs [SP800-108] defines three KDFs (using counter mode, feedback mode, and a double-pipeline iteration mode) all of which assume an input of a uniform pseudorandom value, and which require McGrew & Weis Expires August 30, 2010 [Page 5] Internet-Draft KDFs and their Uses February 2010 identifiers for the key usage and optionally accept identifiers for the entities associated with the keys. They were developed specifically for use case #1. These functions use a cryptographic hash function or a block cipher as an underlying primitive. 3.3. NIST SP 800-90 The NIST Recommendation for Random Number Generation Using Deterministic Random Bit Generators (Revised) [SP800-90] defines KDFs intended for use case #3. Of the inputs that we consider, these functions accept only a seed value. They have additional properties, such as backtracking resistance. 3.4. PKCS #5 The first KDF described by PKCS #5: Password-Based Cryptography Specification Version 2.0 [RFC2898] is PBKDF. It is a hash function in OFB mode. The second KDF described is PBKDF2, which is an HMAC iterated KDF, with all of the iterates XORed together. These functions have the property that they can be computationally expensive, in order to thwart dictionary attacks against keys derived from user-generated passwords. These KDFs were designed for use case #4, but is seen in other use cases as well. Notes: o Neither KDF defined in PKCS #5 matches either the NIST KDF definitions or HKDF. However, it should be noted that none of these KDF definitions were intended to be used for a use case #4. 4. Protocol Specific KDFs Many Internet and other network protocols have described one or more particular KDFs as part of their specification. This section summarizes how the KDF was designed, and in which of the use cases described in Section 2 each KDF is deployed. Particular attention is paid as to whether the KDF meets the requirements of the specifications in the previous section ([SP800-108], [I-D.krawczyk-hkdf], Section 3.4) or Section 5 of [SP800-56A]. 4.1. NIST SP 800-56A The NIST Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography [SP800-108] describes two counter mode KDFs. They are similar, but differ in that one is intended for McGrew & Weis Expires August 30, 2010 [Page 6] Internet-Draft KDFs and their Uses February 2010 use with ASN.1 encodings. These KDFs take a Diffie-Hellman shared secret as a seed input, and are intended for use case #2. They require as input identifiers for the key usage and identifiers for the entities associated with the key establishment protocol. 4.2. ANSI X9.42 The ANSI Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography [X9.42] defines a hash function KDF. It is intended for use cases #1 and #2. 4.3. ANSI X9.63 The ANSI Public Key Cryptography for the Financial Services Industry Key Agreement and Key Transport Using Elliptic Curve Cryptography [X9.63] defines a hash function in counter mode. It is intended for use cases #1 and #2. 4.4. IEEE 1363-2000 The IEEE Standard Specifications for Public-Key Cryptography [IEEE1363] defines KDF1, a key derivation function used with public key key agreement schemes. It describes a keyed hash of the DH result and a string. This is use case #2. Notes: o KDF1 nearly matches SP 800-56A, but it does not include a counter input. The standard also does not clearly define how the key derivation parameters associated with the session are determined. o The KDF1 specification says that it was derived from ANSI X9.42. o KDF1 does not match HKDF. It does not include an Extract function, but nearly matches the Expand function (again, the absent counter input) as long as the output only requires one iteration of the HKDF HMAC-Hash function. 4.5. IEEE 1363a-2004 Am amendment to IEEE 1363 [IEEE1363a] adds a new KDF2 to the IEEE 1363 standard. It describes a KDF that is a hash function in counter mode. This is use case #2. Notes: McGrew & Weis Expires August 30, 2010 [Page 7] Internet-Draft KDFs and their Uses February 2010 o KDF2 matches SP 800-56A (other than the ordinal position of the counter differs). However, the standard does not clearly define how the key derivation parameters associated with the session are determined. o The KDF2 specification says that it was derived from ANSI X9.42- 2001 and ANSI X9.63. o KDF2 does not match HKDF. It does not include an Extract function, and the Expand function is a counter mode KDF, not a feedback mode KDF. 4.6. ISO-18033-2 The KDFs defined in Encryption algorithms -- Part 2: Asymmetric ciphers [ISO-18033-2] are a more general version of those those in SP 800-56A; the latter specification mandates inputs that are not present in the ISO-18033-2 specification. The ISO-18033-2 KDFs are intended to be used with a DH result as input, which make them suitable for use case #2. 4.7. TLS Version 1.2 P_SHA256 is defined in Section 5 of The Transport Layer Security (TLS) Protocol, Version 1.2 [RFC5246]. This KDF uses HMAC in output feedback mode. Two KDF computations are specified: deriving the "master_secret" from the "pre_master_secret", followed by derivation of session keys (the "key_block") from the "master_secret". The KDF is applied as both use cases #1 and #2, as follows: o Use case #1 occurs when the pre_master_secret is distributed by the client (Section 8.1.1 of RFC 5246). o Use case #2 occurs when the pre_master_secret is derived from Diffie-Hellman (Section 8.1.2 of RFC 5246). o Use case #1 occurs when the key_block is computed from the master_secret (Section 6.3 of RFC 5246). Notes: o When P_SHA256 is used for a use case #1, it nearly matches the "KDF in Feedback Mode" specified in SP 800-108. It is missing only the L ("length of the derived keying material") input. o The feedback construction of P_SHA256 does not conform to either Concatenation Key Derivation Function defined in SP 800-56A. Also, PSHA256 uses an HMAC construction whereas SP 800-56A describes a McGrew & Weis Expires August 30, 2010 [Page 8] Internet-Draft KDFs and their Uses February 2010 keyed hash function. o When P_SHA256 is used for a use case #1, it nearly matches the HKDF-Expand function, but is missing the counter input). o For use case #2, P-SHA256 does not conform to HKDF. It specifies an HMAC of the seed rather than a HKDF-Extract function, and omits the counter input to HKDF-Expand. 4.8. TLS Version 1.1 This KDF is the result of P_MD5 XOR P_SHA1 (Section 5 of The Transport Layer Security (TLS) Protocol Version 1.1 [RFC4346]. This KDF is an HMAC in an OFB mode variant. An HMAC PRF is called twice for each derivation: once with MD5 as the hash function and once with SHA1 as the hash function. The results of the two PRF calls are XORed together and become the output of the KDF. The KDF is applied as both use cases #1 and #2, as described for TLS 1.2: Notes: o The P_MD5 XOR P_SHA1 does not match either SP 800-108 or SP 800- 56A. The use of MD5 is strongly discouraged, in general, though this use of MD5 is believed to provide adequate security. o The P_MD5 XOR P_SHA1 does not match HKDF. 4.9. IKEv1 The Internet Key Exchange (IKE) [RFC2409] defines a KDF, which it calls a PRF. The "HMAC version of the negotiated hash algorithm" is used as the default KDF (Section 4 of RFC 2409). Hash algorithms currently defined int the IANA IPsec Registry include SHA-1, SHA-256, SHA-384, and SHA-512. The KDF used to protect IKEv1 messages ("phase 1 prf") is composed of two serialized PRF operations, where the data given to the PRF depends on the type of authentication used in the IKEv1 exchange. The KDF is applied as use case #1 or #2 depending on the type of authentication. IKEv1 also generates keying material for IPsec using a PRF, where the keying material used with the PRF is the result of the phase 1 PRF. Notes: o None of the KDFs match either SP 800-108 or SP 800-56A. McGrew & Weis Expires August 30, 2010 [Page 9] Internet-Draft KDFs and their Uses February 2010 o None of the KDFs match HKDF. 4.10. IKEv2: HMAC The Internet Key Exchange (IKEv2) Protocol[RFC4306] defines a KDF, which it calls PRF+ (Section 2.13 of RFC 4306). PRF+ uses a negotiated hash algorithm. In this section we consider negotiated HMAC algorithms, which used creates a KDF that is an HMAC in an OFB mode. It is first used to extract the SKEYSEED from a shared Diffie- Hellman result (use case #1). The KDF is then used to create a set of shared keys using SKEYSEED (use case #2). Notes: o PRF+ strictly conforms to HKDF: deriving SKEYSEED matches the HKDF-Extract step, and derivation of the shared keys matches the HKDF-Expand step. o Deriving SKEYSEED does not conform to SP 800-56A: it specifies the use of an HMAC (where nonces are used as the "key" input) rather than a hash. Also, the it is missing data inputs of a counter and "other information". o Deriving the set of shared keys from SKEYSEED very nearly conforms to SP 800-108 but the inputs are different: a counter is included but concatenated after S, S is not necesarily a null terminated string, and the ("length of the derived keying material") input is missing. 4.11. IKEv2: CMAC A CMAC hash function has been defined for IKEv2: The Advanced Encryption Standard- Cipher-based Message Authentication Code-Pseudo- Random Function-128 (AES-CMAC-PRF-128) [RFC4615]. This KDF can be used as an alternative to the HMAC methods described in the previous IKEv2 section; it is used identically. This KDF uses AES with a fixed key, and offers no theoretical justification for this practice. This makes it vulnerable to a related-key attack, making it unsuitable for general-purpose use. Note: o Deriving SKEYSEED does not conform to SP 800-56A (as described in the previous section). o Deriving the set of shared keys from SKEYSEED very nearly conforms to SP 800-108 but the inputs are different (as described in the McGrew & Weis Expires August 30, 2010 [Page 10] Internet-Draft KDFs and their Uses February 2010 previous section). o HKDF only supports the use of HMAC-based key derivation functions, so AES-CMAC-PRF-128 does not conform to HKDF. 4.12. SSH The Secure Shell (SSH) Transport Layer Protocol [RFC4253] KDF is defined in Section 7.2 of RFC 4253. The input keying material to the KDF is a Diffie-Hellman result, which is use case #2. Notes: o The SSH KDF does not conform to SP 800-56A. A hash function is used to expand the DH result and it uses a counter beginning at 0x65, which are necessary components to conform. However, the ordinal positions of the counter inputs does not match SP 800-56A. Also, the other inputs (H and session_id) do not match either SP 800-56A definition, although it can be noted that the session_id argument was generated from identifiers unique to the two communicating parties. 4.13. SRTP The Secure Real-time Transport Protocol [RFC3711] defined AES-CM-PRF, which construction is defined in Section 4.3. This KDF uses AES in counter (CTR) mode to produce keying material. A counter mode PRF requires a uniformly random key, so without any further processing must fall into use case #1. Most key management standards (e.g., RFC 4568) for SRTP do result in a uniformly random secret key. An emerging key management method for SRTP [I-D.ietf-avt-dtls-srtp] uses the TLS KDF to provide a shared secret to SRTP. In the cases where the TLS shared secret is a secret key, use case #1 applies. However, in the case of a Diffie-Hellman result being the source of the TLS pre-master-secret, this would be considered a use case #2 (even though the master_secret used as source to the SRTP KDF is a uniformly random key). Notes: o The AES-CM-PRF KDF is based on a counter mode cipher, which does not conform to SP 800-56A or SP 800-108, or HKDF. McGrew & Weis Expires August 30, 2010 [Page 11] Internet-Draft KDFs and their Uses February 2010 4.14. S/MIME DH The S/MIME Diffie-Hellman Key Agreement Method (RFC 2631) contains a KDF in Section 2.1.2. Two inputs are given to the SHA-1 hash function: The DH result, and a set of "other information" specific to the communicating parties encoded as ASN.1. This is strictly a use case #2. Notes: o The KDF matches SP 800-56A Approved Alternative 2, with the exception that the counter is included included in the "OtherInfo" input rather than as an explicit argument to the hash function. o The KDF does not match the specification of HKDF. 4.15. CMS The Cryptographic Message Syntax (CMS) Algorithms [RFC3770] describes the use of PBKDF2. See Section 3.4. 4.16. S/MIME The Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification (RFC 5751) specifies the KDF in CMS [RFC5754]. See Section 3.4. 4.17. Kerberos A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism [RFC4402] defines a KDF described as "PRF+". It is a pseudorandom function in counter mode, where the pseudorandom function is defined as part of a cryptographic profile. RFC 3962 [RFC3962] defines an AES profile that defines its pseudorandom function as PBKDF2 with a HMAC SHA-1 hash. See Section 3.4. 4.18. OpenPGP String-to-Key (S2K) Function in "OpenPGP Message Format" [RFC4880]. Hash function in counter mode. The preferred implementation takes a salt and passphrase as inputs, and is iterated. In this mode a configured hash function (e.g., SHA256). Notes: McGrew & Weis Expires August 30, 2010 [Page 12] Internet-Draft KDFs and their Uses February 2010 o The KDF does not match either the NIST KDF definitions or HKDF. 5. Conclusions There are many KDF designs, and there is discouragingly little compatibility between them. Even where KDFs are similar, they most often have incompatibilities that would prevent interoperability. On the positive side, it appears that there are many ways to design adequately secure KDFs. The most prevalent Internet key management protocols, IKE and TLS, use their KDFs for both use cases #1 and #2. This fact shows the value of a multi-purpose KDF, such as HKDF. Ideally, any KDF designed for multi-purpose Internet use should be suitable for both IKE and TLS. (Interestingly, both IKE and TLS use HMAC as an extractor, but IKE uses nonces as the HMAC key and the DH shared secret as the "message" input, while TLS does the reverse.) One potential demerit of a multi-purpose design is complexity. The benefit of using one KDF for two or three purposes could be negated if the KDF was two or three times as complex as each of the single- purpose KDFs that it is intended to replace. In order to promote KDF reusability and agility, it may be worthwhile to devise a standard interface between a KDF and a protocol. Since the complexity of a KDF increases as the number of its inputs increases, any such standard should avoid the temptation to proliferate inputs. (Consider, for instance, the need to validate an implementation across the range of admissible inputs.) There are a great many KDFs designed for use in Diffie-Hellman protocols (use case #2), all of which use hash functions, some in the HMAC construction. Any KDF suitable for use case #3 is likely to be suitable for use case #2. It could be valuable if the existing protocol-independent KDFs that target use case #3 [SP800-90] are found to be suitable for use case #2. 5.1. Future Work The importance of KDF security warrants more attention; it would be useful to reference and summarize theoretical analyses of There are no standards that make use of statistical extractors, though there have been a number of theoretical results in the area. One promising approach is the use of statistical extractors for McGrew & Weis Expires August 30, 2010 [Page 13] Internet-Draft KDFs and their Uses February 2010 Diffie-Hellman protocols, in which the extractor is tailored to the specific mathematical group in which the DH protocol is operating. For instance, an elliptic curve group would use a specific extractor, and a particular group of integers modulo a prime would use a different extractor. To use this approach in a protocol, it would be necessary to associate an extractor with a mathematical group; extraction could be incorporated into the group-specific computations. There would still need to be an expand stage. It may be useful to add a statistical extractor to an existing protocol as an additional step, in order to add robustness to the extraction stage, while retaining the existing KDF. In this scenario, the existing KDF is relieved of meeting the security goals of use case #2, and instead need only meet those of use case #1. Further analysis of the KDFs referenced in this note would be useful. For each of the KDFs referenced in this note, it would be good to know o Under what conditions is it secure? If it relies on a computational assumption, what is that assumption? If it relies on a statistical extractor, what are the requirements of the inputs of that extractor? o Are there test cases for the KDF? o If the KDF is used in a protocol or application, does that protocol or application admit the replacement of the KDF? If so, what is its interface (does it take a "salt" input, for example). There are more KDFs that could be analyzed and included in future versions of this note, but we believe that analysis of these other less-used KDFs would not change our conclusions. 6. Security Considerations The KDF selected for use should meet or exceed the security requirements of its particular usage. 7. IANA Considerations This note has no actions for IANA. This section should be removed by the RFC editor before publication as an RFC. 8. References McGrew & Weis Expires August 30, 2010 [Page 14] Internet-Draft KDFs and their Uses February 2010 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.ietf-avt-dtls-srtp] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-03 (work in progress), July 2008. [I-D.krawczyk-hkdf] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", draft-krawczyk-hkdf-01 (work in progress), January 2010. [IEEE1363] "IEEE Standard Specifications for Public-Key Cryptography", IEEE Std 1363-2000 , January 2000. [IEEE1363a] "IEEE Standard Specifications for Public-Key Cryptography - Amendment 1: Additional Techniques", IEEE Std 1363a- 2004 , March 2004. [ISO-18033-2] "Information technology -- Security techniques -- Encryption algorithms -- Part 2: Asymmetric ciphers", International Organization for Standardization , May 2006. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC3770] Housley, R. and T. Moore, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", RFC 3770, May 2004. [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) McGrew & Weis Expires August 30, 2010 [Page 15] Internet-Draft KDFs and their Uses February 2010 Encryption for Kerberos 5", RFC 3962, February 2005. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism", RFC 4402, February 2006. [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC- PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010. [SP800-108] Chen, L., "Special Publication 800-108: Recommendation for Key Derivation Using Pseudorandom Functions", U.S. National Institute of Standards and Technology (NIST) Special Publication (SP) 800-108, 2008, . [SP800-56A] Barker, E., Johnson, D., and M. Smid, "Special Publication 800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", U.S. National Institute of Standards and Technology (NIST) Special Publication (SP) 800-56A, . [SP800-90] McGrew & Weis Expires August 30, 2010 [Page 16] Internet-Draft KDFs and their Uses February 2010 Barker, E. and J. Kelsey, "Special Publication 800-90: Recommendation for Random Number Generation Using Deterministic Random Bit Generators (Revised)", U.S. National Institute of Standards and Technology (NIST) Special Publication (SP) 800-90, 2007, . [X9.42] "Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography", American National Standard for Financial Services , November 2003. [X9.63] "Public Key Cryptography for the Financial Services Industry Key Agreement and Key Transport Using Elliptic Curve Cryptography", American National Standard for Financial Services , November 2001. Authors' Addresses David A. McGrew Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 USA Phone: (408) 525 8651 Email: mcgrew@cisco.com URI: http://www.mindspring.com/~dmcgrew/dam.htm Brian Weis Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 USA Phone: (408) 526 4796 Email: bew@cisco.com McGrew & Weis Expires August 30, 2010 [Page 17]