File: rfc9242.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 (1978 lines) | stat: -rw-r--r-- 85,385 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 9242: Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<meta content="Valery Smyslov" name="author">
<meta content='
        This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 
      Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment.


The Intermediate Exchange makes it possible to use the existing IKE
fragmentation mechanism (which cannot be used in the initial IKEv2 exchange),
helping to avoid IP fragmentation of large IKE messages if they need to be
sent before IKEv2 SA is established.



       
    ' name="description">
<meta content="xml2rfc 3.12.8" name="generator">
<meta content="IKE_INTERMEDIATE" name="keyword">
<meta content="Quantum Computer resistant key exchange method" name="keyword">
<meta content="Post-quantum" name="keyword">
<meta content="9242" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.8
    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
    MarkupSafe 2.0.1
    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="rfc9242.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;
  }
  pre.breakable {
    break-inside: auto;
  }
  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/rfc9242" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate-10" 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 9242</td>
<td class="center">Intermediate IKEv2 Exchange</td>
<td class="right">May 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Smyslov</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9242" class="eref">9242</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-05" class="published">May 2022</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">V. Smyslov</div>
<div class="org">ELVIS-PLUS</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9242</h1>
<h1 id="title">Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1"> This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 
      Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment.


The Intermediate Exchange makes it possible to use the existing IKE
fragmentation mechanism (which cannot be used in the initial IKEv2 exchange),
helping to avoid IP fragmentation of large IKE messages if they need to be
sent before IKEv2 SA is established.<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 is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9242">https://www.rfc-editor.org/info/rfc9242</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. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="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-and-notation" class="xref">Terminology and Notation</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-intermediate-exchange-detai" class="xref">Intermediate Exchange Details</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-support-for-intermediate-ex" class="xref">Support for Intermediate Exchange Negotiation</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-using-intermediate-exchange" class="xref">Using Intermediate Exchange</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-the-ike_intermediate-exchan" class="xref">The IKE_INTERMEDIATE Exchange Protection and Authentication</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3.2.1">
                    <p id="section-toc.1-1.3.2.3.2.1.1"><a href="#section-3.3.1" class="xref">3.3.1</a>.  <a href="#name-protection-of-ike_intermedi" class="xref">Protection of IKE_INTERMEDIATE Messages</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3.2.2">
                    <p id="section-toc.1-1.3.2.3.2.2.1"><a href="#section-3.3.2" class="xref">3.3.2</a>.  <a href="#name-authentication-of-ike_inter" class="xref">Authentication of IKE_INTERMEDIATE Exchanges</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-error-handling-in-the-ike_i" class="xref">Error Handling in the IKE_INTERMEDIATE Exchange</a></p>
</li>
            </ul>
</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-interaction-with-other-ikev" class="xref">Interaction with Other IKEv2 Extensions</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-considerations" class="xref">Security Considerations</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-iana-considerations" class="xref">IANA Considerations</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-references" class="xref">References</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-normative-references" class="xref">Normative References</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-informative-references" class="xref">Informative References</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="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-example-of-ike_intermediate" class="xref">Example of IKE_INTERMEDIATE Exchange</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="#appendix-B" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</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="#appendix-C" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1"> The Internet Key Exchange Protocol       
Version 2 (IKEv2) defined in <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span>
            uses UDP as a transport for its messages. If the size of a message is larger than the Path MTU (PMTU), IP fragmentation
            takes place, which has been shown to cause operational challenges
            in certain network configurations and devices. The problem is described
            in more detail in <span>[<a href="#RFC7383" class="xref">RFC7383</a>]</span>, which also defines an extension to IKEv2 called "IKE fragmentation".
            This extension allows IKE messages to be fragmented at the IKE level, eliminating possible issues
            caused by IP fragmentation. However, IKE fragmentation cannot be used in the initial IKEv2 exchange 
            (IKE_SA_INIT). In most cases, this limitation is not a problem, since the IKE_SA_INIT
            messages are usually small enough not to cause IP fragmentation.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2"> However, the situation has been changing recently. One example of the need to transfer large amounts 
            of data before an IKE SA is created is using the QC-resistant key exchange methods in IKEv2. 

     Recent progress in quantum computing has led to concern that classical Diffie-Hellman key
            exchange methods will become insecure in the relatively near future and should be replaced with 
            QC-resistant ones.

     Currently, most QC-resistant key exchange methods have
            large public keys. If these keys are exchanged in the IKE_SA_INIT exchange, then
            IP fragmentation will probably take place; therefore, all the problems caused by it will become inevitable.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3"> A possible solution to this problem would be to use TCP as a transport for IKEv2, as defined
            in <span>[<a href="#RFC8229" class="xref">RFC8229</a>]</span>. However, this approach has significant drawbacks and is 
            intended to be a last resort when UDP transport is completely blocked by intermediate
            network devices.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4"> This specification describes a way to transfer a large amount of data in IKEv2 using UDP transport.
            For this purpose, the document defines a new exchange for IKEv2 called "Intermediate Exchange" or "IKE_INTERMEDIATE".
            One or more of these exchanges may take place right after the IKE_SA_INIT exchange and prior
            to the IKE_AUTH exchange. The IKE_INTERMEDIATE exchange messages can be fragmented using the IKE fragmentation mechanism, 
            so these exchanges may be used to transfer large amounts of data that don't fit into the IKE_SA_INIT exchange 
            without causing IP fragmentation.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5"> The Intermediate Exchange can be used to transfer large public keys of QC-resistant key exchange methods, 
            but its application is not limited to this use case. This exchange can also be used 
            whenever some data needs to be transferred before the IKE_AUTH exchange and for some reason
            the IKE_SA_INIT exchange is not suited for this purpose.  This document defines the IKE_INTERMEDIATE
            exchange without tying it to any specific use case. It is expected that separate specifications will define 
            for which purposes and how the IKE_INTERMEDIATE exchange is used in IKEv2. Some considerations
            must be taken into account when designing such specifications:<a href="#section-1-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-6.1"> The IKE_INTERMEDIATE exchange is not intended for 
              bulk transfer. This document doesn't set a hard cap on
              the amount of data that can be safely transferred using this mechanism, 
              as it depends on its application. However, in most cases, it is anticipated that
              the amount of data will be limited to tens of kilobytes (a few hundred kilobytes 
              in extreme cases), which is believed to cause no network problems
              (see <span>[<a href="#RFC6928" class="xref">RFC6928</a>]</span> as an example of experiments with sending
              similar amounts of data in the first TCP flight). See also 
              <a href="#security" class="xref">Section 5</a> for the discussion of possible DoS attack vectors 
              when the amount of data sent in the IKE_INTERMEDIATE exchange is too large.<a href="#section-1-6.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-6.2"> It is expected that the IKE_INTERMEDIATE exchange will 
              only be used for transferring data that is needed to establish IKE SA
              and not for data that can be sent later when this SA is established.<a href="#section-1-6.2" class="pilcrow">¶</a>
