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]