Network Working Group                           Tatu                                          T. Ylonen <ylo@ssh.fi>
INTERNET-DRAFT                               SSH Communications Security                                                T. Kivinen
draft-ietf-secsh-userauth-02.txt                             M. Saarinen
Expires in six months                                                SSH
                                                         14 October 1997

                      SSH Authentication Protocol

Status of This memo

This document is an Internet-Draft. 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.''

To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast),
or ftp.isi.edu (US West Coast).

Abstract

SSH is a protocol for secure remote login and other secure network ser-
vices over an insecure network.

This documents document describes the SSH authentication protocol.  It is used to
prove that the protocol framework and
public key, password, and host-based client is authorized authentication methods.
Additional authentication methods are deferred to access the requested service with
the supplied user name.  This authorization can be demonstrated through
possession of a password, through possession of a key, by authenticating separate documents.

The SSH authentication protocol runs on top the client host SSH transport layer
protocol and user, by some other method, or provides a combination of
these. single authenticated tunnel for the SSH
connection protocol.

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  User  The Authentication   . . . . . . . . . Protocol Framework   . . . . . . . . . . . . .  2
  2.1.  Authentication Requests   . . . . . . . . . . . . . . . . . .  3
  2.2.  Responses to Authentication Requests  . . . . . . . . . . . .  4  3
  2.3.  No  The none Authentication Request   . . . . . . . . . . . . . . . . . . . . .  5  4
  2.4.  Password  Completion of User Authentication   . . . . . . . . . . . . . . . . . .  5
  2.5.  Challenge-Response Authentication   . . . . . . . . . . . . .  6
  2.6.  SecurID Authentication  . . . . . . . . . . . . .  Banner Message  . . . . . .  6
  2.7.  Public Key Authentication . . . . . . . . . . . . . . . . .  7
  2.8.  Host-Based  5
3.  Authentication Protocol Message Numbers   . . . . . . . . . . . . . . . . .  9
  2.9.  Kerberos  5
4.  Public Key Authentication Method: publickey   . . . . . . . . . . . . . . . . . . 10
  2.10.  When  6
5.  Password Authentication Is Complete  . . . . . . . . . . Method: password  . . . . 11
3.  Banner Message . . . . . . . .  7
6.  Host-Based Authentication: hostbased  . . . . . . . . . . . . . .  9
7.  Security Considerations   . . . 11
4.  Message Numbers . . . . . . . . . . . . . . . . . 10
8.  References  . . . . . . . 11
5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 12
6. 10
9.  Author's Address of Author  . . . . . . . . . . . . . . . . . . . . . . . 12 . 10

1.  Introduction

This

The SSH authentication protocol is designed a general-purpose user authentication
protocol.  It is intended to be run over the SSH transport layer
protocol
using the same packet-based [SSH-TRANS].  This protocol as assumes that the transport layer.  The
service name is "ssh-userauth". underlying
protocols provide integrity and confidentiality protection.

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

Authentication works as follows: the client declares the

The service name,
and the user name under which to access this service.  The server
responds to this declaration with a set of acceptable authentication
methods for the given user/service combination.  The client then sends
an authentication request using one of the methods listed by the server.
This dialog continues until access has been granted, or until either the
client or the server disconnects. this protocol is "ssh-userauth".

When the authentication protocols this protocol starts, it receives the session identifier from the transport layer
lower-level protocol.  The session identifier uniquely identifies this
session and is suitable for signing to prove ownership of a private key.
This protocol also needs to know whether the lower-level protocol
provides confidentiality protection.

2.  User  The Authentication Protocol Framework

The server drives the authentication by telling the client which
authentications can usefully continue the dialog 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 ver over the authentication
process if it so 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 names.  Some methods are names, as defined in the protocol; additional methods may be defined using the
syntax "name@domainname" as the method name (for example,
"footoken@footoken.com").  This ensures that private extensions can be
implemented without breaking compatibility and without requiring a
central registry of method names.  Method names are case-sensitive, and
must consist of alphanumeric characters and hyphens.

