File: rfc8915.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (3818 lines) | stat: -rw-r--r-- 204,218 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8915: Network Time Security for the Network Time Protocol</title>
<meta content="Daniel Fox Franke" name="author">
<meta content="Dieter Sibold" name="author">
<meta content="Kristof Teichel" name="author">
<meta content="Marcus Dansarie" name="author">
<meta content="Ragnar Sundblad" name="author">
<meta content="
       
        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.
       
    " name="description">
<meta content="xml2rfc 3.2.1" name="generator">
<meta content="Integrity" name="keyword">
<meta content="Authentication" name="keyword">
<meta content="NTP" name="keyword">
<meta content="Security" name="keyword">
<meta content="8915" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.2.1
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8915.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8915" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp-28" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8915</td>
<td class="center">Network Time Security for NTP</td>
<td class="right">September 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Franke, et al.</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8915" class="eref">8915</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-09" class="published">September 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">D. Franke</div>
<div class="org">Akamai</div>
</div>
<div class="author">
      <div class="author-name">D. Sibold</div>
<div class="org">PTB</div>
</div>
<div class="author">
      <div class="author-name">K. Teichel</div>
<div class="org">PTB</div>
</div>
<div class="author">
      <div class="author-name">M. Dansarie</div>
</div>
<div class="author">
      <div class="author-name">R. Sundblad</div>
