doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc4252.txt b/doc/rfc/rfc4252.txt
new file mode 100644
index 0000000..ddb6146
--- /dev/null
+++ b/doc/rfc/rfc4252.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                          T. Ylonen
+Request for Comments: 4252              SSH Communications Security Corp
+Category: Standards Track                                C. Lonvick, Ed.
+                                                     Cisco Systems, Inc.
+                                                            January 2006
+
+
+             The Secure Shell (SSH) Authentication Protocol
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Secure Shell Protocol (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 & Lonvick            Standards Track                     [Page 1]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Contributors ....................................................3
+   3. Conventions Used in This Document ...............................3
+   4. The Authentication Protocol Framework ...........................4
+   5. Authentication Requests .........................................4
+      5.1. Responses to Authentication Requests .......................5
+      5.2. The "none" Authentication Request ..........................7
+      5.3. Completion of User Authentication ..........................7
+      5.4. Banner Message .............................................7
+   6. Authentication Protocol Message Numbers .........................8
+   7. Public Key Authentication Method: "publickey" ...................8
+   8. Password Authentication Method: "password" .....................10
+   9. Host-Based Authentication: "hostbased" .........................12
+   10. IANA Considerations ...........................................14
+   11. Security Considerations .......................................14
+   12. References ....................................................15
+      12.1. Normative References .....................................15
+      12.2. Informative References ...................................15
+   Authors' Addresses ................................................16
+   Trademark Notice ..................................................16
+
+1.  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.
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 2]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+2.  Contributors
+
+   The major original contributors of this set of documents have been:
+   Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH
+   Communications Security Corp), and Markku-Juhani O. Saarinen
+   (University of Jyvaskyla).  Darren Moffat was the original editor of
+   this set of documents and also made very substantial contributions.
+
+   Many people contributed to the development of this document over the
+   years.  People who should be acknowledged include Mats Andersson, Ben
+   Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller,
+   Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff
+   Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph
+   Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas
+   Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon
+   Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and
+   Tadayoshi Kohno.  Listing their names here does not mean that they
+   endorse this document, but that they have contributed to it.
+
+3.  Conventions Used in This Document
+
+   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.  These keywords are to be interpreted as described in
+   [RFC2119].
+
+   The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
+   FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
+   APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
+   this document when used to describe namespace allocation are to be
+   interpreted as described in [RFC2434].
+
+   Protocol fields and possible values to fill them are defined in this
+   set of documents.  Protocol fields will be defined in the message
+   definitions.  As an example, SSH_MSG_CHANNEL_DATA is defined as
+   follows.
+
+      byte      SSH_MSG_CHANNEL_DATA
+      uint32    recipient channel
+      string    data
+
+   Throughout these documents, when the fields are referenced, they will
+   appear within single quotes.  When values to fill those fields are
+   referenced, they will appear within double quotes.  Using the above
+   example, possible values for 'data' are "foo" and "bar".
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 3]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+4.  The Authentication Protocol Framework
+
+   The server drives the authentication by telling the client which
+   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 granted access
+   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.
+
+   Additional thoughts about authentication timeouts and retries may be
+   found in [ssh-1.2.30].
+
+5.  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 [RFC3629]
+      string    service name in US-ASCII
+      string    method name in US-ASCII
+      ....      method specific fields
+
+   The 'user name' and 'service name' 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
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 4]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+   flush an authentication state, it MUST disconnect if the 'user name'
+   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, authentication MUST NOT be accepted.
+
+   If the requested 'user name' does not exist, the server MAY
+   disconnect, or MAY send a bogus list of acceptable authentication
+   'method name' values, 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 name' 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
+   name' 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.
+
+   The following 'method name' values are defined.
+
+      "publickey"             REQUIRED
+      "password"              OPTIONAL
+      "hostbased"             OPTIONAL
+      "none"                  NOT RECOMMENDED
+
+   Additional 'method name' values may be defined as specified in
+   [SSH-ARCH] and [SSH-NUMBERS].
+
+5.1.  Responses to Authentication Requests
+
+   If the server rejects the authentication request, it MUST respond
+   with the following:
+
+      byte         SSH_MSG_USERAUTH_FAILURE
+      name-list    authentications that can continue
+      boolean      partial success
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 5]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+   The 'authentications that can continue' is a comma-separated name-
+   list of authentication 'method name' values that may productively
+   continue the authentication dialog.
+
+   It is RECOMMENDED that servers only include those 'method name'
+   values in the name-list that are actually useful.  However, it is not
+   illegal to include 'method name' values that cannot be used to
+   authenticate the user.
+
+   Already successfully completed authentications SHOULD NOT be included
+   in the name-list, unless they should be performed again for some
+   reason.
+
+   The value of '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:
+
+      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 requires further messages to be exchanged will be
+   aborted by a subsequent request.  A client MUST NOT send a subsequent
+   request if it has not received a response from the server for a
+   previous request.  A SSH_MSG_USERAUTH_FAILURE message MUST NOT be
+   sent for an 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 6).
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 6]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+5.2.  The "none" Authentication Request
+
+   A client may request a list of authentication 'method name' values
+   that may continue by using the "none" authentication 'method name'.
+
+   If no authentication 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 methods
+   that may continue in its 'authentications that can continue' value.
+
+   This 'method name' MUST NOT be listed as supported by the server.
+
+5.3.  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.
+
+5.4.  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,
+   use TCP wrappers, or similar software to display a banner before
+   issuing a login prompt.
+
+   The SSH server may send an SSH_MSG_USERAUTH_BANNER message at any
+   time after this authentication protocol starts and 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 in ISO-10646 UTF-8 encoding [RFC3629]
+      string    language tag [RFC3066]
+
+   By default, the client SHOULD 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, with line breaks indicated
+   by CRLF pairs.
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 7]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+   If the 'message' string is displayed, control character filtering,
+   discussed in [SSH-ARCH], SHOULD be used to avoid attacks by sending
+   terminal control characters.
+
+6.  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 to ease troubleshooting.
+
+   After successful authentication, such messages are passed to the
+   higher-level service.
+
+   These are the general authentication message codes:
+
+      SSH_MSG_USERAUTH_REQUEST            50
+      SSH_MSG_USERAUTH_FAILURE            51
+      SSH_MSG_USERAUTH_SUCCESS            52
+      SSH_MSG_USERAUTH_BANNER             53
+
+   In addition to the above, there is a range of message numbers (60 to
+   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.
+
+7.  Public Key Authentication Method: "publickey"
+
+   The only REQUIRED authentication 'method name' is "publickey"
+   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.
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 8]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+   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 "publickey" method would be acceptable.
+
+      byte      SSH_MSG_USERAUTH_REQUEST
+      string    user name in ISO-10646 UTF-8 encoding [RFC3629]
+      string    service name in US-ASCII
+      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
+   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 name
+      string    "publickey"
+      boolean   TRUE
+      string    public key algorithm name
+      string    public key to be used for authentication
+      string    signature
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 9]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+   The value of '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 name
+      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.
+
+      SSH_MSG_USERAUTH_PK_OK              60
+
+8.  Password Authentication Method: "password"
+
+   Password authentication uses the following packets.  Note that a
+   server MAY request that a user change the password.  All
+   implementations SHOULD support password authentication.
+
+      byte      SSH_MSG_USERAUTH_REQUEST
+      string    user name
+      string    service name
+      string    "password"
+      boolean   FALSE
+      string    plaintext password in ISO-10646 UTF-8 encoding [RFC3629]
+
+   Note that the 'plaintext password' value is encoded in ISO-10646
+   UTF-8.  It is up to the server how to interpret the password and
+   validate 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.
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 10]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+   From an internationalization standpoint, it is desired that if a user
+   enters their password, the authentication process will work
+   regardless of what OS and client software the user is using.  Doing
+   so requires normalization.  Systems supporting non-ASCII passwords
+   SHOULD always normalize passwords and user names whenever they are
+   added to the database, or compared (with or without hashing) to
+   existing entries in the database.  SSH implementations that both
+   store the passwords and compare them SHOULD use [RFC4013] for
+   normalization.
+
+   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 any case, the server MUST NOT allow an expired password to be used
+   for authentication.
+
+      byte      SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
+      string    prompt in ISO-10646 UTF-8 encoding [RFC3629]
+      string    language tag [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 name
+      string    "password"
+      boolean   TRUE
+      string    plaintext old password in ISO-10646 UTF-8 encoding
+                 [RFC3629]
+      string    plaintext new password in ISO-10646 UTF-8 encoding
+                 [RFC3629]
+
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 11]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+   The server must reply to each 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.
+
+      SSH_MSG_USERAUTH_PASSWD_CHANGEREQ   60
+
+9.  Host-Based Authentication: "hostbased"
+
+   Some sites wish to allow authentication based on the host that 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,
+   authorization (but no further authentication) is performed based on
+   the user names on the server and the client, and the client host
+   name.
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 12]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+      byte      SSH_MSG_USERAUTH_REQUEST
+      string    user name
+      string    service name
+      string    "hostbased"
+      string    public key algorithm for host key
+      string    public host key and certificates for client host
+      string    client host name expressed as the FQDN in US-ASCII
+      string    user name on the client host in ISO-10646 UTF-8 encoding
+                 [RFC3629]
+      string    signature
+
+   Public key algorithm names for use in 'public key algorithm for host
+   key' are defined in the transport layer specification [SSH-TRANS].
+   The 'public host key and certificates for client host' may include
+   certificates.
+
+   The value of '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 name
+      string    "hostbased"
+      string    public key algorithm for host key
+      string    public host key and certificates for client host
+      string    client host name expressed as the FQDN in US-ASCII
+      string    user name on the client host in ISO-10646 UTF-8 encoding
+                 [RFC3629]
+
+   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' value 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.
+
+   Whenever possible, it is RECOMMENDED that 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.
+
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 13]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+10.  IANA Considerations
+
+   This document is part of a set.  The IANA considerations for the SSH
+   protocol, as defined in [SSH-ARCH], [SSH-TRANS], [SSH-CONNECT], and
+   this document, are detailed in [SSH-NUMBERS].
+
+11.  Security Considerations
+
+   The purpose of this protocol is to perform client user
+   authentication.  It assumed that this runs over a secure transport
+   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
+   [SSH-ARCH].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 14]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+12.  References
+
+12.1.  Normative References
+
+   [SSH-ARCH]    Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+                 Protocol Architecture", RFC 4251, January 2006.
+
+   [SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+                 Connection Protocol", RFC 4254, January 2006.
+
+   [SSH-TRANS]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+                 Transport Layer Protocol", RFC 4253, January 2006.
+
+   [SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell
+                 (SSH) Protocol Assigned Numbers", RFC 4250, January
+                 2006.
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2434]     Narten, T. and H. Alvestrand, "Guidelines for Writing
+                 an IANA Considerations Section in RFCs", BCP 26, RFC
+                 2434, October 1998.
+
+   [RFC3066]     Alvestrand, H., "Tags for the Identification of
+                 Languages", BCP 47, RFC 3066, January 2001.
+
+   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
+                 10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4013]     Zeilenga, K., "SASLprep: Stringprep Profile for User
+                 Names and Passwords", RFC 4013, February 2005.
+
+12.2.  Informative References
+
+   [ssh-1.2.30]  Ylonen, T., "ssh-1.2.30/RFC", File within compressed
+                 tarball  ftp://ftp.funet.fi/pub/unix/security/login/
+                 ssh/ssh-1.2.30.tar.gz, November 1995.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 15]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+Authors' Addresses
+
+   Tatu Ylonen
+   SSH Communications Security Corp
+   Valimotie 17
+   00380 Helsinki
+   Finland
+
+   EMail: ylo@ssh.com
+
+
+   Chris Lonvick (editor)
+   Cisco Systems, Inc.
+   12515 Research Blvd.
+   Austin  78759
+   USA
+
+   EMail: clonvick@cisco.com
+
+Trademark Notice
+
+   "ssh" is a registered trademark in the United States and/or other
+   countries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 16]
+
+RFC 4252              SSH Authentication Protocol           January 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 17]
+