File: rfc9206.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 (1865 lines) | stat: -rw-r--r-- 89,267 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 9206: Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec)</title>
<meta content="Laura Corcoran" name="author">
<meta content="Michael Jenkins" name="author">
<meta content="
       The United States Government has published the National Security Agency's 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 in Internet Protocol Security (IPsec). 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 IPsec. 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="post quantum" name="keyword">
<meta content="quantum resistant" name="keyword">
<meta content="NSA" name="keyword">
<meta content="9206" 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="rfc9206.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/rfc9206" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-corcoran-cnsa-ipsec-profile-06" 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 9206</td>
<td class="center">CNSA Suite IPsec Profile</td>
<td class="right">February 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Corcoran &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/rfc9206" class="eref">9206</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-02" class="published">February 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">L. Corcoran</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 9206</h1>
<h1 id="title">Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec)</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's 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 in Internet Protocol Security (IPsec). 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 IPsec. 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/rfc9206">https://www.rfc-editor.org/info/rfc9206</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-compliant-ipsec-overvi" class="xref">CNSA-Compliant IPsec Overview</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-ipsec-user-interface-suites" class="xref">IPsec User Interface Suites</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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-suite-cnsa-gcm-256-ecdh-384" class="xref">Suite CNSA-GCM-256-ECDH-384</a></p>
</li>
              <li class="compact toc ulBare 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-suite-cnsa-gcm-256-dh-3072" class="xref">Suite CNSA-GCM-256-DH-3072</a></p>
</li>
              <li class="compact toc ulBare 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-suite-cnsa-gcm-256-dh-4096" class="xref">Suite CNSA-GCM-256-DH-4096</a></p>
</li>
            </ul>
</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-ikev2-authentication" class="xref">IKEv2 Authentication</a></p>
</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-certificates" class="xref">Certificates</a></p>
</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-ikev2-security-associations" class="xref">IKEv2 Security Associations (SAs)</a></p>
</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-the-key-exchange-payload-in" class="xref">The Key Exchange Payload in the IKE_SA_INIT Exchange</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-generating-key-material-for" class="xref">Generating Key Material for the IKE SA</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-additional-requirements" class="xref">Additional Requirements</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-guidance-for-applications-w" class="xref">Guidance for Applications with Long Data-Protection Requirements</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-13" class="xref">13</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-14" class="xref">14</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-15" class="xref">15</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.15.2.1">
                <p id="section-toc.1-1.15.2.1.1"><a href="#section-15.1" class="xref">15.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.15.2.2">
                <p id="section-toc.1-1.15.2.2.1"><a href="#section-15.2" class="xref">15.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.16">
            <p id="section-toc.1-1.16.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 the conventions for using the United States National Security Agency's (NSA's) Commercial National Security Algorithm (CNSA) Suite algorithms <span>[<a href="#CNSA" class="xref">CNSA</a>]</span> in Internet Protocol Security (IPsec). It defines CNSA-based User Interface suites ("UI suites") describing sets of security configurations for Internet Key Exchange Protocol Version 2 (IKEv2) and IP Encapsulating Security Payload (ESP) protocol use, and specifies certain other constraints with respect to algorithm selection and configuration. 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 IPsec. 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>
<p id="section-1-2">The reader is assumed to have familiarity with the following:<a href="#section-1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-3.1">
        "<a href="#RFC4303" class="xref">IP Encapsulating Security Payload (ESP)</a>" <span>[<a href="#RFC4303" class="xref">RFC4303</a>]</span><a href="#section-1-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-3.2">
        "<a href="#RFC5280" class="xref">Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</a>" <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span><a href="#section-1-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-3.3">
        "<a href="#RFC7296" class="xref">Internet Key Exchange Protocol Version 2 (IKEv2)</a>" <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span><a href="#section-1-3.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-3.4">
        "<a href="#RFC8221" class="xref">Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)</a>" <span>[<a href="#RFC8221" class="xref">RFC8221</a>]</span><a href="#section-1-3.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-3.5">"<a href="#RFC8603" class="xref">Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile</a>" <span>[<a href="#RFC8603" class="xref">RFC8603</a>]</span><a href="#section-1-3.5" class="pilcrow">¶</a>
</li>
      </ul>
</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>
<p id="section-2-2">AES refers to the Advanced Encryption Standard. ECDSA and ECDH refer to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH), respectively. DH refers to Diffie-Hellman key establishment. RSA refers to an RSA signature.<a href="#section-2-2" 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 to both (1) assist with the US Government transition to new algorithms and (2) 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. The purpose behind this flexibility is to avoid vendors and customers making two major transitions 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="overview">
<section id="section-4">
      <h2 id="name-cnsa-compliant-ipsec-overvi">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-cnsa-compliant-ipsec-overvi" class="section-name selfRef">CNSA-Compliant IPsec Overview</a>
      </h2>
