Akamai Technologies

rsalz@akamai.com

ntp NTP extensions registries IANA The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of assigned number registries, collectively called the NTP registries. Some registries have wrong values, some registries do not follow current common practice, and some are just right. For the sake of completeness, this document reviews all NTP and NTS registries. This document updates RFC 5905, RFC 5906, RFC 8573, RFC 7822, and RFC 7821. Notes This document is a product of the NTP Working Group. Source for this draft and an issue tracker can be found at . RFC Editor: Please update 'this RFC' to refer to this document, once its RFC number is known, through the document.

Introduction The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of assigned number registries, collectively called the NTP registries. Some registries have wrong values, some registries do not follow current common practice, and some are just right. For the sake of completeness, this document reviews all NTP and NTS registries. The bulk of this document can be divided into two parts:

• First, each registry, its defining document, and a summary of its syntax is defined.
• Second, the revised format and entries for each registry that is being modified is specified.

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, Kiss-o'-Death defined two registries; the Reference ID in Section 7.3, and the Kiss-o'-Death in Section 7.4. Both of these are allowed to be 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 formal request to define the registries is in Section 16. defined the on-the-wire format of extension fields but did not create a registry for it.

Extension Field Types mentioned the Extension Field Types registry, and defined it indirectly by defining 30 extensions (15 each for request and response) in Section 13. It did 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. added a new entry, Checksum Complement, to the Extension Field Types registry. clarified the processing rules for Extension Field Types, particularly around the interaction with the Message Authentication Code (MAC) field. changed the cryptography used in the MAC field. The following problems exists with the current registry:

• Many of the entries in the Extension Field Types registry have swapped some of the nibbles; 0x1234 is listed as 0x1432 for example. This was due to documentation errors with the original implementation of Autokey. This document marks the erroneous values as reserved.
• Some values were mistakenly re-used.

Network Time Security Registries defines the NTS protocol. Its registries are listed here for completeness, but no changes to them are specified in this document. Sections 7.1 through 7.5 (inclusive) added entries to existing registries. Section 7.6 created a new registry, NTS Key Establishment Record Types, that partitions the assigned numbers into three different registration policies: IETF Review, Specification Required, and Private or Experimental Use. Section 7.7 created a new registry, NTS Next Protocols, that similarly partitions the assigned numbers. Section 7.8 created two new registries, NTS Error Codes and NTS Warning Codes. Both registries are also partitioned the same way.

Updated Registries The following general guidelines apply to all registries updated here:

• Every entry reserves a partition for Private or Experimentatal Use.
• Registries with ASCII fields are now limited to uppercase letters; fields starting with 0x2D, the ASCII minus sign, are reserved for Private or Experimental Use..
• The policy for every registry is now Specification Required, as defined in .

The IESG is requested to choose three designated experts, with two being required to approve a registry change. Each entry described in the sub-sections below is intended to completely replace the existing entry with the same name.

IANA Considerations

NTP Reference Identifier Codes The registration procedure is changed to Specification Required. The Note is changed to read as follows:

• Codes beginning with the character "-" 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 zeros. Each value must be an ASCII uppercase letter or minus sign
• 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. The Note is changed to read as follows:

• Codes beginning with the character "-" 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 zeros. Each value must be an ASCII uppercase letter or minus sign.
• 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 is changed to Specification Required. The reference should be added, if possible. The following Note is 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 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.

The table is replaced with the following entries.

Field Type	Meaning	Reference
0x0002	Reserved for historic reasons	This RFC
0x0102	Reserved for historic reasons	This RFC
0x0104	Unique Identifier	RFC 8915, Section 5.3
0x0200	No-Operation Request	RFC 5906
0x0201	Association Message Request	RFC 5906
0x0202	Certificate Message Request	RFC 5906
0x0203	Cookie Message Request	RFC 5906
0x0204	NTS Cookie	RFC 8915, Section 5.4
0x0204	Autokey Message Request	RFC 5906
0x0205	Leapseconds Message Request	RFC 5906
0x0206	Sign Message Request	RFC 5906
0x0207	IFF Identity Message Request	RFC 5906
0x0208	GQ Identity Message Request	RFC 5906
0x0209	MV Identity Message Request	RFC 5906
0x0302	Reserved for historic reasons	This RFC
0x0304	NTS Cookie Placeholder	RFC 8915, Section 5.5
0x0402	Reserved for historic reasons	This RFC
0x0404	NTS Authenticator and Encrypted Extension Fields	RFC 8915, Section 5.6
0x0502	Reserved for historic reasons	This RFC
0x0602	Reserved for historic reasons	This RFC
0x0702	Reserved for historic reasons	This RFC
0x2005	Reserved for historic reasons	This RFC
0x8002	Reserved for historic reasons	This RFC
0x8102	Reserved for historic reasons	This RFC
0x8200	No-Operation Response	RFC 5906
0x8201	Association Message Response	RFC 5906
0x8202	Certificate Message Response	RFC 5906
0x8203	Cookie Message Response	RFC 5906
0x8204	Autokey Message Response	RFC 5906
0x8205	Leapseconds Message Response	RFC 5906
0x8206	Sign Message Response	RFC 5906
0x8207	IFF Identity Message Response	RFC 5906
0x8208	GQ Identity Message Response	RFC 5906
0x8209	MV Identity Message Response	RFC 5906
0x8302	Reserved for historic reasons	This RFC
0x8402	Reserved for historic reasons	This RFC
0x8502	Reserved for historic reasons	This RFC
0x8602	Reserved for historic reasons	This RFC
0x8702	Reserved for historic reasons	This RFC
0x8802	Reserved for historic reasons	This RFC
0xC002	Reserved for historic reasons	This RFC
0xC102	Reserved for historic reasons	This RFC
0xC200	No-Operation Error Response	RFC 5906
0xC201	Association Message Error Response	RFC 5906
0xC202	Certificate Message Error Response	RFC 5906
0xC203	Cookie Message Error Response	RFC 5906
0xC204	Autokey Message Error Response	RFC 5906
0xC205	Leapseconds Message Error Response	RFC 5906
0xC206	Sign Message Error Response	RFC 5906
0xC207	IFF Identity Message Error Response	RFC 5906
0xC208	GQ Identity Message Error Response	RFC 5906
0xC209	MV Identity Message Error Response	RFC 5906
0xC302	Reserved for historic reasons	This RFC
0xC402	Reserved for historic reasons	This RFC
0xC502	Reserved for historic reasons	This RFC
0xC602	Reserved for historic reasons	This RFC
0xC702	Reserved for historic reasons	This RFC
0xC802	Reserved for historic reasons	This RFC
0x0902	Reserved for historic reasons	This RFC
0x8902	Reserved for historic reasons	This RFC
0xC902	Reserved for historic reasons	This RFC

Acknowledgements The members of the NTP Working Group helped a great deal. Notable contributors include:

• Miroslav Lichvar, Red Hat
• Daniel Franke, Akamai Technologies
• Danny Mayer, Network Time Foundation
• Michelle Cotton, IANA

Normative References 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] 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. 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. 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). 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. 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. 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.