</li>
      </ul>
</section>
<div id="mustshouldmay">
<section id="section-2">
      <h2 id="name-terminology-and-notation">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology-and-notation" class="section-name selfRef">Terminology and Notation</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"> It is expected that readers are familiar with the terms used in the
      IKEv2 specification <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span>. Notation
      for the payloads contained in IKEv2 messages is defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7296#section-1.2" class="relref">Section 1.2</a> of [<a href="#RFC7296" class="xref">RFC7296</a>]</span>.<a href="#section-2-2" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3">
      <h2 id="name-intermediate-exchange-detai">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-intermediate-exchange-detai" class="section-name selfRef">Intermediate Exchange Details</a>
      </h2>
<section id="section-3.1">
        <h3 id="name-support-for-intermediate-ex">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-support-for-intermediate-ex" class="section-name selfRef">Support for Intermediate Exchange Negotiation</a>
        </h3>
<p id="section-3.1-1"> The initiator indicates its support for Intermediate Exchange by including a 
                notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in the IKE_SA_INIT request message. 
                If the responder also supports this exchange, it includes this notification 
                in the response message.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-3.1-2">
<pre>
Initiator                                 Responder
-----------                               -----------
HDR, SAi1, KEi, Ni,
[N(INTERMEDIATE_EXCHANGE_SUPPORTED)] --&gt;
                                   &lt;-- HDR, SAr1, KEr, Nr, [CERTREQ],
                                 [N(INTERMEDIATE_EXCHANGE_SUPPORTED)]
</pre><a href="#section-3.1-2" class="pilcrow">¶</a>
</div>
<p id="section-3.1-3">
The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2 
notification with Notify Message Type 16438. When it is sent, the Protocol ID 
and SPI Size fields in the Notify payload are both set to 0.

                This specification doesn't define any data that this notification may contain,
                so the Notification Data is left empty. However, future enhancements to this specification may override this.
                Implementations <span class="bcp14">MUST</span> ignore non-empty Notification Data if they don't understand its purpose.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
</section>
<section id="section-3.2">
        <h3 id="name-using-intermediate-exchange">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-using-intermediate-exchange" class="section-name selfRef">Using Intermediate Exchange</a>
        </h3>
<p id="section-3.2-1"> If both peers indicated their support for the Intermediate Exchange, the initiator may
                use one or more these exchanges to transfer additional data. Using the Intermediate Exchange is optional; 
                the initiator may find it unnecessary even when support for this exchange has been negotiated.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2"> The Intermediate Exchange is denoted as IKE_INTERMEDIATE; its Exchange Type is 43.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-3.2-3">
<pre>
Initiator                                 Responder
-----------                               -----------
HDR, ..., SK {...}  --&gt;
                                     &lt;--  HDR, ..., SK {...}
</pre><a href="#section-3.2-3" class="pilcrow">¶</a>
</div>
<p id="section-3.2-4"> The initiator may use several IKE_INTERMEDIATE exchanges if necessary.
                Since window size is initially set to 1 for both peers (<span><a href="https://www.rfc-editor.org/rfc/rfc7296#section-2.3" class="relref">Section 2.3</a> of [<a href="#RFC7296" class="xref">RFC7296</a>]</span>), these exchanges <span class="bcp14">MUST</span> be sequential 
                and <span class="bcp14">MUST</span> all be completed before the IKE_AUTH exchange is initiated.
                The IKE SA <span class="bcp14">MUST NOT</span> be considered as established until the IKE_AUTH
                exchange is successfully completed.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.2-5"> The Message IDs for IKE_INTERMEDIATE exchanges <span class="bcp14">MUST</span> be chosen according to the standard
                IKEv2 rule, described in <span><a href="https://www.rfc-editor.org/rfc/rfc7296#section-2.2" class="relref">Section 2.2</a> of [<a href="#RFC7296" class="xref">RFC7296</a>]</span>, i.e.,
                it is set to 1 for the first IKE_INTERMEDIATE exchange, 2 for the next (if any), and so on.
                Implementations <span class="bcp14">MUST</span> verify that Message IDs in the IKE_INTERMEDIATE messages they receive actually follow this rule.
                The Message ID for the first pair of IKE_AUTH messages is one more 
                than the value used in the last IKE_INTERMEDIATE exchange.<a href="#section-3.2-5" class="pilcrow">¶</a></p>