<p id="section-4-1">CNSA-compliant implementations for IPsec <span class="bcp14">MUST</span> use IKEv2 <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span>.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">Implementing a CNSA-compliant IPsec system requires cryptographic algorithm selection for both the IKEv2 and ESP protocols. The following CNSA requirements apply to IPsec:<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">Encryption:<a href="#section-4-3" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty">
<li class="compact ulEmpty" id="section-4-4.1">AES <span>[<a href="#FIPS197" class="xref">FIPS197</a>]</span> (with key size 256 bits)<a href="#section-4-4.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-5">Digital Signature:<a href="#section-4-5" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty">
<li class="compact ulEmpty" id="section-4-6.1">ECDSA <span>[<a href="#FIPS186" class="xref">FIPS186</a>]</span> (using the NIST P-384 elliptic curve)<a href="#section-4-6.1" class="pilcrow">¶</a>
</li>
        <li class="compact ulEmpty" id="section-4-6.2">RSA <span>[<a href="#FIPS186" class="xref">FIPS186</a>]</span> (with a modulus of 3072 bits or larger)<a href="#section-4-6.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-7">Key Establishment:<a href="#section-4-7" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty">
<li class="compact ulEmpty" id="section-4-8.1">ECDH <span>[<a href="#SP80056A" class="xref">SP80056A</a>]</span> (using the NIST P-384 elliptic curve)<a href="#section-4-8.1" class="pilcrow">¶</a>
</li>
        <li class="compact ulEmpty" id="section-4-8.2">DH <span>[<a href="#RFC3526" class="xref">RFC3526</a>]</span> (with a prime modulus of 3072 or larger)<a href="#section-4-8.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-9">To facilitate selection of appropriate combinations of compliant algorithms, this document provides CNSA-compliant User Interface suites (UI suites) <span>[<a href="#RFC4308" class="xref">RFC4308</a>]</span> to implement IPsec on National Security Systems.<a href="#section-4-9" class="pilcrow">¶</a></p>
<p id="section-4-10">The approved CNSA hash function for all purposes is SHA-384, as defined in <span>[<a href="#FIPS180" class="xref">FIPS180</a>]</span>. However, PRF_HMAC_SHA_512 is specified for the IKEv2 Pseudorandom Function (PRF) instead of PRF_HMAC_SHA_384, due to availability. See <a href="#sa" class="xref">Section 8</a> below.<a href="#section-4-10" class="pilcrow">¶</a></p>
<p id="section-4-11">For CNSA Suite applications, public key certificates <span class="bcp14">MUST</span> be compliant with the CNSA Suite Certificate and CRL Profile specified in <span>[<a href="#RFC8603" class="xref">RFC8603</a>]</span>.<a href="#section-4-11" class="pilcrow">¶</a></p>
<p id="section-4-12">Under certain conditions, such as applications having long-lived
data-protection requirements, systems that do not comply with the requirements of this document are acceptable; see <a href="#long-life" class="xref">Section 12</a>.<a href="#section-4-12" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ui-suites">
<section id="section-5">
      <h2 id="name-ipsec-user-interface-suites">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-ipsec-user-interface-suites" class="section-name selfRef">IPsec User Interface Suites</a>
      </h2>
<p id="section-5-1">User Interface (UI) suites <span>[<a href="#RFC4308" class="xref">RFC4308</a>]</span> are named suites that cover some typical security policy options for IPsec. Use of UI suites does not change the IPsec protocol in any way. The following UI suites provide cryptographic algorithm choices for ESP <span>[<a href="#RFC4303" class="xref">RFC4303</a>]</span> and for IKEv2 <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span>.
  The selection of a UI suite will depend on the key exchange algorithm.  The suite names indicate the Advanced Encryption Standard <span>[<a href="#FIPS197" class="xref">FIPS197</a>]</span> mode, AES key length specified for encryption, and the key exchange algorithm.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">Although RSA is also a CNSA-approved key establishment algorithm, only DH and ECDH are specified for key exchange in IKEv2 <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span>.
 RSA in IPsec is used only for digital signatures. See <a href="#ikev2-authn" class="xref">Section 6</a>.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">ESP requires negotiation of both a confidentiality algorithm and an integrity algorithm. However, algorithms for Authenticated Encryption with Associated Data (AEAD) <span>[<a href="#RFC5116" class="xref">RFC5116</a>]</span> do not require a separate integrity algorithm to be negotiated.
 In particular, since AES-GCM is an AEAD algorithm, ESP implementing AES-GCM <span class="bcp14">MUST</span> either offer no integrity algorithm or indicate the single integrity algorithm NONE (see <span><a href="https://www.rfc-editor.org/rfc/rfc7296#section-3.3" class="relref">Section 3.3</a> of [<a href="#RFC7296" class="xref">RFC7296</a>]</span>).<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">To be CNSA compliant, IPsec implementations that use the following UI suites <span class="bcp14">MUST</span> use the suite names listed below.  IPsec implementations <span class="bcp14">SHOULD NOT</span> use names different than those listed here for the suites that are described and <span class="bcp14">MUST NOT</span> use the names listed here for suites that do not match these values.  These requirements are necessary for interoperability.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">Transform names are as listed in the IANA "Internet Key Exchange Version 2 (IKEv2) Parameters" registry. Definitions of the transforms are contained in the references specified in that registry.<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">Other UI suites may be acceptable for CNSA compliance. See <a href="#sa" class="xref">Section 8</a> for details.<a href="#section-5-6" class="pilcrow">¶</a></p>
