On 22 Oct 2013, at 18:41, Andrew Deason <[email protected]> wrote:
> So anyway, a few ways to more robustly solve this. I'll give them > identifiers as I sometimes do so they can be referred to unambiguously. 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. 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. Cheers, Simon _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
