LDAP Channel Binding

[Weijun Wang]

> On Jan 22, 2020, at 6:31 AM, Michael Osipov <1983-01-06 at gmx.net> wrote:
> 
> 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.

Are you suggesting any change here? JGSS has channel binding method but the SASL mech has not called it.

Thanks,
Max

> 
> 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
>>> 
>> 
>> 
>