RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
RFC 4432
Document | Type |
RFC - Proposed Standard
(March 2006; No errata)
Was draft-harris-ssh-rsa-kex (individual in sec area)
|
|
---|---|---|---|
Author | Ben Harris | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4432 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Sam Hartman | ||
Send notices to | sommerfeld@sun.com |
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 encoding of K is always short enough to be thus encrypted. Having performed the encryption, the client sends: byte SSH_MSG_KEXRSA_SECRET string RSAES-OAEP-ENCRYPT(K_T, K) Note that the last stage of RSAES-OAEP-ENCRYPT is to encode an integer as an octet string using the I2OSP primitive of [RFC3447].Show full document text