[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Compromise Authentication Proposal
Chris,
I agree with you about the intent, but I think you are mixing
Authentication and Access Control. Administrators would want to set up
Access Controls to implement the type of access you are talking about.
What we need is to allow the administrators to:
1. Configure Authentication mechanisms that enables the Directory to verify
that a user is who he/she/it claims to be with varying degrees of certainty
(based on the strength of the mechanism).
2. Configure Access Control mechanisms that specify which users can do what
to specified information in the Directory, based on the knowledge in 1.
LDAP does not curreently have a formal way of specifying Access Control
Information. This is required for multi-vendor interoperability when we
implement shadowing. Yet another future work item.
Anyway, aside from semantics, it sounds as if we are converging!
Cheers, ....Erik.
-------------------------------------------
Erik Skovgaard
GeoTrain Corp.
LDAP/X.500 Consulting and Training
http://www.geotrain.com
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
>
>
>