<div id="suite-ecdh">
<section id="section-5.1">
        <h3 id="name-suite-cnsa-gcm-256-ecdh-384">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-suite-cnsa-gcm-256-ecdh-384" class="section-name selfRef">Suite CNSA-GCM-256-ECDH-384</a>
        </h3>
<span class="break"></span><dl class="dlCompact dlNewline" id="section-5.1-1">
          <dt id="section-5.1-1.1">ESP SA:</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-1.2">
            <span class="break"></span><dl class="dlCompact dlParallel" id="section-5.1-1.2.1">
              <dt id="section-5.1-1.2.1.1">Encryption:</dt>
              <dd style="margin-left: 1.5em" id="section-5.1-1.2.1.2">ENCR_AES_GCM_16 (with key size 256 bits)<a href="#section-5.1-1.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.1-1.2.1.3">Integrity:</dt>
              <dd style="margin-left: 1.5em" id="section-5.1-1.2.1.4">NONE<a href="#section-5.1-1.2.1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
          <dd class="break"></dd>
<dt id="section-5.1-1.3">IKEv2 SA:</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-1.4">
            <span class="break"></span><dl class="dlCompact dlParallel" id="section-5.1-1.4.1">
              <dt id="section-5.1-1.4.1.1">Encryption:</dt>
              <dd style="margin-left: 1.5em" id="section-5.1-1.4.1.2">ENCR_AES_GCM_16 (with key size 256 bits)<a href="#section-5.1-1.4.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.1-1.4.1.3">PRF:</dt>
              <dd style="margin-left: 1.5em" id="section-5.1-1.4.1.4">PRF_HMAC_SHA2_512<a href="#section-5.1-1.4.1.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.1-1.4.1.5">Integrity:</dt>
              <dd style="margin-left: 1.5em" id="section-5.1-1.4.1.6">NONE<a href="#section-5.1-1.4.1.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.1-1.4.1.7">Diffie-Hellman group:</dt>
              <dd style="margin-left: 1.5em" id="section-5.1-1.4.1.8">384-bit random ECP group<a href="#section-5.1-1.4.1.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="suite-dh3k">
<section id="section-5.2">
        <h3 id="name-suite-cnsa-gcm-256-dh-3072">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-suite-cnsa-gcm-256-dh-3072" class="section-name selfRef">Suite CNSA-GCM-256-DH-3072</a>
        </h3>
<span class="break"></span><dl class="dlCompact dlNewline" id="section-5.2-1">
          <dt id="section-5.2-1.1">ESP SA:</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-1.2">
            <span class="break"></span><dl class="dlCompact dlParallel" id="section-5.2-1.2.1">
              <dt id="section-5.2-1.2.1.1">Encryption:</dt>
              <dd style="margin-left: 1.5em" id="section-5.2-1.2.1.2">ENCR_AES_GCM_16 (with key size 256 bits)<a href="#section-5.2-1.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.2-1.2.1.3">Integrity:</dt>
              <dd style="margin-left: 1.5em" id="section-5.2-1.2.1.4">NONE<a href="#section-5.2-1.2.1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
          <dd class="break"></dd>
<dt id="section-5.2-1.3">IKEv2 SA:</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-1.4">
            <span class="break"></span><dl class="dlCompact dlParallel" id="section-5.2-1.4.1">
              <dt id="section-5.2-1.4.1.1">Encryption:</dt>
              <dd style="margin-left: 1.5em" id="section-5.2-1.4.1.2">ENCR_AES_GCM_16 (with key size 256 bits)<a href="#section-5.2-1.4.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.2-1.4.1.3">PRF:</dt>
              <dd style="margin-left: 1.5em" id="section-5.2-1.4.1.4">PRF_HMAC_SHA2_512<a href="#section-5.2-1.4.1.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.2-1.4.1.5">Integrity:</dt>
              <dd style="margin-left: 1.5em" id="section-5.2-1.4.1.6">NONE<a href="#section-5.2-1.4.1.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.2-1.4.1.7">Diffie-Hellman group:</dt>
              <dd style="margin-left: 1.5em" id="section-5.2-1.4.1.8">3072-bit MODP group<a href="#section-5.2-1.4.1.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="suite-dh4k">
<section id="section-5.3">
        <h3 id="name-suite-cnsa-gcm-256-dh-4096">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-suite-cnsa-gcm-256-dh-4096" class="section-name selfRef">Suite CNSA-GCM-256-DH-4096</a>
        </h3>
