draft-ietf-secsh-userauth-18.txt

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

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


                      SSH Authentication Protocol
                    draft-ietf-secsh-userauth-18.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 2, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002). 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
   authentication protocol framework and public key, password, and
   host-based client authentication methods. Additional authentication
   methods are described in separate documents. The SSH authentication
   protocol runs on top of the SSH transport layer protocol and provides
   a single authenticated tunnel for the SSH connection protocol.







Ylonen & Moffat          Expires March 2, 2003                  [Page 1]

Internet-Draft        SSH Authentication Protocol         September 2002


Table of Contents

   1.    Contributors . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.    Conventions Used in This Document  . . . . . . . . . . . . .  3
   3.1   The Authentication Protocol Framework  . . . . . . . . . . .  3
   3.1.1 Authentication Requests  . . . . . . . . . . . . . . . . . .  4
   3.1.2 Responses to Authentication Requests . . . . . . . . . . . .  5
   3.1.3 The "none" Authentication Request  . . . . . . . . . . . . .  6
   3.1.4 Completion of User Authentication  . . . . . . . . . . . . .  6
   3.1.5 Banner Message . . . . . . . . . . . . . . . . . . . . . . .  7
   3.2   Authentication Protocol Message Numbers  . . . . . . . . . .  7
   3.3   Public Key Authentication Method: publickey  . . . . . . . .  8
   3.4   Password Authentication Method: password . . . . . . . . . . 10
   3.5   Host-Based Authentication: hostbased . . . . . . . . . . . . 11
   4.    Security Considerations  . . . . . . . . . . . . . . . . . . 12
         Normative  . . . . . . . . . . . . . . . . . . . . . . . . . 13
         Informative  . . . . . . . . . . . . . . . . . . . . . . . . 13
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
         Intellectual Property and Copyright Statements . . . . . . . 15































Ylonen & Moffat          Expires March 2, 2003                  [Page 2]

Internet-Draft        SSH Authentication Protocol         September 2002


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 authentication protocol is a general-purpose user
   authentication protocol. It is intended to be run over the SSH
   transport layer protocol [SSH-TRANS]. This protocol assumes that the
   underlying protocols provide integrity and confidentiality
   protection.

   This document should be read only after reading the SSH architecture
   document [SSH-ARCH]. This document freely uses terminology and
   notation from the architecture document without reference or further
   explanation.

   The service name for this protocol is "ssh-userauth".

   When this protocol starts, it receives the session identifier from
   the lower-level protocol (this is the exchange hash H from the first
   key exchange). The session identifier uniquely identifies this
   session and is suitable for signing in order to prove ownership of a
   private key. This protocol also needs to know whether the lower-level
   protocol provides confidentiality protection.

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.

3.1 The Authentication Protocol Framework

   The server drives the authentication by telling the client which



Ylonen & Moffat          Expires March 2, 2003                  [Page 3]

Internet-Draft        SSH Authentication Protocol         September 2002


   authentication methods can be used to continue the exchange at any
   given time. The client has the freedom to try the methods listed by
   the server in any order. This gives the server complete control over
   the authentication process if desired, but also gives enough
   flexibility for the client to use the methods it supports or that are
   most convenient for the user, when multiple methods are offered by
   the server.

   Authentication methods are identified by their name, as defined in
   [SSH-ARCH].  The "none" method is reserved, and MUST NOT be listed as
   supported.  However, it MAY be sent by the client.  The server MUST
   always reject this request, unless the client is to be allowed in
   without any authentication, in which case the server MUST accept this
   request.  The main purpose of sending this request is to get the list
   of supported methods from the server.

   The server SHOULD have a timeout for authentication, and disconnect
   if the authentication has not been accepted within the timeout
   period. The RECOMMENDED timeout period is 10 minutes.  Additionally,
   the implementation SHOULD limit the number of failed authentication
   attempts a client may perform in a single session (the RECOMMENDED
   limit is 20 attempts).  If the threshold is exceeded, the server
   SHOULD disconnect.

3.1.1 Authentication Requests

   All authentication requests MUST use the following message format.
   Only the first few fields are defined; the remaining fields depend on
   the authentication method.

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name (in ISO-10646 UTF-8 encoding [RFC2279])
     string    service name (in US-ASCII)
     string    method name (US-ASCII)
     The rest of the packet is method-specific.

   The user name and service are repeated in every new authentication
   attempt, and MAY change.  The server implementation MUST carefully
   check them in every message, and MUST flush any accumulated
   authentication states if they change.  If it is unable to flush some
   authentication state, it MUST disconnect if the user or service name
   changes.

   The service name specifies the service to start after authentication.
   There may be several different authenticated services provided.  If
   the requested service is not available, the server MAY disconnect
   immediately or at any later time.  Sending a proper disconnect
   message is RECOMMENDED.  In any case, if the service does not exist,



Ylonen & Moffat          Expires March 2, 2003                  [Page 4]

Internet-Draft        SSH Authentication Protocol         September 2002


   authentication MUST NOT be accepted.

   If the requested user does not exist, the server MAY disconnect, or
   MAY send a bogus list of acceptable authentication methods, but never
   accept any.  This makes it possible for the server to avoid
   disclosing information on which accounts exist.  In any case, if the
   user does not exist, the authentication request MUST NOT be accepted.

   While there is usually little point for clients to send requests that
   the server does not list as acceptable, sending such requests is not
   an error, and the server SHOULD simply reject requests that it does
   not recognize.

   An authentication request MAY result in a further exchange of
   messages.  All such messages depend on the authentication method
   used, and the client MAY at any time continue with a new
   SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST
   abandon the previous authentication attempt and continue with the new
   one.

3.1.2 Responses to Authentication Requests

   If the server rejects the authentication request, it MUST respond
   with the following:

     byte      SSH_MSG_USERAUTH_FAILURE
     string    authentications that can continue
     boolean   partial success

   "Authentications that can continue" is a comma-separated list of
   authentication method names that may productively continue the
   authentication dialog.

   It is RECOMMENDED that servers only include those methods in the list
   that are actually useful.  However, it is not illegal to include
   methods that cannot be used to authenticate the user.

   Already successfully completed authentications SHOULD NOT be included
   in the list, unless they really should be performed again for some
   reason.

   "Partial success" MUST be TRUE if the authentication request to which
   this is a response was successful.  It MUST be FALSE if the request
   was not successfully processed.

   When the server accepts authentication, it MUST respond with the
   following:




Ylonen & Moffat          Expires March 2, 2003                  [Page 5]

Internet-Draft        SSH Authentication Protocol         September 2002


     byte      SSH_MSG_USERAUTH_SUCCESS

   Note that this is not sent after each step in a multi-method
   authentication sequence, but only when the authentication is
   complete.

   The client MAY send several authentication requests without waiting
   for responses from previous requests.  The server MUST process each
   request completely and acknowledge any failed requests with a
   SSH_MSG_USERAUTH_FAILURE message before processing the next request.

   A request that results in further exchange of messages will be
   aborted by a second request. It is not possible to send a second
   request without waiting for a response from the server, if the first
   request will result in further exchange of messages.  No