draft-ietf-secsh-userauth-05.txt   draft-ietf-secsh-userauth-06.txt 
Network Working Group T. Ylonen Network Working Group T. Ylonen
INTERNET-DRAFT T. Kivinen INTERNET-DRAFT T. Kivinen
draft-ietf-secsh-userauth-05.txt M. Saarinen draft-ietf-secsh-userauth-06.txt M. Saarinen
Expires in six months T. Rinne Expires in six months T. Rinne
S. Lehtinen S. Lehtinen
SSH SSH
22 February 1999 22 June 1999
SSH Authentication Protocol SSH Authentication Protocol
Status of This memo Status of This Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
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 Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 2, line 10 skipping to change at page 2, line 10
client authentication methods. Additional authentication methods are client authentication methods. Additional authentication methods are
deferred to separate documents. The SSH authentication protocol runs on deferred to separate documents. The SSH authentication protocol runs on
top the SSH transport layer protocol and provides a single authenticated top the SSH transport layer protocol and provides a single authenticated
tunnel for the SSH connection protocol. tunnel for the SSH connection protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Authentication Protocol Framework . . . . . . . . . . . . . 2 2. The Authentication Protocol Framework . . . . . . . . . . . . . 2
2.1. Authentication Requests . . . . . . . . . . . . . . . . . . 3 2.1. Authentication Requests . . . . . . . . . . . . . . . . . . 3
2.2. Responses to Authentication Requests . . . . . . . . . . . . 3 2.2. Responses to Authentication Requests . . . . . . . . . . . . 4
2.3. The none Authentication Request . . . . . . . . . . . . . . 4 2.3. The none Authentication Request . . . . . . . . . . . . . . 4
2.4. Completion of User Authentication . . . . . . . . . . . . . 5 2.4. Completion of User Authentication . . . . . . . . . . . . . 5
2.5. Banner Message . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Banner Message . . . . . . . . . . . . . . . . . . . . . . . 5
3. Authentication Protocol Message Numbers . . . . . . . . . . . . 5 3. Authentication Protocol Message Numbers . . . . . . . . . . . . 5
4. Public Key Authentication Method: publickey . . . . . . . . . . 6 4. Public Key Authentication Method: publickey . . . . . . . . . . 6
5. Password Authentication Method: password . . . . . . . . . . . . 7 5. Password Authentication Method: password . . . . . . . . . . . . 7
6. Host-Based Authentication: hostbased . . . . . . . . . . . . . . 9 6. Host-Based Authentication: hostbased . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The SSH authentication protocol is a general-purpose user authentication The SSH authentication protocol is a general-purpose user authentication
protocol. It is intended to be run over the SSH transport layer protocol protocol. It is intended to be run over the SSH transport layer protocol
[SSH-TRANS]. This protocol assumes that the underlying protocols provide [SSH-TRANS]. This protocol assumes that the underlying protocols provide
integrity and confidentiality protection. integrity and confidentiality protection.
This document should be read only after reading the SSH architecture This document should be read only after reading the SSH architecture
document [SSH-ARCH]. This document freely uses terminology and notation document [SSH-ARCH]. This document freely uses terminology and notation
skipping to change at page 2, line 55 skipping to change at page 3, line 4
client has the freedom to try the methods listed by the server in any client has the freedom to try the methods listed by the server in any
order. This gives the server complete control over the authentication order. This gives the server complete control over the authentication
process if it so desired, but also gives enough flexibility for the process if it so desired, but also gives enough flexibility for the
client to use the methods it supports or that are most convenient for client to use the methods it supports or that are most convenient for
the user when multiple methods are offered by the server. the user when multiple methods are offered by the server.
Authentication methods are identified by names, as defined in [SSH- Authentication methods are identified by names, as defined in [SSH-
ARCH]. The "none" method is reserved, and MUST NOT be listed as ARCH]. The "none" method is reserved, and MUST NOT be listed as
supported. However, it MAY be sent by the client. The server MUST supported. However, it MAY be sent by the client. The server MUST
always reject this request, unless the client is to be allowed in always reject this request, unless the client is to be allowed in
without any authentication, in which case the server MUST accept this
without any authentication, in which case the server MUST accept this
request. The main purpose of sending this request is to get the list of request. The main purpose of sending this request is to get the list of
supported methods from the server. supported methods from the server.
The server SHOULD have a timeout for authentication, and disconnect if The server SHOULD have a timeout for authentication, and disconnect if
the authentication has not been accepted within the timeout period. The the authentication has not been accepted within the timeout period. The
RECOMMENDED timeout period is 10 minutes. Additionally, the RECOMMENDED timeout period is 10 minutes. Additionally, the
implementation SHOULD limit the number of failed authentication attempts implementation SHOULD limit the number of failed authentication attempts
a client may perform in a single session (the RECOMMENDED limit is 20 a client may perform in a single session (the RECOMMENDED limit is 20
attempts). If the threshold is exceeded, the server SHOULD disconnect. attempts). If the threshold is exceeded, the server SHOULD disconnect.
skipping to change at page 9, line 50 skipping to change at page 9, line 50
string client user name on the remote host (ISO-10646 UTF-8) string client user name on the remote host (ISO-10646 UTF-8)
string signature string signature
Public key algorithm names for use in "public key algorithm for host Public key algorithm names for use in "public key algorithm for host
key" are defined in the transport layer specification. The "public host key" are defined in the transport layer specification. The "public host
key for client host" may include certificates. key for client host" may include certificates.
Signature is a signature with the private host key of the following Signature is a signature with the private host key of the following
data, in this order: data, in this order:
o session identifier, and o session identifier (encoded as string), and
o packet payload without the signature. o packet payload without the signature.
The server MUST verify that the host key actually belongs to the client The server MUST verify that the host key actually belongs to the client
host named in the message, that the given user on that host is allowed host named in the message, that the given user on that host is allowed
to log in, and that the signature is a valid signature on the to log in, and that the signature is a valid signature on the
appropriate value by the given host key. The server MAY ignore the appropriate value by the given host key. The server MAY ignore the
client user name, if it wants to authenticate only the client host. client user name, if it wants to authenticate only the client host.
skipping to change at page 10, line 43 skipping to change at page 10, line 43
are allowed. It is up to the server's local policy to decide which are allowed. It is up to the server's local policy to decide which
methods (or combinations of methods) it is willing to accept for each methods (or combinations of methods) it is willing to accept for each
user. Authentication is no stronger than the weakest combination user. Authentication is no stronger than the weakest combination
allowed. allowed.
Special care should be taken when designing debug messages. These Special care should be taken when designing debug messages. These
messages may reveal surprising amounts of information about the host if messages may reveal surprising amounts of information about the host if
not properly designed. Debug messages can be disabled (during user not properly designed. Debug messages can be disabled (during user
authentication phase) if high security is sought after. authentication phase) if high security is sought after.
8. References 8. Trademark Issues
SSH is a registered trademark and Secure Shell is a trademark of SSH
Communications Security Ltd. SSH Communications Security Ltd 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 Ltd
(www.ssh.fi)''. 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 Ltd.
9. References
[RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages",
March 1995. March 1995.
[RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and [RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and
ISO 10646", October 1996. ISO 10646", October 1996.
[SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet [SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet
Draft, draft-secsh-architecture-03.txt Draft, draft-secsh-architecture-04.txt
[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet
Draft, draft-secsh-transport-05.txt Draft, draft-secsh-transport-06.txt
[SSH-CONNECT] Ylonen, T., et al, "SSH Connection Protocol", Internet [SSH-CONNECT] Ylonen, T., et al, "SSH Connection Protocol", Internet
Draft, draft-secsh-connect-06.txt
Draft, draft-secsh-connect-05.txt 10. Author's Address
9. Author's Address
Tatu Ylonen Tatu Ylonen
SSH Communications Security Ltd. SSH Communications Security Ltd.
Tekniikantie 12 Tekniikantie 12
FIN-02150 ESPOO FIN-02150 ESPOO
Finland Finland
E-mail: ylo@ssh.fi E-mail: ylo@ssh.fi
Tero Kivinen Tero Kivinen
SSH Communications Security Ltd. SSH Communications Security Ltd.
 End of changes. 

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