draft-ietf-secsh-userauth-24.txt   draft-ietf-secsh-userauth-25.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 30, 2005 November 29, 2004 Expires: June 9, 2005 December 9, 2004
SSH Authentication Protocol SSH Authentication Protocol
draft-ietf-secsh-userauth-24.txt draft-ietf-secsh-userauth-25.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 35
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 30, 2005. This Internet-Draft will expire on June 9, 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 2, line 22 skipping to change at page 2, line 22
5.1 Responses to Authentication Requests . . . . . . . . . . . 5 5.1 Responses to Authentication Requests . . . . . . . . . . . 5
5.2 The "none" Authentication Request . . . . . . . . . . . . 7 5.2 The "none" Authentication Request . . . . . . . . . . . . 7
5.3 Completion of User Authentication . . . . . . . . . . . . 7 5.3 Completion of User Authentication . . . . . . . . . . . . 7
5.4 Banner Message . . . . . . . . . . . . . . . . . . . . . . 7 5.4 Banner Message . . . . . . . . . . . . . . . . . . . . . . 7
6. Authentication Protocol Message Numbers . . . . . . . . . . . 8 6. Authentication Protocol Message Numbers . . . . . . . . . . . 8
7. Public Key Authentication Method: publickey . . . . . . . . . 8 7. Public Key Authentication Method: publickey . . . . . . . . . 8
8. Password Authentication Method: password . . . . . . . . . . . 10 8. Password Authentication Method: password . . . . . . . . . . . 10
9. Host-Based Authentication: hostbased . . . . . . . . . . . . . 12 9. Host-Based Authentication: hostbased . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 14 12.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16
1. Contributors 1. Contributors
The major original contributors of this set of documents have been: The major original contributors of this set of documents have been:
Tatu Ylonen, 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 set of documents 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].
skipping to change at page 4, line 45 skipping to change at page 4, line 45
Additional thoughts about authentication timeouts and retries may be Additional thoughts about authentication timeouts and retries may be
found in [ssh-1.2.30]. 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 ISO-10646 UTF-8 encoding
[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
The rest of the packet is method-specific. The rest of the packet is method-specific.
The 'user name' and 'service name' are repeated in every new The 'user name' and 'service name' are repeated in every new
authentication attempt, and MAY change. The server implementation authentication attempt, and MAY change. The server implementation
MUST carefully check them in every message, and MUST flush any MUST carefully check them in every message, and MUST flush any
accumulated authentication states if they change. If it is unable to accumulated authentication states if they change. If it is unable to
flush some authentication state, it MUST disconnect if the 'user flush some authentication state, it MUST disconnect if the 'user
name' or 'service name' changes. name' or 'service name' changes.
skipping to change at page 9, line 8 skipping to change at page 9, line 8
MAY require additional authentications after successful MAY require additional authentications after successful
authentication.) authentication.)
Private keys are often stored in an encrypted form at the client Private keys are often stored in an encrypted form at the client
host, and the user must supply a passphrase before the signature can host, and the user must supply a passphrase before the signature can
be generated. Even if they are not, the signing operation involves be generated. Even if they are not, the signing operation involves
some expensive computation. To avoid unnecessary processing and user some expensive computation. To avoid unnecessary processing and user
interaction, the following message is provided for querying whether interaction, the following message is provided for querying whether
authentication using the key would be acceptable. authentication using the key would be acceptable.
byte SSH_MSG_USERAUTH_REQUEST byte SSH_MSG_USERAUTH_REQUEST
string user name in UTF-8, normalized according to string user name in ISO-10646 UTF-8 encoding
[I-D.ietf-sasl-saslprep]
string service name in US-ASCII string service name in US-ASCII
string "publickey" string "publickey"
boolean FALSE boolean FALSE
string public key algorithm name string public key algorithm name
string public key blob string public key blob
Public key algorithms are defined in the transport layer Public key algorithms are defined in the transport layer
specification [SSH-TRANS]. The 'public key blob' may contain specification [SSH-TRANS]. The 'public key blob' may contain
certificates. certificates.
skipping to change at page 10, line 36 skipping to change at page 10, line 35
Password authentication uses the following packets. Note that a Password authentication uses the following packets. Note that a
server MAY request the user to change the password. All server MAY request the user to change the password. All
implementations SHOULD support password authentication. implementations SHOULD support password authentication.
byte SSH_MSG_USERAUTH_REQUEST byte SSH_MSG_USERAUTH_REQUEST
string user name string user name
string service string service
string "password" string "password"
boolean FALSE boolean FALSE
string plaintext password in UTF-8, normalized by string plaintext password in ISO-10646 UTF-8 encoding
[I-D.ietf-sasl-saslprep]
Note that the 'plaintext password' value is encoded in ISO-10646 Note that the 'plaintext password' value is encoded in ISO-10646
UTF-8. This encoding MUST be performed canonically as described in UTF-8. It is up to the server how it interprets the password and
[I-D.ietf-sasl-saslprep]. It is up to the server how it interprets validates it against the password database. However, if the client
the password and validates it against the password database. reads the password in some other encoding (e.g., ISO 8859-1 - ISO
However, if the client reads the password in some other encoding Latin1), it MUST convert the password to ISO-10646 UTF-8 before
(e.g., ISO 8859-1 - ISO Latin1), it MUST convert the password to transmitting, and the server MUST convert the password to the
ISO-10646 UTF-8 before transmitting, and the server MUST convert the encoding used on that system for passwords.
password to the encoding used on that system for passwords.
From an internationalization standpoint, it is desired that if a user
enters their password 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 [I-D.ietf-sasl-saslprep] for
normalization.
Note that even though the cleartext password is transmitted in the Note that even though the cleartext password is transmitted in the
packet, the entire packet is encrypted by the transport layer. Both packet, the entire packet is encrypted by the transport layer. Both
the server and the client should check whether the underlying the server and the client should check whether the underlying
transport layer provides confidentiality (i.e., if encryption is transport layer provides confidentiality (i.e., if encryption is
being used). If no confidentiality is provided ("none" cipher), being used). If no confidentiality is provided ("none" cipher),
password authentication SHOULD be disabled. If there is no password authentication SHOULD be disabled. If there is no
confidentiality or no MAC, password change SHOULD be disabled. confidentiality or no MAC, password change SHOULD be disabled.
Normally, the server responds to this message with success or Normally, the server responds to this message with success or
skipping to change at page 13, line 49 skipping to change at page 14, line 11
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-19.txt, November 2004. draft-ietf-secsh-architecture-20.txt, December 2004.
[SSH-CONNECT] [SSH-CONNECT]
Lonvick, C., "SSH Connection Protocol", I-D Lonvick, C., "SSH Connection Protocol", I-D
draft-ietf-connect-22.txt, November 2004. draft-ietf-secsh-connect-23.txt, December 2004.
[SSH-TRANS] [SSH-TRANS]
Lonvick, C., "SSH Transport Layer Protocol", I-D Lonvick, C., "SSH Transport Layer Protocol", I-D
draft-ietf-transport-21.txt, November 2004. draft-ietf-secsh-transport-22.txt, December 2004.
[SSH-NUMBERS] [SSH-NUMBERS]
Lonvick, C., "SSH Protocol Assigned Numbers", I-D Lonvick, C., "SSH Protocol Assigned Numbers", I-D
draft-ietf-assignednumbers-09.txt, November 2004. draft-ietf-secsh-assignednumbers-10.txt, December 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 [RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001. Languages", BCP 47, RFC 3066, January 2001.
 End of changes. 

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