< draft-ietf-lamps-crmf-update-algs-05.txt		draft-ietf-lamps-crmf-update-algs-06.txt >
	Network Working Group R. Housley		Network Working Group R. Housley
	Internet-Draft Vigil Security		Internet-Draft Vigil Security
	Updates: 4211 (if approved) 30 March 2021		Updates: 4211 (if approved) 6 April 2021
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 1 October 2021		Expires: 8 October 2021
	Algorithm Requirements Update to the Internet X.509 Public Key		Algorithm Requirements Update to the Internet X.509 Public Key
	Infrastructure Certificate Request Message Format (CRMF)		Infrastructure Certificate Request Message Format (CRMF)
	draft-ietf-lamps-crmf-update-algs-05		draft-ietf-lamps-crmf-update-algs-06
	Abstract		Abstract
	This document updates the cryptographic algorithm requirements for		This document updates the cryptographic algorithm requirements for
	the Password-Based Message Authentication Code in the Internet X.509		the Password-Based Message Authentication Code in the Internet X.509
	Public Key Infrastructure Certificate Request Message Format (CRMF)		Public Key Infrastructure Certificate Request Message Format (CRMF)
	specified in RFC 4211.		specified in RFC 4211.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 1 October 2021.		This Internet-Draft will expire on 8 October 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
			This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Signature Key POP . . . . . . . . . . . . . . . . . . . . . . 3		3. Signature Key POP . . . . . . . . . . . . . . . . . . . . . . 3
	4. Password-Based Message Authentication Code . . . . . . . . . 3		4. Password-Based Message Authentication Code . . . . . . . . . 3
	4.1. Introduction Paragraph . . . . . . . . . . . . . . . . . 3		4.1. Introduction Paragraph . . . . . . . . . . . . . . . . . 3
	4.2. One-Way Function . . . . . . . . . . . . . . . . . . . . 4		4.2. One-Way Function . . . . . . . . . . . . . . . . . . . . 4
	4.3. Iteration Count . . . . . . . . . . . . . . . . . . . . . 4		4.3. Iteration Count . . . . . . . . . . . . . . . . . . . . . 4
	4.4. MAC Algorithm . . . . . . . . . . . . . . . . . . . . . . 4		4.4. MAC Algorithm . . . . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	This document updates the cryptographic algorithm requirements for		This document updates the cryptographic algorithm requirements for
	the Password-Based Message Authentication Code (MAC) in the Internet		the Password-Based Message Authentication Code (MAC) in the Internet
	X.509 Public Key Infrastructure Certificate Request Message Format		X.509 Public Key Infrastructure Certificate Request Message Format
	(CRMF) [RFC4211]. The algorithms specified in [RFC4211] were		(CRMF) [RFC4211]. The algorithms specified in [RFC4211] were
	appropriate in 2005; however, these algorithms are no longer		appropriate in 2005; however, these algorithms are no longer
	considered the best choices:		considered the best choices:
	* HMAC-SHA1 [HMAC][SHS] is not boken yet, but there are much		* HMAC-SHA1 [HMAC][SHS] is not broken yet, but there are much
	stronger alternatives [RFC6194].		stronger alternatives [RFC6194].
	* DES-MAC [PKCS11] provides 56 bits of security, which is no longer		* DES-MAC [PKCS11] provides 56 bits of security, which is no longer
	considered secure [WITHDRAW].		considered secure [WITHDRAW].
	* Triple-DES-MAC [PKCS11] provides 112 bits of security, which is		* Triple-DES-MAC [PKCS11] provides 112 bits of security, which is
	now deprecated [TRANSIT].		now deprecated [TRANSIT].
	This update specifies algorithms that are more appropriate today.		This update specifies algorithms that are more appropriate today.
			CRMF is defined using Abstract Syntax Notation One (ASN.1) [X680].
	2. Terminology		2. 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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Signature Key POP		3. Signature Key POP
	skipping to change at page 5, line 20 ¶		skipping to change at page 5, line 38 ¶
	NEW:		NEW:
	mac identifies the algorithm and associated parameters of the MAC		mac identifies the algorithm and associated parameters of the MAC
	function to be used. All implementations MUST support HMAC-SHA256		function to be used. All implementations MUST support HMAC-SHA256
	[HMAC]. All implementations SHOULD support AES-GMAC AES [GMAC]		[HMAC]. All implementations SHOULD support AES-GMAC AES [GMAC]
	with a 128 bit key.		with a 128 bit key.
	For convenience, the identifiers for these two algorithms are		For convenience, the identifiers for these two algorithms are
	repeated here.		repeated here.
	The algorithm identifier for HMAC-SHA256 is defined in [RFC4231]:		The ASN.1 algorithm identifier for HMAC-SHA256 is defined in
			[RFC4231]:
	id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)		id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) digestAlgorithm(2) 9 }		us(840) rsadsi(113549) digestAlgorithm(2) 9 }
	When this algorithm identifier is used, the parameters SHOULD be		When this object identifier is used in the ASN.1 algorithm
	present. When present, the parameters MUST contain a type of NULL.		identifier, the parameters SHOULD be present. When present, the
			parameters MUST contain a type of NULL.
	The algorithm identifier for AES-GMAC [AES][GMAC] with a 128-bit key		The ASN.1 algorithm identifier for AES-GMAC [AES][GMAC] with a
	is defined in [I-D.ietf-lamps-cms-aes-gmac-alg]:		128-bit key is defined in [I-D.ietf-lamps-cms-aes-gmac-alg]:
	id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)		id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)		country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) aes(1) 9 }		nistAlgorithm(4) aes(1) 9 }
	When this algorithm identifier is used, the parameters MUST be		When this object identifier is used in the ASN.1 algorithm
	present, and the parameters MUST contain the GMACParameters structure		identifier, the parameters MUST be present, and the parameters MUST
	as follows:		contain the GMACParameters structure as follows:
	GMACParameters ::= SEQUENCE {		GMACParameters ::= SEQUENCE {
	nonce OCTET STRING,		nonce OCTET STRING,
	length MACLength DEFAULT 12 }		length MACLength DEFAULT 12 }
	MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16)		MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16)
	The GMACParameters nonce parameter is the GMAC initialization vector.		The GMACParameters nonce parameter is the GMAC initialization vector.
	The nonce may have any number of bits between 8 and (2^64)-1, but it		The nonce may have any number of bits between 8 and (2^64)-1, but it
	MUST be a multiple of 8 bits. Within the scope of any GMAC key, the		MUST be a multiple of 8 bits. Within the scope of any GMAC key, the
	skipping to change at page 6, line 27 ¶		skipping to change at page 6, line 48 ¶
	the hash function is applied as well as the entropy of the shared		the hash function is applied as well as the entropy of the shared
	secret (the password). Hardware support for hash calculation is		secret (the password). Hardware support for hash calculation is
	available at very low cost [PHS], which reduces the protection		available at very low cost [PHS], which reduces the protection
	provided by a high iterationCount value. Therefore, the entropy of		provided by a high iterationCount value. Therefore, the entropy of
	the password is crucial for the security of the password-based MAC		the password is crucial for the security of the password-based MAC
	function. In 2010, researchers showed that about half of the real-		function. In 2010, researchers showed that about half of the real-
	world passwords can be broken with less than 150 million trials,		world passwords can be broken with less than 150 million trials,
	indicating a median entropy of only 27 bits [DMR]. Higher entropy		indicating a median entropy of only 27 bits [DMR]. Higher entropy
	can be achieved by using randomly generated strings. For example,		can be achieved by using randomly generated strings. For example,
	assuming an alphabet of 60 characters a randomly chosen password with		assuming an alphabet of 60 characters a randomly chosen password with
	10 characters offers 59 bits a entropy, and 20 characters offers 118		10 characters offers 59 bits of entropy, and 20 characters offers 118
	bits of entropy. Using a one-time password also increases the		bits of entropy. Using a one-time password also increases the
	security of the MAC, assuming that the integrity-protected		security of the MAC, assuming that the integrity-protected
	transaction will complete before the attacker is able to learn the		transaction will complete before the attacker is able to learn the
	password with an offline attack.		password with an offline attack.
	Please see [RFC8018] for security considerations related to PBMAC1.		Please see [RFC8018] for security considerations related to PBMAC1.
	Please see [HMAC] and [SHS] for security considerations related to		Please see [HMAC] and [SHS] for security considerations related to
	HMAC-SHA256.		HMAC-SHA256.
	skipping to change at page 7, line 13 ¶		skipping to change at page 7, line 31 ¶
	updated by this specification.		updated by this specification.
	When a Password-Based MAC is used, implementations must protect the		When a Password-Based MAC is used, implementations must protect the
	password and the MAC key. Compromise of either the password or the		password and the MAC key. Compromise of either the password or the
	MAC key may result in the ability of an attacker to undermine		MAC key may result in the ability of an attacker to undermine
	authentication.		authentication.
	7. Acknowledgements		7. Acknowledgements
	Many thanks to Hans Aschauer, Hendrik Brockhaus, Quynh Dang, Roman		Many thanks to Hans Aschauer, Hendrik Brockhaus, Quynh Dang, Roman
	Danyliw, Tomas Gustavsson, Jonathan Hammell, Tim Hollebeek, Lijun		Danyliw, Lars Eggert, Tomas Gustavsson, Jonathan Hammell, Tim
	Liao, Mike Ounsworth, Tim Polk, Ines Robles, Mike StJohns, and Sean		Hollebeek, Erik Kline, Lijun Liao, Mike Ounsworth, Francesca
	Turner for their careful review and improvements.		Palombini, Tim Polk, Ines Robles, Mike StJohns, and Sean Turner for
			their careful review and improvements.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[AES] National Institute of Standards and Technology, "Advanced		[AES] National Institute of Standards and Technology, "Advanced
	encryption standard (AES)", DOI 10.6028/nist.fips.197,		encryption standard (AES)", DOI 10.6028/nist.fips.197,
	November 2001, <https://doi.org/10.6028/nist.fips.197>.		November 2001, <https://doi.org/10.6028/nist.fips.197>.
	[GMAC] National Institute of Standards and Technology,		[GMAC] National Institute of Standards and Technology,
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 33 ¶
	<https://www.rfc-editor.org/info/rfc8018>.		<https://www.rfc-editor.org/info/rfc8018>.
	[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>.
	[SHS] National Institute of Standards and Technology, "Secure		[SHS] National Institute of Standards and Technology, "Secure
	Hash Standard", DOI 10.6028/nist.fips.180-4, July 2015,		Hash Standard", DOI 10.6028/nist.fips.180-4, July 2015,
	<https://doi.org/10.6028/nist.fips.180-4>.		<https://doi.org/10.6028/nist.fips.180-4>.
			[X680] ITU-T, "Information technology -- Abstract Syntax Notation
			One (ASN.1): Specification of basic notation",
			Recommendation X.680, 2015.
	8.2. Informative References		8.2. Informative References
	[DIGALM] National Institute of Standards and Technology, "Digital		[DIGALM] National Institute of Standards and Technology, "Digital
	identity guidelines: authentication and lifecycle		identity guidelines: authentication and lifecycle
	management", DOI 10.6028/nist.sp.800-63b, June 2017,		management", DOI 10.6028/nist.sp.800-63b, June 2017,
	<https://doi.org/10.6028/nist.sp.800-63b>.		<https://doi.org/10.6028/nist.sp.800-63b>.
	[DMR] Dell'Amico, M., Michiardi, P., and Y. Roudier, "Password		[DMR] Dell'Amico, M., Michiardi, P., and Y. Roudier, "Password
	Strength: An Empirical Analysis",		Strength: An Empirical Analysis",
	DOI 10.1109/INFCOM.2010.5461951, March 2010,		DOI 10.1109/INFCOM.2010.5461951, March 2010,
End of changes. 16 change blocks.
	19 lines changed or deleted		40 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/