> 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.
This seems rather more heavyweight (at least from the perspective of implementing it in openafs), since it would involve inserting some sort of loop around client rpcs in every server and any client that uses localauth, whereas andrew's options would be implemented within src/auth/authcon.c (and lower level things called from there). (Assuming we were willing to take some liberties, I suppose D could also be implemented in a new rx security class, but would probably require new rx security ops so rx could know if it should retry, and it would also mean that rx connection and call objects could have their identity change out from under the caller) At some point during the development of rxkad-k5, some of us discussed an extention to KeyFileExt that would include up to four timestamps containing key validity periods (a start and end time for use as a server credential, and a start and end time for use as a client credential). This would be similar in effect to C. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
