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

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Mon, 29 March 2021 10:16 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 40D3C3A376D for <ntp@ietfa.amsl.com>; Mon, 29 Mar 2021 03:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id isMNIBmfFhdY for <ntp@ietfa.amsl.com>; Mon, 29 Mar 2021 03:16:45 -0700 (PDT)
Received: from mx4.uni-regensburg.de (mx4.uni-regensburg.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56E83A376C for <ntp@ietf.org>; Mon, 29 Mar 2021 03:16:44 -0700 (PDT)
Received: from mx4.uni-regensburg.de (localhost []) by localhost (Postfix) with SMTP id A10036000055 for <ntp@ietf.org>; Mon, 29 Mar 2021 12:16:37 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de []) by mx4.uni-regensburg.de (Postfix) with ESMTP id 5AE9C600004E for <ntp@ietf.org>; Mon, 29 Mar 2021 12:16:34 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Mon, 29 Mar 2021 12:16:34 +0200
Message-Id: <6061A7A0020000A100040168@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.1
Date: Mon, 29 Mar 2021 12:10:40 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: "ntp@ietf.org" <ntp@ietf.org>,<mills@udel.edu>
References: <61c01bcb-0f07-27e0-f809-1bee2aa31f71@Udel.edu>
In-Reply-To: <61c01bcb-0f07-27e0-f809-1bee2aa31f71@Udel.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/9saDJ3Kq0Qsxz_IIUIxaNqPkSXc>
Subject: [Ntp] Antw: [EXT] Protocol and Security Enhancements for the Network Time Protocol (NTP)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Mar 2021 10:16:49 -0000

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.

Ulrich Windl
>>> David Mills <Mills@Udel.edu> schrieb am 28.03.2021 um 19:36 in Nachricht
> 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