Re: Authentication Methods for LDAP - last call

["John C. Strassner" <johns@cisco.com>]

Comments inline.

regards,
John

At 06:15 PM 8/3/98 -0700, 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

[js] umm, excuse me, but there is a huge difference between the relatively
small number of users that a single server can support and the very large
number of users that a distributed system consisting of multiple servers
can support.

>* CRAM-MD5 is several orders of magnitude faster than X.509.

[js] shooting yourself in the head will probably make you die faster than
shooting yourself multiple times in the foot - what's the point? if the
requirement is scalability and/or being able to support large numbers of
users for secure authentication, CRAM-MD5 won't cut it. period.

>* CRAM-MD5 scales better for many users on one server than X.509

[js] see above.

>* 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

[js] but undertaking security for a distributed system is a huge burden in
and of itself. taking short cuts doesn't make this easier.

>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. 

[js] sorry, i disagree. single-server deployments does not equal large
deployments. and even your wording seems like you're trying to make excuses
to justify the limitations of CRAM-MD5. "easier to implement" and "faster
in performance" and "good enough properties for single-server deployments"
are not good reasons to saddle LDAP (or any other protocol that wants to
work in the Internet) with this.

>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

[js] I think that this needs further discussion. Kerberos, for one, seems
to be a better choice.