5

I am doing some research in order to get an understanding of the security of the Network Time Protocol. In particular, my goal was/is to understand how the protocol is secured and what the issues are.

So far, I understood that there are basically 2 ways to secure NTP, in order to provide authentication (and integrity as well, since a MAC is used): via symmetric cryptography and via public key cryptography. However, for several reasons (that I do not list explicitly for the sake of space), these 2 measurements are often not used and therefore NTP is left unauthenticated. This leads to a series of issues in terms of security.

My question is: in practice, how often is NTP really subject to attack? I know that there is the possibility of both on-path and off-path attacks, and that some of them have been fixed (I mainly refer to the studies done by the Boston University research group). If it was so easy to hack a protocol like NTP, everyone would be messing up with applications relying on time (certificates etc.). From what I read, in general, it seems like in fact there are not so many attacks available on NTP, although most of the times the protocol is not secured. The only exception seems to be DDoS attacks (such as amplification and reflection attacks), for which there are not so many solutions. Did I get this right or am I missing something important from the big picture?

Another question: why only recently some new solutions have been proposed? I am referring mainly to the Network Time Security specification (pdf) to secure NTP, which was also presented at Real World Cryptography Conference 2017 by one of the authors of the IETF draft (Daniel Franke). What I have been wondering is whether this solution would really provide something useful, since people keep using NTP without authentication and they do not seem to worry too much about it.

I hope my question was clear.

Xander
  • 35,525
  • 27
  • 113
  • 141
Mark
  • 159
  • 1
  • 1
    Now, when you have mentioned it, I wonder flooding NTP might actually bring desynchronization between different machines on network thereby, disabling their ability to communicate. But does this even work in real world? – Panda Apr 04 '17 at 00:32
  • 2
    I think the short answer is that correct time, in general, isn't particularly critical for most applications. If it is, you can pretty easily enable the authentication and integrity features. Also, NTP endpoints themselves ignore large inaccuracies in time. Not because they think they're malicious, but because they're likely wrong. So you can't just simply set someones clock to 1989 with a MiTM attack. The best you could achieve is likely slew the clock a few seconds/minutes over a few days/weeks. – Steve Sether Apr 04 '17 at 04:03
  • I have another question: I often read that a problem of the NTP public cryptography authentication (Autokey) is that it has no root of trust, and therefore an attacker can simply set up his/her NTP server and send wrong time to users. Is this really an issue? I mean, NTP is often auto-configured by the operating system, and even if someone has to configure it manually there are pools of servers that should be trustable. For instance: http://www.pool.ntp.org/zone/it . Am I missing something, or what they say about the "no root of trust issue" is in fact not that big issue? – Mark Apr 04 '17 at 11:37
  • I'm not an expert on NTP authentication, but in general I believe people setup their own authentication for their own infra-structure. So you'd create your own public/private key, install it on your own trusted NTP server synced to GPS or some other stratum 0 source, and install the public keys on clients. But I'm not exactly an expert on NTP, so don't take this as gospel. – Steve Sether Apr 04 '17 at 17:37

1 Answers1

1

For most people in most applications, highly accurate local time is not of the essence. There are two broad categories for the exceptions:

  • Certificate Authorities, nonrepudiation systems, financial controls and others need to make sure that the time of an event as reflects the real-world time is accurately recorded, assuring integrity, but not to very precise tolerances (outside HFT)
  • Authentication systems, key exchange mechanisms and other temporary interactions involving authentication are concerned with protecting against replay attacks and use the concept of "now" to achieve this, while not being terribly concerned when "now" really is, only that it's not being replayed from "then".

Even inside these categories, unless there are legal or safety consequences for a lack of accuracy or synchronisation with the outside world, there is either a wide tolerance of drifts/disagreements among parties (eg most authentication survive can survive of seconds to minutes) or a simple requirement that, while the time is not completely accurate against the outside world, then at least that all parties agree on their own representation of the time (eg all log events exactly 1.522 seconds late are still correctly ordered).

Mostly, attacks require at least the server, if not both ends of the connection to have compromised time, and good monitoring will detect this event if the design does not outright reject it.

My understanding is that for most end users, Denial of Service is the bigger concern. The big guys won't be relying on open NTP across the Internet if they're really serious.

Liam Dennehy
  • 587
  • 2
  • 8