< draft-ietf-curdle-ssh-kex-sha2-12.txt		draft-ietf-curdle-ssh-kex-sha2-13.txt >
	Internet Engineering Task Force M. D. Baushke		Internet Engineering Task Force M. D. Baushke
	Internet-Draft Juniper Networks, Inc.		Internet-Draft Juniper Networks, Inc.
	Updates: 4250 (if approved) 23 November 2020		Updates: 4250 4253 4432 4462 (if approved) 14 January 2021
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 27 May 2021		Expires: 18 July 2021
	Key Exchange (KEX) Method Updates and Recommendations for Secure Shell		Key Exchange (KEX) Method Updates and Recommendations for Secure Shell
	(SSH)		(SSH)
	draft-ietf-curdle-ssh-kex-sha2-12		draft-ietf-curdle-ssh-kex-sha2-13
	Abstract		Abstract
	This document is intended to update the recommended set of key		This document is intended to update the recommended set of key
	exchange methods for use in the Secure Shell (SSH) protocol to meet		exchange methods for use in the Secure Shell (SSH) protocol to meet
	evolving needs for stronger security. This document updates RFC		evolving needs for stronger security. This document updates RFC
	4250.		4250, RFC 4253, RFC 4432, and RFC 4462.
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 27 May 2021.		This Internet-Draft will expire on 18 July 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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. Overview and Rationale . . . . . . . . . . . . . . . . . . . 2		1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 2
	1.1. Selecting an appropriate hashing algorithm . . . . . . . 3		1.1. Selecting an appropriate hashing algorithm . . . . . . . 3
	1.2. Selecting an appropriate Public Key Algorithm . . . . . . 3		1.2. Selecting an appropriate Public Key Algorithm . . . . . . 3
	1.2.1. Elliptic Curve Cryptography (ECC) . . . . . . . . . . 4		1.2.1. Elliptic Curve Cryptography (ECC) . . . . . . . . . . 4
	1.2.2. Finite Field Cryptography (FFC) . . . . . . . . . . . 4		1.2.2. Finite Field Cryptography (FFC) . . . . . . . . . . . 4
	1.2.3. Integer Factorization Cryptography (IFC) . . . . . . 5		1.2.3. Integer Factorization Cryptography (IFC) . . . . . . 5
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
	3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 5		3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 6
	3.1. SHA-1 and SHA-2 Hashing . . . . . . . . . . . . . . . . . 6		3.1. SHA-1 and SHA-2 Hashing . . . . . . . . . . . . . . . . . 6
	3.2. Elliptic Curve Cryptography (ECC) . . . . . . . . . . . . 6		3.2. Elliptic Curve Cryptography (ECC) . . . . . . . . . . . . 6
	3.2.1. curve25519-sha256 and gss-curve25519-sha256-* . . . . 6		3.2.1. curve25519-sha256 and gss-curve25519-sha256-* . . . . 6
	3.2.2. curve448-sha512 and gss-curve448-sha512-* . . . . . . 7		3.2.2. curve448-sha512 and gss-curve448-sha512-* . . . . . . 7
	3.2.3. ECC diffie-hellman using ecdh-*, ecmqv-sha2, and		3.2.3. ECC diffie-hellman using ecdh-*, ecmqv-sha2, and
	gss-nistp* . . . . . . . . . . . . . . . . . . . . . 7		gss-nistp* . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Finite Field Cryptography (FFC) . . . . . . . . . . . . . 8		3.3. Finite Field Cryptography (FFC) . . . . . . . . . . . . . 8
	3.3.1. FFC diffie-hellman using generated MODP groups . . . 8		3.3.1. FFC diffie-hellman using generated MODP groups . . . 8
	3.3.2. FFC diffie-hellman using named MODP groups . . . . . 8		3.3.2. FFC diffie-hellman using named MODP groups . . . . . 8
	3.4. Integer Factorization Cryptography (IFC) . . . . . . . . 9		3.4. Integer Factorization Cryptography (IFC) . . . . . . . . 9
	skipping to change at page 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Overview and Rationale		1. Overview and Rationale
	Secure Shell (SSH) is a common protocol for secure communication on		Secure Shell (SSH) is a common protocol for secure communication on
	the Internet. In [RFC4253], SSH originally defined two Key Exchange		the Internet. In [RFC4253], SSH originally defined two Key Exchange
	(KEX) Method Names that MUST be implemented. Over time what was once		(KEX) Method Names that MUST be implemented. Over time what was once
	considered secure is no longer considered secure. The purpose of		considered secure is no longer considered secure. The purpose of
	this RFC is to recommend that some published key exchanges be		this RFC is to recommend that some published key exchanges be
	deprecated as well as recommending some that SHOULD and one that MUST		deprecated as well as recommending some that SHOULD and one that MUST
	be adopted. This document updates [RFC4250].		be adopted. This document updates [RFC4250] [RFC4253] [RFC4432]
			[RFC4462] by changing the requirement level ("MUST" moving to
			"SHOULD" or "MAY" or "SHOULD NOT", and "MAY" moving to "MUST" or
			"SHOULD" or "SHOULD NOT" or "MUST NOT") of various key-exchange
			mechanisms.
	A key exchange has two components, a hashing algorithm and a public		A key exchange has two components, a hashing algorithm and a public
	key algorithm. The following subsections describe how to select each		key algorithm. The following subsections describe how to select each
	component.		component.
	1.1. Selecting an appropriate hashing algorithm		1.1. Selecting an appropriate hashing algorithm
	The SHA-1 hash is in the process of being deprecated for many		The SHA-1 hash is in the process of being deprecated for many
	reasons. There have been attacks against SHA-1 that have shown there		reasons. There have been attacks against SHA-1 that have shown there
	are weaknesses in the algorithm. Therefore, it is desirable to move		are weaknesses in the algorithm. Therefore, it is desirable to move
	away from using it before attacks become more serious.		away from using it before attacks become more serious.
	At present, the attacks against SHA-1 are collision attacks that rely		At present, the attacks against SHA-1 are collision attacks that
	on human help rather than a pre-image attack. So, it is still		usually rely on human help rather than a pre-image attack. SHA-1
	possible to allow time backward compatibility use of SHA-1 during a		resistance against 2nd pre-image is still at 160 bits, but SSH does
	SSH key-exchange for a transition to stronger hashing. However, any		not depend on that, but rather on chosen prefix resistance.
	such key exchanges should be listed last in the preference list.
			Transcript Collision attacks are documented in [TRANS-COLL]. This
			paper shows that the man in the middle does not tamper with the
			Diffie-Hellman values and does not know the connection keys.
			However, it manages to tamper with both Ic and Is, and can therefore
			downgrade the negotiated ciphersuite to a weak cryptographic
			algorithm that the attacker knows how to break.
			These attacks are still computationally very difficult to perform,
			but is is desirable that any Key Exchanging using SHA-1 be phased out
			as soon as possible.
			These attacks are potentially slightly easier when the server
			provides the Diffie-Hellman parameters such as using the [RFC4419]
			generated set of diffie-hellman parameters with SHA-1 hashing. If
			there is a need for using SHA-1 in a Key Exchange for compatibility,
			it would be desirable it be listed last in the preference list of key
			exchanges.
	Use of the SHA-2 family of hashes found in [RFC6234] rather than the		Use of the SHA-2 family of hashes found in [RFC6234] rather than the
	SHA-1 hash is strongly advised.		SHA-1 hash is strongly advised.
	When it comes to the SHA-2 family of Secure Hashing functions,		When it comes to the SHA-2 family of Secure Hashing functions,
	SHA2-224 has 112 bits of security strength; SHA2-256 has 128 bits of		SHA2-224 has 112 bits of security strength; SHA2-256 has 128 bits of
	security strength; SHA2-384 has 192 bits of security strength; and		security strength; SHA2-384 has 192 bits of security strength; and
	SHA2-512 has 256 bits of security strength. As the same compute		SHA2-512 has 256 bits of security strength. As the same compute
	power is needed for both SHA2-224 and SHA2-256 and currently no KeX		power is needed for both SHA2-224 and SHA2-256 and currently no KeX
	uses SHA2-224, it is suggested that the minimum secure hashing		uses SHA2-224, it is suggested that the minimum secure hashing
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 30 ¶
	Table 2: FFC MODP Security Strengths		Table 2: FFC MODP Security Strengths
	The minimum MODP group that MAY be used is the 2048-bit MODP group14.		The minimum MODP group that MAY be used is the 2048-bit MODP group14.
	Implementations SHOULD support a 3072-bit MODP group or larger.		Implementations SHOULD support a 3072-bit MODP group or larger.
	1.2.3. Integer Factorization Cryptography (IFC)		1.2.3. Integer Factorization Cryptography (IFC)
	The only IFC algorithm for key exchange is the RSA algorithm via		The only IFC algorithm for key exchange is the RSA algorithm via
	[RFC4432]. The minimum modulus size is 2048 bits. The use of a		[RFC4432]. The minimum modulus size is 2048 bits. The use of a
	SHA-2 Family hash with RSA 2048-bit keys has sufficient security.		SHA-2 Family hash with RSA 2048-bit keys has sufficient security.
			The rsa1024-sha1 key exchange has less than 2048 bits and MUST NOT be
			implemented.
	+=====================+=============================+		+=====================+=============================+
	| Key Exchange Method | Estimated Security Strength |		| Key Exchange Method | Estimated Security Strength |
	+=====================+=============================+		+=====================+=============================+
	| rsa1024-sha1 | 80 bits |		| rsa1024-sha1 | 80 bits |
	+---------------------+-----------------------------+		+---------------------+-----------------------------+
	| rsa2048-sha256 | 112 bits |		| rsa2048-sha256 | 112 bits |
	+---------------------+-----------------------------+		+---------------------+-----------------------------+
	Table 3: IFC Security Strengths		Table 3: IFC Security Strengths
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 33 ¶
	deprecated and phased out of use because SHA-1 has security concerns		deprecated and phased out of use because SHA-1 has security concerns
	provided in [RFC6194]. The SHA-2 Family of hashes [RFC6234] is the		provided in [RFC6194]. The SHA-2 Family of hashes [RFC6234] is the
	only one which is more secure than SHA-1 and has been standardized		only one which is more secure than SHA-1 and has been standardized
	for use with SSH key exchanges.		for use with SSH key exchanges.
	diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 are		diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 are
	currently mandatory to implement (MTI). diffie-hellman-group14-sha1		currently mandatory to implement (MTI). diffie-hellman-group14-sha1
	is the stronger of the two. Group14 (a 2048-bit MODP group) is		is the stronger of the two. Group14 (a 2048-bit MODP group) is
	defined in [RFC3526]. It is reasonable to retain the diffie-hellman-		defined in [RFC3526]. It is reasonable to retain the diffie-hellman-
	group14-sha1 exchange for interoperability with legacy		group14-sha1 exchange for interoperability with legacy
	implementations. Therefore, diffie-hellman-group14-sha1 SHOULD be		implementations. The diffie-hellman-group14-sha1 key exchange MAY be
	implemented and all other *-sha1 key exchanges SHOULD NOT be		implemented.
			The diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1,
			gss-gex-sha1-*, and gss-group1-sha1-* key exchanges SHOULD NOT be
	implemented.		implemented.
	3.2. Elliptic Curve Cryptography (ECC)		3.2. Elliptic Curve Cryptography (ECC)
	3.2.1. curve25519-sha256 and gss-curve25519-sha256-*		3.2.1. curve25519-sha256 and gss-curve25519-sha256-*
	Curve25519 is efficient on a wide range of architectures with		Curve25519 is efficient on a wide range of architectures with
	properties that allow higher performance implementations compared to		properties that allow higher performance implementations compared to
	traditional elliptic curves. The use of SHA2-256 (also known as		traditional elliptic curves. The use of SHA2-256 (also known as
	SHA-256 and sha256) as defined in [RFC6234] for integrity is a		SHA-256 and sha256) as defined in [RFC6234] for integrity is a
	skipping to change at page 10, line 18 ¶		skipping to change at page 10, line 18 ¶
	| curve25519-sha256 | RFC8731 | SHOULD |		| curve25519-sha256 | RFC8731 | SHOULD |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| curve448-sha512 | RFC8731 | MAY |		| curve448-sha512 | RFC8731 | MAY |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| diffie-hellman-group-exchange-sha1 | RFC4419 | SHOULD NOT |		| diffie-hellman-group-exchange-sha1 | RFC4419 | SHOULD NOT |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| diffie-hellman-group-exchange-sha256 | RFC4419 | MAY |		| diffie-hellman-group-exchange-sha256 | RFC4419 | MAY |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| diffie-hellman-group1-sha1 | RFC4253 | SHOULD NOT |		| diffie-hellman-group1-sha1 | RFC4253 | SHOULD NOT |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| diffie-hellman-group14-sha1 | RFC4253 | SHOULD |		| diffie-hellman-group14-sha1 | RFC4253 | MAY |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| diffie-hellman-group14-sha256 | RFC8268 | MUST |		| diffie-hellman-group14-sha256 | RFC8268 | MUST |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| diffie-hellman-group15-sha512 | RFC8268 | MAY |		| diffie-hellman-group15-sha512 | RFC8268 | MAY |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| diffie-hellman-group16-sha512 | RFC8268 | SHOULD |		| diffie-hellman-group16-sha512 | RFC8268 | SHOULD |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| diffie-hellman-group17-sha512 | RFC8268 | MAY |		| diffie-hellman-group17-sha512 | RFC8268 | MAY |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| diffie-hellman-group18-sha512 | RFC8268 | MAY |		| diffie-hellman-group18-sha512 | RFC8268 | MAY |
	skipping to change at page 11, line 19 ¶		skipping to change at page 11, line 19 ¶
	| gss-group16-sha512-* | RFC8732 | SHOULD |		| gss-group16-sha512-* | RFC8732 | SHOULD |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| gss-group17-sha512-* | RFC8732 | MAY |		| gss-group17-sha512-* | RFC8732 | MAY |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| gss-group18-sha512-* | RFC8732 | MAY |		| gss-group18-sha512-* | RFC8732 | MAY |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| gss-nistp256-sha256-* | RFC8732 | SHOULD |		| gss-nistp256-sha256-* | RFC8732 | SHOULD |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| gss-nistp384-sha384-* | RFC8732 | SHOULD |		| gss-nistp384-sha384-* | RFC8732 | SHOULD |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| gss-nistp521-sha512-* | RFC8732 | MAY |		| gss-nistp521-sha512-* | RFC8732 | SHOULD |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| rsa1024-sha1 | RFC4432 | MUST NOT |		| rsa1024-sha1 | RFC4432 | MUST NOT |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| rsa2048-sha256 | RFC4432 | MAY |		| rsa2048-sha256 | RFC4432 | MAY |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	Table 6: IANA guidance for key exchange method name		Table 6: IANA guidance for key exchange method name
	implementations		implementations
	The full set of official [IANA-KEX] key algorithm method names not		The full set of official [IANA-KEX] key algorithm method names not
	skipping to change at page 13, line 27 ¶		skipping to change at page 13, line 27 ¶
	<https://www.rfc-editor.org/info/rfc8270>.		<https://www.rfc-editor.org/info/rfc8270>.
	[RFC8308] Bider, D., "Extension Negotiation in the Secure Shell		[RFC8308] Bider, D., "Extension Negotiation in the Secure Shell
	(SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March		(SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
	2018, <https://www.rfc-editor.org/info/rfc8308>.		2018, <https://www.rfc-editor.org/info/rfc8308>.
	8.2. Informative References		8.2. Informative References
	[IANA-KEX] Internet Assigned Numbers Authority (IANA), "Secure Shell		[IANA-KEX] Internet Assigned Numbers Authority (IANA), "Secure Shell
	(SSH) Protocol Parameters: Key Exchange Method Names",		(SSH) Protocol Parameters: Key Exchange Method Names",
	July 2020, <http://www.iana.org/assignments/ssh-		December 2020, <http://www.iana.org/assignments/ssh-
	parameters/ssh-parameters.xhtml#ssh-parameters-16>.		parameters/ssh-parameters.xhtml#ssh-parameters-16>.
	[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)		[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
	Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,		Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
	January 2006, <https://www.rfc-editor.org/info/rfc4251>.		January 2006, <https://www.rfc-editor.org/info/rfc4251>.
	[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman		[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman
	Group Exchange for the Secure Shell (SSH) Transport Layer		Group Exchange for the Secure Shell (SSH) Transport Layer
	Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006,		Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006,
	<https://www.rfc-editor.org/info/rfc4419>.		<https://www.rfc-editor.org/info/rfc4419>.
	skipping to change at page 14, line 25 ¶		skipping to change at page 14, line 25 ¶
	[RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure		[RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure
	Shell (SSH) Key Exchange Method Using Curve25519 and		Shell (SSH) Key Exchange Method Using Curve25519 and
	Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020,		Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020,
	<https://www.rfc-editor.org/info/rfc8731>.		<https://www.rfc-editor.org/info/rfc8731>.
	[RFC8732] Sorce, S. and H. Kario, "Generic Security Service		[RFC8732] Sorce, S. and H. Kario, "Generic Security Service
	Application Program Interface (GSS-API) Key Exchange with		Application Program Interface (GSS-API) Key Exchange with
	SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020,		SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020,
	<https://www.rfc-editor.org/info/rfc8732>.		<https://www.rfc-editor.org/info/rfc8732>.
			[TRANS-COLL]
			Bhargavan, K. and G. Leurent, "Transcript Collision
			Attacks: Breaking Authentication in TLS, IKE, and SSH",
			Network and Distributed System Security Symposium - NDSS
			2016, Feb 2016, San Diego, United
			States. 10.14722/ndss.2016.23418 . hal-01244855,
			<https://hal.inria.fr/hal-01244855/document>.
	Author's Address		Author's Address
	Mark D. Baushke		Mark D. Baushke
	Juniper Networks, Inc.		Juniper Networks, Inc.
	Email: mdb@juniper.net		Email: mdb@juniper.net
End of changes. 15 change blocks.
	18 lines changed or deleted		52 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/