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

Versions: 00 01 02 03 RFC 5084

INTERNET DRAFT                                                  R. Housley
S/MIME Working Group                                        Vigil Security
Expires July 2007                                             January 2007


           Using AES-CCM and AES-GCM Authenticated Encryption
               in the Cryptographic Message Syntax (CMS)
             <draft-ietf-smime-cms-aes-ccm-and-gcm-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 specifies the conventions for using the AES-CCM and the
   AES-GCM authenticated encryption algorithms with the Cryptographic
   Message Syntax (CMS) authenticated-enveloped-data content type.













Housley                                                         [Page 1]


INTERNET DRAFT    Using AES-CCM and AES-GCM in the CMS      January 2007


1.  Introduction

   This document specifies the conventions for using AES-CCM and AES-GCM
   authenticated encryption algorithms as the content-authenticated-
   encryption algorithm with the Cryptographic Message Syntax [CMS]
   authenticated-enveloped-data content type [AuthEnv].

1.1.  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 RFC 2119 [STDWORDS].

1.2.  ASN.1

   CMS values are generated using ASN.1 [X.208-88], using the Basic
   Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules
   (DER) [X.509-88].

1.3.  AES

   Dr. Joan Daemen and Dr. Vincent Rijmen, both from Belgium, developed
   the Rijndael block cipher algorithm, and they submitted it for
   consideration as the Advanced Encryption Standard (AES).  Rijndael
   was selected by the National Institute for Standards and Technology
   (NIST), and it is specified in a U.S. Federal Information Processing
   Standard (FIPS) Publication [AES].  NIST selected the Rijndael
   algorithm for AES because it offers a combination of security,
   performance, efficiency, ease of implementation, and flexibility.
   Specifically, the algorithm performs well in both hardware and
   software across a wide range of computing environments.  Also, the
   very low memory requirements of the algorithm make it very well
   suited for restricted-space environments.  The AES is widely used by
   organizations, institutions, and individuals outside of the U.S.
   Government.

   The AES specifies three key sizes: 128, 192, and 256 bits.

1.4.  AES-CCM

   The Counter with CBC-MAC (CCM) mode of operation is specified in
   [CCM].  CCM is a generic authenticated encryption block cipher mode.
   CCM is only defined for use with any 128-bit block cipher, but in
   this document, CCM is only used with the AES block cipher.

   AES-CCM has four inputs: an AES key, a nonce, a plaintext, and
   optional additional authenticated data (AAD).  AES-CCM generates two
   outputs: a ciphertext and an authentication tag.



Housley                                                         [Page 2]


INTERNET DRAFT    Using AES-CCM and AES-GCM in the CMS      January 2007


   Within the scope of any authenticated-encryption key, the nonce value
   MUST be unique.  That is, the set of nonce values used with any given
   key MUST NOT contain any duplicate values.  Using the same nonce for
   two different messages encrypted with the same key destroys the
   security properties.

   AAD is authenticated but not encrypted.  Thus, the AAD is not
   included in the AES-CCM output.  It can be used to authenticate
   plaintext packet headers.  In CMS, authenticated attributes comprise
   the AAD.

1.5.  AES-GCM

   The Galois/Counter Mode (GCM) is specified in [GCM].  GCM is a
   generic authenticated encryption block cipher mode.  GCM is only
   defined for use with any 128-bit block cipher, but in this document,
   GCM is only used with the AES block cipher.

   AES-GCM has four inputs: an AES key, an initialization vector (IV), a
   plaintext content, and optional additional authenticated data (AAD).
   AES-GCM generates two outputs: a ciphertext and an authentication
   tag.  To have a common set of terms for AES-CCM and AES-GCM, the AES-
   GCM IV is referred to as a nonce in the remainder of this document.

   Within the scope of any authenticated-encryption key, the nonce value
   MUST be unique.  That is, the set of nonce values used with any given
   key MUST NOT contain any duplicate values.  Using the same nonce for
   two different messages encrypted with the same key destroys the
   security properties.

   AAD is authenticated but not encrypted.  Thus, the AAD is not
   included in the AES-GCM output.  It can be used to authenticate
   plaintext packet headers.  In CMS, authenticated attributes comprise
   the AAD.

