--On Wednesday, April 12, 2023 3:16 PM +0200 Stefan Kania <[email protected]> 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


Reply via email to