> On May 27, 2020, at 1:46 AM, Alexey Bakhtin <ale...@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.w...@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 <ale...@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
>
