Here is an updated version of my proposal, fully formatted as an I-D.
Also, I've updated it to be even more generic, with support for
smartcards and biometrics (although how that support is to be done
is not specified in this version... looking for help there...)
I didn't run it through the "formfeed script" to avoid embedding
control characters in an email/posting.
Network Working Group F. Cusack
INTERNET-DRAFT Qwest Internet Solutions
draft-ietf-secsh-genericauth-00.txt 22 Feb 1999
Expires in six months
Generic Message Exchange Authentication For SSH
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
SSH is a protocol for secure remote login and other secure network
services over an insecure network. This document describes a general
purpose message exchange authentication method for the SSH protocol.
The major goal of this method is to allow the SSH client to have
little or no knowledge of the actual authentication mechanism used by
the SSH server.
Cusack FORMFEED[Page 1]
draft-ietf-secsh-genericauth-00.txt 22 Feb 1999
1. Introduction
The SSH authentication protocol is a general-purpose user
authentication protocol. It is intended to be run over the SSH
transport layer protocol [SSH-TRANS]. The protocol assumes that the
underlying protocols provide integrity and confidentiality
protection.
This document describes a generic message exchange authentication
method for the SSH authentication protocol. The rationale for this
generic method is to allow the server to arbitrarily select or change
the underlying authentication method without having to update client
code.
The method name for this authentication method is "password-plus".
This document should be read only after reading the SSH architecture
document [SSH-ARCH] and the SSH authentication document [SSH-
USERAUTH]. This document freely uses terminology and notation from
both documents without reference or further explanation.
This document also describes some of the client interaction with the
user in obtaining the authentication information. While this is
somewhat out of the scope of a protocol specification, it is still
described here since some aspects of the protocol are specifically
designed based on user interface issues.
2. Discussion
Currently defined authentication methods for SSH are tightly coupled
with the underlying authentication mechanism. This makes it
difficult to add new mechanisms for authentication as all clients
must be updated to support the new mechanism. With the generic
method defined here, clients will not require code changes to support
new authentication mechanisms, and if a separate 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
"password" method, as new (presumably stronger) methods may be added
"at will" and system security can be transparently enhanced.
3. Protocol Exchanges
The client initiates the authentication with a
SSH_MSG_USERAUTH_REQUEST message. The server then requests
authentication information from the client with a
SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the
Cusack FORMFEED[Page 2]
draft-ietf-secsh-genericauth-00.txt 22 Feb 1999
information from the user and then responds with a
SSM_MSG_USERAUTH_INFO_RESPONSE message.
3.1 Initial Exchange
The authentication starts with the client sending the following
packet:
byte SSH_MSG_USERAUTH_REQUEST
string username
string service
string "password-plus"
int num-supported-input-types
int input-type[0]
...
int input-type[n]
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
included with this initial message (unlike the "password" method).
The input-types are from the list of types in section 5.
The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS,
SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message.
The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message
if the failure is based on the username or service; instead it SHOULD
send a SSH_MSG_USERAUTH_INFO_REQUEST message requesting a password,
and then send the failure message (after a suitable delay, as
described below). This is to prevent leaking of information that
could potentially be used in an attack.
3.2 Information Requests / User Interface
Requests are generated from the server using the
SSH_MSG_USERAUTH_INFO_REQUEST message.
Input types are specified in the request messages, and are limited to
a single input type per request message. The server MUST NOT send a
request message with an input type that the client did not indicate
support for in the initial exchange.
The server may send as many requests as are necessary to authenticate
the client; the client MUST be prepared to handle multiple exchanges,
each with potentially different input types.
The SSH_MSG_USERAUTH_INFO_REQUEST message is divided into a "common
Cusack FORMFEED[Page 3]
draft-ietf-secsh-genericauth-00.txt 22 Feb 1999
part" and an "input-type-specific part". The "common part" is
defined as follows:
byte SSH_MSG_USERAUTH_INFO_REQUEST
int input-type
boolean name-present
string name (if name-present is TRUE) (ISO-10646 UTF-8)
boolean banner-present
string banner (if banner-present is TRUE) (ISO-10646 UTF-8)
rest of the packet is input-type-specific
The server SHOULD limit the length of the name field to 30
characters. No restrictions are placed on the banner field.
3.2.1 SSH_USERAUTH_INPUT_KEYBOARD
This input type is used when the user should type the response[s].
This includes (e.g.) passwords and challenge-response authentications
using handheld tokens. All clients MUST support this input type.
When this input type is specified, the remainder of the request
message is defined as follows:
int num-prompts
string prompt[0] (ISO-10646 UTF-8)
boolean echo[0]
...
string prompt[n] (ISO-10646 UTF-8)
boolean echo[n]
string language tag (as defined in [RFC-1766])
The server SHOULD limit the length of the prompt fields to 30
characters.
Upon receiving a request message of this type, the client SHOULD
prompt the user as follows:
For each prompt, the echo field indicates whether or not the user
input should be echoed as characters are typed. Clients MUST
correctly echo/mask user input for each prompt independently of other
prompts in the request message. Clients MUST NOT add any additional
characters to the prompt such as ": "; the server is reponsible for
supplying all text to be displayed to the user. Clients MUST also
accept empty responses from the user and pass them on as empty
strings.
A CLI client SHOULD print the name and banner, adding newlines. Then
for each prompt in turn, the client MUST display the prompt and read
Cusack FORMFEED[Page 4]
draft-ietf-secsh-genericauth-00.txt 22 Feb 1999
the user input.
A GUI client SHOULD present a dialog window, using the name (if
supplied) as the title of the window, the banner (if supplied) as a
text message inside the dialog, and the appropriate number of entry
fields with the prompts as labels. A GUI client SHOULD NOT present
each prompt in a separate window. A GUI client MUST properly handle
banners with embedded newlines. A GUI client MUST also be able to
display at least 30 characters for the name and prompts. If the
server presents names/prompts longer than 30 characters, the client
MAY truncate these fields to the length it can display.
3.2.2 SSH_USERAUTH_INPUT_PCSC
This input type is used when the user must authenticate via a
smartcard. The client will pass messages from/to the smartcard via
the PC/SC interface.
Protocol details will be provided in a later version of this
specification.
3.2.3 SSH_USERAUTH_INPUT_BIO
This input type is used when the user must authenticate via a
biometric device.
Protocol details will be provided in a later version of this
specification.
3.3 Information Responses
After obtaining the requested information from a user, the client
MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message.
The format of the response is input-type-specific.
3.3.1 SSH_USERAUTH_INPUT_KEYBOARD
When the input type is SSH_USERAUTH_INPUT_KEYBOARD, the format of the
SSH_MSG_USERAUTH_INFO_RESPONSE message is as follows:
byte SSH_MSG_USERAUTH_INFO_RESPONSE
int num responses
string response[0] (ISO-10646 UTF-8)
...
string response[n] (ISO-10646 UTF-8)
Note that the responses are encoded in ISO-10646 UTF-8. It is up to
Cusack FORMFEED[Page 5]
draft-ietf-secsh-genericauth-00.txt 22 Feb 1999
the server how it interprets the responses and validates them.
However, if the client reads the responses in some other encoding
(e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8
before transmitting, and the server MUST convert the responses to the
encoding used on that system that is needed to verify them.
Upon receiving the response, the server MUST send a
SSH_MSG_USERAUTH_FAILURE message if the number of responses is not
the same as the number of prompts, or if validation of the responses
fails.
If validation of the responses is successful, and no further
information is needed from the user, the server MUST respond with a
SSH_MSG_USERAUTH_SUCCESS message.
3.3.2 SSH_USERAUTH_INPUT_PCSC
Protocol details will be provided in a later version of this
specification.
3.3.3 SSH_USERAUTH_INPUT_BIO
Protocol details will be provided in a later version of this
specification.
4. Authentication Example
Here is an example exchange between a client and server:
C: byte SSH_MSG_USERAUTH_REQUEST
C: string "foo"
C: string "ssh-connection"
C: string "password-plus"
C: int 1
C: int SSH_USERAUTH_INPUT_KEYBOARD
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: int SSH_USERAUTH_INPUT_KEYBOARD
S: boolean TRUE
S: string "Password Authentication"
S: boolean TRUE
S: string "Enter password for foo"
S: int 1
S: string "Password: "
S: boolean FALSE
S: string "en-US"
[Client prompts user for password]
Cusack FORMFEED[Page 6]
draft-ietf-secsh-genericauth-00.txt 22 Feb 1999
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1
C: string "bar"
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: int SSH_USERAUTH_INPUT_KEYBOARD
S: boolean TRUE
S: string "Password Expired"
S: boolean TRUE
S: string "Your password has expired."
S: int 2
S: string "Enter new password: "
S: boolean FALSE
S: string "Enter it again: "
S: boolean FALSE
S: string "en-US"
[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
5. Protocol constants
The following method-specific constants are used with this
authentication method:
Message exchanges:
SSH_MSG_USERAUTH_INFO_REQUEST 60
SSH_MSG_USERAUTH_INFO_RESPONSE 61
Input types:
SSH_USERAUTH_INPUT_KEYBOARD 1
SSH_USERAUTH_INPUT_PCSC 2
SSH_USERAUTH_INPUT_BIO 3
All negative values for input types are reserved for locally
defined methods. No method is specified for determining what
"locality" a negative input type is valid in.
6. References
Cusack FORMFEED[Page 7]
draft-ietf-secsh-genericauth-00.txt 22 Feb 1999
[PAM] Samar, V., Schemers, R., "Unified Login With Pluggable
Authentication Modules (PAM)", OSF RFC 86.0, October 1995
[RFC-1766] Alvestrand, H., "Tags for the Identification of
Languages", March 1995.
[RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode
and ISO 10646", October 1996.
[SSH-ARCH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Protocol
Architecture", Internet Draft, draft-secsh-architecture-00.txt
[SSH-TRANS] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Transport
Layer Protocol", Internet Draft, draft-secsh-transport-02.txt
[SSH-USERAUTH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH
Authentication Protocol", Internet Draft, draft-ietf-secsh-userauth-
02.txt
[SSH-CONNECT] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH
Connection Protocol", Internet Draft, draft-secsh-connect-02.txt
7. Author's Address
Frank Cusack
Qwest Internet Solutions
1200 Harbor Blvd, 8th Fl.
Weehawken, NJ 07087
Email: [EMAIL PROTECTED]
Cusack FORMFEED[Page 8]
