rfc.nroff

OpenSSL Source code for SFTP, SSH, and many others

.\" -*- nroff -*-
.\"
.\" $OpenBSD: RFC.nroff,v 1.2 2000/10/16 09:38:44 djm Exp $
.\"
.pl 10.0i
.po 0
.ll 7.2i
.lt 7.2i
.nr LL 7.2i
.nr LT 7.2i
.ds LF Ylonen
.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet-Draft
.ds RH 15 November 1995
.ds CH SSH (Secure Shell) Remote Login Protocol
.na
.hy 0
.in 0
Network Working Group					       T. Ylonen
Internet-Draft			       Helsinki University of Technology
draft-ylonen-ssh-protocol-00.txt			15 November 1995
Expires: 15 May 1996

.in 3

.ce
The SSH (Secure Shell) Remote Login Protocol

.ti 0
Status of This Memo

This document is an Internet-Draft.   Internet-Drafts  are  working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid  for  a  maximum  of  six
months  and  may  be updated, replaced, or obsoleted by other docu-
ments at any time.  It is inappropriate to use  Internet-Drafts  as
reference  material  or  to  cite them other than as ``work in pro-
gress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

The distribution of  this  memo  is  unlimited.

.ti 0
Introduction

SSH (Secure Shell) is a program to log into another computer over a
network, to execute commands in a remote machine, and to move files
from one machine to another.  It provides strong authentication and
secure communications over insecure networks.  Its features include
the following:
.IP o
Closes several security holes (e.g., IP, routing, and DNS spoofing).
New authentication methods: .rhosts together with RSA [RSA] based host
authentication, and pure RSA authentication.
.IP o
All communications are automatically and transparently encrypted.
Encryption is also used to protect integrity.
.IP o
X11 connection forwarding provides secure X11 sessions.
.IP o
Arbitrary TCP/IP ports can be redirected over the encrypted channel
in both directions.
.IP o
Client RSA-authenticates the server machine in the beginning of every
connection to prevent trojan horses (by routing or DNS spoofing) and
man-in-the-middle attacks, and the server RSA-authenticates the client
machine before accepting .rhosts or /etc/hosts.equiv authentication
(to prevent DNS, routing, or IP spoofing).
.IP o
An authentication agent, running in the user's local workstation or
laptop, can be used to hold the user's RSA authentication keys.
.RT

The goal has been to make the software as easy to use as possible for
ordinary users.  The protocol has been designed to be as secure as
possible while making it possible to create implementations that
are easy to use and install.  The sample implementation has a number
of convenient features that are not described in this document as they
are not relevant for the protocol.


.ti 0
Overview of the Protocol

The software consists of a server program running on a server machine,
and a client program running on a client machine (plus a few auxiliary
programs).  The machines are connected by an insecure IP [RFC0791]
network (that can be monitored, tampered with, and spoofed by hostile
parties).

A connection is always initiated by the client side.  The server
listens on a specific port waiting for connections.  Many clients may
connect to the same server machine.

The client and the server are connected via a TCP/IP [RFC0793] socket
that is used for bidirectional communication.  Other types of
transport can be used but are currently not defined.

When the client connects the server, the server accepts the connection
and responds by sending back its version identification string.  The
client parses the server's identification, and sends its own
identification.  The purpose of the identification strings is to
validate that the connection was to the correct port, declare the
protocol version number used, and to declare the software version used
on each side (for debugging purposes).  The identification strings are
human-readable.  If either side fails to understand or support the
other side's version, it closes the connection.

After the protocol identification phase, both sides switch to a packet
based binary protocol.  The server starts by sending its host key
(every host has an RSA key used to authenticate the host), server key
(an RSA key regenerated every hour), and other information to the
client.  The client then generates a 256 bit session key, encrypts it
using both RSA keys (see below for details), and sends the encrypted
session key and selected cipher type to the server.  Both sides then
turn on encryption using the selected algorithm and key.  The server
sends an encrypted confirmation message to the client.

The client then authenticates itself using any of a number of
authentication methods.  The currently supported authentication
methods are .rhosts or /etc/hosts.equiv authentication (disabled by
default), the same with RSA-based host authentication, RSA
authentication, and password authentication.

After successful authentication, the client makes a number of requests
to prepare for the session.  Typical requests include allocating a
pseudo tty, starting X11 [X11] or TCP/IP port forwarding, starting
authentication agent forwarding, and executing the shell or a command.

When a shell or command is executed, the connection enters interactive
session mode.  In this mode, data is passed in both directions, 
new forwarded connections may be opened, etc.  The interactive session
normally terminates when the server sends the exit status of the
program to the client.


The protocol makes several reservations for future extensibility.
First of all, the initial protocol identification messages include the
protocol version number.  Second, the first packet by both sides
includes a protocol flags field, which can be used to agree on
extensions in a compatible manner.  Third, the authentication and
session preparation phases work so that the client sends requests to
the server, and the server responds with success or failure.  If the
client sends a request that the server does not support, the server
simply returns failure for it.  This permits compatible addition of
new authentication methods and preparation operations.  The
interactive session phase, on the other hand, works asynchronously and
does not permit the use of any extensions (because there is no easy
and reliable way to signal rejection to the other side and problems
would be hard to debug).  Any compatible extensions to this phase must
be agreed upon during any of the earlier phases.

.ti 0
The Binary Packet Protocol

