rfc9748.original.xml   rfc9748.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.3. -ietf-ntp-update-registries-16" number="9748" category="std" consensus="true" su
3) --> bmissionType="IETF" obsoletes="" updates="5905, 5906, 7821, 7822, 8573" tocInclu
<?rfc compact="yes"?> de="true" sortRefs="true" symRefs="true" version="3" xml:lang="en">
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-ntp-update-registries-16" category="std" consensus="true" submissionType="
IETF" updates="5905, 5906, 8573, 7822, 7821" tocInclude="true" sortRefs="true" s
ymRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.22.0 -->
<front> <front>
<title>Updating the NTP Registries</title> <title>Updating the NTP Registries</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-ntp-update-registries-16 "/> <seriesInfo name="RFC" value="9748"/>
<author initials="R." surname="Salz" fullname="Rich Salz"> <author initials="R." surname="Salz" fullname="Rich Salz">
<organization>Akamai Technologies</organization> <organization>Akamai Technologies</organization>
<address> <address>
<email>rsalz@akamai.com</email> <email>rsalz@akamai.com</email>
</address> </address>
</author> </author>
<date year="2024" month="August" day="20"/> <date year="2025" month="February"/>
<area>INT</area>
<workgroup>ntp</workgroup> <workgroup>ntp</workgroup>
<keyword>NTP</keyword> <keyword>NTP</keyword>
<keyword>extensions</keyword> <keyword>extensions</keyword>
<keyword>registries</keyword> <keyword>registries</keyword>
<keyword>IANA</keyword> <keyword>IANA</keyword>
<abstract> <abstract>
<?line 34?>
<t>The Network Time Protocol (NTP) and Network Time Security (NTS) documents <t>The Network Time Protocol (NTP) and Network Time Security (NTS) documents
define a number of assigned number registries, collectively called the NTP define a number of registries, collectively called the NTP
registries.</t> registries.</t>
<t>Some registries have wrong values, some registries <t> Some registries are correct, but some include incorrect assignments
do not follow current common practice, and some are just right. and some don’t follow common practice. For the sake of completeness,
For the sake of completeness, this document reviews all NTP and NTS registries, this document reviews all NTP and NTS registries, and corrects the
and makes updates where necessary.</t> registries where necessary.</t>
<t>This document updates RFC 5905, RFC 5906, RFC 8573, RFC 7822, and
RFC 7821.</t> <t>This document updates RFCs 5905, 5906, 7821, 7822, and 8573.
</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Notes</name>
<t>This document is a product of the
<eref target="https://dt.ietf.org/wg/ntp">NTP Working Group</eref>.
Source for this draft and an issue tracker can be found at
<eref target="https://github.com/richsalz/draft-rsalz-update-registries"/>.
</t>
<t>RFC Editor: Please update 'this RFC' to refer to this document,
once its RFC number is known, through the document.</t>
</note>
</front> </front>
<middle> <middle>
<?line 48?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The Network Time Protocol (NTP) and Network Time Security (NTS) documen ts <t>The Network Time Protocol (NTP) and Network Time Security (NTS) documen ts
define a number of assigned number registries, collectively called the NTP define a number of registries, collectively called the NTP
registries. registries.
The NTP registries can all be found at The NTP registries can all be found at
<eref target="https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xht ml">https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml</eref> <eref target="https://www.iana.org/assignments/ntp-parameters" brackets="angle"/ >
and the NTS registries can all be found at and the NTS registries can all be found at
<eref target="https://www.iana.org/assignments/nts/nts.xhtml">https://www.iana.o <eref target="https://www.iana.org/assignments/nts" brackets="angle"/>.</t>
rg/assignments/nts/nts.xhtml</eref>.</t> <t>Some registries are correct, but some include incorrect assignments
<t>Some registries have wrong values, some registries and some don’t follow common practice. For the sake of completeness,
do not follow current common practice, and some are just right. this document reviews all NTP and NTS registries, and corrects the
For the sake of completeness, this document reviews all NTP and NTS registries, registries where necessary.</t>
and makes updates where necessary.</t>
<t>The bulk of this document can be divided into two parts:</t> <t>The bulk of this document can be divided into two parts:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>First, each registry, its defining document, and a summary of its <t>a summary of the relevant registries, including syntax requirements
syntax is defined.</t> ,
registration procedures, and the defining documents.</t>
</li> </li>
<li> <li>
<t>Second, the revised format and entries for each registry that is <t>a revised format and entries for each registry
being modified is specified.</t> being modified. </t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="existing-registries"> <section anchor="existing-registries">
<name>Existing Registries</name> <name>Existing Registries</name>
<t>This section describes the registries and the rules for them. <t>This section describes the registries and the rules for them.
It is intended to be a short summary of the syntax and registration It is intended to be a short summary of the syntax and registration
requirements for each registry. requirements for each registry.
The semantics and protocol processing rules for each registry -- that is, The semantics and protocol processing rules for each registry -- that is,
how an implementation acts when sending or receiving any of the fields -- how an implementation acts when sending or receiving any of the fields --
are not described here.</t> are not described here.</t>
<section anchor="reference-id-kiss-o-death"> <section anchor="reference-id-kiss-o-death">
<name>Reference ID, Kiss-o'-Death</name> <name>Reference ID and Kiss-o'-Death Registries</name>
<t><xref target="RFC5905"/> defined two registries; the Reference ID in
Section 7.3, and the <t><xref target="RFC5905"/> defines two registries:
Kiss-o'-Death in Section 7.4. Both of these are allowed to be four ASCII "NTP Reference Identifier Codes" in Section <xref target="RFC5905" sectio
characters; padded on the right with all-bits-zero if necessary. n="7.3" sectionFormat="bare"/> and the
"NTP Kiss-o'-Death Codes" in Section <xref target="RFC5905" section="7.4" sectio
nFormat="bare"/>. 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 Entries that start with 0x58, the ASCII
letter uppercase X, are reserved for Private or Experimental Use. letter uppercase X, are reserved for Private or Experimental Use.
Both registries are first-come first-served. The formal request to define Both registries are First Come First Served. The registries were created
the registries is in <xref section="16" sectionFormat="comma" target="RFC5905"/> per <xref section="16" sectionFormat="of" target="RFC5905"/>.</t>
.</t>
</section> </section>
<section anchor="extension-field-types"> <section anchor="extension-field-types">
<name>Extension Field Types</name> <name>Extension Field Types</name>
<t><xref section="7.5" sectionFormat="comma" target="RFC5905"/> defined <t><xref section="7.5" sectionFormat="of" target="RFC5905"/> defines the
the on-the-wire format of extension on-the-wire format of extension
fields but did not create a registry for them.</t> fields but does not create a registry for them.</t>
<t><xref section="13" sectionFormat="comma" target="RFC5906"/> mentioned <t><xref target="RFC5906" sectionFormat="of" section="13"/> mentions the
the Extension Field Types registry, and defined it "NTP Extension Field Types" registry, and defines it
indirectly by defining 30 extensions (10 each for request, response, and indirectly by defining 30 extensions (10 each for request, response, and
error response). error response).
It did not provide a formal definition of the columns in the registry. It does not provide a formal definition of the columns in the registry.
<xref section="10" sectionFormat="comma" target="RFC5906"/> splits the Field Typ <xref section="10" sectionFormat="of" target="RFC5906"/> splits the Field Type i
e into four subfields, nto four subfields,
only for use within the Autokey extensions.</t> only for use within the Autokey extensions.</t>
<t><xref target="RFC7821"/> added a new entry, Checksum Complement, to t <t><xref target="RFC7821"/> adds a new entry, Checksum Complement, to th
he Extension e "NTP Extension Field Types" registry.</t>
Field Types registry.</t> <t><xref target="RFC7822"/> clarifies the processing rules for Extension
<t><xref target="RFC7822"/> clarified the processing rules for Extension Field Types,
Field Types,
particularly around the interaction with the Message Authentication particularly around the interaction with the Message Authentication
Code (MAC) field. NTPv4 packets may contain a MAC that appears where Code (MAC) field. NTPv4 packets may contain a MAC that appears where
one would expect the next extension field header.</t> one would expect the next extension field header.</t>
<t><xref target="RFC8573"/> changed the cryptography used in the MAC fie <t><xref target="RFC8573"/> changes the cryptography used in the MAC fie
ld.</t> ld.</t>
<t><xref target="RFC8915"/> added four new entries to the Extension Fiel <t><xref target="RFC8915"/> adds four new entries to the "NTP Extension
d Types registry.</t> Field Types" registry.</t>
<t>The following problems exist with the current registry:</t> <t>The following problems exist with the current registry:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Many of the entries in the Extension Field Types registry have
swapped some of the nibbles; 0x1234 is listed as 0x1432 for example. <t>Many of the entries in the "NTP Extension Field Types" registry h
This was due to documentation errors with the original implementation ave
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. of Autokey.
This document marks the erroneous values as reserved, in case there This document marks the erroneous values as reserved, in case there
is an implementation that used the registered values is an implementation using the registered values
instead of what the original implementation used. instead of what the original implementation used.
Applications that might have used those values would have realized Applications that used those values would have realized
that they did not interoperate with the dominant (if not only) that they did not interoperate with the dominant (if not only)
implementation at the time. implementation at the time.
Marking the values as reserved ensures that any such applications would still Marking the values as reserved ensures that any such applications continue
be able to work as-is.</t> to work as is.</t>
</li> </li>
<li> <li>
<t>Some values were mistakenly re-used.</t> <t>Some values were mistakenly reused.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="network-time-security-registries"> <section anchor="network-time-security-registries">
<name>Network Time Security Registries</name> <name>Network Time Security Registries</name>
<t><xref target="RFC8915"/> defines the NTS protocol. <t><xref target="RFC8915"/> defines the NTS protocol.
Its registries are listed here for completeness, but no changes The related registries are listed here for completeness, but there are no
to them are specified in this document.</t> changes specified in this document.</t>
<t>Sections 7.1 through 7.5 (inclusive) added entries to existing regist
ries.</t> <t>In <xref target="RFC8915"/>:</t>
<t>Section 7.6 created a new registry, NTS Key Establishment Record Type <t>Sections <xref target="RFC8915" section="7.1" sectionFormat="bare"/>
s, through <xref target="RFC8915" section="7.5" sectionFormat="bare"/> (inclusive)
that partitions the assigned numbers into three different registration added entries to existing registries.</t>
policies: IETF Review, Specification Required, and Private or Experimental Use.<
/t> <t>Section <xref target="RFC8915" section="7.6" sectionFormat="bare"/> c
<t>Section 7.7 created a new registry, NTS Next Protocols, reated the "Network Time Security Key Establishment Record Types" registry that
that similarly partitions the assigned numbers.</t> partitions the range into three different registration policies:
<t>Section 7.8 created two new registries, NTS Error Codes and NTS Warni IETF Review, Specification Required, and Private or Experimental Use.</t>
ng Codes. <t>Section <xref target="RFC8915" section="7.7" sectionFormat="bare"/> c
Both registries are also partitioned the same way.</t> reated the "Network Time Security Next Protocols" registry that similarly partit
ions the range.</t>
<t>Section <xref target="RFC8915" section="7.8" sectionFormat="bare"/> c
reated the "Network Time Security Error Codes" and "Network Time Security Warnin
g Codes" registries.
Both registries are partitioned the same way.</t>
</section> </section>
</section> </section>
<section anchor="updated-registries">
<name>Updated Registries</name> <section anchor="registry-updates">
<t>The following general guidelines apply to all registries updated here:< <name>NTP Registry Updates</name>
/t> <t>The following general guidelines apply to the NTP registries:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Every registry reserves a partition for Private or Experimental Use .</t> <t>A partition of the "NTP Extension Field Types" registry is reserved for Private or Experimental Use.</t>
</li> </li>
<li> <li>
<t>Entries with ASCII fields are now limited to uppercase letters or d igits; fields <t>In the "NTP Reference Identifier Codes" and "NTP Kiss-o'-Death Code s" 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 starting with 0x58, the uppercase letter "X", are reserved for Private or
Experimental Use.</t> Experimental Use.</t>
</li> </li>
<li> <li>
<t>The policy for every registry is now Specification Required, as def ined <t>The policy for each registry is now Specification Required, as defi ned
in <xref section="4.6" sectionFormat="comma" target="RFC8126"/>.</t> in <xref section="4.6" sectionFormat="comma" target="RFC8126"/>.</t>
</li> </li>
</ul> </ul>
<t>The IESG is requested to choose three designated experts, with two bein
g <section anchor="designated-experts">
required to approve a registry change. Guidance for such experts is <name>Designated Experts</name>
given below.</t> <t>The IESG is requested to choose three designated experts (DEs), with ap
<t>Each entry described in the sub-sections below is intended to completel provals from two being required to implement a change. Guidance for the experts
y is given below.</t>
replace the existing entry with the same name.</t> <t>The DEs should be familiar with <xref target="RFC8126"/>, particularl
<section anchor="guidance-to-designated-experts"> y
<name>Guidance to Designated Experts</name> Section <xref target="RFC8126" section="5" sectionFormat="bare"/>. As that refer
<t>The designated experts (DE) should be familiar with <xref target="RFC ence suggests, the DE should ascertain the existence
8126"/>, particularly of a suitable specification and verify that it is publicly available. The DE
Section 5. 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 is also expected to check the clarity of purpose and use of the requested
code points.</t> code points.</t>
<t>In addition, the DE is expected to be familiar with this document, <t>In addition, the DE is expected to be familiar with this document,
specifically the history documented here.</t> specifically the history documented here.</t>
</section>
</section> </section>
</section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>Each entry described in the subsections below is intended to completely
replace the existing entry with the same name.</t>
<section anchor="ntp-reference-identifier-codes"> <section anchor="ntp-reference-identifier-codes">
<name>NTP Reference Identifier Codes</name> <name>NTP Reference Identifier Codes</name>
<t>The registration procedure is changed to Specification Required.</t>
<t>The Note is changed to read as follows:</t> <t>The registration procedure has been changed to Specification Required
<ul spacing="normal"> and this document has been added as a reference.</t>
<li> <t>The Note has been changed to read as follows:</t>
<t>Codes beginning with the character "X" are reserved for experimen
tation <blockquote>Codes beginning with the character "X" are reserved for
and development. IANA cannot assign them.</t> experimentation and development. IANA cannot assign them.</blockquote>
</li>
</ul>
<t>The columns are defined as follows:</t> <t>The columns are defined as follows:</t>
<ul spacing="normal"> <dl spacing="compact" newline="false">
<li> <dt>ID (required):</dt><dd> a four-byte value padded on the right
<t>ID (required): a four-byte value padded on the right with all-bit with all-bits-zero. Each byte other than padding must be ASCII
s-zero. uppercase letters or digits.</dd>
Each byte other than padding must be an ASCII uppercase letter or digits.</t> <dt>Clock source (required):</dt><dd>a brief text description of the I
</li> D.</dd>
<li> <dt>Reference (required):</dt><dd>the publication defining the ID.</dd
<t>Clock source (required): A brief text description of the ID.</t> >
</li> </dl>
<li>
<t>Reference (required): the publication defining the ID.</t>
</li>
</ul>
<t>The existing entries are left unchanged.</t> <t>The existing entries are left unchanged.</t>
</section> </section>
<section anchor="ntp-kiss-o-death-codes"> <section anchor="ntp-kiss-o-death-codes">
<name>NTP Kiss-o'-Death Codes</name> <name>NTP Kiss-o'-Death Codes</name>
<t>The registration procedure is changed to Specification Required.</t> <t>The registration procedure is changed to Specification Required and t
<t>The Note is changed to read as follows:</t> his document has been added as a reference.</t>
<ul spacing="normal"> <t>The Note has been changed to read as follows:</t>
<li>
<t>Codes beginning with the character "X" are reserved for experimen <blockquote>Codes beginning with the character "X" are reserved for
tation experimentation and development. IANA cannot assign them.</blockquote>
and development. IANA cannot assign them.</t>
</li>
</ul>
<t>The columns are defined as follows:</t> <t>The columns are defined as follows:</t>
<ul spacing="normal"> <dl spacing="compact" newline="false">
<li> <dt>ID (required):</dt><dd>a four-byte value padded on the right
<t>ID (required): a four-byte value padded on the right with all-bit with all-bits-zero. Each byte other than padding must be ASCII
s-zero. uppercase letters or digits.</dd>
Each byte other than padding must be an ASCII uppercase letter or digits.</t> <dt>Meaning source (required):</dt><dd>a brief text description of the
</li> ID.</dd>
<li> <dt>Reference (required):</dt><dd>the publication defining the ID.</dd
<t>Meaning source (required): A brief text description of the ID.</t >
> </dl>
</li>
<li>
<t>Reference (required): the publication defining the ID.</t>
</li>
</ul>
<t>The existing entries are left unchanged.</t> <t>The existing entries are left unchanged.</t>
</section> </section>
<section anchor="ntp-extension-field-types"> <section anchor="ntp-extension-field-types">
<name>NTP Extension Field Types</name> <name>NTP Extension Field Types</name>
<t>The registration procedure is changed to Specification Required.</t>
<t>The reference <xref target="RFC5906"/> should be added, if possible.< <t>The registration procedure has been changed to Specification Required
/t> and <xref target="RFC5906"/> and this document have been added as references.</
<t>The following two Notes are added:</t> t>
<ul spacing="normal"> <t>The following two Notes have been added:</t>
<li>
<t>Field Types in the range 0xF000 through 0xFFFF, inclusive, are re <blockquote>Field Types in the range 0xF000 through 0xFFFF,
served inclusive, are reserved for experimentation and development. IANA
for experimentation and development. IANA cannot assign them. cannot assign them. Both NTS Cookie and Autokey Message Request have
Both NTS Cookie and Autokey Message Request have the same Field Type; the same Field Type; in practice this is not a problem as the field
in practice this is not a problem as the field semantics will be semantics will be determined by other parts of the message.</blockquote>
determined by other parts of the message.</t>
</li> <blockquote>The "Reserved for historic reasons" is for differences
<li> between the original documentation and implementation of Autokey and
<t>The "Reserved for historic reasons" is for differences between th marks the erroneous values as reserved, in case there is an
e implementation that used the registered values instead of what the
original documentation and implementation of Autokey and marks original implementation used.</blockquote>
the erroneous values as reserved, in case there is an implementation
that used the registered values instead of what the original
implementation used.</t>
</li>
</ul>
<t>The columns are defined as follows:</t> <t>The columns are defined as follows:</t>
<ul spacing="normal"> <dl spacing="compact" newline="false">
<li> <dt>Field Type (required):</dt><dd>a two-byte value in hexadecimal.</d
<t>Field Type (required): A two-byte value in hexadecimal.</t> d>
</li> <dt>Meaning (required):</dt><dd>a brief text description of the field
<li> type.</dd>
<t>Meaning (required): A brief text description of the field type.</ <dt>Reference (required):</dt><dd>the publication defining the field t
t> ype.</dd>
</li> </dl>
<li>
<t>Reference (required): the publication defining the field type.</t <t>IANA has updated the registry as shown in <xref target="tab1"/>.</t>
> <table anchor="tab1">
</li>
</ul>
<t>The table is replaced with the following entries.
IANA is requested to replace "This RFC" with the actual RFC number once
assigned.</t>
<table>
<thead> <thead>
<tr> <tr>
<th align="left">Field Type</th> <th align="left">Field Type</th>
<th align="left">Meaning</th> <th align="left">Meaning</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0x0000</td> <td align="left">0x0000</td>
<td align="left">Crypto-NAK; authentication failure</td> <td align="left">Crypto-NAK; authentication failure</td>
<td align="left">RFC 5905</td> <td align="left"><xref target="RFC5905"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0002</td> <td align="left">0x0002</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0102</td> <td align="left">0x0102</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0104</td> <td align="left">0x0104</td>
<td align="left">Unique Identifier</td> <td align="left">Unique Identifier</td>
<td align="left">RFC 8915, Section 5.3</td> <td align="left"><xref target="RFC8915" sectionFormat="comma" sect ion="5.3"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0200</td> <td align="left">0x0200</td>
<td align="left">No-Operation Request</td> <td align="left">No-Operation Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0201</td> <td align="left">0x0201</td>
<td align="left">Association Message Request</td> <td align="left">Association Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0202</td> <td align="left">0x0202</td>
<td align="left">Certificate Message Request</td> <td align="left">Certificate Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0203</td> <td align="left">0x0203</td>
<td align="left">Cookie Message Request</td> <td align="left">Cookie Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0204</td> <td align="left">0x0204</td>
<td align="left">Autokey Message Request</td> <td align="left">Autokey Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0204</td> <td align="left">0x0204</td>
<td align="left">NTS Cookie</td> <td align="left">NTS Cookie</td>
<td align="left">RFC 8915, Section 5.4</td> <td align="left"><xref target="RFC8915" sectionFormat="comma" sect ion="5.4"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0205</td> <td align="left">0x0205</td>
<td align="left">Leapseconds Message Request</td> <td align="left">Leapseconds Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0206</td> <td align="left">0x0206</td>
<td align="left">Sign Message Request</td> <td align="left">Sign Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0207</td> <td align="left">0x0207</td>
<td align="left">IFF Identity Message Request</td> <td align="left">IFF Identity Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0208</td> <td align="left">0x0208</td>
<td align="left">GQ Identity Message Request</td> <td align="left">GQ Identity Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0209</td> <td align="left">0x0209</td>
<td align="left">MV Identity Message Request</td> <td align="left">MV Identity Message Request</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0302</td> <td align="left">0x0302</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0304</td> <td align="left">0x0304</td>
<td align="left">NTS Cookie Placeholder</td> <td align="left">NTS Cookie Placeholder</td>
<td align="left">RFC 8915, Section 5.5</td> <td align="left"><xref target="RFC8915" sectionFormat="comma" sect ion="5.5"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0402</td> <td align="left">0x0402</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0404</td> <td align="left">0x0404</td>
<td align="left">NTS Authenticator and Encrypted Extension Fields< /td> <td align="left">NTS Authenticator and Encrypted Extension Fields< /td>
<td align="left">RFC 8915, Section 5.6</td> <td align="left"><xref target="RFC8915" sectionFormat="comma" sect ion="5.6"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0502</td> <td align="left">0x0502</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0602</td> <td align="left">0x0602</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0702</td> <td align="left">0x0702</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr>
<tr>
<td align="left">0x0802</td>
<td align="left">Reserved for historic reasons</td>
<td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x0902</td> <td align="left">0x0902</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x2005</td> <td align="left">0x2005</td>
<td align="left">UDP Checksum Complement</td> <td align="left">UDP Checksum Complement</td>
<td align="left">RFC 7821</td> <td align="left"><xref target="RFC7821"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8002</td> <td align="left">0x8002</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8102</td> <td align="left">0x8102</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8200</td> <td align="left">0x8200</td>
<td align="left">No-Operation Response</td> <td align="left">No-Operation Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8201</td> <td align="left">0x8201</td>
<td align="left">Association Message Response</td> <td align="left">Association Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8202</td> <td align="left">0x8202</td>
<td align="left">Certificate Message Response</td> <td align="left">Certificate Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8203</td> <td align="left">0x8203</td>
<td align="left">Cookie Message Response</td> <td align="left">Cookie Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8204</td> <td align="left">0x8204</td>
<td align="left">Autokey Message Response</td> <td align="left">Autokey Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8205</td> <td align="left">0x8205</td>
<td align="left">Leapseconds Message Response</td> <td align="left">Leapseconds Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8206</td> <td align="left">0x8206</td>
<td align="left">Sign Message Response</td> <td align="left">Sign Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8207</td> <td align="left">0x8207</td>
<td align="left">IFF Identity Message Response</td> <td align="left">IFF Identity Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8208</td> <td align="left">0x8208</td>
<td align="left">GQ Identity Message Response</td> <td align="left">GQ Identity Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8209</td> <td align="left">0x8209</td>
<td align="left">MV Identity Message Response</td> <td align="left">MV Identity Message Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8302</td> <td align="left">0x8302</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8402</td> <td align="left">0x8402</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8502</td> <td align="left">0x8502</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8602</td> <td align="left">0x8602</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8702</td> <td align="left">0x8702</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8802</td> <td align="left">0x8802</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0x8902</td> <td align="left">0x8902</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC002</td> <td align="left">0xC002</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC102</td> <td align="left">0xC102</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC200</td> <td align="left">0xC200</td>
<td align="left">No-Operation Error Response</td> <td align="left">No-Operation Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC201</td> <td align="left">0xC201</td>
<td align="left">Association Message Error Response</td> <td align="left">Association Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC202</td> <td align="left">0xC202</td>
<td align="left">Certificate Message Error Response</td> <td align="left">Certificate Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC203</td> <td align="left">0xC203</td>
<td align="left">Cookie Message Error Response</td> <td align="left">Cookie Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC204</td> <td align="left">0xC204</td>
<td align="left">Autokey Message Error Response</td> <td align="left">Autokey Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC205</td> <td align="left">0xC205</td>
<td align="left">Leapseconds Message Error Response</td> <td align="left">Leapseconds Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC206</td> <td align="left">0xC206</td>
<td align="left">Sign Message Error Response</td> <td align="left">Sign Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC207</td> <td align="left">0xC207</td>
<td align="left">IFF Identity Message Error Response</td> <td align="left">IFF Identity Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC208</td> <td align="left">0xC208</td>
<td align="left">GQ Identity Message Error Response</td> <td align="left">GQ Identity Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC209</td> <td align="left">0xC209</td>
<td align="left">MV Identity Message Error Response</td> <td align="left">MV Identity Message Error Response</td>
<td align="left">RFC 5906</td> <td align="left"><xref target="RFC5906"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC302</td> <td align="left">0xC302</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC402</td> <td align="left">0xC402</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC502</td> <td align="left">0xC502</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC602</td> <td align="left">0xC602</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC702</td> <td align="left">0xC702</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC802</td> <td align="left">0xC802</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xC902</td> <td align="left">0xC902</td>
<td align="left">Reserved for historic reasons</td> <td align="left">Reserved for historic reasons</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
<tr> <tr>
<td align="left">0xF000-<br/>0xFFFF</td> <td align="left">0xF000-0xFFFF</td>
<td align="left">Reserved for Experimental Use</td> <td align="left">Reserved for Experimental Use</td>
<td align="left">This RFC</td> <td align="left">RFC 9748</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document adds no new security considerations, as they are defined <t>This document adds no new security considerations, as they are defined
in the document that defines the extension. See the References column of the in the document that defines the extension. See the References column of the
appropriate table.</t> appropriate IANA registry.</t>
</section> </section>
<section anchor="acknowledgements">
</middle>
<back>
<references anchor="sec-normative-references">
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.590
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.590
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.782
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.782
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.812
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.857
3.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.891
5.xml"/>
</references>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The members of the NTP Working Group helped a great deal. <t>The members of the NTP Working Group helped a great deal.
Notable contributors include:</t> Notable contributors include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Miroslav Lichvar, Red Hat</t> <t><contact fullname="Miroslav Lichvar"/>, Red Hat</t>
</li> </li>
<li> <li>
<t>Daniel Franke, formerly at Akamai Technologies</t> <t><contact fullname="Daniel Franke"/>, formerly at Akamai Technologie s</t>
</li> </li>
<li> <li>
<t>Danny Mayer, Network Time Foundation</t> <t><contact fullname="Danny Mayer"/>, Network Time Foundation</t>
</li> </li>
<li> <li>
<t>Michelle Cotton, formerly at IANA</t> <t><contact fullname="Michelle Cotton"/>, formerly at IANA</t>
</li> </li>
<li> <li>
<t>Tamme Dittrich, Tweede Golf</t> <t><contact fullname="Tamme Dittrich"/>, Tweede Golf</t>
</li> </li>
</ul> </ul>
</section> </section>
</middle>
<back>
<references anchor="sec-normative-references">
<name>Normative References</name>
<reference anchor="RFC5905">
<front>
<title>Network Time Protocol Version 4: Protocol and Algorithms Specif
ication</title>
<author fullname="D. Mills" initials="D." surname="Mills"/>
<author fullname="J. Martin" initials="J." role="editor" surname="Mart
in"/>
<author fullname="J. Burbank" initials="J." surname="Burbank"/>
<author fullname="W. Kasch" initials="W." surname="Kasch"/>
<date month="June" year="2010"/>
<abstract>
<t>The Network Time Protocol (NTP) is widely used to synchronize com
puter clocks in the Internet. This document describes NTP version 4 (NTPv4), whi
ch 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 h
eader to accommodate the Internet Protocol version 6 address family. NTPv4 inclu
des fundamental improvements in the mitigation and discipline algorithms that ex
tend 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 c
ases, specific server configuration is not required. It corrects certain errors
in the NTPv3 design and implementation and includes an optional extension mechan
ism. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5905"/>
<seriesInfo name="DOI" value="10.17487/RFC5905"/>
</reference>
<reference anchor="RFC5906">
<front>
<title>Network Time Protocol Version 4: Autokey Specification</title>
<author fullname="B. Haberman" initials="B." role="editor" surname="Ha
berman"/>
<author fullname="D. Mills" initials="D." surname="Mills"/>
<date month="June" year="2010"/>
<abstract>
<t>This memo describes the Autokey security model for authenticating
servers to clients using the Network Time Protocol (NTP) and public key cryptog
raphy. Its design is based on the premise that IPsec schemes cannot be adopted i
ntact, since that would preclude stateless servers and severely compromise timek
eeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume au
thenticated time values are always available to enforce certificate lifetimes; h
owever, cryptographically verified timestamps require interaction between the ti
mekeeping and authentication functions.</t>
<t>This memo includes the Autokey requirements analysis, design prin
ciples, and protocol specification. A detailed description of the protocol state
s, events, and transition functions is included. A prototype of the Autokey desi
gn based on this memo has been implemented, tested, and documented in the NTP ve
rsion 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 In
ternet Standards Track specification; it is published for informational purposes
.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5906"/>
<seriesInfo name="DOI" value="10.17487/RFC5906"/>
</reference>
<reference anchor="RFC7821">
<front>
<title>UDP Checksum Complement in the Network Time Protocol (NTP)</tit
le>
<author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
<date month="March" year="2016"/>
<abstract>
<t>The Network Time Protocol (NTP) allows clients to synchronize to
a time server using timestamped protocol messages. To facilitate accurate timest
amping, some implementations use hardware-based timestamping engines that integr
ate the accurate transmission time into every outgoing NTP packet during transmi
ssion. Since these packets are transported over UDP, the UDP Checksum field is t
hen updated to reflect this modification. This document proposes an extension fi
eld that includes a 2-octet Checksum Complement, allowing timestamping engines t
o reflect the checksum modification in the last 2 octets of the packet rather th
an in the UDP Checksum field. The behavior defined in this document is interoper
able with existing NTP implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7821"/>
<seriesInfo name="DOI" value="10.17487/RFC7821"/>
</reference>
<reference anchor="RFC7822">
<front>
<title>Network Time Protocol Version 4 (NTPv4) Extension Fields</title
>
<author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
<author fullname="D. Mayer" initials="D." surname="Mayer"/>
<date month="March" year="2016"/>
<abstract>
<t>The Network Time Protocol version 4 (NTPv4) defines the optional
usage of extension fields. An extension field, as defined in RFC 5905, is an opt
ional field that resides at the end of the NTP header and that can be used to ad
d optional capabilities or additional information that is not conveyed in the st
andard NTP header. This document updates RFC 5905 by clarifying some points rega
rding NTP extension fields and their usage with Message Authentication Codes (MA
Cs).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7822"/>
<seriesInfo name="DOI" value="10.17487/RFC7822"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</
title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use const
ants to identify various protocol parameters. To ensure that the values in these
fields do not have conflicting uses and to promote interoperability, their allo
cations are often coordinated by a central record keeper. For IETF protocols, th
at role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance descr
ibing 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 d
efines a framework for the documentation of these guidelines by specification au
thors, 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.</t>
<t>This is the third edition of this document; it obsoletes RFC 5226
.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8573">
<front>
<title>Message Authentication Code for the Network Time Protocol</titl
e>
<author fullname="A. Malhotra" initials="A." surname="Malhotra"/>
<author fullname="S. Goldberg" initials="S." surname="Goldberg"/>
<date month="June" year="2019"/>
<abstract>
<t>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 deprecat
es MD5-based authentication, which is considered too weak, and recommends the us
e of AES-CMAC as described in RFC 4493 as a replacement.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8573"/>
<seriesInfo name="DOI" value="10.17487/RFC8573"/>
</reference>
<reference anchor="RFC8915">
<front>
<title>Network Time Security for the Network Time Protocol</title>
<author fullname="D. Franke" initials="D." surname="Franke"/>
<author fullname="D. Sibold" initials="D." surname="Sibold"/>
<author fullname="K. Teichel" initials="K." surname="Teichel"/>
<author fullname="M. Dansarie" initials="M." surname="Dansarie"/>
<author fullname="R. Sundblad" initials="R." surname="Sundblad"/>
<date month="September" year="2020"/>
<abstract>
<t>This memo specifies Network Time Security (NTS), a mechanism for
using Transport Layer Security (TLS) and Authenticated Encryption with Associate
d Data (AEAD) to provide cryptographic security for the client-server mode of th
e Network Time Protocol (NTP).</t>
<t>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 fiel
ds in the NTP packets, and holds all required state only on the client via opaqu
e cookies.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8915"/>
<seriesInfo name="DOI" value="10.17487/RFC8915"/>
</reference>
</references>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+1bW3PbxhV+31+x4zzU7pCM7paZTKcqJbma1G5qKW1nOp3O
EliSW4FYFguIYmr/937n7C4IUCAth3loptVMEhLAnvv5zgVMv98XqU1yNddD
mRZqUvaNLif9vFz0q0WqSt0v9NS4sjDa9Q/PhL/ohvL0zcFpj/591pPnp6+P
e/L1+dER//tQlKbMQPAHetjkU1nOtHx/9738UNMSCchMbbEaSlemAhe1mg/l
zdXdtVja4n5a2GoxlJBDmEUxlGVRufLo4ODNwZHA0ypP/6Eym4PJCsQWZiik
LG3iv0rpbAGKE1d/X82bXxM7X6ikrO9W4/pKboW41yvIkA7l3yB0T+rHUufO
2Nz15NoaPXlz8f7i70KoqpzZggTo4x8pvTE/mGQmb1X2I1+zxXQoL+7VXBl5
p5NZbjM7NcxcSo2r2VAWDk//VvFDA8gjclvMYb8HTbQ/XI/I5MP4ob50Fi+d
+UvkgGH8UF86ipeO/KXzwyN/kD6ES/DiMH4Il94ceo70QYh+vy/VGOrDUkLc
kVN1Sd6Sd2au5feFhQtsJl/CbK8kfNS+f6uTqjDliu7fvpKIu2qu89KJVE9M
rqWSeTUf60LaiVTOmWmu03ipaXewyHRChslWMlH4ksYIE+vnBkLcWnBdX5Ez
9aDlsrCIyAeVVUTLtR9BMiACSjkBC7uUkLeAhBQvc5vLBSluEt1j3fioKrT8
J0JTFmY6Kwfi2hYsi1P3mvSguMo04kc7cCtnxtV6g+2D0UsnoQFnBxvs7rap
q6Brc9ByMmSeXM40eOY6AUVVrAbkiCbV+By8FpI0fDrzn3yy0iefsOAgwrfD
gffx3KRppoX4St7kZWHTClrb/Bfg8buAMw2fJypnA481nFpBQFWKb2dluXDD
r79eLpcDo3I1QH5+7QVg+b4m/FuoAplc6mLz6+BxVs6z37BvvBS3PwdH/ifQ
/l8KXi3HVXZP/NocyI6wYWoeTAp/m7y0ErEl4YjSDRGp8toUrgQ+K0Bt4Lvq
SVOCCMUXVZ5IzWutAPXzORgTNzwn3Cov1aM04YROByCLqLV52mNTkJoO3CeM
xUwE1NghuNRmjQN4xDgx1sR6blMzMSS5k26hE/4yoKy6esTz9EijHvosdppT
DdK4pDBjcPFC1FEQY66osiACvs0H4oYYk410TsaCqcaUXg6VqWwqze71ShOp
QFlxfhf6X5UpNMfjU+18djkUqxxh5CVZxPzHB3Ip6bSWrG0c4EqwT0/MEJ7w
rqHwInbMXyI+OUJycMlTomUJBhKNCMAXldcawJJZ6kBSUAhTzEeDpZIijKz8
Faw7wec80fLmsie/M8717a/6l1qVMyH+/e9QSD99ir7n6Frb+htm1SQC+1Jw
sLCvB8e96A3Rot1+6mQg5e8srnrRnc86RRla+wkwUciL29HNjUhmivIUKPMN
Aj0lX4IMe5xyVC4NSOF0f4zw7f+oCyvNpJlQVyE62dZolIpw5uDx9NyHtGeE
vAYXJOZCF4mCWH/tsWQFRCwefMQD380D8pb8cPWIBw07K5M/OJiYtWqGZkGO
QUb2EwIX/9ETG0iKHc6hTFKYaYAOdPeGFxsxzoEsawf1amsenn365F17FVsy
YABCQd6tFpRDHWdeD1oeBieb9/Gf/tIUOqY1fFM3eSIE17hCVJmUoytBd1pS
PtXRvM68mulZQ9Bj8CRb4Uvg2ilxA7UolKKUphQGCYDQL1Hvxqs1nB0fNLpR
+fLwwCfZhBOFzUotqlvgrgd6oYuCb/prrxgpolrIWsJW6BVc4/mwCiHTkNzV
PGeHNLyEOOvS+gBau0VGAEwPrxX14M1hjl7bG7gnbJ55Q1YIPwrSwOSiKi1a
8Iam0crUo4CHzws0D3rJaAzzjWY6uQfOyZGNoNKjCGuZXnSZvkH7CLSTTBUe
tuloJ651urInqC6ZpMJ5qKUKLv1Eg0CZay8OcCrSxXeUr1PWdUZxkngIHlm4
4+W7i9Erj3EDqq0PJ4CC5F7DrHOF/sciB2EqJfGcz3OFLFZFKK+wK8xpK0im
kbRJyQxzWHNtUU8dWKlSXUQLUGdIFpipfBr0T4rVorTTQi1mK3JTGgOBWHsJ
42FMCLVr2NPRO4xG9hlJELoB376QyWH9MXzpIDceWBsvdjbxIDcD7xr1IbIN
wu5my52VcEsyYmiMApncjMEfSHzweHh0fELAlOEIxZ6jayfHR77QPSoKuoGv
4UvcTCvN+Ba6D1/fOBXdWg0LSDc50q5dBwW4hxQYbPT2qOL3PreIVq5t5UIz
SBJF6O6R3ozpJceDcR3FluOGPbrOazycBnoAIHxXKZliSY/uEJjJDMTFAqnv
4ziUnzmXLG5cAycLoYLAPkL5JtA1Mz/qVJSB06qGKE4ei9JD+FtbLrVzyAGD
vKTih8cISl6JzX7CS12iag3EO5guriKemgwR46oilk2KJFcBV1VTJS8wGrcs
E9RcITTIxzztKNc3jntHCp+oIfW6c9gVLTBBXaH73lJUwbrnpGZD2EwrXxlc
PW7Exovg3G0W4RCj3GpTeLbbeKpruQ1Z7oTPzDkfrLtUnziNyKN5xKO8Q0U9
xE3g23RG1RU+yJOschjOXoX0b2S9jq1uezCvi/NZqK0RztcFkdT8DpFwBfuN
odKMM+ADevOihlz2FuNujDq9OUe6MDjMCk2zxIS7ubLd+C4svGxoq0X7J/Cg
0QZ1zZvD+x9XuTtOfane2Rk19Hu9U7/3BMpxiI76ODM3voh8RrMWo/OaEXWx
DVY8QBOzK+4EqMK4elr7iyq4r+Cr3S2dypxdSxLwwmEUBtCteJzhNR9utKeZ
JpBPEXsFrDOt0G5kHMmUWiuKEBogGyyrQIyil3H96kEXqzVYh4wFgbVQn+9V
iU4ISgYR7oHjGOFniCXyZm5K35Sv22LfJzsimwL9SlQDf0xwc03abfTXm2fl
i7++2Nlbi055yYIcmL5H0m0zIDdJ5K0hWg+0IrbStOhb92onA99LE5ebq9u3
RDB0kN4CycxariCcN5oij/1CLQXm714A4yUNMDBCHB75LHyLzrLVL3u4Gci3
iABF0xTpxBgbCNLcPAWG0MyPqIFoV9TZcnvXmO5CRUcX2XcRkPjA5vgbQS9b
QbRFphLt62bEI0+4rigc0LS59ehciwlKl2vlr7ys3mxPjSJfXl69opmbCgXN
dQqZbFTh2dRe+PSpJ5vNYp3FpwN5EUpQUY+drpoCp0vng+vyKtJXLgFPFQzC
etHz1D3QmsOUXKBcM0A8dCGQzCQuK3htsKgAsAl1rQ8K0INzfmC7vOLegQDA
d5IxNNBr+0aMmuWS265FVSwoYIgD9fOhhapjSiTU2i6soSWXEDc51QrjpQqK
Gddi88SArYrUE7VqGQEJSOB2aSlawiONZQDv6oFy6AJT7VHf+TLMbyXqET+l
Xhz5HXDSO7pZK/xEkKJXIHHrVtluycSQYe9tufl8Qc2VcgEk/T7LY/MY7PK8
Bha2c9wKEJY8hRK9xg+uZ36WfEBaLLh4e+0TlVOr5KtIHF7vGjMe0Y0j6IZk
N5fyZczwV0MeGKuiP16Vodl55q5i4JOaz1lqTikKcz7MGzPaRVJrlQeAfgKl
NQozRI4yi0B0EAW+a8p3IcfAekQg1VcPHovmVHtzyefXjm8e5rmPM0KFXVwY
vuuTd5tAUndeeoKmOg9uHtQR1t4P/T+0/vtD651WbKdfQHBt2YX9POG1rkP1
woeWPHWJY9/0aAcJ9HeGSsdm80c9AkVpaCfpQNjer2fxuF4iodBKXR8cHNQz
Br7ij4baMGa0mynREaby+WHKLS+1wiNr742vX3EBFZc0H8LGkofVultYy/8N
NVnx/YovU9yfldSk+h0GRX29uW5s0ZeG3xSJlN4szTk/xqsQwPyiI0bV3MtS
t4YvPjTT1Jc+k1DuO9S2FyTAhEN6EhxI2V8utWbFRT3Kt1cUpP3GFL3eRkj/
Pqe4d+ILVxCyawUhPrOCkLtWEJuzfhisn4k5jc1kO7MRq03ogRIz/ahSJMhc
ZS1g+BJE8E4vwe6nIkOLAinpuztu2rm5TdeIvs68gB4DwdG/2eHHtvgF75iQ
3C/WNBDKFYKD3gvHN7TUW8YJFEJ8bBrxY22WXX8fG5p/FB+H/fVf68vWv+ZT
IABkOCCg8LRHvKrsv7/47hupWltVtJEmI9wjCcJbcSlrAke1cDsSqlYhGqsm
cLg/gZNw64fcwD/NLrTTiPQS/81h4x3H6eA4Ejuq7fHe9v+4CL1ujWCdxAjU
5ZrAYbh14ZxNjD+/iYQ7CUR7jDCf+MKiv4zAcSTgIXnb2e0EokG3AfmzCTQK
w9a/bo+crImdhsf+oNXC8btl92X2OAu3bqls7bTGFgKvw62b6+sQXeVWo3QS
OA+33v7ps+e7CbwJt979+ScRON43yY67XPo94d/MZulmpnW79DQSO9lXmpOW
NI13QKBCRfYq5xcvvHFoNXdui2hnkfLpvqKd7Uvg9b4E3uxJABAYM+6Hy++7
3gx2+JreLEYC5/vWhPN9a8L5Vhj3r3Hb0dqRMOefg/E2nU4Cu2H8GQS2wniH
Ep0EtsP4UwqdBHYj7zNU2IK8z/fCZ5C3RaiTwG7kfYYKu5H3swT2Rd7zfcHy
fF9IO98X0s73hbTz830J7IuJo30hbbQvpI22QJp/K/UkpZ5G4mg3pG3S6SSw
C9KeRWALpHUq0UlgG6R1UegksAvSnqVCJ6R9iRd2QtoGoU4CuyDtWSrsgrRn
ENgX0kb7QtpoX0gb7Qtpo30hbbQvpI32hTTaEfa/HRe/8fvBDlKbr1U7SYmv
1r++2Hw/1P7xjUpTWurxu3UXjyStI72w5ls1l08iLDdrQrz3av6io/5Z1kBC
GN3+3akLC62wTBL8cnVRGMIu3gLx+62L5D63y0ynU//7Xb8lmmv/E4iwh6Jt
8V+s/x3MW/ofbORMZwv+bcKUfjwAoWjL9d767RL90KwwYyAV/4oiyaqUXsn/
Wr4zhXWZepB/MMnsQRU9SJvK36sS9y5VjkFFXhcqv9c9/mGh5h/ElZ3//wsf
yJG+aqVBp/WrmGv6CZ1fFRLPBMJCqpEtS3pp2KRM+y08c6fmOHZpSoidzHry
bql1quVbm03EfwCfoe+j6jQAAA==
</back>
</rfc> </rfc>
 End of changes. 114 change blocks. 
531 lines changed or deleted 272 lines changed or added

This html diff was produced by rfcdiff 1.48.