<div class="org">Netnod</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8915</h1>
<h1 id="title">Network Time Security for the Network Time Protocol</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
        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).<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">
        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.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            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.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8915">https://www.rfc-editor.org/info/rfc8915</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) 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 Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-objectives" class="xref">Objectives</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-terms-and-abbreviations" class="xref">Terms and Abbreviations</a><a href="#section-toc.1-1.1.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.1.2.3">
                <p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="xref">1.3</a>.  <a href="#name-protocol-overview" class="xref">Protocol Overview</a><a href="#section-toc.1-1.1.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-tls-profile-for-network-tim" class="xref">TLS Profile for Network Time Security</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-the-nts-key-establishment-p" class="xref">The NTS Key Establishment Protocol</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-nts-ke-record-types" class="xref">NTS-KE Record Types</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.4.2.1.2.1">
                    <p id="section-toc.1-1.4.2.1.2.1.1"><a href="#section-4.1.1" class="xref">4.1.1</a>.  <a href="#name-end-of-message" class="xref">End of Message</a><a href="#section-toc.1-1.4.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.1.2.2">
                    <p id="section-toc.1-1.4.2.1.2.2.1"><a href="#section-4.1.2" class="xref">4.1.2</a>.  <a href="#name-nts-next-protocol-negotiati" class="xref">NTS Next Protocol Negotiation</a><a href="#section-toc.1-1.4.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.1.2.3">
                    <p id="section-toc.1-1.4.2.1.2.3.1"><a href="#section-4.1.3" class="xref">4.1.3</a>.  <a href="#name-error" class="xref">Error</a><a href="#section-toc.1-1.4.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.1.2.4">
                    <p id="section-toc.1-1.4.2.1.2.4.1"><a href="#section-4.1.4" class="xref">4.1.4</a>.  <a href="#name-warning" class="xref">Warning</a><a href="#section-toc.1-1.4.2.1.2.4.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.1.2.5">
                    <p id="section-toc.1-1.4.2.1.2.5.1"><a href="#section-4.1.5" class="xref">4.1.5</a>.  <a href="#name-aead-algorithm-negotiation" class="xref">AEAD Algorithm Negotiation</a><a href="#section-toc.1-1.4.2.1.2.5.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.1.2.6">
                    <p id="section-toc.1-1.4.2.1.2.6.1"><a href="#section-4.1.6" class="xref">4.1.6</a>.  <a href="#name-new-cookie-for-ntpv4" class="xref">New Cookie for NTPv4</a><a href="#section-toc.1-1.4.2.1.2.6.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.1.2.7">
                    <p id="section-toc.1-1.4.2.1.2.7.1"><a href="#section-4.1.7" class="xref">4.1.7</a>.  <a href="#name-ntpv4-server-negotiation" class="xref">NTPv4 Server Negotiation</a><a href="#section-toc.1-1.4.2.1.2.7.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.1.2.8">
                    <p id="section-toc.1-1.4.2.1.2.8.1"><a href="#section-4.1.8" class="xref">4.1.8</a>.  <a href="#name-ntpv4-port-negotiation" class="xref">NTPv4 Port Negotiation</a><a href="#section-toc.1-1.4.2.1.2.8.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-retry-intervals" class="xref">Retry Intervals</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-key-extraction-generally" class="xref">Key Extraction (Generally)</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-nts-extension-fields-for-nt" class="xref">NTS Extension Fields for NTPv4</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-key-extraction-for-ntpv4" class="xref">Key Extraction (for NTPv4)</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-packet-structure-overview" class="xref">Packet Structure Overview</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-the-unique-identifier-exten" class="xref">The Unique Identifier Extension Field</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-the-nts-cookie-extension-fi" class="xref">The NTS Cookie Extension Field</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-the-nts-cookie-placeholder-" class="xref">The NTS Cookie Placeholder Extension Field</a><a href="#section-toc.1-1.5.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.6">
                <p id="section-toc.1-1.5.2.6.1"><a href="#section-5.6" class="xref">5.6</a>.  <a href="#name-the-nts-authenticator-and-e" class="xref">The NTS Authenticator and Encrypted Extension Fields Extension Field</a><a href="#section-toc.1-1.5.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.7">
                <p id="section-toc.1-1.5.2.7.1"><a href="#section-5.7" class="xref">5.7</a>.  <a href="#name-protocol-details" class="xref">Protocol Details</a><a href="#section-toc.1-1.5.2.7.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-suggested-format-for-nts-co" class="xref">Suggested Format for NTS Cookies</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-service-name-and-transport-" class="xref">Service Name and Transport Protocol Port Number Registry</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-tls-application-layer-proto" class="xref">TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs Registry</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-tls-exporter-labels-registr" class="xref">TLS Exporter Labels Registry</a><a href="#section-toc.1-1.7.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.7.2.4">
                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-ntp-kiss-o-death-codes-regi" class="xref">NTP Kiss-o'-Death Codes Registry</a><a href="#section-toc.1-1.7.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.7.2.5">
                <p id="section-toc.1-1.7.2.5.1"><a href="#section-7.5" class="xref">7.5</a>.  <a href="#name-ntp-extension-field-types-r" class="xref">NTP Extension Field Types Registry</a><a href="#section-toc.1-1.7.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.7.2.6">
                <p id="section-toc.1-1.7.2.6.1"><a href="#section-7.6" class="xref">7.6</a>.  <a href="#name-network-time-security-key-e" class="xref">Network Time Security Key Establishment Record Types Registry</a><a href="#section-toc.1-1.7.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.7.2.7">
                <p id="section-toc.1-1.7.2.7.1"><a href="#section-7.7" class="xref">7.7</a>.  <a href="#name-network-time-security-next-" class="xref">Network Time Security Next Protocols Registry</a><a href="#section-toc.1-1.7.2.7.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.7.2.8">
                <p id="section-toc.1-1.7.2.8.1"><a href="#section-7.8" class="xref">7.8</a>.  <a href="#name-network-time-security-error" class="xref">Network Time Security Error and Warning Codes Registries</a><a href="#section-toc.1-1.7.2.8.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-protected-modes" class="xref">Protected Modes</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-cookie-encryption-key-compr" class="xref">Cookie Encryption Key Compromise</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-sensitivity-to-ddos-attacks" class="xref">Sensitivity to DDoS Attacks</a><a href="#section-toc.1-1.8.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.8.2.4">
                <p id="section-toc.1-1.8.2.4.1"><a href="#section-8.4" class="xref">8.4</a>.  <a href="#name-avoiding-ddos-amplification" class="xref">Avoiding DDoS Amplification</a><a href="#section-toc.1-1.8.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.8.2.5">
                <p id="section-toc.1-1.8.2.5.1"><a href="#section-8.5" class="xref">8.5</a>.  <a href="#name-initial-verification-of-ser" class="xref">Initial Verification of Server Certificates</a><a href="#section-toc.1-1.8.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.8.2.6">
                <p id="section-toc.1-1.8.2.6.1"><a href="#section-8.6" class="xref">8.6</a>.  <a href="#name-delay-attacks" class="xref">Delay Attacks</a><a href="#section-toc.1-1.8.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.8.2.7">
                <p id="section-toc.1-1.8.2.7.1"><a href="#section-8.7" class="xref">8.7</a>.  <a href="#name-nts-stripping" class="xref">NTS Stripping</a><a href="#section-toc.1-1.8.2.7.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-privacy-considerations" class="xref">Privacy Considerations</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-unlinkability" class="xref">Unlinkability</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-confidentiality" class="xref">Confidentiality</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
 This memo specifies Network Time Security (NTS), a
 cryptographic security mechanism for network time
 synchronization. A complete specification is provided for
 application of NTS to the client-server mode of the
        <span><a href="#RFC5905" class="xref">Network Time Protocol (NTP)</a> [<a href="#RFC5905" class="xref">RFC5905</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<section id="section-1.1">
        <h3 id="name-objectives">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-objectives" class="section-name selfRef">Objectives</a>
        </h3>
<p id="section-1.1-1">
   The objectives of NTS are as follows:<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.1-2.1">
        Identity: Through the use of a X.509 public key infrastructure,
        implementations can cryptographically establish the identity of
        the parties they are communicating with.<a href="#section-1.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-2.2">
       Authentication: Implementations can cryptographically
       verify that any time synchronization packets are
       authentic, i.e., that they were produced by an
       identified party and have not been modified in transit.<a href="#section-1.1-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-2.3">
       Confidentiality: Although basic time synchronization
       data is considered nonconfidential and sent in the
       clear, NTS includes support for encrypting NTP extension
       fields.<a href="#section-1.1-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-2.4">
       Replay prevention: Client implementations can detect when
       a received time synchronization packet is a replay of
       a previous packet.<a href="#section-1.1-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-2.5">
       Request-response consistency: Client implementations can
       verify that a time synchronization packet received from
       a server was sent in response to a particular request from
       the client.<a href="#section-1.1-2.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-2.6">
       Unlinkability: For mobile clients, NTS will not leak any
       information additional to NTP which would permit a
       passive adversary to determine that two packets sent
       over different networks came from the same client.<a href="#section-1.1-2.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-2.7">
              Non-amplification: Implementations (especially server
              implementations) can avoid acting as distributed
              denial-of-service (DDoS) amplifiers by never responding to a
              request with a packet larger than the request packet.<a href="#section-1.1-2.7" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-2.8">
       Scalability: Server implementations can serve large
       numbers of clients without having to retain any
       client-specific state.<a href="#section-1.1-2.8" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-2.9">
       Performance: NTS must not significantly degrade the
       quality of the time transfer. The encryption and
       authentication used when actually transferring time
       should be lightweight (see Section
              <a href="https://www.rfc-editor.org/rfc/rfc7384#section-5.7" class="relref">5.7</a>
              of <span><a href="#RFC7384" class="xref">RFC 7384</a> [<a href="#RFC7384" class="xref">RFC7384</a>]</span>).<a href="#section-1.1-2.9" class="pilcrow">¶</a>
</li>
        </ul>
</section>
<section id="section-1.2">
        <h3 id="name-terms-and-abbreviations">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-terms-and-abbreviations" class="section-name selfRef">Terms and Abbreviations</a>
        </h3>
<span class="break"></span><dl class="dlParallel" id="section-1.2-1">
          <dt id="section-1.2-1.1">AEAD   </dt>
          <dd style="margin-left: 5.5em" id="section-1.2-1.2">
            <span><a href="#RFC5116" class="xref">Authenticated Encryption
            with Associated Data</a> [<a href="#RFC5116" class="xref">RFC5116</a>]</span><a href="#section-1.2-1.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-1.3">ALPN   </dt>
          <dd style="margin-left: 5.5em" id="section-1.2-1.4">
            <span><a href="#RFC7301" class="xref">Application-Layer Protocol
            Negotiation</a> [<a href="#RFC7301" class="xref">RFC7301</a>]</span><a href="#section-1.2-1.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-1.5">C2S    </dt>
          <dd style="margin-left: 5.5em" id="section-1.2-1.6">Client-to-server<a href="#section-1.2-1.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-1.7">DoS    </dt>
          <dd style="margin-left: 5.5em" id="section-1.2-1.8">Denial-of-Service<a href="#section-1.2-1.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-1.9">DDoS   </dt>
          <dd style="margin-left: 5.5em" id="section-1.2-1.10">Distributed Denial-of-Service<a href="#section-1.2-1.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-1.11">EF     </dt>
          <dd style="margin-left: 5.5em" id="section-1.2-1.12">
            <span><a href="#RFC5905" class="xref">Extension Field</a> [<a href="#RFC5905" class="xref">RFC5905</a>]</span><a href="#section-1.2-1.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-1.13">HKDF   </dt>
          <dd style="margin-left: 5.5em" id="section-1.2-1.14">
            <span><a href="#RFC5869" class="xref">Hashed Message
            Authentication Code-based Key Derivation Function</a> [<a href="#RFC5869" class="xref">RFC5869</a>]</span><a href="#section-1.2-1.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-1.15">KoD    </dt>
          <dd style="margin-left: 5.5em" id="section-1.2-1.16">
            <span><a href="#RFC5905" class="xref">Kiss-o'-Death</a> [<a href="#RFC5905" class="xref">RFC5905</a>]</span><a href="#section-1.2-1.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-1.17">NTP    </dt>
          <dd style="margin-left: 5.5em" id="section-1.2-1.18">
            <span><a href="#RFC5905" class="xref">Network Time Protocol</a> [<a href="#RFC5905" class="xref">RFC5905</a>]</span><a href="#section-1.2-1.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-1.19">NTS    </dt>
          <dd style="margin-left: 5.5em" id="section-1.2-1.20">Network Time Security<a href="#section-1.2-1.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-1.21">NTS NAK</dt>
          <dd style="margin-left: 5.5em" id="section-1.2-1.22">NTS negative-acknowledgment<a href="#section-1.2-1.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-1.23">NTS-KE </dt>
          <dd style="margin-left: 5.5em" id="section-1.2-1.24">Network Time Security Key Establishment<a href="#section-1.2-1.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-1.25">S2C    </dt>
          <dd style="margin-left: 5.5em" id="section-1.2-1.26">Server-to-client<a href="#section-1.2-1.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-1.27">TLS    </dt>
          <dd style="margin-left: 5.5em" id="section-1.2-1.28">
            <span><a href="#RFC8446" class="xref">Transport Layer
            Security</a> [<a href="#RFC8446" class="xref">RFC8446</a>]</span><a href="#section-1.2-1.28" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
<div id="sec-protocol-overview">
<section id="section-1.3">
        <h3 id="name-protocol-overview">
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-protocol-overview" class="section-name selfRef">Protocol Overview</a>
        </h3>
<p id="section-1.3-1">
          The Network Time Protocol includes many different operating modes to
          support various network topologies (see Section
          <a href="https://www.rfc-editor.org/rfc/rfc5905#section-3" class="relref">3</a> of
          <span><a href="#RFC5905" class="xref">RFC 5905</a> [<a href="#RFC5905" class="xref">RFC5905</a>]</span>). In addition to its best-known and
          most-widely-used client-server mode, it also includes modes for
          synchronization between symmetric peers, a control mode for server
          monitoring and administration, and a broadcast mode. These various
          modes have differing and partly contradictory requirements for
          security and performance. Symmetric and control modes demand mutual
          authentication and mutual replay protection. Additionally, for certain
          message types, the control mode may require confidentiality as well as
          authentication. Client-server mode places more stringent requirements
          on resource utilization than other modes because servers may have a
          vast number of clients and be unable to afford to maintain per-client
          state. However, client-server mode also has more relaxed security
          needs because only the client requires replay protection: it is
          harmless for stateless servers to process replayed packets. The
          security demands of symmetric and control modes, on the other hand,
          are in conflict with the resource-utilization demands of client-server
          mode: any scheme that provides replay protection inherently involves
          maintaining some state to keep track of which messages have already
          been seen.<a href="#section-1.3-1" class="pilcrow">¶</a></p>
<p id="section-1.3-2">
          This memo specifies NTS exclusively for the client-server mode of NTP.
          To this end, NTS is structured as a suite of two protocols:<a href="#section-1.3-2" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-1.3-3.1">
              The "NTS Extension Fields for NTPv4" define a collection of NTP
              extension fields for cryptographically securing NTPv4 using
              previously established key material. They are suitable for
              securing client-server mode because the server can implement them
              without retaining per-client state. All state is kept by the
              client and provided to the server in the form of an encrypted
              cookie supplied with each request. On the other hand, the NTS
              Extension Fields are suitable <em>only</em> for client-server mode
              because only the client, and not the server, is protected from
              replay.<a href="#section-1.3-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal ulEmpty" id="section-1.3-3.2">
              The "NTS Key Establishment" protocol (NTS-KE) is a
              mechanism for establishing key material for use with the NTS
              Extension Fields for NTPv4. It uses TLS to establish keys, to provide
              the client with an initial supply of cookies, and to negotiate some
              additional protocol options. After this, the TLS channel
              is closed with no per-client state remaining on the server side.<a href="#section-1.3-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-1.3-4">
          The typical protocol flow is as follows: The client connects to an
          NTS-KE server on the NTS TCP port and the two parties perform a TLS
          handshake. Via the TLS channel, the parties negotiate some additional
          protocol parameters, and the server sends the client a supply of
          cookies along with an address and port of an NTP server
          for which the cookies are valid. The parties use
          <span><a href="#RFC5705" class="xref">TLS key export</a> [<a href="#RFC5705" class="xref">RFC5705</a>]</span> to extract key material,
          which will be used in the next phase of the protocol. This negotiation
          takes only a single round trip, after which the server closes the
          connection and discards all associated state. At this point, the NTS-KE
          phase of the protocol is complete. Ideally, the client never needs to
          connect to the NTS-KE server again.<a href="#section-1.3-4" class="pilcrow">¶</a></p>
<p id="section-1.3-5">
          Time synchronization proceeds with the indicated NTP server.
          The client sends the server an NTP client
          packet that includes several extension fields. Included among these
          fields are a cookie (previously provided by the key establishment server)
          and an authentication tag, computed using key material extracted from
          the NTS-KE handshake.  The NTP server uses the cookie to recover this
          key material and send back an authenticated response. The response
          includes a fresh, encrypted cookie that the client then sends back in
          the clear in a subsequent request. This constant refreshing of cookies
          is necessary in order to achieve NTS's unlinkability goal.<a href="#section-1.3-5" class="pilcrow">¶</a></p>
<p id="section-1.3-6">
          <a href="#protocol-overview" class="xref">Figure 1</a> provides an overview of the
          high-level interaction between the client, the NTS-KE server, and the
          NTP server. Note that the cookies' data format and the exchange of
          secrets between NTS-KE and NTP servers are not part of this
          specification and are implementation dependent. However, a suggested
          format for NTS cookies is provided in
          <a href="#suggested-format-for-nts-cookies" class="xref">Section 6</a>.<a href="#section-1.3-6" class="pilcrow">¶</a></p>
<span id="name-overview-of-high-level-inte"></span><div id="protocol-overview">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-1.3-7.1">
<pre>
                                                     +--------------+
                                                     |              |
                                                 +-&gt; | NTP Server 1 |
                                                 |   |              |
                           Shared cookie         |   +--------------+
+---------------+      encryption parameters     |   +--------------+
|               |    (Implementation dependent)  |   |              |
| NTS-KE Server | &lt;------------------------------+-&gt; | NTP Server 2 |
|               |                                |   |              |
+---------------+                                |   +--------------+
       ^                                         |          .
       |                                         |          .
       | 1. Negotiate parameters,                |          .
       |    receive initial cookie               |   +--------------+
       |    supply, generate AEAD keys,          |   |              |
       |    and receive NTP server IP            +-&gt; | NTP Server N |
       |    addresses using "NTS Key                 |              |
       |    Establishment" protocol.                 +--------------+
       |                                                    ^
       |                                                    |
       |             +----------+                           |
       |             |          |                           |
       +-----------&gt; |  Client  | &lt;-------------------------+
                     |          |  2. Perform authenticated
                     +----------+     time synchronization
                                      and generate new
                                      cookies using "NTS
                                      Extension Fields for
                                      NTPv4".
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-overview-of-high-level-inte" class="selfRef">Overview of High-Level Interactions in NTS</a>
          </figcaption></figure>
</div>
</section>
</div>
</section>
<section id="section-2">
      <h2 id="name-requirements-language">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
      </h2>
<p id="section-2-1">
        The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
        "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>",
        "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>",
        "<span class="bcp14">NOT RECOMMENDED</span>", "<span class="bcp14">MAY</span>", and
        "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as described in
        BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when,
        and only when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
<div id="tls-profile">
<section id="section-3">
      <h2 id="name-tls-profile-for-network-tim">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-tls-profile-for-network-tim" class="section-name selfRef">TLS Profile for Network Time Security</a>
      </h2>
<p id="section-3-1">
        Network Time Security makes use of TLS for NTS key establishment.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
        Since the NTS protocol is new as of this publication, no
        backward-compatibility concerns exist to justify using
        obsolete, insecure, or otherwise broken TLS features or
        versions. Implementations <span class="bcp14">MUST</span> conform with
        <span><a href="#RFC7525" class="xref">RFC 7525</a> [<a href="#RFC7525" class="xref">RFC7525</a>]</span> or
        with a later revision of BCP 195.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">
        Implementations <span class="bcp14">MUST NOT</span> negotiate TLS versions earlier than 1.3
        <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span> and <span class="bcp14">MAY</span> refuse to negotiate any TLS version
        that has been superseded by a later supported version.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">
        Use of the <span><a href="#RFC7301" class="xref">Application-Layer Protocol
        Negotiation Extension</a> [<a href="#RFC7301" class="xref">RFC7301</a>]</span> is integral to NTS, and support for
        it is <span class="bcp14">REQUIRED</span> for interoperability.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">
        Implementations <span class="bcp14">MUST</span> follow the rules in <span><a href="#RFC5280" class="xref">RFC 5280</a> [<a href="#RFC5280" class="xref">RFC5280</a>]</span> and <span><a href="#RFC6125" class="xref">RFC 6125</a> [<a href="#RFC6125" class="xref">RFC6125</a>]</span> for the
        representation and verification of the application's service identity.
        When NTS-KE service discovery (out of scope for this document)
        produces one or more host names, use of the
        <span><a href="#RFC6125" class="xref">DNS-ID identifier type</a> [<a href="#RFC6125" class="xref">RFC6125</a>]</span> is <span class="bcp14">RECOMMENDED</span>;
        specifications for service discovery mechanisms can provide additional
        guidance for certificate validation based on the results of
        discovery. <a href="#sec-cert-verification" class="xref">Section 8.5</a> of this memo
        discusses particular considerations for certificate verification in
        the context of NTS.<a href="#section-3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="nts-ke">
<section id="section-4">
      <h2 id="name-the-nts-key-establishment-p">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-the-nts-key-establishment-p" class="section-name selfRef">The NTS Key Establishment Protocol</a>
      </h2>
<p id="section-4-1">
        The NTS key establishment protocol is conducted via TCP port 4460.
        The two endpoints carry out a TLS handshake in conformance with
        <a href="#tls-profile" class="xref">Section 3</a>, with the client offering (via an
        <span><a href="#RFC7301" class="xref">ALPN extension</a> [<a href="#RFC7301" class="xref">RFC7301</a>]</span>), and the server accepting,
        an application-layer protocol of "ntske/1". Immediately
        following a successful handshake, the client <span class="bcp14">SHALL</span> send a single request
        as Application Data encapsulated in the TLS-protected channel. Then, the
        server <span class="bcp14">SHALL</span> send a single response. After sending their respective
        request and response, the client and server <span class="bcp14">SHALL</span> send TLS
        "close_notify" alerts in accordance with Section
        <a href="https://www.rfc-editor.org/rfc/rfc8446#section-6.1" class="relref">6.1</a> of
        <span><a href="#RFC8446" class="xref">RFC 8446</a> [<a href="#RFC8446" class="xref">RFC8446</a>]</span>.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
        The client's request and the server's response each <span class="bcp14">SHALL</span> consist of a
        sequence of records formatted according to
        <a href="#ntske-record" class="xref">Figure 2</a>. The request and a non-error response each
        <span class="bcp14">SHALL</span> include exactly one NTS Next Protocol Negotiation record. The
        sequence <span class="bcp14">SHALL</span> be terminated by a "End of Message" record. The
        requirement that all NTS-KE messages be terminated by an End of Message
        record makes them self-delimiting.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">
        Clients and servers <span class="bcp14">MAY</span> enforce length limits on requests and responses;
        however, servers <span class="bcp14">MUST</span> accept requests of at least 1024 octets, and
        clients <span class="bcp14">SHOULD</span> accept responses of at least 65536 octets.<a href="#section-4-3" class="pilcrow">¶</a></p>
<span id="name-nts-ke-record-format"></span><div id="ntske-record">
<figure id="figure-2">
        <div class="artwork art-text alignLeft" id="section-4-4.1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|         Record Type         |          Body Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                           Record Body                         .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-nts-ke-record-format" class="selfRef">NTS-KE Record Format</a>
        </figcaption></figure>
</div>
<p id="section-4-5">
        The fields of an NTS-KE record are defined as follows:<a href="#section-4-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4-6">
        <dt id="section-4-6.1">C (Critical Bit):</dt>
        <dd style="margin-left: 1.5em" id="section-4-6.2">Determines the disposition of unrecognized Record
            Types. Implementations which receive a record with an unrecognized
            Record Type <span class="bcp14">MUST</span> ignore the record if the Critical Bit is 0 and <span class="bcp14">MUST</span>
            treat it as an error if the Critical Bit is 1 (see <a href="#nts-error" class="xref">Section 4.1.3</a>).<a href="#section-4-6.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-6.3">Record Type Number:</dt>
        <dd style="margin-left: 1.5em" id="section-4-6.4">A 15-bit integer in network byte order. The
            semantics of Record Types 0-7 are specified in this memo.
            Additional type numbers <span class="bcp14">SHALL</span> be tracked through the IANA "Network
            Time Security Key Establishment Record Types" registry.<a href="#section-4-6.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-6.5">Body Length:</dt>
        <dd style="margin-left: 1.5em" id="section-4-6.6">The length of the Record Body field, in octets, as a
            16-bit integer in network byte order. Record bodies <span class="bcp14">MAY</span> have any
            representable length and need not be aligned to a word boundary.<a href="#section-4-6.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-6.7">Record Body:</dt>
        <dd style="margin-left: 1.5em" id="section-4-6.8">The syntax and semantics of this field <span class="bcp14">SHALL</span> be
           determined by the Record Type.<a href="#section-4-6.8" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-4-7">
        For clarity regarding bit-endianness: the Critical Bit is the
        most significant bit of the first octet. In the C programming language,
        given a network buffer
        'unsigned char b[]' containing an NTS-KE record, the critical bit is
        'b[0] &gt;&gt; 7' while the record type is
        '((b[0] &amp; 0x7f) &lt;&lt; 8) + b[1]'.<a href="#section-4-7" class="pilcrow">¶</a></p>
<p id="section-4-8">
        Note that, although the Type-Length-Body format of an NTS-KE record is
        similar to that of an NTP extension field, the semantics of the length
        field differ. While the length subfield of an NTP extension field gives
        the length of the entire extension field including the type and length
        subfields, the length field of an NTS-KE record gives just the length
        of the body.<a href="#section-4-8" class="pilcrow">¶</a></p>
<p id="section-4-9">
        <a href="#fig_NTSKeyEstablishment" class="xref">Figure 3</a> provides a schematic overview of the
        key establishment. It displays the protocol steps to be performed by the NTS
        client and server and Record Types to be exchanged.<a href="#section-4-9" class="pilcrow">¶</a></p>
<span id="name-nts-key-establishment-messa"></span><div id="fig_NTSKeyEstablishment">
<figure id="figure-3">
        <div class="artwork art-text alignLeft" id="section-4-10.1">
<pre>
                +---------------------------------------+
                | - Verify client request message.      |
                | - Extract TLS key material.           |
                | - Generate KE response message.       |
                |   - Include Record Types:             |
                |       o NTS Next Protocol Negotiation |
                |       o AEAD Algorithm Negotiation    |
                |       o &lt;NTPv4 Server Negotiation&gt;    |
                |       o &lt;NTPv4 Port Negotiation&gt;      |
                |       o New Cookie for NTPv4          |
                |       o &lt;New Cookie for NTPv4&gt;        |
                |       o End of Message                |
                +-----------------+---------------------+
                                  |
                                  |
Server -----------+---------------+-----+-----------------------&gt;
                  ^                      \
                 /                        \
                /    TLS application       \
               /     data                   \
              /                              \
             /                                V
Client -----+---------------------------------+-----------------&gt;
            |                                 |
            |                                 |
            |                                 |
+-----------+----------------------+   +------+-----------------+
|- Generate KE request message.    |   |- Verify server response|
| - Include Record Types:          |   |  message.              |
|  o NTS Next Protocol Negotiation |   |- Extract cookie(s).    |
|  o AEAD Algorithm Negotiation    |   +------------------------+
|  o &lt;NTPv4 Server Negotiation&gt;    |
|  o &lt;NTPv4 Port Negotiation&gt;      |
|  o End of Message                |
+----------------------------------+
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-nts-key-establishment-messa" class="selfRef">NTS Key Establishment Messages</a>
        </figcaption></figure>
</div>
<section id="section-4.1">
        <h3 id="name-nts-ke-record-types">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-nts-ke-record-types" class="section-name selfRef">NTS-KE Record Types</a>
        </h3>
<p id="section-4.1-1">The following NTS-KE Record Types are defined:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<div id="end-of-message">
<section id="section-4.1.1">
          <h4 id="name-end-of-message">
<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-end-of-message" class="section-name selfRef">End of Message</a>
          </h4>
<p id="section-4.1.1-1">
            The End of Message record has a Record Type number of 0 and a
            zero-length body. It <span class="bcp14">MUST</span> occur exactly once as the final record of
            every NTS-KE request and response. The Critical Bit <span class="bcp14">MUST</span> be set.<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="nts-next-protocol-negotiation">
<section id="section-4.1.2">
          <h4 id="name-nts-next-protocol-negotiati">
<a href="#section-4.1.2" class="section-number selfRef">4.1.2. </a><a href="#name-nts-next-protocol-negotiati" class="section-name selfRef">NTS Next Protocol Negotiation</a>
          </h4>
<p id="section-4.1.2-1">
            The NTS Next Protocol Negotiation record has a Record Type number
            of 1. It <span class="bcp14">MUST</span> occur exactly once in every NTS-KE request and
            response. Its body consists of a sequence of 16-bit unsigned
            integers in network byte order. Each integer represents a Protocol
            ID from the IANA "Network Time Security Next Protocols" registry
            (<a href="#iana-nts-next-protocols" class="xref">Section 7.7</a>). The
            Critical Bit <span class="bcp14">MUST</span> be set.<a href="#section-4.1.2-1" class="pilcrow">¶</a></p>
<p id="section-4.1.2-2">

            The Protocol IDs listed in the client's NTS Next Protocol
            Negotiation record denote those protocols that the client wishes to
            speak using the key material established through this NTS-KE
            session. Protocol IDs listed in the NTS-KE server's response <span class="bcp14">MUST</span>
            comprise a subset of those listed in the request and
            denote those protocols that the NTP server is willing and
            able to speak using the key material established through
            this NTS-KE session. The client <span class="bcp14">MAY</span>
            proceed with one or more of them. The request <span class="bcp14">MUST</span> list at least one
            protocol, but the response <span class="bcp14">MAY</span> be empty.<a href="#section-4.1.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="nts-error">
<section id="section-4.1.3">
          <h4 id="name-error">
<a href="#section-4.1.3" class="section-number selfRef">4.1.3. </a><a href="#name-error" class="section-name selfRef">Error</a>
          </h4>
<p id="section-4.1.3-1">
            The Error record has a Record Type number of 2. Its body is exactly
            two octets long, consisting of an unsigned 16-bit integer in network
            byte order, denoting an error code. The Critical Bit <span class="bcp14">MUST</span> be set.<a href="#section-4.1.3-1" class="pilcrow">¶</a></p>
<p id="section-4.1.3-2">
            Clients <span class="bcp14">MUST NOT</span> include Error records in their request. If clients
            receive a server response that includes an Error record, they <span class="bcp14">MUST</span>
            discard any key material negotiated during the initial TLS exchange
            and <span class="bcp14">MUST NOT</span> proceed to the Next Protocol. Requirements for retry
            intervals are described in <a href="#nts-ke-retry" class="xref">Section 4.2</a>.<a href="#section-4.1.3-2" class="pilcrow">¶</a></p>
<p id="section-4.1.3-3">
            The following error codes are defined:<a href="#section-4.1.3-3" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-4.1.3-4.1">
                Error code 0 means "Unrecognized Critical Record". The
                server <span class="bcp14">MUST</span> respond with this error code if the request included
                a record that the server did not understand and that had its
                Critical Bit set. The client <span class="bcp14">SHOULD NOT</span> retry its request
                without modification.<a href="#section-4.1.3-4.1" class="pilcrow">¶</a>
</li>
            <li class="normal ulEmpty" id="section-4.1.3-4.2">
                Error code 1 means "Bad Request". The server <span class="bcp14">MUST</span>
                respond with this error if the request is not complete
                and syntactically well-formed, or, upon the expiration
                of an implementation-defined timeout, it has not yet
                received such a request. The client <span class="bcp14">SHOULD NOT</span> retry its
                request without modification.<a href="#section-4.1.3-4.2" class="pilcrow">¶</a>
</li>
            <li class="normal ulEmpty" id="section-4.1.3-4.3">
                Error code 2 means "Internal Server Error". The server
                <span class="bcp14">MUST</span> respond with this error if it is unable to respond properly
                due to an internal condition. The client <span class="bcp14">MAY</span> retry its request.<a href="#section-4.1.3-4.3" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="nts-warning">
<section id="section-4.1.4">
          <h4 id="name-warning">
<a href="#section-4.1.4" class="section-number selfRef">4.1.4. </a><a href="#name-warning" class="section-name selfRef">Warning</a>
          </h4>
<p id="section-4.1.4-1">
            The Warning record has a Record Type number of 3. Its body is
            exactly two octets long, consisting of an unsigned 16-bit integer in
            network byte order, denoting a warning code. The Critical Bit <span class="bcp14">MUST</span>
            be set.<a href="#section-4.1.4-1" class="pilcrow">¶</a></p>
<p id="section-4.1.4-2">
            Clients <span class="bcp14">MUST NOT</span> include Warning records in their request. If
            clients receive a server response that includes a Warning record,
            they <span class="bcp14">MAY</span> discard any negotiated key material and abort without
            proceeding to the Next Protocol. Unrecognized warning codes <span class="bcp14">MUST</span> be
            treated as errors.<a href="#section-4.1.4-2" class="pilcrow">¶</a></p>
<p id="section-4.1.4-3">
            This memo defines no warning codes.<a href="#section-4.1.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="aead-algorithm-negotiation">
<section id="section-4.1.5">
          <h4 id="name-aead-algorithm-negotiation">
<a href="#section-4.1.5" class="section-number selfRef">4.1.5. </a><a href="#name-aead-algorithm-negotiation" class="section-name selfRef">AEAD Algorithm Negotiation</a>
          </h4>
<p id="section-4.1.5-1">
            The AEAD Algorithm Negotiation record has a Record Type number of 4.
            Its body consists of a sequence of unsigned 16-bit integers in
            network byte order, denoting Numeric Identifiers from the IANA
            <span><a href="#IANA-AEAD" class="xref">"AEAD Algorithms" registry</a> [<a href="#IANA-AEAD" class="xref">IANA-AEAD</a>]</span>. The
            Critical Bit <span class="bcp14">MAY</span> be set.<a href="#section-4.1.5-1" class="pilcrow">¶</a></p>
<p id="section-4.1.5-2">
            If the NTS Next Protocol Negotiation record offers Protocol ID 0
            (for NTPv4), then this record <span class="bcp14">MUST</span> be included exactly once. Other
            protocols <span class="bcp14">MAY</span> require it as well.<a href="#section-4.1.5-2" class="pilcrow">¶</a></p>
<p id="section-4.1.5-3">
            When included in a request, this record denotes which AEAD
            algorithms the client is willing to use to secure the Next Protocol,
            in decreasing preference order. When included in a response, this
            record denotes which algorithm the server chooses to use. It is
            empty if the server supports none of the algorithms offered. In
            requests, the list <span class="bcp14">MUST</span> include at least one algorithm. In
            responses, it <span class="bcp14">MUST</span> include at most one. Honoring the client's
            preference order is <span class="bcp14">OPTIONAL</span>: servers may select among any of the
            client's offered choices, even if they are able to support some
            other algorithm that the client prefers more.<a href="#section-4.1.5-3" class="pilcrow">¶</a></p>
<p id="section-4.1.5-4">
            Server implementations of
            <span><a href="#nts-extension-fields-for-ntpv4" class="xref">NTS Extension Fields for NTPv4</a> (<a href="#nts-extension-fields-for-ntpv4" class="xref">Section 5</a>)</span>
            <span class="bcp14">MUST</span> support
            <span><a href="#RFC5297" class="xref">AEAD_AES_SIV_CMAC_256</a> [<a href="#RFC5297" class="xref">RFC5297</a>]</span>
            (Numeric Identifier 15). That is, if the client includes AEAD_AES_SIV_CMAC_256 in its
            AEAD Algorithm Negotiation record, and the server accepts Protocol
            ID 0 (NTPv4) in its NTS Next Protocol Negotiation record, then the
            server's AEAD Algorithm Negotiation record <span class="bcp14">MUST NOT</span> be empty.<a href="#section-4.1.5-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="new-cookie-for-ntpv4">
<section id="section-4.1.6">
          <h4 id="name-new-cookie-for-ntpv4">
<a href="#section-4.1.6" class="section-number selfRef">4.1.6. </a><a href="#name-new-cookie-for-ntpv4" class="section-name selfRef">New Cookie for NTPv4</a>
          </h4>
<p id="section-4.1.6-1">
            The New Cookie for NTPv4 record has a Record Type number of 5. The
            contents of its body <span class="bcp14">SHALL</span> be implementation-defined,
            and clients <span class="bcp14">MUST NOT</span> attempt to interpret them.
            See <a href="#suggested-format-for-nts-cookies" class="xref">Section 6</a> for a suggested
            construction.<a href="#section-4.1.6-1" class="pilcrow">¶</a></p>
<p id="section-4.1.6-2">
            Clients <span class="bcp14">MUST NOT</span> send records of this type. Servers <span class="bcp14">MUST</span> send at
            least one record of this type, and <span class="bcp14">SHOULD</span> send eight of them, if the
            Next Protocol Negotiation response record contains Protocol ID 0
            (NTPv4) and the AEAD Algorithm Negotiation response record is not
            empty. The Critical Bit <span class="bcp14">SHOULD NOT</span> be set.<a href="#section-4.1.6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ntp-server-negotiation">
<section id="section-4.1.7">
          <h4 id="name-ntpv4-server-negotiation">
<a href="#section-4.1.7" class="section-number selfRef">4.1.7. </a><a href="#name-ntpv4-server-negotiation" class="section-name selfRef">NTPv4 Server Negotiation</a>
          </h4>
<p id="section-4.1.7-1">
            The NTPv4 Server Negotiation record has a Record Type number of 6.
            Its body consists of an
            <span><a href="#RFC0020" class="xref">ASCII-encoded</a> [<a href="#RFC0020" class="xref">RFC0020</a>]</span> string. The
            contents of the string <span class="bcp14">SHALL</span> be either an IPv4 address, an IPv6
            address, or a fully qualified domain name (FQDN). IPv4 addresses
            <span class="bcp14">MUST</span> be in dotted decimal notation. IPv6 addresses <span class="bcp14">MUST</span> conform to
            the "Text Representation of Addresses" as specified in
            <span><a href="#RFC4291" class="xref">RFC 4291</a> [<a href="#RFC4291" class="xref">RFC4291</a>]</span> and <span class="bcp14">MUST NOT</span> include zone
            identifiers <span>[<a href="#RFC6874" class="xref">RFC6874</a>]</span>. If a label contains at least
            one non-ASCII character, it is an internationalized domain name,
            and an A-LABEL <span class="bcp14">MUST</span> be used as defined in Section
            <a href="https://www.rfc-editor.org/rfc/rfc5890#section-2.3.2.1" class="relref">2.3.2.1</a>
            of <span><a href="#RFC5890" class="xref">RFC 5890</a> [<a href="#RFC5890" class="xref">RFC5890</a>]</span>.
            If the record contains a domain name, the recipient <span class="bcp14">MUST</span> treat it
            as a FQDN, e.g., by making sure it ends with a dot.<a href="#section-4.1.7-1" class="pilcrow">¶</a></p>
<p id="section-4.1.7-2">
            When NTPv4 is negotiated as a Next Protocol and this
            record is sent by the server, the body specifies the
            hostname or IP address of the NTPv4 server with which the
            client should associate and that will accept the supplied
            cookies. If no record of this type is sent, the client
            <span class="bcp14">SHALL</span> interpret this as a directive to associate with an
            NTPv4 server at the same IP address as the NTS-KE server.
            Servers <span class="bcp14">MUST NOT</span> send more than one record of this type.<a href="#section-4.1.7-2" class="pilcrow">¶</a></p>
<p id="section-4.1.7-3">
            When this record is sent by the client, it indicates that
            the client wishes to associate with the specified NTP
            server. The NTS-KE server <span class="bcp14">MAY</span> incorporate this request when
            deciding which NTPv4 Server Negotiation records to respond
            with, but honoring the client's preference is
            <span class="bcp14">OPTIONAL</span>. The client <span class="bcp14">MUST NOT</span> send more than one record of
            this type.<a href="#section-4.1.7-3" class="pilcrow">¶</a></p>
<p id="section-4.1.7-4">
            If the client has sent a record of this type, the NTS-KE server
            <span class="bcp14">SHOULD</span> reply with the same record if it is valid and the server is
            able to supply cookies for it. If the client has not sent any
            record of this type, the NTS-KE server <span class="bcp14">SHOULD</span> respond with either
            an NTP server address in the same family as the NTS-KE session or
            a FQDN that can be resolved to an address in that family, if such
            alternatives are available.<a href="#section-4.1.7-4" class="pilcrow">¶</a></p>
<p id="section-4.1.7-5">
            Servers <span class="bcp14">MAY</span> set the Critical Bit on records of this type;
            clients <span class="bcp14">SHOULD NOT</span>.<a href="#section-4.1.7-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ntp-port-negotiation">
<section id="section-4.1.8">
          <h4 id="name-ntpv4-port-negotiation">
<a href="#section-4.1.8" class="section-number selfRef">4.1.8. </a><a href="#name-ntpv4-port-negotiation" class="section-name selfRef">NTPv4 Port Negotiation</a>
          </h4>
<p id="section-4.1.8-1">
            The NTPv4 Port Negotiation record has a Record Type number
            of 7. Its body consists of a 16-bit unsigned integer in
            network byte order, denoting a UDP port number.<a href="#section-4.1.8-1" class="pilcrow">¶</a></p>
<p id="section-4.1.8-2">
            When NTPv4 is negotiated as a Next Protocol, and this
            record is sent by the server, the body specifies the port
            number of the NTPv4 server with which the client should
            associate and that will accept the supplied cookies. If
            no record of this type is sent, the client <span class="bcp14">SHALL</span> assume
            a default of 123 (the registered port number for NTP).<a href="#section-4.1.8-2" class="pilcrow">¶</a></p>
<p id="section-4.1.8-3">
            When this record is sent by the client in conjunction with
            a NTPv4 Server Negotiation record, it indicates that the
            client wishes to associate with the NTP server at the
            specified port. The NTS-KE server <span class="bcp14">MAY</span> incorporate this
            request when deciding what NTPv4 Server Negotiation and
            NTPv4 Port Negotiation records to respond with, but
            honoring the client's preference is <span class="bcp14">OPTIONAL</span>.<a href="#section-4.1.8-3" class="pilcrow">¶</a></p>
<p id="section-4.1.8-4">
            Servers <span class="bcp14">MAY</span> set the Critical Bit on records of this type;
            clients <span class="bcp14">SHOULD NOT</span>.<a href="#section-4.1.8-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<div id="nts-ke-retry">
<section id="section-4.2">
        <h3 id="name-retry-intervals">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-retry-intervals" class="section-name selfRef">Retry Intervals</a>
        </h3>
<p id="section-4.2-1">
          A mechanism for not unnecessarily overloading the NTS-KE server is
          <span class="bcp14">REQUIRED</span> when retrying the key establishment process due to protocol,
          communication, or other errors. The exact workings of this will be
          dependent on the application and operational experience gathered over
          time. Until such experience is available, this memo provides the
          following suggestion.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">
          Clients <span class="bcp14">SHOULD</span> use exponential backoff, with an initial and minimum
          retry interval of 10 seconds, a maximum retry interval of 5 days, and
          a base of 1.5. Thus, the minimum interval in seconds, 't', for the nth
          retry is calculated with the following:<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-4.2-3.1">
              t = min(10 * 1.5<sup>n-1</sup>, 432000).<a href="#section-4.2-3.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.2-4">
          Clients <span class="bcp14">MUST NOT</span> reset the retry interval until they have performed
          a successful key establishment with the NTS-KE server, followed by a
          successful use of the negotiated Next Protocol with the keys and data
          established during that transaction.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="key-extraction">
<section id="section-4.3">
        <h3 id="name-key-extraction-generally">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-key-extraction-generally" class="section-name selfRef">Key Extraction (Generally)</a>
        </h3>
<p id="section-4.3-1">
          Following a successful run of the NTS-KE protocol, key material <span class="bcp14">SHALL</span>
          be extracted using <span><a href="#RFC5869" class="xref">the HMAC-based
          Extract-and-Expand Key Derivation Function (HKDF)</a> [<a href="#RFC5869" class="xref">RFC5869</a>]</span> in
          accordance with Section <a href="https://www.rfc-editor.org/rfc/rfc8446#section-7.5" class="relref">7.5</a>
          of <span><a href="#RFC8446" class="xref">RFC 8446</a> [<a href="#RFC8446" class="xref">RFC8446</a>]</span>.

          Inputs to the exporter function are to be constructed in a manner
          specific to the negotiated Next Protocol. However, all protocols that
          utilize NTS-KE <span class="bcp14">MUST</span> conform to the following two rules:<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-4.3-2.1">
              The <span><a href="#RFC5705" class="xref">disambiguating label string</a> [<a href="#RFC5705" class="xref">RFC5705</a>]</span> <span class="bcp14">MUST</span>
              be "EXPORTER-network-time-security".<a href="#section-4.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal ulEmpty" id="section-4.3-2.2">
              The <span><a href="#RFC5705" class="xref">per-association context value</a> [<a href="#RFC5705" class="xref">RFC5705</a>]</span>
            <span class="bcp14">MUST</span> be provided and <span class="bcp14">MUST</span> begin with the two-octet Protocol ID
              that was negotiated as a Next Protocol.<a href="#section-4.3-2.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="nts-extension-fields-for-ntpv4">
<section id="section-5">
      <h2 id="name-nts-extension-fields-for-nt">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-nts-extension-fields-for-nt" class="section-name selfRef">NTS Extension Fields for NTPv4</a>
      </h2>
<section id="section-5.1">
        <h3 id="name-key-extraction-for-ntpv4">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-key-extraction-for-ntpv4" class="section-name selfRef">Key Extraction (for NTPv4)</a>
        </h3>
<p id="section-5.1-1">
          Following a successful run of the NTS-KE protocol wherein Protocol
          ID 0 (NTPv4) is selected as a Next Protocol, two AEAD keys <span class="bcp14">SHALL</span> be
          extracted: a client-to-server (C2S) key and a server-to-client (S2C)
          key. These keys <span class="bcp14">SHALL</span> be computed with the HKDF defined in
          Section <a href="https://www.rfc-editor.org/rfc/rfc8446#section-7.5" class="relref">7.5</a>
          of <span><a href="#RFC8446" class="xref">RFC 8446</a> [<a href="#RFC8446" class="xref">RFC8446</a>]</span> using the
          following inputs:<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-5.1-2.1">
              The <span><a href="#RFC5705" class="xref">disambiguating label string</a> [<a href="#RFC5705" class="xref">RFC5705</a>]</span>
            <span class="bcp14">SHALL</span> be "EXPORTER-network-time-security".<a href="#section-5.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal ulEmpty" id="section-5.1-2.2">
            <p id="section-5.1-2.2.1">
              The <span><a href="#RFC5705" class="xref">per-association context value</a> [<a href="#RFC5705" class="xref">RFC5705</a>]</span>
              <span class="bcp14">SHALL</span> consist of the following five octets:<a href="#section-5.1-2.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-2.2.2.1">
                  The first two octets <span class="bcp14">SHALL</span> be zero (the Protocol ID for
                  NTPv4).<a href="#section-5.1-2.2.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-5.1-2.2.2.2">
                  The next two octets <span class="bcp14">SHALL</span> be the Numeric Identifier of the
                  negotiated AEAD algorithm in network byte order.<a href="#section-5.1-2.2.2.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-5.1-2.2.2.3">
                  The final octet <span class="bcp14">SHALL</span> be 0x00 for the C2S key and 0x01 for the
                  S2C key.<a href="#section-5.1-2.2.2.3" class="pilcrow">¶</a>
</li>
            </ul>
</li>
        </ul>
<p id="section-5.1-3">
          Implementations wishing to derive additional keys for private or
          experimental use <span class="bcp14">MUST NOT</span> do so by extending the above-specified
          syntax for per-association context values. Instead, they <span class="bcp14">SHOULD</span> use
          their own disambiguating label string. Note that <span><a href="#RFC5705" class="xref">RFC 5705</a> [<a href="#RFC5705" class="xref">RFC5705</a>]</span> provides that disambiguating label
          strings beginning with "EXPERIMENTAL" <span class="bcp14">MAY</span> be used without
          IANA registration.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
</section>
<section id="section-5.2">
        <h3 id="name-packet-structure-overview">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-packet-structure-overview" class="section-name selfRef">Packet Structure Overview</a>
        </h3>
<p id="section-5.2-1">
          In general, an NTS-protected NTPv4 packet consists of the following:<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-5.2-2.1">
              The usual 48-octet NTP header, which is authenticated but not
              encrypted.<a href="#section-5.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal ulEmpty" id="section-5.2-2.2">
              Some extension fields, which are authenticated but not encrypted.<a href="#section-5.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal ulEmpty" id="section-5.2-2.3">
              An extension field that contains AEAD output (i.e., an
              authentication tag and possible ciphertext). The corresponding
              plaintext, if non-empty, consists of some extension fields that
              benefit from both encryption and authentication.<a href="#section-5.2-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal ulEmpty" id="section-5.2-2.4">
              Possibly, some additional extension fields that are neither
              encrypted nor authenticated. In general, these are discarded by the
              receiver.<a href="#section-5.2-2.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.2-3">
          Always included among the authenticated or authenticated-and-encrypted
          extension fields are a cookie extension field and a unique identifier
          extension field, as described in <a href="#protocol-details" class="xref">Section 5.7</a>. The purpose of the
          cookie extension field is to enable the server to offload storage of
          session state onto the client. The purpose of the unique identifier
          extension field is to protect the client from replay attacks.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
</section>
<div id="unique-identifier-extension-field">
<section id="section-5.3">
        <h3 id="name-the-unique-identifier-exten">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-the-unique-identifier-exten" class="section-name selfRef">The Unique Identifier Extension Field</a>
        </h3>
<p id="section-5.3-1">
          The Unique Identifier extension field provides the client with a
          cryptographically strong means of detecting replayed packets. It has a
          Field Type of 0x0104. When the extension field is included in a
          client packet (mode 3), its body <span class="bcp14">SHALL</span> consist of a string of octets
          generated by a <span><a href="#RFC4086" class="xref">cryptographically secure random
          number generator</a> [<a href="#RFC4086" class="xref">RFC4086</a>]</span>. The string <span class="bcp14">MUST</span> be at least 32 octets
          long. When the extension field is included in a server packet
          (mode 4), its body <span class="bcp14">SHALL</span> contain the same octet string as was provided
          in the client packet to which the server is responding. All server
          packets generated by NTS-implementing servers in response to client
          packets containing this extension field <span class="bcp14">MUST</span> also contain this field
          with the same content as in the client's request. The field's use in
          modes other than client-server is not defined.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">
          This extension field <span class="bcp14">MAY</span> also be used standalone, without NTS, in
          which case it provides the client with a means of detecting spoofed
          packets from off-path attackers. Historically, NTP's origin timestamp
          field has played both these roles, but this
          is suboptimal for cryptographic purposes because it is only 64 bits long, and depending on
          implementation details, most of those bits may be predictable. In
          contrast, the Unique Identifier extension field enables a degree of
          unpredictability and collision resistance more consistent with
          cryptographic best practice.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="nts-cookie-extension-field">
<section id="section-5.4">
        <h3 id="name-the-nts-cookie-extension-fi">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-the-nts-cookie-extension-fi" class="section-name selfRef">The NTS Cookie Extension Field</a>
        </h3>
<p id="section-5.4-1">
          The NTS Cookie extension field has a Field Type of 0x0204. Its
          purpose is to carry information that enables the server to recompute
          keys and other session state without having to store any per-client
          state. The contents of its body <span class="bcp14">SHALL</span> be implementation-defined, and
          clients <span class="bcp14">MUST NOT</span> attempt to interpret them.
          See <a href="#suggested-format-for-nts-cookies" class="xref">Section 6</a> for a suggested
          construction.  The NTS Cookie extension field <span class="bcp14">MUST NOT</span> be included in
          NTP packets whose mode is other than 3 (client) or 4 (server).<a href="#section-5.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="nts-cookie-placeholder-extension-field">
<section id="section-5.5">
        <h3 id="name-the-nts-cookie-placeholder-">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-the-nts-cookie-placeholder-" class="section-name selfRef">The NTS Cookie Placeholder Extension Field</a>
        </h3>
<p id="section-5.5-1">
          The NTS Cookie Placeholder extension field has a Field Type of
          0x0304.  When this extension field is included in a client packet
          (mode 3), it communicates to the server that the client wishes it to
          send additional cookies in its response. This extension field <span class="bcp14">MUST NOT</span>
          be included in NTP packets whose mode is other than 3.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
<p id="section-5.5-2">
          Whenever an NTS Cookie Placeholder extension field is present, it <span class="bcp14">MUST</span>
          be accompanied by an NTS Cookie extension field. The body length of
          the NTS Cookie Placeholder extension field <span class="bcp14">MUST</span> be the same as the
          body length of the NTS Cookie extension field. This length requirement
          serves to ensure that the response will not be larger than the
          request, in order to improve timekeeping precision and prevent DDoS
          amplification. The contents of the NTS Cookie Placeholder extension
          field's body <span class="bcp14">SHOULD</span> be all zeros and, aside from checking its length,
          <span class="bcp14">MUST</span> be ignored by the server.<a href="#section-5.5-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="nts-aeef-extension-field">
<section id="section-5.6">
        <h3 id="name-the-nts-authenticator-and-e">
<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-the-nts-authenticator-and-e" class="section-name selfRef">The NTS Authenticator and Encrypted Extension Fields Extension Field</a>
        </h3>
<p id="section-5.6-1">
          The NTS Authenticator and Encrypted Extension Fields extension field
          is the central cryptographic element of an NTS-protected NTP packet.
          Its Field Type is 0x0404. It <span class="bcp14">SHALL</span> be formatted according to
          <a href="#fig-aeef-field" class="xref">Figure 4</a> and include the following fields:<a href="#section-5.6-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5.6-2">
          <dt id="section-5.6-2.1">Nonce Length:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-2.2">Two octets in network byte order, giving the length
              of the Nonce field, excluding any padding, interpreted as an
              unsigned integer.<a href="#section-5.6-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-2.3">Ciphertext Length:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-2.4">Two octets in network byte order, giving the
              length of the Ciphertext field, excluding any padding, interpreted
              as an unsigned integer.<a href="#section-5.6-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-2.5">Nonce:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-2.6">A nonce as required by the negotiated AEAD algorithm. The
              end of the field is zero-padded to a word (four octets) boundary.<a href="#section-5.6-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-2.7">Ciphertext:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-2.8">The output of the negotiated AEAD algorithm. The
              structure of this field is determined by the negotiated algorithm,
              but it typically contains an authentication tag in addition to the
              actual ciphertext. The end of the field is zero-padded to a word
              (four octets) boundary.<a href="#section-5.6-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-2.9">Additional Padding:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-2.10">Clients that use a nonce length shorter than
              the maximum allowed by the negotiated AEAD algorithm may be required
              to include additional zero-padding. The necessary length of this
              field is specified below.<a href="#section-5.6-2.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span id="name-nts-authenticator-and-encry"></span><div id="fig-aeef-field">
<figure id="figure-4">
          <div class="artwork art-text alignLeft" id="section-5.6-3.1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Nonce Length         |      Ciphertext Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.          Nonce, including up to 3 octets padding              .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.        Ciphertext, including up to 3 octets padding           .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                                                               .
.                      Additional Padding                       .
.                                                               .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-nts-authenticator-and-encry" class="selfRef">NTS Authenticator and Encrypted Extension Fields Extension Field Format</a>
          </figcaption></figure>
</div>
<p id="section-5.6-4">
          The Ciphertext field <span class="bcp14">SHALL</span> be formed by providing the following inputs
          to the negotiated AEAD algorithm:<a href="#section-5.6-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5.6-5">
          <dt id="section-5.6-5.1">K:</dt>
          <dd style="margin-left: 2.0em" id="section-5.6-5.2">For packets sent from the client to the server, the C2S key
              <span class="bcp14">SHALL</span> be used. For packets sent from the server to the client, the
              S2C key <span class="bcp14">SHALL</span> be used.<a href="#section-5.6-5.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-5.3">A:</dt>
          <dd style="margin-left: 2.0em" id="section-5.6-5.4">The associated data <span class="bcp14">SHALL</span> consist of the portion of the NTP
              packet beginning from the start of the NTP header and ending at
              the end of the last extension field that precedes the NTS
              Authenticator and Encrypted Extension Fields extension field.<a href="#section-5.6-5.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-5.5">P:</dt>
          <dd style="margin-left: 2.0em" id="section-5.6-5.6">The plaintext <span class="bcp14">SHALL</span> consist of all (if any) NTP extension fields to
              be encrypted; if multiple extension fields are present, they <span class="bcp14">SHALL</span> be
              joined by concatenation. Each such field <span class="bcp14">SHALL</span> be formatted in
              accordance with <span><a href="#RFC7822" class="xref">RFC 7822</a> [<a href="#RFC7822" class="xref">RFC7822</a>]</span>, except that, contrary to the RFC
              7822 requirement that fields have a minimum length of 16 or 28 octets,
              encrypted extension fields <span class="bcp14">MAY</span> be arbitrarily short (but still <span class="bcp14">MUST</span> be
              a multiple of 4 octets in length).<a href="#section-5.6-5.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-5.7">N:</dt>
          <dd style="margin-left: 2.0em" id="section-5.6-5.8">The nonce <span class="bcp14">SHALL</span> be formed however required by the negotiated
              AEAD algorithm.<a href="#section-5.6-5.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.6-6">
          The purpose of the Additional Padding field is to ensure
          that servers can always choose a nonce whose length is
          adequate to ensure its uniqueness, even if the client
          chooses a shorter one, and still ensure that the overall
          length of the server's response packet does not exceed the
          length of the request. For mode 4 (server) packets, no
          Additional Padding field is ever required.  For mode 3
          (client) packets, the length of the Additional Padding field
          <span class="bcp14">SHALL</span> be computed as follows.  Let 'N_LEN' be the padded
          length of the Nonce field. Let 'N_MAX' be, as specified
          by <span><a href="#RFC5116" class="xref">RFC 5116</a> [<a href="#RFC5116" class="xref">RFC5116</a>]</span>, the maximum
          permitted nonce length for the negotiated AEAD
          algorithm. Let 'N_REQ' be the lesser of 16 and N_MAX,
          rounded up to the nearest multiple of 4.  If N_LEN is
          greater than or equal to N_REQ, then no Additional Padding
          field is required. Otherwise, the Additional Padding field
          <span class="bcp14">SHALL</span> be at least N_REQ - N_LEN octets in length. Servers
          <span class="bcp14">MUST</span> enforce this requirement by discarding any packet that
          does not conform to it.<a href="#section-5.6-6" class="pilcrow">¶</a></p>
<p id="section-5.6-7">
          Senders are always free to include more Additional Padding
          than mandated by the above paragraph. Theoretically, it
          could be necessary to do so in order to bring the extension
          field to the minimum length required by <span><a href="#RFC7822" class="xref">RFC 7822</a> [<a href="#RFC7822" class="xref">RFC7822</a>]</span>. This should never happen in
          practice because any reasonable AEAD algorithm will have a nonce and
          an authenticator long enough to bring the extension field to
          its required length already.  Nonetheless, implementers are
          advised to explicitly handle this case and ensure that the
          extension field they emit is of legal length.<a href="#section-5.6-7" class="pilcrow">¶</a></p>
<p id="section-5.6-8">
          The NTS Authenticator and Encrypted Extension Fields extension field
          <span class="bcp14">MUST NOT</span> be included in NTP packets whose mode is other than 3
          (client) or 4 (server).<a href="#section-5.6-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="protocol-details">
<section id="section-5.7">
        <h3 id="name-protocol-details">
<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-protocol-details" class="section-name selfRef">Protocol Details</a>
        </h3>
<p id="section-5.7-1">
          A client sending an NTS-protected request <span class="bcp14">SHALL</span> include the following
          extension fields as displayed in  <a href="#fig_NTSTimeSyncMessage" class="xref">Figure 5</a>:<a href="#section-5.7-1" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-5.7-2.1">
              Exactly one Unique Identifier extension field that <span class="bcp14">MUST</span> be
              authenticated, <span class="bcp14">MUST NOT</span> be encrypted, and whose contents <span class="bcp14">MUST</span> be
              the output of a <span><a href="#RFC4086" class="xref">cryptographically secure random number generator</a> [<a href="#RFC4086" class="xref">RFC4086</a>]</span>.<a href="#section-5.7-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal ulEmpty" id="section-5.7-2.2">
              Exactly one NTS Cookie extension field that <span class="bcp14">MUST</span> be authenticated
              and <span class="bcp14">MUST NOT</span> be encrypted. The cookie <span class="bcp14">MUST</span> be one which has been
              previously provided to the client, either from the key establishment
              server during the NTS-KE handshake or from the NTP server in
              response to a previous NTS-protected NTP request.<a href="#section-5.7-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal ulEmpty" id="section-5.7-2.3">
              Exactly one NTS Authenticator and Encrypted Extension Fields
              extension field, generated using an AEAD algorithm and C2S key
              established through NTS-KE.<a href="#section-5.7-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.7-3">
          To protect the client's privacy, the client <span class="bcp14">SHOULD</span> avoid reusing
          a cookie. If the client does not have any cookies that it has not
          already sent, it <span class="bcp14">SHOULD</span> initiate a rerun of the NTS-KE protocol. The
          client <span class="bcp14">MAY</span> reuse cookies in order to prioritize resilience over
          unlinkability. Which of the two that should be prioritized in any
          particular case is dependent on the application and the user's
          preference. <a href="#Unlinkability" class="xref">Section 9.1</a> describes the privacy
          considerations of this in further detail.<a href="#section-5.7-3" class="pilcrow">¶</a></p>
<p id="section-5.7-4">
          The client <span class="bcp14">MAY</span> include one or more NTS Cookie Placeholder extension
          fields that <span class="bcp14">MUST</span> be authenticated and <span class="bcp14">MAY</span> be encrypted. The number of
          NTS Cookie Placeholder extension fields that the client includes
          <span class="bcp14">SHOULD</span> be such that if the client includes N placeholders and the server
          sends back N+1 cookies, the number of unused cookies stored by the
          client will come to eight. The client <span class="bcp14">SHOULD NOT</span> include more than seven
          NTS Cookie Placeholder extension fields in a request. When both the
          client and server adhere to all cookie-management guidance provided in
          this memo, the number of placeholder extension fields will equal the
          number of dropped packets since the last successful volley.<a href="#section-5.7-4" class="pilcrow">¶</a></p>
<p id="section-5.7-5">
          In rare circumstances, it may be necessary to include fewer
          NTS Cookie Placeholder extensions than recommended above in
          order to prevent datagram fragmentation. When cookies adhere
          to the format recommended in <a href="#suggested-format-for-nts-cookies" class="xref">Section 6</a> and the AEAD in
          use is the mandatory-to-implement AEAD_AES_SIV_CMAC_256,
          senders can include a cookie and seven placeholders and
          still have packet size fall comfortably below 1280 octets if
          no non-NTS-related extensions are used; 1280 octets is the
          minimum prescribed MTU for IPv6 and is generally safe
          for avoiding IPv4 fragmentation. Nonetheless,
          senders <span class="bcp14">SHOULD</span> include fewer cookies and placeholders than
          otherwise indicated if doing so is necessary to prevent
          fragmentation.<a href="#section-5.7-5" class="pilcrow">¶</a></p>
<span id="name-nts-protected-ntp-time-sync"></span><div id="fig_NTSTimeSyncMessage">
<figure id="figure-5">
          <div class="artwork art-text alignLeft" id="section-5.7-6.1">
<pre>
                +---------------------------------------+
                | - Verify time request message.        |
                | - Generate time response message.     |
                |   - Included NTPv4 extension fields:  |
                |      o Unique Identifier EF           |
                |      o NTS Authentication and         |
                |        Encrypted Extension Fields EF  |
                |        - NTS Cookie EF                |
                |        - &lt;NTS Cookie EF&gt;              |
                | - Transmit time request packet.       |
                +-----------------+---------------------+
                                  |
                                  |
Server -----------+---------------+-----+-----------------------&gt;
                  ^                      \
                 /                        \
  Time request  /                          \   Time response
  (mode 3)     /                            \  (mode 4)
              /                              \
             /                                V
Client -----+---------------------------------+-----------------&gt;
            |                                 |
            |                                 |
            |                                 |
+-----------+-----------------------+   +-----+------------------+
|- Generate time request message.   |   |- Verify time response  |
| - Include NTPv4 Extension fields: |   |  message.              |
|    o Unique Identifier EF         |   |- Extract cookie(s).    |
|    o NTS Cookie EF                |   |- Time synchronization  |
|    o &lt;NTS Cookie Placeholder EF&gt;  |   |  processing.           |
|                                   |   +------------------------+
|- Generate AEAD tag of NTP message.|
|- Add NTS Authentication and       |
|  Encrypted Extension Fields EF.   |
|- Transmit time request packet.    |
+-----------------------------------+
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-nts-protected-ntp-time-sync" class="selfRef">NTS-Protected NTP Time Synchronization Messages</a>
          </figcaption></figure>
</div>
<p id="section-5.7-7">
          The client <span class="bcp14">MAY</span> include additional (non-NTS-related) extension fields
          that <span class="bcp14">MAY</span> appear prior to the NTS Authenticator and Encrypted Extension
          Fields extension fields (therefore authenticated but not encrypted),
          within it (therefore encrypted and authenticated), or after it
          (therefore neither encrypted nor authenticated).
          The server <span class="bcp14">MUST</span> discard any unauthenticated extension
          fields. Future specifications of extension fields <span class="bcp14">MAY</span> provide
          exceptions to this rule.<a href="#section-5.7-7" class="pilcrow">¶</a></p>
<p id="section-5.7-8">
          Upon receiving an NTS-protected request, the server <span class="bcp14">SHALL</span> (through some
          implementation-defined mechanism) use the cookie to recover the AEAD
          algorithm, C2S key, and S2C key associated with the request, and then
          use the C2S key to authenticate the packet and decrypt the ciphertext.
          If the cookie is valid and authentication and decryption succeed, the
          server <span class="bcp14">SHALL</span> include the following extension fields in its response:<a href="#section-5.7-8" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-5.7-9.1">
              Exactly one Unique Identifier extension field that <span class="bcp14">MUST</span> be
              authenticated, <span class="bcp14">MUST NOT</span> be encrypted, and whose contents <span class="bcp14">SHALL</span> echo
              those provided by the client.<a href="#section-5.7-9.1" class="pilcrow">¶</a>
</li>
          <li class="normal ulEmpty" id="section-5.7-9.2">
              Exactly one NTS Authenticator and Encrypted Extension Fields
              extension field, generated using the AEAD algorithm and S2C key
              recovered from the cookie provided by the client.<a href="#section-5.7-9.2" class="pilcrow">¶</a>
</li>
          <li class="normal ulEmpty" id="section-5.7-9.3">
              One or more NTS Cookie extension fields that <span class="bcp14">MUST</span> be authenticated
              and encrypted. The number of NTS Cookie extension fields included
              <span class="bcp14">SHOULD</span> be equal to, and <span class="bcp14">MUST NOT</span> exceed, one plus the number of
              valid NTS Cookie Placeholder extension fields included in the
              request. The cookies returned in those fields <span class="bcp14">MUST</span> be valid for use
              with the NTP server that sent them. They <span class="bcp14">MAY</span> be valid for other NTP
              servers as well, but there is no way for the server to indicate
              this.<a href="#section-5.7-9.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.7-10">
          We emphasize the contrast that NTS Cookie extension fields <span class="bcp14">MUST NOT</span> be
          encrypted when sent from client to server but <span class="bcp14">MUST</span> be encrypted when
          sent from server to client. The former is necessary in order for the
          server to be able to recover the C2S and S2C keys, while the latter is
          necessary to satisfy the unlinkability goals discussed in <a href="#Unlinkability" class="xref">Section 9.1</a>. We emphasize also that "encrypted"
          means encapsulated within the NTS Authenticator and Encrypted
          Extensions extension field. While the body of an NTS Cookie extension
          field will generally consist of some sort of AEAD output (regardless of
          whether the recommendations of <a href="#suggested-format-for-nts-cookies" class="xref">Section 6</a> are precisely followed),
          this is not sufficient to make the extension field
          "encrypted".<a href="#section-5.7-10" class="pilcrow">¶</a></p>
<p id="section-5.7-11">
          The server <span class="bcp14">MAY</span> include additional (non-NTS-related) extension fields
          that <span class="bcp14">MAY</span> appear prior to the NTS Authenticator and Encrypted Extension
          Fields extension field (therefore authenticated but not encrypted),
          within it (therefore encrypted and authenticated), or after it
          (therefore neither encrypted nor authenticated).
          The client <span class="bcp14">MUST</span> discard any unauthenticated extension fields.
          Future specifications of extension fields <span class="bcp14">MAY</span> provide exceptions to
          this rule.<a href="#section-5.7-11" class="pilcrow">¶</a></p>
<p id="section-5.7-12">
          Upon receiving an NTS-protected response, the client <span class="bcp14">MUST</span> verify that
          the Unique Identifier matches that of an outstanding request, and that
          the packet is authentic under the S2C key associated with that
          request. If either of these checks fails, the packet <span class="bcp14">MUST</span> be discarded
          without further processing. In particular, the client <span class="bcp14">MUST</span> discard
          unprotected responses to NTS-protected requests.<a href="#section-5.7-12" class="pilcrow">¶</a></p>
<p id="section-5.7-13">
          If the server is unable to validate the cookie or authenticate the
          request, it <span class="bcp14">SHOULD</span> respond with a Kiss-o'-Death (KoD) packet (see
          Section <a href="https://www.rfc-editor.org/rfc/rfc5905#section-7.4" class="relref">7.4</a>
          of <span><a href="#RFC5905" class="xref">RFC 5905</a> [<a href="#RFC5905" class="xref">RFC5905</a>]</span>) with kiss code
          "NTSN", meaning "NTS NAK" (NTS negative-acknowledgment).
          It <span class="bcp14">MUST NOT</span> include any NTS Cookie or NTS Authenticator and
          Encrypted Extension Fields extension fields.<a href="#section-5.7-13" class="pilcrow">¶</a></p>
