File: rfc9191.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 (2054 lines) | stat: -rw-r--r-- 88,924 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 9191: Handling Large Certificates and Long Certificate Chains in TLS‑Based EAP Methods</title>
<meta content="Mohit Sethi" name="author">
<meta content="John Preuß Mattsson" name="author">
<meta content="Sean Turner" name="author">
<meta content="
       
 The Extensible Authentication Protocol (EAP), defined in RFC
 3748, provides a standard mechanism for support of multiple
 authentication methods. EAP-TLS and other TLS-based EAP
 methods are widely deployed and used for network access
 authentication. Large certificates and long certificate chains
 combined with authenticators that drop an EAP session after
 only 40 - 50 round trips is a major deployment problem. This
 document looks at this problem in detail and describes the
 potential solutions available.
       
    " name="description">
<meta content="xml2rfc 3.12.1" name="generator">
<meta content="EAP-TLS" name="keyword">
<meta content="X.509" name="keyword">
<meta content="EAP authenticator" name="keyword">
<meta content="Maximum Transmission Unit" name="keyword">
<meta content="9191" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.1
    Python 3.6.15
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9191.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/rfc9191" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert-08" 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 9191</td>
<td class="center">Certificates in TLS-Based EAP Methods</td>
<td class="right">February 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Sethi, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9191" class="eref">9191</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-02" class="published">February 2022</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">M. Sethi</div>
<div class="org">Ericsson</div>
</div>
<div class="author">
      <div class="author-name">J. Preuß Mattsson</div>
<div class="org">Ericsson</div>
</div>
<div class="author">
      <div class="author-name">S. Turner</div>
<div class="org">sn3rd</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9191</h1>
<h1 id="title">Handling Large Certificates and Long Certificate Chains in TLS‑Based EAP Methods</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), defined in RFC
 3748, provides a standard mechanism for support of multiple
 authentication methods. EAP-TLS and other TLS-based EAP
 methods are widely deployed and used for network access
 authentication. Large certificates and long certificate chains
 combined with authenticators that drop an EAP session after
 only 40 - 50 round trips is a major deployment problem. This
 document looks at this problem in detail and describes the
 potential solutions available.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This 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).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9191">https://www.rfc-editor.org/info/rfc9191</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-experience-with-deployments" class="xref">Experience with Deployments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-handling-of-large-certifica" class="xref">Handling of Large Certificates and Long Certificate Chains</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-updating-certificates-and-c" class="xref">Updating Certificates and Certificate Chains</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1.2.1">
                    <p id="section-toc.1-1.4.2.1.2.1.1"><a href="#section-4.1.1" class="xref">4.1.1</a>.  <a href="#name-guidelines-for-certificates" class="xref">Guidelines for Certificates</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1.2.2">
                    <p id="section-toc.1-1.4.2.1.2.2.1"><a href="#section-4.1.2" class="xref">4.1.2</a>.  <a href="#name-pre-distributing-and-omitti" class="xref">Pre-distributing and Omitting CA Certificates</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1.2.3">
                    <p id="section-toc.1-1.4.2.1.2.3.1"><a href="#section-4.1.3" class="xref">4.1.3</a>.  <a href="#name-using-fewer-intermediate-ce" class="xref">Using Fewer Intermediate Certificates</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-updating-tls-and-eap-tls-co" class="xref">Updating TLS and EAP-TLS Code</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.1">
                    <p id="section-toc.1-1.4.2.2.2.1.1"><a href="#section-4.2.1" class="xref">4.2.1</a>.  <a href="#name-urls-for-client-certificate" class="xref">URLs for Client Certificates</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.2">
                    <p id="section-toc.1-1.4.2.2.2.2.1"><a href="#section-4.2.2" class="xref">4.2.2</a>.  <a href="#name-caching-certificates" class="xref">Caching Certificates</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.3">
                    <p id="section-toc.1-1.4.2.2.2.3.1"><a href="#section-4.2.3" class="xref">4.2.3</a>.  <a href="#name-compressing-certificates" class="xref">Compressing Certificates</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.4">
                    <p id="section-toc.1-1.4.2.2.2.4.1"><a href="#section-4.2.4" class="xref">4.2.4</a>.  <a href="#name-compact-tls-13" class="xref">Compact TLS 1.3</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.5">
                    <p id="section-toc.1-1.4.2.2.2.5.1"><a href="#section-4.2.5" class="xref">4.2.5</a>.  <a href="#name-suppressing-intermediate-ce" class="xref">Suppressing Intermediate Certificates</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.6">
                    <p id="section-toc.1-1.4.2.2.2.6.1"><a href="#section-4.2.6" class="xref">4.2.6</a>.  <a href="#name-raw-public-keys" class="xref">Raw Public Keys</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.7">
                    <p id="section-toc.1-1.4.2.2.2.7.1"><a href="#section-4.2.7" class="xref">4.2.7</a>.  <a href="#name-new-certificate-types-and-c" class="xref">New Certificate Types and Compression Algorithms</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-updating-authenticators" class="xref">Updating Authenticators</a></p>
</li>
            </ul>
</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>
</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>
</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"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">


