[EMAIL PROTECTED] 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/
