[Date Prev][Date Next]
Re: (ITS#5195) ssf not available during sasl bind
> 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
-- 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/