The Extensible Authentication Protocol (EAP), defined in <span>[<a href="#RFC3748" class="xref">RFC3748</a>]</span>, provides a standard mechanism for support
of multiple authentication methods. EAP-TLS <span>[<a href="#RFC5216" class="xref">RFC5216</a>]</span> <span>[<a href="#RFC9190" class="xref">RFC9190</a>]</span> relies on TLS
<span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span> to provide strong mutual
authentication with certificates <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span> and
is widely deployed and often used for network access authentication.


There are also many other standardized TLS-based EAP methods such as Flexible
Authentication via Secure Tunneling (EAP-FAST) <span>[<a href="#RFC4851" class="xref">RFC4851</a>]</span>, Tunneled Transport Layer Security (EAP-TTLS) <span>[<a href="#RFC5281" class="xref">RFC5281</a>]</span>, the Tunnel Extensible Authentication Protocol
(TEAP) <span>[<a href="#RFC7170" class="xref">RFC7170</a>]</span>, as well as several
vendor-specific EAP methods such as the Protected Extensible Authentication Protocol (PEAP) <span>[<a href="#PEAP" class="xref">PEAP</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
 Certificates in EAP deployments can be relatively large, and the certificate chains can be long. Unlike the use of TLS on the web, where typically only the TLS server is authenticated, EAP-TLS deployments typically authenticate both the EAP peer and the EAP server. Also, from deployment experience, EAP peers typically have longer certificate chains than servers. This is because EAP peers often follow organizational hierarchies and tend to have many intermediate certificates. Thus, EAP-TLS authentication usually involves exchange of significantly more octets than when TLS is used as part of HTTPS.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
 <span><a href="https://www.rfc-editor.org/rfc/rfc3748#section-3.1" class="relref">Section 3.1</a> of [<a href="#RFC3748" class="xref">RFC3748</a>]</span> states that EAP implementations can
 assume a Maximum Transmission Unit (MTU) of at least
 1020 octets from lower layers. The EAP fragment size
 in typical deployments is just 1020 - 1500 octets
 (since the maximum Ethernet frame size is ~ 1500
 bytes). Thus, EAP-TLS authentication needs to be
 fragmented into many smaller packets for
 transportation over the lower layers. Such
 fragmentation not only can negatively affect the
 latency, but also results in other challenges.


 For example, some EAP authenticator (e.g., an access
 point) implementations will drop an EAP session if it
 has not finished after 40 - 50 round trips. This is a
 major problem and means that, in many situations, the
 EAP peer cannot perform network access authentication
 even though both the sides have valid credentials for
 successful authentication and key derivation.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
 Not all EAP deployments are constrained by the MTU of
 the lower layer. For example, some implementations
 support EAP over Ethernet "jumbo" frames that can
 easily allow very large EAP packets. Larger packets
 will naturally help lower the number of round trips
 required for successful EAP-TLS
 authentication. However, deployment experience has
 shown that these jumbo frames are not always
 implemented correctly. Additionally, EAP fragment size
 is also restricted by protocols such as RADIUS <span>[<a href="#RFC2865" class="xref">RFC2865</a>]</span>, which are
 responsible for transporting EAP messages between an
 authenticator and an EAP server. RADIUS can generally
 transport only about 4000 octets of EAP in a single
 message (the maximum length of a RADIUS packet is
 restricted to 4096 octets in <span>[<a href="#RFC2865" class="xref">RFC2865</a>]</span>).<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
 This document looks at related work and potential
 tools available for overcoming the deployment
 challenges induced by large certificates and long
 certificate chains.

  It then discusses the solutions available to overcome
  these challenges. Many of the solutions require TLS
  1.3 <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>. The IETF has
  standardized EAP-TLS 1.3 <span>[<a href="#RFC9190" class="xref">RFC9190</a>]</span> and
  is working on specifications such as <span>[<a href="#TLS-EAP-TYPES" class="xref">TLS-EAP-TYPES</a>]</span> for how other TLS-based EAP
  methods use TLS 1.3.<a href="#section-1-5" class="pilcrow">¶</a></p>
</section>
<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">
 Readers are expected to be familiar with the terms and
 concepts used in EAP <span>[<a href="#RFC3748" class="xref">RFC3748</a>]</span>, EAP-TLS <span>[<a href="#RFC5216" class="xref">RFC5216</a>]</span>, and TLS <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>. In particular, 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="dlParallel" 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. Typically implemented
 as part of a network switch or a
 wireless access point.<a href="#section-2-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.3">EAP 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. In EAP-TLS,
 the EAP peer implements the TLS client
 role.<a href="#section-2-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.5">EAP 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. In
 EAP-TLS, the EAP server implements the
 TLS server role.<a href="#section-2-3.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-2-4">
 The document additionally uses the terms "trust anchor" and "certification path" defined in <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span>.<a href="#section-2-4" class="pilcrow">¶</a></p>
</section>
<section id="section-3">
      <h2 id="name-experience-with-deployments">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-experience-with-deployments" class="section-name selfRef">Experience with Deployments</a>
      </h2>
<p id="section-3-1">
 As stated earlier, the EAP fragment size in typical deployments is just 1020 - 1500 octets. A certificate can, however, be large for a number of reasons:<a href="#section-3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-2.1">It can have a long Subject Alternative Name field.<a href="#section-3-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-2.2">It can have long Public Key and Signature fields.<a href="#section-3-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-2.3">It can contain multiple object identifiers (OIDs) that indicate the
        permitted uses of the certificate as noted in <span><a href="https://www.rfc-editor.org/rfc/rfc5216#section-5.3" class="relref">Section 5.3</a> of [<a href="#RFC5216" class="xref">RFC5216</a>]</span>. Most implementations verify the
        presence of these OIDs for successful authentication.<a href="#section-3-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-2.4">It can contain multiple organization naming fields to reflect the
        multiple group memberships of a user (in a client certificate).<a href="#section-3-2.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-3">
 A certificate chain (called a certification path in
 <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span>) in EAP-TLS
 can commonly have 2 - 6 intermediate certificates
 between the end-entity certificate and the trust
 anchor.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">
 The size of certificates (and certificate chains) may
 also increase manyfold in the future with the
 introduction of post-quantum cryptography. For
 example, lattice-based cryptography would have public
 keys of approximately 1000 bytes and signatures of
 approximately 2000 bytes.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">
 Many access point implementations drop EAP sessions
 that do not complete within 40 - 50 round trips. This
 means that if the chain is larger than ~ 60 kilobytes,
 EAP-TLS authentication cannot complete successfully in
 most deployments.<a href="#section-3-5" class="pilcrow">¶</a></p>
</section>
<div id="handle-large-cert-long-chain">
<section id="section-4">
      <h2 id="name-handling-of-large-certifica">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-handling-of-large-certifica" class="section-name selfRef">Handling of Large Certificates and Long Certificate Chains</a>
      </h2>
<p id="section-4-1">
 This section discusses some possible alternatives for overcoming the challenge of large certificates and long certificate chains in EAP-TLS authentication. <a href="#update-certs" class="xref">Section 4.1</a> considers recommendations that require an update of the certificates or certificate chains used for EAP-TLS authentication without requiring changes to the existing EAP-TLS code base. It also provides some guidelines that should be followed when issuing certificates for use with EAP-TLS. <a href="#update-code" class="xref">Section 4.2</a> considers recommendations that rely on updates to the EAP-TLS implementations and can be deployed with existing certificates. Finally, <a href="#update-APs" class="xref">Section 4.3</a> briefly discusses what could be done to update or reconfigure authenticators when it is infeasible to replace deployed components giving a solution that can be deployed without changes to existing certificates or code.<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="update-certs">
<section id="section-4.1">
        <h3 id="name-updating-certificates-and-c">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-updating-certificates-and-c" class="section-name selfRef">Updating Certificates and Certificate Chains</a>
        </h3>
<p id="section-4.1-1">
 Many IETF protocols now use elliptic curve cryptography (ECC) <span>[<a href="#RFC6090" class="xref">RFC6090</a>]</span> for the underlying cryptographic operations. The use of ECC can reduce the size of certificates and signatures. For example, at a 128-bit security level, the size of a public key with traditional RSA is about 384 bytes, while the size of a public key with ECC is only 32-64 bytes. Similarly, the size of a digital signature with traditional RSA is 384 bytes, while the size is only 64 bytes with the elliptic curve digital signature algorithm (ECDSA) and the Edwards-curve digital signature algorithm (EdDSA) <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>. Using certificates that use ECC can reduce the number of messages in EAP-TLS authentication, which can alleviate the problem of authenticators dropping an EAP session because of too many round trips. In the absence of a standard application profile specifying otherwise, TLS 1.3 <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span> requires implementations to support ECC. New cipher suites that use ECC are also specified for TLS 1.2 <span>[<a href="#RFC8422" class="xref">RFC8422</a>]</span>. Using ECC-based cipher suites with existing code can significantly reduce the number of messages in a single EAP session.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<div id="cert-guide">
<section id="section-4.1.1">
          <h4 id="name-guidelines-for-certificates">
<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-guidelines-for-certificates" class="section-name selfRef">Guidelines for Certificates</a>
          </h4>
<p id="section-4.1.1-1">The general guideline of keeping the certificate size small by not populating fields with excessive information can help avert the problems of failed EAP-TLS authentication. More specific recommendations for certificates used with EAP-TLS are as follows:<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1.1-2.1">
              <p id="section-4.1.1-2.1.1">
 Object Identifier (OID) is an ASN.1 data type that defines
 unique identifiers for objects. The OID's ASN.1 value, which
 is a string of integers, is then used to name objects to which
 they relate. The Distinguished Encoding Rules (DER) specify
 that the first two integers always occupy one octet and
 subsequent integers are base-128 encoded in the fewest
 possible octets. OIDs are used lavishly in X.509 certificates
 <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span> and while not all
 can be avoided, e.g., OIDs for extensions or algorithms and
 their associate parameters, some are well within the
 certificate issuer's control:<a href="#section-4.1.1-2.1.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1.1-2.1.2.1">
 Each naming attribute in a DN (Distinguished Name) has one. DNs
 are used in the issuer and subject fields as well as numerous
 extensions. A shallower name will be smaller, e.g., C=FI,
 O=Example, SN=B0A123499EFC as against C=FI, O=Example,
 OU=Division 1, SOPN=Southern Finland, CN=Coolest IoT Gadget
 Ever, and SN=B0A123499EFC.<a href="#section-4.1.1-2.1.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-4.1.1-2.1.2.2">
 Every certificate policy (and qualifier) and any mappings to
 another policy uses identifiers. Consider carefully what
 policies apply.<a href="#section-4.1.1-2.1.2.2" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li class="normal" id="section-4.1.1-2.2">
 DirectoryString and GeneralName types are used extensively to
 name things, e.g., the DN naming attribute O= (the
 organizational naming attribute) DirectoryString includes
 "Example" for the Example organization and
 uniformResourceIdentifier can be used to indicate the location
 of the Certificate Revocation List (CRL), e.g.,
 "http://crl.example.com/sfig2s1-128.crl", in the CRL
 Distribution Point extension. For these particular examples,
 each character is a single byte. For some non-ASCII character
 strings, characters can be several bytes. Obviously, the names
 need to be unique, but there is more than one way to
 accomplish this without long strings. This is especially true
 if the names are not meant to be meaningful to users.<a href="#section-4.1.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.1.1-2.3">
 Extensions are necessary to comply with <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span>, but the vast majority are
 optional. Include only those that are necessary to operate.<a href="#section-4.1.1-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.1.1-2.4">As stated earlier, certificate chains of the EAP peer often
            follow organizational hierarchies. In such cases, information in
            intermediate certificates (such as postal addresses) do not
            provide any additional value and they can be shortened (for
            example, only including the department name instead of the full
            postal address).<a href="#section-4.1.1-2.4" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<section id="section-4.1.2">
          <h4 id="name-pre-distributing-and-omitti">
<a href="#section-4.1.2" class="section-number selfRef">4.1.2. </a><a href="#name-pre-distributing-and-omitti" class="section-name selfRef">Pre-distributing and Omitting CA Certificates</a>
          </h4>
<p id="section-4.1.2-1">

 The TLS Certificate message conveys the sending endpoint's
 certificate chain. TLS allows endpoints to reduce the size of
 the Certificate message by omitting certificates that the
 other endpoint is known to possess. When using TLS 1.3, all
 certificates that specify a trust anchor known by the other
 endpoint may be omitted (see <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2" class="relref">Section 4.4.2</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span>). When using TLS 1.2 or
 earlier, only the self-signed certificate that specifies the
 root certificate authority may be omitted (see <span><a href="https://www.rfc-editor.org/rfc/rfc5246#section-7.4.2" class="relref">Section 7.4.2</a> of [<a href="#RFC5246" class="xref">RFC5246</a>]</span>).
 Therefore, updating TLS implementations to version 1.3 can
 help to significantly reduce the number of messages exchanged
 for EAP-TLS authentication. The omitted certificates need to
 be pre-distributed independently of TLS, and the TLS
 implementations need to be configured to omit these
 pre-distributed certificates.<a href="#section-4.1.2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-4.1.3">
          <h4 id="name-using-fewer-intermediate-ce">
<a href="#section-4.1.3" class="section-number selfRef">4.1.3. </a><a href="#name-using-fewer-intermediate-ce" class="section-name selfRef">Using Fewer Intermediate Certificates</a>
          </h4>
<p id="section-4.1.3-1">
 The EAP peer certificate chain does not have to mirror the organizational hierarchy. For successful EAP-TLS authentication, certificate chains <span class="bcp14">SHOULD NOT</span> contain more than 4 intermediate certificates.<a href="#section-4.1.3-1" class="pilcrow">¶</a></p>
<p id="section-4.1.3-2">
 Administrators responsible for deployments using TLS-based EAP methods
 can examine the certificate chains and make rough calculations about
 the number of round trips required for successful authentication. For
 example, dividing the total size of all the certificates in the peer
 and server certificate chain (in bytes) by 1020 bytes will indicate
 the number of round trips required. If this number exceeds 50,
 then administrators can expect failures with many common authenticator
 implementations.<a href="#section-4.1.3-2" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="update-code">
<section id="section-4.2">
        <h3 id="name-updating-tls-and-eap-tls-co">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-updating-tls-and-eap-tls-co" class="section-name selfRef">Updating TLS and EAP-TLS Code</a>
        </h3>
<p id="section-4.2-1">This section discusses how the fragmentation problem can be avoided by updating the underlying TLS or EAP-TLS implementation. Note that in some cases, the new feature may already be implemented in the underlying library and simply needs to be enabled.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<section id="section-4.2.1">
          <h4 id="name-urls-for-client-certificate">
<a href="#section-4.2.1" class="section-number selfRef">4.2.1. </a><a href="#name-urls-for-client-certificate" class="section-name selfRef">URLs for Client Certificates</a>
          </h4>
<p id="section-4.2.1-1">
 <span>[<a href="#RFC6066" class="xref">RFC6066</a>]</span> defines the "client_certificate_url" extension, which allows TLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate chain. URLs can refer to a single certificate or a certificate chain. Using this extension can curtail the amount of fragmentation in EAP deployments thereby allowing EAP sessions to successfully complete.<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-4.2.2">
          <h4 id="name-caching-certificates">
<a href="#section-4.2.2" class="section-number selfRef">4.2.2. </a><a href="#name-caching-certificates" class="section-name selfRef">Caching Certificates</a>
          </h4>
<p id="section-4.2.2-1">
 The TLS Cached Information Extension <span>[<a href="#RFC7924" class="xref">RFC7924</a>]</span> specifies an extension where a server can exclude transmission of certificate information cached in an earlier TLS handshake. The client and the server would first execute the full TLS handshake. The client would then cache the certificate provided by the server. When the TLS client later connects to the same TLS server without using session resumption, it can attach the "cached_info" extension to the ClientHello message. This would allow the client to indicate that it has cached the certificate. The client would also include a fingerprint of the server certificate chain. If the server's certificate has not changed, then the server does not need to send its certificate and the corresponding certificate chain again. In case information has changed, which can be seen from the fingerprint provided by the client, the certificate payload is transmitted to the client to allow the client to update the cache. The extension, however, necessitates a successful full handshake before any caching. This extension can be useful when, for example, a successful authentication between an EAP peer and EAP server has occurred in the home network. If authenticators in a roaming network are stricter at dropping long EAP sessions, an EAP peer can use the Cached Information Extension to reduce the total number of messages.<a href="#section-4.2.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2.2-2">
 However, if all authenticators drop the EAP session for a given EAP peer and EAP server combination, a successful full handshake is not possible. An option in such a scenario would be to cache validated certificate chains even if the EAP-TLS exchange fails, but such caching is currently not specified in <span>[<a href="#RFC7924" class="xref">RFC7924</a>]</span>.<a href="#section-4.2.2-2" class="pilcrow">¶</a></p>
</section>
<section id="section-4.2.3">
          <h4 id="name-compressing-certificates">
<a href="#section-4.2.3" class="section-number selfRef">4.2.3. </a><a href="#name-compressing-certificates" class="section-name selfRef">Compressing Certificates</a>
          </h4>
<p id="section-4.2.3-1">
 The TLS Working Group has standardized an extension for TLS 1.3 <span>[<a href="#RFC8879" class="xref">RFC8879</a>]</span> that allows compression of
 certificates and certificate chains during full handshakes. The client
 can indicate support for compressed server certificates by including
 this extension in the ClientHello message. Similarly, the server can
 indicate support for compression of client certificates by including
 this extension in the CertificateRequest message. While such an
 extension can alleviate the problem of excessive fragmentation in
 EAP-TLS, it can only be used with TLS version 1.3 and
 higher. Deployments that rely on older versions of TLS cannot benefit
 from this extension.<a href="#section-4.2.3-1" class="pilcrow">¶</a></p>
</section>
<section id="section-4.2.4">
          <h4 id="name-compact-tls-13">
<a href="#section-4.2.4" class="section-number selfRef">4.2.4. </a><a href="#name-compact-tls-13" class="section-name selfRef">Compact TLS 1.3</a>
          </h4>
<p id="section-4.2.4-1">
 <span>[<a href="#I-D.ietf-tls-ctls" class="xref">cTLS</a>]</span> defines a "compact" version of TLS 1.3 and reduces the message size of the protocol by removing obsolete material and using more efficient encoding. It also defines a compression profile with which either side can define a dictionary of "known certificates". Thus, cTLS could provide another mechanism for EAP-TLS deployments to reduce the size of messages and avoid excessive fragmentation.<a href="#section-4.2.4-1" class="pilcrow">¶</a></p>
</section>
<section id="section-4.2.5">
          <h4 id="name-suppressing-intermediate-ce">
<a href="#section-4.2.5" class="section-number selfRef">4.2.5. </a><a href="#name-suppressing-intermediate-ce" class="section-name selfRef">Suppressing Intermediate Certificates</a>
          </h4>
<p id="section-4.2.5-1">
 For a client that has all intermediate certificates in the certificate chain, having the server send intermediates in the TLS handshake increases the size of the handshake unnecessarily. <span>[<a href="#I-D.thomson-tls-sic" class="xref">TLS-SIC</a>]</span> proposes an extension for TLS 1.3 that allows a TLS client that has access to the complete set of published intermediate certificates to inform servers of this fact so that the server can avoid sending intermediates, reducing the size of the TLS handshake. The mechanism is intended to be complementary with certificate compression.<a href="#section-4.2.5-1" class="pilcrow">¶</a></p>
<p id="section-4.2.5-2">
 The Authority Information Access (AIA)
 extension specified in <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span>
 can be used with end-entity and CA
 certificates to access information
 about the issuer of the certificate in
 which the extension appears. For
 example, it can be used to provide the
 address of the Online Certificate
 Status Protocol (OCSP) responder from
 where revocation status of the
 certificate (in which the extension
 appears) can be checked. It can also
 be used to obtain the issuer
 certificate. Thus, the AIA extension
 can reduce the size of the certificate
 chain by only including a pointer to
 the issuer certificate instead of
 including the entire issuer
 certificate. However, it requires the
 side receiving the certificate
 containing the extension to have
 network connectivity (unless the
 information is already cached
 locally). Naturally, such indirection
 cannot be used for the server
 certificate (since EAP peers in most
 deployments do not have network
 connectivity before authentication and
 typically do not maintain an
 up-to-date local cache of issuer
 certificates).<a href="#section-4.2.5-2" class="pilcrow">¶</a></p>
</section>
<section id="section-4.2.6">
          <h4 id="name-raw-public-keys">
<a href="#section-4.2.6" class="section-number selfRef">4.2.6. </a><a href="#name-raw-public-keys" class="section-name selfRef">Raw Public Keys</a>
          </h4>
<p id="section-4.2.6-1">
 <span>[<a href="#RFC7250" class="xref">RFC7250</a>]</span> defines a new
 certificate type and TLS extensions to
 enable the use of raw public keys for
 authentication. Raw public keys use
 only a subset of information found in
 typical certificates and are therefore
 much smaller in size. However, raw
 public keys require an out-of-band
 mechanism to bind the public key with
 the entity presenting the key. Using
 raw public keys will obviously avoid
 the fragmentation problems resulting
 from large certificates and long
 certificate chains. Deployments can
 consider their use as long as an
 appropriate out-of-band mechanism for
 binding public keys with identifiers
 is in place. Naturally, deployments
 will also need to consider the
 challenges of revocation and key
 rotation with the use of raw public
 keys.<a href="#section-4.2.6-1" class="pilcrow">¶</a></p>
</section>
<div id="new-cert-format">
<section id="section-4.2.7">
          <h4 id="name-new-certificate-types-and-c">
<a href="#section-4.2.7" class="section-number selfRef">4.2.7. </a><a href="#name-new-certificate-types-and-c" class="section-name selfRef">New Certificate Types and Compression Algorithms</a>
          </h4>
<p id="section-4.2.7-1">
 There is ongoing work to specify new certificate types that are
 smaller than traditional X.509 certificates. For example, <span>[<a href="#I-D.mattsson-cose-cbor-cert-compress" class="xref">CBOR-CERT</a>]</span>
 defines a Concise Binary Object Representation (CBOR) <span>[<a href="#RFC8949" class="xref">RFC8949</a>]</span> encoding of X.509
 Certificates. The CBOR encoding can be used to compress existing X.509
 certificates or for natively signed CBOR certificates. <span>[<a href="#I-D.tschofenig-tls-cwt" class="xref">TLS-CWT</a>]</span> registers a new TLS
 Certificate type that would enable TLS implementations to use CBOR
 Web Tokens (CWTs) <span>[<a href="#RFC8392" class="xref">RFC8392</a>]</span> as
 certificates. While these are early initiatives, future EAP-TLS
 deployments can consider the use of these new certificate types and
 compression algorithms to avoid large message sizes.<a href="#section-4.2.7-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="update-APs">
<section id="section-4.3">
        <h3 id="name-updating-authenticators">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-updating-authenticators" class="section-name selfRef">Updating Authenticators</a>
        </h3>
<p id="section-4.3-1">
 There are several legitimate reasons that authenticators may want to
 limit the number of packets / octets / round trips that can be sent. The
 main reason has been to work around issues where the EAP peer and EAP
 server end up in an infinite loop ACKing their messages. Another
 reason is that unlimited communication from an unauthenticated device
 using EAP could provide a channel for inappropriate bulk data
 transfer. A third reason is to prevent denial-of-service attacks.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">
 Updating the millions of already deployed
 access points and switches is in many cases
 not realistic. Vendors may be out of business
 or no longer supporting the products and
 administrators may have lost the login
 information to the devices. For practical
 purposes, the EAP infrastructure is ossified
 for the time being.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">
 Vendors making new authenticators should
 consider increasing the number of round trips
 allowed to 100 before denying the EAP
 authentication to complete. Based on the size
 of the certificates and certificate chains
 currently deployed, such an increase would
 likely ensure that peers and servers can
 complete EAP-TLS authentication. At the same
 time, administrators responsible for EAP
 deployments should ensure that this 100
 round-trip limit is not exceeded in practice.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
</section>
</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 document has no IANA actions.<a href="#section-5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Security">
<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">
 Updating implementations to TLS version 1.3 allows
 omitting all certificates with a trust anchor known by
 the other endpoint. TLS 1.3 additionally provides
 improved security, privacy, and reduced latency for
 EAP-TLS <span>[<a href="#RFC9190" class="xref">RFC9190</a>]</span>.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
 Security considerations when compressing certificates
 are specified in <span>[<a href="#RFC8879" class="xref">RFC8879</a>]</span>.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">
 Specific security considerations of the referenced
 documents apply when they are taken into use.<a href="#section-6-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-7">
      <h2 id="name-references">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-7.1">
        <h3 id="name-normative-references">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="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="RFC4851">[RFC4851]</dt>
        <dd>
<span class="refAuthor">Cam-Winget, N.</span>, <span class="refAuthor">McGrew, D.</span>, <span class="refAuthor">Salowey, J.</span>, and <span class="refAuthor">H. Zhou</span>, <span class="refTitle">"The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)"</span>, <span class="seriesInfo">RFC 4851</span>, <span class="seriesInfo">DOI 10.17487/RFC4851</span>, <time datetime="2007-05" class="refDate">May 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4851">https://www.rfc-editor.org/info/rfc4851</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="RFC5280">[RFC5280]</dt>
        <dd>
<span class="refAuthor">Cooper, D.</span>, <span class="refAuthor">Santesson, S.</span>, <span class="refAuthor">Farrell, S.</span>, <span class="refAuthor">Boeyen, S.</span>, <span class="refAuthor">Housley, R.</span>, and <span class="refAuthor">W. Polk</span>, <span class="refTitle">"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"</span>, <span class="seriesInfo">RFC 5280</span>, <span class="seriesInfo">DOI 10.17487/RFC5280</span>, <time datetime="2008-05" class="refDate">May 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5280">https://www.rfc-editor.org/info/rfc5280</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5281">[RFC5281]</dt>
        <dd>
<span class="refAuthor">Funk, P.</span> and <span class="refAuthor">S. Blake-Wilson</span>, <span class="refTitle">"Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)"</span>, <span class="seriesInfo">RFC 5281</span>, <span class="seriesInfo">DOI 10.17487/RFC5281</span>, <time datetime="2008-08" class="refDate">August 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5281">https://www.rfc-editor.org/info/rfc5281</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7170">[RFC7170]</dt>
        <dd>
<span class="refAuthor">Zhou, H.</span>, <span class="refAuthor">Cam-Winget, N.</span>, <span class="refAuthor">Salowey, J.</span>, and <span class="refAuthor">S. Hanna</span>, <span class="refTitle">"Tunnel Extensible Authentication Protocol (TEAP) Version 1"</span>, <span class="seriesInfo">RFC 7170</span>, <span class="seriesInfo">DOI 10.17487/RFC7170</span>, <time datetime="2014-05" class="refDate">May 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7170">https://www.rfc-editor.org/info/rfc7170</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[RFC8446]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9190">[RFC9190]</dt>
      <dd>
<span class="refAuthor">Preuß Mattsson, J.</span> and <span class="refAuthor">M. Sethi</span>, <span class="refTitle">"EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3"</span>, <span class="seriesInfo">RFC 9190</span>, <span class="seriesInfo">DOI 10.17487/RFC9190</span>, <time datetime="2022-02" class="refDate">February 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9190">https://www.rfc-editor.org/rfc/rfc9190</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="I-D.mattsson-cose-cbor-cert-compress">[CBOR-CERT]</dt>
        <dd>
<span class="refAuthor">Raza, S.</span>, <span class="refAuthor">Höglund, J.</span>, <span class="refAuthor">Selander, G.</span>, <span class="refAuthor">Preuß Mattsson, J.</span>, and <span class="refAuthor">M. Furuhed</span>, <span class="refTitle">"CBOR Encoded X.509 Certificates (C509 Certificates)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-mattsson-cose-cbor-cert-compress-08</span>, <time datetime="2021-02-22" class="refDate">22 February 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-mattsson-cose-cbor-cert-compress-08">https://datatracker.ietf.org/doc/html/draft-mattsson-cose-cbor-cert-compress-08</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-tls-ctls">[cTLS]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refAuthor">Barnes, R.</span>, and <span class="refAuthor">H. Tschofenig</span>, <span class="refTitle">"Compact TLS 1.3"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-tls-ctls-04</span>, <time datetime="2021-10-25" class="refDate">25 October 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctls-04">https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctls-04</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 NNetworks--Port-Based Network Access Control"</span>, <span class="seriesInfo">DOI 10.1109/IEEESTD.2020.9018454</span>, <span class="seriesInfo">IEEE Standard 802.1X-2020</span>, <time datetime="2020-02" class="refDate">February 2020</time>, <span>&lt;<a href="https://doi.org/10.1109/IEEESTD.2020.9018454">https://doi.org/10.1109/IEEESTD.2020.9018454</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="PEAP">[PEAP]</dt>
        <dd>
<span class="refAuthor">Microsoft Corporation</span>, <span class="refTitle">"[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)"</span>, <time datetime="2021-06" class="refDate">June 2021</time>. </dd>
<dd class="break"></dd>
<dt id="RFC2865">[RFC2865]</dt>
        <dd>
<span class="refAuthor">Rigney, C.</span>, <span class="refAuthor">Willens, S.</span>, <span class="refAuthor">Rubens, A.</span>, and <span class="refAuthor">W. Simpson</span>, <span class="refTitle">"Remote Authentication Dial In User Service (RADIUS)"</span>, <span class="seriesInfo">RFC 2865</span>, <span class="seriesInfo">DOI 10.17487/RFC2865</span>, <time datetime="2000-06" class="refDate">June 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2865">https://www.rfc-editor.org/info/rfc2865</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5246">[RFC5246]</dt>
        <dd>
<span class="refAuthor">Dierks, T.</span> and <span class="refAuthor">E. Rescorla</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.2"</span>, <span class="seriesInfo">RFC 5246</span>, <span class="seriesInfo">DOI 10.17487/RFC5246</span>, <time datetime="2008-08" class="refDate">August 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5246">https://www.rfc-editor.org/info/rfc5246</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6066">[RFC6066]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"Transport Layer Security (TLS) Extensions: Extension Definitions"</span>, <span class="seriesInfo">RFC 6066</span>, <span class="seriesInfo">DOI 10.17487/RFC6066</span>, <time datetime="2011-01" class="refDate">January 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6066">https://www.rfc-editor.org/info/rfc6066</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6090">[RFC6090]</dt>
        <dd>
<span class="refAuthor">McGrew, D.</span>, <span class="refAuthor">Igoe, K.</span>, and <span class="refAuthor">M. Salter</span>, <span class="refTitle">"Fundamental Elliptic Curve Cryptography Algorithms"</span>, <span class="seriesInfo">RFC 6090</span>, <span class="seriesInfo">DOI 10.17487/RFC6090</span>, <time datetime="2011-02" class="refDate">February 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6090">https://www.rfc-editor.org/info/rfc6090</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7250">[RFC7250]</dt>
        <dd>
<span class="refAuthor">Wouters, P., Ed.</span>, <span class="refAuthor">Tschofenig, H., Ed.</span>, <span class="refAuthor">Gilmore, J.</span>, <span class="refAuthor">Weiler, S.</span>, and <span class="refAuthor">T. Kivinen</span>, <span class="refTitle">"Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">RFC 7250</span>, <span class="seriesInfo">DOI 10.17487/RFC7250</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7250">https://www.rfc-editor.org/info/rfc7250</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7924">[RFC7924]</dt>
        <dd>
<span class="refAuthor">Santesson, S.</span> and <span class="refAuthor">H. Tschofenig</span>, <span class="refTitle">"Transport Layer Security (TLS) Cached Information Extension"</span>, <span class="seriesInfo">RFC 7924</span>, <span class="seriesInfo">DOI 10.17487/RFC7924</span>, <time datetime="2016-07" class="refDate">July 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7924">https://www.rfc-editor.org/info/rfc7924</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8032">[RFC8032]</dt>
        <dd>
<span class="refAuthor">Josefsson, S.</span> and <span class="refAuthor">I. Liusvaara</span>, <span class="refTitle">"Edwards-Curve Digital Signature Algorithm (EdDSA)"</span>, <span class="seriesInfo">RFC 8032</span>, <span class="seriesInfo">DOI 10.17487/RFC8032</span>, <time datetime="2017-01" class="refDate">January 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8032">https://www.rfc-editor.org/info/rfc8032</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8392">[RFC8392]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Wahlstroem, E.</span>, <span class="refAuthor">Erdtman, S.</span>, and <span class="refAuthor">H. Tschofenig</span>, <span class="refTitle">"CBOR Web Token (CWT)"</span>, <span class="seriesInfo">RFC 8392</span>, <span class="seriesInfo">DOI 10.17487/RFC8392</span>, <time datetime="2018-05" class="refDate">May 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8392">https://www.rfc-editor.org/info/rfc8392</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8422">[RFC8422]</dt>
        <dd>
<span class="refAuthor">Nir, Y.</span>, <span class="refAuthor">Josefsson, S.</span>, and <span class="refAuthor">M. Pegourie-Gonnard</span>, <span class="refTitle">"Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier"</span>, <span class="seriesInfo">RFC 8422</span>, <span class="seriesInfo">DOI 10.17487/RFC8422</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8422">https://www.rfc-editor.org/info/rfc8422</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8879">[RFC8879]</dt>
        <dd>
<span class="refAuthor">Ghedini, A.</span> and <span class="refAuthor">V. Vasiliev</span>, <span class="refTitle">"TLS Certificate Compression"</span>, <span class="seriesInfo">RFC 8879</span>, <span class="seriesInfo">DOI 10.17487/RFC8879</span>, <time datetime="2020-12" class="refDate">December 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8879">https://www.rfc-editor.org/info/rfc8879</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8949">[RFC8949]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span> and <span class="refAuthor">P. Hoffman</span>, <span class="refTitle">"Concise Binary Object Representation (CBOR)"</span>, <span class="seriesInfo">STD 94</span>, <span class="seriesInfo">RFC 8949</span>, <span class="seriesInfo">DOI 10.17487/RFC8949</span>, <time datetime="2020-12" class="refDate">December 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8949">https://www.rfc-editor.org/info/rfc8949</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>
<dt id="TLS-EAP-TYPES">[TLS-EAP-TYPES]</dt>
        <dd>
<span class="refAuthor">DeKok, A.</span>, <span class="refTitle">"TLS-based EAP types and TLS 1.3"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-emu-tls-eap-types-04</span>, <time datetime="2022-01-22" class="refDate">22 January 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-emu-tls-eap-types-04">https://datatracker.ietf.org/doc/html/draft-ietf-emu-tls-eap-types-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.thomson-tls-sic">[TLS-SIC]</dt>
      <dd>
<span class="refAuthor">Thomson, M.</span>, <span class="refTitle">"Suppressing Intermediate Certificates in TLS"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-thomson-tls-sic-00</span>, <time datetime="2019-03-27" class="refDate">27 March 2019</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-thomson-tls-sic-00">https://datatracker.ietf.org/doc/html/draft-thomson-tls-sic-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="appendix-A">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-A-1">
 This document is a result of several useful discussions with
 <span class="contact-name">Alan DeKok</span>, <span class="contact-name">Bernard   Aboba</span>, <span class="contact-name">Jari Arkko</span>, <span class="contact-name">Jouni Malinen</span>, <span class="contact-name">Darshak   Thakore</span>, and <span class="contact-name">Hannes Tschofening</span>.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">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">John Preuß Mattsson</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left"><span class="locality">Kista</span></div>
<div dir="auto" class="left"><span class="country-name">Sweden</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:john.mattsson@ericsson.com" class="email">john.mattsson@ericsson.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Sean Turner</span></div>
<div dir="auto" class="left"><span class="org">sn3rd</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:sean@sn3rd.com" class="email">sean@sn3rd.com</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>