On Dec 28, 2012, at 12:56 PM, Wiebe Cazemier <wiebe(a)halfgaar.net> wrote:
----- Original Message -----
> From: "Philip Guenther" <guenther+ldaptech(a)sendmail.com>
> To: "Wiebe Cazemier" <wiebe(a)halfgaar.net>
> Cc: "Dieter Klünter" <dieter(a)dkluenter.de>,
> Sent: Friday, 28 December, 2012 9:36:50 PM
> Subject: Re: Forcing TLS encryption
> On Fri, 28 Dec 2012, Wiebe Cazemier wrote:
>> I understand that, but this way, even when you're forcing TLS,
>> users can
>> still expose their passwords if their computers are mal-configured.
>> SMTP, IMAP, FTP, etc don't allow this, because they reject the
>> connection if LOGINNAME is given before STARTTLS.
> That is not true of SMTP's AUTH PLAIN, IMAP's AUTHENTICATE PLAIN, or
> IMAP's LOGIN. The PLAIN SASL mechanism and IMAP's LOGIN command both
> the username and password without waiting for a response from the
>> It's kind of a security issue. Is it because in LDAP, username and
>> password are given as one command, and the server doesn't have the
>> chance to abort at that point? If so, then I guess it's
> Philip Guenther
> ** Well, to be completely accurate, IMAP AUTHENTICATE requires a
> response if the server doesn't support the SASL-IR capability
Then why is the LDAPS port deprecated? If the connection is SSL from the start, you
don't have this issue.
You still have the issue that the client might be configured for ldap://host:636 and
Simple Bind or SASL PLAIN (generally by user mis-configuration).
In short, nothing in the server can prevent a poorly coded or poorly configured client
from disclosing a user password in appropriately.
ldaps:// was never standardized and hence deprecated. There were many reasons why the
IETF choose not to standardize ldaps://, one being interoperability issues between
pre-existing implementations... another being that it viewed as not needed.