Re: [OSPF] FW: Using dynamically derived Traffic Keys for Routing Protocols

["Bhatia, Manav (Manav)" <[e-mail]>]

 
> 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.

Yes, this is correct.
 
> 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.

This too is correct and is inline with what I am thinking.

I was initially thinking of deriving the traffic or the session key based on the nonce that the other end generates. While this works when there are only two routers speaking to each other, it creates a problem on a LAN because now you don't know which nonce to pick for generating the traffic key. We could define some election mechanism but that's getting needlessly complex.

A different approach that fixes this issue is by deriving the traffic key based on the nonce that the router itself generates.

Let me explain how.

Routers A and B have a Key/Password that is exchanged through some OOB mechanism or a KMP. Each side generates a nonce and mixes it with the Key using some KDF to derive its own traffic keys. This means that both A and B use a different traffic key/password to secure the packets on the TX. Upon receiving the protected protocol packets each side reads the Nonce that's carried in the packet and is able to derive the traffic key since its aware of the original Key and the KDF. It uses this traffic key to authenticate the packet. 

To make this work the freshness of a packet carrying the nonce must be guaranteed, because we don't want the receiver to start consuming replayed packets carrying an older nonce.

This can be achieved by using a mechanism similar to our original challenge/response mechanism which will always guarantee freshness.

Traffic or Session Key rollover is achieved by simply changing the Nonce at the local end. The receiver will verify that its indeed the router that it should be speaking to that's changed this and once it verifies it will move to the new key. Again, how the receiver verifies this has been explained in draft-bhatia-karp-ospf-ip-layer-protection

Cheers, Manav