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

["David L. Mills" <[e-mail]>]

Miroslav Lichvar wrote:

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

Dave