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<7c362eef9c7896468b36c9b79200d8350cfd0de...@inbansxchmbsa1.in.alcatel-lucent.com>
"Bhatia, Manav (Manav)" writes:
OSPFers,
Can a variant of this method be used to protect OSPFv2 and OSPFv3-AT?
Cheers, Manav
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
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Bhatia, Manav (Manav)
Sent: Thursday, April 14, 2011 5.18 AM
To: [email protected]
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 protected]
https://www.ietf.org/mailman/listinfo/karp
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
