On Dec 28, 2012, at 12:56 PM, Wiebe Cazemier wiebe@halfgaar.net wrote:
----- Original Message -----
From: "Philip Guenther" guenther+ldaptech@sendmail.com To: "Wiebe Cazemier" wiebe@halfgaar.net Cc: "Dieter Klünter" dieter@dkluenter.de, openldap-technical@openldap.org 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 send the username and password without waiting for a response from the server**.
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 unavoidable.
Correct.
Philip Guenther
** Well, to be completely accurate, IMAP AUTHENTICATE requires a server 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.
-- Kurt