<p id="section-3.2-6"> If the presence of NAT is detected in the IKE_SA_INIT exchange via NAT_DETECTION_SOURCE_IP and
                NAT_DETECTION_DESTINATION_IP notifications, then the peers switch to port 4500 in the first IKE_INTERMEDIATE exchange
                and use this port for all subsequent exchanges, as described in <span><a href="https://www.rfc-editor.org/rfc/rfc7296#section-2.23" class="relref">Section 2.23</a> of [<a href="#RFC7296" class="xref">RFC7296</a>]</span>.<a href="#section-3.2-6" class="pilcrow">¶</a></p>
<p id="section-3.2-7"> The content of the IKE_INTERMEDIATE exchange messages depends on the data being transferred
                and will be defined by specifications utilizing this exchange.
                However, since the main motivation for the IKE_INTERMEDIATE exchange is to avoid
                IP fragmentation when large amounts of data need to be transferred
                prior to the IKE_AUTH exchange, the Encrypted payload <span class="bcp14">MUST</span> be present in the 
                IKE_INTERMEDIATE exchange messages, and payloads containing large amounts of data
                <span class="bcp14">MUST</span> be placed inside it. This will allow IKE fragmentation 
                <span>[<a href="#RFC7383" class="xref">RFC7383</a>]</span> to take place, provided it is supported 
                by the peers and negotiated in the initial exchange.<a href="#section-3.2-7" class="pilcrow">¶</a></p>
<p id="section-3.2-8"> <a href="#example" class="xref">Appendix A</a> contains an example of using an IKE_INTERMEDIATE exchange
                in creating an IKE SA.<a href="#section-3.2-8" class="pilcrow">¶</a></p>
</section>
<section id="section-3.3">
        <h3 id="name-the-ike_intermediate-exchan">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-the-ike_intermediate-exchan" class="section-name selfRef">The IKE_INTERMEDIATE Exchange Protection and Authentication</a>
        </h3>
<div id="protection">
<section id="section-3.3.1">
          <h4 id="name-protection-of-ike_intermedi">
<a href="#section-3.3.1" class="section-number selfRef">3.3.1. </a><a href="#name-protection-of-ike_intermedi" class="section-name selfRef">Protection of IKE_INTERMEDIATE Messages</a>
          </h4>
<p id="section-3.3.1-1"> The keys SK_e[i/r] and SK_a[i/r] for the protection of IKE_INTERMEDIATE exchanges
                    are computed in the standard fashion, as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7296#section-2.14" class="relref">Section 2.14</a> of [<a href="#RFC7296" class="xref">RFC7296</a>]</span>.<a href="#section-3.3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.3.1-2"> Every subsequent IKE_INTERMEDIATE exchange uses the most recently calculated IKE SA keys before 
                    this exchange is started. So, the first IKE_INTERMEDIATE exchange always uses SK_e[i/r] and SK_a[i/r] keys 
                    that were computed as a result of the IKE_SA_INIT exchange. If additional key exchange is performed 
                    in the first IKE_INTERMEDIATE exchange, resulting in the update of SK_e[i/r] and SK_a[i/r], 
                    then these updated keys are used for protection of the second IKE_INTERMEDIATE exchange. 
                    Otherwise, the original SK_e[i/r] and SK_a[i/r] keys are used again, and so on.<a href="#section-3.3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.3.1-3"> Once all the IKE_INTERMEDIATE exchanges are completed, the most recently calculated
                    SK_e[i/r] and SK_a[i/r] keys are used for protection of the IKE_AUTH exchange and all subsequent exchanges.<a href="#section-3.3.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3.3.2">
          <h4 id="name-authentication-of-ike_inter">
<a href="#section-3.3.2" class="section-number selfRef">3.3.2. </a><a href="#name-authentication-of-ike_inter" class="section-name selfRef">Authentication of IKE_INTERMEDIATE Exchanges</a>
          </h4>
<p id="section-3.3.2-1"> The IKE_INTERMEDIATE messages must be authenticated in the IKE_AUTH exchange,
                    which is performed by adding their content into the AUTH payload calculation. It is anticipated that in many use cases, IKE_INTERMEDIATE 
                    messages will be fragmented using the IKE fragmentation <span>[<a href="#RFC7383" class="xref">RFC7383</a>]</span> mechanism. According to <span>[<a href="#RFC7383" class="xref">RFC7383</a>]</span>, 
                    when IKE fragmentation is negotiated, the initiator may first send a request message in unfragmented form, 
                    but later turn on IKE fragmentation and resend it fragmented if no response is received after a few retransmissions. 
                    In addition, peers may resend a fragmented message using different fragment sizes to perform simple PMTU discovery.<a href="#section-3.3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.3.2-2"> The requirement to support this behavior makes authentication challenging: it is not appropriate to add 
                    on-the-wire content of the IKE_INTERMEDIATE messages into the AUTH payload calculation,
                    because implementations are generally unaware of which form these messages are received by peers. 
                    Instead, a more complex scheme is used; authentication is performed by adding the content of these messages before
                    their encryption and possible fragmentation, so that the data to be authenticated doesn't depend on the form
                    the messages are delivered in.<a href="#section-3.3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.3.2-3">
