File: rfc9140.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 (4746 lines) | stat: -rw-r--r-- 269,313 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 9140: Nimble Out-of-Band Authentication for EAP (EAP‑NOOB)</title>
<meta content="Tuomas Aura" name="author">
<meta content="Mohit Sethi" name="author">
<meta content="Aleksi Peltonen" name="author">
<meta content="
       The Extensible Authentication Protocol (EAP) provides support for multiple
      authentication methods.
      This document defines the EAP-NOOB authentication method for
      nimble out-of-band (OOB) authentication and key derivation. The EAP method is intended
      for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no
      preconfigured authentication credentials. The method makes use of a user-assisted,
      one-directional, out-of-band (OOB) message between the peer device and authentication
      server to
      authenticate the in-band key exchange. The device must have a nonnetwork input or
      output interface, such as a display, microphone, speaker, or blinking light, that can
      send or receive dynamically generated messages of tens of bytes in length. 
    " name="description">
<meta content="xml2rfc 3.12.0" name="generator">
<meta content="IoT security" name="keyword">
<meta content="cybersecurity" name="keyword">
<meta content="network access authorization" name="keyword">
<meta content="Extensible Authentication Protocol" name="keyword">
<meta content="key exchange" name="keyword">
<meta content="9140" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.0
    Python 3.6.13
    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="rfc9140.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/rfc9140" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob-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 9140</td>
<td class="center">EAP-NOOB</td>
<td class="right">December 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Aura, et al.</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9140" class="eref">9140</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="2021-12" class="published">December 2021</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">T. Aura</div>
<div class="org">Aalto University</div>
</div>
<div class="author">
      <div class="author-name">M. Sethi</div>
<div class="org">Ericsson</div>
</div>
<div class="author">
      <div class="author-name">A. Peltonen</div>
<div class="org">Aalto University</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9140</h1>
<h1 id="title">Nimble Out-of-Band Authentication for EAP (EAP‑NOOB)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">The Extensible Authentication Protocol (EAP) provides support for multiple
      authentication methods.
      This document defines the EAP-NOOB authentication method for
      nimble out-of-band (OOB) authentication and key derivation. The EAP method is intended
      for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no
      preconfigured authentication credentials. The method makes use of a user-assisted,
      one-directional, out-of-band (OOB) message between the peer device and authentication
      server to
      authenticate the in-band key exchange. The device must have a nonnetwork input or
      output interface, such as a display, microphone, speaker, or blinking light, that can
      send or receive dynamically generated messages of tens of bytes in length.<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/rfc9140">https://www.rfc-editor.org/info/rfc9140</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) 2021 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" 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"><a href="#section-3" class="xref">3</a>.  <a href="#name-eap-noob-method" class="xref">EAP-NOOB Method</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-protocol-overview" class="xref">Protocol Overview</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-protocol-messages-and-seque" class="xref">Protocol Messages and Sequences</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.1">
                    <p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="xref">3.2.1</a>.  <a href="#name-common-handshake-in-all-eap" class="xref">Common Handshake in All EAP-NOOB Exchanges</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.2">
                    <p id="section-toc.1-1.3.2.2.2.2.1"><a href="#section-3.2.2" class="xref">3.2.2</a>.  <a href="#name-initial-exchange" class="xref">Initial Exchange</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.3">
                    <p id="section-toc.1-1.3.2.2.2.3.1"><a href="#section-3.2.3" class="xref">3.2.3</a>.  <a href="#name-oob-step" class="xref">OOB Step</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.4">
                    <p id="section-toc.1-1.3.2.2.2.4.1"><a href="#section-3.2.4" class="xref">3.2.4</a>.  <a href="#name-completion-exchange" class="xref">Completion Exchange</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.5">
                    <p id="section-toc.1-1.3.2.2.2.5.1"><a href="#section-3.2.5" class="xref">3.2.5</a>.  <a href="#name-waiting-exchange" class="xref">Waiting Exchange</a></p>
</li>
                </ul>
</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-protocol-data-fields" class="xref">Protocol Data Fields</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-peer-identifier-and-nai" class="xref">Peer Identifier and NAI</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-message-data-fields" class="xref">Message Data Fields</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-fast-reconnect-and-rekeying" class="xref">Fast Reconnect and Rekeying</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4.2.1">
                    <p id="section-toc.1-1.3.2.4.2.1.1"><a href="#section-3.4.1" class="xref">3.4.1</a>.  <a href="#name-persistent-eap-noob-associa" class="xref">Persistent EAP-NOOB Association</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4.2.2">
                    <p id="section-toc.1-1.3.2.4.2.2.1"><a href="#section-3.4.2" class="xref">3.4.2</a>.  <a href="#name-reconnect-exchange" class="xref">Reconnect Exchange</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4.2.3">
                    <p id="section-toc.1-1.3.2.4.2.3.1"><a href="#section-3.4.3" class="xref">3.4.3</a>.  <a href="#name-user-reset" class="xref">User Reset</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-key-derivation" class="xref">Key Derivation</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.6">
                <p id="section-toc.1-1.3.2.6.1"><a href="#section-3.6" class="xref">3.6</a>.  <a href="#name-error-handling" class="xref">Error Handling</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.6.2.1">
                    <p id="section-toc.1-1.3.2.6.2.1.1"><a href="#section-3.6.1" class="xref">3.6.1</a>.  <a href="#name-invalid-messages" class="xref">Invalid Messages</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.6.2.2">
                    <p id="section-toc.1-1.3.2.6.2.2.1"><a href="#section-3.6.2" class="xref">3.6.2</a>.  <a href="#name-unwanted-peer" class="xref">Unwanted Peer</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.6.2.3">
                    <p id="section-toc.1-1.3.2.6.2.3.1"><a href="#section-3.6.3" class="xref">3.6.3</a>.  <a href="#name-state-mismatch" class="xref">State Mismatch</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.6.2.4">
                    <p id="section-toc.1-1.3.2.6.2.4.1"><a href="#section-3.6.4" class="xref">3.6.4</a>.  <a href="#name-negotiation-failure" class="xref">Negotiation Failure</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.6.2.5">
                    <p id="section-toc.1-1.3.2.6.2.5.1"><a href="#section-3.6.5" class="xref">3.6.5</a>.  <a href="#name-cryptographic-verification-" class="xref">Cryptographic Verification Failure</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.6.2.6">
                    <p id="section-toc.1-1.3.2.6.2.6.1"><a href="#section-3.6.6" class="xref">3.6.6</a>.  <a href="#name-application-specific-failur" class="xref">Application-Specific Failure</a></p>
</li>
                </ul>
</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-serverinfo-and-peerinfo-con" class="xref">ServerInfo and PeerInfo Contents</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-iana-considerations" class="xref">IANA Considerations</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-cryptosuites" class="xref">Cryptosuites</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-message-types" class="xref">Message Types</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-error-codes" class="xref">Error Codes</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-serverinfo-data-fields-2" class="xref">ServerInfo Data Fields</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-peerinfo-data-fields-2" class="xref">PeerInfo Data Fields</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.6">
                <p id="section-toc.1-1.5.2.6.1"><a href="#section-5.6" class="xref">5.6</a>.  <a href="#name-domain-name-reservation" class="xref">Domain Name Reservation</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.7">
                <p id="section-toc.1-1.5.2.7.1"><a href="#section-5.7" class="xref">5.7</a>.  <a href="#name-guidance-for-designated-exp" class="xref">Guidance for Designated Experts</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-security-considerations" class="xref">Security Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-authentication-principle" class="xref">Authentication Principle</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-identifying-correct-endpoin" class="xref">Identifying Correct Endpoints</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-trusted-path-issues-and-mis" class="xref">Trusted Path Issues and Misbinding Attacks</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.4">
                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-peer-identifiers-and-attrib" class="xref">Peer Identifiers and Attributes</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.5">
                <p id="section-toc.1-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-downgrading-threats" class="xref">Downgrading Threats</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.6">
                <p id="section-toc.1-1.6.2.6.1"><a href="#section-6.6" class="xref">6.6</a>.  <a href="#name-protected-success-and-failu" class="xref">Protected Success and Failure Indications</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.7">
                <p id="section-toc.1-1.6.2.7.1"><a href="#section-6.7" class="xref">6.7</a>.  <a href="#name-channel-binding" class="xref">Channel Binding</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.8">
                <p id="section-toc.1-1.6.2.8.1"><a href="#section-6.8" class="xref">6.8</a>.  <a href="#name-denial-of-service" class="xref">Denial of Service</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.9">
                <p id="section-toc.1-1.6.2.9.1"><a href="#section-6.9" class="xref">6.9</a>.  <a href="#name-recovery-from-loss-of-last-" class="xref">Recovery from Loss of Last Message</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.10">
                <p id="section-toc.1-1.6.2.10.1"><a href="#section-6.10" class="xref">6.10</a>. <a href="#name-privacy-considerations" class="xref">Privacy Considerations</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.11">
                <p id="section-toc.1-1.6.2.11.1"><a href="#section-6.11" class="xref">6.11</a>. <a href="#name-eap-security-claims" class="xref">EAP Security Claims</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-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-exchanges-and-events-per-st" class="xref">Exchanges and Events per State</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">Appendix B</a>.  <a href="#name-application-specific-parame" class="xref">Application-Specific Parameters</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">Appendix C</a>.  <a href="#name-eap-noob-roaming" class="xref">EAP-NOOB Roaming</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="#appendix-D" class="xref">Appendix D</a>.  <a href="#name-oob-message-as-a-url" class="xref">OOB Message as a URL</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="#appendix-E" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</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="#appendix-F" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<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 describes a method for registration, authentication, and key derivation
      for network-connected smart devices, such as consumer and enterprise appliances that are
      part of the Internet of Things (IoT). These devices may be off-the-shelf hardware that
      is sold and distributed without any prior registration or credential-provisioning
      process, or they may be recycled devices after a hard reset. Thus, the device
      registration in a server database, ownership of the device, and the authentication
      credentials for both network access and application-level security must all be
      established at the time of the device deployment. Furthermore, many such devices have
      only limited user interfaces that could be used for their configuration. Often, the user
      interfaces are limited to either only input (e.g., a camera) or output (e.g., a display
      screen). The device configuration is made more challenging by the fact that the devices
      may exist in large numbers and may have to be deployed or reconfigured nimbly based on
      user needs.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">To summarize, devices may have the following characteristics:<a href="#section-1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-3.1">no preestablished relation with the intended server or user,<a href="#section-1-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-3.2">no preprovisioned device identifier or authentication credentials, or<a href="#section-1-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-3.3">an input or output interface that may be capable of only one-directional
 out-of-band communication.<a href="#section-1-3.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-4">Many proprietary out-of-band (OOB) configuration methods exist for specific IoT
      devices. The goal of this specification is to provide an open standard and a generic
      protocol for bootstrapping the security of network-connected appliances, such as
      displays, printers, speakers, and cameras. The security bootstrapping in this
      specification makes use of a user-assisted OOB channel. The device authentication relies
      on a user having physical access to the device, and the key exchange security is based
      on the assumption that attackers are not able to observe or modify the messages conveyed
      through the OOB channel. We follow the common approach taken in pairing protocols:
      performing a Diffie-Hellman key exchange over the insecure network and authenticating
      the established key with the help of the OOB channel in order to prevent impersonation
      attacks.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">The solution presented here is intended for devices that have either a nonnetwork
      input or output interface, such as a camera, microphone, display screen, speaker, or
      blinking Light Emitting Diode (LED) light, that is able to send or receive dynamically
      generated messages of
      tens of bytes in length. Naturally, this solution may not be appropriate for very small
      sensors or actuators that have no user interface at all or for devices that are
      inaccessible to the user. We also assume that the OOB channel is at least partly
      automated (e.g., a camera scanning a bar code); thus, there is no need to absolutely
      minimize the length of the data transferred through the OOB channel. This differs, for
      example, from Bluetooth pairing <span>[<a href="#Bluetooth" class="xref">Bluetooth</a>]</span>,
      where it is essential to minimize the length of the manually transferred or compared
      codes. The OOB messages in this specification are dynamically generated. Thus, we do not
      support static printed registration codes. One reason for requiring dynamic OOB messages
      is that the receipt of the OOB message authorizes the server to take ownership of the
      device. Dynamic OOB messages are more secure than static printed codes, which could be
      leaked and later misused.<a href="#section-1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="terminology">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
      "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
      "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
      "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be
      interpreted as
      described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
      when, and only when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">In addition, this document frequently uses the following terms as they have been
      defined in <span>[<a href="#RFC5216" class="xref">RFC5216</a>]</span>:<a href="#section-2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2-3">
        <dt id="section-2-3.1">authenticator</dt>
        <dd style="margin-left: 3.0em" id="section-2-3.2">The entity initiating EAP authentication.<a href="#section-2-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.3">peer</dt>
        <dd style="margin-left: 3.0em" id="section-2-3.4">The entity that responds to the authenticator. In <span>[<a href="#IEEE-802.1X" class="xref">IEEE-802.1X</a>]</span>, this entity is known as the supplicant. (We use the terms peer,
 device, and peer device interchangeably.)<a href="#section-2-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.5">server</dt>
        <dd style="margin-left: 3.0em" id="section-2-3.6">The entity that terminates the EAP authentication method with the peer. In the
 case where no backend authentication server is used, the EAP server is part of the
 authenticator. In the case where the authenticator operates in pass-through mode, the
 EAP server is located on the backend authentication server.<a href="#section-2-3.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="eap-noob">
<section id="section-3">
      <h2 id="name-eap-noob-method">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-eap-noob-method" class="section-name selfRef">EAP-NOOB Method</a>
      </h2>
<p id="section-3-1">This section defines the EAP-NOOB method. The protocol is a generalized version of
      the original idea presented by <span><a href="#Sethi14" class="xref">Sethi et
      al.</a> [<a href="#Sethi14" class="xref">Sethi14</a>]</span>.<a href="#section-3-1" class="pilcrow">¶</a></p>
<div id="overview">
<section id="section-3.1">
        <h3 id="name-protocol-overview">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-protocol-overview" class="section-name selfRef">Protocol Overview</a>
        </h3>
<p id="section-3.1-1">One EAP-NOOB method execution spans two or more EAP conversations, called
 Exchanges in this specification. Each Exchange consists of several EAP
 request-response pairs. At least two separate EAP conversations are needed to give the
 human user time to deliver the OOB message between them.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">The overall protocol starts with the Initial Exchange, which comprises four EAP
 request-response pairs. In the Initial Exchange, the server allocates an identifier to
 the peer, and the server and peer negotiate the protocol version and cryptosuite
 (i.e., cryptographic algorithm suite), exchange nonces, and perform an Ephemeral
 Elliptic Curve Diffie-Hellman (ECDHE) key exchange. The user-assisted OOB Step then
 takes place. This step requires only one out-of-band message, either from the peer to
 the server or from the server to the peer. While waiting for the OOB Step action, the
 peer <span class="bcp14">MAY</span> probe the server by reconnecting to it with EAP-NOOB. If the
 OOB Step has already taken place, the probe leads to the Completion Exchange, which
 completes the mutual authentication and key confirmation. On the other hand, if the
 OOB Step has not yet taken place, the probe leads to the Waiting Exchange, and the
 peer will perform another probe after a server-defined minimum waiting time. The
 Initial Exchange and Waiting Exchange always end in EAP-Failure, while the Completion
 Exchange may result in EAP-Success. Once the peer and server have performed a
 successful Completion Exchange, both endpoints store the created association in
 persistent storage, and the OOB Step is not repeated. Thereafter, creation of new
 temporal keys, ECDHE rekeying, and updates of cryptographic algorithms can be achieved
 with the Reconnect Exchange.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<span id="name-eap-noob-server-peer-associ"></span><div id="fig-statemachine">
<figure id="figure-1">
          <div class="alignLeft art-text artwork" id="section-3.1-3.1">
<pre>
                                    OOB Output/Initial Exchange/
                                               Waiting Exchange
                                                 .-----.
                                                 |     v
     .------------------.   Initial       .------------------.
     |                  |   Exchange      |                  |
  .-&gt;| Unregistered (0) |----------------&gt;|Waiting for OOB(1)|
  |  |   (ephemeral)    |                 |   (ephemeral)    |
  |  |                  |                 |                  |
  |  '------------------'                 '------------------'
  |                                         |      |      ^
 User Reset                 Completion      |      |      |
  |                         Exchange        |     OOB   OOB
  |&lt;-------.      .-------------------------'    Input  Reject/
  |        |      |                                |    Initial
  |        |      |                                |    Exchange
  |        |      v                                v      |
  |  .------------------.   Completion    .------------------.
  |  |                  |   Exchange      |                  |
  |  |  Registered (4)  |&lt;----------------| OOB Received (2) |
  |  |   (persistent)   |                 |   (ephemeral)    |
  |  |                  |                 |                  |
  |  '------------------'                 '------------------'
  |        |      ^
  |  Mobility/    |
  |  Timeout/   Reconnect
  |  Failure    Exchange
  |        |      |
  |        v      |
  |  .------------------.
  |  |                  |
  '--| Reconnecting (3) |
     |   (persistent)   |
     |                  |
     '------------------'
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-eap-noob-server-peer-associ" class="selfRef">EAP-NOOB Server-Peer Association State Machine</a>
          </figcaption></figure>
</div>
<p id="section-3.1-4"><a href="#fig-statemachine" class="xref">Figure 1</a> shows the association state
 machine, which is the same for the server and for the peer. (For readability, only the
 main state transitions are shown. The complete table of transitions can be found in
 <a href="#exchangeappendix" class="xref">Appendix A</a>.) When the peer initiates the
 EAP-NOOB method, the server chooses the ensuing message exchange based on the
 combination of the server and peer states. The EAP server and peer are initially in
 the Unregistered (0) state, in which no state information needs to be stored. Before a
 successful Completion Exchange, the server-peer association state is ephemeral in both
 the server and peer (ephemeral states 0..2), and a timeout or error may cause one or
 both endpoints to go back to the Unregistered (0) state so that the Initial Exchange
 is
 repeated. After the Completion Exchange has resulted in EAP-Success, the association
 state becomes persistent (persistent states 3..4). Only user reset or memory failure
 can cause the return of the server or the peer from the persistent states to the
 ephemeral states and to the Initial Exchange.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.1-5">The server <span class="bcp14">MUST NOT</span> repeat a successful OOB Step with the same peer
 except if the association with the peer is explicitly reset by the user or lost due to
 failure of the persistent storage in the server. More specifically, once the
 association has entered the Registered (4) state, the server <span class="bcp14">MUST NOT</span>
 delete the association or go back to the ephemeral states 0..2 without explicit user
 approval. Similarly, the peer <span class="bcp14">MUST NOT</span> repeat the OOB Step unless the
 user explicitly deletes the association with the server from the peer or resets the
 peer to the Unregistered (0) state. The server and peer <span class="bcp14">MAY</span> implement
 user
 reset of the association by deleting the state data from that endpoint. If an endpoint
 continues to store data about the association after the user reset, its behavior
 <span class="bcp14">MUST</span> be equivalent to having deleted the association data.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
<p id="section-3.1-6">It can happen that the peer accidentally (or through user reset) loses its
 persistent
 state and reconnects to the server without a previously allocated peer identifier. In
 that case, the server <span class="bcp14">MUST</span> treat the peer as a new peer. The server
 <span class="bcp14">MAY</span> use auxiliary information, such as the PeerInfo field received in
 the Initial Exchange, to detect multiple associations with the same peer. However, it
 <span class="bcp14">MUST NOT</span> delete or merge redundant associations without user or
 application approval because EAP-NOOB internally has no secure way of verifying that
 the two peers are the same physical device. Similarly, the server might lose the
 association state because of a memory failure or user reset. In that case, the only
 way to recover is that the user also resets the peer.<a href="#section-3.1-6" class="pilcrow">¶</a></p>
<p id="section-3.1-7">A special feature of the EAP-NOOB method is that the server is not assumed to have
 any a priori knowledge of the peer. Therefore, the peer initially uses the generic
 identity string "noob@eap-noob.arpa" as its Network Access Identifier (NAI). The
 server then allocates a server-specific identifier to the peer. The generic NAI serves
 two purposes: firstly, it tells the server that the peer supports and expects the
 EAP-NOOB method; secondly, it allows routing of the EAP-NOOB sessions to a
 specific authentication server in an Authentication, Authorization, and Accounting
 (AAA) architecture.<a href="#section-3.1-7" class="pilcrow">¶</a></p>
<p id="section-3.1-8">EAP-NOOB is an unusual EAP method in that the peer has to have multiple EAP
 conversations with the server before it can receive EAP-Success. The reason is that,
 while EAP allows delays between the request-response pairs, e.g., for repeated
 password entry, the user delays in OOB authentication can be much longer than in
 password trials. Moreover, EAP-NOOB supports peers with no input capability in the
 user interface (e.g., LED light bulbs). Since users cannot initiate the protocol in
 these devices, the devices have to perform the Initial Exchange opportunistically and
 hope for the OOB Step to take place within a timeout period (NoobTimeout), which is
 why the timeout needs to be several minutes rather than seconds. To support such
 high-latency OOB channels, the peer and server perform the Initial Exchange in one EAP
 conversation, then allow time for the OOB message to be delivered, and later perform
 the Waiting Exchange and Completion Exchange in different EAP conversations.<a href="#section-3.1-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="protocol">
<section id="section-3.2">
        <h3 id="name-protocol-messages-and-seque">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-protocol-messages-and-seque" class="section-name selfRef">Protocol Messages and Sequences</a>
        </h3>
<p id="section-3.2-1">This section defines the EAP-NOOB exchanges, which correspond to EAP conversations.
 The exchanges start with a common handshake, which determines the type of the
 following exchange. The common handshake messages and the subsequent messages for each
 exchange type are listed in the diagrams below. The diagrams also specify the data
 fields present in each message. Each exchange comprises multiple EAP request-response
 pairs and ends in either EAP-Failure, indicating that authentication is not (yet)
 successful, or in EAP-Success.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<div id="commonhandshake">
<section id="section-3.2.1">
          <h4 id="name-common-handshake-in-all-eap">
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-common-handshake-in-all-eap" class="section-name selfRef">Common Handshake in All EAP-NOOB Exchanges</a>
          </h4>
<p id="section-3.2.1-1">All EAP-NOOB exchanges start with common handshake messages. The handshake begins
   with the identity request and response that are common to all EAP methods. Their
   purpose is to enable the AAA architecture to route the EAP conversation to the EAP
   server and to enable the EAP server to select the EAP method. The handshake then
   continues with one EAP-NOOB request-response pair in which the server discovers the
   peer identifier used in EAP-NOOB and the peer state.<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
