Simple Authentication and Security Layer (SASL)
obsoleted by
- rfc-4422 — Simple Authentication and Security Layer (SASL)
- rfc-4752 — The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism
updated by
- rfc-2444 — The One-Time-Password SASL Mechanism
Extracted elements (28)
SASL separates the authorization identity from the authentication credentials identity, enabling proxy servers to authenticate with their own credentials while requesting privileges for a different identity. This feature is not always provided by transport security services such as TLS or IPsec.
The EXTERNAL mechanism is explicitly designed for the case where a transport security service (such as TLS or IPsec) secures the connection and authenticates the client, while SASL negotiates the authorization identity and transitions the protocol to 'authenticated' state. In this scenario a SASL security layer would be redundant and should be negotiated off.
TLS and similar transport security services do not fit the SASL model because their framing would be redundant with SASL framing and they do not provide the authorization identity negotiation that SASL requires. Protocols needing TLS should add a separate command (e.g., STARTTLS) outside the SASL command space.
If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer remains in effect. If a second security layer is selected, it replaces the first. This applies only when the protocol profile explicitly permits multiple SASL negotiations.
Protocol profiles must specify: the service name (from the IANA GSSAPI host-based service name registry), the authentication initiation command and its encoding of challenges/responses, where the security layer takes effect in each direction, and how the authorization identity is interpreted.
A protocol profile SHOULD include an optional initial response parameter in the command that initiates authentication, allowing the client to avoid a round trip with mechanisms where the client sends data first. If an initial response is sent but the selected mechanism requires the server to start, the command fails.
If a protocol profile does not permit a server challenge to be returned with a success indication, the server issues the challenge without success, the client responds with no data, and only then does the server indicate successful completion.
If a protocol profile does not permit an initial client response and the client sends data first, the server issues a challenge with no data and the client's response to that empty challenge is used as the initial client response.
In GSSAPI, the server must verify that the src_name from the GSS context is authorized to authenticate as the claimed authorization identity before completing the authentication process.
In KERBEROS_V4 and GSSAPI, bits in the security layer bitmask which are not understood MUST be negotiated off. Bit 1 means no security layer, bit 2 means integrity protection, bit 4 means privacy protection.
Unless the protocol profile explicitly permits multiple successful SASL negotiations, only one may occur per session and further attempts to initiate an exchange must fail after one succeeds. Multiple security layers must never be simultaneously in effect; a new security layer selection replaces the previous one.
SASL mechanism names are strings of 1 to 20 characters consisting of upper-case letters, digits, hyphens, and/or underscores. All mechanism names must be registered with IANA.
The authorization identity transmitted from client to server may differ from the identity in the client's authentication credentials, enabling proxy servers to authenticate with their own credentials while requesting access privileges for another identity. Transmitting an empty string directs the server to derive the authorization identity from authentication credentials.
The EXTERNAL mechanism (name 'EXTERNAL') defers authentication to an external system such as IPsec or TLS. The client sends an initial response with the authorization identity (or empty string to derive it from external credentials); the server uses out-of-band information to determine authorization.
The GSSAPI mechanism (name 'GSSAPI') uses GSS_Init_sec_context/GSS_Accept_sec_context iteratively until GSS_S_COMPLETE. After context establishment, the server sends a GSS_Wrap'd (conf_flag=FALSE) 4-octet structure with the supported security layer bitmask and maximum token size; the client replies with its selected layer, maximum size, and authorization identity.
The KERBEROS_V4 mechanism uses a two-challenge exchange: the server sends a random 32-bit challenge; the client responds with a Kerberos ticket and authenticator. The server then sends an 8-octet DES-ECB-encrypted structure containing the incremented checksum, supported security layer bitmask, and maximum cipher-text buffer size.
The SASL authentication exchange consists of a series of server challenges and client responses defined by the mechanism as binary tokens of arbitrary length. The protocol profile specifies how these tokens are encoded for transfer over the connection.
The SKEY mechanism (name 'SKEY') uses S/Key with MD4. The client sends an initial response with the authorization identity; the server challenges with a decimal sequence number, a space, and the seed string. The client responds with the one-time-password as either a 64-bit network byte order value or in 'six English words' format. No security layer is supported.
SASL Mechanisms registry maintained by IANA. Registration requires a mechanism name, security considerations, optional published specification, contact information, and intended usage (COMMON, LIMITED USE, or OBSOLETE). Registrations may not be deleted but can be marked OBSOLETE.
All protocol interactions prior to authentication are performed in the clear and may be modified. Security-sensitive protocol negotiations should be performed after authentication completes; protocols should be designed to ignore or revalidate pre-authentication negotiations once authentication is complete.
The client's SASL mechanism selection is transmitted in the clear and may be modified by an active attacker. New SASL mechanisms must be designed so that an attacker cannot obtain authentication with weaker security properties by modifying the mechanism name or the challenges and responses.
When a client selects a security layer with at least integrity protection, the negotiation of the security layer and authorization identity is itself integrity protected, preventing an active attacker from hijacking the connection and downgrading to a plaintext connection.
When a server or client supports multiple mechanisms of different security strengths, an active attacker can force use of the weakest mechanism. Both client and server should have a configurable minimum strength; a server-only check is insufficient because an attacker can modify the advertised mechanism list seen by the client.
The security layer takes effect immediately following the last response of the authentication exchange for data sent by the client, and immediately following the completion indication for data sent by the server. Once in effect, all subsequent protocol data is processed by the security layer.
In GSSAPI, the server's security negotiation token (after GSS_S_COMPLETE) contains 4 octets: octet 1 is the supported security layer bitmask, octets 2-4 are the maximum output_token size in network byte order. The client's response has the same structure followed by the authorization identity string.
In KERBEROS_V4, the client's final response is DES-PCBC-encrypted data: octets 1-4 are the original server checksum, octet 5 is the selected security layer bitmask, octets 6-8 are the client's maximum receive buffer size, followed by the authorization identity and zero-padding to a multiple of 8 octets.
In KERBEROS_V4, the server's second challenge is 8 octets encrypted with DES ECB: octets 1-4 are the incremented checksum (network byte order), octet 5 is the security layer bitmask, and octets 6-8 are the maximum cipher-text buffer size (network byte order).
When a security layer is in effect, each cipher-text buffer is transferred over the connection prepended with a four-octet field in network byte order representing the length of the following buffer. The cipher-text buffer length must not exceed the maximum size negotiated by the other side.