File: rfc9212.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 (1756 lines) | stat: -rw-r--r-- 74,326 bytes
<!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 9212: Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)</title>
<meta content="Nicholas Gajcowski" name="author">
<meta content="Michael Jenkins" name="author">
<meta content="
       The United States Government has published the National Security
      Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which
      defines cryptographic algorithm policy for national security
      applications. This document specifies the conventions for using the
      United States National Security Agency's CNSA Suite algorithms with the
      Secure Shell Transport Layer Protocol and the Secure Shell
      Authentication Protocol. It applies to the capabilities, configuration,
      and operation of all components of US National Security Systems
      (described in NIST Special Publication 800-59) that employ Secure Shell
      (SSH).  This document is also appropriate for all other US Government
      systems that process high-value information. It is made publicly
      available for use by developers and operators of these and any other
      system deployments.
 
    " name="description">
<meta content="xml2rfc 3.12.2" name="generator">
<meta content="NSS" name="keyword">
<meta content="remote administration" name="keyword">
<meta content="9212" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.2
    Python 3.6.15
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9212.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.ulBare, li.ulBare {
  margin-left: 0em !important;
}
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;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#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: auto;
  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";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9212" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-gajcowski-cnsa-ssh-profile-07" 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 9212</td>
<td class="center">CNSA Suite SSH Profile</td>
<td class="right">March 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Gajcowski &amp; Jenkins</td>
<td class="center">Informational</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">Independent Submission</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9212" class="eref">9212</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-03" class="published">March 2022</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">N. Gajcowski</div>
<div class="org">NSA</div>
</div>
<div class="author">
      <div class="author-name">M. Jenkins</div>
<div class="org">NSA</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9212</h1>
<h1 id="title">Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">The United States Government has published the National Security
      Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which
      defines cryptographic algorithm policy for national security
      applications. This document specifies the conventions for using the
      United States National Security Agency's CNSA Suite algorithms with the
      Secure Shell Transport Layer Protocol and the Secure Shell
      Authentication Protocol. It applies to the capabilities, configuration,
      and operation of all components of US National Security Systems
      (described in NIST Special Publication 800-59) that employ Secure Shell
      (SSH).  This document is also appropriate for all other US Government
      systems that process high-value information. It is made publicly
      available for use by developers and operators of these and any other
      system deployments.<a href="#section-abstract-1" 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 document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This is a contribution to the RFC Series, independently of any
            other RFC stream.  The RFC Editor has chosen to publish this
            document at its discretion and makes no statement about its value
            for implementation or deployment.  Documents approved for
            publication by the RFC Editor are not candidates for any level of
            Internet Standard; see 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/rfc9212">https://www.rfc-editor.org/info/rfc9212</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) 2022 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.<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="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-the-commercial-national-sec" class="xref">The Commercial National Security Algorithm Suite</a></p>
</li>
          <li class="compact toc ulBare 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-cnsa-and-secure-shell" class="xref">CNSA and Secure Shell</a></p>
</li>
          <li class="compact toc ulBare 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-security-mechanism-negotiat" class="xref">Security Mechanism Negotiation and Initialization</a></p>
</li>
          <li class="compact toc ulBare 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-key-exchange" class="xref">Key Exchange</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-ecdh-key-exchange" class="xref">ECDH Key Exchange</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-dh-key-exchange" class="xref">DH Key Exchange</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-authentication" class="xref">Authentication</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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-server-authentication" class="xref">Server Authentication</a></p>
</li>
              <li class="compact toc ulBare 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-user-authentication" class="xref">User Authentication</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-confidentiality-and-data-in" class="xref">Confidentiality and Data Integrity of SSH Binary Packets</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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-galois-counter-mode" class="xref">Galois/Counter Mode</a></p>
</li>
              <li class="compact toc ulBare 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-data-integrity" class="xref">Data Integrity</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-rekeying" class="xref">Rekeying</a></p>
