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 <[email protected]> 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 <[email protected]> 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 >>> >> > >
