RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
RFC 4432

Network Working Group                                          B. Harris
Request for Comments: 4432                                    March 2006
Category: Standards Track

              RSA Key Exchange for the Secure Shell (SSH)
                        Transport Layer Protocol

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This memo describes a key-exchange method for the Secure Shell (SSH)
   protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption.
   It uses much less client CPU time than the Diffie-Hellman algorithm
   specified as part of the core protocol, and hence is particularly
   suitable for slow client systems.

1.  Introduction

   Secure Shell (SSH) [RFC4251] is a secure remote-login protocol.  The
   core protocol uses Diffie-Hellman key exchange.  On slow CPUs, this
   key exchange can take tens of seconds to complete, which can be
   irritating for the user.  A previous version of the SSH protocol,
   described in [SSH1], uses a key-exchange method based on
   Rivest-Shamir-Adleman (RSA) public-key encryption, which consumes an
   order of magnitude less CPU time on the client, and hence is
   particularly suitable for slow client systems such as mobile devices.
   This memo describes a key-exchange mechanism for the version of SSH
   described in [RFC4251] that is similar to that used by the older
   version, and about as fast, while retaining the security advantages
   of the newer protocol.

Harris                      Standards Track                     [Page 1]
RFC 4432                  SSH RSA Key Exchange                March 2006

2.  Conventions Used in This Document

   The key words "MUST" and "SHOULD" in this document are to be
   interpreted as described in [RFC2119].

   The data types "byte", "string", and "mpint" are defined in Section 5
   of [RFC4251].

   Other terminology and symbols have the same meaning as in [RFC4253].

3.  Overview

   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
   the private key.  This may be a transient key generated solely for
   this SSH connection, or it may be re-used for several connections.
   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
   client and server each hash K, K_T, and the various key-exchange
   parameters to generate the exchange hash, H, which is 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 client
   then verifies the host key as described in Section 8 of [RFC4253].

   This method provides explicit server identification as defined in
   Section 7 of [RFC4253].  It requires a signature-capable host key.

4.  Details

   The RSA key-exchange method has the following parameters:

       HASH     hash algorithm for calculating exchange hash, etc.
       HLEN     output length of HASH 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.

   First, the server sends:

       byte      SSH_MSG_KEXRSA_PUBKEY
       string    server public host key and certificates (K_S)
       string    K_T, transient RSA public key

Harris                      Standards Track                     [Page 2]
RFC 4432                  SSH RSA Key Exchange                March 2006

   The key K_T is encoded according to the "ssh-rsa" scheme described in
   Section 6.6 of [RFC4253].  Note that unlike an "ssh-rsa" host key,
   K_T is used only for encryption, and not for signature.  The modulus
   of K_T MUST be at least MINKLEN bits long.

   The client generates a random integer, K, in the range
   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:

       mpint     K, the shared secret

   The encryption is performed according to the RSAES-OAEP scheme of
   [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