Max (Weijun) Wang wrote: > Hi All > > 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?
No, more then one key can be valid. > > 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 be doing this. Two (or more) keys may still be valid. If the key of a service is updated in the KDC and keytab a new kvno is used. The KDC will start issuing new tickets using the new key, but tickets issued prior to this but still withing their lifetime are still valid, and may have been cached by a client and can still be used. Thus for some time two (or more versions) of the key are still valid. After the longest possible lifetime for a ticket, the admin should then remove the the old keytab entries. If there is some concern that older valid tickets should not be used the admin can remove the old key from the keytab rather then adding it. > > Thanks > Max > > _______________________________________________ > kerberos-discuss mailing list > kerberos-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/kerberos-discuss > > -- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
