< draft-harris-ssh-rsa-kex-01.txt   draft-harris-ssh-rsa-kex-02.txt >
Network Working Group B. Harris Network Working Group B. Harris
Internet-Draft March 17, 2005 Internet-Draft July 4, 2005
Expires: September 18, 2005 Expires: January 5, 2006
RSA key exchange for the SSH Transport Layer Protocol Rivest-Shamir-Adleman (RSA) key exchange for the Secure Shell (SSH)
draft-harris-ssh-rsa-kex-01.txt Transport Layer Protocol
draft-harris-ssh-rsa-kex-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
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."
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 September 18, 2005. This Internet-Draft will expire on January 5, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This memo describes an RSA-based key-exchange method for the SSH This memo describes a key-exchange method for the Secure Shell (SSH)
protocol. It uses much less client CPU time than the Diffie-Hellman protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption.
algorithm specified as part of the core protocol, and hence is It uses much less client CPU time than the Diffie-Hellman algorithm
particularly suitable for slow client systems. specified as part of the core protocol, and hence is particularly
suitable for slow client systems.
1. Introduction 1. Introduction
Secure Shell (SSH) [I-D.ietf-secsh-architecture] is a secure Secure Shell (SSH) [I-D.ietf-secsh-architecture] is a secure remote-
remote-login protocol. The core protocol uses Diffie-Hellman key login protocol. The core protocol uses Diffie-Hellman key exchange.
exchange. On slow CPUs, this key exchange can take tens of seconds On slow CPUs, this key exchange can take tens of seconds to complete,
to complete, which can be irritating for the user. A previous which can be irritating for the user. A previous version of the SSH
version of the SSH protocol, described in [SSH1] uses an RSA-based protocol, described in [SSH1] uses a key-exchange method based on
key exchange method, which consumes an order of magnitude less CPU Rivest-Shamir-Adleman (RSA) public-key encryption, which consumes an
time on the client, and hence is particularly suitable for slow order of magnitude less CPU time on the client, and hence is
client systems such as mobile devices. This memo describes a particularly suitable for slow client systems such as mobile devices.
key-exchange mechanism for the version of SSH described in This memo describes a key-exchange mechanism for the version of SSH
[I-D.ietf-secsh-architecture] which is similar to that used by the described in [I-D.ietf-secsh-architecture] which is similar to that
older version, and about as fast, while retaining the security used by the older version, and about as fast, while retaining the
advantages of the newer protocol. security advantages of the newer protocol.
2. Conventions Used in this Document 2. Conventions Used in this Document
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].
3. Overview 3. Overview
The RSA key-exchange method consists of three messages. First, the The RSA key-exchange method consists of three messages. First, the
server sends to the client an RSA public key, K_T, to which the server sends to the client an RSA public key, K_T, to which the
server holds the private key. This may be a transient key generated server holds the private key. This may be a transient key generated
solely for this SSH connection, or it may be re-used for several solely for this SSH connection, or it may be re-used for several
connections. The client generates a string of random bytes, K, connections. The client generates a string of random bytes, K,
encrypts it using K_T, and sends the result back to the server, which encrypts it using K_T, and sends the result back to the server, which
decrypts it. The client and server each hash K, K_T, and the various decrypts it. The client and server each hash K, K_T, and the various
key-exchange parameters to generate the exchange hash, H, which is key-exchange parameters to generate the exchange hash, H, which is
used to generate the encryption keys for the session, and the server used to generate the encryption keys for the session, and the server
signs H with its host key and sends the signature to the client. The signs H with its host key and sends the signature to the client. The
client then verifies the host key as described in client then verifies the host key as described in [I-D.ietf-secsh-
[I-D.ietf-secsh-transport]. transport].
This method provides explicit server identification as defined in This method provides explicit server identification as defined in
section 7 of [I-D.ietf-secsh-transport]. It requires a section 7 of [I-D.ietf-secsh-transport]. It requires a signature-
signature-capable host key. capable host key.
4. Details 4. Details
The RSA key exchange method has the following parameters, which are The RSA key exchange method has the following parameters, which are
defined by the method name: defined by the method name:
HASH hash algorithm for calculating exchange hash etc. HASH hash algorithm for calculating exchange hash etc.
HLEN output length of HASH in bits HLEN output length of HASH in bits
MINKLEN minimum transient RSA modulus length in bits MINKLEN minimum transient RSA modulus length in bits
The method uses the following messages. The method uses the following messages.
First, the server sends: First, the server sends:
byte SSH_MSG_KEXRSA_PUBKEY byte SSH_MSG_KEXRSA_PUBKEY
string K_T, transient RSA public key string K_T, transient RSA public key
The key K_T is encoded according to the "ssh-rsa" scheme described in The key K_T is encoded according to the "ssh-rsa" scheme described in
section 6.6 of [I-D.ietf-secsh-transport]. Note that unlike an section 6.6 of [I-D.ietf-secsh-transport]. Note that unlike an "ssh-
"ssh-rsa" host key, K_T is only used for encryption, and not for rsa" host key, K_T is only used for encryption, and not for
signature. The modulus of K_T MUST be at least MINKLEN bits long. signature. The modulus of K_T MUST be at least MINKLEN bits long.
The client generates a random integer, K, in the range The client generates a random integer, K, in the range
0 <= K < 2^(KLEN-2HLEN-49), where KLEN is the length of the modulus 0 <= K < 2^(KLEN-2HLEN-49), where KLEN is the length of the modulus
of K_T, in bits. The client then uses K_T to encrypt: of K_T, in bits. The client then uses K_T to encrypt:
mpint K, the shared secret mpint K, the shared secret
The encryption is performed according to the RSAES-OAEP scheme of The encryption is performed according to the RSAES-OAEP scheme of
[RFC3447], with a mask generation function of MGF1-with-HASH, a hash [RFC3447], with a mask generation function of MGF1-with-HASH, a hash
of HASH, and an empty label. See Appendix A for a proof that the of HASH, and an empty label. See Appendix A for a proof that the
encoding of K is always short enough to be thus encrypted. Having encoding of K is always short enough to be thus encrypted. Having
performed the encryption, the client sends: performed the encryption, the client sends:
byte SSH_MSG_KEXRSA_SECRET byte SSH_MSG_KEXRSA_SECRET
string RSAES-OAEP-ENCRYPT(K_T, K) string RSAES-OAEP-ENCRYPT(K_T, K)
The server decrypts K. If a decryption error occurs, the server Note that the last stage of RSAES-OAEP-ENCRYPT is to encode an
integer as an octet-string using the I2OSP primitive of [RFC3447].
This, combined with encoding the result as an SSH "string", gives a
result which is similar, but not identical, to the SSH "mpint"
encoding applied to that integer. This is the same encoding as is
used by "ssh-rsa" signatures in [I-D.ietf-secsh-transport].
The server decrypts K. If a decryption error occurs, the server
SHOULD send SSH_MESSAGE_DISCONNECT with a reason code of SHOULD send SSH_MESSAGE_DISCONNECT with a reason code of
SSH_DISCONNECT_KEY_EXCHANGE_FAILED and MUST disconnect. Otherwise, SSH_DISCONNECT_KEY_EXCHANGE_FAILED and MUST disconnect. Otherwise,
the server responds with: the server responds with:
byte SSH_MSG_KEXRSA_DONE byte SSH_MSG_KEXRSA_DONE
string server public host key and certificates (K_S) string server public host key and certificates (K_S)
string signature of H string signature of H
The hash H is computed as the HASH hash of the concatenation of the The hash H is computed as the HASH hash of the concatenation of the
following: following:
string V_C, the client's version string (CR and NL excluded) string V_C, the client's version string (CR and NL excluded)
string V_S, the server's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded)
string I_C, the payload of the client's SSH_MSG_KEXINIT string I_C, the payload of the client's SSH_MSG_KEXINIT
string I_S, the payload of the server's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT
string K_S, the host key string K_S, the host key
string K_T, the transient RSA key string K_T, the transient RSA key
string RSAES_OAEP_ENCRYPT(K_T, K), the encrypted secret
mpint K, the shared secret mpint K, the shared secret
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 that padding - for example, "ssh-dss" specifies SHA-1 hashing. In that
case, the data is first hashed with HASH to compute H, and H is then case, the data is first hashed with HASH to compute H, and H is then
hashed with SHA-1 as part of the signing operation. hashed with SHA-1 as part of the signing operation.
5. rsa1024-sha1-draft-01@putty.projects.tartarus.org 5. rsa1024-sha1-draft-02@putty.projects.tartarus.org
The "rsa1024-sha1-draft-01@putty.projects.tartarus.org" method The "rsa1024-sha1-draft-02@putty.projects.tartarus.org" method
specifies RSA key exchange as described above with the following specifies RSA key exchange as described 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-01@putty.projects.tartarus.org 6. rsa2048-sha512-draft-02@putty.projects.tartarus.org
The "rsa1024-sha256-draft-01@putty.projects.tartarus.org" method The "rsa2048-sha512-draft-02@putty.projects.tartarus.org" method
specifies RSA key exchange as described above with the following specifies RSA key exchange as described above with the following
parameters: parameters:
HASH SHA-256, as defined in [FIPS-180-2] HASH SHA-512, as defined in [FIPS-180-2]
HLEN 256 HLEN 512
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
SSH_MSG_KEXRSA_SECRET 31 SSH_MSG_KEXRSA_SECRET 31
SSH_MSG_KEXRSA_DONE 32 SSH_MSG_KEXRSA_DONE 32
Note that Numbers 30-49 are used for kex packets. Different kex
methods may reuse message numbers in this range.
8. Security Considerations 8. Security Considerations
The security considerations in [I-D.ietf-secsh-architecture] apply. The security considerations in [I-D.ietf-secsh-architecture] apply.
If the RSA private key generated by the server is revealed then the If the RSA private key generated by the server is revealed then the
session key is revealed. The server should thus arrange to erase session key is revealed. The server should thus arrange to erase
this from memory as soon as it is no longer required. If the same this from memory as soon as it is no longer required. If the same
RSA key is used for multiple SSH connections, an attacker who can RSA key is used for multiple SSH connections, an attacker who can
find the private key (either by factorising the public key or by find the private key (either by factorising the public key or by
other means) will gain access to all of the sessions which used that other means) will gain access to all of the sessions which used that
key. key. As a result, servers SHOULD use each RSA key for as few key
exchanges as possible.
[RFC3447] recommends that RSA keys used with RSAES-OAEP not be used [RFC3447] recommends that RSA keys used with RSAES-OAEP not be used
with other schemes, or with RSAES-OAEP using a different hash with other schemes, or with RSAES-OAEP using a different hash
function. In particular, this means that K_T should not be used as a function. In particular, this means that K_T should not be used as a
host key, or as a server key in earlier versions of the SSH protocol. host key, or as a server key in earlier versions of the SSH protocol.
The random data, K, generated by the client, is the only secret The random data, K, generated by the client, is the only secret
shared by client and server, so its entropy directly determines the shared by client and server, so its entropy directly determines the
security of the session against eavesdropping. security of the session against eavesdropping.
The size of transient key used should be sufficient to protect the The size of transient key used should be sufficient to protect the
encryption and integrity keys generated by the key exchange method. encryption and integrity keys generated by the key exchange method.
For recommendations on this, see [RFC3766]. The strength of For recommendations on this, see [RFC3766]. The strength of RSAES-
RSAES-OAEP is in part dependent on the hash function it uses. OAEP is in part dependent on the hash function it uses. [RFC3447]
[RFC3447] suggests using a hash with an output length of twice the suggests using a hash with an output length of twice the security
security level required, so SHA-1 is appropriate for applications level required, so SHA-1 is appropriate for applications requiring up
requiring up to 80 bits of security, and SHA-256 for those requiring to 80 bits of security, and SHA-512 for those requiring up to 256
up to 128 bits. bits.
Unlike the Diffie-Hellman key exchange method defined by Unlike the Diffie-Hellman key exchange method defined by [I-D.ietf-
[I-D.ietf-secsh-transport], this method allows the client to fully secsh-transport], this method allows the client to fully determine
determine the shared secret, K. This is believed not to be the shared secret, K. This is believed not to be significant, since K
significant, since K is only ever used when hashed with data provided is only ever used when hashed with data provided in part by the
in part by the server (usually in the form of the exchange hash, H). server (usually in the form of the exchange hash, H). If an
If an extension to SSH were to use K directly and to assume that it extension to SSH were to use K directly and to assume that it had
had been generated by Diffie-Hellman key exchange, this could produce been generated by Diffie-Hellman key exchange, this could produce a
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.
9. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
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 The text of this document is derived in part from [I-D.ietf-secsh-
[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.
[I-D.ietf-secsh-architecture] [I-D.ietf-secsh-architecture]
Lonvick, C., "SSH Protocol Architecture", Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
Internet-Draft draft-ietf-secsh-architecture-22, March draft-ietf-secsh-architecture-22 (work in progress),
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",
Internet-Draft draft-ietf-secsh-transport-24, March 2005. draft-ietf-secsh-transport-24 (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, p. 37-42, July Internet", 6th USENIX Security Symposium, pp. 37-42,
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 Author's Address
Ben Harris Ben Harris
37 Milton Road 37 Milton Road
CAMBRIDGE CB4 1XA CAMBRIDGE CB4 1XA
GB GB
Email: bjh21@bjh21.me.uk 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's The requirements on the size of K are intended to ensure that it's
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
"SSH" is a registered trademark in the United States.
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. 27 change blocks. 
69 lines changed or deleted 80 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/