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



Thanks for the insight into the openldap design for DIGEST-MD5.

Perhaps this does not apply to openldap 2.0:

1. If a directory is replicated, do you also need to replicate the
DIGEST-MD5 database (to other machines)?

2. When Cyrus authenticates a user, how does this get mapped to
the authentication of a particular DN?  i.e. how does the Cyrus
authentication of "kurt" get mapped to authentication of


3. Does this design preclude operation with multiple machines?

Again thanks for the insight.
David Cahlander David.A.Cahlander@syntegra.com 651-415-3171

----- Original Message -----
From: Kurt D. Zeilenga <Kurt@OpenLDAP.org>
To: David Cahlander <david.a.cahlander@syntegra.com>
Cc: <openldap-devel@OpenLDAP.org>
Sent: Wednesday, August 30, 2000 1:12 PM
Subject: Re: LDAP and DIGEST-MD5 SASL

| At 12:38 PM 8/30/00 -0500, David Cahlander wrote:
| >How does OpenLDAP 2.x implement DIGEST-MD5 version of SASL?
| Currently, OpenLDAP 2.x relies on Cyrus SASL to implement
| particular mechanisms.
| >In particular, where is the authentication information stored?
| Currently, OpenLDAP 2.x relies on Cyrus SASL to manage all SASL
| authentication information.  In the case of DIGEST-MD5, the
| authentication information is stored in Cyrus SASL's SASLdb.
| I have been chatting with Cyrus SASL developers regarding mechanisms
| for storing secrets.  The current callback mechanism does not solve
| the more general problem of providing authentication information to
| a suite of applications (without requiring modification of each
| application).  I hope the next release of Cyrus SASL will support
| an external "secret" service (pwaccessd) as discussed on the
| Cyrus SASL mailing list and we then would implement a variant
| of this service which uses secured LDAP-based storage.
| Note, we could use the existing callback mechanisms to store
| authentication secrets in the directory... but that kind of
| pointless without providing a means for other applications to
| share those secrets.  So, for the moment, we (like most Cyrus
| SASL applications) use SASLdb.
| There is also work underway to store authorization information in
| the directory.  See the archives for details.
| >Who needs to have access to this information?
| The SASL service layer on the server side needs access to the
| authentication information.  The application protocol server
| need not have access to this information itself.
| >What information is stored?
| For DIGEST-MD5, I believe Cyrus SASL stores
|   H({ username-value, ":", realm-value, ":", passwd })
| (where H is the MD5 digest function) for each username @ REALM
| the value as outlined in RFC2831, 3.9.
| >Thanks.
| >
| >Background infromation.
| >
| >----- Original Message -----
| >From: David Cahlander <david.a.cahlander@syntegra.com>
| >| I'm trying to implement DIGEST-MD5 in an LDAP front-end to an X500
| >| Directory.
| >| I can't figure out what needs to be stored for credentials.  Thanks to
| >| OpenLDAP, I have an ldapsearch that does the first part of the bind
| >| operation.
| >| I have read RFC2829 and RFC2831 but find that I am at a loss to
| >| how the very simple operation of authentication is performed.
| >|
| >| From RFC2829 section 6.1:
| >|
| >|    The server will respond with a bind response in which the resultCode
| >|    is either success, or an error indication.
| >|
| >| I have no idea how this operation is performed.  RFC2831 does not seem
| >| give a clue about this either.  As near as I can tell, the LDAP server
| >| is required to either use a separate file for authentication
| >| that contains:
| >|
| >|     username
| >|     MD5hash( username-value ":" realm-value ":" passwd )
| >|
| >| or store this information in the directory entry for the user that is
| >| trying to authenticate.  It is not clear which attribute this
| >| needs to be stored in or what access control is needed for this
| >|
| >| The catch-22 comes from what I see as a very serious security violation
| >| with any of the methods that can be used to implement this operation.
| >| Since the user needs only the MD5hash value to authenticate, The
| >| value can be considered as a plaintext password.  (3,9 in /rfc2831)
| >| In order to do the DIGEST-MD5 calulation, this attribute needs to be
| >| to be read.  This means that any administrator that has access to the
| >| directory can read this password hash and use it to authenticate to the
| >| directory as that user.
| >|
| >| In an X500 situation, this attribute must be able to be read between
| >| DSAs.  A snoop on the line will reveal this password hash, the same as
| >| being able to read a cleartext password.  At least with simple
| >| authentication
| >| the only thing passed between the DSAs is a compare operation.
| >|
| >| I'm sure that I'm missing something very basic.  With all the
| >| of the DIGEST-MD5 operation, I can't believe that it is so simple to
| >| break the authentication operation.
| >|
| >| Thanks
| >---
| >David Cahlander David.A.Cahlander@syntegra.com 651-415-3171