pic/alice44.gif
from Alice’s Adventures in Wonderland, Lewis Carroll Our resident cryptographer; now you see him, now you don’t.

2. Table of Contents

3. Introduction

Authentication support allows the NTP client to verify that the server is in fact known and trusted and not an intruder accidentally or intentionally masquerading 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 an 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.

3.1. Symmetric-Key Cryptography

NTP allows use of any one of possibly 65,535 keys, each distinguished by a 32-bit key identifier, to authenticate an association. Both server and client must agree on the key and key identifier in order 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.

4. Operation

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 key file. Server Bob has a symmetric key file. Alice sends an unauthenticated message to Bob. Bob therefore replies also with an unauthenticated message.

Client Carol does have a copy of Bob’s symmetric key file. Carol selects key ID 4, and sends a message to Bob. Bob verifies the message with his key ID 4. If the key matches and the message verifies, Bob replies to Carol with a message authenticated with his key ID 4. If verification fails, Bob sends Carol a crypto-NAK, which tells her that something is broken. She can see the evidence using the ntpq(1) program.

It should be clear from the above that Bob can support both unauthenticated Alice and authenticated Carol alike. Unauthenticated messages will receive unauthenticated replies. Authenticated messages will receive authenticated replies, assuming the authentication method and credentials are valid and compatible.

Bob also can act just like Alice and Carol in his own choice of connections to other servers; he can run multiple configured associations with multiple different servers (or the same server, although that might not be useful).

5. Key Management

Shared keys used for authentication are incorporated into the keys files generated by the ntpkeygen(8) utility program.

6. Algorithms

The NTP standards include symmetric (private-key) authentication using any message digest algorithm supported by the OpenSSL package. NTPsec will truncate digests longer than 20 bytes. This algorithm computes a message digest or one-way hash which can be used to verify that 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.

7. Data Formats

The NTPv4 specification (RFC 5905) allows any one of possibly 65,535 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 into the MAC. On receive, the message digest is computed and compared with the MAC. The packet is only accepted if the two MACs are identical. If the client finds a discrepancy, then it ignores the packet but raises the alarm. If this happens at the server, the server returns a special message called a crypto-NAK. Since the loopback test protects the crypto-NAK, an intruder cannot disrupt the protocol by sending a bogus crypto-NAK.

ntpd's digest mode can use any digest supported by libcrypto from the OpenSSL project. MD5 digests are 16 bytes. SHA1 digests are 20 bytes. Longer digests are truncated.

ntpd's CMAC mode can use any cipher with a CBC mode that is supported by libcrypto from the OpenSSL project. AES is short for AES-128. AES needs a 16 byte key. Longer keys are truncated. Shorter keys are padded with 0s. AES MACs are 16 bytes long. MACs longer than 20 bytes will be truncated.

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. Typical Symmetric Key File

Typical Symmetric Key File

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.

8. 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.

9. History

Old versions of NTP supported Autokey. It is described in RFC 5906. It used key ids greater than 64K.


icons/home.gif Home Page

icons/sitemap.png Site Map

icons/mail2.gif Contacts