Eric said: > Trying to change that by breaking out a separate NTS-KE server would > introduce a lot of complexity when we could achieve the same result by > pointing the ntpd instances at a common key on a fileshare.
That adds the fileshare to the security tangle and probably complicates the startup dance. > If you don't trust that your LAN is secured enough to do that, you can't > trust it enough to pass NTS-KE traffic over it either. Huh? The NTS-KE traffic in encrypted by TLS. ------- > I now think this plan is a mistake and that Hal did the right thing by > building key service into ntpd itself. I could see all the pieces and how they fit together. (and I didn't have to write the code to read K/I from the disk to get started). The server side of NTS-KE is not very complicated. A stand alone server would be simple. 173 553 4497 ntpd/nts.c 494 1561 14317 ntpd/nts_client.c 242 783 5713 ntpd/nts_cookie.c 238 761 5610 ntpd/nts_cookie.cc 415 1295 11866 ntpd/nts_extens.c 414 1247 11905 ntpd/nts_server.c 1976 6200 53908 total The client and extens are not needed for a NTS-KE server. It is not tightly tangled with ntpd. It needs msyslog and a bit of initialization. The hard part would be coordinating K/I with the ntp servers. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
