RE: Authentication Methods for LDAP - last call

[Chris Newman <Chris.Newman@INNOSOFT.COM>]

For the record, I will be unable to attend LDAPEXT WG because I am
chairing the DRUMS working group which meets at the same time.  I would
like to register my opposition to changing the authmeth draft to use HTTP
digest for the following reasons: 

(1) HTTP digest uses a construct which prevents users from being renamed. 
While this may be a minor concern in some protocols, in LDAP it is a
significant concern with DNs because moving a user from one department to
another could cause that user's password to stop working.

(2) HTTP digest will recycle at proposed standard status as soon as the
new HTTP digest draft is published.  This will also reset the authmeth
draft to proposed standard and further delay it.

(3) It is unclear how much syntax from RFC 2068 (HTTP) is necessary to
recast RFC 2069 (HTTP DIGEST) as a SASL mechanism (and thus suitable for
multiprotocol-use).  Is header folder permitted in HTTP digest in LDAP?
The syntax is significantly more complex than CRAM-MD5.

(4) Given that HTTP digest was designed for a single protocol rather than
multi-protocol use, it has some facilities which are inappropriate in a
multi-protocol authentication mechanism.  Can we be sure these have been
adequately identified and evaluated?

(5) CRAM-MD5 is mandatory-to-implement in ACAP, which sets IETF precedent
as ACAP was the first protocol spec published under the new IESG
no-clear-text rules.  The choice was debated for months, including a
counter-proposal (SCRAM) which is about the same complexity level as HTTP
digest, but provides better security.

(6) CRAM-MD5 is already being deployed in IMAP, ACAP and POP servers and
is already implemented in at least one LDAP server.  It will move to draft
standard soon.  It is also much closer to current practice in other IETF
protocols including PPP CHAP and APOP.  It is clearly more mature on the
standards track than HTTP digest.

(7) RFC 2069 has a major security flaw in the definition of a "realm."  It
allows me to set up a web server which advertises itself as "AOL.COM" and
the majority of clients will blindly send the AOL.COM user/password pair
if the user had already enterred it.  I consider the concept of a "realm"
to be very useful, and it would be a great disservice to further deploy a
protocol with a broken definition.  The new HTTP digest draft fixes the
problem, but do we want to wait for that?

If the WG reaches concensus to consider things other than CRAM-MD5, I'd
like to put:
	draft-newman-auth-scram-03.txt
in the running.  I have a functional prototype and the spec is 100%
complete and could be moved to last call in its present form.  It has the
significant advantage over HTTP Digest that the verifier stored on the
server is not plaintext equivalent. That means the verifier is no less
secure than present-day verifiers such as /etc/passwd.  HTTP digest and
CRAM-MD5 both use plaintext equivalent verifiers, meaning if an attacker
breaks into the server they can automatically impersonate all users to
other servers in the same "realm."

If LDAPEXT goes with CRAM-MD5 now, I would be glad to cooperate on a
mechanism which combines the best features of HTTP digest and SCRAM.  Once
the result is standards track, then it would be reasonable to reconsider
the mandatory-to-implement mechanism.

		- Chris