Another issue discussed at length at the hackathon was that of key
expiry and migration. rxgk has a 'byte life' which indicates an
advisory maximum to the amount of data that may be encrypted by a
single key. However, the process of determining how to rekey the
connection remained unclear. The following was proposed:
As part of the security header which precedes the encrypted payload,
include a key version number. Incorporate that key version number into
the per-connection derivation alogrithm, so we can derive a unique key
for each key version number. When a client, or a server, wishes to
rekey the connection, it may simply start sending packets with a later
key, and key version number. When the other end receives packets with
a later version number, it should start sending using a key with that
version number, too.
Comments?
Simon.
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
