Yo Hal! On Thu, 17 Jan 2019 15:54:28 -0800 Hal Murray via devel <devel@ntpsec.org> wrote:
> The NTP-server to NTS-KE-server is complicated. Gary has proposed no
> connection, start with the shared key in a file and keep the keys in
> sync by running the same update on both ends. I think that could be
> made to work, but I'd prefer a connection.
Correction: I have made no recommendation, just noted at least two
ways exist to get the initial shared master key.
At least initially putting the shared key on a file is a bootstrap
to a full connection.
> A connection handles the case of multiple NTP servers for a single
> NTS-KE server and sets things up for the case of multiple NTS-KE
> servers for the same name.
And maybe more. Maybe not.
> With a connection, we could avoid storing the master keys on disk.
Nope. The last thing you want when you reboot a data center is for
all the NTPD to contact the one NTS-KE for new keys.
> Clients would have to rekey if the system rebooted.
Whcih also creates another rush. Modern data center design is to
minimize initial setups as much as possible.
> We could restart
> NTP-server or NTS-KE-server as long as the other end stayed up and we
> arranged to send the keys in both directions.
well, you sorta need a key to do that, right? Seems circular...
> There is another problem area: who makes the initial certificates.
Lets Encrypt, or similar.
> If the NTS-KE server makes them, then the admin has to keep the
> NTS-KE server and NTP server in sync.
A bad idea.
> If the NTS-KE server gets them
> from the NTP-server, then we need a working connection from NTS-KE
> server to NTP-server in order for a NTP-client to get started.
Also a bad idea.
> I think the common case of both on the same system should be OK. If
> the NTS-KE-server can't connect to the NTP-server the NTP-client
> probably can't either. I haven't thought much about more complicated
> configurations.
I think the NTPD should initiate communications to the NTS-KE.
> > Delta will need an IANA public port assignment.
>
> The NTP port is assigned and unused for TCP. I've been assuming that
> we will use that until somebody says otherwise.
The Proposed RFC saya otherwise.
> > I'm leaning towards an organization in which the NTS client code
> > lives inside ntpd; this would reduce deployment friction slightly.
> > Is there any scenario in which we'd want to run these pieces on
> > different hosts?
>
> Seems reasonable. It might be nice to have them as separate programs
> until we get things going. For example, we could write hack
> debugging programs to act as fake NTP or NTS-KE clients to figure out
> what the other end is doing and/or poke particular cases.
I don't see how a single NTS-KE/NTPD daemon prevents that. Like gpsd,
just have the test clients link into the main ntpd library.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
pgpM2Wb4GUo6j.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
