Re: [Ntp] NTS Pools

["\"Dr. Dieter Sibold\"" <[e-mail]>]

Hi Martin,

thanks for your thought an NTS protected NTP pools.

Please find comments below.

On 22 Feb 2024, at 15:39, martin.langer=[e-mail] wrote:

> 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, 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.
From my point of view we carefully should differentiate between secured time synchronisation and trustworthy time sources. So my claim would be: Usage of NTS for NTP pools would indeed increase security of time exchanges. However, the question of trust in the member of the NTP pools remains unsolved. I don’t think that this can be solved by enhancing NTS. I would suppose that the question of trust is to be solved independently from NTS. In many respects that’s similar to HTTPS, where you need TLS to secure exchange of information and a PKI to establish trust in the Web server.


>
>
> 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,
> Martin
>
>
>
> 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.: [phone]
> E-Mail: [e-mail]
> __________________________________________

> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp