< draft-ietf-curdle-ssh-kex-sha2-17.txt		draft-ietf-curdle-ssh-kex-sha2-18.txt >
	Internet Engineering Task Force M. D. Baushke		Internet Engineering Task Force M. D. Baushke
	Internet-Draft 22 April 2021		Internet-Draft 16 June 2021
	Updates: 4250 4253 4432 4462 (if approved)		Updates: 4250 4253 4432 4462 (if approved)
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 24 October 2021		Expires: 18 December 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-17		draft-ietf-curdle-ssh-kex-sha2-18
	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, RFC 4253, RFC 4432, and RFC 4462.		4250, RFC 4253, RFC 4432, and RFC 4462.
	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 24 October 2021.		This Internet-Draft will expire on 18 December 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 28 ¶		skipping to change at page 2, line 28 ¶
	3.1.3. ecdh-*, ecmqv-sha2, and gss-nistp* . . . . . . . . . 10		3.1.3. ecdh-*, ecmqv-sha2, and gss-nistp* . . . . . . . . . 10
	3.2. Finite Field Cryptography (FFC) . . . . . . . . . . . . . 11		3.2. Finite Field Cryptography (FFC) . . . . . . . . . . . . . 11
	3.2.1. FFC diffie-hellman using generated MODP groups . . . 11		3.2.1. FFC diffie-hellman using generated MODP groups . . . 11
	3.2.2. FFC diffie-hellman using named MODP groups . . . . . 12		3.2.2. FFC diffie-hellman using named MODP groups . . . . . 12
	3.3. Integer Factorization Cryptography (IFC) . . . . . . . . 13		3.3. Integer Factorization Cryptography (IFC) . . . . . . . . 13
	3.4. KDFs and Integrity Hashing . . . . . . . . . . . . . . . 14		3.4. KDFs and Integrity Hashing . . . . . . . . . . . . . . . 14
	3.5. Secure Shell Extension Negotiation . . . . . . . . . . . 15		3.5. Secure Shell Extension Negotiation . . . . . . . . . . . 15
	4. Summary Guidance for Key Exchange Method Names		4. Summary Guidance for Key Exchange Method Names
	Implementations . . . . . . . . . . . . . . . . . . . . . 15		Implementations . . . . . . . . . . . . . . . . . . . . . 15
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.1. Normative References . . . . . . . . . . . . . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . 19
	8.2. Informative References . . . . . . . . . . . . . . . . . 19		8.2. Informative References . . . . . . . . . . . . . . . . . 20
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
	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 or disallowed as well as recommending some that SHOULD and		deprecated or disallowed as well as recommending some that SHOULD and
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 14 ¶
	1.2.1. Elliptic Curve Cryptography (ECC)		1.2.1. Elliptic Curve Cryptography (ECC)
	For ECC, across all of the named curves the minimum security strength		For ECC, across all of the named curves the minimum security strength
	is approximately 128 bits. The [RFC5656] key exchanges for the named		is approximately 128 bits. The [RFC5656] key exchanges for the named
	curves use a hashing function with a matching security strength.		curves use a hashing function with a matching security strength.
	Likewise, the [RFC8731] key exchanges use a hashing function which		Likewise, the [RFC8731] key exchanges use a hashing function which
	has more security strength than the curves. The minimum strength		has more security strength than the curves. The minimum strength
	will be the security strength of the curve. Table 3 contains a		will be the security strength of the curve. Table 3 contains a
	breakdown of just the ECC security strength by curve name and not		breakdown of just the ECC security strength by curve name and not
	including the hashing algorithm used. The hashing algorithm defined		including the hashing algorithm used. The hashing algorithm
	have approximately the same number of bits of security as the named		designated for use with the individual curves have approximately the
	curve.		same number of bits of security as the named curve.
	+============+=============================+		+============+=============================+
	| Curve Name | Estimated Security Strength |		| Curve Name | Estimated Security Strength |
	+============+=============================+		+============+=============================+
	| nistp256 | 128 bits |		| nistp256 | 128 bits |
	+------------+-----------------------------+		+------------+-----------------------------+
	| nistp384 | 192 bits |		| nistp384 | 192 bits |
	+------------+-----------------------------+		+------------+-----------------------------+
	| nistp521 | 512 bits |		| nistp521 | 512 bits |
	+------------+-----------------------------+		+------------+-----------------------------+
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 27 ¶
	| 8192-bit | 200 bits | group18 |		| 8192-bit | 200 bits | group18 |
	+------------------+-----------------------------+------------+		+------------------+-----------------------------+------------+
	Table 4: FFC MODP Security Strengths		Table 4: FFC MODP Security Strengths
	The minimum MODP group is the 2048-bit MODP group14. When used with		The minimum MODP group is the 2048-bit MODP group14. When used with
	sha1, this group provides approximately 80 bits of security. When		sha1, this group provides approximately 80 bits of security. When
	used with sha256, this group provides approximately 112 bits of		used with sha256, this group provides approximately 112 bits of
	security. The 3des-cbc cipher itself provides at most 112 bits of		security. The 3des-cbc cipher itself provides at most 112 bits of
	security, so the group14-sha256 key exchanges is sufficient to keep		security, so the group14-sha256 key exchanges is sufficient to keep
	all of the 3des-cbc key at 112 bits of security.		all of the 3des-cbc key, for 112 bits of security.
	A 3072-bit MODP group with sha256 hash will provide approximately 128		A 3072-bit MODP group with sha256 hash will provide approximately 128
	bits of security. This is desirable when using a Cipher such as		bits of security. This is desirable when using a Cipher such as
	aes128 or chacha20-poly1305 that provides approximately 128 bits of		aes128 or chacha20-poly1305 that provides approximately 128 bits of
	security.		security.
	The 8192-bit group18 MODP group when used with sha512 provides		The 8192-bit group18 MODP group when used with sha512 provides
	approximately 200 bits of security which is sufficient to protect		approximately 200 bits of security which is sufficient to protect
	aes192 with 192 bits of security.		aes192 with 192 bits of security.
	skipping to change at page 8, line 50 ¶		skipping to change at page 8, line 50 ¶
	implementations.		implementations.
	3.1. Elliptic Curve Cryptography (ECC)		3.1. Elliptic Curve Cryptography (ECC)
	The EC key exchange algorithms used with SSH include the ECDH and EC		The EC key exchange algorithms used with SSH include the ECDH and EC
	Menezes-Qu-Vanstone (ecmqv).		Menezes-Qu-Vanstone (ecmqv).
	The ECC curves defined for the key exchange algorithms above include;		The ECC curves defined for the key exchange algorithms above include;
	curve25519, curve448, the NIST prime curves (nistp256, nistp384,		curve25519, curve448, the NIST prime curves (nistp256, nistp384,
	nistp521) as well as other curves allowed for by [RFC5656] section 6.		nistp521) as well as other curves allowed for by [RFC5656] section 6.
	There are GSSAPI forms for these curves as well which have a 'gss-'		There are GSSAPI-based key-exchange mechanisms that use these curves
	prefix.		as well which have a 'gss-' prefix.
	3.1.1. curve25519-sha256 and gss-curve25519-sha256-*		3.1.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 hash SHA2-256 (also known as		traditional elliptic curves. The corresponding key exchange methods
	SHA-256 and sha256) as defined in [RFC6234] for integrity is a		use SHA2-256 (also known as SHA-256) defined in [RFC6234]. SHA2-256
	reasonable one for both the KDF and integrity for use with both gss		is a reasonable hash in both the KDF and integrity in both gss and
	and non-gss uses of curve25519 key exchange methods. These key		non-gss uses of curve25519 key exchange methods. These key exchange
	exchange methods are described in [RFC8731] and [RFC8732] and are		methods are described in [RFC8731] and [RFC8732] and are similar to
	similar to the IKEv2 key agreement described in [RFC8031]. The		the IKEv2 key agreement described in [RFC8031]. The
	curve25519-sha256 key exchange method has multiple implementations		curve25519-sha256 key exchange method has multiple implementations
	and SHOULD be implemented. The gss-curve25519-sha256-* key exchange		and SHOULD be implemented. The gss-curve25519-sha256-* key exchange
	method SHOULD also be implemented because it shares the same		method SHOULD also be implemented because it shares the same
	performance and security characteristics as curve25519-sha256.		performance and security characteristics as curve25519-sha256.
	Table 6 contains a summary of the recommendations for curve25519		Table 6 contains a summary of the recommendations for curve25519
	based key exchanges.		based key exchanges.
	+==========================+==========+		+==========================+==========+
	| Key Exchange Method Name | Guidance |		| Key Exchange Method Name | Guidance |
	skipping to change at page 9, line 38 ¶		skipping to change at page 9, line 38 ¶
	| gss-curve25519-sha256-* | SHOULD |		| gss-curve25519-sha256-* | SHOULD |
	+--------------------------+----------+		+--------------------------+----------+
	Table 6: Curve25519 Implementation		Table 6: Curve25519 Implementation
	Guidance		Guidance
	3.1.2. curve448-sha512 and gss-curve448-sha512-*		3.1.2. curve448-sha512 and gss-curve448-sha512-*
	Curve448 provides more security strength than Curve25519 at a higher		Curve448 provides more security strength than Curve25519 at a higher
	computational and bandwidth cost. The corresponding key exchange		computational and bandwidth cost. The corresponding key exchange
	methods use SHA2-512 (also known as SHA-512) defined in [RFC6234] for		methods use SHA2-512 (also known as SHA-512) defined in [RFC6234].
	integrity is a reasonable one for both the KDF and integrity for use		SHA2-512 is reasonable hash in both the KDF and integrity in both gss
	with both gss and non-gss uses of curve448 key exchange methods.		and non-gss uses of curve448 key exchange methods. These key
	These key exchange methods are described in [RFC8731] and [RFC8732]		exchange methods are described in [RFC8731] and [RFC8732] and are
	and are similar to the IKEv2 key agreement described in [RFC8031].		similar to the IKEv2 key agreement described in [RFC8031]. The
	The curve448-sha512 key exchange method MAY be implemented. The gss-		curve448-sha512 key exchange method MAY be implemented. The gss-
	curve448-sha512-* key exchange method MAY also be implemented because		curve448-sha512-* key exchange method MAY also be implemented because
	it shares the same performance and security characteristics as		it shares the same performance and security characteristics as
	curve448-sha512.		curve448-sha512.
	Table 7 contains a summary of the recommendations for curve448 based		Table 7 contains a summary of the recommendations for curve448 based
	key exchanges.		key exchanges.
	+==========================+==========+		+==========================+==========+
	| Key Exchange Method Name | Guidance |		| Key Exchange Method Name | Guidance |
	+==========================+==========+		+==========================+==========+
	skipping to change at page 14, line 51 ¶		skipping to change at page 14, line 51 ¶
	Prior to the changes made by this document, diffie-hellman-		Prior to the changes made by this document, diffie-hellman-
	group1-sha1 and diffie-hellman-group14-sha1 were mandatory to		group1-sha1 and diffie-hellman-group14-sha1 were mandatory to
	implement (MTI). diffie-hellman-group14-sha1 is the stronger of the		implement (MTI). diffie-hellman-group14-sha1 is the stronger of the
	two. Group14 (a 2048-bit MODP group) is defined in [RFC3526]. The		two. Group14 (a 2048-bit MODP group) is defined in [RFC3526]. The
	group1 MODP group with approximately 80 bits of security is too weak		group1 MODP group with approximately 80 bits of security is too weak
	to be retained. However, rather than jumping from the MTI to making		to be retained. However, rather than jumping from the MTI to making
	it disallowed, many implementers suggested that it should transition		it disallowed, many implementers suggested that it should transition
	to deprecated first and be disallowed at a later time. The group14		to deprecated first and be disallowed at a later time. The group14
	MODP group using a sha1 hash for the KDF is not as weak as the group1		MODP group using a sha1 hash for the KDF is not as weak as the group1
	MODP group. There are some legacy situations where it will still		MODP group. There are some legacy situations where it will still
	provide administrators with value. Transitioning from MTI to one		provide administrators with value. Transitioning from MTI to a
	that provides for continued use with the expectation of deprecating		requirement status that provides for continued use with the
	or disallowing it in the future was able to find consensus.		expectation of deprecating or disallowing it in the future was able
	Therefore, it is considered reasonable to retain the diffie-hellman-		to find consensus. Therefore, it is considered reasonable to retain
	group14-sha1 exchange for interoperability with legacy		the diffie-hellman-group14-sha1 exchange for interoperability with
	implementations. The diffie-hellman-group14-sha1 key exchange MAY be		legacy implementations. The diffie-hellman-group14-sha1 key exchange
	implemented, but should be put at the end of the list of negotiated		MAY be implemented, but should be put at the end of the list of
	key exchanges.		negotiated key exchanges.
	The diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1,		The diffie-hellman-group1-sha1 and diffie-hellman-group-exchange-sha1
	gss-gex-sha1-*, and gss-group1-sha1-* key exchanges SHOULD NOT be		SHOULD NOT be implemented. The gss-group1-sha1-*, gss-
	implemented.		group14-sha1-*, and gss-gex-sha1-* key exchanges are already
			specified as SHOULD NOT be implemented by [RFC8732].
	3.5. Secure Shell Extension Negotiation		3.5. Secure Shell Extension Negotiation
	There are two methods, ext-info-c and ext-info-s, defined in		There are two methods, ext-info-c and ext-info-s, defined in
	[RFC8308]. They provide a mechanism to support other Secure Shell		[RFC8308]. They provide a mechanism to support other Secure Shell
	negotiations. Being able to extend functionality is desirable. Both		negotiations. Being able to extend functionality is desirable. Both
	ext-info-c and ext-info-s SHOULD be implemented.		ext-info-c and ext-info-s SHOULD be implemented.
	4. Summary Guidance for Key Exchange Method Names Implementations		4. Summary Guidance for Key Exchange Method Names Implementations
	skipping to change at page 16, line 29 ¶		skipping to change at page 16, line 30 ¶
	| ecdh-sha2-nistp384 | RFC5656 | MUST | SHOULD |		| ecdh-sha2-nistp384 | RFC5656 | MUST | SHOULD |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| ecdh-sha2-nistp521 | RFC5656 | MUST | SHOULD |		| ecdh-sha2-nistp521 | RFC5656 | MUST | SHOULD |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| ecmqv-sha2 | RFC5656 | MAY | MAY |		| ecmqv-sha2 | RFC5656 | MAY | MAY |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| ext-info-c | RFC8308 | SHOULD | SHOULD |		| ext-info-c | RFC8308 | SHOULD | SHOULD |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| ext-info-s | RFC8308 | SHOULD | SHOULD |		| ext-info-s | RFC8308 | SHOULD | SHOULD |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| gss-* | RFC4462 | none | MAY |		| gss- | RFC4462 | reserved | reserved |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| gss- | RFC8732 | SHOULD | SHOULD |		| gss- | RFC8732 | SHOULD | SHOULD |
	| curve25519-sha256-* | | | |		| curve25519-sha256-* | | | |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| gss-curve448-sha512-* | RFC8732 | MAY | MAY |		| gss-curve448-sha512-* | RFC8732 | MAY | MAY |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| gss-gex-sha1-* | RFC4462 | none | SHOULD |		| gss-gex-sha1-* | RFC4462/ | SHOULD NOT | SHOULD |
	| | | | NOT |		| | RFC8732 | | NOT |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| gss-group1-sha1-* | RFC4462 | none | SHOULD |		| gss-group1-sha1-* | RFC4462/ | SHOULD NOT | SHOULD |
	| | | | NOT |		| | RFC8732 | | NOT |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| gss-group14-sha256-* | RFC8732 | none | SHOULD |		| gss-group14-sha1-* | RFC4462/ | SHOULD NOT | SHOULD |
			| | RFC8732 | | NOT |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| gss-group15-sha512-* | RFC8732 | none | MAY |		| gss-group14-sha256-* | RFC8732 | SHOULD | SHOULD |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| gss-group16-sha512-* | RFC8732 | none | MAY |		| gss-group15-sha512-* | RFC8732 | MAY | MAY |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| gss-group17-sha512-* | RFC8732 | none | MAY |		| gss-group16-sha512-* | RFC8732 | SHOULD | SHOULD |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| gss-group18-sha512-* | RFC8732 | none | MAY |		| gss-group17-sha512-* | RFC8732 | MAY | MAY |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| gss-nistp256-sha256-* | RFC8732 | none | SHOULD |		| gss-group18-sha512-* | RFC8732 | MAY | MAY |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| gss-nistp384-sha384-* | RFC8732 | none | SHOULD |		| gss-nistp256-sha256-* | RFC8732 | SHOULD | SHOULD |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| gss-nistp521-sha512-* | RFC8732 | none | SHOULD |		| gss-nistp384-sha384-* | RFC8732 | MAY | SHOULD |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| rsa1024-sha1 | RFC4432 | none | MUST NOT |		| gss-nistp521-sha512-* | RFC8732 | MAY | SHOULD |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	| rsa2048-sha256 | RFC4432 | none | MAY |		| rsa1024-sha1 | RFC4432 | MAY | MUST NOT |
			+--------------------------+-----------+----------------+-----------+
			| rsa2048-sha256 | RFC4432 | MAY | MAY |
	+--------------------------+-----------+----------------+-----------+		+--------------------------+-----------+----------------+-----------+
	Table 12: IANA guidance for key exchange method name implementations		Table 12: IANA guidance for key exchange method name 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
	otherwise mentioned in this document MAY be implemented.		otherwise mentioned in this document MAY be implemented.
	[TO BE REMOVED: This registration should take place at the following		[TO BE REMOVED: This registration should take place at the following
	location URL: http://www.iana.org/assignments/ssh-parameters/ssh-		location URL: http://www.iana.org/assignments/ssh-parameters/ssh-
	parameters.xhtml#ssh-parameters-16 It is hoped that the Table 12 in		parameters.xhtml#ssh-parameters-16 It is hoped that the Table 12 in
	skipping to change at page 17, line 47 ¶		skipping to change at page 18, line 11 ¶
	to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh)		to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh)
	and Poderosa implementations also adopting new Diffie-Hellman groups		and Poderosa implementations also adopting new Diffie-Hellman groups
	based on this draft.		based on this draft.
	6. Security Considerations		6. Security Considerations
	This SSH protocol provides a secure encrypted channel over an		This SSH protocol provides a secure encrypted channel over an
	insecure network. It performs server host authentication, key		insecure network. It performs server host authentication, key
	exchange, encryption, and integrity checks. It also derives a unique		exchange, encryption, and integrity checks. It also derives a unique
	session ID that may be used by higher-level protocols. The key		session ID that may be used by higher-level protocols. The key
	exchange itself, generates a shared secret and uses the hash function		exchange itself generates a shared secret and uses the hash function
	for both the KDF and integrity.		for both the KDF and integrity.
	Full security considerations for this protocol are provided in		Full security considerations for this protocol are provided in
	[RFC4251]. In addition, the security considerations provided in		[RFC4251] continue to apply. In addition, the security
	[RFC4432]. Note that Forward Secrecy is NOT available with the		considerations provided in [RFC4432] apply. Note that Forward
	rsa1024-sha1 or rsa2048-sha256 key exchanges.		Secrecy is NOT available with the rsa1024-sha1 or rsa2048-sha256 key
			exchanges.
	It is desirable to deprecate or disallow key exchange methods that		It is desirable to deprecate or disallow key exchange methods that
	are considered weak so they are not in still actively in operation		are considered weak so they are not in still actively in operation
	when they are broken.		when they are broken.
	A key exchange method is considered weak when the security strength		A key exchange method is considered weak when the security strength
	is insufficient to match the symmetric cipher or the algorithm has		is insufficient to match the symmetric cipher or the algorithm has
	been broken.		been broken.
	The 1024-bit MODP group used by diffie-hellman-group1-sha1 is too		The 1024-bit MODP group used by diffie-hellman-group1-sha1 is too
	skipping to change at page 19, line 45 ¶		skipping to change at page 20, line 13 ¶
	2018, <https://www.rfc-editor.org/info/rfc8308>.		2018, <https://www.rfc-editor.org/info/rfc8308>.
	[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>.
	8.2. Informative References		8.2. Informative References
	[IANA-KEX] IANA, "Secure Shell (SSH) Protocol Parameters: Key		[IANA-KEX] IANA, "Secure Shell (SSH) Protocol Parameters: Key
	Exchange Method Names", April 2021,		Exchange Method Names", June 2021,
	<http://www.iana.org/assignments/ssh-parameters/ssh-		<http://www.iana.org/assignments/ssh-parameters/ssh-
	parameters.xhtml#ssh-parameters-16>.		parameters.xhtml#ssh-parameters-16>.
	[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)		[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
	Diffie-Hellman groups for Internet Key Exchange (IKE)",		Diffie-Hellman groups for Internet Key Exchange (IKE)",
	RFC 3526, DOI 10.17487/RFC3526, May 2003,		RFC 3526, DOI 10.17487/RFC3526, May 2003,
	<https://www.rfc-editor.org/info/rfc3526>.		<https://www.rfc-editor.org/info/rfc3526>.
	[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,
End of changes. 28 change blocks.
	58 lines changed or deleted		63 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/