POP3 AUTHentication command
obsoleted by
- rfc-5034 — The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism
Extracted elements (15)
The server is not required to support any particular authentication mechanism, nor are authentication mechanisms required to support any protection mechanisms. This allows flexible deployment where servers may support only a subset of mechanisms, with USER/PASS or APOP serving as a last resort fallback.
The authentication mechanisms used by the POP3 AUTH command are those defined for IMAP4. Any use of the string "imap" in a server authentication identity within an IMAP4 authentication mechanism definition is replaced with the string "pop" when used with POP3.
If an AUTH command fails, the client may try another authentication mechanism by issuing another AUTH command, or may attempt to authenticate using the USER/PASS or APOP commands.
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.
If the requested authentication mechanism is not supported, the server should reject the AUTH command by sending a negative response.
Implementations MUST accept auth_type strings in a case-insensitive fashion.
The AUTH command may only be given in the AUTHORIZATION state.
The protection mechanism takes effect immediately following the CRLF that concludes the authentication exchange for the client, and the CRLF of the positive response for the server.
A protection mechanism provides integrity and privacy protection to the protocol session. If negotiated, it applies to all subsequent data sent over the connection. The maximum ciphertext buffer length is defined by the protection mechanism.
The AUTH command allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a protection mechanism for subsequent protocol interactions. It takes a single argument: a string identifying an IMAP4 authentication mechanism.
Security issues are discussed throughout the memo. The AUTH command enables negotiation of strong authentication mechanisms and optional protection mechanisms providing integrity and privacy, replacing or supplementing the plaintext USER/PASS and APOP authentication methods.
Upon successful completion of the authentication exchange, the POP3 server issues a positive response and the POP3 session enters the TRANSACTION state. On failure, the session remains in the AUTHORIZATION state.
A server challenge (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.
The AUTH command syntax is: "AUTH" followed by one or more spaces or tabs, then the auth_type (one or more ATOM_CHARs), optionally followed by base64 data lines, and terminated by CRLF. The continue_req server challenge is "+" SPACE base64 CRLF.
When a protection mechanism is in effect, each buffer of ciphertext is transferred over the connection prepended with a four-octet field in network byte order representing the length of the following data.