[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 5083

S/MIME Working Group                                          R. Housley
Internet-Draft                                            Vigil Security
Updates: 3852 (if approved)                                 January 2007


                 The CMS AuthEnvelopedData Content Type
              <draft-ietf-smime-cms-auth-enveloped-00.txt>


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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 a "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   This document describes an additional content type for the
   Cryptographic Message Syntax (CMS).  The AuthEnvelopedData content
   type is intended for use with authenticated encryption modes.  All of
   the various key management techniques that are supported in the
   EnvelopedData content type are also supported by the
   AuthEnvelopedData content type.











Housley                                                         [Page 1]

INTERNET-DRAFT       AuthEnvelopedData Content Type         January 2007


1. Introduction

   This document describes an additional content type for the
   Cryptographic Message Syntax (CMS) [CMS].  The AuthEnvelopedData
   content type is intended for use with authenticated encryption modes,
   where an arbitrary content is both authenticated and encrypted.
   Also, some associated data, in the form of authenticated attributes
   can also be authenticated.  All of the various key management
   techniques that are supported in the EnvelopedData content type are
   also supported by the AuthEnvelopedData content type.

   The AuthEnvelopedData content type, like all of the other CMS content
   types, employs ASN.1 [X.208-88], and it uses both the Basic Encoding
   Rules [X.209-88] and the Distinguished Encoding Rules (DER)
   [X.509-88].

1.1  Terminology

   In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as
   described in [STDWORDS].

1.2  Version Numbers

   The major data structure (AuthEnvelopedData) includes a version
   number as the first item in the data structure.  The version number
   is intended to avoid ASN.1 decode errors.  Some implementations do
   not check the version number prior to attempting a decode, and if a
   decode error occurs, then the version number is checked as part of
   the error handling routine.  This is a reasonable approach; it places
   error processing outside of the fast path.  This approach is also
   forgiving when an incorrect version number is used by the sender.

   Whenever the structure is updated, a higher version number will be
   assigned.  However, to ensure maximum interoperability the higher
   version number is only used when the new syntax feature is employed.
   That is, the lowest version number that supports the generated syntax
   is used.

2.  Authenticated-enveloped-data Content Type

   The authenticated-enveloped-data content type consists of an
   authenticated and encrypted content of any type and encrypted
   content-encryption keys for one or more recipients.  The combination
   of the authenticated and encrypted content and one encrypted content-
   authenticated-encryption key for a recipient is a "digital envelope"
   for that recipient.  Any type of content can be enveloped for an
   arbitrary number of recipients using any of the supported key



Housley                                                         [Page 2]

INTERNET-DRAFT       AuthEnvelopedData Content Type         January 2007


   management techniques for each recipient.  In addition, authenticated
   but not encrypted attributes may be provided by the originator.

   The typical application of the authenticated-enveloped-data content
   type will represent one or more recipients' digital envelopes on an
   encapsulated content.

   Authenticated-enveloped-data is constructed by the following steps:

      1.  A content-encryption key for a particular content-
      authenticated-encryption algorithm is generated at random.

      2.  The content-authenticated-encryption key is encrypted for each
      recipient.  The details of this encryption depend on the key
      management algorithm used, but four general techniques are
      supported:

         key transport: the content-authenticated-encryption key is
            encrypted in the recipient's public key;

         key agreement: the recipient's public key and the sender's
            private key are used to generate a pairwise symmetric key,
            then the content-authenticated-encryption key is encrypted
            in the pairwise symmetric key;

         symmetric key-encryption keys: the content-authenticated-
            encryption key is encrypted in a previously distributed
            symmetric key-encryption key; and

         passwords: the content-authenticated-encryption key is
            encrypted in a key-encryption key that is derived from a
            password or other shared secret value.

      3.  For each recipient, the encrypted content-authenticated-
      encryption key and other recipient-specific information are
      collected into a RecipientInfo value, defined in Section 6.2 of
      [CMS].

      4.  Any attributes that are to be authenticated but not encrypted
      are collected in the authenticated attributes.

      5.  The attributes collected in step 4 are authenticated and the
      content is authenticated and encrypted with the content-
      authenticated-encryption key.  If the authenticated encryption
      algorithm requires the content to be padded to a multiple of some
      block size, then the padding is added as described in Section 6.3
      of [CMS].




Housley                                                         [Page 3]

INTERNET-DRAFT       AuthEnvelopedData Content Type         January 2007


      6.  Any attributes that are to be provided without authentication
      or encryption are collected in the unauthenticated attributes.

      7.  The RecipientInfo values for all the recipients, the
      authenticated attributes, then unauthenticated attributes, and the
      authenticated and encrypted content are collected together to form
      an AuthEnvelopedData value as defined in Section 2.1.

   A recipient opens the digital envelope by decrypting one of the
   encrypted content-authenticated-encryption keys, and then using the
   recovered key to decrypt and verify the integrity of the
   authenticated and encrypted content as well as verifying the
   integrity of the authenticated attributes.

   This section is divided into three parts.  The first part describes
   the AuthEnvelopedData content type, the second part describes the
   authentication and encryption process, and third part describes the
   key encryption process.

2.1  AuthEnvelopedData Type

   The following object identifier identifies the authenticated-
   enveloped-data content type:

      id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1)
          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
          smime(16) ct(1) 23 }

   The authenticated-enveloped-data content type MUST have ASN.1 type
   AuthEnvelopedData:

      AuthEnvelopedData ::= SEQUENCE {
        version CMSVersion,
        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
        authEncryptedContentInfo EncryptedContentInfo,
        mac MessageAuthenticationCode,
        unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }

   The fields of type AuthEnvelopedData have the following meanings:

      version is the syntax version number.  It MUST be set to 0.

      originatorInfo optionally provides information about the
      originator.  It is present only if required by the key management
      algorithm.  It may contain certificates and CRLs, and the
      OriginatorInfo type is defined in Section 6.1 of [CMS].



