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

[Jeremy Jackson]

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
>>
>