path: root/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt

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: [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 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
   SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method.

   SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When
   SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication
   requests received after that SHOULD be silently ignored.

   Any non-authentication messages sent by the client after the request
   that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed
   to the service being run on top of this protocol.  Such messages can
   be identified by their message numbers (see Section Message Numbers
   (Section 3.2)).

3.1.3 The "none" Authentication Request

   A client may request a list of authentication methods that may
   continue by using the "none" authentication method.

   If no authentication at all is needed for the user, the server MUST
   return SSH_MSG_USERAUTH_SUCCESS.  Otherwise, the server MUST return
   SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of
   authentication methods that can continue.

   This method MUST NOT be listed as supported by the server.

3.1.4 Completion of User Authentication

   Authentication is complete when the server has responded with
   SSH_MSG_USERAUTH_SUCCESS; all authentication related messages
   received after sending this message SHOULD be silently ignored.

   After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the
   requested service.




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


3.1.5 Banner Message

   In some jurisdictions, sending a warning message before
   authentication may be relevant for getting legal protection.  Many
   UNIX machines, for example, normally display text from `/etc/issue',
   or use "tcp wrappers" or similar software to display a banner before
   issuing a login prompt.

   The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time
   before authentication is successful.  This message contains text to
   be displayed to the client user before authentication is attempted.
   The format is as follows:

     byte      SSH_MSG_USERAUTH_BANNER
     string    message (ISO-10646 UTF-8)
     string    language tag (as defined in [RFC3066])

   The client SHOULD by default display the message on the screen.
   However, since the message is likely to be sent for every login
   attempt, and since some client software will need to open a separate
   window for this warning, the client software may allow the user to
   explicitly disable the display of banners from the server.  The
   message may consist of multiple lines.

   If the message string is displayed, control character filtering
   discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending
   terminal control characters.

3.2 Authentication Protocol Message Numbers

   All message numbers used by this authentication protocol are in the
   range from 50 to 79, which is part of the range reserved for
   protocols running on top of the SSH transport layer protocol.

   Message numbers of 80 and higher are reserved for protocols running
   after this authentication protocol, so receiving one of them before
   authentication is complete is an error, to which the server MUST
   respond by disconnecting (preferably with a proper disconnect message
   sent first to ease troubleshooting).

   After successful authentication, such messages are passed to the
   higher-level service.

   These are the general authentication message codes:

     #define SSH_MSG_USERAUTH_REQUEST            50
     #define SSH_MSG_USERAUTH_FAILURE            51
     #define SSH_MSG_USERAUTH_SUCCESS            52



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


     #define SSH_MSG_USERAUTH_BANNER             53

   In addition to the above, there is a range of message numbers
   (60..79) reserved for method-specific messages.  These messages are
   only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST
   messages). Different authentication methods reuse the same message
   numbers.

3.3 Public Key Authentication Method: publickey

   The only REQUIRED authentication method is public key authentication.
   All implementations MUST support this method; however, not all users
   need to have public keys, and most local policies are not likely to
   require public key authentication for all users in the near future.

   With this method, the possession of a private key serves as
   authentication.  This method works by sending a signature created
   with a private key of the user.  The server MUST check that the key
   is a valid authenticator for the user, and MUST check that the
   signature is valid.  If both hold, the authentication request MUST be
   accepted; otherwise it MUST be rejected.  (Note that the server MAY
   require additional authentications after successful authentication.)

   Private keys are often stored in an encrypted form at the client
   host, and the user must supply a passphrase before the signature can
   be generated. Even if they are not, the signing operation involves
   some expensive computation.  To avoid unnecessary processing and user
   interaction, the following message is provided for querying whether
   authentication using the key would be acceptable.

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service
     string    "publickey"
     boolean   FALSE
     string    public key algorithm name
     string    public key blob

   Public key algorithms are defined in the transport layer
   specification [SSH-TRANS]. The public key blob may contain
   certificates.

   Any public key algorithm may be offered for use in authentication.
   In particular, the list is not constrained by what was negotiated
   during key exchange.  If the server does not support some algorithm,
   it MUST simply reject the request.

   The server MUST respond to this message with either



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


   SSH_MSG_USERAUTH_FAILURE or with the following:

     byte      SSH_MSG_USERAUTH_PK_OK
     string    public key algorithm name from the request
     string    public key blob from the request

   To perform actual authentication, the client MAY then send a
   signature generated using the private key.  The client MAY send the
   signature directly without first verifying whether the key is
   acceptable. The signature is sent using the following packet:

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service
     string    "publickey"
     boolean   TRUE
     string    public key algorithm name
     string    public key to be used for authentication
     string    signature

   Signature is a signature by the corresponding private key over the
   following data, in the following order:

     string    session identifier
     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service
     string    "publickey"
     boolean   TRUE
     string    public key algorithm name
     string    public key to be used for authentication

   When the server receives this message, it MUST check whether the
   supplied key is acceptable for authentication, and if so, it MUST
   check whether the signature is correct.

   If both checks succeed, this method is successful.  Note that the
   server may require additional authentications.  The server MUST
   respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are
   needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more
   authentications are needed).

   The following method-specific message numbers are used by the
   publickey authentication method.

     /* Key-based */
     #define SSH_MSG_USERAUTH_PK_OK              60




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


3.4 Password Authentication Method: password

   Password authentication uses the following packets.  Note that a
   server MAY request the user to change the password.  All
   implementations SHOULD support password authentication.

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service
     string    "password"
     boolean   FALSE
     string    plaintext password (ISO-10646 UTF-8)

   Note that the password is encoded in ISO-10646 UTF-8.  It is up to
   the server how it interprets the password and validates it against
   the password database.  However, if the client reads the password in
   some other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert
   the password to ISO-10646 UTF-8 before transmitting, and the server
   MUST convert the password to the encoding used on that system for
   passwords.

   Note that even though the cleartext password is transmitted in the
   packet, the entire packet is encrypted by the transport layer.  Both
   the server and the client should check whether the underlying
   transport layer provides confidentiality (i.e., if encryption is
   being used).  If no confidentiality is provided (none cipher),
   password authentication SHOULD be disabled.  If there is no
   confidentiality or no MAC, password change SHOULD be disabled.

   Normally, the server responds to this message with success or
   failure. However, if the password has expired the server SHOULD
   indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.
   In anycase the server MUST NOT allow an expired password to be used
   for authentication.

     byte      SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
     string    prompt (ISO-10646 UTF-8)
     string    language tag (as defined in [RFC3066])

   In this case, the client MAY continue with a different authentication
   method, or request a new password from the user and retry password
   authentication using the following message. The client MAY also send
   this message instead of the normal password authentication request
   without the server asking for it.

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service



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


     string    "password"
     boolean   TRUE
     string    plaintext old password (ISO-10646 UTF-8)
     string    plaintext new password (ISO-10646 UTF-8)

   The server must reply to request message with
   SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another
   SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.  The meaning of these is as
   follows:

      SSH_MSG_USERAUTH_SUCCESS The password has been changed, and
      authentication has been successfully completed.

      SSH_MSG_USERAUTH_FAILURE with partial success The password has
      been changed, but more authentications are needed.

      SSH_MSG_USERAUTH_FAILURE without partial success The password has
      not been changed.  Either password changing was not supported, or
      the old password was bad.  Note that if the server has already
      sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports
      changing the password.

      SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because
      the new password was not acceptable (e.g. too easy to guess).

   The following method-specific message numbers are used by the
   password authentication method.

     #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ   60


3.5 Host-Based Authentication: hostbased

   Some sites wish to allow authentication based on the host where the
   user is coming from, and the user name on the remote host.  While
   this form of authentication is not suitable for high-security sites,
   it can be very convenient in many environments.  This form of
   authentication is OPTIONAL. When used, special care SHOULD be taken
   to prevent a regular user from obtaining the private host key.

   The client requests this form of authentication by sending the
   following message.  It is similar to the UNIX "rhosts" and
   "hosts.equiv" styles of authentication, except that the identity of
   the client host is checked more rigorously.

   This method works by having the client send a signature created with
   the private key of the client host, which the server checks with that
   host's public key.  Once the client host's identity is established,



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


   authorization (but no further authentication) is performed based on
   the user names on the server and the client, and the client host
   name.

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service
     string    "hostbased"
     string    public key algorithm for host key
     string    public host key and certificates for client host
     string    client host name (FQDN; US-ASCII)
     string    user name on the client host (ISO-10646 UTF-8)
     string    signature

   Public key algorithm names for use in "public key algorithm for host
   key" are defined in the transport layer specification.  The "public
   host key for client host" may include certificates.

   Signature is a signature with the private host key of the following
   data, in this order:

     string    session identifier
     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service
     string    "hostbased"
     string    public key algorithm for host key
     string    public host key and certificates for client host
     string    client host name (FQDN; US-ASCII)
     string    user name on the client host(ISO-10646 UTF-8)

   The server MUST verify that the host key actually belongs to the
   client host named in the message, that the given user on that host is
   allowed to log in, and that the signature is a valid signature on the
   appropriate value by the given host key.  The server MAY ignore the
   client user name, if it wants to authenticate only the client host.

   It is RECOMMENDED that whenever possible, the server perform
   additional checks to verify that the network address obtained from
   the (untrusted) network matches the given client host name.  This
   makes exploiting compromised host keys more difficult.  Note that
   this may require special handling for connections coming through a
   firewall.

4. Security Considerations

   The purpose of this protocol is to perform client user
   authentication. It assumed that this runs over a secure transport



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


   layer protocol, which has already authenticated the server machine,
   established an encrypted communications channel, and computed a
   unique session identifier for this session. The transport layer
   provides forward secrecy for password authentication and other
   methods that rely on secret data.

   Full security considerations for this protocol are provided in
   Section 8 of [SSH-ARCH]

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

   [RFC3066]  Alvestrand, H., "Tags for the Identification of
              Languages", BCP 47, RFC 3066, January 2001.

   [RFC2279]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", RFC 2279, January 1998.









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


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]

































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


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 (2002). 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          Expires March 2, 2003                 [Page 15]

Internet-Draft        SSH Authentication Protocol         September 2002


   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          Expires March 2, 2003                 [Page 16]