[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Compromise Authentication Proposal
Chris,
I agree with you that a barebones LDAP directory is useless in a large
installation, but I thought we were trying to remedy the situation?
The problem I have with your statement about the base spec is that it
tempts people to use LDAP servers to do only short-term planning. An
enterprise directory should be designed with organization growth im mind.
That means addressing the architectural issues, including distribution,
access control and naming.
In today's business climate, who can tell if your company is merged with
another tomorrow? What about customers and trading partners? I am willing
to bet that many organizations will want to share directory information in
order to facilitate electronic commerce or for other reasons (e.g. to be
able to exchange email - perhaps secure email).
Ultimately, I would like to see some of these individual corporate
directories tie together into a coordinated Internet Directory. Hence we
*do* have to address scalability up front. Otherwise we build in limits to
growth from the start.
I am not so naiive that I think *all* organizations will participate in the
Internet Directory, but I don't think we should *prevent* them to do it by
design.
Cheers, ....Erik.
----------------------------------------
Erik Skovgaard
GeoTrain Corp.
Enterprise Directory Architecture
http://www.geotrain.com
+1 (604) 244-9131
At 11:10 08/10/98 -0700, Chris Newman wrote:
>On Thu, 8 Oct 1998, Erik Skovgaard wrote:
>> If we set the bar too low, LDAP becomes useless
>> to large installations.
>
>This is the crux of the disagreement. I claim that a bare-bones LDAP
>server is inherently useless to large installations, regardless of what
>requirements we include for authentication and whatnot. There is a
>fundamental quality of implementation issue, and large installations will
>just have to shop around. A separate profile of LDAP for large
>installations which dicusses distributed authentication requrements,
>management requirements, replication requirements and whatnot would be
>quite useful to such large sites when shopping around. But it doesn't
>belong in the base spec and base requirements as those services aren't
>necessary for basic on-the-wire interoperability required by 80% of LDAP
>sites today.
>
>> As far as I can see, the issue is mainly for clients. How if we allow
>> three profiles for clients:
>>
>> 1. Clients with only anonymous and clear text password capabilities.
>> 2. Clients that support 1. and lightweight strong authentication.
>> 3. Clients that support 1. and scalable strong authentication.
>
>This is exactly what the IESG is trying to get rid of (with good reason).
>Your three profiles implicitly make anything but unencrypted clear text
>passwords non-interoperable. The profiles I believe we want are:
>
> 1. Clients with read-only anonymous access.
> 2. Clients with anonymous and lightweight digest authentication.
> (SHOULD do TLS + simple bind, MAY do simple bind)
> 3. Clients with (2) plus "scalable strong authentication."
>
>> 1. Servers which support anonymous, clear text passwords and lightweight
>> strong authentication.
> (I'd add: SHOULD support TLS + simple bind, vanilla simple bind optional).
>> 2. Servers which support 1. and scalable strong authentication.
>>
>> How's that for a compromise?
>
>I haven't seen anyone opposed to these two options.
>
> - Chris
>
>
>
>