< draft-ietf-lamps-cms-aes-gmac-alg-03.txt		draft-ietf-lamps-cms-aes-gmac-alg-04.txt >
	Network Working Group R. Housley		Network Working Group R. Housley
	Internet-Draft Vigil Security		Internet-Draft Vigil Security
	Intended status: Standards Track 27 January 2021		Intended status: Standards Track 8 March 2021
	Expires: 31 July 2021		Expires: 9 September 2021
	Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)		Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)
	draft-ietf-lamps-cms-aes-gmac-alg-03		draft-ietf-lamps-cms-aes-gmac-alg-04
	Abstract		Abstract
	This document specifies the conventions for using the AES-GMAC		This document specifies the conventions for using the AES-GMAC
	Message Authentication Code algorithms with the Cryptographic Message		Message Authentication Code algorithms with the Cryptographic Message
	Syntax (CMS) as specified in RFC 5652.		Syntax (CMS) as specified in RFC 5652.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 31 July 2021.		This Internet-Draft will expire on 9 September 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. Message Authentication Code Algorithms . . . . . . . . . . . 2		3. Message Authentication Code Algorithms . . . . . . . . . . . 2
	3.1. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . . . 2		3.1. AES-GMAC . . . . . . . . . . . . . . . . . . . . . . . . 2
	4. Implementation Considerations . . . . . . . . . . . . . . . . 3		4. Implementation Considerations . . . . . . . . . . . . . . . . 3
	5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 4		5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 4
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 5		7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	8.1. Normative References . . . . . . . . . . . . . . . . . . 6		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8.2. Informative References . . . . . . . . . . . . . . . . . 6		9.1. Normative References . . . . . . . . . . . . . . . . . . 6
			9.2. Informative References . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	This document specifies the conventions for using the AES-GMAC		This document specifies the conventions for using the AES-GMAC
	[AES][GCM] Message Authentication Code (MAC) algorithm with the		[AES][GCM] Message Authentication Code (MAC) algorithm with the
	Cryptographic Message Syntax (CMS) [RFC5652].		Cryptographic Message Syntax (CMS) [RFC5652].
	2. Terminology		2. Terminology
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 44 ¶
	data origin authentication is not provided. Any party that knows the		data origin authentication is not provided. Any party that knows the
	message-authentication key can compute a valid MAC, therefore the		message-authentication key can compute a valid MAC, therefore the
	content could originate from any one of the parties.		content could originate from any one of the parties.
	Within the scope of any content-authentication key, the AES-GMAC		Within the scope of any content-authentication key, the AES-GMAC
	nonce value MUST be unique. Use of a nonce value more than once		nonce value MUST be unique. Use of a nonce value more than once
	allows an attacker to generate valid AES-GMAC authentication codes		allows an attacker to generate valid AES-GMAC authentication codes
	for arbitrary messages, resulting in the loss of authentication as		for arbitrary messages, resulting in the loss of authentication as
	described in Appendix A of [GCM].		described in Appendix A of [GCM].
			Within the scope of any content-authentication key, the
			authentication tag length (MACLength) MUST be fixed.
			When IV lengths other than 96 bits are used, the GHASH function is
			used to process the provided IV, which introduces a potential of IV
			collisions. However, IV collisions are not a concern with CMS
			AuthenticatedData because a fresh content-authentication key is
			usually generated for each message.
			The probability of a successful forgery is close to 2^(-t), where t
			is the number of bits in the authentication tag length (MACLength*8).
			This nearly ideal authentication protection is achieved for CMS
			AuthenticatedData when a fresh content-authentication key is
			generated for each message. However, the strength of GMAC degrades
			slightly as a function of the length of the message being
			authenticated [F2005][MV2005]. Implementations SHOULD use 16-octet
			authentication tags for messages over 2^64 octets.
	Implementations must randomly generate message-authentication keys.		Implementations must randomly generate message-authentication keys.
	The use of inadequate pseudo-random number generators (PRNGs) to		The use of inadequate pseudo-random number generators (PRNGs) to
	generate keys can result in little or no security. An attacker may		generate keys can result in little or no security. An attacker may
	find it much easier to reproduce the PRNG environment that produced		find it much easier to reproduce the PRNG environment that produced
	the keys, searching the resulting small set of possibilities, rather		the keys, searching the resulting small set of possibilities, rather
	than brute force searching the whole key space. The generation of		than brute force searching the whole key space. The generation of
	quality random numbers is difficult. [RFC4086] offers important		quality random numbers is difficult. [RFC4086] offers important
	guidance in this area.		guidance in this area.
	Implementers should be aware that cryptographic algorithms become		Implementers should be aware that cryptographic algorithms become
	weaker with time. As new cryptanalysis techniques are developed and		weaker with time. As new cryptanalysis techniques are developed and
	computing performance improves, the work factor to break a particular		computing performance improves, the work factor to break a particular
	cryptographic algorithm will reduce. Therefore, cryptographic		cryptographic algorithm will reduce. Therefore, cryptographic
	algorithm implementations should be modular allowing new algorithms		algorithm implementations should be modular allowing new algorithms
	to be readily inserted. That is, implementers should be prepared to		to be readily inserted. That is, implementers should be prepared to
	regularly update the set of algorithms in their implementations.		regularly update the set of algorithms in their implementations.
			More information is available in BCP 201 [RFC7696].
	8. References		8. Acknowledgements
	8.1. Normative References		Many thanks to Quynh Dang, Roman Danyliw, Tim Hollebeek, Ben Kaduk,
			Mike Ounsworth, and Magnus Westerlund for their careful review and
			thoughtful improvements.
			9. References
			9.1. Normative References
	[AES] National Institute of Standards and Technology (NIST),		[AES] National Institute of Standards and Technology (NIST),
	"Advanced Encryption Standard (AES)", FIPS		"Advanced Encryption Standard (AES)", FIPS
	Publication 197, November 2001.		Publication 197, November 2001.
	[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of		[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
	Operation: Galois/Counter Mode (GCM) and GMAC", NIST		Operation: Galois/Counter Mode (GCM) and GMAC", NIST
	Special Publication 800-38D, November 2007.		Special Publication 800-38D, November 2007.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,		[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
	RFC 5652, DOI 10.17487/RFC5652, September 2009,		RFC 5652, DOI 10.17487/RFC5652, September 2009,
	<https://www.rfc-editor.org/info/rfc5652>.		<https://www.rfc-editor.org/info/rfc5652>.
			[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
			Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
			DOI 10.17487/RFC5912, June 2010,
			<https://www.rfc-editor.org/info/rfc5912>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	8.2. Informative References		9.2. Informative References
			[F2005] Ferguson, N., "Authentication weaknesses in GCM", 20 May
			2005, <https://csrc.nist.gov/csrc/media/projects/block-
			cipher-techniques/documents/bcm/comments/cwc-gcm/
			ferguson2.pdf>. Comments to the NIST Modes of Operation
			process.
			[MV2005] McGrew, D. and J. Viega, "GCM Update", 31 May 2005,
			<https://csrc.nist.gov/CSRC/media/Projects/Block-Cipher-
			Techniques/documents/BCM/Comments/CWC-GCM/gcm-update.pdf>.
			Comments to the NIST Modes of Operation process.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<https://www.rfc-editor.org/info/rfc4086>.		<https://www.rfc-editor.org/info/rfc4086>.
	[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated		[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated
	Encryption in the Cryptographic Message Syntax (CMS)",		Encryption in the Cryptographic Message Syntax (CMS)",
	RFC 5084, DOI 10.17487/RFC5084, November 2007,		RFC 5084, DOI 10.17487/RFC5084, November 2007,
	<https://www.rfc-editor.org/info/rfc5084>.		<https://www.rfc-editor.org/info/rfc5084>.
	[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the		[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
	Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,		Agility and Selecting Mandatory-to-Implement Algorithms",
	DOI 10.17487/RFC5912, June 2010,		BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
	<https://www.rfc-editor.org/info/rfc5912>.		<https://www.rfc-editor.org/info/rfc7696>.
	Author's Address		Author's Address
	Russ Housley		Russ Housley
	Vigil Security, LLC		Vigil Security, LLC
	516 Dranesville Road		516 Dranesville Road
	Herndon, VA, 20170		Herndon, VA, 20170
	United States of America		United States of America
	Email: housley@vigilsec.com		Email: housley@vigilsec.com
End of changes. 12 change blocks.
	15 lines changed or deleted		56 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/