On Mon, Oct 19, 2009 at 11:11:49PM +0800, Max (Weijun) Wang wrote:
> In Java, the Kerberos acceptor reads one key for each etype from a
> keytab file at the very beginning. When there are multiple keys with
> the same etype for a service principal in the keytab, we have to
> choose one of them. We used to choose the one which appears last, but
> have changed to choose the one with the highest kvno recently.
> However, it seems both are breaking apps out there in this or that
> customer's environment.
>
> My question is: does a new key always have a higher kvno than the
> older one? I know there's also a timestamp in the keytab file. Is
> choosing the latest timestamp a better choice?
The *protocol* specification (RFC4120) does not require it. In practice
monotonically increasing kvnos is the common practice, but you cannot
rely on it for two reasons: a) KDC implementors are free to do something
other than monotonic increments, b) often admins will delete a principal
and then re-create it, which resets the kvno, which means that you'll
see repeating kvnos.
> If no one is guaranteed correct, we'll have to read all keys and
> choose the correct one at runtime according to the kvno field in the
> EncryptedData received. This approach should be the best one but is
> quite different from our current one-key-per-etype policy. Before
> making this change, I'd like suggestions from you.
You should search the keytab for exact[*] {sname, srealm, enctype, kvno}
matches. If you don't find a keytab entry for that, then you must fail.
If you find more than one match with different keys then you should use
the latest entry[**], if you can tell which that is, else you should try
them all or just fail (you're free to declare such a situation a
misconfiguration).
Nico
[*] Well, taking "enctype similarity" (all the 1DES enctypes are
"similar") into account.
[**] Keytab entries have no timestamp, sadly, and though entries are
typically appended to a keytab, you can't entirely depend on that
(the tools are available to manipulate keytabs). But in practice
the last entry is typically the latest, so if there are multiple
matches with different keys, picking the last one is a reasonable
strategy. If a customer re-orders the keytab in such a way that
you'd pick the wrong key, then IMO you're free to call this a
misconfiguration.
