Re: (ITS#5195) ssf not available during sasl bind

[hyc@symas.com]

russell-openldap@stuart.id.au wrote:
> On Mon, 2007-10-29 at 18:07 +0100, Hallvard B Furuseth wrote:
>> No, you've forced users who authenticate against userPassword
>> to be encrypted.  Not all SASL methods, nor auth with rootpw.
> 
> Thats a worry.  Rootpw aside, the intended objective of
> the ACL was to ensure passwords were never sent in the
> clear.  Either a protocol like CRAM-MD5 was used, or the
> entire link is encrypted.

By the way, CRAM-MD5 has a few known weaknesses. Should use DIGEST-MD5 
instead. http://www.ietf.org/rfc/rfc2831.txt (For what that's worth. Given 
that methods exist to create MD5 collisions, it's not clear how much longer 
DIGEST-MD5 will be useful.)

> Does it not do that?  (Actually
> it doesn't.  It should have been sasl_ssf=71.  But bugs
> aside ...)
> 
> Secondly, just out of curiosity, are there SASL methods
> that check a shared secret of some kind and don't use
> userPassword?  What are they?
> 
> The "security" option may produce better error messages
> by it appears to apply to all connections, including
> lookups done by SASL to dn="" to discover what mechanisms
> are allowed.  It wasn't at all obvious to a newbie like me
> that this sentence from "man 1 ldapsearch" only applies
> if you don't use the "security" option:
> 
>   "-Y mech .... If it's not  specified, the program will
>   choose the best mechanism the server knows."

Perhaps we should add a security option to separately specify the SSF for 
anonymous sessions.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/