I have been writing down some logic to deal with when KDC needs to change epochs. This is in part because I need to figure out what should be constant and what needs to be exposed in the user interface for configuration purposes. Some of the inputs are pretty easy to see such as: If X amount of time has passed then do a key roll over or, Don't roll keys over if less than Y time has passed. Some of the checks can get really weird such as: I have issued you a kid but have not given you key material in the current epoch, so I can just give you the same kid with the new key material. On the other hand if I have given you key material in the current epoch, I should not need to roll over the key material but do need to provide a new kid so that you do not reuse the save IV values. Alternatively, it could be that rolling the key material would be more efficient in terms of traffic on the wire depending on if one things that retrieving key material or retrieving signatures for every entity is going to be smaller.
The one case that I have not been able to get a good handle on is as follows: The KDC persists keys and key ids in a database. The KDC at some point crashes and then restarts. Should the KDC roll the epoch and the key material on re-start or should it just load the current key material and continue with it? A client that tries to JOIN would be unable to do so because the KDC does not respond so that would not force a roll over. A client that tries to do a RENEWAL because of IV exhaustion would be unable to do so and would have to go quiet until the KDC because alive and that would not force a roll over. A client that tries to do an LEAVE would not be able to tell the KDC that. This is the one case that having the KDC do the roll over of the keys would make sense. However the KDC would be unable to tell anybody of that decision as all of the observe relationships would have been lost at the point so that in some respects the damage of allowing an entity that left to continue reading messages would continue. Does anybody have an opinion or different analysis that they would be willing to share? Jim _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
