NTP robustness requirements are similar to those of other multiple-peer distributed protocols used for network routing, management and
file access. These include protection from faulty implementations, improper operation and possibly malicious replay attacks with or
without data modification. These requirements are especially stringent with
distributed protocols, since damage due to failures can propagate quickly throughout the network, devastating archives, routes and
monitoring systems and even bring down major portions of the network in the fashion of the classic Internet Worm.
The access-control mechanism suggested in the NTP specification responds to these requirements by limiting access to trusted peers.
The various sanity checks resist most replay and spoofing attacks by discarding old duplicates and using the originate timestamp as a
one-time pad, since it is unlikely that even a synchronized peer can predict future timestamps with the precision required on the
basis of past observations alone. In addition, the protocol environment resists jamming attacks by employing redundant time servers
and diverse network paths. Resistance to stochastic disruptions, actual or manufactured, are minimized by careful design of the
filtering and selection algorithms.
However, it is possible that a determined intruder can disrupt timekeeping operations between peers by subtle modifications of NTP
message data, such as falsifying header fields or certain timestamps. In cases where protection from even these types of attacks is
required, a specifically engineered message-authentication mechanism based on
cryptographic techniques is necessary. Typical mechanisms involve the use of cryptographic certificates, algorithms and key media,
together with secure media databases and key-management protocols. Ongoing research efforts in this area are directed toward
developing a standard methodology that can be used with many protocols, including NTP. However, while it may eventually be the case
that ubiquitous, widely applicable authentication methodology may be adopted by the Internet community and effectively overtake the
mechanism described here, it does not appear that specific standards and implementations will happen within the lifetime of this
particular version of NTP.
The NTP authentication mechanism described here is intended for interim use until specific standards and implementations operating at
the network level or transport level are available. Support for this mechanism is not required in order to conform to the NTP
specification itself. The mechanism, which operates at the application level, is
designed to protect against unauthorized message-stream modification and misrepresentation of source by insuring that unbroken,
authenticated paths exist between a trusted, stratum-one server in a particular synchronization subnet and all other servers in that
subnet. It employs a crypto-checksum, computed by the sender and checked by the receiver,
together with a set of predistributed algorithms, certificates and cryptographic keys indexed by a key identifier included in the
message. However, there are no provisions in NTP itself to distribute or maintain the certificates, algorithms or keys. These
quantities may occasionally be changed, which may result in inconsistent key information while rekeying is in progress. The nature of
NTP itself is quite tolerant to such disruptions, so no particular provisions are included to deal with them.
The intent of the authentication mechanism is to provide a framework that can be used in conjunction with selected mode combinations
to build specific plans to manage clockworking communities and implement policy
as necessary. It can be selectively enabled or disabled on a per-peer basis. There is no specific plan proposed to manage the use of
such schemes; although several possibilities are immediately obvious. In one scenario a group of time servers peers among themselves
using symmetric modes and shares one secret key, say key 1, while another group of servers peers among themselves using symmetric
modes and shares another secret key, say key 2. Now, assume by policy it is decided that selected servers in group 1 can provide
synchronization to group 2, but not the
other way around. The selected servers in group 1 are given key 2, but operated only in server mode, so cannot accept synchronization
from group 2; however, group 2 has authenticated access to group-1 servers. Many other scenarios are possible with suitable
combinations of modes and keys.
A packet format and crypto-checksum procedure appropriate for NTP is specified in the following sections. The cryptographic
information is carried in an authenticator which follows the (unmodified) NTP header fields. The crypto-checksum procedure uses the
Data Encryption Standard (DES) [NBS77]; however, only the DES encryption algorithm is used and the decryption algorithm is not
necessary. This feature is specifically targeted toward governmental sensitivities on the export of cryptographic technology, since
the DES decryption algorithm need not be
included in NTP software distributions and thus cannot be extracted and used in other applications to avoid message data
NTP Authentication Mechanism
When it is created and possibly at other times, each association is allocated variables identifying the certificate authority,
encryption algorithm, cryptographic key and possibly other data. The specific procedures to allocate and initialize these variables
are beyond the scope of this specification, as are the association of the identifiers and keys and the management and distribution of
the keys themselves. For example and consistency with the conventions of the NTP specification, a set of appropriate peer and packet
variables might include the following:
Authentication Enabled Bit (peer.authenable): This is a bit indicating that the association is to operate in the authenticated mode.
For configured peers this bit is determined from the startup environment. For non-configured peers, this bit is set to one if an
arriving message includes the authenticator and set to zero otherwise.
Authenticated Bit (peer.authentic): This is a bit indicating that the last message received from the peer has been correctly
Key Identifier (peer.hostkeyid, peer.peerkeyid, pkt.keyid): This is an integer identifying the cryptographic key used to generate the
message-authentication code. The system variable peer.hostkeyid is used for active associations. The peer.peerkeyid variable is
initialized at zero (unspecified) when the association is mobilized. For purposes of
authentication an unassigned value is interpreted as zero (unspecified).
Cryptographic Keys (sys.key): This is a set of 64-bit DES keys. Each key is constructed as in the Berkeley Unix distributions, which
consists of eight octets, where the seven low-order bits of each octet correspond to the DES bits 1-7 and the high-order bit
corresponds to the DES
odd-parity bit 8. By convention, the unspecified key 0 (zero), consisting of eight odd-parity zero octets, is used for testing and
presumed known throughout the NTP community. The remaining keys are distributed using methods outside the scope of NTP.
Crypto-Checksum (pkt.check): This is a crypto-checksum computed by the encryption procedure.
The authenticator field consists of two subfields, one consisting of the pkt.keyid variable and the other the pkt.check variable
computed by the encrypt procedure, which is called by the transmit procedure described in the NTP specification, and by the decrypt
procedure, which is called by the receive procedure described in the NTP specification. Its presence is revealed by the fact the total
datagram length according to the UDP header is longer than the NTP message length, which includes the header plus the data field, if
present. For authentication purposes, the
NTP message is zero-padded if necessary to a 64-bit boundary, although the padding bits are not considered part of the NTP message
itself. The authenticator format shown in Figure 7<$&fig7> has 96 bits, including a 32-bit key identifier and 64-bit
crypto-checksum, and is aligned on a 32-bit boundary for efficient computation. Additional information required in some
implementations, such as certificate authority and encryption algorithm, can be inserted between the (padded) NTP message and the key
identifier, as long as the alignment conditions are met. Like the authenticator itself, this information is not included in the
crypto-checksum. Use of these data are beyond the scope of this specification. These conventions may be changed in future as the
result of other standardization activities.
NTP Authentication Procedures
When authentication is implemented there are two additional procedures added to those described in the NTP specification. One of these
(encrypt) constructs the crypto-checksum in transmitted messages, while the other (decrypt) checks this quantity in received messages.
The procedures use a variant of the cipher-block chaining method described in [NBS80] as applied to DES. In principal, the procedure
is independent of DES and requires only that the encryption algorithm operate on 64-bit blocks. While the NTP authentication mechanism
specifies the use of DES, other algorithms could be used by prior arrangement.
For ordinary NTP messages the encryption procedure operates as follows. If authentication is not enabled, the procedure simply exits.
If the association is active (modes 1, 3, 5), the key is determined from the system key identifier. If the association is passive
(modes 2, 4) the key is determined from the peer key identifier, if the authentic bit is set, or as the default key (zero) otherwise.
These conventions allow further protection against replay attacks and keying errors, as well as facilitate testing and migration to
new versions. The crypto-checksum is calculated using the 64-bit NTP header and data words, but not the authenticator or padding
begin encrypt procedure
if (peer.authenable = 0) exit; /* do nothing if not enabled */
if (peer.hostmode = 1 or peer.hostmode = 3 or peer.hostmode =5)
keyid <-- peer.hostkeyid; /* active modes use system key */
if (peer.authentic = 1) /* passive modes use peer key */
keyid <-- peer.peerkeyid;
keyid <-- 0; /* unauthenticated use key 0 */
temp <-- 0; /* calculate crypto-checksum */
for (each 64-bit header and data word) begin
temp <-- temp xor word;
temp <-- DES (temp,keyid);
pkt.keyid <-- keyid; /* insert packet variables */
pkt.check <-- temp;
end encrypt procedure;
For ordinary messages the decryption procedure operates as follows. If the peer is not configured, the data portion of the message is
inspected to determine if the authenticator fields are present. If so, authentication is enabled; otherwise, it is disabled. If
authentication is enabled and the authenticator fields are present and the crypto-checksum succeeds, the authentication bit is set to
one; otherwise, it is set to zero.
begin decrypt procedure
peer.authentic <-- 0;
if (peer.config =0) /* if not configured, enable per packet */
if (authenticator present)
peer.authenable <-- 1;
peer.authenable <-- 0;
if (peer.authenable = 0 or authenticator not present)) exit;
peer.peerkeyid <-- pkt.keyid; /* use peer key */
temp <-- 0; /* calculate crypto-checksum */
for (each 64-bit header and data word) begin
temp <-- temp xor word;
temp <-- DES (temp, peer.peerkeyid);
if (temp == pkt.check) peer.authentic <-- 1; /* declare result */
end decrypt procedure;
In anticipation that the functions provided by the NTP control messages will eventually be subsumed by a comprehensive
network-managment function, the peer variables are not used for control message
authentication. If an NTP command message is received with an authenticator field, the crypto-checksum is computed as in the decrypt
procedure and the response message includes the authenticator field as computed by the encrypt procedure. If the received
authenticator is correct, the key for the response is the same as in the command; otherwise, the default key (zero) is used. Commands
causing a change to the peer data base, such as the write variables and set trap address/port commands, must be correctly
authenticated; however, the remaining commands are normally not authenticated in order to minimize the encryption overhead.