At 15:34 06.06.2001 -0400, FOREST Laurent wrote:
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.
unfortunately right - this is indeed simple.
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?
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.
Are there any means to store a non-clear text password (e.g. encrypted or
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
ietf_censored(_at_)beatles(_dot_)cselt(_dot_)it, which
is a sublist of ietf(_at_)ietf(_dot_)org(_dot_) Not all messages are passed.
Decisions on what to pass are made solely by Maurizio Codogno.