-
CSR
-
Resolution: Approved
-
P3
-
None
-
behavioral
-
minimal
-
-
Other
-
JDK
Summary
Add support for LDAP Channel Binding information for Java GSS/Kerberos connection. No changes from JDK 16, CSR JDK-8247311
Problem
Microsoft introduced a 'LdapEnforceChannelBinding' option requiring clients to provide channel binding information in order to connect to AD over SSL/TLS.
The current JDK implementation does not send required Channel Binding data to the server. As a result, LDAPS connection from an authenticated client that uses GSS fails.
Solution
- Add "com.sun.jndi.ldap.tls.cbtype" JNDI environment property indicating Channel Binding type required for connection. Possible value is:
- "tls-server-end-point" - Channel Binding data on the base of the server TLS certificate.
- The following TLS Channel Binding types are specified in RFC-5929 but not supported:
- "tls-unique" is not supported.
- "tls-unique-for-telnet" is not applicable for LDAP connection.
- The Channel Binding data is created according to the following specifications:
- RFC-5929 "Channel Bindings for TLS". Section 4 describes the encoding of the TLS Channel Binding data
- RFC-5056 "On the Use of Channel Bindings to Secure Channels". Section 2.1 describes the prefix encoding for different channel binding types.
- RFC-4121. Section 4.1.1.2 describes format end encoding of Channel Binding data for GSS/Kerberos
- "NTLM and Channel Binding Hash" document. This document describes values and encoding of the initiator/acceptor addresses and address type values.
- The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding (based on the TLS server certificate). The channel binding data is calculated as follows:
- Implementation calculates a hash of the TLS server certificate. The hash algorithm is selected on the base of the certificate signature algorithm. Also, the implementation should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based
- Implementation adds name of the Channel Binding type and colon (ASCII 0x3A) before the hash.
- Initiator and acceptor addresses should be set to NULL
- Initiator and acceptor address types should be zero. It contradicts the "Using Channel Bindings in GSS-API" document that says that the address type should be set to GSS_C_AF_NULLADDR=0xFF, instead of GSS_C_AF_UNSPEC=0x00. The implementation ensures that the changes in address type are applied to the TLS Channel Binding data only requested by "com.sun.jndi.ldap.tls.cbtype" property.
Links to the documents:
RFC-5929 "Channel Bindings for TLS": https://www.ietf.org/rfc/rfc5929.txt
RFC-5056 "On the Use of Channel Bindings to Secure Channels": https://www.ietf.org/rfc/rfc5056.txt
RFC-4121 "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2": https://www.ietf.org/rfc/rfc4121.txt
"NTLM and Channel Binding Hash": https://docs.microsoft.com/en-us/archive/blogs/openspecification/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication
"Using Channel Bindings in GSS-API": https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html
Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v14/
Specification
Add the following section into src/java.naming/share/classes/module-info.java
* <li>{@code com.sun.jndi.ldap.tls.cbtype}:
* <br>The value of this property is the string representing the TLS
* Channel Binding type required for an LDAP connection over SSL/TLS.
* Possible value is :
* <ul>
* <li>"tls-server-end-point" - Channel Binding data is created on
* the basis of the TLS server certificate.
* </li>
* </ul>
* <br>"tls-unique" TLS Channel Binding type is specified in RFC-5929
* but not supported.
* <br>If this property is not specified, the client does not send
* channel binding information to the server.
* </li>
- csr of
-
JDK-8256650 LDAP Channel Binding support for Java GSS/Kerberos
- Resolved
-
JDK-8256555 LDAP Channel Binding support for Java GSS/Kerberos
- Closed