Housley                                                         [Page 4]

INTERNET-DRAFT       AuthEnvelopedData Content Type         January 2007


      recipientInfos is a collection of per-recipient information.
      There MUST be at least one element in the collection.  The
      RecipientInfo type is defined in Section 6.2 of [CMS].

      authAttrs optionally contains the authenticated attributes.  The
      AuthenticatedData content type uses the same type to carry
      authenticated attributes.  The AuthAttributes type is defined in
      Section 9.1 of [CMS].  Useful attribute types are defined in
      Section 11 of [CMS].

      authEncryptedContentInfo is the authenticated and encrypted
      content.  The EnvelopedData content type uses the same type to
      carry the encrypted content.  The EncryptedContentInfo type is
      defined in Section 6.1 of [CMS].

      mac is the integrity check value (ICV) or message authentication
      code (MAC) that is generated by the authenticated encryption
      algorithm.  The AuthenticatedData content type uses the same type
      to carry a MAC.  In this case, the MAC covers the authenticated
      attributes and the content directly, and a digest algorithm is not
      used. The MessageAuthenticationCode type is defined in Section 9.1
      of [CMS].

      unauthAttrs optionally contains the unauthenticated attributes.
      The AuthenticatedData content type uses the same type to carry
      unauthenticated attributes.  The UnauthAttributes type is defined
      in Section 9.1 of [CMS].  Useful attribute types are defined in
      Section 11 of [CMS].

2.2.  Authentication and Encryption Process

   The content-authenticated-encryption key for the desired content-
   authenticated-encryption algorithm is randomly generated.

   If the authenticated encryption algorithm requires the content to be
   padded to a multiple of some block size, then the padding MUST be
   added as described in Section 6.3 of [CMS].  This padding method is
   well defined if and only if number of octets in the block size is
   less than 256.

   If optional authenticated attributes are present, then they are DER
   encoded.  The result will be used as the authenticated associated
   data (AAD) input to the authenticated encryption algorithm.

   The inputs to the authenticated encryption algorithm are the content
   (the data, which is padded if necessary), the DER-encoded
   authenticated attributes (the AAD), and the content-authenticated-
   encryption key.  Under control of a content-authenticated-encryption



Housley                                                         [Page 5]

INTERNET-DRAFT       AuthEnvelopedData Content Type         January 2007


   key, the authenticated encryption operation maps an arbitrary string
   of octets (the data) to another string of octets (the ciphertext) and
   it computes an authentication tag over the AAD and the data.  The
   encrypted data is included in the AuthEnvelopedData
   encryptedContentInfo encryptedContent OCTET STRING, and the
   authentication tag is included in the AuthEnvelopedData mac.

2.3.  Key Encryption Process

   The input to the key encryption process -- the value supplied to the
   recipient's key-encryption algorithm -- is just the "value" of the
   content-authenticated-encryption key.

   Any of the aforementioned key management techniques can be used for
   each recipient of the same encrypted content.

