russell-openldap(a)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/