JDK-7197159 : accept different kvno if there no match
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-09-09
  • Updated: 2015-02-02
  • Resolved: 2012-12-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6u60Fixed 7u80Fixed 8 b71Fixed
6893158 introduced kvno (key version number) check in AP-REQ parsing. This is a correct behavior but might cause interop/compatibility problems if the server uses a keytab with wrong kvno values. In fact, our vey own ktab.exe tool included in JDK can generate such keytab files because it does not know what the correct kvno is. (Other keytab generation tools like the kadmin or ktpass know the correct kvno because they need to connect to the KDC to work, but ktab.exe is a completely standalone tool)

Through 6984764, we've updated the ktab.exe tool so that user can specify the correct kvno on the command line, or specify it as 0 if it's unknown (0 will be accepted by the check). However, first it's quite difficult to find out the correct kvno. Second, there are old kaytab files that just contain wrong kvno.

This fix intends to add a fallback to the kvno checking, that when no key with matched kvno can be found, we will return the key of the same etype with the highest kvno, hoping it's the last one added to the keytab and therefore likely to be also the latest.