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]