Re: Authentication Methods for LDAP - last call (mandatory CRAM-MD5)

[Jonathan Trostle <jtrostle@cisco.com>]

> 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