RE: more authentication questions..

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

At 07:20 PM 1/9/01 -0800, Jeff Costlow wrote:
>Yes, my general idea was to use DIGEST-MD5 (for obvious security reasons) to log users into LDAP using the password that is stored within the directory.

This is not supported (yet).

>It appears as if they only way I could do this would be to write a pwcheckd on my local machine that logs into the LDAP server, and returns userPassword to SASL, who then authenticates and authorizes the user. 

pwcheckd only supports verification of a password and hence
is only useful for SASL/PLAIN and SASL/LOGIN.

>Although the cyrus docs and your fourth paragraph both seem to indicate that DIGEST-MD5 can only work from SASLdb. (Why this is I'm not certain, it seems as if the realm is the only magical part of a digest-auth)

Because DIGEST-MD5 requires access to a mechanism specific secret
(or a copy of the user's password).  

>Is this correct, or is there something I am missing?  Please point me toward any documentation I might be overlooking.

See above comments.

>I currently have 2.0.7 compiled and running with cyrus-sasl 1.5.24 (and openssl 0.9.6 thrown in as well).  I've read up on digest auth (both the SASL rfc, and the original HTTP rfc), and I'm convinced it is the only way to do secure-enough authenticaion without resorting to SSL.

SASL/GSSAPI
SASL/KERBEROS_V4
SASL/SRP


>Thank you for your time.
>
>-----Original Message-----
>From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>Sent: Tuesday, January 09, 2001 6:27 PM
>To: Jeff Costlow
>Cc: 'openldap-software@openldap.org'
>Subject: Re: more authentication questions..
>
>
>LDAP "simple" authentication uses userPassword values stored in
>the directory.  There are numerous schemes supported, including
>ones which refer the server to external authentication services
>(UNIX, Kerberos, SASL).
>
>SASL authentication provides a variety of mechanisms.  Some
>mechanisms require external authentication services (e.g.
>Kerberos), others require access to mechanism specific secrets
>(e.g. DIGEST-MD5), and others (PLAIN, LOGIN) only require a
>method to verify the asserted password is correct.  In the
>latter case, Cyrus SASL can be configured to use external
>authentication services such as UNIX, Kerberos, and SASLdb.
>Cyrus SASL can also be configured to verify asserted passwords
>via a password check daemon.   Though (IIRC) the original pwcheckd
>was designed to verify against UNIX shadow passwords, one can
>(and folks have) write a pwcheckd that verifies against external
>services such as SQL databases and LDAP directories.
>
>I note that an LDAP-aware pwcheckd would only make sense where
>you used LDAP as your authentication service and wanted non-LDAP
>services to authenticate against LDAP via SASL/PLAIN.  However,
>such a configuration has significant security drawbacks.
>
>If you want to use DIGEST-MD5, you currently need to use
>the Cyrus SASLdb for secret storage.  This allows multiple
>services hosted on the same machine to share DIGEST-MD5
>secrets, but does not address sharing of secrets between
>services hosted on multiple systems.  We're working with
>Cyrus folks to address this issue.
>
>If you want a common, distributed, secure authentication service,
>I recommend Kerberos V (MIT or Heimdal) and use of GSSAPI [which
>LDAP supports via SASL/GSSAPI].
>
>So,
>
>At 05:41 PM 1/9/01 -0800, Jeff Costlow wrote:
>>I have read some of the threads about authentication, particularly this one form september 2000:
>>http://www.openldap.org/lists/openldap-software/200009/msg00180.html called "SASL docs?"
>>
>>If I understand correctly, I currently have to maintain my password list twice -- once in the SASL db, and once in the LDAP db.
>
>No.
>
>>So if the above is true, has someone come up with a method so that when a user updates his password in LDAP, the password gets updated in SASL?  Or is that a 2.1 feature?
>
>If using SASLdb storage, update via saslpasswd.
>If using LDAP storage, update via ldappasswd.
>
>I recommend using SASLdb over LDAP storage as it supports DIGEST-MD5.
>
>>And as long as I am asking questions, is anyone currently working on doing a complete dump to a replicated server rather than transferring db files (which doesn't work so well when your linux box uses gdbm, and your bsd box uses dbm, etc...)
>
>slapcat / slapadd
>
>Kurt
>
>
>>Thank you.