Purpose of 'generate from/to' and 'accept from/to' for passwords?
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
On Mon, Jan 20, 2020 at 05:27:34PM +0100, Toke Høiland-Jørgensen wrote:
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?
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: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Ondrej Zajicek -
Toke Høiland-Jørgensen