The R13B03 release.OTP_R13B03

1 files changed, 1624 insertions, 0 deletions

diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt b/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt
new file mode 100644
index 0000000000..9073ea52b2
--- /dev/null
+++ b/lib/ssh/doc/standard/draft-ietf-secsh-transport-17.txt
@@ -0,0 +1,1624 @@
+
+
+
+Network Working Group                                          T. Ylonen
+Internet-Draft                          SSH Communications Security Corp
+Expires: March 31, 2004                           D. Moffat, Editor, Ed.
+                                                   Sun Microsystems, Inc
+                                                                Oct 2003
+
+
+                      SSH Transport Layer Protocol
+                   draft-ietf-secsh-transport-17.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 March 31, 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 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
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004               [Page 1]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+   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.    Contributors . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.    Conventions Used in This Document  . . . . . . . . . . . . .  3
+   4.    Connection Setup . . . . . . . . . . . . . . . . . . . . . .  3
+   4.1   Use over TCP/IP  . . . . . . . . . . . . . . . . . . . . . .  4
+   4.2   Protocol Version Exchange  . . . . . . . . . . . . . . . . .  4
+   4.3   Compatibility With Old SSH Versions  . . . . . . . . . . . .  4
+   4.3.1 Old Client, New Server . . . . . . . . . . . . . . . . . . .  5
+   4.3.2 New Client, Old Server . . . . . . . . . . . . . . . . . . .  5
+   5.    Binary Packet Protocol . . . . . . . . . . . . . . . . . . .  5
+   5.1   Maximum Packet Length  . . . . . . . . . . . . . . . . . . .  6
+   5.2   Compression  . . . . . . . . . . . . . . . . . . . . . . . .  7
+   5.3   Encryption . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   5.4   Data Integrity . . . . . . . . . . . . . . . . . . . . . . .  9
+   5.5   Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 10
+   5.6   Public Key Algorithms  . . . . . . . . . . . . . . . . . . . 11
+   6.    Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . 13
+   6.1   Algorithm Negotiation  . . . . . . . . . . . . . . . . . . . 13
+   6.2   Output from Key Exchange . . . . . . . . . . . . . . . . . . 16
+   6.3   Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . 17
+   7.    Diffie-Hellman Key Exchange  . . . . . . . . . . . . . . . . 18
+   7.1   diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . 19
+   8.    Key Re-Exchange  . . . . . . . . . . . . . . . . . . . . . . 20
+   9.    Service Request  . . . . . . . . . . . . . . . . . . . . . . 21
+   10.   Additional Messages  . . . . . . . . . . . . . . . . . . . . 21
+   10.1  Disconnection Message  . . . . . . . . . . . . . . . . . . . 22
+   10.2  Ignored Data Message . . . . . . . . . . . . . . . . . . . . 22
+   10.3  Debug Message  . . . . . . . . . . . . . . . . . . . . . . . 23
+   10.4  Reserved Messages  . . . . . . . . . . . . . . . . . . . . . 23
+   11.   Summary of Message Numbers . . . . . . . . . . . . . . . . . 23
+   12.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 24
+   13.   Security Considerations  . . . . . . . . . . . . . . . . . . 24
+   14.   Intellectual Property  . . . . . . . . . . . . . . . . . . . 24
+   15.   Additional Information . . . . . . . . . . . . . . . . . . . 24
+         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26
+         Normative  . . . . . . . . . . . . . . . . . . . . . . . . . 25
+         Informative  . . . . . . . . . . . . . . . . . . . . . . . . 25
+   A.    Contibutors  . . . . . . . . . . . . . . . . . . . . . . . . 27
+         Intellectual Property and Copyright Statements . . . . . . . 28
+
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004               [Page 2]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+1. Contributors
+
+   The major original contributors of this document were: Tatu Ylonen,
+   Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications
+   Security Corp), and Markku-Juhani O. Saarinen (University of
+   Jyvaskyla)
+
+   The document editor is: [email protected].  Comments on this
+   internet draft should be sent to the IETF SECSH working group,
+   details at: http://ietf.org/html.charters/secsh-charter.html
+
+2. 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.
+
+3. 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.
+
+4. 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.
+
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004               [Page 3]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+   The client initiates the connection.
+
+4.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.
+
+4.2 Protocol Version Exchange
+
+   When the connection has been established, both sides MUST send an
+   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 7).
+
+   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.
+
+4.3 Compatibility With Old SSH Versions
+
+   During the transition period, it is important to be able to work in a
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004               [Page 4]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+   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.  There is no standards track or informational
+   draft available that defines the SSH 1.x protocol.  The only known
+   documentation of the 1.x protocol is contained in README files that
+   are shipped along with the source code.
+
+4.3.1 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".
+   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.
+
+4.3.2 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.
+
+5. 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
+
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004               [Page 5]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+         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".
+
+      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.
+
+5.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
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004               [Page 6]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+   length is reasonable for the implementation to avoid
+   denial-of-service and/or buffer overflow attacks.
+
+5.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.
+
+   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].
+
+5.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).
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004               [Page 7]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+   The following ciphers are currently defined:
+
+     3des-cbc         REQUIRED          three-key 3DES in CBC mode
+     blowfish-cbc     OPTIONALi         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)
+     twofish192-cbc   OPTIONAL          Twofish with 192-bit key
+     twofish128-cbc   OPTIONAL          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 [FIPS-46-3]
+
+   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)
+   [FIPS-197], formerly Rijndael, in CBC mode. This version uses 256-bit
+   key.
+
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004               [Page 8]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+   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.
+
+   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].
+
+   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].
+
+5.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
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004               [Page 9]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+   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
+   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
+
+                                Figure 1
+
+   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].
+
+5.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].
+
+
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 10]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+5.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
+      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    Raw DSS Key
+   ssh-rsa              RECOMMENDED  sign    Raw RSA Key
+   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.
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 11]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+   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
+     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).
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 12]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+   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 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.
+
+6. 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 6.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.
+
+6.1 Algorithm Negotiation
+
+   Key exchange begins by each side sending the following packet:
+
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 13]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+     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
+     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.
+
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 14]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+      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 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 5.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.
+
+
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 15]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+         Note that "none" must be explicitly listed if it is to be
+         acceptable.  The compression algorithm names are listed in
+         Section Section 5.2.
+
+      languages
+         This is a comma-separated list of language tags in order of
+         preference [RFC3066]. Both parties MAY ignore this list. If
+         there are no language preferences, this list SHOULD be empty.
+         Language tags SHOULD NOT be present unless they are known to be
+         needed by the sending party.
+
+      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.
+
+6.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:
+
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 16]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+   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)
+   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) MUST be used for algorithms with variable-length
+   keys. The only variable key length algorithm defined in this document
+   is arcfour).  For other algorithms, as many bytes as are needed are
+   taken from the beginning of the hash value. If the key length needed
+   is 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.
+
+6.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.
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 17]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+     byte      SSH_MSG_NEWKEYS
+
+
+7. 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 & Moffat, Editor    Expires March 31, 2004              [Page 18]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 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.
+
+7.1 diffie-hellman-group1-sha1
+
+   The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key
+   exchange with SHA-1 as HASH, and Oakley group 14 [RFC3526] (2048-bit
+   MODP Group).  It is included below in hexadecimal and decimal.
+
+   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
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 19]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+         FFFFFFFF FFFFFFFF.
+
+   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.
+
+8. 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
+   6.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
+   above the SSH transport layer.
+
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 20]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+9. 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.
+
+10. Additional Messages
+
+   Either party may send any of the following messages at any time.
+
+
+
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 21]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+10.1 Disconnection Message
+
+     byte      SSH_MSG_DISCONNECT
+     uint32    reason code
+     string    description [RFC2279]
+     string    language tag [RFC3066]
+
+   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.
+
+10.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 & Moffat, Editor    Expires March 31, 2004              [Page 22]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+10.3 Debug Message
+
+     byte      SSH_MSG_DEBUG
+     boolean   always_display
+     string    message [RFC2279]
+     string    language tag [RFC3066]
+
+   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.
+
+10.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
+
+
+11. 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
+     #define SSH_MSG_NEWKEYS                21
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 23]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+     /* 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
+
+
+12. IANA Considerations
+
+   This document is part of a set, the IANA considerations for the SSH
+   protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH],
+   [SSH-CONNECT] are detailed in [SSH-NUMBERS].
+
+13. 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]
+
+14. 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.
+
+15. Additional Information
+
+   The current document editor is: [email protected]. Comments on
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 24]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+   this internet draft should be sent to the IETF SECSH working group,
+   details at: http://ietf.org/html.charters/secsh-charter.html
+
+Normative
+
+   [SSH-ARCH]
+              Ylonen, T., "SSH Protocol Architecture", I-D
+              draft-ietf-architecture-15.txt, Oct 2003.
+
+   [SSH-TRANS]
+              Ylonen, T., "SSH Transport Layer Protocol", I-D
+              draft-ietf-transport-17.txt, Oct 2003.
+
+   [SSH-USERAUTH]
+              Ylonen, T., "SSH Authentication Protocol", I-D
+              draft-ietf-userauth-18.txt, Oct 2003.
+
+   [SSH-CONNECT]
+              Ylonen, T., "SSH Connection Protocol", I-D
+              draft-ietf-connect-18.txt, Oct 2003.
+
+   [SSH-NUMBERS]
+              Lehtinen, S. and D. Moffat, "SSH Protocol Assigned
+              Numbers", I-D draft-ietf-secsh-assignednumbers-05.txt, Oct
+              2003.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+Informative
+
+   [FIPS-186]
+              Federal Information Processing Standards Publication,
+              "FIPS PUB 186, Digital Signature Standard", May 1994.
+
+   [FIPS-197]
+              NIST, "FIPS PUB 197 Advanced Encryption Standard (AES)",
+              November 2001.
+
+   [FIPS-46-3]
+              U.S. Dept. of Commerce, "FIPS PUB 46-3, Data Encryption
+              Standard (DES)", October 1999.
+
+   [RFC2459]  Housley, R., Ford, W., Polk, T. 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",
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 25]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+              STD 13, RFC 1034, November 1987.
+
+   [RFC3066]  Alvestrand, H., "Tags for the Identification of
+              Languages", BCP 47, RFC 3066, January 2001.
+
+   [RFC1950]  Deutsch, L. 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.
+
+   [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.
+
+   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+              Diffie-Hellman groups for Internet Key Exchange (IKE)",
+              RFC 3526, May 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 26]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+Authors' Addresses
+
+   Tatu Ylonen
+   SSH Communications Security Corp
+   Fredrikinkatu 42
+   HELSINKI  FIN-00100
+   Finland
+
+   EMail: [email protected]
+
+
+   Darren J. Moffat (editor)
+   Sun Microsystems, Inc
+   17 Network Circle
+   Menlo Park  95025
+   USA
+
+   EMail: [email protected]
+
+Appendix A. Contibutors
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 27]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+Intellectual Property Statement
+
+   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 implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard. Please address the information to the IETF Executive
+   Director.
+
+   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.
+
+
+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 assignees.
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 28]
+
+Internet-Draft        SSH Transport Layer Protocol              Oct 2003
+
+
+   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.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 29]
\ No newline at end of file