On Dec 28, 2012, at 12:56 PM, Wiebe Cazemier <[email protected]> wrote:
> ----- Original Message ----- >> From: "Philip Guenther" <[email protected]> >> To: "Wiebe Cazemier" <[email protected]> >> Cc: "Dieter Klünter" <[email protected]>, [email protected] >> 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