If one or more IKE_INTERMEDIATE exchanges took place, the definition of the
blob to be signed (or MACed) from <span><a href="https://www.rfc-editor.org/rfc/rfc7296#section-2.15" class="relref">Section 2.15</a> of [<a href="#RFC7296" class="xref">RFC7296</a>]</span> is modified as follows:<a href="#section-3.3.2-3" class="pilcrow">¶</a></p>
<div id="section-3.3.2-4">
<pre class="sourcecode">
InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI | IntAuth
ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR | IntAuth

IntAuth =  IntAuth_iN | IntAuth_rN | IKE_AUTH_MID

IntAuth_i1 = prf(SK_pi1,              IntAuth_i1A [| IntAuth_i1P])
IntAuth_i2 = prf(SK_pi2, IntAuth_i1 | IntAuth_i2A [| IntAuth_i2P])
IntAuth_i3 = prf(SK_pi3, IntAuth_i2 | IntAuth_i3A [| IntAuth_i3P])
...
IntAuth_iN = prf(SK_piN, IntAuth_iN-1 | IntAuth_iNA [| IntAuth_iNP])

IntAuth_r1 = prf(SK_pr1,              IntAuth_r1A [| IntAuth_r1P])
IntAuth_r2 = prf(SK_pr2, IntAuth_r1 | IntAuth_r2A [| IntAuth_r2P])
IntAuth_r3 = prf(SK_pr3, IntAuth_r2 | IntAuth_r3A [| IntAuth_r3P])
...
IntAuth_rN = prf(SK_prN, IntAuth_rN-1 | IntAuth_rNA [| IntAuth_rNP])
</pre><a href="#section-3.3.2-4" class="pilcrow">¶</a>
</div>
<p id="section-3.3.2-5"> The essence of this modification is that a new chunk called "IntAuth" is appended to the string of octets that is signed (or MACed) by the peers.
                    IntAuth consists of three parts: IntAuth_iN, IntAuth_rN, and IKE_AUTH_MID.<a href="#section-3.3.2-5" class="pilcrow">¶</a></p>
<p id="section-3.3.2-6"> The IKE_AUTH_MID chunk is a value of the Message ID field from the IKE Header of the first round of the IKE_AUTH exchange. 
                    It is represented as a four-octet integer in network byte order (in other words, exactly as it appears on the wire).<a href="#section-3.3.2-6" class="pilcrow">¶</a></p>
<p id="section-3.3.2-7"> The IntAuth_iN and IntAuth_rN chunks represent the cumulative result of applying the negotiated Pseudorandom Function (PRF)
                    to all IKE_INTERMEDIATE exchange messages sent during IKE SA establishment by the initiator and the responder, respectively.
                    After the first IKE_INTERMEDIATE exchange is complete, peers calculate the IntAuth_i1 value
                    by applying the negotiated PRF to the content of the request message from this exchange and
                    calculate the IntAuth_r1 value by applying the negotiated PRF to the content of the response message.
                    For every subsequent IKE_INTERMEDIATE exchange (if any), peers recalculate these values as follows:
                    after the nth exchange is complete, they compute IntAuth_[i/r]n by applying the negotiated 
                    PRF to the concatenation of IntAuth_[i/r](n-1) (computed for the previous IKE_INTERMEDIATE exchange) and 
                    the content of the request (for IntAuth_in) or response (for IntAuth_rn) messages from this exchange. After all IKE_INTERMEDIATE exchanges
                    are over, the resulted IntAuth_[i/r]N values (assuming N exchanges took place) are used in computing the AUTH payload.<a href="#section-3.3.2-7" class="pilcrow">¶</a></p>
<p id="section-3.3.2-8"> For the purpose of calculating the IntAuth_[i/r]* values, the content of the IKE_INTERMEDIATE messages 
                    is represented as two chunks of data: mandatory IntAuth_[i/r]*A, optionally followed by IntAuth_[i/r]*P.<a href="#section-3.3.2-8" class="pilcrow">¶</a></p>
<p id="section-3.3.2-9"> The IntAuth_[i/r]*A chunk consists of the sequence of octets from the first octet of the IKE Header (not including the prepended four octets of zeros, 
                    if UDP encapsulation or TCP encapsulation of ESP packets is used) to the last octet of the generic header of the Encrypted payload. 
                    The scope of IntAuth_[i/r]*A is identical to the scope of Associated Data defined for the use of AEAD algorithms in IKEv2 
                    (see <span><a href="https://www.rfc-editor.org/rfc/rfc5282#section-5.1" class="relref">Section 5.1</a> of [<a href="#RFC5282" class="xref">RFC5282</a>]</span>), which is stressed by using the "A" suffix in its name. Note that calculation of IntAuth_[i/r]*A
                    doesn't depend on whether an AEAD algorithm or a plain cipher is used in IKE SA.<a href="#section-3.3.2-9" class="pilcrow">¶</a></p>
