The R13B03 release.OTP_R13B03

1 files changed, 896 insertions, 0 deletions

diff --git a/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt b/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt
new file mode 100644
index 0000000000..9dae578a35
--- /dev/null
+++ b/lib/ssh/doc/standard/draft-ietf-secsh-userauth-18.txt
@@ -0,0 +1,896 @@
+
+
+
+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]
\ No newline at end of file