Subject: [Ntp] 9.3. Usage of NTP pools

From: Ask Bjørn Hansen <[email-masked]>
Date: Sun, 3 Sep 2017 20:09:24 -0700

I sent this earlier in the week, but it doesn’t seem like it made to it to the list.

[ Speaking as the NTP Pool maintainer and not for anyone or anything else ]

> 9.3.  Usage of NTP pools
> 
>  Additional standardization work and infrastructure development is
>  necessary before NTS can be used with public NTP server pools.
>  First, a scheme needs to be specified for determining what
>  constitutes an acceptable certificate for a pool server, such as
>  establishing a value required to be contained in its Extended Key
>  Usage attribute, and how to determine, given the DNS name of a pool,
>  what Subject Alternative Name to expect in the certificates of its
>  members.

I don’t think there’s a practical way to manage thousands of independently run servers all using the same (set of) “pool-domain(s)” and gain any new security benefits.

If NTP clients supported SRV records there could be a scheme for a pool to “delegate” serving time, including the name, so

 pool.example.com SRV 10 0 123 some.server.example.org.
 pool.example.com SRV 10 0 123 another.example.net.

would have the client talk to some.server.example.org and another.example.com expecting those names in the certificates rather than pool.example.com. (This assumes DNSSEC for pool.example.com to make sense).

It’d be better than a large number of servers all having the same certificate in that an attacker can’t just MITM with a valid certificate, but also have to get the client to want to talk to that particular server (versus any server in pool system).

(I don’t think I explained that idea very well).

>  A more important matter, however, is that pool operators
>  need procedures for establishing and maintaining trust in their
>  members.  Pools in existence as of 2017 are volunteer-run, with
>  minimal requirements for admission and no organized effort to monitor
>  pool servers for misbehavior.

Assuming this is referring to the ntppool.org / www.pool.ntp.org system this is either very vague or incorrect.

I’m not sure what work would be considered an “organized effort to monitor”, but the NTP Pool system does monitor the time accuracy, leap second flags and other attributes of all the servers. We also regularly work with researchers and others to do other “diagnostics” across the system.

(Of course nothing is to stop a server operator from targeting specific source IPs for “bad time”, but from the data I have the average pool server behaves as well or better as any other average public NTP server, including various national “time references”[1]).

I’d suggest the last sentence above and the next below either be taken out or be rewritten with a section of what the requirements for monitoring misbehavior should be, in the editors opinion (though that seems out of scope).

>  Without any sort of policing in place,
>  there is nothing to prevent an adversary from going through normal
>  channels to obtain a valid certificate for participation in a pool
>  and then proceeding to serve maliciously inaccurate time.

For an attacker with a specific target in mind the protection against this is the client being conservative about what it believes and using multiple servers. My suggested scheme above would make it harder to take over all the NTP traffic for a target and easier for the client to exclude the malicious servers.

Ask

[1] We’ve noticed national time references being overloaded, have incorrect leap second flags, generally be in-accurate, etc etc. Generalized slightly, deployed time keeping and NTP implementations and the quality of the operations of them are not very good.

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Sun, 3 Sep 2017 20:09:24 -0700

Ask