Re: SASL with secrets in OpenLDAP database

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:40 AM 10/19/00 +0100, Jim Hud wrote:
>I understand from the web site development roadmap that "SASL in-directory
>storage of authentication secrets" is part of 2.1 and Kurt tells me it is
>being worked on.

Yes.

We're working with the Cyrus SASL folks on extensions to their
library to allow plugable, external secret storage. 

Backgound: Today, Cyrus SASL has a callback mechanism to allow
individual application protocol servers (APS) to provide their
own storage. However, this doesn't server our needs.  We want:
  1) all APSs to use common secret database
  2) allow replacement of the database without requiring
  recompilation of each APSs
  3) provide isolating barrier between the APSs and the
  external secret store to avoid link conflicts and other
  such problems.

Cyrus SASL provide such a mechanism today for password checking
via pwcheckd.  However, for sophisticated mechanisms like
DIGEST-MD5, SASL needs to be able to obtain a copy of the
stored secret (instead of just being able to assert that it
has the same secret).  The plan is to modify Cyrus SASL to
obtain the secret using a new "secret access" protocol.
This protocol would be much like the current pwcheckd protocol,
but would provide full read/write access to the secret.  Like
pwcheckd, the protocol would operate over host-only IPC (such
as Unix domain sockets).  I've been calling these "pwaccessd"
daemons.

Like they do with pwcheckd, Cyrus SASL would be shipped with
some simple pwaccessd.  However, others can easily development
alternative implementations.  One of those would be an LDAP-based
enabled pwaccessd.

>who is working on it

Currently?  I am not sure anyone is actively working it.  We
(Larry of Cyrus SASL project, Mark Adamson, and I) sat down and
discussed the "approach" a couple of months ago.  Since that
time, we've all been quite busy.

>is there a "spec"

One hasn't been written...

>can I help develop and/or test

In implementing the above approach, the working needing to
get done is mostly in Cyrus SASL.  If you want to help
develop the needed Cyrus SASL changes, I'd suggest
contacting Larry and/or posting to the Cyrus SASL
mailing list.  See http://asg.web.cmu.edu/sasl/ for contact
info.

Now, if all you want is for the LDAP servers to share
secrets which are stored in the directory, there is another
approach.  As noted above, Cyrus SASL does provide a callback
mechanism that slapd could use to provide it's own secrets
and these secrets could be stored in the directory.  To
implement this, you'd just need to:
  1) develop schema to hold the secrets
  2) implement the callback to make use of them

(you could then write callbacks for other APSs to use
LDAP to fetch these secrets if you desired such).

If you want to work on this, just "jump on in".

Kurt