[Ntp] Post NTS, Is shared key authentication interesting?

Hal Murray <hmurray@megapathdsl.net> Mon, 25 May 2020 07:56 UTC

Return-Path: <hmurray@megapathdsl.net>
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 A4A383A0CEF for <ntp@ietfa.amsl.com>; Mon, 25 May 2020 00:56:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.934
X-Spam-Level: **
X-Spam-Status: No, score=2.934 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_DYNAMIC_IPADDR=1.951, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 0X_esyp_KEgw for <ntp@ietfa.amsl.com>; Mon, 25 May 2020 00:56:07 -0700 (PDT)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2EF3A0C52 for <ntp@ietf.org>; Mon, 25 May 2020 00:56:07 -0700 (PDT)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 52F0C40605C; Mon, 25 May 2020 00:56:06 -0700 (PDT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: ntp@ietf.org
cc: Hal Murray <hmurray@megapathdsl.net>
From: Hal Murray <hmurray@megapathdsl.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 25 May 2020 00:56:06 -0700
Message-Id: <20200525075606.52F0C40605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/soS8N2x7t2SwsvudMIyzr_JS0d8>
Subject: [Ntp] Post NTS, Is shared key authentication interesting?
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, 25 May 2020 07:56:09 -0000

I'm assuming the answer is "Yes" since RFC 8573 updated the idea to use AES 
and it was issued less than a year ago.  It seems like a good idea to have an 
alternative to NTS/TLS.

RFC 7822 from March 2016 describes the restrictions on extension lengths 
required to grandfather in the old non-extension MACs.  I think we should move 
MACs to an extension.

What that RFC doesn't describe is that shared keys require an explicit setup 
step by the server operator.  If the operator chooses as policy, not to 
support old style MACs, there is no reason for the code on her server to 
support them.  (or even know about them)

Is there any interest in an RFC for shared-key MACs in extensions?  I'm 
willing to do most of the editing if somebody will guide me through the 
process.

-------

Perhaps this should wait until NTPv5.  I'd rather get started now.

---

NTPsec has code that we inherited from the NTF/reference/Mills package to TCP 
out to a a Microsoft Samba/AD server to sign/check NTP packets.  Does anybody 
use that?


-- 
These are my opinions.  I hate spam.