[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                          C. Newman
Internet Draft: Authentication Responses                        Innosoft
Document: draft-newman-auth-resp-00.txt                        July 1998
Updates: RFC 821, 1893, 1939, 2060, 2244           Expires in six months

     Authentication Responses for Protocols (SMTP, IMAP, POP, etc)

Status of this memo

     This document is an Internet-Draft.  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

     To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
     (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
     West Coast).


     This memo assigns client authentication error codes for those
     situations where a client may take specific corrective action in
     the face of a failed authentication attempt.  Some of these codes
     are used by one strategy to transition users away from unencrypted
     clear text passwords.

     A number of important security considerations related to
     authentication errors are also discussed.

     This memo assigns SMTP error codes [SMTP], ESMTP error codes
     [ESMTP-ERR], IMAP response codes [IMAP4], POP3 [POP3] extension
     codes [POPEXT], and ACAP [ACAP] response codes.

Newman                                                          [Page 1]

Internet Draft          Authentication Responses               July 1998

1. Conventions Used in this Memo

     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
     in this document are to be interpreted as defined in "Key words for
     use in RFCs to Indicate Requirement Levels" [KEYWORDS].

1.1. Terminology Used in the Memo

     Authentication Credentials
          The information the client sends to the server to prove its
          identity to the server.

     Authentication Verifier
          A piece of per-user data stored on a server which is used to
          verify if an authentication exchange for a given user includes
          valid authentication credentials.

          The term "passphrase" is used rather than "password" to
          discourage the use of simple single-word passphrases.

2. Concealing Users on the System

     Before discussing specific error codes, it is important to note
     that an active attacker who is aware of the userids of people on
     the system is more dangerous than an active attacker with no
     information.  This concern is pervasive when discussing
     authentication error codes, because it is very easy to reveal the
     existance of a user with an incautious authentication error system.

     However, there may be cases where it is more important to give the
     client good information so it can take corrective action, than it
     is to conceal users.  For example, help desk costs necessary for
     users who see a generic "Authentication Failed" error at one site
     might outweigh the risk of revealing system userids to an active

     Every server which provides client authentication SHOULD have a
     configuration setting where the validity of a user is not revealed
     by a failed authentication attempt.  In particular, the
     non-existance of a user is treated identically to a bad passphrase,
     an authentication mechanism deemed too weak, or a missing
     authentication verifier, both in the text of the protocol and in
     the speed of the server response.

Newman                                                          [Page 2]

Internet Draft          Authentication Responses               July 1998

3. An Authentication Transition System

     While there is a strong desire to stop sending unencrypted clear
     text passphrases, system administrators of existing systems often
     are unable to do so unless it is nearly painless for the users.  A
     number of Internet protocols (e.g., HTTP, POP, ACAP, IMAP, SNMP,
     PPP) now have standards track challenge-response authentication
     mechanisms based on cryptographic hash functions.  However, the
     authentication verifier for these mechanisms is either the user's
     passphrase itself or something derived from it in a special way.

     Unfortunately, most sites with existing users have authentication
     verifiers that are an incompatible one-way function of the user's
     passphrase.  Thus a new mechanism normally can not be deployed
     without forcing users to set new passphrases on the system.  So
     even if a user were to set his POP client to use APOP [POP3], the
     authentication would fail until the appropriate server verifier was

     A site which is more concerned with ending the use of unencrypted
     clear text passphrases than with revealing users to an active
     attacker can enable authentication transitioning.  When a client
     attempts to use APOP, but the verifier is not initialized, then the
     server returns a response code indicating that a "transition is
     needed."  The client then attempts authentication with a clear text
     passphrase one last time (with user confirmation) to force a
     transition.  After this, both the client and the server can flag
     the user as transitioned and cease using unencrypted clear text

     Note that a man-in-the-middle attacker could cause a client
     authentication to fail with this specific error code in an attempt
     to trick the client into using an unencrypted clear text
     passphrase.  A client can prevent this attack by negotiating a
     full-strength encryption layer prior to using a clear text
     passphrase for the transition, or mitigate the attack either by
     getting explicit user permission for the transition or by saving a
     flag after a successful strong authentication and refusing to
     transition again.

4. Authentication Response Codes

     This section identifies a number of authentication success and
     error conditions where a client MAY take a specific action.  For
     each condition, a response code suitable for ACAP, IMAP or POP is
     defined, a regular SMTP 3-digit error code, an enhanced SMTP error
     code [ESMTP-CODES], and in some cases an FTP response codes from

Newman                                                          [Page 3]

Internet Draft          Authentication Responses               July 1998

     [FTP-SEC] is included for completeness.

     Some of the response codes are already defined in other
     specifications and are included here for completeness, a reference
     is included for already defined response codes.

     Successful Authentication

          ACAP, IMAP, POP: Generic "OK" response suffices
                     SMTP: 234                   [SMTP-AUTH]
            Enhanced SMTP: 2.7.0
                      FTP: multiple, see [FTP] and [FTP-SEC] for details

          This indicates that the security exchange was successful.

          Security Considerations: May not indicate client or server is

     Successful Authentication with Data

                     ACAP: SASL base64data       [ACAP]
                IMAP, POP: N/A
                     SMTP: N/A
            Enhanced SMTP: N/A
                      FTP: 235 [ADAT=base64data] [FTP-SEC]

          This is used when the server has successfully authenticated
          the client, but includes optional data in the response which
          the client may use to mutually authenticate the server.
          Protocols without such a response have an extra round-trip
          when the server provides mutual authentication data as
          described in SASL [SASL].

          Security Considerations: Integrity protection is not possible
          if this information ignored by the client.

     Temporary Authentication Failure

          ACAP, IMAP, POP: TRYLATER              [ACAP]
                     SMTP: 454                   [SMTP-AUTH]
            Enhanced SMTP: 4.7.0
                      FTP: 431                   [FTP-SEC]

          This occurs when there is a temporary failure during
          authentication.  It indicates some resource necessary to
          authenticate is unavailable at the present time.

          Security Considerations: May reveal information about users on

Newman                                                          [Page 4]

Internet Draft          Authentication Responses               July 1998

          a system with multiple authentication sources where an earlier
          one is local and a later one is remote.

     Invalid Authentication Mechanism

          ACAP, IMAP, POP: The generic BAD or -ERR response suffices
                     SMTP: 504                   [SMTP, SMTP-AUTH]
            Enhanced SMTP: 5.5.4                 [ESMTP-CODES]
                      FTP: 504                   [FTP, FTP-SEC]

          This error code occurs when the client attempts to use an
          authentication mechanism which the server does not implement.

          Security Considerations: An active attacker could issue this
          error code to attempt to get the client to try a weaker
          mechanism and reveal more information.  Clients SHOULD be
          configurable to fail or get user permission if the only
          remaining mechanisms are weak.

     Authentication Failed (Bad user name or passphrase)

          ACAP, IMAP, POP: The generic NO or -ERR response suffices
                     SMTP: 535                   [SMTP-AUTH]
            Enhanced SMTP: 5.7.8
                      FTP: 530                   [FTP]

          This occurs when an invalid user name is used, or the
          passphrase or other authentication credentials are incorrect.
          It is also the preferred error code for any non-syntax
          failures which do not have a specific error code here.  It is
          quite reasonable for a server to return only success error
          codes, or this error code.

          Security Considerations: It is important not to distinguish
          between "unknown user" and "bad passphrase" to conceal users.
          It is important to supply a consistant delay when this error
          code occurs to prevent fast password searches.  A server MAY
          unilaterally close the connection after a specific number of
          failed authentication attempts to make password searches even

     Authenticate Exchange Cancelled

          ACAP, IMAP, POP: The generic BAD or -ERR response suffices
                     SMTP: 501                   [SMTP-AUTH]
            Enhanced SMTP: 5.7.0                 [ESMTP-CODES]
                      FTP: not defined

Newman                                                          [Page 5]

Internet Draft          Authentication Responses               July 1998

          This occurs when the client cancels a multiple-round-trip
          authenticate exchange in the middle.  SASL profiles are
          required to document how the client cancels the exchange.

          Security Considerations: none

     Authentication Mechanism Too Weak

          ACAP, IMAP, POP: AUTH-TOO-WEAK         [ACAP]
                     SMTP: 522                   [SMTP-AUTH]
            Enhanced SMTP: 5.7.9
                      FTP: 534                   [FTP-SEC]

          Some currently deployed clients are staticly configured to use
          only clear text passphrases by default, but can be configured
          to support a stronger mechanism.  This error code provides a
          way to tell those clients that they are no longer permitted to
          use a weak mechanism, such as clear text passphrases, and must
          try something stronger.  It may be particularly useful during
          a transition period where a weaker mechanism is available to
          un-transitioned users and a stronger mechanism is required for
          transitioned users.

          Security Considerations: Reveals information about the users
          on the system, but provides ability to force clients to
          upgrade their authentication.

     Encryption Needed

                     SMTP: 523                   [SMTP-AUTH]
            Enhanced SMTP: 5.7.10
                      FTP: not defined

          This indicates that external strong privacy layer is needed in
          order to use the requested authentication mechanism.  This is
          primarily intended for use with clear text authentication
          mechanisms.  A client which receives this may activate a
          security layer such as TLS prior to authenticating, or attempt
          to use a stronger mechanism.  Note that code this does reveal
          the existance of users on the system to an active attacker but
          that is mitigated by the ability to force users to activate a
          privacy layer.

          Security Considerations: If this is applied regardless of the
          user name supplied, this can improve site security.  If this
          is applied on a per-user basis, it can reveal information
          about users on the system.

Newman                                                          [Page 6]

Internet Draft          Authentication Responses               July 1998

     Expired Passphrase

                     SMTP: 524
            Enhanced SMTP: 5.7.11
                      FTP: not defined

          This indicates the user's passphrase or passphrase has expired
          and needs to be changed.  Many sites have a policy which
          forbids a passphrase or passphrase from being used too long.
          These sites will set a time period after which passphrases
          must be changed.  Some sites also pre-expire passphrases set
          by a system administrator, such that a user must change their
          passphrase prior to using their account.  A client which
          receives this error code can treat it as a user request to
          change her passphrase.

          Security Considerations: The server should verify that the
          correct old authentication credentials were provided prior to
          issuing this error, otherwise it would reveal information
          about users on the system.

     Transition Needed

                     SMTP: 422                   [SMTP-AUTH]
            Enhanced SMTP: 4.7.12
                      FTP: not defined

          This occurs after a client attempts to authenticate using a
          mechanism other than clear text.  It indicates that the server
          has an entry for the specified user in a legacy authentication
          database but does not yet have an authentication verifier
          necessary to offer the requested mechanism.  A client which
          receives this error code may do a one-time login using a clear
          text login after asking the user for permission to activate
          the transition.

          Security Considerations: If clear text passwords are used to
          transition, a strong privacy layer SHOULD be used.  This error
          reveals the existance of users to active attackers, but it
          also provides an effective method to transition away from
          using clear text passphrases without forcing users to change
          their passphrases.

Newman                                                          [Page 7]

Internet Draft          Authentication Responses               July 1998

     User Account Disabled

                     SMTP: 525
            Enhanced SMTP: 5.7.13
                      FTP: not defined

          Sometimes a system administrator will have to disable a user's
          account (e.g., due to lack of payment, abuse, evidence of a
          break-in attempt, etc).  This error code occurs after a
          successful authentication to a disabled account.  This informs
          the client that the failure is permanent until the user
          contacts their system administrator to get the account re-
          enabled.  It differs from a generic authentication failure
          where the client's best option is to present the passphrase
          entry dialog in case the user simply mistyped their

          Security Considerations: Same as for EXPIRED-PASS above.

5. Gradual Transition on PLAIN Example

     Here is a sample transition exchange between an IMAP client and
     server.  In this example, "C:" and "S:" indicate lines sent by the
     client and server respectively.  If such lines are wrapped without
     a new "C:" or "S:" label, then the wrapping is for editorial
     clarity and is not part of the command.

     Note that this example uses the IMAP profile [IMAP4] of SASL
     [SASL].  The base64 encoding of challenges and responses, as well
     as the "+ " preceding the responses are part of the IMAP4 profile,
     not part of SASL itself.  Newer profiles of SASL will include the
     initial client PLAIN message with the AUTHENTICATE command itself
     so the extra round trip below (the server response with an empty "+
     ") can be eliminated.

     In this example, the user's authentication identifier is "tim", his
     authorization identifier is the same, and his passphrase is

        S: * OK IMAP4 server ready
        C: A001 CAPABILITY
        S: A001 OK done
        S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+

Newman                                                          [Page 8]

Internet Draft          Authentication Responses               July 1998

        S: A002 NO [TRANSITION-NEEDED] You can't login securely until
                you've changed your passphrase on the server
        <client gets permission from user to transition>
        S: +
        C: AHRpbQB0YW5zdGFhZnRhbnN0YWFm
        S: A003 OK You can now login securely in the future.
        C: A004 SELECT INBOX

6. Security Considerations

     Security considerations are discussed throughout this document, and
     in sections 2-4 in some detail.  This memo focuses on two major
     security concerns: network transmission of unencrypted clear text
     passphrases, and revealing the existance of users on the system to
     an attacker.  It suggests one way to remedy the former at the
     short-term expense of the latter weakness.

7. References

     [ACAP] Newman, Myers, "ACAP -- Application Configuration Access
     Protocol", RFC 2244, Innosoft, Netscape, November 1997.

     [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
     for Simple Challenge/Response", RFC 2195, MCI, September 1997.

     [FTP] Postel, J., Reynolds, J., "FILE TRANSFER PROTOCOL (FTP)", RFC
     959, ISI, October 1985.

     [FTP-SEC] Horowitz, M., Lunt, S., "FTP Security Extensions", RFC
     2228, Cygnus Solutions, Bellcore, October 1997.

     [HTTP] Fielding, Gettys, Mogul, Frystyk, Berners-Lee, "Hypertext
     Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, DEC, MIT/LCS,
     January 1997.

     [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
     4rev1", RFC 2060, University of Washington, December 1996.

     [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
     Requirement Levels", RFC 2119, Harvard University, March 1997.

     [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC
     1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996.

Newman                                                          [Page 9]

Internet Draft          Authentication Responses               July 1998

     [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie
     Mellon, December 1994.

     [POPEXT] Gellens, Newman, Lundblade "POP3 Extension Mechanism",
     Work in progress.

     [SASL] Myers, "Simple Authentication and Security Layer (SASL)",
     RFC 2222, Netscape Communications, October 1997.

     [SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821,
     Information Sciences Institute, August 1982.

9. Acknowledgements

     The following people provided helpful feedback on this document:

     Ned Freed, Steve Hole, John Myers, Larry Osterman

10. Author's Address

     Chris Newman
     Innosoft International, Inc.
     1050 Lakes Drive
     West Covina, CA 91790 USA

     Email: chris.newman@innosoft.com

Newman                                                         [Page 10]