JGSS EncryptionKey.findKey() exception handling enhancement - guidance requested

[Jeremy Jackson]

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