code review request: 7197159: accept different kvno if there no match

Weijun Wang weijun.wang at oracle.com
Sun Sep 9 10:27:53 UTC 2012


Please take a review at this

    http://cr.openjdk.java.net/~weijun/7197159/webrev.00/

In 6893158, we started kvno checking when parsing AP-REQ. Since then, we 
have compatibility reports that keytab created with JDK's ktab.exe fail 
because of this change. In 6984764, we added an option to katb.exe so 
that users can specify the correct kvno when creating a keytab, but it 
seems not enough.

This fix adds another fallback to the kvno check. If none of the keys in 
a keytab matches the required kvno, instead of reporting a 
KRB_AP_ERR_BADKEYVER error, we now returns a key of the same etype with 
the highest kvno.

Hope this stops the compatibility problem.

*Mala*: this is the alternative way I propose to solve the problem. It 
should be applicable to 6u and 7u.

Thanks
Max


-------- Original Message --------
7197159: accept different kvno if there no match

=== *Description* 
============================================================
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.




More information about the security-dev mailing list