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

[Jonathan Trostle <jtrostle@cisco.com>]

Right. I think public key crypto is the accepted way of solving this problem. So 
you should use TLS, Kerberos pkinit, X509 or some other public key mechanism 
when going outside the local administrative unit. Within the local 
administrative unit, secret key Kerberos works for most cases. (As you probably 
know, Kerberos does not replicate secrets to every server in the domain).

Jonathan

> X-SMAP-Received-From: outside
> From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
> To: "'ietf-ldapext@netscape.com '" <ietf-ldapext@netscape.com>, 
"'Jeff.Hodges@stanford.edu '" <Jeff.Hodges@stanford.edu>
> Cc: "'mcs@netscape.com '" <mcs@netscape.com>, "'howes@netscape.com '" 
<howes@netscape.com>, "'S.Kille@isode.com '" <S.Kille@isode.com>, 
"'M.Wahl@INNOSOFT.COM '" <M.Wahl@INNOSOFT.COM>, "'johns@cisco.com '" 
<johns@cisco.com>, "'Bob.Morgan@stanford.edu '" <Bob.Morgan@stanford.edu>, 
"'Harald.Alvestrand@maxware.no '" <Harald.Alvestrand@maxware.no>, 
"'jtrostle@cisco.com '" <jtrostle@cisco.com>
> Subject: RE: Authentication Methods for LDAP - last call (mandatory CRAM-M D5)
> Date: Tue, 4 Aug 1998 13:50:25 +1000
> X-Priority: 3
> MIME-Version: 1.0
> 
>  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 
>