[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

     Personal Draft                                    Q. Dang
     Internet Draft                                    T. Polk
     Expires: November 2006                              NIST
                                                    June 23, 2006
   
   
   
                   Hash-Based Key Derivation (HKD)
                      draft-dang-nistkdf-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.
   
   
   
   
   
   
   
   
   
   
   
     Dang                Expires December 2006            [Page 1]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
                            Abstract
   
        This draft specifies two Key Derivation Functions
        (KDFs) that may be used to derive symmetric keying
        material for participating parties from a secret value
        and application specific information. Each KDF is
        based on a concatenation technique and a secure hash
        function. The length in bits of secret keying material
        that can be generated by either of the KDFs is limited
        to (2**32 - 1) times the length in bits of the output
        block of the hash function. The derived keying
        material is a concatenation of the outputs of the
        hashing operations. Outputs from the KDFs are either
        "Invalid" or desired secret keying material.
   
        The HKDFs specified in this document are intended for
        use in scenarios where the communicating parties
        derive keying material for their own use.  This
        specification is not intended for implementation of
        key hierarchies.
   
                Conventions used in this document
   
        The Key Word "Secret Value" and "Key Derivation" are
        defined as follows:
   
        Secret Value: A value known only by the two
        communicating parties that will be used as input to the
        key derivation function. This value may be established
        out-of-band, selected by one of the communicating
        parties, or by the two communicating parties.
   
        Key Derivation: The process by which keying material
        (e.g., one or more symmetric keys) is derived from a
        secret value and other non-secret information.
   
        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].
   
   
   
   
   
   
   
   
     Dang            Expires December 2006       [Page 2]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
                          Table of Contents
   
   
        1. Introduction......................................4
        2. Hash-Based Key Derivation Overview................5
           2.1   HKDF Inputs.................................6
           2.2   Basic HKDF Algorithm........................7
        3. Specific HKDF Functions...........................8
           3.1. Concatenation Based HKDF.....................9
              3.1.1. Inputs and Fixed Values.................9
                 3.1.1.1. Secret Value (SV)..................9
                 3.1.1.2. algorithmID.......................10
                 3.1.1.4  keydatalen........................12
                 3.1.1.5  SharedInfo........................13
                 3.1.1.6  hashlen and max-hash-inputlen.....14
              3.1.2    Concatenation HKDF Algorithm.........14
           3.2   ASN.1 Structured HKDF......................15
              3.2.1    Inputs and Fixed Values..............16
                 3.2.1.1  Secret Value......................16
                 3.2.1.2  Key Data Length...................17
                 3.2.1.3 Algorithm Identifier(s)............17
                 3.2.1.4   Initiator Identifier.............17
                 3.2.1.5   Recipient Identifier.............18
                 3.2.1.6  Supplemental Private Information..18
                 3.2.1.7  Supplemental Public Information...18
                 3.2.1.8  Hash Length.......................19
                 3.2.1.9  Maximum Hash Input Length.........19
              3.2.2    ASN.1 Encoding.......................19
              3.2.3    ASN.1 Structured HKDF Algorithm......19
        4. Supported Scenarios..............................21
           4.1 Static-Static Key Agreement..................21
           4.2 Static-Ephemeral Key Agreement...............22
           4.3 Ephemeral-Ephemeral Key Agreement............23
           4.4 Anonymous Key Agreement......................24
        5. Security Considerations..........................24
        6. IANA Considerations..............................26
        7. Acknowledgments..................................26
        8. References.......................................26
           8.1 Normative References.........................26
           8.2  Informative References......................26
        9. Author's Addresses...............................27
        10. Intellectual Property Statement.................28
        11. Disclaimer of Validity..........................28
        12. Copyright Statement.............................28
        13. Acknowledgment..................................29
   
   
   
     Dang            Expires December 2006       [Page 3]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
     1. Introduction
   
        The security of a secret key shared between two
        participating parties may be reduced if the secret
        key is used for each and every secure channel or
        transaction. However, it is inconvenient and
        inefficient if communicating parties must maintain
        different secret values for each secure channel or
        transaction. To minimize the number of long term
        secrets that must be maintained, it is often
        preferable to derive distinct secret keying material
        for each and every secure channel or transaction from
        a single secret value shared between participating
        parties. This algorithm should be strong and
        standardized to overcome compatibility issues in
        communication protocols and their implementations.
   
        There are two such algorithms described in this draft.
        They are hash-based key derivation functions (HKDFs).
        They are used to derive secret keying material from a
        secret value. The output from either of the HKDFs is
        only used for secret keying material, such as a
        symmetric key used for data encryption or message
        integrity, a secret initialization vector, etc. Non-
        secret keying material (such as a non-secret
        initialization vector) is not generated using the
        secret value.
   
        Each of the algorithms is based on a secret value, a
        hash function (e.g., SHA-256) [FIPS 180-2], and
        concatenation.
   
        This document defines two hash-based key derivation
        functions that can be used with any secure hash
        functions.  Section 2 provides an overview of hash-
        based key derivation, and defines inputs and
        parameters that are common to the two HKDFs specified
        in this document.  Section 3 describes the two
        algorithms in detail.  Each algorithm includes
        mandatory and optional inputs, enabling the algorithm
        to support a broad range of protocols and
        applications. Section 4 describes four key agreement
        scenarios to establish secret values that are used in
        the HKDFs, and indicates when the optional steps are
        required.  Section 5 presents security considerations
        with respect to the application of the HKDFs.
   
   
     Dang            Expires December 2006       [Page 4]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
   
   
   
     2. Hash-Based Key Derivation Overview
   
        Each of the HKDFs is constructed from a secure
        hash function, called H. The HKDF accepts
        mandatory and optional inputs, in addition to
        several implementation dependent fixed values.
   
        A secret value shared by all communication
        parties is a required input.  This is the only
        input that contributes entropy to the secret
        keying material derived by the HKDF. Without this
        required shared secret, the secret keying
        material could be generated or known to everyone,
        not only the communicating parties.
   
        Other mandatory inputs are an algorithm
        identifier which identifies the purpose of the
        generating secret keying material and contextual
        information which identifies the communicating
        parties.  This information provides assurance
        that the communicating parties agree on the use
        of the derived keying material.
   
        Beside mandatory inputs, each HKDF supports
        optional supplementary information such as
        protocol-specific information.  The
        implementation dependent fixed values describe
        properties (e.g., output length) of the hash
        function H.
   
        The inputs are more fully described below, in
        Section 2.1.
   
        The HKDF is constructed as an iterative process.
        An initialization phase establishes counters and
        constructs a string from the contextual
        information (and other ooptional inputs) for
        processing.  H is used to hash the counter,
        secret value, and the input string to generate a
        block of keying material.  If additional keying
        material is required, the counter is incremented
        and an additional block is generated until enough
   
   
     Dang            Expires December 2006       [Page 5]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
        keying material is available.  The blocks of key
        material are concatenated and returned to the
        calling process.  Thr basic HKDF algorithm is
        more fully described in Section 2.2.
   
       2.1 HKDF Inputs
   
   
        General inputs to a HKDF are described as
        follows:
   
            o hashlen: an integer equal to the length (in
            bits) of the output of the pseudorandom
            function used to derive blocks of secret
            keying material. This is a fixed value and
            implementation dependent.  For example, if
            the pseudorandom function is SHA-1, hashlen
            is fixed at 160.  If the pseudorandom
            function is SHA-256, hashlen is 256.
   
            o SeedKey: a bit string encoding of the
            shared secret.
   
            o AlgorithmID: a bit string identifying the
            purpose for which the secret keying material
            is being generated.
   
            o contextID : a bit string identifying the
            parties for which the secret keying material
            is being generated; contextID is encoded in a
            prefix-free manner - meaning that, in
            addition to being a one-to-one function of
            the represented data, the encoding ensures
            that one contextID bit string can never
            appear as even the initial portion of another
            contextID bit string. This can be
            accomplished, for example, by using ASN.1 DER
            encoding, or, by constructing contextID as
            the concatenation of a specific sequence of
            fixed-length bit strings.
   
            In this Recommendation, contextID includes
            IDU and IDV,the bit strings that serve as
   
            identifiers of the two parties (U and V) who
            are participating in the key establishment
   
   
     Dang            Expires December 2006       [Page 6]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
            process; contextID may also include an
            AlgorithmID that indicates how to parse the
            derived secret keying material and allocate
            the resulting bit strings to various
            algorithms.
   
            o keydatalen: a positive integer that
            indicates the length (in bits) of the secret
            keying material to be generated.  For the
            HKDFs specified in this document, keydatalen
            is limited to hashlen * (2**32 - 1).
   
            o SharedInfo (optional): a bit string
            consisting of data shared by the parties
            generating the secret keying material.
   
   
        2.2  Basic HKDF Algorithm
   
   
          The HKDFs are constructed as an iterative
          process.  Each iteration generates a block of
          key material by hashing a message constructed
          by concatenating a set of inputs.  The results
          of each iteration are concatenated to generate
          the desired keying material
   
          Message construction requires careful ordering
          and encoding techniques.  The inputs are
          ordered so that the more variable input
          components are first (leftmost) and the least
          variable components last (rightmost). For
          example, a counter is placed to the left of the
          shared secret, and is incremented after each
          iteration.  If the inputs are of fixed size,
          the message can be constructed by simple
          concatenation.  Where inputs are of variable
          size, the representation must include the
          length of each value to ensure that each
          sequence of inputs is unambiguous.
   
          Each HKDF described in Section 3 follow the
          same basic process:
   
   
   
   
     Dang            Expires December 2006       [Page 7]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
           1. Compute reps, the number of iterations required to
           obtain the appropriate amount of keying material.
           Verify that the KDF can securely generate that amount of
           keying material.  If not, the process aborts.
   
           2. Construct a fixed string from the algorithmID,
           contextID, and the sharedInfo.  This string will be part
           of the input to the hash function.
   
           3. Establish a counter value (usually zero).
   
           4. For i = 1 to reps by 1, do the following:
   
            a. Construct a message M(i) from the Counter,
               SeedKey, and the fixed string.
   
            b. Hash M(i) to generate a block of secret
               keying material H(i)
   
            c. Increment the counter
   
           5. Concatenate the output values to construct
             the desired keying material:
   
                H(1) ||  H(2) || ... || H(reps)
   
        The output of the KDF will either be a bit string
        of length keydatalen bits or an error indicator.
   
     3. Specific HKDF Functions
   
        This section specifies two HKDF functions that
        satisfy the HKDF framework described in Section
        2.
   
        The first HKDF is called the Concatenation Based
        HKDF, and is specified in Section 3.1.  The
        Concatenation KDF converts values into a length
        value notation before concatenation. The second
        KDF is called the ASN.1 Structured HKDF, and is
        specified in Section 3.2.  The ASN.1 Structured
        KDF relies on ASN.1 DER encoding. Both KDFs were
        originally specified in [SP 800-56A].
   
   
   
   
   
     Dang            Expires December 2006       [Page 8]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
        3.1. Concatenation Based HKDF
   
   
        This HKDF accepts four mandatory inputs and one
        optional input, and uses two implementation
        dependent fixed values.
   
        The mandatory HKDF inputs are the secret value
        that is a bit string, algorithm identifier, the
        contextual information, and the length of the
        desired key material.  The optional HKDF input is
        information shared between the participating
        parties. The implementation dependent fixed value
        describes the length of the output from the hash
        function H.  The HKDF inputs and implementation-
        dependent fixed values are described in detail in
        Section 3.1.
   
        The HKDF algorithm returns either the desired key
        material, or an error.  The complete HKDF
        algorithm is presented in Section 3.2.
   
        3.1.1. Inputs and Fixed Values
   
   
        The mandatory, optional, and implementation
        independent fixed value inputs of the
        Concatenation HKDF are described as follows.
   
   
        3.1.1.1. Secret Value (SV)
   
   
        The secret value, SV, is a bit string known only
        to the participating parties and is a mandatory
        input. The secret value can be either a fixed or
        variable length bit string. To ensure that the
        secret value input by both parties is the same
        when the secret value is variable in length, it
        is preceded by a fixed length string that
        indicates the length (in bytes) of the secret
        value.
   
   
   
   
     Dang            Expires December 2006       [Page 9]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
        Let SVData be a secret bit string that is
        generated from one of Supported Scenarios
        described in Section 3 of this document. When
        SVData is a fixed length bit string, SV has the
        form:
   
                    SV = SVData
   
   
        When SVData is a variable length bit string, SV
        has the form:
   
                    SV = SVLen || SVData
   
        where SVData is a variable-length bit string of
        (eight-bit) bytes, while SVLen is a fixed length
        bit string that indicates the length (in bytes)
        of SVData.
   
        Protocols that reference this specification MUST
        specify the format of the secret value and the
        lengths of the fixed length quantities:
   
            a. Where SV is a fixed length string, the
               protocol MUST specify the length; and
   
            b. Where SV is a variable length string, the
               protocol MUST specify the size of SVLen.
   
        SV may be established through off-line or on-line
        processes, depending upon the scenario.  See
        Section 3 for supported scenarios through which
        the SV can be established. The security strength
        of SV is determined by the method used to
        generate SV (see Section 4).
   
        3.1.1.2. algorithmID
   
   
        The algorithmID is a mandatory input indicating
        how the derived keying material will be parsed
        and for which algorithm(s) the derived keying
        material will be used. For example, algorithmID
        might indicate that bits 1-80 are to be used as
   
   
   
     Dang            Expires December 2006       [Page 10]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
        an 80-bit HMAC key, and that bits 81-208 are to
        be used as a 128-bit AES key.
   
        An algorithmID consists of two concatenated
        values: algorithmLen and algorithmOID.  The
        algorithmLen is a fixed length bit string that
        indicates the length (in bytes) of algorithmOID.
        The algorithmOID is an ASCII string representing
        an ASN.1 object identifier.
   
        Protocols that reference this specification MUST
        specify the length of algorithmLen and the
        semantics of any recognized object identifiers.
   
        3.1.1.3. contextID
   
        The contextID is a mandatory input.  The
        contextID is a string formed by concatenating
        strings IDU and IDV; IDU and IDV identify the
        participating parties.  Each of the bit strings
        IDU and IDV is an identifier (that is, a bit
        string that is associated with a person, device
        or organization). An identifier may be an
        identifying name or may be something more
        abstract (for example, an IP address and
        timestamp), depending on the application.  IDU
        identifies the initiator of the session or
        transaction, and IDV identifies the responder, as
        specified by the protocol.
   
        There are two formats for the contextID: a fixed-
        length contextID format and a variable-length
        contextID format.
   
        The fixed-length contextID format is used where
        IDU and IDV are fixed-length bit strings, and
        contextID consists of IDU || IDV.
   
        The variable-length contextID format is used
        where IDU and IDV are variable-length bit
        strings.  In this case, contextID has the form:
   
   
                       IDlenU || IDU || IDlenV || IDV
   
   
   
   
     Dang            Expires December 2006       [Page 11]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
        where IDU and IDV are variable-length strings (of
        eight-bit bytes) that serve as the identifiers of the
        participating parties, and IDLenU and IDlenV are
        fixed-length bit strings that indicate the lengths (in
        eight-bit bytes) of IDU and IDV, respectively.
   
        Party U shall be the initiator, and party V shall be the
        responder, as assigned by the protocol.
   
        Protocols that reference this specification MUST specify
        the following information:
   
               1.Which party is defined as the initiator and which
                 is the responder;
   
               2.The contextID format (i.e., fixed length vs.
                 variable length);
   
               3. The source of the identifiers IDU and IDV (e.g.,
                 "use the dns name of the server as IDV"). The
                 values for IDU and IDV should be as specific as
                 feasible for their intended use, and each shall
                 be represented in a protocol-specific format.
   
                 d) The lengths for the fixed-length quantities and
                    the acceptable range of variable-length
                    quantities.  For the fixed-length contextID,
                    the fixed-length quantities are IDU and IDV.
                    For the variable-length contextID, the fixed-
                    length quantities are IDlenU and IDlenV.  (Note
                    that the maximum length of IDU and IDV in the
                    variable-length format must be consistent with
                    the size of IDlenU and IDlenV.
   
        3.1.1.4 keydatalen
   
   
        Keydatalen is a mandatory input.  Keydatalen is
        an integer that indicates the length in bits of
        the secret keying material to be generated;
        keydatalen shall be less than or equal to hashlen
        x (2**32 - 1).
   
   
   
   
   
     Dang            Expires December 2006       [Page 12]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
       3.1.1.5  SharedInfo
   
   
        SharedInfo is an optional input.  SharedInfo is a
        bit string that consists of the concatenation of
        a (protocol-specific) sequence of substrings of
        data shared by the parties generating the secret
        keying material.  Where the substring has a fixed
        length, the substring is composed of just the
        substring data.  Where a substring has variable
        length, the substring has the form Datalen ||
        Data, where Data is a variable length string (of
        eight bit bytes), and Datalen is a fixed-length
        string that indicates the length (in bytes) of
        Data. This SharedInfo can be private or/and
        public shared information between communicating
        parties.
   
        Protocols may specify a SharedInfo field that
        contains fixed length substrings, variable length
        substrings, or a combination. For each substring
        of SharedInfo, a protocol using this key
        derivation function must specify which of these
        data representations is used.  The protocol must
        also specify the lengths for all fixed-length
        quantities.
   
            SharedInfo ::= Substring-1 || Substring-2
            ||... Substring-n
   
            n is a number of substrings in SharedInfo.
   
            Substring-i ::= FixedSubString /
            VariableSubString
   
            i is an integer between 1 and n.
   
           FixedSubstring ::= Fixed-length bit string
   
            VariableSubstring::= Datalen || Data
   
            Datalen ::= fixed-length string
   
            Data    ::= variable length eight-bit byte
            string.
   
   
     Dang            Expires December 2006       [Page 13]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
   
   
        3.1.1.6 hashlen and max-hash-inputlen
   
   
        In addition to the input values, the HKDF
        algorithm depends upon the base hash function and
        two related implementation-dependent fixed
        values. The base hash function, or H, is used to
        derive blocks of secret keying material. One of
        the implementation-dependent fixed values is
        hashlen.  The hashlen is an integer value that
        indicates the length in bits of the output block
        of H. The other one is max-hash-inputlen. The
        max-hash-inputlen is an integer that indicates
        the maximum lengh (in bits) of the bit string(s)
        input to the hash function. If the input sting(s)
        is larger than this max-hash-inputlen value, then
        the HKDF will not work and on output will be
        produced except an error indicator.
   
        Protocols that reference this specification
        SHOULD support multiple hash functions and MAY
        support negotiation between the communicating
        parties for the selection of H.
   
        3.1.2 Concatenation HKDF Algorithm
   
   
          1. reps = ceiling ( keydatalen / hashlen )
   
          2. If reps > (2**32 - 1), then ABORT: and error indicator
            and stop.
   
          3. Initialize a 32-bit, big-endian bit string counter as
            00000001 in hexadecimal.
   
          4. If (counter || SV || algorithmID || contextID  {||
            SharedInfo}) is  more than max-hash-inputlen bits
            long, then ABORT: an error indicator and stop.
   
          5. For i = 1 to reps by 1, do the following:
   
             a. Compute Hash-i = H (counter || SV || algorithmID ||
            contextID {|| SharedInfo}).
   
   
     Dang            Expires December 2006       [Page 14]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
             b. Increment counter (modulo 2**32), treating it as an
            unsigned 32-bit integer.
   
          6. Let Hhash be set to Hash-reps if (keydatalen /
            hashlen) is an integer; otherwise, let Hhash be set to
            the (keydatalen mod hashlen) leftmost bits of Hash-
            reps.
   
          7. Set DerivedKeyingMaterial = Hash-1 || Hash-2 || ... ||
            Hash-(reps-1)|| Hhash.
   
                 Output:
   
   
          The bit string DerivedKeyingMaterial of length
          keydatalen bits (or an error indicator).
   
          Any scheme attempting to call this key
          derivation function with keydatalen greater
          than or equal to hashlen * (2**32 - 1) shall
          output and error indicator and stop without
          outputting DerivedKeyingMaterial. Any call to
          the key derivation function involving an
          attempt to hash a bit string that is greater
          than max-hash-inputlen bits long shall cause
          the HKDF to output an error indicator and stop
          without outputting DerivedKeyingMaterial.
   
            3.2 ASN.1 Structured HKDF
   
   
          This HKDF relies on ASN.1 DER encoding for
          unambiguous encoding of input values. It
          accepts five mandatory inputs, two optional
          inputs, and uses two implementation dependent
          fixed values.
   
          The mandatory HKDF inputs are the secret value
          that is a bit string, the algorithmID, two
          identifiers decribing the initiator and
          recipient, and the length of the desired key
          material. One of the implementation dependent
          fixed values describes the length of the output
          from the hash function H, called hashlen. The
          other is an integer equal to the maximum length
   
   
     Dang            Expires December 2006       [Page 15]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
          (in bits) of the bit string(s) input to the
          hash function, called max-hash-inputlen.  The
          HKDF inputs and implementation-dependent fixed
          values are described in detail in Section
          3.2.1.
   
          The HKDF inputs are DER ASN.1 encoded before
          generating the key material.  Section 3.2.2
          specifies the ASN.1 structure used to encode
          the inputs
   
          This HKDF algorithm returns either the desired
          key material, or an error.  The complete HKDF
          algorithm is presented in Section 3.2.3.
   
            3.2.1    Inputs and Fixed Values
   
   
          The mandatory, optional, and implementation
          dependent fixed value inputs of the ASN.1
          Structured HKDF are described in this section.
   
          The ASN.1 Structured HKDF requires two
          additional inputs.  These values are fixed with
          respect to the hash function H that will be
          used by the HKDF.  The additional inputs are
          the Hash length and maximum hash input length.
          These inputs are described in Sections 3.2.1.8
          and 3.2.1.9.
   
          3.2.1.1   Secret Value
   
   
            The Secret Value (SV) is a byte string that
            is the shared secret known only to the (two)
            communicating parties. This is a mandatory
            input to the HKDF function.
   
   
   
   
   
   
   
   
   
   
     Dang            Expires December 2006       [Page 16]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
            3.2.1.2 Key Data Length
   
   
            The keydatalen input is an integer that is
            the length (in bits) of the secret keying
            material to be generated; keydatalen must be
            less than or equal to hashlen * (2**32  - 1).
            This is a mandatory input to the HKDF
            function.
   
   
           3.2.1.3 Algorithm Identifier(s)
   
   
           AlgorithmID is a unique object identifier that
           indicates the algorithm(s) for which the
           derived secret keying material will be used.
           For example, AlgorithmID might indicate that
           bits 1-128 are to be used as a 128-bit AES key
           and that bits 129-208 are to be used as an 80-
           bit HMAC key. This is a mandatory input to the
           HKDF function.
   
   
           3.2.1.4   Initiator Identifier
   
           PartyUInfo is a bit string that contains
           public information contributed by the
           initiator. At a minimum, PartyUInfo must
           include IDU, the identifier of party U;
           PartyUInfo may also contain other data
           contributed by the initiator. This is a
           mandatory input to the HKDF function.
   
   
   
   
   
   
   
   
   
   
   
   
   
     Dang            Expires December 2006       [Page 17]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
           3.2.1.5   Recipient Identifier
   
          PartyVInfo is a bit string that contains public
          information that was contributed by the
          recipient. At a minimum, PartyVInfo must
          include IDV, the identifier of party V;
          PartyVInfo may also contain other data
          contributed by the recipient. This is a
          mandatory input to the HKDF function.
   
   
            Note: Each of the bit strings IDU and IDV is
            an identifier (that is, a bit string that is
            associated with a person, device or
            organization). An identifier may be an
            identifying name or may be something more
            abstract (for example, an IP address and a
            timestamp), depending on the application. The
            values for IDU and IDV should be as specific
            as feasible for their intended use. Party U
            must be the initiator, and party V must be
            the responder, as assigned by the protocol.
   
          3.2.1.6   Supplemental Private Information
   
   
          SuppPrivInfo is a bit string that contains some
          additional, mutually-known private information
          (for example, a shared secret symmetric key
          that has been communicated through a separate
          channel) to only the communicating parties U
          and V. This is an optional input to the HKDF
          function.
   
   
            3.2.1.7 Supplemental Public Information
   
   
          SuppPubInfo is a bit string that contains some
          additional, mutually-known public information.
          This information may be known to other parties
          other than the communicating parties U and V.
          This is an optional input to the HKDF function.
   
   
   
     Dang            Expires December 2006       [Page 18]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
            3.2.1.8 Hash Length
   
   
          Hashlen is an integer equal to the length (in
          bits) of the output of the hash function used
          to derive blocks of secret keying material.
          This is a mandatory input to the HKDF function.
   
            3.2.1.9 Maximum Hash Input Length
   
   
          max_hash_inputlen is an integer equal to the
          maximum length (in bits) of the bit string(s)
          input to the hash function. This is a mandatory
          input to the HKDF function.
   
            3.2.2  ASN.1 Encoding
   
   
          In this HKDF, algorithmID, PartyUInfor, PartyVinfor,
          SuppPrivInfo, and SuppPubInfo are ASN. 1 DER encoded.
          OtherInfo is the ASN.1 DER encoded value of the
          attributes as following:
   
          OtherInfo ::= SEQUENCE {
              algorithmID   AlgorithmIdentifier,
              partyUInfo     [0] OCTET STRING  MANDATORY,
              partyVInfo     [1] OCTET STRING  MANDATORY,
              suppPubInfo    [2] OCTET STRING  OPTIONAL,
              suppPrivInfo   [3] OCTET STRING  OPTIONAL
          }
   
   
   
   
            3.2.3  ASN.1 Structured HKDF Algorithm
   
   
                 1. Let reps = ceiling (keydatalen / hashlen).
   
                 2. If reps > (2**32 - 1), then ABORT: and error
                      indicator and stop.
   
   
   
   
     Dang            Expires December 2006       [Page 19]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
                 3. Set counter = 00000001in hex (and update
   
                      OtherInfo accordingly).
   
                 4. If ( counter || SV || OtherInfo ) is more than
                      max_hash_inputlen bits long,
                      then ABORT: output an error indicator and
                      stop.
   
                 5. For i = 1 to reps by 1, do the following:
   
                      5.1 Compute h-i = H( counter|| SV || OtherInfo
                      ).
   
                      5.2 Convert counter to an unsigned, 32-bit
                      integer.
   
                      5.3 Increment counter (modulo 2**32).
   
                      5.4 Convert counter to a 32-bit byte string
                      (and update OtherInfo accordingly) for the
                      next execution of the hash function H if i <
                      reps.
   
                 6. Let Hhash be set to h-reps if (keydatalen /
                      hashlen) is an integer; otherwise, let Hhash
                      be set to the (keydatalen mod hashlen)
                      leftmost bits of h-reps.
   
                 6. Compute DerivedKeyingMaterial = h-1|| h-2||...
   
                      || Hhash). .
   
            Output:
   
   
            The DerivedKeyingMaterial is as a bit string
            of length keydatalen bits (or an error
            indicator).
   
            The ASN.1 HKDF produces secret keying
            material that is at most hashlen * (2**32 -1)
            bits in length. Any call to this key
            derivation function using a keydatalen value
            that is greater than hashlen * (2**32-1) will
            cause the HKDF to output and error indicator
            and stop without outputting
   
   
     Dang            Expires December 2006       [Page 20]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
            DerivedKeyingMaterial. Similarly, it is
            assumed that the key derivation function
            calls do not involve hashing a bit string
            that is more than max_hash_inputlen bits in
            length. Any call to the key derivation
            function involving a bit string counter || SV
            || OtherInfo that is greater than
            max_hash_inputlen bits long shall cause the
            KDF to output and error indicator and stop
            without outputting DerivedKeyingMaterial.
   
     4. Supported Scenarios
   
     This section describes four general Key Agreement
     Scenarios to generate secret values for the hash-
     based key derivation function (HKDFs). Two
     communicating parties use one of them to establish a
     secret value. Communicating parties use asymmetric
     cryptography (e.g., Diffie-Hellman or Menezes-Qu-
     Vanstone) to establish a secret value using a key
     agreement scheme. The secret value is used with the
     HKDF to establish a session-specific or transaction-
     specific keying material. The secret value should be
     deleted immediately after computing the keying
     material.
   
     The parties may use previously registered long-term
     asymmetric keys (a.k.a. static keys), or generate a
     new ephemeral (temporary, one-time) key pair
     specifically for this iteration of the key agreement
     process. Where one or more static keys are employed,
     the HKDF supplements the secret value with
     application specific and/or session specific
     information to ensure that the keying material is
     distinct.
   
   4.1 Static-Static Key Agreement
   
     When both participating parties have complementary
     static key pairs for key agreement, the secret value
     SV may be computed.  For example, if both parties
     have Diffie-Hellman static key pairs with the same
     parameters, or elliptic curve key pairs over the
     same curve, the secret value SV may be generated
     using the appropriate key agreement algorithm. In
     general, the public keys associated with these
   
   
     Dang            Expires December 2006       [Page 21]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
     static key pairs are conveyed in X.509 certificates.
     After SV is generated, it is then used to derive the
     keying material.
   
     Since both key pairs are static, this method will
     always produce the same SV for any pair of
     participants. The contextID (in the Concatenation
     Based HKDF) will be the same for these participants
     for any given protocol or application. To ensure
     that distinct keying material is derived, a protocol
     using static-static key agreement MUST include
     SharedInfo substrings that are unique to this
     session or execution of a protocol. The SharedInfo
     substrings MUST include information contributed by
     both the initiator and the recipient. Similarly,
     PartyUInfo and PartyVInfo (in the ASN.1 Structured
     HKDF) will be the same. And if the AlgorithmID is
     the same, a protocol using static-static key
     agreement MUST include optional SuppPrivInfo and/or
     SuppPubInfo that are unique to this session or
     execution of a protocol to ensure that distinct
     keying material is derived.
   
   4.2 Static-Ephemeral Key Agreement
   
     Static-ephemeral key agreement may be performed when
     one participant (the recipient) has a static key
     pair, and the other party (the intiator) has the
     ability to generate ephemeral keys. The recipient's
     static public key is known to the initiator through
     an X.509 certificate or other secure mechanism. In
     this case, the initiator generates a complementary
     ephemeral key pair (e.g., a temporary or one-time
     Diffie-Hellman key pair that is generated with the
     same parameters that were used to generate the
     recipient's static key pair) for this specific
     session or transaction. The initiator sends its
     ephemeral public key to the recipient. Each party
     uses its own key pair, the other party's public key
     and the appropriate key agreement algorithm to
     generate the secret value. The secret value is then
     used to derive the keying material. (The initiator
     should delete the ephemeral private key after
     generating the secret value.)
   
   
   
   
     Dang            Expires December 2006       [Page 22]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
     This method is vulnerable to man-in-the-middle
     attacks if the initiator's ephemeral public key is
     not verified, because an attacker can impersonate
     the initiator in this key agreement protocol.
   
     Authentication of the ephemeral public key can be
     obtained if the initiator has a digital signature
     key pair with a corresponding public key
     certificate. In this case, the initiator signs its
     ephemeral public key using its digital signature
     private key, and then sends the ephemeral public key
     and the signature to the recipient, who can use the
     corresponding public key certificate to verify the
     signature and authenticate the initiator.
   
     The HKDF computation SHOULD include SharedInfo
     substrings (in the Concatenation Based HKDF) or
     SuppPrivInfo and/or SuppPubInfo (in the ASN.1
     Structured HKDF) with unique transaction or
     application-specific information.
   
   4.3 Ephemeral-Ephemeral Key Agreement
   
     Ephemeral-ephemeral key agreement may be performed
     when neither participant has a long term key pair,
     but each participant has the ability to generate
     ephemeral key pairs. In this case, the participants
     agree on parameters (or curves), then each
     participant generates an ephemeral key pair using
     those parameters.
   
     Each participant signs the public key from its
     ephemeral key agreement key pair using its private
     digital signature key and sends the ephemeral public
     key and the signature to the other party. The
     receiver uses the sending party's corresponding
     public key to verify the signature. In general, the
     receiver will use the sender's public key
     certificate to authenticate the participant.
   
     Each party uses its own ephemeral key pair, the
     other party's ephemeral public key and the
     appropriate key agreement algorithm to compute the
     secret value.  The ephemeral private keys should be
     erased after computation of the secret value.
   
   
   
     Dang            Expires December 2006       [Page 23]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
     This option appears to be the most secure of the key
     agreement options because it results in a temporary,
     authenticated ephemeral key.
   
     For this scenario, the SharedInfo substrings (in the
     Concatenation Based HKDF) and SuppPrivInfo and/or
     SuppPubInfo (in the ASN.1 Structured HKDF) are
     optional, since the participants generate a new
     secret value based on new ephemeral key pairs for
     each execution of the HKDF. Each participant
     contributes randomness through their key generation
     process.
   
     4.4 Anonymous Key Agreement
   
     In this scenario, the ephemeral-ephemeral key
     agreement algorithm is used without authentication.
     That is, the participants agree on public (e.g.,
     Diffie-Hellman) parameters and exchange ephemeral
     public keys but do not sign the messages. This
     protocol results in a secret value and derived
     keying material in the same way as ephemeral-
     ephemeral key agreement.
   
     This approach is vulnerable to man-in-the-middle
     attacks, in which the attacker conducts anonymous
     key agreement exchanges with both parties. The
     public key agreement parameters can be delivered
     physically or electronically.
   
     As above, the SharedInfo substrings (in the
     Concatenation Based HKDF) or SuppPrivInfo and/or
     SuppPubInfo (in the ASN.1 Structured HKDF) are
     optional, since the participants generate a new
     secret value based on new ephemeral key pairs for
     each execution of the HKDF.
   
     5. Security Considerations
   
     Special care should be taken to protect the secret
     value and to limit its exposure over time. When a
     secret value is no longer needed, it should be
     destroyed.
   
     If a session key generated from the HKDF is
     compromised, an attacker can decrypt all the
   
   
     Dang            Expires December 2006       [Page 24]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
     messages exchanged in the session. However, this
     provides no information about the other session keys
     or the original secret value. Previous and
     subsequent session keys generated from the same
     secret value in different HKDF computations are
     still secure.This provides a much stronger security
     than using the same key in all sessions. This is one
     of the main purposes to use the HKDF algorithm as
     described above.
   
     If the original secret value is somehow compromised,
     then an attacker can derive all the session keying
     material and use it to access all messages in all
     communication sessions between the two parties that
     used that secret value. So, the original secret
     value must be strongly resistant to brute-force
     attacks and kept securely.
   
     The strength of a key derived using the HKDF is
     limited by the security strength of the hash
     function H, the strength of the secret value, and
     the length of the derived key itself.
   
     Assuming that the output of the HKDF cannot be
     differentiated from random data, the best attack
     against a derived key is a brute force attack.  The
     work factor to perform such an attack is 2**n, where
     n is the length of the derived key. Then, the
     security of a derived key will be the minimum
     security strength of the hash function H, the secret
     value, SV, and the length of the key itself.
   
     When used in HKDF, the work factor to attack a
     secure hash function is 2**h, where h is the length
     of the output.
   
     The HKDFs are intended for use in scenarios where
     the communicating parties derive keying material for
     their own use.  This specification is not intended
     for scenarios where keys are redistributed, such as
     key hierarchies.
   
     When secret values are generated using key agreement
     schemes, the security strengths of the secret values
     depend on the key agreement algorithms used and the
     security strengths of the asymmetric keys. For
   
   
     Dang            Expires December 2006       [Page 25]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
     example, 1024 bit Diffie-Hellman has approximate
     security strength of 80 bits. That is, a secret
     value derived using 1024 bit Diffie-Hellman is
     roughly equivalent to an 80 bit randomly generated
     secret value. Similarly, a secret value derived
     using 163 bit elliptic curve Diffie-Hellman is
     roughly equivalent to an 80 bit randomly generated
     secret value. For additional information regarding
     the strength of values obtained using key agreement
     schemes, see [RFC 3766] and [SP 800-57].
   
     6. IANA Considerations
   
            None
   
   
     7. Acknowledgments
   
     The protocol defined in this document is based
     largely on work by Elaine Barker, Don Johnson, and
     Miles Smid in [SP 800-56A]. This document also
     borrows some text from [SP 800-52] by C. Michael
     Chernick, Charles Edington III, Mathew J. Fanto.
     John Kelsey, Morrie Dworkin, and Bill Burr provided
     invaluable advice and assistance.
   
     8. References
   
               8.1 Normative References
   
   
        [RFC 2119] Bradner, S., "Key words for use in RFCs to
                 Indicate Requirement Levels", BCP 14, RFC 2119,
                 March 1997.
   
   
   
               8.2  Informative References
   
   
   
   
        [FIPS 180-2]   National Institute of Standards and
             Technology, "Secure Hash Standard (SHS)", Federal
   
   
   
     Dang            Expires December 2006       [Page 26]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
             Information Processing Standards Publication 180-2,
             August 2002.
   
        [SP 800-56A]   National Institute of Standards and
             Technology, "Recommendation for Pair-Wise Key
             Establishment Schemes Using Discrete Logarithm
             Cryptography", NIST Special Publication 800-56A,
             March, 2006.
   
        [SP 800-52]   National Institute of Standards and
             Technology, "Guidelines for the Selection and Use of
             Transport Layer Security (TLS)Implementation", NIST
             Special Publication 800-52, June, 2005.
   
        [RFC 3766]    Orman H. and Hoffman P., "Determining
             Strengths For Public Keys Used For Exchanging
             Symmetric Keys", RFC 3766, April 2004.
   
        [SP 800-57]   National Institute of Standards and
             Technology, "Recommendation for Key Management", NIST
             Special Publication 800-57, August 2005.
   
        [FIPS 198]   National Institute of Standards and
             Technology, "The Keyed-Hash Message Authentication
             Code (HMAC)", Federal Information Processing
             Standards Publication 198, March 2002.
   
     9. Author's Addresses
   
            Quynh Dang
            National Institute of Standards and
            Technology
            100 Bureau Drive, Mail Stop 8930
            Gaithersburg, MD 20899-8930
            Email: quynh.dang@nist.gov
   
   
   
            Tim Polk
            National Institute of Standards and
            Technology
            100 Bureau Drive, Mail Stop 8930
            Gaithersburg, MD 20899-8930
            Email: tim.polk@nist.gov
   
   
   
     Dang            Expires December 2006       [Page 27]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
   
     10. 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.
   
     11. 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 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.
   
     12. Copyright Statement
   
     Copyright (C) The Internet Society (2006).
   
   
   
     Dang            Expires December 2006       [Page 28]


     Internet-Draft       Hash-Based Key Derivation  May 2006
   
   
     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.
   
   
     13. Acknowledgment
   
     Funding for the RFC Editor function is currently provided by
     the Internet Society.
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
     Dang            Expires December 2006       [Page 29]
   

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