On Oct 19, 2009, at 11:11, 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? > > 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.
If you're doing it to process received authenticators, I would say that using the kvno and enctype received is the best way to go. Even if you can figure out the most recently stored key with 100% accuracy, there are legitimate cases where it will be the wrong one to use. Consider a site with a security policy that says service keys should get changed every N weeks. (Or, a new software update adds support for a new, stronger encryption type.) So you get a new key and kvno. However, two minutes earlier, someone authenticated to the server and has the credentials cached, and they're going to want to authenticate again shortly. If you only permit the newest kvno value, that user will be out of luck; it'll look like any other decryption failure, data corruption, whatever. (There are use cases where you do want to immediately invalidate old keys, generally because the key's been compromised or may have been. But in that case, why keep it around in the keytab? Why not just get rid of it altogether? Then this problem of choosing which to accept wouldn't apply to that case.)
