draft-ietf-secsh-userauth-23.txt   draft-ietf-secsh-userauth-24.txt 
Network Working Group C. Lonvick, Ed. Network Working Group C. Lonvick, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: May 19, 2005 November 18, 2004 Expires: May 30, 2005 November 29, 2004
SSH Authentication Protocol SSH Authentication Protocol
draft-ietf-secsh-userauth-23.txt draft-ietf-secsh-userauth-24.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 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 May 19, 2005. This Internet-Draft will expire on May 30, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (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 the SSH services over an insecure network. This document describes the SSH
authentication protocol framework and public key, password, and authentication protocol framework and public key, password, and
skipping to change at page 3, line 7 skipping to change at page 3, line 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 14 12.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 15
1. Contributors 1. Contributors
The major original contributors of this document were: Tatu Ylonen, The major original contributors of this set of documents have been:
Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH
Communications Security Corp), and Markku-Juhani O. Saarinen Communications Security Corp), and Markku-Juhani O. Saarinen
(University of Jyvaskyla). Darren Moffit was the original editor of (University of Jyvaskyla). Darren Moffit was the original editor of
this document and also made very substantial contributions. this set of documents and also made very substantial contributions.
Additional contributors to this document include [need list]. Additional contributors to this document include [need list].
Listing their names here does not mean that they endorse this Listing their names here does not mean that they endorse this
document, but that they have contributed to it. document, but that they have contributed to it.
Comments on this internet draft should be sent to the IETF SECSH Comments on this internet draft should be sent to the IETF SECSH
working group, details at: working group, details at:
http://ietf.org/html.charters/secsh-charter.html Note: This paragraph http://ietf.org/html.charters/secsh-charter.html Note: This paragraph
will be removed before this document progresses to become an RFC. will be removed before this document progresses to become an RFC.
skipping to change at page 4, line 36 skipping to change at page 4, line 36
of supported methods from the server. of supported methods from the server.
The server SHOULD have a timeout for authentication, and disconnect The server SHOULD have a timeout for authentication, and disconnect
if the authentication has not been accepted within the timeout if the authentication has not been accepted within the timeout
period. The RECOMMENDED timeout period is 10 minutes. Additionally, period. The RECOMMENDED timeout period is 10 minutes. Additionally,
the implementation SHOULD limit the number of failed authentication the implementation SHOULD limit the number of failed authentication
attempts a client may perform in a single session (the RECOMMENDED attempts a client may perform in a single session (the RECOMMENDED
limit is 20 attempts). If the threshold is exceeded, the server limit is 20 attempts). If the threshold is exceeded, the server
SHOULD disconnect. SHOULD disconnect.
Additional thoughts about authentication timeouts and retries may be
found in [ssh-1.2.30].
5. Authentication Requests 5. Authentication Requests
All authentication requests MUST use the following message format. All authentication requests MUST use the following message format.
Only the first few fields are defined; the remaining fields depend on Only the first few fields are defined; the remaining fields depend on
the authentication method. the authentication method.
byte SSH_MSG_USERAUTH_REQUEST byte SSH_MSG_USERAUTH_REQUEST
string user name in UTF-8, normalized according to string user name in UTF-8, normalized according to
[I-D.ietf-sasl-saslprep] [I-D.ietf-sasl-saslprep]
string service name in US-ASCII string service name in US-ASCII
string method name in US-ASCII string method name in US-ASCII
skipping to change at page 5, line 49 skipping to change at page 6, line 4
Additional 'method name' values may be defined as specified in Additional 'method name' values may be defined as specified in
[SSH-ARCH] and [SSH-NUMBERS]. [SSH-ARCH] and [SSH-NUMBERS].
5.1 Responses to Authentication Requests 5.1 Responses to Authentication Requests
If the server rejects the authentication request, it MUST respond If the server rejects the authentication request, it MUST respond
with the following: with the following:
byte SSH_MSG_USERAUTH_FAILURE byte SSH_MSG_USERAUTH_FAILURE
string authentications that can continue name-list authentications that can continue
boolean partial success boolean partial success
The 'authentications that can continue' string is a comma-separated
list of authentication 'method name' values that may productively The 'authentications that can continue' is a comma-separated
continue the authentication dialog. name-list of authentication 'method name' values that may
productively continue the authentication dialog.
It is RECOMMENDED that servers only include those 'method name' It is RECOMMENDED that servers only include those 'method name'
values in the list that are actually useful. However, it is not values in the name-list that are actually useful. However, it is not
illegal to include 'method name' values that cannot be used to illegal to include 'method name' values that cannot be used to
authenticate the user. authenticate the user.
Already successfully completed authentications SHOULD NOT be included Already successfully completed authentications SHOULD NOT be included
in the list, unless they really should be performed again for some in the name-list, unless they really should be performed again for
reason. some reason.
The value of 'partial success' MUST be TRUE if the authentication The value of 'partial success' MUST be TRUE if the authentication
request to which this is a response was successful. It MUST be FALSE request to which this is a response was successful. It MUST be FALSE
if the request was not successfully processed. if the request was not successfully processed.
When the server accepts authentication, it MUST respond with the When the server accepts authentication, it MUST respond with the
following: following:
byte SSH_MSG_USERAUTH_SUCCESS byte SSH_MSG_USERAUTH_SUCCESS
skipping to change at page 11, line 50 skipping to change at page 11, line 50
SSH_MSG_USERAUTH_FAILURE with partial success The password has SSH_MSG_USERAUTH_FAILURE with partial success The password has
been changed, but more authentications are needed. been changed, but more authentications are needed.
SSH_MSG_USERAUTH_FAILURE without partial success The password has SSH_MSG_USERAUTH_FAILURE without partial success The password has
not been changed. Either password changing was not supported, or not been changed. Either password changing was not supported, or
the old password was bad. Note that if the server has already the old password was bad. Note that if the server has already
sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports
changing the password. changing the password.
SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because
the new password was not acceptable (e.g. too easy to guess). the new password was not acceptable (e.g., too easy to guess).
The following method-specific message numbers are used by the The following method-specific message numbers are used by the
password authentication method. password authentication method.
SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60
9. Host-Based Authentication: hostbased 9. Host-Based Authentication: hostbased
Some sites wish to allow authentication based on the host where the Some sites wish to allow authentication based on the host where the
user is coming from, and the user name on the remote host. While user is coming from, and the user name on the remote host. While
skipping to change at page 13, line 49 skipping to change at page 13, line 49
Full security considerations for this protocol are provided in Full security considerations for this protocol are provided in
[SSH-ARCH]. [SSH-ARCH].
12. References 12. References
12.1 Normative 12.1 Normative
[SSH-ARCH] [SSH-ARCH]
Lonvick, C., "SSH Protocol Architecture", I-D Lonvick, C., "SSH Protocol Architecture", I-D
draft-ietf-architecture-18.txt, October 2004. draft-ietf-architecture-19.txt, November 2004.
[SSH-CONNECT] [SSH-CONNECT]
Lonvick, C., "SSH Connection Protocol", I-D Lonvick, C., "SSH Connection Protocol", I-D
draft-ietf-connect-21.txt, October 2004. draft-ietf-connect-22.txt, November 2004.
[SSH-TRANS] [SSH-TRANS]
Lonvick, C., "SSH Transport Layer Protocol", I-D Lonvick, C., "SSH Transport Layer Protocol", I-D
draft-ietf-transport-20.txt, October 2004. draft-ietf-transport-21.txt, November 2004.
[SSH-NUMBERS] [SSH-NUMBERS]
Lonvick, C., "SSH Protocol Assigned Numbers", I-D Lonvick, C., "SSH Protocol Assigned Numbers", I-D
draft-ietf-assignednumbers-08.txt, October 2004. draft-ietf-assignednumbers-09.txt, November 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[I-D.ietf-sasl-saslprep] [I-D.ietf-sasl-saslprep]
Zeilenga, K., "SASLprep: Stringprep profile for user names Zeilenga, K., "SASLprep: Stringprep profile for user names
and passwords", draft-ietf-sasl-saslprep-10 (work in and passwords", draft-ietf-sasl-saslprep-10 (work in
progress), July 2004. progress), July 2004.
12.2 Informative 12.2 Informative
[RFC3066] Alvestrand, H., "Tags for the Identification of [ssh-1.2.30]
Languages", BCP 47, RFC 3066, January 2001. Ylonen, T., "ssh-1.2.30/RFC", File within compressed
tarball ftp://ftp.funet.fi/pub/unix/security/login/ssh/
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO ssh-1.2.30.tar.gz, November 1995.
10646", STD 63, RFC 3629, November 2003.
Author's Address Author's Address
Chris Lonvick (editor) Chris Lonvick (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
12515 Research Blvd. 12515 Research Blvd.
Austin 78759 Austin 78759
USA USA
EMail: clonvick@cisco.com EMail: clonvick@cisco.com
 End of changes. 

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