< draft-ietf-secsh-auth-kbdinteract-06.txt   draft-ietf-secsh-auth-kbdinteract-07.txt >
Network Working Group F. Cusack Network Working Group F. Cusack
INTERNET-DRAFT Google, Inc. INTERNET-DRAFT Google, Inc.
Expires November 1, 2004 M. Forssen Expires September 21, 2005 M. Forssen
Appgate AB Appgate AB
May 1, 2004 March 21, 2005
Generic Message Exchange Authentication For SSH Generic Message Exchange Authentication For SSH
<draft-ietf-secsh-auth-kbdinteract-06.txt> <draft-ietf-secsh-auth-kbdinteract-07.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 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 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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/1id-abstracts.html>.
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, 2004. This Internet-Draft will expire on September 21, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
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 (or equivalent alphanumeric input device).
the SSH client to support a whole class of authentication The major goal of this method is to allow the SSH client to support a
mechanism(s) without knowing the specifics of the actual whole class of authentication mechanism(s) without knowing the
authentication mechanism(s). 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
skipping to change at page 7, line 21 skipping to change at page 7, line 21
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
enters responses the authentication process will work regardless of
what OS and client software they are using. Doing so requires
normalization. Systems supporting non-ASCII passwords SHOULD always
normalize passwords and usernames whenever they are added to the
database, or compared (with or without hashing) to existing entries
in the database. SSH implementations that both store the 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. 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 a
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
skipping to change at page 10, line 29 skipping to change at page 10, line 44
[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-3629] Yergeau, F., "UTF-8, a transformation format of [RFC-3629] Yergeau, F., "UTF-8, a transformation format of
Unicode and ISO 10646", RFC 3629, November 2003. 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] Lonvick, C., "SSH Protocol Architecture", work in
Lehtinen, S., "SSH Protocol Architecture", work in progress, draft-ietf-secsh-architecture-22.txt, March
progress, draft-ietf-secsh-architecture-15.txt, 2005.
October, 2003.
[SSH-CONNECT] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and [SSH-CONNECT] Lonvick, C., "SSH Connection Protocol", work in
Lehtinen, S., "SSH Connection Protocol", work in progress, draft-ietf-secsh-connect-25.txt, March
progress, draft-ietf-secsh-connect-18.txt, October, 2005.
2003.
[SSH-TRANS] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and [SSH-TRANS] Lonvick, C., "SSH Transport Layer Protocol", work in
Lehtinen, S., "SSH Transport Layer Protocol", work in progress, draft-ietf-secsh-transport-24.txt, March
progress, draft-ietf-secsh-transport-17.txt, October, 2005.
2003.
[SSH-USERAUTH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and [SSH-USERAUTH] Lonvick, C., "SSH Authentication Protocol", work in
Lehtinen, S., "SSH Authentication Protocol", work in progress, draft-ietf-secsh-userauth-27.txt, March
progress, draft-ietf-secsh-userauth-18.txt, 2005.
September, 2002.
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep profile for user
names and passwords", work in progress,
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 8. Authors' Addresses
Frank Cusack Frank Cusack
Google, Inc. Google, Inc.
2400 Bayshore Parkway 1600 Amphitheatre 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. Intellectual Property and Copyright Statements
9.1. Intellectual Property Statement 9.1 IPR Disclosure Acknowlegement
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 (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
IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 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
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 or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has made
has made any effort to identify any such rights. Information on the any independent effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and procedures with respect to rights in RFC documents can be found in BCP
standards-related documentation can be found in BCP-11. Copies of 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any assurances
obtain a general license or permission for the use of such of licenses to be made available, or the result of an attempt made to
proprietary rights by implementors or users of this specification can obtain a general license or permission for the use of such proprietary
be obtained from the IETF Secretariat. rights by implementers or users of this 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 copyrights, patents or patent applications, or other proprietary rights
rights which may cover technology that may be required to practice that may cover technology that may be required to implement this standard.
this standard. Please address the information to the IETF Executive Please address the information to the IETF at <ietf-ipr@ietf.org>.
Director.
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. 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 Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 18 change blocks. 
73 lines changed or deleted 80 lines changed or added

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