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/