Subject: LDAP authentication passwords

From: FOREST Laurent <[email-masked]>
Date: Wed, 6 Jun 2001 15:34:38 -0400

Hello,

reading RFC 2251 (pages 20 - 22), I understood that if a client uses the
simple authentication mechanism then the password must be in clear text.

Am I right or wrong?
Are there any means to exchange a non-clear text password (e.g. encrypted or
hashed) between a client and a server?
Are there any means to store a non-clear text password (e.g. encrypted or
hashed) on the directory server database?

Thank you

Laurent

---

From: "Wang Xianzhu" <[email-masked]>
Date: Thu, 7 Jun 2001 14:11:20 +0800

> hashed) between a client and a server?

In theory, hashed passwords are used to validate clear text passwords.  It's no
use to hash the password at the client, because the hashed password transferred 
on the network can be repeated as the credential, just the same as clear text
passwords.

If you intend to resolve this security problem, you must use some shared 
secret, random challenge or public key mechanisms.

> hashed) on the directory server database?

Sure,  SHA and Unix are the most common used hash algorithms in 
current directory servers.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 07 Jun 2001 09:27:00 +0200

>simple authentication mechanism then the password must be in clear text.

unfortunately right - this is indeed simple.

>hashed) between a client and a server?

The use of LDAP simple auth for secret data or update is NOT recommended.
If you want to use LDAP for that, check out RFC 2829 and RFC 2830.

 From RFC 2829:

    The following scenarios are typical for LDAP directories on the
    Internet, and have different security requirements. (In the
    following, "sensitive" means data that will cause real damage to the
    owner if revealed; there may be data that is protected but not
    sensitive).  This is not intended to be a comprehensive list, other
    scenarios are possible, especially on physically protected networks.

       (1)   A read-only directory, containing no sensitive data,
             accessible to "anyone", and TCP connection hijacking or IP
             spoofing is not a problem.  This directory requires no
             security functions except administrative service limits.

       (2)   A read-only directory containing no sensitive data; read
             access is granted based on identity.  TCP connection
             hijacking is not currently a problem. This scenario requires
             a secure authentication function.

       (3)   A read-only directory containing no sensitive data; and the
             client needs to ensure that the directory data is
             authenticated by the server and not modified while being
             returned from the server.

       (4)   A read-write directory, containing no sensitive data; read
             access is available to "anyone", update access to properly
             authorized persons.  TCP connection hijacking is not
             currently a problem.  This scenario requires a secure
             authentication function.

       (5)   A directory containing sensitive data.  This scenario
             requires session confidentiality protection AND secure
             authentication.

The IESG intended that implementation of at least one secure authentication 
function be required for ALL conforming LDAP implementations; from the same 
RFC:

    Therefore, the following implementation conformance requirements are
    in place:

       (1)   For a read-only, public directory, anonymous authentication,
             described in section 5, can be used.

       (2)   Implementations providing password-based authenticated
             access MUST support authentication using the DIGEST-MD5 SASL
             mechanism [4], as described in section 6.1.  This provides
             client authentication with protection against passive
             eavesdropping attacks, but does not provide protection
             against active intermediary attacks.

       (3)   For a directory needing session protection and
             authentication, the Start TLS extended operation [5], and
             either the simple authentication choice or the SASL EXTERNAL
             mechanism, are to be used together.  Implementations SHOULD
             support authentication with a password as described in
             section 6.2, and SHOULD support authentication with a
             certificate as described in section 7.1.  Together, these
             can provide integrity and disclosure protection of
             transmitted data, and authentication of client and server,
             including protection against active intermediary attacks.

>hashed) on the directory server database?

there are implementations that do this, and work has been going on to 
standardize such mechanisms. See the LDAPEXT group.

>Thank you
>
>Laurent
>
>-
>This message was passed through [email-masked], which
>is a sublist of [email-masked]. Not all messages are passed.
>Decisions on what to pass are made solely by Maurizio Codogno.