Authentication for PTP

To the best of our knowledge, this isn’t yet widely implemented. However, a mechanism for distributing the keys for PTP authentication called NTS4PTP is currently going through the IETF process. This led us to take a closer look at both this key distribution mechanism and the underlying PTP security mechanism. Doing this, we found a number of problems in the design of the PTP security mechanism, which we will take a deeper look at in the rest of this blog.

PTP Authentication

PTP Authentication, like the rest of the PTP standard, is very flexible and allows a wide range of uses. For simplicity, we will focus on only one of the operating modes (immediate validation) in this blog and will assume all messages are signed. However, most of the problems we find are present in one way or another in all of the operating modes.

When enabled, PTP messages are authenticated by adding a signature to them based on a symmetric key. This symmetric key is known to all PTP nodes in the network, and we assume that all of these nodes are trustworthy.

When a node receives a PTP message, it verifies this signature. If it is correct, it then processes the message as normal. Any messages that are not correctly signed are discarded and can be logged for monitoring purposes.

Event messages

This signing ensures the messages were, at some point, sent by a node of the PTP network. However, in PTP there are additional complications because, for a number of messages, when they are sent is part of the information they convey.

This is most obvious with the event messages like the sync. The time at which the time transmitter sends the sync messages is one part of the offset measurement. If it gets retransmitted at a later time and accepted again by a time receiver, this will cause that time receiver to calculate an inaccurate offset.

However, due to the design choices made in PTP, this is also the case for some of the general PTP messages. The main example of this is the announce message sent by a time transmitter. The mere presence of these announce messages from a time transmitter is seen as proof of liveness. Hence, should retransmitted announce messages be accepted by a time receiver, it may decide to try to follow a time transmitter that is no longer present in the network.

Replay protection

The PTP authentication mechanism aims to mitigate these replay problems by including a sequence ID in every message. On every message a PTP node sends, it increments the sequence ID it uses for sending by one. All other nodes in the network only accept messages with a sequence ID higher than what they have previously received from the sending PTP node.

However, there are several ways in which this mechanism is rather fragile. This leads to various ways an attacker could disrupt time synchronization in a PTP network.

The dead node problem

The first challenge comes from dead nodes in a PTP network. Suppose that during normal operation the time transmitter in a PTP network becomes unavailable for one reason or another. This will be compensated for by the network choosing a different time transmitter. However, there is now no one transmitting new messages with the identity of the old time transmitter.

This means that at a later time an attacker could start retransmitting messages from the old time transmitter. Any node that has only joined after the old time transmitter went offline should accept these, as they contain sequence IDs that are “new” from their perspective. This could result in those nodes losing time synchronization.

Even worse, if one of the new nodes is the time transmitter of the network, this may cause it to think there is a better time transmitter. This would cause the whole network to lose its source of time.

The startup problem

A second problem is that when a new node joins the PTP network, it does not have knowledge yet of which sequence IDs were already used before it joined. Therefore, it may initially accept replayed messages from other nodes.

This becomes especially problematic in light of the fact that PTP sequence IDs are only 16-bit integers. These values do roll over in practice, which means that for the replay prevention, PTP nodes should accept only a limited window of forward jumps in these sequence IDs.

As the standard does not provide guidance on how large this forward jump range should be, this can rather easily be chosen to be too short. If that is done, the initially accepted replayed messages may lock the new node out from accepting genuine messages.

Delay attacks

The above vulnerabilities can all be seen as symptoms of a deeper problem: the sequence ID mechanism does not provide protection against delayed delivery.

This is a hard problem to solve in general. In NTP, when enabling NTS, although the received time might be more accurate, the security mechanism can only guarantee an upper bound of synchronization accuracy above half the round trip time to the server. It is in fact fundamentally impossible to do better than this.

However, PTP compounds this problem by making the main synchronization message time transmitter initiated. This means that the time receiver has no local time reference for the earliest point in time it was sent. Thus, it cannot establish a round-trip bound on maximum error from a security perspective.

With the end-to-end delay mechanism, this can be mitigated to a degree. As the synchronization messages are used there for the delay calculation, any consistent delaying of them will show up as an anomalously high delay between the time receiver and time transmitter.

However, with the peer-to-peer delay mechanism, the sync is completely independent from delay estimation. Hence, there needn’t be any sign of delaying tactics observable to any of the PTP nodes in the network.

Conclusion

Given the issues we identified above, we consider the current PTP security mechanism to be critically broken. Yes, the individual messages are to some degree protected, but that protection does not translate into any meaningful protection on the actual functional behavior of PTP. Getting to a point where the meaningful functionality of PTP is protected will likely require significant changes to how the PTP protocol works.

However, when precision better than the round trip time is needed, an untrusted network is likely never going to be appropriate, due to the potential of delay attacks. This is the case for almost all PTP deployments. Any future authentication mechanism for PTP should therefore carefully consider what types of attacks it wants to protect against and why.

This information should also be carefully communicated to implementers and end users. The latter should always do a proper security review of their specific setup whenever using PTP in critical applications. Due to the nature of time synchronization, PTP security will likely never be straightforward.