NTP Authentication Overview on CTP Devices

Network Time Protocol (NTP) is a UDP protocol for IP networks. It is a protocol designed to synchronize the clock on client machines with the clock on NTP servers. NTP uses Coordinated Universal Time (UTC) as the reference time.

The implementation of NTP requires separate client and server applications. Superficially, NTP is a software daemon operating in a client mode and server mode. Using NTP packets, the client and server exchange time stamp data, ultimately setting the clock on the client machine similar to that of the NTP server. Starting with CTPOS Release 7.2R1, NTP authentication is supported. NTP authentication checks the authenticity of NTP server before synchronizing local time with server. This phenomenon helps you to identify secure servers from unauthorized or illegal servers. NTP authentication works with a symmetric key configured by user. The key is shared by the client and an external NTP server. The servers and clients must agree on the key to authenticate NTP packets. Currently NTP is already supported in CTP devices but NTP authentication is not supported. Authentication support allows the NTP client to verify that the server is in fact known and trusted and not an intruder intending accidentally or on purpose to masquerade as that server.

The following are the different operating modes used by NTP:

Client/Server—In a common client/server model, a client sends an NTP message to one or more servers and processes the replies as received. The server interchanges addresses and ports, overwrites certain fields in the message, recalculates the checksum, and returns the message immediately. Information included in the NTP message allows the client to determine the server time with respect to local time and adjust the local clock.
Symmetric Active/Passive—Configuring a peer in symmetric-active mode indicates remote server that one wish to obtain time from the remote server and that one is also willing to supply time to the remote server if necessary. This mode is appropriate in configurations involving a number of redundant time servers interconnected through diverse network paths. Symmetric modes are most often used between two or more servers operating as a mutually redundant group.
Broadcast—The advantage is that clients do not need to be configured for a specific server, as this mode is intended for configurations involving one or a few servers and a possibly very large client population. Broadcast mode requires a broadcast server on the same subnet. Since broadcast messages are not propagated by routers, only broadcast servers on the same subnet are used. Since an intruder can impersonate a broadcast server and inject false time values, this mode should always be authenticated.

In the CTPView server, the Client/Server mode is implemented, which is the use case of the CTP device and CTPView or any other Linux machine within the same network as that of the CTP device will act as NTP servers for authentication.

Although you can configure NTP using the CTPView server in CTPView releases earlier than Release 7.2, you can configure NTP authentication starting from CTPView Release 7.2R1. NTP can only be configured from the CTPView server by using the System Configuration > Node Settings page of the CTPView server. NTP authentication allows the NTP client to verify that servers are known and trusted. Symmetric key authentication will be used to authenticate the packets. It is assumed that the shared secret key is already being communicated between client and server and it is the responsibility of the server to have the shared secret keys already configured in their configuration and keys files. The client then adds the required key id and shared secret key to their configuration and keys files through CTPView or through syscfg commands. The Key ID and Key Value fields must be left blank in CTPView to disable NTP authentication.

NTP Authentication Procedure

It is assumed that the shared secret key is already being communicated between client and server and it is the responsibility of the server to have the shared secret keys already configured in their configuration and keys files. Also, the “trustedkey keyid” attribute must be mentioned in the server’s ntp.conf file and the NTP process (ntpd) must be started in the server side for successful authentication.

The user provides the communicated key id and key values through the CTPView server or syscfg commands. The CTPView server adds the key value and key id to the conf and keys files of the CTP device and starts the NTP daemon. The NTP servers and clients involved must agree on the key, key ID, and key type to authenticate the NTP packets.

When the NTP daemon is started, it reads the key file specified by the keys command and installs the keys in the key cache. It then exchanges packets with its configured servers at poll intervals. The NTP authentication packet adds the key ID and the MAC address in its header, and the packets are accepted by the server only if the key ID matches a trusted key and the message digest is verified with this key. After authentication is successful, the NTP server stores its own timestamp and a transmit timestamp into the packet and send it back to the client. In the case of authentication failure, time is not synchronized.

The following is the example of NTP authentication assuming that the key received from NTP server is 12345 and the key number and corresponding key value is added to the conf and key files of the CTP device.

The preceding command, when run without “-d” option, synchronizes the time of CTP device with the NTP server. The “-d” option runs in debug mode, prints the intermediate results, and does not adjust the clock. If the key number or key value are not correct, then the message “authentication passed” is replaced with “authentication failed” and time is not synchronized.