RE: Authentication Methods for LDAP - last call

[Bruce Greenblatt <Bgreenblatt@rsa.com>]

Clause 6, subclause (2) currently reads:

(2)   Implementations providing password-based authenticated access
           MUST support authentication using CRAM-MD5, as described in 
           section 8.1.  This provides client authentication with 
           protection against passive eavesdropping attacks, but does
           not provide protection against active intermediary attacks.

Since it appears that we'll require all LDAP v3 servers to be able to be
configured to accepts password based mechanisms, this clause is misleading.
It should say:

(2)   Implementations 
           MUST support authentication using CRAM-MD5, as described in 
           section 8.1.  This provides client authentication with 
           protection against passive eavesdropping attacks, but does
           not provide protection against active intermediary attacks.


> -----Original Message-----
> From:	Tim Howes [SMTP:howes@netscape.com]
> Sent:	Thursday, August 06, 1998 8:57 PM
> To:	ietf-ldapext@netscape.com
> Subject:	Re: Authentication Methods for LDAP - last call
> 
> Wow, I'm away from email for a day and a half, and
> look what happens! Here's how I see it and what I
> think we should do.
> 
> We are having arguments about several different
> things:
> 
> 1) Should there be a MUST implement non-clear-text-password
> authentication mechanism for update-capable LDAP servers?
> The IESG has told us yes, and the document in question is
> a result of that edict. We could accept this as a
> requirement, or we could argue with the IESG. Part of
> my job as co-chair is to keep the group from tilting
> at windmills. I believe this to be one such windmill.
> Therefore, I believe that no, we should not try to argue
> with the IESG on this point. This is not a new requirement,
> it's been around for a long time, it's clear the IESG
> feels strongly, we should not waste our time.
> 
> 2) What should the MUST implement non-clear-text-password
> authentication mechanism for update-capable LDAP servers
> be? I've seen five things suggested: CRAM-MD5, HTTP Digest,
> Kerberos, Certificates, plain-text passwords over TLS.
> More on this later. Much of the discussion here has been
> related to 3).
> 
> 3) There has been much discussion about the fact that
> CRAM-MD5 is not totally secure, not suitable for some
> environments, etc. The direction of this discussion has
> the flavor of "we should solve the whole problem or none
> at all". Many, many working groups have ground to a halt
> in the mire of this kind of attitude. Let's not do that.
> 
> Instead, let's make some assumptions:
> 
> a) Defining this MUST implement non-clear-text-password
> authentication mechanism is a requirement.
> 
> b) The mechanism we choose should be the simplest one
> possible that satisfies the requirement.
> 
> c) We are NOT trying to solve the non-clear-text-password
> authentication problem in every conceivable situation.
> 
> d) We ARE trying to solve the non-clear-text-password
> authentication problem in the simplest, single-server or
> small-number-of-servers cases.
> 
> e) We can define other mechanisms later that apply to
> other situations.
> 
> Given these assumptions, it's clear that kerberos and
> certificates and tls don't satisfy b). I think it's
> pretty clear that CRAM-MD5 is the simplest option, though
> there's room for argument maybe with HTTP Digest.
> 
> The arguments about distributed versus centralized,
> multiple versus single servers don't make a lot of
> sense to me. Of course people will use LDAP in all of
> these environments and more. The point is not that.
> The point is that there is no SINGLE authentication
> mechanism that we could choose that would be appropriate
> for all situations. That is not what we are doing.
> Refer to asumptions c) and d).
> 
> Let's get back on track!         -- Tim