Kerberos Bug Introduced in d777e2918a77?

Weijun Wang at
Wed Apr 22 23:22:02 UTC 2015

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 

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.


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

More information about the security-dev mailing list