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