< draft-ietf-lamps-crmf-update-algs-04.txt		draft-ietf-lamps-crmf-update-algs-05.txt >
	Network Working Group R. Housley		Network Working Group R. Housley
	Internet-Draft Vigil Security		Internet-Draft Vigil Security
	Updates: 4211 (if approved) 19 February 2021		Updates: 4211 (if approved) 30 March 2021
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 23 August 2021		Expires: 1 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-04		draft-ietf-lamps-crmf-update-algs-05
	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 23 August 2021.		This Internet-Draft will expire on 1 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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. Signature Key POP . . . . . . . . . . . . . . . . . . . . . . 2		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 . . . . . . . . . . . . . . . . . . . . 3		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 . . . . . . . . . . . . . . . . . . . . . . 4
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 6		8.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		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. This update specifies algorithms that		considered the best choices:
	are more appropriate today.
			* HMAC-SHA1 [HMAC][SHS] is not boken yet, but there are much
			stronger alternatives [RFC6194].
			* DES-MAC [PKCS11] provides 56 bits of security, which is no longer
			considered secure [WITHDRAW].
			* Triple-DES-MAC [PKCS11] provides 112 bits of security, which is
			now deprecated [TRANSIT].
			This update specifies algorithms that are more appropriate today.
	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 3, line 9 ¶		skipping to change at page 3, line 21 ¶
	OLD:		OLD:
	algId identifies the algorithm used to compute the MAC value. All		algId identifies the algorithm used to compute the MAC value. All
	implementations MUST support id-PasswordBasedMAC. The details on		implementations MUST support id-PasswordBasedMAC. The details on
	this algorithm are presented in section 4.4		this algorithm are presented in section 4.4
	NEW:		NEW:
	algId identifies the algorithm used to compute the MAC value. All		algId identifies the algorithm used to compute the MAC value. All
	implementations MUST support id-PasswordBasedMAC as presented in		implementations MUST support id-PasswordBasedMAC as presented in
	Section 4.4 of this document. Implementations MAY also support		Section 4.4 of [RFC4211]. Implementations MAY also support PBMAC1
	PBMAC1 presented in Section 7.1 of [RFC8018].		presented in Section 7.1 of [RFC8018].
	4. Password-Based Message Authentication Code		4. Password-Based Message Authentication Code
	Section 4.4 of [RFC4211] specifies a Password-Based MAC that relies		Section 4.4 of [RFC4211] specifies a Password-Based MAC that relies
	on a one-way function to compute a symmetric key from the password		on a one-way function to compute a symmetric key from the password
	and a MAC algorithm. This section specifies algorithm requirements		and a MAC algorithm. This section specifies algorithm requirements
	for the one-way function and the MAC algorithm.		for the one-way function and the MAC algorithm.
	4.1. Introduction Paragraph		4.1. Introduction Paragraph
	skipping to change at page 6, line 24 ¶		skipping to change at page 6, line 33 ¶
	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 a 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 [HMAC] and [SHS] for security considerations related to
			HMAC-SHA256.
			Please see [AES] and [GMAC] for security considerations related to
			AES-GMAC.
	Cryptographic algorithms age; they become weaker with time. As new		Cryptographic algorithms age; they become weaker with time. As new
	cryptanalysis techniques are developed and computing capabilities		cryptanalysis techniques are developed and computing capabilities
	improve, the work required to break a particular cryptographic		improve, the work required to break a particular cryptographic
	algorithm will reduce, making an attack on the algorithm more		algorithm will reduce, making an attack on the algorithm more
	feasible for more attackers. While it is unknown how cryptoanalytic		feasible for more attackers. While it is unknown how cryptoanalytic
	attacks will evolve, it is certain that they will get better. It is		attacks will evolve, it is certain that they will get better. It is
	unknown how much better they will become or when the advances will		unknown how much better they will become or when the advances will
	happen. For this reason, the algorithm requirements for CRMF are		happen. For this reason, the algorithm requirements for CRMF are
	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, Tomas Gustavsson, Jonathan Hammell, Tim Hollebeek, Lijun
	Liao, Mike Ounsworth, Tim Polk, Mike StJohns, and Sean Turner for		Liao, Mike Ounsworth, Tim Polk, Ines Robles, Mike StJohns, and Sean
	their careful review and improvements.		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 28 ¶		skipping to change at page 8, line 48 ¶
	[PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards -		[PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards -
	PKCS #11 v2.11: Cryptographic Token Interface Standard",		PKCS #11 v2.11: Cryptographic Token Interface Standard",
	June 2001.		June 2001.
	[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-		[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
	224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",		224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
	RFC 4231, DOI 10.17487/RFC4231, December 2005,		RFC 4231, DOI 10.17487/RFC4231, December 2005,
	<https://www.rfc-editor.org/info/rfc4231>.		<https://www.rfc-editor.org/info/rfc4231>.
			[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
			Considerations for the SHA-0 and SHA-1 Message-Digest
			Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
			<https://www.rfc-editor.org/info/rfc6194>.
			[TRANSIT] National Institute of Standards and Technology,
			"Transitioning the use of cryptographic algorithms and key
			lengths", NIST SP 800-131Ar2, March 2019.
			[WITHDRAW] National Institute of Standards and Technology, "NIST
			Withdraws Outdated Data Encryption Standard", 2 June 2005.
	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. 13 change blocks.
	18 lines changed or deleted		48 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/