Re: Compromise Authentication Proposal

[Chris Newman <Chris.Newman@INNOSOFT.COM>]

On Tue, 6 Oct 1998, Erik Skovgaard wrote:
> Well, I am beginning to lean towards TLS.  Aside from the scalability, it
> also provides me with Confidentiality services; i.e. the Client-server
> session is encrypted.  This is not only useful, but I could argue that it
> is *required* for any administrator's client.

You need to distinguish between "TLS + simple bind" and "TLS + client
certs".

> With TLS, it would seem to me, we are gaining:
> 
> 1. A scalable and solid authentication mechansm.

I would argue that CRAM-MD5 or HTTP digest is more scalable than TLS +
simple bind -- they have the same secret management issues, but
CRAM-MD5/HTTP-digest are much faster.  However, TLS + simple bind does
have a strong track record on large scale web server installations, so it 
can't be dismissed as a viable candiate. It also has the nice feature of
backwards compatibility.

As for TLS + client certs, that's even slower that TLS + simple bind, it's
far from "solid" given the X.509 profile was only just approved for
publication as an RFC and it's rarely used in practice on the web despite
being deployed in most web browsers.  It requires a completely different
management and operational structure for authentication than most sites
are used to.  We speculate that it handles distributed authentication
hierarchy better, but that's only if the other problems can be overcome in
practice and I'm honestly not sure that will happen.  I think even
recommending support for client certs is going too far, but I'm willing to
settle for that (as in the present draft) as a compromise.

Also be aware that if you ask for "TLS" you're effectively doubling the
size of a minimal LDAP client library and forcing them to deal with nasty
patent, trade-secret and export issues.  That's a lot to require of client
developers, although I have no problems with recommending it.  Note that
POP3 could _never_ require TLS as it would increase by several orders of
magnitude the amount of code necessary to support the protocol.

One could argue that write access to LDAP will only be used for
administrative purposes, in which case it may make sense to require
implementation of TLS for write-access.  The complexity of the DIT has
already caused many (most?) email client/server developers to treat LDAP
as a read-only protocol. 

> 2. COnfidentiality on the link between the client and server.

Certainly desirable and worth recommending.  But most "write-access" to
servers is not confidentialty protected today (including downloading &
deleting email), so is it really a requirement?  I know some people want
LDAP support to be ubiquitous in arbitrary clients in which case the
potential for a small client library is much more compelling than
mandatory privacy.

Remember that regardless of what we choose as mandatory to implement, the
marketplace can and will cause important and useful mechanisms to become
blessed.  For that matter, SSL/TLS has never been mandatory to implement
in any protocol, but it's _very_ common in HTTP (albeit with 40-bit keys,
RSA-patented PKI, and the dubious RC4 trade-secret cipher).  I don't trust
the marketplace to get rid of clear-text passwords as the minimum for
interoperability (this is visible by track record), but I do trust the
marketplace to force deployment of better mechanisms as requirements for
security increase. 

Let's set the minimum bar high enough that we have a chance to get rid of
unencrypted clear-text passwords, but not so high that some vendors will
be forced to ignore the requirement (thus making unencrypted clear-text
the de-facto mandatory-to-implement as it is today).  We can make
recommendations for stronger stuff, but I don't see any strong
justification to require it. 

		- Chris