LDAP Channel Binding

[Michael Osipov]

Am 2020-01-21 um 17:57 schrieb Bernd Eckenfels:
> Hello,
>
> I have now repeated the tests with LdapEnforceChannelBinding=2 and I
> could see the rejection with error code 80090346 for GSSAPI and
> DIGEST-MD5 with TLS.
>
> The simple bind with TLS and the GSSAPI or DIGEST-MD5 without TLS but
> with auth-int/conf all work with signing and binding required (I.e
> after Microsoft charged defaults in March)
>
> (Which makes the TLS binding a bit useless, but we should still think
> about supporting it.)
>
> Jgss seems to already allow to set it, so only JSSE needs to provide
> an api for sasl/jndi.

How? I am confused! The Kerberos SaslClient does not use/set GSS channel
bindings. I don't see any in com.sun.security.sasl.gsskerb.

The implication of LDAP channel binding is not to rely on mech binding,
but on the outer channel (TLS) binding.


> ________________________________ Von: Michael Osipov
> <1983-01-06 at gmx.net> Gesendet: Sonntag, Januar 19, 2020 11:15 AM An:
> Bernd Eckenfels Cc: security-dev at openjdk.java.net Betreff: Re: LDAP
> Channel Binding
>
> 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
>>
>
>