Network Working Group J. Herzog
Internet-Draft R. Khazan
Intended status: Informational MIT Lincoln Laboratory
Expires: October 16, 2011 April 14, 2011
The With-MAC key-wrapping algorithm for Cryptographic Message Syntax
draft-herzog-withmac-keywrap-00
Abstract
This document describes a new key-wrapping algorithm to be used in
the EnvelopedData, AuthenticatedData and AuthEnvelopedData structures
of the Cryptographic Message Syntax. Because these structures do not
provide data-origin authentication, a recipient cannot
cryptographically verify that the plaintext received was the
plaintext encapsulated by the message's original sender. The With-
MAC key-wrapping algorithm allows an EncryptedKey value to hold both
a wrapped symmetric key and a MAC value on the data to be
authenticated. When used in EnvelopedData, AuthenticatedData and
AuthEnvelopedData structures, therefore, these structures can achieve
data-origin authentication (in some circumstances) using only
symmetric-key algorithms.
Disclaimer
This work is sponsored by the United States Air Force under Air Force
Contract FA8721-05-C-0002. Opinions, interpretations, conclusions
and recommendations are those of the authors and are not necessarily
endorsed by the United States Government.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 16, 2011.
Herzog & Khazan Expires October 16, 2011 [Page 1]
Internet-Draft With-MAC keywrap algorithm April 2011
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 7
3. Structures of the With-MAC key-wrap algorithm . . . . . . . . 7
4. Actions of the sender . . . . . . . . . . . . . . . . . . . . 8
5. Actions of the receiver . . . . . . . . . . . . . . . . . . . 11
6. Requirements and Recommendations . . . . . . . . . . . . . . . 12
7. Security considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Herzog & Khazan Expires October 16, 2011 [Page 2]
Internet-Draft With-MAC keywrap algorithm April 2011
1. Introduction
This document extends the Cryptographic Message Syntax (CMS) [CMS] so
as to allow EncryptedKey values to contain both an encrypted key and
a message authentication code (MAC) value. CMS is a standard
notation and representation for cryptographic messages.
Specifically, CMS uses ASN.1 notation [X.680] [X.681] [X.682] [X.683]
to define a number of structures for encrypted data, signed data,
authenticated data, and so on. Such structures carry both:
o The cryptographically-protected information, and
o Key-management information regarding the keys used.
Of particular interest here are three 'top-level' structures:
o EnvelopedData, which holds encrypted (but not necessarily
authenticated) information [CMS],
o AuthenticatedData, which holds authenticated (MACed) information
[CMS], and
o AuthEnvelopedData, which holds information protected by
authenticated encryption: a cryptographic scheme that combines
encryption and authentication [CMS-AUTHENV].
All three of these structures are constructed in the same basic way.
First, the message-creator generates a fresh symmetric key, which we
will call the content-protection key (CPK). (In context of
EnvelopedData structures, AuthenticatedData structures and
AuthEnvelopedData structures, this key is called the content-
encryption key, the authentication key, and the content-
authenticated-encryption key respectively. We will use the term CPK
as a generic term when speaking of all three of these structures in
the aggregate.) Next, the creator uses the CPK to cryptographically
protect the content. Lastly, the CPK is then wrapped for each
recipient. That is, copies of the CPK are encrypted in a sequence of
'wrap keys' (one copy per wrap-key) such that every recipient knows
(or can compute) at least one wrap-key. A recipient, upon receiving
the message, decrypts one of the wraps to retrieve the CPK and then
uses the CPK to decrypt or verify the content.
CMS supports several different types of wrap-keys, including:
o Key transport: the wrap key is the public encryption key of some
recipient.
Herzog & Khazan Expires October 16, 2011 [Page 3]
Internet-Draft With-MAC keywrap algorithm April 2011
o Key agreement: the wrap key is a key-encryption key (KEK) created
using a key-agreement scheme (such as Diffie-Hellman [CMS-ALG])
and a key-derivation function (KDF).
o Key-encryption key: the wrap key is a previously-distributed
symmetric key-encrypting key known to the recipient.
o Password: the wrap key is a key-encryption key derived from a
password.
Each of these methods is represented by a different 'key wrap'
structure, called the KeyTransRecipientInfo, KeyAgreeRecipientInfo,
KEKRecipientInfo and PasswordRecipientInfo structures, respectively.
Each such structure is an instance of the RecipientInfo type, which
can be embedded in each of EnvelopedData, AuthenticatedData and
AuthEnvelopedData, respectively. Thus, each key-wrap method can be
used in each top-level structure mentioned above.
Furthermore, a single top-level structure can hold multiple key-wrap
structures, as might be the case when a single message has multiple
distinct receivers. In this case, every wrap-structure in the
message will encrypt the same CPK. This means, unfortunately, that
the top-level CMS structures described above do not provide data-
origin authentication. Consider, for example, the following sequence
of events:
o Alice sends an AuthEnvelopedData message to both Bob and Mallory.
This message uses a fresh, new content-authenticated-encryption
key to protect the plaintext with authenticated-encryption
algorithm. This algorithm will produce both ciphertext and MAC
value, thus providing both confidentiality and integrity
guarantees. Furthermore, Alice will wrap this content-
authenticated-encryption key to both Bob and Mallory. The final
AuthEnvelopedData message contains the ciphertext, the MAC value,
and both wrap-structures (one for Bob and one for Mallory).
o Mallory intercepts the message and prevents Bob from receiving it.
o Mallory unwraps the content-authenticated-encryption key from the
wrap intended for her. Mallory then creates new plaintext of her
choice, and encrypts it using the same authenticated-encryption
algorithm and the same content-authenticated-encryption key used
by Alice.
o Mallory then replaces the ciphertext and MAC value of Alice's
message with the values just generated. She may additionally
remove her key-wrap structure from Alice's message.
Herzog & Khazan Expires October 16, 2011 [Page 4]
Internet-Draft With-MAC keywrap algorithm April 2011
o Mallory sends the modified message to Bob.
o Bob receives the message, unwraps the content-authenticated-
encryption key, and decrypts/authenticates the message.
At this point, Bob has received and validated a message that appears
to have been sent by Alice, but whose content was chosen by Mallory.
(Furthermore, Mallory may not even be an apparent receiver of the
modified message.)
This same 'attack' can be successfully launched against EnvelopedData
and AuthenticatedData structures. We rush to note, however, that
none of these structures were actually designed to provide data-
origin authentication. By data-origin authentication, we mean the
guarantee that a recipient will not accept a message that was not
sent, as received, by the ostensible sender. This would require that
the messages identify the ostensible sender, but these structures
might not do so:
o These structures do contain an OriginiatorInfo field, which would
identify the sender. This value is sometimes optional, however.
o The key-wrap structures, listed above, may partially identify the
sender. The use of password-based key-wrap, for example, implies
that the (ostensible) sender is among the entities that know the
password. Likewise, the use of key-encrypting-key key-wrap
implies that the (ostensible) sender is among the entities that
know the key. This is only partial identification, however, and
the key-transport key-wrap method will not identify the ostensible
sender. (The key-agreement method will identify the sender, if
the sender uses a certified public value [STATIC].)
We also note that it is not necessary for these top-level CMS
structures to provide data-origin authentication. CMS already
provides an entirely separate structure for this purpose: the
SignedData structure, which applies digital signatures to the
encapsulated 'plaintext.' Furthermore, these top-level structures
can be encapsulated in each other. Alice, above, can entirely
prevent the described attack by encapsulating the AuthEnvelopedData
structure in a SignedData structure. Then the AuthEnvelopedData
structure would be signed by Alice, and Mallory could not change that
structure's plaintext without invalidating Alice's signature.
Unfortunately, this is not a universal solution. In particular, the
sender may not have a certified public signature key, or the ability
to send their signature-verification key to the recipients in an
authenticated manner. In this case, the SignedData structure will
not be able to provide data-origin authentication guarantees to the
Herzog & Khazan Expires October 16, 2011 [Page 5]
Internet-Draft With-MAC keywrap algorithm April 2011
recipients(s). Also, 'small' hardware implementations may not be
able to include the number-theoretic algorithms that underlie public-
key signature schemes, and would therefore be unable to create or
process SignedData structures.
Given this, it may be desirable to identify alternate methods to
achieve data-origin authentication in CMS. In this document, we
describe a method by which EnvelopedData, AuthenticatedData, and
AuthEnvelopedData structures can provide data-origin authentication
using only symmetric cryptographic algorithms. Specifically, we
define the With-MAC key-wrap 'algorithm.' In actuality, this
'algorithm' is simply a wrapper which allows key-wrap structures to
contain both:
o A content-protecting symmetric key (encrypted, as before), and
o A MAC value protecting the content of the enclosing EnvelopedData,
AuthenticatedData, or AuthEnvelopedData structure.
The encryption is created using a 'wrap-encryption' key, and the MAC
is generated using a 'wrap-MAC' key. Both of these keys are derived
from the wrap-key using a key-derivation function. Therefore, the
MAC value authenticates the origin of the data to the extent that the
key-wrap mechanism cryptographically authenticates the sender of the
message.
In this way, the With-MAC algorithm provides the following
guarantees:
o When the key-wrap mechanism is based on a shared key-encrypting
key (KEKRecipientInfo) it guarantees to the receiver that the data
was sent by someone who knows the relevant key-transportation key.
o When the key-wrap mechanism is based on passwords
(PasswordRecipientInfo) it guarantees to the receiver that the
data was sent by someone who knows the relevant password.
o When the key-wrap mechanism is based on key-agreement mechanisms
(KeyAgreeRecipientInfo) and the sender uses a long-term, certified
value, it guarantees to the receiver that the data was sent by
someone who knows the sender's private key-agreement key.
(The With-MAC algorithm can not be used when the key-wrap method is
based on key-transport. It can be used when the key-wrap method is
based on key-agreement and the sender uses an ephemeral value, but it
provides no data-authentication properties.)
Because the With-MAC algorithm uses only symmetric-key algorithms, it
Herzog & Khazan Expires October 16, 2011 [Page 6]
Internet-Draft With-MAC keywrap algorithm April 2011
may also be more appropriate than the SignedData structure for
resource-constrained (e. g., power, space) hardware implementations.
Lastly, we note that MAC values tend to be smaller than digital
signatures. Under some circumstances (such as when there are
relatively few key-wraps) the With-MAC algorithm may result in
shorter messages than a SignedData structure.
2. Requirements Terminology
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 [MUST].
3. Structures of the With-MAC key-wrap algorithm
In the KeyTransRecipientInfo, KeyAgreeRecipientInfo,
PasswordRecipientInfo and KEKRecipientInfo, the CPK-wrapping
algorithm is identified through an AlgorithmIdentifier structure
[PROFILE]:
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
The With-MAC key-wrap algorithm has the algorithm identifier:
id-alg-WithMACWrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) X }
When the algorithm field of an AlgorithmIdentifier structure is id-
alg-WithMACWrap, the parameters field MUST be a WithMACParameters
value:
WithMACParameters ::= SEQUENCE {
wrapAlgorithm KeyEncryptionAlgorithmIdentifier,
kdfAlgorithm KeyDerivationAlgorithmIdentifier,
macAlgorithm MessageAuthenticationCodeAlgorithm }
The fields are used as follows:
Herzog & Khazan Expires October 16, 2011 [Page 7]
Internet-Draft With-MAC keywrap algorithm April 2011
o The wrapAlgorithm value identifies the algorithm which will be
used to wrap the CPK.
o The kdfAlgorithm value identifies the key-derivation function
which will be used to derive the wrap-encryption key and the wrap-
MAC key from the wrap-key.
o The macAlgorithm value identifies the MAC algorithm used to
provide data-origin authentication.
The With-MAC algorithm CAN NOT be used in a KeyTransRecipientInfo
structure, but CAN be used in a KeyAgreeRecipientInfo,
KEKRecipientInfo or PasswordRecipientInfo structure. When the With-
MAC key-wrap algorithm is provided as the key-wrap algorithm in one
of these three structures, the encryptedKey field of that structure
MUST hold the DER encoding of a EncryptedKeyWithMACValue value:
EncryptedKeyWithMACValue ::= SEQUENCE {
encryptedKey EncryptedKey,
macValue MessageAuthenticationCode }
These fields are used as follows:
o The encryptedKey field holds the wrapped CPK, and
o The macValue holds a MAC value computed over the 'plaintext' of
the enclosing EnvelopedData, AuthenticatedData, or
AuthEnvelopedData.
These fields are discussed in more detail in the next sections.
4. Actions of the sender
The specific actions of the sender depend on whether it is being used
as the key-wrap algorithm of a KeyAgreeRecipientInfo,
PasswordRecipientInfo or KEKRecipientInfo structure, and whether that
structure is in an EnvelopedData, AuthenticatedData or
AuthEnvelopedData structure. In all cases, the sender chooses a key-
encryption algorithm, a key-derivation algorithm, and a MAC
algorithm. It then encodes these choices (and their associated
parameters) in a WithMACParameters structure. (If the kdfAlgorithm
parameters includes a 'key length' field of any type (e.g. PBKDF2
[CMS-ALG]) then this MUST be set to zero.) The sender then creates
an AlgorithmIdentifier structure composed of the id-alg-WithMACWrap
value (in the algorithm field) and that WithMACParameters structure
Herzog & Khazan Expires October 16, 2011 [Page 8]
Internet-Draft With-MAC keywrap algorithm April 2011
(in the parameters field).
The sender then places this AlgorithmIdentifier in the
keyEncryptionAlgorithm of the key-wrap structure being constructed
(KeyAgreeRecipientInfo, KEKRecipientInfo, or PasswordRecipientInfo).
Then, the sender performs the following actions once per EncryptedKey
value in the key-wrap structure. (This will be exactly once, in the
case of KEKRecipientInfo and PasswordRecipientInfo, and once per
RecipientEncryptedKey in the case of KeyAgreeRecipientInfo.)
o First, the sender generates the wrap-key according to the standard
CMS process for this key-wrap type:
* In the case of PasswordRecipientInfo, the wrap key is generated
by applying a key-derivation function (identified in the
keyDerivationAlgorithm field of the PasswordRecipientInfo
structure) to the password.
* In the case of KEKRecipientInfo, the wrap key is the key
identified by the kekid field of that structure.
* And in the case of KeyAgreeRecipientInfo, the wrap key is
generated by applying the relevant key-agreement algorithm to
the public value or the sender (identified in the originator
field of the KeyAgreeRecipientInfo structure), the public value
of the receiver (identified in the rid field of the
RecipientEncryptedKey structure being built) and the fresh per-
message randomness (in the ukm field if the
KeyAgreeRecipientInfo structure) if present.
o The sender then derives the wrap-encryption key from the wrap-key
by applying the KDF identified in the kdfAlgorithm field of the
WithMACParameters structure. Typically, key-derivation functions
are used to transform a password into a key, and some take an
additional 'context' or 'info' input [HKDF-PAPER] [HKDF-RFC]:
* If the KDF takes a 'context' or 'info' parameter, then the
'password' input to the KDF is the wrap key and the
'context'/'info' parameter will be the value of the
wrapAlgorithm field of the WithMACParameters structure. (That
is, the type and length bytes are omitted.)
* If the KDF does not take a 'context' or 'info' parameter, then
the 'password' input to the KDF is the concatenation of the
wrap-key and the value of the wrapAlgorithm field of the
WithMACParameters structure. (That is, the type and length
bytes are omitted.)
Herzog & Khazan Expires October 16, 2011 [Page 9]
Internet-Draft With-MAC keywrap algorithm April 2011
In both cases, the length of the key to be generated is that
required by the algorithm identified in the wrapAlgorithm field of
the WithMACParameters structure.
o The sender then uses the wrap-encryption key to wrap the CPK,
which depends on the top-level structure being built:
* In the case of EnvelopedData, the CPK is the content-encryption
key.
* In the case of AuthenticatedData, the CPK is the authentication
key.
* In the case of AuthEnvelopedData, the CPK is the content-
authenticated-encryption key.
In all cases, the CPK is wrapped according to the algorithm (and
parameters) identified in the wrapAlgorithm field of the
WithMACParameters structure created above. This process results
in an EncryptedKey value, which we will call the 'inner
EncryptedKey'.
o The sender then derives the wrap-MAC key from the wrap-key by
applying the KDF identified in the kdfAlgorithm field of the
WithMACParameters structure:
* If this KDF takes a 'context' or 'info' parameter, then the
'password' input to the KDF is the wrap key and the
'context'/'info' parameter will be the value of the
macAlgorithm field of the WithMACParameters structure. (That
is, the type and length bytes are omitted.)
* If the KDF does not take a 'context' or 'info' parameter, then
the 'password' input to the KDF is the concatenation of the
wrap-key and the value of the macAlgorithm field of the
WithMACParameters structure. (That is, the type and length
bytes are omitted.)
In both cases, the length of the key to be generated is that
required by the algorithm identified in the macAlgorithm field of
the WithMACParameters structure.
o The sender then computes a MAC value by applying the MAC algorithm
identified in the macAlgorithm field of the WithMACParameters
structure to the wrap-MAC key and the data to be protected:
* In the case of an EnvelopedData structure, the data to be
protected is the value of the structure's encryptedContentInfo
Herzog & Khazan Expires October 16, 2011 [Page 10]
Internet-Draft With-MAC keywrap algorithm April 2011
field.
* In the case of an AuthenticatedData structure, the data to be
protected is the value of the structure's encapContentInfo
field.
* In the case of an AuthEnvelopedData structure, the data to be
protected is the value of the structure's
authEncryptedContentInfo field.
In all three cases, the type and length bytes of the relevant
field are not included in the input to the MAC algorithm, but only
the bytes representing its value. The MAC algorithm will output a
MessageAuthenticationCode value.
o The sender then embeds the inner EncryptedKey value and this
MessageAuthenticationCode value in an EncryptedKeyWithMACValue
structure.
o The sender then DER-encodes this EncryptedKeyWithMACValue
structure, and embeds these octets (the 'outer EncryptedKey
value') in the encryptedKey field being constructed.
5. Actions of the receiver
When the receiver processes an EnvelopedData, AuthenticatedData or
AuthEnvelopedData structure, and
o has selected has selected a RecipientInfo structure to process for
the CPK, and
o recognizes the id-alg-WithMACWrap value (in the algorithm field of
the AlgorithmIdentifier value in the keyEncryptionAlgorithm field
of that RecipientInfo structure),
it will perform the following steps:
o It first parses the parameters field of that AlgorithmIdentifier
as a WithMACParameters structure, above. If the
AlgorithmIdentifier in the kdfAlgorithm field contains a key-
length parameter in the Parameters field, this MUST be set to
zero.
o The receiver then generates or retrieves the wrap-key according to
the standard CMS process for this key-wrap type. It then derives
a wrap-encryption key and wrap-MAC key from the wrap-key as
described in Section 4, using the algorithm identified in the
Herzog & Khazan Expires October 16, 2011 [Page 11]
Internet-Draft With-MAC keywrap algorithm April 2011
kdfAlgorithm field of the WithMACParameters structure.
o It then parses the encryptedKey field of that RecipientInfo
structure (or the relevant RecipientEncryptedKey structure, in the
case of a KeyAgreeRecipientInfo) as the DER encoding of a
EncryptedKeyWithMACValue. In this way, it recovers the 'inner'
EncryptedKey value and a MessageAuthenticationCode value.
o It then decrypts the inner EncryptedKey value with the wrap-
encryption key, according to the algorithm identified in the
wrapAlgorithm field of the WithMACParameters structure, In doing
so, it recovers the wrapped key (be it content-encryption key,
authentication key, or content-authenticated-encryption key).
o At this point, the receiver MUST both:
* Use the wrapped key to process the encryptedContentInfo,
encapContentInfo, or authEncryptedContentInfo as specified in
[CMS], [CMS] and [CMS-AUTHENV] respectively, and
* Use the wrap-MAC key and the MAC algorithm specified in the
macAlgorithm field of the WithMACParameters structure to verify
the integrity of the encryptedContentInfo, encapContentInfo, or
authEncryptedContentInfo, respectively.
The receiver SHOULD reject the entire top-level structure
(EnvelopedData, AuthenticatedData, or AuthEnvelopedData) if the
MAC value fails to verify.
6. Requirements and Recommendations
This document does not define the actions of sender or receiver when
the top-level structure is EncryptedData or DigestedData. Therefore,
this algorithm MUST NOT be used in EncryptedData or DigestedData
structures. Similarly, this document does not define the actions of
sender or receiver when the key-wrap mechanism is key-transport.
Therefore, the With-MAC algorithm MUST NOT be used when the key-wrap
structure is KeyTransRecipientInfo. This algorithm MAY but SHOULD
NOT be used when the key-wrap method is based on key-agreement and
the sender uses an ephemeral value, as it provides no data-origin
guarantees. See Section 7. However, receivers that support the use
of this algorithm when the sender uses a static key-agreement key
MUST also gracefully accept this use of this algorithm when the
sender uses an ephemeral value. (Such receivers MUST also reject the
entire top-level structure when the MAC fails to verify, as in
Section 5, even when the sender uses an ephemeral value.)
Herzog & Khazan Expires October 16, 2011 [Page 12]
Internet-Draft With-MAC keywrap algorithm April 2011
It is RECOMMENDED that implementations of this specification support
EnvelopedData, AuthenticatedData and AuthEnvelopedData.
Implementations that support this specification MUST support the
following key-wrap algorithms: id-aes128-wrap, id-aes192-wrap, id-
aes256-wrap [AES-WRAP].
Implementations that support this specification MUST support the
following key-derivation function algorithm: id-PBKDF2 [CMS-ALG].
Furthermore, implementations that support this specification MUST
support the use of the MAC algorithms below for use as the prf:
[SP800-132].
Implementations that support this specification MUST support the
following MAC algorithms: id-hmacWithSHA224, id-hmacWithSHA256, id-
hmacWithSHA384, id-hmacWithSHA512, all with parameters present but
set to type NULL [SHA2-HMAC].
7. Security considerations
The goal of this document is to add data-origin authentication to
EnvelopedData, AuthenticatedData, and AuthEnvelopedData structures
without weakening the existing security properties of those
structures. To that end, it is essential that the key-derivation
function (used to derive the wrap-encryption and wrap-MAC key from
the wrap key) be sufficiently strong. Such algorithms are designed
to take two inputs: some secret, weak randomness and some public,
strong randomness, and to output strong, secret randomness. In this
application, the strong, public randomness is a salt value (included
in the AlgorithmIdentifier structure in the kdfAlgorithm field).
However, this salt will be used twice: either to derive two keys from
two related 'passwords' (the wrap-key concatenated with either the
wrapAlgorithm value or the macAlgorithm value) or the same password
(the wrap-key) in two different contexts (the wrapAlgorithm value or
the macAlgorithm value). The security of this algorithm requires
that the KDF ensure two resulting key (the wrap-encryption and wrap-
MAC keys) to be cryptographically independent. See [HKDF-PAPER] for
details. It is not yet known whether the PBKDF2 function satisfies
this property, but there is no evidence to the contrary either.
However, the HKDF scheme [HKDF-RFC] provably achieves this property,
and should be added to Section 6 as a required (and default)
algorithm when it receives an object identifier.
This algorithm provides no data-origin guarantees when there is no
binding between the wrap-key and the data-origin. Therefore, this
document does not define the usage of this algorithm when the key-
wrap mechanism is key-transport. Similarly, this algorithm will
Herzog & Khazan Expires October 16, 2011 [Page 13]
Internet-Draft With-MAC keywrap algorithm April 2011
provide no data-origin guarantees when the key-wrap mechanisms is
key-agreement and the data-origin uses an ephemeral key-agreement key
value. Although such usage is valid under this specification, there
is no advantage to using this algorithm rather than the algorithm
identified in the wrapAlgorithm field of the WithMACParameters
structure.
8. IANA Considerations
This document makes use of object identifiers. These object
identifiers have been registered in an arc delegated to the IETF
S/MIME Working Group. This arc and its registration procedures will
be transferred to IANA soon. No further action by IANA is necessary
for this document or any anticipated updates.
9. Acknowledgements
The authors would like thank Jim Schaad for informing them of the
attack described in Section 1. We would also like to thank Russ
Housely and Sean Turner for their valuable comments.
10. References
10.1. Normative References
[AES-WRAP]
Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", Request For Comments 3394,
September 2002.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", Request
For Comments 5652, September 2009.
[CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", Request For Comments 3370, August 2002.
[CMS-AUTHENV]
Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", Request For
Comments 5083, November 2007.
[MUST] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", Request For Comments 2119,
March 1997.
Herzog & Khazan Expires October 16, 2011 [Page 14]
Internet-Draft With-MAC keywrap algorithm April 2011
[PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", Request For Comments 5280, May 2008.
[SHA2-HMAC]
Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
Request For Comments 4231, December 2005.
[SP800-132]
Turan, M., Barker, E., Burr, W., and L. Chen,
"Recommendation for Password-Based Key Derivation Part 1:
Storage Applications (DRAFT)", NIST Special
Publication 800-132, June 2010.
[X.680] ITU-T, "Information Technology - Abstract Syntax Notation
One", Recommendation X.680, ISO/IEC 8824-1:2002, 2002.
[X.681] ITU-T, "Information Technology - Abstract Syntax Notation
One: Information Object Specification",
Recommendation X.681, ISO/IEC 8824-2:2002, 2002.
[X.682] ITU-T, "Information Technology - Abstract Syntax Notation
One: Constraint Specification", Recommendation X.682, ISO/
IEC 8824-3:2002, 2002.
[X.683] ITU-T, "Information Technology - Abstract Syntax Notation
One: Parameterization of ASN.1 Specifications",
Recommendation X.683, ISO/IEC 8824-4:2002, 2002.
10.2. Informative References
[HKDF-PAPER]
Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010,
August 2010.
[HKDF-RFC]
Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", Request For
Comments 5869, May 2010.
[STATIC] Herzog, J. and R. Khazan, "Use of static-static Elliptic-
Curve Diffie-Hellman key agreement in Cryptographic
Message Syntax", Internet
Draft draft-herzog-static-ecdh-01.txt, November 2010.
Herzog & Khazan Expires October 16, 2011 [Page 15]
Internet-Draft With-MAC keywrap algorithm April 2011
Appendix A. ASN.1 Module
This appendix provides the normative ASN.1 definitions for the
structures described in this specification using ASN.1 as defined in
[X.680] through [X.683].
WithMACKeyEncryption
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) XX }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL
IMPORTS
KeyEncryptionAlgorithmIdentifier,
KeyDerivationAlgorithmIdentifier,
MessageAuthenticationCodeAlgorithm,
EncryptedKey,
MessageAuthenticationCode
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24)}
;
id-alg-WithMACWrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) X }
WithMACParameters ::= SEQUENCE {
wrapAlgorithm KeyEncryptionAlgorithmIdentifier,
kdfAlgorithm KeyDerivationAlgorithmIdentifier,
macAlgorithm MessageAuthenticationCodeAlgorithm }
EncryptedKeyWithMACValue ::= SEQUENCE {
encryptedKey EncryptedKey,
macValue MessageAuthenticationCode }
END
Herzog & Khazan Expires October 16, 2011 [Page 16]
Internet-Draft With-MAC keywrap algorithm April 2011
Authors' Addresses
Jonathan C. Herzog
MIT Lincoln Laboratory
244 Wood St.
Lexington, MA 02144
USA
Email: jherzog@ll.mit.edu
Roger Khazan
MIT Lincoln Laboratory
244 Wood St.
Lexington, MA 02144
USA
Email: rkh@ll.mit.edu
Herzog & Khazan Expires October 16, 2011 [Page 17]