Am 2020-04-16 um 02:50 schrieb Weijun Wang:
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
There it is!
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.
Yes, it is bigger and inline with the other Kerberos implemenatations.
Is there any reason not to turn it on by default since the others do it too?
Thank you very very much for your support. Everything works now
consistently across platforms.
Michael
