Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

[Doug Arnold <[e-mail]>]

Regarding delay attacks and PTP.

First, in most applications that include PTP, for example power substations, if a malicious agent takes over a switch or router in the network, then there might be 10 things they could do that are worse than manipulating the time.

That being said, PTP needs to have resistance to delay attacks, which won’t likely come from cryptography.  Approaches that are used or are being discussed are:

  *   Multiple PTP domains, and a voting algorithm.  In this case the PTP domains need to  have different network paths. An equivalent approach is measuring PTP clients using a reverse PTP mechanism through a different path than the time transfer path.
  *   Heuristic checks on incoming time compared to the stability of the local oscillator.  No sudden jumps, or ramps that are faster than the local oscillator drift rate.  This works best if the local oscillator is very stable or if physical layer syntonization is used.
  *   GNSS capable probes in the network to spot check the PTP accuracy, and report issues.
  *   Other means of verifying the time at the clients outside of PTP

What cryptography can do for PTP is prevent attacks by entities that have not taken over a switch or router, but have gained access to the network, such as impersonating a PTP server.

PTP is

From: ntp <[e-mail]> on behalf of Daniel Franke <[e-mail]>
Date: Wednesday, May 26, 2021 at 9:28 AM
To: Heiko Gerstung <heiko.gerstung=[e-mail]>, NTP WG <[e-mail]>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
(Resending to reply to the list)

I finally gave this draft a close read this morning. I have to oppose
adoption, on the grounds that it doesn't appear to achieve any of
NTS's goals.

It clearly doesn't attempt to achieve server statelessness. It doesn't
achieve client unlinkability either, since only one cookie is provided
and there's no mechanism for refreshing it without a new NTS-KE. The
case possibly could be made (but hasn't been) that these goals aren't
as important for PTP as they are for NTP, but after this I would still
object that calling a protocol "NTS" when it doesn't provide these
things is bad marketing for NTS4NTP.

The killer, though, is that the protocol fails to provide time
authentication to within any reasonable error bounds. The only secure
time exchange is the one that happens in phase 2 during the
DELAY_REQ/DELAY_RESP exchange. Transmissions during phase 3 are
vulnerable to delay attacks. Checking sequence numbers is not
sufficient mitigation against these. A MitM could forward packet N
when (and only when) the server sends packet 2N. All sequence number
checks would pass, but absent any other sanity checks the client's
clock would be slowed by a factor of two.

The NTS TLV is missing any field that corresponds to the Unique
Identifier EF from NTS4NTP. Without this, an attacker can drop or
reorder the server's messages and confuse the client as to what
request a response corresponds to. This is easy to fix, but absent a
fix, clients would have to mitigate this by making sure they only ever
have one request in flight at a time. Failure to promptly obtain a
response to any time-sensitive request such as DELAY_REQ would require
rerunning NTS-KE. Non-time-sensitive requests could simply be
retransmitted.

To salvage the security of this protocol, you could first fix the
Unique Identifier issue and then have the client send DELAY_REQ
messages at NTP-like intervals, rather than just once per handshake,
in order to regularly reëstablish tight error bounds that can be used
to sanity-check the phase 3 packets. This would achieve time security
about equal to what you get from the NTP/PTP hybrid I proposed last
month, but without privacy, without server statelessness, and with an
added requirement for support from the server rather than being able
to unilaterally implement it on the client side.

On Wed, May 26, 2021 at 4:31 AM Heiko Gerstung <heiko.gerstung=[e-mail]<mailto:[e-mail]>> wrote:
Dear fellow NTP working group members,

I just submitted the latest revision of our NTS for Unicast PTP draft (-02) which you can find here:
https://datatracker.ietf.org/doc/draft-gerstung-nts4uptp/


Based on our experience of more than 20 years (NTP) and 15 years of PTP based network time synchronization for quite a large number of different applications and industries, we believe that the proposed draft will increase the number of potential use cases for unicast PTP by adding serious and sound security mechanisms to this protocol. It will enable users in a large variety of areas to transport highly accurate and reliable time over wide area networks and hard to protect large-scale private networks.

Unicast PTP is a protocol that has been designed to be used in protected network environments and requires additional protection to allow using it in other types networks, i.e. the Internet or wide-area-networks where it is impossible to ensure that no malicious actor with access to the network can carry out various attacks. The proposed draft offers protection against most of the possible attacks.

The authors acknowledge that other variants of PTP, namely the multicast and hybrid (i.e. unicast and multicast) forms, need to be protected as well. However, those forms are rarely used over wide area networks and are much more common in local area networks and protected network environments. Securing multicast and hybrid PTP requires a more complex solution and our expectation is that the proposed standard for securing unicast PTP will be completed faster due to the fact that we built it on the work that already went into RFC8915. The similarities in the key exchange phase of the protocol also offer an efficient way to implement combined NTS4NTP and NTS4UPTP key exchange service daemons and therefore helps to simplify deploying secure time synchronization solutions that support NTP, PTP or both in parallel.

I therefore would like to formally request adoption of this draft by this working group and kindly ask you to review the draft, and send your questions, comments and general feedback to the WG and/or one of the authors of this draft.

Thank you and best regards,
  Heiko



--
Heiko Gerstung
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone: [phone]
Fax: [phone]

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Email:
[e-mail]<mailto:[e-mail]>
Web:
Deutsch https://www.meinberg.de
English https://www.meinbergglobal.com

Do not miss our Time Synchronization Blog:
https://blog.meinbergglobal.com

Connect via LinkedIn:
https://www.linkedin.com/in/heikogerstung


_______________________________________________
ntp mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ntp