<span class="break"></span><dl class="dlCompact dlNewline" id="section-5.3-1">
          <dt id="section-5.3-1.1">ESP SA:</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.2">
            <span class="break"></span><dl class="dlCompact dlParallel" id="section-5.3-1.2.1">
              <dt id="section-5.3-1.2.1.1">Encryption:</dt>
              <dd style="margin-left: 1.5em" id="section-5.3-1.2.1.2">ENCR_AES_GCM_16 (with key size 256 bits)<a href="#section-5.3-1.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.3-1.2.1.3">Integrity:</dt>
              <dd style="margin-left: 1.5em" id="section-5.3-1.2.1.4">NONE<a href="#section-5.3-1.2.1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-1.3">IKEv2 SA:</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-1.4">
            <span class="break"></span><dl class="dlCompact dlParallel" id="section-5.3-1.4.1">
              <dt id="section-5.3-1.4.1.1">Encryption:</dt>
              <dd style="margin-left: 1.5em" id="section-5.3-1.4.1.2">ENCR_AES_GCM_16 (with key size 256 bits)<a href="#section-5.3-1.4.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.3-1.4.1.3">PRF:</dt>
              <dd style="margin-left: 1.5em" id="section-5.3-1.4.1.4">PRF_HMAC_SHA2_512<a href="#section-5.3-1.4.1.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.3-1.4.1.5">Integrity:</dt>
              <dd style="margin-left: 1.5em" id="section-5.3-1.4.1.6">NONE<a href="#section-5.3-1.4.1.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.3-1.4.1.7">Diffie-Hellman group:</dt>
              <dd style="margin-left: 1.5em" id="section-5.3-1.4.1.8">4096-bit MODP group<a href="#section-5.3-1.4.1.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="ikev2-authn">
<section id="section-6">
      <h2 id="name-ikev2-authentication">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-ikev2-authentication" class="section-name selfRef">IKEv2 Authentication</a>
      </h2>
<p id="section-6-1">Authentication of the IKEv2 Security Association (SA) requires computation of a digital signature.  To be CNSA compliant, digital signatures <span class="bcp14">MUST</span> be generated with SHA-384 as defined in <span>[<a href="#RFC8017" class="xref">RFC8017</a>]</span> together with either ECDSA-384 as defined in <span>[<a href="#RFC4754" class="xref">RFC4754</a>]</span> or RSA with 3072-bit or greater modulus.
 (For applications with long data-protection requirements, somewhat different rules apply; see <a href="#long-life" class="xref">Section 12</a>.)<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">Initiators and responders <span class="bcp14">MUST</span> be able to verify ECDSA-384 signatures and <span class="bcp14">MUST</span> be able to verify RSA with 3072-bit or 4096-bit modulus and SHA-384 signatures.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">For CNSA-compliant systems, authentication methods other than ECDSA-384 or RSA <span class="bcp14">MUST NOT</span> be accepted for IKEv2 authentication. A 3072-bit modulus or larger <span class="bcp14">MUST</span> be used for RSA. If the relying party receives a message signed with any authentication method other than an ECDSA-384 or RSA signature, it <span class="bcp14">MUST</span> return an AUTHENTICATION_FAILED notification and stop processing the message. If the relying party receives a message signed with RSA using less than a 3072-bit modulus, it <span class="bcp14">MUST</span> return an AUTHENTICATION_FAILED notification and stop processing the message.<a href="#section-6-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="certs">
<section id="section-7">
      <h2 id="name-certificates">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-certificates" class="section-name selfRef">Certificates</a>
      </h2>
<p id="section-7-1">To be CNSA compliant, the initiator and responder <span class="bcp14">MUST</span> use X.509 certificates that comply with <span>[<a href="#RFC8603" class="xref">RFC8603</a>]</span>. Peer authentication decisions must be based on the Subject or Subject Alternative Name from the certificate that contains the key used to validate the signature in the Authentication Payload as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7296#section-3.8" class="relref">Section 3.8</a> of [<a href="#RFC7296" class="xref">RFC7296</a>]</span>, rather than the Identification Data from the Identification Payload that is used to look up policy.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sa">
<section id="section-8">
      <h2 id="name-ikev2-security-associations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-ikev2-security-associations" class="section-name selfRef">IKEv2 Security Associations (SAs)</a>
      </h2>
<p id="section-8-1"><a href="#ui-suites" class="xref">Section 5</a> specifies three UI suites for ESP and IKEv2 Security Associations. All three use AES-GCM for encryption but differ in the key exchange algorithm. Galois/Counter Mode (GCM) <span>[<a href="#RFC4106" class="xref">RFC4106</a>]</span>  combines counter (CTR) mode with a secure, parallelizable, and efficient authentication mechanism. Since AES-GCM is an AEAD algorithm, ESP implements AES-GCM with no additional integrity algorithm (see <span><a href="https://www.rfc-editor.org/rfc/rfc7296#section-3.3" class="relref">Section 3.3</a> of [<a href="#RFC7296" class="xref">RFC7296</a>]</span>).<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">An initiator proposal <span class="bcp14">SHOULD</span> be constructed from one or more of the following suites:<a href="#section-8-2" class="pilcrow">¶</a></p>
<ul class="compact">
<li class="compact" id="section-8-3.1">CNSA-GCM-256-ECDH-384<a href="#section-8-3.1" class="pilcrow">¶</a>
</li>
        <li class="compact" id="section-8-3.2">CNSA-GCM-256-DH-3072<a href="#section-8-3.2" class="pilcrow">¶</a>
</li>
        <li class="compact" id="section-8-3.3">CNSA-GCM-256-DH-4096<a href="#section-8-3.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-8-4">A responder <span class="bcp14">SHOULD</span> accept proposals constructed from at least one of the three named suites. Other UI suites may result in acceptable proposals (such as those based on PRF_HMAC_SHA2_384); however, these are provided to promote interoperability.<a href="#section-8-4" class="pilcrow">¶</a></p>
