Subject: [babel] key rotation take #2

From: Dave Taht <[email-masked]>
Date: Wed, 28 Nov 2018 02:06:22 -0800

OK, nobody liked timestamps and the dnssec analogy, nor standardizing on
an easily distributable out of band key format.

I can live with that.

However, what I would like to be doing is testing the key signing, and
rollover methods, and measuring the overhead of HMAC-ing twice, as well
as the effects (and bugs) on unicast and multicast transmissions and the
rollover process itself, and interoperability between bird and babel.

So here's a simpler alternate suggestion for configuring the the thing.
It is not intended as an ietf standard but as a means to deploy tests of
key rollovers.

This is the present babel conf file format:

key id key1 type sha1 value deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
key id key2 type sha1 value dea2f0d01a57b0071057a11da7adeadbeeffffff
default enable-timestamps true unicast true hmac key1
interface enp7s0 unicast false hmac key1
interface wlps3 type wireless
interface enp4s0
interface wg1 hmac key2

so we invent a new keyword "serial".

a key rollover is initiated by adding a new key with the same name and a
larger serial number than the old one.

A key id line with no serial keyword has an implied serial number of 0.

A new line gets added (via conf or configuration interface) that looks
like this:

key id key2 type blake2s serial 1 value dea2f0d01a57b0071057a11da7adeadbeefffff0

*the protocol* retires the old key as soon as possible.

the admin removes the old key when convenient and safe to do so.

Does that work for everybody?

PS it would be mildly more compact to use
base64 to encode the key.

/me hides

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 28 Nov 2018 13:09:05 +0100

> so we invent a new keyword "serial".

So what you're trying to express here is the notion of a "receive-only"
key that is not used for signing outgoing packets, right? If so, I think
it would be better to express that explicitly as a property of the key
config that can be changed on a per-key basis. For one thing, 'serial'
is misleading as it sounds like something that affects the wire format,
and for another with your proposal it becomes difficult to re-instate a
previously retired key (say, if you want to restore connectivity to an
old router that dropped off while you were changing keys).

-Toke

---

From: Dave Taht <[email-masked]>
Date: Wed, 28 Nov 2018 08:31:05 -0800

Toke Høiland-Jørgensen <[email-masked]> writes:

> key that is not used for signing outgoing packets, right?

No... the old key is retired from active use in the protocol after
concensus is achieved on the new key by the protocol, and not used again
unless a router comes up with an unreadable hmac. In that case we go
back to at least trying to verify (periodically?) that it's not using
the old key (if we still have it around) and if it's using the old key,
we go back to signing stuff with that key.

Does that concept need to be in the protocol spec?

>If so, I think

Mmmm... I would say that I'm trying to institute key rollover on an
unreliable not-always fully connected network that may or may not be
under attack.

As one example, I have a rogue AP on the network right now. I can't
get into it, nor can I physically find it, but it's exchanging routes. I
can block the routerid on the devices that can hear it via changing the
conf file on the devices that can hear it, but it's "loud" so as fast as
I get rid of the closer machines that can hear it, others pick it up.

Another worse case scenario is that it's announcing routes to 8.8.8.8
with a metric of zero, and also ping flooding the network probing for
every address in the 10.0.0.0/8 range, and every time I try to block the
routerid, it changes. In this case you'd want to add a new key, and
retire the old one as fast as possible, but that's only "as possible".

...

I don't know if you've been in a world where every keystroke takes 10
seconds to transmit, but I have some horror stories that oft require
beer to tell. One attack (in 2004) literally melted down the
switch... the QA team deployed 60? windows virtual machines - fresh
installs - virgins - no anti-virus or upgrades installed - and unbnownst
to my team a worm was already loose on one machine on that
network. Inside of 10 minutes it had grabbed all 60 vms, and it was on a
10 network, and thus every machine started probing the entire /8... and
doing a DOS on every machine it could find - which included those vms -
the carnage proceeded until the switch overheated and failed
overnight. 3AM, we blindly replaced the switch only to see all
the lights go solid again. It's not obvious you're under attack at that
point (things like broadcast storms we explored first), and it wasn't
until the QA guy responsible wandered in at noon wondering why it was
taking 10 seconds for each keystroke to get through to his shiny new QA
network that light dawned on us... "You did *what*???"

> is misleading as it sounds like something that affects the wire

OK. how about "new" and "old" as keywords? That implies two states and
two states only. I liked 0 and X as numbers, so long as the ascending
property is maintained. As for why not 0 and 1, see below.

Totally open to bikeshedding the name. :) babeltowerno? 

> old router that dropped off while you were changing keys).

No it doesn't. you just would reinstate the prior key with the smaller
serial number. Or if you've gone back to 0 for it you increment the
current key to 1 and then put in the 0th one.

another use case:

I have 6 campus routers in the lab that are not powered on right now,
pending a reflash with the latest stuff. Worse, they used to be
connected to a far-off portion of the network and when I bring them up,
they start announcing routes to that bit (and the longer prefixes
overall mean they end up being my default route to the rest of the
campus network, over a really crappy link going from the basement to the
roof).

I do a key upgrade throughout the net and they can no longer do any
harm, and can deal with each via a dedicated reconfiguration router
that filters them out before they hit the rest of the net. Yea!

Over time I'll end up with a file full of retired keys.

(there are still 20+ machines not powered up in the lab and the rest are
being donated to charity)

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 28 Nov 2018 21:23:46 +0100

Dave Taht <[email-masked]> writes:

> concensus is achieved on the new key by the protocol, and not used
> again unless a router comes up with an unreadable hmac. In that case
> we go back to at least trying to verify (periodically?) that it's not
> using the old key (if we still have it around) and if it's using the
> old key, we go back to signing stuff with that key.
>

This reads to me like a specific operational procedure for deployment;
don't think that should go into the spec, no.

> Totally open to bikeshedding the name. :) babeltowerno?

Don't care what they are called. My point is just that it's a property
of a particular key.

Bird already has this, BTW: each key can be set to "generate" signatures
and "accept" signatures, where the former puts them on the wire, and the
latter will accept packets signed with that key. You can set time ranges
for each or both. See
https://bird.network.cz/?get_doc&v=20&f=bird-3.html (search for
"password option"). The Babel HMAC implementation inherits this.

-Toke

---

From: Dave Taht <[email-masked]>
Date: Wed, 28 Nov 2018 13:03:55 -0800

> "password option"). The Babel HMAC implementation inherits this.

That is essentially my first proposal... in bird syntax. :) Aside from
needing good time, there are really good reasons to stage key
rotations that way....

while the odds are much better that a boot/bootstrapping bird router
has a working rtc, your typical home router doesn't.

>
> -Toke
>
> _______________________________________________
> Babel-users mailing list
> [email-masked]
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users

-- 

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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 28 Nov 2018 22:19:41 +0100

> has a working rtc, your typical home router doesn't.

No, but you can use the mechanism without the timeouts to mark keys as
active/passive using whatever provisioning system you are using to
distribute the keys (just use "{generate,accept} from 1970-01-01").

-Toke