LDAP Channel Binding

[Alexey Bakhtin]

Hello Bernd, Michael,

We’ve been working on the same issue and found that the Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding (based on the TLS server certificate):
	• The client calculates a hash of the TLS server certificate. The hash algorithm is selected on the base of the certificate signature algorithm. Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based
	• The channel binding information is the same as defined in rfc4121 [1] with small corrections:
		• initiator and acceptor addresses should be set to NULL
		• initiator and acceptor address types should be zero.
                  It contradicts to the “Using Channel Bindings in GSS-API” document [2] that say that
                  the address type should be set to GSS_C_AF_NULLADDR=0xFF,
                  instead of GSS_C_AF_UNSPEC=0x00.
On the base of this information we’ve made a patch for the LDAP, SASL and JGSS modules
to generate channel binding data automatically if requested by an application.
This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes
initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC.
The patch introduces new environment property “com.sun.jndi.ldap.tls.cbtype” that indicates
Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos.
Right now "tls-server-end-point" Channel Binding type is supported only.
The client extracts server certificate from the underlying TLS connection and creates
Channel Binding data for JGSS/Kerberos authentication if application indicates
com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property.
Client application should also specify existing "com.sun.jndi.ldap.connect.timeout” property
to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated.

The patch is available at : http://cr.openjdk.java.net/~abakhtin/channel_binding/webrev.v0/

[1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2
[2] - https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html

Regards
Alexey


Date: Tue, 18 Feb 2020 19:17:20 +0100
From: Michael Osipov <michaelo at apache.org>
To: Bernd Eckenfels <ecki at zusammenkunft.net>,
	"security-dev at openjdk.java.net" <security-dev at openjdk.java.net>
Subject: Re: LDAP Channel Binding
Message-ID: <28180b5f-515d-aab7-b901-b74153964d86 at apache.org>
Content-Type: text/plain; charset=windows-1252; format=flowed

Since we don't know what type of channel binding is used, how do you
want to fix that?

Are we finally talking about TLS channel binding? But which tls-unique
or tls-server-end-point?

Can you provide a pcap from that comm as well as debug dump from JSSE
and JNDI?

Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200519/d5d4ef6a/signature.asc>