</li>
          <li class="compact toc ulBare 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-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="xref">12.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="xref">12.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#appendix-A" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<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 document specifies conventions for using the United States
      National Security Agency's CNSA Suite algorithms <span>[<a href="#CNSA" class="xref">CNSA</a>]</span> with the Secure Shell Transport Layer Protocol <span>[<a href="#RFC4253" class="xref">RFC4253</a>]</span> and the Secure Shell Authentication
      Protocol <span>[<a href="#RFC4252" class="xref">RFC4252</a>]</span>. It applies to the
      capabilities, configuration, and operation of all components of US
      National Security Systems (described in NIST Special Publication 800-59
      <span>[<a href="#SP80059" class="xref">SP80059</a>]</span>) that employ SSH.  This
      document is also appropriate for all other US Government systems that
      process high-value information. It is made publicly available for use by
      developers and operators of these and any other system deployments.<a href="#section-1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="terminology">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</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>
<div id="cnsa">
<section id="section-3">
      <h2 id="name-the-commercial-national-sec">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-the-commercial-national-sec" class="section-name selfRef">The Commercial National Security Algorithm Suite</a>
      </h2>
<p id="section-3-1">The NSA profiles commercial cryptographic algorithms and
      protocols as part of its mission to support secure, interoperable communications for US
      Government National Security Systems. To this end, it publishes guidance both to assist
      with the US Government's transition to new algorithms and to provide vendors -- and the
      Internet community in general -- with information concerning their proper use and
      configuration.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">Recently, cryptographic transition plans have become overshadowed by the prospect of the
      development of a cryptographically relevant quantum computer. The NSA has established the
      Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users
      near-term flexibility in meeting their information assurance interoperability requirements
      using current cryptography. The purpose behind this flexibility is to avoid vendors and
      customers making two major transitions (i.e., to elliptic curve cryptography and then to
      post-quantum cryptography) in a relatively short timeframe, as we anticipate a need to
      shift to quantum-resistant cryptography in the near future.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">The NSA is authoring a set of RFCs, including this one, to provide updated guidance
      concerning the use of certain commonly available commercial algorithms in IETF protocols.
      These RFCs can be used in conjunction with other RFCs and cryptographic guidance (e.g.,
      NIST Special Publications) to properly protect Internet traffic and data-at-rest for US
      Government National Security Systems.<a href="#section-3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cnsa-and-ssh">
<section id="section-4">
      <h2 id="name-cnsa-and-secure-shell">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-cnsa-and-secure-shell" class="section-name selfRef">CNSA and Secure Shell</a>
      </h2>
