Build | | GitHub | Twitter

This document provide note and summary of RFC 4422, Simple Authentication and Security Layer (SASL).

1. Introduction

SASL is conceptually a framework that provides an abstraction layer between protocols and mechanisms as illustrated in the following diagram.

    SMTP    LDAP    XMPP   Other protocols ...
       \       |    |      /
        \      |    |     /
       SASL abstraction layer
        /      |    |     \
       /       |    |      \
EXTERNAL   GSSAPI  PLAIN   Other mechanisms ...

2. Identity Concepts

Authentication identity is an identity that is used on credential form that will be passed to SASL server to get the authorization identity.

Authorization identity is the actual identity in system.

For example, the username and password to login to system is called authentication identity, and when the username exist and the password is correct, the system may use unique number (identification or ID) as authorization identity to replace the username.

The SASL describe the syntax and semantics on how the username, password, and authorization identity to be transferred by mechanism.

3. The Authentication Exchange

The following illustration provides a high-level overview of an authentication exchange.

C: Request available mechanism on server
S: List of available mechanism
<Client select the best and suitable mechanism>
C: Request authentication exchange
<Mechanism name + [ additional data ]>
S: Initial challenge
C: Initial response
<additional challenge/response messages>
S: Outcome of authentication exchange

Some mechanism may simplified this exchange into,

C: Request authentication exchange + Initial response
S: Outcome of authentication exchange

The initial response may contains the authentication identity, depends on mechanism specification.

The authentication exchange involves one or more pairs of server-challenges and client-responses, the particulars of which are mechanism specific.

Server may return the authorization identity to client when on the successful outcome of authentication exchange.

Server MUST provide an outcome message that can be distinguished between errors from input by client or errors from server (for example, invalid credential, timeout, internal server error).

Client or server may abort the authentication exchange any time.

3.1. Mechanism Naming

sasl-mech    = 1*20mech-char
; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _
; from ASCII character set.

UPPER-ALPHA  = %x41-5A  ; A-Z (uppercase only)
DIGIT        = %x30-39  ; 0-9
HYPHEN       = %x2D ; hyphen (-)
UNDERSCORE   = %x5F ; underscore (_)

3.2. Security Layers

If use of a security layer is negotiated in the authentication protocol exchange, the layer is installed by the server after indicating the outcome of the authentication exchange and installed by the client upon receipt of the success outcome indication. The security layer is in effect until underlying transport connection is closed.

The underlying transport connection MUST be closed when the security layer unable or unwilling to encode or decode buffers that protect protocol data.

The length of the protected data buffer MUST be no larger than the maximum size that the other side expects. The maximum size is fixed by mechanism, either through negotiation or by specification. Upon the receipt of a length field whose value is greater than the maximum size, the receiver SHOULD close the connection, as this might be a sign of an attack.

If a security layer is in effect and a subsequent SASL negotiation selects a second security layer, then the second security layer replaces the first.

If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer remains in effect.

4. Protocol Requirements

In order for a protocol to offer SASL services, its specification MUST supply the following information:

  1. A service name, to be selected from registry of "service" elements for the Generic Security Service Application Program Interface (GSSAPI) host-based service name form.

  2. A function through which the client may discover the names of the SASL mechanisms that the server makes available to the client.

  3. Definition of the messages necessary for authentication exchange, including the following:

    1. A message to initiate the authentication exchange. The message MUST contain a field for mechanism name and SHOULD contain an optional field for carrying an initial response. The message MUST be able to distinguished between an empty initial response and no initial response.

    2. Messages to transfer server challenges and client responses.

    3. A message to indicate the outcome of the authentication. This message SHOULD contain an optional field for carrying additional data with a successful outcome.

  4. Prescribe the syntax and semantics of non-empty authorization identity strings exchange. The protocol specification MUST detail precisely how and where (client or server) non-empty authorization identity strings are prepared, including all normalizations, for comparison and other applicable functions to ensure proper function.

  5. Detail any facility the protocol provides that allows the client and/or server to abort authentication exchange.

  6. Identify precisely where newly negotiated security layers start to take effect, in both directions.

  7. If the protocol supports other layered security services, such as Transport Layer Security (TLS), the specification MUST prescribe the order in which security layers are applied to protocol data.

  8. Indicate whether the protocol supports multiple authentications. If so, the protocol MUST detail the effect a failed SASL authentication exchange will have upon a previously established authentication and authorization state.

