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


How does OpenLDAP 2.x implement DIGEST-MD5 version of SASL?
In particular, where is the authentication information stored?
Who needs to have access to this information?
What information is stored?


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