draft-ietf-secsh-userauth-09.txt   draft-ietf-secsh-userauth-10.txt 
Network Working Group T. Ylonen Network Working Group T. Ylonen
INTERNET-DRAFT T. Kivinen INTERNET-DRAFT T. Kivinen
draft-ietf-secsh-userauth-09.txt M. Saarinen draft-ietf-secsh-userauth-10.txt M. Saarinen
Expires: 9 July, 2001 T. Rinne Expires: 2 September, 2001 T. Rinne
S. Lehtinen S. Lehtinen
SSH Communications Security SSH Communications Security
9 January, 2001 2 March, 2001
SSH Authentication Protocol Secure Shell 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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
"work in progress." "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.
Abstract Abstract
SSH is a protocol for secure remote login and other secure network ser- The Secure Shell Remote Login Protocol is a protocol for secure remote
vices over an insecure network. This document describes the SSH authen- login and other secure network services over an insecure network. This
tication protocol framework and public key, password, and host-based document describes the Secure Shell authentication protocol framework
client authentication methods. Additional authentication methods are and public key, password, and host-based client authentication methods.
described in separate documents. The SSH authentication protocol runs Additional authentication methods are described in separate documents.
on top of the SSH transport layer protocol and provides a single authen- The Secure Shell Authentication Protocol runs on top of the Secure Shell
ticated tunnel for the SSH connection protocol. Transport Layer Protocol and provides a single authenticated tunnel for
the Secure Shell 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The SSH authentication protocol is a general-purpose user authentication The Secure Shell Authentication Protocol is a general-purpose user
protocol. It is intended to be run over the SSH transport layer protocol authentication protocol. It is intended to be run over the Secure Shell
[SSH-TRANS]. This protocol assumes that the underlying protocols provide Transport Layer Protocol [SECSH-TRANS]. This protocol assumes that the
integrity and confidentiality protection. underlying protocols provide integrity and confidentiality protection.
This document should be read only after reading the SSH architecture This document should be read only after reading the Secure Shell Remote
document [SSH-ARCH]. This document freely uses terminology and notation Login Protocol Architecture document [SECSH-ARCH]. This document freely
from the architecture document without reference or further explanation. uses terminology and notation 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 (this is the exchange hash H from the first key lower-level protocol (this is the exchange hash H from the first key
exchange). The session identifier uniquely identifies this session and exchange). The session identifier uniquely identifies this session and
is suitable for signing in order to prove ownership of a private key. 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
authentication methods can be used to continue the exchange at any given authentication methods can be used to continue the exchange at any given
time. The client has the freedom to try the methods listed by the server 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 in any order. This gives the server complete control over the
authentication process if desired, but also gives enough flexibility for authentication process if desired, but also gives enough flexibility for
the client to use the methods it supports or that are most convenient the client to use the methods it supports or that are most convenient
for 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 their name, as defined in [SSH- Authentication methods are identified by their name, as defined in
ARCH]. The "none" method is reserved, and MUST NOT be listed as [SECSH-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
skipping to change at page 5, line 23 skipping to change at page 5, line 26
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 for 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" example, normally display text from `/etc/issue', or use "tcp wrappers"
or 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 server may send a SSH_MSG_USERAUTH_BANNER message at any time before
before authentication is successful. This message contains text to be 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 [SECSH-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 from 50 to 79, which is part of the range reserved for protocols range from 50 to 79, which is part of the range reserved for protocols
running on top of the SSH transport layer protocol. running on top of the Secure Shell 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 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.
skipping to change at page 6, line 47 skipping to change at page 6, line 50
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. [SECSH-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. If the server does not support some algorithm, it MUST key exchange. 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 the following: 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 perform 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. The client MAY send the signature generated using the private key. The client MAY send the signature
directly without first verifying whether the key is acceptable. The directly without first verifying whether the key is acceptable. The
signature is sent using the following packet: signature is sent using the following packet:
skipping to change at page 10, line 56 skipping to change at page 11, line 5
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 required. 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 of SSH Communications Security Corp in
the United States and/or other countries.
Communications Security Corp. SSH Communications Security Corp permits
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
standard, provided that the following acknowledgement is included where
the trademarks are used: ''SSH is a registered trademark and Secure
Shell is a trademark of SSH Communications Security Corp
(www.ssh.com)''. These trademarks may not be used as part of a product
name or in otherwise confusing manner without prior written permission
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-2279] Yergeau, F: "UTF-8, a transformation format of ISO 10646", [RFC-2279] Yergeau, F: "UTF-8, a transformation format of ISO 10646",
January 1998. January 1998.
[SSH-ARCH] Ylonen, T., et al: "SSH Protocol Architecture", Internet- [SECSH-ARCH] Ylonen, T., et al: "Secure Shell Remote Login Protocol
Draft, draft-secsh-architecture-07.txt Architecture", Internet-Draft, draft-secsh-architecture-08.txt
[SSH-TRANS] Ylonen, T., et al: "SSH Transport Layer Protocol", Internet- [SECSH-TRANS] Ylonen, T., et al: "Secure Shell Transport Layer
Draft, draft-secsh-transport-09.txt Protocol", Internet-Draft, draft-secsh-transport-10.txt
[SSH-CONNECT] Ylonen, T., et al: "SSH Connection Protocol", Internet- [SECSH-CONNECT] Ylonen, T., et al: "Secure Shell Connection Protocol",
Draft, draft-secsh-connect-09.txt Internet-Draft, draft-secsh-connect-10.txt
10. Authors' Addresses 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
 End of changes. 

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