Ping again (Re: code review request: 7197159: accept different kvno if there no match)

[Xuelei Fan]

Looks fine to me.  Good to have for compatibility.

Xuelei

On 12/17/2012 10:25 AM, Weijun Wang wrote:
> Xuelei or Valerie,
> 
> Can you review this code change? Some customers really likes this fallback.
> 
> Thanks
> Max
> 
> On 09/09/2012 06:27 PM, Weijun Wang wrote:
>> 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 ktab.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.
>>