RE: Authentication Methods for LDAP - last call

[Bruce Greenblatt <Bgreenblatt@rsa.com>]

I'm in total agreement with Chris.  One note that I'd pass along (that I
think is useful) is related to the availability of shared secrets in a
distributed environment.  If there are two LDAP servers (lets say LDAP1 and
LDAP2), and my "shared secret" is only known to LDAP1 (and not to LDAP2),
then if I attempt to Bind to LDAP2 using the CRAM-MD5 mechanism, nothing
says that the Bind has to succeed.  This is the case even though I might
have computed my response to the server's challenge correctly.  What the
IETF wants you to be able to do is to "statically" configure any random LDAP
client and server to be able to make a secure connection.  Note also that
the IETF is not asking your (or my) opinion on whether CRAM-MD5 is secure.
My humble opinion is that it is substantially more secure that passwords in
the clear over TCP.

Bruce


> -----Original Message-----
> From:	Chris Newman [SMTP:Chris.Newman@innosoft.com]
> Sent:	Monday, August 03, 1998 6:16 PM
> To:	Steve Kille
> Cc:	ietf-ldapext@netscape.com
> Subject:	Re: Authentication Methods for LDAP - last call
> 
> 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
>