< draft-harris-ssh-rsa-kex-05.txt   draft-harris-ssh-rsa-kex-06.txt >
Network Working Group B. Harris Network Working Group B. Harris
Internet-Draft August 25, 2005 Internet-Draft December 19, 2005
Expires: February 26, 2006 Expires: June 22, 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-05 draft-harris-ssh-rsa-kex-06
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 26, 2006. This Internet-Draft will expire on June 22, 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 25 skipping to change at page 2, line 25
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" and "SHOULD" in this document are to be The key words "MUST" and "SHOULD" in this document are to be
interpreted as described in [RFC2119]. interpreted as described in [RFC2119].
The data types "byte", "string", and "mpint" are defined in section 5
of [I-D.ietf-secsh-architecture].
Other terminology and symbols have the same meaning as in [I-D.ietf-
secsh-transport].
3. Overview 3. Overview
The RSA key-exchange method consists of three messages. The server The RSA key-exchange method consists of three messages. The server
sends to the client an RSA public key, K_T, to which the server holds 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 solely for the private key. This may be a transient key generated solely for
this SSH connection, or it may be re-used for several connections. this SSH connection, or it may be re-used for several connections.
The client generates a string of random bytes, K, encrypts it using The client generates a string of random bytes, K, encrypts it using
K_T, and sends the result back to the server, which decrypts it. The 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 key-exchange client and server each hash K, K_T, and the various key-exchange
parameters to generate the exchange hash, H, which is used to parameters to generate the exchange hash, H, which is used to
generate the encryption keys for the session, and the server signs H generate the encryption keys for the session, and the server signs H
with its host key and sends the signature to the client. The client with its host key and sends the signature to the client. The client
then verifies the host key as described in [I-D.ietf-secsh- then verifies the host key as described in section 8 of [I-D.ietf-
transport]. secsh-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
defined by the method name: The RSA key exchange method has the following parameters:
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
Their values are defined in Section 5 and Section 6 for the two
methods defined by this document.
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 server public host key and certificates (K_S) string server public host key and certificates (K_S)
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 "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-2*HLEN-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:
skipping to change at page 4, line 9 skipping to change at page 4, line 16
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 signature of H with host key string signature of H with host key
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 identification string
string V_S, the server's version string (CR and NL excluded) (CR and LF excluded)
string V_S, the server's identification string
(CR and LF 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 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.
skipping to change at page 5, line 31 skipping to change at page 5, line 40
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.
K, the random integer generated by the client, is the only secret Like all key-exchange mechanisms, this one depends for its security
shared by client and server. Thus its entropy directly determines on the randomness of the secrets generated by the client (the random
the security of the session against eavesdropping. number K) and the server (the transient RSA private key). In
particular, it is essential that the client use a high-quality
cryptographic pseudo-random number generator to generate K. Using a
bad random number generator will allow an attacker to break all the
encryption and integrity protection of the Secure Shell transport
layer. See [RFC4086] for recommendations on random-number generation
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-256 for those requiring up to 128
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
skipping to change at page 7, line 27 skipping to change at page 7, line 45
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.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
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-2*HLEN-49+1+7)/8 + 4 = (KLEN-2*HLEN-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-2*HLEN-16)/8 =
(KLEN-2HLEN-9)/8. Thus, the encoded version of K is always small (KLEN-2*HLEN-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 Author's Address
Ben Harris Ben Harris
37 Milton Road 2a Eachard Road
CAMBRIDGE CB4 1XA CAMBRIDGE CB4 1XA
GB GB
Email: bjh21@bjh21.me.uk Email: a7250@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
 End of changes. 17 change blocks. 
20 lines changed or deleted 40 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/