[Ntp] Re: Call for NTP WG adoption of https://datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp/

[David Venhoek <[e-mail]>]

My specific concern is that we are trying to "secure" PTP, based on a
mechanism (the authentication TLVs) that isn't even anywhere close to
achieving that.

This may perhaps be a problem with how we understand the term securing
in this context. To me that is an end to end guarantee on the output
(clock synchronization) based on the protocols involved. This is a
though problem that basically isn't met by the PTP standard Annex P.
Getting there is tricky, and I think that that needs attention in the
PTP protocol itself, and is not something that can be "bolted on
later". In particular, this in my view cannot be solved by simply
specifying SA parameters and a key exchange mechanism.

If on the other hand, we should move to a different notion of what
"secure" should mean in this context, and which guarantees this should
entail, that on its own is a deeply non-trivial question. What parts
of the protocol should we protect, and which guarantees should that
protection yield? These choices are relevant, but crucially, they are
relevant beyond the specific key distribution mechanism used, and
honestly should have been part of Annex P in the first place.
Furthermore, we should be very careful with calling that "secure", as
that leaves the door open to all sorts of misinterpretations. This is
already somewhat true in NTS, where the timing guarantees are
significantly looser than usual performance, but this becomes even
more so with PTP since precision beyond the round trip delay is the
whole name of the game. And it becomes especially insidious if we
don't give a timing guarantee at all but rather some different subset
of protection.

In terms of concrete attack vectors, the various forms of delay
attacks are right now for me the main concern. However, note that
unlike in NTP, these have far wider reaching impact than "just" a slip
in synchronization. The BMCA, which is the main source and state
management solution in PTP critically depends on when announce
messages arrive. Delayed announces can have all sorts of fun
unexpected effects on the BMCA. As discussed before on this mailing
list, the BMCA is not optional, so this will need fixing somehow.

All of these concerns are essentially independent of the key
provisioning mechanism and choices regarding the SA, and are I think
much more likely to be solved in a good way in the IEEE, and not in an
attempt to fix them from the outside through an IETF process.

Kind regards,
David Venhoek