<p id="section-4-1">Several RFCs have documented how each of the CNSA components are to be integrated into Secure Shell (SSH):<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">kex algorithms:<a href="#section-4-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-3.1">ecdh-sha2-nistp384 <span>[<a href="#RFC5656" class="xref">RFC5656</a>]</span><a href="#section-4-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-3.2">diffie-hellman-group15-sha512 <span>[<a href="#RFC8268" class="xref">RFC8268</a>]</span><a href="#section-4-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-3.3">diffie-hellman-group16-sha512 <span>[<a href="#RFC8268" class="xref">RFC8268</a>]</span><a href="#section-4-3.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-4">public key algorithms:<a href="#section-4-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-5.1">ecdsa-sha2-nistp384 <span>[<a href="#RFC5656" class="xref">RFC5656</a>]</span><a href="#section-4-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-5.2">rsa-sha2-512 <span>[<a href="#RFC8332" class="xref">RFC8332</a>]</span><a href="#section-4-5.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-6">encryption algorithms (both client_to_server and server_to_client):<a href="#section-4-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-7.1">AEAD_AES_256_GCM <span>[<a href="#RFC5647" class="xref">RFC5647</a>]</span><a href="#section-4-7.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-8">message authentication code (MAC) algorithms (both client_to_server and server_to_client):<a href="#section-4-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-9.1">AEAD_AES_256_GCM <span>[<a href="#RFC5647" class="xref">RFC5647</a>]</span><a href="#section-4-9.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-10">While the approved CNSA hash function for all purposes is SHA-384, as defined in <span>[<a href="#FIPS180" class="xref">FIPS180</a>]</span>, commercial products are more likely to incorporate the kex algorithms and public key algorithms based on SHA-512 (sha2-512), which are defined in <span>[<a href="#RFC8268" class="xref">RFC8268</a>]</span> and <span>[<a href="#RFC8332" class="xref">RFC8332</a>]</span>. Therefore, the SHA-384-based kex and public key algorithms <span class="bcp14">SHOULD</span> be used; SHA-512-based algorithms <span class="bcp14">MAY</span> be used. Any hash algorithm other than SHA-384 or SHA-512 <span class="bcp14">MUST NOT</span> be used.<a href="#section-4-10" class="pilcrow">¶</a></p>
<p id="section-4-11">Use of the Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) shall meet the requirements set forth in <span>[<a href="#SP800-38D" class="xref">SP800-38D</a>]</span>, with the additional requirements that all 16 octets of the authentication tag <span class="bcp14">MUST</span> be used as the SSH data integrity value and that AES is used with a 256-bit key. Use of AES-GCM in SSH should be done as described in <span>[<a href="#RFC5647" class="xref">RFC5647</a>]</span>, with the exception that AES-GCM need not be listed as the MAC algorithm when its use is implicit (such as done in aes256-gcm@openssh.com). In addition, <span>[<a href="#RFC5647" class="xref">RFC5647</a>]</span> fails to specify that the AES-GCM invocation counter is incremented mod 2<sup>64</sup>. CNSA implementations <span class="bcp14">MUST</span> ensure the counter never repeats and is properly incremented after processing a binary packet:<a href="#section-4-11" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-4-12">invocation_counter = invocation_counter + 1  mod 2<sup>64</sup>.<a href="#section-4-12" class="pilcrow">¶</a></p>
<p id="section-4-13">The purpose of this document is to draw upon all of these documents to provide guidance for CNSA-compliant implementations of Secure Shell. Algorithms specified in this document may be different from mandatory-to-implement algorithms; where this occurs, the latter will be present but not used. Note that, while compliant Secure Shell implementations <span class="bcp14">MUST</span> follow the guidance in this document, that requirement does not in and of itself imply that a given implementation of Secure Shell is suitable for use national security systems. An implementation must be validated by the appropriate authority before such usage is permitted.<a href="#section-4-13" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-mech-neg-init">
<section id="section-5">
      <h2 id="name-security-mechanism-negotiat">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-mechanism-negotiat" class="section-name selfRef">Security Mechanism Negotiation and Initialization</a>
      </h2>
<p id="section-5-1">As described in <span><a href="https://www.rfc-editor.org/rfc/rfc4253#section-7.1" class="relref">Section 7.1</a> of [<a href="#RFC4253" class="xref">RFC4253</a>]</span>, the exchange of SSH_MSG_KEXINIT between the server and the client establishes which key agreement algorithm, MAC algorithm, host key algorithm (server authentication algorithm), and encryption algorithm are to be used. This section specifies the use of CNSA components in the Secure Shell algorithm negotiation, key agreement, server authentication, and user authentication.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">The choice of all but the user authentication methods is determined by the exchange of SSH_MSG_KEXINIT between the client and the server.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">The kex_algorithms name-list is used to negotiate a single key agreement algorithm between the server and client in accordance with the guidance given in <a href="#cnsa-and-ssh" class="xref">Section 4</a>. While <span>[<a href="#RFC9142" class="xref">RFC9142</a>]</span> establishes general guidance on the capabilities of SSH implementations and requires support for "diffie-hellman-group14-sha256", it <span class="bcp14">MUST NOT</span> be used. The result <span class="bcp14">MUST</span> be one of the following kex_algorithms, or the connection <span class="bcp14">MUST</span> be terminated:<a href="#section-5-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-4.1">ecdh-sha2-nistp384 <span>[<a href="#RFC5656" class="xref">RFC5656</a>]</span><a href="#section-5-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-4.2">diffie-hellman-group15-sha512 <span>[<a href="#RFC8268" class="xref">RFC8268</a>]</span><a href="#section-5-4.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-4.3">diffie-hellman-group16-sha512 <span>[<a href="#RFC8268" class="xref">RFC8268</a>]</span><a href="#section-5-4.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-5-5">One of the following sets <span class="bcp14">MUST</span> be used for the encryption_algorithms and mac_algorithms name-lists. Either set <span class="bcp14">MAY</span> be used for each direction (i.e., client_to_server or server_to_client), but the result must be the same (i.e., use of AEAD_AES_256_GCM).<a href="#section-5-5" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-5-6">encryption_algorithm_name_list := { AEAD_AES_256_GCM }<a href="#section-5-6" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-5-7">mac_algorithm_name_list := { AEAD_AES_256_GCM }<a href="#section-5-7" class="pilcrow">¶</a></p>
<p id="section-5-8"> or<a href="#section-5-8" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-5-9">encryption_algorithm_name_list := { aes256-gcm@openssh.com }<a href="#section-5-9" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-5-10">mac_algorithm_name_list := {}<a href="#section-5-10" class="pilcrow">¶</a></p>
<p id="section-5-11">One of the following public key algorithms <span class="bcp14">MUST</span> be used:<a href="#section-5-11" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-12.1">rsa-sha2-512 <span>[<a href="#RFC8332" class="xref">RFC8332</a>]</span><a href="#section-5-12.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-12.2">ecdsa-sha2-nistp384 <span>[<a href="#RFC5656" class="xref">RFC5656</a>]</span><a href="#section-5-12.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-5-13">The procedures for applying the negotiated algorithms are given in the following sections.<a href="#section-5-13" class="pilcrow">¶</a></p>
</section>
</div>
<div id="kex">
<section id="section-6">
      <h2 id="name-key-exchange">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-key-exchange" class="section-name selfRef">Key Exchange</a>
      </h2>
