On Fri, 12 Dec 2008, Dan White wrote:

Jeremiah Martell wrote:

...

Is there a way, when calling "ldap_sasl_interactive_bind_s", to tell it that when it does LDAP+GSSAPI authentication, only use GSSAPI for authentication, and not confidentiality?

In other words, just use GSSAPI to encrypt the authentication part, but not all subsequent searches, etc.

You can use SASL security properties to accomplish that.

...

dwhite@zek:~$ ldapwhoami -Y GSSAPI -h ldap.example.net -O maxssf=0 SASL/GSSAPI authentication started SASL username: dwhite@EXAMPLE.NET SASL SSF: 0 dn:uid=dwhite@example.net,ou=people,dc=example,dc=net

Hmm, how about integrity checking? If you want/need to protect your connection from substitution attacks or TCP hijacking then you should specify a maxssf of one. The GSSAPI layer would then still carry a crypto hash of the data without encrypting it.

Philip Guenther

On Fri, 12 Dec 2008, Jeremiah Martell wrote: ...

Interesting. I wanted to do this because Microsoft servers complain about redundant encryption.

If your GSSAPI provides confidentiality, and you're trying to use TLS, they barf out this error: Cannot start kerberos signing/sealing when using TLS/SSL

...

I'll experiment with setting it to 1, but perhaps I'm already protected by using TLS from the things you mentioned?

Short answer: yes.

All the normally enabled TLS cipher suites provide integrity protection (and confidentiality, for that matter).

Long answer: it depends

The issue is that there's no 'binding' of the GSSAPI authentication to the TLS channel: the GSSAPI bits on the two ends can't be sure that they're actually talking across the same secure channel.

The classic illustration is a server that requires confidentiality, but a client that doesn't. If the client sends a bind that doesn't request confidentiality without first doing StartTLS, the server will reject it (or require confidentiality to be negotiated anyway, I don't remember which). However, an active attacker could intercept the client's connection, then make its own connection to the server and negotiate TLS and pass the data between those. The server would think the connection has confidentiality and let it go forward, but that's not actually true.

There are two solutions to this: 1) enforce the confidentiality requirement in the client (if TLS is used, then checking of the server's cert must be done for this to be secure) 2) use a SASL mechanism that supports "channel bindings"

The latter is still a work in progress and will require time for support to be taken up by clients and servers.

Right now, if you're using an LDAP client with ldaps or that requires StartTLS (ala the -ZZ option) and it does proper server certificate checking (which has been the default in OpenLDAP since at least 2.2), then you're fine, but keep in mind that enforcing the confidentiality of the connection is incumbent on the client doing those correctly.

Philip Guenther