[Ntp] NTS Pools

martin.langer@ptb.de Thu, 22 February 2024 14:39 UTC

Return-Path: <martin.langer@ptb.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 25050C180B60 for <ntp@ietfa.amsl.com>; Thu, 22 Feb 2024 06:39:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.929
X-Spam-Status: No, score=-3.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ptb.de
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JEFrpKPKaBaN for <ntp@ietfa.amsl.com>; Thu, 22 Feb 2024 06:39:45 -0800 (PST)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.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 4A2BEC151549 for <ntp@ietf.org>; Thu, 22 Feb 2024 06:39:44 -0800 (PST)
Received: from s23397.bs.ptb.de ([]) by mx1.bs.ptb.de with ESMTP id 41MEdfVr021899-41MEdfVt021899 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Feb 2024 15:39:41 +0100
MIME-Version: 1.0
From: martin.langer@ptb.de
To: David Venhoek <david@venhoek.nl>, NTP WG <ntp@ietf.org>
Cc: Dieter.Sibold@ptb.de, Kristof.Teichel@ptb.de, Rainer Bermbach <r.bermbach@ostfalia.de>
Message-ID: <OF2E6B0FFD.229AD710-ONC1258ACB.004EFEAA-C1258ACB.0050896E@ptb.de>
X-Priority: 3 (Normal)
Importance: Normal
Date: Thu, 22 Feb 2024 15:39:40 +0100
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-FE-Policy-ID: 5:5:5:SYSTEM
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=ptb.de; s=s1-ptbde; c=relaxed/relaxed; h=mime-version:references:subject:from:to:cc:message-id:date:content-type; bh=AgoftgLajVt8qvpircxoCt0BwRlBdFJKoz3izWqdHFE=; b=llK8k+KIxAcZHF5Iq5JnUoYMuGwbqinUVzYE2m3XSzd6odvVO3WLHntEEX6AyQ9pbE9dRrRGFZMv R9o2NJ99EDC1j+jAClyUdwVtidxfUo9/tjOyVC6BnkDStUiyUBRkuabdMVvpSzEdh1DEd16nHYNf 8GWtNqJ767mYzrhKWs2TzZq1hjtwAH/w3FYOwBjupw9yoCY82Om4FUIoURqfRazcv/BwVIqaCKva BWxvvh9j73MsTN4+aZICjJfqzfSzOQfqTUSx2agPVb4tCALXWINu/b9wmfsSTEO0KCXh9KgGGlp6 SAK47cNaKRv8TXSqPfaA9V4V7N2VbdEyPChLoQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/noqut95Cmumjbfxa2JpYus85HQs>
Subject: [Ntp] NTS Pools
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <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: Thu, 22 Feb 2024 14:39:50 -0000

Hi David,

I was talking with Krisof Teichel, Dieter Sibold and Rainer Bermbach about how we should handle NTS secured NTP pools. It's not easy as there are different perspectives on the purpose, use cases and security considerations. In general, I think I can provide support from the PTB side, even though I have very little time for it at the moment. (...NTS4PTP is very time consuming)

I also spent a lot of time thinking about this and discussed the possibilities intensively with Rainer Bermbach. The main results are described in my recently published dissertation [https://leopard.tu-braunschweig.de/servlets/MCRFileNodeServlet/dbbs_derivate_00053439/Diss_Langer_Martin.pdf" title="https://leopard.tu-braunschweig.de/servlets/MCRFileNodeServlet/dbbs_derivate_00053439/Diss_Langer_Martin.pdf">https://leopard.tu-braunschweig.de/servlets/MCRFileNodeServlet/dbbs_derivate_00053439/Diss_Langer_Martin.pdf, Chapter 4.2]. I would like to give you a brief overview here. First of all: NTS4PTP already solves this problem for PTP and provides an NTS subprotocol that can also be used for NTP (more details below).

My personal goal

From my point of view, I would like to see the communication between the NTS-KE server and the NTS capable NTP server defined. Especially in large local networks, a central NTS-KE server could be set up which, similar to the NTP pool, assigns the known NTP servers to the requesting clients. This way an admin can connect any number of NTP servers to the NTS-KE server without having to reconfigure any NTP client.

However, I would NOT want to change public NTP pools, as this is not absolutely necessary to provide NTS-secured NTP. Depending on the implementation approach, there are different advantages/disadvantages and challenges (see below).

Use Case and Security Considerations

The biggest question is who wants to use NTS-secured NTP pools and what security promises should be fulfilled. If someone wants "secure time or
secure time synchronization", then NTS-secured NTP pools do not provide it. Although NTS secures the communication between the NTP client and NTP server, it does not provide any indication as to whether the time server itself is trustworthy. So it makes a difference whether I intentionally add 1, 2 or 3 NTS-capable time servers in the NTP configuration, or whether I hand over control and let some be assigned to me at random. ...you should at least always keep this in mind.

NTS pool solution approach 1: The simplest variant: ...do nothing.

You could simply provide the NTP pools with NTS-capable NTP servers. When a client receives different IP addresses for NTP servers, it can simply check via TCP port 4460 if an NTS-KE server is present. If so, it will perform the key establishment protocol for the corresponding NTP server. This is also more secure, since no central NTS-KE server is involved in the key negotiation. ...NTP pools could possibly be modified to signal which NTP servers are capable of NTS, or a client could explicitly ask for NTS capable NTP servers. The only disadvantage is that the client has to perform several TLS handshakes... but this should be acceptable.

NTS pool solution approach 2: central NTS-KE server

This method gives the NTS-KE server the ability to assign NTP servers and also to implement other services such as load control. NTS for NTP already provides mechanisms for port and IP negotiation. However, there are a number of challenges to be addressed.

1: Time server registration

The communication between the NTS-KE server and the NTP server has to be defined. Since the NTS-KE protocol does not include message type detection, another NTS subprotocol is required. I have done this in NTS4PTP, which can also be easily extended for NTP.

2: Authorization

In short, the question of who can register with a central NTS-KE server and who issues the certificates. If this is not a question, then of course anyone can provide an NTS-secured NTP server. ...this goes back to the question of trust in the time server.

3. cookie format

If the NTS-KE server generates cookies, the cookie format has to be defined. The cookie format described in RFC8915 is currently recommended. Deviations are therefore allowed. Although all known NTS implementations follow this format, they all differ in field length and byte order and are therefore not compatible!

4. nonce collisions / key recovery

If the NTS-KE server and the NTP server are separated, it must be ensured that both sides do not accidentally use the same key with the same nonce, otherwise a key recovery is possible. Either the nonce generation has to be regulated or we need 2 master keys.

5. miscellaneous

Then there are many more questions:
- Keeping the TLS channel open for multiple requests (you solved this with the keep-alive record; I solved it without a record based on timeouts and 'close_notify')
- Heartbeat messages for NTP servers
- Registration revocation mechanisms for NTP servers
- possibly data synchronization between NTS-KE servers (for resilience)
- ...

..so just my thoughts

have a nice day.

kind regards,

PS: there is an error in my thesis (chapter 4.2.5): we have no Source PortIdentity in NTP ..so ignore it ;)

Dr.-Ing. Martin Langer
Physikalisch-Technische Bundesanstalt (PTB)
Working Group 4.42 "Dissemination of Time"
Bundesallee 100,
38116 Braunschweig (Germany)
Tel.: +49 531 592-4470
E-Mail: martin.langer@ptb.de