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

From: David Mills <[email-masked]>
Date: Sun, 28 Mar 2021 13:36:44 -0400

Folks,

In retirement I have been working on new and improved protocols and 
algorithms for the network time protocol NTP. The primary goal in this 
enterprise is to reduce incidental synchronization errors to the low 
tens of microseconds on fast internet paths. Secondary goals are to 
extend the algorithms and protocols to all NTP modes and security 
schemes. 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.

The current protocoldesign makes it awkward to develop mew capabilities. 
The design needs to be simplified and compacted as described in this 
memo. The new designs include the following:

o extemd the interleave scheme to work transparently in all protocol 
modes. this should be considered an extension and simplification of a 
recent internet draft on the same issues.

o provide automatic random keygeneration, expiration and rollover 
without requiring operator assistance,

o extend the onwire protocol and algorithms to work in all NTP modes, 
including client/server, symmetric and broadcast modes,

o develop a layer based architecture that includes format, private key 
and public key security models,

o search for likely wiretap and middleman vulnerabilities of the 
protocol and algorithms and invent defenses against them,

o reexamine startup and error discovery procedures to recover operations 
in spite of all manner of hostile mischief

o provide legacy compatibility with the existing ntp version 4reference 
implementation

In pursuit of these goals my fantasies were born in a public memo 
revealed some months ago. I have refined the architecture and design 
with frequent updates ever since. The overall design is intended to work 
in nonsecure, private key and public key secure configurations. The 
design philosopy is based on UDP and protocol messages embedded in NTP 
extension fields without inviting TCP/TLS, handshake dances. However, 
TCP/TLS can be used to generate a shared working key.

I would treasure a discussion on these principles among the computer 
engineering and computer science experts. Once upon a time the memo 
would be an internet engineering note ien, but nnow it might flourish as 
an internet draft. In any case, it would be a suitable project for an 
intern familiar with ccurrent programming practice, but not necessarily 
familiarwith clock synchronization technowlogy. In practice, the most 
useful use of the memo might be to carve out individual topics for 
future internet drafts.

Dave

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

Abstract

This memo proposes new protocol and security enhancements for the 
Network Time Protocol (NTP) described in rfc5905, along with a 
replacement for the Autokey security scheme described in rfc5906. The 
primary goal in this memo is to improve synchronization accuracy to the 
low tens of microseconds. Secondary goals include new agreement and 
security algorithms that protect players using private and public key 
cryptography.

The onwire protocols have been refined and improved, including the 
following:

    o the interleave and basic protocols are combined transparentlyin
    all modes and security regimes, while simplifying the implementation
    and configuration,

    o improved huff 'n puff filters optimize accuracy under severe
    network congestion conditions,

    o dynamic key agreement algorithms can be used in all modes except
    broadcast,

    o defenses against protocol attacks have been overhauled and improved,

    o perishable cryptographic keys can be automatically expired and
    refreshed.

The protocol and security enhancements are compatible with the current 
reference implementation and others in the community. To acknowledge its 
ancestry, the proposed design is called NTP Lite. NTP Lite is resistant 
to protocol and security attacks and key compromise. It involves various 
hash, encryption, agreement and signature algorithms protecting NTP 
hosts against wiretap and middleman insurrections.

NTP Lite is based on UDP and a single port 123 shared with NTP. The 
design supports all NTP modes, including symmetric, client/server and 
broadcast modes.The design is based on a state machine and a set of 
extension fields appended to the NTP packet header.

NTP Lite can be used along with other security schemes such as NTS and 
with the selected scheme activated by a configuration switch in each 
association. This allows a host to support multiple security schemes at 
the same time. Individual associations can be configured for nonsecure, 
private key secure or public key secure operations.

Fundamental Axioms for NTP Lite

    Law 1: A packet may not injure a peer or, through inaction, allow a
    peer to come to harm.

    Law 2: A packet must obey orders given it by peers except where such
    orders would conflict with the First Law.

    Law 3: A packet must protect its own existence as long as such
    protection does not conflict with the First or Second Law.

-- Apologies to Isaac Asimov

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 29 Mar 2021 12:10:40 +0200

Hello Dave,

nice to hear that you did not "abandon your child" ;-)

What came into my mind as an additional goal was:

o Suggest auto-tuning of parameters from long(er)-term statistics.
  Specifically I'm thinking of some of the tinker constants like dispersion, polling rates, fudge offsets, etc.

Regards,
Ulrich Windl
  
>>> David Mills <[email-masked]> schrieb am 28.03.2021 um 19:36 in Nachricht