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

[Weijun Wang]

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