1. Table of Contents

2. Overview of relevant standards

The principal standard informing the NTPsec software is RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification.

NTPsec has entirely dropped conformance with the Autokey feature described in RFC 5906: Network Time Protocol Version 4: Autokey Specification. Autokey never quite worked, and the design was unstable enough that if there was ever actually a time when it fully conformed to its RFC that span must have been pretty short.

RFC 5297: Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES) describes the authenticated encryption used in Network Time Security key exchanges.

Network Time Security is described by RFC 8915: Network Time Security for the Network Time Protocol.

3. Divergences from RFC 5905

Code conformance was never quite exact even before the NTPsec fork. In this section we attempt to list divergences. This list is probably not exhaustive.

Modes 5 (Broadcast) and 6 (Broadcast client) are no longer implemented in NTPsec, as they were impossible to secure. Mode 1 (Symmetric Active) is no longer implemented; such packets are treated as ordinary client (mode 3) packets. Mode 2 (Symmetric Passive) is still distinct from mode 3 but its only effect is on initial poll interval.

In figure 8 of section 7.3, 128 bits (16 octets, corresponding to an MD5 or AES-CMAC digest) is not the only possible length for the MAC. This was a pre-NTPsec change present in NTP Classic versions after 2010.

NTPsec conforms to the NTP Client Data Minimization draft RFC, which changes the client-side generation of some packet headers.

The table of reference identifiers in Figure 12 is largely obsolete and somewhat incomplete relative to the code.

In the table of KISS codes (Figure 13), only RATE still exists and is implemented in NTPsec; others proved unnecessary or (in the cases of DENY and RSTR) outright dangerous. INIT and STEP are no longer KoD types but persist as peer statuses that may be reported by ntpq(1)/ntpmon(1). NTPsec has additional codes DNS and NTS for preparatory phases in association setup.

The continuing relevance of much of Appendix A is doubtful.

4. Divergences from RFC 2030

In the packet-format illustration of section 4 (NTP Message Format) 128 is not the only possible bit length for a MAC. However, this field is not shipped in SNTP operation, so the flaw is theoretical.

Some packet mode values are, as previously noted, no longer implemented. Many External Reference Source types are obsolete. Broadcast, multicast and anycast modes are no longer implemented.

homeHome Page

sitemapSite Map