[ntp:questions] Authenticated time

Danny Mayer mayer at ntp.org
Thu Mar 3 19:18:20 UTC 2016

On 2/29/2016 3:20 AM, Juhasz Gabor wrote:
> Hi All,
> I am newbie in NTP world so it is possible that my question
> has been already answered. Sorry for it.
> The latest openNTP (openntpd-5.7p4) contains a very
> useful feature: CONSTRAINTS
> openntpd.conf.5:
> "openntpd(8) can be configured to query the ‘Date’ from trusted
> HTTPS servers via TLS. This time information is not used
> for precision but acts as an authenticated constraint, thereby
> reducing the impact of unauthenticated NTP man-in-the-middle
> attacks. Received NTP packets with time information falling
> outside of a range near the constraint will be discarded and
> such NTP servers will be marked as invalid."

RFC2616 Section 14.18 talks about the Date field in the http header.
What it does NOT guarantee is that the date is correct or valid for any
purpose. It does state that it is the date and time that the message was
originated but there is nothing to say that it is valid. Neither HTTPS
nor TLS guarantee that. In fact if the clock was off by 2 years, as long
as the relevant certificates in the certificate change were valid at
that time it would allow the TLS protocol to complete and you'd get that
date in the header. Not only that you have no idea how reliable it is,
how much jitter there is what the root delay or dispersion is, whether
it is coasting along or using a valid NTP server. Where does the trusted
part come from? This is one of those ideas that look good on the outside
but fail to solve the problem that you think you are solving. ntpd will
not let the clock move too far (except during startup if you override
the panic gate).

How will this proposal make ntpd better?


More information about the questions mailing list