from Alice’s Adventures in Wonderland, Lewis Carroll Our resident cryptographer; now you see him, now you don’t.
Table of Contents
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. NTP performs authentication via message digests. It computes a one-way hash, which verifies that the server has the correct private key and key identifier.
A detailed discussion of the NTP multi-layer security model and vulnerability analysis is in the white paper NTP Security Analysis.
Authentication is configured separately for each association using the key subcommand on the server configuration commands. The authentication options described below specify the locations of the key files and which symmetric keys are trusted.
Authentication is always enabled, although ineffective if not configured as described below. If a NTP packet arrives including a message authentication code (MAC), it is accepted only if it passes all cryptographic checks. The checks require correct key ID, key value and message digest. If the packet has been modified in any way by an intruder, it will fail one or more of these checks and be discarded. Authentication doesn’t prevent replays.
NTP allows any one of possibly 65,534 keys, each distinguished by a 32-bit key identifier, to authenticate an association. The servers and clients involved must agree on the key and key identifier to authenticate NTP packets. Keys and related information are specified in a key file. More info in ntp.keys(5). It must be distributed and stored using secure means beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the ntpq(1) utility program.
When ntpd(8) is first started, it reads the key file specified in the keys configuration command and installs the keys in the key cache. However, individual keys must be activated with the trustedkey command before use. This allows, for instance, the installation of possibly several batches of keys and then activating or deactivating each batch remotely using ntpq(1). This also provides a revocation capability that can be used if a key becomes compromised. The controlkey command selects the key used as the password for the ntpq(1) utility.
A server receiving an unauthenticated packet will respond with an unauthenticated packet, while the same server receiving a packet of a cryptotype it supports will respond with packets of that cryptotype.
Some examples may help to reduce confusion. Client Alice has no keys file. Server Bob has a symmetric key file. Alice’s unauthenticated messages arrive at Bob, who replies with unauthenticated messages. Cathy has a copy of Bob’s symmetric key file and has selected key ID 4 in messages to Bob. Bob verifies the message with his key ID 4. If it’s the same key and the message is verified, Bob sends Cathy a reply authenticated with that key. If verification fails, Bob sends Cathy a crypto-NAK, which tells her something broke. She can see the evidence using the ntpq(1) program.
It should be clear from the above that Bob can support all the girls at the same time, as long as he has compatible authentication and identity credentials. Now, Bob can act just like the girls in his own choice of servers; he can run multiple configured associations with multiple different servers (or the same server, although that might not be useful). But, wise security policy might preclude some combinations; for instance, running authentication with one server and no authentication with another might not be wise.
Shared keys used for authentication are incorporated keys files generated by the ntpkeygen(8) utility program.
The NTP standards include symmetric (private-key) authentication using any message digest algorithm supported by the OpenSSL package. Digests longer than 20 bytes will be truncated. This algorithm computes a message digest or one-way hash which can be used to verify the client has the same message digest as the server.
Authentication is configured separately for each association using the key option of the server configuration command, as described in the Server Options page. The ntpkeygen page describes the files required for the various authentication schemes.
By default, the client sends non-authenticated packets and the server responds with non-authenticated packets. If the client sends authenticated packets, the server responds with authenticated packets if correct, or a crypto-NAK packet if not. The notrust flag, described on the Access Control Options page, can be used to disable access to all but correctly authenticated clients.
The NTPv4 specification (RFC 5905) allows any one of possibly 65,534 message digest keys (excluding zero), each distinguished by a 32-bit key ID, to authenticate an association. The servers and clients involved must agree on the key ID, key type and key to authenticate NTP packets.
The message digest is a cryptographic hash computed by an algorithm such as MD5 or SHA1. When authentication is specified, a message authentication code (MAC) is appended to the NTP packet header. The MAC consists of a 32-bit key identifier (key ID) followed by a 128- or 160-bit message digest. The algorithm computes the digest as the hash of the key concatenated with the NTP packet header fields and the key ID. On transmit, the message digest is computed and inserted in the MAC. On receive, the message digest is computed and compared with the MAC. The packet is accepted only if the two MACs are identical. If a discrepancy is found by the client, the client ignores the packet, but raises an alarm. If this happens at the server, the server returns a special message called a crypto-NAK. Since the crypto-NAK is protected by the loopback test, an intruder cannot disrupt the protocol by sending a bogus crypto-NAK.
MD5 digests are 16 bytes. SHA1 digests are 20 bytes. Longer digests don’t work yet. 2018-Jan-07 FIXME: long digests
Keys and related information are specified in a keys file, which must be distributed and stored using secure means beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the ntpq utility program. See ntp.keys(5) for details.
Figure 1 shows a typical keys file. In this figure, for key IDs in he range 1-10, the key is interpreted as a printable ASCII string. For key IDs in the range 11-20, the key is a 40-character hex digit string. Any line can be edited to change any field or new lines can be added. Note that two or more keys files can be combined in any order as long as the key IDs are distinct.
When ntpd is started, it reads the keys file specified by the keys command and installs the keys in the key cache. However, individual keys must be activated with the trustedkey configuration command before use. This allows, for instance, the installation of possibly several batches of keys and then activating a key remotely using ntpq. The controlkey command selects the key ID used as the password for the ntpq utility.
Microsoft Windows Authentication
In addition to the above means, ntpd supports Microsoft Windows MS-SNTP authentication using Active Directory services. This support was contributed by the Samba Team and is still in development. It requires the --enable-mssntp option to waf configure. At run time, it is enabled using the mssntp flag of the restrict command described on the Access Control Options page. Note: Potential users should be aware that these services involve a TCP connection to another process that could potentially block, denying services to other users. Therefore, this flag should be used only for a dedicated server with no clients other than MS-SNTP.