Hi Daniel
I've read more about your bug report and know what's happening.
You are proposing 2 OIDs, [1.2.840.48018.1.2.2, 1.2.840.113554.1.2.2],
1st one being Microsoft's own krb5 OID and 2nd the standard one. Java
only understands the 2nd one but before that changeset it blindly
accepts the mechToken without looking at the OID. Since it's also krb5,
the mechToken is processed correctly and everything goes on. After the
changeset, it does not recognize the OID anymore and asks the client to
send another mechToken with 1.2.840.113554.1.2.2.
I believe a lot of people is using the Microsoft OID. I will see if it's
possible to recognize both OIDs.
On the other hand, your program has
context.acceptSecContext(kerberosTicket, 0, kerberosTicket.length);
String user = context.getSrcName().toString();
which is not standard. The acceptSecContext call should be in a loop
until a context is established, and then you can call getSrcName(). Can
you try that? Hopefully after the client sees the server request for a
1.2.840.113554.1.2.2 mechToken it can send one and the server can go on.
Thanks
Max
On 4/23/2015 7:22 AM, Weijun Wang wrote:
Hi Daniel
Thanks for the report.
In fact, the bug behind the changeset you mentioned -- 8048194 -- was
just meant to make your case work. Before that, the server blindly
accepts the mechToken and process it no matter if the OID is supported.
Now it first looks at the OID and accept the token if it supports the
OID; otherwise, only the negotiated result (its supported OID) is sent
back, and waits for the client sending the correct mechToken in the next
round.
It seems the logic above is not implemented correctly, can you show me
the full stack of your NullPointerException? If it includes any
sensitive info you can write me privately.
Thanks
Max
On 4/23/2015 12:21 AM, Rob McKenna wrote:
Hi Daniel,
Thanks for the report, I'm cc'ing the security-dev alias.
-Rob
On 22/04/15 13:10, Daniel Jones wrote:
Hi all,
Apologies if this is the wrong mailing list - please direct me to the
correct one if so.
I believe I've found a bug in OpenJDK 1.8.0_40, introduced in commit
d777e2918a77:
http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java
The change introduced on line 548 means that an authentication
mechanism is
only accepted if the OID of the mechanism desired is the *first* in the
list of mechanisms specified as acceptable in the incoming ticket.
In the case of my current client their service tickets are specifying 4
acceptable mechanism OIDs, but the only available mechanism's OID
appears
second on that list. So whilst the server *can *satisfy the ticket, the
code change on line 548 prevents this from happening.
Using the same server code, the same Kerberos KDC, and OpenJDK 1.8.0_31,
everything works. Changing only the JDK results in the mechContext not
being properly populated, which in turn causes a NullPointerException
from
some Spring Security Kerberos code.
Has anyone else experienced this?
