Detections
Analytics

6.7.6 Ensure Strong Authentication Methods are used for NTP Authentication

Information

Strong authentication methods should be set for NTP Servers

Rationale:
Having established the need for NTP, it is essential to ensure that the devices time is not manipulated by an attacker as this could allow DoS to services relying on accurate time as well as replay attacks and other malicious activity.
NTP Version 3 introduced Authentication mechanisms for NTP messages using a Keyed Hash based Message Authentication Check (HMAC), where a hash of the message ensures both that the message is authentic and that it was not changed in transit. All JUNOS platforms support HMAC with NTP Versions 3 and 4 using MD5 and some platforms also support the more robust SHA1 and SHA2-256 algorithms.
Message Digest 5 (MD5) is an older hashing mechanism dating back to the early 90's. Since 2004 an increasing number of collision vulnerabilities have been shown in MD5 and the algorithm is no longer considered suitable for authentication and integrity protection of sensitive material or X.509 certificates.
While not supported across all devices, some JUNOS devices now support use of SHA1 and SHA2-256 HMAC for NTP message authentication and these should be considered for deployment where available and the security of network segments used to reach NTP Servers is of concern.

NOTE - Both the keys and the algorithm must match on all NTP peers being configured.
Where some peers do not support the more advanced algorithms or do not require the additional protections use the server or peer (if you are configuring a JUNOS device to act as the NTP Server) option to set individual keys and algorithms on a per peer basis.

Solution

Keys are configured on a key ring and identified by an ID number. To add a key enter the following command from the [edit system ntp] hierarchy;
[edit system ntp]
user@host#set authentication-key <Key ID> type <algorithm> value <Key>
<Key ID> is an arbitrary 32-bit non-zero integer used to identify this key locally on the device. The <algorithm> can be set to MD5 (the default), SHA1 or SHA2-256 (with SHA1 and SHA2 only being supported on some devices) - for Strong Authentication Methods you should use sha1 or sha2-256 only.
Finally configure the key as trusted so that the router will accept NTP traffic encrypted using it. This mechanism provides an easy method to retire keys in the event of compromise. Enter following command from the [edit system ntp] hierarchy;
[edit system ntp]
user@host#set trusted-key <Key ID>
The <Key ID> which is trusted can be one key or several keys by enclosing the list in square brackets or repeating the command.

NOTE - Keys can also be set on a per server or per peer or broadcast basis (if this device is also acting as an NTP Server), but the key must also be trusted here.

Impact:
If keys or algorithms do not match on NTP Servers and Client devices NTP will not be able to update and this could impact Logging, Authentication, Encryption/VPN or other services which rely on consistent time.

Default Value:
NTP is not configured by default

See Also

https://workbench.cisecurity.org/files/2278

Item Details

Category: IDENTIFICATION AND AUTHENTICATION

References: 800-53|IA-3, CSCv6|11.4

Plugin: Juniper

Control ID: 72a71f4c71a59e66d299ec3ae5145779726678de5bdef7baccdea02c92fbb25b