<p id="section-3.2.1-2">In more detail, each EAP-NOOB exchange begins with the authenticator sending an
   EAP-Request/Identity packet to the peer. From this point on, the EAP conversation
   occurs between the server and the peer, and the authenticator acts as a pass-through
   device. The peer responds to the authenticator with an EAP-Response/Identity packet,
   which contains the Network Access Identifier (NAI). The authenticator, acting as a
   pass-through device, forwards this response and the following EAP conversation
   between the peer and the AAA architecture. The AAA architecture routes the
   conversation to a specific AAA server (called "EAP server" or simply "server" in
   this specification) based on the realm part of the NAI. The server selects the
   EAP-NOOB method based on the user part of the NAI, as defined in <a href="#nai" class="xref">Section 3.3.1</a>.<a href="#section-3.2.1-2" class="pilcrow">¶</a></p>
<p id="section-3.2.1-3">After receiving the EAP-Response/Identity message, the server sends the first
   EAP-NOOB request (Type=1) to the peer, which responds with the peer identifier
   (PeerId) and state (PeerState) in the range 0..3. However, the peer
   <span class="bcp14">SHOULD</span> omit the PeerId from the response (Type=1) when PeerState=0.
   The server then chooses the EAP-NOOB exchange, i.e., the ensuing message sequence,
   as explained below. The peer recognizes the exchange based on the message type field
   (Type) of the next EAP-NOOB request received from the server.<a href="#section-3.2.1-3" class="pilcrow">¶</a></p>
<p id="section-3.2.1-4">The server <span class="bcp14">MUST</span> determine the exchange type based on the
   combination of the peer and server states as follows (also summarized in <a href="#tab-exchanges" class="xref">Table 14</a>). If either the peer or server is in the
   Unregistered (0) state and the other is in one of the ephemeral states (0..2), the
   server chooses the Initial Exchange. If either the peer or server is in the OOB
   Received (2) state and the other is either in the Waiting for OOB (1) or OOB
   Received (2) state, the OOB Step has taken place and the server chooses the
   Completion Exchange. If both the server and peer are in the Waiting for OOB (1)
   state, the server chooses the Waiting Exchange. If the peer is in the Reconnecting
   (3) state and the server is in the Registered (4) or Reconnecting (3) state, the
   server chooses the Reconnect Exchange. All other state combinations are error
   situations where user action is required, and the server <span class="bcp14">SHOULD</span>
   indicate such errors to the peer with the error code 2002 (see <a href="#statemismatch" class="xref">Section 3.6.3</a>). Note also that the peer <span class="bcp14">MUST NOT</span> initiate EAP-NOOB when the peer is in the Registered (4) state.<a href="#section-3.2.1-4" class="pilcrow">¶</a></p>
<span id="name-common-handshake-in-all-eap-"></span><div id="fig-commonhandshake">
<figure id="figure-2">
            <div class="alignCenter art-text artwork" id="section-3.2.1-5.1">
<pre>
EAP Peer                      Authenticator    EAP Server
  |                                   |              |
  |&lt;----------- EAP-Request/Identity -|              |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/Identity --------------&gt;|
  |      (NAI=noob@eap-noob.arpa)                    |
  |                                                  |
  |                                                  |
  |&lt;----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=1)                                    |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB --------------&gt;|
  |      (Type=1,[PeerId],PeerState=1)               |
  |                                                  |
  |  continuing with exchange-specific messages...   |
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-common-handshake-in-all-eap-" class="selfRef">Common Handshake in All EAP-NOOB Exchanges</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="initialexchange">
<section id="section-3.2.2">
          <h4 id="name-initial-exchange">
<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-initial-exchange" class="section-name selfRef">Initial Exchange</a>
          </h4>
<p id="section-3.2.2-1">The Initial Exchange comprises the common handshake and two further EAP-NOOB
   request-response pairs: one for version, cryptosuite, and parameter negotiation and
   the other for the ECDHE key exchange. The first EAP-NOOB request (Type=2) from the
   server contains a newly allocated PeerId for the peer and an optional NewNAI for
   assigning a new NAI to the peer. The server allocates a new PeerId in the Initial
   Exchange regardless of any old PeerId received in the previous response (Type=1).
   The server also sends in the request a list of the protocol versions (Vers) and
   cryptosuites (Cryptosuites) it supports, an indicator of the OOB channel directions
   it supports (Dirs), and a ServerInfo object. The peer chooses one of the versions
   and cryptosuites. The peer sends a response (Type=2) with the selected protocol
   version (Verp), the received PeerId, the selected cryptosuite (Cryptosuitep), an
   indicator of the OOB channel direction(s) selected by the peer (Dirp), and a
   PeerInfo object. In the second EAP-NOOB request and response (Type=3), the server
   and peer exchange the public components of their ECDHE keys and nonces
   (PKs, Ns, PKp, and Np). The ECDHE keys <span class="bcp14">MUST</span> be based on the
   negotiated
   cryptosuite, i.e., Cryptosuitep. The Initial Exchange always ends with EAP-Failure
   from the server because the authentication cannot yet be completed.<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
<span id="name-initial-exchange-2"></span><div id="fig-initial">
<figure id="figure-3">
            <div class="alignCenter art-text artwork" id="section-3.2.2-2.1">
<pre>
EAP Peer                                        EAP Server
  |       ...continuing from common handshake        |
  |                                                  |
  |&lt;----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=2,Vers,PeerId,[NewNAI],               |
  |       Cryptosuites,Dirs,ServerInfo)              |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB --------------&gt;|
  |      (Type=2,Verp,PeerId,Cryptosuitep,           |
  |        Dirp,PeerInfo)                            |
  |                                                  |
  |                                                  |
  |&lt;----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=3,PeerId,PKs,Ns,[SleepTime])          |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB --------------&gt;|
  |      (Type=3,PeerId,PKp,Np)                      |
  |                                                  |
  |                                                  |
  |&lt;----------- EAP-Failure -------------------------|
  |                                                  |
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-initial-exchange-2" class="selfRef">Initial Exchange</a>
            </figcaption></figure>
</div>
<p id="section-3.2.2-3">At the conclusion of the Initial Exchange, both the server and the peer move to
   the Waiting for OOB (1) state.<a href="#section-3.2.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="oobstep">
<section id="section-3.2.3">
          <h4 id="name-oob-step">
<a href="#section-3.2.3" class="section-number selfRef">3.2.3. </a><a href="#name-oob-step" class="section-name selfRef">OOB Step</a>
          </h4>
<p id="section-3.2.3-1">The OOB Step, labeled as OOB Output and OOB Input in <a href="#fig-statemachine" class="xref">Figure 1</a>, takes place after the Initial
   Exchange. Depending on the negotiated OOB channel direction, the peer or the server
   outputs the OOB message as shown in Figures <a href="#fig-oob1" class="xref">4</a> or
   <a href="#fig-oob2" class="xref">5</a>, respectively. The data fields are the
   PeerId, the secret nonce Noob, and the cryptographic fingerprint Hoob. The contents
   of the data fields are defined in <a href="#messagedatafields" class="xref">Section 3.3.2</a>. The OOB message is delivered to the other endpoint via a
   user-assisted OOB channel.<a href="#section-3.2.3-1" class="pilcrow">¶</a></p>
<p id="section-3.2.3-2">For brevity, we will use the terms OOB sender and OOB receiver in addition to the
   already familiar EAP server and EAP peer. If the OOB message is sent in the
   server-to-peer direction, the OOB sender is the server and the OOB receiver is the
   peer. On the other hand, if the OOB message is sent in the peer-to-server direction,
   the OOB sender is the peer and the OOB receiver is the server.<a href="#section-3.2.3-2" class="pilcrow">¶</a></p>
<span id="name-oob-step-from-peer-to-eap-s"></span><div id="fig-oob1">
<figure id="figure-4">
            <div class="alignCenter art-text artwork" id="section-3.2.3-3.1">
<pre>
EAP Peer                                        EAP Server
  |                                                  |
  |=================OOB=============================&gt;|
  |             (PeerId,Noob,Hoob)                   |
  |                                                  |
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-oob-step-from-peer-to-eap-s" class="selfRef">OOB Step, from Peer to EAP Server</a>
            </figcaption></figure>
</div>
<span id="name-oob-step-from-eap-server-to"></span><div id="fig-oob2">
<figure id="figure-5">
            <div class="alignCenter art-text artwork" id="section-3.2.3-4.1">
<pre>
EAP Peer                                        EAP Server
  |                                                  |
  |&lt;================OOB==============================|
  |             (PeerId,Noob,Hoob)                   |
  |                                                  |
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-oob-step-from-eap-server-to" class="selfRef">OOB Step, from EAP Server to Peer</a>
            </figcaption></figure>
</div>
<p id="section-3.2.3-5">The OOB receiver <span class="bcp14">MUST</span> compare the received value of the
   fingerprint Hoob (see <a href="#messagedatafields" class="xref">Section 3.3.2</a>) with a
   value that it computed locally for the PeerID received. This integrity check ensures
   that the endpoints agree on contents of the Initial Exchange. If the values are
   equal, the receiver moves to the OOB Received (2) state. Otherwise, the receiver
   <span class="bcp14">MUST</span> reject the OOB message. For usability reasons, the OOB receiver
   <span class="bcp14">SHOULD</span> indicate the acceptance or rejection of the OOB message to the
   user. The receiver <span class="bcp14">SHOULD</span> reject invalid OOB messages without
   changing its state in the association state machine until an application-specific
   number of invalid messages (OobRetries) has been reached; after which, the receiver
   <span class="bcp14">SHOULD</span> consider it an error and go back to the Unregistered (0)
   state.<a href="#section-3.2.3-5" class="pilcrow">¶</a></p>
<p id="section-3.2.3-6">The server or peer <span class="bcp14">MAY</span> send multiple OOB messages with different
   Noob values while in the Waiting for OOB (1) state. The OOB sender
   <span class="bcp14">SHOULD</span> remember the Noob values until they expire and accept any one
   of them in the following Completion Exchange. The Noob values sent by the server
   expire after an application-dependent timeout (NoobTimeout), and the server
   <span class="bcp14">MUST NOT</span> accept Noob values older than that in the Completion
   Exchange. The <span class="bcp14">RECOMMENDED</span> value for NoobTimeout is 3600 seconds if
   there are no application-specific reasons for making it shorter or longer. The Noob
   values sent by the peer expire, as defined in <a href="#waitingexchange" class="xref">Section 3.2.5</a>.<a href="#section-3.2.3-6" class="pilcrow">¶</a></p>
<p id="section-3.2.3-7">The OOB receiver does not accept further OOB messages after it has accepted one
   and moved to the OOB Received (2) state. However, the receiver <span class="bcp14">MAY</span>
   buffer redundant OOB messages in case an OOB message expiry or similar error
   detected in the Completion Exchange causes it to return to the Waiting for OOB (1)
   state. It is <span class="bcp14">RECOMMENDED</span> that the OOB receiver notifies the user
   about redundant OOB messages, but it <span class="bcp14">MAY</span> instead discard them
   silently.<a href="#section-3.2.3-7" class="pilcrow">¶</a></p>
<p id="section-3.2.3-8">The sender will typically generate a new Noob, and therefore a new OOB message,
   at constant time intervals (NoobInterval). The <span class="bcp14">RECOMMENDED</span> interval
   is<a href="#section-3.2.3-8" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-3.2.3-9">NoobInterval = NoobTimeout / 2<a href="#section-3.2.3-9" class="pilcrow">¶</a></p>
<p id="section-3.2.3-10">in which case, the receiver of the OOB will at any given time
          accept either of the two latest Noob values. However, the timing of
          the Noob generation may also be based on user interaction or on
          implementation considerations.<a href="#section-3.2.3-10" class="pilcrow">¶</a></p>
<p id="section-3.2.3-11">Even though not recommended (see <a href="#datafields" class="xref">Section 3.3</a>),
   this specification allows both directions to be negotiated (Dirp=3) for the OOB
   channel. In that case, both sides <span class="bcp14">SHOULD</span> output the OOB message, and
   it is up to the user to deliver at least one of them.<a href="#section-3.2.3-11" class="pilcrow">¶</a></p>
<p id="section-3.2.3-12">The details of the OOB channel implementation including the message encoding are
   defined by the application. <a href="#urloob" class="xref">Appendix D</a> gives an
   example of how the OOB message can be encoded as a URL that may be embedded in a
   dynamic QR code or NFC (Near Field Communication) tag.<a href="#section-3.2.3-12" class="pilcrow">¶</a></p>
</section>
</div>
<div id="completionexchange">
<section id="section-3.2.4">
          <h4 id="name-completion-exchange">
<a href="#section-3.2.4" class="section-number selfRef">3.2.4. </a><a href="#name-completion-exchange" class="section-name selfRef">Completion Exchange</a>
          </h4>
<p id="section-3.2.4-1">After the Initial Exchange, if the OOB channel directions selected by the peer
   include the peer-to-server direction, the peer <span class="bcp14">SHOULD</span> initiate the
   EAP-NOOB method again after an applications-specific waiting time in order to probe
   for completion of the OOB Step. If the OOB channel directions selected by the peer
   include the server-to-peer direction and the peer receives the OOB message, it
   <span class="bcp14">SHOULD</span> initiate the EAP-NOOB method immediately. Depending on the
   combination of the peer and server states, the server continues with the Completion
   Exchange or Waiting Exchange (see <a href="#commonhandshake" class="xref">Section 3.2.1</a>
   on how the server makes this decision).<a href="#section-3.2.4-1" class="pilcrow">¶</a></p>
<p id="section-3.2.4-2">The Completion Exchange comprises the common handshake and one or two further
   EAP-NOOB request-response pairs. If the peer is in the Waiting for OOB (1) state,
   the OOB message has been sent in the peer-to-server direction. In that case, only
   one request-response pair (Type=6) takes place. In the request, the server sends the
   NoobId value (see <a href="#messagedatafields" class="xref">Section 3.3.2</a>), which the
   peer uses to identify the exact OOB message received by the server. On the other
   hand, if the peer is in the OOB Received (2) state, the direction of the OOB message
   is from server to peer. In this case, two request-response pairs (Type=5 and Type=6)
   are needed. The purpose of the first request-response pair (Type=5) is that it
   enables the server to discover NoobId, which identifies the exact OOB message
   received by the peer. The server returns the same NoobId to the peer in the latter
   request.<a href="#section-3.2.4-2" class="pilcrow">¶</a></p>
<p id="section-3.2.4-3">In the last request-response pair (Type=6) of the Completion Exchange, the server
   and peer exchange message authentication codes. Both sides <span class="bcp14">MUST</span>
   compute the keys Kms and Kmp, as defined in <a href="#keyderivation" class="xref">Section 3.5</a>, and the message authentication codes MACs and MACp, as defined
   in <a href="#messagedatafields" class="xref">Section 3.3.2</a>. Both sides
   <span class="bcp14">MUST</span>
   compare the received message authentication code with a locally computed value. If
   the peer finds that it has received the correct value of MACs and the server finds
   that it has received the correct value of MACp, the Completion Exchange ends in
   EAP-Success.
   Otherwise, the endpoint where the comparison fails indicates this with
   an error message (error code 4001, see <a href="#cryptofailure" class="xref">Section 3.6.5</a>), and the Completion Exchange ends in EAP-Failure.<a href="#section-3.2.4-3" class="pilcrow">¶</a></p>
<p id="section-3.2.4-4">After the successful Completion Exchange, both the server and the peer move to
   the
   Registered (4) state. They also derive the output keying material and store the
   persistent EAP-NOOB association state, as defined in Sections <a href="#fastreconnect" class="xref">3.4</a> and <a href="#keyderivation" class="xref">3.5</a>.<a href="#section-3.2.4-4" class="pilcrow">¶</a></p>
<p id="section-3.2.4-5">It is possible that the OOB message expires before it is received. In that case,
   the sender of the OOB message no longer recognizes the NoobId that it receives in
   the Completion Exchange. Another reason why the OOB sender might not recognize the
   NoobId is if the received OOB message was spoofed and contained an
   attacker-generated Noob value. The recipient of an unrecognized NoobId indicates
   this with an error message (error code 2003, see <a href="#invalidmessages" class="xref">Section 3.6.1</a>), and the Completion Exchange ends in EAP-Failure. The recipient
   of the error message 2003 moves back to the Waiting for OOB (1) state. This state
   transition is called OOB Reject in <a href="#fig-statemachine" class="xref">Figure 1</a> (even though it really is a specific type of failed Completion
   Exchange). On the other hand, the sender of the error message stays in its
   previous state.<a href="#section-3.2.4-5" class="pilcrow">¶</a></p>
<p id="section-3.2.4-6">Although it is not expected to occur in practice, poor user interface design
   could lead to two OOB messages delivered simultaneously, one from the peer to the
   server and the other from the server to the peer. The server detects this event in
   the beginning of the Completion Exchange by observing that both the server and peer
   are in the OOB Received (2) state. In that case, as a tiebreaker, the server
   <span class="bcp14">MUST</span> behave as if only the server-to-peer message had been
   delivered.<a href="#section-3.2.4-6" class="pilcrow">¶</a></p>
<span id="name-completion-exchange-2"></span><div id="fig-completion">
<figure id="figure-6">
            <div class="alignCenter art-text artwork" id="section-3.2.4-7.1">
<pre>
EAP Peer                                        EAP Server
  |       ...continuing from common handshake        |
  |                                                  |
  |&lt;----------- [ EAP-Request/EAP-NOOB ] ------------|
  |      (Type=5,PeerId)                             |
  |                                                  |
  |                                                  |
  |------------ [ EAP-Response/EAP-NOOB ] ----------&gt;|
  |      (Type=5,PeerId,NoobId)                      |
  |                                                  |
  |                                                  |
  |&lt;----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=6,PeerId,NoobId,MACs)                 |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB --------------&gt;|
  |      (Type=6,PeerId,MACp)                        |
  |                                                  |
  |                                                  |
  |&lt;----------- EAP-Success -------------------------|
  |                                                  |
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-completion-exchange-2" class="selfRef">Completion Exchange</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="waitingexchange">
<section id="section-3.2.5">
          <h4 id="name-waiting-exchange">
<a href="#section-3.2.5" class="section-number selfRef">3.2.5. </a><a href="#name-waiting-exchange" class="section-name selfRef">Waiting Exchange</a>
          </h4>
<p id="section-3.2.5-1">As explained in <a href="#completionexchange" class="xref">Section 3.2.4</a>, the peer
   <span class="bcp14">SHOULD</span> probe the server for completion of the OOB Step. When the
   combination of the peer and server states indicates that the OOB message has not yet
   been delivered, the server chooses the Waiting Exchange (see <a href="#commonhandshake" class="xref">Section 3.2.1</a> on how the server makes this decision).
   The Waiting Exchange comprises the common handshake and one further request-response
   pair, and it always ends in EAP-Failure.<a href="#section-3.2.5-1" class="pilcrow">¶</a></p>
<p id="section-3.2.5-2">In order to limit the rate at which peers probe the server, the server
   <span class="bcp14">MAY</span> send to the peer either in the Initial Exchange or in the Waiting
   Exchange a minimum time to wait before probing the server again. A peer that has not
   received an OOB message <span class="bcp14">SHOULD</span> wait at least the server-specified
   minimum waiting time in seconds (SleepTime) before initiating EAP again with the
   same server. The peer uses the latest SleepTime value that it has received in or
   after the Initial Exchange. If the server has not sent any SleepTime value, the peer
   <span class="bcp14">MUST</span> wait for an application-specified minimum time
   (SleepTimeDefault).<a href="#section-3.2.5-2" class="pilcrow">¶</a></p>
<p id="section-3.2.5-3">After the Waiting Exchange, the peer <span class="bcp14">MUST</span> discard (from its local
   ephemeral storage) Noob values that it has sent to the server in OOB messages that
   are older than the application-defined timeout NoobTimeout (see <a href="#oobstep" class="xref">Section 3.2.3</a>). The peer <span class="bcp14">SHOULD</span> discard such
   expired Noob values even if the probing failed because of, e.g., failure to connect
   to the EAP server or an incorrect message authentication code. The timeout of
   peer-generated Noob values is defined like this in order to allow the peer to probe
   the server once after it has waited for the server-specified SleepTime.<a href="#section-3.2.5-3" class="pilcrow">¶</a></p>
<p id="section-3.2.5-4">If the server and peer have negotiated to use only the server-to-peer direction
   for the OOB channel (Dirp=2), the peer <span class="bcp14">SHOULD</span> nevertheless probe the
   server. The purpose of this is to keep the server informed about the peers that are
   still waiting for OOB messages. The server <span class="bcp14">MAY</span> set SleepTime to a
   high number (e.g., 3600) to prevent the peer from probing the server frequently.<a href="#section-3.2.5-4" class="pilcrow">¶</a></p>
<span id="name-waiting-exchange-2"></span><div id="fig-waiting">
<figure id="figure-7">
            <div class="alignCenter art-text artwork" id="section-3.2.5-5.1">
<pre>
EAP Peer                                        EAP Server
  |       ...continuing from common handshake        |
  |                                                  |
  |&lt;----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=4,PeerId,[SleepTime])                 |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB --------------&gt;|
  |      (Type=4,PeerId)                             |
  |                                                  |
  |                                                  |
  |&lt;----------- EAP-Failure -------------------------|
  |                                                  |
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-waiting-exchange-2" class="selfRef">Waiting Exchange</a>
            </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
<div id="datafields">
<section id="section-3.3">
        <h3 id="name-protocol-data-fields">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-protocol-data-fields" class="section-name selfRef">Protocol Data Fields</a>
        </h3>
<p id="section-3.3-1">This section defines the various identifiers and data fields used in the EAP-NOOB
 method.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<div id="nai">
<section id="section-3.3.1">
          <h4 id="name-peer-identifier-and-nai">
<a href="#section-3.3.1" class="section-number selfRef">3.3.1. </a><a href="#name-peer-identifier-and-nai" class="section-name selfRef">Peer Identifier and NAI</a>
          </h4>
