draft-ietf-secsh-auth-kbdinteract-05.txt   draft-ietf-secsh-auth-kbdinteract-06.txt 
Network Working Group F. Cusack Network Working Group F. Cusack
INTERNET-DRAFT Google, Inc. INTERNET-DRAFT Google, Inc.
Expires November 1, 2003 M. Forssen Expires November 1, 2004 M. Forssen
Appgate AB Appgate AB
May 1, 2003 May 1, 2004
Generic Message Exchange Authentication For SSH Generic Message Exchange Authentication For SSH
<draft-ietf-secsh-auth-kbdinteract-05.txt> <draft-ietf-secsh-auth-kbdinteract-06.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 November 1, 2003. This Internet-Draft will expire on November 1, 2004.
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
skipping to change at page 3, line 34 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, as defined in [RFC-2279]) 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. 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].
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. The language to be
used if the server does not support the requested language is used if the server does not support the requested language 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 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) which 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 which the user and
the server needs to agree upon. the 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.
skipping to change at page 4, line 40 skipping to change at page 4, line 40
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) which 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 just 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
authentication is required for the user in question, however a better
approach, for reasons discussed above, might be to reply with a
SSH_MSG_USERAUTH_INFO_REQUEST message and ignore (don't validate) 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.
skipping to change at page 5, line 18 skipping to change at page 5, line 22
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
may be removed in a future revision of this specification. The
server SHOULD instead select the language used based on the tags
communicated during key exchange [SSH-TRANS].
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
this protocol. The language tag SHOULD NOT be used for language
selection for messages outside of this protocol. The language to be
used if the server does not support the requested language is
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 user23@host.domain" and a prompt field "Password authentication for user23@host.domain" and a prompt field
of "Password: ". It is expected that this authentication method of "Password: ". It is expected that this authentication method
would typically be backended by [PAM] and so such choices would not would typically be backended 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 language tag SHOULD describe the language used in the textual
fields. If the server does not know the language used, or if
multiple languages are used, the language tag MUST be the empty
string.
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
skipping to change at page 6, line 19 skipping to change at page 6, line 31
because its windows lack titles; it SHOULD instead find another way because its windows lack titles; it SHOULD instead find another way
to display this information. If prompts are presented in a dialog to display this information. If prompts are presented in a dialog
window, then the client SHOULD NOT present each prompt in a separate window, then the client SHOULD NOT present each prompt in a separate
window. 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 occured. there MUST be an obvious indication that such truncation has
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 or
not the user input should be echoed as characters are typed. Clients not the user input should be echoed as characters are typed. Clients
SHOULD correctly echo/mask user input for each prompt independently SHOULD correctly echo/mask user input for each prompt independently
of other prompts in the request message. If a client does not honor of other prompts in the request message. If a client does not honor
the echo field for whatever reason, then the client MUST err on the the echo field for whatever reason, then the client MUST err on the
skipping to change at page 7, line 35 skipping to change at page 7, line 46
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 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 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"
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"
S: string "The challenge is '14315716'" S: string "The challenge is '14315716'"
S: string "en-US" S: string "en-US"
S: int 1 S: int 1
S: string "Response: " S: string "Response: "
S: boolean TRUE S: boolean TRUE
[Client prompts user for password] [Client prompts user for password]
skipping to change at page 9, line 47 skipping to change at page 9, line 51
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, depends The authentication protocol, and this authentication method, depend
on the security of the underlying SSH transport layer. Without the on 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 frequency of a site's password expiration policy. determine the password lifetime imposed by a site's password
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 Level", BCP 14, RFC 2119, March 1997.
[RFC-2279] Yergeau, F., "UTF-8, a transformation format of [RFC-3629] Yergeau, F., "UTF-8, a transformation format of
Unicode and ISO 10646", RFC 2279, October 1996. Unicode and ISO 10646", 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] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and [SSH-ARCH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and
Lehtinen, S., "SSH Protocol Architecture", work in Lehtinen, S., "SSH Protocol Architecture", work in
progress, draft-ietf-secsh-architecture-13.txt, progress, draft-ietf-secsh-architecture-15.txt,
September, 2002. October, 2003.
[SSH-CONNECT] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and [SSH-CONNECT] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and
Lehtinen, S., "SSH Connection Protocol", work in Lehtinen, S., "SSH Connection Protocol", work in
progress, draft-ietf-secsh-connect-16.txt, September, progress, draft-ietf-secsh-connect-18.txt, October,
2002. 2003.
[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-17.txt, October,
September, 2002. 2003.
[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-18.txt,
September, 2002. September, 2002.
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. Author's Addresses 8. Authors' 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
SE-411 21 Gothenburg SE-411 21 Gothenburg
SWEDEN SWEDEN
Email: maf@appgate.com Email: maf@appgate.com
9. Intellectual Property and Copyright Statements
9.1. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
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.
9.2 Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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