[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Authentication Methods for LDAP - last call
Tim, whilst appreciating that we get on with our lives - which we all
like to do. It is important to recognise that our lives are sometimes
wasted on documents which by the buzzword oriented - marketing machine
that surrounds LDAP ????, that having a "document" in the public eye
that even has a title like Authmeth or Signed Operations - gives the
uninformed or very busy people not directly involved in the process the
impression that this solves all their authentication problems
In the process of deploying large scale trusted directory systems, one
can either "go with the flow and provide an LDAP mess" or one has to
present all the vaguries of LDAP - why it does scale - why it is
operationally unworkble, why certficate path processing cannot work
accross a global EC system , why one has to replicate everything to
everywhere... etc, etc... Just to provide a commercial grade directory
service. Hence the demand for serious X.500 directory backbone systems.
Your statement:
"Second, remember that the document does not specify
what people must use in deployed environments. It
specifies requirements for implementors, not deployers."
This view must be questioned.
As said the LDAP development approach to directory systems is now at
odds with a working scaleable and distributed international directory
standard and at odds with every aspect (commercial, operational,
security and technology ) of deploying large scale directory systems .
Any one can invent what they like - Cant stop that.. But please for the
sake of the IT industry and its credibility dont call documents
standards when they only cover a mechanism - and those mechanisms do not
relate to a scaleable system design that cannot be commercially deployed
or provide capability or utility to customers that apply them.
If your statement reflects authmeth, signed ops , etc - Its best to
trash them now.
regards alan
----------
From: howes@netscape.com
To: Chris Newman
Cc: Steve Kille; ietf-ldapext@netscape.com
Sent: 8/4/98 2:51:42 PM
Subject: Re: Authentication Methods for LDAP - last call
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