<p id="section-3.3.1-1">The server allocates a new peer identifier (PeerId) for the peer in the Initial
   Exchange. The peer identifier <span class="bcp14">MUST</span> follow the syntax of the
   utf8-username specified in <span>[<a href="#RFC7542" class="xref">RFC7542</a>]</span>. The server
   <span class="bcp14">MUST</span> generate the identifiers in such a way that they do not repeat
   and cannot be guessed by the peer or third parties before the server sends them to
   the peer in the Initial Exchange. One way to generate the identifiers is to choose a
   random 16-byte identifier and to base64url encode it without padding <span>[<a href="#RFC4648" class="xref">RFC4648</a>]</span> into a 22-character ASCII string. Another way to
   generate the identifiers is to choose a random 22-character alphanumeric ASCII
   string. It is <span class="bcp14">RECOMMENDED</span> to not use identifiers longer than this
   because they result in longer OOB messages.<a href="#section-3.3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.3.1-2">The peer uses the allocated PeerId to identify itself to the server in the
   subsequent exchanges. The peer <span class="bcp14">MUST</span> copy the PeerId byte by byte from
   the message where it was allocated, and the server <span class="bcp14">MUST</span> perform a
   byte-by-byte comparison between the received and the previously allocated PeerID.
   The peer sets the PeerId value in response type 1 as follows. As stated in <a href="#commonhandshake" class="xref">Section 3.2.1</a>, when the peer is in the Unregistered
   (0) state, it <span class="bcp14">SHOULD</span> omit the PeerId from response type 1. When the
   peer is in one of the states 1..2, it <span class="bcp14">MUST</span> use the PeerId that the
   server assigned to it in the latest Initial Exchange. When the peer is in one of the
   persistent states 3..4, it <span class="bcp14">MUST</span> use the PeerId from its persistent
   EAP-NOOB association. (The PeerId is written to the association when the peer moves
   to the Registered (4) state after a Completion Exchange.)<a href="#section-3.3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.3.1-3">The default NAI for the peer is "noob@eap-noob.arpa". The peer implementation
   <span class="bcp14">MAY</span> allow the user or application to configure a different NAI, which
   overrides the default NAI. Furthermore, the server <span class="bcp14">MAY</span> assign a new
   NAI to the peer in the Initial Exchange or Reconnect Exchange in the NewNAI field
   of request types 2 and 7 to override any previous NAI value. When the peer is in
   the Unregistered (0) state, or when the peer is in one of the states 1..2 and the
   server did not send a NewNAI in the latest Initial Exchange, the peer
   <span class="bcp14">MUST</span> use the configured NAI or, if it does not exist, the default
   NAI. When the peer is in one of the states 1..2 and the server sent a NewNAI in the
   latest Initial Exchange, the peer <span class="bcp14">MUST</span> use this server-assigned NAI.
   When the peer moves to the Registered (4) state after the Completion Exchange, it
   writes to the persistent EAP-NOOB association the same NAI value that it used in the
   Completion Exchange. When the peer is in the Reconnecting (3) or Registered (4)
   state, it <span class="bcp14">MUST</span> use the NAI from its persistent EAP-NOOB association.
   When the server sends NewNAI in the Reconnect Exchange, the peer writes its value to
   the persistent EAP-NOOB association when it moves from the Reconnecting (3) state to
   the Registered (4) state. All the NAI values <span class="bcp14">MUST</span> follow the syntax
   specified in <span>[<a href="#RFC7542" class="xref">RFC7542</a>]</span>.<a href="#section-3.3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.3.1-4">The purpose of the server-assigned NAI is to enable more flexible routing of the
   EAP sessions over the AAA infrastructure, including roaming scenarios (see <a href="#roaming" class="xref">Appendix C</a>). Moreover, some authenticators or AAA servers
   use the realm part of the assigned NAI to determine peer-specific connection
   parameters, such as isolating the peer to a specific VLAN. On the other hand, the
   user- or application-configured NAI enables registration of new devices while
   roaming. It also enables manufacturers to set up their own AAA servers for
   bootstrapping of new peer devices.<a href="#section-3.3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.3.1-5">The peer's PeerId and server-assigned NAI are ephemeral until a successful
   Completion Exchange takes place. Thereafter, the values become parts of the
   persistent EAP-NOOB association until the user resets the peer and server or
   until a new NAI is assigned in the Reconnect Exchange.<a href="#section-3.3.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="messagedatafields">
<section id="section-3.3.2">
          <h4 id="name-message-data-fields">
<a href="#section-3.3.2" class="section-number selfRef">3.3.2. </a><a href="#name-message-data-fields" class="section-name selfRef">Message Data Fields</a>
          </h4>
<p id="section-3.3.2-1"><a href="#tab-datafields" class="xref">Table 1</a> defines the data fields in the
   protocol messages. The in-band messages are formatted as JSON objects <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span> in UTF-8 encoding. The JSON member names are in
   the left-hand column of the table.<a href="#section-3.3.2-1" class="pilcrow">¶</a></p>
<span id="name-message-data-fields-2"></span><div id="tab-datafields">
<table class="center" id="table-1">
            <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-message-data-fields-2" class="selfRef">Message Data Fields</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Data Field</th>
                <th class="text-left" rowspan="1" colspan="1">Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Vers, Verp</td>
                <td class="text-left" rowspan="1" colspan="1">EAP-NOOB protocol versions supported by the EAP server and
 the protocol version chosen by the peer. Vers is a JSON array of unsigned
 integers, and Verp is an unsigned integer. Example values are "[1]" and "1",
 respectively.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">PeerId</td>
                <td class="text-left" rowspan="1" colspan="1">Peer identifier, as defined in <a href="#nai" class="xref">Section 3.3.1</a>.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">NAI, NewNAI</td>
                <td class="text-left" rowspan="1" colspan="1">Peer NAI and server-assigned new peer NAI, as defined in
 <a href="#nai" class="xref">Section 3.3.1</a>.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Type</td>
                <td class="text-left" rowspan="1" colspan="1">EAP-NOOB message type. The type is an integer in the range
 0..9. EAP-NOOB requests and the corresponding responses share the same type
 value.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">PeerState</td>
                <td class="text-left" rowspan="1" colspan="1">Peer state is an integer in the range 0..4 (see <a href="#fig-statemachine" class="xref">Figure 1</a>). However, only values 0..3 are
 ever sent in the protocol messages.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">PKs, PKp</td>
                <td class="text-left" rowspan="1" colspan="1">The public components of the ECDHE keys of the server and
 peer. PKs and PKp are sent in the JSON Web Key (JWK) format <span>[<a href="#RFC7517" class="xref">RFC7517</a>]</span>. The detailed format of the JWK object is
 defined by the cryptosuite.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Cryptosuites, Cryptosuitep</td>
                <td class="text-left" rowspan="1" colspan="1">The identifiers of cryptosuites supported by the server and
 of the cryptosuite selected by the peer. The server-supported cryptosuites in
 Cryptosuites are formatted as a JSON array of the identifier integers. The
 server <span class="bcp14">MUST</span> send a nonempty array with no repeating elements,
 ordered by decreasing priority. The peer <span class="bcp14">MUST</span> respond with
 exactly one suite in the Cryptosuitep value, formatted as an identifier
 integer. Mandatory-to-implement cryptosuites and the registration procedure
 for new cryptosuites are specified in <a href="#cryptosuites" class="xref">Section 5.1</a>. Example values are "[1]" and "1", respectively.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Dirs, Dirp</td>
                <td class="text-left" rowspan="1" colspan="1">An integer indicating the OOB channel directions supported by
 the server and the directions selected by the peer. The possible values are
 1=peer-to-server, 2=server-to-peer, and 3=both directions.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Dir</td>
                <td class="text-left" rowspan="1" colspan="1">The actual direction of the OOB message (1=peer-to-server,
 2=server-to-peer). This value is not sent over any communication channel, but
 it is included in the computation of the cryptographic fingerprint Hoob.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Ns, Np</td>
                <td class="text-left" rowspan="1" colspan="1">32-byte nonces for the Initial Exchange.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">ServerInfo</td>
                <td class="text-left" rowspan="1" colspan="1">This field contains information about the server to be passed
 from the EAP method to the application layer in the peer. The information is
 specific to the application or to the OOB channel, and it is encoded as a JSON
 object of at most 500 bytes. It could include, for example, the access-network
 name and server name, a Uniform Resource Locator (URL) <span>[<a href="#RFC3986" class="xref">RFC3986</a>]</span>, or some other information that helps the
 user deliver the OOB message to the server through the out-of-band
 channel.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">PeerInfo</td>
                <td class="text-left" rowspan="1" colspan="1">This field contains information about the peer to be passed
 from the EAP method to the application layer in the server. The information is
 specific to the application or to the OOB channel, and it is encoded as a JSON
 object of at most 500 bytes. It could include, for example, the peer brand,
 model, and serial number, which help the user distinguish between devices
 and deliver the OOB message to the correct peer through the out-of-band
 channel.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">SleepTime</td>
                <td class="text-left" rowspan="1" colspan="1">The number of seconds for which the peer <span class="bcp14">MUST NOT</span> start a new execution of the EAP-NOOB method with the
 authenticator, unless the peer receives the OOB message or the sending is
 triggered by an application-specific user action. The server can use this
 field to limit the rate at which peers probe it. SleepTime is an unsigned
 integer in the range 0..3600.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Noob</td>
                <td class="text-left" rowspan="1" colspan="1">16-byte secret nonce sent through the OOB channel and used
 for the session key derivation. The endpoint that received the OOB message
 uses this secret in the Completion Exchange to authenticate the exchanged key
 to the endpoint that sent the OOB message.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Hoob</td>
                <td class="text-left" rowspan="1" colspan="1">16-byte cryptographic fingerprint (i.e., hash value) computed
 from all the parameters exchanged in the Initial Exchange and in the OOB
 message. Receiving this fingerprint over the OOB channel guarantees the
 integrity of the key exchange and parameter negotiation. Hence, it
 authenticates the exchanged key to the endpoint that receives the OOB
 message.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">NoobId</td>
                <td class="text-left" rowspan="1" colspan="1">16-byte identifier for the OOB message, computed with a
 one-way function from the nonce Noob in the message.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MACs, MACp</td>
                <td class="text-left" rowspan="1" colspan="1">Message authentication codes (HMAC) for mutual
 authentication, key confirmation, and integrity check on the exchanged
 information. The input to the HMAC is defined below, and the key for the HMAC
 is defined in <a href="#keyderivation" class="xref">Section 3.5</a>.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Ns2, Np2</td>
                <td class="text-left" rowspan="1" colspan="1">32-byte nonces for the Reconnect Exchange.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">KeyingMode</td>
                <td class="text-left" rowspan="1" colspan="1">Integer indicating the key derivation method. 0 in the
 Completion Exchange, and 1..3 in the Reconnect Exchange.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">PKs2, PKp2</td>
                <td class="text-left" rowspan="1" colspan="1">The public components of the ECDHE keys of the server and
 peer for the Reconnect Exchange. PKp2 and PKs2 are sent in the JSON Web Key
 (JWK) format <span>[<a href="#RFC7517" class="xref">RFC7517</a>]</span>. The detailed format of
 the JWK object is defined by the cryptosuite.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">MACs2, MACp2</td>
                <td class="text-left" rowspan="1" colspan="1">Message authentication codes (HMAC) for mutual
 authentication, key confirmation, and integrity check on the Reconnect
 Exchange. The input to the HMAC is defined below, and the key for the HMAC is
 defined in <a href="#keyderivation" class="xref">Section 3.5</a>.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">ErrorCode</td>
                <td class="text-left" rowspan="1" colspan="1">Integer indicating an error condition. Defined in <a href="#errorcodes" class="xref">Section 5.3</a>.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">ErrorInfo</td>
                <td class="text-left" rowspan="1" colspan="1">Textual error message for logging and debugging purposes. A
 UTF-8 string of at most 500 bytes.</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-3.3.2-3">It is <span class="bcp14">RECOMMENDED</span> for servers to support both OOB channel
   directions (Dirs=3) unless the type of the OOB channel limits them to one direction
   (Dirs=1 or Dirs=2). On the other hand, it is <span class="bcp14">RECOMMENDED</span> that the
   peer selects only one direction (Dirp=1 or Dirp=2) even when both directions
   (Dirp=3) would be technically possible. The reason is that, if value 3 is
   negotiated, the user may be presented with two OOB messages, one for each direction,
   even though only one of them needs to be delivered. This can be confusing to the
   user. Nevertheless, the EAP-NOOB protocol is designed to also cope with the value 3;
   in which case, it uses the first delivered OOB message. In the unlikely case of
   simultaneously delivered OOB messages, the protocol prioritizes the server-to-peer
   direction.<a href="#section-3.3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.3.2-4">The nonces in the in-band messages (Ns, Np, Ns2, Np2) are 32-byte fresh random
   byte strings, and the secret nonce Noob is a 16-byte fresh random byte string. All
   the nonces are generated by the endpoint that sends the message.<a href="#section-3.3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.3.2-5">The fingerprint Hoob and the identifier NoobId are computed with the
   cryptographic hash function H, which is specified in the negotiated cryptosuite and
   truncated to the 16 leftmost bytes of the output. The message authentication codes
   (MACs, MACp, MACs2, MACp2) are computed with the function HMAC, which is the hashed
   message authentication code <span>[<a href="#RFC2104" class="xref">RFC2104</a>]</span> based on the
   cryptographic hash function H and truncated to the 32 leftmost bytes of the
   output.<a href="#section-3.3.2-5" class="pilcrow">¶</a></p>
<p id="section-3.3.2-6">The inputs to the hash function for computing the fingerprint Hoob and to the
   HMAC for computing MACs, MACp, MACs2, and MACp2 are JSON arrays containing a fixed
   number (17) of elements. The array elements <span class="bcp14">MUST</span> be copied to
   the
   array verbatim from the sent and received in-band messages. When the element is a
   JSON object, its members <span class="bcp14">MUST NOT</span> be reordered or reencoded.
   White space <span class="bcp14">MUST NOT</span> be added anywhere in the JSON structure.
   Implementers should check that their JSON library copies the elements as UTF-8
   strings, does not modify them in any way, and does not add white space to
   the HMAC input.<a href="#section-3.3.2-6" class="pilcrow">¶</a></p>
<p id="section-3.3.2-7">The inputs for computing the fingerprint and message authentication codes are the
   following:<a href="#section-3.3.2-7" class="pilcrow">¶</a></p>
<div id="section-3.3.2-8">
<pre class="lang-pseudocode sourcecode">
Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,
Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).

NoobId = H("NoobId",Noob).

MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,
Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).

MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,
Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).

MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo],
Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"")

MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo],
Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"")
</pre><a href="#section-3.3.2-8" class="pilcrow">¶</a>
</div>
<p id="section-3.3.2-9">The inputs denoted with "" above are not present, and the values in brackets
          [] are optional. Both kinds of missing input values are represented by empty strings
   "" in the HMAC input (JSON array). The NAI included in the inputs is the NAI value
   that will be in the persistent EAP-NOOB association if the Completion Exchange or
   Reconnect Exchange succeeds.
   In the Completion Exchange, the NAI is the NewNAI value
   assigned by the server in the preceding Initial Exchange or, if no NewNAI was sent,
   the NAI used by the client in the Initial Exchange. In the Reconnect Exchange,
   the NAI is the NewNAI value assigned by the server in the same Reconnect Exchange
   or, if
   no NewNAI was sent, the unchanged NAI from the persistent EAP-NOOB association. Each
   of the values in brackets for the computation of Macs2 and Macp2 <span class="bcp14">MUST</span>
   be included if it was sent or received in the same Reconnect Exchange; otherwise,
   the value is replaced by an empty string "".<a href="#section-3.3.2-9" class="pilcrow">¶</a></p>
<p id="section-3.3.2-10">The parameter Dir indicates the direction in which the OOB message containing the
   Noob value is being sent (1=peer-to-server, 2=server-to-peer). This field is
   included in the Hoob input to prevent the user from accidentally delivering the OOB
   message back to its originator in the rare cases where both OOB directions have been
   negotiated. The keys (Kms, Kmp, Kms2, and Kmp2) for the HMACs are defined in <a href="#keyderivation" class="xref">Section 3.5</a>.<a href="#section-3.3.2-10" class="pilcrow">¶</a></p>
<p id="section-3.3.2-11">The nonces (Ns, Np, Ns2, Np2, and Noob) and the hash value (NoobId)
   <span class="bcp14">MUST</span> be base64url encoded <span>[<a href="#RFC4648" class="xref">RFC4648</a>]</span>
   when they are used as input to the cryptographic functions H or HMAC. These values
   and the message authentication codes (MACs, MACp, MACs2, and MACp2)
   <span class="bcp14">MUST</span>
   also be base64url encoded when they are sent as JSON strings in the in-band
   messages. The values Noob and Hoob in the OOB channel <span class="bcp14">MAY</span> be
   base64url encoded if that is appropriate for the application and the OOB channel.
   All base64url encoding is done without padding. The base64url-encoded values will
   naturally consume more space than the number of bytes specified above (e.g., a
   22-character
   string for a 16-byte nonce and a 43-character string for a 32-byte nonce or message
   authentication code). In the key derivation in <a href="#keyderivation" class="xref">Section 3.5</a>, on the other hand, the unencoded nonces (raw bytes) are used as
   input to the key derivation function.<a href="#section-3.3.2-11" class="pilcrow">¶</a></p>
<p id="section-3.3.2-12">The ServerInfo and PeerInfo are JSON objects with UTF-8 encoding. The length of
   either encoded object as a byte array <span class="bcp14">MUST NOT</span> exceed 500 bytes. The
   format and semantics of these objects <span class="bcp14">MUST</span> be defined by the
   application that uses the EAP-NOOB method.<a href="#section-3.3.2-12" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="fastreconnect">
<section id="section-3.4">
        <h3 id="name-fast-reconnect-and-rekeying">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-fast-reconnect-and-rekeying" class="section-name selfRef">Fast Reconnect and Rekeying</a>
        </h3>
<p id="section-3.4-1">EAP-NOOB implements fast reconnect (<span>[<a href="#RFC3748" class="xref">RFC3748</a>], <a href="https://www.rfc-editor.org/rfc/rfc3748#section-7.2.1" class="relref">Section 7.2.1</a></span>), which avoids repeated use of the user-assisted OOB channel.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">The rekeying and the Reconnect Exchange may be needed for several reasons. New EAP
 output values Main Session Key (MSK) and Extended Main Session Key (EMSK) may be
 needed because of mobility or timeout of session keys. Software or hardware failure or
 user action may also cause the authenticator, EAP server, or peer to lose its
 nonpersistent state data. The failure would typically be detected by the peer or
 authenticator when session keys are no longer accepted by the other endpoint. Changes
 in the supported cryptosuites in the EAP server or peer may also cause the need for a
 new key exchange. When the EAP server or peer detects any one of these events, it
 <span class="bcp14">MUST</span> change from the Registered (4) state to the Reconnecting (3)
 state. These state
 transitions are labeled Mobility/Timeout/Failure in <a href="#fig-statemachine" class="xref">Figure 1</a>. The EAP-NOOB method will then perform the Reconnect Exchange the
 next time when EAP is triggered.<a href="#section-3.4-2" class="pilcrow">¶</a></p>
<div id="persistentassociation">
<section id="section-3.4.1">
          <h4 id="name-persistent-eap-noob-associa">
<a href="#section-3.4.1" class="section-number selfRef">3.4.1. </a><a href="#name-persistent-eap-noob-associa" class="section-name selfRef">Persistent EAP-NOOB Association</a>
          </h4>
<p id="section-3.4.1-1">To enable rekeying, the EAP server and peer store the session state in persistent
   memory after a successful Completion Exchange. This state data, called "persistent
   EAP-NOOB association", <span class="bcp14">MUST</span> include at least the data fields shown in
   <a href="#tab-persistent" class="xref">Table 2</a>. They are used for identifying and
   authenticating the peer in the Reconnect Exchange. When a persistent EAP-NOOB
   association exists, the EAP server and peer are in the Registered (4) state or
   Reconnecting (3) state, as shown in <a href="#fig-statemachine" class="xref">Figure 1</a>.<a href="#section-3.4.1-1" class="pilcrow">¶</a></p>
<span id="name-persistent-eap-noob-associat"></span><div id="tab-persistent">
<table class="center" id="table-2">
            <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-persistent-eap-noob-associat" class="selfRef">Persistent EAP-NOOB Association</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Data Field</th>
                <th class="text-left" rowspan="1" colspan="1">Value</th>
                <th class="text-left" rowspan="1" colspan="1">Type</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">PeerId</td>
                <td class="text-left" rowspan="1" colspan="1">Peer identifier allocated by server</td>
                <td class="text-left" rowspan="1" colspan="1">UTF-8 string (typically 22 ASCII characters)</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Verp</td>
                <td class="text-left" rowspan="1" colspan="1">Negotiated protocol version</td>
                <td class="text-left" rowspan="1" colspan="1">integer</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Cryptosuitep</td>
                <td class="text-left" rowspan="1" colspan="1">Negotiated cryptosuite</td>
                <td class="text-left" rowspan="1" colspan="1">integer</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">CryptosuitepPrev (at peer only)</td>
                <td class="text-left" rowspan="1" colspan="1">Previous cryptosuite</td>
                <td class="text-left" rowspan="1" colspan="1">integer</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">NAI</td>
                <td class="text-left" rowspan="1" colspan="1">NAI assigned by the server or configured by the user or the
 default NAI "noob@eap-noob.arpa"</td>
                <td class="text-left" rowspan="1" colspan="1">UTF-8 string</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Kz</td>
                <td class="text-left" rowspan="1" colspan="1">Persistent key material</td>
                <td class="text-left" rowspan="1" colspan="1">32 bytes</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">KzPrev (at peer only)</td>
                <td class="text-left" rowspan="1" colspan="1">Previous Kz value</td>
                <td class="text-left" rowspan="1" colspan="1">32 bytes</td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</div>
<div id="reconnectexchange">
<section id="section-3.4.2">
          <h4 id="name-reconnect-exchange">
<a href="#section-3.4.2" class="section-number selfRef">3.4.2. </a><a href="#name-reconnect-exchange" class="section-name selfRef">Reconnect Exchange</a>
          </h4>
<p id="section-3.4.2-1">The server chooses the Reconnect Exchange when both the peer and the server are
   in a persistent state and fast reconnection is needed (see <a href="#commonhandshake" class="xref">Section 3.2.1</a> for details).<a href="#section-3.4.2-1" class="pilcrow">¶</a></p>