2.  Automatic Key Management

   The reuse of an AES-CCM or AES-GCM nonce/key combination destroys the
   security guarantees.  As a result, it can be extremely difficult to
   use AES-CCM or AES-GCM securely when using statically configured
   keys.  For safety's sake, implementations MUST use an automated key
   management system.









Housley                                                         [Page 3]


INTERNET DRAFT    Using AES-CCM and AES-GCM in the CMS      January 2007


   The CMS authenticated-enveloped-data content type supports four
   general key management techniques:

      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.

   All of these key management techniques meet the automated key
   management system requirement as long as a fresh content-
   authenticated-encryption key is generated for the protection of each
   content.  Note that some of these key management techniques use one
   key-encryption key to encrypt more than one content-authenticated-
   encryption key during the system life cycle.  As long as fresh
   content-authenticated-encryption key is used each time, AES-CCM and
   AES-GCM can be used safely with the CMS authenticated-enveloped-data
   content type.

   In addition to these four general key management techniques, CMS
   supports other key management techniques.  See Section 6.2.5 of
   [CMS].  Since the properties of these key management techniques are
   unknown, no statement can be made about whether these key management
   techniques meet the automated key management system requirement.
   Designers and implementers must perform their own analysis if one of
   these other key management techniques is supported.

3.  Content Authenticated Encryption Algorithms

   This section specifies the conventions employed by CMS
   implementations that support content authenticated encryption using
   AES-CCM or AES-GCM.

   Content authenticated encryption algorithm identifiers are located in
   the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm
   field.





Housley                                                         [Page 4]


INTERNET DRAFT    Using AES-CCM and AES-GCM in the CMS      January 2007


   Content authenticated encryption algorithms are used to encipher the
   content located in the AuthEnvelopedData EncryptedContentInfo
   encryptedContent field and to provide the message authentication code
   for the AuthEnvelopedData mac field.  Note that the message
   authentication code provides integrity protection for both the
   AuthEnvelopedData authAttrs and the AuthEnvelopedData
   EncryptedContentInfo encryptedContent.

3.1.  AES-CCM

   The AES-CCM authenticated encryption algorithm is described in [CCM].
   A brief summary of the properties of AES-CCM is provided in Section
   1.4.  There are three algorithm identifiers for AES-CCM, one for each
   AES key size:

      aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
          organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }

      id-aes128-CCM OBJECT IDENTIFIER ::= { aes 5 }

      id-aes192-CCM OBJECT IDENTIFIER ::= { aes 25 }

      id-aes256-CCM OBJECT IDENTIFIER ::= { aes 45 }

   With all three AES-CCM algorithm identifiers, the AlgorithmIdentifier
   parameters field MUST be present, and the parameters field must
   contain a CCMParameter:

      CCMParameters ::= SEQUENCE {
        aes-nonce         OCTET STRING (SIZE(7..13)),
        aes-ICVlen        AES-CCM-ICVlen DEFAULT 12 }

      AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16)

   The aes-nonce parameter field contains 15-L octets, where L is the
   size of the length field.  With CMS, the normal situation is for the
   content-authenticated-encryption key to be used for a single content,
   therefore L=8 is RECOMMENDED.  See [CCM] for a discussion of the
   trade-off between the maximum content size and the size of the Nonce.
   Within the scope of any content-authenticated-encryption key, the
   nonce value MUST be unique.  That is, the set of nonce values used
   with any given key MUST NOT contain any duplicate values.

   The aes-ICVlen parameter field tells the size of the message
   authentication code.  It MUST match the size in octets of the value
   in the AuthEnvelopedData mac field.  A length of 12 octets is
   RECOMMENDED.




Housley                                                         [Page 5]


INTERNET DRAFT    Using AES-CCM and AES-GCM in the CMS      January 2007


