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)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4432 (Proposed Standard) | |
| 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
Show full document text