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

[Jeff.Hodges@stanford.edu]

Re: the mandatory CRAM-MD5 argument. 

> Steve Kille said:
> If an enterprise chooses to adopt authentication scheme X, 
> then only clients that support this scheme will 
> interoperate with servers in that enterprise.  We are NOT 
> going to force CRAM-MD5 onto all enterprises.  
> Interoperability really is bogus in this case.

Well, I think that the spirit of the IESG requirement is more in terms of 
ensuring that some random off-the-shelf client utilizing protocol X will be 
able to be configured to interact with some random off-the-shelf server 
implementing protocol X -- without passing user's passwords over the net in 
the clear. This requires that there be some security feature common to all 
implementations of X -- let's call it S. This ~doesn't~ mean that sites 
deploying X have to configure and use S. They can if they want or not if they 
want.

> Steve Kille had said a bit before:
> While there are benefits to having a single mandatory 
> mechanism, given the current situation with LDAP, forcing
> a mandatory implementation of a mechanism which is totally 
> inadequate for many deployments is a nonsense.

But there will be many deployments where it is adequate. LDAP isn't going to 
be only used in large enterprise settings where its deployment is likely to be 
site-specific. It will also be used in plug-and-play off-the-shelf 
consumer-oriented LAN/intranet software suites (lessee, one's called 
Suitespot?). As Tim said, we considered a certificate-based mechanism, and 
rejected it as too high an implementation burden (these days).

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


(*) In actuality, we do care, because in our highly decentralized environment, 
individual departments are going out and deploying stuff, such as Suitespot, 
and using it's wholy-inadequate default password-in-the-clear auth over our 
highly hostile network. These orgs and their use of stuff such as Suitespot 
are examples of the sorts of organizations where having a 
lowest-common-denominator security mechanism such as CRAM-MD5 is a step in the 
right direction. Stronger and more complete (e.g. providing for 
confidentiality and integrity) security stuff would be even better, but we'll 
take what we can reasonably get ~today~.