draft-ietf-secsh-architecture-15.txt

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

Network Working Group                                          T. Ylonen
Internet-Draft                          SSH Communications Security Corp
Expires: March 31, 2004                                   D. Moffat, Ed.
                                                   Sun Microsystems, Inc
                                                                Oct 2003


                       SSH Protocol Architecture
                  draft-ietf-secsh-architecture-15.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
   architecture of the SSH protocol, as well as the notation and
   terminology used in SSH protocol documents. It also discusses the SSH
   algorithm naming system that allows local extensions. The SSH
   protocol consists of three major components: The Transport Layer
   Protocol provides server authentication, confidentiality, and
   integrity with perfect forward secrecy. The User Authentication
   Protocol authenticates the client to the server. The Connection
   Protocol multiplexes the encrypted tunnel into several logical
   channels. Details of these protocols are described in separate



Ylonen & Moffat          Expires March 31, 2004                 [Page 1]

Internet-Draft         SSH Protocol Architecture                Oct 2003


   documents.

Table of Contents

   1.    Contributors . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.    Specification of Requirements  . . . . . . . . . . . . . . .  3
   4.    Architecture . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.1   Host Keys  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.2   Extensibility  . . . . . . . . . . . . . . . . . . . . . . .  5
   4.3   Policy Issues  . . . . . . . . . . . . . . . . . . . . . . .  5
   4.4   Security Properties  . . . . . . . . . . . . . . . . . . . .  6
   4.5   Packet Size and Overhead . . . . . . . . . . . . . . . . . .  6
   4.6   Localization and Character Set Support . . . . . . . . . . .  7
   5.    Data Type Representations Used in the SSH Protocols  . . . .  8
   6.    Algorithm Naming . . . . . . . . . . . . . . . . . . . . . . 10
   7.    Message Numbers  . . . . . . . . . . . . . . . . . . . . . . 11
   8.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 11
   9.    Security Considerations  . . . . . . . . . . . . . . . . . . 12
   9.1   Pseudo-Random Number Generation  . . . . . . . . . . . . . . 12
   9.2   Transport  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   9.2.1 Confidentiality  . . . . . . . . . . . . . . . . . . . . . . 13
   9.2.2 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 16
   9.2.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   9.2.4 Man-in-the-middle  . . . . . . . . . . . . . . . . . . . . . 17
   9.2.5 Denial-of-service  . . . . . . . . . . . . . . . . . . . . . 19
   9.2.6 Covert Channels  . . . . . . . . . . . . . . . . . . . . . . 19
   9.2.7 Forward Secrecy  . . . . . . . . . . . . . . . . . . . . . . 20
   9.3   Authentication Protocol  . . . . . . . . . . . . . . . . . . 20
   9.3.1 Weak Transport . . . . . . . . . . . . . . . . . . . . . . . 21
   9.3.2 Debug messages . . . . . . . . . . . . . . . . . . . . . . . 21
   9.3.3 Local security policy  . . . . . . . . . . . . . . . . . . . 21
   9.3.4 Public key authentication  . . . . . . . . . . . . . . . . . 22
   9.3.5 Password authentication  . . . . . . . . . . . . . . . . . . 22
   9.3.6 Host based authentication  . . . . . . . . . . . . . . . . . 23
   9.4   Connection protocol  . . . . . . . . . . . . . . . . . . . . 23
   9.4.1 End point security . . . . . . . . . . . . . . . . . . . . . 23
   9.4.2 Proxy forwarding . . . . . . . . . . . . . . . . . . . . . . 23
   9.4.3 X11 forwarding . . . . . . . . . . . . . . . . . . . . . . . 24
         Normative References . . . . . . . . . . . . . . . . . . . . 24
         Informative References . . . . . . . . . . . . . . . . . . . 25
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
         Intellectual Property and Copyright Statements . . . . . . . 28








Ylonen & Moffat          Expires March 31, 2004                 [Page 2]

Internet-Draft         SSH Protocol Architecture                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

   SSH is a protocol for secure remote login and other secure network
   services over an insecure network.  It consists of three major
   components:
   o  The Transport Layer Protocol [SSH-TRANS] provides server
      authentication, confidentiality, and integrity. It may optionally
      also provide compression. The transport layer will typically be
      run over a TCP/IP connection, but might also be used on top of any
      other reliable data stream.
   o  The User Authentication Protocol [SSH-USERAUTH] authenticates the
      client-side user to the server. It runs over the transport layer
      protocol.
   o  The Connection Protocol [SSH-CONNECT] multiplexes the encrypted
      tunnel into several logical channels. It runs over the user
      authentication protocol.

   The client sends a service request once a secure transport layer
   connection has been established. A second service request is sent
   after user authentication is complete. This allows new protocols to
   be defined and coexist with the protocols listed above.

   The connection protocol provides channels that can be used for a wide
   range of purposes. Standard methods are provided for setting up
   secure interactive shell sessions and for forwarding ("tunneling")
   arbitrary TCP/IP ports and X11 connections.

3. Specification of Requirements

   All documents related to the SSH protocols shall use the keywords
   "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe
   requirements.  They are to be interpreted as described in [RFC2119].

4. Architecture