<p id="section-8-5">Nonce construction for AES-GCM using a misuse-resistant technique <span>[<a href="#RFC8452" class="xref">RFC8452</a>]</span> conforms with the requirements of this document and <span class="bcp14">MAY</span> be used if a Federal Information Processing Standard (FIPS) validated implementation is available.<a href="#section-8-5" class="pilcrow">¶</a></p>
<p id="section-8-6">The named UI suites specify PRF_HMAC_SHA2_512 for the IKEv2 SA PRF transform, as PRF_HMAC_SHA2_384 is not listed among required PRF transforms in <span>[<a href="#RFC8247" class="xref">RFC8247</a>]</span>; therefore, implementation of the latter is likely to be scarce. The security level of PRF_HMAC_SHA2_512 is comparable, and the difference in performance is negligible. However, SHA-384 is the official CNSA algorithm for computing a condensed representation of information. Therefore, the PRF_HMAC_SHA2_384 transform is CNSA compliant if it is available to the initiator and responder. Any PRF transform other than PRF_HMAC_SHA2_384 or PRF_HMAC_SHA2_512 <span class="bcp14">MUST NOT</span> be used.<a href="#section-8-6" class="pilcrow">¶</a></p>
<p id="section-8-7">If none of the proposals offered by the initiator consist solely of transforms based on CNSA algorithms (such as those in the UI suites defined in <a href="#ui-suites" class="xref">Section 5</a>), the responder <span class="bcp14">MUST</span> return a Notify payload with the error NO_PROPOSAL_CHOSEN when operating in CNSA-compliant mode.<a href="#section-8-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ike-sa-init">
<section id="section-9">
      <h2 id="name-the-key-exchange-payload-in">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-the-key-exchange-payload-in" class="section-name selfRef">The Key Exchange Payload in the IKE_SA_INIT Exchange</a>
      </h2>
<p id="section-9-1">The key exchange payload is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange. The CNSA-compliant initiator and responder <span class="bcp14">MUST</span> each generate an ephemeral key pair to be used in the key exchange.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">If the Elliptic Curve Diffie-Hellman (ECDH) key exchange is selected for the SA, the initiator and responder both <span class="bcp14">MUST</span> generate an elliptic curve (EC) key pair using the P-384 elliptic curve. The ephemeral public keys <span class="bcp14">MUST</span> be stored in the key exchange payload as described in <span>[<a href="#RFC5903" class="xref">RFC5903</a>]</span>.<a href="#section-9-2" class="pilcrow">¶</a></p>
<p id="section-9-3">If the Diffie-Hellman (DH) key exchange is selected for the SA, the initiator and responder both <span class="bcp14">MUST</span> generate a key pair using the appropriately sized MODP group as described in <span>[<a href="#RFC3526" class="xref">RFC3526</a>]</span>. The size of the MODP group will be determined by the selection of either a 3072-bit or greater modulus for the SA.<a href="#section-9-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ikesa-keygen">
<section id="section-10">
      <h2 id="name-generating-key-material-for">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-generating-key-material-for" class="section-name selfRef">Generating Key Material for the IKE SA</a>
      </h2>
<p id="section-10-1">As noted in <span><a href="https://www.rfc-editor.org/rfc/rfc5903#section-7" class="relref">Section 7</a> of [<a href="#RFC5903" class="xref">RFC5903</a>]</span>, the shared secret result of an ECDH key exchange is the 384-bit x value of the ECDH common value. The shared secret result of a DH key exchange is the number of octets needed to accommodate the prime (e.g., 384 octets for 3072-bit MODP group) with leading zeros as necessary, as described in <span><a href="https://www.rfc-editor.org/rfc/rfc2631#section-2.1.2" class="relref">Section 2.1.2</a> of [<a href="#RFC2631" class="xref">RFC2631</a>]</span>.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">IKEv2 allows for the reuse of Diffie-Hellman private keys; see <span><a href="https://www.rfc-editor.org/rfc/rfc7296#section-2.12" class="relref">Section 2.12</a> of [<a href="#RFC7296" class="xref">RFC7296</a>]</span>.  However, there are 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 <span class="bcp14">MUST</span> be used in exactly one key establishment transaction and <span class="bcp14">MUST</span> be destroyed (zeroized) as soon as possible. Section 5.8 of <span>[<a href="#SP80056A" class="xref">SP80056A</a>]</span> states that any shared secret derived from key establishment <span class="bcp14">MUST</span> be destroyed (zeroized) immediately after its use.
 CNSA-compliant IPsec systems <span class="bcp14">MUST</span> follow the mandates in <span>[<a href="#SP80056A" class="xref">SP80056A</a>]</span>.<a href="#section-10-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="addl-reqt">
<section id="section-11">
      <h2 id="name-additional-requirements">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-additional-requirements" class="section-name selfRef">Additional Requirements</a>
      </h2>