On Fri, May 31, 2024 at 12:28 PM <[e-mail]> wrote:
>
> Hello David,
>
> as we said... NTS4PTP is not only a key management system, but also specifies
> in detail the use of SAs in PTP.
>
> PTPv2.1 does not provide native protection. We also believe that the sequence
> number in the PTP header was not designed to protect PTP from attacks in any way.
> Therefore, we would not speak of a security flaw. It is used to recognize the packet
> sequence, e.g. to be able to discard older sync messages directly. If PTP explicitly
> claimed that this sequence number serves as replay protection, then it would be very
> strange if the PTP standard did not provide authenticity and integrity protection at
> the same time, but only made suggestions for implementation.  We can understand
> that this can lead to confusion, as the PTP standard also defines an authentication
> TLV in detail, describes what the individual data fields are for, and then does not
> describe a security solution that actually uses this TLV. The (forbidden) use of the
> sequence number within the authentication TLV has also not been sufficiently defined
> and is not used either ... but this has nothing to do with whether PTP can be secured
> in principle or not.
>
> We agree that PTP is complex. That is also the reason why our draft has many more
> pages than the NTS-for-NTP RFC, as there is much more to consider. We have been
> focusing intensively on the question of how to secure PTP for over 5 years and therefore
> we know many scenarios that need to be considered. Many thoughts on the attack
> scenarios and design decisions in NTS4PTP can also be found in my dissertation [1],
> although there have been a couple of updates since then.
>
> Apart from delay attacks, are there certain scenarios that you are convinced cannot
> be secured? We can offer to discuss everything to get clarity. You can also list the
> attack vectors that you think are critical and we will describe how we defend against
> them. ...but in order to create clarity, we obviously need to know what your specific
> concerns are.
>
> I am convinced that we can secure PTP with NTS4PTP, regardless of the current security
> status of PTP. ....In addition, we are currently working on the reference implementation
> in order to subsequently use it in White-Rabbit-capable PTP hardware.
>
>
> kind regards,
> Martin and Rainer
>
> [1] https://leopard.tu-braunschweig.de/servlets/MCRFileNodeServlet/dbbs_derivate_00053439/Diss_Langer_Martin.pdf
> __________________________________________
> Dr.-Ing. Martin Langer
> Physikalisch-Technische Bundesanstalt (PTB)
> Working Group 4.42 "Dissemination of Time"
> Bundesallee 100,
> 38116 Braunschweig (Germany)
> Tel.: [phone]
> E-Mail: [e-mail]
> __________________________________________
>
> -----"David Venhoek" <[e-mail]> schrieb: -----
> An: [e-mail]
> Von: "David Venhoek" <[e-mail]>
> Datum: 31.05.2024 10:25
> Betreff: [Ntp] Re: Call for NTP WG adoption of https://datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp/
>
> Hi All,
>
> Just to further clarify, my objection is rooted in the fact that I
> don't think the PTP side issues are minor and can be fixed in the key
> exchange portion of the protocol. I think there needs to be serious
> reconsideration of how a security mechanism for PTP should function at
> its core, and clear objectives around what it should protect and why
> that is useful. I don't see that as an easy to fix issue and think it
> will take significant time, and might run into significant further
> challenges. Furthermore, I feel that if we don't tackle those issues,
> we are likely to produce (part of) a security mechanism that on the
> surface seems to provide security against a large class of attacks,
> where in reality that is not the case for most of those. This risks
> creating a situation where people start building setups that are
> unwise, lulled into a sense of security by the existence of the
> mechanism that doesn't quite protect what they think it does. To me,
> that is a situation worse than not having a security mechanism at all.
>
> I do fully agree that the key distribution through nts key exchange
> servers makes sense, and that it makes sense to develop that in the
> context of the IETF. I just do not think it wise to develop the
> message signature methods and the framework for what that should
> protect within the IETF, due to the complexity of PTP and the fact
> that, even with partial access, this will not be developed as in the
> open as other IETF security standards. I am worried that we are going
> to make a mistake in this process, and that it is going to be
> significantly harder for people not directly involved to spot that.
> Even with the option to get the standards, that is still a barrier and
> will make it harder from people from the security area to contribute,
> especially in the "just taking a short look" kind of way which could
> be crucial here in my view.
>
> In short, I think fixing the issues are not a matter of: "providing
> the missing key distribution and just tweaking some parameters"
> (paraphrased) to produce a tool that is useful. I feel that to solve
> the security concerns I have over the PTP security mechanism will
> require deep modifications that interact significantly with how PTP
> works on a fundamental level, and to me the IETF feels like the wrong
> forum for that work.
>
> Kind regards,
> David Venhoek
>
> On Fri, May 31, 2024 at 6:39 AM Karen ODonoghue <[e-mail]> wrote:
> >
> > Hi David,
> >
> > I'd like to make a few comments addressing some of the higher level issues you have raised.
> >
> > First, the IEEE 1588 specification has been made available to those in the NTP working group who want to help with the development or review of PTP related documents in the IETF. The NTP working group chairs have been given permission to provide a copy to those who request it. This has been mentioned a number of times in the NTP working group meetings but perhaps not recently. We are not allowed to post it publicly, but we can share it with those who ask. Additionally, the IEEE 1588 working group has a pretty low barrier to admittance. You just have to ask the leadership in order to participate.
> >
> > Second, NTS was specified in the IETF. IEEE 1588 is interested in using it as one of the potential key management schemes for their security architecture. Vendors who are looking at selling NTP and PTP servers would like to have some commonality where possible. The reality of this commonality has not yet been fully determined, but this is a starting point. Changes and additions to NTS need to happen in the IETF. Just as we recently had a lengthy conversation about whether or not our NTP over PTP specification was changing PTP or not (and we weren't allowed to do that because PTP was defined by IEEE), IEEE 1588 cannot change NTS.
> >
> > Third, your comments were received by the IEEE 1588 Security Subcommittee, and plans are underway to address the issues raised. This may result in a maintenance update or an amendment. This is a positive development, and further collaboration and work on NTS can only help further the potential applicability and use of NTS.
> >
> > Finally, I think it is unrealistic to think that NTS for PTP will solve all of the possible security scenarios for PTP. It will be another tool for PTP deployments to use. In fact, even NTS was narrowed in scope to address only the client/server modes of NTP operation. We are still waiting for solid mature proposals to address the remaining modes of NTP operation that were not addressed in NTS.
> >
> > Regards,
> > Karen
> >
> > On Thu, May 30, 2024 at 4:49 AM David Venhoek <[e-mail]> wrote:
> >>
> >> TLDR: I would like to object to the adoption of the NTS4PTP draft, on
> >> the grounds of problems with the PTP specification it is building
> >> upon. I would like to emphasize that our problems are specifically
> >> with IEEE1588-2019, and not the draft here. However, these problems
> >> are of such a nature that I feel further work on nts4ptp at this stage
> >> from the IETF would be wasted effort.
> >>
> >> At work, we have had the opportunity to play around with implementing
> >> both PTP Annex P (the security protocol from PTP) as well as the group
> >> mode of the spec under consideration here. From those experiments, we
> >> have come to the conclusion that the specification given in PTP Annex
> >> P is, as it stands right now, fundamentally broken.
> >>
> >> We have found 3 different flaws, included below. For one of these, the
> >> delaying of individual messages, there is no reasonable mitigation
> >> known to us at this time. A number of the others require in our view
> >> significant normative changes to the PTP specification.
> >>
> >> Furthermore, we feel that these issues are actually a consequence of
> >> an underlying problem. Namely, that the PTP specification is unclear
> >> on what protections the security layer should offer. There is no
> >> proper model provided that indicates what guarantees the security
> >> layer is intended to make. This makes it easy for users to assume the
> >> security layer offers better guarantees than it ever could.
> >>
> >> Given this state of the protocol specified in Annex P, at this time a
> >> standard not attempting to fix those vulnerabilities would likely fail
> >> to meet security goals. However, fixing these issues from the IETF
> >> working group is in our view not a good idea. The closed nature of the
> >> PTP standard, combined with its complexity, makes it too difficult for
> >> someone without access to the PTP spec itself to judge security of
> >> such an effort. This, in our opinion, would make the risk of hidden
> >> flaws in the specification too severe to be acceptable.
> >>
> >> This in our view makes it currently not possible to successfully start
> >> an effort within the IETF to provide a security protocol for PTP. We
> >> think the better path forward would be to start an effort within the
> >> IEEE to provide fixes to Annex P, including hopefully an effort to
> >> better specify which guarantees the security protocol in that annex
> >> intends to provide.
> >>
> >> To preemptively answer the question as to why I have not come forward
> >> before with these concerns: The specific flaws that lead to the
> >> conclusion above were still under a responsible disclosure process up
> >> until a few hours ago. This unfortunately took somewhat longer than
> >> hoped, but this effectively stopped me from making the argument above
> >> without potentially disclosing security issues in implementations, had
> >> there been any.
> >>
> >> Kind regards,
> >> David Venhoek
> >>
> >> ----
> >> PTP Message delay attack
> >> Issue
> >> An attacker can cause the clock of an attacked instance to change by
> >> delaying event messages from/to that instance. It can either do this
> >> by actually delaying some of the messages (in particular sync) or by
> >> changing the correction field if this is not signed.
> >>
> >> This issue is particularly hard to detect when using the peer to peer
> >> delay mechanism, as then the delay measurements are independent of the
> >> sync message, and hence delaying the sync message leaves no trace in
> >> any delay on the path between the slave and master clocks.
> >>
> >> Mitigation
> >> The issue cannot be meaningfully mitigated when using the peer to peer
> >> delay mechanism. When using the end to end delay mechanism, the attack
> >> can potentially be detected by monitoring the mean delay and alerting
> >> when it is larger than expected.
> >>
> >> In addition, the correction field must be signed in the authentication
> >> TLV, otherwise attacks cannot be meaningfully detected.
> >>
> >> ----
> >> PTP Authentication Sequence ID Reset vulnerability
> >> Issue
> >> Per clause 16.14.4.2.1 a PTP implementation supporting authentication
> >> TLV’s needs to check that the sequence ID received for an inbound
> >> message is larger than the last sequence id received for that
> >> combination of key, sender port identity and message type. However,
> >> per 7.3.7, sequence IDs may change non-sequentially on state change of
> >> a PTP port.
> >>
> >> As such, an attacker that can cause the port state of an instance to
> >> change may thus cause that instance to change the sequence IDs it uses
> >> for transmission such that they become smaller than previously sent
> >> sequence IDs. This causes that port to become unable to send further
> >> ptp messages to other instances, resulting in denial of service. This
> >> is particularly easy to trigger on ports in the slave state, as it is
> >> sufficient to inhibit delivery of announcement messages to cause a
> >> switch to the master state.
> >>
> >> Mitigation
> >> PTP instances should avoid resetting or otherwise changing sequence id
> >> numbering on port state changes.
> >>
> >> ----
> >> PTP Authentication Startup Replay attack
> >> Issue
> >> A ptp instance that is in the startup process does not know which
> >> sequence IDs have already been used and which are the most recent.
> >> Hence, an attacker can deliver old messages immediately on startup,
> >> getting it to accept an old sequence ID for the purpose of checking
> >> whether new messages should be accepted.
> >>
> >> If in combination the sequence id forward jump limit is too small,
> >> this will cause the attacker to reject all genuine messages from the
> >> remote as old, allowing the attacker to subsequently fully control
> >> which messages are received by the target port.
> >>
> >> If one or more instances went away during the current rekeying
> >> interval, the attacker similarly can keep these looking alive to any
> >> new instances.
> >>
> >> Mitigation
> >> The PTP network as a whole should rekey before any instance comes
> >> close to using more than 215 sequence IDs from one of its pools.
> >> Instances should accept forward jumps in sequence IDs large enough to
> >> cover all messages sent by any port for the period the current key is
> >> in use.
> >>
> >> If devices join or leave the PTP network, it should be rekeyed as soon
> >> as possible to limit available messages to an attacker.
> >>
> >> On Wed, May 29, 2024 at 5:41 AM Karen ODonoghue <[e-mail]> wrote:
> >> >
> >> > NTP working group,
> >> >
> >> > This email starts a two week call for adoption for the NTS for PTP document:
> >> > https://datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp/
> >> >
> >> > Please review the document, provide any comments, and indicate whether or not you believe this document is a good starting point for our NTS for PTP work.
> >> > This Call for Adoption ends on 11 June 2024.
> >> >
> >> > Thank you,
> >> > Karen and Dieter
> >> > _______________________________________________
> >> > ntp mailing list -- [e-mail]
> >> > To unsubscribe send an email to [e-mail]
> >>
> >> _______________________________________________
> >> ntp mailing list -- [e-mail]
> >> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> ntp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]