[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Heimdal/OpenLDAP/Samba howto and bugreport
At 12:22 PM 5/31/2004, Howard Chu wrote:
>> -----Original Message-----
>> From: firstname.lastname@example.org
>> [mailto:email@example.com]On Behalf Of Kurt D. Zeilenga
>> Regarding commenting out sasl-secprops minssf=128, it might
>> be better to instead lower the minssf to 70. The base SSF of
>> ldapi:// is currently 71. We figured that use of ldapi:// was better
>> than weak encryption (<65) but not as good as stronger
>> encryption (>95), hence the 71. The ldapi:// SSF should really
>> be a configurable option. I'll add that to our TODO list.
>No, that won't work. The minssf here is used to select eligible SASL
>mechanisms to offer to the client,
Right. When ldapi:// is used, slapd(8) sets the transport
SSF to 71 so that mechanisms which can met the minssf
>and SASL/EXTERNAL always has an SSF of
>zero as far as the SASL library is concerned.
I was under the impression it was only offered when
the minssf was satisfied by the transport as SASL/EXTERNAL
doesn't itself improve the ssf. Will have to read through
Cyrus SASL server.c again to figure out exactly...
I just saw this comment:
* IF mech strength + external strength < min ssf THEN FAIL
I thought it was (and, IMO, should be):
* If max(mech strength, external strength) < min ssf THEN FAIL.
That is, if mech provides 64 and external provides 64 than
the session ssf should 64 not 128. Ugh.
>The SSF that ldapi provides is
>transport-level, and SASL has no knowledge of it during mech selection.
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support