Updating the NTP Registries Akamai Technologies
rsalz@akamai.com
INT ntp NTP extensions registries IANA The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of registries, collectively called the NTP registries. Some registries are correct, but some include incorrect assignments and some don't follow common practice. For the sake of completeness, this document reviews all NTP and NTS registries, and corrects the registries where necessary. This document updates RFCs 5905, 5906, 7821, 7822, and 8573.
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
  • .  Introduction
  • .  Existing Registries
    • .  Reference ID and Kiss-o'-Death Registries
    • .  Extension Field Types
    • .  Network Time Security Registries
  • .  NTP Registry Updates
    • .  Designated Experts
  • .  IANA Considerations
    • .  NTP Reference Identifier Codes
    • .  NTP Kiss-o'-Death Codes
    • .  NTP Extension Field Types
  • .  Security Considerations
  • .  Normative References
  • Acknowledgements
  • Author's Address
Introduction The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of registries, collectively called the NTP registries. The NTP registries can all be found at and the NTS registries can all be found at . Some registries are correct, but some include incorrect assignments and some don't follow common practice. For the sake of completeness, this document reviews all NTP and NTS registries, and corrects the registries where necessary. The bulk of this document can be divided into two parts:
  • a summary of the relevant registries, including syntax requirements, registration procedures, and the defining documents.
  • a revised format and entries for each registry being modified.
Existing Registries This section describes the registries and the rules for them. It is intended to be a short summary of the syntax and registration requirements for each registry. The semantics and protocol processing rules for each registry -- that is, how an implementation acts when sending or receiving any of the fields -- are not described here.
Reference ID and Kiss-o'-Death Registries defines two registries: "NTP Reference Identifier Codes" in Section and the "NTP Kiss-o'-Death Codes" in Section . Reference identifiers and kiss codes can be up to four ASCII characters, padded on the right with all-bits-zero if necessary. Entries that start with 0x58, the ASCII letter uppercase X, are reserved for Private or Experimental Use. Both registries are First Come First Served. The registries were created per .
Extension Field Types defines the on-the-wire format of extension fields but does not create a registry for them. mentions the "NTP Extension Field Types" registry, and defines it indirectly by defining 30 extensions (10 each for request, response, and error response). It does not provide a formal definition of the columns in the registry. splits the Field Type into four subfields, only for use within the Autokey extensions. adds a new entry, Checksum Complement, to the "NTP Extension Field Types" registry. clarifies the processing rules for Extension Field Types, particularly around the interaction with the Message Authentication Code (MAC) field. NTPv4 packets may contain a MAC that appears where one would expect the next extension field header. changes the cryptography used in the MAC field. adds four new entries to the "NTP Extension Field Types" registry. The following problems exist with the current registry:
  • Many of the entries in the "NTP Extension Field Types" registry have swapped some of the nibbles; for example, 0x0302 was listed for Cookie Message Request instead of 0x0203. The errors are due to documentation errors with the original implementation of Autokey. This document marks the erroneous values as reserved, in case there is an implementation using the registered values instead of what the original implementation used. Applications that used those values would have realized that they did not interoperate with the dominant (if not only) implementation at the time. Marking the values as reserved ensures that any such applications continue to work as is.
  • Some values were mistakenly reused.
Network Time Security Registries defines the NTS protocol. The related registries are listed here for completeness, but there are no changes specified in this document. In : Sections through (inclusive) added entries to existing registries. Section created the "Network Time Security Key Establishment Record Types" registry that partitions the range into three different registration policies: IETF Review, Specification Required, and Private or Experimental Use. Section created the "Network Time Security Next Protocols" registry that similarly partitions the range. Section created the "Network Time Security Error Codes" and "Network Time Security Warning Codes" registries. Both registries are partitioned the same way.
NTP Registry Updates The following general guidelines apply to the NTP registries:
  • A partition of the "NTP Extension Field Types" registry is reserved for Private or Experimental Use.
  • In the "NTP Reference Identifier Codes" and "NTP Kiss-o'-Death Codes" registries, entries with ASCII fields are now limited to uppercase letters or digits. Fields starting with 0x58, the uppercase letter "X", are reserved for Private or Experimental Use.
  • The policy for each registry is now Specification Required, as defined in .
