[ntp:questions] pool.ntp.org and authentication
nomail at example.com
Tue Dec 16 10:13:43 UTC 2014
Miroslav Lichvar <mlichvar at redhat.com> wrote:
> On Tue, Dec 16, 2014 at 05:43:59AM +0000, Harlan Stenn wrote:
>> d_anderson writes:
>> > Thanks! I quickly skimmed through the document, and I think I am
>> > asking the wrong questions..
>> I've been trying to think of good reasons to authenticate pool servers
>> and I haven't come up with any good ones yet.
> Protection against MITM attacks?
> Of course, with a public pool like pool.ntp.org an attacker could join
> it with a number of his NTP servers, get their certificates signed and
> serve whatever he wants, no need for a MITM. Even if DNS was secure
> and all clients were configured to use four pool servers, the pool DNS
> server would not likely be able to prevent some clients getting three
> bad servers outvoting the fourth server.
> But I think it would still be a significant improvement in security.
> The NTS draft says the scheme is not applicable to pools. I'm
> wondering what would be needed to make it applicable.
Just like a certificate on a website tells absolutely nothing about
the quality of the content of the website, so does a certificate on
an NTP server. It tells you who applied for the certificate, not
what quality they are serving.
In the NTP pool the servers are only put in the DNS when the monitoring
system considers the time returned from that server sufficiently reliable.
But the server can easily separate the queries from the monitoring system
from the queries by the clients they want to mislead, so it is trivial
to keep the servers in the pool while returning wrong time to others.
Authentication does absolutely nothing to solve that. It could be
alleviated by "cloud monitoring" of the servers. E.g. code could be added
in ntpd so each NTP pool server using that code version also monitors
some other servers in the pool (possibly a rotating set), and reports
its findings to the pool control server. That still would not prevent
targeted attacks to clients of which the IP address is fixed and known
to the attackers, and known to be not in the NTP pool.
More information about the questions