On Wed, 10 Apr 2002, David Wright wrote:
> Since there is such as SASL love-fest going on here, allow me to chime
> in with my dissenting viewpoint. SASL adds nothing but an annoying
> dependency to LDAP. No, I take that back, it also adds a security hole.
SASL does not in any way force the addition of an LDAP dependancy. Nor,
for that matter, does libsasl.
> Challenge-response mechanisms have absolutely no advantage over straight
> password transmittion across an SSL/TLS encrypted line. In fact, if they
> run in cleartext, they have a few disadvantages: (1) No server
> certificate authentication. (2) If you watch challenge-response a few
> times, you can get a good deal of the way toward decrypting the password.
Ignoring, for the moment, the obvious problems with running PLAIN and
LOGIN in cleartext, the other mechanisms are designed to defeat passive
dictionary attacks by means such as random choice of a nonce (CRAM and
DIGEST), or through using Kerberos (or GSSAPI). And OTP uses an s/key
like mechanism.
> Furthermore, in order to support multiple authentication mechanisms,
> SASL must store password essentially in cleartext (i.e. not in a hased
> form). That means if anyone ever gets access to your sasldb, you are
> hosed. Not true for an LDAP database, stores passwords in hashed form.
There is no requirement in SASL that says that passwords must be stored in
cleartext. Yes, it is true that libsasl's sasldb does so, however this is
an easily plugable backend that can be changed for whatever type of
password database you desire, provided that someone has written an auxprop
plugin for it.
> The only advantage of a security layer is flexibility: allowing
> authentication via arbitrary backeds (LDAP, SQL, passwd, shadow,
> kerberos). While SASL makes this possible in theory, I have not had good
> experiences in trying to make use of this flexibility -- there is very
> little in the way of widely-distributed, well-tested, well-supported,
> drop-in code to do all this stuff.
No, the advantage of a session layer ("security layer" typically refers to
the optional encryption provided by a mechanism) is on the protocol side,
it allows protocols which support a SASL interface to support any number
of authentication methods, all without a change to the protocol. libsasl
(and the various SASL APIs) aim to allow programmers of applications the
same flexability, that is, they just have to write their program to a
single API and they can automatically support whatever new mechanisms are
released.
libsasl's support for many different backends is more or less a byproduct
of the variety of situations where it has been used in the past, not a
requirement of SASL.
-Rob
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 235 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
