[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: owner-heimdal-discuss@sics.se
>> [mailto:owner-heimdal-discuss@sics.se]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
are available.

>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