> * Henning Brauer <hb-openbsdt...@ml.bsws.de> [2015-02-10 13:21]: > > * Kevin Chadwick <ma1l1i...@yahoo.co.uk> [2015-02-10 13:14]: > > > On Tue, 10 Feb 2015 10:55:53 +0100 > > > Reyk Floeter wrote: > > > > The standardized attempts to add authentication to NTP are a) fairly > > > > horrible (ASN.1 etc.) and b) rarely deployed. > > > When ntpd acts as a server, could the package signing code be of use > > > with ntpd keys? > > getting the signature into the ntp packets in a way that doesn't break > > compatibility is the challenge. > > let me elaborate slightly: even if we came up with a überauth > mechanism that doesn't suck and doesn't break compat, it wouldn't be > of much use unless the servers you sync from support it - one of the > pools for most. even if you could completely trust them and whatever > model of key distribution, for them to support this, you have to get it > standarized. and even if we managed to get it pushed through the > standards corpses^Wbodies, it would take ages until it gets deployed, > IF it ever gets widely deployed. > That's a lot of ifs, I leave the judgement on likeliness to you. > > constraints from https, however - that works today.
So full disclosure, this was my idea, though Reyk wrote the code. I was struck by how 2 decades ago there was common practice to use "rdate -a", thus using the RFC 868 timed protocol. It is a one-shot, triggering a slide using the kernel adjtime system call. Then ntp showed up, kind of but it was heavy, and it became more common practice to have small machines do rdate -an. Once again, it is a one-shot, triggering a slide using the kernel adjtime system call. Such practice was good enough for most uses. Some people did this in cron. ntp was just too large to compile, too complicated for automatic setup, so it was rarely used back in those days. Some time went by, and more people started using official NTP, but we wavered, not liking the sourc code. Finally openntpd arrived, designed to be light and secure -- enough so we could run it in all circumstances. It contains protection against NTP packet spoofing, but cannot solve the NTP protocol MITM problems. Recently, tlsdate showed up, which is basically rdate -TLS, and perhaps it has an option like "-a", but still that would be the one-shot triggering a slide in the kernel. Solving nothing new really in terms of time quality... However it struck me that we could use such a method to authenticate information learned from NTP sources. As long as the information was handled correctly in one daemon. Asyncronously, and very carefully, using the privsep model for safety. So I gave Reyk some beer, and he did the impossible :-)
