[Babel-users] HMAC Key rotation key format (was ripemd)

Dave Taht dave.taht at gmail.com
Mon Nov 26 22:03:53 GMT 2018


On Mon, Nov 26, 2018 at 1:10 PM Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>
> Dave Taht <dave.taht at gmail.com> writes:
>
> > To me this leaves the biggest problem remaining is key rotation. Me
> > being me, and remembering just how hard it was to get dnssec working
> > on systems lacking reliable time,
>
> The Babel HMAC extension as currently specified does not rely on wall
> clock time in any way, so not really sure how a comparison to dnssec is
> relevant?

More below. Relative time is ok, too. 3000 seconds from now, start
rolling over. Stop signing records with the old key as soon as
everyone you can currently hear uses the new key, 6000 seconds from
now, retire the old key unconditionally.

> > Setting that aside for the moment, having a standardized file format
> > for babel keys would be a boon and boost interoperability between
> > bird/babel and other possible implementations.
>
> From the point of view of each routing daemon this would just make Babel
> a special snowflake.

ok. That leaves how to get new keys into nodes running different
daemons. Anyone for IKEv2?

My out of bound way is via scp and ssh.

Also the present babeld cannot rewrite it's entire config file (so far
as I know). I think bird can... but I don't trust it.

As for the key format, I wanted a way to test keys and key rollover in
the existing daemons to verify this bit would work, and also measure
the cpu overhead and failure modes, like those I describe below.

> What we can do is to specify the format in the information model if a
> cross-implementation format is really needed (which I'm not really
> convinced of, either)...

To quote from appendix A:

"In order to perform key rotation, the new key is added to all the
nodes; once this is done, both the old and the new key are sent in all
packets, and packets are accepted if they are properly signed by
either of the keys. At that point, the old key is removed."

My key points made here are "the new key is added to *all* the
nodes"... which may or may not be up over the course of days, or weeks
for whatever definition of "all" you have ... "Once this is done" -
how can you tell? -  "and packets are accepted if they are properly
signed by either of the keys" hopefully you log this ... "the old key
is removed".

perhaps "deprecated, no longer actively used for signing, then removed
after a suitable period"?

So, if you do a key rotation and X routers are offline or inaccessible
at that particular time... they are going to stay inaccessible
forevermore, unless rekey'd via sneakernet, climbing on trees, and
other forms of manual intervention.

The case where you want to immediately remove a key is in the event of
a security breach.


I tried to use the example of dnssec as one way key rotation (on
admittedly a much bigger scale) that got done right, but the new keys
were distributed a good year beforehand.

https://kb.isc.org/docs/aa-00822

...

also "old and new key are sent" should be "old & new keys are used for signing".

...

>
> -Toke



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740



More information about the Babel-users mailing list