On Tue, 22 Oct 2013 20:47:34 +0100 Simon Wilkinson <simonxwilkin...@gmail.com> wrote:
> Requiring additional configuration, further keyfiles, or modifications > to the existing KeyFileExt format all sound like very heavyweight > solutions to the problem. In particular, I'm concerned that they'll > make what is already a tricky area of configuration even harder. Yes, of course; if we can do this without any user-visible anything, that is almost certainly better. > So, I suspect the best bet is > > D) When we're creating a new server connection we try the key with the > highest kvno in the keyfile for each server. If that key fails to > work, then we try the one with the next highest, and so on, until we > either succeed, or run out of keys. This does mean that an attacker > could force us to use an older key, but only for the period during > which the rollover is being performed. But how do we know if something failed due to key-related problems? I assume we can't really depend on a certain range of error codes (like rxk.*), and we can't redo everything on every error. -- Andrew Deason adea...@sinenomine.net _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
