The change looks fine.
Well, I am fine w/ only provide the workaround for this MIT bug in jdk7
Valerie
On 03/31/11 09:38 PM, Weijun Wang wrote:
Hi Valerie
http://cr.openjdk.java.net/~weijun/7030180/webrev.00/
A bug in MIT krb5 1.8 triggers this exception (read evaluation below).
They will fix it in 1.8.4 and 1.9. At the mean time, we can check both
the session key and the subkey on the acceptor side.
I think this does not deserve a backport to 6u releases. Your opinion?
Thanks
Max
-------- Original Message --------
*Change Request ID*: 7030180
*Synopsis*: AES 128/256 decrypt exception
=== *Description*
============================================================
I tried to use SPNEGO.
When I use DES3 It works for a principal. When I try to use AES
128/256 It crashes.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
GSSException: Failure unspecified at GSS-API level (Mechanism level:
Checksum failed)
at
sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:741)
....
=== *Evaluation*
=============================================================
The customer is using krb5 1.8 on the client side. There is a known
issue that KRB-CRED inside AP-REQ is encrypted with the authenticator
subkey instead of the ticket session key:
http://krbdev.mit.edu/rt/Ticket/Display.html?id=6768&user=guest&pass=guest
At the same time, we can try both the session key and the sub key in
Java, this is also what MIT and Heimdal have done for years.