Designated Experts The IESG is requested to choose three designated experts (DEs), with approvals from two being required to implement a change. Guidance for the experts is given below. The DEs should be familiar with , particularly Section . As that reference suggests, the DE should ascertain the existence of a suitable specification and verify that it is publicly available. The DE is also expected to check the clarity of purpose and use of the requested code points. In addition, the DE is expected to be familiar with this document, specifically the history documented here.
IANA Considerations Each entry described in the subsections below is intended to completely replace the existing entry with the same name.
NTP Reference Identifier Codes The registration procedure has been changed to Specification Required and this document has been added as a reference. The Note has been changed to read as follows:
Codes beginning with the character "X" are reserved for experimentation and development. IANA cannot assign them.
The columns are defined as follows:
ID (required):
a four-byte value padded on the right with all-bits-zero. Each byte other than padding must be ASCII uppercase letters or digits.
Clock source (required):
a brief text description of the ID.
Reference (required):
the publication defining the ID.
The existing entries are left unchanged.
NTP Kiss-o'-Death Codes The registration procedure is changed to Specification Required and this document has been added as a reference. The Note has been changed to read as follows:
Codes beginning with the character "X" are reserved for experimentation and development. IANA cannot assign them.
The columns are defined as follows:
ID (required):
a four-byte value padded on the right with all-bits-zero. Each byte other than padding must be ASCII uppercase letters or digits.
Meaning source (required):
a brief text description of the ID.
Reference (required):
the publication defining the ID.
The existing entries are left unchanged.
NTP Extension Field Types The registration procedure has been changed to Specification Required and and this document have been added as references. The following two Notes have been added:
Field Types in the range 0xF000 through 0xFFFF, inclusive, are reserved for experimentation and development. IANA cannot assign them. Both NTS Cookie and Autokey Message Request have the same Field Type; in practice this is not a problem as the field semantics will be determined by other parts of the message.
The "Reserved for historic reasons" is for differences between the original documentation and implementation of Autokey and marks the erroneous values as reserved, in case there is an implementation that used the registered values instead of what the original implementation used.
The columns are defined as follows:
Field Type (required):
a two-byte value in hexadecimal.
Meaning (required):
a brief text description of the field type.
Reference (required):
the publication defining the field type.
IANA has updated the registry as shown in .
Field Type Meaning Reference
0x0000 Crypto-NAK; authentication failure
0x0002 Reserved for historic reasons RFC 9748
0x0102 Reserved for historic reasons RFC 9748
0x0104 Unique Identifier
0x0200 No-Operation Request
0x0201 Association Message Request
0x0202 Certificate Message Request
0x0203 Cookie Message Request
0x0204 Autokey Message Request
0x0204 NTS Cookie
0x0205 Leapseconds Message Request
0x0206 Sign Message Request
0x0207 IFF Identity Message Request
0x0208 GQ Identity Message Request
0x0209 MV Identity Message Request
0x0302 Reserved for historic reasons RFC 9748
0x0304 NTS Cookie Placeholder
0x0402 Reserved for historic reasons RFC 9748
0x0404 NTS Authenticator and Encrypted Extension Fields
0x0502 Reserved for historic reasons RFC 9748
0x0602 Reserved for historic reasons RFC 9748
0x0702 Reserved for historic reasons RFC 9748
0x0802 Reserved for historic reasons RFC 9748
0x0902 Reserved for historic reasons RFC 9748
0x2005 UDP Checksum Complement
0x8002 Reserved for historic reasons RFC 9748
0x8102 Reserved for historic reasons RFC 9748
0x8200 No-Operation Response
0x8201 Association Message Response
0x8202 Certificate Message Response
0x8203 Cookie Message Response
0x8204 Autokey Message Response
0x8205 Leapseconds Message Response
0x8206 Sign Message Response
0x8207 IFF Identity Message Response
0x8208 GQ Identity Message Response
0x8209 MV Identity Message Response
0x8302 Reserved for historic reasons RFC 9748
0x8402 Reserved for historic reasons RFC 9748
0x8502 Reserved for historic reasons RFC 9748
0x8602 Reserved for historic reasons RFC 9748
0x8702 Reserved for historic reasons RFC 9748
0x8802 Reserved for historic reasons RFC 9748
0x8902 Reserved for historic reasons RFC 9748
0xC002 Reserved for historic reasons RFC 9748
0xC102 Reserved for historic reasons RFC 9748
0xC200 No-Operation Error Response
0xC201 Association Message Error Response
0xC202 Certificate Message Error Response
0xC203 Cookie Message Error Response
0xC204 Autokey Message Error Response
0xC205 Leapseconds Message Error Response
0xC206 Sign Message Error Response
0xC207 IFF Identity Message Error Response
0xC208 GQ Identity Message Error Response
0xC209 MV Identity Message Error Response
0xC302 Reserved for historic reasons RFC 9748
0xC402 Reserved for historic reasons RFC 9748
0xC502 Reserved for historic reasons RFC 9748
0xC602 Reserved for historic reasons RFC 9748
0xC702 Reserved for historic reasons RFC 9748
0xC802 Reserved for historic reasons RFC 9748
0xC902 Reserved for historic reasons RFC 9748
0xF000-0xFFFF Reserved for Private or Experimental Use RFC 9748
Security Considerations This document adds no new security considerations, as they are defined in the document that defines the extension. See the References column of the appropriate IANA registry.
Normative References Network Time Protocol Version 4: Protocol and Algorithms Specification The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK] Network Time Protocol Version 4: Autokey Specification This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions. This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of the protocol states, events, and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested, and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual Memory System (VMS) operating systems at http://www.ntp.org. This document is not an Internet Standards Track specification; it is published for informational purposes. UDP Checksum Complement in the Network Time Protocol (NTP) The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets of the packet rather than in the UDP Checksum field. The behavior defined in this document is interoperable with existing NTP implementations. Network Time Protocol Version 4 (NTPv4) Extension Fields The Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields. An extension field, as defined in RFC 5905, is an optional field that resides at the end of the NTP header and that can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes (MACs). Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Message Authentication Code for the Network Time Protocol The Network Time Protocol (NTP), as described in RFC 5905, states that NTP packets should be authenticated by appending NTP data to a 128-bit key and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC as described in RFC 4493 as a replacement. Network Time Security for the Network Time Protocol This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP). NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTS Extension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies.
Acknowledgements The members of the NTP Working Group helped a great deal. Notable contributors include:
  • , Red Hat
  • , formerly at Akamai Technologies
  • , Network Time Foundation
  • , formerly at IANA
  • , Tweede Golf
Author's Address Akamai Technologies
rsalz@akamai.com