5. Mechanism Specifications

SASL mechanism specifications MUST supply the following information:

  1. The name of the mechanism.

  2. A definition of the server-challenges and client-responses of the authentication exchange, as well as the following:

    1. An indication of whether the mechanism is client-first. If a SASL mechanism is defined as client-first and the client does not send an initial response in the authentication request, then the first server challenge MUST be empty.

      If a SASL mechanism is defined as server-first, then the client MUST NOT send an initial client response in the authentication request.

    2. An indication of whether the server is expected to provide additional data when indicating a successful outcome.

      SASL mechanisms SHOULD be designed to minimize the number of challenges and responses necessary to complete the exchange.

  3. An indication of whether the mechanism is capable of transferring authorization identity strings.

    The mechanism SHOULD NOT be capable of transferring both no authorization identity string and an empty authorization identity.

    Mechanisms that are capable of transferring an authorization identity string MUST be capable of transferring arbitrary non-empty sequences of Unicode characters, excluding those that contain the NUL (U+0000) character. The specification MUST detail how any Unicode code points special to the mechanism that might appear in the authorization identity string are escaped to avoid ambiguity during decoding of the authorization identity string.

  4. The specification MUST detail whether the mechanism offers a security layer.

  5. If the underlying cryptographic technology used by a mechanism supports data integrity, then the mechanism specification MUST integrity protect the transmission of an authorization identity and the negotiation of the security layer.

SASL mechanisms SHOULD be protocol neutral.

SASL mechanisms SHOULD reuse existing credential and identity forms, as well as associated syntaxes and semantics.

SASL mechanisms SHOULD use the UTF-8 transformation format for encoding Unicode code points for transfer.

The mechanism SHOULD NOT use the authorization identity string in generation of any long-term cryptographic keys or hashes as there is no requirement that the authorization identity string be canonical.

6. Security Considerations

6.1. Active Attacks

When use of a security layer is negotiated by the authentication protocol exchange, the receiver SHOULD handle gracefully any protected data buffer larger than the defined/negotiated maximal size. In particular, it MUST NOT blindly allocate the amount of memory specified in the buffer size field, as this might cause the "out of memory" condition. If the receiver detects a large block, it SHOULD close the connection.

6.1.1. Hijack Attacks

Implementations SHOULD close the connection security layer report protocol data lack of data integrity.

6.1.2. Downgrade Attacks

Implementations SHOULD NOT advertise mechanisms and/or features that cannot meet their minimum security requirements. Implementation SHOULD NOT enter into or continue authentication exchanges that cannot meet their minimum security requirements, and SHOULD verify that completed authentication exchanges result in security services that meet their minimum security requirements.

If the client finds that the integrity-protected list (the list obtained after the security layer was installed) contains a stronger mechanism than those in the previously obtained list, the client should assume that the previously obtained list was modified by an attacker and SHOULD close the underlying transport connection.

6.1.3. Replay Attacks

Some mechanisms may be subject to replay attacks unless protected by external data security services (e.g., TLS).

6.1.4. Truncation Attacks

A protocol can defend against these attacks by ensuring that each information exchange has a clear final result and that each protocol session has a graceful closure mechanism, and that these are integrity protected.

6.2. Passive Attacks

Many mechanisms are subject to various passive attacks, including simple eavesdropping of unprotected credential information as well as online and off-line dictionary attacks of protected credential information.

6.3. Re-keying

Re-keying (key renegotiation process) is a way of addressing the weakening of cryptographic keys. The SASL framework does not itself provide for re-keying; SASL mechanisms may. Designers of future SASL mechanisms should consider providing re-keying services.

7. Mechanism Registry

The SASL mechanism registry is maintained by IANA. The registry is currently available at <>.