<p id="section-5.7-14">
          If the NTP server has previously responded with authentic NTS-protected
          NTP packets, the client <span class="bcp14">MUST</span> verify that
          any KoD packets received from the server contain the Unique Identifier
          extension field and that the Unique Identifier matches that of an
          outstanding request. If this check fails, the packet <span class="bcp14">MUST</span> be discarded
          without further processing. If this check passes, the client <span class="bcp14">MUST</span> comply
          with Section <a href="https://www.rfc-editor.org/rfc/rfc5905#section-7.4" class="relref">7.4</a>
          of <span><a href="#RFC5905" class="xref">RFC 5905</a> [<a href="#RFC5905" class="xref">RFC5905</a>]</span> where required.<a href="#section-5.7-14" class="pilcrow">¶</a></p>
<p id="section-5.7-15">
          A client <span class="bcp14">MAY</span> automatically rerun the NTS-KE protocol upon forced
          disassociation from an NTP server. In that case, it <span class="bcp14">MUST</span> avoid quickly
          looping between the NTS-KE and NTP servers by rate limiting the
          retries. Requirements for retry intervals in NTS-KE are described in
          <a href="#nts-ke-retry" class="xref">Section 4.2</a>.<a href="#section-5.7-15" class="pilcrow">¶</a></p>
