Authenticated Public NTP server howto

Configuring an NTP server is by far not the most strait forward nor best documenting activities while managing a data center. Adding authentication on top of it, just makes things worse, far worse. Fortunately, it’s something only done once.

The end goal: Authenticated NTP.

ntpdate -d -k /etc/ntp.keys -a 10 your.ntpserver.com
 9 Jul 23:24:33 ntpdate[19359]: ntpdate [email protected] Fri May 28 01:20:57 UTC 2010 (1)
Looking for host your.ntpserver.com and service ntp
host found : 13.3.150.148
transmit(13.3.150.148)
receive(13.3.150.148)
receive: authentication passed


There are a few caveats as well: assymmetric authentication over NTP is effectively broken, from both security and usability perspectives. This assymmetric authentication relies on the authentication of both server and client, which also means that not only all clients needs to have the server certificate, as obvious, but also the server needs to have certificates from all clients. This completely kills the usage of assymmetric authentication with mass availability. Also, those certificates do not abides to any standard, such as X509 or SSL, and only lasts for 365 days.

If you look at the documentation thoroughly, one can understand this is targeted at comunications between low stratum servers, and from this perspective it’s not completely senseless. But, for anything else, it doesn’t work.

There’s another authentication method, which is daily equivalent in terms of security but it improves on the usability front: symmetric authentication. As usual, symmetric authentication relies on a shared secret which is present on both server and client. Here one can correctly assume a very limited number use cases for this, and it’s mostly limited to one: a secure NTP server providing time to a big number of secure end devices. Obviously, this does not apply to PCs nor smartphones, but it fits perfectly to some embedded devices.

In order to overcome all the issues above, a new standard, Authenticated NTP, based on SSL certificates is on the way, but it’s still years away. It creates some ambiguity on having SSL certificates being validated by SSL certificates, but at the end one needs to start somewhere. It already happens today with Root SSL certificates and PGP keys. However, this is still science fiction.

Why authenticate NTP?

Most people, and by most I mean, including IT and engineering staff included, won’t consider NTP as the first line of any security infrastructure, but just consider this: certificates, either SSL, PGP, all depend on it for validity check.

Secrecy and security have relied on the difficulty of discovering a secret key, which shall be computationally difficult by the time the certificate is created. This means a certificate created while PCs were based on Intel i486 DX2 were not the same as today, however, one can easily and quickly break on of those today. To start with, key lengths were relatively small, in order to be usable by most PCs at the time. Then, safe algorithms weren’t safe as thought then, but no one knew that until a few years later.

Looking at some years in the past, certificates created with 56bit DES keys or signed with MD5 , were a common thing. Nowadays, finding a valid MD5 collision takes less than a second, and cracking a 56-bit DES key in a matter of minutes, so for sure no such of those certificates are in use today. The point is: how does a how knowns a specific certificate is no longer valid, due to out of date security? Simple: it validates both “Not valid before” and  “Not valid after” fields. Now, if an attacker gets a copy of an old certificate, one created with those old methods, it is able to generate another certificate, with the attacker’s data and make the victim use it. Then, the only thing left if for the attacker to take control of the victim’s clock, for instance, by messing with the victim’s NTP server, then the victim is completely defenceless. This is how important is to have an authenticated clock.