Hello Bernd,
> On 27 May 2020, at 13:12, Bernd Eckenfels <e...@zusammenkunft.net> wrote:
>
> LdapCtxt:
> 2568 /**
> 2569 * Sets the read timeout value
> 2570 */
> 2571 private void setChannelBindingType(String cbTypeProp) {
Thank you. This is misprint. Should be “Sets the channel binding type”
About timeout - Yes. It is required. Otherwise, LdapClient does not wait for
TLS handshake completion and we can not get TLS server certificate before
Channel Binding data is populated.
Actually, we can force to wait for handshake completion but what timeout should
be set in this case.
As mentioned by Danial, information about new property and timeout should be
documented in the release notes.
For the TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT type name, I do not
think it is good approach. If you think different servers could accept
different address types for the same Channel Binding type, It would be better
to introduce separate boolean compatibility property like
“com.sun.security.sasl.addrtype.compat”. In this case it would be applied not
only for tls-server-end-point but for any provided Channel Bindings
>
> Not sure if that javadoc is the right one? And I also wonder if enforcing the
> timeout is needed, and if yes if it should be documented why. Was not obvious
> to me,
>
> what about having two type names (TlsChannelBindingType.TLS_SERVER_END_POINT
> and TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT?)
>
> This could be configured as a SASL property and it would add the benefit that
> you don't need the instance specific if in the gssstub native code if you
> instead have two different types values?
>
> Gruss
> Bernd
>
> Von: security-dev <security-dev-boun...@openjdk.java.net> im Auftrag von
> Alexey Bakhtin <ale...@azul.com>
> Gesendet: Mittwoch, Mai 27, 2020 11:43 AM
> An: Valerie Peng
> Cc: security-...@openjdk.java.net; core-libs-dev@openjdk.java.net; Thomas
> Maslen
> Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
>
> Hello Valerie, Unfortunately, Windows LDAP server with
> LdapEnforceChannelBinding=2 does not accept GSS_C_AF_NULLADDR address type.
> This is exact reason of these changes. I ve tried to fix inconsistency of
> address type value in the latest webrev:
> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/
