Network Working Group J. Herzog
Internet-Draft R. Khazan
Intended status: Standards Track MIT Lincoln Laboratory
Expires: February 28, 2013 August 27, 2012
The With-MAC key-wrapping algorithm for Cryptographic Message Syntax
draft-herzog-withmac-keywrap-02
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. This is useful in cases where the
structures must be generated by entities without certified digital-
signature keys.
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."
Herzog & Khazan Expires February 28, 2013 [Page 1]
Internet-Draft With-MAC keywrap algorithm August 2012
This Internet-Draft will expire on February 28, 2013.
Copyright Notice
Copyright (c) 2012 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.
Herzog & Khazan Expires February 28, 2013 [Page 2]
Internet-Draft With-MAC keywrap algorithm August 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 8
3. Structures of the With-MAC key-wrap algorithm . . . . . . . . 8
4. Actions of the sender . . . . . . . . . . . . . . . . . . . . 10
5. Actions of the receiver . . . . . . . . . . . . . . . . . . . 13
6. Requirements and Recommendations . . . . . . . . . . . . . . . 14
7. Security considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Herzog & Khazan Expires February 28, 2013 [Page 3]
Internet-Draft With-MAC keywrap algorithm August 2012
1. Introduction
This document extends the Cryptographic Message Syntax (CMS)
[RFC5652] 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 [RFC5652],
o AuthenticatedData, which holds authenticated (MACed) information
[RFC5652], and
o AuthEnvelopedData, which holds information protected by
authenticated encryption: a cryptographic scheme that combines
encryption and authentication [RFC5083].
All three of these structures are constructed in the same basic way.
o First, the message-creator generates a fresh symmetric key. 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.
o Next, the creator uses the CPK to cryptographically protect the
content.
o 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.
Herzog & Khazan Expires February 28, 2013 [Page 4]
Internet-Draft With-MAC keywrap algorithm August 2012
CMS supports several different types of wrap-keys, including:
o Key transport: the wrap key is the public encryption key of some
recipient.
o Key agreement: the wrap key is a key-encryption key (KEK) created
using a key-agreement scheme (such as Diffie-Hellman [RFC3370])
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.
Herzog & Khazan Expires February 28, 2013 [Page 5]
Internet-Draft With-MAC keywrap algorithm August 2012
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.
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, exactly 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 [RFC6278].)
We also note that it is not strictly 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
Herzog & Khazan Expires February 28, 2013 [Page 6]
Internet-Draft With-MAC keywrap algorithm August 2012
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
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 is 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 a pseudo-algorithm which allows key-wrap structures to
contain both:
o A content-protecting symmetric key (encrypted, as before), and
o A MAC value protecting the contents of the enclosing
EnvelopedData, AuthenticatedData, or AuthEnvelopedData structure.
If the standard CMS encryption operation in an EnvelopedData
structure is
KEK1( CPK ) || KEK2( CPK ) || ... || CPK( data )
then the encryption operation of this document is
KEK1'( CPK ), MAC1'( CPK( data ) ) ||
KEK2'( CPK ), MAC2'( CPK( data) ) ||... || CPK( data )
where KEK1' and MAC1' are both derived from KEK1. Specifically, the
encryption of the CPK 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
same 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.
Herzog & Khazan Expires February 28, 2013 [Page 7]
Internet-Draft With-MAC keywrap algorithm August 2012
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
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 [RFC2119].
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
[RFC5280]:
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 }
Herzog & Khazan Expires February 28, 2013 [Page 8]
Internet-Draft With-MAC keywrap algorithm August 2012
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:
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 'ciphertext' of
the enclosing EnvelopedData, AuthenticatedData, or
AuthEnvelopedData. That is, this document follows the 'encrypt
then MAC' paradigm, in which the plaintext is encrypted and the
ciphertext MACed.
These fields are discussed in more detail in the next sections.
Herzog & Khazan Expires February 28, 2013 [Page 9]
Internet-Draft With-MAC keywrap algorithm August 2012
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
[RFC3370]) 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 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 CPK and uses it to protect the
payload of the EnvelopedData, AuthenticatedData or
AuthEnvelopedData structure as described in [RFC5652].
o Then, 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.
Herzog & Khazan Expires February 28, 2013 [Page 10]
Internet-Draft With-MAC keywrap algorithm August 2012
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] [RFC5869]:
* 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.
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
Herzog & Khazan Expires February 28, 2013 [Page 11]
Internet-Draft With-MAC keywrap algorithm August 2012
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
field. The type and length bytes are omitted.
* In the case of an AuthenticatedData structure, the data to be
protected is the the DER encoding of the following structure:
AuthenticatedDataAuthenticatedContents ::= SEQUENCE {
encapContentInfo EncapsulatedContentInfo,
authAttrs AuthAttributes OPTIONAL }
In this structure, the encapContentInfo field holds the same
value as the same field in the AuthenticatedData structure.
Likewise, the authAttrs field holds the same value as the same
field in the AuthenticatedData structure if present, and
omitted if absent.
* In the case of an AuthEnvelopedData structure, the data to be
protected is the DER encoding of the following structure:
AuthEnvelopedDataAuthenticatedContents ::= SEQUENCE {
authEncryptedContentInfo EncapsulatedContentInfo,
authAttrs AuthAttributes OPTIONAL }
In this structure, the authEncryptedContentInfo field holds the
same value as the same field in the AuthEnvelopedData
structure. Likewise, the authAttrs field holds the same value
as the same field in the AuthEnvelopedData structure if
Herzog & Khazan Expires February 28, 2013 [Page 12]
Internet-Draft With-MAC keywrap algorithm August 2012
present, and omitted if absent.
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
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
Herzog & Khazan Expires February 28, 2013 [Page 13]
Internet-Draft With-MAC keywrap algorithm August 2012
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
[RFC5652], [RFC5652] and [RFC5083] 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 protected data (defined in Section 4).
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 the algorithm provides no
data-origin guarantees in this case. (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.
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 [RFC3394].
Implementations that support this specification MUST support the
following key-derivation function algorithm: id-PBKDF2 [RFC3370].
Furthermore, implementations that support this specification MUST
support the use of the MAC algorithms of the next paragraph for use
Herzog & Khazan Expires February 28, 2013 [Page 14]
Internet-Draft With-MAC keywrap algorithm August 2012
as the prf or this KDF [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 [RFC4231].
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 are designed 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) are cryptographically independent. See [HKDF] 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 [RFC5869] provably achieves this property,
and should be added to Section 6 as a required and default algorithm
when it receives an object identifier.
In keeping with [RFC6476], this specification uses the 'encrypt then
MAC' approach to combining encryption and integrity, rather than the
'MAC then encrypt' approach. For a discussion of this issue, see
[EncryptThenAuth].
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
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.
Herzog & Khazan Expires February 28, 2013 [Page 15]
Internet-Draft With-MAC keywrap algorithm August 2012
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
RFC 4231, December 2005.
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083,
November 2007.
[RFC5280] 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", RFC 5280, May 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 5652, September 2009.
[SP800-132]
Turan, M., Barker, E., Burr, W., and L. Chen,
"Recommendation for Password-Based Key Derivation Part 1:
Herzog & Khazan Expires February 28, 2013 [Page 16]
Internet-Draft With-MAC keywrap algorithm August 2012
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
[EncryptThenAuth]
Krawczyk, H., "The Order of Encryption and Authentication
for Protecting Communications (or: How Secure Is SSL?)",
Proceedings of CRYPTO 2001, August 2001.
[HKDF] Krawczyk, H., "Cryptographic Extraction and Key
Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010,
August 2010.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, May 2010.
[RFC6278] Herzog, J. and R. Khazan, "Use of static-static Elliptic-
Curve Diffie-Hellman key agreement in Cryptographic
Message Syntax", RFC 6278, November 2010.
[RFC6476] Gutmann, p., "Using Message Authentication Code (MAC)
Encryption in the Cryptographic Message Syntax (CMS)",
RFC 6476, January 2012.
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].
Herzog & Khazan Expires February 28, 2013 [Page 17]
Internet-Draft With-MAC keywrap algorithm August 2012
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,
AuthAttributes,
EncapsulatedContentInfo,
EncryptedContentInfo
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 }
AuthenticatedDataAuthenticatedContents ::= SEQUENCE {
encapContentInfo EncapsulatedContentInfo,
authAttrs AuthAttributes OPTIONAL }
AuthEnvelopedDataAuthenticatedContents ::= SEQUENCE {
authEncryptedContentInfo EncryptedContentInfo,
authAttrs AuthAttributes OPTIONAL }
END
Herzog & Khazan Expires February 28, 2013 [Page 18]
Internet-Draft With-MAC keywrap algorithm August 2012
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 February 28, 2013 [Page 19]