The following methods are predefined:

          none                 Unsupported authentication method
          password             Password-based authentication
          securid              SecurID authentication
          otp-md4              One-time passwords using MD4 hashing
          otp-md5              One-time passwords using MD5 hashing
          otp-sha1             One-time passwords using SHA1 hashing
          publickey            Possession of private key
          hostbased            Client host and user (.rhosts-style)
          kerberos4            Kerberos v4 authentication
          kerberos5            Kerberos v5 authentication
          kerberos-afs         AFS Kerberos authentication [SSH-
ARCH].  The "none" method should never is reserved, and MUST NOT be listed as
supported.  However, it may MAY be sent by the client.  The server should MUST
always reject this request, unless the client is to be allowed in
without any authentication. 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.

There are no mandatory authentication methods; all methods are optional.
The motivation for this is that which methods to use is a matter of
local policy rather than protocol.  However, it is strongly recommended
that all implementations support at least "password" authentication.

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

2.1.  Authentication Requests

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

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

The username user name and service are repeated in every new authentication
attempt, and may MAY change.  The server implementation must MUST carefully check
them in every message, and must MUST flush any accumulated authentication
state if they change.

Service  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 MAY disconnect
immediately or any time later.  Sending a proper disconnect message is recommended.
RECOMMENDED.  In any case, if the service does not exist, authentication
MUST NOT be accepted.

If the requested user does not exist, the server is allowed to MAY disconnect, or may MAY
send a bogus list of acceptable authentications but never accept any.
This makes it possible for the server to avoid disclosing information
about 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 in for clients sending to send requests that
the server does not list as acceptable, sending such requests is not an
error, and the server should SHOULD simply reject requests that it does not
recognize.

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

2.2.  Responses to Authentication Requests

If the server rejects the authentication request, it responds MUST respond with

  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 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 SHOULD NOT be included in
the list list, unless they really should be performed again for some weird reason.

"Partial success" is TRUE MUST be true if the particular authentication request, in
response request to which
this is being sent, a response was accepted, but more
authentication is still needed. successful.  It is FALSE MUST be false if the request was
not successfully processed.

When the server accepts authentication, it responds MUST respond with

  byte      SSH_MSG_USERAUTH_SUCCESS

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

The client may MAY send several authentication requests without waiting for
responses from previous requests.  The server will MUST acknowledge any
failed requests with a SSH_SMSG_AUTH_FAILURE SSH_MSG_USERAUTH_FAILURE message.  However,
SSH_SMSG_AUTH_SUCCESS is
SSH_MSG_USERAUTH_SUCCESS MUST sent only once.

Once once, and once
SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication
requests received after that are SHOULD be silently ignored, while any non-
authentication ignored.

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

2.3.  No  The none Authentication Request

A client may request the a list of real authentication methods that may continue
by using the "none" authentication method.  This is actually an
authentication request: if

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

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

2.4.  Password  Completion of User Authentication

Password

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

After sending SSH_MSG_USERAUTH_SUCCESS, the following packets.  Note that server starts the requested
service.

2.5.  Banner Message

In some jurisdictions, sending a warning message before authentication
may be relevant to 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 request 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 to change password.

            byte      SSH_MSG_USERAUTH_REQUEST
            string    username
            string    service
            string    "password"
            boolean   FALSE
            string    plaintext password

            byte      SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
            string    prompt before authentication is attempted.  The
format is as follows.

  byte      SSH_MSG_USERAUTH_REQUEST
            string    username
            string    service
            string    "password"
            boolean   TRUE      SSH_MSG_USERAUTH_BANNER
  string    plaintext old password    message (ISO-10646 UTF-8)
  string    plaintext new password

            byte      SSH_MSG_USERAUTH_PASSWD_CHANGEREPLY
            boolean   password changed

Normally, the    language tag (as defined in RFC 1766)

