One document matched: draft-myers-sasl-pop3-02.txt
Differences from draft-myers-sasl-pop3-01.txt
Network Working Group J. Myers
Internet Draft: POP3 Authentication Netscape Communications
Document: draft-myers-sasl-pop3-02.txt November 1997
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 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 October 27, 1997
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 October 27, 1997
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 October 27, 1997
+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 October 27, 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-
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 October 27, 1997
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",
draft-myers-auth-sasl-13.txt, November 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]
| PAFTECH AB 2003-2026 | 2026-04-24 09:09:12 |