[Moderator: I believe the following questions particular to OpenLDAP were still unanswered]
On Fri, 22 Aug 2008, Ben Wailea, openldap-software wrote:
On Fri, Aug 22, 2008 at 12:50 PM, Philip Guenther guenther+ldapsoft@sendmail.com wrote:
...
security tls=256
I.e., refuse to do _anything_ unless TLS is negotiated with an SSF of at least 256 (i.e., 256 bit encryption cipher). Is that *really* the requirement you mean to enforce?
the goal is to always/only use TLS with an AES-256 encryption cipher. the hope is that that 'security' directive accomplishges that.
Sorta. It makes LDAP requests fail if they didn't use TLS with AES-256, but it doesn't prevent a client from negotiating TLS with, say, AES-128. If you want to require AES-256, then you should set the TlsCipherSuite option to limit the accept ciphers also. The exact syntax will depend on whether you're using OpenSSL or GNUtls and what type of key the server has. See the slapd.conf(5) manpage for details.
(Interestingly, some versions of openssl support AES256, but don't have any way to say "accept AES256 and not AES126". In effect, the cipher suite parsing can't "tell them apart". So test your settings before relying on them!)
disallow tls_2_anon
Hmm, why do you set that option? Do you know why the default isn't to do that?
the goal is to not allow any anonymous connetion/bind/etc.
to the extent that 'man slapd.conf' shares
tls_2_anon disables Start TLS from forcing session to anonymous status (see also tls_authc). tls_authc disables StartTLS if authenticated (see also tls_2_anon).
that seems to be the right choice. afaict, there's no additional documentation on the matter.
That's not what the "disallow tls_2_anon" option does.
By default, if a client does this: BIND STARTTLS
then the STARTTLS will 'undo' the authentication, reverting it to anonymous. That's good because the connection was unprotected between the BIND and the STARTTLS and could have been hijacked. The option disallow tls_2_anon
changes it so that it _doesn't_ revert to anonymous. That option is *less* secure than the default and should only be used in specific situations where required and the implications are understood.
However, your other settings make the change pointless, because you don't permit BIND before STARTTLS anyway!
and, that description smacks of "read other side" being written on both sides of a postcard ...
Not at all. The tls_2_anon says "if you do permit STARTTLS after BIND, then don't undo the BIND", while "tls_authc" says "don't permit STARTTLS after BIND at all".
Philip Guenther