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

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

Thanks,
Max

> On Apr 15, 2020, at 5:09 AM, Osipov, Michael <michael.osipov at siemens.com> wrote:
> 
> Hi Max,
> 
> I have just wasted an entire day to make the following observation:
> 
> Running Java 8u242, SPNEGO acceptor via HTTP. SSPI clients constantly report: SEC_E_INVALID_TOKEN. Tried with Java via JNA, Java via new SSPI Bridge, Python SSPI Negotiate module. Regardless of what I do the token generated by Java is invalid for the initiator.
> I am running a Windows 10 client on my desktop.
> A MIT Kerberos acceptor reponds:
> > oYG2MIGzoAMKAQChCwYJKoZIgvcSAQICooGeBIGbYIGYBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARuixaQG7nwXC0uiguOl256srmAhgjVD9A5OgHQ+fXdJ03zNMQhLu2ly93WzHfUxaDOKZPS5Wkfz1NHVyRMiYcS7EwzYg+c97Q0aYOLqcQG+0j3pGVHFWzEyMZW4OoWOD6avnX9dI+oDE
> 
> An ASN.1 sequence with three members. Java, SSPI, MIT Kerberos accept this one.
> 
> JGSS responds:
> > oYHzMIHwoAMKAQChCwYJKoZIgvcSAQICom0Ea2BpBgkqhkiG9xIBAgICAG9aMFigAwIBBaEDAgEPokwwSqADAgESokMEQT2FosuhMJoIXpAw4GyGADOfD7bsyPGfNAvUV1kKJGqR/0X+2rzby4XU5qWYypCT4asVvlw6LkWbK79P6vaT5vCQo20Ea2BpBgkqhkiG9xIBAgICAG9aMFigAwIBBaEDAgEPokwwSqADAgESokMEQT2FosuhMJoIXpAw4GyGADOfD7bsyPGfNAvUV1kKJGqR/0X+2rzby4XU5qWYypCT4asVvlw6LkWbK79P6vaT5vCQ
> 
> Sequence has four members. The last two members are the encrypted response token twice(!). Java and MIT Kerberos accept this, SSPI rejects.
> 
> After poking around for hours I have found sun.security.spnego.msinterop. As soon as this one is set to false (default: true). Following token is genereated:
> > oYGEMIGBoAMKAQChCwYJKoZIgvcSAQICom0Ea2BpBgkqhkiG9xIBAgICAG9aMFigAwIBBaEDAgEPokwwSqADAgESokMEQRS9XZ5wjfA5wj832Zs9pufcP6IRArfBgG6/2XiU/vv2++i1vK/kmhc3UIa9X4nb2e7+CgCXV7X1rK30vCHKTeIv
> 
> Three members, but the token is almost as twice as small as the one from MIT Kerberos.
> 
> A SSPI acceptor returns:
> > oYG2MIGzoAMKAQChCwYJKoZIgvcSAQICooGeBIGbYIGYBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARuuhFIL4c9Nzov6g93sh5Q81AB2c5nK5ZyQQXcN1TmNaCDjsdn9irTnui7NO3ogemrrUO6sRT2A7hB01mwvY23ZVetNaQ/DCmnI8q2ATppcFf9yUPRNDZ8Gqg2FlKSTeusK5fcFQOjZmmxXB1vbRo=
> 
> three members and 110 bytes just like MIT Kerberos.
> 
> Decoded with: https://lapo.it/asn1js
> 
> Two important points arise here:
> * As far as I remember MIT Kerberos never returned anything else. This hack does not work for SSPI initiators anymore, at least here on Windows 10. File an issue with JBS? Request to set to false for 15, reqeust backport and document it?
> * Why is the token as twice as small?
> 
> Michael