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

In message <4DA67655.10301@alcatel-lucent.com>
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<7C362EEF9C7896468B36C9B79200D8350CFD0DE257@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: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On
> >>> Behalf Of Bhatia, Manav (Manav)
> >>> Sent: Thursday, April 14, 2011 5.18 AM
> >>> To: karp@ietf.org
> >>> 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
> >>> karp@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/karp
> >>>
> >> _______________________________________________
> >> OSPF mailing list
> >> OSPF@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ospf