In message <[email protected]> Manav Bhatia writes: > > Hi Curtis, > > > > > You might want to say "for doing *session* key rollovers". The > > persistant key rollover would need a different mechanism. > > > > I had actually meant a persistant key rollover. Why would this mechanism > not work there? > > Assume A and B are speaking to each other and A now wants to move to a > different key. All it needs to do is to generate a new Nonce that will > be fed into the KDF that B will use to generate the new traffic key. > > Also note that the keys used in this proposal will not be symmetrical. > > Cheers, Manav
The common practice as I understand it is to maintain at least two keys, one is used to build authentication headers and one or either of the two can be used to check authentication headers. During a cutover, there is an interim period during which one end is more up to date than the other. First the second key is added as an alternate key to check authentication headers. Then when the provider (or software) has verified that this key is available where it needs to be, the new key is used to build authentication headers. Finally the old key is disabled and the process can be repeated later. The same applies to assymmetrical key pairs. The new public key needs to be on the recieve side before the sender starts using the new private key (assuming that sort of key pair). There should be no requirement for the persistant key to be symmetrical and it is perfectly valid to have different shared session keys for each direction, though perhaps there is very if any little benefit. The session keys would be unique to a pair of routers, would be transient in nature, and there is no need for the NOC (network operation center) to know what session keys are in use at any given time. Only the persistant keys would be maintained by the NOC and held in non-volitile memory so as to remain persistant over reboots. Curtis _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
