Internet-Draft D. Bider Intended status: Standards Track Bitvise Limited Expires: September 11, 2017 March 11, 2017 Extended authentication information in Secure Shell (SSH) draft-ssh-ext-auth-info-00.txt Abstract This memo defines a way for SSH server applications to send additional information to clients as part of authentication failure. A mechanism to relay such information can reduce the need for end user support in situations where a client would successfully authenticate, but cannot log in for a policy reason, such as password age or public key size. Status This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Bider [Page 1] Internet-Draft Extended authentication information in SSH March 2017 1. Overview and Rationale Secure Shell (SSH) is a common protocol for secure communication on the Internet. In [RFC4252], SSH defines a standard failure message, SSH_MSG_USERAUTH_FAILURE, for use with "password", "publickey", and other authentication methods. The SSH_MSG_USERAUTH_FAILURE message was designed under the assumption that the server never needs to inform the client about exact reasons behind an authentication failure. In practice, there are situations where revealing such information is beneficial, and is not a risk. In these situations, not revealing the cause of failure deprives client software and end users of information needed to appropriately respond. This memo describes a mechanism which leverages [SSH-EXT-INFO] for client software to signal that it is willing to receive extra information as part of the SSH_MSG_USERAUTH_FAILURE message. A format for the additional information is described, as well as definitions for a number of common status codes. 1.1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Indicating Support Extended information cannot be sent to clients that do not indicate support: widely used clients disconnect on unexpected data. Therefore, SSH clients and servers that support this extension SHALL implement [SSH-EXT-INFO]. When sending SSH_MSG_EXT_INFO to a server that signals support for that message, a client MAY include this extension: extension-name: "ext-auth-info" extension-value: (empty) The client MUST send an empty extension value. A server that does not expect an extension value MUST ignore it, regardless of the value. Bider [Page 2] Internet-Draft Extended authentication information in SSH March 2017 3. Extended Format of SSH_MSG_USERAUTH_FAILURE When sending SSH_MSG_USERAUTH_FAILURE to a client that signals support for this mechanism as per Section 2, the server MAY send the message in original format, as specified in [RFC4252]: byte SSH_MSG_USERAUTH_FAILURE name-list authentications that can continue boolean partial success If the server decides additional information is safe to send, the server MAY extend the format of SSH_MSG_USERAUTH_FAILURE as follows: byte SSH_MSG_USERAUTH_FAILURE name-list authentications that can continue boolean partial success string authentication status name string message (in UTF-8 encoding without BOM) string language tag (as per [RFC5646]) If the server sends extended information, it MUST send all three additional fields (and perhaps optional status-specific data). It is not permissible to send e.g. only the authentication status name, but no message or language tag. After the language tag, clients MUST tolerate optional data. If a client does not understand the optional data, it MUST ignore it. An authentication status name follows the format of an algorithm or method name as specified in [RFC4251], Section 6. 3.1. Authentication Status Names The following authentication status names are defined: "internal-error" MAY be sent in response to any authentication request. The request could not be processed due to an internal server error. It is appropriate to contact the server administrator. "transient-conflict" MAY be sent in response to any authentication request. The request could not be processed due to a transient server-side conflict. The issue may be resolved if the request is tried again, or the connection is re-attempted. "account-disabled" MAY be sent in response to any authentication request. Credentials were valid successful, but the account is disabled. Bider [Page 3] Internet-Draft Extended authentication information in SSH March 2017 "account-restriction" MAY be sent in response to any authentication request. Credentials were valid, but the account is restricted in a non-absolute manner (e.g. logon hours) that prevents login. "pk-size-restriction" MAY be sent in response to public key authentication. The public key sent by the client is known to the server, but does not meet the server's key size criteria. "pk-alg-restriction" MAY be sent in response to public key authentication. The public key sent by the client is known to the server, but the key or signature uses an algorithm not supported or accepted by the server. "password-expired" MAY be sent in response to password authentication. The password was correct, but is expired and must change, AND cannot be changed in the current session. If the password can be changed, the server SHOULD instead send SSH_MSG_USERAUTH_PASSWORD_CHANGEREQ. "password-must-change" MAY be sent in response to password authentication. The password was correct, is not expired, but must change, AND cannot be changed in the current session. If the password can be changed, the server SHOULD instead send SSH_MSG_USERAUTH_PASSWORD_CHANGEREQ. "password-cannot-change" MAY be sent in response to a password change request. Password change cannot be performed regardless of the new password requested. "gss-no-mechanism" MAY be sent in response to a GSSAPI authentication request that that enumerates no supported mechanisms. "gss-identity" MAY be sent in response to a GSSAPI authentication request when the server cannot verify that the GSSAPI identity is the same as that named in the SSH authentication request. 3.2. Authentication conditions WITHOUT status names Authentication status names are intentionally NOT defined for the following conditions: - Password change request: Password ill-formed - Password change request: Password does not meet policy requirements In these cases, the server SHOULD instead send (potentially another) SSH_MSG_USERAUTH_PASSWORD_CHANGEREQ with an appropriate message. Bider [Page 4] Internet-Draft Extended authentication information in SSH March 2017 4. IANA Considerations 4.1. Additions to existing tables IANA is requested to insert the following entries into the table Extension Names (added in [SSH-EXT-INFO]) under Secure Shell (SSH) Protocol Parameters [RFC4250]: Extension Name Reference Note ext-auth-info [this document] Section 2 4.2. New table: Authentication Status Names Under Secure Shell (SSH) Protocol Parameters, IANA is requested to create a new table, Authentication Status Names, with initial content: Extension Name Reference Note internal-error [this document] Section 3.1 transient-error [this document] Section 3.1 account-disabled [this document] Section 3.1 account-restriction [this document] Section 3.1 pk-size-restriction [this document] Section 3.1 pk-alg-restriction [this document] Section 3.1 password-expired [this document] Section 3.1 password-must-change [this document] Section 3.1 password-cannot-change [this document] Section 3.1 gss-no-mechanism [this document] Section 3.1 gss-identity [this document] Section 3.1 5. Security Considerations Servers MUST NOT send extended authentication information if this would reveal sensitive information to an untrusted client. For example, the status "account-disabled" is meant to be sent to a user who would successfully authenticate, and the only reason they cannot log in is because their account is disabled. Extended information with this status SHOULD NOT be sent to a user who is trying to log into a disabled account with an incorrect password. Bider [Page 5] Internet-Draft Extended authentication information in SSH March 2017 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4251] Ylonen, T. and Lonvick, C., Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4252] Ylonen, T. and Lonvick, C., Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC5646] Phillips, A., Ed. and Davis, M., Ed., "Tags for Identifying Languages", RFC 5646, September 2009. [SSH-EXT-INFO] Bider, D., "Extension Negotiation in Secure Shell (SSH)", draft-ietf-curdle-ssh-ext-info-02.txt, February 2017, . 6.2. Informative References [RFC4250] Lehtinen, S. and Lonvick, C., Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. Bider [Page 6] Internet-Draft Extended authentication information in SSH March 2017 Author's Address Denis Bider Bitvise Limited Suites 41/42, Victoria House 26 Main Street GI Phone: +506 8315 6519 EMail: ietf-ssh3@denisbider.com URI: https://www.bitvise.com/ Bider [Page 7]