[Date Prev][Date Next] [Chronological] [Thread] [Top]

SASL secrets in LDAP

I've been finishing up an auxprop plugin for slapd and Cyrus 2 that will
allow slapd to lookup SASL authentication secrets internally. Unfortunately,
it isn't very useful without a good mechanism for putting the secrets there
in the first place.

In Cyrus 2 the authentication mechanisms no longer generate their own
secrets to be stored in a password database. Instead, they mostly retrieve a
plaintext password and crunch it as needed. My primary interest here is to
get DIGEST-MD5 workable since that's the mechanism required by the standard
(RFC 2829).

For many good reasons, we discourage the storage of plaintext passwords in
LDAP. As such, we can't rely on using a plaintext password to generate the
MD5 secret on demand. In this case, it would make sense to generate and
store the DIGEST-MD5 secret during a PASSWD_EXTOP request. There's no single
entry point provided in SASL that will generate this secret for us, so this
code needs to be added (to liblutil/passwd.c? )

The DIGEST-MD5 secret is a hash of <sasl username> : <sasl realm> :
<password>
which is a problem for the current liblutil API; it just expects a password
to crunch on. I guess we can handle this in the front end somewhere, when
the PASSWD request arrives...

(The above paragraphs assume that we add a {DIGEST-MD5} password scheme.
It's not clear to me that this is the right thing to do, it really doesn't
make sense for this hash to be available to a simple Bind.)

Thoughts?

(After thinking about this for so long, I personally will probably stick to
issuing X.509 certificates to users and abandon any other auth mechs...)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support