Kerberos Bug Introduced in d777e2918a77?

[Seán Coffey]

Thanks for following through on logging this issue Daniel. I think 
you've sufficient information in the report to allow it to be evaluated. 
It's in the security team's queue at 
https://bugs.openjdk.java.net/browse/JDK-8078439

Regards,
Sean.

On 22/04/15 11:39, Daniel Jones wrote:
>
> Thanks for the reply.
>
> I've raised it as a bug through the online form, but sadly because of 
> the nature of the bug I couldn't provide a repeatable test in a 
> reasonable amount of time. Do you think it will still get taken seriously?
>
> Thanks again.
>
> On 22 Apr 2015 17:27, "Seán Coffey" <sean.coffey at oracle.com 
> <mailto:sean.coffey at oracle.com>> wrote:
>
>     Daniel,
>
>     thanks for the report. It might be best to report this issue via
>     http://bugreport.java.com/
>     Your report will be triaged there. You could also mail the
>     security-dev at openjdk.java.net
>     <mailto:security-dev at openjdk.java.net> list which has a more
>     suitable audience for such reports.
>
>     Regards,
>     Sean.
>
>     On 22/04/15 05: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?
>
>
>