> On Apr 16, 2020, at 5:10 AM, Osipov, Michael <michael.osi...@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
