SMTP Service Extension for Authentication
obsoleted by
- rfc-4954 — SMTP Service Extension for Authentication
Extracted elements (25)
It may be undesirable for a submission server to advertise a SASL mechanism when use of that mechanism grants the client no benefits over anonymous submission, since a message submission client may require user authentication whenever a suitable mechanism is advertised.
The optional initial-response argument to AUTH saves a round trip for mechanisms that send no data in the initial challenge; a zero-length initial response uses '=' rather than an empty string to distinguish it from a zero-length answer to a 334 challenge.
This extension is not intended to replace end-to-end message signature/encryption (S/MIME, PGP). It addresses a different problem: it is useful within a trusted enclave, protects the message envelope rather than body, authenticates submission rather than authorship, and can assure delivery to the next hop when mutual authentication and a security layer are negotiated.
A client MAY compare the list of advertised SASL mechanisms before and after authentication to detect an active down-negotiation attack, as an exception to the general rule of discarding pre-SASL server knowledge.
The SASL service name used by this profile is 'smtp'. Implementations must use this service name when constructing SASL exchanges to ensure cross-implementation compatibility.
A MAIL FROM parameter of AUTH=<> indicates the original submitter is unknown; the server MUST NOT treat the message as having been originally submitted by the client.
After a successful AUTH command, the server MUST reject any further AUTH commands in the same session with a 503 reply.
All alphabetic characters in AUTH syntax strings are case-insensitive; implementations MUST accept them in a case-insensitive fashion.
Clients and servers MUST be able to support BASE64 challenges and responses of arbitrary length, as long as the authentication mechanisms they support may generate, independent of other line length limitations.
If an AUTH command fails, the server MUST behave as if the client had not issued the AUTH command, allowing the client to try another mechanism.
If an AUTH=<> parameter was supplied (explicitly or by policy), the server MUST supply AUTH=<> when relaying the message to any server to which it has authenticated using the AUTH extension.
If the client sends a single '*' to cancel an authentication exchange, the server MUST reject the AUTH command with a 501 reply.
If the server does not sufficiently trust the authenticated identity of the client, or if the client is not authenticated, the server MUST behave as if AUTH=<> was supplied.
The client SHOULD send an EHLO command as the first command after a successful SASL negotiation that results in a security layer being enabled.
Upon security layer activation, the server MUST discard knowledge obtained from the client (e.g., EHLO argument) not derived from SASL negotiation; the client MUST discard server knowledge (e.g., service extension list) not derived from SASL negotiation.
A new SMTP verb 'AUTH' is defined, taking a mechanism name and an optional base64-encoded initial response as arguments. The AUTH command cannot be issued during a mail transaction.
An optional AUTH parameter is added to the MAIL FROM command (AUTH=addr-spec or AUTH=<>), encoded as xtext, communicating the authenticated identity of the original message submitter. This extends the maximum MAIL FROM line length by 500 characters.
Server challenges during authentication are 334 replies with BASE64-encoded text; client responses are lines containing BASE64-encoded strings. A zero-length initial response is encoded as a single '=' character rather than an empty string.
Six authentication-specific SMTP error codes are defined: 432 (password transition needed), 534 (mechanism too weak), 538 (encryption required), 454 (temporary authentication failure), 503 (already authenticated), and 530 (authentication required).
The AUTH SMTP service extension is identified by EHLO keyword 'AUTH', which advertises a space-separated list of supported SASL mechanism names as its parameter.
Before SASL negotiation begins, all protocol interactions are in the clear and may be modified by an active attacker; therefore clients and servers MUST discard any knowledge obtained prior to the start of SASL negotiation upon completion of a negotiation resulting in a security layer.
If a client uses this extension for an encrypted tunnel, it must be configured to never send mail to the server when the connection is not mutually authenticated and encrypted, to prevent an attacker from hijacking the connection and stealing mail by suppressing or failing AUTH.
The AUTH=<> parameter prevents a TCP port-redirect attack (relay to submission port) from causing a relayed message to inherit the relay client's authentication. This extension does not protect the TCP port itself.
When a SASL security layer is negotiated, it takes effect immediately after the CRLF concluding the authentication exchange (client side) and after the CRLF of the 235 success reply (server side). The SMTP protocol then resets to its initial state, and both client and server MUST discard knowledge obtained prior to the SASL negotiation.
The AUTH command syntax is: 'AUTH' SPACE auth_type [SPACE (base64 / '=')] followed by optional continuation lines of base64 data. The auth_type is 1–20 characters from ALPHA, DIGIT, '-', and '_'. The AUTH= MAIL FROM parameter uses xtext encoding where the decoded value must be an addr-spec or '<>'.