[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LDAP and DIGEST-MD5 SASL
Kurt,
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
cn=Manager,o=openldap,dc=org
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
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
|
|