Re: meaning of bind_ssf

[Stefan Kania]

Am 12.04.23 um 23:39 schrieb Quanah Gibson-Mount:

--On Wednesday, April 12, 2023 3:16 PM +0200 Stefan Kania <ste...@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.

Ok thank's

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

----------------

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?

key length. For example, DES is 56, 3DES is 112, and AES 128, 192, or 256.

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.

Thank you for this information. I'm using Debian 11 with MIT-Kerberos. The installed Debian version is 1.18.3-6+deb11u3 so still 56 :-(

But now I know :-)

Thank's

Stefan

--Quanah

smime.p7s
Description: S/MIME Cryptographic Signature