<p id="section-3.4.2-2">The Reconnect Exchange comprises the common handshake and three further EAP-NOOB
   request-response pairs: one for cryptosuite and parameter negotiation, another for
   the nonce and ECDHE key exchange, and the last one for exchanging message
   authentication codes. In the first request and response (Type=7), the server and peer
   negotiate a protocol version and cryptosuite in the same way as in the Initial
   Exchange. The server <span class="bcp14">SHOULD NOT</span> offer and the peer <span class="bcp14">MUST NOT</span> accept protocol versions or cryptosuites that it knows to be weaker than
   the one currently in the Cryptosuitep field of the persistent EAP-NOOB association.
   The server <span class="bcp14">SHOULD NOT</span> needlessly change the cryptosuites it offers to
   the same peer because peer devices may have limited ability to update their
   persistent storage. However, if the peer has different values in the Cryptosuitep
   and CryptosuitepPrev fields, it <span class="bcp14">SHOULD</span> also accept offers that are
   not weaker than CryptosuitepPrev. Note that Cryptosuitep and CryptosuitePrev from
   the persistent EAP-NOOB association are only used to support the negotiation as
   described above; all actual cryptographic operations use the newly negotiated
   cryptosuite. The request and response (Type=7) <span class="bcp14">MAY</span> additionally
   contain PeerInfo and ServerInfo objects.<a href="#section-3.4.2-2" class="pilcrow">¶</a></p>
<p id="section-3.4.2-3">The server then determines the KeyingMode (defined in <a href="#keyderivation" class="xref">Section 3.5</a>) based on changes in the negotiated
   cryptosuite and whether it desires to achieve forward secrecy or not. The server
   <span class="bcp14">SHOULD</span> only select KeyingMode 3 when the negotiated cryptosuite
   differs from the Cryptosuitep in the server's persistent EAP-NOOB association,
   although it is technically possible to select this value without changing the
   cryptosuite. In the second request and response (Type=8), the server informs the
   peer about the KeyingMode and the server and peer exchange nonces (Ns2, Np2). When
   KeyingMode is 2 or 3 (rekeying with ECDHE), they also exchange public components of
   ECDHE keys (PKs2, PKp2). The server ECDHE key <span class="bcp14">MUST</span> be fresh, i.e.,
   not previously used with the same peer, and the peer ECDHE key <span class="bcp14">SHOULD</span>
   be fresh, i.e., not previously used.<a href="#section-3.4.2-3" class="pilcrow">¶</a></p>
<p id="section-3.4.2-4">In the third and final request and response (Type=9), the server and peer
   exchange message authentication codes. Both sides <span class="bcp14">MUST</span> compute the
   keys Kms2 and Kmp2, as defined in <a href="#keyderivation" class="xref">Section 3.5</a>,
   and the message authentication codes MACs2 and MACp2, as defined in <a href="#messagedatafields" class="xref">Section 3.3.2</a>. Both sides <span class="bcp14">MUST</span>
   compare the received message authentication code with a locally computed value.<a href="#section-3.4.2-4" class="pilcrow">¶</a></p>
<p id="section-3.4.2-5">The rules by which the peer compares the received MACs2 are nontrivial because,
   in addition to authenticating the current exchange, MACs2 may confirm the success or
   failure of a recent cryptosuite upgrade. The peer processes the final request
   (Type=9) as follows:<a href="#section-3.4.2-5" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.4.2-6">
     <li id="section-3.4.2-6.1">The peer first compares the received MACs2 value with one it computed using
     the Kz stored in the persistent EAP-NOOB association. If the received and computed
     values match, the peer deletes any data stored in the CryptosuitepPrev and KzPrev
     fields of the persistent EAP-NOOB association. It does this because the received
     MACs2 confirms that the peer and server share the same Cryptosuitep and Kz, and
     any previous values must no longer be accepted.<a href="#section-3.4.2-6.1" class="pilcrow">¶</a>
</li>
            <li id="section-3.4.2-6.2">On the other hand, if the peer finds that the received MACs2 value does not
     match the one it computed locally with Kz, the peer checks whether the KzPrev
     field in the persistent EAP-NOOB association stores a key. If it does, the peer
     repeats the key derivation (<a href="#keyderivation" class="xref">Section 3.5</a>) and
     local MACs2 computation (<a href="#messagedatafields" class="xref">Section 3.3.2</a>)
     using KzPrev in place of Kz. If this second computed MACs2 matches the received
     value, the match indicates synchronization failure caused by the loss of the last
     response (Type=9) in a previously attempted cryptosuite upgrade. In this case, the
     peer rolls back that upgrade by overwriting Cryptosuitep with CryptosuitepPrev and
     Kz with KzPrev in the persistent EAP-NOOB association. It also clears the
     CryptosuitepPrev and KzPrev fields.<a href="#section-3.4.2-6.2" class="pilcrow">¶</a>
</li>
            <li id="section-3.4.2-6.3">If the received MACs2 matched one of the locally computed values, the peer
     proceeds to send the final response (Type=9). The peer also moves to the
     Registered (4) state. When KeyingMode is 1 or 2, the peer stops here. When
     KeyingMode is 3, the peer also updates the persistent EAP-NOOB association with
     the negotiated Cryptosuitep and the newly derived Kz value. To prepare for
     possible synchronization failure caused by the loss of the final response (Type=9)
     during cryptosuite upgrade, the peer copies the old Cryptosuitep and Kz values in
     the persistent EAP-NOOB association to the CryptosuitepPrev and KzPrev fields.<a href="#section-3.4.2-6.3" class="pilcrow">¶</a>
</li>
            <li id="section-3.4.2-6.4">Finally, if the peer finds that the received MACs2 does not match either of
     the two values that it computed locally (or one value if no KzPrev was stored),
     the peer sends an error message (error code 4001, see <a href="#cryptofailure" class="xref">Section 3.6.5</a>), which causes the Reconnect Exchange
     to end in EAP-Failure.<a href="#section-3.4.2-6.4" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-3.4.2-7">The server rules for processing the final message are simpler than the peer rules
   because the server does not store previous keys and it never rolls back a
   cryptosuite upgrade. Upon receiving the final response (Type=9), the server compares
   the received value of MACp2 with one it computes locally. If the values match, the
   Reconnect Exchange ends in EAP-Success. When KeyingMode is 3, the server also
   updates Cryptosuitep and Kz in the persistent EAP-NOOB association. On the other
   hand, if the server finds that the values do not match, it sends an error message
   (error code 4001), and the Reconnect Exchange ends in EAP-Failure.<a href="#section-3.4.2-7" class="pilcrow">¶</a></p>
<p id="section-3.4.2-8">The endpoints <span class="bcp14">MAY</span> send updated NewNAI, ServerInfo, and PeerInfo
   objects in the Reconnect Exchange. When there is no update to the values, they
   <span class="bcp14">SHOULD</span> omit this information from the messages. If the NewNAI was
   sent, each side updates NAI in the persistent EAP-NOOB association when moving to
   the Registered (4) state.<a href="#section-3.4.2-8" class="pilcrow">¶</a></p>
<span id="name-reconnect-exchange-2"></span><div id="fig-reconnect">
<figure id="figure-8">
            <div class="alignCenter art-text artwork" id="section-3.4.2-9.1">
<pre>
EAP Peer                                        EAP Server
  |       ...continuing from common handshake        |
  |                                                  |
  |&lt;----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=7,Vers,PeerId,Cryptosuites,           |
  |       [NewNAI],[ServerInfo])                     |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB --------------&gt;|
  |      (Type=7,Verp,PeerId,Cryptosuitep,[PeerInfo])|
  |                                                  |
  |                                                  |
  |&lt;----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=8,PeerId,KeyingMode,[PKs2],Ns2)       |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB --------------&gt;|
  |      (Type=8,PeerId,[PKp2],Np2)                  |
  |                                                  |
  |                                                  |
  |&lt;----------- EAP-Request/EAP-NOOB ----------------|
  |      (Type=9,PeerId,MACs2)                       |
  |                                                  |
  |                                                  |
  |------------ EAP-Response/EAP-NOOB --------------&gt;|
  |      (Type=9,PeerId,MACp2)                       |
  |                                                  |
  |                                                  |
  |&lt;----------- EAP-Success -------------------------|
  |                                                  |
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-reconnect-exchange-2" class="selfRef">Reconnect Exchange</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="userreset">
<section id="section-3.4.3">
          <h4 id="name-user-reset">
<a href="#section-3.4.3" class="section-number selfRef">3.4.3. </a><a href="#name-user-reset" class="section-name selfRef">User Reset</a>
          </h4>
<p id="section-3.4.3-1">As shown in the association state machine in <a href="#fig-statemachine" class="xref">Figure 1</a>, the only specified way for the association to return from the
   Registered (4) state to the Unregistered (0) state is through user-initiated reset.
   After the reset, a new OOB message will be needed to establish a new association
   between the EAP server and peer. Typical situations in which the user reset is
   required are when the other side has accidentally lost the persistent EAP-NOOB
   association data or when the peer device is decommissioned.<a href="#section-3.4.3-1" class="pilcrow">¶</a></p>
<p id="section-3.4.3-2">The server could detect that the peer is in the Registered or Reconnecting state,
   but the server itself is in one of the ephemeral states 0..2 (including situations
   where the server does not recognize the PeerId). In this case, effort should be made
   to recover the persistent server state, for example, from a backup storage --
   especially if many peer devices are similarly affected. If that is not possible, the
   EAP server <span class="bcp14">SHOULD</span> log the error or notify an administrator. The only
   way to continue from such a situation is by having the user reset the peer
   device.<a href="#section-3.4.3-2" class="pilcrow">¶</a></p>
<p id="section-3.4.3-3">On the other hand, if the peer is in any of the ephemeral states 0..2, including
   the Unregistered state, the server will treat the peer as a new peer device and
   allocate a new PeerId to it. The PeerInfo can be used by the user as a clue to which
   physical device has lost its state. However, there is no secure way of matching the
   "new" peer with the old PeerId without repeating the OOB Step. This situation will
   be resolved when the user performs the OOB Step and thus identifies the physical
   peer device. The server user interface <span class="bcp14">MAY</span> support situations where
   the "new" peer is actually a previously registered peer that has been reset by a
   user or otherwise lost its persistent data. In those cases, the user could choose to
   merge the new peer identity with the old one in the server. The alternative is to
   treat the device just like a new peer.<a href="#section-3.4.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="keyderivation">
<section id="section-3.5">
        <h3 id="name-key-derivation">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-key-derivation" class="section-name selfRef">Key Derivation</a>
        </h3>
<p id="section-3.5-1">EAP-NOOB derives the EAP output values MSK and EMSK and other secret keying
 material from the output of an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE)
 algorithm following the NIST specification <span>[<a href="#NIST-DH" class="xref">NIST-DH</a>]</span>.
 In NIST terminology, we use a C(2e, 0s, ECC CDH) scheme, i.e., two ephemeral keys and
 no static keys. In the Initial Exchange and Reconnect Exchange, the server and peer
 compute the ECDHE shared secret Z, as defined in Section 6.1.2 of the NIST specification <span>[<a href="#NIST-DH" class="xref">NIST-DH</a>]</span>. In the Completion
 Exchange and
 Reconnect Exchange, the server and peer compute the secret keying material from Z
 with the one-step key derivation function (KDF) defined in Section 5.8.2.1 of the NIST
 specification. The auxiliary function H is a hash function, and it is taken from the
 negotiated cryptosuite.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<span id="name-keying-modes"></span><div id="keyingmodes">
<table class="center" id="table-3">
          <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-keying-modes" class="selfRef">Keying Modes</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">KeyingMode</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">Completion Exchange (always with ECDHE)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">Reconnect Exchange, rekeying without ECDHE</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">Reconnect Exchange, rekeying with ECHDE, no change in
       cryptosuite</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">3</td>
              <td class="text-left" rowspan="1" colspan="1">Reconnect Exchange, rekeying with ECDHE, new cryptosuite
       negotiated</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-3.5-3">The key derivation has four different modes (KeyingMode), which are specified in
 <a href="#keyingmodes" class="xref">Table 3</a>. <a href="#tab-keyderivationinput" class="xref">Table 4</a> defines the inputs to KDF in each KeyingMode.<a href="#section-3.5-3" class="pilcrow">¶</a></p>
<p id="section-3.5-4">In the Completion Exchange (KeyingMode=0), the input Z comes from the preceding
 Initial exchange. The KDF takes some additional inputs (FixedInfo), for which we use
 the
 concatenation format defined in Section
 5.8.2.1.1 of the NIST specification <span>[<a href="#NIST-DH" class="xref">NIST-DH</a>]</span>. FixedInfo consists of the AlgorithmId,
 PartyUInfo, PartyVInfo, and SuppPrivInfo fields. The first three fields are
 fixed-length bit strings, and SuppPrivInfo is a variable-length string with a one-byte
 Datalength counter. AlgorithmId is the fixed-length, 8-byte ASCII string "EAP-NOOB".
 The other input values are the server and peer nonces. In the Completion Exchange, the
 inputs also include the secret nonce Noob from the OOB message.<a href="#section-3.5-4" class="pilcrow">¶</a></p>
<p id="section-3.5-5">In the simplest form of the Reconnect Exchange (KeyingMode=1), fresh nonces are
 exchanged, but no ECDHE keys are sent. In this case, input Z to the KDF is replaced
 with the shared key Kz from the persistent EAP-NOOB association. The result is
 rekeying without the computational cost of the ECDHE exchange but also without
 forward secrecy.<a href="#section-3.5-5" class="pilcrow">¶</a></p>
<p id="section-3.5-6">When forward secrecy is desired in the Reconnect Exchange (KeyingMode=2 or
 KeyingMode=3), both nonces and ECDHE keys are exchanged. Input Z is the fresh shared
 secret from the ECDHE exchange with PKs2 and PKp2. The inputs also include the shared
 secret Kz from the persistent EAP-NOOB association. This binds the rekeying output to
 the previously authenticated keys.<a href="#section-3.5-6" class="pilcrow">¶</a></p>
<span id="name-key-derivation-input"></span><div id="tab-keyderivationinput">
<table class="center" id="table-4">
          <caption>
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-key-derivation-input" class="selfRef">Key Derivation Input</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">KeyingMode</th>
              <th class="text-left" rowspan="1" colspan="1">KDF input field</th>
              <th class="text-left" rowspan="1" colspan="1">Value</th>
              <th class="text-left" rowspan="1" colspan="1">Length (bytes)</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="6" colspan="1">0 Completion</td>
              <td class="text-left" rowspan="1" colspan="1">Z</td>
              <td class="text-left" rowspan="1" colspan="1">ECDHE shared secret from PKs and PKp</td>
              <td class="text-left" rowspan="1" colspan="1">variable</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">AlgorithmId</td>
              <td class="text-left" rowspan="1" colspan="1">"EAP-NOOB"</td>
              <td class="text-left" rowspan="1" colspan="1">8</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PartyUInfo</td>
              <td class="text-left" rowspan="1" colspan="1">Np</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PartyVInfo</td>
              <td class="text-left" rowspan="1" colspan="1">Ns</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">SuppPubInfo</td>
              <td class="text-left" rowspan="1" colspan="1">(not allowed)</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">SuppPrivInfo</td>
              <td class="text-left" rowspan="1" colspan="1">Noob</td>
              <td class="text-left" rowspan="1" colspan="1">16</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="6" colspan="1">1 Reconnect, rekeying without ECDHE</td>
              <td class="text-left" rowspan="1" colspan="1">Z</td>
              <td class="text-left" rowspan="1" colspan="1">Kz</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">AlgorithmId</td>
              <td class="text-left" rowspan="1" colspan="1">"EAP-NOOB"</td>
              <td class="text-left" rowspan="1" colspan="1">8</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PartyUInfo</td>
              <td class="text-left" rowspan="1" colspan="1">Np2</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PartyVInfo</td>
              <td class="text-left" rowspan="1" colspan="1">Ns2</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">SuppPubInfo</td>
              <td class="text-left" rowspan="1" colspan="1">(not allowed)</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">SuppPrivInfo</td>
              <td class="text-left" rowspan="1" colspan="1">(null)</td>
              <td class="text-left" rowspan="1" colspan="1">0</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="6" colspan="1">2 or 3 Reconnect, rekeying, with ECDHE, same or new cryptosuite</td>
              <td class="text-left" rowspan="1" colspan="1">Z</td>
              <td class="text-left" rowspan="1" colspan="1">ECDHE shared secret from PKs2 and PKp2</td>
              <td class="text-left" rowspan="1" colspan="1">variable</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">AlgorithmId</td>
              <td class="text-left" rowspan="1" colspan="1">"EAP-NOOB"</td>
              <td class="text-left" rowspan="1" colspan="1">8</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PartyUInfo</td>
              <td class="text-left" rowspan="1" colspan="1">Np2</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PartyVInfo</td>
              <td class="text-left" rowspan="1" colspan="1">Ns2</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">SuppPubInfo</td>
              <td class="text-left" rowspan="1" colspan="1">(not allowed)</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">SuppPrivInfo</td>
              <td class="text-left" rowspan="1" colspan="1">Kz</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-3.5-8"><a href="#tab-keyderivationoutput" class="xref">Table 5</a> defines how the output
 bytes of the KDF are used. In addition to the EAP output values MSK and EMSK, the
 server and peer derive another shared secret key AMSK (Application Main Session Key),
 which <span class="bcp14">MAY</span> be used for
 application-layer security. Further output bytes are used internally by EAP-NOOB for
 the message authentication keys (Kms, Kmp, Kms2, and Kmp2).<a href="#section-3.5-8" class="pilcrow">¶</a></p>
<p id="section-3.5-9">The Completion Exchange (KeyingMode=0) produces the shared secret Kz, which the
 server and peer store in the persistent EAP-NOOB association. When a new cryptosuite
 is negotiated in the Reconnect Exchange (KeyingMode=3), it similarly produces a new
 Kz. In that case, the server and peer update both the cryptosuite and Kz in the
 persistent EAP-NOOB association. Additionally, the peer stores the previous
 Cryptosuitep and Kz values in the CryptosuitepPrev and KzPrev fields of the persistent
 EAP-NOOB association.<a href="#section-3.5-9" class="pilcrow">¶</a></p>
<span id="name-key-derivation-output"></span><div id="tab-keyderivationoutput">
<table class="center" id="table-5">
          <caption>
<a href="#table-5" class="selfRef">Table 5</a>:
<a href="#name-key-derivation-output" class="selfRef">Key Derivation Output</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">KeyingMode</th>
              <th class="text-left" rowspan="1" colspan="1">KDF output bytes</th>
              <th class="text-left" rowspan="1" colspan="1">Used as</th>
              <th class="text-left" rowspan="1" colspan="1">Length (bytes)</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="7" colspan="1">0 Completion</td>
              <td class="text-left" rowspan="1" colspan="1">0..63</td>
              <td class="text-left" rowspan="1" colspan="1">MSK</td>
              <td class="text-left" rowspan="1" colspan="1">64</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">64..127</td>
              <td class="text-left" rowspan="1" colspan="1">EMSK</td>
              <td class="text-left" rowspan="1" colspan="1">64</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">128..191</td>
              <td class="text-left" rowspan="1" colspan="1">AMSK</td>
              <td class="text-left" rowspan="1" colspan="1">64</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">192..223</td>
              <td class="text-left" rowspan="1" colspan="1">MethodId</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">224..255</td>
              <td class="text-left" rowspan="1" colspan="1">Kms</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">256..287</td>
              <td class="text-left" rowspan="1" colspan="1">Kmp</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">288..319</td>
              <td class="text-left" rowspan="1" colspan="1">Kz</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="6" colspan="1">1 or 2 Reconnect, rekeying without ECDHE, or with ECDHE and unchanged cryptosuite</td>
              <td class="text-left" rowspan="1" colspan="1">0..63</td>
              <td class="text-left" rowspan="1" colspan="1">MSK</td>
              <td class="text-left" rowspan="1" colspan="1">64</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">64..127</td>
              <td class="text-left" rowspan="1" colspan="1">EMSK</td>
              <td class="text-left" rowspan="1" colspan="1">64</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">128..191</td>
              <td class="text-left" rowspan="1" colspan="1">AMSK</td>
              <td class="text-left" rowspan="1" colspan="1">64</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">192..223</td>
              <td class="text-left" rowspan="1" colspan="1">MethodId</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">224..255</td>
              <td class="text-left" rowspan="1" colspan="1">Kms2</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">256..287</td>
              <td class="text-left" rowspan="1" colspan="1">Kmp2</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="7" colspan="1">3 Reconnect, rekeying with ECDHE, new cryptosuite</td>
              <td class="text-left" rowspan="1" colspan="1">0..63</td>
              <td class="text-left" rowspan="1" colspan="1">MSK</td>
              <td class="text-left" rowspan="1" colspan="1">64</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">64..127</td>
              <td class="text-left" rowspan="1" colspan="1">EMSK</td>
              <td class="text-left" rowspan="1" colspan="1">64</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">128..191</td>
              <td class="text-left" rowspan="1" colspan="1">AMSK</td>
              <td class="text-left" rowspan="1" colspan="1">64</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">192..223</td>
              <td class="text-left" rowspan="1" colspan="1">MethodId</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">224..255</td>
              <td class="text-left" rowspan="1" colspan="1">Kms2</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">256..287</td>
              <td class="text-left" rowspan="1" colspan="1">Kmp2</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">288..319</td>
              <td class="text-left" rowspan="1" colspan="1">Kz</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-3.5-11">Finally, every EAP method must export a Server-Id, Peer-Id, and Session-Id <span>[<a href="#RFC5247" class="xref">RFC5247</a>]</span>. In EAP-NOOB, the exported Peer-Id is the PeerId
 that the server has assigned to the peer. The exported Server-Id is a zero-length
 string (i.e., null string) because EAP-NOOB neither knows nor assigns any server
 identifier.  
The exported Session-Id is created by concatenating the one-byte Type-Code 0x38 (decimal value 56) with the
MethodId, which is obtained from the KDF output, as shown in <a href="#tab-keyderivationoutput" class="xref">Table 5</a>.<a href="#section-3.5-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="failure">
<section id="section-3.6">
        <h3 id="name-error-handling">
<a href="#section-3.6" class="section-number selfRef">3.6. </a><a href="#name-error-handling" class="section-name selfRef">Error Handling</a>
        </h3>