The client sends the first form, and SHOULD by default display the server responds with
success or failure. message on the screen.
However, since the server may also send message is likely to be sent for every login attempt,
and since some client software will need to open a
SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.  In separate window for
this case, warning, the client should
request a new password from the user, and send a new request of software may allow the

second form user to change explicitly
disable the password. display of banners from the server.  The server will then reply with
SSH_MSG_USERAUTH_PASSWD_CHANGEREPLY. message may consist
of multiple lines.

If "password changed" is true, the
server will continue with either SSH_MSG_USERAUTH_SUCCESS or
SSH_MSG_USERAUTH_FAILURE.  Otherwise, the dialog continues and the
client can try changing the password again.

2.5.  Challenge-Response Authentication

Most challenge-response authentication methods use the following message
exchange:

            byte      SSH_MSG_USERAUTH_REQUEST
            string    username
            string    service
            string    method name
            boolean   FALSE

The server responds with either SSH_MSG_USERAUTH_FAILURE or

  byte      SSH_MSG_USERAUTH_CHALLENGE
  string    prompt

The client then responds with either a new authentication request or

            byte      SSH_MSG_USERAUTH_REQUEST string    username
            string    service
            string    method name
            boolean   TRUE
            string    response

The server responds is displayed, control character filtering
discussed in [SSH-ARCH] SHOULD be used to this avoid attacks by sending
terminal control characters.

3.  Authentication Protocol Message Numbers

All message with either success or failure.

The "otp-md4", "otp-md5" and "otp-sha1" methods numbers used by this authentication protocol are defined in RFC 1938,
and follow this pattern.

2.6.  SecurID Authentication

SecurID is a timing-based hardware token authenticator.  The user enters
a code displayed on the token as authentication.  There are different
versions
range 50..79, which is part of the SecurID tokens.  Some versions support changing range reserved for protocols running
on top of the PIN
(either to a server-supplied or user-supplied pin), SSH transport layer protocol.

Message numbers 80 and some might even
allow textual passphrases.

The method name higher are reserved for SecurID protocols running after
this authentication protocol, so receiving one of them before
authentication is "securid".  The following
packets are used:

            byte      SSH_MSG_USERAUTH_REQUEST
            string    username
            string    service
            string    "securid"
            boolean   is_new_pin
            string    pin
  byte      SSH_MSG_USERAUTH_SECURID_PINREQ
  boolean   user may supply
  string    suggested pin
  uint32    min len
  uint32    max len
  boolean   nondigits ok

            byte      SSH_MSG_USERAUTH_SECURID_PINREPLY
            boolean   pin accepted

Authentication starts by the client sending complete is an error, to which the SSH_MSG_USERAUTH_REQUEST
message with "is_new_pin" FALSE.  The server responds with
SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or MUST respond
by disconnecting (preferably with
SSH_MSG_USERAUTH_SECURID_PINREQ if it wants the user a proper disconnect message sent first
to ease troubleshooting).

After successful authentication, such messages are passed to change his/her
pincode.  In this message, "user may supply" is TRUE if the user may
choose higher-
level service.

These are the new pin, and FALSE if general authentication message codes:

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

