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

Weijun Wang weijun.wang at oracle.com
Thu Apr 16 00:50:32 UTC 2020



> On Apr 16, 2020, at 5:10 AM, Osipov, Michael <michael.osipov at siemens.com> wrote:
> 
> 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.

http://hg.openjdk.java.net/jdk/jdk/diff/74f0622db875/src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java

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

It is still used. When not set (or true), mechListMIC field is ignored and not generated.

> 
> So since JDK only understands Kerberos where is the point in still having this property since you always omit the mechListMIC?

Set it to false and you get the mechListMIC. It is not useful now.

I remember there is a part in the Microsoft SPNEGO doc (MS-SPNG) on which versions of Windows use this field. It's quite complicated. I think leaving this system property there might help with interop issue in some cases (when the MS peer insists the field should be present).

> 
> Can you also answer why the new token (sans mechListMIC) is still smaller than the one from MIT Kerberos or SSPI?

The AP-REP inside contains a 

   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
           ctime           [0] KerberosTime,
           cusec           [1] Microseconds,
           subkey          [2] EncryptionKey OPTIONAL,
           seq-number      [3] UInt32 OPTIONAL

So I guess it's because Java has no subkey set. Try "-Dsun.security.krb5.acceptor.subkey=true" to see if it's bigger.

Thanks,
Max

> 
> Michael



More information about the security-dev mailing list