Re: [Ntp] Protocol and Security Enhancements for the Network Time Protocol (NTP)

[David Mills <[e-mail]>]

Folks,

Thanks to Miroslav and friends who offered advice and comfort on the 
memo i proposed to the working group. The intended mission of the memo 
is to explore and evaluate new designs that improve accuracy and 
security without affecting the core algorithms of the reference 
implementation.

Note that the current version of the memo has evolved considerably since 
the first draft some months ago. The text is more crisp and the 
reasoning is more focussed. Happily, the more obnoxious critters such as 
the evil genie and shark packets have been expunged.

The onwire protocol is the most important design to take away from the 
memo.  It runs continuously and independenly of security provisions.  It 
is compatible with the current version 4 reference implementation.

The interleave protocol is supported in all NTP modes, including 
symmetric, client/server and broadcast modes. Note that a full 
complement of interleave devstamps requires two player rounds.

An important issue raised by Miroslav is the broadcast interleave 
protocol. That exposed vulnerabilities to old duplicate and lost 
packets. The revised protocol does not use comparisons of old and new 
timestamps, but uses static comparisons between packet and state variables.

The huff 'n puff filter has been redesigned. Again. This is a work in 
progress. As usual, the stumbling issue is how to set the congestion and 
skew thresholds in various traffic regimes.

Startup and recovery procedures have been revisited. The intent is to 
have a progression from an unsecured state through private key 
cryptography to public key cryptography security with the same onwire 
protocol.

Management and key refreshment procedures can be controlled with out 
operator involvement. This avoids the hassle with untrained operators 
not comfortable with key refreshment procedures.

The DDoS defences are improved against brutal attacs with large numbers 
of offenders operating at punishing rates. An evil blast with thousands 
of source addresses is reduced, but not always eliminated.

The section on leap seconds has been revised according to the 
professional astronemers. Activists will be disappointed that the smear 
option is not available in the operating system design. The option can 
be available in the system library.

The crypto-Nak and agreement exchange packets are protected by the 
onwire protocol and loopback test and the three-way handshake. The 
crypto-NAK packets are sent by a previously working player, so the 
receiver can verify the message. The agreement exchange may be 
vulnerable to ornery intruders. This is complicated by the need to 
recover from arbitrary attacks without a working key.

A 64-bit nonce can be used to replace the transmit sofstamp in a client 
packet.  This apparently makes it harder for a wiretapper to learn the 
position of a mobile client.

A lesson learned from previous NTP versions is the need to verify 
correct protocol behavior using simulation techniques described in NTP 
white papers on the NTP research project page.  The simulations explore 
protocol behavior under various error conditions. This has been done 
with several protocol designs, including EGP and NTP. This is an 
important topic for future projects with the protocols described in this 
memo.

Dave
https://www.eecis.udel.edu/~mills/Autokey3.txt


On 4/19/2021 7:09 AM, Miroslav Lichvar wrote:
> On Fri, Apr 16, 2021 at 03:32:20PM -0400, David L. Mills wrote:
>> Miroslav Lichvar wrote:
>>> The protocol doesn't prevent amplification attacks using the cookie
>>> response. The document claims that rate limiting prevents such
>>> attacks, but I don't think that is true. Rate limiting is not a
>>> security mechanism. It actually creates other security issues. The
>>> server has a limited amount of memory. Attackers can avoid rate
>>> limiting by using more addresses than the server can remember. That's
>>> easy if the victim is using IPv6.
>>>
>> Rate limiting in itself is not the issue.  See the DDoS section .
>> The effect is to delete packets with a headway less than two seconds.
>> The LRU list includes up to 700 distinct IP addresses, so the goal is to
>> amputate those enemy attacks before generating a response packet.
>> This scheme has been used at NIST for several years.
> If the server's LRU list is limited to 700 addresses, the attackers
> will simply use 701 or more addresses to prevent any address from
> accumulating requests and effectively disable the rate limiting.
> Generally, it cannot prevent an amplification attack.
>
> What is worse, it can be exploited for a DoS attack on real NTP
> clients if it doesn't randomly let some packets through. An attacker
> can send requests to the server with spoofed source address frequently
> enough to keep the rate limiting constantly enabled in order to
> prevent the real client from getting any responses to its own
> requests. This was reported years ago, but it is still not fixed in
> the ntp.org implementation.
>
> It is a widespread issue. A third of public servers included in the
> pool.ntp.org project seems to be affected.
>
>>> It doesn't have a fully random nonce in addition to the transmit
>>> timestamp. It claims that transmit timestamps are not predictable
>>> while it recommends to not use the data minimization.
>>>
>> I submit that in this context, the transmit timestamp can be an adequate
>> nonce.  It would be possible
>> to replace this function by an explicit nonce, but this means to be
>> overkill.  The data minimization
>> issue is not relevant.
> The data minimization draft requires clients to use fully random
> transmit timestamps. That's a good nonce, but it can be used only in
> the client-server mode, not the symmetric mode.
>
>>> In the broadcast mode the transmit timestamp is used as a sequence
>>> number, which means the server cannot have a backward step. It doesn't
>>> have a mechanism to protect against delay attacks. (That was a goal
>>> in earlier NTS designs.)
>>>
>> The hazzard is mitigated by the rules explained in section 4.3.  An old
>> duplicate
>> is recognized by a check on the apparent  poll interval.
> That is not always sufficient. An attacker who can prevent packets
> sent by the genuine server from reaching the client, can replay old
> packets at a consistent rate with a constant delay (arbitrarily
> large). The client will not see anything suspicious, except that the
> time is in past. If it accepts the backward step, it will be
> susceptible to the attack.
>
>>> The described parser detects legacy MACs by checking whether the
>>> length field of an extension field is zero. I guess that was meant to
>>> be the type of the field? That would work only with key IDs below
>>> 65536.
>>>
>> The proposed scheme does not work with legecy autokey.  Fancy that .
> The trouble is that it will fail to parse messages of implementations
> implementing RFC 5905 but not RFC 5906, using MACs with key IDs larger
> than 65535.
>
>>> It claims that NTS doesn't support interleaved mode. How could it, are
>>> those two not at different layers? NTS+xleave definitely works for me.
>>>
>> The proposed onwire protocol combines basic and interleave modes in a single
>> protocol where
>> the transmit devstamp is used  for all protocol rounds.  The detailed design
>> is described in section 4.3.
> The document doesn't have enough details for me to fully understand
> the new combined protocol.
>
> Is a server or peer supposed to send responses with transmit timestamp
> of a previous response whenever it has this timestamp saved, meaning
> interleaved mode constantly enabled, except it is not indicated by the
> origin timestamp as it used to?
>
> How would an older client or peer not implementing this new protocol
> be able to process received responses? I suspect it would be
> dropping all measurements due to a large delay.
>
> Another issue is that the symmetric mode cannot always work in
> interleaved mode. When the polling intervals of the peers don't match,
> there are multiple responses per request, using the same origin
> timestamp. This means there is an ambiguity for the interleaved
> transmit timestamp. The peer doesn't know if it actually received the
> response to which the transmit timestamp corresponds to. In such a
> case the symmetric mode needs to switch to basic mode. This is how it
> works in the ntp-interleaved-modes draft.
>