<p id="section-11-1">The IPsec protocol AH <span class="bcp14">MUST NOT</span> be used in CNSA-compliant implementations.<a href="#section-11-1" class="pilcrow">¶</a></p>
<p id="section-11-2">A Diffie-Hellman group <span class="bcp14">MAY</span> be negotiated for a Child SA as described in <span><a href="https://www.rfc-editor.org/rfc/rfc7296#section-1.3" class="relref">Section 1.3</a> of [<a href="#RFC7296" class="xref">RFC7296</a>]</span>,
allowing peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange. If a transform of type 4 is specified for an SA for ESP, the value of that transform <span class="bcp14">MUST</span> match the value of the transform used by the IKEv2 SA.<a href="#section-11-2" class="pilcrow">¶</a></p>
<p id="section-11-3">Per <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span>, if a CREATE_CHILD_SA exchange includes a KEi payload, at least one of the SA offers <span class="bcp14">MUST</span> include the Diffie-Hellman group of the KEi. For CNSA-compliant IPsec implementations, the Diffie-Hellman group of the KEi <span class="bcp14">MUST</span> use the same group used in the IKE_INIT_SA.<a href="#section-11-3" class="pilcrow">¶</a></p>
<p id="section-11-4">For IKEv2, rekeying of the CREATE_CHILD_SA <span class="bcp14">MUST</span> be supported by both parties. The initiator of this exchange <span class="bcp14">MAY</span> include a new Diffie-Hellman key; if it is included, it <span class="bcp14">MUST</span> use the same group used in the IKE_INIT_SA. If the initiator of the exchange includes a Diffie-Hellman key, the responder <span class="bcp14">MUST</span> include a Diffie-Hellman key, and it <span class="bcp14">MUST</span> use the same group.<a href="#section-11-4" class="pilcrow">¶</a></p>
<p id="section-11-5">For CNSA-compliant systems, the IKEv2 authentication method <span class="bcp14">MUST</span> use an end-entity certificate provided by the authenticating party. Identification Payloads (IDi and IDr) in the IKE_AUTH exchanges <span class="bcp14">MUST NOT</span> be used for the IKEv2 authentication method but may be used for policy lookup.<a href="#section-11-5" class="pilcrow">¶</a></p>
<p id="section-11-6">The administrative User Interface (UI) for a system that conforms to this profile <span class="bcp14">MUST</span> allow the operator to specify a single suite.  If only one suite is specified in the administrative UI, the IKEv2 implementation <span class="bcp14">MUST</span> only offer algorithms for that one suite.<a href="#section-11-6" class="pilcrow">¶</a></p>
<p id="section-11-7">The administrative UI <span class="bcp14">MAY</span> allow the operator to specify more than one suite; if it allows this, it <span class="bcp14">MUST</span> allow the operator to specify a preferred order for the suites that are to be offered or accepted.  If more than one suite is specified in the administrative UI, the IKEv2 implementation <span class="bcp14">MUST</span> only offer algorithms of those suites. (Note that although this document does not define a UI suite specifying PRF_HMAC_SHA2_384, a proposal containing such a transform is CNSA compliant.)<a href="#section-11-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="long-life">
<section id="section-12">
      <h2 id="name-guidance-for-applications-w">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-guidance-for-applications-w" class="section-name selfRef">Guidance for Applications with Long Data-Protection Requirements</a>
      </h2>
<p id="section-12-1">The CNSA mandate is to continue to use current algorithms with increased security parameters, then transition to approved post-quantum resilient algorithms when they are identified. However, some applications have data-in-transit-protection requirements that are long enough that post-quantum resilient protection must be provided now. Lacking approved asymmetric post-quantum resilient confidentiality algorithms, that means approved symmetric techniques must be used as described in this section until approved post-quantum resilient asymmetric algorithms are identified.<a href="#section-12-1" class="pilcrow">¶</a></p>
<p id="section-12-2">For new applications, confidentiality and integrity requirements from the sections above <span class="bcp14">MUST</span> be followed, with the addition of a Pre-Shared Key (PSK) mixed in as defined in <span>[<a href="#RFC8784" class="xref">RFC8784</a>]</span>.<a href="#section-12-2" class="pilcrow">¶</a></p>
<p id="section-12-3">Installations currently using IKEv1 with PSKs <span class="bcp14">MUST</span> (1) use AES in cipher block chaining mode (AES-CBC) in conjunction with a CNSA-compliant integrity algorithm (e.g., AUTH_HMAC_SHA2_384_192) and (2) transition to IKEv2 with PSKs <span>[<a href="#RFC8784" class="xref">RFC8784</a>]</span> as soon as implementations become available.<a href="#section-12-3" class="pilcrow">¶</a></p>
<p id="section-12-4">Specific guidance for systems not compliant with the requirements of this document, including non-GCM modes and PSK length, and PSK randomness, will be defined in
solution-specific requirements appropriate to the application.
 Details of those requirements will depend on the program under which the commercial National Security Systems solution is developed (e.g., an NSA Commercial Solutions for Classified Capability Package).<a href="#section-12-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-considerations">
<section id="section-13">
      <h2 id="name-security-considerations">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-13-1">This document inherits all of the security considerations of the IPsec and IKEv2 documents, including <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span>, <span>[<a href="#RFC4303" class="xref">RFC4303</a>]</span>, <span>[<a href="#RFC4754" class="xref">RFC4754</a>]</span>, and <span>[<a href="#RFC8221" class="xref">RFC8221</a>]</span>.<a href="#section-13-1" class="pilcrow">¶</a></p>
