RE: Authentication Methods for LDAP - last call (mandatory CRAM-M D5)

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

 My concerns are when one builds a real directory system with many users
accessing many servers - how does one do that with LDAP - unless one
replicates all the entries of those users to all the servers and all the
crypto used to verify those users to all the servers....

As said - it does not matter what algorithm one might define as  default
for ONE LDAP server.. Thats not a saleable or scaleable solution when
dealing with real systems.

Until one puts distribution and mutual authentication between servers as
per X.500 DSP - into the LDAP program - the security designs for LDAP
have limited value..

regards alan
----------
From: Jonathan Trostle
To: ietf-ldapext@netscape.com; Jeff.Hodges@stanford.edu
Cc: mcs@netscape.com; howes@netscape.com; S.Kille@isode.com;
M.Wahl@INNOSOFT.COM; johns@cisco.com; Bob.Morgan@stanford.edu;
Harald.Alvestrand@maxware.no; jtrostle@cisco.com
Sent: 8/4/98 12:19:56 PM
Subject: Re: Authentication Methods for LDAP - last call (mandatory
CRAM-MD5)


> In fact, my concern isn't so much having CRAM-MD5 be the 
> least-common-denominator auth mechanism -- its more what we've omitted

> entirely from profiling in AuthMeth -- e.g. Kerberos v4 and v5, in
particular, 
> that concerns me. I think it is more important for the larger, more
customized 
> enterprise deployments (such as Stanford) to have adequate provisions
for 
> tailoring directory client and servers to their already-deployed auth 
> infrastructure than it is to worry (for them) about whether CRAM-MD5
is 
> implemented by default in the tools they buy. They simply aren't going
to use 
> it(*).
> 
> In terms of addressing this last point, I'm not sure whether it's
legitimate 
> or not to put something in AuthMeth like..
> 
>   Client and server mplementations MUST have provisions for end-user
addition
>   of support for at least these security mechanisms: <list of SASL
mechs 
here>.
> 
>   [E.g. the fashion in which Netscape's client SDKs and Directory
servers are 
>    extensible through plug-ins.]
> 
> ..but it'd be great for Stanford (if we can't get Kerberos v4 and v5
to be 
> mandatory for all our vendors to implement ;-)
> 
> So, I think the CRAM-MD5 thing is fine (for now), but I wonder if the
doc goes 
> far enough in that it doesn't profile Kerberos v4 or GSSAPI (Kerberos
v5 et 
> al), or make any mandates about implementation extensibility.
> 
> Jeff

We could live with GSSAPI/Kerberos v5 as a mandatory mechanism :-). It 
accomplishes what CRAM-MD5 tries to do plus more, but is more work to
implement. 
Given that CRAM-MD5 does not satisfy everyone's needs, and that a purely

certificate based mechanism has been rejected as the mandatory
mechanism, would 
Kerberos v5 or some other mechanism be suitable as a mandatory
mechanism?

Jonathan