The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
updates
- rfc-2595 — Using TLS with IMAP, POP3 and ACAP
Extracted elements (20)
Clear-text, multiple-use passwords are chosen because they interoperate with almost all existing operating system authentication databases and facilitate a smooth transition to more secure mechanisms, despite the drawback of being unacceptable over unencrypted connections.
SASLprep is recommended but not mandatory so that servers may employ other preparation algorithms (including none) when necessary, for example to interoperate with an external authentication system that uses a different scheme.
The ABNF grammar (updated from RFC 2595) allows LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) in authzid, authcid, and passwd productions, but whether they may actually be used depends on applicable string preparation rules; for passwd and authcid, control characters are prohibited.
The PLAIN mechanism is intended for use in protocols that lack a simple password authentication command (e.g., ACAP, SMTP-AUTH) and is not a replacement for protocols that already have such a command.
By default, implementations SHOULD advertise and make use of the PLAIN mechanism only when adequate data security services are in place (e.g., TLS).
Regardless of the preparation algorithm used, if preparation fails or results in an empty string, verification SHALL fail.
Regardless of the preparation algorithm used, if the output of a non-invertible function (e.g., hash) of the expected string is stored, the string MUST be prepared before input to that function.
Servers MUST be capable of accepting authzid, authcid, and passwd productions up to and including 255 octets. Note that a single Unicode character may encode to up to 4 UTF-8 octets.
Specifications for IETF protocols that indicate PLAIN is an applicable authentication mechanism MUST mandate that implementations support a strong data security service such as TLS.
The authzid, authcid, passwd, and NUL delimiters SHALL be transferred as UTF-8 encoded strings of Unicode characters.
The NUL (U+0000) character MUST NOT appear in the authzid, authcid, or passwd productions because it is used as the field delimiter.
The SASLPrep profile of StringPrep is the RECOMMENDED preparation algorithm for both presented and stored authentication identity and password strings before verification.
SASLprep preparation is applied differently to presented strings (treated as 'query' strings — unassigned code points allowed) versus database strings (treated as 'stored' strings — unassigned code points prohibited).
The authorization identity (authzid) is optional; when absent, the server derives the authorization identity from the prepared representation of the authentication identity (authcid). The authzid form is specific to the application-level SASL profile.
The PLAIN SASL mechanism is a single-message mechanism: the client sends one message to the server containing authzid, authcid, and passwd; the server verifies the credentials and the authorization identity, then authenticates the user if both checks succeed.
The IANA SASL Mechanism registry entry for PLAIN has been updated to reference RFC 4616 as the technical specification, with intended usage COMMON and IESG as author/change controller.
General SASL security considerations, as well as Unicode, UTF-8, and StringPrep security considerations, all apply to the PLAIN mechanism.
The PLAIN mechanism provides no integrity or confidentiality protections itself. By default, implementations SHOULD NOT advertise and SHOULD NOT make use of PLAIN unless adequate data security services (e.g., TLS) are in place.
When the PLAIN mechanism is used, the server gains the ability to impersonate the user to all services sharing the same password, regardless of any TLS encryption. Clients are encouraged to have an operational mode where all mechanisms that reveal the user's password to the server are disabled.
The PLAIN mechanism client message consists of an optional authzid, a NUL (U+0000) delimiter, the authcid, another NUL delimiter, and the passwd — all UTF-8 encoded Unicode strings. ABNF: message = [authzid] UTF8NUL authcid UTF8NUL passwd.