home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1734 < prev    next >
Text File  |  1994-12-20  |  8KB  |  284 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           J. Myers
  8. Request for Comments: 1734                               Carnegie Mellon
  9. Category: Standards Track                                  December 1994
  10.  
  11.  
  12.                       POP3 AUTHentication command
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22.  
  23. 1. Introduction
  24.  
  25.    This document describes the optional AUTH command, for indicating an
  26.    authentication mechanism to the server, performing an authentication
  27.    protocol exchange, and optionally negotiating a protection mechanism
  28.    for subsequent protocol interactions.  The authentication and
  29.    protection mechanisms used by the POP3 AUTH command are those used by
  30.    IMAP4.
  31.  
  32.  
  33. 2. The AUTH command
  34.  
  35.    AUTH mechanism
  36.  
  37.          Arguments:
  38.              a string identifying an IMAP4 authentication mechanism,
  39.              such as defined by [IMAP4-AUTH].  Any use of the string
  40.              "imap" used in a server authentication identity in the
  41.              definition of an authentication mechanism is replaced with
  42.              the string "pop".
  43.  
  44.          Restrictions:
  45.              may only be given in the AUTHORIZATION state
  46.  
  47.          Discussion:
  48.              The AUTH command indicates an authentication mechanism to
  49.              the server.  If the server supports the requested
  50.              authentication mechanism, it performs an authentication
  51.              protocol exchange to authenticate and identify the user.
  52.              Optionally, it also negotiates a protection mechanism for
  53.              subsequent protocol interactions.  If the requested
  54.              authentication mechanism is not supported, the server
  55.  
  56.  
  57.  
  58. Myers                                                           [Page 1]
  59.  
  60. RFC 1734                       POP3 AUTH                   December 1994
  61.  
  62.  
  63.              should reject the AUTH command by sending a negative
  64.              response.
  65.  
  66.              The authentication protocol exchange consists of a series
  67.              of server challenges and client answers that are specific
  68.              to the authentication mechanism.  A server challenge,
  69.              otherwise known as a ready response, is a line consisting
  70.              of a "+" character followed by a single space and a BASE64
  71.              encoded string.  The client answer consists of a line
  72.              containing a BASE64 encoded string.  If the client wishes
  73.              to cancel an authentication exchange, it should issue a
  74.              line with a single "*".  If the server receives such an
  75.              answer, it must reject the AUTH command by sending a
  76.              negative response.
  77.  
  78.              A protection mechanism provides integrity and privacy
  79.              protection to the protocol session.  If a protection
  80.              mechanism is negotiated, it is applied to all subsequent
  81.              data sent over the connection.  The protection mechanism
  82.              takes effect immediately following the CRLF that concludes
  83.              the authentication exchange for the client, and the CRLF of
  84.              the positive response for the server.  Once the protection
  85.              mechanism is in effect, the stream of command and response
  86.              octets is processed into buffers of ciphertext.  Each
  87.              buffer is transferred over the connection as a stream of
  88.              octets prepended with a four octet field in network byte
  89.              order that represents the length of the following data.
  90.              The maximum ciphertext buffer length is defined by the
  91.              protection mechanism.
  92.  
  93.              The server is not required to support any particular
  94.              authentication mechanism, nor are authentication mechanisms
  95.              required to support any protection mechanisms.  If an AUTH
  96.              command fails with a negative response, the session remains
  97.              in the AUTHORIZATION state and client may try another
  98.              authentication mechanism by issuing another AUTH command,
  99.              or may attempt to authenticate by using the USER/PASS or
  100.              APOP commands.  In other words, the client may request
  101.              authentication types in decreasing order of preference,
  102.              with the USER/PASS or APOP command as a last resort.
  103.  
  104.              Should the client successfully complete the authentication
  105.              exchange, the POP3 server issues a positive response and
  106.              the POP3 session enters the TRANSACTION state.
  107.  
  108.          Possible Responses:
  109.              +OK maildrop locked and ready
  110.              -ERR authentication exchange failed
  111.  
  112.  
  113.  
  114. Myers                                                           [Page 2]
  115.  
  116. RFC 1734                       POP3 AUTH                   December 1994
  117.  
  118.  
  119.  
  120.          Examples:
  121.              S: +OK POP3 server ready
  122.              C: AUTH KERBEROS_V4
  123.              S: + AmFYig==
  124.              C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
  125.                 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
  126.                 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
  127.              S: + or//EoAADZI=
  128.              C: DiAF5A4gA+oOIALuBkAAmw==
  129.              S: +OK Kerberos V4 authentication successful
  130.                 ...
  131.              C: AUTH FOOBAR
  132.              S: -ERR Unrecognized authentication type
  133.  
  134.               Note: the line breaks in the first client answer  are
  135.               for editorial clarity and are not in real authentica-
  136.               tors.
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Myers                                                           [Page 3]
  171.  
  172. RFC 1734                       POP3 AUTH                   December 1994
  173.  
  174.  
  175. 3. Formal Syntax
  176.  
  177.    The following syntax specification uses the augmented Backus-Naur
  178.    Form (BNF) notation as specified in RFC 822.
  179.  
  180.    Except as noted otherwise, all alphabetic characters are case-
  181.    insensitive.  The use of upper or lower case characters to define
  182.    token strings is for editorial clarity only.  Implementations MUST
  183.    accept these strings in a case-insensitive fashion.
  184.  
  185.    ATOM_CHAR       ::= <any CHAR except atom_specials>
  186.  
  187.    atom_specials   ::= "(" / ")" / "{" / SPACE / CTLs / "%" / "*" /
  188.                        <"> / "\"
  189.  
  190.    auth            ::= "AUTH" 1*(SPACE / TAB) auth_type *(CRLF base64)
  191.                        CRLF
  192.  
  193.    auth_type       ::= 1*ATOM_CHAR
  194.  
  195.    base64          ::= *(4base64_CHAR) [base64_terminal]
  196.  
  197.    base64_char     ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
  198.            "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
  199.                        "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
  200.                        "Y" / "Z" /
  201.                        "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
  202.                        "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
  203.                        "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
  204.                        "y" / "z" /
  205.                        "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
  206.                        "8" / "9" / "+" / "/"
  207.                        ;; Case-sensitive
  208.  
  209.    base64_terminal ::= (2base64_char "==") / (3base64_char "=")
  210.  
  211.    CHAR            ::= <any 7-bit US-ASCII character except NUL,
  212.                         0x01 - 0x7f>
  213.  
  214.    continue_req    ::= "+" SPACE base64 CRLF
  215.  
  216.    CR              ::= <ASCII CR, carriage return, 0x0C>
  217.  
  218.    CRLF            ::= CR LF
  219.  
  220.    CTL             ::= <any ASCII control character and DEL,
  221.                         0x00 - 0x1f, 0x7f>
  222.  
  223.  
  224.  
  225.  
  226. Myers                                                           [Page 4]
  227.  
  228. RFC 1734                       POP3 AUTH                   December 1994
  229.  
  230.  
  231.    LF              ::= <ASCII LF, line feed, 0x0A>
  232.  
  233.    SPACE           ::= <ASCII SP, space, 0x20>
  234.  
  235.    TAB             ::= <ASCII HT, tab, 0x09>
  236.  
  237.  
  238.  
  239. 4. References
  240.  
  241.    [IMAP4-AUTH]  Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
  242.    Carnegie Mellon, December 1994.
  243.  
  244.  
  245.  
  246. 5. Security Considerations
  247.  
  248.    Security issues are discussed throughout this memo.
  249.  
  250.  
  251.  
  252. 6. Author's Address
  253.  
  254.    John G. Myers
  255.    Carnegie-Mellon University
  256.    5000 Forbes Ave
  257.    Pittsburgh, PA 15213
  258.  
  259.    EMail: jgm+@cmu.edu
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Myers                                                           [Page 5]
  283.  
  284.