NTS: config and initialization

Hal Murray hmurray at megapathdsl.net
Fri Mar 8 23:17:40 UTC 2019


Gary said:
>>  So maybe master.keys?
> Works for me.  Hal?

Seems misleading to me.  There is nothing master-ish about it.  It only lets 
you unlock a subset of the cookies associated with a single system.

> I care to reduce the vocabulary, and to make the vocabulary match the
> Proposed RFC. 

Master isn't used in the draft.  The terms in the draft are K and I.

How about K-I.keys


> Uh, say what?  How/when/where does ntpd create the master keys?  I thought
> those were an input.  At least the initial master key(s). 

Nope.  ntpd makes up the keys, writes them to disk, and reloads them on 
restart.

There is a proposal, hinted at in the draft and clarified in a message from 
Daniel to derive successive keys with a ratchet algorithm.  The idea is that a 
NTS-KE server could support a cluster/pool by getting copies of the 
whatever-they-are-called files from the NTP servers it supports.  It could run 
the same ratchet algorithm so it could make cookies without needing to consult 
the server it picked.  (The cluster server would have a file per server.)  You 
could reverse it and have the NTS-KE server make the file and send it to the 
NTP server.

Plan B is to extend the NTS-KE protocol slightly to handle the cluster/pool 
case.  The individual NTP servers in the cluster/pool would also run a NTS-KE 
server.  The NTS-KE server for the cluster/pool would relay the KE request to 
the selected server.  The protocol would have to be extended to include C2S 
and S2C.



-- 
These are my opinions.  I hate spam.





More information about the devel mailing list