Five-minute facts about packet timing
Network Time Protocol version 4 (RFC 5905) is a spectacularly successful network time transfer protocol. It can be found in almost every IP network. Often NTP messages will traverse leased lines or the “public internet”. Therefore, it is especially important that an NTP client can determine that the NTP server is who they say they are, and that no one has altered the messages in route. Fortunately, NTPv4 has a built-in security mechanism, called NTP autokey (Yay!). Unfortunately, autokey has known weaknesses and can now be broken by a brute force attack (Oh no!). Not to worry the mighty Internet Engineering Task Force (IETF) recently published an updated security mechanism called Network Time Security (RFC 8915) that does not have these weaknesses.
How does it work? If you are using any communication mode for NTP other than unicast client-server it doesn’t. For any of the less common communication modes of NTP then you are stuck with autokey or no security for a while longer. Sorry, but it was hard enough to define NTS for unicast. Let’s start by identifying the players in the game, shown in Figure 1. Beside the NTP server and client there is the NTS-KE server. KE stands for Key exchange. In practice the NTS-KE server and the NTP server might be two programs running on the same server, or they might be on separate hardware. The purpose of the KE server is to make sure that the NTP client and server are using the same cryptographic algorithms and optionally authenticate the identity of the NTP server and client.
Before a client can talk NTS with the KE server it opens a secure session using Transport Layer Security (TLS). See Figure 2. TLS is the same security mechanism you used earlier to order that batman watch you’ve been coveting without anyone being able to see your credit card number. It is also used to protect numerous other protocols on the internet, so it is a highly tested security protocol. I won’t be able to describe the details of TLS without exceeding my 5-minute limit, so I will leave that as an exercise for the reader. Once the TLS session is established the client will send a list of the AEAD security algorithms that it supports and (optionally) a preferred NTP server and port number in the network stack. The KE server will respond with a selected algorithm, server IP address, port number and one or more initial cookies. Because the NTS and KE servers are often implemented by the same time server manufacturer and bundled together, NTS does not specify the interaction between them. Somehow the NTS server tells the KE server which security algorithms it wants to use and the key to encrypt cookies with.
Once the NTP client has an initial cookie from the KE server it can send a secure NTP request with the NTP server. The NTP server will use the information in the NTP extension fields to collect the cookie and authenticate the NTP request. The NTP server will then generate the next cookie and send it with the NTP response. This is shown in Figure 3. So what is with all of the cookies going back and forth? The reason is that NTP servers are “stateless.” They don’t want to remember individual clients, since there could be a very large number or them. Note that the client might obtain multiple cookies from the KE server so that it does not have to check in with the KE server again every time it needs to re-start NTP.
NTS makes use of NTP extension fields (RFC The unique identifier is like a sequence number but random generated from a cryptographically secure random number generator. That gives the NTP messages more entropy than one where the ordinary sequence numbers, which makes the security harder to break with brute force cracking algorithms. The same unique identifier will be used in an NTP request and response pair. Along with the cookie is a pointer to the key used by the NTS server so that it can decrypt the cookie. The authentication extension field contains an integrated check value, i.e. hash code, that is compared to the one that the client and server generate upon receiving the message. If they match, then the message was not altered in the network.
So how do you bake a cookie for NTS? The ingredients are shown in Figure 5. The cookie is not ready to eat until it is encrypted. Note that the client will have encrypted cookies to send to the server but cannot read them. The client is just storing information for the server, to save memory on the server. A nonce is a field of random bits added to the message to increase entropy for the encrypted cookie. NTS uses different keys for the client to server NTP request (C2S) and for the server to client response (S2C).
Well, that should more than enough for you to dazzle your friends at your next dinner party with your knowledge of NTS.
If you have any questions about packet timing, don’t hesitate to send me an email at doug.arnold@meinberg-usa.com, or visit our website at www.meinbergglobal.com.
VERY interesting, Thank you !!!