<p id="section-5.7-16">
          Upon reception of the NTS NAK kiss code, the client <span class="bcp14">SHOULD</span> wait until
          the next poll for a valid NTS-protected response, and if none is
          received, initiate a fresh NTS-KE handshake to try to renegotiate new
          cookies, AEAD keys, and parameters. If the NTS-KE handshake succeeds,
          the client <span class="bcp14">MUST</span> discard all old cookies and parameters and use the new
          ones instead. As long as the NTS-KE handshake has not succeeded, the
          client <span class="bcp14">SHOULD</span> continue polling the NTP server using the cookies and
          parameters it has.<a href="#section-5.7-16" class="pilcrow">¶</a></p>
<p id="section-5.7-17">
          To allow for NTP session restart when the NTS-KE server is unavailable
          and to reduce NTS-KE server load, the client <span class="bcp14">SHOULD</span> keep at least one
          unused but recent cookie, AEAD keys, negotiated AEAD algorithm, and
          other necessary parameters in persistent storage. This way, the client
          is able to resume the NTP session without performing renewed NTS-KE
          negotiation.<a href="#section-5.7-17" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="suggested-format-for-nts-cookies">
<section id="section-6">
      <h2 id="name-suggested-format-for-nts-co">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-suggested-format-for-nts-co" class="section-name selfRef">Suggested Format for NTS Cookies</a>
      </h2>
