< draft-ietf-curdle-rsa-sha2-03-rpetrov.txt		draft-ietf-curdle-rsa-sha2-03.txt >
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	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].
	2. Public Key Algorithms		2. Public Key Algorithms
	This memo adopts the style and conventions of [RFC4253] in specifying		This memo adopts the style and conventions of [RFC4253] in specifying
	how use of a public key algorithm is indicated in SSH.		how use of a signature algorithm is indicated in SSH.
	The following new public key algorithms are defined:		The following new signature algorithms are defined:
	rsa-sha2-256 RECOMMENDED sign Raw RSA key		rsa-sha2-256 RECOMMENDED sign Raw RSA key
	rsa-sha2-512 OPTIONAL sign Raw RSA key		rsa-sha2-512 OPTIONAL sign Raw RSA key
	These algorithms are suitable for use both in the SSH transport		These signature algorithms are suitable for use both in the SSH transport
	layer [RFC4253] for server authentication, and in the authentication		layer [RFC4253] for server authentication, and in the authentication
	layer [RFC4252] for client authentication.		layer [RFC4252] for client authentication.
	2.1. Public Key Format
	Since RSA keys are not dependent on the choice of hash function, both		Since RSA keys are not dependent on the choice of hash function, both
	new algorithms reuse the public key format of the existing "ssh-rsa"		new algorithms reuse the public key format of the existing "ssh-rsa"
	algorithm as defined in [RFC4253]:		algorithm as defined in [RFC4253]:
	string "ssh-rsa"		string "ssh-rsa"
	mpint e		mpint e
	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", in order to allow users' existing RSA keys to be		string "ssh-rsa", in order to allow users' existing RSA keys to be
	used with the new signature formats, without requiring re-encoding,		used with the new signature formats, without requiring re-encoding,
	or affecting already trusted key fingerprints.		or affecting already trusted key fingerprints.
	2.2. Signature Encoding
	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 [RFC3447] using SHA-2 [FIPS-180-4] as		the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using SHA-2 [FIPS-180-4] as
	hash; MGF1 as mask function; and salt length equal to hash size.		hash; MGF1 as mask function; and salt length equal to hash size.
	For the algorithm "rsa-sha2-256", the hash used is SHA-2 256.		For the algorithm "rsa-sha2-256", the hash used is SHA-2 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-2 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.
	2.3. Use for server authentication		2.1. Use for server authentication
	To express support and preference for one or both of these algorithms		To express support and preference for one or both of these algorithms
	for server authentication, the SSH client or server includes one or		for server authentication, the SSH client or server includes one or
	both algorithm names, "rsa-sha2-256" and/or "rsa-sha2-512", in the		both algorithm names, "rsa-sha2-256" and/or "rsa-sha2-512", in the
	name-list field "server_host_key_algorithms" in the SSH_MSG_KEXINIT		name-list field "server_host_key_algorithms" in the SSH_MSG_KEXINIT
	packet [RFC4253]. If one of the two host key algorithms is negotiated,		packet [RFC4253]. If one of the two host key algorithms is negotiated,
	the server sends an "ssh-rsa" public key as part of the negotiated key		the server sends an "ssh-rsa" public key as part of the negotiated key
	exchange method (e.g. in SSH_MSG_KEXDH_REPLY), and encodes a signature		exchange method (e.g. in SSH_MSG_KEXDH_REPLY), and encodes a signature
	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".
	2.4. Use for client authentication		2.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" format identifier.		field encodes the RSA public key using the "ssh-rsa" algorithm name.
	The signature field, if present, encodes a signature using an		The signature field, if present, encodes a signature using an
	signature format identifier that MUST match the algorithm name in SSH authentication request - either		algorithm name that MUST match the SSH authentication request - either
	"rsa-sha2-256", or "rsa-sha2-512".		"rsa-sha2-256", or "rsa-sha2-512".
	For example, an SSH "publickey" signed authentication request using an		For example, an SSH "publickey" authentication request using an
	"rsa-sha2-512" algorithm would be properly encoded as follows:		"rsa-sha2-512" signature would be 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
	skipping to change at page 4, line 21 ¶		skipping to change at page 4, line 21 ¶
	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
	[SSH-EXT-INFO], including especially the "server-sig-algs" extension.		[SSH-EXT-INFO], including especially the "server-sig-algs" extension.
	When authenticating with an RSA key against a server that does not		When authenticating with an RSA key against a server that does not
	implement the "server-sig-algs" extension, clients MAY default to an		implement the "server-sig-algs" extension, clients MAY default to an
	ssh-rsa signature to avoid authentication penalties.		ssh-rsa signature to avoid authentication penalties.
	4. IANA Considerations		4. IANA Considerations
	Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250],		IANA is requested to update the "Secure Shell (SSH) Protocol
	this document makes the following registrations:		Parameters" registry, to extend the table Public Key Algorithm Names:
	In the Public Key Algorithm Names registry:		- To the immediate right of the column Public Key Algorithm Name,
	- The SSH public key algorithm "rsa-sha2-256".		a new column is to be added, titled Signature Algorithm Name. For
	- The SSH public key algorithm "rsa-sha2-512".		existing entries, the column Signature Algorithm Name should be
			assigned the same value found under Public Key Algorithm Name.
	This document creates no new registries.		- Immediately following the existing entry for "ssh-rsa", two sibling
			entries are to be added:
			P. K. Alg. Name Sig. Alg. Name Reference Note
			ssh-rsa rsa-sha2-256 [this document] Section 2
			ssh-rsa rsa-sha2-512 [this document] Section 2
	5. Security Considerations		5. Security Considerations
	The security considerations of [RFC4253] apply to this document.		The security considerations of [RFC4253] apply to this document.
	The National Institute of Standards and Technology (NIST) Special		The National Institute of Standards and Technology (NIST) Special
	Publication 800-131A [800-131A] disallows the use of RSA and DSA keys		Publication 800-131A [800-131A] disallows the use of RSA and DSA keys
	shorter than 2048 bits for US government use after 2013. Keys of 2048		shorter than 2048 bits for US government use after 2013. Keys of 2048
	bits or larger are considered acceptable.		bits or larger are considered acceptable.
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	FIPS Publication 180-4, August 2015,		FIPS Publication 180-4, August 2015,
	<http://dx.doi.org/10.6028/NIST.FIPS.180-4>.		<http://dx.doi.org/10.6028/NIST.FIPS.180-4>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography		[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
	Standards (PKCS) #1: RSA Cryptography Specifications		Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 3447, February 2003.		Version 2.1", RFC 3447, February 2003.
	[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH)
	Protocol Assigned Numbers", RFC 4250, January 2006.
	[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
	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.
	7.2. Informative References		7.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
End of changes. 14 change blocks.
	25 lines changed or deleted		21 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/