< draft-harris-ssh-rsa-kex-04.txt		draft-harris-ssh-rsa-kex-05.txt >
	Network Working Group B. Harris		Network Working Group B. Harris
	Internet-Draft August 15, 2005		Internet-Draft August 25, 2005
	Expires: February 16, 2006		Expires: February 26, 2006
	Rivest-Shamir-Adleman (RSA) key exchange for the Secure Shell (SSH)		Rivest-Shamir-Adleman (RSA) key exchange for the Secure Shell (SSH)
	Transport Layer Protocol		Transport Layer Protocol
	draft-harris-ssh-rsa-kex-04		draft-harris-ssh-rsa-kex-05
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on February 16, 2006.		This Internet-Draft will expire on February 26, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This memo describes a key-exchange method for the Secure Shell (SSH)		This memo describes a key-exchange method for the Secure Shell (SSH)
	protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption.		protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption.
	It uses much less client CPU time than the Diffie-Hellman algorithm		It uses much less client CPU time than the Diffie-Hellman algorithm
	skipping to change at page 4, line 27 ¶		skipping to change at page 4, line 28 ¶
	This value is called the exchange hash, and it is used to		This value is called the exchange hash, and it is used to
	authenticate the key exchange. The exchange hash SHOULD be kept		authenticate the key exchange. The exchange hash SHOULD be kept
	secret.		secret.
	The signature algorithm MUST be applied over H, not the original		The signature algorithm MUST be applied over H, not the original
	data. Most signature algorithms include hashing and additional		data. Most signature algorithms include hashing and additional
	padding. For example, "ssh-dss" specifies SHA-1 hashing. In such		padding. For example, "ssh-dss" specifies SHA-1 hashing. In such
	cases, the data is first hashed with HASH to compute H, and H is then		cases, the data is first hashed with HASH to compute H, and H is then
	hashed again as part of the signing operation.		hashed again as part of the signing operation.
	5. rsa1024-sha1-draft-04@putty.projects.tartarus.org		5. rsa1024-sha1
	The "rsa1024-sha1-draft-04@putty.projects.tartarus.org" method		The "rsa1024-sha1" method specifies RSA key exchange as described
	specifies RSA key exchange as described above with the following		above with the following parameters:
	parameters:
	HASH SHA-1, as defined in [RFC3174]		HASH SHA-1, as defined in [RFC3174]
	HLEN 160		HLEN 160
	MINKLEN 1024		MINKLEN 1024
	6. rsa2048-sha256-draft-04@putty.projects.tartarus.org		6. rsa2048-sha256
	The "rsa2048-sha256-draft-04@putty.projects.tartarus.org" method		The "rsa2048-sha256" method specifies RSA key exchange as described
	specifies RSA key exchange as described above with the following		above with the following parameters:
	parameters:
	HASH SHA-256, as defined in [FIPS-180-2]		HASH SHA-256, as defined in [FIPS-180-2]
	HLEN 256		HLEN 256
	MINKLEN 2048		MINKLEN 2048
	7. Message numbers		7. Message numbers
	The following message numbers are defined:		The following message numbers are defined:
	SSH_MSG_KEXRSA_PUBKEY 30		SSH_MSG_KEXRSA_PUBKEY 30
	skipping to change at page 6, line 10 ¶		skipping to change at page 6, line 10 ¶
	server (usually in the form of the exchange hash, H). If an		server (usually in the form of the exchange hash, H). If an
	extension to SSH were to use K directly and to assume that it had		extension to SSH were to use K directly and to assume that it had
	been generated by Diffie-Hellman key exchange, this could produce a		been generated by Diffie-Hellman key exchange, this could produce a
	security weakness. Protocol extensions using K directly should be		security weakness. Protocol extensions using K directly should be
	viewed with extreme suspicion.		viewed with extreme suspicion.
	This key-exchange method is designed to be resistant to collision		This key-exchange method is designed to be resistant to collision
	attacks on the exchange hash, by ensuring that neither side is able		attacks on the exchange hash, by ensuring that neither side is able
	to freely choose its input to the hash after seeing all of the other		to freely choose its input to the hash after seeing all of the other
	side's input. The server's last input is in SSH_MSG_KEXRSA_PUBKEY,		side's input. The server's last input is in SSH_MSG_KEXRSA_PUBKEY,
	before it has seen the client's choice of K. The clients last input		before it has seen the client's choice of K. The client's last input
	is K and its RSA encryption, and the one-way nature of RSA encryption		is K and its RSA encryption, and the one-way nature of RSA encryption
	should ensure that the client cannot choose K so as to cause a		should ensure that the client cannot choose K so as to cause a
	collision.		collision.
	9. IANA Considerations		9. IANA Considerations
	This document has no actions for IANA.		IANA should assign the names "rsa1024-sha1" and "rsa2048-sha256" as
			Key Exchange Method Names in accordance with [I-D.ietf-secsh-
			assignednumbers].
	10. Acknowledgments		10. Acknowledgments
	The author acknowledges the assistance of Simon Tatham with the		The author acknowledges the assistance of Simon Tatham with the
	design of this key exchange method.		design of this key exchange method.
	The text of this document is derived in part from [I-D.ietf-secsh-		The text of this document is derived in part from [I-D.ietf-secsh-
	transport].		transport].
	11. References		11. References
	11.1 Normative References		11.1. Normative References
	[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.
	[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1		[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
	(SHA1)", RFC 3174, September 2001.		(SHA1)", RFC 3174, September 2001.
	[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.
	skipping to change at page 6, line 51 ¶		skipping to change at page 7, line 8 ¶
	[I-D.ietf-secsh-architecture]		[I-D.ietf-secsh-architecture]
	Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",		Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
	draft-ietf-secsh-architecture-22 (work in progress),		draft-ietf-secsh-architecture-22 (work in progress),
	March 2005.		March 2005.
	[I-D.ietf-secsh-transport]		[I-D.ietf-secsh-transport]
	Lonvick, C., "SSH Transport Layer Protocol",		Lonvick, C., "SSH Transport Layer Protocol",
	draft-ietf-secsh-transport-24 (work in progress),		draft-ietf-secsh-transport-24 (work in progress),
	March 2005.		March 2005.
			[I-D.ietf-secsh-assignednumbers]
			Lehtinen, S. and C. Lonvick, "SSH Protocol Assigned
			Numbers", draft-ietf-secsh-assignednumbers-12 (work in
			progress), March 2005.
	[FIPS-180-2]		[FIPS-180-2]
	National Institute of Standards and Technology (NIST),		National Institute of Standards and Technology (NIST),
	"Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002.		"Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002.
	11.2 Informative References		11.2. Informative References
	[SSH1] Ylonen, T., "SSH -- Secure Login Connections over the		[SSH1] Ylonen, T., "SSH -- Secure Login Connections over the
	Internet", 6th USENIX Security Symposium, pp. 37-42,		Internet", 6th USENIX Security Symposium, pp. 37-42,
	July 1996.		July 1996.
	[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For		[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
	Public Keys Used For Exchanging Symmetric Keys", BCP 86,		Public Keys Used For Exchanging Symmetric Keys", BCP 86,
	RFC 3766, April 2004.		RFC 3766, April 2004.
	Author's Address
	Ben Harris
	37 Milton Road
	CAMBRIDGE CB4 1XA
	GB
	Email: bjh21@bjh21.me.uk
	Appendix A. On the size of K		Appendix A. On the size of K
	The requirements on the size of K are intended to ensure that it is		The requirements on the size of K are intended to ensure that it is
	always possible to encrypt it under K_T. The mpint encoding of K		always possible to encrypt it under K_T. The mpint encoding of K
	requires a leading zero bit, padding to a whole number of bytes, and		requires a leading zero bit, padding to a whole number of bytes, and
	a four-byte length field, giving a maximum length in bytes,		a four-byte length field, giving a maximum length in bytes,
	B = (KLEN-2HLEN-49+1+7)/8 + 4 = (KLEN-2HLEN-9)/8 (where "/"		B = (KLEN-2HLEN-49+1+7)/8 + 4 = (KLEN-2HLEN-9)/8 (where "/"
	represents integer division rounding down).		represents integer division rounding down).
	The maximum length of message that can be encrypted using RSAEP-OAEP		The maximum length of message that can be encrypted using RSAEP-OAEP
	is defined by [RFC3447] in terms of the key length in bytes, which is		is defined by [RFC3447] in terms of the key length in bytes, which is
	(KLEN+7)/8. The maximum length is thus L = (KLEN+7-2HLEN-16)/8 =		(KLEN+7)/8. The maximum length is thus L = (KLEN+7-2HLEN-16)/8 =
	(KLEN-2HLEN-9)/8. Thus, the encoded version of K is always small		(KLEN-2HLEN-9)/8. Thus, the encoded version of K is always small
	enough to be encrypted under K_T.		enough to be encrypted under K_T.
	Trademark Notice		Trademark Notice
	"SSH" is a registered trademark in the United States.		"SSH" is a registered trademark in the United States.
			Author's Address
			Ben Harris
			37 Milton Road
			CAMBRIDGE CB4 1XA
			GB
			Email: bjh21@bjh21.me.uk
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
End of changes. 14 change blocks.
	25 lines changed or deleted		30 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/