<p id="section-3.6-1">Various error conditions in EAP-NOOB are handled by sending an error notification
 message (Type=0) instead of a next EAP request or response message. Both the EAP
 server and the peer may send the error notification, as shown in Figures <a href="#fig-servererror" class="xref">9</a> and <a href="#fig-peererror" class="xref">10</a>. After sending or receiving an error notification, the server
 <span class="bcp14">MUST</span> send an EAP-Failure (as required by <span>[<a href="#RFC3748" class="xref">RFC3748</a>], <a href="https://www.rfc-editor.org/rfc/rfc3748#section-4.2" class="relref">Section 4.2</a></span>). The notification <span class="bcp14">MAY</span> contain an
 ErrorInfo field, which is a UTF-8-encoded text string with a maximum length of 500
 bytes. It is used for sending descriptive information about the error for logging and
 debugging purposes.<a href="#section-3.6-1" class="pilcrow">¶</a></p>
<span id="name-error-notification-from-ser"></span><div id="fig-servererror">
<figure id="figure-9">
          <div class="alignCenter art-text artwork" id="section-3.6-2.1">
<pre>
EAP Peer                                        EAP Server
  ...                                                ...
  |                                                  |
  |&lt;----------- EAP-Request/EAP-NOOB ----------------|
  |        (Type=0,[PeerId],ErrorCode,[ErrorInfo])   |
  |                                                  |
  |                                                  |
  |&lt;----------- EAP-Failure -------------------------|
  |                                                  |
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-error-notification-from-ser" class="selfRef">Error Notification from Server to Peer</a>
          </figcaption></figure>
</div>
<span id="name-error-notification-from-pee"></span><div id="fig-peererror">
<figure id="figure-10">
          <div class="alignCenter art-text artwork" id="section-3.6-3.1">
<pre>
EAP Peer                                        EAP Server
  ...                                                ...
  |                                                  |
  |------------ EAP-Response/EAP-NOOB --------------&gt;|
  |        (Type=0,[PeerId],ErrorCode,[ErrorInfo])   |
  |                                                  |
  |                                                  |
  |&lt;----------- EAP-Failure -------------------------|
  |                                                  |
</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-error-notification-from-pee" class="selfRef">Error Notification from Peer to Server</a>
          </figcaption></figure>
</div>
<p id="section-3.6-4">After the exchange fails due to an error notification, the server and peer set the
 association state as follows. In the Initial Exchange, both the sender and recipient
 of the error notification <span class="bcp14">MUST</span> set the association state to the
 Unregistered (0) state. In the Waiting Exchange and Completion Exchange, each side
 <span class="bcp14">MUST</span> remain in its old state as if the failed exchange had not taken
 place, with the exception that the recipient of error code 2003 processes it as
 specified in <a href="#completionexchange" class="xref">Section 3.2.4</a>. In the Reconnect
 Exchange, both sides <span class="bcp14">MUST</span> set the association state to the Reconnecting
 (3) state.<a href="#section-3.6-4" class="pilcrow">¶</a></p>
<p id="section-3.6-5">Errors that occur in the OOB channel are not explicitly notified in-band.<a href="#section-3.6-5" class="pilcrow">¶</a></p>
<div id="invalidmessages">
<section id="section-3.6.1">
          <h4 id="name-invalid-messages">
<a href="#section-3.6.1" class="section-number selfRef">3.6.1. </a><a href="#name-invalid-messages" class="section-name selfRef">Invalid Messages</a>
          </h4>
<p id="section-3.6.1-1">If the NAI structure is invalid, the server <span class="bcp14">SHOULD</span> send the error
   code 1001 to the peer. The recipient of an EAP-NOOB request or response
   <span class="bcp14">SHOULD</span> send the following error codes back to the sender: 1002 if it
   cannot parse the message as a JSON object or the top-level JSON object has missing
   or unrecognized members; 1003 if a data field has an invalid value, such as an
   integer out of range, and there is no more specific error code available; 1004 if
   the received message type was unexpected in the current state; 2004 if the PeerId
   has an unexpected value; 2003 if the NoobId is not recognized; and 1005 if the ECDHE
   key is invalid.<a href="#section-3.6.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="unwantedpeer">
<section id="section-3.6.2">
          <h4 id="name-unwanted-peer">
<a href="#section-3.6.2" class="section-number selfRef">3.6.2. </a><a href="#name-unwanted-peer" class="section-name selfRef">Unwanted Peer</a>
          </h4>
<p id="section-3.6.2-1">The preferred way for the EAP server to rate limit EAP-NOOB connections from a
   peer is to use the SleepTime parameter in the Waiting Exchange. However, if the EAP
   server receives repeated EAP-NOOB connections from a peer that apparently should
   not connect to this server, the server <span class="bcp14">MAY</span> indicate that the
   connections are unwanted by sending the error code 2001. After receiving this error
   message, the peer <span class="bcp14">MAY</span> refrain from reconnecting to the same EAP
   server, and, if possible, both the EAP server and peer <span class="bcp14">SHOULD</span>
   indicate
   this error condition to the user or server administrator. However, in order to avoid
   persistent denial of service, peer devices that are unable to alert a user
   <span class="bcp14">SHOULD</span> continue to try to reconnect infrequently (e.g., approximately
   every 3600 seconds).<a href="#section-3.6.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="statemismatch">
<section id="section-3.6.3">
          <h4 id="name-state-mismatch">
<a href="#section-3.6.3" class="section-number selfRef">3.6.3. </a><a href="#name-state-mismatch" class="section-name selfRef">State Mismatch</a>
          </h4>
<p id="section-3.6.3-1">In the states indicated by "-" in <a href="#tab-exchanges" class="xref">Table 14</a>
   in <a href="#exchangeappendix" class="xref">Appendix A</a>, user action is required to
   reset the association state or to recover it, for example, from backup storage. In
   those cases, the server sends the error code 2002 to the peer. If possible, both the
   EAP server and peer <span class="bcp14">SHOULD</span> indicate this error condition to the user
   or server administrator.<a href="#section-3.6.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="negotiationfailure">
<section id="section-3.6.4">
          <h4 id="name-negotiation-failure">
<a href="#section-3.6.4" class="section-number selfRef">3.6.4. </a><a href="#name-negotiation-failure" class="section-name selfRef">Negotiation Failure</a>
          </h4>
<p id="section-3.6.4-1">If there is no matching protocol version, the peer sends the error code 3001 to
   the server. If there is no matching cryptosuite, the peer sends the error code 3002
   to the server. If there is no matching OOB direction, the peer sends the error code
   3003 to the server.<a href="#section-3.6.4-1" class="pilcrow">¶</a></p>
<p id="section-3.6.4-2">In practice, there is no way of recovering from these errors without software or
   hardware changes. If possible, both the EAP server and peer <span class="bcp14">SHOULD</span>
   indicate these error conditions to the user.<a href="#section-3.6.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cryptofailure">
<section id="section-3.6.5">
          <h4 id="name-cryptographic-verification-">
<a href="#section-3.6.5" class="section-number selfRef">3.6.5. </a><a href="#name-cryptographic-verification-" class="section-name selfRef">Cryptographic Verification Failure</a>
          </h4>
<p id="section-3.6.5-1">If the receiver of the OOB message detects an unrecognized PeerId or incorrect
   fingerprint (Hoob) in the OOB message, the receiver <span class="bcp14">MUST</span> remain in
   the Waiting for OOB (1) state as if no OOB message was received. The receiver
   <span class="bcp14">SHOULD</span> indicate the failure to accept the OOB message to the user. No
   in-band error message is sent.<a href="#section-3.6.5-1" class="pilcrow">¶</a></p>
<p id="section-3.6.5-2">Note that if the OOB message was delivered from the server to the peer and the
   peer does not recognize the PeerId, the likely cause is that the user has
   unintentionally delivered the OOB message to the wrong peer device. If possible, the
   peer <span class="bcp14">SHOULD</span> indicate this to the user; however, the peer device may
   not have the capability for many different error indications to the user, and it
   <span class="bcp14">MAY</span> use the same indication as in the case of an incorrect
   fingerprint.<a href="#section-3.6.5-2" class="pilcrow">¶</a></p>
<p id="section-3.6.5-3">The rationale for the above is that the invalid OOB message could have been
   presented to the receiver by mistake or intentionally by a malicious party;
   thus, it should be ignored in the hope that the honest user will soon deliver a
   correct OOB message.<a href="#section-3.6.5-3" class="pilcrow">¶</a></p>
<p id="section-3.6.5-4">If the EAP server or peer detects an incorrect message authentication code (MACs,
   MACp, MACs2, or MACp2), it sends the error code 4001 to the other side. As
   specified in
   the beginning of <a href="#failure" class="xref">Section 3.6</a>, the failed Completion
   Exchange will not result in server or peer state changes, while an error in the
   Reconnect Exchange will put both sides to the Reconnecting (3) state and thus lead
   to another reconnect attempt.<a href="#section-3.6.5-4" class="pilcrow">¶</a></p>
<p id="section-3.6.5-5">The rationale for this is that the invalid cryptographic message may have been
   spoofed by a malicious party; thus, it should be ignored. In particular, a
   spoofed message on the in-band channel should not force the honest user to perform
   the OOB Step again. In practice, however, the error may be caused by other failures,
   such as a software bug. For this reason, the EAP server <span class="bcp14">MAY</span> limit the
   rate of peer connections with SleepTime after the above error. Also, there
   <span class="bcp14">SHOULD</span> be a way for the user to reset the peer to the Unregistered
   (0) state so that the OOB Step can be repeated as the last resort.<a href="#section-3.6.5-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="appfailure">
<section id="section-3.6.6">
          <h4 id="name-application-specific-failur">
<a href="#section-3.6.6" class="section-number selfRef">3.6.6. </a><a href="#name-application-specific-failur" class="section-name selfRef">Application-Specific Failure</a>
          </h4>
<p id="section-3.6.6-1">Applications <span class="bcp14">MAY</span> define new error messages for failures that are
   specific to the application or to one type of OOB channel. They <span class="bcp14">MAY</span>
   also use the generic application-specific error code 5001 or the error codes 5002
   and 5004, which have been reserved for indicating invalid data in the ServerInfo and
   PeerInfo fields, respectively. Additionally, anticipating OOB channels that make use
   of a URL, the error code 5003 has been reserved for indicating an invalid server
   URL.<a href="#section-3.6.6-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="serverinfo-peerinfo-meaning">
<section id="section-4">
      <h2 id="name-serverinfo-and-peerinfo-con">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-serverinfo-and-peerinfo-con" class="section-name selfRef">ServerInfo and PeerInfo Contents</a>
      </h2>
<p id="section-4-1">The ServerInfo and PeerInfo fields in the Initial Exchange and Reconnect Exchange
      enable the server and peer, respectively, to send information about themselves to the
      other endpoint. They contain JSON objects whose structure may be specified separately
      for each application and each type of OOB channel. ServerInfo and PeerInfo
      <span class="bcp14">MAY</span> contain auxiliary data needed for the OOB channel messaging and for
      EAP channel binding (see <a href="#channel-binding" class="xref">Section 6.7</a>). This
      section describes the optional initial data fields for ServerInfo and PeerInfo
      registered by this specification. Further specifications may request new
      application-specific ServerInfo and PeerInfo data fields from IANA (see Sections <a href="#serverinfo-data-fields" class="xref">5.4</a> and <a href="#peerinfo-data-fields" class="xref">5.5</a>).<a href="#section-4-1" class="pilcrow">¶</a></p>
<span id="name-serverinfo-data-fields"></span><div id="tab-serverinfo-meaning">
<table class="center" id="table-6">
        <caption>
<a href="#table-6" class="selfRef">Table 6</a>:
<a href="#name-serverinfo-data-fields" class="selfRef">ServerInfo Data Fields</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Data Field</th>
            <th class="text-left" rowspan="1" colspan="1">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Type</td>
            <td class="text-left" rowspan="1" colspan="1">Type-tag string that can be used by the peer as a hint for how to
     interpret the ServerInfo contents.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">ServerName</td>
            <td class="text-left" rowspan="1" colspan="1">String that may be used to aid human identification of the
     server.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">ServerURL</td>
            <td class="text-left" rowspan="1" colspan="1">Prefix string when the OOB message is formatted as a URL, as
     suggested in <a href="#urloob" class="xref">Appendix D</a>.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">SSIDList</td>
            <td class="text-left" rowspan="1" colspan="1">List of IEEE 802.11 wireless network service set identifier
     (SSID) strings
     used for roaming support, as suggested in <a href="#roaming" class="xref">Appendix C</a>. JSON array of ASCII-encoded SSID strings.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Base64SSIDList</td>
            <td class="text-left" rowspan="1" colspan="1">List of IEEE 802.11 wireless network identifier (SSID) strings
     used for roaming support, as suggested in <a href="#roaming" class="xref">Appendix C</a>. JSON array of SSIDs, each of which is base64url-encoded
     without padding. Peers <span class="bcp14">SHOULD</span> send at most one of the fields
     SSIDList and Base64SSIDList in PeerInfo, and the server <span class="bcp14">SHOULD</span>
     ignore SSIDList if Base64SSIDList is included.</td>
          </tr>
        </tbody>
      </table>
</div>
<span id="name-peerinfo-data-fields"></span><div id="tab-peerinfo-meaning">
<table class="center" id="table-7">
        <caption>
<a href="#table-7" class="selfRef">Table 7</a>:
<a href="#name-peerinfo-data-fields" class="selfRef">PeerInfo Data Fields</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Data Field</th>
            <th class="text-left" rowspan="1" colspan="1">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Type</td>
            <td class="text-left" rowspan="1" colspan="1">Type-tag string that can be used by the server as a hint for how
     to interpret the PeerInfo contents.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">PeerName</td>
            <td class="text-left" rowspan="1" colspan="1">String that may be used to aid human identification of the
     peer.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Manufacturer</td>
            <td class="text-left" rowspan="1" colspan="1">Manufacturer or brand string.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Model</td>
            <td class="text-left" rowspan="1" colspan="1">Manufacturer-specified model string.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">SerialNumber</td>
            <td class="text-left" rowspan="1" colspan="1">Manufacturer-assigned serial number.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">MACAddress</td>
            <td class="text-left" rowspan="1" colspan="1">Peer link-layer 48-bit extended unique identifier (EUI-48) in
     the 12-digit base-16 form
     <span>[<a href="#EUI-48" class="xref">EUI-48</a>]</span>. The string <span class="bcp14">MAY</span> be in
     upper or lower case and <span class="bcp14">MAY</span> include additional colon ':' or dash
     '-' characters that <span class="bcp14">MUST</span> be ignored by the server.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">SSID</td>
            <td class="text-left" rowspan="1" colspan="1">IEEE 802.11 network SSID for channel binding. The SSID is an
     ASCII string.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Base64SSID</td>
            <td class="text-left" rowspan="1" colspan="1">IEEE 802.11 network SSID for channel binding. The SSID is
     base64url encoded. Peer <span class="bcp14">SHOULD</span> send at most one of the fields SSID
     and Base64SSID in PeerInfo, and the server <span class="bcp14">SHOULD</span> ignore SSID if
     Base64SSID is included.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">BSSID</td>
            <td class="text-left" rowspan="1" colspan="1">Wireless network basic service set identifier (BSSID) (EUI-48)
     in the 12-digit base-16 form
     <span>[<a href="#EUI-48" class="xref">EUI-48</a>]</span> for channel binding. The string
     <span class="bcp14">MAY</span> be in upper or lower case and <span class="bcp14">MAY</span> include
     additional colon ':' or dash '-' characters that <span class="bcp14">MUST</span> be ignored by
     the server.</td>
          </tr>
        </tbody>
      </table>
</div>
</section>
</div>
<div id="iana">
<section id="section-5">
      <h2 id="name-iana-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-5-1">This section provides information
      regarding registration of values related to the EAP-NOOB method, in accordance with
      <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">The EAP Method Type for EAP-NOOB (value 56) has been assigned in the "Method Types"
      subregistry of the "Extensible Authentication Protocol (EAP) Registry".<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">Per this memo, IANA has created and will maintain a new registry entitled "Nimble
      Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" in the Extensible Authentication Protocol
      (EAP) category. Also, IANA has created and will maintain the subregistries defined in
      the following subsections.<a href="#section-5-3" class="pilcrow">¶</a></p>
<div id="cryptosuites">
<section id="section-5.1">
        <h3 id="name-cryptosuites">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-cryptosuites" class="section-name selfRef">Cryptosuites</a>
        </h3>
<p id="section-5.1-1">IANA has created and will maintain a new subregistry entitled "EAP-NOOB
 Cryptosuites" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry.
 Cryptosuites are identified by an integer. Each cryptosuite <span class="bcp14">MUST</span>
 specify an ECDHE curve for the key exchange, encoding of the ECDHE public key as a JWK
 object, and a cryptographic hash function for the fingerprint and HMAC computation and
 key derivation. The hash value output by the cryptographic hash function
 <span class="bcp14">MUST</span> be at least 32 bytes in length. The initial values for this
 registry are:<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<span id="name-eap-noob-cryptosuites"></span><div id="tab-cryptosuites">
<table class="center" id="table-8">
          <caption>
<a href="#table-8" class="selfRef">Table 8</a>:
<a href="#name-eap-noob-cryptosuites" class="selfRef">EAP-NOOB Cryptosuites</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Cryptosuite</th>
              <th class="text-left" rowspan="1" colspan="1">Algorithms</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">Reserved</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">ECDHE curve Curve25519 <span>[<a href="#RFC7748" class="xref">RFC7748</a>]</span>, public-key format <span>[<a href="#RFC7517" class="xref">RFC7517</a>]</span>,
       hash function SHA-256 <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span>. The JWK
       encoding of Curve25519 public key is defined in <span>[<a href="#RFC8037" class="xref">RFC8037</a>]</span>. For clarity, the "crv" parameter is "X25519", the "kty"
       parameter is "OKP", and the public-key encoding contains only an
       x-coordinate.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">ECDHE curve NIST P-256 <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span>, public-key format <span>[<a href="#RFC7517" class="xref">RFC7517</a>]</span>,
       hash function SHA-256 <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span>. The JWK
       encoding of NIST P-256 public key is defined in <span>[<a href="#RFC7518" class="xref">RFC7518</a>]</span>. For clarity, the "crv" parameter is "P-256", the "kty"
       parameter is "EC", and the public-key encoding has both an x and y coordinate,
       as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7518#section-6.2.1" class="relref">Section 6.2.1</a> of [<a href="#RFC7518" class="xref">RFC7518</a>]</span>.</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-5.1-3">EAP-NOOB implementations <span class="bcp14">MUST</span> support Cryptosuite 1. Support for
 Cryptosuite 2 is <span class="bcp14">RECOMMENDED</span>. An example of a Cryptosuite 1 public-key
 encoded as a JWK object is given below. (Line breaks are for readability only.)<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<div id="section-5.1-4">