<p id="section-6-1">
        This section is non-normative. It gives a suggested way for servers to
        construct NTS cookies. All normative requirements are stated in
        <a href="#new-cookie-for-ntpv4" class="xref">Section 4.1.6</a> and <a href="#nts-cookie-extension-field" class="xref">Section 5.4</a>.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
        The role of cookies in NTS is closely analogous to that of session
        tickets in TLS. Accordingly, the thematic resemblance of this section to
        <span><a href="#RFC5077" class="xref">RFC 5077</a> [<a href="#RFC5077" class="xref">RFC5077</a>]</span> is deliberate, and the reader
        should likewise take heed of its security considerations.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">
        Servers should select an AEAD algorithm that they will use to encrypt
        and authenticate cookies. The chosen algorithm should be one such as
        <span><a href="#RFC5297" class="xref">AEAD_AES_SIV_CMAC_256</a> [<a href="#RFC5297" class="xref">RFC5297</a>]</span>, which resists
        accidental nonce reuse. It need not be the same as the one that was
        negotiated with the client. Servers should randomly generate and store a
        secret master AEAD key 'K'. Servers should additionally choose a non-secret,
        unique value 'I' as key identifier for 'K'.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">
        Servers should periodically (e.g., once daily) generate a new pair '(I,K)'
        and immediately switch to using these values for all newly-generated
        cookies. Following each such key rotation, servers should
        securely erase any previously generated keys that should now be expired.
        Servers should continue to accept any cookie generated using keys that
        they have not yet erased, even if those keys are no longer current.
        Erasing old keys provides for forward secrecy, limiting the scope of
        what old information can be stolen if a master key is somehow
        compromised. Holding on to a limited number of old keys allows clients
        to seamlessly transition from one generation to the next without having
        to perform a new NTS-KE handshake.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">
        The need to keep keys synchronized between NTS-KE and NTP servers as
        well as across load-balanced clusters can make automatic key rotation
        challenging. However, the task can be accomplished without the need for
        central key-management infrastructure by using a ratchet, i.e., making
        each new key a deterministic, cryptographically pseudorandom function
        of its predecessor. A recommended concrete implementation of this
        approach is to use <span><a href="#RFC5869" class="xref">HKDF</a> [<a href="#RFC5869" class="xref">RFC5869</a>]</span> to derive new
        keys, using the key's predecessor as Input Keying Material and its key
        identifier as a salt.<a href="#section-6-5" class="pilcrow">¶</a></p>
