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

[Miroslav Lichvar <[e-mail]>]

On Sun, Mar 28, 2021 at 01:36:44PM -0400, David Mills wrote:
> Recent
> discussion in the newsgroup has centered on dramatic security mechanisms and
> exotic services for ntp version 5, but less attention has been on the
> underlying onwire protocols evolved from current NTP version 4.

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

I didn't see any comments about this document. Others here would
know better how this works as a replacement of the old Autokey. I'll
just point out few non-crypto things that didn't seem quite right to
me.

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.

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.

The cookie seems to be constructed just from a secret key and client
address, without a nonce.

The handshake in the symmetric mode seems to be still vulnerable to
off-path DoS attacks.

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 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.

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.

-- 
Miroslav Lichvar