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

[Wei-Jun Wang]

Hi Jeremy,

Please read https://bugs.openjdk.org/browse/JDK-7197159 for the reason behind the code.

That said, we will see if the exception message can be enhanced or there can be extra debug messages. I've filed https://bugs.openjdk.org/browse/JDK-8367344.

Thanks,
Weijun

> On Sep 9, 2025, at 19:08, Jeremy Jackson <jerj at coplanar.net> wrote:
> 
> 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
>