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]