draft-ietf-curdle-rsa-sha2-11.txt		draft-ietf-curdle-rsa-sha2-12.txt
	Internet-Draft D. Bider		Internet-Draft D. Bider
	Updates: 4252, 4253 (if approved) Bitvise Limited		Updates: 4252, 4253 (if approved) Bitvise Limited
	Intended status: Standards Track October 6, 2017		Intended status: Standards Track October 12, 2017
	Expires: April 6, 2018		Expires: April 12, 2018
	Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)		Use of RSA Keys with SHA-256 and SHA-512 in Secure Shell (SSH)
	draft-ietf-curdle-rsa-sha2-11.txt		draft-ietf-curdle-rsa-sha2-12.txt
	Abstract		Abstract
	This memo updates RFC 4252 and RFC 4253 to define new public key		This memo updates RFC 4252 and RFC 4253 to define new public key
	algorithms for use of RSA keys with SHA-2 hashing for server and		algorithms for use of RSA keys with SHA-256 and SHA-512 for server and
	client authentication in SSH connections.		client authentication in SSH connections.
	Status		Status
	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 Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other		Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	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 public key		the Internet. In [RFC4253], SSH originally defined the public key
	algorithms "ssh-rsa" for server and client authentication using RSA		algorithms "ssh-rsa" for server and client authentication using RSA
	with SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1. These		with SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1. These
	algorithms are now considered deficient. For US government use, NIST		algorithms are now considered deficient. For US government use, NIST
	has disallowed 1024-bit RSA and DSA, and use of SHA-1 for signing		has disallowed 1024-bit RSA and DSA, and use of SHA-1 for signing
	[800-131A].		[800-131A].
	This memo updates RFC 4252 and RFC 4253 to define new public key		This memo updates RFC 4252 and RFC 4253 to define new public key
	algorithms allowing for interoperable use of existing and new RSA keys		algorithms allowing for interoperable use of existing and new RSA keys
	with SHA-2 hashing.		with SHA-256 and SHA-512.
	1.1. Requirements Terminology		1.1. Requirements Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.2. Wire Encoding Terminology		1.2. Wire Encoding Terminology
	The wire encoding types in this document - "boolean", "byte",		The wire encoding types in this document - "boolean", "byte",
	skipping to change at page 3, line 35 ¶		skipping to change at page 3, line 35 ¶
	mpint n		mpint n
	All aspects of the "ssh-rsa" format are kept, including the encoded		All aspects of the "ssh-rsa" format are kept, including the encoded
	string "ssh-rsa". This allows existing RSA keys to be used with the		string "ssh-rsa". This allows existing RSA keys to be used with the
	new public key algorithms, without requiring re-encoding, or affecting		new public key algorithms, without requiring re-encoding, or affecting
	already trusted key fingerprints.		already trusted key fingerprints.
	Signing and verifying using these algorithms is performed according to		Signing and verifying using these algorithms is performed according to
	the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash.		the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash.
	For the algorithm "rsa-sha2-256", the hash used is SHA-2 256.		For the algorithm "rsa-sha2-256", the hash used is SHA-256.
	For the algorithm "rsa-sha2-512", the hash used is SHA-2 512.		For the algorithm "rsa-sha2-512", the hash used is SHA-512.
	The resulting signature is encoded as follows:		The resulting signature is encoded as follows:
	string "rsa-sha2-256" / "rsa-sha2-512"		string "rsa-sha2-256" / "rsa-sha2-512"
	string rsa_signature_blob		string rsa_signature_blob
	The value for 'rsa_signature_blob' is encoded as a string containing		The value for 'rsa_signature_blob' is encoded as a string containing
	S - an octet string which is the output of RSASSA-PKCS1-v1_5, of		S - an octet string which is the output of RSASSA-PKCS1-v1_5, of
	length equal to the length in octets of the RSA modulus.		length equal to the length in octets of the RSA modulus.
	skipping to change at page 4, line 24 ¶		skipping to change at page 4, line 24 ¶
	with the appropriate signature algorithm name - either "rsa-sha2-256",		with the appropriate signature algorithm name - either "rsa-sha2-256",
	or "rsa-sha2-512".		or "rsa-sha2-512".
	3.2. Use for client authentication		3.2. Use for client authentication
	To use this algorithm for client authentication, the SSH client sends		To use this algorithm for client authentication, the SSH client sends
	an SSH_MSG_USERAUTH_REQUEST message [RFC4252] encoding the "publickey"		an SSH_MSG_USERAUTH_REQUEST message [RFC4252] encoding the "publickey"
	method, and encoding the string field "public key algorithm name" with		method, and encoding the string field "public key algorithm name" with
	the value "rsa-sha2-256" or "rsa-sha2-512". The "public key blob"		the value "rsa-sha2-256" or "rsa-sha2-512". The "public key blob"
	field encodes the RSA public key using the "ssh-rsa" public key		field encodes the RSA public key using the "ssh-rsa" public key
	format. The signature field, if present, encodes a signature using an		format.
	algorithm name that MUST match the SSH authentication request - either
	"rsa-sha2-256", or "rsa-sha2-512".
	For example, as defined in [RFC4252] and [RFC4253], an SSH "publickey"		For example, as defined in [RFC4252] and [RFC4253], an SSH "publickey"
	authentication request using an "rsa-sha2-512" signature would be		authentication request using an "rsa-sha2-512" signature would be
	properly encoded as follows:		properly encoded as follows:
	byte SSH_MSG_USERAUTH_REQUEST		byte SSH_MSG_USERAUTH_REQUEST
	string user name		string user name
	string service name		string service name
	string "publickey"		string "publickey"
	boolean TRUE		boolean TRUE
	string "rsa-sha2-512"		string "rsa-sha2-512"
	string public key blob:		string public key blob:
	string "ssh-rsa"		string "ssh-rsa"
	mpint e		mpint e
	mpint n		mpint n
	string signature:		string signature:
	string "rsa-sha2-512"		string "rsa-sha2-512"
	string rsa_signature_blob		string rsa_signature_blob
			If the client includes the signature field, the client MUST encode the
			same algorithm name in the signature as in SSH_MSG_USERAUTH_REQUEST -
			either "rsa-sha2-256", or "rsa-sha2-512". If a server receives a
			mismatching request, it MAY apply arbitrary authentication penalties,
			including but not limited to authentication failure or disconnect.
			OpenSSH 7.2 (but not 7.2p2) incorrectly encodes the algorithm in the
			signature as "ssh-rsa" when the algorithm in SSH_MSG_USERAUTH_REQUEST
			is "rsa-sha2-256" or "rsa-sha2-512". In this case, the signature does
			actually use either SHA-256 or SHA-512. A server MAY, but is not
			required to, accept this variant, or another variant that corresponds
			to a good-faith implementation, and is decided to be safe to accept.
	3.3. Discovery of public key algorithms supported by servers		3.3. Discovery of public key algorithms supported by servers
	Implementation experience has shown that there are servers which apply		Implementation experience has shown that there are servers which apply
	authentication penalties to clients attempting public key algorithms		authentication penalties to clients attempting public key algorithms
	which the SSH server does not support.		which the SSH server does not support.
	Servers that accept rsa-sha2-* signatures for client authentication		Servers that accept rsa-sha2-* signatures for client authentication
	SHOULD implement the extension negotiation mechanism defined in		SHOULD implement the extension negotiation mechanism defined in
	[EXT-INFO], including especially the "server-sig-algs" extension.		[EXT-INFO], including especially the "server-sig-algs" extension.
	skipping to change at page 5, line 41 ¶		skipping to change at page 5, line 51 ¶
	The security considerations of [RFC4251] apply to this document.		The security considerations of [RFC4251] apply to this document.
	5.1. Key Size and Signature Hash		5.1. Key Size and Signature Hash
	The National Institute of Standards and Technology (NIST) Special		The National Institute of Standards and Technology (NIST) Special
	Publication 800-131A, Revision 1 [800-131A], disallows the use of RSA		Publication 800-131A, Revision 1 [800-131A], disallows the use of RSA
	and DSA keys shorter than 2048 bits for US government use. The same		and DSA keys shorter than 2048 bits for US government use. The same
	document disallows the SHA-1 hash function for digital signature		document disallows the SHA-1 hash function for digital signature
	generation, except under NIST's protocol-specific guidance.		generation, except under NIST's protocol-specific guidance.
			It is prudent to follow this advice also outside of US government use.
	5.2. Transition		5.2. Transition
	This document is based on the premise that RSA is used in environments		This document is based on the premise that RSA is used in environments
	where a gradual, compatible transition to improved algorithms will be		where a gradual, compatible transition to improved algorithms will be
	better received than one that is abrupt and incompatible. It advises		better received than one that is abrupt and incompatible. It advises
	that SSH implementations add support for new RSA public key algorithms		that SSH implementations add support for new RSA public key algorithms
	along with SSH_MSG_EXT_INFO and the "server-sig-algs" extension to		along with SSH_MSG_EXT_INFO and the "server-sig-algs" extension to
	allow coexistence of new deployments with older versions that support		allow coexistence of new deployments with older versions that support
	only "ssh-rsa". Nevertheless, implementations SHOULD start to disable		only "ssh-rsa". Nevertheless, implementations SHOULD start to disable
	"ssh-rsa" in their default configurations as soon as they have reason		"ssh-rsa" in their default configurations as soon as they have reason
	skipping to change at page 7, line 26 ¶		skipping to change at page 7, line 26 ¶
	[RFC4251] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)		[RFC4251] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
	Protocol Architecture", RFC 4251, January 2006.		Protocol Architecture", RFC 4251, January 2006.
	[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)		[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
	Authentication Protocol", RFC 4252, January 2006.		Authentication Protocol", RFC 4252, January 2006.
	[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, January 2006.		Transport Layer Protocol", RFC 4253, January 2006.
			[EXT-INFO] Bider, D., "Extension Negotiation in Secure Shell (SSH)",
			draft-ietf-curdle-ssh-ext-info-15.txt, September 2017,
			<https://tools.ietf.org/html/
			draft-ietf-curdle-ssh-ext-info-15>.
	6.2. Informative References		6.2. Informative References
	[800-131A] National Institute of Standards and Technology (NIST),		[800-131A] National Institute of Standards and Technology (NIST),
	"Transitions: Recommendation for Transitioning the Use of		"Transitions: Recommendation for Transitioning the Use of
	Cryptographic Algorithms and Key Lengths", NIST Special		Cryptographic Algorithms and Key Lengths", NIST Special
	Publication 800-131A, Revision 1, November 2015,		Publication 800-131A, Revision 1, November 2015,
	<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/		<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
	NIST.SP.800-131Ar1.pdf>.		NIST.SP.800-131Ar1.pdf>.
	[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, January 2006.		Protocol Assigned Numbers", RFC 4250, January 2006.
	[RFC6979] Pornin, T., "Deterministic Usage of the Digital
	Signature Algorithm (DSA) and Elliptic Curve Digital
	Signature Algorithm (ECDSA)", RFC 6979, August 2013.
	[RFC8017] Moriarty, K., Kaliski, B., Jonsson, J. and Rusch, A.,		[RFC8017] Moriarty, K., Kaliski, B., Jonsson, J. and Rusch, A.,
	"PKCS #1: RSA Cryptography Specifications Version 2.2",		"PKCS #1: RSA Cryptography Specifications Version 2.2",
	RFC 8017, November 2016.		RFC 8017, November 2016.
	[EXT-INFO] Bider, D., "Extension Negotiation in Secure Shell (SSH)",
	draft-ietf-curdle-ssh-ext-info-15.txt, September 2017,
	<https://tools.ietf.org/html/
	draft-ietf-curdle-ssh-ext-info-15>.
	[IANA-PKA] "Secure Shell (SSH) Protocol Parameters",		[IANA-PKA] "Secure Shell (SSH) Protocol Parameters",
	<https://www.iana.org/assignments/ssh-parameters/		<https://www.iana.org/assignments/ssh-parameters/
	ssh-parameters.xhtml#ssh-parameters-19>.		ssh-parameters.xhtml#ssh-parameters-19>.
	Author's Address		Author's Address
	Denis Bider		Denis Bider
	Bitvise Limited		Bitvise Limited
	4105 Lombardy Court		4105 Lombardy Court
	Colleyville, Texas 76034		Colleyville, Texas 76034
	United States of America		United States of America
	Email: ietf-ssh3@denisbider.com		Email: ietf-ssh3@denisbider.com
	URI: https://www.bitvise.com/		URI: https://www.bitvise.com/
	Acknowledgments		Acknowledgments
	Thanks to Jon Bright, Niels Moeller, Stephen Farrell, Mark D. Baushke,		Thanks to Jon Bright, Niels Moeller, Stephen Farrell, Mark D. Baushke,
	Jeffrey Hutzelman, Hanno Boeck, Peter Gutmann, Damien Miller, Mat		Jeffrey Hutzelman, Hanno Boeck, Peter Gutmann, Damien Miller, Mat
	Berchtold, Roumen Petrov, Daniel Migault, and Eric Rescorla for reviews,		Berchtold, Roumen Petrov, Daniel Migault, Eric Rescorla, Russ Housley,
	comments, and suggestions.		Alissa Cooper, Adam Roach, and Ben Campbell for reviews, comments, and
			suggestions.
End of changes. 12 change blocks.
	20 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/