draft-ietf-secsh-transport-17.txt

来自「OTP是开放电信平台的简称」· 文本 代码 · 共 1,624 行 · 第 1/5 页

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: [e-mail].  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