XNTPD supports the optional authentication procedure specified in NTP versions 2 and 3.
When an association runs in the authenticated mode, each packet transmitted appends a 32-bit key ID and a 64/128-bit cryptographic checksum of the packet contents. This is computed using either the Data Encryption Standard (DES) or Message Digest (MD5) algorithms. These algorithms provide sufficient protection from message modification attacks.
NOTE:Distribution of DES algorithm implementation is restricted to U.S. and Canada, but MD5 is currently free from such restrictions.
In both the algorithms, the receiving peer recomputes the checksum and compares it with the one included in the packet. For this to work, the peers must share at least one encryption key and must associate the shared key with the same key ID.
This requires some minor modifications to the basic packet processing procedures, as required by the specification. These modifications are enabled by the “enable authenticate” configuration declaration.
In particular, the following servers are marked untrustworthy and unsuitable for synchronization in the authenticated mode:
Peers that send unauthenticated packets
Peers that send authenticated packets that the local server is unable to decrypt
Peers that send authenticated packets encrypted by using a key that NTP does not trust
NOTE:Although the server might know many keys (identified by many key IDs), it is possible to declare only a subset of these as trusted. This allows the server to share keys with a client that trusts the server and requires authenticated time, even though the server does not trust the client.
Also, some additional configuration language is required to specify the key ID to be used to authenticate each configured peer association. For example, for a server running in authenticated mode, the configuration file might look similar to the following:
# peer configuration for 128.100.100.7
# (expected to operate at stratum 2)
# fully authenticated this time
peer 128.100.49.105 key 22 # suzuki.ccie.utoronto.ca
peer 128.8.10.1 key 4 # umd1.umd.edu
peer 192.35.82.50 key 6 # lilben.tn.cornell.edu
enable auth
keys sys:\etc\ntp.keys # path for key file
trustedkey 22 4 6 # define trusted keys
requestkey 15 # key (6) for accessing server variables
controlkey 15 # key (7) for accessing server variables
authdelay 0.000094 # authentication delay (Sun4c/50 IPX)
The enable auth line enables authentication processing.
The keys sys:\etc\ntp.keys line specifies the path to the keys file (see below and the XNTPD document page for details of the file format).
The trustedkey line identifies those keys that are known to be uncompromising; the remainder presumably represent the expired or possibly compromised keys. Both sets of keys must be declared by the key identifier in the ntp.keys file described below. This provides a way to retire old keys while minimizing the frequency of delicate key-distribution procedures.
The requestkey 15 line establishes the key to be used for mode 6 control messages as specified in RFC-1305 and used by the NTPQ utility program.
The controlkey 15 establishes the key to be used for mode 7 private control messages used by the XNTPDC utility program. These keys are used to prevent unauthorized modification of daemon variables.
As a general rule, keys should be chosen randomly, except possibly the request and control keys, which must be typed by the user as a password.
The ntp.keys file contains the list of keys and associated key IDs that the server knows about.
WARNING:This file should be left unreadable by anyone except admin.
The contents of the ntp.keys file might look similar to the following:
# ntp keys file (ntp.keys)
1 N 29233E0461ECD6AE # des key in NTP format
2 M RIrop8KPPvQvYotM # md5 key as an ASCII random string
14 M sundial # md5 key as an ASCII string
15 A sundial # des key as an ASCII string
# the following 3 keys are identical
10 A SeCReT
10 N d3e54352e5548080
10 S a7cb86a4cba80101
Each line in the key file has three attributes. For example:
1 N 29233E0461ECD6AE
In the above example:
1 is the key ID
N is the key format
29233E0461ECD6AE is the key itself
The following table explains the four key formats.
Table 7-2 XNTPD Security Key Formats
NOTE:Because of the simple token routine, the characters #, \t, \n, \0 and a space cannot be used in either a DES or MD5 ASCII key. Key 0 (zero) is used for special purposes and should not appear in this file.
This sample scenario demonstrates a setup where XNTPD on ServerB (time consumer) needs to take time from the XNTPD on ServerA (time provider) with authentication.
In the ntp.conf file located in sys:\etc, make the following changes:
Mention sys:\etc as the path of the key file as follows:
keys sys:\etc\ntp.keys
Mark 1 as the trusted key ID. See the following figure for more details.
Figure 7-4 Ntp.conf File of ServerA
In the ntp.keys file located in sys:\etc, give a key value for key ID 1, pass1.
Figure 7-5 Ntp.keys File of ServerA
In the ntp.conf file located in sys:\etc, make the following changes:
Mention sys:\etc as the path of the key file as follows:
keys sys:\etc\ntp.keys
Mark 1 as the trusted key ID. See the following figure for more details.
Figure 7-6 Ntp.conf File of ServerB
In the ntp.keys file located in sys:\etc, give the same key value (that was given in ServerA for key ID 1) as shown in the following figure.
Figure 7-7 Ntp.keys File of ServerB
After entering the details in ServerA's and ServerB's ntp.conf and ntp.keys files, restart XNTPD on both the servers.