Ylonen & Moffat          Expires March 31, 2004                 [Page 3]

Internet-Draft         SSH Protocol Architecture                Oct 2003


4.1 Host Keys

   Each server host SHOULD have a host key.  Hosts MAY have multiple
   host keys using multiple different algorithms.  Multiple hosts MAY
   share the same host key. If a host has keys at all, it MUST have at
   least one key using each REQUIRED public key algorithm (DSS
   [FIPS-186]).

   The server host key is used during key exchange to verify that the
   client is really talking to the correct server. For this to be
   possible, the client must have a priori knowledge of the server's
   public host key.

   Two different trust models can be used:
   o  The client has a local database that associates each host name (as
      typed by the user) with the corresponding public host key.  This
      method requires no centrally administered infrastructure, and no
      third-party coordination.  The downside is that the database of
      name-to-key associations may become burdensome to maintain.
   o  The host name-to-key association is certified by some trusted
      certification authority.  The client only knows the CA root key,
      and can verify the validity of all host keys certified by accepted
      CAs.

      The second alternative eases the maintenance problem, since
      ideally only a single CA key needs to be securely stored on the
      client.  On the other hand, each host key must be appropriately
      certified by a central authority before authorization is possible.
      Also, a lot of trust is placed on the central infrastructure.

   The protocol provides the option that the server name - host key
   association is not checked when connecting to the host for the first
   time. This allows communication without prior communication of host
   keys or certification. The connection still provides protection
   against passive listening; however, it becomes vulnerable to active
   man-in-the-middle attacks. Implementations SHOULD NOT normally allow
   such connections by default, as they pose a potential security
   problem. However, as there is no widely deployed key infrastructure
   available on the Internet yet, this option makes the protocol much
   more usable during the transition time until such an infrastructure
   emerges, while still providing a much higher level of security than
   that offered by older solutions (e.g. telnet [RFC-854] and rlogin
   [RFC-1282]).

   Implementations SHOULD try to make the best effort to check host
   keys.  An example of a possible strategy is to only accept a host key
   without checking the first time a host is connected, save the key in
   a local database, and compare against that key on all future



Ylonen & Moffat          Expires March 31, 2004                 [Page 4]

Internet-Draft         SSH Protocol Architecture                Oct 2003


   connections to that host.

   Implementations MAY provide additional methods for verifying the
   correctness of host keys, e.g. a hexadecimal fingerprint derived from
   the SHA-1 hash of the public key. Such fingerprints can easily be
   verified by using telephone or other external communication channels.

   All implementations SHOULD provide an option to not accept host keys
   that cannot be verified.

   We believe that ease of use is critical to end-user acceptance of
   security solutions, and no improvement in security is gained if the
   new solutions are not used.  Thus, providing the option not to check
   the server host key is believed to improve the overall security of
   the Internet, even though it reduces the security of the protocol in
   configurations where it is allowed.

4.2 Extensibility

   We believe that the protocol will evolve over time, and some
   organizations will want to use their own encryption, authentication
   and/or key exchange methods.  Central registration of all extensions
   is cumbersome, especially for experimental or classified features.
   On the other hand, having no central registration leads to conflicts
   in method identifiers, making interoperability difficult.

   We have chosen to identify algorithms, methods, formats, and
   extension protocols with textual names that are of a specific format.
   DNS names are used to create local namespaces where experimental or
   classified extensions can be defined without fear of conflicts with
   other implementations.

   One design goal has been to keep the base protocol as simple as
   possible, and to require as few algorithms as possible.  However, all
   implementations MUST support a minimal set of algorithms to ensure
   interoperability (this does not imply that the local policy on all
   hosts would necessary allow these algorithms).  The mandatory
   algorithms are specified in the relevant protocol documents.

   Additional algorithms, methods, formats, and extension protocols can
   be defined in separate drafts.  See Section Algorithm Naming (Section
   6) for more information.

4.3 Policy Issues

   The protocol allows full negotiation of encryption, integrity, key
   exchange, compression, and public key algorithms and formats.
   Encryption, integrity, public key, and compression algorithms can be



Ylonen & Moffat          Expires March 31, 2004                 [Page 5]

Internet-Draft         SSH Protocol Architecture                Oct 2003


   different for each direction.

   The following policy issues SHOULD be addressed in the configuration
   mechanisms of each implementation:
   o  Encryption, integrity, and compression algorithms, separately for
      each direction.  The policy MUST specify which is the preferred
      algorithm (e.g. the first algorithm listed in each category).
   o  Public key algorithms and key exchange method to be used for host
      authentication.  The existence of trusted host keys for different
      public key algorithms also affects this choice.
   o  The authentication methods that are to be required by the server
      for each user.  The server's policy MAY require multiple
      authentication for some or all users.  The required algorithms MAY
      depend on the location where the user is trying to log in from.
   o  The operations that the user is allowed to perform using the
      connection protocol.  Some issues are related to security; for
      example, the policy SHOULD NOT allow the server to start sessions
      or run commands on the client machine, and MUST NOT allow
      connections to the authentication agent unless forwarding such
      connections has been requested.  Other issues, such as which TCP/
      IP ports can be forwarded and by whom, are clearly issues of local