<p id="section-13-2">The security of a system that uses cryptography depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering and administration of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system.<a href="#section-13-2" class="pilcrow">¶</a></p>
<p id="section-13-3">When selecting a mode for the AES encryption <span>[<a href="#RFC5116" class="xref">RFC5116</a>]</span>, be aware that nonce reuse can result in a loss of confidentiality. Nonce reuse is catastrophic for GCM, since it also results in a loss of integrity.<a href="#section-13-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
<section id="section-14">
      <h2 id="name-iana-considerations">
<a href="#section-14" class="section-number selfRef">14. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-14-1">IANA has added the UI suites defined in this document to the "Cryptographic Suites for IKEv1, IKEv2, and IPsec" registry located at <span>&lt;<a href="https://www.iana.org/assignments/crypto-suites">https://www.iana.org/assignments/crypto-suites</a>&gt;</span>:<a href="#section-14-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-center" rowspan="1" colspan="1">Identifier</th>
            <th class="text-center" rowspan="1" colspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">CNSA-GCM-256-ECDH-384</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 9206</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">CNSA-GCM-256-DH-3072</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 9206</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">CNSA-GCM-256-DH-4096</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 9206</td>
          </tr>
        </tbody>
      </table>
</section>
</div>
<section id="section-15">
      <h2 id="name-references">
<a href="#section-15" class="section-number selfRef">15. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-15.1">
        <h3 id="name-normative-references">
<a href="#section-15.1" class="section-number selfRef">15.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="refContent">CNSSP 15</span>, <time datetime="2016-10" class="refDate">October 2016</time>, <span>&lt;<a href="https://www.cnss.gov/CNSS/Issuances/Policies.htm">https://www.cnss.gov/CNSS/Issuances/Policies.htm</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="refContent">Federal Information Processing Standard 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://csrc.nist.gov/publications/detail/fips/180/4/final">https://csrc.nist.gov/publications/detail/fips/180/4/final</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="FIPS186">[FIPS186]</dt>
        <dd>
<span class="refAuthor">National Institute of Standards and Technology</span>, <span class="refTitle">"Digital Signature Standard (DSS)"</span>, <span class="refContent">NIST Federal Information Processing Standard 186-4</span>, <span class="seriesInfo">DOI 10.6028/NIST.FIPS.186-4</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span>&lt;<a href="https://csrc.nist.gov/publications/detail/fips/186/4/final">https://csrc.nist.gov/publications/detail/fips/186/4/final</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="FIPS197">[FIPS197]</dt>
        <dd>
<span class="refAuthor">National Institute of Standards and Technology</span>, <span class="refTitle">"Advanced Encryption Standard (AES)"</span>, <span class="refContent">Federal Information Processing Standard 197</span>, <span class="seriesInfo">DOI 10.6028/NIST.FIPS.197</span>, <time datetime="2001-11" class="refDate">November 2001</time>, <span>&lt;<a href="https://csrc.nist.gov/publications/detail/fips/197/final">https://csrc.nist.gov/publications/detail/fips/197/final</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="RFC2631">[RFC2631]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"Diffie-Hellman Key Agreement Method"</span>, <span class="seriesInfo">RFC 2631</span>, <span class="seriesInfo">DOI 10.17487/RFC2631</span>, <time datetime="1999-06" class="refDate">June 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2631">https://www.rfc-editor.org/info/rfc2631</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3526">[RFC3526]</dt>
        <dd>
<span class="refAuthor">Kivinen, T.</span> and <span class="refAuthor">M. Kojo</span>, <span class="refTitle">"More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)"</span>, <span class="seriesInfo">RFC 3526</span>, <span class="seriesInfo">DOI 10.17487/RFC3526</span>, <time datetime="2003-05" class="refDate">May 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3526">https://www.rfc-editor.org/info/rfc3526</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4106">[RFC4106]</dt>
        <dd>
<span class="refAuthor">Viega, J.</span> and <span class="refAuthor">D. McGrew</span>, <span class="refTitle">"The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)"</span>, <span class="seriesInfo">RFC 4106</span>, <span class="seriesInfo">DOI 10.17487/RFC4106</span>, <time datetime="2005-06" class="refDate">June 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4106">https://www.rfc-editor.org/info/rfc4106</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4303">[RFC4303]</dt>
        <dd>
<span class="refAuthor">Kent, S.</span>, <span class="refTitle">"IP Encapsulating Security Payload (ESP)"</span>, <span class="seriesInfo">RFC 4303</span>, <span class="seriesInfo">DOI 10.17487/RFC4303</span>, <time datetime="2005-12" class="refDate">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4303">https://www.rfc-editor.org/info/rfc4303</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4308">[RFC4308]</dt>
        <dd>
<span class="refAuthor">Hoffman, P.</span>, <span class="refTitle">"Cryptographic Suites for IPsec"</span>, <span class="seriesInfo">RFC 4308</span>, <span class="seriesInfo">DOI 10.17487/RFC4308</span>, <time datetime="2005-12" class="refDate">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4308">https://www.rfc-editor.org/info/rfc4308</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4754">[RFC4754]</dt>
        <dd>
