Re: Authentication Methods for LDAP - last call

[howes@netscape.com (Tim Howes)]

I don't have much to say on this topic that Chris, Mark,
Jeff, and others haven't already said quite well. But I
would pick out the following points which have been made.

First, remember that the idea behind the requirement
driving this document is that two independently developed
implementations should be able to interoperate. This is
a good thing.

Second, remember that the document does not specify
what people must use in deployed environments. It
specifies requirements for implementors, not deployers.

Third, this document in no way hinders the development
or specification of alternate mechanisms that are certainly
more appropriate for some environments (e.g., the highly
distributed ones that Steve and Alan are talking about).

Finally, we're trying to put this behind us and get on with
the rest of our lives. This document represents the best
and quickest way to do that.                   -- Tim

Chris Newman wrote:

> On Sat, 1 Aug 1998, Steve Kille wrote:
> > I am totally opposed to mandatory support of CRAM-MD5 in
> > LDAP.   CRAM-MD5 requires a shared secret between client
> > and server.  In a large scale distributed system, where a
> > given client might bind to many servers, this is totally
> > unmagageable.   I think that the policy documents should
> > NOT be requiring this.  I cannot overstate how BAD I think
> > this choice is?
>
> I've been studying the mandatory-to-implement authentication mechanism
> problem for over a year (see draft-newman-auth-mandatory-00.txt for a
> problem statement), so I have a strong opinion in this area.  Let me
> start by observing the following:
>
> * The IESG requires that if a random update-capable client and a random
> read/write capable server are selected, there will be a way to configure
> them to authenticate using something better than unencrypted clear text
> passwords.  While this is a harsh requirement, it is not unreasonable.
> Experience demonstrates that if no mandatory-to-implement mechanism is
> defined, then the real-world mandatory-to-implement mechanism is
> unencrypted clear text passwords.  This is true of POP3, LDAP and IMAP
> today.
>
> * Scalability comes in two forms -- many users on one server or many
> servers with distributed rules
>
> * CRAM-MD5 is several orders of magnitude faster than X.509.
>
> * CRAM-MD5 scales better for many users on one server than X.509
>
> * X.509 scales better for a distributed system than CRAM-MD5
>
> * CRAM-MD5 is a small burden on an implementor, X.509 is a huge burden
>
> CRAM-MD5 is the right choice today for the mandatory-to-implement
> mechanism in LDAP.  It has good enough properties and scalability for
> single-server deployments.  It is not hard to implement.  There is, of
> course, no requirement to use the mandatory-to-implement mechanism or even
> to have it on by default as long as it can be turned on.
>
> I happen to think that TLS-protected clear text passwords make a good
> SHOULD implement feature -- as they provide backwards compatibility with
> legacy authentication sources such as NTLM or /etc/passwd -- an issue that
> Mark Smith pointed out.
>
> Implementations SHOULD NOT use unprotected clear text passwords.  That's a
> recommendation most will ignore for practical reasons, but it causes
> sufficient harm that the recommendation is important.
>
> I believe the current draft is realistic and pragmatic.  Unless someone
> else can make a compelling argument for a different mandatory-to-implement
> standards-track mechanism, CRAM-MD5 is the best choice today.
>
>                 - Chris