After the protocol identification strings, both sides only send
specially formatted packets.  The packet layout is as follows:
.IP o
Packet length: 32 bit unsigned integer, coded as four 8-bit bytes, msb
first.  Gives the length of the packet, not including the length field
and padding.  The maximum length of a packet (not including the length
field and padding) is 262144 bytes.
.IP o
Padding: 1-8 bytes of random data (or zeroes if not encrypting).  The
amount of padding is (8 - (length % 8)) bytes (where % stands for the
modulo operator).  The rationale for always having some random padding
at the beginning of each packet is to make known plaintext attacks
more difficult.
.IP o
Packet type: 8-bit unsigned byte.  The value 255 is reserved for
future extension.
.IP o
Data: binary data bytes, depending on the packet type.  The number of
data bytes is the "length" field minus 5.
.IP o
Check bytes: 32-bit crc, four 8-bit bytes, msb first.  The crc is the
Cyclic Redundancy Check, with the polynomial 0xedb88320, of the
Padding, Packet type, and Data fields.  The crc is computed before
any encryption.
.RT

The packet, except for the length field, may be encrypted using any of
a number of algorithms.  The length of the encrypted part (Padding +
Type + Data + Check) is always a multiple of 8 bytes.  Typically the
cipher is used in a chained mode, with all packets chained together as
if it was a single data stream (the length field is never included in
the encryption process).  Details of encryption are described below.

When the session starts, encryption is turned off.  Encryption is
enabled after the client has sent the session key.  The encryption
algorithm to use is selected by the client.


.ti 0
Packet Compression

If compression is supported (it is an optional feature, see
SSH_CMSG_REQUEST_COMPRESSION below), the packet type and data fields
of the packet are compressed using the gzip deflate algorithm [GZIP].
If compression is in effect, the packet length field indicates the
length of the compressed data, plus 4 for the crc.  The amount of
padding is computed from the compressed data, so that the amount of
data to be encrypted becomes a multiple of 8 bytes.

When compressing, the packets (type + data portions) in each direction
are compressed as if they formed a continuous data stream, with only the
current compression block flushed between packets.  This corresponds
to the GNU ZLIB library Z_PARTIAL_FLUSH option.  The compression
dictionary is not flushed between packets.  The two directions are
compressed independently of each other.


.ti 0
Packet Encryption

The protocol supports several encryption methods.  During session
initialization, the server sends a bitmask of all encryption methods
that it supports, and the client selects one of these methods.  The
client also generates a 256-bit random session key (32 8-bit bytes) and
sends it to the server.

The encryption methods supported by the current implementation, and
their codes are:
.TS
center;
l r l.
SSH_CIPHER_NONE	0	   No encryption
SSH_CIPHER_IDEA	1	   IDEA in CFB mode
SSH_CIPHER_DES	2	   DES in CBC mode
SSH_CIPHER_3DES	3	   Triple-DES in CBC mode
SSH_CIPHER_TSS	4	   An experimental stream cipher
SSH_CIPHER_RC4	5	   RC4
.TE

All implementations are required to support SSH_CIPHER_DES and
SSH_CIPHER_3DES.  Supporting SSH_CIPHER_IDEA, SSH_CIPHER_RC4, and
SSH_CIPHER_NONE is recommended.  Support for SSH_CIPHER_TSS is
optional (and it is not described in this document).  Other ciphers
may be added at a later time; support for them is optional.

For encryption, the encrypted portion of the packet is considered a
linear byte stream.  The length of the stream is always a multiple of
8.  The encrypted portions of consecutive packets (in the same
direction) are encrypted as if they were a continuous buffer (that is,
any initialization vectors are passed from the previous packet to the
next packet).  Data in each direction is encrypted independently.
.IP SSH_CIPHER_DES
The key is taken from the first 8 bytes of the session key.  The least
significant bit of each byte is ignored.  This results in 56 bits of
key data.  DES [DES] is used in CBC mode.  The iv (initialization vector) is
initialized to all zeroes.
.IP SSH_CIPHER_3DES
The variant of triple-DES used here works as follows: there are three
independent DES-CBC ciphers, with independent initialization vectors.
The data (the whole encrypted data stream) is first encrypted with the
first cipher, then decrypted with the second cipher, and finally
encrypted with the third cipher.  All these operations are performed
in CBC mode.

The key for the first cipher is taken from the first 8 bytes of the
session key; the key for the next cipher from the next 8 bytes, and
the key for the third cipher from the following 8 bytes.  All three
initialization vectors are initialized to zero.

(Note: the variant of 3DES used here differs from some other
descriptions.)
.IP SSH_CIPHER_IDEA
The key is taken from the first 16 bytes of the session key.  IDEA
[IDEA] is used in CFB mode.  The initialization vector is initialized
to all zeroes.
.IP SSH_CIPHER_TSS
All 32 bytes of the session key are used as the key.

There is no reference available for the TSS algorithm; it is currently
only documented in the sample implementation source code.  The
security of this cipher is unknown (but it is quite fast).  The cipher
is basically a stream cipher that uses MD5 as a random number
generator and takes feedback from the data.
.IP SSH_CIPHER_RC4
The first 16 bytes of the session key are used as the key for the
server to client direction.  The remaining 16 bytes are used as the
key for the client to server direction.  This gives independent
128-bit keys for each direction.

This algorithm is the alleged RC4 cipher posted to the Usenet in 1995.
It is widely believed to be equivalent with the original RSADSI RC4
cipher.  This is a very fast algorithm.
.RT


.ti 0
Data Type Encodings

The Data field of each packet contains data encoded as described in
this section.  There may be several data items; each item is coded as
described here, and their representations are concatenated together
(without any alignment or padding).

Each data type is stored as follows:
.IP "8-bit byte"
The byte is stored directly as a single byte.
.IP "32-bit unsigned integer"
Stored in 4 bytes, msb first.
.IP "Arbitrary length binary string"
First 4 bytes are the length of the string, msb first (not including
the length itself).  The following "length" bytes are the string
value.  There are no terminating null characters.
.IP "Multiple-precision integer"
First 2 bytes are the number of bits in the integer, msb first (for