sun.security.spnego.msinterop does not work anymore/disable by default for 15

[Osipov, Michael]

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