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

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 14 Apr 2011 08:02:12 +0530

OSPFers,

Can a variant of this method be used to protect OSPFv2 and OSPFv3-AT? 

Cheers, Manav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bhatia, Manav (Manav)
> Sent: Thursday, April 14, 2011 5.18 AM
> To: [email-masked]
> Subject: [karp] Using dynamically derived Traffic Keys for 
> Routing Protocols
> 
> Hi,
> 
> Instead of using the pre shared key (PSK) in manual keying 
> for all packets the routing protocols could use a traffic key 
> that's derived from the PSK using some key derivation 
> function. Each side could announce a random number (a nonce) 
> and the KDF could mix this with the PSK to derive the traffic 
> key per session. Benefits of this approach:
> 
> o Key rollover becomes very easy as it's a local decision now 
> requiring now co-ordination with our peers. Each side can 
> generate a new nonce and all others recompute the traffic key 
> based on the new nonce value. Attackers cant inject packets 
> with spurious nonces as this packet will be protected using 
> the traffic key based on the nonce that others have sent.
> 
> o Avoids inter-session replay attacks without involving non 
> volatile memory as each router will use a different nonce 
> upon booting up.
> 
> In OSPF the nonce could be carried in the HELLO packets. 
> There could be bit carried in the HELLOs which would indicate 
> that the Hello is currently using the long lived key (or the 
> PSK). The receiver upon receiving this would authenticate the 
> packet using the PSK and would use the KDF to derive the 
> traffic key. The KDF would mix the nonce with the PSK in some 
> deterministic fashion. The receiver uses the derived traffic 
> key for signing all subsequent OSPF packets and would 
> indicate this by setting some bit (which says using traffic 
> key). It will also include its own nonce. The original sender 
> now uses the nonce that it receives and starts using the 
> traffic key derived from this nonce for all subsequent 
> packets. For a key rollover, the senders just have to choose 
> a new nonce value. This can be done as frequently as desired 
> and requires no manual intervention. 
> 
> Does this sound as going in the right direction?
> 
> Cheers, Manav
> 
> --
> Manav Bhatia,
> Service Router Product Group (SRPG)
> Alcatel-Lucent, India
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 14 Apr 2011 00:19:06 -0400

In message <[email-masked]>
> Can a variant of this method be used to protect OSPFv2 and OSPFv3-AT? 

Hesitant to say "me too" again for S/N reasons, but ...  yes/agree

Someone needs to write up the details though.  (and Manav seems
willing to volunteer).

Curtis

> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 14 Apr 2011 09:51:41 +0530

Curtis,

I can write a small ID explaining how this can be used for OSPF if folks 
believe this is something acceptable for doing key rollovers.

Cheers, Manav

On 4/14/2011 9:49 AM, Curtis Villamizar wrote:
>
> In message<[email-masked]>

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 14 Apr 2011 01:07:18 -0400

In message <[email-masked]>
Manav Bhatia writes:
>  
> Curtis,
>  
> I can write a small ID explaining how this can be used for OSPF if
> folks believe this is something acceptable for doing key rollovers.
>  
> Cheers, Manav

Manav,

You might want to say "for doing *session* key rollovers".  The
persistant key rollover would need a different mechanism.

Curtis

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 14 Apr 2011 10:40:26 +0530

Hi Curtis,

> 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

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Apr 2011 16:39:08 -0400

> Also note that the keys used in this proposal will not be symmetrical.

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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 16 Apr 2011 07:34:31 +0530

> old key is disabled and the process can be repeated later.

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