In addition to the server-supplied pin (in "suggested
pin") must be used.  "Suggested pin" above, there is a new PIN suggested by the
server, but may also be empty.  "Min len" is the minimum length range of the
new pin, "max len" is the maximum length, and "nondigits ok" is TRUE if
characters other than digits message numbers (25..29)
reserved for method-specific messages.  These messages are allowed.

To change the pin, only sent by
the client continues with a new server (client only sends SSH_MSG_USERAUTH_REQUEST with "is_new_pin" TRUE and messages).
Different authentication methods reuse the new pin in
"pin".  The server responds to this same message with
SSH_MSG_USERAUTH_SECURID_PINREPLY (with "pin accepted" TRUE if the new
pin is now in effect, FALSE otherwise), followed by either
SSH_MSG_USERAUTH_SUCCESS or SSH_MSG_USERAUTH_FAILURE.  Note that some
versions of SecurID do not permit the user in if the pin was changed.

2.7. numbers.

4.  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 near future.

With this method, the possession of a private key can serve serves as
authentication.  This method works by sending a signature created with the a
private key of the
user, which the user.  The server checks with MUST check that the client user's public key.

Private keys are often stored encrypted at key is a valid
authenticator for the client host, user, and MUST check that the user
must supply 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 encrypted 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 needing to supply passphrases when it is not necessary, unnecessary processing and user interaction, the client
can optionally verify following
message is provided for querying whether a particular authentication using the key
would be acceptable as
authentication.  This is done with the following message. acceptable.

  byte      SSH_MSG_USERAUTH_REQUEST
  string    username    user name
  string    service
  string    "publickey"
  boolean   FALSE
  string    public key algorithm name
  string    public key to be used for authentication blob

Public key algorithms are defined in the transport layer specification. specification
[SSH-TRANS].  The "public public key to be used for authentication" blob may include 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 (as that was affected by which algorithms the server had a
host key).  If the server does not support some algorithm, it MUST
simply reject the request.

The server will MUST respond to this message with either
SSH_MSG_USERAUTH_FAILURE or with

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

To do actual authentication, the client should MAY then send a signature
generated using the private key.  It is permissible to  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    username    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 of the HASH
of the concatenation of over the following,
following data, in this order:

o  session identifier (which binds the signature to the server host key
   and the particular key exchange),

o  length of the user name as a 32-bit integer, msb first,

o  user name (without length or null characters),

o  length of the service name as a 32-bit integer, msb first,

o  service name (without length or null characters),

o  length of the public key algorithm name as a 32-bit integer, msb
   first,

o  public key algorithm name (without length or null characters),

o  length of the public key from the message as a 32-bit integer, msb
   first, identifier, and

o  public key from  packet payload without the message (without length or null characters). signature.

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

If both checks succeed, authentication may be granted (the this method is successful.  Note that the server
may
also require further authentication additional authentications.  The server MUST respond with other methods, without letting
SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or
SSH_MSG_USERAUTH_FAILURE (if the client know at this point that authentication has partially
succeeded).

2.8.  Host-Based Authentication

Some sites wish to allow request failed, or more authentications
are needed).

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

  /* Key-based */
  #define SSH_MSG_USERAUTH_PK_OK              60

5.  Password Authentication Method: password

Password authentication uses the host where following packets.  Note that a server
MAY request the user
is coming from and the to change password.  All implementations SHOULD
support password authentication.

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

Note that the remote host.  While this form of
authentication password is not suitable for high-security sites, it can be very
convenient encoded in many environments.  The client requests this form of
authentication by sending the following message. ISO-10646 UTF-8.  It is rather similar up to the Unix "rhosts" and "hosts.equiv" styles of authentication, except
that
server how it interprets the identity of password and validates it against the client host is checked more rigorously.

This method works by having
password database.  However, if the client send a signature created with reads the
private key of password in some
other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert the client host, which
password to ISO-10646 UTF-8 before transmitting, and the server checks with MUST
convert the password to the encoding used on that host's
public key.  Once system for passwords.

Note that even though the client host's identity cleartext password is established,
authorization, but no further authentication, transmitted in the
packet, the entire packet is performed based on encrypted by the
usernames on transport layer.  Both the
server and client, and the client host name.

            byte      SSH_MSG_USERAUTH_REQUEST
            string    username
            string    service
            string    "hostbased"
            string    public key algorithm for host key
            string    public host key for client host
            string    client host name
            string    client user name
            string    signature

Public key algorithm names for use in "public key algorithm for host
key" are defined in should check whether the underlying transport
layer specification.  The "public host
key for client host" may include certificates.
Signature provides confidentiality (i.e., encryption is a signature with the private host key for the client host
of the HASH (where the hash algorithm being used).  If no
confidentiality is from the transport layer) of
the concatenation of the following, in this order:

o  session identifier (which binds the signature to provided ("none" cipher), password authentication
SHOULD be disabled.  If there is no confidentiality or no MAC, password
change SHOULD be disabled.

Normally, the server host key
   and the particular key exchange),

o  length of the user name as a 32-bit integer, msb first,

o  user name (without length responds to this message with success or null characters),

o  length of failure.
However, the service name as a 32-bit integer, msb first,

o  service name (without length or null characters),

o  length of server MAY also respond with
SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.

  byte      SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
  string    prompt (ISO-10646 UTF-8)
  string    language tag (as defined in RFC 1766)

In this case, the public host key algorithm name as software client SHOULD request a 32-bit integer, msb
   first,

o  public host key algorithm name (without length or null characters),

o  length of the public host key new password from the message as
user, and send a 32-bit integer,
   msb first,

o  public host key from new request using the following message.  The client
may also send this message (without length or null characters),

o  length instead of the client host name as a 32-bit integer, msb first,

o  client host name (without length or null characters),

o  length of normal password authentication
request without the client server asking for it.

  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service
  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 a 32-bit integer, msb first, follows:

    SSH_MSG_USERAUTH_SUCCESS
      Password has been changed, and

o  client user name (without length 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 null characters).

Authentication is accepted the old password was bad.  Note that if the
      server can verify has already sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know
      that it supports changing the host key
actually belongs to the client host named in password.

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

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

  #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ   60

6.  Host-Based Authentication: hostbased

Some sites wish to allow authentication based on that the host where the user
is allowed to log in, coming from and the signature is a valid
signature user name on the appropriate value by 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 given private host key.  (The server
The client requests this form of authentication by sending the following
message.  It is also allowed similar to ignore the client user name, if it wants to
authenticate only UNIX "rhosts" and "hosts.equiv" styles of
authentication, except that the identity of the client host.)

It host is recommended that whenever possible, 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 perform additional checks to verify with that host's
public key.  Once the network address obtained from client host's identity is established,
authorization, but no further authentication, is performed based on the (untrusted)
network matches
user names on the server and client, and the given client host name.  This makes exploiting
compromised

  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service
  string    "hostbased"
  string    public key algorithm for host keys more difficult.  Note that this may require
special handling key
  string    public host key and certificates for connections coming through a firewall.

2.9.  Kerberos Authentication

There are several ways to authenticate the user using Kerberos (OSF DCE
and AFS are also incarnations of Kerberos).  Different versions of
Kerberos (v4, v5, DCE, and AFS) have different capabilities.  Separate
messages have been defined for each of these.  In each case, the server
should respond with success or failure.

            byte      SSH_MSG_USERAUTH_REQUEST
            string    username
            string    service
            string    "kerberos4"
            string    kerberos v4 credentials

            byte      SSH_MSG_USERAUTH_REQUEST
            string    username
            string    service
            string    "kerberos5"
            string    kerberos v5 credentials
            string    kerberos v5 ticket granting ticket (may be empty)

            byte      SSH_MSG_USERAUTH_REQUEST
            string    username
            string    service
            string    "kerberos-afs" client host
  string    AFS token

The Kerberos authentication requests should be sent before other
authentication requests.  The other authentication methods may need to
access files from the user's home directory, which may not be accessible
until e.g. the AFS token has been passed.  Note that even if these
requests fail, they may have side effects, such as making the home

directory accessible.

2.10.  When Authentication Is Complete

Authentication is complete when the server has responded with
SSH_MSG_USERAUTH_SUCCESS; any SSH_MSG_USERAUTH_REQUEST messages received
after sending this message are silently ignored.

When sending SSH_MSG_USERAUTH_SUCCESS, the server also starts whatever
application was requested as the service.  Any non-authentication
messages received after this point are passed to the requested service.

3.  Banner Message

In some jurisdictions, sending a warning message before authentication
may be relevant to getting legal protection.  Many Unix machines, for
example, 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
form is as follows, where "message" may contain newlines:

            byte      SSH_MSG_USERAUTH_BANNER host name (FQDN; US-ASCII)
  string    message

The    client should by default display the message user name on the screen.
However, since the message is likely to be sent remote host (ISO-10646 UTF-8)
  string    signature

Public key algorithm names for every login attempt,
and since some client software will need to open a separate window use in "public key algorithm for
this warning, the client software may allow the user to explicitly
disable the display of banners from the server.

4.  Message Numbers

All message numbers used by this authentication protocol host
key" are defined in the
range 20..29, which transport layer specification.  The "public host
key for client host" may include certificates.

Signature is part of a signature with the range reserved for protocols running
on top private host key of the SSH transport layer protocol.

Message numbers 30 and higher are reserved for protocols running after following
data, in this authentication protocol, so receiving one of them before
authentication is complete is an error, to which order:

o  session identifier, and

o  packet payload without the signature.

The server must respond
by disconnecting (preferably with a proper disconnect sent first to ease
troubleshooting).

After successful authentication, such messages are passed MUST verify that the host key actually belongs to the higher-
level service.

These are client
host named in the general authentication message codes:

#define SSH_MSG_USERAUTH_REQUEST            20
#define SSH_MSG_USERAUTH_FAILURE            21
#define SSH_MSG_USERAUTH_SUCCESS            22

#define SSH_MSG_USERAUTH_BANNER             23

In addition message, that the given user on that host is allowed
to log in, and that the above, there signature is a range of message numbers (25..29)
reserved for method-specific messages.  These messages are only sent valid signature on the
appropriate value by the given host key.  The server (client MAY ignore the

client user name, if it wants to authenticate only sends SSH_MSG_USERAUTH_REQUEST messages).
Differnet authentication methods reuse the same message numbers.

/* Password */
#define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ   25
#define SSH_MSG_USERAUTH_PASSWD_CHANGEREPLY 26
/* Key-based */
#define SSH_MSG_USERAUTH_PK_OK              25
/* One-time passwords */
#define SSH_MSG_USERAUTH_CHALLENGE          25
/* SecurID */
#define SSH_MSG_USERAUTH_SECURID_PINREQ     25
#define SSH_MSG_USERAUTH_SECURID_PINREPLY   26

5. 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.

7.  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.

If the transport layer does not provide encryption, authentication
methods that rely on secret data SHOULD be disabled.  If it does not
provide MAC protection, requests to change authentication data (e.g.
password change) SHOULD be disabled to avoid an attacker from modifying
the ciphertext without being noticed, rendering the new authentication
data unusable (denial of service).

Several authentication methods with different security characteristics
are allowed.  It is up to the server's local policy to decide which
methods (or combinations of methods) it is willing to accept for each
user.

6.  Address  Authentication is no stronger than the weakest combination
allowed.

Special care should be taken when designing debug messages. These
messages may reveal surprising amounts of Author information about the host if
not properly designed. Debug messages can be disabled (during user
authentication phase) if high security is sought after.

8.  References

[RFC-1766] Alvestrand, H., "Tags for the Identification of Languages",
March 1995.

[RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and
ISO 10646", October 1996.

[SSH-ARCH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Protocol
Architecture", Internet Draft, draft-secsh-architecture-00.txt

[SSH-TRANS] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Transport
Layer Protocol", Internet Draft, draft-secsh-transport-02.txt

[SSH-CONNECT] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Connection
Protocol", Internet Draft, draft-secsh-connect-02.txt

9.  Author's Address

    Tatu Ylonen
    SSH Communications Security Ltd.
    Tekniikantie 12
    FIN-02150 ESPOO
    Finland
    E-mail: ylo@ssh.fi

    Tero Kivinen
    SSH Communications Security Ltd.
    Tekniikantie 12
    FIN-02150 ESPOO
    Finland
    E-mail: kivinen@ssh.fi

    Markku-Juhani O. Saarinen
    SSH Communications Security Ltd.
    Tekniikantie 12
    FIN-02150 ESPOO
    Finland
    E-mail: mjos@ssh.fi