<p id="section-3.3.2-10"> The IntAuth_[i/r]*P chunk is present if the Encrypted payload is not empty. It consists of the content of the Encrypted payload 
                    that is fully formed but not yet encrypted. The Initialization Vector, Padding, Pad Length, and Integrity Checksum Data fields
                    (see <span><a href="https://www.rfc-editor.org/rfc/rfc7296#section-3.14" class="relref">Section 3.14</a> of [<a href="#RFC7296" class="xref">RFC7296</a>]</span>) are not included into the calculation. 
                    In other words, the IntAuth_[i/r]*P chunk is the inner payloads of the Encrypted payload in plaintext form,
                    which is stressed by using the "P" suffix in its name.<a href="#section-3.3.2-10" class="pilcrow">¶</a></p>
<span id="name-data-to-authenticate-in-the"></span><div id="layout">
<figure id="figure-1">
            <div class="alignLeft art-text artwork" id="section-3.3.2-11.1">
<pre>
                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^
|                       IKE SA Initiator's SPI                  | | |
|                                                               | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I |
|                       IKE SA Responder's SPI                  | K |
|                                                               | E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |
|  Next Payload | MjVer | MnVer | Exchange Type |     Flags     | H |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d |
|                          Message ID                           | r A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
|                       Adjusted Length                         | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v |
|                                                               |   |
~                 Unencrypted payloads (if any)                 ~   |
|                                                               |   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |
| Next Payload  |C|  RESERVED   |    Adjusted Payload Length    | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v
|                                                               | |
~                     Initialization Vector                     ~ E
|                                                               | E
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^
|                                                               | r |
~             Inner payloads (not yet encrypted)                ~   P
|                                                               | P |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v
|              Padding (0-255 octets)           |  Pad Length   | d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|                                                               | |
~                    Integrity Checksum Data                    ~ |
|                                                               | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-data-to-authenticate-in-the" class="selfRef">Data to Authenticate in the IKE_INTERMEDIATE Exchange Messages</a>
            </figcaption></figure>
</div>
<p id="section-3.3.2-12"> <a href="#layout" class="xref">Figure 1</a> illustrates the layout of the IntAuth_[i/r]*A (denoted as A) 
                    and the IntAuth_[i/r]*P (denoted as P) chunks in case the Encrypted payload is not empty.<a href="#section-3.3.2-12" class="pilcrow">¶</a></p>
<p id="section-3.3.2-13"> For the purpose of prf calculation, the Length field in the IKE Header and the Payload Length 
                    field in the Encrypted payload header are adjusted so that they don't count the lengths
                    of Initialization Vector, Integrity Checksum Data, Padding, and Pad Length fields.
                    In other words, the Length field in the IKE Header (denoted as Adjusted Length in <a href="#layout" class="xref">Figure 1</a>)
                    is set to the sum of the lengths of IntAuth_[i/r]*A and IntAuth_[i/r]*P, and the Payload Length
                    field in the Encrypted payload header (denoted as Adjusted Payload Length in <a href="#layout" class="xref">Figure 1</a>)
                    is set to the length of IntAuth_[i/r]*P plus the size of the Encrypted payload header (four octets).<a href="#section-3.3.2-13" class="pilcrow">¶</a></p>
<p id="section-3.3.2-14"> The prf calculations <span class="bcp14">MUST</span> be applied to whole messages only, before possible IKE fragmentation. 
                    This ensures that the IntAuth will be the same regardless of whether or not IKE fragmentation takes place.
                    If the message was received in fragmented form, it <span class="bcp14">MUST</span> be reconstructed before calculating the prf as if it were received unfragmented.
                    While reconstructing, the RESERVED field in the reconstructed Encrypted payload header <span class="bcp14">MUST</span> be set to the value of the RESERVED 
                    field in the Encrypted Fragment payload header from the first fragment (with the Fragment Number field set to 1).<a href="#section-3.3.2-14" class="pilcrow">¶</a></p>
<p id="section-3.3.2-15"> Note that it is possible to avoid actual reconstruction of the message by incrementally calculating prf on 
                    decrypted (or ready to be encrypted) fragments. However, care must be taken to properly replace the content of the Next Header and the Length fields 
                    so that the result of computing the prf is the same as if it were computed on the reconstructed message.<a href="#section-3.3.2-15" class="pilcrow">¶</a></p>
<p id="section-3.3.2-16"> Each calculation of IntAuth_[i/r]* uses its own keys SK_p[i/r]*, which are the most recently updated SK_p[i/r] keys 
                    available before the corresponded IKE_INTERMEDIATE exchange is started. The first IKE_INTERMEDIATE exchange 
                    always uses the SK_p[i/r] keys that were computed in the IKE_SA_INIT exchange as SK_p[i/r]1. If the first IKE_INTERMEDIATE exchange performs
                    additional key exchange resulting in an SK_p[i/r] update, then these updated SK_p[i/r] keys are used as SK_p[i/r]2; otherwise, the original 
                    SK_p[i/r] keys are used, and so on. Note that if keys are updated, then for any given IKE_INTERMEDIATE exchange, the keys SK_e[i/r] and SK_a[i/r] 
                    used for protection of its messages (see <a href="#protection" class="xref">Section 3.3.1</a>) and the key SK_p[i/r] for its authentication are always 
                    from the same generation.<a href="#section-3.3.2-16" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-3.4">
        <h3 id="name-error-handling-in-the-ike_i">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-error-handling-in-the-ike_i" class="section-name selfRef">Error Handling in the IKE_INTERMEDIATE Exchange</a>
        </h3>
