draft-ietf-secsh-userauth-22.txt   draft-ietf-secsh-userauth-23.txt 
Network Working Group C. Lonvick, Ed. Network Working Group C. Lonvick, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc.
Expires: April 24, 2005 October 24, 2004 Expires: May 19, 2005 November 18, 2004
SSH Authentication Protocol SSH Authentication Protocol
draft-ietf-secsh-userauth-22.txt draft-ietf-secsh-userauth-23.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 35 skipping to change at page 1, line 34
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 April 24, 2005. This Internet-Draft will expire on May 19, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). 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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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
4. The Authentication Protocol Framework . . . . . . . . . . . . 4 4. The Authentication Protocol Framework . . . . . . . . . . . . 4
5. Authentication Requests . . . . . . . . . . . . . . . . . . . 4 5. Authentication Requests . . . . . . . . . . . . . . . . . . . 4
5.1 Responses to Authentication Requests . . . . . . . . . . . 5 5.1 Responses to Authentication Requests . . . . . . . . . . . 5
5.2 The "none" Authentication Request . . . . . . . . . . . . 6 5.2 The "none" Authentication Request . . . . . . . . . . . . 7
5.3 Completion of User Authentication . . . . . . . . . . . . 6 5.3 Completion of User Authentication . . . . . . . . . . . . 7
5.4 Banner Message . . . . . . . . . . . . . . . . . . . . . . 7 5.4 Banner Message . . . . . . . . . . . . . . . . . . . . . . 7
6. Authentication Protocol Message Numbers . . . . . . . . . . . 7 6. Authentication Protocol Message Numbers . . . . . . . . . . . 8
7. Public Key Authentication Method: publickey . . . . . . . . . 8 7. Public Key Authentication Method: publickey . . . . . . . . . 8
8. Password Authentication Method: password . . . . . . . . . . . 10 8. Password Authentication Method: password . . . . . . . . . . . 10
9. Host-Based Authentication: hostbased . . . . . . . . . . . . . 11 9. Host-Based Authentication: hostbased . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 13 12.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 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 35 skipping to change at page 3, line 35
authentication protocol. It is intended to be run over the SSH authentication protocol. It is intended to be run over the SSH
transport layer protocol [SSH-TRANS]. This protocol assumes that the transport layer protocol [SSH-TRANS]. This protocol assumes that the
underlying protocols provide integrity and confidentiality underlying protocols provide integrity and confidentiality
protection. 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 document [SSH-ARCH]. This document freely uses terminology and
notation from the architecture document without reference or further notation from the architecture document without reference or further
explanation. 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 When this protocol starts, it receives the session identifier from
the lower-level protocol (this is the exchange hash H from the first the lower-level protocol (this is the exchange hash H from the first
key exchange). The session identifier uniquely identifies this key exchange). The session identifier uniquely identifies this
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", All documents related to the SSH protocols shall use the keywords
and "MAY" that appear in this document are to be interpreted as "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
described in [RFC2119] "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe
requirements. These keywords are to be interpreted as described in
[RFC2119].
The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
this document when used to describe namespace allocation are to be this document when used to describe namespace allocation are to be
interpreted as described in [RFC2434]. interpreted as described in [RFC2434].
4. 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
skipping to change at page 4, line 40 skipping to change at page 4, line 42
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.
5. 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 [RFC3629] string user name in UTF-8, normalized according to
[I-D.ietf-sasl-saslprep]
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 name' are repeated in every new The 'user name' and 'service name' are repeated in every new
authentication attempt, and MAY change. The server implementation authentication attempt, and MAY change. The server implementation
MUST carefully check them in every message, and MUST flush any MUST carefully check them in every message, and MUST flush any
accumulated authentication states if they change. If it is unable to accumulated authentication states if they change. If it is unable to
flush some authentication state, it MUST disconnect if the 'user flush some authentication state, it MUST disconnect if the 'user
name' or 'service name' changes. name' or 'service name' changes.
The 'service name' specifies the service to start after The 'service name' specifies the service to start after
authentication. There may be several different authenticated authentication. There may be several different authenticated
services provided. If the requested service is not available, the services provided. If the requested service is not available, the
server MAY disconnect immediately or at any later time. Sending a server MAY disconnect immediately or at any later time. Sending a
proper disconnect message is RECOMMENDED. In any case, if the proper disconnect message is RECOMMENDED. In any case, if the
service does not exist, 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 'method name'
accept any. This makes it possible for the server to avoid values, but never accept any. This makes it possible for the server
disclosing information on which accounts exist. In any case, if the to avoid disclosing information on which accounts exist. In any
user does not exist, the authentication request MUST NOT be accepted. case, if the user does not exist, the authentication request MUST NOT
be accepted.
While there is usually little point for clients to send requests that 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 name' 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.
The following 'method name' values are defined.
public key REQUIRED
password OPTIONAL
hostbased OPTIONAL
none NOT RECOMMENDED
Additional 'method name' values may be defined as specified in
[SSH-ARCH] and [SSH-NUMBERS].
5.1 Responses to Authentication Requests 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
The 'authentications that can continue' string is a comma-separated The 'authentications that can continue' string is a comma-separated
list of authentication method names that may productively continue list of authentication 'method name' values that may productively
the authentication dialog. continue the authentication dialog.
It is RECOMMENDED that servers only include those methods in the list It is RECOMMENDED that servers only include those 'method name'
that are actually useful. However, it is not illegal to include values in the list that are actually useful. However, it is not
methods that cannot be used to authenticate the user. illegal to include 'method name' values 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.
The value of 'partial success' MUST be TRUE if the authentication The value of 'partial success' MUST be TRUE if the authentication
request to which this is a response was successful. It MUST be FALSE request to which this is a response was successful. It MUST be FALSE
if the request 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
skipping to change at page 6, line 37 skipping to change at page 7, line 7
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 6). be identified by their message numbers (see Section 6).
5.2 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 'method name' values
continue by using the "none" authentication method. that may continue by using the "none" authentication 'method name'.
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 'method name' values that can continue.
This method MUST NOT be listed as supported by the server. This 'method name' MUST NOT be listed as supported by the server.
5.3 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.
skipping to change at page 7, line 31 skipping to change at page 7, line 49
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]
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 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.
6. 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
skipping to change at page 8, line 16 skipping to change at page 8, line 35
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.
7. 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 name' is public key
All implementations MUST support this method; however, not all users authentication. All implementations MUST support this method;
need to have public keys, and most local policies are not likely to however, not all users need to have public keys, and most local
require public key authentication for all users in the near future. policies are not likely to require public key authentication for all
users in the near future.
With this method, the possession of a private key serves as 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
signature is valid. If both hold, the authentication request MUST be 'signature' is valid. If both hold, the authentication request MUST
accepted; otherwise it MUST be rejected. (Note that the server MAY be accepted; otherwise it MUST be rejected. (Note that the server
require additional authentications after successful authentication.) MAY require additional authentications after successful
authentication.)
Private keys are often stored in an encrypted form at the client Private keys are often stored in an encrypted form at the client
host, and the user must supply a passphrase before the signature can host, and the user must supply a passphrase before the signature can
be generated. Even if they are not, the signing operation involves be generated. Even if they are not, the signing operation involves
some expensive computation. To avoid unnecessary processing and user some expensive computation. To avoid unnecessary processing and user
interaction, the following message is provided for querying whether interaction, the following message is provided for querying whether
authentication using the key would be acceptable. authentication using the key would be acceptable.
byte SSH_MSG_USERAUTH_REQUEST byte SSH_MSG_USERAUTH_REQUEST
string user name string user name in UTF-8, normalized according to
string service [I-D.ietf-sasl-saslprep]
string service name in US-ASCII
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 Public key algorithms are defined in the transport layer
specification [SSH-TRANS]. The public key blob may contain specification [SSH-TRANS]. The 'public key blob' may contain
certificates. certificates.
Any public key algorithm may be offered for use in authentication. Any public key algorithm may be offered for use in authentication.
In particular, the list is not constrained by what was negotiated In particular, the list is not constrained by what was negotiated
during key exchange. If the server does not support some algorithm, during key exchange. If the server does not support some algorithm,
it MUST simply reject the request. it MUST 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 the following: SSH_MSG_USERAUTH_FAILURE or with the following:
skipping to change at page 10, line 16 skipping to change at page 10, line 36
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 UTF-8, normalized by
[I-D.ietf-sasl-saslprep]
Note that the 'plaintext password' value is encoded in ISO-10646 Note that the 'plaintext password' value is encoded in ISO-10646
UTF-8. It is up to the server how it interprets the password and UTF-8. This encoding MUST be performed canonically as described in
validates it against the password database. However, if the client [I-D.ietf-sasl-saslprep]. It is up to the server how it interprets
reads the password in some other encoding (e.g., ISO 8859-1 - ISO the password and validates it against the password database.
Latin1), it MUST convert the password to ISO-10646 UTF-8 before However, if the client reads the password in some other encoding
transmitting, and the server MUST convert the password to the (e.g., ISO 8859-1 - ISO Latin1), it MUST convert the password to
encoding used on that system for passwords. ISO-10646 UTF-8 before transmitting, and the server MUST convert the
password to the encoding used on that system for passwords.
Note that even though the cleartext password is transmitted in the 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
failure. However, if the password has expired the server SHOULD failure. However, if the password has expired the server SHOULD
indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.
In any case the server MUST NOT allow an expired password to be used In any case the server MUST NOT allow an expired password to be used
for authentication. for authentication.
byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
string prompt in ISO-10646 UTF-8 encoding string prompt in ISO-10646 UTF-8 encoding
skipping to change at page 12, line 17 skipping to change at page 12, line 41
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 expressed as the FQDN in US-ASCII string client host name expressed as the FQDN in US-ASCII
string user name on the client host in ISO-10646 UTF-8 encoding string user name on the client host in ISO-10646 UTF-8 encoding
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 key' are defined in the transport layer specification. The 'public
host key for client host" may include certificates. host key and certificates for client host' may include certificates.
Signature is a signature with the private host key of the following The value of 'signature' is a signature with the private host key of
data, in this order: the following data, in this 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 "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 expressed as the FQDN in US-ASCII string client host name expressed as the FQDN in US-ASCII
string user name on the client host in ISO-10646 UTF-8 encoding string user name on the client host in ISO-10646 UTF-8 encoding
The server MUST verify that the host key actually belongs to the 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 client host named in the message, that the given user on that host is
allowed to log in, and that the signature is a valid signature on the allowed to log in, and that the 'signature' value is a valid
appropriate value by the given host key. The server MAY ignore the signature on the appropriate value by the given host key. The server
client user name, if it wants to authenticate only the client host. MAY ignore the 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.
10. IANA Considerations 10. IANA Considerations
skipping to change at page 13, line 23 skipping to change at page 13, line 48
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].
12. References 12. References
12.1 Normative 12.1 Normative
[SSH-ARCH] [SSH-ARCH]
Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", Lonvick, C., "SSH Protocol Architecture", I-D
I-D draft-ietf-architecture-17.txt, October 2004. draft-ietf-architecture-18.txt, October 2004.
[SSH-CONNECT] [SSH-CONNECT]
Ylonen, T. and C. Lonvick, "SSH Connection Protocol", I-D Lonvick, C., "SSH Connection Protocol", I-D
draft-ietf-connect-20.txt, October 2004. draft-ietf-connect-21.txt, October 2004.
[SSH-TRANS] [SSH-TRANS]
Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol", Lonvick, C., "SSH Transport Layer Protocol", I-D
I-D draft-ietf-transport-19.txt, October 2004. draft-ietf-transport-20.txt, October 2004.
[SSH-NUMBERS] [SSH-NUMBERS]
Ylonen, T. and C. Lonvick, "SSH Protocol Assigned Lonvick, C., "SSH Protocol Assigned Numbers", I-D
Numbers", I-D draft-ietf-assignednumbers-07.txt, October draft-ietf-assignednumbers-08.txt, October 2004.
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.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[I-D.ietf-sasl-saslprep]
Zeilenga, K., "SASLprep: Stringprep profile for user names
and passwords", draft-ietf-sasl-saslprep-10 (work in
progress), July 2004.
12.2 Informative 12.2 Informative
[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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
Author's Address 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 Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
 End of changes. 

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