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

[David Venhoek <[e-mail]>]

Apologies for the somewhat larger delay in answering this. I had a
busy week and didn't have time to sit down for this until now.

In Response to Rodney,

At risk of repeating myself: Yes, I do think that the current TLV
security mechanism is broken to such a degree that making a key
exchange mechanism for it at this time is wasted effort. We can
disagree on that, but that is where my stance is coming from.

>From how I see it, there is no clear security guarantees that are
provided by the mechanism. By adding to it from the IETF, I fear we
would be reinforcing the idea that it "secures" ptp, which creates
more risks than it solves in my opinion.

I am considering joining the IEEE WG, however I have to also content
with the fact that I have limited time and quite enough going on as it
is at the moment between a (physics) PhD, a job and trying to learn
how to fly, so I have to be a bit careful not to overload myself. I
can unfortunately say that I can't make the next IEEE security WG
meeting though, as I have a conference where I am presenting at the
same time.

In response to Kristof,

As for 1a), see the paragraph above. In addition, I think the IETF is
the wrong forum to do the work of figuring out and listing all those
security caveats. That to me is part of fixing the TLV security
mechanism, and should be done in the IEEE WG. I just don't think the
spec is open enough for that part of the process to be succesfull
enough within the IETF.

1b) Again, see above. I think the current mechanism is so broken that
spending further time on the key exchange is wasted. The mechanism
needs fixing, and that can only be reasonably done within the IEEE.

2a) To get concrete on what would need to change, at the very minimum,
the 1588 standard should list clearly what is and isn't protected by
the security mechanism (i.e. what functional, not protocol,
protections does it provide). That would at least aleviate the massive
risk of overassuming protection.

I would like to see that include at least protection of the BMCA (i.e.
guarantees that attackers cannot influence choice of master), which
already would require some way of dealing with the delay attacks.
Ideally of course it would mean some guarantees to the quality of
synchronization, which is a lot harder.

2b) I honestly wasn't aware of that alternative, but I'll take your
word for it that it might be broken as well. Reality is I don't see
the tlvs being any good either soon, and working on the key exchange
part specifically won't do much either way.

2c) Yes, as long as it does not provide security, I think we are
better of not having an NTS4PTP spec. Again, most end users are
horible at judging these things, and the existance of a spec from the
IETF suggests a certain modicum of security. Thus they may falsly
assume they are safe even if they are not, which is much more
dangerous in my view than not having this at all.

Having finished answering the questions, lets move to your final
points. Yes, at lot of these are hard issues to solve, especially with
the architecture of PTP. But until we do, the holes are big enough for
the mechanism to basically give no protection, hence my concern.

On a few specific points, you might be overly pessimistic though. The
startup issue is, to a degree, solvable. For one, long lived keys can
be used to bootstrap trust without relying on time. Once you have
trust, mechanisms that rely on a roundtrip measurement can give time
to within the duration of the roundtrip. That isn't anywhere near the
end goal of what ptp aims to achieve, but it isn't nothing either.

Also, key usage periods technically dont require fully synchronized
clocks. They merely require a local timescale that is precise enough
(100ppm will typically do) together with an agreed upon start time.
Your mechanism actually provides this, assuming the duration of the
ntske session is short enough (say 1s).

As for DoS attacks, although I agree with you that cutting the wire is
always an option, the thing to watch out for is attacks that easily
scale from a distance, and the sequence ID reset issue has that
potential. Although I agree with you that it is far from the most
serious problem uncovered (and actually has a pretty easy fix for
once).

Finally, I noticed that I made a minor typo in copying over the last
issue, 215 should read 2^15, which might reduce your DoS concern on
the last issue, unless I misunderstand what your concern is there.

Kind regards,
David Venhoek

