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

[Markus Stenberg]

For interconnected domains and whatever, I would rather just use DTLS with 
relatively shortlived and auto-renewed certs (real-time revocation is hard to 
do if you are authenticating routing - chicken 'n' egg problem; one alternative 
is of course some sort of manual blacklisting if you want to go with long-lived 
certs).  

If HNCP is in picture, DNCP trust based consensus model is also an option - 
with it, (self-signed) certificates can have long lifetime as their usefulness 
is determined by consensus of nodes -> as long as there's only few compromised 
nodes, you can blacklist them in real time if you control the rest of the nodes.

Cheers,

-Markus


___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users

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

[Juliusz Chroboczek]

> FWIW, for homenet the thought was to use HNCP to distribute keys amongst
> routers.

HNCP is not a good choice for symmetric key distribution, since it floods
all information across the HNCP domain.  It's impossible to use HNCP to
distribute a key to some routers only while keeping it secret from others.

-- 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] [babel] HMAC Key rotation key format (was ripemd)

[Ted Lemon]

On Thu, Nov 29, 2018 at 1:14 AM Dave Taht  wrote:

> Mahesh Jethanandani  writes:
> > A draft that proposed pair-wise key management was proposed here. It
> > does not address the question of timestamp, but is something that
> > could be exchanged as part of key rollover to allow routers to
> > calculate the delta. Including the original authors of the draft.
>
> I'm sorry but adding this level of complexity is not in the cards
> from my perspective. Layering key exchange over a different out of band
> medium, being a slip of paper, a telephone call, ssh or https seems
> saner.


FWIW, for homenet the thought was to use HNCP to distribute keys amongst
routers.   This doesn't solve the general problem, but illustrates your
point, Dave, that this is something that can be provisioned out of band.
(In the HNCP case we're talking about public keys for DTLS, not shared
secrets, of course).   This seems like a better choice than a complicated
pairwise key management strategy for HMAC.
___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users

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

[Dave Taht]

Mahesh Jethanandani  writes:

> A draft that proposed pair-wise key management was proposed here. It
> does not address the question of timestamp, but is something that
> could be exchanged as part of key rollover to allow routers to
> calculate the delta. Including the original authors of the draft.

I'm sorry but adding this level of complexity is not in the cards
from my perspective. Layering key exchange over a different out of band
medium, being a slip of paper, a telephone call, ssh or https seems
saner.

>
> On Nov 26, 2018, at 6:21 AM, Dave Taht 
> wrote:
>
> 
> 
> 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,
> I worry about that part. What we settled on for dnsmasq-dnssec was
> to
> write the current time to flash every day (or few hours), boot up
> without dnssec enabled long enough to
> get an ntp server... and rely on key rollover taking hours or days
> to
> *usually* get a correct result. RTCs with batteries are usually
> not
> included.
> 
> that's still fragile (imagine a power failure lasting days, or a
> box
> being down for several days for repair. It happens).
> 
> In the case of routing... if you don't have the correct time...
> and
> you can't get a route so you can get the correct time from ntp...
> then
> what? Do we make GPSes MTI also?
> 
> 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.
> You would merely declare a key name in the main conf for bird or
> babel, and reference it in a separate file with a format like
> this:
> 
> KEY START_DATE END_DATE TYPE VALUE
> name\wrfc3339\wrfc3339\wsha256|blake2s\wvalue
> 
> https://tools.ietf.org/html/rfc3339
> 
> administrators would push out this one standard format file to
> routers, strongly suggesting that UTC times be used universally
> and
> that key rollover should be staged over hours or days lest
> connectivity be lost. Other sanity checks like ensuring there is
> some
> form of persistent and correct time on routers using
> authentication
> are also needed.
> 
> alternatives might include certs and other stuff that bears
> drinking about.
> 
> 
> 
> 
> -- 
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
> 
> ___
> babel mailing list
> ba...@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
> 
>
> Mahesh Jethanandani
> mjethanand...@gmail.com
>
>
> ___
> 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] [babel] HMAC Key rotation key format (was ripemd)

[Mahesh Jethanandani]

A draft that proposed pair-wise key management was proposed here 
.  It does not address 
the question of timestamp, but is something that could be exchanged as part of 
key rollover to allow routers to calculate the delta. Including the original 
authors of the draft.

> On Nov 26, 2018, at 6:21 AM, Dave Taht  wrote:
> 
> 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,
> I worry about that part. What we settled on for dnsmasq-dnssec was to
> write the current time to flash every day (or few hours), boot up
> without dnssec enabled long enough to
> get an ntp server... and rely on key rollover taking hours or days to
> *usually* get a correct result. RTCs with batteries are usually not
> included.
> 
> that's still fragile (imagine a power failure lasting days, or a box
> being down for several days for repair. It happens).
> 
> In the case of routing... if you don't have the correct time... and
> you can't get a route so you can get the correct time from ntp... then
> what? Do we make GPSes MTI also?
> 
> 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.
> You would merely declare a key name in the main conf for bird or
> babel, and reference it in a separate file with a format like this:
> 
> KEY  START_DATE END_DATE TYPE VALUE
> name\wrfc3339\wrfc3339\wsha256|blake2s\wvalue
> 
> https://tools.ietf.org/html/rfc3339
> 
> administrators would push out this one standard format file to
> routers, strongly suggesting that UTC times be used universally and
> that key rollover should be staged over hours or days lest
> connectivity be lost. Other sanity checks like ensuring there is some
> form of persistent and correct time on routers using authentication
> are also needed.
> 
> alternatives might include certs and other stuff that bears drinking about.
> 
> 
> 
> 
> -- 
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
> 
> ___
> babel mailing list
> ba...@ietf.org
> https://www.ietf.org/mailman/listinfo/babel

Mahesh Jethanandani
mjethanand...@gmail.com



___
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users