<p id="section-6-6">
        To form a cookie, servers should first form a plaintext 'P' consisting
        of the following fields:<a href="#section-6-6" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-6-7.1">The AEAD algorithm negotiated during NTS-KE.<a href="#section-6-7.1" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="section-6-7.2">The S2C key.<a href="#section-6-7.2" class="pilcrow">¶</a>
</li>
        <li class="normal ulEmpty" id="section-6-7.3">The C2S key.<a href="#section-6-7.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-6-8">
        Servers should then generate a nonce 'N' uniformly at random, and form
        AEAD output 'C' by encrypting 'P' under key 'K' with nonce 'N' and no
        associated data.<a href="#section-6-8" class="pilcrow">¶</a></p>
<p id="section-6-9">
        The cookie should consist of the tuple '(I,N,C)'.<a href="#section-6-9" class="pilcrow">¶</a></p>
<p id="section-6-10">
        To verify and decrypt a cookie provided by the client, first parse it
        into its components 'I', 'N', and 'C'. Use 'I' to look up its decryption
        key 'K'. If the key whose identifier is 'I' has been erased or never
        existed, decryption fails; reply with an NTS NAK. Otherwise, attempt to
        decrypt and verify ciphertext 'C' using key 'K' and nonce 'N' with no
        associated data. If decryption or verification fails, reply with an NTS
        NAK. Otherwise, parse out the contents of the resulting plaintext 'P' to
        obtain the negotiated AEAD algorithm, S2C key, and C2S key.<a href="#section-6-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana-considerations">
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<section id="section-7.1">
        <h3 id="name-service-name-and-transport-">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-service-name-and-transport-" class="section-name selfRef">Service Name and Transport Protocol Port Number Registry</a>
        </h3>
<p id="section-7.1-1">
          IANA has allocated the following entry in the
          "Service Name and Transport Protocol
          Port Number Registry" <span>[<a href="#RFC6335" class="xref">RFC6335</a>]</span>:<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.1-2">
          <dt id="section-7.1-2.1">Service Name:</dt>
          <dd style="margin-left: 1.5em" id="section-7.1-2.2">ntske<a href="#section-7.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.1-2.3">Port Number:</dt>
          <dd style="margin-left: 1.5em" id="section-7.1-2.4">4460<a href="#section-7.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.1-2.5">Transport Protocol:</dt>
          <dd style="margin-left: 1.5em" id="section-7.1-2.6">tcp<a href="#section-7.1-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.1-2.7">Description:</dt>
          <dd style="margin-left: 1.5em" id="section-7.1-2.8">Network Time Security Key Establishment<a href="#section-7.1-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.1-2.9">Assignee:</dt>
          <dd style="margin-left: 1.5em" id="section-7.1-2.10">IESG &lt;iesg@ietf.org&gt;<a href="#section-7.1-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.1-2.11">Contact:</dt>
          <dd style="margin-left: 1.5em" id="section-7.1-2.12">IETF Chair &lt;chair@ietf.org&gt;<a href="#section-7.1-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.1-2.13">Registration Date:</dt>
          <dd style="margin-left: 1.5em" id="section-7.1-2.14">2020-04-07<a href="#section-7.1-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.1-2.15">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-7.1-2.16">RFC 8915<a href="#section-7.1-2.16" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
<section id="section-7.2">
        <h3 id="name-tls-application-layer-proto">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-tls-application-layer-proto" class="section-name selfRef">TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs Registry</a>
        </h3>
<p id="section-7.2-1">
          IANA has allocated the following entry in the
          "TLS Application-Layer Protocol Negotiation
            (ALPN) Protocol IDs" registry <span>[<a href="#RFC7301" class="xref">RFC7301</a>]</span>:<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.2-2">
          <dt id="section-7.2-2.1">Protocol:</dt>
          <dd style="margin-left: 1.5em" id="section-7.2-2.2">Network Time Security Key Establishment, version 1<a href="#section-7.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.2-2.3">Identification Sequence:</dt>
          <dd style="margin-left: 1.5em" id="section-7.2-2.4">0x6E 0x74 0x73 0x6B 0x65 0x2F 0x31 ("ntske/1")<a href="#section-7.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.2-2.5">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-7.2-2.6">RFC 8915, <a href="#nts-ke" class="xref">Section 4</a><a href="#section-7.2-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
<section id="section-7.3">
        <h3 id="name-tls-exporter-labels-registr">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-tls-exporter-labels-registr" class="section-name selfRef">TLS Exporter Labels Registry</a>
        </h3>
<p id="section-7.3-1">
          IANA has allocated the following entry in the
          <span><a href="#RFC5705" class="xref">TLS Exporter Labels registry</a> [<a href="#RFC5705" class="xref">RFC5705</a>]</span>:<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<table class="center" id="table-1">
          <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Value</th>
              <th class="text-left" rowspan="1" colspan="1">DTLS-OK</th>
              <th class="text-left" rowspan="1" colspan="1">Recommended</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
              <th class="text-left" rowspan="1" colspan="1">Note</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">EXPORTER-network-time-security</td>
              <td class="text-left" rowspan="1" colspan="1">Y</td>
              <td class="text-left" rowspan="1" colspan="1">Y</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915, <a href="#key-extraction" class="xref">Section 4.3</a>
</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
          </tbody>
        </table>
</section>
<section id="section-7.4">
        <h3 id="name-ntp-kiss-o-death-codes-regi">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-ntp-kiss-o-death-codes-regi" class="section-name selfRef">NTP Kiss-o'-Death Codes Registry</a>
        </h3>
<p id="section-7.4-1">
          IANA has allocated the following entry in the
          "NTP Kiss-o'-Death Codes"
   registry <span>[<a href="#RFC5905" class="xref">RFC5905</a>]</span>:<a href="#section-7.4-1" class="pilcrow">¶</a></p>
<table class="center" id="table-2">
          <caption><a href="#table-2" class="selfRef">Table 2</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Code</th>
              <th class="text-left" rowspan="1" colspan="1">Meaning</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">NTSN</td>
              <td class="text-left" rowspan="1" colspan="1">Network Time Security (NTS) negative-acknowledgment (NAK)</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915, <a href="#protocol-details" class="xref">Section 5.7</a>
</td>
            </tr>
          </tbody>
        </table>
</section>
<section id="section-7.5">
        <h3 id="name-ntp-extension-field-types-r">
<a href="#section-7.5" class="section-number selfRef">7.5. </a><a href="#name-ntp-extension-field-types-r" class="section-name selfRef">NTP Extension Field Types Registry</a>
        </h3>
<p id="section-7.5-1">
          IANA has allocated the following entries in the
          "NTP Extension Field Types" registry <span>[<a href="#RFC5905" class="xref">RFC5905</a>]</span>:<a href="#section-7.5-1" class="pilcrow">¶</a></p>
<table class="center" id="table-3">
          <caption><a href="#table-3" class="selfRef">Table 3</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Field Type</th>
              <th class="text-left" rowspan="1" colspan="1">Meaning</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0x0104</td>
              <td class="text-left" rowspan="1" colspan="1">Unique Identifier</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915,
            <a href="#unique-identifier-extension-field" class="xref">Section 5.3</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0x0204</td>
              <td class="text-left" rowspan="1" colspan="1">NTS Cookie</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915, <a href="#nts-cookie-extension-field" class="xref">Section 5.4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0x0304</td>
              <td class="text-left" rowspan="1" colspan="1">NTS Cookie Placeholder</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915,
            <a href="#nts-cookie-placeholder-extension-field" class="xref">Section 5.5</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0x0404</td>
              <td class="text-left" rowspan="1" colspan="1">NTS Authenticator and Encrypted Extension Fields</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915, <a href="#nts-aeef-extension-field" class="xref">Section 5.6</a>
</td>
            </tr>
          </tbody>
        </table>
</section>
<section id="section-7.6">
        <h3 id="name-network-time-security-key-e">
<a href="#section-7.6" class="section-number selfRef">7.6. </a><a href="#name-network-time-security-key-e" class="section-name selfRef">Network Time Security Key Establishment Record Types Registry</a>
        </h3>
<p id="section-7.6-1">
          IANA has created a new registry entitled
          "Network Time Security Key Establishment Record Types".
          Entries have the following fields:<a href="#section-7.6-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.6-2">
          <dt id="section-7.6-2.1">Record Type Number (<span class="bcp14">REQUIRED</span>):</dt>
          <dd style="margin-left: 1.5em" id="section-7.6-2.2">An integer in the range
              0-32767 inclusive.<a href="#section-7.6-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.6-2.3">Description (<span class="bcp14">REQUIRED</span>):</dt>
          <dd style="margin-left: 1.5em" id="section-7.6-2.4">A short text description of the purpose of
              the field.<a href="#section-7.6-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.6-2.5">Reference (<span class="bcp14">REQUIRED</span>):</dt>
          <dd style="margin-left: 1.5em" id="section-7.6-2.6">A reference to a document specifying the
              semantics of the record.<a href="#section-7.6-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-7.6-3">
          The registration policy varies by Record Type Number, as follows:<a href="#section-7.6-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.6-4">
          <dt id="section-7.6-4.1">0-1023:</dt>
          <dd style="margin-left: 1.5em" id="section-7.6-4.2">IETF Review<a href="#section-7.6-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.6-4.3">1024-16383:</dt>
          <dd style="margin-left: 1.5em" id="section-7.6-4.4">Specification Required<a href="#section-7.6-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.6-4.5">16384-32767:</dt>
          <dd style="margin-left: 1.5em" id="section-7.6-4.6">Private or Experimental Use<a href="#section-7.6-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-7.6-5">
          The initial contents of this registry are as follows:<a href="#section-7.6-5" class="pilcrow">¶</a></p>
<table class="center" id="table-4">
          <caption><a href="#table-4" class="selfRef">Table 4</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Record Type Number</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">End of Message</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915, <a href="#end-of-message" class="xref">Section 4.1.1</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">NTS Next Protocol Negotiation</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915,
            <a href="#nts-next-protocol-negotiation" class="xref">Section 4.1.2</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">Error</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915, <a href="#nts-error" class="xref">Section 4.1.3</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">3</td>
              <td class="text-left" rowspan="1" colspan="1">Warning</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915, <a href="#nts-warning" class="xref">Section 4.1.4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">4</td>
              <td class="text-left" rowspan="1" colspan="1">AEAD Algorithm Negotiation</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915, <a href="#aead-algorithm-negotiation" class="xref">Section 4.1.5</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">5</td>
              <td class="text-left" rowspan="1" colspan="1">New Cookie for NTPv4</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915, <a href="#new-cookie-for-ntpv4" class="xref">Section 4.1.6</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">6</td>
              <td class="text-left" rowspan="1" colspan="1">NTPv4 Server Negotiation</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915, <a href="#ntp-server-negotiation" class="xref">Section 4.1.7</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">7</td>
              <td class="text-left" rowspan="1" colspan="1">NTPv4 Port Negotiation</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915, <a href="#ntp-port-negotiation" class="xref">Section 4.1.8</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">8-16383</td>
              <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">16384-32767</td>
              <td class="text-left" rowspan="1" colspan="1">Reserved for Private or Experimental Use</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915</td>
            </tr>
          </tbody>
        </table>
</section>
<div id="iana-nts-next-protocols">
<section id="section-7.7">
        <h3 id="name-network-time-security-next-">
<a href="#section-7.7" class="section-number selfRef">7.7. </a><a href="#name-network-time-security-next-" class="section-name selfRef">Network Time Security Next Protocols Registry</a>
        </h3>
<p id="section-7.7-1">
          IANA has created a new registry entitled
          "Network Time Security Next Protocols". Entries have
          the following fields:<a href="#section-7.7-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.7-2">
          <dt id="section-7.7-2.1">Protocol ID (<span class="bcp14">REQUIRED</span>):</dt>
          <dd style="margin-left: 1.5em" id="section-7.7-2.2">An integer in the range 0-65535 inclusive,
              functioning as an identifier.<a href="#section-7.7-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.7-2.3">Protocol Name (<span class="bcp14">REQUIRED</span>):</dt>
          <dd style="margin-left: 1.5em" id="section-7.7-2.4">A short text string naming the protocol
              being identified.<a href="#section-7.7-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.7-2.5">Reference (<span class="bcp14">REQUIRED</span>):</dt>
          <dd style="margin-left: 1.5em" id="section-7.7-2.6"> A reference to a relevant specification
              document.<a href="#section-7.7-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-7.7-3">
          The registration policy varies by Protocol ID, as follows:<a href="#section-7.7-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.7-4">
          <dt id="section-7.7-4.1">0-1023:</dt>
          <dd style="margin-left: 1.5em" id="section-7.7-4.2">IETF Review<a href="#section-7.7-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.7-4.3">1024-32767:</dt>
          <dd style="margin-left: 1.5em" id="section-7.7-4.4">Specification Required<a href="#section-7.7-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.7-4.5">32768-65535:</dt>
          <dd style="margin-left: 1.5em" id="section-7.7-4.6">Private or Experimental Use<a href="#section-7.7-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-7.7-5">
          The initial contents of this registry are as follows:<a href="#section-7.7-5" class="pilcrow">¶</a></p>
<table class="center" id="table-5">
          <caption><a href="#table-5" class="selfRef">Table 5</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Protocol ID</th>
              <th class="text-left" rowspan="1" colspan="1">Protocol Name</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">Network Time Protocol version 4 (NTPv4)</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1-32767</td>
              <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">32768-65535</td>
              <td class="text-left" rowspan="1" colspan="1">Reserved for Private or Experimental Use</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915</td>
            </tr>
          </tbody>
        </table>
</section>
</div>
<section id="section-7.8">
        <h3 id="name-network-time-security-error">
<a href="#section-7.8" class="section-number selfRef">7.8. </a><a href="#name-network-time-security-error" class="section-name selfRef">Network Time Security Error and Warning Codes Registries</a>
        </h3>
<p id="section-7.8-1">
          IANA has created two new registries entitled
          "Network Time Security Error Codes" and
          "Network Time Security Warning Codes". Entries in each 
          have the following fields:<a href="#section-7.8-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.8-2">
          <dt id="section-7.8-2.1">Number (<span class="bcp14">REQUIRED</span>):</dt>
          <dd style="margin-left: 1.5em" id="section-7.8-2.2">An integer in the range 0-65535 inclusive<a href="#section-7.8-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.8-2.3">Description (<span class="bcp14">REQUIRED</span>):</dt>
          <dd style="margin-left: 1.5em" id="section-7.8-2.4">A short text description of the
              condition.<a href="#section-7.8-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.8-2.5">Reference (<span class="bcp14">REQUIRED</span>):</dt>
          <dd style="margin-left: 1.5em" id="section-7.8-2.6">A reference to a relevant specification
              document.<a href="#section-7.8-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-7.8-3">
          The registration policy varies by Number, as follows:<a href="#section-7.8-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-7.8-4">
          <dt id="section-7.8-4.1">0-1023:</dt>
          <dd style="margin-left: 1.5em" id="section-7.8-4.2">IETF Review<a href="#section-7.8-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.8-4.3">1024-32767:</dt>
          <dd style="margin-left: 1.5em" id="section-7.8-4.4">Specification Required<a href="#section-7.8-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-7.8-4.5">32768-65535:</dt>
          <dd style="margin-left: 1.5em" id="section-7.8-4.6">Private or Experimental Use<a href="#section-7.8-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-7.8-5">
          The initial contents of the "Network Time Security Error Codes" registry
          are as follows:<a href="#section-7.8-5" class="pilcrow">¶</a></p>