<p id="section-6-1">The key exchange to be used is determined by the name-lists exchanged in the SSH_MSG_KEXINIT packets, as described above. Either Elliptic Curve Diffie-Hellman (ECDH) or Diffie-Hellman (DH) <span class="bcp14">MUST</span> be used to establish a shared secret value between the client and the server.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">A compliant system <span class="bcp14">MUST NOT</span> allow the reuse of ephemeral/exchange values in a key exchange algorithm due to security concerns related to this practice.
Section 5.6.3.3 of <span>[<a href="#SP80056A" class="xref">SP80056A</a>]</span> states that an ephemeral private key shall be used in exactly one key establishment transaction and shall be destroyed (zeroized) as soon as possible. Section 5.8 of <span>[<a href="#SP80056A" class="xref">SP80056A</a>]</span> states that such shared secrets shall be destroyed (zeroized) immediately after its use. CNSA-compliant systems <span class="bcp14">MUST</span> follow these mandates.<a href="#section-6-2" class="pilcrow">¶</a></p>
<div id="ecdh-kex">
<section id="section-6.1">
        <h3 id="name-ecdh-key-exchange">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-ecdh-key-exchange" class="section-name selfRef">ECDH Key Exchange</a>
        </h3>
<p id="section-6.1-1">The key exchange begins with the SSH_MSG_KEXECDH_INIT message that contains the client's ephemeral public key used to generate a shared secret value.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">The server responds to an SSH_MSG_KEXECDH_INIT message with an SSH_MSG_KEXECDH_REPLY message that contains the server's ephemeral public key, the server's public host key, and a signature of the exchange hash value formed from the newly established shared secret value. The kex algorithm <span class="bcp14">MUST</span> be ecdh-sha2-nistp384, and the public key algorithm <span class="bcp14">MUST</span> be either ecdsa-sha2-nistp384 or rsa-sha2-512.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dh-kex">
<section id="section-6.2">
        <h3 id="name-dh-key-exchange">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-dh-key-exchange" class="section-name selfRef">DH Key Exchange</a>
        </h3>
<p id="section-6.2-1">The key exchange begins with the SSH_MSG_KEXDH_INIT message that contains the client's DH exchange value used to generate a shared secret value.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">The server responds to an SSH_MSG_KEXDH_INIT message with an SSH_MSG_KEXDH_REPLY message that contains the server's DH exchange value, the server's public host key, and a signature of the exchange hash value formed from the newly established shared secret value. The kex algorithm <span class="bcp14">MUST</span> be one of diffie-hellman-group15-sha512 or diffie-hellman-group16-sha512, and the public key algorithm <span class="bcp14">MUST</span> be either ecdsa-sha2-nistp384 or rsa-sha2-512.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="authn">
<section id="section-7">
      <h2 id="name-authentication">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-authentication" class="section-name selfRef">Authentication</a>
      </h2>
<div id="serv-authn">
<section id="section-7.1">
        <h3 id="name-server-authentication">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-server-authentication" class="section-name selfRef">Server Authentication</a>
        </h3>
