The notion of accurate time is essential to determining the order in which events occur. This is a fundamental aspect of transactional integrity, system and network-wide logging and auditing, and troubleshooting and forensics. Having an accurate time source plays a critical role in tracing and debugging problems that occur on different platforms across a network. Events must be correlated with each other regardless of where they were generated. Furthermore, the notion of time (or time ranges) is used in many forms of access control, authentication, and encryption. In some cases, these controls can be bypassed or rendered inoperative if the time source could be manipulated. For example, a payroll function could be tricked into providing access over a weekend when normally it would be restricted to normal business hours. Many organizations have become reliant on NTP just as they are with other services such as the domain name service (DNS). This reliance can be a weakness if the service is not properly safeguarded. Therefore, it is important that these time sources are adequately protected against a wide array of threats, both internal and external, local and remote.

Time is not just an extraneous service. It is fundamental to the successful operation of todays environments. The most significant risks to NTP services are tampering and jamming. Tampering occurs when the NTP server is affected by either accidental or malicious data modification. Jamming occurs when a time server is either destroyed or prevented from providing NTP service. As with any other application, administrators must remember that NTP is not guaranteed to be secure; poor coding and other flaws in the program could allow unintended access to NTP internals or the underlying operating system. The NTP service is capable of protecting itself against some of these threats using architectural choices such as redundancy, and configuration options such as access control and authentication. Redundancy and its impact on an NTP implementation was discussed previously. Access control is achieved by restricting what NTP functions can be accessed from specific hosts or networks. Authentication is currently provided using symmetric keys that are installed on the NTP servers and clients.

NTP MD5 keying. NTP packets can be encrypted using standard MD5 algorithm. In this mode each packet is hashed using specified key number. In NTS-xxxx you can use keys in range from 1 to 65000. Both sender and receiver of encrypted packet must have identical key (string) entered at the same number (key id) to work.

You can enter and view NTS-xxxx MD5 keys in AUTH menu. All entered keys are considered to be trusted for time service needs, but there is default nopeer nomodify restriction in NTS-xxxx access control list.

You have to put the same keys at the same positions to file (/etc/ntp.keys) on client side. Please make sure that key file is not world readable -- it should be owned by root (on UNIX platforms), and be chmoded to 0600. Then you need to add keys /etc/ntp.keys line to your /etc/ntp.conf file.

You can have many NTP clients accessing NTS-xxxx in broadcast and multicast modes. Please note, that in default client NTP setup these modes requre authenticated packets to work (unless you add disable auth line to your ntp.conf file). Make sure, that you choose appropriate broadcast and multicast address. Please refer to original ntp documentation for further details about authenticated modes, and planing subnet synchronization using broadcast and multicast.