Re: [Ntp] [EXT] Consensus call: NTPv5 and supported modes

[David Venhoek <[e-mail]>]

As a further clarification on my earlier arguments, below my analysis
as to why I think the current status of both the broadcast modes and
peer modes could still be security risks. Please note that these do
not constitute fully realizable active attacks, but are merely
observations as to why I see these modes as significantly more risky
than the client-server mode.

For broadcast mode, when using no authentication, anyone with the
capabality of sending network packets to the clients can get them to
set arbitrary time quite trivially. However, even with some form of
authentication, there is the difficulty that there is no way for a
client to send any sort of challenge to the server. As such, it
becomes hard to impossible for a client to put any bound on how far in
the past the particular packet it received was generated, leaving it
vulnerable to replay attacks. As far as I am aware, outside of using a
shared notion of time (which we can't rely on as providers of that
shared notion) there is no good solution for protection against replay
attacks in broadcast-style protocols.

For peer modes, having a system accept ephemeral associations is
trivial to exploit if authentication is not present. However, even
with authentication, and even with both peers being in active mode,
the interdependence between the packets going from A to B and those
going from B to A makes it tricky as to when an association between
two peers should be reset, when it should be demobilize and other
decisions regarding state changes and packet acceptance. Getting this
wrong has caused multiple security issues in the reference
implementation (see for example CVE-2016-1547, CVE-2016-1549,
CVE-2018-7170), and to be honest I am not convinced that there is
currently an implementation that is fully immune from issues in this
area.

I might be missing something though, and perhaps there has been more
complete modelling done of how either of these modes can be done
securely, in which case I would love to see those models and proofs.

As for your response Danny, I was wondering what you mean by
Anderson's work needing broadcast mode? As far as I can tell, his
research stems rather from the opposite, namely that any securing  a
broadcast type signal (in his research specifically, gnss based
signals) through the TESLA scheme requires preexisting rough agreement
on the current time. However, I didn't really dive all that deeply
into his work so if you could explain what I am missing that would be
very welcome.

Kind regards,
David Venhoek

On Sun, Jul 2, 2023 at 5:43 PM Danny Mayer <[e-mail]> wrote:
>
>
> On 6/30/23 5:05 AM, David Venhoek wrote:
> > I am of the opinion that we should not include the modes 1, 2 and 5,
> > based on the following arguments (in order of importance):
> There are a lot of assumptions made here which are probably not valid.
> >   - They are known to be vulnerable (about 50% of all ntp reference
> > implementation vulnerabilities over the past years came from these
> > modes alone, and I for one am not convinced that they are in any way
> > securely usable today).
>
> What evidence to you have of this and which modes do you think that they
> apply to? Certainly modes 1 and 2 are able to use the same security as
> modes 3 and 4.
>
> There are ways of dealing with mode 5 (broadcast and multicast) and I
> seem to remember that autokey works for that. Yes, I know that autokey
> is vunerable but it means that there are ways to deal with it.
>
> >   - There seems to be limited interest in working towards fixes for
> > their vulnerability, and I have not seen concrete ideas as to how.
> I don't know what that means. See above.
> >   - The use cases for these modes have reasonable alternatives
> > available today: dhcp can distribute the address of an ntp server as
> > replacement for mode 5, and mutual client-server connections can be
> > used in the same situations as modes 1/2 (if needed with configuration
> > settings in the implementation for special algorithmic treatment).
> That not a substitute for multicast and cannot handle changes in servers
> sending multicast packets. Furthermore many servers have fixed IP
> addresses and do not use dhcp.
> >   - Removing them would significantly simplify both the NTPv5 standard
> > and the process of creating it.
> Simplication of a standard is not a goal merely because it's easier.
> >   - They are already not supported in 2 of the 4 major implementations
> > (ntpsec, ntpd-rs), and only partially in a 3rd (chrony).
> That's irrelevant since it ignores the many systems that use it today.
> >
> > I would prefer we mark them as obsolete/deprecated or something like
> > that, as I don't see a realistic path to getting them to the point
> > where the security concerns are going to be allayed, but am willing to
> > leave them open as potential future extensions to NTPv5.
> No. The NTP reference implementation will continue to support them and
> it is straightforward to implement NTS for modes 1 and 2. Mode 5 will
> probably need additional work. I need to remind everyone of Jason
> Anderson's work on needing Broadcast mode (though I would change this to
> Multicast since Broadcast is not available in IPv6).
> > On the idea that this might inhibit adoption, I am not convinced of
> > that. Based on contacts I have had through the ntpd-rs project with
> > users, these modes are not among the missing features people seem
> > interested in. I know there have been claims that this is absolutely
> > critical for some users, but we have not seen anything concrete as to
> > for whom and why, and I am therefore not inclined to take those claims
> > seriously.
> >
> > Kind regards,
> > David Venhoek
> >
> > On Thu, Jun 29, 2023 at 3:13 PM Windl, Ulrich <[e-mail]> wrote:
> >> Hi!
> >>
> >> On " Should NTPv5 additionally support also the modes 1, 2 and 5 known from NTPv4?": If not, what should the document say about those? Obsolete? An extension?
> >> IMHO being too restrictive may delay adoption or acceptance of NTPv5 after it is available.
> >>
> >> Kind regards,
> >> Ulrich Windl
> >>
> >>
> >> -----Original Message-----
> >> From: ntp <[e-mail]> On Behalf Of Dieter Sibold
> >> Sent: Wednesday, June 28, 2023 9:53 PM
> >> To: NTP WG <[e-mail]>
> >> Subject: [EXT] [Ntp] Consensus call: NTPv5 and supported modes
> >>
> >> Dear all,
> >>
> >> at IETF 116 we decided to have two consensus calls regarding the content of the NTPv5 requirement draft. These are consensus calls that we would like to conduct to help progress the NTPv5 requirements document (https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5-requirements/). Both consensus calls will run until July 21st 2023 and will be discussed at the next NTP wg meeting at IETF 117 in San Francisco.
> >>
> >> The first consensus call (the second comes in a follow up mail):
> >>
> >> Regarding supported modes:
> >>
> >> Currently, the NTPv5 requirement draft considers a client-server communication mode only. Should NTPv5 additionally support also the modes 1, 2 and 5 known from NTPv4?
> >>
> >>
> >> Greetings
> >> Karen and Dieter
> >>
> >>
> >> _______________________________________________
> >> ntp mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ntp
> > _______________________________________________
> > ntp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ntp
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp