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

[Weijun Wang]

> On May 27, 2020, at 1:46 AM, Alexey Bakhtin <alexey at azul.com> wrote:
> 
> 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.

Not sure if I understand, what do "Different SASL protocols" mean? Here LdapClient is the application and therefore the "protocol". Are you worried that another SASL mechanism might choose a different prefix?

I really find the TLS word in a SASL mechanism strange. It belongs to a different layer.

--Max

> 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
>