LDAP Channel Binding

[Bernd Eckenfels]

Hello,

Ok, so I have tested the GSSAPI method with a non-native (endured, non delegated) Kerberos login and it works with and without TLS no matter if channel binding is enforced or not. (GSS without TLS fails as expected with auth when request signing is required).

So this either means the enforcing does not work on Windows Server 2019 or the enforcing is not for TLS binding in GSSAPI handshakes.

I will publish the traces later.

BTW1 when using GSS with TLS and requesting Auth-int and/or auth-conf the MS DS will actually terminate the connection with a "wrong parameter" error (on the server side event log) and close the socket with no proper error.

BTW2 i tested anonymous binds, it rejects RootDSE queries in my case.

Gruss
Bernd

--
http://bernd.eckenfels.net
________________________________
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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20200120/952da373/attachment-0001.htm>