[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 05                                                   
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

   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]

             an optional string identifying a SASL authentication
             an optional base64-encoded response

             may only be given in the AUTHORIZATION state

             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

             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
             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

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       = <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>

J. Myers                                                        [Page 5]

Internet Draft                 POP3 AUTH                  August 6, 1998

   LF              = <ASCII LF, line feed, 0x0A>

   SPACE           = <ASCII SP, space, 0x20>

   TAB             = <ASCII HT, tab, 0x09>

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]