<p id="section-3.4-1"> Since messages of the IKE_INTERMEDIATE exchange are not authenticated until the IKE_AUTH exchange successfully 
                completes, possible errors need to be handled with care. There is a trade-off between providing
                better diagnostics of the problem and risk of becoming part of a DoS attack.
                Sections <a href="https://www.rfc-editor.org/rfc/rfc7296#section-2.21.1" class="relref">2.21.1</a> and <a href="https://www.rfc-editor.org/rfc/rfc7296#section-2.21.2" class="relref">2.21.2</a> of <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span> describe how errors are handled
                in initial IKEv2 exchanges; these considerations are also applied to the IKE_INTERMEDIATE exchange
                with the qualification that not all error notifications may appear in the IKE_INTERMEDIATE
                exchange (for example, errors concerning authentication are generally only applicable to the IKE_AUTH exchange).<a href="#section-3.4-1" class="pilcrow">¶</a></p>
</section>
</section>
<div id="interaction">
<section id="section-4">
      <h2 id="name-interaction-with-other-ikev">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-interaction-with-other-ikev" class="section-name selfRef">Interaction with Other IKEv2 Extensions</a>
      </h2>
<p id="section-4-1"> The IKE_INTERMEDIATE exchanges <span class="bcp14">MAY</span> be used during the IKEv2 Session Resumption <span>[<a href="#RFC5723" class="xref">RFC5723</a>]</span>
            between the IKE_SESSION_RESUME and the IKE_AUTH exchanges. To be able to use it, peers <span class="bcp14">MUST</span> negotiate 
            support for Intermediate Exchange by including INTERMEDIATE_EXCHANGE_SUPPORTED notifications in the 
            IKE_SESSION_RESUME messages. Note that a flag denoting whether peers supported the IKE_INTERMEDIATE exchange 
            is not stored in the resumption ticket and is determined each time from the IKE_SESSION_RESUME exchange.<a href="#section-4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security">
<section id="section-5">
      <h2 id="name-security-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-5-1"> The data that is transferred by means of the IKE_INTERMEDIATE exchanges is not authenticated
            until the subsequent IKE_AUTH exchange is complete. However, if the data is placed inside
            the Encrypted payload, then it is protected from passive eavesdroppers. In addition, the peers
            can be certain that they receive messages from the party they performed the IKE_SA_INIT exchange with
            if they can successfully verify the Integrity Checksum Data of the Encrypted payload.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2"> The main application for the Intermediate Exchange is to transfer
      large amounts of data before an IKE SA is set up, without causing IP
      fragmentation. For that reason, it is expected that IKE fragmentation
      will be employed in IKE_INTERMEDIATE exchanges in most cases. <span><a href="https://www.rfc-editor.org/rfc/rfc7383#section-5" class="relref">Section 5</a> of [<a href="#RFC7383" class="xref">RFC7383</a>]</span>
      contains security considerations for IKE fragmentation.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3"> Since authentication of peers occurs only in the IKE_AUTH exchange, a malicious initiator
            may use the Intermediate Exchange to mount a DoS attack on the responder. In this case, it 
            starts creating an IKE SA, negotiates using the Intermediate Exchanges, and transfers a lot
            of data to the responder that may also require computationally expensive processing. 
            Then, it aborts the SA establishment before the IKE_AUTH exchange.
            Specifications utilizing the Intermediate Exchange <span class="bcp14">MUST NOT</span> allow an unlimited number of these exchanges to take
            place at the initiator's discretion. It is recommended that these
            specifications be defined in such a way that the responder would
            know (possibly via negotiation with the initiator) the exact
            number of these exchanges that need to take place.

In other words, after the IKE_SA_INIT exchange is
complete, it is preferred that both the initiator and the responder
know the exact number of IKE_INTERMEDIATE exchanges they have to
perform; it is possible that some IKE_INTERMEDIATE exchanges are
optional and are performed at the initiator's discretion, but if a specification
defines optional use of IKE_INTERMEDIATE, then the maximum number 
of these exchanges must be hard capped by the corresponding specification.



     In addition, <span>[<a href="#RFC8019" class="xref">RFC8019</a>]</span> provides guidelines for the responder of how to
            deal with DoS attacks during IKE SA establishment.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4"> Note that if an attacker was able to break the key exchange in real time
            (e.g., by means of a quantum computer), then the security of the IKE_INTERMEDIATE exchange would degrade.
            In particular, such an attacker would be able to both read data contained in the 
            Encrypted payload and forge it. The forgery would become evident in the IKE_AUTH
            exchange (provided the attacker cannot break the employed authentication mechanism),
            but the ability to inject forged IKE_INTERMEDIATE exchange messages with a valid Integrity Check Value (ICV) would allow
            the attacker to mount a DoS attack. Moreover, in this situation, if the negotiated
            PRF was not secure against a second preimage attack with known key, then the attacker could 
            forge the IKE_INTERMEDIATE exchange messages without later being detected in the IKE_AUTH exchange.
            To do this, the attacker would find the same IntAuth_[i/r]* value for the forged message as for the original.<a href="#section-5-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
<section id="section-6">
      <h2 id="name-iana-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-6-1">This document defines a new Exchange Type in the "IKEv2 Exchange Types" registry:<a href="#section-6-1" class="pilcrow">¶</a></p>
