Network Working Group C. Newman Internet Draft: Plaintext Password SASL Mechanism Innosoft Document: draft-newman-sasl-plaintrans-02.txt June 1997 Expires in six months Plaintext Password SASL Mechanism and Transition Codes 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 progress." 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 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract While plaintext passwords have very poor security characteristics by themselves, there are a number of contexts where they are useful or necessary. This defines a plaintext password mechanism for SASL [SASL] which is intended to be used in combination with an external encryption layer, as a transition mechanism from a legacy authentication database, or to use (insecurely) a legacy authentication database which can not practically be replaced. In hopes of promoting the future elimination of unencrypted plaintext passwords, this defines error codes for use with POP3 and IMAP4: one to indiciate the need for a transition to a stronger mechanism, a second to indicate that plaintext passwords are no longer accepted by a given service, and a third to indicate that plaintext passwords are only accepted by a given service in combination with an external strong encryption mechanism. Any protocol offering the PLAIN mechanism should also support these error codes. Newman [Page 1]
Internet Draft Plaintext Password SASL Mechanism June 1997 1. Conventions Used in this Document 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]. 2. Security Impact of Plaintext Passwords Use of unencrypted plaintext passwords over the Internet is a severe security risk. In particular, a passive observer can get the password with any packet sniffer. This requires no technical expertise, as one can simply plug a consumer level computer into the network and run widely available network snoop programs. Such attacks are difficult or impossible to detect, and can only be prevented by complete physical and virtual security of the network between the client and server -- something which is usually impossible to achieve. Unfortunately, most modern servers use legacy authentication databases, usually tightly integrated with the operating system, which apply a one-way function to the user's password preventing the use of any mechanism other than plaintext passwords. This means that plaintext passwords are the only authentication technology today which will work with the vast majority of deployed authentication databases. Often the cost of deploying a new authentication technology or having different authentication credentials for different services outweighs the security risks of plaintext passwords. Thus there are three situations where plaintext passwords are necessary or useful: (1) As a method to transition, on a per-user basis, from a legacy authentication database a secure password mechanism such as CRAM-MD5 [CRAM-MD5]. (2) As the only feasible mechanism when a legacy authentication database is in use, multiple remote services are offered, there is no way to transition all the remote services, and it is unacceptable to have different passwords for different services. (3) In conjunction with a strong encryption layer. In all other cases, plaintext passwords SHOULD NOT be used. In addition, any client or server supporting this mechanism SHOULD also support a strong encryption layer or a stronger authentication mechanism. Newman [Page 2]
Internet Draft Plaintext Password SASL Mechanism June 1997 3. Plaintext Password SASL mechanism The mechanism name associated with plaintext passwords is "PLAIN". The mechanism consists of a single message from the client to the server. The client sends the authorization identity, followed by a US-ASCII NUL character, followed by the authentication identity, followed by a US-ASCII NUL character, followed by the plaintext password. The client may leave the authorization identity empty to indicate that it is the same as the authentication identity. The server will verify the authentication identity and password with the system authentication database and verify that the authentication credentials permit the client to login as the authorization identity. If both these steps succeed, the user is logged in. When used as a transition mechanism, the password will be stored in a new authentication database capable of supporting stronger authentication mechanisms. Once this is completed, the server MAY refuse future use of the PLAIN mechanism by that authentication identity. The formal grammar for the client message using Augmented BNF [ABNF] follows. message = [authorize-id] NUL authenticate-id NUL password ACHAR = %x20..7E PCHAR = %x01..09 / %x0B..0C / %x0E..7F NUL = %x00 authenticate-id = 1*255ACHAR authorize-id = 1*255ACHAR password = 1*255PCHAR 4. New Error/Response Codes When used as a transition mechanism, two new response codes are helpful to provide guidance to clients. A third response code is useful to indicate the need for an external encryption mechanism. Newman [Page 3]
Internet Draft Plaintext Password SASL Mechanism June 1997 The failure codes for use with IMAP4 [IMAP4] are defined here: TRANSITION-NEEDED This IMAP response code occurs on the tagged NO response to an AUTHENTICATE command after an attempt to use a mechanism other than PLAIN. It indicates that that mechanism is not currently usable, but will be usable once PLAIN or LOGIN is used. PLAINTEXT-DENIED This IMAP response code occurs on the tagged NO response to a LOGIN command or "AUTHENTICATE PLAIN" command. It indicates that a transition has already happened on the server and plaintext passwords are no longer permitted. This may also be used on the untagged OK response when an AUTHENTICATE command using a stronger mechanism succeeds to indicate that plaintext passwords will not be accepted from that user at a later date. ENCRYPT-NEEDED This IMAP response code occurs on the tagged NO response to a LOGIN command or "AUTHENTICATE PLAIN" command. It indicates that plaintext passwords may only be used in combination with an external strong encryption service. The failure codes for use with POP3 [POP3] are defined here: -ERR [TRANSITION-NEEDED] A password transition is needed. The portion between the "[" and "]" is a machine parsable message, interpreted in a case insensitive fashion. The remainer of the line may contain any human readable text. This occurs in response to an APOP or AUTH [POP-AUTH] command that is not currently available, but will be available after the use of the PLAIN mechanism or the USER/PASS commands. -ERR [PLAINTEXT-DENIED] Plaintext passwords forbidden This occurs in response to a USER, PASS or AUTH PLAIN command and indicates that the server no longer permits plaintext passwords because a transition has occurred. It may also occure on a "+OK" line after a successful APOP or AUTH command to indicate that plaintext passwords will not be accepted from that user at a later date. Newman [Page 4]
Internet Draft Plaintext Password SASL Mechanism June 1997 -ERR [ENCRYPT-NEEDED] Plaintext passwords need encryption This occurs in response to a USER, PASS or AUTH PLAIN command and indicates that the server does not permit plaintext passwords without an external encryption mechanism for the specified user. 5. 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. 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 client 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 password is "tanstaaftanstaaf". S: * OK IMAP4 server ready C: A001 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=PLAIN S: A001 OK done C: A002 AUTHENTICATE CRAM-MD5 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw S: A002 NO [TRANSITION-NEEDED] You can't login securely until you've changed your password on the server C: A003 AUTHENTICATE PLAIN 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. A man in the middle or a spoof server may be able to aquire the Newman [Page 5]
Internet Draft Plaintext Password SASL Mechanism June 1997 user's password by pretending no strong authentication mechanisms are available. The are two steps the client can take to help defeat such attacks. First, clients SHOULD record the occurance of a PLAINTEXT-DENIED or ENCRYPT-NEEDED error for a given user, server and protocol combination and refuse to use unencrypted plaintext passwords for that combination in the future. Second, clients SHOULD get permission from the user prior to using an unencrypted plaintext password. If the user normally makes a secure connection and suddenly sees a warning, this might prevent a password compromise. Unencrypted plaintext passwords are visible to any network snooper, as discussed in section 2. Servers SHOULD have the ability to enable the PLAINTEXT-DENIED or ENCRYPT-NEEDED errors on a per-user basis to ease the transition away from unencrypted plaintext passwords. 7. References [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", Work in progress: draft-ietf-drums-abnf-xx.txt [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2095, MCI, January 1997. <ftp://ds.internic.net/rfc/rfc2095.txt> [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. <ftp://ds.internic.net/rfc/rfc2060.txt> [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. <ftp://ds.internic.net/rfc/rfc2119.txt> [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. <ftp://ds.internic.net/rfc/rfc1939.txt> [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie Mellon, December 1994. <ftp://ds.internic.net/rfc/rfc1734.txt> Newman [Page 6]
Internet Draft Plaintext Password SASL Mechanism June 1997 [SASL] Myers, "Simple Authentication and Security Layer (SASL)", work in progress. [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, Alis Technologies, October 1996. <ftp://ds.internic.net/rfc/rfc2044.txt> 8. Acknowledgements Thanks to John Myers and Larry Osterman for providing feedback on the initial version of this specification. Special thanks to Ned Freed and Kevin Carosso for coming up with the basic plaintext transition idea. 9. Author's Address Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA Email: chris.newman@innosoft.com Newman [Page 7]