draft-ietf-secsh-userauth-07.txt   draft-ietf-secsh-userauth-08.txt 
Network Working Group T. Ylonen Network Working Group T. Ylonen
INTERNET-DRAFT T. Kivinen INTERNET-DRAFT T. Kivinen
draft-ietf-secsh-userauth-07.txt M. Saarinen draft-ietf-secsh-userauth-08.txt M. Saarinen
Expires in six months T. Rinne Expires in six months T. Rinne
S. Lehtinen S. Lehtinen
SSH Communications Security SSH Communications Security
11 May 2000 21 Nov, 2000
SSH Authentication Protocol SSH Authentication Protocol
Status of This memo Status of This memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
SSH is a protocol for secure remote login and other secure network ser- SSH is a protocol for secure remote login and other secure network ser-
vices over an insecure network. This document describes the SSH authen- vices over an insecure network. This document describes the SSH authen-
tication protocol framework and public key, password, and host-based tication protocol framework and public key, password, and host-based
client authentication methods. Additional authentication methods are client authentication methods. Additional authentication methods are
deferred to separate documents. The SSH authentication protocol runs on described in separate documents. The SSH authentication protocol runs
top the SSH transport layer protocol and provides a single authenticated on top of the SSH transport layer protocol and provides a single authen-
tunnel for the SSH connection protocol. ticated tunnel for the SSH connection protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Authentication Protocol Framework . . . . . . . . . . . . . 2 2. The Authentication Protocol Framework . . . . . . . . . . . . . 2
2.1. Authentication Requests . . . . . . . . . . . . . . . . . . 3 2.1. Authentication Requests . . . . . . . . . . . . . . . . . . 3
2.2. Responses to Authentication Requests . . . . . . . . . . . . 4 2.2. Responses to Authentication Requests . . . . . . . . . . . . 4
2.3. The none Authentication Request . . . . . . . . . . . . . . 4 2.3. The "none" Authentication Request . . . . . . . . . . . . . 4
2.4. Completion of User Authentication . . . . . . . . . . . . . 5 2.4. Completion of User Authentication . . . . . . . . . . . . . 5
2.5. Banner Message . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Banner Message . . . . . . . . . . . . . . . . . . . . . . . 5
3. Authentication Protocol Message Numbers . . . . . . . . . . . . 5 3. Authentication Protocol Message Numbers . . . . . . . . . . . . 5
4. Public Key Authentication Method: publickey . . . . . . . . . . 6 4. Public Key Authentication Method: publickey . . . . . . . . . . 6
5. Password Authentication Method: password . . . . . . . . . . . . 7 5. Password Authentication Method: password . . . . . . . . . . . . 7
6. Host-Based Authentication: hostbased . . . . . . . . . . . . . . 9 6. Host-Based Authentication: hostbased . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10
8. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The SSH authentication protocol is a general-purpose user authentication The SSH authentication protocol is a general-purpose user authentication
protocol. It is intended to be run over the SSH transport layer protocol protocol. It is intended to be run over the SSH transport layer protocol
[SSH-TRANS]. This protocol assumes that the underlying protocols provide [SSH-TRANS]. This protocol assumes that the underlying protocols provide
integrity and confidentiality protection. integrity and confidentiality protection.
This document should be read only after reading the SSH architecture This document should be read only after reading the SSH architecture
document [SSH-ARCH]. This document freely uses terminology and notation document [SSH-ARCH]. This document freely uses terminology and notation
from the architecture document without reference or further explanation. from the architecture document without reference or further explanation.
The service name for this protocol is "ssh-userauth". The service name for this protocol is "ssh-userauth".
When this protocol starts, it receives the session identifier from the When this protocol starts, it receives the session identifier from the
lower-level protocol. The session identifier uniquely identifies this lower-level protocol (this is the exchange hash H from the first key
session and is suitable for signing to prove ownership of a private 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 This protocol also needs to know whether the lower-level protocol
provides confidentiality protection. provides confidentiality protection.
2. The Authentication Protocol Framework 2. The Authentication Protocol Framework
The server drives the authentication by telling the client which The server drives the authentication by telling the client which
authentications can usefully continue the dialog at any given time. The authentication methods can be used to continue the exchange at any given
client has the freedom to try the methods listed by the server in any time. The client has the freedom to try the methods listed by the server
order. This gives the server complete control over the authentication in any order. This gives the server complete control over the
process if it so desired, but also gives enough flexibility for the authentication process if desired, but also gives enough flexibility for
client to use the methods it supports or that are most convenient for the client to use the methods it supports or that are most convenient
the user when multiple methods are offered by the server. for the user, when multiple methods are offered by the server.
Authentication methods are identified by names, as defined in [SSH- Authentication methods are identified by their name, as defined in [SSH-
ARCH]. The "none" method is reserved, and MUST NOT be listed as ARCH]. The "none" method is reserved, and MUST NOT be listed as
supported. However, it MAY be sent by the client. The server MUST supported. However, it MAY be sent by the client. The server MUST
always reject this request, unless the client is to be allowed in
always reject this request, unless the client is to be allowed in
without any authentication, in which case the server MUST accept this 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 request. The main purpose of sending this request is to get the list of
supported methods from the server. supported methods from the server.
The server SHOULD have a timeout for authentication, and disconnect if The server SHOULD have a timeout for authentication, and disconnect if
the authentication has not been accepted within the timeout period. The the authentication has not been accepted within the timeout period. The
RECOMMENDED timeout period is 10 minutes. Additionally, the RECOMMENDED timeout period is 10 minutes. Additionally, the
implementation SHOULD limit the number of failed authentication attempts implementation SHOULD limit the number of failed authentication attempts
a client may perform in a single session (the RECOMMENDED limit is 20 a client may perform in a single session (the RECOMMENDED limit is 20
attempts). If the threshold is exceeded, the server SHOULD disconnect. attempts). If the threshold is exceeded, the server SHOULD disconnect.
skipping to change at page 3, line 26 skipping to change at page 3, line 27
2.1. Authentication Requests 2.1. Authentication Requests
All authentication requests MUST use the following message format. Only All authentication requests MUST use the following message format. Only
the first few fields are defined; the remaining fields depend on the the first few fields are defined; the remaining fields depend on the
authentication method. authentication method.
byte SSH_MSG_USERAUTH_REQUEST byte SSH_MSG_USERAUTH_REQUEST
string user name (in ISO-10646 UTF-8 encoding) string user name (in ISO-10646 UTF-8 encoding)
string service name (in US-ASCII) string service name (in US-ASCII)
string method name (US-ASCII) string method name (US-ASCII)
rest of the packet is method-specific The rest of the packet is method-specific.
The user name and service are repeated in every new authentication The user name and service are repeated in every new authentication
attempt, and MAY change. The server implementation MUST carefully check attempt, and MAY change. The server implementation MUST carefully check
them in every message, and MUST flush any accumulated authentication them in every message, and MUST flush any accumulated authentication
state if they change. If it is unable to flush some authentication states if they change. If it is unable to flush some authentication
state, it MUST disconnect if the user or service name changes. state, it MUST disconnect if the user or service name changes.
The service name specifies the service to start after authentication. The service name specifies the service to start after authentication.
There may be several different authenticated services provided. If the There may be several different authenticated services provided. If the
requested service is not available, the server MAY disconnect requested service is not available, the server MAY disconnect
immediately or any time later. Sending a proper disconnect message is immediately or at any later time. Sending a proper disconnect message
RECOMMENDED. In any case, if the service does not exist, authentication is RECOMMENDED. In any case, if the service does not exist,
MUST NOT be accepted. authentication MUST NOT be accepted.
If the requested user does not exist, the server MAY disconnect, or MAY If the requested user does not exist, the server MAY disconnect, or MAY
send a bogus list of acceptable authentications but never accept any. send a bogus list of acceptable authentication methods, but never accept
This makes it possible for the server to avoid disclosing information any. This makes it possible for the server to avoid disclosing
about which accounts exist. In any case, if the user does not exist, information on which accounts exist. In any case, if the user does not
the authentication request MUST NOT be accepted. exist, the authentication request MUST NOT be accepted.
While there is usually little point for clients to send requests that 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 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 error, and the server SHOULD simply reject requests that it does not
recognize. recognize.
An authentication request MAY result in a further exchange of messages. An authentication request MAY result in a further exchange of messages.
All such messages depend on the authentication method used, and the All such messages depend on the authentication method used, and the
client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST
message, in which case the server MUST abandon the previous message, in which case the server MUST abandon the previous
authentication attempt and continue with the new one. authentication attempt and continue with the new one.
2.2. Responses to Authentication Requests 2.2. Responses to Authentication Requests
If the server rejects the authentication request, it MUST respond with If the server rejects the authentication request, it MUST respond with
the following:
byte SSH_MSG_USERAUTH_FAILURE byte SSH_MSG_USERAUTH_FAILURE
string authentications that can continue string authentications that can continue
boolean partial success boolean partial success
"Authentications that can continue" is a comma-separated list of "Authentications that can continue" is a comma-separated list of
authentication method names that may productively continue the authentication method names that may productively continue the
authentication dialog. authentication dialog.
It is RECOMMENDED that servers only include those methods in the list 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 are actually useful. However, it is not illegal to include methods
that cannot be used to authenticate the user. that cannot be used to authenticate the user.
Already successfully completed authentications SHOULD NOT be included in Already successfully completed authentications SHOULD NOT be included in
the list, unless they really should be performed again for some reason. the list, unless they really should be performed again for some reason.
"Partial success" MUST be true if the authentication request to which "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 this is a response was successful. It MUST be FALSE if the request was
not successfully processed. not successfully processed.
When the server accepts authentication, it MUST respond with When the server accepts authentication, it MUST respond with the
following:
byte SSH_MSG_USERAUTH_SUCCESS byte SSH_MSG_USERAUTH_SUCCESS
Note that this is not sent after each step in a multi-method authentica- Note that this is not sent after each step in a multi-method
tion sequence, but only when authentication is complete. authentication sequence, but only when the authentication is complete.
The client MAY send several authentication requests without waiting for The client MAY send several authentication requests without waiting for
responses from previous requests. The server MUST acknowledge any responses from previous requests. The server MUST acknowledge any
failed requests with a SSH_MSG_USERAUTH_FAILURE message. However, failed requests with a SSH_MSG_USERAUTH_FAILURE message. However,
SSH_MSG_USERAUTH_SUCCESS MUST sent only once, and once SSH_MSG_USERAUTH_SUCCESS MUST be sent only once, and once
SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication
requests received after that SHOULD be silently ignored. requests received after that SHOULD be silently ignored.
Any non-authentication messages sent by the client after the request Any non-authentication messages sent by the client after the request
that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed to 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 the service being run on top of this protocol. Such messages can be
identified by their message numbers (see Section ``Message Numbers''). identified by their message numbers (see Section ``Message Numbers'').
2.3. The none Authentication Request 2.3. The "none" Authentication Request
A client may request a list of authentication methods that may continue A client may request a list of authentication methods that may continue
by using the "none" authentication method. by using the "none" authentication method.
If no authentication at all is needed for the user, the server MUST If no authentication at all is needed for the user, the server MUST
return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return
SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of authentication SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of authentication
methods that can continue. methods that can continue.
This method MUST NOT be listed as supported by the server. This method MUST NOT be listed as supported by the server.
skipping to change at page 5, line 17 skipping to change at page 5, line 19
Authentication is complete when the server has responded with Authentication is complete when the server has responded with
SSH_MSG_USERAUTH_SUCCESS; all authentication related messages received SSH_MSG_USERAUTH_SUCCESS; all authentication related messages received
after sending this message SHOULD be silently ignored. after sending this message SHOULD be silently ignored.
After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the requested After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the requested
service. service.
2.5. Banner Message 2.5. Banner Message
In some jurisdictions, sending a warning message before authentication In some jurisdictions, sending a warning message before authentication
may be relevant to getting legal protection. Many UNIX machines, for may be relevant for getting legal protection. Many UNIX machines, for
example, normally display text from /etc/issue, or use "tcp wrappers" or example, normally display text from `/etc/issue', or use "tcp wrappers"
similar software to display a banner before issuing a login prompt. 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 The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time
before authentication is successful. This message contains text to be before authentication is successful. This message contains text to be
displayed to the client user before authentication is attempted. The displayed to the client user before authentication is attempted. The
format is as follows. format is as follows:
byte SSH_MSG_USERAUTH_BANNER byte SSH_MSG_USERAUTH_BANNER
string message (ISO-10646 UTF-8) string message (ISO-10646 UTF-8)
string language tag (as defined in RFC 1766) string language tag (as defined in RFC 1766)
The client SHOULD by default display the message on the screen. The client SHOULD by default display the message on the screen.
However, since the message is likely to be sent for every login attempt, 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 and since some client software will need to open a separate window for
this warning, the client software may allow the user to explicitly this warning, the client software may allow the user to explicitly
disable the display of banners from the server. The message may consist disable the display of banners from the server. The message may consist
of multiple lines. of multiple lines.
If the message string is displayed, control character filtering If the message string is displayed, control character filtering
discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending
terminal control characters. terminal control characters.
3. Authentication Protocol Message Numbers 3. Authentication Protocol Message Numbers
All message numbers used by this authentication protocol are in the All message numbers used by this authentication protocol are in the
range 50..79, which is part of the range reserved for protocols running range from 50 to 79, which is part of the range reserved for protocols
on top of the SSH transport layer protocol. running on top of the SSH transport layer protocol.
Message numbers 80 and higher are reserved for protocols running after Message numbers of 80 and higher are reserved for protocols running
this authentication protocol, so receiving one of them before after this authentication protocol, so receiving one of them before
authentication is complete is an error, to which the server MUST respond authentication is complete is an error, to which the server MUST respond
by disconnecting (preferably with a proper disconnect message sent first by disconnecting (preferably with a proper disconnect message sent first
to ease troubleshooting). to ease troubleshooting).
After successful authentication, such messages are passed to the higher- After successful authentication, such messages are passed to the higher-
level service. level service.
These are the general authentication message codes: These are the general authentication message codes:
#define SSH_MSG_USERAUTH_REQUEST 50 #define SSH_MSG_USERAUTH_REQUEST 50
#define SSH_MSG_USERAUTH_FAILURE 51 #define SSH_MSG_USERAUTH_FAILURE 51
#define SSH_MSG_USERAUTH_SUCCESS 52 #define SSH_MSG_USERAUTH_SUCCESS 52
#define SSH_MSG_USERAUTH_BANNER 53 #define SSH_MSG_USERAUTH_BANNER 53
In addition to the above, there is a range of message numbers (60..79) 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 reserved for method-specific messages. These messages are only sent by
the server (client only sends SSH_MSG_USERAUTH_REQUEST messages). the server (client sends only SSH_MSG_USERAUTH_REQUEST messages).
Different authentication methods reuse the same message numbers. Different authentication methods reuse the same message numbers.
4. Public Key Authentication Method: publickey 4. Public Key Authentication Method: publickey
The only REQUIRED authentication method is public key authentication. The only REQUIRED authentication method is public key authentication.
All implementations MUST support this method; however, not all users All implementations MUST support this method; however, not all users
need to have public keys, and most local policies are not likely to need to have public keys, and most local policies are not likely to
require public key authentication for all users in near future. require public key authentication for all users in the near future.
With this method, the possession of a private key serves as With this method, the possession of a private key serves as
authentication. This method works by sending a signature created with a 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 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. authenticator for the user, and MUST check that the signature is valid.
If both hold, the authentication request MUST be accepted; otherwise it If both hold, the authentication request MUST be accepted; otherwise it
MUST be rejected. (Note that the server MAY require additional MUST be rejected. (Note that the server MAY require additional
authentications after successful authentication.) authentications after successful authentication.)
Private keys are often stored in an encrypted form at the client host,
Private keys are often stored encrypted at the client host, and the user and the user must supply a passphrase before the signature can be
must supply a passphrase before the signature can be generated. Even if generated. Even if they are not, the signing operation involves some
they are not, the signing operation involves some expensive computation. expensive computation. To avoid unnecessary processing and user
To avoid unnecessary processing and user interaction, the following interaction, the following message is provided for querying whether
message is provided for querying whether authentication using the key authentication using the key would be acceptable.
would be acceptable.
byte SSH_MSG_USERAUTH_REQUEST byte SSH_MSG_USERAUTH_REQUEST
string user name string user name
string service string service
string "publickey" string "publickey"
boolean FALSE boolean FALSE
string public key algorithm name string public key algorithm name
string public key blob string public key blob
Public key algorithms are defined in the transport layer specification Public key algorithms are defined in the transport layer specification
[SSH-TRANS]. The public key blob may contain certificates. [SSH-TRANS]. The public key blob may contain certificates.
Any public key algorithm may be offered for use in authentication. In Any public key algorithm may be offered for use in authentication. In
particular, the list is not constrained by what was negotiated during particular, the list is not constrained by what was negotiated during
key exchange (as that was affected by which algorithms the server had a key exchange. If the server does not support some algorithm, it MUST
host key). If the server does not support some algorithm, it MUST
simply reject the request. simply reject the request.
The server MUST respond to this message with either The server MUST respond to this message with either
SSH_MSG_USERAUTH_FAILURE or with SSH_MSG_USERAUTH_FAILURE or with the following:
byte SSH_MSG_USERAUTH_PK_OK byte SSH_MSG_USERAUTH_PK_OK
string public key algorithm name from the request string public key algorithm name from the request
string public key blob from the request string public key blob from the request
To do actual authentication, the client MAY then send a signature To perform actual authentication, the client MAY then send a signature
generated using the private key. Client MAY send the signature directly generated using the private key. The client MAY send the signature
without first verifying whether the key is acceptable. The signature is directly without first verifying whether the key is acceptable. The
sent using the following packet signature is sent using the following packet:
byte SSH_MSG_USERAUTH_REQUEST byte SSH_MSG_USERAUTH_REQUEST
string user name string user name
string service string service
string "publickey" string "publickey"
boolean TRUE boolean TRUE
string public key algorithm name string public key algorithm name
string public key to be used for authentication string public key to be used for authentication
string signature string signature
Signature is a signature by the corresponding private key over the Signature is a signature by the corresponding private key over the
following data, in this order: following data, in the following order:
o session identifier (encoded as string), and
o packet payload without the signature. 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 When the server receives this message, it MUST check whether the
supplied key is acceptable for authentication, and if so, it MUST check supplied key is acceptable for authentication, and if so, it MUST check
whether the signature is correct. whether the signature is correct.
If both checks succeed, this method is successful. Note that the server If both checks succeed, this method is successful. Note that the server
may require additional authentications. The server MUST respond with may require additional authentications. The server MUST respond with
SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or
SSH_MSG_USERAUTH_FAILURE (if the request failed, or more authentications SSH_MSG_USERAUTH_FAILURE (if the request failed, or more authentications
are needed). are needed).
The following method-specific message numbers are used by the publickey The following method-specific message numbers are used by the publickey
authentication method. authentication method.
/* Key-based */ /* Key-based */
#define SSH_MSG_USERAUTH_PK_OK 60 #define SSH_MSG_USERAUTH_PK_OK 60
5. Password Authentication Method: password 5. Password Authentication Method: password
Password authentication uses the following packets. Note that a server Password authentication uses the following packets. Note that a server
MAY request the user to change password. All implementations SHOULD MAY request the user to change the password. All implementations SHOULD
support password authentication. support password authentication.
byte SSH_MSG_USERAUTH_REQUEST byte SSH_MSG_USERAUTH_REQUEST
string user name string user name
string service string service
string "password" string "password"
boolean FALSE boolean FALSE
string plaintext password (ISO-10646 UTF-8) string plaintext password (ISO-10646 UTF-8)
Note that the password is encoded in ISO-10646 UTF-8. It is up to the 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 server how it interprets the password and validates it against the
password database. However, if the client reads the password in some password database. However, if the client reads the password in some
other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert the 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 password to ISO-10646 UTF-8 before transmitting, and the server MUST
convert the password to the encoding used on that system for passwords. convert the password to the encoding used on that system for passwords.
Note that even though the cleartext password is transmitted in the Note that even though the cleartext password is transmitted in the
packet, the entire packet is encrypted by the transport layer. Both the packet, the entire packet is encrypted by the transport layer. Both the
server and the client should check whether the underlying transport server and the client should check whether the underlying transport
layer provides confidentiality (i.e., encryption is being used). If no layer provides confidentiality (i.e., if encryption is being used). If
confidentiality is provided ("none" cipher), password authentication no confidentiality is provided (none cipher), password authentication
SHOULD be disabled. If there is no confidentiality or no MAC, password SHOULD be disabled. If there is no confidentiality or no MAC, password
change SHOULD be disabled. change SHOULD be disabled.
Normally, the server responds to this message with success or failure. Normally, the server responds to this message with success or failure.
However, the server MAY also respond with However, the server MAY also respond with
SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.
byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
string prompt (ISO-10646 UTF-8) string prompt (ISO-10646 UTF-8)
string language tag (as defined in RFC 1766) string language tag (as defined in RFC 1766)
skipping to change at page 8, line 46 skipping to change at page 8, line 50
string "password" string "password"
boolean TRUE boolean TRUE
string plaintext old password (ISO-10646 UTF-8) string plaintext old password (ISO-10646 UTF-8)
string plaintext new 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, The server must reply to request message with SSH_MSG_USERAUTH_SUCCESS,
SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.
The meaning of these is as follows: The meaning of these is as follows:
SSH_MSG_USERAUTH_SUCCESS SSH_MSG_USERAUTH_SUCCESS
Password has been changed, and authentication has been The password has been changed, and authentication has been
successfully completed. successfully completed.
SSH_MSG_USERAUTH_FAILURE with partial success SSH_MSG_USERAUTH_FAILURE with partial success
The password has been changed, but more authentications are The password has been changed, but more authentications are
needed. needed.
SSH_MSG_USERAUTH_FAILURE without partial success SSH_MSG_USERAUTH_FAILURE without partial success
The password has not been changed. Either password changing was The password has not been changed. Either password changing was
not supported, or the old password was bad. Note that if the not supported, or the old password was bad. Note that if the
server has already sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know server has already sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know
skipping to change at page 9, line 17 skipping to change at page 9, line 23
acceptable (e.g. too easy to guess). acceptable (e.g. too easy to guess).
The following method-specific message numbers are used by the password The following method-specific message numbers are used by the password
authentication method. authentication method.
#define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60
6. Host-Based Authentication: hostbased 6. Host-Based Authentication: hostbased
Some sites wish to allow authentication based on the host where the user 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 is coming from, and the user name on the remote host. While this form
authentication is not suitable for high-security sites, it can be very of authentication is not suitable for high-security sites, it can be
convenient in many environments. This form of authentication is very convenient in many environments. This form of authentication is
OPTIONAL. When used, special care SHOULD be taken to prevent a regular OPTIONAL. When used, special care SHOULD be taken to prevent a regular
user from obtaining the private host key. user from obtaining the private host key.
The client requests this form of authentication by sending the following The client requests this form of authentication by sending the following
message. It is similar to the UNIX "rhosts" and "hosts.equiv" styles of message. It is similar to the UNIX "rhosts" and "hosts.equiv" styles of
authentication, except that the identity of the client host is checked authentication, except that the identity of the client host is checked
more rigorously. more rigorously.
This method works by having the client send a signature created with the 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 private key of the client host, which the server checks with that host's
public key. Once the client host's identity is established, public key. Once the client host's identity is established,
authorization, but no further authentication, is performed based on the authorization (but no further authentication) is performed based on the
user names on the server and client, and the client host name. user names on the server and the client, and the client host name.
byte SSH_MSG_USERAUTH_REQUEST byte SSH_MSG_USERAUTH_REQUEST
string user name string user name
string service string service
string "hostbased" string "hostbased"
string public key algorithm for host key string public key algorithm for host key
string public host key and certificates for client host string public host key and certificates for client host
string client host name (FQDN; US-ASCII) string client host name (FQDN; US-ASCII)
string client user name on the remote host (ISO-10646 UTF-8) string client user name on the remote host (ISO-10646 UTF-8)
string signature string signature
Public key algorithm names for use in "public key algorithm for host Public key algorithm names for use in "public key algorithm for host
key" are defined in the transport layer specification. The "public host key" are defined in the transport layer specification. The "public host
key for client host" may include certificates. key for client host" may include certificates.
Signature is a signature with the private host key of the following Signature is a signature with the private host key of the following
data, in this order: data, in this order:
o session identifier (encoded as string), and string session identifier
byte SSH_MSG_USERAUTH_REQUEST
o packet payload without the signature. 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 client user name on the remote host (ISO-10646 UTF-8)
The server MUST verify that the host key actually belongs to the client 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 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 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 appropriate value by the given host key. The server MAY ignore the
client user name, if it wants to authenticate only the client host. client user name, if it wants to authenticate only the client host.
It is RECOMMENDED that whenever possible, the server perform additional It is RECOMMENDED that whenever possible, the server perform additional
checks to verify that the network address obtained from the (untrusted) checks to verify that the network address obtained from the (untrusted)
network matches the given client host name. This makes exploiting network matches the given client host name. This makes exploiting
compromised host keys more difficult. Note that this may require compromised host keys more difficult. Note that this may require
special handling for connections coming through a firewall. special handling for connections coming through a firewall.
7. Security Considerations 7. Security Considerations
skipping to change at page 10, line 22 skipping to change at page 10, line 34
7. Security Considerations 7. Security Considerations
The purpose of this protocol is to perform client user authentication. The purpose of this protocol is to perform client user authentication.
It assumed that this runs over a secure transport layer protocol, which It assumed that this runs over a secure transport layer protocol, which
has already authenticated the server machine, established an encrypted has already authenticated the server machine, established an encrypted
communications channel, and computed a unique session identifier for communications channel, and computed a unique session identifier for
this session. The transport layer provides forward secrecy for password this session. The transport layer provides forward secrecy for password
authentication and other methods that rely on secret data. authentication and other methods that rely on secret data.
The server may go into a "sleep" period after repeated unsuccesful The server may go into a "sleep" period after repeated unsuccessful
authentications to make key search harder. authentications to make key search harder.
If the transport layer does not provide encryption, authentication If the transport layer does not provide encryption, authentication
methods that rely on secret data SHOULD be disabled. If it does not methods that rely on secret data SHOULD be disabled. If it does not
provide MAC protection, requests to change authentication data (e.g. provide MAC protection, requests to change authentication data (e.g.
password change) SHOULD be disabled to avoid an attacker from modifying password change) SHOULD be disabled to avoid an attacker from modifying
the ciphertext without being noticed, rendering the new authentication the ciphertext without being noticed, rendering the new authentication
data unusable (denial of service). data unusable (denial of service).
Several authentication methods with different security characteristics Several authentication methods with different security characteristics
are allowed. It is up to the server's local policy to decide which 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 methods (or combinations of methods) it is willing to accept for each
user. Authentication is no stronger than the weakest combination user. Authentication is no stronger than the weakest combination
allowed. allowed.
Special care should be taken when designing debug messages. These Special care should be taken when designing debug messages. These
messages may reveal surprising amounts of information about the host if messages may reveal surprising amounts of information about the host if
not properly designed. Debug messages can be disabled (during user not properly designed. Debug messages can be disabled (during user
authentication phase) if high security is sought after. authentication phase) if high security is required.
8. Trademark Issues 8. Trademark Issues
SSH is a registered trademark and Secure Shell is a trademark of SSH SSH is a registered trademark and Secure Shell is a trademark of SSH
Communications Security Corp. SSH Communications Security Corp permits Communications Security Corp. SSH Communications Security Corp permits
the use of these trademarks as the name of this standard and protocol, the use of these trademarks as the name of this standard and protocol,
and permits their use to describe that a product conforms to this and permits their use to describe that a product conforms to this
standard, provided that the following acknowledgement is included where standard, provided that the following acknowledgement is included where
the trademarks are used: ``SSH is a registered trademark and Secure the trademarks are used: ''SSH is a registered trademark and Secure
Shell is a trademark of SSH Communications Security Corp Shell is a trademark of SSH Communications Security Corp
(www.ssh.com)''. These trademarks may not be used as part of a product (www.ssh.com)''. These trademarks may not be used as part of a product
name or in otherwise confusing manner without prior written permission name or in otherwise confusing manner without prior written permission
of SSH Communications Security Corp. of SSH Communications Security Corp.
9. References 9. References
[RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", [RFC-1766] Alvestrand, H: "Tags for the Identification of Languages",
March 1995. March 1995.
[RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and [RFC-2044] Yergeau, F: "UTF-8, a Transformation Format of Unicode and
ISO 10646", October 1996. ISO 10646", October 1996.
[SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet [SSH-ARCH] Ylonen, T., et al: "SSH Protocol Architecture", Internet
Draft, draft-secsh-architecture-05.txt Draft, draft-secsh-architecture-05.txt
[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet [SSH-TRANS] Ylonen, T., et al: "SSH Transport Layer Protocol", Internet
Draft, draft-secsh-transport-07.txt Draft, draft-secsh-transport-07.txt
[SSH-CONNECT] Ylonen, T., et al, "SSH Connection Protocol", Internet [SSH-CONNECT] Ylonen, T., et al: "SSH Connection Protocol", Internet
Draft, draft-secsh-connect-07.txt Draft, draft-secsh-connect-07.txt
10. Author's Address 10. Authors' Addresses
Tatu Ylonen Tatu Ylonen
SSH Communications Security Corp SSH Communications Security Corp
Fredrikinkatu 42 Fredrikinkatu 42
FIN-00100 HELSINKI FIN-00100 HELSINKI
Finland Finland
E-mail: ylo@ssh.com E-mail: ylo@ssh.com
Tero Kivinen Tero Kivinen
SSH Communications Security Corp SSH Communications Security Corp
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/