ports/libssh
ports/libssh
1
1
Форкнуть 0
Код Релизы 1 Активность
55846a4c7b
libssh/doc/draft-ietf-secsh-transport-16.txt
Aris Adamantiadis c65f56aefa first import 
git-svn-id: svn+ssh://svn.berlios.de/svnroot/repos/libssh/trunk@1 7dcaeef0-15fb-0310-b436-a5af3365683c
2005-07-05 01:21:44 +00:00

1625 строки
60 KiB
Plaintext
Исходник Ответственный История

Этот файл содержит невидимые символы Юникода

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Network Working Group T. Ylonen
Internet-Draft T. Kivinen
Expires: January 12, 2004 SSH Communications Security Corp
M. Saarinen
University of Jyvaskyla
T. Rinne
S. Lehtinen
SSH Communications Security Corp
July 14, 2003
SSH Transport Layer Protocol
draft-ietf-secsh-transport-16.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
SSH is a protocol for secure remote login and other secure network
services over an insecure network.
This document describes the SSH transport layer protocol which
typically runs on top of TCP/IP. The protocol can be used as a
Ylonen, et. al. Expires January 12, 2004 [Page 1]
Internet-Draft SSH Transport Layer Protocol July 2003
basis for a number of secure network services. It provides strong
encryption, server authentication, and integrity protection. It
may also provide compression.
Key exchange method, public key algorithm, symmetric encryption
algorithm, message authentication algorithm, and hash algorithm
are all negotiated.
This document also describes the Diffie-Hellman key exchange
method and the minimal set of algorithms that are needed to
implement the SSH transport layer protocol.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Connection Setup . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Protocol Version Exchange . . . . . . . . . . . . . . . . . . 4
3.3 Compatibility With Old SSH Versions . . . . . . . . . . . . . 5
3.4 Old Client, New Server . . . . . . . . . . . . . . . . . . . . 5
3.5 New Client, Old Server . . . . . . . . . . . . . . . . . . . . 6
4. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . . 6
4.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . . . 7
4.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . . . 11
4.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . . . 11
5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . . . 14
5.2 Output from Key Exchange . . . . . . . . . . . . . . . . . . . 17
5.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . . 18
6. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 19
6.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . . 20
7. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . . 21
8. Service Request . . . . . . . . . . . . . . . . . . . . . . . 22
9. Additional Messages . . . . . . . . . . . . . . . . . . . . . 22
9.1 Disconnection Message . . . . . . . . . . . . . . . . . . . . 23
9.2 Ignored Data Message . . . . . . . . . . . . . . . . . . . . . 23
9.3 Debug Message . . . . . . . . . . . . . . . . . . . . . . . . 24
9.4 Reserved Messages . . . . . . . . . . . . . . . . . . . . . . 24
10. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. Intellectual Property . . . . . . . . . . . . . . . . . . . . 25
13. Additional Information . . . . . . . . . . . . . . . . . . . . 25
References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
Ylonen, et. al. Expires January 12, 2004 [Page 2]
Internet-Draft SSH Transport Layer Protocol July 2003
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 29
Ylonen, et. al. Expires January 12, 2004 [Page 3]
Internet-Draft SSH Transport Layer Protocol July 2003
1. Introduction
The SSH transport layer is a secure low level transport protocol.
It provides strong encryption, cryptographic host authentication,
and integrity protection.
Authentication in this protocol level is host-based; this protocol
does not perform user authentication. A higher level protocol for
user authentication can be designed on top of this protocol.
The protocol has been designed to be simple, flexible, to allow
parameter negotiation, and to minimize the number of round-trips.
Key exchange method, public key algorithm, symmetric encryption
algorithm, message authentication algorithm, and hash algorithm
are all negotiated. It is expected that in most environments,
only 2 round-trips will be needed for full key exchange, server
authentication, service request, and acceptance notification of
service request. The worst case is 3 round-trips.
2. Conventions Used in This Document
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
NOT", and "MAY" that appear in this document are to be interpreted
as described in [RFC2119]
The used data types and terminology are specified in the
architecture document [SSH-ARCH]
The architecture document also discusses the algorithm naming
conventions that MUST be used with the SSH protocols.
3. Connection Setup
SSH works over any 8-bit clean, binary-transparent transport. The
underlying transport SHOULD protect against transmission errors as
such errors cause the SSH connection to terminate.
The client initiates the connection.
3.1 Use over TCP/IP
When used over TCP/IP, the server normally listens for connections
on port 22. This port number has been registered with the IANA,
and has been officially assigned for SSH.
3.2 Protocol Version Exchange
When the connection has been established, both sides MUST send an
Ylonen, et. al. Expires January 12, 2004 [Page 4]
Internet-Draft SSH Transport Layer Protocol July 2003
identification string of the form "SSH-protoversion-
softwareversion comments", followed by carriage return and newline
characters (ASCII 13 and 10, respectively). Both sides MUST be
able to process identification strings without carriage return
character. No null character is sent. The maximum length of the
string is 255 characters, including the carriage return and
newline.
The part of the identification string preceding carriage return
and newline is used in the Diffie-Hellman key exchange (see
Section Section 6).
The server MAY send other lines of data before sending the version
string. Each line SHOULD be terminated by a carriage return and
newline. Such lines MUST NOT begin with "SSH-", and SHOULD be
encoded in ISO-10646 UTF-8 [RFC2279] (language is not specified).
Clients MUST be able to process such lines; they MAY be silently
ignored, or MAY be displayed to the client user; if they are
displayed, control character filtering discussed in [SSH-ARCH]
SHOULD be used. The primary use of this feature is to allow TCP-
wrappers to display an error message before disconnecting.
Version strings MUST consist of printable US-ASCII characters, not
including whitespaces or a minus sign (-). The version string is
primarily used to trigger compatibility extensions and to indicate
the capabilities of an implementation. The comment string should
contain additional information that might be useful in solving
user problems.
The protocol version described in this document is 2.0.
Key exchange will begin immediately after sending this identifier.
All packets following the identification string SHALL use the
binary packet protocol, to be described below.
3.3 Compatibility With Old SSH Versions
During the transition period, it is important to be able to work
in a way that is compatible with the installed SSH clients and
servers that use an older version of the protocol. Information in
this section is only relevant for implementations supporting
compatibility with SSH versions 1.x.
3.4 Old Client, New Server
Server implementations MAY support a configurable "compatibility"
flag that enables compatibility with old versions. When this flag
is on, the server SHOULD identify its protocol version as "1.99".
Ylonen, et. al. Expires January 12, 2004 [Page 5]
Internet-Draft SSH Transport Layer Protocol July 2003
Clients using protocol 2.0 MUST be able to identify this as
identical to "2.0". In this mode the server SHOULD NOT send the
carriage return character (ASCII 13) after the version
identification string.
In the compatibility mode the server SHOULD NOT send any further
data after its initialization string until it has received an
identification string from the client. The server can then
determine whether the client is using an old protocol, and can
revert to the old protocol if required. In the compatibility
mode, the server MUST NOT send additional data before the version
string.
When compatibility with old clients is not needed, the server MAY
send its initial key exchange data immediately after the
identification string.
3.5 New Client, Old Server
Since the new client MAY immediately send additional data after
its identification string (before receiving server's
identification), the old protocol may already have been corrupted
when the client learns that the server is old. When this happens,
the client SHOULD close the connection to the server, and
reconnect using the old protocol.
4. Binary Packet Protocol
Each packet is in the following format:
uint32 packet_length
byte padding_length
byte[n1] payload; n1 = packet_length - padding_length - 1
byte[n2] random padding; n2 = padding_length
byte[m] mac (message authentication code); m = mac_length
packet_length
The length of the packet (bytes), not including MAC or the
packet_length field itself.
padding_length
Length of padding (bytes).
payload
The useful contents of the packet. If compression has been
negotiated, this field is compressed. Initially,
compression MUST be "none".
Ylonen, et. al. Expires January 12, 2004 [Page 6]
Internet-Draft SSH Transport Layer Protocol July 2003
random padding
Arbitrary-length padding, such that the total length of
(packet_length || padding_length || payload || padding) is a
multiple of the cipher block size or 8, whichever is larger.
There MUST be at least four bytes of padding. The padding
SHOULD consist of random bytes. The maximum amount of
padding is 255 bytes.
mac
Message authentication code. If message authentication has
been negotiated, this field contains the MAC bytes.
Initially, the MAC algorithm MUST be "none".
Note that length of the concatenation of packet length, padding
length, payload, and padding MUST be a multiple of the cipher
block size or 8, whichever is larger. This constraint MUST be
enforced even when using stream ciphers. Note that the packet
length field is also encrypted, and processing it requires special
care when sending or receiving packets.
The minimum size of a packet is 16 (or the cipher block size,
whichever is larger) bytes (plus MAC); implementations SHOULD
decrypt the length after receiving the first 8 (or cipher block
size, whichever is larger) bytes of a packet.
4.1 Maximum Packet Length
All implementations MUST be able to process packets with
uncompressed payload length of 32768 bytes or less and total
packet size of 35000 bytes or less (including length, padding
length, payload, padding, and MAC.). The maximum of 35000 bytes
is an arbitrary chosen value larger than uncompressed size.
Implementations SHOULD support longer packets, where they might be
needed, e.g. if an implementation wants to send a very large
number of certificates. Such packets MAY be sent if the version
string indicates that the other party is able to process them.
However, implementations SHOULD check that the packet length is
reasonable for the implementation to avoid denial-of-service
and/or buffer overflow attacks.
4.2 Compression
If compression has been negotiated, the payload field (and only
it) will be compressed using the negotiated algorithm. The length
field and MAC will be computed from the compressed payload.
Encryption will be done after compression.
Ylonen, et. al. Expires January 12, 2004 [Page 7]
Internet-Draft SSH Transport Layer Protocol July 2003
Compression MAY be stateful, depending on the method. Compression
MUST be independent for each direction, and implementations MUST
allow independently choosing the algorithm for each direction.
The following compression methods are currently defined:
none REQUIRED no compression
zlib OPTIONAL ZLIB (LZ77) compression
The "zlib" compression is described in [RFC1950] and in [RFC1951].
The compression context is initialized after each key exchange,
and is passed from one packet to the next with only a partial
flush being performed at the end of each packet. A partial flush
means that the current compressed block is ended and all data will
be output. If the current block is not a stored block, one or
more empty blocks are added after the current block to ensure that
there are at least 8 bits counting from the start of the end-of-
block code of the current block to the end of the packet payload.
Additional methods may be defined as specified in [SSH-ARCH].
4.3 Encryption
An encryption algorithm and a key will be negotiated during the
key exchange. When encryption is in effect, the packet length,
padding length, payload and padding fields of each packet MUST be
encrypted with the given algorithm.
The encrypted data in all packets sent in one direction SHOULD be
considered a single data stream. For example, initialization
vectors SHOULD be passed from the end of one packet to the
beginning of the next packet. All ciphers SHOULD use keys with an
effective key length of 128 bits or more.
The ciphers in each direction MUST run independently of each
other, and implementations MUST allow independently choosing the
algorithm for each direction (if multiple algorithms are allowed
by local policy).
The following ciphers are currently defined:
3des-cbc REQUIRED three-key 3DES in CBC mode
blowfish-cbc RECOMMENDED Blowfish in CBC mode
twofish256-cbc OPTIONAL Twofish in CBC mode,
with 256-bit key
twofish-cbc OPTIONAL alias for "twofish256-cbc" (this
is being retained for
historical reasons)
Ylonen, et. al. Expires January 12, 2004 [Page 8]
Internet-Draft SSH Transport Layer Protocol July 2003
twofish192-cbc OPTIONAL Twofish with 192-bit key
twofish128-cbc RECOMMENDED Twofish with 128-bit key
aes256-cbc OPTIONAL AES (Rijndael) in CBC mode,
with 256-bit key
aes192-cbc OPTIONAL AES with 192-bit key
aes128-cbc RECOMMENDED AES with 128-bit key
serpent256-cbc OPTIONAL Serpent in CBC mode, with
256-bit key
serpent192-cbc OPTIONAL Serpent with 192-bit key
serpent128-cbc OPTIONAL Serpent with 128-bit key
arcfour OPTIONAL the ARCFOUR stream cipher
idea-cbc OPTIONAL IDEA in CBC mode
cast128-cbc OPTIONAL CAST-128 in CBC mode
none OPTIONAL no encryption; NOT RECOMMENDED
The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-
encrypt), where the first 8 bytes of the key are used for the
first encryption, the next 8 bytes for the decryption, and the
following 8 bytes for the final encryption. This requires 24
bytes of key data (of which 168 bits are actually used). To
implement CBC mode, outer chaining MUST be used (i.e., there is
only one initialization vector). This is a block cipher with 8
byte blocks. This algorithm is defined in [SCHNEIER]
The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit
keys [SCHNEIER]. This is a block cipher with 8 byte blocks.
The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC
mode, with 256 bit keys as described [TWOFISH]. This is a block
cipher with 16 byte blocks.
The "twofish192-cbc" cipher. Same as above but with 192-bit key.
The "twofish128-cbc" cipher. Same as above but with 128-bit key.
The "aes256-cbc" cipher is AES (Advanced Encryption Standard),
formerly Rijndael, in CBC mode. This version uses 256-bit key.
The "aes192-cbc" cipher. Same as above but with 192-bit key.
The "aes128-cbc" cipher. Same as above but with 128-bit key.
The "serpent256-cbc" cipher in CBC mode, with 256-bit key as
described in the Serpent AES submission.
The "serpent192-cbc" cipher. Same as above but with 192-bit key.
The "serpent128-cbc" cipher. Same as above but with 128-bit key.
Ylonen, et. al. Expires January 12, 2004 [Page 9]
Internet-Draft SSH Transport Layer Protocol July 2003
The "arcfour" is the Arcfour stream cipher with 128 bit keys. The
Arcfour cipher is believed to be compatible with the RC4 cipher
[SCHNEIER]. RC4 is a registered trademark of RSA Data Security
Inc. Arcfour (and RC4) has problems with weak keys, and should be
used with caution.
The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER].
IDEA is patented by Ascom AG.
The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode
[RFC2144].
The "none" algorithm specifies that no encryption is to be done.
Note that this method provides no confidentiality protection, and
it is not recommended. Some functionality (e.g. password
authentication) may be disabled for security reasons if this
cipher is chosen.
Additional methods may be defined as specified in [SSH-ARCH].
4.4 Data Integrity
Data integrity is protected by including with each packet a
message authentication code (MAC) that is computed from a shared
secret, packet sequence number, and the contents of the packet.
The message authentication algorithm and key are negotiated during
key exchange. Initially, no MAC will be in effect, and its length
MUST be zero. After key exchange, the selected MAC will be
computed before encryption from the concatenation of packet data:
mac = MAC(key, sequence_number || unencrypted_packet)
where unencrypted_packet is the entire packet without MAC (the
length fields, payload and padding), and sequence_number is an
implicit packet sequence number represented as uint32. The
sequence number is initialized to zero for the first packet, and
is incremented after every packet (regardless of whether
encryption or MAC is in use). It is never reset, even if
keys/algorithms are renegotiated later. It wraps around to zero
after every 2^32 packets. The packet sequence number itself is
not included in the packet sent over the wire.
The MAC algorithms for each direction MUST run independently, and
implementations MUST allow choosing the algorithm independently
for both directions.
The MAC bytes resulting from the MAC algorithm MUST be transmitted
Ylonen, et. al. Expires January 12, 2004 [Page 10]
Internet-Draft SSH Transport Layer Protocol July 2003
without encryption as the last part of the packet. The number of
MAC bytes depends on the algorithm chosen.
The following MAC algorithms are currently defined:
hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key
length = 20)
hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest
length = 12, key length = 20)
hmac-md5 OPTIONAL HMAC-MD5 (digest length = key
length = 16)
hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest
length = 12, key length = 16)
none OPTIONAL no MAC; NOT RECOMMENDED
The "hmac-*" algorithms are described in [RFC2104] The "*-n" MACs
use only the first n bits of the resulting value.
The hash algorithms are described in [SCHNEIER].
Additional methods may be defined as specified in [SSH-ARCH].
4.5 Key Exchange Methods
The key exchange method specifies how one-time session keys are
generated for encryption and for authentication, and how the
server authentication is done.
Only one REQUIRED key exchange method has been defined:
diffie-hellman-group1-sha1 REQUIRED
This method is described later in this document.
Additional methods may be defined as specified in [SSH-ARCH].
4.6 Public Key Algorithms
This protocol has been designed to be able to operate with almost
any public key format, encoding, and algorithm (signature and/or
encryption).
There are several aspects that define a public key type:
o Key format: how is the key encoded and how are certificates
represented. The key blobs in this protocol MAY contain
certificates in addition to keys.
o Signature and/or encryption algorithms. Some key types may not
support both signing and encryption. Key usage may also be
Ylonen, et. al. Expires January 12, 2004 [Page 11]
Internet-Draft SSH Transport Layer Protocol July 2003
restricted by policy statements in e.g. certificates. In this
case, different key types SHOULD be defined for the different
policy alternatives.
o Encoding of signatures and/or encrypted data. This includes
but is not limited to padding, byte order, and data formats.
The following public key and/or certificate formats are currently defined:
ssh-dss REQUIRED sign Simple DSS
ssh-rsa RECOMMENDED sign Simple RSA
x509v3-sign-rsa OPTIONAL sign X.509 certificates (RSA key)
x509v3-sign-dss OPTIONAL sign X.509 certificates (DSS key)
spki-sign-rsa OPTIONAL sign SPKI certificates (RSA key)
spki-sign-dss OPTIONAL sign SPKI certificates (DSS key)
pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key)
pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key)
Additional key types may be defined as specified in [SSH-ARCH].
The key type MUST always be explicitly known (from algorithm
negotiation or some other source). It is not normally included in
the key blob.
Certificates and public keys are encoded as follows:
string certificate or public key format identifier
byte[n] key/certificate data
The certificate part may have be a zero length string, but a
public key is required. This is the public key that will be used
for authentication; the certificate sequence contained in the
certificate blob can be used to provide authorization.
Public key / certifcate formats that do not explicitly specify a
signature format identifier MUST use the public key / certificate
format identifier as the signature identifier.
Signatures are encoded as follows:
string signature format identifier (as specified by the
public key / cert format)
byte[n] signature blob in format specific encoding.
The "ssh-dss" key format has the following specific encoding:
string "ssh-dss"
mpint p
mpint q
Ylonen, et. al. Expires January 12, 2004 [Page 12]
Internet-Draft SSH Transport Layer Protocol July 2003
mpint g
mpint y
Here the p, q, g, and y parameters form the signature key blob.
Signing and verifying using this key format is done according to
the Digital Signature Standard [FIPS-186] using the SHA-1 hash. A
description can also be found in [SCHNEIER].
The resulting signature is encoded as follows:
string "ssh-dss"
string dss_signature_blob
dss_signature_blob is encoded as a string containing r followed by
s (which are 160 bits long integers, without lengths or padding,
unsigned and in network byte order).
The "ssh-rsa" key format has the following specific encoding:
string "ssh-rsa"
mpint e
mpint n
Here the e and n parameters form the signature key blob.
Signing and verifying using this key format is done according to
[SCHNEIER] and [PKCS1] using the SHA-1 hash.
The resulting signature is encoded as follows:
string "ssh-rsa"
string rsa_signature_blob
rsa_signature_blob is encoded as a string containing s (which is
an integer, without lengths or padding, unsigned and in network
byte order).
The "spki-sign-rsa" method indicates that the certificate blob
contains a sequence of SPKI certificates. The format of SPKI
certificates is described in [RFC2693]. This method indicates
that the key (or one of the keys in the certificate) is an RSA-
key.
The "spki-sign-dss". As above, but indicates that the key (or one
of the keys in the certificate) is a DSS-key.
The "pgp-sign-rsa" method indicates the certificates, the public
Ylonen, et. al. Expires January 12, 2004 [Page 13]
Internet-Draft SSH Transport Layer Protocol July 2003
key, and the signature are in OpenPGP compatible binary format
([RFC2440]). This method indicates that the key is an RSA-key.
The "pgp-sign-dss". As above, but indicates that the key is a
DSS-key.
5. Key Exchange
Key exchange begins by each side sending lists of supported
algorithms. Each side has a preferred algorithm in each category,
and it is assumed that most implementations at any given time will
use the same preferred algorithm. Each side MAY guess which
algorithm the other side is using, and MAY send an initial key
exchange packet according to the algorithm if appropriate for the
preferred method.
Guess is considered wrong, if:
o the kex algorithm and/or the host key algorithm is guessed
wrong (server and client have different preferred algorithm),
or
o if any of the other algorithms cannot be agreed upon (the
procedure is defined below in Section Section 5.1).
Otherwise, the guess is considered to be right and the
optimistically sent packet MUST be handled as the first key
exchange packet.
However, if the guess was wrong, and a packet was optimistically
sent by one or both parties, such packets MUST be ignored (even if
the error in the guess would not affect the contents of the
initial packet(s)), and the appropriate side MUST send the correct
initial packet.
Server authentication in the key exchange MAY be implicit. After
a key exchange with implicit server authentication, the client
MUST wait for response to its service request message before
sending any further data.
5.1 Algorithm Negotiation
Key exchange begins by each side sending the following packet:
byte SSH_MSG_KEXINIT
byte[16] cookie (random bytes)
string kex_algorithms
string server_host_key_algorithms
string encryption_algorithms_client_to_server
string encryption_algorithms_server_to_client
Ylonen, et. al. Expires January 12, 2004 [Page 14]
Internet-Draft SSH Transport Layer Protocol July 2003
string mac_algorithms_client_to_server
string mac_algorithms_server_to_client
string compression_algorithms_client_to_server
string compression_algorithms_server_to_client
string languages_client_to_server
string languages_server_to_client
boolean first_kex_packet_follows
uint32 0 (reserved for future extension)
Each of the algorithm strings MUST be a comma-separated list of
algorithm names (see ''Algorithm Naming'' in [SSH-ARCH]). Each
supported (allowed) algorithm MUST be listed in order of
preference.
The first algorithm in each list MUST be the preferred (guessed)
algorithm. Each string MUST contain at least one algorithm name.
cookie
The cookie MUST be a random value generated by the sender.
Its purpose is to make it impossible for either side to
fully determine the keys and the session identifier.
kex_algorithms
Key exchange algorithms were defined above. The first
algorithm MUST be the preferred (and guessed) algorithm. If
both sides make the same guess, that algorithm MUST be used.
Otherwise, the following algorithm MUST be used to choose a
key exchange method: iterate over client's kex algorithms,
one at a time. Choose the first algorithm that satisfies
the following conditions:
+ the server also supports the algorithm,
+ if the algorithm requires an encryption-capable host key,
there is an encryption-capable algorithm on the server's
server_host_key_algorithms that is also supported by the
client, and
+ if the algorithm requires a signature-capable host key,
there is a signature-capable algorithm on the server's
server_host_key_algorithms that is also supported by the
client.
+ If no algorithm satisfying all these conditions can be
found, the connection fails, and both sides MUST
disconnect.
server_host_key_algorithms
List of the algorithms supported for the server host key.
The server lists the algorithms for which it has host keys;
the client lists the algorithms that it is willing to
Ylonen, et. al. Expires January 12, 2004 [Page 15]
Internet-Draft SSH Transport Layer Protocol July 2003
accept. (There MAY be multiple host keys for a host,
possibly with different algorithms.)
Some host keys may not support both signatures and
encryption (this can be determined from the algorithm), and
thus not all host keys are valid for all key exchange
methods.
Algorithm selection depends on whether the chosen key
exchange algorithm requires a signature or encryption
capable host key. It MUST be possible to determine this
from the public key algorithm name. The first algorithm on
the client's list that satisfies the requirements and is
also supported by the server MUST be chosen. If there is no
such algorithm, both sides MUST disconnect.
encryption_algorithms
Lists the acceptable symmetric encryption algorithms in
order of preference. The chosen encryption algorithm to
each direction MUST be the first algorithm on the client's
list that is also on the server's list. If there is no such
algorithm, both sides MUST disconnect.
Note that "none" must be explicitly listed if it is to be
acceptable. The defined algorithm names are listed in
Section Section 4.3.
mac_algorithms
Lists the acceptable MAC algorithms in order of preference.
The chosen MAC algorithm MUST be the first algorithm on the
client's list that is also on the server's list. If there
is no such algorithm, both sides MUST disconnect.
Note that "none" must be explicitly listed if it is to be
acceptable. The MAC algorithm names are listed in Section
Figure 1.
compression_algorithms
Lists the acceptable compression algorithms in order of
preference. The chosen compression algorithm MUST be the
first algorithm on the client's list that is also on the
server's list. If there is no such algorithm, both sides
MUST disconnect.
Note that "none" must be explicitly listed if it is to be
acceptable. The compression algorithm names are listed in
Section Section 4.2.
Ylonen, et. al. Expires January 12, 2004 [Page 16]
Internet-Draft SSH Transport Layer Protocol July 2003
languages
This is a comma-separated list of language tags in order of
preference [RFC1766]. Both parties MAY ignore this list.
If there are no language preferences, this list SHOULD be
empty.
first_kex_packet_follows
Indicates whether a guessed key exchange packet follows. If
a guessed packet will be sent, this MUST be TRUE. If no
guessed packet will be sent, this MUST be FALSE.
After receiving the SSH_MSG_KEXINIT packet from the other
side, each party will know whether their guess was right.
If the other party's guess was wrong, and this field was
TRUE, the next packet MUST be silently ignored, and both
sides MUST then act as determined by the negotiated key
exchange method. If the guess was right, key exchange MUST
continue using the guessed packet.
After the KEXINIT packet exchange, the key exchange algorithm is
run. It may involve several packet exchanges, as specified by the
key exchange method.
5.2 Output from Key Exchange
The key exchange produces two values: a shared secret K, and an
exchange hash H. Encryption and authentication keys are derived
from these. The exchange hash H from the first key exchange is
additionally used as the session identifier, which is a unique
identifier for this connection. It is used by authentication
methods as a part of the data that is signed as a proof of
possession of a private key. Once computed, the session
identifier is not changed, even if keys are later re-exchanged.
Each key exchange method specifies a hash function that is used in
the key exchange. The same hash algorithm MUST be used in key
derivation. Here, we'll call it HASH.
Encryption keys MUST be computed as HASH of a known value and K as
follows:
o Initial IV client to server: HASH(K || H || "A" || session_id)
(Here K is encoded as mpint and "A" as byte and session_id as
raw data."A" means the single character A, ASCII 65).
o Initial IV server to client: HASH(K || H || "B" || session_id)
o Encryption key client to server: HASH(K || H || "C" ||
session_id)
Ylonen, et. al. Expires January 12, 2004 [Page 17]
Internet-Draft SSH Transport Layer Protocol July 2003
o Encryption key server to client: HASH(K || H || "D" ||
session_id)
o Integrity key client to server: HASH(K || H || "E" ||
session_id)
o Integrity key server to client: HASH(K || H || "F" ||
session_id)
Key data MUST be taken from the beginning of the hash output. 128
bits (16 bytes) SHOULD be used for algorithms with variable-length
keys. For other algorithms, as many bytes as are needed are taken
from the beginning of the hash value. If the key length in longer
than the output of the HASH, the key is extended by computing HASH
of the concatenation of K and H and the entire key so far, and
appending the resulting bytes (as many as HASH generates) to the
key. This process is repeated until enough key material is
available; the key is taken from the beginning of this value. In
other words:
K1 = HASH(K || H || X || session_id) (X is e.g. "A")
K2 = HASH(K || H || K1)
K3 = HASH(K || H || K1 || K2)
...
key = K1 || K2 || K3 || ...
This process will lose entropy if the amount of entropy in K is
larger than the internal state size of HASH.
5.3 Taking Keys Into Use
Key exchange ends by each side sending an SSH_MSG_NEWKEYS message.
This message is sent with the old keys and algorithms. All
messages sent after this message MUST use the new keys and
algorithms.
When this message is received, the new keys and algorithms MUST be
taken into use for receiving.
This message is the only valid message after key exchange, in
addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE
messages. The purpose of this message is to ensure that a party
is able to respond with a disconnect message that the other party
can understand if something goes wrong with the key exchange.
Implementations MUST NOT accept any other messages after key
exchange before receiving SSH_MSG_NEWKEYS.
byte SSH_MSG_NEWKEYS
Ylonen, et. al. Expires January 12, 2004 [Page 18]
Internet-Draft SSH Transport Layer Protocol July 2003
6. Diffie-Hellman Key Exchange
The Diffie-Hellman key exchange provides a shared secret that can
not be determined by either party alone. The key exchange is
combined with a signature with the host key to provide host
authentication.
In the following description (C is the client, S is the server; p
is a large safe prime, g is a generator for a subgroup of GF(p),
and q is the order of the subgroup; V_S is S's version string; V_C
is C's version string; K_S is S's public host key; I_C is C's
KEXINIT message and I_S S's KEXINIT message which have been
exchanged before this part begins):
1. C generates a random number x (1 < x < q) and computes e = g^x
mod p. C sends "e" to S.
2. S generates a random number y (0 < y < q) and computes f = g^y
mod p. S receives "e". It computes K = e^y mod p, H =
hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (these
elements are encoded according to their types; see below), and
signature s on H with its private host key. S sends "K_S || f
|| s" to C. The signing operation may involve a second
hashing operation.
3. C verifies that K_S really is the host key for S (e.g. using
certificates or a local database). C is also allowed to
accept the key without verification; however, doing so will
render the protocol insecure against active attacks (but may
be desirable for practical reasons in the short term in many
environments). C then computes K = f^x mod p, H = hash(V_C ||
V_S || I_C || I_S || K_S || e || f || K), and verifies the
signature s on H.
Either side MUST NOT send or accept e or f values that are not in
the range [1, p-1]. If this condition is violated, the key
exchange fails.
This is implemented with the following messages. The hash
algorithm for computing the exchange hash is defined by the method
name, and is called HASH. The public key algorithm for signing is
negotiated with the KEXINIT messages.
First, the client sends the following:
Ylonen, et. al. Expires January 12, 2004 [Page 19]
Internet-Draft SSH Transport Layer Protocol July 2003
byte SSH_MSG_KEXDH_INIT
mpint e
The server responds with the following:
byte SSH_MSG_KEXDH_REPLY
string server public host key and certificates (K_S)
mpint f
string signature of H
The hash H is computed as the HASH hash of the concatenation of
the following:
string V_C, the client's version string (CR and NL excluded)
string V_S, the server's version string (CR and NL excluded)
string I_C, the payload of the client's SSH_MSG_KEXINIT
string I_S, the payload of the server's SSH_MSG_KEXINIT
string K_S, the host key
mpint e, exchange value sent by the client
mpint f, exchange value sent by the server
mpint K, the shared secret
This value is called the exchange hash, and it is used to
authenticate the key exchange. The exchange hash SHOULD be kept
secret.
The signature algorithm MUST be applied over H, not the original
data. Most signature algorithms include hashing and additional
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 hashed with SHA-1 as part of the signing operation.
6.1 diffie-hellman-group1-sha1
The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman
key exchange with SHA-1 as HASH, and the following group:
The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor( 2^894
Pi + 129093 ). Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF.
Ylonen, et. al. Expires January 12, 2004 [Page 20]
Internet-Draft SSH Transport Layer Protocol July 2003
In decimal, this value is:
179769313486231590770839156793787453197860296048756011706444
423684197180216158519368947833795864925541502180565485980503
646440548199239100050792877003355816639229553136239076508735
759914822574862575007425302077447712589550957937778424442426
617334727629299387668709205606050270810842907692932019128194
467627007.
The generator used with this prime is g = 2. The group order q is
(p - 1) / 2.
This group was taken from the ISAKMP/Oakley specification, and was
originally generated by Richard Schroeppel at the University of
Arizona. Properties of this prime are described in [Orm96].
7. Key Re-Exchange
Key re-exchange is started by sending an SSH_MSG_KEXINIT packet
when not already doing a key exchange (as described in Section
Section 5.1). When this message is received, a party MUST respond
with its own SSH_MSG_KEXINIT message except when the received
SSH_MSG_KEXINIT already was a reply. Either party MAY initiate
the re-exchange, but roles MUST NOT be changed (i.e., the server
remains the server, and the client remains the client).
Key re-exchange is performed using whatever encryption was in
effect when the exchange was started. Encryption, compression,
and MAC methods are not changed before a new SSH_MSG_NEWKEYS is
sent after the key exchange (as in the initial key exchange). Re-
exchange is processed identically to the initial key exchange,
except for the session identifier that will remain unchanged. It
is permissible to change some or all of the algorithms during the
re-exchange. Host keys can also change. All keys and
initialization vectors are recomputed after the exchange.
Compression and encryption contexts are reset.
It is recommended that the keys are changed after each gigabyte of
transmitted data or after each hour of connection time, whichever
comes sooner. However, since the re-exchange is a public key
operation, it requires a fair amount of processing power and
should not be performed too often.
More application data may be sent after the SSH_MSG_NEWKEYS packet
has been sent; key exchange does not affect the protocols that lie
Ylonen, et. al. Expires January 12, 2004 [Page 21]
Internet-Draft SSH Transport Layer Protocol July 2003
above the SSH transport layer.
8. Service Request
After the key exchange, the client requests a service. The
service is identified by a name. The format of names and
procedures for defining new names are defined in [SSH-ARCH].
Currently, the following names have been reserved:
ssh-userauth
ssh-connection
Similar local naming policy is applied to the service names, as is
applied to the algorithm names; a local service should use the
"servicename@domain" syntax.
byte SSH_MSG_SERVICE_REQUEST
string service name
If the server rejects the service request, it SHOULD send an
appropriate SSH_MSG_DISCONNECT message and MUST disconnect.
When the service starts, it may have access to the session
identifier generated during the key exchange.
If the server supports the service (and permits the client to use
it), it MUST respond with the following:
byte SSH_MSG_SERVICE_ACCEPT
string service name
Message numbers used by services should be in the area reserved
for them (see Section 6 in [SSH-ARCH]). The transport level will
continue to process its own messages.
Note that after a key exchange with implicit server
authentication, the client MUST wait for response to its service
request message before sending any further data.
9. Additional Messages
Either party may send any of the following messages at any time.
Ylonen, et. al. Expires January 12, 2004 [Page 22]
Internet-Draft SSH Transport Layer Protocol July 2003
9.1 Disconnection Message
byte SSH_MSG_DISCONNECT
uint32 reason code
string description [RFC2279]
string language tag [RFC1766]
This message causes immediate termination of the connection. All
implementations MUST be able to process this message; they SHOULD
be able to send this message.
The sender MUST NOT send or receive any data after this message,
and the recipient MUST NOT accept any data after receiving this
message. The description field gives a more specific explanation
in a human-readable form. The error code gives the reason in a
more machine-readable format (suitable for localization), and can
have the following values:
#define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1
#define SSH_DISCONNECT_PROTOCOL_ERROR 2
#define SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3
#define SSH_DISCONNECT_RESERVED 4
#define SSH_DISCONNECT_MAC_ERROR 5
#define SSH_DISCONNECT_COMPRESSION_ERROR 6
#define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7
#define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8
#define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9
#define SSH_DISCONNECT_CONNECTION_LOST 10
#define SSH_DISCONNECT_BY_APPLICATION 11
#define SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12
#define SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13
#define SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14
#define SSH_DISCONNECT_ILLEGAL_USER_NAME 15
If the description string is displayed, control character
filtering discussed in [SSH-ARCH] should be used to avoid attacks
by sending terminal control characters.
9.2 Ignored Data Message
byte SSH_MSG_IGNORE
string data
All implementations MUST understand (and ignore) this message at
any time (after receiving the protocol version). No
implementation is required to send them. This message can be used
as an additional protection measure against advanced traffic
analysis techniques.
Ylonen, et. al. Expires January 12, 2004 [Page 23]
Internet-Draft SSH Transport Layer Protocol July 2003
9.3 Debug Message
byte SSH_MSG_DEBUG
boolean always_display
string message [RFC2279]
string language tag [RFC1766]
All implementations MUST understand this message, but they are
allowed to ignore it. This message is used to pass the other side
information that may help debugging. If always_display is TRUE,
the message SHOULD be displayed. Otherwise, it SHOULD NOT be
displayed unless debugging information has been explicitly
requested by the user.
The message doesn't need to contain a newline. It is, however,
allowed to consist of multiple lines separated by CRLF (Carriage
Return - Line Feed) pairs.
If the message string is displayed, terminal control character
filtering discussed in [SSH-ARCH] should be used to avoid attacks
by sending terminal control characters.
9.4 Reserved Messages
An implementation MUST respond to all unrecognized messages with
an SSH_MSG_UNIMPLEMENTED message in the order in which the
messages were received. Such messages MUST be otherwise ignored.
Later protocol versions may define other meanings for these
message types.
byte SSH_MSG_UNIMPLEMENTED
uint32 packet sequence number of rejected message
10. Summary of Message Numbers
The following message numbers have been defined in this protocol:
#define SSH_MSG_DISCONNECT 1
#define SSH_MSG_IGNORE 2
#define SSH_MSG_UNIMPLEMENTED 3
#define SSH_MSG_DEBUG 4
#define SSH_MSG_SERVICE_REQUEST 5
#define SSH_MSG_SERVICE_ACCEPT 6
#define SSH_MSG_KEXINIT 20
Ylonen, et. al. Expires January 12, 2004 [Page 24]
Internet-Draft SSH Transport Layer Protocol July 2003
#define SSH_MSG_NEWKEYS 21
/* Numbers 30-49 used for kex packets.
Different kex methods may reuse message numbers in
this range. */
#define SSH_MSG_KEXDH_INIT 30
#define SSH_MSG_KEXDH_REPLY 31
11. Security Considerations
This protocol provides a secure encrypted channel over an insecure
network. It performs server host authentication, key exchange,
encryption, and integrity protection. It also derives a unique
session id that may be used by higher-level protocols.
Full security considerations for this protocol are provided in
Section 8 of [SSH-ARCH]
12. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights.
Information on the IETF's procedures with respect to rights in
standards-track and standards-related documentation can be found
in BCP-11. Copies of claims of rights made available for
publication and any assurances of licenses to be made available,
or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers
or users of this specification can be obtained from the IETF
Secretariat.
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
13. Additional Information
The current document editor is: Darren.Moffat@Sun.COM. Comments
on this internet draft should be sent to the IETF SECSH working
group, details at: http://ietf.org/html.charters/secsh-
charter.html
Ylonen, et. al. Expires January 12, 2004 [Page 25]
Internet-Draft SSH Transport Layer Protocol July 2003
References
[FIPS-186] Federal Information Processing Standards
Publication, ., "FIPS PUB 186, Digital Signature
Standard", May 1994.
[Orm96] Orman, H., "The Okaley Key Determination Protcol
version1, TR97-92", 1996.
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and CRL Profile", RFC 2459, January
1999.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, Nov 1987.
[RFC1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995.
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May
1996.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", RFC 2279, January 1998.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC
2104, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm",
RFC 2144, May 1997.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R.
Thayer, "OpenPGP Message Format", RFC 2440,
November 1998.
[RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R.,
Thomas, B. and T. Ylonen, "SPKI Certificate
Theory", RFC 2693, September 1999.
Ylonen, et. al. Expires January 12, 2004 [Page 26]
Internet-Draft SSH Transport Layer Protocol July 2003
[SCHNEIER] Schneier, B., "Applied Cryptography Second
Edition: protocols algorithms and source in code
in C", 1996.
[TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm:
A 128-Bit Block Cipher, 1st Edition", March 1999.
[SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D
draft-ietf-architecture-14.txt, July 2003.
[SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D
draft-ietf-transport-16.txt, July 2003.
[SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D
draft-ietf-userauth-17.txt, July 2003.
[SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft-
ietf-connect-17.txt, July 2003.
[SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH Protocol Assigned
Numbers", I-D draft-ietf-secsh-assignednumbers-
03.txt, July 2003.
Authors' Addresses
Tatu Ylonen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: ylo@ssh.com
Tero Kivinen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: kivinen@ssh.com
Markku-Juhani O. Saarinen
University of Jyvaskyla
Ylonen, et. al. Expires January 12, 2004 [Page 27]
Internet-Draft SSH Transport Layer Protocol July 2003
Timo J. Rinne
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: tri@ssh.com
Sami Lehtinen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: sjl@ssh.com
Ylonen, et. al. Expires January 12, 2004 [Page 28]
Internet-Draft SSH Transport Layer Protocol July 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ylonen, et. al. Expires January 12, 2004 [Page 29]
Показать git blame Копировать постоянную ссылку