<p id="section-7.1-1">A signature on the exchange hash value derived from the newly established shared secret value is used to authenticate the server to the client. Servers <span class="bcp14">MUST</span> be authenticated using digital signatures. The public key algorithm implemented <span class="bcp14">MUST</span> be ecdsa-sha2-nistp384 or rsa-sha2-512. The RSA public key modulus <span class="bcp14">MUST</span> be 3072 or 4096 bits in size; clients <span class="bcp14">MUST NOT</span> accept RSA signatures from a public key modulus of any other size.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">The following public key algorithms <span class="bcp14">MUST</span> be used:<a href="#section-7.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.1-3.1">ecdsa-sha2-nistp384 <span>[<a href="#RFC5656" class="xref">RFC5656</a>]</span><a href="#section-7.1-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-3.2">rsa-sha2-512 <span>[<a href="#RFC8332" class="xref">RFC8332</a>]</span><a href="#section-7.1-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.1-4">The client <span class="bcp14">MUST</span> verify that the presented key is a valid authenticator for the server before verifying the server signature. If possible, validation <span class="bcp14">SHOULD</span> be done using certificates. Otherwise, the client <span class="bcp14">MUST</span> validate the presented public key through some other secure, possibly off-line mechanism. Implementations <span class="bcp14">MUST NOT</span> employ a "Trust on First Use (TOFU)" security model where a client accepts the first public host key presented to it from a not-yet-verified server. Use of a TOFU model would allow an intermediate adversary to present itself to the client as the server.<a href="#section-7.1-4" class="pilcrow">¶</a></p>
<p id="section-7.1-5">Where X.509 v3 Certificates are used, their use <span class="bcp14">MUST</span> comply with <span>[<a href="#RFC8603" class="xref">RFC8603</a>]</span>.<a href="#section-7.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="user-authn">
<section id="section-7.2">
        <h3 id="name-user-authentication">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-user-authentication" class="section-name selfRef">User Authentication</a>
        </h3>
