Network Working Group C. Newman Internet Draft: Plain Transition SASL mechanism Innosoft Document: draft-newman-sasl-plaintrans-00.txt May 1997 Expires in six months Plaintext Password Transition SASL mechanism 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire six months after publication. Distribution of this draft is unlimited. Abstract In order to replace plaintext passwords, the Internet community needs a strong authentication system which is standards track, general purpose, and sufficiently easy to implement that client authors might be willing to spend valuable development time implementing it. The only mechanism which comes close to this today is CRAM-MD5 [CRAM-MD5]. Unfortunately, CRAM-MD5 and it's predecessor APOP [POP3] can not be used with most server authentication databases in use today since these databases store the password after applying an incompatible one-way function. This proposal defines a SASL [SASL] mechanism and associated response codes which can be used to make the Newman [Page 1]
Internet Draft Plain Transition SASL mechanism May 1997 transition relatively painless. 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. Plaintext Password Transition SASL mechanism The mechanism name associated with plaintext password transition is "PLAINTRANSITION". The mechanism consists of a single message from the client to the server. The client sends the authorization identity, followed by a US-ASCII tab character, followed by the authentication identity, followed by a US-ASCII tab 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 password will be stored in a new authentication database capable of supporting stronger authentication mechanisms. Once this has completed, the server MUST refuse future PLAINTRANSITION commands by that authentication identity, and SHOULD refuse future plaintext login commands by that authentication identity. The formal grammar for the client message using Augmented BNF [ABNF] follows. message = [authorize-id] TAB authenticate-id TAB password ACHAR = %x20..7E PCHAR = %x01..09 / %x0B..0C / %x0E..7F TAB = %x09 authenticate-id = 1*255ACHAR authorize-id = 1*255ACHAR password = 1*255PCHAR Newman [Page 2]
Internet Draft Plain Transition SASL mechanism May 1997 3. New response codes This mechanism requires support for new failure codes in protocols which use it. 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 PLAINTRANSITION. It indicates that that mechanism is not currently usable, but would be usable one a PLAINTRANSITION has occured. This may also occur in response to a LOGIN command indicating that the user is required to use PLAINTRANSITION but all other uses of plaintext passwords will be denied. This may also be used on an OK response to a LOGIN command to indicate that the user should transition to a stronger mechanism. In this context it may be followed by a number indicating the number of days until the user's password will expire if the user fails to transition. PLAINTEXT-DENIED This IMAP response code occurs on the tagged NO response to a LOGIN command or "AUTHENTICATE PLAINTRANSITION" command. It indicates that a transition has already happened on the server and plaintext passwords are no longer permitted. The failure codes for use with POP3 [POP3] are defined here: -ERR Transition needed 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 PLAINTRANSITION. It can occur in response to a USER or PASS command to indicate that transition is required but all other uses of plaintext passwords will be denied. Additional text may be added on the end of this message to explain the error more clearly. +OK <number> days until password transition required This message occurs in response to a successful PASS command and indicates when the user's password will expire if the user fails to transition. Newman [Page 3]
Internet Draft Plain Transition SASL mechanism May 1997 -ERR Plaintext passwords forbidden This occurs in response to a USER, PASS or AUTH PLAINTRANSITION command and indicates that the server no longer permits plaintext passwords because a transition has occurred. Additional text may be added on the end of this message to explain the error more clearly. 4. Implementation Requirements for Plaintext Password Transition Clients MUST NOT use the PLAINTRANSITION mechanism unless the server offers another SASL mechanism which the client understands. Servers which support PLAINTRANSITION MUST support another stronger SASL mechanism. Clients SHOULD NOT use PLAINTRANSITION unless they first attempt a stronger mechanism and receive an indication from the server that a transition is needed. Clients are encouraged to warn the user that the transition may be one way and could prevent future use of insecure clients. Clients are encouraged to negotiate an encrypted stream prior to use of PLAINTRANSITION if possible. Clients which fail to do this may wish to warn the user that the transition itself is an insecure process. 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 Newman [Page 4]
Internet Draft Plain Transition SASL mechanism May 1997 S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=PLAINTRANSITION 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 PLAINTRANSITION S: + C: CXRpbQl0YW5zdGFhZnRhbnN0YWFmCg== 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 passive network observer can aquire the user's password if a client uses PLAINTRANSITION over an unencrypted stream. Clients are encouraged to record the occurance of a successful strong authentication or a successful PLAINTRANSITION for a given user, server and protocol combination and refuse to use plain text passwords for that user and that server in the future. This will prevent a man in the middle or a spoof server from aquiring the user's password by pretending no strong authentication mechanisms are available. 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> Newman [Page 5]
Internet Draft Plain Transition SASL mechanism May 1997 [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> [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 Special thanks to Ned Freed and Kevin Carosso for coming up with the basic idea for this proposal. 9. Author's Address Chris Newman Innosoft International, Inc. 1050 East Garvey Ave. South West Covina, CA 91790 USA Email: chris.newman@innosoft.com Newman [Page 6]