The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism
Extracted elements (25)
The original POP3 AUTH command predated SASL and was therefore missing key components such as a way to list available authentication mechanisms. RFC 2449 attempted to remedy this with CAPA and initial client response support, but problems remained in the specification's clarity.
This document consolidates POP3 AUTH information that was previously scattered across RFC 1734, RFC 2449, RFC 2595, RFC 3206, and RFC 4422 into a single document, because creating a full POP3 AUTH implementation required understanding at least five different documents.
POP3 does not allow for additional data to be sent with a message indicating a successful outcome (i.e., the +OK reply), unlike some other SASL-enabled protocols. This is a known difference from the general SASL framework defined in RFC 4422 Section 3.6.
The list of available SASL mechanisms MAY change after a successful STLS command. However, implementations MUST continue to include the SASL capability in CAPA responses even after a successful AUTH command has been completed, even though no further AUTH commands may be issued.
A server implementation MUST implement a configuration in which it does NOT advertise or permit any plaintext password mechanisms unless the STLS command has been used to negotiate a TLS session. Per RFC 4616, this SHOULD be the default configuration.
After an AUTH command has been successfully completed, no more AUTH commands may be issued in the same session. A server MUST reject any further AUTH commands with an -ERR reply.
Before using a plaintext password mechanism over a TLS session, client implementations MUST verify the TLS server certificate as required by RFC 2595, Section 2.4.
Client and server implementations of this extension MUST implement the PLAIN SASL mechanism running over TLS. This is a minimum interoperability requirement.
If a server does not support the CAPA command or does not advertise the SASL capability, clients SHOULD NOT attempt the AUTH command. If a client does attempt AUTH in such a situation, it MUST NOT supply the client initial response parameter for backwards compatibility with RFC 1734.
If specifying an initial response would cause the AUTH command to exceed the 255-octet limit defined in RFC 2449 Section 4, the client MUST NOT use the initial-response parameter and must instead send its initial response after an empty challenge.
If the client needs to send a zero-length initial response, it MUST transmit the response as a single equals sign ('='). This indicates that the response is present but contains no data.
If the initial response argument is omitted and the chosen mechanism requires an initial client response, the server MUST proceed by issuing an empty challenge: a line with only '+' followed by a single space, with no other data.
If the server cannot Base64 decode a client response, it MUST reject the AUTH command with an -ERR reply. If the client cannot Base64 decode a server challenge, it MUST cancel the authentication using the '*' response.
Servers and clients MUST reject any character not explicitly allowed by the Base64 alphabet, and MUST reject any sequence of Base64 characters that contains the pad character ('=') anywhere other than the end of the string.
The authorization identity generated by the SASL exchange SHOULD use the SASLprep profile of StringPrep to prepare names for matching. If preparation of the authorization identity fails or results in an empty string (unless transmitted as empty), the server MUST fail the authentication.
When a security layer takes effect, the server MUST discard any knowledge previously obtained from the client not obtained from the SASL negotiation itself, and the client MUST discard any knowledge obtained from the server such as the list of available POP3 service extensions.
When both TLS and SASL security layers are in effect, the TLS encoding MUST be applied after the SASL encoding when sending data.
The AUTH command takes a SASL mechanism name and an optional initial-response parameter. The initial response MUST be encoded as Base64 or consist only of the single character '=', which represents an empty initial response.
The SASL capability is advertised via the CAPA command and lists supported SASL mechanisms as a space-separated argument. It permits use of the AUTH command to begin a SASL negotiation as defined in RFC 4422. This capability supersedes the definition in Section 6.3 of RFC 2449.
The SASL service name for POP3 is 'pop'. This is the name specified by this protocol's profile of SASL and is used in GSSAPI/SASL service name registrations.
The IANA updated the POP3 extension registry at iana.org/assignments/pop3-extension-mechanism and the GSSAPI/SASL service name registry at iana.org/assignments/gssapi-service-names to refer to this RFC instead of RFC 1734.
Plaintext password mechanisms MUST NOT be advertised or permitted unless a TLS session has been negotiated via STLS. Client implementations MUST verify TLS server certificates before using plaintext passwords over TLS. Implementations SHOULD additionally support SASL mechanisms that do not send plaintext passwords, such as GSSAPI.
Upon successful completion of the AUTH exchange, the POP3 session transitions from the AUTHORIZATION state to the TRANSACTION state. The AUTH command may only be issued during the AUTHORIZATION state.
A server challenge during AUTH is sent as a line beginning with '+' followed by a single space and a Base64-encoded string. This line MUST NOT contain any text other than the Base64-encoded challenge. The continue-req ABNF is: '+ SP [base64] CRLF'.
The AUTH command syntax is: 'AUTH SP sasl-mech [SP initial-response] *(CRLF [base64]) [CRLF cancel-response] CRLF'. The initial-response is either a base64 string or '='. A cancel-response is a single '*' character.