Re: LDAP and DIGEST-MD5 SASL

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

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 understand
>| 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 to
>| 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 information
>| 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 information
>| needs to be stored in or what access control is needed for this attribute.
>|
>| 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 MD5hash
>| 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 able
>| 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 two
>| 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 complexity
>| 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