draft-ietf-secsh-auth-kbdinteract-01.txt   draft-ietf-secsh-auth-kbdinteract-02.txt 
Network Working Group M. Forssen Network Working Group M. Forssen
INTERNET-DRAFT Appgate AB INTERNET-DRAFT Appgate AB
draft-ietf-secsh-auth-kbdinteract-01.txt F. Cusack draft-ietf-secsh-auth-kbdinteract-02.txt F. Cusack
Expires in six months Qwest Internet Solutions Expires in six months Qwest Internet Solutions
12 October 2000 1 March 2001
Generic Message Exchange Authentication For SSH Generic Message Exchange Authentication For SSH
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 in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 SSH is a protocol for secure remote login and other secure network
services over an insecure network. This document describes a general services over an insecure network. This document describes a general
purpose authentication method for the SSH protocol, suitable for purpose authentication method for the SSH protocol, suitable for
interactive authentications where the authentication data should be interactive authentications where the authentication data should be
entered via a keyboard. The major goal of this method is to allow entered via a keyboard. The major goal of this method is to allow
the SSH client to have little or no knowledge of the underlying the SSH client to support a whole class of authentication
authentication mechanism(s) used by the SSH server. mechanism(s) without knowing the specifics of the actual
authentication mechanism(s).
1. Introduction 1. Introduction
The SSH authentication protocol is a general-purpose user The SSH authentication protocol is a general-purpose user
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]. The protocol assumes that the transport layer protocol [SSH-TRANS]. The protocol assumes that the
underlying protocols provide integrity and confidentiality underlying protocols provide integrity and confidentiality
protection. protection.
This document describes a general purpose authentication method for This document describes a general purpose authentication method for
the SSH protocol, suitable for interactive authentications where the the SSH protocol. This method is suitable for interactive
authentication data should be entered via a keyboard. The major goal authentication methods which does not need any special software
of this method is to allow the SSH client to have little or no support on the client side. Instead all authentication data should be
knowledge of the underlying authentication mechanism(s) used by the entered via the keyboard. The major goal of this method is to allow
SSH server. This will allow the server to arbitrarily select or the SSH client to have little or no knowledge of the specifics of the
change the underlying authentication mechanism(s) without having to underlying authentication mechanism(s) used by the SSH server. This
update client code. will allow the server to arbitrarily select or change the underlying
authentication mechanism(s) without having to update client code.
The name for this authentication method is "keyboard-interactive". The name for this authentication method is "keyboard-interactive".
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] and the SSH authentication document [SSH- document [SSH-ARCH] and the SSH authentication document [SSH-
USERAUTH]. This document freely uses terminology and notation from USERAUTH]. This document freely uses terminology and notation from
both documents without reference or further explanation. both documents without reference or further explanation.
This document also describes some of the client interaction with the This document also describes some of the client interaction with the
user in obtaining the authentication information. While this is user in obtaining the authentication information. While this is
somewhat out of the scope of a protocol specification, it is still somewhat out of the scope of a protocol specification, it is still
described here since some aspects of the protocol are specifically described here since some aspects of the protocol are specifically
designed based on user interface issues, and omitting this designed based on user interface issues, and omitting this
information may lead to incompatible or awkward implementations. information may lead to incompatible or awkward implementations.
2. Rationale 2. Rationale
Currently defined authentication methods for SSH are tightly coupled Currently defined authentication methods for SSH are tightly coupled
with the underlying authentication mechanism. This makes it with the underlying authentication mechanism. This makes it difficult
difficult to add new mechanisms for authentication as all clients to add new mechanisms for authentication as all clients must be
must be updated to support the new mechanism. With the generic updated to support the new mechanism. With the generic method defined
method defined here, clients will not require code changes to support here, clients will not require code changes to support further new
new authentication mechanisms, and if a separate authentication layer authentication mechanisms, provided the mechanism fits the
is used, such as [PAM], then the server may not need any code changes requirements for keyboard-interactive. And if a separate
either. authentication layer is used, such as [PAM], then the server may not
need any code changes either.
This presents a significant advantage to other methods, such as the This presents a significant advantage to other methods, such as the
"password" method (defined in [SSH-USERAUTH]), as new (presumably "password" method (defined in [SSH-USERAUTH]), as new (presumably
stronger) methods may be added "at will" and system security can be stronger) methods may be added "at will" and system security can be
transparently enhanced. transparently enhanced.
Challenge-response and One Time Password mechanisms are also easily Challenge-response and One Time Password mechanisms are also easily
supported with this authentication method. supported with this authentication method.
This authentication method is however limited to authentication This authentication method is however limited to authentication
mechanisms which do not require any special code, such as hardware mechanisms which do not require any special code, such as hardware
drivers or password mangling, on the client. drivers or password mangling, on the client.
3. Protocol Exchanges 3. Protocol Exchanges
The client initiates the authentication with a The client initiates the authentication with a
SSH_MSG_USERAUTH_REQUEST message. The server then requests SSH_MSG_USERAUTH_REQUEST message. The server then requests
authentication information from the client with a authentication information from the client with a
SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the
information from the user and then responds with a information from the user and then responds with a
SSM_MSG_USERAUTH_INFO_RESPONSE message. SSH_MSG_USERAUTH_INFO_RESPONSE message. The server MUST not send
another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the
answer from the client.
3.1 Initial Exchange 3.1 Initial Exchange
The authentication starts with the client sending the following The authentication starts with the client sending the following
packet: packet:
byte SSH_MSG_USERAUTH_REQUEST byte SSH_MSG_USERAUTH_REQUEST
string user name (ISO-10646 UTF-8) string user name (ISO-10646 UTF-8)
string service name (US-ASCII) string service name (US-ASCII)
string "keyboard-interactive" (US-ASCII) string "keyboard-interactive" (US-ASCII)
string language tag (as defined in [RFC-1766]) string language tag (as defined in [RFC-1766])
string devices (ISO-10646 UTF-8) string submethods (ISO-10646 UTF-8)
The language tag indicates the client's preferred language. The The language tag indicates the client's preferred language. The
server SHOULD use this language for all text that is to be presented server SHOULD use this language for all text that is to be presented
to the user in the subsequent exchanges. to the user in the subsequent exchanges.
If the server cannot support the requested language, the language to If the server cannot support the requested language, the language to
be used is implementation-dependent. be used is implementation-dependent.
The devices field is a comma-separated list of authentication devices The submethods field is included so the user can give a hint of which
(software or hardware) that are available to authenticate the user actual methods he wants to use. It is a a comma-separated list of
using the keyboard-interactive authentication method. If the client authentication submethods (software or hardware) which the user
has knowledge of the devices available to the user, it MAY use the prefers. If the client has knowledge of the submethods preferred by
devices field to pass this information to the server. Otherwise it the user, presumably through a configuration setting, it MAY use the
submethods field to pass this information to the server. Otherwise it
MUST send the empty string. MUST send the empty string.
Server interpretation of the devices is implementation-dependent. The actual names of the submethods is something which the user and
the server needs to agree upon.
One possible implementation strategy of the devices field on the Server interpretation of the submethods field is implementation-
server is that, unless the user may use multiple different devices, dependent.
the server ignores this field. If the user may authenticate using one
of several different devices the server should treat the devices
field as a hint on which device the user wants to use this time.
Device names should be registered with IANA (Internet Assigned One possible implementation strategy of the submethods field on the
Numbers Authority), or a locally defined name containing an at-sign server is that, unless the user may use multiple different
(@). See section 5 of [SSH-ARCH] for more discussion on name syntax. submethods, the server ignores this field. If the user may
authenticate using one of several different submethods the server
should treat the submethods field as a hint on which submethod the
user wants to use this time.
Note that when this message is sent to the server, the client has not Note that when this message is sent to the server, the client has not
yet prompted the user for a password, and so that information is NOT yet prompted the user for a password, and so that information is NOT
included with this initial message (unlike the "password" method). included with this initial message (unlike the "password" method).
The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS, The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS,
SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message. SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message.
The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message
if the failure is based on the user name or service name; instead it if the failure is based on the user name or service name; instead it
skipping to change at page 4, line 32 skipping to change at page 4, line 38
impossible to find valid user names by just comparing the results impossible to find valid user names by just comparing the results
when authenticating as different users. when authenticating as different users.
3.2 Information Requests 3.2 Information Requests
Requests are generated from the server using the Requests are generated from the server using the
SSH_MSG_USERAUTH_INFO_REQUEST message. SSH_MSG_USERAUTH_INFO_REQUEST message.
The server may send as many requests as are necessary to authenticate The server may send as many requests as are necessary to authenticate
the client; the client MUST be prepared to handle multiple exchanges. the client; the client MUST be prepared to handle multiple exchanges.
However the server MUST never have more than one
SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is it may not
send another request before the client has answered.
The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows: The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows:
byte SSH_MSG_USERAUTH_INFO_REQUEST byte SSH_MSG_USERAUTH_INFO_REQUEST
string name (ISO-10646 UTF-8) string name (ISO-10646 UTF-8)
string instruction (ISO-10646 UTF-8) string instruction (ISO-10646 UTF-8)
string language tag (as defined in [RFC-1766]) string language tag (as defined in [RFC-1766])
int num-prompts int num-prompts
string prompt[1] (ISO-10646 UTF-8) string prompt[1] (ISO-10646 UTF-8)
boolean echo[1] boolean echo[1]
skipping to change at page 6, line 36 skipping to change at page 6, line 52
SSH_MSG_USERAUTH_INFO_REQUEST message. SSH_MSG_USERAUTH_INFO_REQUEST message.
If the server fails to authenticate the user (through the underlying If the server fails to authenticate the user (through the underlying
authentication mechanism(s)), it SHOULD NOT send another request authentication mechanism(s)), it SHOULD NOT send another request
message(s) in an attempt to obtain new authentication data, instead message(s) in an attempt to obtain new authentication data, instead
it SHOULD send a failure message. The only time the server should it SHOULD send a failure message. The only time the server should
send multiple request messages is if additional authentication data send multiple request messages is if additional authentication data
is needed (i.e., because there are multiple underlying authentication is needed (i.e., because there are multiple underlying authentication
mechanisms that must be used to authenticate the user). mechanisms that must be used to authenticate the user).
If the server responds with a failure message, it SHOULD delay a If the server intends to respond with a failure message, it MAY delay
minimum of 2 seconds before sending the failure message, to limit for an implementation dependent time before sending to the client.
certain types of attacks. It is suspected that implementations are likely to make the time
delay a configurable, a suggested default is 2 seconds.
4. Authentication Example 4. Authentication Example
Here is an example exchange between a client and server: Here is an example exchange between a client and server:
C: byte SSH_MSG_USERAUTH_REQUEST C: byte SSH_MSG_USERAUTH_REQUEST
C: string "user23" C: string "user23"
C: string "ssh-userauth" C: string "ssh-userauth"
C: string "keyboard-interactive" C: string "keyboard-interactive"
C: string "en-US" C: string "en-US"
skipping to change at page 7, line 4 skipping to change at page 7, line 18
4. Authentication Example 4. Authentication Example
Here is an example exchange between a client and server: Here is an example exchange between a client and server:
C: byte SSH_MSG_USERAUTH_REQUEST C: byte SSH_MSG_USERAUTH_REQUEST
C: string "user23" C: string "user23"
C: string "ssh-userauth" C: string "ssh-userauth"
C: string "keyboard-interactive" C: string "keyboard-interactive"
C: string "en-US" C: string "en-US"
C: string "" C: string ""
S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Authentication" S: string "CryptoCARD Authentication"
S: string "Enter password for user23@server" S: string "The challenge is '14315716'"
S: string "en-US" S: string "en-US"
S: int 1 S: int 1
S: string "Password: " S: string "Response: "
S: boolean FALSE S: boolean TRUE
[Client prompts user for password] [Client prompts user for password]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1 C: int 1
C: string "bar" C: string "6d757575"
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Expired"
S: string "Your password has expired, you must enter a new one"
S: string "en-US"
S: int 2
S: string "New password: "
S: boolean FALSE
S: string "Enter it again: "
S: boolean FALSE
[Client prompts user for new password]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 2
C: string "baz"
C: string "baz"
S: byte SSH_MSG_USERAUTH_SUCCESS S: byte SSH_MSG_USERAUTH_SUCCESS
5. Protocol constants 5. Protocol constants
The following method-specific constants are used with this The following method-specific constants are used with this
authentication method: authentication method:
SSH_MSG_USERAUTH_INFO_REQUEST 60 SSH_MSG_USERAUTH_INFO_REQUEST 60
SSH_MSG_USERAUTH_INFO_RESPONSE 61 SSH_MSG_USERAUTH_INFO_RESPONSE 61
skipping to change at page 8, line 10 skipping to change at page 8, line 8
Authentication Modules (PAM)", OSF RFC 86.0, October 1995 Authentication Modules (PAM)", OSF RFC 86.0, October 1995
[RFC-1766] Alvestrand, H., "Tags for the Identification of [RFC-1766] Alvestrand, H., "Tags for the Identification of
Languages", March 1995. Languages", March 1995.
[RFC-2279] Yergeau, F., "UTF-8, a Transformation Format of Unicode [RFC-2279] Yergeau, F., "UTF-8, a Transformation Format of Unicode
and ISO 10646", October 1996. and ISO 10646", October 1996.
[SSH-ARCH] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. [SSH-ARCH] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S.
Lehtinen, "SSH Protocol Architecture", Internet Draft, draft-ietf- Lehtinen, "SSH Protocol Architecture", Internet Draft, draft-ietf-
secsh-architecture-05.txt secsh-architecture-06.txt
[SSH-CONNECT] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. [SSH-CONNECT] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S.
Lehtinen, "SSH Connection Protocol", Internet Draft, draft-ietf- Lehtinen, "SSH Connection Protocol", Internet Draft, draft-ietf-
secsh-connect-07.txt secsh-connect-08.txt
[SSH-TRANS] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. [SSH-TRANS] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S.
Lehtinen, "SSH Transport Layer Protocol", Internet Draft, draft- Lehtinen, "SSH Transport Layer Protocol", Internet Draft, draft-
ietf-secsh-transport-07.txt ietf-secsh-transport-08.txt
[SSH-USERAUTH] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. [SSH-USERAUTH] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S.
Lehtinen, "SSH Authentication Protocol", Internet Draft, draft-ietf- Lehtinen, "SSH Authentication Protocol", Internet Draft, draft-ietf-
secsh-userauth-07.txt secsh-userauth-08.txt
7. Author's Addresses 7. Author's Addresses
Frank Cusack Frank Cusack
Qwest Internet Solutions Qwest Internet Solutions
1200 Harbor Blvd, 8th Fl. 1200 Harbor Blvd, 8th Fl.
Weehawken, NJ 07087 Weehawken, NJ 07087
Email: fcusack@iconnet.net Email: fcusack@iconnet.net
Martin Forssen Martin Forssen
 End of changes. 

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