In message <[email protected]> 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 > 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
