[Ntp] Protocol and Security Enhancements for the Network Time Protocol (NTP)
David Mills <Mills@Udel.edu> Sun, 28 March 2021 17:37 UTC
Return-Path: <Mills@Udel.edu>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709183A21F7 for <ntp@ietfa.amsl.com>; Sun, 28 Mar 2021 10:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifAxzswd1qNr for <ntp@ietfa.amsl.com>; Sun, 28 Mar 2021 10:37:10 -0700 (PDT)
Received: from whimsy.udel.edu (whimsy.udel.edu [128.4.24.99]) by ietfa.amsl.com (Postfix) with ESMTP id E72F53A21F5 for <ntp@ietf.org>; Sun, 28 Mar 2021 10:37:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by whimsy.udel.edu (Postfix) with ESMTP id DC904A528A for <ntp@ietf.org>; Sun, 28 Mar 2021 13:37:07 -0400 (EDT)
X-Virus-Scanned: amavisd-new at whimsy.udel.edu
Received: from whimsy.udel.edu ([127.0.0.1]) by localhost (whimsy.udel.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7XvdSpG7C55I for <ntp@ietf.org>; Sun, 28 Mar 2021 13:36:45 -0400 (EDT)
Received: from [128.4.2.6] (backroom.udel.edu [128.4.2.6]) (Authenticated sender: mills) by whimsy.udel.edu (Postfix) with ESMTPSA id D81B4A52ED for <ntp@ietf.org>; Sun, 28 Mar 2021 13:36:44 -0400 (EDT)
To: NTP WG <ntp@ietf.org>
From: David Mills <Mills@Udel.edu>
Message-ID: <61c01bcb-0f07-27e0-f809-1bee2aa31f71@Udel.edu>
Date: Sun, 28 Mar 2021 13:36:44 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------5F0F421D94C761BB538B884B"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/CWMywyuC5Og11wv0DOL5hipuq2A>
Subject: [Ntp] 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: Sun, 28 Mar 2021 17:37:14 -0000
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
- [Ntp] Protocol and Security Enhancements for the … David Mills
- [Ntp] Antw: [EXT] Protocol and Security Enhanceme… Ulrich Windl
- Re: [Ntp] Protocol and Security Enhancements for … Miroslav Lichvar
- Re: [Ntp] Protocol and Security Enhancements for … David L. Mills
- Re: [Ntp] Protocol and Security Enhancements for … Miroslav Lichvar
- Re: [Ntp] DDoS meets NTP Hal Murray
- [Ntp] DDoS meets NTP Hal Murray
- Re: [Ntp] DDoS meets NTP Daniel Franke
- Re: [Ntp] DDoS meets NTP Daniel Franke
- Re: [Ntp] DDoS meets NTP Danny Mayer
- [Ntp] Antw: [EXT] Re: DDoS meets NTP Ulrich Windl
- Re: [Ntp] DDoS meets NTP Miroslav Lichvar
- Re: [Ntp] [EXT] Re: DDoS meets NTP Daniel Franke
- Re: [Ntp] Protocol and Security Enhancements for … James Browning
- Re: [Ntp] Protocol and Security Enhancements for … David Mills