< draft-harris-ssh-rsa-kex-00.txt   draft-harris-ssh-rsa-kex-01.txt >
Network Working Group B. Harris Network Working Group B. Harris
Internet-Draft January 6, 2005 Internet-Draft March 17, 2005
Expires: July 7, 2005 Expires: September 18, 2005
RSA key exchange for the SSH Transport Layer Protocol RSA key exchange for the SSH Transport Layer Protocol
draft-harris-ssh-rsa-kex-00.txt draft-harris-ssh-rsa-kex-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. 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-Drafts. Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 July 7, 2005. This Internet-Draft will expire on September 18, 2005.
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 an RSA-based key-exchange method for the SSH
protocol. It uses much less client CPU time than the Diffie-Hellman protocol. It uses much less client CPU time than the Diffie-Hellman
algorithm specified as part of the core protocol, and hence is algorithm specified as part of the core protocol, and hence is
particularly suitable for slow client systems. particularly suitable for slow client systems.
1. Introduction 1. Introduction
Secure Shell (SSH) [SSH-ARCH] is a secure remote-login protocol. The Secure Shell (SSH) [I-D.ietf-secsh-architecture] is a secure
core protocol uses Diffie-Hellman key exchange. On slow CPUs, this remote-login protocol. The core protocol uses Diffie-Hellman key
key exchange can take tens of seconds to complete, which can be exchange. On slow CPUs, this key exchange can take tens of seconds
irritating for the user. A previous version of the SSH protocol, to complete, which can be irritating for the user. A previous
described in [SSH1] uses an RSA-based key exchange method, which version of the SSH protocol, described in [SSH1] uses an RSA-based
consumes an order of magnitude less CPU time on the client, and hence key exchange method, which consumes an order of magnitude less CPU
is particularly suitable for slow client systems such as mobile time on the client, and hence is particularly suitable for slow
devices. This memo describes a key-exchange mechanism for the client systems such as mobile devices. This memo describes a
version of SSH described in [SSH-ARCH] which is similar to that used key-exchange mechanism for the version of SSH described in
by the older version, and about as fast, while retaining the security [I-D.ietf-secsh-architecture] which is similar to that used by the
older version, and about as fast, while retaining the security
advantages of the newer protocol. 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 [SSH-TRANS]. client then verifies the host key as described in
[I-D.ietf-secsh-transport].
This method provides explicit server identification as defined in This method provides explicit server identification as defined in
section 7 of [SSH-TRANS]. It requires a signature-capable host key. section 7 of [I-D.ietf-secsh-transport]. It requires a
signature-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 [SSH-TRANS]. Note that unlike an "ssh-rsa" host key, section 6.6 of [I-D.ietf-secsh-transport]. Note that unlike an
K_T is only used for encryption, and not for signature. The modulus "ssh-rsa" host key, K_T is only used for encryption, and not for
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
skipping to change at page 4, line 8 skipping to change at page 4, line 26
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. rsa-sha1-draft-00@putty.projects.tartarus.org 5. rsa1024-sha1-draft-01@putty.projects.tartarus.org
The "rsa-sha1-draft-00@putty.projects.tartarus.org" method specifies The "rsa1024-sha1-draft-01@putty.projects.tartarus.org" method
RSA key exchange as described above with the following parameters: specifies RSA key exchange as described above with the following
parameters:
HASH SHA-1, as defined in [FIPS-180-2] HASH SHA-1, as defined in [RFC3174]
HLEN 160 HLEN 160
MINKLEN 1024 MINKLEN 1024
6. Message numbers 6. rsa2048-sha256-draft-01@putty.projects.tartarus.org
The "rsa1024-sha256-draft-01@putty.projects.tartarus.org" method
specifies RSA key exchange as described above with the following
parameters:
HASH SHA-256, as defined in [FIPS-180-2]
HLEN 256
MINKLEN 2048
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 Note that Numbers 30-49 are used for kex packets. Different kex
methods may reuse message numbers in this range. methods may reuse message numbers in this range.
7. Security Considerations 8. Security Considerations
The security considerations in [SSH-ARCH] 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.
[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
RSAES-OAEP is in part dependent on the hash function it uses.
[RFC3447] suggests using a hash with an output length of twice the
security level required, so SHA-1 is appropriate for applications
requiring up to 80 bits of security, and SHA-256 for those requiring
up to 128 bits.
For recommendations on this, see [RFC3766]. Unlike the Diffie-Hellman key exchange method defined by
[I-D.ietf-secsh-transport], this method allows the client to fully
Unlike the Diffie-Hellman key exchange method defined by [SSH-TRANS], determine the shared secret, K. This is believed not to be
this method allows the client to fully determine the shared secret, significant, since K is only ever used when hashed with data provided
K. This is believed not to be significant, since K is only ever used in part by the server (usually in the form of the exchange hash, H).
when hashed with data provided in part by the server (usually in the If an extension to SSH were to use K directly and to assume that it
form of the exchange hash, H). If an extension to SSH were to use K had been generated by Diffie-Hellman key exchange, this could produce
directly and to assume that it had been generated by Diffie-Hellman a security weakness. Protocol extensions using K directly should be
key exchange, this could produce a security weakness. Protocol viewed with extreme suspicion.
extensions using K directly should be viewed with extreme suspicion.
8. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. 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 [SSH-TRANS]. The text of this document is derived in part from
[I-D.ietf-secsh-transport].
10. References 11. References
10.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
(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.
[SSH-ARCH] [I-D.ietf-secsh-architecture]
Lonvick, C., Ed., "SSH Protocol Architecture", I-D Lonvick, C., "SSH Protocol Architecture",
draft-ietf-secsh-architecture-20.txt, December 2004. Internet-Draft draft-ietf-secsh-architecture-22, March
2005.
[SSH-TRANS] [I-D.ietf-secsh-transport]
Lonvick, C., Ed., "SSH Transport Layer Protocol", I-D Lonvick, C., "SSH Transport Layer Protocol",
draft-ietf-secsh-transport-22.txt, December 2004. Internet-Draft draft-ietf-secsh-transport-24, 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.
10.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, p. 37-42, July
1996. 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 in 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.
 End of changes. 27 change blocks. 
51 lines changed or deleted 75 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/