< draft-ietf-curdle-ssh-kex-sha2-13.txt		draft-ietf-curdle-ssh-kex-sha2-14.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 4253 4432 4462 (if approved) 14 January 2021		Updates: 4250 4253 4432 4462 (if approved) 10 February 2021
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 18 July 2021		Expires: 14 August 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-13		draft-ietf-curdle-ssh-kex-sha2-14
	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 18 July 2021.		This Internet-Draft will expire on 14 August 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. 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 . . . . . . 4
	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) . . . . . . . . . . . 5
	1.2.3. Integer Factorization Cryptography (IFC) . . . . . . 5		1.2.3. Integer Factorization Cryptography (IFC) . . . . . . 5
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
	3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 6		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-* . . . . 7
	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
	3.5. Secure Shell Extension Negotiation . . . . . . . . . . . 9		3.5. Secure Shell Extension Negotiation . . . . . . . . . . . 9
	4. Summary Guidance for Key Exchange Method Names		4. Summary Guidance for Key Exchange Method Names
	Implementations . . . . . . . . . . . . . . . . . . . . . 9		Implementations . . . . . . . . . . . . . . . . . . . . . 9
	skipping to change at page 3, line 13 ¶		skipping to change at page 3, line 13 ¶
	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		At present, the attacks against SHA-1 are collision attacks that
	usually rely on human help rather than a pre-image attack. SHA-1		usually rely on human help, rather than a pre-image attack. SHA-1
	resistance against 2nd pre-image is still at 160 bits, but SSH does		resistance against second pre-image is still at 160 bits, but SSH
	not depend on that, but rather on chosen prefix resistance.		does not depend on second pre-image resistance, but rather on chosen-
			prefix collision resistance.
	Transcript Collision attacks are documented in [TRANS-COLL]. This		Transcript Collision attacks are documented in [TRANS-COLL]. This
	paper shows that the man in the middle does not tamper with the		paper shows that the man in the middle does not tamper with the
	Diffie-Hellman values and does not know the connection keys.		Diffie-Hellman values and does not know the connection keys.
	However, it manages to tamper with both Ic and Is, and can therefore		However, it manages to tamper with both I_C and I_S, and can
	downgrade the negotiated ciphersuite to a weak cryptographic		therefore downgrade the negotiated ciphersuite to a weak
	algorithm that the attacker knows how to break.		cryptographic algorithm that the attacker knows how to break.
	These attacks are still computationally very difficult to perform,		These attacks are still computationally very difficult to perform,
	but is is desirable that any Key Exchanging using SHA-1 be phased out		but is is desirable that any Key Exchanging using SHA-1 be phased out
	as soon as possible.		as soon as possible.
	These attacks are potentially slightly easier when the server		These attacks are potentially slightly easier when the server
	provides the Diffie-Hellman parameters such as using the [RFC4419]		provides the Diffie-Hellman parameters such as using the [RFC4419]
	generated set of diffie-hellman parameters with SHA-1 hashing. If		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,		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		it would be desirable it be listed last in the preference list of key
	skipping to change at page 4, line 30 ¶		skipping to change at page 4, line 34 ¶
	chosen to be comparable with the security strength of the other		chosen to be comparable with the security strength of the other
	elements of the SSH handshake. Attackers can target the weakest		elements of the SSH handshake. Attackers can target the weakest
	element of the SSH handshake.		element of the SSH handshake.
	It is desirable to select a minimum of 112 bits of security strength.		It is desirable to select a minimum of 112 bits of security strength.
	Based on implementer security needs, a stronger minimum may be		Based on implementer security needs, a stronger minimum may be
	desired.		desired.
	1.2.1. Elliptic Curve Cryptography (ECC)		1.2.1. Elliptic Curve Cryptography (ECC)
	For ECC, it is recommended to select one with approximately 128 bits		For ECC, it is recommended to select a curve with approximately 128
	of security strength.		bits of security strength.
	+============+=============================+		+============+=============================+
	| 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 |
	+------------+-----------------------------+		+------------+-----------------------------+
	| Curve25519 | 128 bits |		| Curve25519 | 128 bits |
	+------------+-----------------------------+		+------------+-----------------------------+
	| Curve448 | 224 bits |		| Curve448 | 224 bits |
	+------------+-----------------------------+		+------------+-----------------------------+
	Table 1: ECC Security Strengths		Table 1: ECC Security Strengths
	1.2.2. Finite Field Cryptography (FFC)		1.2.2. Finite Field Cryptography (FFC)
	For FFC, a modulus 2048 bits (112 bits of security strength).		For FFC, it is recommended to use a modulus with 2048 bits (112 bits
			of security strength).
	+==================+=============================+============+		+==================+=============================+============+
	| Prime Field Size | Estimated Security Strength | Example |		| Prime Field Size | Estimated Security Strength | Example |
	| | | MODP Group |		| | | MODP Group |
	+==================+=============================+============+		+==================+=============================+============+
	| 2048-bit | 112 bits | group14 |		| 2048-bit | 112 bits | group14 |
	+------------------+-----------------------------+------------+		+------------------+-----------------------------+------------+
	| 3072-bit | 128 bits | group15 |		| 3072-bit | 128 bits | group15 |
	+------------------+-----------------------------+------------+		+------------------+-----------------------------+------------+
	| 4096-bit | 152 bits | group16 |		| 4096-bit | 152 bits | group16 |
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 32 ¶
	| 8192-bit | 200 bits | group18 |		| 8192-bit | 200 bits | group18 |
	+------------------+-----------------------------+------------+		+------------------+-----------------------------+------------+
	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
	[RFC4432]. The minimum modulus size is 2048 bits. The use of a		specified in [RFC4432]. The minimum modulus size is 2048 bits. The
	SHA-2 Family hash with RSA 2048-bit keys has sufficient security.		use of a SHA-2 Family hash with RSA 2048-bit keys has sufficient
	The rsa1024-sha1 key exchange has less than 2048 bits and MUST NOT be		security. The rsa1024-sha1 key exchange has less than 2048 bits and
	implemented.		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 23 ¶		skipping to change at page 6, line 31 ¶
	suggested suitability for implementation of MUST, SHOULD, SHOULD NOT,		suggested suitability for implementation of MUST, SHOULD, SHOULD NOT,
	and MUST NOT. Any method not explicitly listed MAY be implemented.		and MUST NOT. Any method not explicitly listed MAY be implemented.
	This document is intended to provide guidance as to what key exchange		This document is intended to provide guidance as to what key exchange
	algorithms are to be considered for new or updated SSH		algorithms are to be considered for new or updated SSH
	implementations.		implementations.
	3.1. SHA-1 and SHA-2 Hashing		3.1. SHA-1 and SHA-2 Hashing
	All of the key exchanges using the SHA-1 hashing algorithm should be		All of the key exchanges using the SHA-1 hashing algorithm should be
	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		as documented in [RFC6194]. The SHA-2 Family of hashes [RFC6234] is
	only one which is more secure than SHA-1 and has been standardized		the only one which is more secure than SHA-1 and has been
	for use with SSH key exchanges.		standardized for use with SSH key exchanges.
	diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 are		Prior to the changes made by this document, diffie-hellman-
	currently mandatory to implement (MTI). diffie-hellman-group14-sha1		group1-sha1 and diffie-hellman-group14-sha1 were mandatory to
	is the stronger of the two. Group14 (a 2048-bit MODP group) is		implement (MTI). diffie-hellman-group14-sha1 is the stronger of the
	defined in [RFC3526]. It is reasonable to retain the diffie-hellman-		two. Group14 (a 2048-bit MODP group) is defined in [RFC3526]. It is
	group14-sha1 exchange for interoperability with legacy		reasonable to retain the diffie-hellman-group14-sha1 exchange for
	implementations. The diffie-hellman-group14-sha1 key exchange MAY be		interoperability with legacy implementations. The diffie-hellman-
	implemented.		group14-sha1 key exchange MAY be implemented.
	The diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1,		The diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1,
	gss-gex-sha1-*, and gss-group1-sha1-* key exchanges SHOULD NOT be		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
	reasonable one for this method. These key exchange methods are		reasonable one for this method. These key exchange methods are
	described in [RFC8731] and [RFC8732] and is similar to the IKEv2 Key		described in [RFC8731] and [RFC8732] and are similar to the IKEv2 Key
	Agreement described in [RFC8031]. The curve25519-sha256 key exchange		Agreement described in [RFC8031]. The curve25519-sha256 key exchange
	method has multiple implementations and SHOULD be implemented. The		method has multiple implementations and SHOULD be implemented. The
	gss-curve25519-sha256-* key exchange method SHOULD also be		gss-curve25519-sha256-* key exchange method SHOULD also be
	implemented because it shares the same performance and security		implemented because it shares the same performance and security
	characteristics as curve25519-sha2.		characteristics as curve25519-sha2.
	3.2.2. curve448-sha512 and gss-curve448-sha512-*		3.2.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. It uses SHA2-512 (also known as		computational and bandwidth cost. It uses SHA2-512 (also known as
	SHA-512) defined in [RFC6234] for integrity. This Key Exchange		SHA-512) defined in [RFC6234] for integrity. These Key Exchange
	Method is described in [RFC8731] and is similar to the IKEv2 Key		Methods are described in [RFC8731] and [RFC8732] and are similar to
	Agreement described in [RFC8031]. This method MAY be implemented.		the IKEv2 Key Agreement described in [RFC8031]. The curve448-sha512
	The gss-curve448-sha512-* key exchange method MAY also be implemented		key exchange method MAY be implemented. The gss-curve448-sha512-*
	because it shares the same performance and security characteristics		key exchange method MAY also be implemented because it shares the
	as curve448-sha512.		same performance and security characteristics as curve448-sha512.
	3.2.3. ECC diffie-hellman using ecdh-*, ecmqv-sha2, and gss-nistp*		3.2.3. ECC diffie-hellman using ecdh-*, ecmqv-sha2, and gss-nistp*
	The ecdh-sha2-* name-space allows for other curves to be defined for		The ecdh-sha2-* name-space allows for other curves to be defined for
	the elliptic curve Diffie Hellman key exchange. At present, there		the elliptic curve Diffie Hellman key exchange. At the time of this
	are three named curves in this name-space which SHOULD be supported.		writing, there are three named curves in this name-space which SHOULD
	They appear in [RFC5656] in section 10.1 Required Curves all of the		be supported. They appear in [RFC5656] in section 10.1 ("Required
	NISTP curves named are mandatory to implement if any of this RFC is		Curves"). All of the NISTP curves named therein are mandatory to
	implemented. This set of methods MAY be implemented. If		implement if any of that RFC is implemented. If implemented, the
	implemented, the named curves SHOULD always be enabled unless		named curves SHOULD always be enabled unless specifically disabled by
	specifically disabled by local security policy. In [RFC5656],		local security policy. In [RFC5656], section 6.1, the method to name
	section 6.1, the method to name other ECDH curves using OIDs is		other ECDH curves using OIDs is specified. These other curves MAY be
	specified. These other curves MAY be implemented.		implemented.
	The GSS-API name-space with gss-nistp*-sha* mirrors the algorithms		The GSS-API name-space with gss-nistp*-sha* mirrors the algorithms
	used by ecdh-sha2-* names. The table provides guidance for		used by ecdh-sha2-* names. The are described in [RFC8732]. The
	implementation.		table provides guidance for implementation.
	ECDH reduces bandwidth of key exchanges compared to FFC DH at a		ECDH reduces bandwidth of key exchanges compared to FFC DH at a
	similar security strength.		similar security strength.
	The following table lists algorithms as SHOULD where implementations		The following table lists algorithms as SHOULD where implementations
	may be more efficient or widely deployed. The items listed as MAY		may be more efficient or widely deployed. The items listed as MAY
	are potentially less efficient.		are potentially less efficient.
	+==========================+==========+		+==========================+==========+
	| Key Exchange Method Name | Guidance |		| Key Exchange Method Name | Guidance |
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 37 ¶
	It is advisable to match the ECDSA and ECDH algorithms to use the		It is advisable to match the ECDSA and ECDH algorithms to use the
	same curve for both to maintain the same security strength in the		same curve for both to maintain the same security strength in the
	connection.		connection.
	3.3. Finite Field Cryptography (FFC)		3.3. Finite Field Cryptography (FFC)
	3.3.1. FFC diffie-hellman using generated MODP groups		3.3.1. FFC diffie-hellman using generated MODP groups
	This random selection from a set of pre-generated moduli for key		This random selection from a set of pre-generated moduli for key
	exchange uses SHA2-256 as defined in [RFC4419]. [RFC8270] mandates		exchange uses SHA2-256 as defined in [RFC4419]. [RFC8270] mandates
	implementations avoid any MODP group whose modulus size is less than		that implementations avoid any MODP group whose modulus size is less
	2048 bits. Care should be taken in the pre-generation of the moduli		than 2048 bits. Care should be taken in the pre-generation of the
	P and generator G such that the generator provides a Q-ordered		moduli P and generator G such that the generator provides a Q-ordered
	subgroup of P. Otherwise, the parameter set may leak one bit of the		subgroup of P. Otherwise, the parameter set may leak one bit of the
	shared secret leaving the MODP group half as strong. This key		shared secret leaving the MODP group half as strong. This key
	exchange MAY be used.		exchange MAY be used.
	3.3.2. FFC diffie-hellman using named MODP groups		3.3.2. FFC diffie-hellman using named MODP groups
	diffie-hellman-group14-sha256 represents the smallest FFC DH key		diffie-hellman-group14-sha256 represents the smallest FFC DH key
	exchange method considered to be secure. It is a reasonably simple		exchange method considered to be secure. It is a reasonably simple
	transition from SHA-1 to SHA-2. diffie-hellman-group14-sha256 method		transition from SHA-1 to SHA-2. The diffie-hellman-group14-sha256
	MUST be implemented. The rest of the FFC MODP groups MAY be		method MUST be implemented. The rest of the FFC MODP groups MAY be
	implemented. The table below provides explicit guidance by name.		implemented. The table below provides explicit guidance by name.
	+===============================+==========+		+===============================+==========+
	| Key Exchange Method Name | Guidance |		| Key Exchange Method Name | Guidance |
	+===============================+==========+		+===============================+==========+
	| diffie-hellman-group14-sha256 | MUST |		| diffie-hellman-group14-sha256 | MUST |
	+-------------------------------+----------+		+-------------------------------+----------+
	| gss-group14-sha256-* | SHOULD |		| gss-group14-sha256-* | SHOULD |
	+-------------------------------+----------+		+-------------------------------+----------+
	| diffie-hellman-group15-sha512 | MAY |		| diffie-hellman-group15-sha512 | MAY |
	skipping to change at page 9, line 33 ¶		skipping to change at page 9, line 33 ¶
	+-------------------------------+----------+		+-------------------------------+----------+
	| diffie-hellman-group18-sha512 | MAY |		| diffie-hellman-group18-sha512 | MAY |
	+-------------------------------+----------+		+-------------------------------+----------+
	| gss-group18-sha512-* | MAY |		| gss-group18-sha512-* | MAY |
	+-------------------------------+----------+		+-------------------------------+----------+
	Table 5: FFC Implementation Guidance		Table 5: FFC Implementation Guidance
	3.4. Integer Factorization Cryptography (IFC)		3.4. Integer Factorization Cryptography (IFC)
	The rsa2048-sha256 key exchange method is defined in [RFC4432]. Uses		The rsa2048-sha256 key exchange method is defined in [RFC4432]. It
	an RSA 2048-bit modulus with a SHA2-256 hash. This key exchange		uses an RSA 2048-bit modulus with a SHA2-256 hash. This key exchange
	meets 112 bit minimum security strength. This method MAY be		meets 112 bit minimum security strength. This method MAY be
	implemented.		implemented.
	3.5. Secure Shell Extension Negotiation		3.5. Secure Shell Extension Negotiation
	There are two key exchange methods, ext-info-c and ext-info-s,		There are two key exchange methods, ext-info-c and ext-info-s,
	defined in [RFC8308] which are not actually key exchanges. They		defined in [RFC8308] which are not actually key exchanges. They
	provide a method to support other Secure Shell negotiations. Being		provide a method to support other Secure Shell negotiations. Being
	able to extend functionality is desirable. This method SHOULD be		able to extend functionality is desirable. This method SHOULD be
	implemented.		implemented.
	skipping to change at page 11, line 9 ¶		skipping to change at page 11, line 9 ¶
	| gss-curve448-sha512-* | RFC8732 | MAY |		| gss-curve448-sha512-* | RFC8732 | MAY |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| gss-gex-sha1-* | RFC4462 | SHOULD NOT |		| gss-gex-sha1-* | RFC4462 | SHOULD NOT |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| gss-group1-sha1-* | RFC4462 | SHOULD NOT |		| gss-group1-sha1-* | RFC4462 | SHOULD NOT |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| gss-group14-sha256-* | RFC8732 | SHOULD |		| gss-group14-sha256-* | RFC8732 | SHOULD |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| gss-group15-sha512-* | RFC8732 | MAY |		| gss-group15-sha512-* | RFC8732 | MAY |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| gss-group16-sha512-* | RFC8732 | SHOULD |		| gss-group16-sha512-* | RFC8732 | MAY |
	+--------------------------------------+-----------+------------+		+--------------------------------------+-----------+------------+
	| 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 | SHOULD |		| gss-nistp521-sha512-* | RFC8732 | SHOULD |
	skipping to change at page 12, line 17 ¶		skipping to change at page 12, line 17 ¶
	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.		session ID that may be used by higher-level protocols.
	Full security considerations for this protocol are provided in		Full security considerations for this protocol are provided in
	[RFC4251].		[RFC4251].
	It is desirable to deprecate or remove key exchange method name that		It is desirable to deprecate or remove key exchange method name that
	are considered weak. A key exchange method may be weak because too		are considered weak. A key exchange method may be weak because too
	few bits are used, or the hashing algorithm is considered too weak.		few bits are used, or the hashing algorithm is considered too weak,
			or for other reasons.
	7. IANA Considerations		7. IANA Considerations
	IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be		IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be
	implemented as being deprecated by this document.		implemented as being deprecated by this document.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	skipping to change at page 12, line 47 ¶		skipping to change at page 12, line 48 ¶
	[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)		[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
	Protocol Assigned Numbers", RFC 4250,		Protocol Assigned Numbers", RFC 4250,
	DOI 10.17487/RFC4250, January 2006,		DOI 10.17487/RFC4250, January 2006,
	<https://www.rfc-editor.org/info/rfc4250>.		<https://www.rfc-editor.org/info/rfc4250>.
	[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)		[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
	Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,		Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
	January 2006, <https://www.rfc-editor.org/info/rfc4253>.		January 2006, <https://www.rfc-editor.org/info/rfc4253>.
	[RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the
	Internet Key Exchange Protocol Version 2 (IKEv2) Key
	Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016,
	<https://www.rfc-editor.org/info/rfc8031>.
	[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>.
	[RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie-		[RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie-
	Hellman (DH) Key Exchange (KEX) Groups for Secure Shell		Hellman (DH) Key Exchange (KEX) Groups for Secure Shell
	(SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017,		(SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017,
	<https://www.rfc-editor.org/info/rfc8268>.		<https://www.rfc-editor.org/info/rfc8268>.
	[RFC8270] Velvindron, L. and M. Baushke, "Increase the Secure Shell		[RFC8270] Velvindron, L. and M. Baushke, "Increase the Secure Shell
	Minimum Recommended Diffie-Hellman Modulus Size to 2048		Minimum Recommended Diffie-Hellman Modulus Size to 2048
	Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017,		Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017,
	<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>.
			[RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure
			Shell (SSH) Key Exchange Method Using Curve25519 and
			Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020,
			<https://www.rfc-editor.org/info/rfc8731>.
	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",
	December 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>.
	skipping to change at page 14, line 15 ¶		skipping to change at page 14, line 20 ¶
	[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security		[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
	Considerations for the SHA-0 and SHA-1 Message-Digest		Considerations for the SHA-0 and SHA-1 Message-Digest
	Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,		Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
	<https://www.rfc-editor.org/info/rfc6194>.		<https://www.rfc-editor.org/info/rfc6194>.
	[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms		[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
	(SHA and SHA-based HMAC and HKDF)", RFC 6234,		(SHA and SHA-based HMAC and HKDF)", RFC 6234,
	DOI 10.17487/RFC6234, May 2011,		DOI 10.17487/RFC6234, May 2011,
	<https://www.rfc-editor.org/info/rfc6234>.		<https://www.rfc-editor.org/info/rfc6234>.
	[RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure		[RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the
	Shell (SSH) Key Exchange Method Using Curve25519 and		Internet Key Exchange Protocol Version 2 (IKEv2) Key
	Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020,		Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016,
	<https://www.rfc-editor.org/info/rfc8731>.		<https://www.rfc-editor.org/info/rfc8031>.
	[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]		[TRANS-COLL]
	Bhargavan, K. and G. Leurent, "Transcript Collision		Bhargavan, K. and G. Leurent, "Transcript Collision
	Attacks: Breaking Authentication in TLS, IKE, and SSH",		Attacks: Breaking Authentication in TLS, IKE, and SSH",
	Network and Distributed System Security Symposium - NDSS		Network and Distributed System Security Symposium - NDSS
End of changes. 28 change blocks.
	70 lines changed or deleted		72 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/