Network Working Group J. Myers Internet Draft: SMTP Authentication Carnegie Mellon Document: draft-myers-sasl-pop3-00.txt November 1996 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 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 before July 1997. Distribution of this draft is unlimited. 1. Introduction This document describes the optional AUTH command, 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]. 2. The AUTH command AUTH [mechanism] [initial-response] Arguments: an optional string identifying a SASL authentication mechanism. an optional base64-encoded response Myers [Page 1]
Internet Draft POP3 AUTH November 15, 1996 Restrictions: may only be given in the AUTHORIZATION state Discussion: If no argument was given and the POP3 server issues a positive response, thn 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 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 should 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 Myers [Page 2]
Internet Draft POP3 AUTH November 15, 1996 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 +OK maildrop locked and ready -ERR authentication exchange failed Myers [Page 3]
Internet Draft POP3 AUTH November 15, 1996 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. Myers [Page 4]
Internet Draft POP3 AUTH November 15, 1996 3. 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 ::= <any CHAR except atom_specials> 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 ::= <any 7-bit US-ASCII character except NUL, 0x01 - 0x7f> continue_req ::= "+" SPACE base64 CRLF CR ::= <ASCII CR, carriage return, 0x0C> CRLF ::= CR LF CTL ::= <any ASCII control character and DEL, 0x00 - 0x1f, 0x7f> Myers [Page 5]
Internet Draft POP3 AUTH November 15, 1996 LF ::= <ASCII LF, line feed, 0x0A> SPACE ::= <ASCII SP, space, 0x20> TAB ::= <ASCII HT, tab, 0x09> 4. References [SASL] Myers, J., "Simple Authentication and Security Layer", draft-myers-auth-sasl-XX.txt, Carnegie Mellon. 5. Security Considerations Security issues are discussed throughout this memo. Additional security considerations are mentioned in the SASL specification [SASL]. 6. Author's Address: John G. Myers Carnegie-Mellon University 5000 Forbes Ave Pittsburgh, PA 15213 EMail: jgm+@cmu.edu Myers [Page 6]