Re: Auth Compromise (was Re: Authentication Methods for LDAP - last call)

[Jeff.Hodges@stanford.edu]

I personally think this proposal is a reasonable starting place from which to 
nail down a solution.

I think it is awfully late in the game to entertain changing from CRAM-MD5 to 
DAA (Digest Access Authentication, aka HTTP Digest). DAA would have to offer 
significantly greater security for roughly equal implementation (and 
deployment) cost for us to consider switching to it now. Personally, I'm going 
to look RFC 2069 over and get back to the list on my thoughts, but I'm 
certainly not a security-mechanism-and-digest-and-ciphersuite expert, and I 
don't know if any of us really are so maybe it's worth hearing from some about 
this.

I have a couple of comments on the proposed compromise text..

> here's a counter-proposal:
> 
>   CRAM-MD5 is MANDATORY-TO-IMPLEMENT for all LDAP servers.  This does not 
>   mean that CRAM-MD5 is appropriate to use in all cases.  However, when
>   CRAM-MD5 is disabled, an LDAP connection will be restricted to anonymous
>   access unless the client and server happen to have another 
>   authentication mechanism in common.  Because CRAM-MD5 is intended to be
>   the minimal acceptable authentication mechanism, LDAP servers SHOULD NOT
>   permit the use of simple bind over an unencrypted connection.  LDAP
>   clients and servers MUST have a configuration option to disable simple
>   bind over an unencrypted connection if they permit its use at all.
> 
>   Servers and clients SHOULD implement an authentication mechanism which
>   passes encrypted clear text passwords, such as the simple bind mechanism
                                         ^
                              over an encrypted connection

>   combined with TLS encryption.  This provides compatibility for existing
>   authentication databases such as Unix /etc/passwd.
> 
>   Servers and clients intended to operate in a large distributed
>   environment MUST implement an authentication mechanism capable of
                ^^^^
               SHOULD
>   distributed management such as the EXTERNAL SASL mechanism with TLS
>   client certificates, or the GSSAPI SASL mechanism with Kerberos V5.

In terms of the "SHOULD", we have no literal control over deployment 
intentions (the IETF isn't doing an implementation "branding" program, yet 
anyway), so I think it should be a SHOULD.


> I note that each of these three segments meets a different incompatible
> requirement for authentication mechanisms.  The first addresses the
> "simple, fast, but not clear text" requirement, the second addresses the
> "backwards compatible" requirement and the third addresses the "good 
> security & distributed management" requirement.

And these are the requirements as laid out in draft-newman-auth-mandatory-00.tx
t, yes?


Jeff