< draft-ietf-curdle-ssh-kex-sha2-04.txt		draft-ietf-curdle-ssh-kex-sha2-05.txt >
	Internet Engineering Task Force M. Baushke		Internet Engineering Task Force M. Baushke
	Internet-Draft Juniper Networks, Inc.		Internet-Draft Juniper Networks, Inc.
	Updates: 4253, 4419, 4432, 4462, 5656 September 7, 2016		Updates: 4253, 4419, 4432, 4462, 5656 September 20, 2016
	(if approved)		(if approved)
	Intended status: Standards Track		Intended status: Standards Track
	Expires: March 11, 2017		Expires: March 24, 2017
	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-04		draft-ietf-curdle-ssh-kex-sha2-05
	Abstract		Abstract
	This document adds recommendations for adoption of ssh-curves from		This document adds recommendations for adoption of ssh-curves from
	the [I-D.ietf-curdle-ssh-curves], adds some new Modular Exponential		the [I-D.ietf-curdle-ssh-curves] and new-modp from the
	(MODP) Groups, and deprecates some previously specified Key Exchange		[I-D.ietf-curdle-ssh-modp-dh-sha2], and deprecates some previously
	Method algorithm names for the Secure Shell (SSH) protocol. It also		specified Key Exchange Method algorithm names for the Secure Shell
	updates [RFC4253], [RFC4419], [RFC4462], and [RFC5656] by specifying		(SSH) protocol. It also updates [RFC4253], [RFC4419], [RFC4462], and
	the set key exchange algorithms that currently exist and which ones		[RFC5656] by specifying the set key exchange algorithms that
	MUST, SHOULD, MAY, and SHOULD NOT be implemented. New key exchange		currently exist and which ones MUST, SHOULD, MAY, and SHOULD NOT be
	methods use the SHA-2 family of hashes.		implemented. New key exchange methods use the SHA-2 family of
			hashes.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 March 11, 2017.		This Internet-Draft will expire on March 24, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 17 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	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 the Key Exchange		the Internet. In [RFC4253], SSH originally defined the Key Exchange
	Method Name diffie-hellman-group1-sha1 which used [RFC2409] Oakley		Method Name diffie-hellman-group1-sha1 which used [RFC2409] Oakley
	Group 1 (a 768-bit MODP group) and SHA-1 [RFC3174]. Due to recent		Group 2 (a 1024-bit MODP group) and SHA-1 [RFC3174]. Due to recent
	security concerns with SHA-1 [RFC6194] and with MODP groups with less		security concerns with SHA-1 [RFC6194] and with MODP groups with less
	than 2048 bits [NIST-SP-800-131Ar1] implementer and users request		than 2048 bits [NIST-SP-800-131Ar1] implementer and users request
	support for larger MODP group sizes with data integrity verification		support for larger MODP group sizes with data integrity verification
	using the SHA-2 family of secure hash algorithms as well as MODP		using the SHA-2 family of secure hash algorithms as well as MODP
	groups providing more security.		groups providing more security.
	The United States Information Assurance Directorate (IAD) at the		The United States Information Assurance Directorate (IAD) at the
	National Security Agency (NSA) has published a FAQ		National Security Agency (NSA) has published a FAQ
	[MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve		[MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve
	Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes		Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes
	less than SHA2-384 are no longer sufficient for transport of Top		less than SHA2-384 are no longer sufficient for transport of Top
	Secret information. It is for this reason that this draft moves		Secret information. It is for this reason that this draft moves
	ecdh-sha2-nistp256 from a REQUIRED to OPTIONAL as a key exchange		ecdh-sha2-nistp256 from a REQUIRED to OPTIONAL as a key exchange
	method. This is the same reason that the stronger MODP groups being		method. This is the same reason that the stronger MODP groups being
	introduced are using SHA2-512 as the hash algorithm. Group14 is		adopted. As the MODP group14 is already present in most SSH
	already present in most SSH implementations and most implementations		implementations and most implementations already have a SHA2-256
	already have a SHA2-256 implementation, so diffie-hellman-		implementation, so diffie-hellman-group14-sha256 is provided as an
	group14-sha256 is provided as an easy to implement and faster to use		easy to implement and faster to use key exchange. Small embedded
	key exchange. Small embedded applications may find this KEX		applications may find this KEX desirable to use.
	desirable to use.
	The NSA Information Assurance Directorate (IAD) has also published		The NSA Information Assurance Directorate (IAD) has also published
	the Commercial National Security Algorithm Suite (CNSA Suite)		the Commercial National Security Algorithm Suite (CNSA Suite)
	[CNSA-SUITE] in which the 3072-bit MODP Group 15 in RFC 3526 is		[CNSA-SUITE] in which the 3072-bit MODP Group 15 in RFC 3526 is
	explicitly mentioned as the minimum modulus to protect Top Secret		explicitly mentioned as the minimum modulus to protect Top Secret
	communications.		communications.
	It has been observed in [safe-curves] that the NIST recommended		It has been observed in [safe-curves] that the NIST recommended
	Elliptic Curve Prime Curves (P-256, P-384, and P-521) are perhaps not		Elliptic Curve Prime Curves (P-256, P-384, and P-521) are perhaps not
	the best available for Elliptic Curve Cryptography (ECC) Security.		the best available for Elliptic Curve Cryptography (ECC) Security.
	skipping to change at page 3, line 22 ¶		skipping to change at page 3, line 22 ¶
	3. Key Exchange Algorithms		3. Key Exchange Algorithms
	This memo adopts the style and conventions of [RFC4253] in specifying		This memo adopts the style and conventions of [RFC4253] in specifying
	how the use of new data key exchange is indicated in SSH.		how the use of new data key exchange is indicated in SSH.
	A new set of Elliptic Curve Diffie-Hellman ssh-curves exist. The		A new set of Elliptic Curve Diffie-Hellman ssh-curves exist. The
	curve25519-sha256 MUST be adopted where possible.		curve25519-sha256 MUST be adopted where possible.
	As a hedge against uncertainty raised by the NSA IAD FAQ publication,		As a hedge against uncertainty raised by the NSA IAD FAQ publication,
	five new MODP Diffie-Hellman based key exchanges are proposed for		new MODP Diffie-Hellman based key exchanges are proposed for
	inclusion in the set of key exchange method names as well as the		inclusion in the set of key exchange method names as well as the
	curve448-sha512 curve.		curve448-sha512 curve.
	The following new key exchange algorithms are defined:		The following new key exchange algorithms are defined:
	Key Exchange Method Name Note		Key Exchange Method Name Note
	diffie-hellman-group14-sha256 SHOULD/RECOMMENDED		----------------------------- ------------------
	diffie-hellman-group15-sha512 MAY/OPTIONAL		curve25519-sha256 MUST/REQUIRED
	diffie-hellman-group16-sha512 SHOULD/RECOMMENDED		curve448-sha512 MAY/OPTIONAL
	diffie-hellman-group17-sha512 MAY/OPTIONAL		diffie-hellman-group14-sha256 MUST/REQUIRED
	diffie-hellman-group18-sha512 MAY/OPTIONAL		diffie-hellman-group15-sha512 MAY/OPTIONAL
			diffie-hellman-group16-sha512 SHOULD/RECOMMENDED
	Figure 1		diffie-hellman-group17-sha512 MAY/OPTIONAL
			diffie-hellman-group18-sha512 MAY/OPTIONAL
			gss-group14-sha256-* SHOULD/RECOMMENDED
			gss-group15-sha512-* MAY/OPTIONAL
			gss-group16-sha512-* SHOULD/RECOMMENDED
			gss-group17-sha512-* MAY/OPTIONAL
			gss-group18-sha512-* MAY/OPTIONAL
	The SHA-2 family of secure hash algorithms are defined in		The SHA-2 family of secure hash algorithms are defined in
	[FIPS-180-4].		[FIPS-180-4].
	The method of key exchange used for the name "diffie-hellman-		4. IANA Considerations
	group14-sha256" is the same as that for "diffie-hellman-group14-sha1"
	except that the SHA2-256 hash algorithm is used. This new method is
	desirable for interoperability with resource-constrained devices.
	The group15 through group18 names are the same as those specified in
	[RFC3526] 3072-bit MODP Group 15, 4096-bit MODP Group 16, 6144-bit
	MODP Group 17, and 8192-bit MODP Group 18. All of these groups are
	within the guidelines for CNSA Suite for Top Secret.
	The SHA2-512 algorithm is to be used when "sha512" is specified as a		This RFC augments the Key Exchange Method Names in [RFC4253]. It
	part of the key exchange method name.		downgrades the use of SHA-1 hashing for key exchange methods in
			[RFC4419], [RFC4432], and [RFC4462]. It also moves from MUST to
			SHOULD the ecdh-sha2-nistp256 given in [RFC5656].
	4. IANA Considerations		It adds a new set of named "gss-*" methods to [RFC4462] with a MAY
			recommendation.
	This document augments the Key Exchange Method Names in [RFC4253].		It is desirable to also include the new-modp from the
	It downgrades the use of SHA-1 hashing for key exchange methods in		[I-D.ietf-curdle-ssh-modp-dh-sha2] in this list.
	[RFC4419], [RFC4432], and [RFC4462]. It also moves from MUST to MAY
	the ecdh-sha2-nistp256 given in [RFC5656].
	It is desirable to also include the ssh-curves from the		It is desirable to also include the ssh-curves from the
	[I-D.ietf-curdle-ssh-curves] in this list. The "curve25519-sha256"		[I-D.ietf-curdle-ssh-curves] in this list. The "curve25519-sha256"
	is currently available in some Secure Shell implementations under the		is currently available in some Secure Shell implementations under the
	name "curve25519-sha256@libssh.org" and is the best candidate for a		name "curve25519-sha256@libssh.org" and is the best candidate for a
	fast, safe, and secure key exchange method.		fast, safe, and secure key exchange method.
	IANA is requested to update the SSH algorithm registry with the		IANA is requested to update the SSH algorithm registry to ensure that
	following entries:		all of the listed Key Exchange Method Name and References exist in
			the following table. However, the Implement column is just the
	Key Exchange Method Name Reference Note		current recommendations of this RFC.
	diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT
	diffie-hellman-group-exchange-sha256 RFC4419 MAY
	diffie-hellman-group1-sha1 RFC4253 SHOULD NOT
	diffie-hellman-group14-sha1 RFC4253 SHOULD
	ecdh-sha2-nistp256 RFC5656 MAY
	ecdh-sha2-nistp384 RFC5656 SHOULD
	ecdh-sha2-nistp521 RFC5656 SHOULD
	ecdh-sha2-* RFC5656 MAY
	ecmqv-sha2 RFC5656 MAY
	gss-gex-sha1-* RFC4462 SHOULD NOT
	gss-group1-sha1-* RFC4462 SHOULD NOT
	gss-group14-sha1-* RFC4462 MAY
	gss-* RFC4462 MAY
	rsa1024-sha1 RFC4432 SHOULD NOT
	rsa2048-sha256 RFC4432 MAY
	diffie-hellman-group14-sha256 This Draft SHOULD
	diffie-hellman-group15-sha512 This Draft MAY
	diffie-hellman-group16-sha512 This Draft SHOULD
	diffie-hellman-group17-sha512 This Draft MAY
	diffie-hellman-group18-sha512 This Draft MAY
	curve25519-sha256 ssh-curves MUST
	curve448-sha512 ssh-curves MAY
	Figure 2		Key Exchange Method Name Reference Implement
			------------------------------------ ---------- ----------
			curve25519-sha256 ssh-curves MUST
			curve448-sha512 ssh-curves MAY
			diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT
			diffie-hellman-group-exchange-sha256 RFC4419 MAY
			diffie-hellman-group1-sha1 RFC4253 SHOULD NOT
			diffie-hellman-group14-sha1 RFC4253 SHOULD
			diffie-hellman-group14-sha256 new-modp MUST
			diffie-hellman-group15-sha512 new-modp MAY
			diffie-hellman-group16-sha512 new-modp SHOULD
			diffie-hellman-group17-sha512 new-modp MAY
			diffie-hellman-group18-sha512 new-modp MAY
			ecdh-sha2-nistp256 RFC5656 SHOULD
			ecdh-sha2-nistp384 RFC5656 SHOULD
			ecdh-sha2-nistp521 RFC5656 SHOULD
			ecdh-sha2-* RFC5656 MAY
			ecmqv-sha2 RFC5656 SHOULD NOT
			gss-gex-sha1-* RFC4462 SHOULD NOT
			gss-group1-sha1-* RFC4462 SHOULD NOT
			gss-group14-sha1-* RFC4462 SHOULD
			gss-group14-sha256-* new-modp SHOULD
			gss-group15-sha512-* new-modp MAY
			gss-group16-sha512-* new-modp SHOULD
			gss-group17-sha512-* new-modp MAY
			gss-group18-sha512-* new-modp MAY
			gss-* RFC4462 MAY
			rsa1024-sha1 RFC4432 SHOULD NOT
			rsa2048-sha256 RFC4432 MAY
	The Note column in the above table is an implementation suggestion/		The Implement column in the above table is a suggestion/
	recommendation for the listed key exchange method. It is up to the		recommendation for the listed key exchange method to be implemented
	end-user as to what algorithms they choose to be able to negotiate.		in the default list of key exchange methods. It is up to the end-
			user as to what algorithms they choose to be able to negotiate, so
			the KEX algorithms should be configurable by the administrator of the
			server as well as the user of the client. This RFC is intended to
			provide IANA defined names for these groups for interoperability.
			The Note column of the IANA table should probably continue to point
			to the implementation detail sections of the Reference RFCs where
			appropriate.
	The guidance of his document is that the SHA-1 algorithm hashing		The guidance of his RFC is that the SHA-1 algorithm hashing SHOULD
	SHOULD NOT be used. If it is used, it should only be provided for		NOT be used. If it is used, it should only be provided for backwards
	backwards compatibility, should not be used in new designs, and		compatibility, should not be used in new designs, and should be
	should be phased out of existing key exchanges as quickly as possible		phased out of existing key exchanges as quickly as possible because
	because of its known weaknesses. Any key exchange using SHA-1 SHOULD		of its known weaknesses. Any key exchange using SHA-1 SHOULD NOT be
	NOT be in a default key exchange list if at all possible. If they		in a default key exchange list if at all possible. If they are
	are needed for backward compatibility, they SHOULD be listed after		needed for backward compatibility, they SHOULD be listed after all of
	all of the SHA-2 based key exchanges.		the SHA-2 based key exchanges.
	The RFC4253 REQUIRED diffie-hellman-group14-sha1 method SHOULD be		The RFC4253 REQUIRED diffie-hellman-group14-sha1 method SHOULD be
	retained for compatibility with older Secure Shell implementations.		retained for compatibility with older Secure Shell implementations.
	It is intended that this key exchange be phased out as soon as		It is intended that this key exchange method be phased out as soon as
	possible.		possible.
			It is believed that all current SSH implementations should be able to
			achieve an implementation of the "diffie-hellman-group14-sha256"
			method. To that end, this is one method that MUST be implemented.
			If GSS-API methods are available, then the RFC4462 REQUIRED gss-
			group14-sha1-* method SHOULD be retained for compatibility with older
			Secure Shell implementations and the gss-groups14-sha256-* method
			SHOULD be added as for "sha1".
			[TO BE REMOVED: This registration should take place at the following
			location: <http://www.iana.org/assignments/ssh-parameters/ssh-
			parameters.xhtml#ssh-parameters-16>]
	5. Acknowledgements		5. Acknowledgements
	Thanks to the following people for review and comments: Denis Bider,		Thanks to the following people for review and comments: Denis Bider,
	Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto		Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto
	Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault.		Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault.
	Thanks to the following people for code to implement interoperable		Thanks to the following people for code to implement interoperable
	exchanges using some of these groups as found in an this draft:		exchanges using some of these groups as found in an this draft:
	Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks		Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks
	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
	The security considerations of [RFC4253] apply to this document.		The security considerations of [RFC4253] apply to this RFC.
	The security considerations of [RFC3526] suggest that these MODP		The security considerations of [RFC3526] suggest that these MODP
	groups have security strengths given in this table. They are based		groups have security strengths given in this table. They are based
	on [RFC3766] Determining Strengths For Public Keys Used For		on [RFC3766] Determining Strengths For Public Keys Used For
	Exchanging Symmetric Keys.		Exchanging Symmetric Keys.
	Group modulus security strength estimates (RFC3526)		Group modulus security strength estimates (RFC3526)
	+--------+----------+---------------------+---------------------+		+--------+----------+---------------------+---------------------+
	| Group | Modulus | Strength Estimate 1 | Strength Estimate 2 |		| Group | Modulus | Strength Estimate 1 | Strength Estimate 2 |
	skipping to change at page 6, line 20 ¶		skipping to change at page 6, line 31 ¶
	| | | | exponent | | exponent |		| | | | exponent | | exponent |
	| | | in bits | size | in bits | size |		| | | in bits | size | in bits | size |
	+--------+----------+----------+----------+----------+----------+		+--------+----------+----------+----------+----------+----------+
	| 14 | 2048-bit | 110 | 220- | 160 | 320- |		| 14 | 2048-bit | 110 | 220- | 160 | 320- |
	| 15 | 3072-bit | 130 | 260- | 210 | 420- |		| 15 | 3072-bit | 130 | 260- | 210 | 420- |
	| 16 | 4096-bit | 150 | 300- | 240 | 480- |		| 16 | 4096-bit | 150 | 300- | 240 | 480- |
	| 17 | 6144-bit | 170 | 340- | 270 | 540- |		| 17 | 6144-bit | 170 | 340- | 270 | 540- |
	| 18 | 8192-bit | 190 | 380- | 310 | 620- |		| 18 | 8192-bit | 190 | 380- | 310 | 620- |
	+--------+----------+---------------------+---------------------+		+--------+----------+---------------------+---------------------+
	Figure 3		Figure 1
	Many users seem to be interested in the perceived safety of using		Many users seem to be interested in the perceived safety of using
	larger MODP groups and hashing with SHA2-based algorithms.		larger MODP groups and hashing with SHA2-based algorithms.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[FIPS-180-4]		[FIPS-180-4]
	National Institute of Standards and Technology, "Secure		National Institute of Standards and Technology, "Secure
	skipping to change at page 7, line 18 ¶		skipping to change at page 7, line 27 ¶
	"Information Assurance by the National Security Agency",		"Information Assurance by the National Security Agency",
	"Commercial National Security Algorithm Suite", September		"Commercial National Security Algorithm Suite", September
	2016, <https://www.iad.gov/iad/programs/iad-initiatives/		2016, <https://www.iad.gov/iad/programs/iad-initiatives/
	cnsa-suite.cfm>.		cnsa-suite.cfm>.
	[I-D.ietf-curdle-ssh-curves]		[I-D.ietf-curdle-ssh-curves]
	Adamantiadis, A. and S. Josefsson, "Secure Shell (SSH) Key		Adamantiadis, A. and S. Josefsson, "Secure Shell (SSH) Key
	Exchange Method using Curve25519 and Curve448", draft-		Exchange Method using Curve25519 and Curve448", draft-
	ietf-curdle-ssh-curves-00 (work in progress), March 2016.		ietf-curdle-ssh-curves-00 (work in progress), March 2016.
			[I-D.ietf-curdle-ssh-modp-dh-sha2]
			Baushke, M., "More Modular Exponential (MODP) Diffie-
			Hellman (DH) Key Exchange (KEX) Groups for Secure Shell
			(SSH)", draft-ietf-curdle-ssh-modp-dh-sha2-00 (work in
			progress), September 2016.
	[MFQ-U-OO-815099-15]		[MFQ-U-OO-815099-15]
	"National Security Agency/Central Security Service", "CNSA		"National Security Agency/Central Security Service", "CNSA
	Suite and Quantum Computing FAQ", January 2016,		Suite and Quantum Computing FAQ", January 2016,
	<https://www.iad.gov/iad/library/ia-guidance/ia-solutions-		<https://www.iad.gov/iad/library/ia-guidance/ia-solutions-
	for-classified/algorithm-guidance/cnsa-suite-and-quantum-		for-classified/algorithm-guidance/cnsa-suite-and-quantum-
	computing-faq.cfm>.		computing-faq.cfm>.
	[NIST-SP-800-131Ar1]		[NIST-SP-800-131Ar1]
	Barker, and Roginsky, "Transitions: Recommendation for the		Barker, and Roginsky, "Transitions: Recommendation for the
	Transitioning of the Use of Cryptographic Algorithms and		Transitioning of the Use of Cryptographic Algorithms and
End of changes. 22 change blocks.
	84 lines changed or deleted		115 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/