On Mon, Jun 3, 2024 at 12:01 PM <[e-mail]> wrote:
>
> Responses in-line...
> Would love to talk about all this on a long-form webcall, BTW (in addition to the interim WG meeting, I mean).
>
> I will also take this opportunity to state that I'm in favor of adoption as a WG draft.
>
>
> Besten Gruß / Kind regards,
> Kristof Teichel
>
> __________________________________________
>
> Dr.-Ing. Kurt Kristof Teichel
> Physikalisch-Technische Bundesanstalt (PTB)
> Arbeitsgruppe 4.42 "Zeitübertragung"
> Bundesallee 100
> 38116 Braunschweig (Germany)
> Tel.:        [phone]
> E-Mail:   [e-mail]
> __________________________________________
>
> "David Venhoek" <[e-mail]> schrieb am 30.05.2024 10:49:19:
>
> > Von: "David Venhoek" <[e-mail]>
> > An: [e-mail]
> > Datum: 30.05.2024 10:50
> > Betreff: [Ntp] Re: Call for NTP WG adoption of https://
> > datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp/
> >
> > 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.
>
> My first set of questions is procedural:
> 1a) What you are voting against here is the transition from a draft authored/edited by private persons to a draft under the responsibility of the NTP WG - how did you come to that view specifically?
> (As opposed to e.g. letting it become a WG draft and ensuring that all security caveats are explicitly and clearly listed in an eventual RFC... because I don't think work would stop being poured into the draft overall, and IMO you and your colleagues would have better ways to provide feedback to a WG draft.)
>
> 1b)It seems to me that if there were any way ever for a published spec for protected PTP, it almost never hurts to have an active WG draft - are you saying no form of this should be published, ever, or am I missing something?
>
> > 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.
>
> 2a) What changes (to the 1588 standard) would it take to disarm these concerns of yours?
> Specifically, are you sure such changes are possible, and do you have a mental image for what they might look like if they are - and how long it would take to implement them?
> (I'm thinking years, with quite fundamental updates to the spec, and some aspects like delay attacks and correction field security look... questionable to me where solvability and/or practicality are concerned)
>
> 2b) I wasn't really able to gauge your opinion on the group key PTP security approach with GDOI - do you think it's a viable/better option?
> (I don't, really, I think it has even less security potential - which is why the alternative to working on this draft seems a lot like accepting a lack of PTP security for the foreseeable future)
>
> 2c) Are you saying that until such time (if ever), you prefer no PTP security over having an NTS4PTP spec as long as everyone is on the same page regarding the lack of security?
>
>
> (Honestly, everything I write below is just variations on "I'm not holding my breath for issue X to be fixed/fixable in the 1588 spec")
>
> > 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.
>
> I think this is all valid, and also a set of problems that is pretty deep-seated in PTP architecture/logic/topology.
> (PTP has a one-way/broadcast model for sync messages baked in at its core. My whole doctoral thesis is basically a long rant on why one-way time transfer is terrible if you want secure time)
> Waiting for this to be fixed before even attempting PTP security from my point of view just means giving up PTP security.
> At most, this approach would limit security to a tiny sub-set of PTP instances that try to emulate NTP-style two-way time transfer as far as possible; I know such things are in the works.
>
> > ----
> > 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.
>
> I mean, it is always annoying to make an attacker's path to DoS shorter/easier.
> But let's remember that, under any serious attacker model, they can always do some equivalent of 'cutting the wire'; IMO not too much effort should be spent on trying to prevent these things (cause you can't, fully).
>
> > ----
> > 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.
>
> I'm not trying to say I understand all implications of this, but it does sound like a variation of the chicken-and-egg problem:
> An instance that is just booting up and has no good info (neither security data nor a synced clock, potentially; also, these two are often dependant on one another) is very vulnerable.
> Presuming that an attacker acts as a MITM right from the start of a given instance basically means that secure time sync (or positioning) is impossible for that instance.
> I don't think there is much to be done about this TBH.
>
> > 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.
>
> Wouldn't this create even larger vectors for DoS?
> Also, doesn't the "period the current key is in use" require synced clocks?
>
> > 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 PTPdocument:
> > > 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]