Sorry for the length.
Here is another version of the draft. Please comment before Friday
so I can submit a reasonably non-controversial version :)
before the conference deadline.
I'd like to address a few of the comments:
In message <[EMAIL PROTECTED]>,
Tero Kivinen writes:
> For example most of the case the smartcard are using the normal public
> key authentication (RSA). If there are some other kinds smartcards
> that use some other authentication methods, then it is better to
> separate them based on the authentication method (public key, one time
> password) not based on the technology (smartcard).
>
I disagree. [Arguably] RSA authentication using a smartcard is much
more secure then RSA using a private key stored on disk. The current
definitions do not allow for specifying that RSA must be done via
a smartcard.
I'm not saying that authentications /should/ be classified according
to technology, only that there definitely should to be a way to
"mandate" that an authentication uses a certain technology.
That said, I don't know how to FORCE a user to use a smartcard
vs. a disk-based key -- a "non-compliant" client implementation
could ignore any flag from the server saying "use x technology".
Without such a way to FORCE such compliance, a technology flag
is moot. If a publickey auth relies on intrinsic server knowledge
of the public key, it may be administratively possible to force
compliance (and a technology flag may not be /required/), but
if publickey auth is verified via a certificate, then it may
be difficult to force technology compliance.
> > 4. Authentication Example
> >
> > Here is an example exchange between a client and server:
> >
> > C: byte SSH_MSG_USERAUTH_REQUEST
> > C: string "foo"
...
> > S: byte SSH_MSG_USERAUTH_SUCCESS
>
> I think this example is bad, because it can already be performed using
> the basic userauth draft, it contains banners, it contains password
> queries, it contains password change-request,
I think this example is good, for the same reason -- it can already
be performed using the userauth draft. This shows how to accomplish
the same thing using this method. It shows the strength of the
generic info request -- no need for another type of message
(PASSWD_CHANGEREQ). I think how to do a challenge response
authentication becomes obvious from this example (which was my
other choice for an example). My third choice was an
administrative no-login situation, where the last info-request
contained zero num-prompts, and then a failure message.
> and it even contains
> advantage compared to this method, it can use users native language
> when printing out most of the prompts.
I don't follow you. This example can use the user's native language.
In message <>,
Martin Forssen writes:
>
> First the big issue. After some thinking I have reached the conclusion
> (this is all IMHO of course) that we do not need to try to define some
> generic protocol which can handle all smart-cards biometric devices
Yeah, I added that in as an afterthought. I agree it was poorly thought
out.
> I would feel more comfortable if we used the same list format as the
> sshauth draft does (ie a comma-separated string). I would like to
> propose the following format instead:
>
> byte SSH_MSG_USERAUTH_REQUEST
> string username
> string service
> string "password-plus"
> string methods
>
> Where methods is a comma-separated strings of supported authentication
> methods using the keyboard input type.
>
> The rationale for having the methods field is that the user may have
> multiple methods availbale (for example both SecurID and CryptoCard).
> This list should be normally be provided by the user. The server should
> also be able to ignore this field if it knows from some other context
> which method(s) are avilable for the user.
This requires client knowledge of the auth device; and a new client
would be required for each auth device. One of the goals was to
not require new client code to support new authentications that
/could/ be handled by existing methods.
Now I agree that there might be a place for the client to tell the
server which authentication devices are available, but in the end
it is up to the server to decide which device to accept. So this
could be wrapped up in the PAM service module (it could check for
a list of users it knows have a securid card, which is how I believe
the securid hack to ssh1 works, and continue on to cryptocard for
users that don't have the securid).
So as long as the input happens with the keyboard, I think specifying
the actual device is better left in the server code. Maybe you
can provide an example where the server does need to know what devices
are available?
=======
As many noticed, this draft really is meant for PAM, which is indeed
a generic keyboard-interactive authentication. I added the non-keyboard
types to attempt to deal with PAM_BINARY, but I do agree that it is
too limiting to add that into this draft. Also, PAM_BINARY is really
a kludge to make PAM do things that the original design didn't
account for.
~frank
Network Working Group F. Cusack
INTERNET-DRAFT Qwest Internet Solutions
draft-ietf-secsh-auth-kbdinteract-00.txt 24 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 authentication method for the SSH protocol, suitable for
interactive authentications where the authentication data should be
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
authentication mechanism(s) used by the SSH server.
Cusack FORMFEED[Page 1]
draft-ietf-secsh-auth-kbdinteract-00.txt 24 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 general purpose authentication method for
the SSH protocol, suitable for interactive authentications where the
authentication data should be 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 authentication mechanism(s) used by the
SSH server. This will allow the server to arbitrarily select or
change the underlying authentication mechanism(s) without having to
update client code.
The method name for this authentication method is "keyboard-
interactive".
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, and omitting this
information may lead to incompatible or awkward implementations.
2. Rationale
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 (defined in [SSH-USERAUTH]), as new (presumably
stronger) methods may be added "at will" and system security can be
transparently enhanced.
Cusack FORMFEED[Page 2]
draft-ietf-secsh-auth-kbdinteract-00.txt 24 Feb 1999
Challenge-response and One Time Password mechanisms are also easily
supported with this authentication method.
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
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 "keyboard-interactive"
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 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 help limit certain types of attacks.
3.2 Information Requests
Requests are generated from the server using the
SSH_MSG_USERAUTH_INFO_REQUEST message.
The server may send as many requests as are necessary to authenticate
the client; the client MUST be prepared to handle multiple exchanges.
The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows:
Cusack FORMFEED[Page 3]
draft-ietf-secsh-auth-kbdinteract-00.txt 24 Feb 1999
byte SSH_MSG_USERAUTH_INFO_REQUEST
string name (ISO-10646 UTF-8)
string instruction (ISO-10646 UTF-8)
int num-prompts
string prompt[1] (ISO-10646 UTF-8)
boolean echo[1]
...
string prompt[num-prompts] (ISO-10646 UTF-8)
boolean echo[num-prompts]
string language tag (as defined in [RFC-1766])
The server SHOULD limit the length of the name and prompt fields to
30 characters. No restrictions are placed on the instruction field.
The name and instruction fields MAY be empty strings, the client MUST
be prepared to handle this correctly.
The num-prompts field may be `0', in which case there will be no
prompt/echo fields in the message, but the client MUST still display
the name and instruction fields (as described below).
3.3 User Interface
Upon receiving a request message, the client SHOULD prompt the user
as follows:
For each prompt, the corresponding 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 instruction (if supplied),
adding newlines. Then for each prompt in turn, the client MUST
display the prompt and read the user input.
A GUI client SHOULD present a dialog window, using the name (if
supplied) as the title of the window, the instruction (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 an instruction 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. If
Cusack FORMFEED[Page 4]
draft-ietf-secsh-auth-kbdinteract-00.txt 24 Feb 1999
the client does truncate any fields, there SHOULD be an obvious
indication that such truncation has occured.
3.4 Information Responses
After obtaining the requested information from the user, the client
MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message.
The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as
follows:
byte SSH_MSG_USERAUTH_INFO_RESPONSE
int num-responses
string response[1] (ISO-10646 UTF-8)
...
string response[num-responses] (ISO-10646 UTF-8)
Note that the responses are encoded in ISO-10646 UTF-8. It is up to
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.
In the case that the server sends a `0' num-prompts field in the
request message, the client MUST send a response message with a `0'
num-responses field.
After receiving the response, the server MUST send either a
SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another
SSH_MSG_USERAUTH_INFO_REQUEST message.
If the server fails to authenticate the user (through the underlying
authentication mechanism(s)), it SHOULD NOT send another request
message(s) in an attempt to obtain new authentication data, instead
it SHOULD send a failure message. The only time the server should
send multiple request messages is if additional authentication data
is needed (i.e., because there are multiple underlying authentication
mechanisms that must be used to authenticate the user).
If the num-responses field does not match the num-prompts field in
the request message, the server MUST send a failure message.
If the server responds with a failure message, it SHOULD delay a
minimum of 2 seconds before sending the failure message, to limit
certain types of attacks.
4. Authentication Example
Cusack FORMFEED[Page 5]
draft-ietf-secsh-auth-kbdinteract-00.txt 24 Feb 1999
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 "keyboard-interactive"
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Authentication"
S: string "Enter password for foo"
S: int 1
S: string "Password: "
S: boolean FALSE
S: string "en-US"
[Client prompts user for password]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1
C: string "bar"
S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Expired"
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:
SSH_MSG_USERAUTH_INFO_REQUEST 60
SSH_MSG_USERAUTH_INFO_RESPONSE 61
Cusack FORMFEED[Page 6]
draft-ietf-secsh-auth-kbdinteract-00.txt 24 Feb 1999
6. References
[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-ietf-secsh-architecture-00.txt
[SSH-CONNECT] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH
Connection Protocol", Internet Draft, draft-ietf-secsh-connect-02.txt
[SSH-TRANS] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Transport
Layer Protocol", Internet Draft, draft-ietf-secsh-transport-02.txt
[SSH-USERAUTH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH
Authentication Protocol", Internet Draft, draft-ietf-secsh-userauth-
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 7]
