Rehash and once again, a proposal to move on

["John C. Strassner" <johns@cisco.com>]

There was a long, yet painful, debate about this very subject before the
Chicago meeting.

First, to respond to two threads that are "in the current":

Phil, size is mentioned because in CRAM-MD5 requires a shared secret
between client and server, and in a large scale distributed system, where a
given client might bind to many servers, this is unmanageable.

George Powers wrote:
>As an embedded systems vendor, we most urgently and definitely require a
>simple and universal LDAP password hashing scheme.

George, I realize that that is your need, but my need is for a large-scale
distributed system that MUST have strong authentication. Such a scheme
won't work for me.

>I think the majority of this list agree with that 
>assessment of priorities, but it's irritating to read a constant  
>stream of cranky messages that seek to hinder progress in
>that direction in order to advance some other agenda.

Umm, excuse me, but it's also irritating to see a constant stream of
messages that want to ignore the needs of distributed systems. And all of
this has been covered before the Chicago meeting. And it is also unfair to
jump to that conclusion, I don't get that impression at all. And, even if
the conclusion is right, the real problem is a single means that can be
used for all purposes.

Second, the rehash (hopefully this represents the views of other large
systems vendors, like Steve):

It was never my intent or purpose to ignore the needs of other systems,
whether they were embedded systems or systems that did not require strong
authentication. My *only* objection was in making CRAM-MD5 (or for that
matter, the HTTP Digest alternative) MANDATORY, because it is 
unsuitable for different types of LDAP deployment. Furthermore, it forces
my system to implement and support a mechanism that NONE of my clients will
be permitted to use.

So we were at an impass - two orthogonal uses of LDAP, divided by the
characteristics of the client and the environment in which the client is
operating in. Looks to me like we've now come full circle. A Bad Thing.

Third, the proposal:

So how do we move forward? The most important thing is to keep this easy
for the client. Therefore, if the goal is to have a "single" mechanism, put
the burden on the server. I had originally proposed such a compromise,
which I'll add to and restate as follows:

  add words to the spec to make the server implement TWO mechanisms,
  one being a simple approach suitable to lightweight clients, such as
  HTTP Digest or CRAM-MD5, and one being a strong mechanism (TLS,
  Kerberos, etc.). Add words in the spec to make clients implement EITHER
  the lightweight server alternative OR the strong authentication server
  approach. Add words in the spec as to why we're doing this.

This will achieve interoperability, since you've divided the clients into
their two dis-similar worlds, lightweight and other, without forcing either
type of client to implement the other type of authentication mechanism.
Since the server implements both, a client is guaranteed to be able to
authenticate. Not great for the server vendors, but at least this way both
client environments are satisfied.

regards,
John

At 03:40 PM 10/1/98 +0100, Phil Pinkerton wrote:
>
>
>
>>Phil,
>>
>>So you propose only supporting the small directory environments?
>>
>
>
>Not at all.  But I fail to understand what the size of a directory
>deployment, be it single server, distributed, or replicated servers has to
>do with mandating a server-side SASL authentication mechanism primarily for
>use by clients - I'm sure someone will explain.  Maybe this view is a bit
>simplistic, but, in my opinion, some of the debate taking place has merely
>been putting hurdles in the way of progress on this topic.
>
>This is difinitely my final comment!
>
>Regards, Phil
>
>
>
>