Subject: [babel] Purpose of 'generate from/to' and 'accept from/to' for passwords?

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 20 Jan 2020 17:27:34 +0100

Hi Bird people

When specifying passwords for protocol authentication in the Bird
config, it is possible to specify time windows in which the password
will be used to sign messages (the 'generate from/to' configuration
options), and a separate time window in which that password will be
accepted to authenticate a packet (the 'accept from/to' options).

My question is this: What is the purpose of having these two time
intervals be separate? I.e., in what deployment scenario is it useful to
have a password be accepted to authenticate a message, without also
using that password to sign outgoing messages?

This question came out of a discussion around whether we should
standardise a similar feature in the Babel RFCs. As you can see I'm
struggling a little to come up with a definite use case:
https://mailarchive.ietf.org/arch/msg/babel/XOahz4fuXXs-nHO4NMGdBwU8AZo

-Toke

---

From: Ondrej Zajicek <[email-masked]>
Date: Mon, 20 Jan 2020 20:01:42 +0100

> using that password to sign outgoing messages?

Hi

Well, it is requirement of OSPF spec (RFC 2328). I could assume it could
help for smoother key transitions when clocks are not perfectly synchronized.

Personally, if i had to do key rotation, i would only use 'generate
from'.  As 'generate to' is implicit by presence of newer valid key and
'accept from/to' could be unlimited during transition, while key would be
removed later after transition.

For systems with dynamic key selections (in contrast to BIRD, where keys
are in config file), it would perhaps make sense to merge 'accept to'
with automatic removal of key from keylist.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: [email-masked])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 20 Jan 2020 21:26:39 +0100

Thanks, Ondrej.

> help for smoother key transitions when clocks are not perfectly synchronized.

Ah, I see.

OSPF only allows one key in the trailer, so it needs the ability to send
one key but accept many.  Babel-MAC allows multiple keys in the trailer,
and that ability is therefore not required.

Or am I missing something?

I have no objection to keeping the ability, since it's pretty trivial to
implement.  No objection to making it optional, since it's not
particularly useful in Babel-MAC.  No objection to removing it altogether,
since it's good to avoid unnecessary features.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 21 Jan 2020 14:37:35 +0100

> Or am I missing something?

No, I think you're right.

> since it's good to avoid unnecessary features.

Well, the Bird implementation (which I really should get around to
finishing) is going to re-use the existing config syntax, so that is
going to implement it in any case. I don't have any strong opinions as
to what the spec should say, as long as it doesn't forbid such an option :)

-Toke