[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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, <http://
              csrc.nist.gov/publications/nistpubs/800-108/
              sp800-108.pdf>.

   [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, <http://csrc.nist.gov/
              publications/nistpubs/800-56A/
              SP800-56A_Revision1_Mar08-2007.pd>.

   [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, <http://
              csrc.nist.gov/publications/nistpubs/800-90/
              SP800-90revised_March2007.pdf>.

   [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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/