<table class="center" id="table-6">
          <caption><a href="#table-6" class="selfRef">Table 6</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Number</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">Unrecognized Critical Record</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915, <a href="#nts-error" class="xref">Section 4.1.3</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">Bad Request</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915, <a href="#nts-error" class="xref">Section 4.1.3</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">Internal Server Error</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915, <a href="#nts-error" class="xref">Section 4.1.3</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">3-32767</td>
              <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">32768-65535</td>
              <td class="text-left" rowspan="1" colspan="1">Reserved for Private or Experimental Use</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915</td>
            </tr>
          </tbody>
        </table>
<p id="section-7.8-7">
          The "Network Time Security Warning Codes" registry is
          initially empty except for the reserved range, i.e.:<a href="#section-7.8-7" class="pilcrow">¶</a></p>
<table class="center" id="table-7">
          <caption><a href="#table-7" class="selfRef">Table 7</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Number</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0-32767</td>
              <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">32768-65535</td>
              <td class="text-left" rowspan="1" colspan="1">Reserved for Private or Experimental Use</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 8915</td>
            </tr>
          </tbody>
        </table>
</section>
</section>
</div>
<section id="section-8">
      <h2 id="name-security-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-protected-modes">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-protected-modes" class="section-name selfRef">Protected Modes</a>
        </h3>
<p id="section-8.1-1">
          NTP provides many different operating modes in order to support different
          network topologies and to adapt to various requirements. This memo only
          specifies NTS for NTP modes 3 (client) and 4 (server) (see
          <a href="#sec-protocol-overview" class="xref">Section 1.3</a>). The best current practice for
          authenticating the other NTP modes is using the symmetric message
          authentication code feature as described in
          <span><a href="#RFC5905" class="xref">RFC 5905</a> [<a href="#RFC5905" class="xref">RFC5905</a>]</span> and
          <span><a href="#RFC8573" class="xref">RFC 8573</a> [<a href="#RFC8573" class="xref">RFC8573</a>]</span>.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-8.2">
        <h3 id="name-cookie-encryption-key-compr">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-cookie-encryption-key-compr" class="section-name selfRef">Cookie Encryption Key Compromise</a>
        </h3>
<p id="section-8.2-1">
          If the suggested format
          for NTS cookies in <a href="#suggested-format-for-nts-cookies" class="xref">Section 6</a>
          of this document is used, an attacker who has gained
          access to the secret cookie encryption key 'K' can impersonate
          the NTP server, including generating new cookies.
          NTP and NTS-KE server operators <span class="bcp14">SHOULD</span> remove compromised keys as soon
          as the compromise is discovered. This will cause the NTP servers to
          respond with NTS NAK, thus forcing key renegotiation. Note that this
          measure does not protect against MITM attacks where the attacker has access
          to a compromised cookie encryption key. If another cookie scheme is used,
          there are likely similar considerations for that particular scheme.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-8.3">
        <h3 id="name-sensitivity-to-ddos-attacks">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-sensitivity-to-ddos-attacks" class="section-name selfRef">Sensitivity to DDoS Attacks</a>
        </h3>
<p id="section-8.3-1">
          The introduction of NTS brings with it the introduction of asymmetric
          cryptography to NTP. Asymmetric cryptography is necessary for initial
          server authentication and AEAD key extraction. Asymmetric
          cryptosystems are generally orders of magnitude slower than their
          symmetric counterparts. This makes it much harder to build systems
          that can serve requests at a rate corresponding to the full line speed
          of the network connection. This, in turn, opens up a new possibility
          for DDoS attacks on NTP services.<a href="#section-8.3-1" class="pilcrow">¶</a></p>
<p id="section-8.3-2">
          The main protection against these attacks in NTS lies in that the use
          of asymmetric cryptosystems is only necessary in the initial NTS-KE
          phase of the protocol. Since the protocol design enables separation of
          the NTS-KE and NTP servers, a successful DDoS attack on an NTS-KE
          server separated from the NTP service it supports will not affect NTP
          users that have already performed initial authentication, AEAD key
          extraction, and cookie exchange.<a href="#section-8.3-2" class="pilcrow">¶</a></p>
<p id="section-8.3-3">
          NTS users should also consider that they are not fully protected
          against DoS attacks by on-path adversaries. In addition to dropping
          packets and attacks such as those described in
          <a href="#DelayAttack" class="xref">Section 8.6</a>, an on-path attacker can send spoofed
          Kiss-o'-Death replies, which are not authenticated, in response to NTP
          requests. This could result in significantly increased load on the
          NTS-KE server. Implementers have to weigh the user's need for
          unlinkability against the added resilience that comes with cookie
          reuse in cases of NTS-KE server unavailability.<a href="#section-8.3-3" class="pilcrow">¶</a></p>
</section>
<section id="section-8.4">
        <h3 id="name-avoiding-ddos-amplification">
<a href="#section-8.4" class="section-number selfRef">8.4. </a><a href="#name-avoiding-ddos-amplification" class="section-name selfRef">Avoiding DDoS Amplification</a>
        </h3>
<p id="section-8.4-1">
          Certain nonstandard and/or deprecated features of the Network Time
          Protocol enable clients to send a request to a server that causes the
          server to send a response much larger than the request. Servers that
          enable these features can be abused in order to amplify traffic volume
          in DDoS attacks by sending them a request with a spoofed source IP address.
          In recent years, attacks of this nature have become an endemic nuisance.<a href="#section-8.4-1" class="pilcrow">¶</a></p>
<p id="section-8.4-2">
          NTS is designed to avoid contributing any further to this problem by
          ensuring that NTS-related extension fields included in server
          responses will be the same size as the NTS-related extension fields
          sent by the client. In particular, this is why the client is required
          to send a separate and appropriately padded-out NTS Cookie Placeholder
          extension field for every cookie it wants to get back, rather than
          being permitted simply to specify a desired quantity.<a href="#section-8.4-2" class="pilcrow">¶</a></p>
<p id="section-8.4-3">
          Due to the <span><a href="#RFC7822" class="xref">RFC 7822</a> [<a href="#RFC7822" class="xref">RFC7822</a>]</span> requirement that
          extensions be padded and aligned to four-octet boundaries, response
          size may still in some cases exceed request size by up to three
          octets. This is sufficiently inconsequential that we have declined to
          address it.<a href="#section-8.4-3" class="pilcrow">¶</a></p>
</section>
<div id="sec-cert-verification">
<section id="section-8.5">
        <h3 id="name-initial-verification-of-ser">
<a href="#section-8.5" class="section-number selfRef">8.5. </a><a href="#name-initial-verification-of-ser" class="section-name selfRef">Initial Verification of Server Certificates</a>
        </h3>
<p id="section-8.5-1">
          NTS's security goals are undermined if the client fails to verify that
          the X.509 certificate chain presented by the NTS-KE server is valid
          and rooted in a trusted certificate authority. <span><a href="#RFC5280" class="xref">RFC 5280</a> [<a href="#RFC5280" class="xref">RFC5280</a>]</span> and <span><a href="#RFC6125" class="xref">RFC
          6125</a> [<a href="#RFC6125" class="xref">RFC6125</a>]</span> specify how such verification is to be performed in
          general. However, the expectation that the client does not yet have a
          correctly-set system clock at the time of certificate verification
          presents difficulties with verifying that the certificate is within
          its validity period, i.e., that the current time lies between the
          times specified in the certificate's notBefore and notAfter fields. It
          may be operationally necessary in some cases for a client to accept a
          certificate that appears to be expired or not yet valid. While there
          is no perfect solution to this problem, there are several mitigations
          the client can implement to make it more difficult for an adversary to
          successfully present an expired certificate:<a href="#section-8.5-1" class="pilcrow">¶</a></p>
<ul class="normal ulEmpty">
<li class="normal ulEmpty" id="section-8.5-2.1">
              Check whether the system time is in fact unreliable. On systems
              with the ntp_adjtime() system call, a return code other than
              TIME_ERROR indicates that some trusted software has already set
              the time and certificates can be strictly validated.<a href="#section-8.5-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal ulEmpty" id="section-8.5-2.2">
              Allow the system administrator to specify that certificates should
              <em>always</em> be strictly validated. Such a configuration is
              appropriate on systems that have a battery-backed clock or that
              can reasonably prompt the user to manually set an
              approximately correct time if it appears to be needed.<a href="#section-8.5-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal ulEmpty" id="section-8.5-2.3">
              Once the clock has been synchronized, periodically write the
              current system time to persistent storage. Do not accept any
              certificate whose notAfter field is earlier than the last recorded
              time.<a href="#section-8.5-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal ulEmpty" id="section-8.5-2.4">
              NTP time replies are expected to be consistent with the NTS-KE TLS
              certificate validity period, i.e. time replies received immediately after
              an NTS-KE handshake are expected to lie within the certificate validity
              period.
              Implementations are recommended to check that this is the case.
              Performing a new NTS-KE handshake based solely on the fact that the
              certificate used by the NTS-KE server in a previous handshake has expired
              is normally not necessary.
              Clients that still wish to do this must take care not to cause an
              inadvertent denial-of-service attack on the NTS-KE server, for example by
              picking a random time in the week preceding certificate expiry to perform
              the new handshake.<a href="#section-8.5-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal ulEmpty" id="section-8.5-2.5">
              Use multiple time sources. The ability to pass off an expired
              certificate is only useful to an adversary who has compromised the
              corresponding private key. If the adversary has compromised only a
              minority of servers, NTP's selection algorithm (Section
              <a href="https://www.rfc-editor.org/rfc/rfc5905#section-11.2.1" class="relref">11.2.1</a>
              of <span><a href="#RFC5905" class="xref">RFC 5905</a> [<a href="#RFC5905" class="xref">RFC5905</a>]</span>) will protect the
              client from accepting bad time from the adversary-controlled
              servers.<a href="#section-8.5-2.5" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="DelayAttack">
<section id="section-8.6">
        <h3 id="name-delay-attacks">
<a href="#section-8.6" class="section-number selfRef">8.6. </a><a href="#name-delay-attacks" class="section-name selfRef">Delay Attacks</a>
        </h3>
<p id="section-8.6-1">
          In a packet delay attack, an adversary with the ability to act as a
          man-in-the-middle delays time synchronization packets between client
          and server asymmetrically <span>[<a href="#RFC7384" class="xref">RFC7384</a>]</span>. Since NTP's
          formula for computing time offset relies on the assumption that
          network latency is roughly symmetrical, this leads to the client to
          compute an inaccurate value <span>[<a href="#Mizrahi" class="xref">Mizrahi</a>]</span>. The delay attack
          does not reorder or modify the content of the exchanged
          synchronization packets. Therefore, cryptographic means do not provide
          a feasible way to mitigate this attack. However, the maximum error
          that an adversary can introduce is bounded by half of the round-trip
          delay.<a href="#section-8.6-1" class="pilcrow">¶</a></p>
<p id="section-8.6-2">
          <span><a href="#RFC5905" class="xref">RFC 5905</a> [<a href="#RFC5905" class="xref">RFC5905</a>]</span> specifies a parameter called
          MAXDIST, which denotes the maximum round-trip latency (including not
          only the immediate round trip between client and server, but the whole
          distance back to the reference clock as reported in the Root Delay
          field) that a client will tolerate before concluding that the server
          is unsuitable for synchronization. The standard value for MAXDIST is
          one second, although some implementations use larger values. Whatever
          value a client chooses, the maximum error that can be introduced by a
          delay attack is MAXDIST/2.<a href="#section-8.6-2" class="pilcrow">¶</a></p>
<p id="section-8.6-3">
          Usage of multiple time sources, or multiple network paths to a given
          time source <span>[<a href="#Shpiner" class="xref">Shpiner</a>]</span>, may also serve to mitigate delay
          attacks if the adversary is in control of only some of the paths.<a href="#section-8.6-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-8.7">
        <h3 id="name-nts-stripping">
<a href="#section-8.7" class="section-number selfRef">8.7. </a><a href="#name-nts-stripping" class="section-name selfRef">NTS Stripping</a>
        </h3>
<p id="section-8.7-1">
          Implementers must be aware of the possibility of "NTS stripping"
          attacks, where an attacker attempts to trick clients into reverting to plain
          NTP. Naive client implementations might, for example, revert
          automatically to plain NTP if the NTS-KE handshake fails. A man-in-the-middle
          attacker can easily cause this to happen. Even clients that already
          hold valid cookies can be vulnerable, since an attacker can force a
          client to repeat the NTS-KE handshake by sending faked NTP mode 4
          replies with the NTS NAK kiss code. Forcing a client to repeat the
          NTS-KE handshake can also be the first step in more advanced attacks.<a href="#section-8.7-1" class="pilcrow">¶</a></p>
<p id="section-8.7-2">
          For the reasons described here, implementations <span class="bcp14">SHOULD NOT</span> revert
          from NTS-protected to unprotected NTP with any server without
          explicit user action.<a href="#section-8.7-2" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-9">
      <h2 id="name-privacy-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
      </h2>
<div id="Unlinkability">
<section id="section-9.1">
        <h3 id="name-unlinkability">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-unlinkability" class="section-name selfRef">Unlinkability</a>
        </h3>
<p id="section-9.1-1">Unlinkability prevents a device from being tracked when it changes
        network addresses (e.g., because said device moved between different
        networks). In other words, unlinkability thwarts an attacker that
        seeks to link a new network address used by a device with a network
        address that it was formerly using because of recognizable data that
        the device persistently sends as part of an NTS-secured NTP
        association. This is the justification for continually supplying the
        client with fresh cookies, so that a cookie never represents
        recognizable data in the sense outlined above.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
<p id="section-9.1-2">NTS's unlinkability objective is merely to not leak any additional
        data that could be used to link a device's network address. NTS does
        not rectify legacy linkability issues that are already present in NTP.
        Thus, a client that requires unlinkability must also minimize
        information transmitted in a client query (mode 3) packet as described
        in the document <span><a href="#I-D.ietf-ntp-data-minimization" class="xref">NTP Client Data Minimization</a> [<a href="#I-D.ietf-ntp-data-minimization" class="xref">NTP-DATA-MIN</a>]</span>.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
<p id="section-9.1-3">The unlinkability objective only holds for time synchronization
        traffic, as opposed to key establishment traffic. This implies that it
        cannot be guaranteed for devices that function not only as time
        clients, but also as time servers (because the latter can be externally
        triggered to send linkable data, such as the TLS certificate).<a href="#section-9.1-3" class="pilcrow">¶</a></p>
<p id="section-9.1-4">It should also be noted that it could be possible to link devices
        that operate as time servers from their time synchronization traffic,
        using information exposed in (mode 4) server response packets (e.g.
        reference ID, reference time, stratum, poll).  Also, devices that
        respond to NTP control queries could be linked using the information
        revealed by control queries.<a href="#section-9.1-4" class="pilcrow">¶</a></p>
<p id="section-9.1-5">Note that the unlinkability objective does not prevent a client device
        from being tracked by its time servers.<a href="#section-9.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-9.2">
        <h3 id="name-confidentiality">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-confidentiality" class="section-name selfRef">Confidentiality</a>
        </h3>
<p id="section-9.2-1">
   NTS does not protect the confidentiality of information in
   NTP's header fields. When clients implement
    <span><a href="#I-D.ietf-ntp-data-minimization" class="xref">NTP Client Data Minimization</a> [<a href="#I-D.ietf-ntp-data-minimization" class="xref">NTP-DATA-MIN</a>]</span>, client packet
   headers do not contain any information that the client
   could conceivably wish to keep secret: one field is random,
   and all others are fixed. Information in server packet
   headers is likewise public: the origin timestamp is copied
   from the client's (random) transmit timestamp, and all other
   fields are set the same regardless of the identity of the
   client making the request.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
