LDAP Authentication Consensus

[Tim Howes <howes@netscape.com>]

All: The Great LDAP Mandatory-to-Implement Authentication
Debate seems to have quieted recently. The purpose of this
message is to summarize the problem and the history and to
put forward our view on what we see as the rough consensus
to which the group has come.

THE PROBLEM

LDAPv3 must specify at least one non-cleartext password
authentication mechanism that is mandatory to implement.
This way, when independent vendors go off and implement
products, they will be guaranteed to interoperate with
better-than-cleartext-password authentication. Other
applications can and will require other authentication
and security methods. This work does not preclude that.

THE HISTORY

At the last meeting (August, in Chicago), the group agreed
on several things:

- TLS was too expensive to be a MUST.
- TLS should proceed independently as a SHOULD.
- Hardly anybody liked CRAM-MD5.
- We sould evaluate Chris and Paul's revised Digest proposal
  and adopt that if it was deemed to fix the problems with
  CRAM-MD5.

Since the August meeting, Chris and Paul have put out this
draft:

http://info.internet.isi.edu:80/in-drafts/files/draft-leach-digest-sasl-00.txt

defining digest as a SASL authentication mechanism and
cleaning up some problems with the original digest specification.
Several comments have been received, mostly minor, and a
revision to address these comments is in the works.

There has also been some debate on the list on the
LDAP MTI subject. This debate can be categorized into
the following proposals, presented below along with our
assessment of where the rough consensus of the group
stands with respect to each proposal.

1) Make Digest a MUST, Make TLS a SHOULD. This is
what was decided at the August meeting, pending the
acceptability of the digest sasl document. The digest
document since has received the rough concensus of
the group that it is acceptable. Therefore, we
recommend that we pursue this proposal as our way
forward.

2) Make TLS and Digest a MUST for servers, a MUST choose
one or the other for clients. This proposal has merit,
since it avoids the main implementation concern for TLS,
which is on the client side. It does not address the
potential implementation burden on the server side,
which is also substantial. While this proposal may be
viable, we recommend the simpler approach above, since
it places less burden on servers as well.

3) Make CRAM-MD5 a MUST, make TLS a SHOULD. This
proposal has not seen significant support in the
group, and therefore we recommend dropping it from
consideration.

4) Make Kerberos or something else the LDAP MTI.
None of these proposals have seen significant support
in the group, and therefore we recommend dropping
them from consideration.

So, here is what we propose to move the group forward
and solve this problem:

- draft-leach-digest-sasl-00.txt should be revised
and submitted as an LDAPEXT draft. We believe this
will help it move through the process. It should be
put up for working group last call.

- draft-ietf-ldapext-authmeth-02.txt should be revised
to reference the digest draft and progressed.

- draft-ietf-ldapext-ldapv3-tls-03.txt should be
revised and progressed.

All these revisions are currently done or underway,
so the last calls should be issued soon.

Finally, recall that our goal is rough consensus
here, and we would ask you to all support this proposal
in the interest of moving the group forward.

Tim Howes
Mark Wahl
LDAPEXT Co-chairs