Seems I do not understand the ssf entries..... either that or something a bit more strange.

[Pat Riehecky <prieheck@iwu.edu>]

>From the doc ( http://www.openldap.org/doc/admin24/security.html )
-----------------
security controls disallow operations when appropriate protections are
not in place. For example:

security ssf=1 update_ssf=112

requires integrity protection for all operations and encryption
protection, 3DES equivalent, for update operations (e.g. add, delete,
modify, etc.). See slapd.conf(5) for details.
-----------------

This sounds good to me, so I read the man page, added this to my
slapd.conf, and restarted openldap but now I get "stronger
confidentiality required for update" when making updates.....

As a test I lowed the value to 34 (security ssf=1 update_ssf=34) halted
slapd and ensured I got a clean restart.  Updates still fail.  If I
lower it down to 31 it succeeds.

Initial reactions would be to blame a lack of SSL for the low ssf
failure.  I assure you I am connecting with -ZZ and an ldapsearch -ZZ
returns results.

I have a suspicion that the problem is in part due to my lack of
understanding.  Here are the logs from an attempt (loglevel 256)

conn=0 fd=17 ACCEPT from IP=127.0.0.1:48533 (IP=0.0.0.0:389)
conn=0 op=0 EXT oid=1.3.6.1.4.1.1466.20037
conn=0 op=0 STARTTLS
conn=0 op=0 RESULT oid= err=0 text=
TLS: gnutls_certificate_verify_peers2 failed -49
conn=0 fd=17 TLS established tls_ssf=32 ssf=32
conn=0 op=1 BIND dn="cn=admin" method=128
conn=0 op=1 BIND dn="cn=admin" mech=SIMPLE ssf=0
conn=0 op=1 RESULT tag=97 err=0 text=
conn=0 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.1
conn=0 op=2 PASSMOD id="uid=test,ou=People,dc=testldap,dc=iwu,dc=edu"
new
conn=0 op=2 RESULT oid= err=13 text=stronger confidentiality required
for update
conn=0 op=3 UNBIND
conn=0 fd=17 closed

Where I think I am getting screwed up is at either tls_ssf=32 or
mech=SIMPLE ssf=0

The tls_ssf seems very low to me.  gnutls is perhaps not at the top of
everyone's SSL list, but my reading of the doc is that it promises
TLS1.0 and SSL3.0 without SSL2.0 ( http://www.gnu.org/software/gnutls/ )
and that "SSF greater than one (>1) roughly correlates to the effective
encryption key
length." ( http://www.openldap.org/doc/admin24/security.html ) I would
not expect something that refuses SSL2 support to select a 32 bit
cipher....

The ssf=0 for simple sasl auth makes perfect sense, I am trying a simple
bind.  A few vendor apps I have on hand wont do more than a simple bind
so that is my low water mark as it were.

In an ideal world I would like security update_ssf=128 simple_bind=112
to be working (force 3DES or better for a bind, for AES or better for an
update), but I will settle for what must I do to make the documented
example work for me?

Pat
Ubuntu 8.04
OpenLDAP 2.4.7 (installed from repo, linked against gnutls)