RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

[Alexey Bakhtin]

Hello Max,

Thank you review.
If I understand correctly tls-server-end-point channel binding data is a hash of server certificate. Different SASL protocols could send cbData differently, with different prefix format. This is a reason I create TLSChannelBinding class and calculate hash from the LdapClient and add “tls-server-end-point:” prefix in the JGSS/Kerberos.

Alexey

> On 26 May 2020, at 17:50, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> I have a question on GssKrb5Client.java:
> 
> Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name "com.sun.security.sasl.channelbinding" suggests it's just a general ChannelBinding which is independent with any application level info.
> 
> From my reading of the code change, it looks like this cbData can be calculated on the LDAP side.
> 
> Thanks,
> Max
> 
>> On May 21, 2020, at 3:35 PM, Alexey Bakhtin <alexey at azul.com> wrote:
>> 
>> Hello,
>> 
>> Could you please review the following patch:
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527
>> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/
>> 
>> 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 following :
>> 	• 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.
>> 
>> This patch introduces changes in 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.
>> 
>> [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
>> 
>> Initial discussion of this issue is available at security-dev list:
>> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html
>> https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html
>> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html
>> https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html

-------------- 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/20200526/9de7cf6b/signature.asc>