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

Tue May 26 17:53:12 UTC 2020

Not completely sure about which of the involved apIs have what possible extensions. Maybe we can somehow make two mechanisms one which is the compatible default and one would be the rfc compliant method. Then SASL can be configured and use different mechanism names with a new propert? That would help jgss for the other mechanisms for channel bindings (cbt) as well. Not sure how jgss and JSSE will talk to each other.. via SASL?

--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> im Auftrag von Alexey Bakhtin <alexey at azul.com>
Gesendet: Tuesday, May 26, 2020 7:46:11 PM
An: Weijun Wang <weijun.wang at oracle.com>
Cc: security-dev at openjdk.java.net <security-dev at openjdk.java.net>; core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; Michael Osipov <michaelo at apache.org>
Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

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 --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200526/0352e08f/attachment.htm>