draft-ietf-secsh-auth-kbdinteract-04.txt   draft-ietf-secsh-auth-kbdinteract-05.txt 
Network Working Group F. Cusack Network Working Group F. Cusack
INTERNET-DRAFT Google, Inc. INTERNET-DRAFT Google, Inc.
Expires April 2, 2003 M. Forssen Expires November 1, 2003 M. Forssen
Appgate AB Appgate AB
October 2, 2002 May 1, 2003
Generic Message Exchange Authentication For SSH Generic Message Exchange Authentication For SSH
<draft-ietf-secsh-auth-kbdinteract-04.txt> <draft-ietf-secsh-auth-kbdinteract-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. 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.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. <http://www.ietf.org/ietf/1id-abstracts.txt>.
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>.
This Internet-Draft will expire on April 2, 2003. This Internet-Draft will expire on November 1, 2003.
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 support a whole class of authentication the SSH client to support a whole class of authentication
mechanism(s) without knowing the specifics of the actual mechanism(s) without knowing the specifics of the actual
authentication mechanism(s). authentication mechanism(s).
1. Introduction 1. Introduction
The SSH authentication protocol is a general-purpose user The SSH authentication protocol [SSH-USERAUTH] is a general-purpose
authentication protocol. It is intended to be run over the SSH user 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 authentication protocol
underlying protocols provide integrity and confidentiality assumes that the underlying protocols provide integrity and
protection. confidentiality protection.
This document describes a general purpose authentication method for This document describes a general purpose authentication method for
the SSH protocol. This method is suitable for interactive the SSH authentication protocol. This method is suitable for
authentication methods which do not need any special software support interactive authentication methods which do not need any special
on the client side. Instead all authentication data should be software support on the client side. Instead all authentication data
entered via the keyboard. The major goal of this method is to allow should be entered via the keyboard. The major goal of this method is
the SSH client to have little or no knowledge of the specifics of the to allow the SSH client to have little or no knowledge of the
underlying authentication mechanism(s) used by the SSH server. This specifics of the underlying authentication mechanism(s) used by the
will allow the server to arbitrarily select or change the underlying SSH server. This will allow the server to arbitrarily select or
authentication mechanism(s) without having to update client code. 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 document [SSH-ARCH] and the SSH authentication document
[SSH-USERAUTH]. This document freely uses terminology and notation [SSH-USERAUTH]. This document freely uses terminology and notation
from both documents without reference or further explanation. from 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
described here since some aspects of the protocol are specifically described here anyway since some aspects of the protocol are
designed based on user interface issues, and omitting this specifically designed based on user interface issues, and omitting
information may lead to incompatible or awkward implementations. this information may lead to incompatible or awkward implementations.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in [RFC-2119].
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 to add new mechanisms for authentication as all clients difficult to add new mechanisms for authentication as all clients
must be updated to support the new mechanism. With the generic must be updated to support the new mechanism. With the generic
method defined here, clients will not require code changes to support method defined here, clients will not require code changes to support
new authentication mechanisms, and if a separate authentication layer new authentication mechanisms, and if a separate authentication layer
is used, such as [PAM], then the server may not need any code changes is used, such as [PAM], then the server may not need any code changes
skipping to change at page 3, line 32 skipping to change at page 3, line 34
SSM_MSG_USERAUTH_INFO_RESPONSE message. The server MUST NOT send SSM_MSG_USERAUTH_INFO_RESPONSE message. The server MUST NOT send
another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the
answer from the client. 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, as defined in [RFC-2279])
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-3066]) string language tag (as defined in [RFC-3066])
string submethods (ISO-10646 UTF-8) string submethods (ISO-10646 UTF-8)
The language tag is deprecated and SHOULD be the empty string. It The language tag is deprecated and SHOULD be the empty string. It
may be removed in a future revision of this specification. The may be removed in a future revision of this specification. The
server SHOULD instead select the language used based on the tags server SHOULD instead select the language used based on the tags
communicated during key exchange [SSH-TRANS]. communicated during key exchange [SSH-TRANS].
skipping to change at page 7, line 40 skipping to change at page 7, line 40
mechanisms that must be used to authenticate the user). mechanisms that must be used to authenticate the user).
If the server intends to respond with a failure message, it MAY delay If the server intends to respond with a failure message, it MAY delay
for an implementation-dependent time before sending to the client. for an implementation-dependent time before sending to the client.
It is suspected that implementations are likely to make the time It is suspected that implementations are likely to make the time
delay a configurable, a suggested default is 2 seconds. delay a configurable, a suggested default is 2 seconds.
4. Authentication Examples 4. Authentication Examples
Here are two example exchanges between a client and server. The Here are two example exchanges between a client and server. The
first is an example of a challenge/response implementation. This is first is an example of challenge/response with a handheld token.
an authentication that is not otherwise possible with other This is an authentication that is not otherwise possible with other
authentication methods. authentication methods.
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 "" C: string ""
C: string "" C: string ""
S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "CRYPTOCard Authentication" S: string "CRYPTOCard Authentication"
skipping to change at page 9, line 34 skipping to change at page 9, line 34
S: string "en-US" S: string "en-US"
S: int 0 S: int 0
[Client displays message to user] [Client displays message to user]
C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 0 C: int 0
S: byte SSH_MSG_USERAUTH_SUCCESS S: byte SSH_MSG_USERAUTH_SUCCESS
5. Protocol constants 5. IANA Considerations
The userauth type "keyboard-interactive" is used for this
authentication method.
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
6. References 6. Security Considerations
The authentication protocol, and this authentication method, depends
on the security of the underlying SSH transport layer. Without the
confidentiality provided therein, any authentication data passed with
this method is subject to interception.
The number of client-server exchanges required to complete an
authentication using this method may be variable. It is possible
that an observer may gain valuable information simply by counting
that number. For example, an observer may guess that a user's
password has expired, and with further observation may be able to
determine the frequency of a site's password expiration policy.
7. References
7.1 Normative References
[PAM] Samar, V., Schemers, R., "Unified Login With
Pluggable Authentication Modules (PAM)", OSF RFC
86.0, October 1995
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997. Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC-2279] Yergeau, F., "UTF-8, a transformation format of [RFC-2279] Yergeau, F., "UTF-8, a transformation format of
Unicode and ISO 10646", RFC 2279, October 1996. Unicode and ISO 10646", RFC 2279, October 1996.
[RFC-3066] Alvestrand, H., "Tags for the Identification of [RFC-3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001. Languages", BCP 47, RFC 3066, January 2001.
[SSH-ARCH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and [SSH-ARCH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and
skipping to change at page 11, line 5 skipping to change at page 11, line 5
[SSH-TRANS] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and [SSH-TRANS] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and
Lehtinen, S., "SSH Transport Layer Protocol", work in Lehtinen, S., "SSH Transport Layer Protocol", work in
progress, draft-ietf-secsh-transport-15.txt, progress, draft-ietf-secsh-transport-15.txt,
September, 2002. September, 2002.
[SSH-USERAUTH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and [SSH-USERAUTH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and
Lehtinen, S., "SSH Authentication Protocol", work in Lehtinen, S., "SSH Authentication Protocol", work in
progress, draft-ietf-secsh-userauth-16.txt, progress, draft-ietf-secsh-userauth-16.txt,
September, 2002. September, 2002.
7. Author's Addresses 7.2 Informative References
[PAM] Samar, V., Schemers, R., "Unified Login With
Pluggable Authentication Modules (PAM)", OSF RFC
86.0, October 1995
8. Author's Addresses
Frank Cusack Frank Cusack
Google, Inc. Google, Inc.
2400 Bayshore Parkway 2400 Bayshore Parkway
Mountain View, CA 94043 Mountain View, CA 94043
Email: frank@google.com Email: frank@google.com
Martin Forssen Martin Forssen
Appgate AB Appgate AB
Stora Badhusgatan 18-20 Stora Badhusgatan 18-20
 End of changes. 

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