<p id="section-9.2-2">
   Future extension fields could hypothetically contain
   sensitive information, in which case NTS provides a
   mechanism for encrypting them.<a href="#section-9.2-2" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-10">
      <h2 id="name-references">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-10.1">
        <h3 id="name-normative-references">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="IANA-AEAD">[IANA-AEAD]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Authenticated Encryption with Associated Data (AEAD) Parameters"</span>, <span>&lt;<a href="https://www.iana.org/assignments/aead-parameters/">https://www.iana.org/assignments/aead-parameters/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0020">[RFC0020]</dt>
        <dd>
<span class="refAuthor">Cerf, V.</span>, <span class="refTitle">"ASCII format for network interchange"</span>, <span class="seriesInfo">STD 80</span>, <span class="seriesInfo">RFC 20</span>, <span class="seriesInfo">DOI 10.17487/RFC0020</span>, <time datetime="1969-10" class="refDate">October 1969</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc20">https://www.rfc-editor.org/info/rfc20</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4291">[RFC4291]</dt>
        <dd>
<span class="refAuthor">Hinden, R.</span><span class="refAuthor"> and S. Deering</span>, <span class="refTitle">"IP Version 6 Addressing Architecture"</span>, <span class="seriesInfo">RFC 4291</span>, <span class="seriesInfo">DOI 10.17487/RFC4291</span>, <time datetime="2006-02" class="refDate">February 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4291">https://www.rfc-editor.org/info/rfc4291</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5116">[RFC5116]</dt>
        <dd>
<span class="refAuthor">McGrew, D.</span>, <span class="refTitle">"An Interface and Algorithms for Authenticated Encryption"</span>, <span class="seriesInfo">RFC 5116</span>, <span class="seriesInfo">DOI 10.17487/RFC5116</span>, <time datetime="2008-01" class="refDate">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5116">https://www.rfc-editor.org/info/rfc5116</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5280">[RFC5280]</dt>
        <dd>
<span class="refAuthor">Cooper, D.</span><span class="refAuthor">, Santesson, S.</span><span class="refAuthor">, Farrell, S.</span><span class="refAuthor">, Boeyen, S.</span><span class="refAuthor">, Housley, R.</span><span class="refAuthor">, and W. Polk</span>, <span class="refTitle">"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"</span>, <span class="seriesInfo">RFC 5280</span>, <span class="seriesInfo">DOI 10.17487/RFC5280</span>, <time datetime="2008-05" class="refDate">May 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5280">https://www.rfc-editor.org/info/rfc5280</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5297">[RFC5297]</dt>
        <dd>
<span class="refAuthor">Harkins, D.</span>, <span class="refTitle">"Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)"</span>, <span class="seriesInfo">RFC 5297</span>, <span class="seriesInfo">DOI 10.17487/RFC5297</span>, <time datetime="2008-10" class="refDate">October 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5297">https://www.rfc-editor.org/info/rfc5297</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5705">[RFC5705]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"Keying Material Exporters for Transport Layer Security (TLS)"</span>, <span class="seriesInfo">RFC 5705</span>, <span class="seriesInfo">DOI 10.17487/RFC5705</span>, <time datetime="2010-03" class="refDate">March 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5705">https://www.rfc-editor.org/info/rfc5705</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5869">[RFC5869]</dt>
        <dd>
<span class="refAuthor">Krawczyk, H.</span><span class="refAuthor"> and P. Eronen</span>, <span class="refTitle">"HMAC-based Extract-and-Expand Key Derivation Function (HKDF)"</span>, <span class="seriesInfo">RFC 5869</span>, <span class="seriesInfo">DOI 10.17487/RFC5869</span>, <time datetime="2010-05" class="refDate">May 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5869">https://www.rfc-editor.org/info/rfc5869</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5890">[RFC5890]</dt>
        <dd>
<span class="refAuthor">Klensin, J.</span>, <span class="refTitle">"Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework"</span>, <span class="seriesInfo">RFC 5890</span>, <span class="seriesInfo">DOI 10.17487/RFC5890</span>, <time datetime="2010-08" class="refDate">August 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5890">https://www.rfc-editor.org/info/rfc5890</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5905">[RFC5905]</dt>
        <dd>
<span class="refAuthor">Mills, D.</span><span class="refAuthor">, Martin, J., Ed.</span><span class="refAuthor">, Burbank, J.</span><span class="refAuthor">, and W. Kasch</span>, <span class="refTitle">"Network Time Protocol Version 4: Protocol and Algorithms Specification"</span>, <span class="seriesInfo">RFC 5905</span>, <span class="seriesInfo">DOI 10.17487/RFC5905</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5905">https://www.rfc-editor.org/info/rfc5905</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6125">[RFC6125]</dt>
        <dd>
<span class="refAuthor">Saint-Andre, P.</span><span class="refAuthor"> and J. Hodges</span>, <span class="refTitle">"Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"</span>, <span class="seriesInfo">RFC 6125</span>, <span class="seriesInfo">DOI 10.17487/RFC6125</span>, <time datetime="2011-03" class="refDate">March 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6125">https://www.rfc-editor.org/info/rfc6125</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6335">[RFC6335]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Eggert, L.</span><span class="refAuthor">, Touch, J.</span><span class="refAuthor">, Westerlund, M.</span><span class="refAuthor">, and S. Cheshire</span>, <span class="refTitle">"Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry"</span>, <span class="seriesInfo">BCP 165</span>, <span class="seriesInfo">RFC 6335</span>, <span class="seriesInfo">DOI 10.17487/RFC6335</span>, <time datetime="2011-08" class="refDate">August 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6335">https://www.rfc-editor.org/info/rfc6335</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6874">[RFC6874]</dt>
        <dd>
<span class="refAuthor">Carpenter, B.</span><span class="refAuthor">, Cheshire, S.</span><span class="refAuthor">, and R. Hinden</span>, <span class="refTitle">"Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers"</span>, <span class="seriesInfo">RFC 6874</span>, <span class="seriesInfo">DOI 10.17487/RFC6874</span>, <time datetime="2013-02" class="refDate">February 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6874">https://www.rfc-editor.org/info/rfc6874</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7301">[RFC7301]</dt>
        <dd>
<span class="refAuthor">Friedl, S.</span><span class="refAuthor">, Popov, A.</span><span class="refAuthor">, Langley, A.</span><span class="refAuthor">, and E. Stephan</span>, <span class="refTitle">"Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension"</span>, <span class="seriesInfo">RFC 7301</span>, <span class="seriesInfo">DOI 10.17487/RFC7301</span>, <time datetime="2014-07" class="refDate">July 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7301">https://www.rfc-editor.org/info/rfc7301</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7525">[RFC7525]</dt>
        <dd>
<span class="refAuthor">Sheffer, Y.</span><span class="refAuthor">, Holz, R.</span><span class="refAuthor">, and P. Saint-Andre</span>, <span class="refTitle">"Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">BCP 195</span>, <span class="seriesInfo">RFC 7525</span>, <span class="seriesInfo">DOI 10.17487/RFC7525</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7525">https://www.rfc-editor.org/info/rfc7525</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7822">[RFC7822]</dt>
        <dd>
<span class="refAuthor">Mizrahi, T.</span><span class="refAuthor"> and D. Mayer</span>, <span class="refTitle">"Network Time Protocol Version 4 (NTPv4) Extension Fields"</span>, <span class="seriesInfo">RFC 7822</span>, <span class="seriesInfo">DOI 10.17487/RFC7822</span>, <time datetime="2016-03" class="refDate">March 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7822">https://www.rfc-editor.org/info/rfc7822</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[RFC8446]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-10.2">
        <h3 id="name-informative-references">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="Mizrahi">[Mizrahi]</dt>
        <dd>
<span class="refAuthor">Mizrahi, T.</span>, <span class="refTitle">"A game theoretic analysis of delay attacks against time synchronization protocols"</span>, <span class="refContent">2012 IEEE International Symposium on Precision Clock Synchronization
                      for Measurement, Control and Communication Proceedings, pp. 1-6</span>, <span class="seriesInfo">DOI 10.1109/ISPCS.2012.6336612</span>, <time datetime="2012-09" class="refDate">September 2012</time>, <span>&lt;<a href="https://doi.org/10.1109/ISPCS.2012.6336612">https://doi.org/10.1109/ISPCS.2012.6336612</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-ntp-data-minimization">[NTP-DATA-MIN]</dt>
        <dd>
<span class="refAuthor">Franke, D. F.</span><span class="refAuthor"> and A. Malhotra</span>, <span class="refTitle">"NTP Client Data Minimization"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ntp-data-minimization-04</span>, <time datetime="2019-03-25" class="refDate">25 March 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-ntp-data-minimization-04">https://tools.ietf.org/html/draft-ietf-ntp-data-minimization-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4086">[RFC4086]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span><span class="refAuthor">, Schiller, J.</span><span class="refAuthor">, and S. Crocker</span>, <span class="refTitle">"Randomness Requirements for Security"</span>, <span class="seriesInfo">BCP 106</span>, <span class="seriesInfo">RFC 4086</span>, <span class="seriesInfo">DOI 10.17487/RFC4086</span>, <time datetime="2005-06" class="refDate">June 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4086">https://www.rfc-editor.org/info/rfc4086</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5077">[RFC5077]</dt>
        <dd>
<span class="refAuthor">Salowey, J.</span><span class="refAuthor">, Zhou, H.</span><span class="refAuthor">, Eronen, P.</span><span class="refAuthor">, and H. Tschofenig</span>, <span class="refTitle">"Transport Layer Security (TLS) Session Resumption without Server-Side State"</span>, <span class="seriesInfo">RFC 5077</span>, <span class="seriesInfo">DOI 10.17487/RFC5077</span>, <time datetime="2008-01" class="refDate">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5077">https://www.rfc-editor.org/info/rfc5077</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7384">[RFC7384]</dt>
        <dd>
<span class="refAuthor">Mizrahi, T.</span>, <span class="refTitle">"Security Requirements of Time Protocols in Packet Switched Networks"</span>, <span class="seriesInfo">RFC 7384</span>, <span class="seriesInfo">DOI 10.17487/RFC7384</span>, <time datetime="2014-10" class="refDate">October 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7384">https://www.rfc-editor.org/info/rfc7384</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8573">[RFC8573]</dt>
        <dd>
<span class="refAuthor">Malhotra, A.</span><span class="refAuthor"> and S. Goldberg</span>, <span class="refTitle">"Message Authentication Code for the Network Time Protocol"</span>, <span class="seriesInfo">RFC 8573</span>, <span class="seriesInfo">DOI 10.17487/RFC8573</span>, <time datetime="2019-06" class="refDate">June 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8573">https://www.rfc-editor.org/info/rfc8573</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Shpiner">[Shpiner]</dt>
      <dd>
<span class="refAuthor">Shpiner, A.</span><span class="refAuthor">, Revah, Y.</span><span class="refAuthor">, and T. Mizrahi</span>, <span class="refTitle">"Multi-path Time Protocols"</span>, <span class="refContent">2013 IEEE International Symposium on Precision Clock Synchronization
                      for Measurement, Control and Communication (ISPCS) Proceedings, pp. 1-6</span>, <span class="seriesInfo">DOI 10.1109/ISPCS.2013.6644754</span>, <time datetime="2013-09" class="refDate">September 2013</time>, <span>&lt;<a href="https://doi.org/10.1109/ISPCS.2013.6644754">https://doi.org/10.1109/ISPCS.2013.6644754</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="Acknowledgments">
<section id="section-appendix.a">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.a-1">The authors would like to thank <span class="contact-name">Richard Barnes</span>,
      <span class="contact-name">Steven Bellovin</span>, <span class="contact-name">Scott Fluhrer</span>,
      <span class="contact-name">Patrik Fältström</span>,
      <span class="contact-name">Sharon Goldberg</span>, <span class="contact-name">Russ Housley</span>,
      <span class="contact-name">Benjamin Kaduk</span>, <span class="contact-name">Suresh Krishnan</span>,
      <span class="contact-name">Mirja Kühlewind</span>, <span class="contact-name">Martin Langer</span>,
      <span class="contact-name">Barry Leiba</span>, <span class="contact-name">Miroslav Lichvar</span>,
      <span class="contact-name">Aanchal Malhotra</span>, <span class="contact-name">Danny Mayer</span>,
      <span class="contact-name">Dave Mills</span>, <span class="contact-name">Sandra Murphy</span>,
      <span class="contact-name">Hal Murray</span>, <span class="contact-name">Karen O'Donoghue</span>,
      <span class="contact-name">Eric K. Rescorla</span>, <span class="contact-name">Kurt Roeckx</span>,
      <span class="contact-name">Stephen Roettger</span>, <span class="contact-name">Dan Romascanu</span>,
      <span class="contact-name">Kyle Rose</span>, <span class="contact-name">Rich Salz</span>,
      <span class="contact-name">Brian Sniffen</span>, <span class="contact-name">Susan Sons</span>,
      <span class="contact-name">Douglas Stebila</span>, <span class="contact-name">Harlan Stenn</span>,
      <span class="contact-name">Joachim Strömbergsson</span>,
      <span class="contact-name">Martin Thomson</span>, <span class="contact-name">Éric Vyncke</span>,
      <span class="contact-name">Richard Welty</span>, <span class="contact-name">Christer Weinigel</span>, and
      <span class="contact-name">Magnus Westerlund</span> for contributions to this document
      and comments on the design of NTS.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Daniel Fox Franke</span></div>
<div dir="auto" class="left"><span class="org">Akamai Technologies</span></div>
<div dir="auto" class="left"><span class="street-address">145 Broadway</span></div>
<div dir="auto" class="left">
<span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02142</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:dafranke@akamai.com" class="email">dafranke@akamai.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Dieter Sibold</span></div>
<div dir="auto" class="left"><span class="org">Physikalisch-Technische Bundesanstalt</span></div>
<div dir="auto" class="left"><span class="street-address">Bundesallee 100</span></div>
<div dir="auto" class="left">
<span class="postal-code">D-38116</span> <span class="locality">Braunschweig</span>
</div>
<div dir="auto" class="left"><span class="country-name">Germany</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+49-(0)531-592-8462" class="tel">+49-(0)531-592-8462</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:dieter.sibold@ptb.de" class="email">dieter.sibold@ptb.de</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Kristof Teichel</span></div>
<div dir="auto" class="left"><span class="org">Physikalisch-Technische Bundesanstalt</span></div>
<div dir="auto" class="left"><span class="street-address">Bundesallee 100</span></div>
<div dir="auto" class="left">
<span class="postal-code">D-38116</span> <span class="locality">Braunschweig</span>
</div>
<div dir="auto" class="left"><span class="country-name">Germany</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+49-(0)531-592-4471" class="tel">+49-(0)531-592-4471</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:kristof.teichel@ptb.de" class="email">kristof.teichel@ptb.de</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Marcus Dansarie</span></div>
<div dir="auto" class="left"><span class="country-name">Sweden</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:marcus@dansarie.se" class="email">marcus@dansarie.se</a>
</div>
<div class="url">
<span>URI:</span>
<a href="https://orcid.org/0000-0001-9246-0263" class="url">https://orcid.org/0000-0001-9246-0263</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ragnar Sundblad</span></div>
<div dir="auto" class="left"><span class="org">Netnod</span></div>
<div dir="auto" class="left"><span class="country-name">Sweden</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ragge@netnod.se" class="email">ragge@netnod.se</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>