Security Strength Factor


Security Strength Factor (SSF) appears to be a broadly interpreted value within some SASL implementations.

We can find No definition has been found in any RFC.


SSF, the Security Strength Factor, indicates the strength of the SASL protection. If the mechanism supports a security layer, the client and server negotiate the SSF. The value of the SSF is based on the security properties that were specified before the SASL negotiation. If a non-zero SSF is negotiated, both client and server need to use the mechanism's security layer when the authentication has completed.

SSF is represented by an integer with one of the following values:

  • 0 – No protection.
  • 1 – Integrity checking only.
  • >1 – Supports authentication, integrity and confidentiality. The number represents the encryption key length.

The confidentiality and integrity operations are performed by the security mechanism. libsasl coordinates these requests.


OpenLDAP has multiple SSFs. For each session, there is one for SASL, one for TLS, etc., and an overall session SSF (the greatest SSF of any particular layer).

From slapd.conf(5): an integer approximate to effective key length used for encryption.

  • 0 (zero) implies no protection,
  • 1 implies integrity protection only,
  • 56 allows DES or other weak ciphers,
  • 112 allows triple DES and other strong ciphers,
  • 128 allows RC4, Blowfish and other modern strong ciphers.

SASL/EXTERNAL, itself, provides no security layers.There may be protections provided by lower layers (like TLS) and, if so, these are reflected in SSF associated with the particular layer providing the protection as well as the overall SSF.[2]

389 Directory Server[3]#

389 Directory Server allows setting Minimum SSF Usage within ACIs, but the calculation of Security Strength Factor was not shown.

More Information#

There might be more information for this subject on one of the following: