Network Working Group J. Schaad
Request for Comments: 3537 Soaring Hawk Consulting
Category: Standards Track R. Housley
Vigil Security
May 2003
Wrapping a Hashed Message Authentication Code (HMAC) key
with a Triple-Data Encryption Standard (DES) Key
or an Advanced Encryption Standard (AES) Key
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document defines two methods for wrapping an HMAC (Hashed
Message Authentication Code) key. The first method defined uses a
Triple DES (Data Encryption Standard) key to encrypt the HMAC key.
The second method defined uses an AES (Advanced Encryption Standard)
key to encrypt the HMAC key. One place that such an algorithm is
used is for the Authenticated Data type in CMS (Cryptographic Message
Syntax).
1. Introduction
Standard methods exist for encrypting a Triple-DES (3DES) content-
encryption key (CEK) with a 3DES key-encryption key (KEK) [3DES-
WRAP], and for encrypting an AES CEK with an AES KEK [AES-WRAP].
Triple-DES key wrap imposes parity restrictions, and in both
instances there are restrictions on the size of the key being wrapped
that make the encryption of HMAC [HMAC] keying material difficult.
This document specifies a mechanism for the encryption of an HMAC key
of arbitrary length by a 3DES KEK or an AES KEK.
Schaad & Housley Standards Track [Page 1]
RFC 3537 HMAC Key Wrap May 2003
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 BCP 14, RFC 2119
[STDWORDS].
2. HMAC Key Guidelines
[HMAC] suggests that the key be at least as long as the output (L) of
the hash function being used. When keys longer than the block size
of the hash algorithm are used, they are hashed and the resulting
hash value is used. Using keys much longer than L provides no
security benefit, unless the random function used to create the key
has low entropy output.
3. HMAC Key Wrapping and Unwrapping with Triple-DES
This section specifies the algorithms for wrapping and unwrapping an
HMAC key with a 3DES KEK [3DES].
The 3DES wrapping of HMAC keys is based on the algorithm defined in
Section 3 of [3DES-WRAP]. The major differences are due to the fact
that an HMAC key is of variable length and the HMAC key has no
particular parity.
In the algorithm description, "a || b" is used to represent 'a'
concatenated with 'b'.
3.1 Wrapping an HMAC Key with a Triple-DES Key-Encryption Key
This algorithm encrypts an HMAC key with a 3DES KEK. The algorithm
is:
1. Let the HMAC key be called KEY, and let the length of KEY in
octets be called LENGTH. LENGTH is a single octet.
2. Let LKEY = LENGTH || KEY.
3. Let LKEYPAD = LKEY || PAD. If the length of LKEY is a multiple
of 8, the PAD has a length of zero. If the length of LKEY is not
a multiple of 8, then PAD contains the fewest number of random
octets to make the length of LKEYPAD a multiple of 8.
4. Compute an 8 octet key checksum value on LKEYPAD as described in
Section 2 of [3DES-WRAP], call the result ICV.
5. Let LKEYPADICV = LKEYPAD || ICV.
6. Generate 8 octets at random, call the result IV.
Schaad & Housley Standards Track [Page 2]
RFC 3537 HMAC Key Wrap May 2003
7. Encrypt LKEYPADICV in CBC mode using the 3DES KEK. Use the
random value generated in the previous step as the initialization
vector (IV). Call the ciphertext TEMP1.
8. Let TEMP2 = IV || TEMP1.
9. Reverse the order of the octets in TEMP2. That is, the most
significant (first) octet is swapped with the least significant