< draft-harris-ssh-rsa-kex-03.txt   draft-harris-ssh-rsa-kex-04.txt >
Network Working Group B. Harris Network Working Group B. Harris
Internet-Draft July 13, 2005 Internet-Draft August 15, 2005
Expires: January 14, 2006 Expires: February 16, 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-03 draft-harris-ssh-rsa-kex-04
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 January 14, 2006. This Internet-Draft will expire on February 16, 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 2, line 22 skipping to change at page 2, line 22
Rivest-Shamir-Adleman (RSA) public-key encryption, which consumes an Rivest-Shamir-Adleman (RSA) public-key encryption, which consumes an
order of magnitude less CPU time on the client, and hence is order of magnitude less CPU time on the client, and hence is
particularly suitable for slow client systems such as mobile devices. particularly suitable for slow client systems such as mobile devices.
This memo describes a key-exchange mechanism for the version of SSH This memo describes a key-exchange mechanism for the version of SSH
described in [I-D.ietf-secsh-architecture] which is similar to that described in [I-D.ietf-secsh-architecture] which is similar to that
used by the older version, and about as fast, while retaining the used by the older version, and about as fast, while retaining the
security 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" and "SHOULD" in this document are to be
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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. The server
server sends to the client an RSA public key, K_T, to which the sends to the client an RSA public key, K_T, to which the server holds
server holds the private key. This may be a transient key generated the private key. This may be a transient key generated solely for
solely for this SSH connection, or it may be re-used for several this SSH connection, or it may be re-used for several connections.
connections. The client generates a string of random bytes, K, The client generates a string of random bytes, K, encrypts it using
encrypts it using K_T, and sends the result back to the server, which K_T, and sends the result back to the server, which decrypts it. The
decrypts it. The client and server each hash K, K_T, and the various client and server each hash K, K_T, and the various key-exchange
key-exchange parameters to generate the exchange hash, H, which is parameters to generate the exchange hash, H, which is used to
used to generate the encryption keys for the session, and the server generate the encryption keys for the session, and the server signs H
signs H with its host key and sends the signature to the client. The with its host key and sends the signature to the client. The client
client then verifies the host key as described in [I-D.ietf-secsh- then verifies the host key as described in [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 signature- section 7 of [I-D.ietf-secsh-transport]. It requires a 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 server public host key and certificates (K_S) string server public host key and certificates (K_S)
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 "ssh- section 6.6 of [I-D.ietf-secsh-transport]. Note that unlike an "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:
skipping to change at page 4, line 23 skipping to change at page 4, line 23
string K_T, the transient RSA key string K_T, the transient RSA key
string RSAES_OAEP_ENCRYPT(K_T, K), the encrypted secret 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 such
case, 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 with SHA-1 as part of the signing operation. hashed again as part of the signing operation.
5. rsa1024-sha1-draft-03@putty.projects.tartarus.org 5. rsa1024-sha1-draft-04@putty.projects.tartarus.org
The "rsa1024-sha1-draft-03@putty.projects.tartarus.org" method The "rsa1024-sha1-draft-04@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-03@putty.projects.tartarus.org 6. rsa2048-sha256-draft-04@putty.projects.tartarus.org
The "rsa2048-sha256-draft-03@putty.projects.tartarus.org" method The "rsa2048-sha256-draft-04@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-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:
skipping to change at page 5, line 31 skipping to change at page 5, line 31
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. As a result, servers SHOULD use each RSA key for as few key key. As a result, servers SHOULD use each RSA key for as few key
exchanges as possible. 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 K, the random integer generated by the client, is the only secret
shared by client and server, so its entropy directly determines the shared by client and server. Thus its entropy directly determines
security of the session against eavesdropping. the 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 RSAES- For recommendations on this, see [RFC3766]. The strength of RSAES-
OAEP is in part dependent on the hash function it uses. [RFC3447] OAEP is in part dependent on the hash function it uses. [RFC3447]
suggests using a hash with an output length of twice the security suggests using a hash with an output length of twice the security
level required, so SHA-1 is appropriate for applications requiring up level required, so SHA-1 is appropriate for applications requiring up
to 80 bits of security, and SHA-512 for those requiring up to 256 to 80 bits of security, and SHA-512 for those requiring up to 256
bits. bits.
Unlike the Diffie-Hellman key exchange method defined by [I-D.ietf- Unlike the Diffie-Hellman key exchange method defined by [I-D.ietf-
secsh-transport], this method allows the client to fully determine secsh-transport], this method allows the client to fully determine
the shared secret, K. This is believed not to be significant, since K the shared secret, K. This is believed not to be significant, since K
is only ever used when hashed with data provided in part by the is only ever used when hashed with data provided in part by the
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
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
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
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
collision.
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 [I-D.ietf-secsh- The text of this document is derived in part from [I-D.ietf-secsh-
skipping to change at page 7, line 20 skipping to change at page 7, line 28
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 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
 End of changes. 15 change blocks. 
30 lines changed or deleted 38 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/