draft-ietf-smime-cms-aes-ccm-and-gcm-03.txt   rfc5084.txt 
INTERNET DRAFT R. Housley Network Working Group R. Housley
S/MIME Working Group Vigil Security Request for Comments: 5084 Vigil Security
Expires March 2008 September 2007 Category: Standards Track November 2007
Using AES-CCM and AES-GCM Authenticated Encryption Using AES-CCM and AES-GCM Authenticated Encryption
in the Cryptographic Message Syntax (CMS) in the Cryptographic Message Syntax (CMS)
<draft-ietf-smime-cms-aes-ccm-and-gcm-03.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 as "work in progress."
The list of current Internet-Drafts can be accessed at Status of This Memo
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
This document specifies the conventions for using the AES-CCM and the This document specifies the conventions for using the AES-CCM and the
AES-GCM authenticated encryption algorithms with the Cryptographic AES-GCM authenticated encryption algorithms with the Cryptographic
Message Syntax (CMS) authenticated-enveloped-data content type. Message Syntax (CMS) authenticated-enveloped-data content type.
1. Introduction 1. Introduction
This document specifies the conventions for using AES-CCM and AES-GCM This document specifies the conventions for using Advanced Encryption
authenticated encryption algorithms as the content-authenticated- Standard-Counter with Cipher Block Chaining-Message Authentication
encryption algorithm with the Cryptographic Message Syntax [CMS] Code (AES-CCM) and AES-Galois/Counter Mode (GCM) authenticated
authenticated-enveloped-data content type [AuthEnv]. encryption algorithms as the content-authenticated-encryption
algorithm with the Cryptographic Message Syntax [CMS] authenticated-
enveloped-data content type [AuthEnv].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [STDWORDS]. document are to be interpreted as described in RFC 2119 [STDWORDS].
1.2. ASN.1 1.2. ASN.1
CMS values are generated using ASN.1 [X.208-88], using the Basic CMS values are generated using ASN.1 [X.208-88], which uses the Basic
Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules
(DER) [X.509-88]. (DER) [X.509-88].
1.3. AES 1.3. AES
Dr. Joan Daemen and Dr. Vincent Rijmen, both from Belgium, developed Dr. Joan Daemen and Dr. Vincent Rijmen, both from Belgium, developed
the Rijndael block cipher algorithm, and they submitted it for the Rijndael block cipher algorithm, and they submitted it for
consideration as the Advanced Encryption Standard (AES). Rijndael consideration as the Advanced Encryption Standard (AES). Rijndael
was selected by the National Institute for Standards and Technology was selected by the National Institute for Standards and Technology
(NIST), and it is specified in a U.S. Federal Information Processing (NIST), and it is specified in a U.S. Federal Information Processing
skipping to change at page 3, line 50 skipping to change at page 3, line 26
included in the AES-GCM output. It can be used to authenticate included in the AES-GCM output. It can be used to authenticate
plaintext packet headers. In the CMS authenticated-enveloped-data plaintext packet headers. In the CMS authenticated-enveloped-data
content type, authenticated attributes comprise the AAD. content type, authenticated attributes comprise the AAD.
2. Automated Key Management 2. Automated Key Management
The reuse of an AES-CCM or AES-GCM nonce/key combination destroys the 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 security guarantees. As a result, it can be extremely difficult to
use AES-CCM or AES-GCM securely when using statically configured use AES-CCM or AES-GCM securely when using statically configured
keys. For safety's sake, implementations MUST use an automated key keys. For safety's sake, implementations MUST use an automated key
management system [KeyMgmt]. management system [KEYMGMT].
The CMS authenticated-enveloped-data content type supports four The CMS authenticated-enveloped-data content type supports four
general key management techniques: general key management techniques:
Key Transport: the content-authenticated-encryption key is Key Transport: the content-authenticated-encryption key is
encrypted in the recipient's public key; encrypted in the recipient's public key;
Key Agreement: the recipient's public key and the sender's Key Agreement: the recipient's public key and the sender's
private key are used to generate a pairwise symmetric key, then private key are used to generate a pairwise symmetric key, then
the content-authenticated-encryption key is encrypted in the the content-authenticated-encryption key is encrypted in the
skipping to change at page 4, line 42 skipping to change at page 4, line 17
content type. content type.
In addition to these four general key management techniques, CMS In addition to these four general key management techniques, CMS
supports other key management techniques. See Section 6.2.5 of supports other key management techniques. See Section 6.2.5 of
[CMS]. Since the properties of these key management techniques are [CMS]. Since the properties of these key management techniques are
unknown, no statement can be made about whether these key management unknown, no statement can be made about whether these key management
techniques meet the automated key management system requirement. techniques meet the automated key management system requirement.
Designers and implementers must perform their own analysis if one of Designers and implementers must perform their own analysis if one of
these other key management techniques is supported. these other key management techniques is supported.
3. Content Authenticated Encryption Algorithms 3. Content-Authenticated Encryption Algorithms
This section specifies the conventions employed by CMS This section specifies the conventions employed by CMS
implementations that support content authenticated encryption using implementations that support content-authenticated encryption using
AES-CCM or AES-GCM. AES-CCM or AES-GCM.
Content authenticated encryption algorithm identifiers are located in Content-authenticated encryption algorithm identifiers are located in
the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm
field. field.
Content authenticated encryption algorithms are used to encipher the Content-authenticated encryption algorithms are used to encipher the
content located in the AuthEnvelopedData EncryptedContentInfo content located in the AuthEnvelopedData EncryptedContentInfo
encryptedContent field and to provide the message authentication code encryptedContent field and to provide the message authentication code
for the AuthEnvelopedData mac field. Note that the message for the AuthEnvelopedData mac field. Note that the message
authentication code provides integrity protection for both the authentication code provides integrity protection for both the
AuthEnvelopedData authAttrs and the AuthEnvelopedData AuthEnvelopedData authAttrs and the AuthEnvelopedData
EncryptedContentInfo encryptedContent. EncryptedContentInfo encryptedContent.
3.1. AES-CCM 3.1. AES-CCM
The AES-CCM authenticated encryption algorithm is described in [CCM]. The AES-CCM authenticated encryption algorithm is described in [CCM].
skipping to change at page 5, line 47 skipping to change at page 5, line 30
CCMParameters ::= SEQUENCE { CCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING (SIZE(7..13)), aes-nonce OCTET STRING (SIZE(7..13)),
aes-ICVlen AES-CCM-ICVlen DEFAULT 12 } aes-ICVlen AES-CCM-ICVlen DEFAULT 12 }
AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16) AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16)
The aes-nonce parameter field contains 15-L octets, where L is the The aes-nonce parameter field contains 15-L octets, where L is the
size of the length field. With the CMS, the normal situation is for size of the length field. With the CMS, the normal situation is for
the content-authenticated-encryption key to be used for a single the content-authenticated-encryption key to be used for a single
content, therefore L=8 is RECOMMENDED. See [CCM] for a discussion of content; therefore, L=8 is RECOMMENDED. See [CCM] for a discussion
the trade-off between the maximum content size and the size of the of the trade-off between the maximum content size and the size of the
Nonce. Within the scope of any content-authenticated-encryption key, nonce. Within the scope of any content-authenticated-encryption key,
the nonce value MUST be unique. That is, the set of nonce values the nonce value MUST be unique. That is, the set of nonce values
used with any given key MUST NOT contain any duplicate values. used with any given key MUST NOT contain any duplicate values.
The aes-ICVlen parameter field tells the size of the message The aes-ICVlen parameter field tells the size of the message
authentication code. It MUST match the size in octets of the value authentication code. It MUST match the size in octets of the value
in the AuthEnvelopedData mac field. A length of 12 octets is in the AuthEnvelopedData mac field. A length of 12 octets is
RECOMMENDED. RECOMMENDED.
3.2. AES-GCM 3.2. AES-GCM
skipping to change at page 7, line 9 skipping to change at page 6, line 44
The aes-ICVlen parameter field tells the size of the message The aes-ICVlen parameter field tells the size of the message
authentication code. It MUST match the size in octets of the value authentication code. It MUST match the size in octets of the value
in the AuthEnvelopedData mac field. A length of 12 octets is in the AuthEnvelopedData mac field. A length of 12 octets is
RECOMMENDED. RECOMMENDED.
4. Security Considerations 4. Security Considerations
AES-CCM and AES-GCM make use of the AES block cipher in counter mode AES-CCM and AES-GCM make use of the AES block cipher in counter mode
to provide encryption. When used properly, counter mode provides to provide encryption. When used properly, counter mode provides
strong confidentiality. Bellare, Desai, Jokipii, Rogaway show in strong confidentiality. Bellare, Desai, Jokipii, and Rogaway show in
[BDJR] that the privacy guarantees provided by counter mode are at [BDJR] that the privacy guarantees provided by counter mode are at
least as strong as those for CBC mode when using the same block least as strong as those for Cipher Block Chaining (CBC) mode when
cipher. using the same block cipher.
Unfortunately, it is easy to misuse counter mode. If counter block Unfortunately, it is easy to misuse counter mode. If counter block
values are ever used for more that one encryption operation with the values are ever used for more than one encryption operation with the
same key, then the same key stream will be used to encrypt both same key, then the same key stream will be used to encrypt both
plaintexts, and the confidentiality guarantees are voided. plaintexts, and the confidentiality guarantees are voided.
Fortunately, the CMS AuthEnvelopedData provides all of the tools Fortunately, the CMS AuthEnvelopedData provides all the tools needed
needed to avoid misuse of counter mode. Automated key management is to avoid misuse of counter mode. Automated key management is
discussed in Section 2. discussed in Section 2.
There are fairly generic precomputation attacks against the use of There are fairly generic precomputation attacks against the use of
any block cipher in counter mode that allow a meet-in-the-middle any block cipher in counter mode that allow a meet-in-the-middle
attack against the key [H][B][MF]. AES-CCM and AES-GCM both make use attack against the key [H][B][MF]. AES-CCM and AES-GCM both make use
of counter mode for encryption. These precomputation attacks require of counter mode for encryption. These precomputation attacks require
the creation and searching of huge tables of ciphertext associated the creation and searching of huge tables of ciphertext associated
with known plaintext and known keys. Assuming that the memory and with known plaintext and known keys. Assuming that the memory and
processor resources are available for a precomputation attack, then processor resources are available for a precomputation attack, then
the theoretical strength of any block cipher in counter mode is the theoretical strength of any block cipher in counter mode is
limited to 2^(n/2) bits, where n is the number of bits in the key. 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 The use of long keys is the best countermeasure to precomputation
attacks. Use of an unpredictable nonce value in the counter block attacks. Use of an unpredictable nonce value in the counter block
significantly increases the size of the table that the attacker must significantly increases the size of the table that the attacker must
compute to mount a successful precomputation attack. compute to mount a successful precomputation attack.
Implementations must randomly generate content-authenticated- Implementations must randomly generate content-authenticated-
encryption keys. The use of inadequate pseudo-random number encryption keys. The use of inadequate pseudo-random number
generators (PRNGs) to generate cryptographic keys can result in generators (PRNGs) to generate cryptographic keys can result in
little or no security. An attacker may find it much easier to little or no security. An attacker may find it much easier to
reproduce the PRNG environment that produced the keys, searching the reproduce the PRNG environment that produced the keys, and then
resulting small set of possibilities, rather than brute force searching the resulting small set of possibilities, rather than brute
searching the whole key space. The generation of quality random force searching the whole key space. The generation of quality
numbers is difficult. RFC 4086 [RANDOM] offers important guidance in random numbers is difficult. RFC 4086 [RANDOM] offers important
this area. guidance in this area.
5. References 5. References
5.1. Normative References 5.1. Normative References
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)", [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)",
November 2001. November 2001.
[CCM] Whiting, D., Housley, R., and N. Ferguson, "Counter with [CCM] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003. CBC-MAC (CCM)", RFC 3610, September 2003.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
RFC 3852, July 2004. 3852, July 2004.
[GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of
Operation (GCM)", Submission to NIST, May 2005.
http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/
gcm/gcm-revised-spec.pdf.
[STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate [GCM] Dworkin, M., "NIST Special Publication 800-38D:
Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC." , U.S. National
Institute of Standards and Technology
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-
800-38D.pdf
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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.
5.2. Informative References 5.2. Informative References
[B] Biham, E., "How to Forge DES-Encrypted Messages in [AuthEnv] Housley, R., "Cryptographic Message Syntax (CMS)
2^28 Steps", Technion Computer Science Department Authenticated-Enveloped-Data Content Type", RFC 5083,
Technical Report CS0884, 1996. November 2007.
[BDJR] Bellare, M, Desai, A., Jokipii, E., and P. Rogaway, [B] Biham, E., "How to Forge DES-Encrypted Messages in 2^28
"A Concrete Security Treatment of Symmetric Encryption: Steps", Technion Computer Science Department Technical
Analysis of the DES Modes of Operation", Proceedings Report CS0884, 1996.
38th Annual Symposium on Foundations of Computer
Science, 1997. [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.
[H] Hellman, M. E., "A cryptanalytic time-memory trade-off", [H] Hellman, M. E., "A cryptanalytic time-memory trade-off",
IEEE Transactions on Information Theory, July 1980, IEEE Transactions on Information Theory, July 1980, pp.
pp. 401-406. 401-406.
[KEYMGMT] Bellovin, S. and R. Housley, "Guidelines for [KEYMGMT] Bellovin, S. and R. Housley, "Guidelines for
Cryptographic Key Management", RFC 4107, BCP 107, Cryptographic Key Management", BCP 107, RFC 4107, June
June 2005. 2005.
[MF] McGrew, D., and S. Fluhrer, "Attacks on Additive [MF] McGrew, D., and S. Fluhrer, "Attacks on Additive
Encryption of Redundant Plaintext and Implications on Encryption of Redundant Plaintext and Implications on
Internet Security", The Proceedings of the Seventh Internet Security", The Proceedings of the Seventh Annual
Annual Workshop on Selected Areas in Cryptography Workshop on Selected Areas in Cryptography (SAC 2000),
(SAC 2000), Springer-Verlag, August, 2000. Springer-Verlag, August, 2000.
[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. }}} [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
Appendix: ASN.1 Module Appendix: ASN.1 Module
CMS-AES-CCM-and-AES-GCM CMS-AES-CCM-and-AES-GCM
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-aes-ccm-and-gcm(32) } pkcs-9(9) smime(16) modules(0) cms-aes-ccm-and-gcm(32) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
-- EXPORTS All -- EXPORTS All
skipping to change at page 10, line 5 skipping to change at page 10, line 5
AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16) AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16)
GCMParameters ::= SEQUENCE { GCMParameters ::= SEQUENCE {
aes-nonce OCTET STRING, -- recommended size is 12 octets aes-nonce OCTET STRING, -- recommended size is 12 octets
aes-ICVlen AES-GCM-ICVlen DEFAULT 12 } aes-ICVlen AES-GCM-ICVlen DEFAULT 12 }
AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16) AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16)
END END
Authors' Addresses Author's Address
Russell Housley Russell Housley
Vigil Security, LLC Vigil Security, LLC
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
EMail: housley@vigilsec.com EMail: housley@vigilsec.com
Copyright and IPR Statements Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. 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 This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
 End of changes. 30 change blocks. 
98 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/