Overview#
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.
389 Directory Server allows setting Minimum SSF Usage within
ACIs, but the calculation of Security Strength Factor was not shown.
There might be more information for this subject on one of the following: