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

[Ulrich Windl <[e-mail]>]

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 <[e-mail]> schrieb am 28.03.2021 um 19:36 in Nachricht
<[e-mail]>:
> 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