openldap-client vs openldap-sasl-client

[Jan Bramkamp]

On 05/01/2017 12:04, Matthew Seaman wrote:
> On 01/05/17 10:43, Kurt Jaeger wrote:
>> Hi!
>>
>> [openldap-client vs openldap-sasl-client and libreoffice etc]
>>> Yes and yes it sucks. The "solution" is to build your own repo and set
>>> the right flags to always use the same LDAP client port. With binary
>>> packages and the speed of modern x86_64 systems I for one no longer see
>>> removing SASL support from OpenLDAP as useful enough to justify the
>>> complexity.
>>
>> The other question is: What's the use of SASL anyway ? I've seen it
>> for years in mailserver setups, etc, and it always caused trouble.
>>
>
> SASL effectively gets you a number of new authentication mechanisms.
> Most of these are ways of proving you know a secret without sending the
> actual secret (ie. password) over the net in plain text, but I think it
> also adds the ability to use client TLS certificates for authentication.
> IIRC.
>
> I don't see much value in the extra mechanisms for secure login over
> unencrypted links nowadays.  Pretty much everything I'm using currently
> already requires TLS for good security reasons, so there's no real
> downside to using plain LOGIN over the encrypted channel.  Plus the
> 'proof of knowledge' authentication mechanisms have a big downside: they
> need the secret stored in the LDAP database in plain text, or in some
> locally reversible encryption.  With LOGIN over TLS, I can use salted
> password hashes in much the same way as Unix passwords.
>
> SASL would be worth it for TLS client certificate functionality, if
> that's the only way to enable that.

SASL external is required by OpenLDAP to extract authentication data 
from TLS client certificates and not all SASL mechs require plaintext 
passwords inside the database to avoid leaking the credentials over the 
wire e.g. SASL SCRAM (RFC 5802). You can also use SASL to authenticate 
against PAM.