Max,
Am 2020-04-15 um 15:41 schrieb Weijun Wang:
I don't know about the history, but it looks like the original author believes
that for MS interop a NegTokenTarg should have the same bytes in reponseToken
and mechListMIC (this is weird of course). It has been working before, maybe
because the client never looks into the mechListMIC or maybe it does like it
being this style.
So the extra size is the mechListMIC token.
Since JDK 13, we don't duplicate the reponseToken into mechListMIC anymore. But
we still use this system property to determine whether to fill in that field.
By default, no; when set to false, add and verify it. If I understand SPNEGO
correctly, the field can be missing if the acceptor only understand one
mechanism, which is the case with JDK.
Have you tried JDK 13 or newer to see if the default works?
Can you point to the JBS causing that change? Going through log on
AdoptOpenJDK 13u doesn't show any change in that area.
I have tried
# /usr/local/openjdk13/bin/java -version
openjdk version "13.0.2" 2020-01-14
OpenJDK Runtime Environment (build 13.0.2+8-1)
OpenJDK 64-Bit Server VM (build 13.0.2+8-1, mixed mode)
and
# /usr/local/openjdk14/bin/java -version
openjdk version "14" 2020-03-17
OpenJDK Runtime Environment (build 14+36-1)
OpenJDK 64-Bit Server VM (build 14+36-1, mixed mode, sharing)
the tweak is not necessary anymore. Funny thing is, regardless of true
or false, I never get the duplicate token now. I wonder wether the
property has still any effect. I have tried curl with SSPI on Windows 10
and curl on FreeBSD with MIT Kerberos.
So since JDK only understands Kerberos where is the point in still
having this property since you always omit the mechListMIC?
Can you also answer why the new token (sans mechListMIC) is still
smaller than the one from MIT Kerberos or SSPI?
Michael