<pre class="lang-json sourcecode">
"jwk":{"kty":"OKP","crv":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-
DQ8hbeGdNrfx-FG-IK08"}
</pre><a href="#section-5.1-4" class="pilcrow">¶</a>
</div>
<p id="section-5.1-5">Assignment of new values for new cryptosuites <span class="bcp14">MUST</span> be done through
          IANA with "Specification Required", as defined in <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="messagetypes">
<section id="section-5.2">
        <h3 id="name-message-types">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-message-types" class="section-name selfRef">Message Types</a>
        </h3>
<p id="section-5.2-1">IANA has created and will maintain a new subregistry entitled "EAP-NOOB
 Message Types" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry.
 EAP-NOOB request and response pairs are identified by an integer Message Type. The
 initial values for this registry are:<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<span id="name-eap-noob-message-types"></span><div id="tab-messagetypes">
<table class="center" id="table-9">
          <caption>
<a href="#table-9" class="selfRef">Table 9</a>:
<a href="#name-eap-noob-message-types" class="selfRef">EAP-NOOB Message Types</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Message Type</th>
              <th class="text-left" rowspan="1" colspan="1">Used in Exchange</th>
              <th class="text-left" rowspan="1" colspan="1">Purpose</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">Error</td>
              <td class="text-left" rowspan="1" colspan="1">Error notification</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">All exchanges</td>
              <td class="text-left" rowspan="1" colspan="1">PeerId and PeerState discovery</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">Initial</td>
              <td class="text-left" rowspan="1" colspan="1">Version, cryptosuite, and parameter negotiation</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">3</td>
              <td class="text-left" rowspan="1" colspan="1">Initial</td>
              <td class="text-left" rowspan="1" colspan="1">Exchange of ECDHE keys and nonces</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">4</td>
              <td class="text-left" rowspan="1" colspan="1">Waiting</td>
              <td class="text-left" rowspan="1" colspan="1">Indication to the peer that the server has not yet received an
       OOB message</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">5</td>
              <td class="text-left" rowspan="1" colspan="1">Completion</td>
              <td class="text-left" rowspan="1" colspan="1">NoobId discovery</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">6</td>
              <td class="text-left" rowspan="1" colspan="1">Completion</td>
              <td class="text-left" rowspan="1" colspan="1">Authentication and key confirmation with HMAC</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">7</td>
              <td class="text-left" rowspan="1" colspan="1">Reconnect</td>
              <td class="text-left" rowspan="1" colspan="1">Version, cryptosuite, and parameter negotiation</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">8</td>
              <td class="text-left" rowspan="1" colspan="1">Reconnect</td>
              <td class="text-left" rowspan="1" colspan="1">Exchange of ECDHE keys and nonces</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">9</td>
              <td class="text-left" rowspan="1" colspan="1">Reconnect</td>
              <td class="text-left" rowspan="1" colspan="1">Authentication and key confirmation with HMAC</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-5.2-3">Assignment of new values for new Message Types <span class="bcp14">MUST</span> be done through
 IANA with "Specification Required", as defined in <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="errorcodes">
<section id="section-5.3">
        <h3 id="name-error-codes">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-error-codes" class="section-name selfRef">Error Codes</a>
        </h3>
<p id="section-5.3-1">IANA has created and will maintain a new subregistry entitled "EAP-NOOB
 Error codes" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry.
 Cryptosuites are identified by an integer. The initial values for this registry
 are:<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<span id="name-eap-noob-error-codes"></span><div id="tab-errors">
<table class="center" id="table-10">
          <caption>
<a href="#table-10" class="selfRef">Table 10</a>:
<a href="#name-eap-noob-error-codes" class="selfRef">EAP-NOOB Error Codes</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Error code</th>
              <th class="text-left" rowspan="1" colspan="1">Purpose</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1001</td>
              <td class="text-left" rowspan="1" colspan="1">Invalid NAI</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1002</td>
              <td class="text-left" rowspan="1" colspan="1">Invalid message structure</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1003</td>
              <td class="text-left" rowspan="1" colspan="1">Invalid data</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1004</td>
              <td class="text-left" rowspan="1" colspan="1">Unexpected message type</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1005</td>
              <td class="text-left" rowspan="1" colspan="1">Invalid ECDHE key</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2001</td>
              <td class="text-left" rowspan="1" colspan="1">Unwanted peer</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2002</td>
              <td class="text-left" rowspan="1" colspan="1">State mismatch, user action required</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2003</td>
              <td class="text-left" rowspan="1" colspan="1">Unrecognized OOB message identifier</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2004</td>
              <td class="text-left" rowspan="1" colspan="1">Unexpected peer identifier</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">3001</td>
              <td class="text-left" rowspan="1" colspan="1">No mutually supported protocol version</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">3002</td>
              <td class="text-left" rowspan="1" colspan="1">No mutually supported cryptosuite</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">3003</td>
              <td class="text-left" rowspan="1" colspan="1">No mutually supported OOB direction</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">4001</td>
              <td class="text-left" rowspan="1" colspan="1">HMAC verification failure</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">5001</td>
              <td class="text-left" rowspan="1" colspan="1">Application-specific error</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">5002</td>
              <td class="text-left" rowspan="1" colspan="1">Invalid server info</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">5003</td>
              <td class="text-left" rowspan="1" colspan="1">Invalid server URL</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">5004</td>
              <td class="text-left" rowspan="1" colspan="1">Invalid peer info</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">6001-6999</td>
              <td class="text-left" rowspan="1" colspan="1">Reserved for Private and Experimental Use</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-5.3-3">Assignment of new error codes <span class="bcp14">MUST</span> be done through IANA with
 "Specification Required", as defined in <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>,
 except for the range 6001-6999. This range is reserved for "Private Use" and
 "Experimental Use", both locally and on the open Internet.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="serverinfo-data-fields">
<section id="section-5.4">
        <h3 id="name-serverinfo-data-fields-2">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-serverinfo-data-fields-2" class="section-name selfRef">ServerInfo Data Fields</a>
        </h3>
<p id="section-5.4-1">IANA has created and will maintain a new subregistry entitled "EAP-NOOB
 ServerInfo Data Fields" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)"
 registry. The initial values for this registry are:<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<span id="name-serverinfo-data-fields-3"></span><div id="tab-serverinfo-data-fields">
<table class="center" id="table-11">
          <caption>
<a href="#table-11" class="selfRef">Table 11</a>:
<a href="#name-serverinfo-data-fields-3" class="selfRef">ServerInfo Data Fields</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Data Field</th>
              <th class="text-left" rowspan="1" colspan="1">Specification</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Type</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9140, <a href="#serverinfo-peerinfo-meaning" class="xref">Section 4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">ServerName</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9140, <a href="#serverinfo-peerinfo-meaning" class="xref">Section 4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">ServerURL</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9140, <a href="#serverinfo-peerinfo-meaning" class="xref">Section 4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">SSIDList</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9140, <a href="#serverinfo-peerinfo-meaning" class="xref">Section 4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Base64SSIDList</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9140, <a href="#serverinfo-peerinfo-meaning" class="xref">Section 4</a>
</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-5.4-3">Assignment of new values for new ServerInfo data fields <span class="bcp14">MUST</span> be done
 through IANA with "Specification Required", as defined in <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-5.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="peerinfo-data-fields">
<section id="section-5.5">
        <h3 id="name-peerinfo-data-fields-2">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-peerinfo-data-fields-2" class="section-name selfRef">PeerInfo Data Fields</a>
        </h3>
<p id="section-5.5-1">IANA is requested to create and maintain a new subregistry entitled "EAP-NOOB
 PeerInfo Data Fields" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)"
 registry. The initial values for this registry are:<a href="#section-5.5-1" class="pilcrow">¶</a></p>
<span id="name-peerinfo-data-fields-3"></span><div id="peerinfo-data-fields-table">
<table class="center" id="table-12">
          <caption>
<a href="#table-12" class="selfRef">Table 12</a>:
<a href="#name-peerinfo-data-fields-3" class="selfRef">PeerInfo Data Fields</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Data Field</th>
              <th class="text-left" rowspan="1" colspan="1">Specification</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Type</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9140, <a href="#serverinfo-peerinfo-meaning" class="xref">Section 4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PeerName</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9140, <a href="#serverinfo-peerinfo-meaning" class="xref">Section 4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Manufacturer</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9140, <a href="#serverinfo-peerinfo-meaning" class="xref">Section 4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Model</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9140, <a href="#serverinfo-peerinfo-meaning" class="xref">Section 4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">SerialNumber</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9140, <a href="#serverinfo-peerinfo-meaning" class="xref">Section 4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">MACAddress</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9140, <a href="#serverinfo-peerinfo-meaning" class="xref">Section 4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">SSID</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9140, <a href="#serverinfo-peerinfo-meaning" class="xref">Section 4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Base64SSID</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9140, <a href="#serverinfo-peerinfo-meaning" class="xref">Section 4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">BSSID</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9140, <a href="#serverinfo-peerinfo-meaning" class="xref">Section 4</a>
</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-5.5-3">Assignment of new values for new PeerInfo data fields <span class="bcp14">MUST</span> be done
 through IANA with "Specification Required", as defined in <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-5.5-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="specialdomainname">
<section id="section-5.6">
        <h3 id="name-domain-name-reservation">
<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-domain-name-reservation" class="section-name selfRef">Domain Name Reservation</a>
        </h3>
<p id="section-5.6-1">The special-use domain "eap-noob.arpa" has been registered in the .arpa registry
 (<span><a href="https://www.iana.org/domains/arpa">https://www.iana.org/domains/arpa</a></span>) and the "Special-Use Domain
 Names" registry (<span><a href="https://www.iana.org/assignments/special-use-domain-names">https://www.iana.org/assignments/special-use-domain-names</a></span>).<a href="#section-5.6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="expertguidance">
<section id="section-5.7">
        <h3 id="name-guidance-for-designated-exp">
<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-guidance-for-designated-exp" class="section-name selfRef">Guidance for Designated Experts</a>
        </h3>
<p id="section-5.7-1">Experts <span class="bcp14">SHOULD</span> be conservative in the allocation of new
 Cryptosuites. Experts <span class="bcp14">MUST</span> ascertain that the requested values match
 the current Crypto Forum Research Group (CFRG) guidance on cryptographic algorithm
 security. Experts <span class="bcp14">MUST</span> ensure that any new Cryptosuites fully specify
 the encoding of the ECDHE public key and should include details, such as the value of
 the "kty" (key type) parameter when JWK <span>[<a href="#RFC7517" class="xref">RFC7517</a>]</span> encoding
 is used.<a href="#section-5.7-1" class="pilcrow">¶</a></p>
<p id="section-5.7-2">Experts <span class="bcp14">SHOULD</span> be conservative in the allocation of new Message
 Types. Experts <span class="bcp14">SHOULD</span> ascertain that a well-defined specification for
 the new Message Type is permanently and publicly available.<a href="#section-5.7-2" class="pilcrow">¶</a></p>
<p id="section-5.7-3">Experts <span class="bcp14">SHOULD</span> be conservative in the allocation of new Error codes,
 since the 6001-6999 range is already reserved for private and experimental use.<a href="#section-5.7-3" class="pilcrow">¶</a></p>
<p id="section-5.7-4">Experts <span class="bcp14">MAY</span> be liberal in the allocation of new ServerInfo and
 PeerInfo data fields. Experts <span class="bcp14">MUST</span> ensure that the data field requested
 has a unique name that is not easily confused with existing registrations. For
 example, requests for a new PeerInfo data field "ssid" should be rejected even though
 it is unique because it can be confused with the existing registration of "SSID".
 Experts <span class="bcp14">MUST</span> ensure that a suitable Description for the data field is
 available.<a href="#section-5.7-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="securityconsiderations">
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">EAP-NOOB is an authentication and key derivation protocol; thus, security
      considerations can be found in most sections of this specification. In the following, we
      explain the protocol design and highlight some other special considerations.<a href="#section-6-1" class="pilcrow">¶</a></p>
<div id="authenticationprinciple">
<section id="section-6.1">
        <h3 id="name-authentication-principle">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-authentication-principle" class="section-name selfRef">Authentication Principle</a>
        </h3>
<p id="section-6.1-1">EAP-NOOB establishes a shared secret with an authenticated ECDHE key exchange. The
 mutual authentication in EAP-NOOB is based on two separate features, both conveyed in
 the OOB message. The first authentication feature is the secret nonce Noob. The peer
 and server use this secret in the Completion Exchange to mutually authenticate the
 session key previously created with ECDHE. The message authentication codes computed
 with the secret nonce Noob are alone sufficient for authenticating the key exchange.
 The second authentication feature is the integrity-protecting fingerprint Hoob. Its
 purpose is to prevent impersonation attacks even in situations where the attacker is
 able to eavesdrop on the OOB channel and the nonce Noob is compromised. In some
 human-assisted OOB channels, such as human-perceptible audio or a user-typed URL, it
 may be easier to detect tampering than disclosure of the OOB message, and such
 applications benefit from the second authentication feature.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">The additional security provided by the cryptographic fingerprint Hoob is somewhat
 intricate to understand. The endpoint that receives the OOB message uses Hoob to
 verify the integrity of the ECDHE exchange. Thus, the OOB receiver can detect
 impersonation attacks that may have happened on the in-band channel. The other
 endpoint, however, is not equally protected because the OOB message and fingerprint
 are sent only in one direction. Some protection to the OOB sender is afforded by the
 fact that the user may notice the failure of the association at the OOB receiver and
 therefore reset the OOB sender. Other device-pairing protocols have solved similar
 situations by requiring the user to confirm to the OOB sender that the association was
 accepted by the OOB receiver, e.g., with a button press on the sender side.
 Applications <span class="bcp14">MAY</span> implement EAP-NOOB in this way. Nevertheless, since
 EAP-NOOB was designed to work with strictly one-directional OOB communication and the
 fingerprint is only the second authentication feature, the EAP-NOOB specification does
 not mandate such explicit confirmation to the OOB sender.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<p id="section-6.1-3">To summarize, EAP-NOOB uses the combined protection of the secret nonce Noob and
 the cryptographic fingerprint Hoob, both conveyed in the OOB message. The secret nonce
 Noob alone is sufficient for mutual authentication unless the attacker can eavesdrop
 on it from the OOB channel. Even if an attacker is able to eavesdrop on the secret
 nonce Noob, it nevertheless cannot perform a full impersonation attack on the in-band
 channel because a mismatching fingerprint would alert the OOB receiver, which would
 reject the OOB message. The attacker that eavesdropped on the secret nonce can
 impersonate the OOB receiver to the OOB sender. If it does, the association will
 appear to be complete only on the OOB sender side, and such situations have to be
 resolved by the user by resetting the OOB sender to the initial state.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<p id="section-6.1-4">The expected use cases for EAP-NOOB are ones where it replaces a user-entered
 access credential in IoT appliances. In wireless network access without EAP, the
 user-entered credential is often a passphrase that is shared by all the network
 stations. The advantage of an EAP-based solution, including EAP-NOOB, is that it
 establishes a different shared secret for each peer device, which makes the system
 more resilient against device compromise. Another advantage is that it is possible to
 revoke the security association for an individual device on the server side.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
<p id="section-6.1-5">Forward secrecy during fast reconnect in EAP-NOOB is optional. The Reconnect
 Exchange in EAP-NOOB provides forward secrecy only if both the server and peer send
 their fresh ECDHE keys. This allows both the server and peer to limit the
 frequency of the costly computation that is required for forward secrecy. The server
 <span class="bcp14">MAY</span> adjust the frequency of its attempts at ECDHE rekeying based on
 what it knows about the peer's computational capabilities.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
<p id="section-6.1-6">Another way in which some servers may control their computational load is to reuse
 the same ECDHE key for all peers over a short server-specific time window. In that
 case, forward secrecy will be achieved only after the server updates its ECDHE key,
 which may be a reasonable trade-off between security and performance. However, the
 server <span class="bcp14">MUST NOT</span> reuse the same ECDHE key with the same peer when
 rekeying with ECDHE (KeyingMode=2 or KeyingMode=3). Instead, it can simply not send an
 ECDHE key (KeyingMode=1).<a href="#section-6.1-6" class="pilcrow">¶</a></p>
<p id="section-6.1-7">The users delivering the OOB messages will often authenticate themselves to the EAP
 server, e.g., by logging into a secure web page or API. In this case, the server can
 associate the peer device with the user account. Applications that make use of
 EAP-NOOB can use this information for configuring the initial owner of the
 freshly registered device.<a href="#section-6.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="deviceidentification">
<section id="section-6.2">
        <h3 id="name-identifying-correct-endpoin">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-identifying-correct-endpoin" class="section-name selfRef">Identifying Correct Endpoints</a>
        </h3>
<p id="section-6.2-1">Potential weaknesses in EAP-NOOB arise from the fact that the user must physically
 identify the correct peer device. If the user mistakenly delivers the OOB message
 from the wrong peer device to the server, the server may create an association with
 the wrong peer. The reliance on the user in identifying the correct endpoints is an
 inherent property of user-assisted, out-of-band authentication. To understand the
 potential consequences of the user mistake, we need to consider a few different
 scenarios. In the first scenario, there is no malicious party, and the user makes an
 accidental mistake between two out-of-the-box devices that are both ready to be
 registered to a server. If the user delivers the OOB message from the wrong device to
 the server, confusion may arise but usually no security issues. In the second
 scenario, an attacker intentionally tricks the user, for example, by substituting the
 original peer device with a compromised one. This is essentially a supply chain attack
 where the user accepts a compromised physical device.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">There is also a third scenario, in which an opportunistic attacker tries to take
 advantage of the user's accidental mistake. For example, the user could play an audio
 or a blinking LED message to a device that is not expecting to receive it. In simple
 security bootstrapping solutions that transfer a primary key to the device via the OOB
 channel, the device could misuse or leak the accidentally received primary key.
 EAP-NOOB is not vulnerable to such opportunistic attackers because the OOB message has
 no value to anyone who did not take part in the corresponding Initial Exchange.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
<p id="section-6.2-3">One mechanism that can mitigate user mistakes is certification of peer devices. A
 certificate or an attestation token (e.g., <span>[<a href="#I-D.tschofenig-tls-cwt" class="xref">TLS-CWT</a>]</span> and <span>[<a href="#I-D.ietf-rats-eat" class="xref">RATS-EAT</a>]</span>) can convey
 to the server authentic identifiers and attributes, such as model and serial number,
 of the peer device. Compared to a fully certificate-based authentication, however,
 EAP-NOOB can be used without trusted third parties and does not require the user to
 know any identifier of the peer device; physical access to the device is sufficient
 for bootstrapping with EAP-NOOB.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
<p id="section-6.2-4">Similarly, the attacker can try to trick the user into delivering the OOB message
 to
 the wrong server so that the peer device becomes associated with the wrong server. If
 the EAP server is accessed through a web user interface, the attack is akin to
 phishing attacks where the user is tricked into accessing the wrong URL and wrong web
 page. OOB implementation with a dedicated app on a mobile device, which communicates
 with a server API at a preconfigured URL, can protect against such attacks.<a href="#section-6.2-4" class="pilcrow">¶</a></p>
<p id="section-6.2-5">After the device registration, an attacker could clone the device identity by
 copying the keys from the persistent EAP-NOOB association into another device. The
 attacker can be an outsider who gains access to the keys or the device owner who wants
 to have two devices matching the same registration. The cloning threats can be
 mitigated by creating the cryptographic keys and storing the persistent EAP-NOOB
 association on the peer device in a secure hardware component such as a trusted
 execution environment (TEE). Furthermore, remote attestation on the application level
 could provide assurance to the server that the device has not been cloned. Reconnect
 Exchange with a new cryptosuite (KeyingMode=3) will also disconnect all but the first
 clone that performs the update.<a href="#section-6.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="trustedpath">
<section id="section-6.3">
        <h3 id="name-trusted-path-issues-and-mis">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-trusted-path-issues-and-mis" class="section-name selfRef">Trusted Path Issues and Misbinding Attacks</a>
        </h3>
<p id="section-6.3-1">Another potential threat is spoofed user input or output on the peer device. When
 the user is delivering the OOB message to or from the correct peer device, a trusted
 path between the user and the peer device is needed. That is, the user must
 communicate directly with an authentic operating system and EAP-NOOB implementation in
 the peer device and not with a spoofed user interface. Otherwise, a registered device
 that is under the control of the attacker could emulate the behavior of an
 unregistered device. The secure path can be implemented, for example, by having the
 user press a reset button to return the device to the Unregistered (0) state and to
 invoke
 a trusted UI. The problem with such trusted paths is that they are not standardized
 across devices.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">Another potential consequence of a spoofed UI is the misbinding attack where the
 user tries to register a correct but compromised device, which tricks the user into
 registering another (uncompromised) device instead. For example, the compromised
 device might have a malicious, full-screen app running, which presents to the user QR
 codes copied, in real time, from another device's screen. If the unwitting user scans
 the QR code and delivers the OOB message in it to the server, the wrong device may
 become registered in the server. Such misbinding vulnerabilities arise because the
 user does not have any secure way of verifying that the in-band cryptographic
 handshake and the out-of-band physical access are terminated at the same physical
 device. Sethi et al. <span>[<a href="#Sethi19" class="xref">Sethi19</a>]</span> analyze the misbinding
 threat against device-pairing protocols and also EAP-NOOB. Essentially, all protocols
 where the authentication relies on the user's physical access to the device are
 vulnerable to misbinding, including EAP-NOOB.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
<p id="section-6.3-3">A standardized trusted path for communicating directly with the trusted computing
 base in a physical device would mitigate the misbinding threat, but such paths rarely
 exist in practice. Careful asset tracking on the server side can also prevent most
 misbinding attacks if the peer device sends its identifiers or attributes in the
 PeerInfo field and the server compares them with the expected values. The wrong but
 uncompromised device's PeerInfo will not match the expected values. Device
 certification by the manufacturer can further strengthen the asset tracking.<a href="#section-6.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="peeridentifiers">
<section id="section-6.4">
        <h3 id="name-peer-identifiers-and-attrib">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-peer-identifiers-and-attrib" class="section-name selfRef">Peer Identifiers and Attributes</a>
        </h3>
<p id="section-6.4-1">The PeerId value in the protocol is a server-allocated identifier for its
 association with the peer and <span class="bcp14">SHOULD NOT</span> be shown to the user because
 its value is initially ephemeral. Since the PeerId is allocated by the server and the
 scope of the identifier is the single server, the so-called identifier squatting
 attacks, where a malicious peer could reserve another peer's identifier, are not
 possible in EAP-NOOB. The server <span class="bcp14">SHOULD</span> assign a random or
 pseudorandom PeerId to each new peer. It <span class="bcp14">SHOULD NOT</span> select the PeerId
 based on any peer characteristics that it may know, such as the peer's link-layer
 network address.<a href="#section-6.4-1" class="pilcrow">¶</a></p>
<p id="section-6.4-2">User reset or failure in the OOB Step can cause the peer to perform many Initial
 Exchanges with the server, which allocates many PeerId values and stores the ephemeral
 protocol state for them. The peer will typically only remember the latest ones.
 EAP-NOOB leaves it to the implementation to decide when to delete these ephemeral
 associations. There is no security reason to delete them early, and the server does
 not have any way to verify that the peers are actually the same one. Thus, it is
 safest to store the ephemeral states on the server for at least one day. If the OOB
 messages are sent only in the server-to-peer direction, the server <span class="bcp14">SHOULD NOT</span> delete the ephemeral state before all the related Noob values have
 expired.<a href="#section-6.4-2" class="pilcrow">¶</a></p>
<p id="section-6.4-3">After completion of EAP-NOOB, the server may store the PeerInfo data, and the user
 may use it to identify the peer and its attributes, such as the make and model or
 serial number. A compromised peer could lie in the PeerInfo that it sends to the
 server. If the server stores any information about the peer, it is important that this
 information is approved by the user during or after the OOB Step. Without verification
 by the user or authentication on the application level, the PeerInfo is not
 authenticated information and should not be relied on. One possible use for the
 PeerInfo field is EAP channel binding (see <a href="#channel-binding" class="xref">Section 6.7</a>).<a href="#section-6.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="downgrading">
<section id="section-6.5">
        <h3 id="name-downgrading-threats">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-downgrading-threats" class="section-name selfRef">Downgrading Threats</a>
        </h3>
<p id="section-6.5-1">The fingerprint Hoob protects all the information exchanged in the Initial
 Exchange, including the cryptosuite negotiation. The message authentication codes MACs
 and MACp also protect the same information. The message authentication codes MACs2 and
 MACp2 protect information exchanged during key renegotiation in the Reconnect
 Exchange. This prevents downgrading attacks to weaker cryptosuites, as long as the
 possible attacks take more time than the maximum time allowed for the EAP-NOOB
 completion. This is typically the case for recently discovered cryptanalytic
 attacks.<a href="#section-6.5-1" class="pilcrow">¶</a></p>
<p id="section-6.5-2">As an additional precaution, the EAP server and peer <span class="bcp14">MUST</span> check for
 downgrading attacks in the Reconnect Exchange as follows. As long as the server or
 peer saves any information about the other endpoint, it <span class="bcp14">MUST</span> also
 remember the previously negotiated cryptosuite and <span class="bcp14">MUST NOT</span> accept
 renegotiation of any cryptosuite that is known to be weaker than the previous one,
 such as a deprecated cryptosuite. Determining the relative strength of the
 cryptosuites is out of scope of this specification and may be managed by
 implementations or by local policies at the peer and server.<a href="#section-6.5-2" class="pilcrow">¶</a></p>
<p id="section-6.5-3">Integrity of the direction negotiation cannot be verified in the same way as the
 integrity of the cryptosuite negotiation. That is, if the OOB channel used in an
 application is critically insecure in one direction, an on-path attacker could modify
 the negotiation messages and thereby cause that direction to be used. Applications
 that support OOB messages in both directions <span class="bcp14">SHOULD</span>, therefore, ensure
 that the OOB channel has sufficiently strong security in both directions. While this
 is a theoretical vulnerability, it could arise in practice if EAP-NOOB is deployed in
 new applications. Currently, we expect most peer devices to support only one OOB
 direction; in which case, interfering with the direction negotiation can only prevent
 the completion of the protocol.<a href="#section-6.5-3" class="pilcrow">¶</a></p>
<p id="section-6.5-4">The long-term shared key material Kz in the persistent EAP-NOOB association is
 established with an ECDHE key exchange when the peer and server are first associated.
 It is a weaker secret than a manually configured random shared key because advances in
 cryptanalysis against the used ECDHE curve could eventually enable the attacker to
 recover Kz. EAP-NOOB protects against such attacks by allowing cryptosuite upgrades in
 the Reconnect Exchange and by updating the shared key material Kz whenever the
 cryptosuite is upgraded. We do not expect the cryptosuite upgrades to be frequent,
 but,
 if an upgrade becomes necessary, it can be done without manual reset and reassociation
 of the peer devices.<a href="#section-6.5-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="indicators">
<section id="section-6.6">
        <h3 id="name-protected-success-and-failu">
<a href="#section-6.6" class="section-number selfRef">6.6. </a><a href="#name-protected-success-and-failu" class="section-name selfRef">Protected Success and Failure Indications</a>
        </h3>
<p id="section-6.6-1"><span><a href="https://www.rfc-editor.org/rfc/rfc3748#section-7.16" class="relref">Section 7.16</a> of [<a href="#RFC3748" class="xref">RFC3748</a>]</span> allows EAP methods to
 specify protected result indications because EAP-Success and EAP-Failure packets are
 neither acknowledged nor integrity protected. <span>[<a href="#RFC3748" class="xref">RFC3748</a>]</span> notes that these indications may be explicit or implicit.<a href="#section-6.6-1" class="pilcrow">¶</a></p>
<p id="section-6.6-2">EAP-NOOB relies on implicit, protected success indicators in the Completion
 Exchange and
 Reconnect Exchange. Successful verification of MACs and MACs2 in the EAP-Request
 message from the server (message type 6 and message type 9, respectively) acts as an
 implicit, protected success indication to the peer. Similarly, successful verification
 of MACp and MACp2 in the EAP-Response message from the peer (message type 6 and
 message type 9, respectively) act as an implicit, protected success indication to the
 server.<a href="#section-6.6-2" class="pilcrow">¶</a></p>
<p id="section-6.6-3">EAP-NOOB failure messages are not protected. Protected failure result indications
 would not significantly improve availability since EAP-NOOB reacts to most malformed
 data by ending the current EAP conversation in EAP-Failure. However, since EAP-NOOB
 spans multiple conversations, failure in one conversation usually means no state
 change on the level of the EAP-NOOB state machine.<a href="#section-6.6-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="channel-binding">
<section id="section-6.7">
        <h3 id="name-channel-binding">
<a href="#section-6.7" class="section-number selfRef">6.7. </a><a href="#name-channel-binding" class="section-name selfRef">Channel Binding</a>
        </h3>
<p id="section-6.7-1">EAP channel binding, defined in <span>[<a href="#RFC6677" class="xref">RFC6677</a>]</span>, means
 that the endpoints compare their perceptions of network properties, such as
 lower-layer identifiers, over the secure channel established by EAP authentication.
 <span><a href="https://www.rfc-editor.org/rfc/rfc6677#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC6677" class="xref">RFC6677</a>]</span> defines two approaches to
 channel binding. EAP-NOOB follows the first approach, in which the peer and server
 exchange plaintext information about the network over a channel that is integrity
 protected with keys derived during the EAP execution. More specifically, channel
 information is exchanged in the plaintext PeerInfo and ServerInfo objects and is later
 verified with message authentication codes (MACp, MACs, MACp2, and MACs2). This allows
 policy-based comparison with locally perceived network properties on either side, as
 well as logging for debugging purposes. The peer <span class="bcp14">MAY</span> include in
 PeerInfo any data items that it wants to bind to the EAP-NOOB association and to the
 exported keys. These can be properties of the authenticator or the access link, such
 as the SSID and BSSID of the wireless network (see <a href="#tab-serverinfo-meaning" class="xref">Table 6</a>). As noted in <span><a href="https://www.rfc-editor.org/rfc/rfc6677#section-4.3" class="relref">Section 4.3</a> of [<a href="#RFC6677" class="xref">RFC6677</a>]</span>, the scope of the channel binding
 varies between deployments. For example, the server may have less link-layer
 information available from roaming networks than from a local enterprise network, and
 it may be unable to verify all the network properties received in PeerInfo. There are
 also privacy considerations related to exchanging the ServerInfo and PeerInfo while
 roaming (see <a href="#privacyconsiderations" class="xref">Section 6.10</a>).<a href="#section-6.7-1" class="pilcrow">¶</a></p>
<p id="section-6.7-2">Channel binding to secure channels, defined in <span>[<a href="#RFC5056" class="xref">RFC5056</a>]</span>, binds authentication at a higher protocol layer to a secure
 channel at a lower layer.  Like most EAP methods, EAP-NOOB exports the session keys
 MSK and EMSK, and an outer tunnel or a higher-layer protocol can bind its
 authentication to these keys. Additionally, EAP-NOOB exports the key AMSK, which may
 be used to bind application-layer authentication to the secure channel created by
 EAP-NOOB and to the session keys MSK and EMSK.<a href="#section-6.7-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dos">
<section id="section-6.8">
        <h3 id="name-denial-of-service">
<a href="#section-6.8" class="section-number selfRef">6.8. </a><a href="#name-denial-of-service" class="section-name selfRef">Denial of Service</a>
        </h3>
<p id="section-6.8-1">While denial-of-service (DoS) attacks by on-link attackers cannot be fully
 prevented, the design goal in EAP-NOOB is to void long-lasting failure caused by an
 attacker who is present only temporarily or intermittently. The main defense mechanism
 is the persistent EAP-NOOB association, which is never deleted automatically due to
 in-band messages or error indications. Thus, the endpoints can always use the
 persistent association for reconnecting after the DoS attacker leaves the network. In
 this sense, the persistent association serves the same function in EAP-NOOB as a
 permanent primary key or certificate in other authentication protocols. We discuss
 logical attacks against the updates of the persistent association in <a href="#completion-loss" class="xref">Section 6.9</a>.<a href="#section-6.8-1" class="pilcrow">¶</a></p>
<p id="section-6.8-2">In addition to logical DoS attacks, it is necessary to consider resource exhaustion
 attacks against the EAP server. The number of persistent EAP-NOOB associations created
 in the server is limited by the need for a user to assist in delivering the OOB
 message. The users can be authenticated for the input or output of the OOB message at
 the EAP server, and any users who create excessive numbers of persistent associations
 can be held accountable and their associations can be deleted by the server
 administrator. What the attacker can do without user authentication is to perform the
 Initial Exchange repeatedly and create a large number of ephemeral associations
 (server in Waiting for OOB (1) state) without ever delivering the OOB message. In
 <a href="#peeridentifiers" class="xref">Section 6.4</a>, it was suggested that the server
 should store the ephemeral states for at least a day. This may require off-loading the
 state storage from memory to disk during a DoS attack. However, if the server
 implementation is unable to keep up with a rate of Initial Exchanges performed by a
 DoS attacker and needs to drop some ephemeral states, no damage is caused to
 already-created persistent associations, and the honest users can resume registering
 new peers when the DoS attacker leaves the network.<a href="#section-6.8-2" class="pilcrow">¶</a></p>
<p id="section-6.8-3">There are some trade-offs in the protocol design between politely backing off and
 giving
 way to DoS attackers. An on-link DoS attacker could spoof the SleepTime value in the
 Initial Exchange or Waiting Exchange to cause denial of service against a specific
 peer device. There is an upper limit on the SleepTime (3600 seconds) to
 mitigate the
 spoofing threat. This means that, in the presence of an on-link DoS attacker who
 spoofs the SleepTime, it could take up to one hour after the delivery of the OOB
 message before the device performs the Completion Exchange and becomes functional.
 Similarly, the Unwanted peer error (error code 2001) could cause the peer to stop
 connecting to the network. If the peer device is able to alert the user about the
 error condition, it can safely stop connecting to the server and wait for the user to
 trigger a reconnection attempt, e.g., by resetting the device. As mentioned in <a href="#unwantedpeer" class="xref">Section 3.6.2</a>, peer devices that are unable to alert the
 user should continue to retry the Initial Exchange infrequently to avoid a permanent
 DoS condition. We believe a maximum backoff time of 3600 seconds is reasonable for a
 new protocol because malfunctioning or misconfigured peer implementations are at least
 as great a concern as DoS attacks, and politely backing off within some reasonable
 limits will increase the acceptance of the protocol. The maximum backoff times could
 be updated to be shorter as the protocol implementations mature.<a href="#section-6.8-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="completion-loss">
<section id="section-6.9">
        <h3 id="name-recovery-from-loss-of-last-">
<a href="#section-6.9" class="section-number selfRef">6.9. </a><a href="#name-recovery-from-loss-of-last-" class="section-name selfRef">Recovery from Loss of Last Message</a>
        </h3>
<p id="section-6.9-1">The EAP-NOOB Completion Exchange, as well as the Reconnect Exchange with
 cryptosuite update, results in a persistent state change that should take place either
 on both endpoints or on neither; otherwise, the result is a state mismatch that
 requires user action to resolve. The state mismatch can occur if the final EAP
 response of the exchanges is lost. In the Completion Exchange, the loss of the final
 response (Type=6) results in the peer moving to the Registered (4) state and creating
 a persistent EAP-NOOB association while the server stays in an ephemeral state (1 or
 2). In the Reconnect Exchange, the loss of the final response (Type=9) results in the
 peer moving to the Registered (4) state and updating its persistent key material Kz
 while the server stays in the Reconnecting (3) state and keeps the old key
 material.<a href="#section-6.9-1" class="pilcrow">¶</a></p>
<p id="section-6.9-2">The state mismatch is an example of an unavoidable problem in distributed systems:
 it is theoretically impossible to guarantee synchronous state changes in endpoints
 that communicate asynchronously. The protocol will always have one critical message
 that may get lost, so that one side commits to the state change and the other side
 does not. In EAP, the critical message is the final response from the peer to the
 server. While the final response is normally followed by EAP-Success, <span>[<a href="#RFC3748" class="xref">RFC3748</a>], <a href="https://www.rfc-editor.org/rfc/rfc3748#section-4.2" class="relref">Section 4.2</a></span> states that the peer
 <span class="bcp14">MAY</span> assume that the EAP-Success was lost and the authentication was
 successful. Furthermore, EAP method implementations in the peer do not receive
 notification of the EAP-Success message from the parent EAP state machine <span>[<a href="#RFC4137" class="xref">RFC4137</a>]</span>. For these reasons, EAP-NOOB on the peer side
 commits to a state change already when it sends the final response.<a href="#section-6.9-2" class="pilcrow">¶</a></p>
<p id="section-6.9-3">The best available solution to the loss of the critical message is to keep trying.
 EAP retransmission behavior defined in <span><a href="https://www.rfc-editor.org/rfc/rfc3748#section-4.3" class="relref">Section 4.3</a> of [<a href="#RFC3748" class="xref">RFC3748</a>]</span> suggests 3-5 retransmissions. In the absence of an attacker, this
 would be sufficient to reduce the probability of failure to an acceptable level.
 However, a determined attacker on the in-band channel can drop the final EAP-Response
 message and all subsequent retransmissions. In the Completion Exchange (KeyingMode=0)
 and Reconnect Exchange with cryptosuite upgrade (KeyingMode=3), this could
 result in a state mismatch and persistent denial of service until the user resets the
 peer state.<a href="#section-6.9-3" class="pilcrow">¶</a></p>
<p id="section-6.9-4">EAP-NOOB implements its own recovery mechanism that allows unlimited retries of the
 Reconnect Exchange. When the DoS attacker eventually stops dropping packets on the
 in-band channel, the protocol will recover. The logic for this recovery mechanism is
 specified in <a href="#reconnectexchange" class="xref">Section 3.4.2</a>.<a href="#section-6.9-4" class="pilcrow">¶</a></p>
<p id="section-6.9-5">EAP-NOOB does not implement the same kind of retry mechanism in the Completion
 Exchange. The reason is that there is always a user involved in the initial
 association process, and the user can repeat the OOB Step to complete the association
 after the DoS attacker has left. On the other hand, Reconnect Exchange needs to work
 without user involvement.<a href="#section-6.9-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="privacyconsiderations">
<section id="section-6.10">
        <h3 id="name-privacy-considerations">
<a href="#section-6.10" class="section-number selfRef">6.10. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
        </h3>
<p id="section-6.10-1">There are privacy considerations related to performing the Reconnect Exchange while
 roaming. The peer and server may send updated PeerInfo and ServerInfo fields in the
 Reconnect Exchange. This data is sent unencrypted between the peer and the EAP
 authenticator, such as a wireless access point. Thus, it can be observed by both
 outsiders and the access network. The PeerInfo field contains identifiers and other
 information about the peer device (see <a href="#tab-serverinfo-meaning" class="xref">Table 6</a>). While the information refers to the peer device and not directly
 to the user, it can leak information about the user to the access network and to
 outside observers. The ServerInfo, on the other hand, can leak information about the
 peer's affiliation with the home network. For this reason, the optional PeerInfo and
 ServerInfo in the Reconnect Exchange <span class="bcp14">SHOULD</span> be omitted unless some
 critical data has changed and it cannot be updated on the application layer.<a href="#section-6.10-1" class="pilcrow">¶</a></p>
<p id="section-6.10-2">Peer devices that randomize their Layer 2 address to prevent tracking can do this
 whenever the user resets the EAP-NOOB association. During the lifetime of the
 association, the PeerId is a unique identifier that can be used to track the peer in
 the access network. Later versions of this specification may consider updating the
 PeerId at each Reconnect Exchange. In that case, it is necessary to consider how the
 authenticator and access-network administrators can recognize and add misbehaving peer
 devices to a deny list, as well as how to avoid loss of synchronization between the
 server and the peer if messages are lost during the identifier update.<a href="#section-6.10-2" class="pilcrow">¶</a></p>
<p id="section-6.10-3">To enable stronger identity protection in later versions of EAP-NOOB, the optional
 server-assigned NAI (NewNAI) <span class="bcp14">SHOULD</span> have a constant username part. The
 <span class="bcp14">RECOMMENDED</span> username is "noob". The server <span class="bcp14">MAY</span>, however,
 send a different username in NewNAI to avoid username collisions within its realm or
 to conform to a local policy on usernames.<a href="#section-6.10-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="securityclaims">
<section id="section-6.11">
        <h3 id="name-eap-security-claims">
<a href="#section-6.11" class="section-number selfRef">6.11. </a><a href="#name-eap-security-claims" class="section-name selfRef">EAP Security Claims</a>
        </h3>
<p id="section-6.11-1">EAP security claims are defined in <span><a href="https://www.rfc-editor.org/rfc/rfc3748#section-7.2.1" class="relref">Section 7.2.1</a> of [<a href="#RFC3748" class="xref">RFC3748</a>]</span>. The security claims for EAP-NOOB are listed in <a href="#tab-securityclaims" class="xref">Table 13</a>.<a href="#section-6.11-1" class="pilcrow">¶</a></p>
<span id="name-eap-security-claims-2"></span><div id="tab-securityclaims">
<table class="center" id="table-13">
          <caption>
<a href="#table-13" class="selfRef">Table 13</a>:
<a href="#name-eap-security-claims-2" class="selfRef">EAP Security Claims</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Security Property</th>
              <th class="text-left" rowspan="1" colspan="1">EAP-NOOB Claim</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Authentication mechanism</td>
              <td class="text-left" rowspan="1" colspan="1">ECDHE key exchange with out-of-band authentication</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Protected cryptosuite negotiation</td>
              <td class="text-left" rowspan="1" colspan="1">yes</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Mutual authentication</td>
              <td class="text-left" rowspan="1" colspan="1">yes</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Integrity protection</td>
              <td class="text-left" rowspan="1" colspan="1">yes</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Replay protection</td>
              <td class="text-left" rowspan="1" colspan="1">yes</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Confidentiality</td>
              <td class="text-left" rowspan="1" colspan="1">no</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Key derivation</td>
              <td class="text-left" rowspan="1" colspan="1">yes</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Key strength</td>
              <td class="text-left" rowspan="1" colspan="1">The specified cryptosuites provide key strength of at least 128
       bits.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Dictionary attack protection</td>
              <td class="text-left" rowspan="1" colspan="1">yes</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Fast reconnect</td>
              <td class="text-left" rowspan="1" colspan="1">yes</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Cryptographic binding</td>
              <td class="text-left" rowspan="1" colspan="1">not applicable</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Session independence</td>
              <td class="text-left" rowspan="1" colspan="1">yes</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Fragmentation</td>
              <td class="text-left" rowspan="1" colspan="1">no</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">Channel binding</td>
              <td class="text-left" rowspan="1" colspan="1">yes (The ServerInfo and PeerInfo can be used to convey
       integrity-protected channel properties, such as network SSID or peer MAC
       address.)</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</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="EUI-48">[EUI-48]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture"</span>, <span class="seriesInfo">DOI 10.1109/IEEESTD.2014.6847097</span>, <span class="seriesInfo">IEEE Standard 802-2014</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://doi.org/10.1109/IEEESTD.2014.6847097">https://doi.org/10.1109/IEEESTD.2014.6847097</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="FIPS186-4">[FIPS186-4]</dt>
        <dd>
<span class="refAuthor">National Institute of Standards and Technology (NIST)</span>, <span class="refTitle">"Digital Signature Standard (DSS)"</span>, <span class="seriesInfo">DOI 10.6028/NIST.FIPS.186-4</span>, <span class="seriesInfo">FIPS 186-4</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span>&lt;<a href="https://doi.org/10.6028/NIST.FIPS.186-4">https://doi.org/10.6028/NIST.FIPS.186-4</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="NIST-DH">[NIST-DH]</dt>
        <dd>
<span class="refAuthor">Barker, E.</span>, <span class="refAuthor">Chen, L.</span>, <span class="refAuthor">Roginsky, A.</span>, <span class="refAuthor">Vassilev, A.</span>, and <span class="refAuthor">R. Davis</span>, <span class="refTitle">"Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography"</span>, <span class="seriesInfo">DOI 10.6028/NIST.SP.800-56Ar3</span>, <span class="seriesInfo">NIST Special Publication 800-56A Revision 3</span>, <time datetime="2018-04" class="refDate">April 2018</time>, <span>&lt;<a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf">https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2104">[RFC2104]</dt>
        <dd>
<span class="refAuthor">Krawczyk, H.</span>, <span class="refAuthor">Bellare, M.</span>, and <span class="refAuthor">R. Canetti</span>, <span class="refTitle">"HMAC: Keyed-Hashing for Message Authentication"</span>, <span class="seriesInfo">RFC 2104</span>, <span class="seriesInfo">DOI 10.17487/RFC2104</span>, <time datetime="1997-02" class="refDate">February 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2104">https://www.rfc-editor.org/info/rfc2104</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="RFC3748">[RFC3748]</dt>
        <dd>
<span class="refAuthor">Aboba, B.</span>, <span class="refAuthor">Blunk, L.</span>, <span class="refAuthor">Vollbrecht, J.</span>, <span class="refAuthor">Carlson, J.</span>, and <span class="refAuthor">H. Levkowetz, Ed.</span>, <span class="refTitle">"Extensible Authentication Protocol (EAP)"</span>, <span class="seriesInfo">RFC 3748</span>, <span class="seriesInfo">DOI 10.17487/RFC3748</span>, <time datetime="2004-06" class="refDate">June 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3748">https://www.rfc-editor.org/info/rfc3748</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4648">[RFC4648]</dt>
        <dd>
<span class="refAuthor">Josefsson, S.</span>, <span class="refTitle">"The Base16, Base32, and Base64 Data Encodings"</span>, <span class="seriesInfo">RFC 4648</span>, <span class="seriesInfo">DOI 10.17487/RFC4648</span>, <time datetime="2006-10" class="refDate">October 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4648">https://www.rfc-editor.org/info/rfc4648</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5247">[RFC5247]</dt>
        <dd>
<span class="refAuthor">Aboba, B.</span>, <span class="refAuthor">Simon, D.</span>, and <span class="refAuthor">P. Eronen</span>, <span class="refTitle">"Extensible Authentication Protocol (EAP) Key Management Framework"</span>, <span class="seriesInfo">RFC 5247</span>, <span class="seriesInfo">DOI 10.17487/RFC5247</span>, <time datetime="2008-08" class="refDate">August 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5247">https://www.rfc-editor.org/info/rfc5247</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6234">[RFC6234]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span> and <span class="refAuthor">T. Hansen</span>, <span class="refTitle">"US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)"</span>, <span class="seriesInfo">RFC 6234</span>, <span class="seriesInfo">DOI 10.17487/RFC6234</span>, <time datetime="2011-05" class="refDate">May 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6234">https://www.rfc-editor.org/info/rfc6234</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7517">[RFC7517]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refTitle">"JSON Web Key (JWK)"</span>, <span class="seriesInfo">RFC 7517</span>, <span class="seriesInfo">DOI 10.17487/RFC7517</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7517">https://www.rfc-editor.org/info/rfc7517</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7518">[RFC7518]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refTitle">"JSON Web Algorithms (JWA)"</span>, <span class="seriesInfo">RFC 7518</span>, <span class="seriesInfo">DOI 10.17487/RFC7518</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7518">https://www.rfc-editor.org/info/rfc7518</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7542">[RFC7542]</dt>
        <dd>
<span class="refAuthor">DeKok, A.</span>, <span class="refTitle">"The Network Access Identifier"</span>, <span class="seriesInfo">RFC 7542</span>, <span class="seriesInfo">DOI 10.17487/RFC7542</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7542">https://www.rfc-editor.org/info/rfc7542</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7748">[RFC7748]</dt>
        <dd>
<span class="refAuthor">Langley, A.</span>, <span class="refAuthor">Hamburg, M.</span>, and <span class="refAuthor">S. Turner</span>, <span class="refTitle">"Elliptic Curves for Security"</span>, <span class="seriesInfo">RFC 7748</span>, <span class="seriesInfo">DOI 10.17487/RFC7748</span>, <time datetime="2016-01" class="refDate">January 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7748">https://www.rfc-editor.org/info/rfc7748</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8037">[RFC8037]</dt>
        <dd>
<span class="refAuthor">Liusvaara, I.</span>, <span class="refTitle">"CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)"</span>, <span class="seriesInfo">RFC 8037</span>, <span class="seriesInfo">DOI 10.17487/RFC8037</span>, <time datetime="2017-01" class="refDate">January 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8037">https://www.rfc-editor.org/info/rfc8037</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</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="RFC8259">[RFC8259]</dt>
      <dd>
<span class="refAuthor">Bray, T., Ed.</span>, <span class="refTitle">"The JavaScript Object Notation (JSON) Data Interchange Format"</span>, <span class="seriesInfo">STD 90</span>, <span class="seriesInfo">RFC 8259</span>, <span class="seriesInfo">DOI 10.17487/RFC8259</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8259">https://www.rfc-editor.org/info/rfc8259</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="Bluetooth">[Bluetooth]</dt>
        <dd>
<span class="refAuthor">Bluetooth Special Interest Group</span>, <span class="refTitle">"Bluetooth Core Specification Version 5.3"</span>, <time datetime="2021-07" class="refDate">July 2021</time>, <span>&lt;<a href="https://www.bluetooth.com/specifications/bluetooth-core-specification">https://www.bluetooth.com/specifications/bluetooth-core-specification</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IEEE-802.1X">[IEEE-802.1X]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"IEEE Standard for Local and Metropolitan Area Networks--Port-Based Network Access Control"</span>, <span class="seriesInfo">IEEE Standard 802.1X-2020</span>, <time datetime="2020-02" class="refDate">February 2020</time>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-rats-eat">[RATS-EAT]</dt>
        <dd>
<span class="refAuthor">Lundblade, L.</span>, <span class="refAuthor">Mandyam, G.</span>, and <span class="refAuthor">J. O'Donoghue</span>, <span class="refTitle">"The Entity Attestation Token (EAT)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rats-eat-11</span>, <time datetime="2021-10-24" class="refDate">24 October 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-11">https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-11</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2904">[RFC2904]</dt>
        <dd>
<span class="refAuthor">Vollbrecht, J.</span>, <span class="refAuthor">Calhoun, P.</span>, <span class="refAuthor">Farrell, S.</span>, <span class="refAuthor">Gommans, L.</span>, <span class="refAuthor">Gross, G.</span>, <span class="refAuthor">de Bruijn, B.</span>, <span class="refAuthor">de Laat, C.</span>, <span class="refAuthor">Holdrege, M.</span>, and <span class="refAuthor">D. Spence</span>, <span class="refTitle">"AAA Authorization Framework"</span>, <span class="seriesInfo">RFC 2904</span>, <span class="seriesInfo">DOI 10.17487/RFC2904</span>, <time datetime="2000-08" class="refDate">August 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2904">https://www.rfc-editor.org/info/rfc2904</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3986">[RFC3986]</dt>
        <dd>
<span class="refAuthor">Berners-Lee, T.</span>, <span class="refAuthor">Fielding, R.</span>, and <span class="refAuthor">L. Masinter</span>, <span class="refTitle">"Uniform Resource Identifier (URI): Generic Syntax"</span>, <span class="seriesInfo">STD 66</span>, <span class="seriesInfo">RFC 3986</span>, <span class="seriesInfo">DOI 10.17487/RFC3986</span>, <time datetime="2005-01" class="refDate">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3986">https://www.rfc-editor.org/info/rfc3986</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4137">[RFC4137]</dt>
        <dd>
<span class="refAuthor">Vollbrecht, J.</span>, <span class="refAuthor">Eronen, P.</span>, <span class="refAuthor">Petroni, N.</span>, and <span class="refAuthor">Y. Ohba</span>, <span class="refTitle">"State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator"</span>, <span class="seriesInfo">RFC 4137</span>, <span class="seriesInfo">DOI 10.17487/RFC4137</span>, <time datetime="2005-08" class="refDate">August 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4137">https://www.rfc-editor.org/info/rfc4137</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5056">[RFC5056]</dt>
        <dd>
<span class="refAuthor">Williams, N.</span>, <span class="refTitle">"On the Use of Channel Bindings to Secure Channels"</span>, <span class="seriesInfo">RFC 5056</span>, <span class="seriesInfo">DOI 10.17487/RFC5056</span>, <time datetime="2007-11" class="refDate">November 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5056">https://www.rfc-editor.org/info/rfc5056</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5216">[RFC5216]</dt>
        <dd>
<span class="refAuthor">Simon, D.</span>, <span class="refAuthor">Aboba, B.</span>, and <span class="refAuthor">R. Hurst</span>, <span class="refTitle">"The EAP-TLS Authentication Protocol"</span>, <span class="seriesInfo">RFC 5216</span>, <span class="seriesInfo">DOI 10.17487/RFC5216</span>, <time datetime="2008-03" class="refDate">March 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5216">https://www.rfc-editor.org/info/rfc5216</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6677">[RFC6677]</dt>
        <dd>
<span class="refAuthor">Hartman, S., Ed.</span>, <span class="refAuthor">Clancy, T.</span>, and <span class="refAuthor">K. Hoeper</span>, <span class="refTitle">"Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods"</span>, <span class="seriesInfo">RFC 6677</span>, <span class="seriesInfo">DOI 10.17487/RFC6677</span>, <time datetime="2012-07" class="refDate">July 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6677">https://www.rfc-editor.org/info/rfc6677</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Sethi14">[Sethi14]</dt>
        <dd>
<span class="refAuthor">Sethi, M.</span>, <span class="refAuthor">Oat, E.</span>, <span class="refAuthor">Di Francesco, M.</span>, and <span class="refAuthor">T. Aura</span>, <span class="refTitle">"Secure bootstrapping of cloud-managed ubiquitous displays"</span>, <span class="refContent">Proceedings of ACM International Joint Conference on Pervasive and
   Ubiquitous Computing (UbiComp 2014), pp. 739-750, Seattle, USA</span>, <span class="seriesInfo">DOI 10.1145/2632048.2632049</span>, <time datetime="2014-09" class="refDate">September 2014</time>, <span>&lt;<a href="http://dx.doi.org/10.1145/2632048.2632049">http://dx.doi.org/10.1145/2632048.2632049</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Sethi19">[Sethi19]</dt>
        <dd>
<span class="refAuthor">Sethi, M.</span>, <span class="refAuthor">Peltonen, A.</span>, and <span class="refAuthor">T. Aura</span>, <span class="refTitle">"Misbinding Attacks on Secure Device Pairing and Bootstrapping"</span>, <span class="seriesInfo">DOI 10.1145/3321705.3329813</span>, <time datetime="2019-02" class="refDate">February 2019</time>, <span>&lt;<a href="https://arxiv.org/abs/1902.07550">https://arxiv.org/abs/1902.07550</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.tschofenig-tls-cwt">[TLS-CWT]</dt>
      <dd>
<span class="refAuthor">Tschofenig, H.</span> and <span class="refAuthor">M. Brossard</span>, <span class="refTitle">"Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-tschofenig-tls-cwt-02</span>, <time datetime="2020-07-13" class="refDate">13 July 2020</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-tschofenig-tls-cwt-02">https://datatracker.ietf.org/doc/html/draft-tschofenig-tls-cwt-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="exchangeappendix">
<section id="appendix-A">
      <h2 id="name-exchanges-and-events-per-st">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-exchanges-and-events-per-st" class="section-name selfRef">Exchanges and Events per State</a>
      </h2>
<p id="appendix-A-1"><a href="#tab-exchanges" class="xref">Table 14</a> shows how the EAP server chooses the
      exchange type depending on the server and peer states. In the state combinations
      marked with hyphen "-", there is no possible exchange and user action is required to
      make progress. Note that peer state 4 is omitted from the table because the peer never
      connects to the server when the peer is in that state. The table also shows the
      handling of errors in each exchange. A notable detail is that the recipient of error
      code 2003 moves to state 1.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<span id="name-how-the-server-chooses-the-"></span><div id="tab-exchanges">
<table class="center" id="table-14">
        <caption>
<a href="#table-14" class="selfRef">Table 14</a>:
<a href="#name-how-the-server-chooses-the-" class="selfRef">How the Server Chooses the Exchange Type</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Peer States</th>
            <th class="text-left" rowspan="1" colspan="1">Exchange Chosen by the Server</th>
            <th class="text-left" rowspan="1" colspan="1">Next Peer and Server States</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-center" rowspan="1" colspan="3">Server State: Unregistered (0)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0..2</td>
            <td class="text-left" rowspan="1" colspan="1">Initial Exchange</td>
            <td class="text-left" rowspan="1" colspan="1">both 1 (0 on error)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">3</td>
            <td class="text-left" rowspan="1" colspan="1">-</td>
            <td class="text-left" rowspan="1" colspan="1">no change, notify user</td>
          </tr>
          <tr>
            <td class="text-center" rowspan="1" colspan="3">Server State: Waiting for OOB (1)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0</td>
            <td class="text-left" rowspan="1" colspan="1">Initial Exchange</td>
            <td class="text-left" rowspan="1" colspan="1">both 1 (0 on error)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1</td>
            <td class="text-left" rowspan="1" colspan="1">Waiting Exchange</td>
            <td class="text-left" rowspan="1" colspan="1">both 1 (no change on error)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">2</td>
            <td class="text-left" rowspan="1" colspan="1">Completion Exchange</td>
            <td class="text-left" rowspan="1" colspan="1">both 4 (A)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">3</td>
            <td class="text-left" rowspan="1" colspan="1">-</td>
            <td class="text-left" rowspan="1" colspan="1">no change, notify user</td>
          </tr>
          <tr>
            <td class="text-center" rowspan="1" colspan="3">Server State: OOB Received (2)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0</td>
            <td class="text-left" rowspan="1" colspan="1">Initial Exchange</td>
            <td class="text-left" rowspan="1" colspan="1">both 1 (0 on error)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1</td>
            <td class="text-left" rowspan="1" colspan="1">Completion Exchange</td>
            <td class="text-left" rowspan="1" colspan="1">both 4 (B)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">2</td>
            <td class="text-left" rowspan="1" colspan="1">Completion Exchange</td>
            <td class="text-left" rowspan="1" colspan="1">both 4 (A)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">3</td>
            <td class="text-left" rowspan="1" colspan="1">-</td>
            <td class="text-left" rowspan="1" colspan="1">no change, notify user</td>
          </tr>
          <tr>
            <td class="text-center" rowspan="1" colspan="3">Server State: Reconnecting (3) or Registered
     (4)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0..2</td>
            <td class="text-left" rowspan="1" colspan="1">-</td>
            <td class="text-left" rowspan="1" colspan="1">no change, notify user</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">3</td>
            <td class="text-left" rowspan="1" colspan="1">Reconnect Exchange</td>
            <td class="text-left" rowspan="1" colspan="1">both 4 (3 on error)</td>
          </tr>
        </tbody>
      </table>
</div>
<span class="break"></span><dl class="dlParallel" id="appendix-A-3">
        <dt id="appendix-A-3.1">(A)</dt>
        <dd style="margin-left: 1.5em" id="appendix-A-3.2">peer to 1 on error 2003; no other changes on error<a href="#appendix-A-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-A-3.3">(B)</dt>
        <dd style="margin-left: 1.5em" id="appendix-A-3.4">server to 1 on error 2003; no other changes on error<a href="#appendix-A-3.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="appendix-A-4"><a href="#tab-localevents" class="xref">Table 15</a> lists the local events that can
      take place in the server or peer. Both the server and peer output and accept OOB
      messages in association state 1, leading the receiver to state 2. Communication errors
      and timeouts in states 0..2 lead back to state 0, while similar errors in states 3..4
      lead to state 3. An application request for rekeying (e.g., to refresh session keys or
      to upgrade cryptosuite) also takes the association from state 3..4 to state 3. The user
      can always reset the association state to 0. Recovering association data, e.g., from a
      backup, leads to state 3.<a href="#appendix-A-4" class="pilcrow">¶</a></p>
<span id="name-local-events-in-the-server-"></span><div id="tab-localevents">
<table class="center" id="table-15">
        <caption>
<a href="#table-15" class="selfRef">Table 15</a>:
<a href="#name-local-events-in-the-server-" class="selfRef">Local Events in the Server and Peer</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Server/Peer State</th>
            <th class="text-left" rowspan="1" colspan="1">Possible Local Events in the Server and Peer</th>
            <th class="text-left" rowspan="1" colspan="1">Next State</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1</td>
            <td class="text-left" rowspan="1" colspan="1">OOB Output</td>
            <td class="text-left" rowspan="1" colspan="1">1</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">1</td>
            <td class="text-left" rowspan="1" colspan="1">OOB Input</td>
            <td class="text-left" rowspan="1" colspan="1">2 (1 on error)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0..2</td>
            <td class="text-left" rowspan="1" colspan="1">Mobility/timeout/network failure</td>
            <td class="text-left" rowspan="1" colspan="1">0</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">3..4</td>
            <td class="text-left" rowspan="1" colspan="1">Mobility/timeout/network failure</td>
            <td class="text-left" rowspan="1" colspan="1">3</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">3..4</td>
            <td class="text-left" rowspan="1" colspan="1">Rekeying request</td>
            <td class="text-left" rowspan="1" colspan="1">3</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0..4</td>
            <td class="text-left" rowspan="1" colspan="1">User resets association</td>
            <td class="text-left" rowspan="1" colspan="1">0</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0..4</td>
            <td class="text-left" rowspan="1" colspan="1">Association state recovery</td>
            <td class="text-left" rowspan="1" colspan="1">3</td>
          </tr>
        </tbody>
      </table>
</div>
</section>
</div>
<div id="oobchannelappendix">
<section id="appendix-B">
      <h2 id="name-application-specific-parame">
<a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-application-specific-parame" class="section-name selfRef">Application-Specific Parameters</a>
      </h2>
<p id="appendix-B-1"><a href="#tab-oobchannel" class="xref">Table 16</a> lists OOB channel parameters that
      need to be specified in each application that makes use of EAP-NOOB. The list is not
      exhaustive and is included for the convenience of implementers only.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<span id="name-oob-channel-characteristics"></span><div id="tab-oobchannel">
<table class="center" id="table-16">
        <caption>
<a href="#table-16" class="selfRef">Table 16</a>:
<a href="#name-oob-channel-characteristics" class="selfRef">OOB Channel Characteristics</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Parameter</th>
            <th class="text-left" rowspan="1" colspan="1">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">OobDirs</td>
            <td class="text-left" rowspan="1" colspan="1">Allowed directions of the OOB channel.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">OobMessageEncoding</td>
            <td class="text-left" rowspan="1" colspan="1">How the OOB message data fields are encoded for the OOB
     channel.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">SleepTimeDefault</td>
            <td class="text-left" rowspan="1" colspan="1">Default minimum time in seconds that the peer should sleep before
     the next Waiting Exchange.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">OobRetries</td>
            <td class="text-left" rowspan="1" colspan="1">Number of received OOB messages with invalid Hoob, after which the
     receiver moves to Unregistered (0) state. When the OOB channel has error detection
     or correction, the <span class="bcp14">RECOMMENDED</span> value is 5.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">NoobTimeout</td>
            <td class="text-left" rowspan="1" colspan="1">How many seconds the sender of the OOB message remembers the sent
     Noob value. The <span class="bcp14">RECOMMENDED</span> value is 3600 seconds.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">ServerInfoType</td>
            <td class="text-left" rowspan="1" colspan="1">The value of the Type field and the other required fields in
     ServerInfo.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">PeerInfoType</td>
            <td class="text-left" rowspan="1" colspan="1">The value of the Type field and the other required fields in
     PeerInfo.</td>
          </tr>
        </tbody>
      </table>
</div>
</section>
</div>
<div id="roaming">
<section id="appendix-C">
      <h2 id="name-eap-noob-roaming">
<a href="#appendix-C" class="section-number selfRef">Appendix C. </a><a href="#name-eap-noob-roaming" class="section-name selfRef">EAP-NOOB Roaming</a>
      </h2>
<p id="appendix-C-1">AAA architectures <span>[<a href="#RFC2904" class="xref">RFC2904</a>]</span> allow for roaming of
      network-connected appliances that are authenticated over EAP. While the peer is roaming
      in a visited network, authentication still takes place between the peer and an
      authentication server at its home network. EAP-NOOB supports such roaming by allowing
      the server to assign a NAI to the peer. After the NAI has been assigned, it enables the
      visited network to route the EAP session to the peer's home AAA server.<a href="#appendix-C-1" class="pilcrow">¶</a></p>
<p id="appendix-C-2">A peer device that is new or has gone through a hard reset should be connected first
      to the home network and establish an EAP-NOOB association with its home AAA server
      before it is able to roam. After that, it can perform the Reconnect Exchange from the
      visited network.<a href="#appendix-C-2" class="pilcrow">¶</a></p>
<p id="appendix-C-3">Alternatively, the device may provide some method for the user to configure the NAI
      of the home network. This is the user or application-configured NAI mentioned in <a href="#nai" class="xref">Section 3.3.1</a>. In that case, the EAP-NOOB association can be created
      while roaming. The configured NAI enables the EAP messages to be routed correctly to the
      home AAA server.<a href="#appendix-C-3" class="pilcrow">¶</a></p>
<p id="appendix-C-4">While roaming, the device needs to identify the networks where the EAP-NOOB
      association can be used to gain network access. For 802.11 access networks, the server
      <span class="bcp14">MAY</span> send a list of SSID strings in the ServerInfo field, called either
      SSIDList or Base64SSIDList. The list is formatted as explained in <a href="#tab-serverinfo-meaning" class="xref">Table 6</a>. If present, the peer
      <span class="bcp14">MAY</span> use this list as a hint to determine the networks where the EAP-NOOB
      association can be used for access authorization, in addition to the access network
      where the Initial Exchange took place.<a href="#appendix-C-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="urloob">
<section id="appendix-D">
      <h2 id="name-oob-message-as-a-url">
<a href="#appendix-D" class="section-number selfRef">Appendix D. </a><a href="#name-oob-message-as-a-url" class="section-name selfRef">OOB Message as a URL</a>
      </h2>
<p id="appendix-D-1">While EAP-NOOB does not mandate any particular OOB communication channel, typical OOB
      channels include graphical displays and emulated NFC tags. In the peer-to-server
      direction, it may be convenient to encode the OOB message as a URL, which is then
      encoded as a QR code for displays and printers or as an NFC Data Exchange Format (NDEF)
      record for dynamic NFC
      tags. A user can then simply scan the QR code or NFC tag and open the URL, which causes
      the OOB message to be delivered to the authentication server. The URL
      <span class="bcp14">MUST</span> specify https or another server-authenticated scheme so that there
      is a secure connection to the server and the on-path attacker cannot read or modify the
      OOB message.<a href="#appendix-D-1" class="pilcrow">¶</a></p>
<p id="appendix-D-2">The ServerInfo in this case includes a field called ServerURL of the following format
      with a <span class="bcp14">RECOMMENDED</span> length of at most 60 characters:<a href="#appendix-D-2" class="pilcrow">¶</a></p>
<p id="appendix-D-3"><code>https://&lt;host&gt;[:&lt;port&gt;]/[&lt;path&gt;]</code><a href="#appendix-D-3" class="pilcrow">¶</a></p>
<p id="appendix-D-4">To this, the peer appends the OOB message fields (PeerId, Noob, and Hoob) as a query
      string. PeerId is provided to the peer by the server and might be a 22-character ASCII
      string. The peer base64url encodes, without padding, the 16-byte values Noob and Hoob
      into 22-character ASCII strings. The query parameters <span class="bcp14">MAY</span> be in any
      order. The resulting URL is of the following format:<a href="#appendix-D-4" class="pilcrow">¶</a></p>
<p id="appendix-D-5"><code>https://&lt;host&gt;[:&lt;port&gt;]/[&lt;path&gt;]?P=&lt;PeerId&gt;&amp;N=&lt;Noob&gt;&amp;H=&lt;Hoob&gt;</code><a href="#appendix-D-5" class="pilcrow">¶</a></p>
<p id="appendix-D-6">The following is an example of a well-formed URL encoding the OOB message (without
      line breaks):<a href="#appendix-D-6" class="pilcrow">¶</a></p>
<p id="appendix-D-7"><code>https://aaa.example.com/eapnoob?P=mcm5BSCDZ45cYPlAr1ghNw&amp;N=rMinS0-F4EfCU8D9ljxX_A&amp;H=QvnMp4UGxuQVFaXPW_14UW</code><a href="#appendix-D-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="acks">
<section id="appendix-E">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-E-1"><span class="contact-name">Max Crone</span>, <span class="contact-name">Shiva Prasad TP</span>, and <span class="contact-name">Raghavendra MS</span> implemented parts of this protocol with wpa_supplicant and
      hostapd. <span class="contact-name">Eduardo Inglés</span> and <span class="contact-name">Dan       Garcia-Carrillo</span> were involved in the
      implementation of this protocol on Contiki. Their inputs helped us in improving the
      specification.<a href="#appendix-E-1" class="pilcrow">¶</a></p>
<p id="appendix-E-2">The authors would like to thank <span class="contact-name">Rhys Smith</span> and <span class="contact-name">Josh Howlett</span> for providing valuable feedback, as well as new use cases and
      requirements for the protocol. Thanks to <span class="contact-name">Eric Rescorla</span>, <span class="contact-name">Alan Dekok</span>, <span class="contact-name">Darshak Thakore</span>, <span class="contact-name">Stefan Winter</span>, <span class="contact-name">Hannes Tschofenig</span>, <span class="contact-name">Daniel Migault</span>, <span class="contact-name">Roman Danyliw</span>, <span class="contact-name">Benjamin Kaduk</span>, <span class="contact-name">Francesca Palombini</span>, <span class="contact-name">Steve Hanna</span>, <span class="contact-name">Lars Eggert</span>, and <span class="contact-name">Éric       Vyncke</span> for their comments and reviews.<a href="#appendix-E-2" class="pilcrow">¶</a></p>
<p id="appendix-E-3">We would also like to express our sincere gratitude to <span class="contact-name">Dave       Thaler</span> for his thorough review of the document.<a href="#appendix-E-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-F">
      <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">Tuomas Aura</span></div>
<div dir="auto" class="left"><span class="org">Aalto University</span></div>
<div dir="auto" class="left">FI-<span class="postal-code">00076</span> <span class="locality">Aalto</span>
</div>
<div dir="auto" class="left"><span class="country-name">Finland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:tuomas.aura@aalto.fi" class="email">tuomas.aura@aalto.fi</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Mohit Sethi</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left">FI-<span class="postal-code">02420</span> <span class="locality">Jorvas</span>
</div>
<div dir="auto" class="left"><span class="country-name">Finland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mohit@iki.fi" class="email">mohit@iki.fi</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Aleksi Peltonen</span></div>
<div dir="auto" class="left"><span class="org">Aalto University</span></div>
<div dir="auto" class="left">FI-<span class="postal-code">00076</span> <span class="locality">Aalto</span>
</div>
<div dir="auto" class="left"><span class="country-name">Finland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:aleksi.peltonen@aalto.fi" class="email">aleksi.peltonen@aalto.fi</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>