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

[Wei-Jun Wang]

The fallback to a key with the highest kvno is for production.

I'm considering two enhancements:

1. Update the error message if decryption fails with a key using different kvno.

2. Add a log message when a key with unmatched kvno is returned.

Thanks,
Weijun

> On Sep 10, 2025, at 13:57, Jeremy Jackson <jerj at coplanar.net> wrote:
> 
> 
> 
> On 2025-09-10 11:24, Wei-Jun Wang wrote:
>> Hi Jeremy,
>> 
>> Please read https://bugs.openjdk.org/browse/JDK-7197159  for the reason behind the code.
> 
> OK thanks, that is helpful as it explains the code comments.
> 
> In https://bugs.openjdk.org/browse/JDK-6907425  I read:
> 
> "...on the server side, keys are not read from keytab but generated with
> username/password pair and have no kvno info."
> 
> however it appears that ktab.exe by default generates keys with kvno =
> 1, which would fail to match after my modification.  Using
> 
> ktab -a <principal> <password> -n 0
> 
> would generate them with a kvno of 0, and the modifications I
> implemented would still allow the same findKey() behaviour.
> 
> The other case, where a keytab has an existing key, with a non-zero but
> non-matching kvno, but a valid key, would begin to fail.
> 
> I am wondering, is this non-RFC behaviour intended to be used in
> production or only in test scenarios where ktab.exe might be used to
> generate test data (keytabs)?
> 
> Thanks,
> Jeremy
> 
>> 
>> 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
>>> 
>> 
> 
>