<span id="name-ikev2-exchange-types"></span><div id="IKE_INTERMEDIATE">
<table class="left" id="table-1">
        <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-ikev2-exchange-types" class="selfRef">IKEv2 Exchange Types</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Value</th>
            <th class="text-left" rowspan="1" colspan="1">Exchange Type</th>
            <th class="text-left" rowspan="1" colspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">43</td>
            <td class="text-left" rowspan="1" colspan="1">IKE_INTERMEDIATE</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 9242</td>
          </tr>
        </tbody>
      </table>
</div>
<p id="section-6-3">This document also defines a new Notify Message Type in the "IKEv2 Notify Message Types - Status Types" registry:<a href="#section-6-3" class="pilcrow">¶</a></p>
<span id="name-ikev2-notify-message-types-"></span><div id="INTERMEDIATE_EXCHANGE_SUPPORTED">
<table class="left" id="table-2">
        <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-ikev2-notify-message-types-" class="selfRef">IKEv2 Notify Message Types - Status Types</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Value</th>
            <th class="text-left" rowspan="1" colspan="1">NOTIFY MESSAGES - STATUS TYPES</th>
            <th class="text-left" rowspan="1" colspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">16438</td>
            <td class="text-left" rowspan="1" colspan="1">INTERMEDIATE_EXCHANGE_SUPPORTED</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 9242</td>
          </tr>
        </tbody>
      </table>
</div>
</section>
</div>
<section id="section-7">
      <h2 id="name-references">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-7.1">
        <h3 id="name-normative-references">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<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="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="RFC7383">[RFC7383]</dt>
        <dd>
<span class="refAuthor">Smyslov, V.</span>, <span class="refTitle">"Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation"</span>, <span class="seriesInfo">RFC 7383</span>, <span class="seriesInfo">DOI 10.17487/RFC7383</span>, <time datetime="2014-11" class="refDate">November 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7383">https://www.rfc-editor.org/info/rfc7383</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>
</dl>
</section>
<section id="section-7.2">
        <h3 id="name-informative-references">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC5282">[RFC5282]</dt>
        <dd>
<span class="refAuthor">Black, D.</span> and <span class="refAuthor">D. McGrew</span>, <span class="refTitle">"Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol"</span>, <span class="seriesInfo">RFC 5282</span>, <span class="seriesInfo">DOI 10.17487/RFC5282</span>, <time datetime="2008-08" class="refDate">August 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5282">https://www.rfc-editor.org/info/rfc5282</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5723">[RFC5723]</dt>
        <dd>
<span class="refAuthor">Sheffer, Y.</span> and <span class="refAuthor">H. Tschofenig</span>, <span class="refTitle">"Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption"</span>, <span class="seriesInfo">RFC 5723</span>, <span class="seriesInfo">DOI 10.17487/RFC5723</span>, <time datetime="2010-01" class="refDate">January 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5723">https://www.rfc-editor.org/info/rfc5723</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6928">[RFC6928]</dt>
        <dd>
<span class="refAuthor">Chu, J.</span>, <span class="refAuthor">Dukkipati, N.</span>, <span class="refAuthor">Cheng, Y.</span>, and <span class="refAuthor">M. Mathis</span>, <span class="refTitle">"Increasing TCP's Initial Window"</span>, <span class="seriesInfo">RFC 6928</span>, <span class="seriesInfo">DOI 10.17487/RFC6928</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6928">https://www.rfc-editor.org/info/rfc6928</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8019">[RFC8019]</dt>
        <dd>
<span class="refAuthor">Nir, Y.</span> and <span class="refAuthor">V. Smyslov</span>, <span class="refTitle">"Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks"</span>, <span class="seriesInfo">RFC 8019</span>, <span class="seriesInfo">DOI 10.17487/RFC8019</span>, <time datetime="2016-11" class="refDate">November 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8019">https://www.rfc-editor.org/info/rfc8019</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8229">[RFC8229]</dt>
      <dd>
<span class="refAuthor">Pauly, T.</span>, <span class="refAuthor">Touati, S.</span>, and <span class="refAuthor">R. Mantha</span>, <span class="refTitle">"TCP Encapsulation of IKE and IPsec Packets"</span>, <span class="seriesInfo">RFC 8229</span>, <span class="seriesInfo">DOI 10.17487/RFC8229</span>, <time datetime="2017-08" class="refDate">August 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8229">https://www.rfc-editor.org/info/rfc8229</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="example">
<section id="appendix-A">
      <h2 id="name-example-of-ike_intermediate">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-example-of-ike_intermediate" class="section-name selfRef">Example of IKE_INTERMEDIATE Exchange</a>
      </h2>
<p id="appendix-A-1"> This appendix contains an example of the messages using IKE_INTERMEDIATE exchanges. 
          This appendix is purely informative; if it disagrees with the body of this document, 
          the other text is considered correct.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2"> In this example, there is one IKE_SA_INIT exchange and two IKE_INTERMEDIATE exchanges,
          followed by the IKE_AUTH exchange to authenticate all initial exchanges. The xxx in the HDR(xxx,MID=yyy)
          indicates the Exchange Type, and yyy indicates the Message ID used for that exchange. 
          The keys used for each SK {} payload are indicated in the parenthesis after the SK. 
          Otherwise, the payload notation is the same as is used in <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span>.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="appendix-A-3">
