[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Authentication Methods for LDAP - last call



 
Comments follow - However its the usual statements.

IETF = Internet Engineering...
Internet.. a distributed network with 100m users which is growing by the
day and a network which is being used for all forms of commercial, govt,
academic uses, etc, etc..

IETF needs to produce standards that at least address scale...
otherwise its a "put it in the bin job".. 

Directories support all forms of network services and applications and
in some cases they have to have security domains and access control
profiles related to user authentication techniques..


----------
From: Chris Newman
To: Steve Kille
Cc: ietf-ldapext@netscape.com
Sent: 8/4/98 11:15:53 AM
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?


Alan: I totally agree with steve.. some of us have to deploy real
distributed directory systems that support the Internet and other
business services.


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

Alan: Disagree with single server and many usres , - one cannot put
1,000,000 users on ONE server..
Internet - and businesss - wants N Users  on N servers - ie. X.500
distributed systems.

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

Alan: Please explain why - is it because 509 deals with a trusted issuer
which one needs in a distributed environment - 
Any thing is "faster" if it is smaller and does less... but that gets to
a point where it is unscaleable and therefore useless for the "internet"
directory services. 

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

* X.509 scales better for a distributed system than CRAM-MD5

Alan: because that what it was designed to do - service trust and
security in a distributed environment.


* CRAM-MD5 is a small burden on an implementor, X.509 is a huge burden

Alan: So are wooden wheels compared to implementing a car.. 
This continued "implementation is simpler" argument just gets me.
Making fundamental directory features unscaleable, undeployable and
absolutely useless for Internet and commercial use - because some think
its too "difficult" to do otherwise - is pointless. Specifically 
when there are real directory systems available from other vendors who
do not find it "difficult" to build more distributed and sophisticated
features.


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. 

Alan: Single Server - replicate everything to everywhere is "scaleable"
- I think NOT.

 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.

Alan: Your choice - but not others eh!
regards alan

		- Chris