Hi All, In developing a Jetty application using SPNEGO, I encountered some misleading error messages.
The browser was sending tickets that had a "kvno" that the webserver didn't have in it's keytab, yielding: GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed) Which does not point towards a solution, to say the least. There are 2 code paths, one (initiator) which requires the newest key be returned, and another (acceptor) which requires an exact kvno match. The current logic returns the newest key even when exact match is requested, instead of throwing BADKEYVER. For the acceptor case, this is an incorrect key, thus triggering exceptions related to decryption failure. According to ChatGPT: RFC 4120 says that when a server receives an AP-REQ, “If the key version indicated by the Ticket in the KRB_AP_REQ is not one the server can use (e.g., it indicates an old key, and the server no longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is returned.” In looking at the code in src/java.security.jgss/share/classes/sun/security/krb5/EncryptionKey.java I can see that the BADKEYVER exception is never thrown, but is commented out *close* to the required code path with the vague explanation "For compatibility, will not fail here." I have created new test cases for all callers of EncryptionKey.findKey() and implemed the missing exception logic. The result has been that existing callers are unaffected. A test of the SPNEGO kvno-mismatch in Jetty now gives the proper exception: GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44)) As a first time contributor I would appreciate some guidance here. The comments related to the missing exception are a bit troubling, and there is also the commented out throw statement, and although I think I have test coverage on all the callers of findKey(), I would welcome some input. Regards, Jeremy