3.  Security Considerations

   This specification defines and additional CMS content type.  The
   security considerations provided in [CMS] apply to this content type
   as well.

   Many authenticated encryption algorithms make use of a block cipher
   in counter mode to provide encryption.  When used properly, counter
   mode provides strong confidentiality.  Bellare, Desai, Jokipii,
   Rogaway show in [BDJR] that the privacy guarantees provided by
   counter mode are at least as strong as those for CBC mode when using
   the same block cipher.

   Unfortunately, it is easy to misuse counter mode.  If counter block
   values are ever used for more that one encryption operation with the
   same key, then the same key stream will be used to encrypt both
   plaintexts, and the confidentiality guarantees are voided.

   Fortunately, the CMS AuthEnvelopedData provides all of the tools
   needed to avoid misuse of counter mode.  When using key transport or
   key agreement, a fresh key should be generated for each content.
   However, when using symmetric key-encryption keys or passwords, one
   cannot assume that a fresh key is generated.  Therefore,
   authenticated encryption algorithms that make use of counter mode
   must support the use of an unpredictable nonce value in the counter
   block, and this unpredictable nonce value (sometimes called a "salt")
   must be carried as an algorithm identifier parameter.

   There are fairly generic precomputation attacks against all block
   cipher modes that allow a meet-in-the-middle attack against the key.
   These attacks require the creation and searching of huge tables of
   ciphertext associated with known plaintext and known keys.  Assuming



Housley                                                         [Page 6]

INTERNET-DRAFT       AuthEnvelopedData Content Type         January 2007


   that the memory and processor resources are available for a
   precomputation attack, then the theoretical strength of any block
   cipher mode is limited to 2^(n/2) bits, where n is the number of bits
   in the key.  The use of long keys is the best countermeasure to
   precomputation attacks.  Use of an unpredictable nonce value in the
   counter block significantly increases the size of the table that the
   attacker must compute to mount a successful precomputation attack.

   Implementations must randomly generate content-authenticated-
   encryption keys, padding, and unpredictable nonce values.  Also, the
   generation of public/private key pairs relies on a random numbers.
   The use of inadequate pseudo-random number generators (PRNGs) to
   generate cryptographic keys can result in little or no security.  An
   attacker may find it much easier to reproduce the PRNG environment
   that produced the keys, searching the resulting small set of
   possibilities, rather than brute force searching the whole key space.
   The generation of quality random numbers is difficult.  RFC 4086
   [RANDOM] offers important guidance in this area.

4  ASN.1 Module

   CMS-AuthEnvelopedData-2007
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
       pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31) }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   -- EXPORTS All
   -- The types and values defined in this module are exported for use
   -- in the other ASN.1 modules.  Other applications may use them for
   -- their own purposes.

   IMPORTS

     -- Imports from RFC 3852 [CMS], Section 12.1
           AuthAttributes, CMSVersion, EncryptedContentInfo,
           MessageAuthenticationCode, OriginatorInfo, RecipientInfos,
           UnauthAttributes
              FROM CryptographicMessageSyntax2004
                   { iso(1) member-body(2) us(840) rsadsi(113549)
                     pkcs(1) pkcs-9(9) smime(16) modules(0)
                     cms-2004(24) } ;


   id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1)
       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
       smime(16) ct(1) 23 }



Housley                                                         [Page 7]

INTERNET-DRAFT       AuthEnvelopedData Content Type         January 2007


   AuthEnvelopedData ::= SEQUENCE {
     version CMSVersion,
     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
     recipientInfos RecipientInfos,
     authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
     authEncryptedContentInfo EncryptedContentInfo,
     mac MessageAuthenticationCode,
     unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }


   END -- of CMS-AuthEnvelopedData-2007

5.  Normative References

   [CMS]        Housley, R., "Cryptographic Message Syntax",
                RFC 3852, July 2004.

   [STDWORDS]   Bradner, S., "Key Words for Use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [X.208-88]   CCITT.  Recommendation X.208: Specification of Abstract
                Syntax Notation One (ASN.1).  1988.

   [X.209-88]   CCITT.  Recommendation X.209: Specification of Basic
                Encoding Rules for Abstract Syntax Notation One (ASN.1).
                1988.

   [X.509-88]   CCITT.  Recommendation X.509: The Directory -
                Authentication Framework.  1988.

6.  Informative References

   [BDJR]       Bellare, M, Desai, A., Jokipii, E., and P. Rogaway,
                "A Concrete Security Treatment of Symmetric Encryption:
                Analysis of the DES Modes of Operation", Proceedings
                38th Annual Symposium on Foundations of Computer
                Science, 1997.

   [RANDOM]     Eastlake, D., Schiller, J., and S. Crocker, "Randomness
                Recommendations for Security", RFC 4086, June 2005.











Housley                                                         [Page 8]

INTERNET-DRAFT       AuthEnvelopedData Content Type         January 2007


7.  Authors' Address

   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA
   EMail: housley@vigilsec.com

Full Copyright Statement

   Copyright (C) The Internet Society (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein
   are provided on an "AS IS" basis and THE CONTRIBUTOR, THE
   ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE
   INTERNET SOCIETY, (THE IETF TRUST) AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.









Housley                                                         [Page 9]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/