--On Wednesday, April 12, 2023 3:16 PM +0200 Stefan Kania stefan@kania-online.de wrote:
Hi to all,
when I connect to openldap, with simple-bind I see:
mech=SIMPLE bind_ssf=0 ssf=256
So there is no security factor for a SIMPLE bind mechanism. The *overall* security factor of the connection is 256 (likely this is a TLS encrypted connection)
When I connect to openldap with GSSAPI I see:
mech=GSSAPI bind_ssf=56 ssf=256
So I uses strong-bind via GSSAPI
there is no place where I can find anything about "bind_ssf". So what ist bind_ssf stands for?
It simply documents the strength of the mechanism used in the bind operation, which could come from as SASL bind or may be a simple bind, etc.
I only found: transport_ssf=<n> tls_ssf=<n> sasl_ssf=<n>
Another strange thing (to me ;-) ) The openldap admin guide is telling me:
The server uses Security Strength Factors (SSF) to indicate the relative strength of protection. A SSF of zero (0) indicates no protections are in place. A SSF of one (1) indicates integrity protection are in place. A SSF greater than one (>1) roughly correlates to the effective encryption key length. For example, DES is 56, 3DES is 112, and AES 128, 192, or 256.
in my kdc.conf I have:
supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal
So no DES with a key-length of 56 is defined. Same when I look at the key from my user I'm using to connect. The infos about the user is telling me in kadmin
Key: vno 1, aes256-cts-hmac-sha1-96 Key: vno 1, aes128-cts-hmac-sha1-96
So why is the log telling me ssf=56?
Because the SSF of GSSAPI is hard coded to be 56. With MIT kerberos they eventually fixed this, but it's still not fixed in Heimdal (last I checked, but haven't checked the status of that bug report in a while). Once that is fixed, then cyrus-sasl has to be fixed to pull in the real SSF, which so far has not been done. Then OpenLDAP could report the 'real' SSF of the SASL bind.
--Quanah