<pre>
Initiator                         Responder
-----------                       -----------
HDR(IKE_SA_INIT,MID=0),
SAi1, KEi, Ni,
N(INTERMEDIATE_EXCHANGE_SUPPORTED)  --&gt;

                             &lt;--  HDR(IKE_SA_INIT,MID=0),
                                  SAr1, KEr, Nr, [CERTREQ],
                                  N(INTERMEDIATE_EXCHANGE_SUPPORTED)
</pre><a href="#appendix-A-3" class="pilcrow">¶</a>
</div>
<p id="appendix-A-4"> At this point, peers calculate SK_* and store them as SK_*1.
          SK_e[i/r]1 and SK_a[i/r]1 will be used to protect the first IKE_INTERMEDIATE exchange,
          and SK_p[i/r]1 will be used for its authentication.<a href="#appendix-A-4" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="appendix-A-5">
<pre>
Initiator                         Responder
-----------                       -----------
HDR(IKE_INTERMEDIATE,MID=1),
SK(SK_ei1,SK_ai1) {...}  --&gt;

         &lt;Calculate IntAuth_i1 = prf(SK_pi1, ...)&gt;

                             &lt;--  HDR(IKE_INTERMEDIATE,MID=1),
                                  SK(SK_er1,SK_ar1) {...}

         &lt;Calculate IntAuth_r1 = prf(SK_pr1, ...)&gt;
</pre><a href="#appendix-A-5" class="pilcrow">¶</a>
</div>
<p id="appendix-A-6"> If the SK_*1 keys are updated (e.g., as a result of a new key exchange) after completing this IKE_INTERMEDIATE exchange, 
          then the peers store the updated keys as SK_*2; otherwise, they use SK_*1 as SK_*2.
          SK_e[i/r]2 and SK_a[i/r]2 will be used to protect the second IKE_INTERMEDIATE exchange,
          and SK_p[i/r]2 will be used for its authentication.<a href="#appendix-A-6" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="appendix-A-7">
<pre>
Initiator                         Responder
-----------                       -----------
HDR(IKE_INTERMEDIATE,MID=2),
SK(SK_ei2,SK_ai2) {...}  --&gt;

         &lt;Calculate IntAuth_i2 = prf(SK_pi2, ...)&gt;

                             &lt;--  HDR(IKE_INTERMEDIATE,MID=2),
                                  SK(SK_er2,SK_ar2) {...}

         &lt;Calculate IntAuth_r2 = prf(SK_pr2, ...)&gt;
</pre><a href="#appendix-A-7" class="pilcrow">¶</a>
</div>
<p id="appendix-A-8"> If the SK_*2 keys are updated (e.g., as a result of a new key exchange) after completing the second IKE_INTERMEDIATE exchange,
          then the peers store the updated keys as SK_*3; otherwise, they use SK_*2 as SK_*3.
          SK_e[i/r]3 and SK_a[i/r]3 will be used to protect the IKE_AUTH exchange, SK_p[i/r]3 will be used for authentication, and
          SK_d3 will be used for derivation of other keys (e.g., for Child SAs).<a href="#appendix-A-8" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="appendix-A-9">
<pre>
Initiator                         Responder
-----------                       -----------
HDR(IKE_AUTH,MID=3),
SK(SK_ei3,SK_ai3)
{IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr}  --&gt;
                             &lt;--  HDR(IKE_AUTH,MID=3),
                                  SK(SK_er3,SK_ar3)
                                  {IDr, [CERT,] AUTH, SAr2, TSi, TSr}
</pre><a href="#appendix-A-9" class="pilcrow">¶</a>
</div>
<p id="appendix-A-10"> In this example, two IKE_INTERMEDIATE exchanges took place; therefore, SK_*3 keys would be used as SK_* keys for 
          further cryptographic operations in the context of the created IKE SA, as defined in <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span>.<a href="#appendix-A-10" class="pilcrow">¶</a></p>
</section>
</div>
<section id="appendix-B">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-B-1"> The idea to use an Intermediate Exchange between the IKE_SA_INIT and IKE_AUTH exchanges was first suggested by <span class="contact-name">Tero Kivinen</span>.
            He also helped to write the example IKE_INTERMEDIATE exchange shown in <a href="#example" class="xref">Appendix A</a>.
            <span class="contact-name">Scott Fluhrer</span> and <span class="contact-name">Daniel Van Geest</span> identified a possible problem with authentication of the IKE_INTERMEDIATE exchange and helped to resolve it.
            The author is grateful to <span class="contact-name">Tobias Brunner</span>, who raised good questions concerning authentication of the IKE_INTERMEDIATE exchange
            and proposed how to make the size of authentication chunks constant regardless of the number of exchanges. 
            The author is also grateful to <span class="contact-name">Paul Wouters</span> and <span class="contact-name">Benjamin Kaduk</span>, who suggested a lot of text improvements for the document.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="appendix-C">
      <h2 id="name-authors-address">
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Valery Smyslov</span></div>
<div dir="auto" class="left"><span class="org">ELVIS-PLUS</span></div>
<div dir="auto" class="left"><span class="street-address">PO Box 81</span></div>
<div dir="auto" class="left"><span class="locality">Moscow (Zelenograd)</span></div>
<div dir="auto" class="left"><span class="postal-code">124460</span></div>
<div dir="auto" class="left"><span class="country-name">Russian Federation</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+7%20495%20276%200211" class="tel">+7 495 276 0211</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:svan@elvis.ru" class="email">svan@elvis.ru</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>