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

"David L. Mills" <> Fri, 16 April 2021 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BFD693A3266 for <>; Fri, 16 Apr 2021 12:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, STOX_BOUND_090909_B=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XySwj2gYUPJL for <>; Fri, 16 Apr 2021 12:32:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3EB123A3243 for <>; Fri, 16 Apr 2021 12:32:45 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66F61A52E5; Fri, 16 Apr 2021 15:32:44 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 5PoLO5wRx_H4; Fri, 16 Apr 2021 15:32:21 -0400 (EDT)
Received: from [] ( []) (Authenticated sender: mills) by (Postfix) with ESMTPSA id 1E616A528A; Fri, 16 Apr 2021 15:32:21 -0400 (EDT)
Message-ID: <>
Date: Fri, 16 Apr 2021 15:32:20 -0400
From: "David L. Mills" <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.2; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Miroslav Lichvar <>
References: <> <YHRr1IhY7Xg8+uo2@localhost>
In-Reply-To: <YHRr1IhY7Xg8+uo2@localhost>
Content-Type: multipart/alternative; boundary="------------000700060208000002030801"
Archived-At: <>
Subject: Re: [Ntp] Protocol and Security Enhancements for the Network Time Protocol (NTP)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Apr 2021 19:32:56 -0000

Miroslav Lichvar wrote:

>On Sun, Mar 28, 2021 at 01:36:44PM -0400, David Mills wrote:
>>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.
>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
>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.

>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 cookie seems to be constructed just from a secret key and client
>address, without a nonce.
I don't see that the cookie requires a nonce.  It is incrypted according 
to the key generated by
a Diffiee-Helman agreement. 

>The handshake in the symmetric mode seems to be still vulnerable to
>off-path DoS attacks.
By handshake I think you mean agreement.  The agreement is vulnerable to 
attack, but the
agreement  is done seldomly  and may represent a relatively minor 
exposure.  The problem
is the requirement that error recovery must be available with no 
preconceived requirement.

>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 
is recognized by a check on the apparent  poll interval.

>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
The proposed scheme does not work with legecy autokey.  Fancy that . 

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

Please forgive my ackward sentences.  It is hard to deal with technical 
issues using a screen-reader
and my wife as editor .