draft-ietf-secsh-userauth-21.txt   draft-ietf-secsh-userauth-22.txt 
Network Working Group T. Ylonen Network Working Group C. Lonvick, Ed.
Internet-Draft SSH Communications Security Corp Internet-Draft Cisco Systems, Inc
Expires: December 1, 2004 C. Lonvick, Ed. Expires: April 24, 2005 October 24, 2004
Cisco Systems, Inc
June 2, 2004
SSH Authentication Protocol SSH Authentication Protocol
draft-ietf-secsh-userauth-21.txt draft-ietf-secsh-userauth-22.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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.
This Internet-Draft will expire on December 1, 2004. This Internet-Draft will expire on April 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
SSH is a protocol for secure remote login and other secure network SSH is a protocol for secure remote login and other secure network
services over an insecure network. This document describes the SSH services over an insecure network. This document describes the SSH
authentication protocol framework and public key, password, and authentication protocol framework and public key, password, and
host-based client authentication methods. Additional authentication host-based client authentication methods. Additional authentication
methods are described in separate documents. The SSH authentication methods are described in separate documents. The SSH authentication
protocol runs on top of the SSH transport layer protocol and provides protocol runs on top of the SSH transport layer protocol and provides
a single authenticated tunnel for the SSH connection protocol. a single authenticated tunnel for the SSH connection protocol.
Table of Contents Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . . 3
3.1 The Authentication Protocol Framework . . . . . . . . . . 4 4. The Authentication Protocol Framework . . . . . . . . . . . . 4
3.1.1 Authentication Requests . . . . . . . . . . . . . . . 4 5. Authentication Requests . . . . . . . . . . . . . . . . . . . 4
3.1.2 Responses to Authentication Requests . . . . . . . . . 5 5.1 Responses to Authentication Requests . . . . . . . . . . . 5
3.1.3 The "none" Authentication Request . . . . . . . . . . 6 5.2 The "none" Authentication Request . . . . . . . . . . . . 6
3.1.4 Completion of User Authentication . . . . . . . . . . 6 5.3 Completion of User Authentication . . . . . . . . . . . . 6
3.1.5 Banner Message . . . . . . . . . . . . . . . . . . . . 7 5.4 Banner Message . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Authentication Protocol Message Numbers . . . . . . . . . 7 6. Authentication Protocol Message Numbers . . . . . . . . . . . 7
3.3 Public Key Authentication Method: publickey . . . . . . . 8 7. Public Key Authentication Method: publickey . . . . . . . . . 8
3.4 Password Authentication Method: password . . . . . . . . . 10 8. Password Authentication Method: password . . . . . . . . . . . 10
3.5 Host-Based Authentication: hostbased . . . . . . . . . . . 11 9. Host-Based Authentication: hostbased . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 13 12.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 15
1. Contributors 1. Contributors
The major original contributors of this document were: Tatu Ylonen, The major original contributors of this document were: Tatu Ylonen,
Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH
Communications Security Corp), and Markku-Juhani O. Saarinen Communications Security Corp), and Markku-Juhani O. Saarinen
(University of Jyvaskyla). Darren Moffit was the original editor of (University of Jyvaskyla). Darren Moffit was the original editor of
this document and also made very substantial contributions. this document and also made very substantial contributions.
skipping to change at page 3, line 50 skipping to change at page 3, line 50
session and is suitable for signing in order to prove ownership of a session and is suitable for signing in order to prove ownership of a
private key. This protocol also needs to know whether the private key. This protocol also needs to know whether the
lower-level protocol provides confidentiality protection. lower-level protocol provides confidentiality protection.
3. Conventions Used in This Document 3. Conventions Used in This Document
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
and "MAY" that appear in this document are to be interpreted as and "MAY" that appear in this document are to be interpreted as
described in [RFC2119] described in [RFC2119]
The used data types and terminology are specified in the architecture The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
document [SSH-ARCH] FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
The architecture document also discusses the algorithm naming APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
conventions that MUST be used with the SSH protocols. this document when used to describe namespace allocation are to be
interpreted as described in [RFC2434].
3.1 The Authentication Protocol Framework 4. The Authentication Protocol Framework
The server drives the authentication by telling the client which The server drives the authentication by telling the client which
authentication methods can be used to continue the exchange at any authentication methods can be used to continue the exchange at any
given time. The client has the freedom to try the methods listed by 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 server in any order. This gives the server complete control over
the authentication process if desired, but also gives enough the authentication process if desired, but also gives enough
flexibility for the client to use the methods it supports or that are flexibility for the client to use the methods it supports or that are
most convenient for the user, when multiple methods are offered by most convenient for the user, when multiple methods are offered by
the server. the server.
skipping to change at page 4, line 34 skipping to change at page 4, line 34
of supported methods from the server. of supported methods from the server.
The server SHOULD have a timeout for authentication, and disconnect The server SHOULD have a timeout for authentication, and disconnect
if the authentication has not been accepted within the timeout if the authentication has not been accepted within the timeout
period. The RECOMMENDED timeout period is 10 minutes. Additionally, period. The RECOMMENDED timeout period is 10 minutes. Additionally,
the implementation SHOULD limit the number of failed authentication the implementation SHOULD limit the number of failed authentication
attempts a client may perform in a single session (the RECOMMENDED attempts a client may perform in a single session (the RECOMMENDED
limit is 20 attempts). If the threshold is exceeded, the server limit is 20 attempts). If the threshold is exceeded, the server
SHOULD disconnect. SHOULD disconnect.
3.1.1 Authentication Requests 5. Authentication Requests
All authentication requests MUST use the following message format. All authentication requests MUST use the following message format.
Only the first few fields are defined; the remaining fields depend on Only the first few fields are defined; the remaining fields depend on
the authentication method. the authentication method.
byte SSH_MSG_USERAUTH_REQUEST byte SSH_MSG_USERAUTH_REQUEST
string user name in ISO-10646 UTF-8 encoding [RFC2279] string user name in ISO-10646 UTF-8 encoding [RFC3629]
string service name in US-ASCII string service name in US-ASCII
string method name in US-ASCII string method name in US-ASCII
The 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 name' are repeated in every new
attempt, and MAY change. The server implementation MUST carefully authentication attempt, and MAY change. The server implementation
check them in every message, and MUST flush any accumulated MUST carefully check them in every message, and MUST flush any
authentication states if they change. If it is unable to flush some accumulated authentication states if they change. If it is unable to
authentication state, it MUST disconnect if the user or service name flush some authentication state, it MUST disconnect if the 'user
changes. name' or 'service name' changes.
The service name specifies the service to start after authentication. The 'service name' specifies the service to start after
There may be several different authenticated services provided. If authentication. There may be several different authenticated
the requested service is not available, the server MAY disconnect services provided. If the requested service is not available, the
immediately or at any later time. Sending a proper disconnect server MAY disconnect immediately or at any later time. Sending a
message is RECOMMENDED. In any case, if the service does not exist, proper disconnect message is RECOMMENDED. In any case, if the
authentication MUST NOT be accepted. service does not exist, authentication MUST NOT be accepted.
If the requested user does not exist, the server MAY disconnect, or If the requested user does not exist, the server MAY disconnect, or
MAY send a bogus list of acceptable authentication methods, but never MAY send a bogus list of acceptable authentication methods, but never
accept any. This makes it possible for the server to avoid accept any. This makes it possible for the server to avoid
disclosing information on which accounts exist. In any case, if the disclosing information on which accounts exist. In any case, if the
user does not exist, the authentication request MUST NOT be accepted. user does not 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 the server does not list as acceptable, sending such requests is not
an error, and the server SHOULD simply reject requests that it does an error, and the server SHOULD simply reject requests that it does
not recognize. not recognize.
An authentication request MAY result in a further exchange of An authentication request MAY result in a further exchange of
messages. All such messages depend on the authentication method messages. All such messages depend on the authentication method
used, and the client MAY at any time continue with a new used, and the client MAY at any time continue with a new
SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST
abandon the previous authentication attempt and continue with the new abandon the previous authentication attempt and continue with the new
one. one.
3.1.2 Responses to Authentication Requests 5.1 Responses to Authentication Requests
If the server rejects the authentication request, it MUST respond If the server rejects the authentication request, it MUST respond
with the following: 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 The 'authentications that can continue' string is a comma-separated
authentication method names that may productively continue the list of authentication method names that may productively continue
authentication dialog. the 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 that are actually useful. However, it is not illegal to include
methods that cannot be used to authenticate the user. methods that cannot be used to authenticate the user.
Already successfully completed authentications SHOULD NOT be included Already successfully completed authentications SHOULD NOT be included
in the list, unless they really should be performed again for some in the list, unless they really should be performed again for some
reason. reason.
"Partial success" MUST be TRUE if the authentication request to which The value of 'partial success' MUST be TRUE if the authentication
this is a response was successful. It MUST be FALSE if the request request to which this is a response was successful. It MUST be FALSE
was not successfully processed. if the request was not successfully processed.
When the server accepts authentication, it MUST respond with the When the server accepts authentication, it MUST respond with the
following: following:
byte SSH_MSG_USERAUTH_SUCCESS byte SSH_MSG_USERAUTH_SUCCESS
Note that this is not sent after each step in a multi-method Note that this is not sent after each step in a multi-method
authentication sequence, but only when the authentication is authentication sequence, but only when the authentication is
complete. complete.
skipping to change at page 6, line 33 skipping to change at page 6, line 33
request will result in further exchange of messages. No request will result in further exchange of messages. No
SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method.
SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When
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 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 to the service being run on top of this protocol. Such messages can
be identified by their message numbers (see Section 3.2). be identified by their message numbers (see Section 6).
3.1.3 The "none" Authentication Request 5.2 The "none" Authentication Request
A client may request a list of authentication methods that may A client may request a list of authentication methods that may
continue by using the "none" authentication method. continue 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 SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of
authentication methods that can continue. authentication 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.
3.1.4 Completion of User Authentication 5.3 Completion of User Authentication
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 SSH_MSG_USERAUTH_SUCCESS. All authentication related messages
received after sending this message SHOULD be silently ignored. received after sending this message SHOULD be silently ignored.
After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the
requested service. requested service.
3.1.5 Banner Message 5.4 Banner Message
In some jurisdictions, sending a warning message before In some jurisdictions, sending a warning message before
authentication may be relevant for getting legal protection. Many authentication may be relevant for getting legal protection. Many
UNIX machines, for example, normally display text from `/etc/issue', UNIX machines, for example, normally display text from '/etc/issue',
or use "tcp wrappers" or similar software to display a banner before or use "tcp wrappers" or similar software to display a banner before
issuing a login prompt. 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 before authentication is successful. This message contains text to
be displayed to the client user before authentication is attempted. be displayed to the client user before authentication is attempted.
The format is as follows: The format is as follows:
byte SSH_MSG_USERAUTH_BANNER byte SSH_MSG_USERAUTH_BANNER
string message in ISO-10646 UTF-8 encoding string message in ISO-10646 UTF-8 encoding
string language tag as defined in [RFC3066] string language tag as defined in [RFC3066]
skipping to change at page 7, line 35 skipping to change at page 7, line 35
However, since the message is likely to be sent for every login However, since the message is likely to be sent for every login
attempt, and since some client software will need to open a separate attempt, and since some client software will need to open a separate
window for this warning, the client software may allow the user to window for this warning, the client software may allow the user to
explicitly disable the display of banners from the server. The explicitly disable the display of banners from the server. The
message may consist of multiple lines. message may consist 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.2 Authentication Protocol Message Numbers 6. 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 from 50 to 79, which is part of the range reserved for range from 50 to 79, which is part of the range reserved for
protocols running on top of the SSH transport layer protocol. protocols running on top of the SSH transport layer protocol.
Message numbers of 80 and higher are reserved for protocols running Message numbers of 80 and higher are reserved for protocols running
after 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 authentication is complete is an error, to which the server MUST
respond by disconnecting, preferably with a proper disconnect message respond by disconnecting, preferably with a proper disconnect message
sent first to ease troubleshooting. sent to ease troubleshooting.
After successful authentication, such messages are passed to the After successful authentication, such messages are passed to the
higher-level service. higher-level service.
These are the general authentication message codes: These are the general authentication message codes:
#define SSH_MSG_USERAUTH_REQUEST 50 SSH_MSG_USERAUTH_REQUEST 50
#define SSH_MSG_USERAUTH_FAILURE 51 SSH_MSG_USERAUTH_FAILURE 51
#define SSH_MSG_USERAUTH_SUCCESS 52 SSH_MSG_USERAUTH_SUCCESS 52
#define SSH_MSG_USERAUTH_BANNER 53 SSH_MSG_USERAUTH_BANNER 53
In addition to the above, there is a range of message numbers In addition to the above, there is a range of message numbers
(60..79) reserved for method-specific messages. These messages are (60..79) reserved for method-specific messages. These messages are
only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST
messages). Different authentication methods reuse the same message messages). Different authentication methods reuse the same message
numbers. numbers.
3.3 Public Key Authentication Method: publickey 7. 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 the 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 authentication. This method works by sending a signature created
with a private key of the user. The server MUST check that the key 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 is a valid authenticator for the user, and MUST check that the
skipping to change at page 9, line 26 skipping to change at page 9, line 26
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 The value of 'signature' is a signature by the corresponding private
following data, in the following order: key over the following data, in the following order:
string session identifier string session identifier
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
skipping to change at page 9, line 51 skipping to change at page 9, line 51
If both checks succeed, this method is successful. Note that the If both checks succeed, this method is successful. Note that the
server may require additional authentications. The server MUST server may require additional authentications. The server MUST
respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are
needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more
authentications are needed). authentications are needed).
The following method-specific message numbers are used by the The following method-specific message numbers are used by the
publickey authentication method. publickey authentication method.
/* Key-based */ SSH_MSG_USERAUTH_PK_OK 60
#define SSH_MSG_USERAUTH_PK_OK 60
3.4 Password Authentication Method: password 8. Password Authentication Method: password
Password authentication uses the following packets. Note that a Password authentication uses the following packets. Note that a
server MAY request the user to change the password. All server MAY request the user to change the password. All
implementations SHOULD support password authentication. implementations SHOULD 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 in ISO-10646 UTF-8 encoding string plaintext password in ISO-10646 UTF-8 encoding
Note that the password is encoded in ISO-10646 UTF-8. It is up to Note that the 'plaintext password' value is encoded in ISO-10646
the server how it interprets the password and validates it against UTF-8. It is up to the server how it interprets the password and
the password database. However, if the client reads the password in validates it against the password database. However, if the client
some other encoding (e.g., ISO 8859-1 - ISO Latin1), it MUST convert reads the password in some other encoding (e.g., ISO 8859-1 - ISO
the password to ISO-10646 UTF-8 before transmitting, and the server Latin1), it MUST convert the password to ISO-10646 UTF-8 before
MUST convert the password to the encoding used on that system for transmitting, and the server MUST convert the password to the
passwords. 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 packet, the entire packet is encrypted by the transport layer. Both
the server and the client should check whether the underlying the server and the client should check whether the underlying
transport layer provides confidentiality (i.e., if encryption is transport layer provides confidentiality (i.e., if encryption is
being used). If no confidentiality is provided (none cipher), being used). If no confidentiality is provided (none cipher),
password authentication SHOULD be disabled. If there is no password authentication SHOULD be disabled. If there is no
confidentiality or no MAC, password change SHOULD be disabled. confidentiality or no MAC, password change SHOULD be disabled.
Normally, the server responds to this message with success or Normally, the server responds to this message with success or
skipping to change at page 11, line 31 skipping to change at page 11, line 31
the old password was bad. Note that if the server has already the old password was bad. Note that if the server has already
sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports
changing the password. changing the password.
SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because
the new password was not acceptable (e.g. too easy to guess). the new password was not acceptable (e.g. too easy to guess).
The following method-specific message numbers are used by the The following method-specific message numbers are used by the
password authentication method. password authentication method.
#define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60
3.5 Host-Based Authentication: hostbased 9. Host-Based Authentication: hostbased
Some sites wish to allow authentication based on the host where the 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 user is coming from, and the user name on the remote host. While
this form of authentication is not suitable for high-security sites, this form of authentication is not suitable for high-security sites,
it can be very convenient in many environments. This form of it can be very convenient in many environments. This form of
authentication is OPTIONAL. When used, special care SHOULD be taken authentication is OPTIONAL. When used, special care SHOULD be taken
to prevent a regular user from obtaining the private host key. to prevent a regular user from obtaining the private host key.
The client requests this form of authentication by sending the The client requests this form of authentication by sending the
following message. It is similar to the UNIX "rhosts" and following message. It is similar to the UNIX "rhosts" and
skipping to change at page 12, line 47 skipping to change at page 12, line 47
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 It is RECOMMENDED that whenever possible, the server perform
additional checks to verify that the network address obtained from additional checks to verify that the network address obtained from
the (untrusted) network matches the given client host name. This the (untrusted) network matches the given client host name. This
makes exploiting compromised host keys more difficult. Note that makes exploiting compromised host keys more difficult. Note that
this may require special handling for connections coming through a this may require special handling for connections coming through a
firewall. firewall.
4. IANA Considerations 10. IANA Considerations
This document is part of a set. The IANA considerations for the SSH This document is part of a set. The IANA considerations for the SSH
protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-CONNECT], and protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-CONNECT], and
this document, are detailed in [SSH-NUMBERS]. this document, are detailed in [SSH-NUMBERS].
5. Security Considerations 11. Security Considerations
The purpose of this protocol is to perform client user The purpose of this protocol is to perform client user
authentication. It assumed that this runs over a secure transport authentication. It assumed that this runs over a secure transport
layer protocol, which has already authenticated the server machine, layer protocol, which has already authenticated the server machine,
established an encrypted communications channel, and computed a established an encrypted communications channel, and computed a
unique session identifier for this session. The transport layer unique session identifier for this session. The transport layer
provides forward secrecy for password authentication and other provides forward secrecy for password authentication and other
methods that rely on secret data. methods that rely on secret data.
Full security considerations for this protocol are provided in Full security considerations for this protocol are provided in
[SSH-ARCH]. [SSH-ARCH].
6. References 12. References
6.1 Normative 12.1 Normative
[SSH-ARCH] [SSH-ARCH]
Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
I-D draft-ietf-architecture-16.txt, May 2004. I-D draft-ietf-architecture-17.txt, October 2004.
[SSH-CONNECT] [SSH-CONNECT]
Ylonen, T. and C. Lonvick, "SSH Connection Protocol", I-D Ylonen, T. and C. Lonvick, "SSH Connection Protocol", I-D
draft-ietf-connect-19.txt, May 2004. draft-ietf-connect-20.txt, October 2004.
[SSH-TRANS] [SSH-TRANS]
Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol", Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol",
I-D draft-ietf-transport-18.txt, May 2004. I-D draft-ietf-transport-19.txt, October 2004.
[SSH-NUMBERS] [SSH-NUMBERS]
Ylonen, T. and C. Lonvick, "SSH Protocol Assigned Ylonen, T. and C. Lonvick, "SSH Protocol Assigned
Numbers", I-D draft-ietf-assignednumbers-06.txt, May 2004. Numbers", I-D draft-ietf-assignednumbers-07.txt, October
2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2 Informative [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 12.2 Informative
10646", RFC 2279, January 1998.
[RFC3066] Alvestrand, H., "Tags for the Identification of [RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001. Languages", BCP 47, RFC 3066, January 2001.
Authors' Addresses [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
Tatu Ylonen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: ylo@ssh.com Author's Address
Chris Lonvick (editor) Chris Lonvick (editor)
Cisco Systems, Inc Cisco Systems, Inc
12515 Research Blvd. 12515 Research Blvd.
Austin 78759 Austin 78759
USA USA
EMail: clonvick@cisco.com EMail: clonvick@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
Full Copyright Statement Disclaimer of Validity
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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