The key-manahement argument
Hal Murray
hmurray at megapathdsl.net
Sat Jan 19 11:10:21 UTC 2019
Richard Laager said:
> * Is NTPsec going to use the suggested cookie format?
Sure, but it isn't a detailed spec.
>* Is NTPsec going to force C2S/S2C key rollover (e.g. by adding an
> expiration time to its cookie format) or leave expiration to clients?
Maybe, but not initially. We need a crypto geek to tell us how much we can
safely encrypt and/or authenticate so we can translate that back to packets.
> * How is NTPsec going to handle key expiration when it is the client?
I assume you are talking about K, the server master key.
The normal case is easy. The client doesn't have to do anything because the
server supports both the current K and the previous 1 (or 2?).
For something like a laptop that goes to sleep for a week, the server will
send a KoD and the client will rekey via NTS-KE.
> * What configuration options will be provided for each piece?
The server needs a file name for the master keys and maybe a flag to start the
NTS-KE server.
The client needs a new option on the server line.
> * Is NTPsec going to initiate NTS by default?
Probably not. That would break backward compatibility.
> I've taken a stab at a bunch of edits:
Thanks.
--
These are my opinions. I hate spam.
More information about the devel
mailing list