<p id="section-7.2-1">The Secure Shell Transport Layer Protocol authenticates the server to the host but does not authenticate the user (or the user's host) to the server. All users <span class="bcp14">MUST</span> be authenticated, <span class="bcp14">MUST</span> follow <span>[<a href="#RFC4252" class="xref">RFC4252</a>]</span>, and <span class="bcp14">SHOULD</span> be authenticated using a public key method. Users <span class="bcp14">MAY</span> authenticate using passwords. Other methods of authentication <span class="bcp14">MUST</span> not be used, including "none".<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">When authenticating with public key, the following public key algorithms <span class="bcp14">MUST</span> be used:<a href="#section-7.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.2-3.1">ecdsa-sha2-nistp384 <span>[<a href="#RFC5656" class="xref">RFC5656</a>]</span><a href="#section-7.2-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.2-3.2">rsa-sha2-512 <span>[<a href="#RFC8332" class="xref">RFC8332</a>]</span><a href="#section-7.2-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.2-4">The server <span class="bcp14">MUST</span> verify that the public key is a valid authenticator for the user. If possible, validation <span class="bcp14">SHOULD</span> be done using certificates. Otherwise, the server must validate the public key through another secure, possibly off-line mechanism.<a href="#section-7.2-4" class="pilcrow">¶</a></p>
<p id="section-7.2-5">Where X.509 v3 Certificates are used, their use <span class="bcp14">MUST</span> comply with <span>[<a href="#RFC8603" class="xref">RFC8603</a>]</span>.<a href="#section-7.2-5" class="pilcrow">¶</a></p>
<p id="section-7.2-6">If authenticating with RSA, the client's public key modulus <span class="bcp14">MUST</span> be 3072 or 4096 bits in size, and the server <span class="bcp14">MUST NOT</span> accept signatures from an RSA public key modulus of any other size.<a href="#section-7.2-6" class="pilcrow">¶</a></p>
<p id="section-7.2-7">To facilitate client authentication with RSA using SHA-512, clients and servers <span class="bcp14">SHOULD</span> implement the server-sig-algs extension, as specified in <span>[<a href="#RFC8308" class="xref">RFC8308</a>]</span>. In that case, in the SSH_MSG_KEXINIT, the client <span class="bcp14">SHALL</span> include the indicator ext-info-c to the kex_algorithms field, and the server <span class="bcp14">SHOULD</span> respond with an SSH_MSG_EXT_INFO message containing the server-sig-algs extension. The server <span class="bcp14">MUST</span> list only ecdsa-sha2-nistp384 and/or rsa-sha2-512 as the acceptable public key algorithms in this response.<a href="#section-7.2-7" class="pilcrow">¶</a></p>
<p id="section-7.2-8">If authenticating by passwords, it is essential that passwords have sufficient entropy to protect against dictionary attacks. During authentication, the password <span class="bcp14">MUST</span> be protected in the established encrypted communications channel. Additional guidelines are provided in <span>[<a href="#SP80063" class="xref">SP80063</a>]</span>.<a href="#section-7.2-8" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="pkt-conf-and-integ">
<section id="section-8">
      <h2 id="name-confidentiality-and-data-in">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-confidentiality-and-data-in" class="section-name selfRef">Confidentiality and Data Integrity of SSH Binary Packets</a>
      </h2>
<p id="section-8-1">Secure Shell transfers data between the client and the server using its own binary packet structure. The SSH binary packet structure is independent of any packet structure on the underlying data channel. The contents of each binary packet and portions of the header are encrypted, and each packet is authenticated with its own message authentication code. Use of AES-GCM will both encrypt the packet and form a 16-octet authentication tag to ensure data integrity.<a href="#section-8-1" class="pilcrow">¶</a></p>
<div id="gcm">
<section id="section-8.1">
        <h3 id="name-galois-counter-mode">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-galois-counter-mode" class="section-name selfRef">Galois/Counter Mode</a>
        </h3>
<p id="section-8.1-1">Use of AES-GCM in Secure Shell is described in <span>[<a href="#RFC5647" class="xref">RFC5647</a>]</span>. CNSA-complaint SSH implementations <span class="bcp14">MUST</span> support AES-GCM (negotiated as AEAD_AES_GCM_256 or aes256-gcm@openssh; see <a href="#sec-mech-neg-init" class="xref">Section 5</a>) to provide confidentiality and ensure data integrity. No other confidentiality or data integrity algorithms are permitted.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<p id="section-8.1-2">The AES-GCM invocation counter is incremented mod 2<sup>64</sup>. That is, after processing a binary packet:<a href="#section-8.1-2" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-8.1-3">invocation_counter = invocation_counter + 1 mod 2<sup>64</sup><a href="#section-8.1-3" class="pilcrow">¶</a></p>
<p id="section-8.1-4">The invocation counter <span class="bcp14">MUST NOT</span> repeat a counter value.<a href="#section-8.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="data-integ">
<section id="section-8.2">
        <h3 id="name-data-integrity">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-data-integrity" class="section-name selfRef">Data Integrity</a>
        </h3>
<p id="section-8.2-1">As specified in <span>[<a href="#RFC5647" class="xref">RFC5647</a>]</span>, all 16 octets of the
 authentication tag <span class="bcp14">MUST</span> be used as the SSH data integrity value of the SSH
 binary packet.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="rekeying">
<section id="section-9">
      <h2 id="name-rekeying">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-rekeying" class="section-name selfRef">Rekeying</a>
      </h2>
<p id="section-9-1"><span><a href="https://www.rfc-editor.org/rfc/rfc4253#section-9" class="relref">Section 9</a> of [<a href="#RFC4253" class="xref">RFC4253</a>]</span> allows either the server or the client to initiate a "key re-exchange ... by sending an SSH_MSG_KEXINIT packet" and to "change some or all of the [cipher] algorithms during the re-exchange".  This specification requires the same cipher suite to be employed when rekeying; that is, the cipher algorithms <span class="bcp14">MUST NOT</span> be changed when a rekey occurs.<a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-considerations">
<section id="section-10">
      <h2 id="name-security-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-10-1">The security considerations of <span>[<a href="#RFC4251" class="xref">RFC4251</a>]</span>, <span>[<a href="#RFC4252" class="xref">RFC4252</a>]</span>, <span>[<a href="#RFC4253" class="xref">RFC4253</a>]</span>, <span>[<a href="#RFC5647" class="xref">RFC5647</a>]</span>, and <span>[<a href="#RFC5656" class="xref">RFC5656</a>]</span>
      apply.<a href="#section-10-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
<section id="section-11">
      <h2 id="name-iana-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-11-1">This document has no IANA actions.<a href="#section-11-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-12">
      <h2 id="name-references">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-12.1">
        <h3 id="name-normative-references">
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="CNSA">[CNSA]</dt>
        <dd>
<span class="refAuthor">Committee for National Security Systems</span>, <span class="refTitle">"Use of Public Standards for Secure Information Sharing"</span>, <span class="seriesInfo">CNSSP 15</span>, <time datetime="2016-10" class="refDate">October 2016</time>, <span>&lt;<a href="https://www.cnss.gov/CNSS/Issuances/Policies.cfm">https://www.cnss.gov/CNSS/Issuances/Policies.cfm</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="FIPS180">[FIPS180]</dt>
        <dd>
<span class="refAuthor">National Institute of Standards and Technology</span>, <span class="refTitle">"Secure Hash Standard (SHS)"</span>, <span class="seriesInfo">FIPS PUB 180-4</span>, <span class="seriesInfo">DOI 10.6028/NIST.FIPS.180-4</span>, <time datetime="2015-08" class="refDate">August 2015</time>, <span>&lt;<a href="https://doi.org/10.6028/NIST.FIPS.180-4">https://doi.org/10.6028/NIST.FIPS.180-4</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="RFC4251">[RFC4251]</dt>
        <dd>
<span class="refAuthor">Ylonen, T.</span> and <span class="refAuthor">C. Lonvick, Ed.</span>, <span class="refTitle">"The Secure Shell (SSH) Protocol Architecture"</span>, <span class="seriesInfo">RFC 4251</span>, <span class="seriesInfo">DOI 10.17487/RFC4251</span>, <time datetime="2006-01" class="refDate">January 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4251">https://www.rfc-editor.org/info/rfc4251</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4252">[RFC4252]</dt>
        <dd>
<span class="refAuthor">Ylonen, T.</span> and <span class="refAuthor">C. Lonvick, Ed.</span>, <span class="refTitle">"The Secure Shell (SSH) Authentication Protocol"</span>, <span class="seriesInfo">RFC 4252</span>, <span class="seriesInfo">DOI 10.17487/RFC4252</span>, <time datetime="2006-01" class="refDate">January 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4252">https://www.rfc-editor.org/info/rfc4252</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4253">[RFC4253]</dt>
        <dd>
<span class="refAuthor">Ylonen, T.</span> and <span class="refAuthor">C. Lonvick, Ed.</span>, <span class="refTitle">"The Secure Shell (SSH) Transport Layer Protocol"</span>, <span class="seriesInfo">RFC 4253</span>, <span class="seriesInfo">DOI 10.17487/RFC4253</span>, <time datetime="2006-01" class="refDate">January 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4253">https://www.rfc-editor.org/info/rfc4253</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5647">[RFC5647]</dt>
        <dd>
<span class="refAuthor">Igoe, K.</span> and <span class="refAuthor">J. Solinas</span>, <span class="refTitle">"AES Galois Counter Mode for the Secure Shell Transport Layer Protocol"</span>, <span class="seriesInfo">RFC 5647</span>, <span class="seriesInfo">DOI 10.17487/RFC5647</span>, <time datetime="2009-08" class="refDate">August 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5647">https://www.rfc-editor.org/info/rfc5647</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5656">[RFC5656]</dt>
        <dd>
<span class="refAuthor">Stebila, D.</span> and <span class="refAuthor">J. Green</span>, <span class="refTitle">"Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer"</span>, <span class="seriesInfo">RFC 5656</span>, <span class="seriesInfo">DOI 10.17487/RFC5656</span>, <time datetime="2009-12" class="refDate">December 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5656">https://www.rfc-editor.org/info/rfc5656</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="RFC8268">[RFC8268]</dt>
        <dd>
<span class="refAuthor">Baushke, M.</span>, <span class="refTitle">"More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)"</span>, <span class="seriesInfo">RFC 8268</span>, <span class="seriesInfo">DOI 10.17487/RFC8268</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8268">https://www.rfc-editor.org/info/rfc8268</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8308">[RFC8308]</dt>
        <dd>
<span class="refAuthor">Bider, D.</span>, <span class="refTitle">"Extension Negotiation in the Secure Shell (SSH) Protocol"</span>, <span class="seriesInfo">RFC 8308</span>, <span class="seriesInfo">DOI 10.17487/RFC8308</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8308">https://www.rfc-editor.org/info/rfc8308</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8332">[RFC8332]</dt>
        <dd>
<span class="refAuthor">Bider, D.</span>, <span class="refTitle">"Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol"</span>, <span class="seriesInfo">RFC 8332</span>, <span class="seriesInfo">DOI 10.17487/RFC8332</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8332">https://www.rfc-editor.org/info/rfc8332</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8603">[RFC8603]</dt>
      <dd>
<span class="refAuthor">Jenkins, M.</span> and <span class="refAuthor">L. Zieglar</span>, <span class="refTitle">"Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile"</span>, <span class="seriesInfo">RFC 8603</span>, <span class="seriesInfo">DOI 10.17487/RFC8603</span>, <time datetime="2019-05" class="refDate">May 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8603">https://www.rfc-editor.org/info/rfc8603</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-12.2">
        <h3 id="name-informative-references">
<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC9142">[RFC9142]</dt>
        <dd>
<span class="refAuthor">Baushke, M.</span>, <span class="refTitle">"Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)"</span>, <span class="seriesInfo">RFC 9142</span>, <span class="seriesInfo">DOI 10.17487/RFC9142</span>, <time datetime="2022-01" class="refDate">January 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9142">https://www.rfc-editor.org/info/rfc9142</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SP800-38D">[SP800-38D]</dt>
        <dd>
<span class="refAuthor">National Institute of Standards and Technology</span>, <span class="refTitle">"Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC"</span>, <span class="seriesInfo">NIST Special Publication 800-38D</span>, <span class="seriesInfo">DOI 10.6028/NIST.SP.800-38D</span>, <time datetime="2007-11" class="refDate">November 2007</time>, <span>&lt;<a href="https://doi.org/10.6028/NIST.SP.800-38D">https://doi.org/10.6028/NIST.SP.800-38D</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SP80056A">[SP80056A]</dt>
        <dd>
<span class="refAuthor">National Institute of Standards and Technology</span>, <span class="refTitle">"Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"</span>, <span class="refContent">Revision 3</span>, <span class="seriesInfo">NIST Special Publication 800-56A</span>, <span class="seriesInfo">DOI 10.6028/NIST.SP.800-56Ar3</span>, <time datetime="2018-04" class="refDate">April 2018</time>, <span>&lt;<a href="https://doi.org/10.6028/NIST.SP.800-56Ar3">https://doi.org/10.6028/NIST.SP.800-56Ar3</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SP80059">[SP80059]</dt>
        <dd>
<span class="refAuthor">National Institute of Standards and Technology</span>, <span class="refTitle">"Guideline for Identifying an Information System as a National Security System"</span>, <span class="seriesInfo">NIST Special Publication 800-59</span>, <span class="seriesInfo">DOI 10.6028/NIST.SP.800-59</span>, <time datetime="2003-08" class="refDate">August 2003</time>, <span>&lt;<a href="https://doi.org/10.6028/NIST.SP.800-59">https://doi.org/10.6028/NIST.SP.800-59</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SP80063">[SP80063]</dt>
      <dd>
<span class="refAuthor">National Institute of Standards and Technology</span>, <span class="refTitle">"Digital Identity Guidelines"</span>, <span class="seriesInfo">NIST Special Publication 800-63-3</span>, <span class="seriesInfo">DOI 10.6028/NIST.SP.800-63-3</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://doi.org/10.6028/NIST.SP.800-63-3">https://doi.org/10.6028/NIST.SP.800-63-3</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="authors-addresses">
<section id="appendix-A">
      <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">Nicholas Gajcowski</span></div>
<div dir="auto" class="left"><span class="org">National Security Agency</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:nhgajco@uwe.nsa.gov" class="email">nhgajco@uwe.nsa.gov</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Michael Jenkins</span></div>
<div dir="auto" class="left"><span class="org">National Security Agency</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mjjenki@cyber.nsa.gov" class="email">mjjenki@cyber.nsa.gov</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>