Re: [Babel-users] HMAC Key rotation key format (was ripemd)
On Sun, Dec 2, 2018 at 2:19 PM Juliusz Chroboczek wrote: > > > 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. > > Have you looked at RFC 7210? > > -- Juliusz https://xkcd.com/927/ It is evident (now!) that my conception of these conceptions was different than the homenet starting point. I envisioned lots and lots of keys interconnecting a multitude of networks, where the design as stands is oriented towards securing a single domain. further, I've learned now, dtls would be a better interconnect, and considering how to do that well might factor in the above standard. I would still rather like to be able to test key rollover by christmas! -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] HMAC Key rotation key format (was ripemd)
> 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. Have you looked at RFC 7210? -- Juliusz ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] HMAC Key rotation key format (was ripemd)
Maybe I'm misunderstanding, but I think this issue is not comparable to DNSSEC. The key difference here (no pun intended) is that you can operate Babel-HMAC with multiple keys at the same time. So your rollover becomes a simple two step process: 0) all routers are functioning with OLD_KEY configured 1) go into all routers one by one and configure them to use both OLD_KEY and NEW_KEY 2) go into all routers one by one and configure them to only use NEW_KEY 3) profit You don't need any notion of time, or any added complexity to the spec. If some of the routers are down during step (1), you get to decide whether to either wait for them to come back, or skip them and effectively disconnect them from the network based on the urgency of your key rollover. Anything beyond that becomes a key management problem that is specific to your deployment, not to the routing protocol you use. On Mon, Nov 26, 2018 at 2:22 PM Toke Høiland-Jørgensen wrote: > Dave Taht writes: > > > On Mon, Nov 26, 2018 at 1:10 PM Toke Høiland-Jørgensen > wrote: > >> > >> Dave Taht 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. > > Well, you would handle this by whatever mechanism you use to configure > your routers in the first place... > > >> > 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. > > I think Juliusz' insistence that we shouldn't reinvent key distribution > is wise. See above; you need to configure the daemons in the first place > anyway... > > > Also the present babeld cannot rewrite it's entire config file (so far > > as I know). I think bird can... > > > Yup, a 'bird reconfigure' will re-read the entire config file and apply > it if it parses successfully. > > > but I don't trust it. > > Your trust issues are probably best resolved between you and your daemon ;) > > >> 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"? > > Hmm, having a way to mark a key as "verify only" may be useful for > simpler monitoring. But really, you *could* derive the same information > from the opposite bit (track how many neighbours don't sign with the new > key yet). So then it becomes more of an efficiency issue (you could save > one signature on the wire during rotation). Not sure if it's worth > specifying another bit in the spec for this? Or if such a configuration > mode should even be in the spec at all? > > > 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. > > Presumably your key rotation policy would take into account the outage > schedules of the routers in your network? :) > > -Toke > > ___ > Babel-users mailing list > Babel-users@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] HMAC Key rotation key format (was ripemd)
Dave Taht writes: > On Mon, Nov 26, 2018 at 1:10 PM Toke Høiland-Jørgensen wrote: >> >> Dave Taht 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. Well, you would handle this by whatever mechanism you use to configure your routers in the first place... >> > 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. I think Juliusz' insistence that we shouldn't reinvent key distribution is wise. See above; you need to configure the daemons in the first place anyway... > Also the present babeld cannot rewrite it's entire config file (so far > as I know). I think bird can... Yup, a 'bird reconfigure' will re-read the entire config file and apply it if it parses successfully. > but I don't trust it. Your trust issues are probably best resolved between you and your daemon ;) >> 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"? Hmm, having a way to mark a key as "verify only" may be useful for simpler monitoring. But really, you *could* derive the same information from the opposite bit (track how many neighbours don't sign with the new key yet). So then it becomes more of an efficiency issue (you could save one signature on the wire during rotation). Not sure if it's worth specifying another bit in the spec for this? Or if such a configuration mode should even be in the spec at all? > 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. Presumably your key rotation policy would take into account the outage schedules of the routers in your network? :) -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] HMAC Key rotation key format (was ripemd)
On Mon, Nov 26, 2018 at 1:10 PM Toke Høiland-Jørgensen wrote: > > Dave Taht 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 ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
Re: [Babel-users] HMAC Key rotation key format (was ripemd)
Dave Taht 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? > 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. 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)... -Toke ___ Babel-users mailing list Babel-users@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
