Attached below follows a proposal for a new authentication method for
SSH2. This new method implements general challenge-response
authentication.
Some background might be in order: the company where I work "Firedoor
Network Security AB" sells a security product (Firedoor) which uses ssh
rather heavily. We currently have installations which run ssh1 and use
securid token authentication and we want to keep those customers when
we upgrade to ssh2, we would also like to use some other authentication
methods.
But nobody has added securid authentication to ssh2. Therefore we
realized that we had to do it ourselves:-) This is the first result, a
draft for a new authentication method. I am including it here to get
some feedback. We are going to implement it if nobody raises any big
objections. The code will the be free for everybody to use. The idea is
then to get SSH Communications OY and DataFellows to merge these
changes into their master versions. We would also like all other ssh2
projects to support it.
This protocol is written so that the client should not need to neither
know nor care about which challenge-response method the user really
uses. The most important issue is to get the generic support into the
clients since it is so much easier to modify a handful of servers that
hunderds of clients (the server must of course know the details of the
underlying authentication method).
I am not sure if the working group should release this as a draft or
what should be done with it. I am open to suggestions.
/MaF
not yet an I-D M. Forssen
draft-ietf-secsh-chrespauth-00.txt Firedoor Network Security AB
4 February 1999
Challenge-response authentication method for the SSH protocol
Abstract
SSH is a protocol for secure remote login and other secure network
services over an insecure network. This document describes a general
purpose challenge-response authentication method for the SSH
protocol.
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 new challenge-response authentication
method for the SSH authentication protocol. The method documented
here is a general purpose challenge-response authentication method
which can be used to support many different authentication methods,
for example SecurID and RADIUS. The rationale for a general purpose
protocol is that it is important to get support for this kind of
protocol into all clients and that it is much easier to add
specialized support for special authentication protocols in the
servers.
The method name for this authentication method is "challenge-
response".
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.
Challenge-response Authentication Method
This method permits interaction between the server and the client
during the authentication phase. The server may ask questions which
the client should answer. The authentication begins with the client
sending a SSH_MSG_USERAUTH_REQUEST message.
M. Forssen [Page 1]
not yet an I-D SSH Challenge-response authentication 4 February 1999
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service
string "challenge-response"
boolean FALSE
string method name
string response string (ISO-10646 UTF-8)
The method name is an optional name of a specific challenge-response
method, the client MAY leave this field empty. The server MAY ignore
this value if it can infer from other data which challenge-response
method is used. One way that can be inferred is when the server only
supports one challenge-response method. The method name must be the same
in all messages until the client receives a success or failure response.
Note that the response string is encoded in ISO-10646 UTF-8. The response
string contains the reply from the user to the last challenge received
from the server. Since the client initiates the authentication session
there is no challenge from the server when the first packet is sent. The
response string may in this case be left empty or filled in with what the
client thinks the server may want first.
The server MUST respond with either SSH_MSG_USERAUTH_SUCCESS,
SSH_MSG_USERAUTH_FAILURE or with a SSH_MSG_USERAUTH_CHALLENGE.
The format of a SSH_MSG_USERAUTH_CHALLENGE is:
byte SSH_MSG_USERAUTH_CHALLENGE
string challenge (ISO-10646 UTF-8)
string language tag (as defined in RFC 1766)
boolean do not echo reply
This reply contains a textual challenge which SHOULD be shown to the user
and the user should be allowed to write a reply. If the "do not echo reply"
field is TRUE then the client should treat the users input as sensitive and
not echo any entered characters (as normally done when passwords are entered).
The client should then reply to this packet with a new
SSH_MSG_USERAUTH_REQUEST with the boolean value set to TRUE to indicate that
this is an actual reply to a challenge.
The following method-specific message numbers are used by the
challenge-response authentication method.
/* Challenge */
#define SSH_MSG_USERAUTH_CHALLENGE 25
Security Considerations
M. Forssen [Page 2]
not yet an I-D SSH Challenge-response authentication 4 February 1999
The purpose of this protocol is to perform client user authentication.
It assumed that this runs over a secure transport layer protocol, which
has already authenticated the server machine, established an encrypted
communications channel, and computed a unique session identifier for
this session. The transport layer provides forward secrecy for password
authentication and other methods that rely on secret data.
The server may go into a "sleep" period after repeated unsuccessful
authentications to make key search harder.
If the transport layer does not provide encryption, authentication
methods that rely on secret data SHOULD be disabled. If it does not
provide MAC protection, requests to change authentication data (e.g.
password change) SHOULD be disabled to avoid an attacker from modifying
the ciphertext without being noticed, rendering the new authentication
data unusable (denial of service).
Several authentication methods with different security characteristics
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
user. Authentication is no stronger than the weakest combination
allowed.
References
[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
Author's Address
Martin Forssen
Firedoor Network Security AB
M. Forssen [Page 3]
not yet an I-D SSH Challenge-response authentication 4 February 1999
Stora Badhusgatan 18-20
SE-411 21 Gothenburg
SWEDEN
E-mail: [EMAIL PROTECTED]
M. Forssen [Page 4]
