Network Working Group J. Myers Internet Draft: SMTP Authentication February 1997 Document: draft-myers-sasl-pop3-01.txt 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]. Myers [Page 1]
Internet Draft POP3 AUTH 26 February 1997 2. Conventions Used in this Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The following terms are used in this document to signify the requirements of this specification. 1) MUST, or the adjective REQUIRED, means that the definition is an absolute requirement of the specification. 2) MUST NOT that the definition is an absolute prohibition of the specification. 3) SHOULD means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications MUST be understood and carefully weighed before choosing a different course. 4) SHOULD NOT means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications SHOULD be understood and the case carefully weighed before implementing any behavior described with this label. 5) MAY, or the adjective OPTIONAL, means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option. "Can" is used instead of "may" when referring to a possible circumstance or situation, as opposed to an optional facility of the protocol. 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 Myers [Page 2]
Internet Draft POP3 AUTH 26 February 1997 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. Option- ally, it also negotiates a security layer for subsequent protocol interactions. If the requested authentication mechanism is not sup- ported, the server SHOULD reject the AUTH command by sending a nega- tive response. The authentication protocol exchange consists of a series of server challenges and client answers that are specific to the authentica- tion mechanism. A server challenge, otherwise known as a ready response, is a line consisting of a "+" character followed by a sin- gle 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 com- mand is used with a mechanism that sends data in the initial chal- lenge, 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 con- cludes 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 Myers [Page 3]
Internet Draft POP3 AUTH 26 February 1997 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 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 edi- torial clarity and are not in real authenticators. Myers [Page 4]
Internet Draft POP3 AUTH 26 February 1997 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-insen- sitive. 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 26 February 1997 LF ::= <ASCII LF, line feed, 0x0A> SPACE ::= <ASCII SP, space, 0x20> TAB ::= <ASCII HT, tab, 0x09> 5. References [SASL] Myers, J., "Simple Authentication and Security Layer", draft-myers-auth-sasl-XX.txt, Carnegie Mellon. 6. Security Considerations Security issues are discussed throughout this memo. Additional security considerations are mentioned in the SASL specifi- cation [SASL]. 7. Author's Address: John G. Myers 220 Palo Alto Ave, Apt 102 Palo Alto, CA 94301 Email: jgm@cmu.edu Myers [Page 6]