3.2.  AES-GCM

   The AES-GCM authenticated encryption algorithm is described in [GCM].
   A brief summary of the properties of AES-CCM is provided in Section
   1.5.  There are three algorithm identifiers for AES-GCM, one for each
   AES key size:

      aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
          organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }

      id-aes128-GCM OBJECT IDENTIFIER ::= { aes 6 }

      id-aes192-GCM OBJECT IDENTIFIER ::= { aes 26 }

      id-aes256-GCM OBJECT IDENTIFIER ::= { aes 46 }

   With all three AES-GCM algorithm identifiers, the AlgorithmIdentifier
   parameters field MUST be present, and the parameters field must
   contain a GCMParameter:

      GCMParameters ::= SEQUENCE {
        aes-nonce        OCTET STRING, -- recommended size is 12 octets
        aes-ICVlen       AES-GCM-ICVlen DEFAULT 12 }

      AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16)

   The aes-nonce is the AES-GCM initialization vector.  The algorithm
   specification permits the nonce to have any number of bits between 1
   and 2^64.  However, the use of OCTET STRING requires the nonce to be
   a multiple of 8 bits.  Within the scope of any content-authenticated-
   encryption key, the nonce value MUST be unique, but need not have
   equal lengths.  A nonce value of 12 octets can be processed more
   efficiently, so that length is RECOMMENDED.

   The aes-ICVlen parameter field tells the size of the message
   authentication code.  It MUST match the size in octets of the value
   in the AuthEnvelopedData mac field.  A length of 12 octets is
   RECOMMENDED.

4.  Security Considerations

   AES-CCM and AES-GCM make use of the AES 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.




Housley                                                         [Page 6]


INTERNET DRAFT    Using AES-CCM and AES-GCM in the CMS      January 2007


   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.  Automated key management is
   discussed in Section 2.

   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
   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.  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.

5.  References

5.1.  Normative References

   [AES]       NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)",
               November 2001.

   [CCM]       Whiting, D., Housley, R., and N. Ferguson, "Counter with
               CBC-MAC (CCM)", RFC 3610, September 2003.

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

   [GCM]       McGrew, D. and J. Viega, "The Galois/Counter Mode of
               Operation (GCM)", Submission to NIST. January 2004.
               http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/
               gcm/gcm-spec.pdf.



Housley                                                         [Page 7]


INTERNET DRAFT    Using AES-CCM and AES-GCM in the CMS      January 2007


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

5.2.  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.

6.  IANA Considerations

   None.

   {{{ RFC Editor: Please remove this section prior to publication. }}}

Appendix:  ASN.1 Module

   CMS-AES-CCM-and-AES-GCM
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) cms-aes-ccm-and-gcm(32) }

   DEFINITIONS IMPLICIT TAGS ::= BEGIN

   -- EXPORTS All

   -- Object Identifiers

   aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
       organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }

   id-aes128-CCM OBJECT IDENTIFIER ::= { aes 5 }

   id-aes192-CCM OBJECT IDENTIFIER ::= { aes 25 }

   id-aes256-CCM OBJECT IDENTIFIER ::= { aes 45 }

   id-aes128-GCM OBJECT IDENTIFIER ::= { aes 6 }

   id-aes192-GCM OBJECT IDENTIFIER ::= { aes 26 }

   id-aes256-GCM OBJECT IDENTIFIER ::= { aes 46 }





Housley                                                         [Page 8]


INTERNET DRAFT    Using AES-CCM and AES-GCM in the CMS      January 2007


   -- Parameters for AigorithmIdentifier

   CCMParameters ::= SEQUENCE {
     aes-nonce         OCTET STRING (SIZE(7..13)),
     aes-ICVlen        AES-CCM-ICVlen DEFAULT 12 }

   AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16)

   GCMParameters ::= SEQUENCE {
     aes-nonce        OCTET STRING, -- recommended size is 12 octets
     aes-ICVlen       AES-GCM-ICVlen DEFAULT 12 }

   AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16)

   END

Authors' Addresses


   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA

   EMail: housley(at)vigilsec.com

























Housley                                                         [Page 9]


INTERNET DRAFT    Using AES-CCM and AES-GCM in the CMS      January 2007


Copyright and IPR Statements

   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.

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at



Housley                                                        [Page 10]


INTERNET DRAFT    Using AES-CCM and AES-GCM in the CMS      January 2007


   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.












































Housley                                                        [Page 11]


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