NTP Authentication Overview on CTP Devices

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.

Command - ntpdate -d –a <Key Id> -k /etc/ntp/keys <Server Ip>

Example - ntpdate -d –a 12345 -k /etc/ntp/keys 10.216.118.101

[root@ctp_74 ctp_cmd 36]# ntpdate -d -a 12345 -k /etc/ntp/keys 10.216.118.101
27 May 16:13:41 ntpdate[11935]: ntpdate 4.2.8@1.3265-o Tue Jan  6 05:50:59 UTC 2015 (3)
Looking for host 10.216.118.101 and service ntp
host found : 10.216.118.101
transmit(10.216.118.101)
receive(10.216.118.101)
receive: authentication passed
transmit(10.216.118.101)
receive(10.216.118.101)
receive: authentication passed
transmit(10.216.118.101)
receive(10.216.118.101)
receive: authentication passed
transmit(10.216.118.101)
receive(10.216.118.101)
receive: authentication passed
server 10.216.118.101, port 123
stratum 11, precision -21, leap 00, trust 000
refid [10.216.118.101], delay 0.02577, dispersion 0.00006
transmitted 4, in filter 4
reference time:    d9101e66.08f2fe3d  Wed, May 27 2015 10:43:50.034
originate timestamp: d9101e68.fbd8b5c6  Wed, May 27 2015 10:43:52.983
transmit timestamp:  d9106bbb.82aca793  Wed, May 27 2015 16:13:47.510
filter delay:  0.02580  0.02579  0.02577  0.02579
         0.00000  0.00000  0.00000  0.00000
filter offset: -19794.5 -19794.5 -19794.5 -19794.5
         0.000000 0.000000 0.000000 0.000000
delay 0.02577, dispersion 0.00006
offset -19794.526903

27 May 16:13:47 ntpdate[11935]: step time server 10.216.118.101 offset -19794.526903 sec

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.