Network Working Group J. Myers Internet Draft: POP3 Authentication Netscape Communications Document: draft-myers-sasl-pop3-05.txt August 1998 POP3 AUTHentication command 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 ftp.ietf.org, 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 before July 1997. Distribution of this draft is unlimited. 1. Introduction This document defines the optional AUTH command to POP3 [POP3], for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a security layer for subsequent protocol interactions. This extension is a profile of the Simple Authentication and Session Layer [SASL]. J. Myers [Page 1] Internet Draft POP3 AUTH August 6, 1998 2. Conventions Used in this Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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]. 3. The AUTH command AUTH [mechanism] [initial-response] Arguments: an optional string identifying a SASL authentication mechanism. an optional base64-encoded response Restrictions: may only be given in the AUTHORIZATION state Discussion: If no argument was given and the POP3 server issues a positive response, then he response given is multi-line. After the initial +OK, for each SASL mechanism supported, the POP3 server responds with a line containing the name of the SASL mechanism. If at least one argument was given, the AUTH command indicates an authentication mechanism to the server. If the server supports the requested authentication mechanism, it performs an authentication protocol exchange to authenticate and identify the user. Optionally, it also negotiates a security layer for subsequent protocol interactions. If the requested authentication mechanism is not supported, the server SHOULD reject the AUTH command by sending a negative response. The authentication protocol exchange consists of a series of server challenges and client answers that are specific to the authentication mechanism. A server challenge, otherwise known as a ready response, is a line consisting of a "+" character followed by a single space and a BASE64 encoded string. The client answer consists of a line containing a BASE64 encoded string. If the client wishes to cancel an authentication exchange, it SHOULD issue a line with a single "*". If the server receives such an J. Myers [Page 2] Internet Draft POP3 AUTH August 6, 1998 answer, it MUST reject the AUTH command by sending a negative response. The optional initial-response argument to the AUTH command is used to save a round trip when using authentication mechanisms that are defined to send no data in the initial challenge. When the initial-response argument is used with such a mechanism, the initial empty challenge is not sent to the client and the server uses the data in the initial- response argument as if it were sent in response to the empty challenge. If the initial-response argument to the AUTH command is used with a mechanism that sends data in the initial challenge, the server MUST reject the AUTH command by sending a negative response. The service name specified by this protocol's profile of SASL is "pop". If a security layer is negotiated through the SASL authentication exchange, it takes effect immediately following the CRLF that concludes the authentication exchange for the client, and the CRLF of the positive response for the server. The server is not required to support any particular authentication mechanism, nor are authentication mechanisms required to support any security layers. If an AUTH command fails with a negative response, the session remains in the AUTHORIZATION state and client may try another authentication mechanism by issuing another AUTH command, or may attempt to authenticate by using the USER/PASS or APOP commands. In other words, the client may request authentication types in decreasing order of preference, with the USER/PASS or APOP command as a last resort. Should the client successfully complete the authentication exchange, the POP3 server issues a positive response and the POP3 session enters the TRANSACTION state. The BASE64 string may in general be arbitrarily long. Clients and servers MUST be able to support challenges and responses that are as long as are generated by the authentication mechanisms they support, independent of any line length limitations the client or server may have in other parts of its protocol implementation. Possible Responses: +OK list of supported mechanisms follows J. Myers [Page 3] Internet Draft POP3 AUTH August 6, 1998 +OK maildrop locked and ready -ERR authentication exchange failed Examples: S: +OK POP3 server ready C: AUTH S: +OK Listing of supported mechanisms follows S: KERBEROS_V4 S: S/KEY S: . C: AUTH KERBEROS_V4 S: + AmFYig== C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh S: + or//EoAADZI= C: DiAF5A4gA+oOIALuBkAAmw== S: +OK Kerberos V4 authentication successful ... C: AUTH FOOBAR S: -ERR Unrecognized authentication type C: AUTH SKEY c21pdGg= S: + OTUgUWE1ODMwOA== C: BsAY3g4gBNo= S: +OK S/Key authentication successful Note: the line breaks in the first client answer are for editorial clarity and are not in real authenticators. J. Myers [Page 4] Internet Draft POP3 AUTH August 6, 1998 4. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in RFC 822. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. ATOM_CHAR = atom_specials = "(" / ")" / "{" / SPACE / CTLs / "%" / "*" / <"> / "\" auth = "AUTH" [ 1*(SPACE / TAB) auth_type [ 1*(SPACE / TAB) base64 ] *(CRLF base64) ] CRLF auth_type = 1*ATOM_CHAR base64 = *(4base64_CHAR) [base64_terminal] base64_char = "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" / "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "+" / "/" ;; Case-sensitive base64_terminal = (2base64_char "==") / (3base64_char "=") CHAR = continue_req = "+" SPACE base64 CRLF CR = CRLF = CR LF CTL = J. Myers [Page 5] Internet Draft POP3 AUTH August 6, 1998 LF = SPACE = TAB = 5. References [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3.", RFC 1939, May 1996 [SASL] Myers, J., "Simple Authentication and Security Layer", RFC 2222, October 1997 6. Security Considerations Security issues are discussed throughout this memo. Additional security considerations are mentioned in the SASL specification [SASL]. 7. Author's Address: John Gardiner Myers Netscape Communications 501 East Middlefield Road Mail Stop MV-029 Mountain View, CA 94043 Email: jgmyers@netscape.com J. Myers [Page 6]