Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key
RFC 3537

Type RFC - Proposed Standard (May 2003; Errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG state RFC 3537 (Proposed Standard)
Telechat date
Responsible AD Steven Bellovin
Send notices to <turners@ieca.com>, <blake@brutesquadlabs.com>

Email authors IPR References Referenced by Nits Search lists

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.


   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

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",
   document are to be interpreted as described in BCP 14, RFC 2119

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

   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.


   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
Show full document text