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