<span class="refAuthor">Fu, D.</span> and <span class="refAuthor">J. Solinas</span>, <span class="refTitle">"IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)"</span>, <span class="seriesInfo">RFC 4754</span>, <span class="seriesInfo">DOI 10.17487/RFC4754</span>, <time datetime="2007-01" class="refDate">January 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4754">https://www.rfc-editor.org/info/rfc4754</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>, and <span class="refAuthor">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="RFC5903">[RFC5903]</dt>
        <dd>
<span class="refAuthor">Fu, D.</span> and <span class="refAuthor">J. Solinas</span>, <span class="refTitle">"Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2"</span>, <span class="seriesInfo">RFC 5903</span>, <span class="seriesInfo">DOI 10.17487/RFC5903</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5903">https://www.rfc-editor.org/info/rfc5903</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7296">[RFC7296]</dt>
        <dd>
<span class="refAuthor">Kaufman, C.</span>, <span class="refAuthor">Hoffman, P.</span>, <span class="refAuthor">Nir, Y.</span>, <span class="refAuthor">Eronen, P.</span>, and <span class="refAuthor">T. Kivinen</span>, <span class="refTitle">"Internet Key Exchange Protocol Version 2 (IKEv2)"</span>, <span class="seriesInfo">STD 79</span>, <span class="seriesInfo">RFC 7296</span>, <span class="seriesInfo">DOI 10.17487/RFC7296</span>, <time datetime="2014-10" class="refDate">October 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7296">https://www.rfc-editor.org/info/rfc7296</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8017">[RFC8017]</dt>
        <dd>
<span class="refAuthor">Moriarty, K., Ed.</span>, <span class="refAuthor">Kaliski, B.</span>, <span class="refAuthor">Jonsson, J.</span>, and <span class="refAuthor">A. Rusch</span>, <span class="refTitle">"PKCS #1: RSA Cryptography Specifications Version 2.2"</span>, <span class="seriesInfo">RFC 8017</span>, <span class="seriesInfo">DOI 10.17487/RFC8017</span>, <time datetime="2016-11" class="refDate">November 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8017">https://www.rfc-editor.org/info/rfc8017</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="RFC8221">[RFC8221]</dt>
        <dd>
<span class="refAuthor">Wouters, P.</span>, <span class="refAuthor">Migault, D.</span>, <span class="refAuthor">Mattsson, J.</span>, <span class="refAuthor">Nir, Y.</span>, and <span class="refAuthor">T. Kivinen</span>, <span class="refTitle">"Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)"</span>, <span class="seriesInfo">RFC 8221</span>, <span class="seriesInfo">DOI 10.17487/RFC8221</span>, <time datetime="2017-10" class="refDate">October 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8221">https://www.rfc-editor.org/info/rfc8221</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8247">[RFC8247]</dt>
        <dd>
<span class="refAuthor">Nir, Y.</span>, <span class="refAuthor">Kivinen, T.</span>, <span class="refAuthor">Wouters, P.</span>, and <span class="refAuthor">D. Migault</span>, <span class="refTitle">"Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)"</span>, <span class="seriesInfo">RFC 8247</span>, <span class="seriesInfo">DOI 10.17487/RFC8247</span>, <time datetime="2017-09" class="refDate">September 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8247">https://www.rfc-editor.org/info/rfc8247</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>
<dt id="RFC8784">[RFC8784]</dt>
        <dd>
<span class="refAuthor">Fluhrer, S.</span>, <span class="refAuthor">Kampanakis, P.</span>, <span class="refAuthor">McGrew, D.</span>, and <span class="refAuthor">V. Smyslov</span>, <span class="refTitle">"Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security"</span>, <span class="seriesInfo">RFC 8784</span>, <span class="seriesInfo">DOI 10.17487/RFC8784</span>, <time datetime="2020-06" class="refDate">June 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8784">https://www.rfc-editor.org/info/rfc8784</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">NIST Special Publication 800-56A, Revision 3</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://csrc.nist.gov/publications/detail/sp/800-56a/rev-3/final">https://csrc.nist.gov/publications/detail/sp/800-56a/rev-3/final</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-15.2">
        <h3 id="name-informative-references">
<a href="#section-15.2" class="section-number selfRef">15.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC8452">[RFC8452]</dt>
        <dd>
<span class="refAuthor">Gueron, S.</span>, <span class="refAuthor">Langley, A.</span>, and <span class="refAuthor">Y. Lindell</span>, <span class="refTitle">"AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption"</span>, <span class="seriesInfo">RFC 8452</span>, <span class="seriesInfo">DOI 10.17487/RFC8452</span>, <time datetime="2019-04" class="refDate">April 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8452">https://www.rfc-editor.org/info/rfc8452</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="refContent">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://csrc.nist.gov/publications/detail/sp/800-59/final">https://csrc.nist.gov/publications/detail/sp/800-59/final</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">Laura Corcoran</span></div>
<div dir="auto" class="left"><span class="org">National Security Agency</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:lscorco@nsa.gov" class="email">lscorco@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 - Center for Cybersecurity Standards</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>