draft-ietf-secsh-auth-kbdinteract-07.txt   rfc4256.txt 
Network Working Group F. Cusack Network Working Group F. Cusack
INTERNET-DRAFT Google, Inc. Request for Comments: 4256 savecore.net
Expires September 21, 2005 M. Forssen Category: Standards Track M. Forssen
Appgate AB AppGate Network Security AB
March 21, 2005 January 2006
Generic Message Exchange Authentication For SSH
<draft-ietf-secsh-auth-kbdinteract-07.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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."
The list of current Internet-Drafts can be accessed at Generic Message Exchange Authentication for
<http://www.ietf.org/1id-abstracts.html>. the Secure Shell Protocol (SSH)
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
<http://www.ietf.org/shadow.html>.
This Internet-Draft will expire on September 21, 2005. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
SSH is a protocol for secure remote login and other secure network The Secure Shell Protocol (SSH) is a protocol for secure remote login
services over an insecure network. This document describes a general and other secure network services over an insecure network. This
purpose authentication method for the SSH protocol, suitable for document describes a general purpose authentication method for the
interactive authentications where the authentication data should be SSH protocol, suitable for interactive authentications where the
entered via a keyboard (or equivalent alphanumeric input device). authentication data should be entered via a keyboard (or equivalent
The major goal of this method is to allow the SSH client to support a alphanumeric input device). The major goal of this method is to
whole class of authentication mechanism(s) without knowing the allow the SSH client to support a whole class of authentication
specifics of the actual authentication mechanism(s). mechanism(s) without knowing the specifics of the actual
authentication mechanism(s).
1. Introduction 1. Introduction
The SSH authentication protocol [SSH-USERAUTH] is a general-purpose The SSH authentication protocol [SSH-USERAUTH] is a general-purpose
user 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 authentication protocol transport layer protocol [SSH-TRANS]. The authentication protocol
assumes that the underlying protocols provide integrity and assumes that the underlying protocols provide integrity and
confidentiality protection. confidentiality protection.
This document describes a general purpose authentication method for This document describes a general purpose authentication method for
the SSH authentication protocol. This method is suitable for the SSH authentication protocol. This method is suitable for
interactive authentication methods which do not need any special interactive authentication methods that do not need any special
software support on the client side. Instead all authentication data software support on the client side. Instead, all authentication
should be entered via the keyboard. The major goal of this method is data should be entered via the keyboard. The major goal of this
to allow the SSH client to have little or no knowledge of the method is to allow the SSH client to have little or no knowledge of
specifics of the underlying authentication mechanism(s) used by the the specifics of the underlying authentication mechanism(s) used by
SSH server. This will allow the server to arbitrarily select or the SSH server. This will allow the server to arbitrarily select or
change the underlying authentication mechanism(s) without having to change the underlying authentication mechanism(s) without having to
update client code. 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 somewhat out of the scope of a protocol specification, it is
described here anyway since some aspects of the protocol are described here anyway because some aspects of the protocol are
specifically designed based on user interface issues, and omitting specifically designed based on user interface issues, and omitting
this 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
either. 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 However, this authentication method is limited to authentication
mechanisms which do not require any special code, such as hardware mechanisms that 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 an
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 an
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 an
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, as defined in [RFC-3629]) string user name (ISO-10646 UTF-8, as defined in [RFC-3629])
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. Instead,
server SHOULD instead select the language used based on the tags the server SHOULD select the language to be used based on the tags
communicated during key exchange [SSH-TRANS]. communicated during key exchange [SSH-TRANS].
If the language tag is not the empty string, the server SHOULD use If the language tag is not the empty string, the server SHOULD use
the specified language for any messages sent to the client as part of the specified language for any messages sent to the client as part of
this protocol. The language tag SHOULD NOT be used for language this protocol. The language tag SHOULD NOT be used for language
selection for messages outside of this protocol. The language to be selection for messages outside of this protocol. If the server does
used if the server does not support the requested language is not support the requested language, the language to be used is
implementation-dependent. implementation-dependent.
The submethods field is included so the user can give a hint of which The submethods field is included so the user can give a hint of which
actual methods he wants to use. It is a comma-separated list of actual methods he wants to use. It is a comma-separated list of
authentication submethods (software or hardware) which the user authentication submethods (software or hardware) that the user
prefers. If the client has knowledge of the submethods preferred by prefers. If the client has knowledge of the submethods preferred by
the user, presumably through a configuration setting, it MAY use the the user, presumably through a configuration setting, it MAY use the
submethods field to pass this information to the server. Otherwise submethods field to pass this information to the server. Otherwise,
it MUST send the empty string. it MUST send the empty string.
The actual names of the submethods is something which the user and The actual names of the submethods is something the user and the
the server need to agree upon. server need to agree upon.
Server interpretation of the submethods field is implementation- Server interpretation of the submethods field is implementation-
dependent. dependent.
One possible implementation strategy of the submethods field on the One possible implementation strategy of the submethods field on the
server is that, unless the user may use multiple different server is that, unless the user may use multiple different
submethods, the server ignores this field. If the user may submethods, the server ignores this field. If the user may
authenticate using one of several different submethods the server authenticate using one of several different submethods, the server
should treat the submethods field as a hint on which submethod the should treat the submethods field as a hint on which submethod the
user wants to use this time. 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 an 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
SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look just SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s), which look just
like the one(s) which would have been sent in cases where like the one(s) that would have been sent in cases where
authentication should proceed, and then send the failure message authentication should proceed, and then send the failure message
(after a suitable delay, as described below). The goal is to make it (after a suitable delay, as described below). The goal is to make it
impossible to find valid usernames by just comparing the results when impossible to find valid usernames by comparing the results when
authenticating as different users. authenticating as different users.
The server MAY reply with a SSH_MSG_USERAUTH_SUCCESS message if no The server MAY reply with an SSH_MSG_USERAUTH_SUCCESS message if no
authentication is required for the user in question, however a better authentication is required for the user in question. However, a
approach, for reasons discussed above, might be to reply with a better approach, for reasons discussed above, might be to reply with
SSH_MSG_USERAUTH_INFO_REQUEST message and ignore (don't validate) the an SSH_MSG_USERAUTH_INFO_REQUEST message and ignore (don't validate)
response. the response.
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 NOT ever have more than one However, the server MUST NOT ever have more than one
SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is, it may SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is, it may
not send another request before the client has answered. 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-3066]) string language tag (as defined in [RFC-3066])
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]
... ...
string prompt[num-prompts] (ISO-10646 UTF-8) string prompt[num-prompts] (ISO-10646 UTF-8)
boolean echo[num-prompts] boolean echo[num-prompts]
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. Instead,
server SHOULD instead select the language used based on the tags the server SHOULD select the language used based on the tags
communicated during key exchange [SSH-TRANS]. communicated during key exchange [SSH-TRANS].
If the language tag is not the empty string, the server SHOULD use If the language tag is not the empty string, the server SHOULD use
the specified language for any messages sent to the client as part of the specified language for any messages sent to the client as part of
this protocol. The language tag SHOULD NOT be used for language this protocol. The language tag SHOULD NOT be used for language
selection for messages outside of this protocol. The language to be selection for messages outside of this protocol. If the server does
used if the server does not support the requested language is not support the requested language, the language to be used is
implementation-dependent. implementation-dependent.
The server SHOULD take into consideration that some clients may not The server SHOULD take into consideration that some clients may not
be able to properly display a long name or prompt field (see next be able to properly display a long name or prompt field (see next
section), and limit the lengths of those fields if possible. For section), and limit the lengths of those fields if possible. For
example, instead of an instruction field of "Enter Password" and a example, instead of an instruction field of "Enter Password" and a
prompt field of "Password for user23@host.domain: ", a better choice prompt field of "Password for user23@host.domain: ", a better choice
might be an instruction field of might be an instruction field of "Password authentication for
"Password authentication for user23@host.domain" and a prompt field user23@host.domain" and a prompt field of "Password: ". It is
of "Password: ". It is expected that this authentication method expected that this authentication method would typically be backended
would typically be backended by [PAM] and so such choices would not by [PAM] and so such choices would not be possible.
be possible.
The name and instruction fields MAY be empty strings, the client MUST The name and instruction fields MAY be empty strings; the client MUST
be prepared to handle this correctly. The prompt field(s) MUST NOT be prepared to handle this correctly. The prompt field(s) MUST NOT
be empty strings. be empty strings.
The num-prompts field may be `0', in which case there will be no The num-prompts field may be `0', in which case there will be no
prompt/echo fields in the message, but the client SHOULD still prompt/echo fields in the message, but the client SHOULD still
display the name and instruction fields (as described below). display the name and instruction fields (as described below).
3.3 User Interface 3.3. User Interface
Upon receiving a request message, the client SHOULD prompt the user Upon receiving a request message, the client SHOULD prompt the user
as follows: as follows:
A command line interface (CLI) client SHOULD print the name and A command line interface (CLI) client SHOULD print the name and
instruction (if non-empty), adding newlines. Then for each prompt in instruction (if non-empty), adding newlines. Then, for each prompt
turn, the client SHOULD display the prompt and read the user input. in turn, the client SHOULD display the prompt and read the user
input.
A graphical user interface (GUI) client has many choices on how to A graphical user interface (GUI) client has many choices on how to
prompt the user. One possibility is to use the name field (possibly prompt the user. One possibility is to use the name field (possibly
prefixed with the application's name) as the title of a dialog window prefixed with the application's name) as the title of a dialog window
in which the prompt(s) are presented. In that dialog window, the in which the prompt(s) are presented. In that dialog window, the
instruction field would be a text message, and the prompts would be instruction field would be a text message, and the prompts would be
labels for text entry fields. All fields SHOULD be presented to the labels for text entry fields. All fields SHOULD be presented to the
user, for example an implementation SHOULD NOT discard the name field user. For example, an implementation SHOULD NOT discard the name
because its windows lack titles; it SHOULD instead find another way field because its windows lack titles; instead, it SHOULD find
to display this information. If prompts are presented in a dialog another way to display this information. If prompts are presented in
window, then the client SHOULD NOT present each prompt in a separate a dialog window, then the client SHOULD NOT present each prompt in a
window. separate window.
All clients MUST properly handle an instruction field with embedded All clients MUST properly handle an instruction field with embedded
newlines. They SHOULD also be able to display at least 30 characters newlines. They SHOULD also be able to display at least 30 characters
for the name and prompts. If the server presents names or prompts for the name and prompts. If the server presents names or prompts
longer than 30 characters, the client MAY truncate these fields to longer than 30 characters, the client MAY truncate these fields to
the length it can display. If the client does truncate any fields, the length it can display. If the client does truncate any fields,
there MUST be an obvious indication that such truncation has there MUST be an obvious indication that such truncation has
occurred. The instruction field SHOULD NOT be truncated. occurred. The instruction field SHOULD NOT be truncated.
Clients SHOULD use control character filtering as discussed in Clients SHOULD use control character filtering, as discussed in
[SSH-ARCH] to avoid attacks by including terminal control characters [SSH-ARCH], to avoid attacks by including terminal control characters
in the fields to be displayed. in the fields to be displayed.
For each prompt, the corresponding echo field indicates whether or For each prompt, the corresponding echo field indicates whether the
not the user input should be echoed as characters are typed. Clients user input should be echoed as characters are typed. Clients SHOULD
SHOULD correctly echo/mask user input for each prompt independently correctly echo/mask user input for each prompt independently of other
of other prompts in the request message. If a client does not honor prompts in the request message. If a client does not honor the echo
the echo field for whatever reason, then the client MUST err on the field for whatever reason, then the client MUST err on the side of
side of masking input. A GUI client might like to have a checkbox masking input. A GUI client might like to have a checkbox toggling
toggling echo/mask. Clients SHOULD NOT add any additional characters echo/mask. Clients SHOULD NOT add any additional characters to the
to the prompt such as ": " (colon-space); the server is responsible prompt, such as ": " (colon-space); the server is responsible for
for supplying all text to be displayed to the user. Clients MUST supplying all text to be displayed to the user. Clients MUST also
also accept empty responses from the user and pass them on as empty accept empty responses from the user and pass them on as empty
strings. strings.
3.4 Information Responses 3.4. Information Responses
After obtaining the requested information from the user, the client After obtaining the requested information from the user, the client
MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message. MUST respond with an SSH_MSG_USERAUTH_INFO_RESPONSE message.
The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as
follows: follows:
byte SSH_MSG_USERAUTH_INFO_RESPONSE byte SSH_MSG_USERAUTH_INFO_RESPONSE
int num-responses int num-responses
string response[1] (ISO-10646 UTF-8) string response[1] (ISO-10646 UTF-8)
... ...
string response[num-responses] (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 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. the server how it interprets the responses and validates them.
However, if the client reads the responses in some other encoding 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 (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8
before transmitting. before transmitting.
From an internationalization standpoint, it is desired that if a user From an internationalization standpoint, it is desired that if a user
enters responses the authentication process will work regardless of enters responses, the authentication process will work regardless of
what OS and client software they are using. Doing so requires what OS and client software they are using. Doing so requires
normalization. Systems supporting non-ASCII passwords SHOULD always normalization. Systems supporting non-ASCII passwords SHOULD always
normalize passwords and usernames whenever they are added to the normalize passwords and usernames whenever they are added to the
database, or compared (with or without hashing) to existing entries database, or compare them (with or without hashing) to existing
in the database. SSH implementations that both store the passwords entries in the database. SSH implementations that both store the
and compare them SHOULD use [SASLPREP] for normalization. passwords and compare them SHOULD use [SASLPREP] for normalization.
If the num-responses field does not match the num-prompts field in If the num-responses field does not match the num-prompts field in
the request message, the server MUST send a failure message. the request message, the server MUST send a failure message.
In the case that the server sends a `0' num-prompts field in the 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' request message, the client MUST send a response message with a `0'
num-responses field to complete the exchange. num-responses field to complete the exchange.
The responses MUST be ordered as the prompts were ordered. That is, The responses MUST be ordered as the prompts were ordered. That is,
response[n] MUST be the answer to prompt[n]. response[n] MUST be the answer to prompt[n].
After receiving the response, the server MUST send either a After receiving the response, the server MUST send either an
SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another
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 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 it 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 configurable; a suggested default is 2 seconds. delay 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 challenge/response with a handheld token. first is an example of challenge/response with a handheld token.
This is 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"
skipping to change at page 8, line 40 skipping to change at page 9, line 5
S: boolean TRUE 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 "6d757575" C: string "6d757575"
S: byte SSH_MSG_USERAUTH_SUCCESS S: byte SSH_MSG_USERAUTH_SUCCESS
The second example is of a standard password authentication, in The second example is a standard password authentication; in this
this case the user's password is expired. case, the user's password is expired.
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 "Password Authentication"
S: string "" S: string ""
S: string "en-US" S: string "en-US"
S: int 1 S: int 1
S: string "Password: " S: string "Password: "
S: boolean FALSE S: boolean FALSE
[Client prompts user for password] [Client prompts user for password]
skipping to change at page 10, line 5 skipping to change at page 10, line 12
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. IANA Considerations 5. IANA Considerations
The userauth type "keyboard-interactive" is used for this The userauth type "keyboard-interactive" is used for this
authentication method. 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. Security Considerations 6. Security Considerations
The authentication protocol, and this authentication method, depend The authentication protocol and this authentication method depend on
on the security of the underlying SSH transport layer. Without the the security of the underlying SSH transport layer. Without the
confidentiality provided therein, any authentication data passed with confidentiality provided therein, any authentication data passed with
this method is subject to interception. this method is subject to interception.
The number of client-server exchanges required to complete an The number of client-server exchanges required to complete an
authentication using this method may be variable. It is possible authentication using this method may be variable. It is possible
that an observer may gain valuable information simply by counting that an observer may gain valuable information simply by counting
that number. For example, an observer may guess that a user's that number. For example, an observer may guess that a user's
password has expired, and with further observation may be able to password has expired, and with further observation may be able to
determine the password lifetime imposed by a site's password determine the password lifetime imposed by a site's password
expiration policy. expiration policy.
7. References 7. References
7.1 Normative References 7.1. Normative References
[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 Levels", BCP 14, RFC 2119, March 1997.
[RFC-3629] Yergeau, F., "UTF-8, a transformation format of [RFC-3629] Yergeau, F., "UTF-8, a transformation format of ISO
Unicode and ISO 10646", RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[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] Lonvick, C., "SSH Protocol Architecture", work in [SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
progress, draft-ietf-secsh-architecture-22.txt, March (SSH) Protocol Architecture", RFC 4251, January 2006.
2005.
[SSH-CONNECT] Lonvick, C., "SSH Connection Protocol", work in
progress, draft-ietf-secsh-connect-25.txt, March
2005.
[SSH-TRANS] Lonvick, C., "SSH Transport Layer Protocol", work in [SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
progress, draft-ietf-secsh-transport-24.txt, March (SSH) Authentication Protocol", RFC 4252, January
2005. 2006.
[SSH-USERAUTH] Lonvick, C., "SSH Authentication Protocol", work in [SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
progress, draft-ietf-secsh-userauth-27.txt, March (SSH) Transport Layer Protocol", RFC 4253, January
2005. 2006.
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep profile for user [SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User
names and passwords", work in progress, Names and Passwords", RFC 4013, February 2005.
draft-ietf-sasl-saslprep-10, July 2004.
7.2 Informative References 7.2. Informative References
[PAM] Samar, V., Schemers, R., "Unified Login With [PAM] Samar, V., Schemers, R., "Unified Login With
Pluggable Authentication Modules (PAM)", OSF RFC Pluggable Authentication Modules (PAM)", OSF RFC
86.0, October 1995 86.0, October 1995.
8. Authors' Addresses Authors' Addresses
Frank Cusack Frank Cusack
Google, Inc. savecore.net
1600 Amphitheatre Parkway
Mountain View, CA 94043 EMail: frank@savecore.net
Email: frank@google.com
Martin Forssen Martin Forssen
Appgate AB AppGate Network Security AB
Stora Badhusgatan 18-20 Otterhallegatan 2
SE-411 21 Gothenburg SE-411 18 Gothenburg
SWEDEN SWEDEN
Email: maf@appgate.com
9. Intellectual Property and Copyright Statements EMail: maf@appgate.com
9.1 IPR Disclosure Acknowlegement Full Copyright Statement
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, and any of
which I become aware will be disclosed, in accordance with RFC 3668.
9.2 Full Copyright Statement Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78 and except as
set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS This document is subject to the rights, licenses and restrictions
IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS contained in BCP 78, and except as set forth therein, the authors
SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING retain all their rights.
TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL This document and the information contained herein are provided on an
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
FITNESS FOR A PARTICULAR PURPOSE. OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has made might or might not be available; nor does it represent that it has
any independent effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
procedures with respect to rights in RFC documents can be found in BCP on the procedures with respect to rights in RFC documents can be
78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances Copies of IPR disclosures made to the IETF Secretariat and any
of licenses to be made available, or the result of an attempt made to assurances of licenses to be made available, or the result of an
obtain a general license or permission for the use of such proprietary attempt made to obtain a general license or permission for the use of
rights by implementers or users of this specification can be obtained such proprietary rights by implementers or users of this
from the IETF on-line IPR repository at <http://www.ietf.org/ipr>. specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary
that may cover technology that may be required to implement this standard. rights that may cover technology that may be required to implement
Please address the information to the IETF at <ietf-ipr@ietf.org>. this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 73 change blocks. 
193 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/