Re: Compromise Authentication Proposal

[Erik Skovgaard <eskovgaard@geotrain.com>]

Chris,

You are right, I did not make it clear.

Well, here is the problem.  If we set the bar too low, LDAP becomes useless
to large installations.  If we set it too high, as you point out, we
eliminate the low end products.

I can see both points of view and all I ask is that we clearly identify the
environment.  I think there is at least some agreement among the members of
the list that we *should* try and address both environments.

As far as I can see, the issue is mainly for clients.  How if we allow
three profiles for clients:

1. Clients with only anonymous and clear text password capabilities.
2. Clients that support 1. and lightweight strong authentication.
3. Clients that support 1. and scalable strong authentication.

If we for the last category can also include confidentiality services (i.e.
encryption on the session), I think we have covered all bases. The "slow"
processing of SSL + certs is a non-issue, IMHO.  Many desktop installations
today use PKI (for instance Entrust) and the processing is very intensive
without disruting users.  Keep in mind that we are developing standards for
the future, not yesterday's equipment.  Of course, we *do* need to allow
for simple clients as per my suggestion above.

One of the main drivers for my option 3 above is administrative clients.
Most of the products today use proprietary mechanisms and it makes it very
difficult to administer a multi-vendor environment.  This is only going to
get worse as different parts of an organization install different products. 

Servers would have to support all three options, but if that is a problem
for some people, we could also profile servers as follows:

1. Servers which support anonymous, clear text passwords and lightweight
strong authentication.
2. Servers which support 1. and scalable strong authentication.

How's that for a compromise?

Cheers,                 ....Erik.

------------------------------------
Erik Skovgaard
GeoTrain Corp.
LDAP/X.500 Directory Training and Consulting
http://www.geotrain.com
+1 (604) 244-9131

At 14:52 06/10/98 -0700, Chris Newman wrote:
>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
>
>