Simple Authentication and Security Layer (SASL)
obsoletes
- rfc-2222 — Simple Authentication and Security Layer (SASL)
Extracted elements (30)
SASL is designed as an abstraction layer between protocols (SMTP, LDAP, XMPP) and mechanisms (EXTERNAL, GSSAPI, PLAIN) so that new protocols can reuse existing mechanisms without redesign and existing protocols can adopt new mechanisms without redesign. This layering intentionally does not hide mechanism particulars from protocol implementations, since identity mapping between authentication and authorization identities is necessarily protocol-specific.
The authorization identity string is defined as a Unicode string (not an octet string as implied by RFC 2222) to allow unambiguous internationalized identity transfer. The NUL character is prohibited to avoid ambiguity in C-string implementations and decoding.
The EXTERNAL mechanism provides no security protection and is vulnerable to spoofing, active attack, and eavesdropping. It SHOULD only be used when adequate security services (e.g., TLS) have already been established externally.
Where a mechanism specifies the client sends data first and the protocol provides an optional initial response field in the authentication request, using that field eliminates one round-trip. Protocols MUST define how an empty initial response is distinguished from an absent initial response to support this optimization correctly.
A mechanism SHOULD NOT use the authorization identity string in generation of any long-term cryptographic keys or hashes, because different clients may provide semantically equivalent but textually different authorization identity strings, causing interoperability failures.
A protocol supporting SASL MUST supply: a GSSAPI service name, mechanism negotiation facility detail, authentication exchange message definitions (including mechanism name field, optional initial response, challenge/response, and outcome messages), authorization identity string syntax, abort facility, security layer activation point, security layer ordering if other layers (e.g., TLS) are supported, and multiple-authentication behavior.
A SASL mechanism specification MUST supply: the mechanism name (which MUST be registered with IANA), the series of server-challenges and client-responses, whether the mechanism is client-first/server-first/variable, whether the server sends additional data on success, whether a security layer is offered, and (if so) the security services and their implementation.
For simple user names and/or passwords in authentication credentials, SASLprep (RFC 4013, a StringPrep profile) SHOULD be specified as the string preparation algorithm to ensure interoperability.
If at any time the security layer is unable or unwilling to continue producing protected buffers, or is not able to decode a received buffer, the underlying transport connection MUST be closed. In both cases, it SHOULD be closed gracefully.
If the protocol supports other layered security services such as TLS, its specification MUST prescribe the order in which security layers are applied to protocol data.
If the underlying cryptographic technology used by a mechanism supports data integrity, the mechanism specification MUST integrity-protect transmission of the authorization identity string and negotiation of the security layer.
Mechanisms capable of transferring an authorization identity string MUST support arbitrary non-empty Unicode sequences (excluding NUL). Mechanisms SHOULD use UTF-8; the specification MUST detail how characters special to the mechanism are escaped in the authorization identity string.
The length of a protected data buffer MUST be no larger than the maximum size the other side expects. Upon receipt of a length field whose value exceeds the maximum size, the receiver SHOULD close the connection, as this may indicate an attack.
The protocol's initiation message MUST contain a field for the mechanism name. It SHOULD contain an optional initial response field; if defined, the specification MUST distinguish empty initial response from absent initial response, and the field MUST carry arbitrary octet sequences.
The protocol specification MUST detail precisely how and where non-empty authorization identity strings are prepared (including all normalizations) for comparison, in order to avoid interoperability problems due to differing normalizations.
Unless explicitly permitted by the protocol specification, only one successful SASL authentication exchange may occur in a protocol session; further attempts to initiate an authentication exchange MUST fail after a successful exchange.
Where multiple successful SASL negotiations are permitted, multiple SASL security layers MUST NOT be simultaneously in effect; a newly negotiated security layer replaces the previous one, and if no layer is selected the original remains.
SASL mechanism names are character strings of 1 to 20 characters consisting solely of ASCII uppercase letters (A-Z), digits (0-9), hyphens (-), and underscores (_). The ABNF production is: sasl-mech = 1*20mech-char.
The authorization identity string is a sequence of zero or more Unicode characters excluding NUL (U+0000). An absent or empty string means the client requests to act as the identity associated with its credentials; a non-empty string requests to act as that represented identity.
The SASL EXTERNAL mechanism allows a client to request that the server use externally established credentials (e.g., via TLS or IPsec) for authentication. It does not provide a security layer and carries an optional UTF-8 encoded authorization identity string as its sole client message.
The SASL Mechanism Registry is maintained by IANA. Individual mechanism names are registered First Come First Served; family name prefixes require Expert Review. Registrations include: mechanism name, security considerations, published specification, intended usage (COMMON/LIMITED USE/OBSOLETE), and owner/change controller. Registrations may not be deleted but may be marked OBSOLETE.
Cryptographic keys in SASL security layers weaken over time and use. The SASL framework does not itself provide re-keying; mechanism designers should consider providing it. Implementations wishing to re-key where the mechanism does not support it SHOULD reauthenticate with the same identities to replace expiring security layers.
Most SASL security layers do not themselves defend against truncation attacks in which an active attacker closes the session, truncating the integrity-protected data stream. Protocols can defend by ensuring information exchanges have clear final results and graceful closure mechanisms protected by integrity.
SASL mechanism negotiation is not protected by the subsequent authentication exchange and is therefore subject to downgrade attacks. Implementations SHOULD NOT advertise mechanisms that cannot meet minimum security requirements, SHOULD NOT enter exchanges that cannot meet them, and SHOULD verify that completed exchanges result in services that meet requirements. The client can detect downgrade attacks by comparing the server's mechanism list before and after installing an integrity-protected security layer.
Some SASL mechanisms may be subject to replay attacks unless protected by external data security services such as TLS.
Upon receiving a protected data buffer, the receiver MUST NOT blindly allocate the amount of memory specified in the buffer size field, as an oversized value may indicate an attack and could cause an out-of-memory condition. If a large block is detected, the receiver SHOULD close the connection.
When a SASL security layer with at least integrity protection is in effect, it protects against connection hijack attacks that modify post-authentication protocol data. Implementations SHOULD close the connection when the security layer reports lack of data integrity.
A SASL authentication exchange begins with a client request naming a mechanism, followed by one or more server-challenge/client-response pairs, and concludes with a server outcome message. If a security layer was negotiated and the outcome is successful, the layer is installed immediately after the outcome.
Each security-layer protected-data buffer is transferred over the transport as a four-octet network-byte-order length field followed by the buffer octets. The length field value MUST NOT exceed the maximum size negotiated or specified for the receiving side.
The EXTERNAL mechanism's initial response is a UTF-8 encoded authorization identity string (authz-id-string = *UTF8-char-no-nul, where UTF8-1-no-nul = %x01-7F). An empty response means the client requests the identity associated with its external credentials; a non-empty response names the desired authorization identity.