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?
