LDAP Channel Binding

[Michael Osipov]

Am 2020-01-19 um 08:02 schrieb Bernd Eckenfels:
> You said it is confusing, but the bug you mentioned is only a valid
> feature request, it does not talk about failing binds. I would assume
> that Kerberos needs the binding token and the others not.
> Unfortunatelly the doc from Microsoft is quite incomplete and
> confusing.

The problem is that JSSE Sun Impl documentation does not even mention
TLS channel binding. To make things worse, I agree with you, Microsoft's
documentation is horrible. It does not say whether we are talking about
GSS-API channel binding or TLS channel biding.

The best I have comeup with is https://github.com/WinRb/rubyntlm/issues/27
https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/dd639324(v=vs.90)?redirectedfrom=MSDN

> So has anybody seeing failing TLS binds yet and if so, in which
> condition?

Yes, see https://stackoverflow.com/q/59756206/696632

What I can say is tht in our company auth-int has been mandatatory for
several months now and my Java code always used auth-conf with GSSAPI
mech w/o any flaws.

> It is also not clear why AD proposes the auth. quality of protection
> from digest-md5 if it is configured to reject it. So if somebody can
> get Microsoft to look into this and provide details, that would be
> great.
>
> Gruss Bernd
>
>
> -- http://bernd.eckenfels.net ________________________________ Von:
> Michael Osipov <1983-01-06 at gmx.net> Gesendet: Saturday, January 18,
> 2020 9:39:08 PM An: Bernd Eckenfels <ecki at zusammenkunft.net>;
> security-dev at openjdk.java.net <security-dev at openjdk.java.net>
> Betreff: Re: LDAP Channel Binding
>
> Am 2020-01-16 um 11:32 schrieb Bernd Eckenfels:
>> Hello,
>>
>> Some updates:
>>
>> Microsoft moved their automatic update of the LDAP policies in
>> Windows Server updates to March 2020 (but still recommend to
>> activate it earlier).
>>
>> And I did some tests: when you turn on the mandatory LDAP Signing,
>> then simple binds or Digest-md5 binds over LDAP are rejected by
>> NTDS. Both work over ldaps: (Implicite TLS, did not check
>> STARTTLS). DIGEST-MD5 without TLS is also possible, but you have to
>> request qop=auth-int. (Sidenode AD will reject digest-md5 with
>> Auth-int over TLS). I did not Test GSSAPI or SPNEGO yet.
>>
>> The mandatory LDAP channel binding does not seem to make a
>> problem/change. I suspect it only applies to Kerberos or NTLM which
>> I still need to test.
>
> That is confusing because:
> https://bugs.openjdk.java.net/browse/JDK-6491070
>
> I am excited to see your GSSAPI mech results. You cannot test SPENGO
> because the Java SASL factory does not suppor the GSS-SPNEGO SASL
> mech.
>
>> PS: testcode
>> https://gist.github.com/ecki/cdd7a14575b7dca10da8d362974731a0
>
> You code looks wrong. Retrieving data from RootDSE does not require
> a successful bind. It will work anonymously. You need to go down the
> tree.
>
> Look at ldapsearch(1), if you don't provide -Y GSSAPI, it will
> perform a simple search for supportedSASLMechanisms and pick the best
> one it supports. This is the same as obtaining the root naming
> contexts, this can be done anonymously too.
>
> Michael
>