rfc9191xml2.original.xml   rfc9191.xml 
<?xml version="1.0" ?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl'
href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'[] > <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc compact="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="d
<?rfc iprnotified="yes" ?> raft-ietf-emu-eaptlscert-08" number="9191" obsoletes="" updates="" submissionTyp
<?rfc toc="yes" ?> e="IETF" category="info" consensus="true" xml:lang="en" tocInclude="true" sortRe
<?rfc symrefs="yes" ?> fs="true" symRefs="true" version="3">
<rfc category="info" ipr="trust200902" docName="draft-ietf-emu-eaptlscert-08">
<front> <front>
<title abbrev="Certificates in TLS-based EAP Methods">Handling Large Cert <title abbrev="Certificates in TLS-Based EAP Methods">Handling Large Certifi
ificates and Long Certificate Chains in&nbsp;TLS&#8209;based&nbsp;EAP&nbsp;Metho cates and Long Certificate Chains in&nbsp;TLS&nbhy;Based&nbsp;EAP&nbsp;Methods</
ds</title> title>
<seriesInfo name="RFC" value="9191"/>
<author initials="M" surname="Sethi" fullname="Mohit Sethi">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city>
<code>02420</code>
<country>Finland</country>
</postal>
<email>mohit@iki.fi</email>
</address>
</author>
<author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson
">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Kista</city>
<code/>
<country>Sweden</country>
</postal>
<email>john.mattsson@ericsson.com</email>
</address>
</author>
<author initials="S" surname="Turner" fullname="Sean Turner">
<organization>sn3rd</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country/>
</postal>
<email>sean@sn3rd.com</email>
</address>
</author>
<date year="2022" month="February"/>
<workgroup>Network Working Group </workgroup>
<author initials="M" surname="Sethi" fullname="Mohit Sethi"> <keyword>EAP-TLS</keyword>
<organization>Ericsson</organization> <keyword>X.509</keyword>
<address> <keyword>EAP authenticator</keyword>
<postal> <keyword>Maximum Transmission Unit</keyword>
<street></street>
<city>Jorvas</city>
<code>02420</code>
<country>Finland</country>
</postal>
<email>mohit@piuha.net</email>
</address>
</author>
<author initials="J" surname="Mattsson" fullname="John Mattsson">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<city>Kista</city>
<code></code>
<country>Sweden</country>
</postal>
<email>john.mattsson@ericsson.com</email>
</address>
</author>
<author initials="S" surname="Turner" fullname="Sean Turner">
<organization>sn3rd</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
</postal>
<email>sean@sn3rd.com</email>
</address>
</author>
<date />
<workgroup>Network Working Group </workgroup> <abstract>
<abstract> <t>
<t> The Extensible Authentication Protocol (EAP), defined in RFC
The Extensible Authentication Protocol (EAP), defined in RFC3748, 3748, provides a standard mechanism for support of multiple
provides a standard mechanism for support of multiple authentication methods. E authentication methods. EAP-TLS and other TLS-based EAP
AP-Transport Layer Security (EAP-TLS) and other TLS-based EAP methods are widely methods are widely deployed and used for network access
deployed and used for network access authentication. Large certificates and lon authentication. Large certificates and long certificate chains
g certificate chains combined with authenticators that drop an EAP session after combined with authenticators that drop an EAP session after
only 40 - 50 round-trips is a major deployment problem. This document looks at only 40 - 50 round trips is a major deployment problem. This
this problem in detail and describes the potential solutions available. document looks at this problem in detail and describes the
</t> potential solutions available.
</abstract> </t>
</front> </abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>
<middle> The Extensible Authentication Protocol (EAP), defined in <xref
<section title="Introduction"> target="RFC3748" format="default"/>, provides a standard mechanism for support
<t> of multiple authentication methods. EAP-TLS <xref target="RFC5216"
The Extensible Authentication Protocol (EAP), defined in format="default"/> <xref target="RFC9190" format="default"/> relies on TLS
<xref target="RFC3748"/>, provides a standard mechanism for support of multiple <xref target="RFC8446" format="default"/> to provide strong mutual
authentication methods. EAP-Transport Layer Security (EAP-TLS) <xref target="RFC authentication with certificates <xref target="RFC5280" format="default"/> and
5216"/> <xref target="I-D.ietf-emu-eap-tls13"/> relies on TLS <xref target="RFC8 is widely deployed and often used for network access authentication.
446"/> to provide strong mutual authentication with certificates <xref target="R
FC5280"/> and is widely deployed and often used for network access authenticatio
n. There are also many other TLS-based EAP methods, such as Flexible Authenticat
ion via Secure Tunneling (EAP-FAST) <xref target="RFC4851"/>, Tunneled Transport
Layer Security (EAP-TTLS) <xref target="RFC5281"/>, Tunnel Extensible Authentic
ation Protocol (EAP-TEAP) <xref target="RFC7170"/>, and possibly many vendor-spe
cific EAP methods.
</t>
<t> There are also many other standardized TLS-based EAP methods such as Flexible
Certificates in EAP deployments can be relatively large, Authentication via Secure Tunneling (EAP-FAST) <xref target="RFC4851"
and the certificate chains can be long. Unlike the use of TLS on the web, where format="default"/>, Tunneled Transport Layer Security (EAP-TTLS) <xref
typically only the TLS server is authenticated; EAP-TLS deployments typically au target="RFC5281" format="default"/>, the Tunnel Extensible Authentication Protoc
thenticate both the EAP peer and the EAP server. Also, from deployment experienc ol
e, EAP peers typically have longer certificate chains than servers. This is beca (TEAP) <xref target="RFC7170" format="default"/>, as well as several
use EAP peers often follow organizational hierarchies and tend to have many inte vendor-specific EAP methods such as the Protected Extensible Authentication Prot
rmediate certificates. Thus, EAP-TLS authentication usually involves exchange of ocol (PEAP) <xref target="PEAP"/>.
significantly more octets than when TLS is used as part of HTTPS.
</t>
<t> </t>
Section 3.1 of <xref target="RFC3748"/> states that EAP i <t>
mplementations can assume a Maximum Transmission Unit (MTU) of at least 1020 oct Certificates in EAP deployments can be relatively large,
ets from lower layers. The EAP fragment size in typical deployments is just 1020 and the certificate chains can be long. Unlike the use of TLS on the web, where
- 1500 octets (since the maximum Ethernet frame size is ~ 1500 bytes). Thus, EA typically only the TLS server is authenticated, EAP-TLS deployments typically au
P-TLS authentication needs to be fragmented into many smaller packets for transp thenticate both the EAP peer and the EAP server. Also, from deployment experienc
ortation over the lower layers. Such fragmentation not only can negatively affec e, EAP peers typically have longer certificate chains than servers. This is beca
t the latency, but also results in other challenges. For example, some EAP authe use EAP peers often follow organizational hierarchies and tend to have many inte
nticator (access point) implementations will drop an EAP session if it has not f rmediate certificates. Thus, EAP-TLS authentication usually involves exchange of
inished after 40 - 50 round-trips. This is a major problem and means that in man significantly more octets than when TLS is used as part of HTTPS.
y situations, the EAP peer cannot perform network access authentication even tho </t>
ugh both the sides have valid credentials for successful authentication and key <t>
derivation. <xref target="RFC3748" sectionFormat="of"
</t> section="3.1"/> states that EAP implementations can
<t> assume a Maximum Transmission Unit (MTU) of at least
Not all EAP deployments are constrained by the MTU of the 1020 octets from lower layers. The EAP fragment size
lower layer. For example, some implementations support EAP over Ethernet "Jumbo in typical deployments is just 1020 - 1500 octets
" frames that can easily allow very large EAP packets. Larger packets will natur (since the maximum Ethernet frame size is ~ 1500
ally help lower the number of round trips required for successful EAP-TLS authen bytes). Thus, EAP-TLS authentication needs to be
tication. However, deployment experience has shown that these jumbo frames are n fragmented into many smaller packets for
ot always implemented correctly. Additionally, EAP fragment size is also restric transportation over the lower layers. Such
ted by protocols such as RADIUS <xref target="RFC2865"/> which are responsible f fragmentation not only can negatively affect the
or transporting EAP messages between an authenticator and an EAP server. RADIUS latency, but also results in other challenges.
can generally transport only about 4000 octets of EAP in a single message (the m
aximum length of RADIUS packet is restricted to 4096 octets in <xref target="RFC
2865"/>).
</t>
<t>
This document looks at related work and potential tools a
vailable for overcoming the deployment challenges induced by large certificates
and long certificate chains. It then discusses the solutions available to overco
me these challenges.
</t>
</section>
<section title="Terminology"> For example, some EAP authenticator (e.g., an access
<t> point) implementations will drop an EAP session if it
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "S has not finished after 40 - 50 round trips. This is a
HALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and major problem and means that, in many situations, the
"OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref t EAP peer cannot perform network access authentication
arget="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in a even though both the sides have valid credentials for
ll capitals, as shown here. successful authentication and key derivation.
</t> </t>
<t>
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 <xref
target="RFC2865" format="default"/>, 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 <xref target="RFC2865"
format="default"/>).
</t>
<t>
This document looks at related work and potential
tools available for overcoming the deployment
challenges induced by large certificates and long
certificate chains.
<t> It then discusses the solutions available to overcome
Readers are expected to be familiar with the terms and co these challenges. Many of the solutions require TLS
ncepts used in EAP <xref target="RFC3748"/>, EAP-TLS <xref target="RFC5216"/>, a 1.3 <xref target="RFC8446"/>. The IETF has
nd TLS <xref target="RFC8446"/>. In particular, this document frequently uses th standardized EAP-TLS 1.3 <xref target="RFC9190"/> and
e following terms as they have been defined in <xref target="RFC5216"/>: is working on specifications such as <xref
<list style="hanging" hangIndent="6"> target="TLS-EAP-TYPES"/> for how other TLS-based EAP
<t hangText="Authenticator"> methods use TLS 1.3.
The entity initiating EAP authentication.
Typically implemented as part of a network switch or a wireless access point.
</t>
<t hangText="EAP peer"> </t>
The entity that responds to the authentic
ator. In <xref target="IEEE-802.1X"/>, this entity is known as the supplicant. I
n EAP-TLS, the EAP peer implements the TLS client role.
</t>
<t hangText="EAP server"> </section>
The entity that terminates the EAP authen <section numbered="true" toc="default">
tication method with the peer. In the case where no backend authentication serve <name>Terminology</name>
r is used, the EAP server is part of the authenticator. In the case where the au <t>
thenticator operates in pass-through mode, the EAP server is located on the back The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST
end authentication server. In EAP-TLS, the EAP server implements the TLS server NOT</bcp14>", "<bcp14>REQUIRED</bcp14>",
role. "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
</t> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
</list> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bc
The document additionally uses the terms "trust anchor" a p14>", "<bcp14>MAY</bcp14>", and
nd "certification path" defined in <xref target="RFC5280"/>. "<bcp14>OPTIONAL</bcp14>" in this document are to be
</t> interpreted as described in BCP&nbsp;14 <xref
</section> target="RFC2119" format="default"/> <xref
target="RFC8174" format="default"/> when, and only
when, they appear in all capitals, as shown here.
</t>
<section title="Experience with Deployments"> <t>
<t> Readers are expected to be familiar with the terms and
concepts used in EAP <xref target="RFC3748"
format="default"/>, EAP-TLS <xref target="RFC5216"
format="default"/>, and TLS <xref target="RFC8446"
format="default"/>. In particular, this document
frequently uses the following terms as they have been
defined in <xref target="RFC5216" format="default"/>:
</t>
<dl newline="false" spacing="normal" indent="6">
<dt>Authenticator:</dt>
<dd>
The entity initiating EAP
authentication. Typically implemented
as part of a network switch or a
wireless access point.
</dd>
<dt>EAP peer:</dt>
<dd>
The entity that responds to the
authenticator. In <xref
target="IEEE-802.1X"
format="default"/>, this entity is
known as the supplicant. In EAP-TLS,
the EAP peer implements the TLS client
role.
</dd>
<dt>EAP server:</dt>
<dd>
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.
</dd>
</dl>
<t>
The document additionally uses the terms "trust anchor" a
nd "certification path" defined in <xref target="RFC5280" format="default"/>.
</t>
</section>
<section numbered="true" toc="default">
<name>Experience with Deployments</name>
<t>
As stated earlier, the EAP fragment size in typical deployments i s just 1020 - 1500 octets. A certificate can, however, be large for a number of reasons: As stated earlier, the EAP fragment size in typical deployments i s just 1020 - 1500 octets. A certificate can, however, be large for a number of reasons:
<list style="symbols"> </t>
<t>It can have a long Subject Alternative Name fi <ul spacing="normal">
eld.</t> <li>It can have a long Subject Alternative Name field.</li>
<li>It can have long Public Key and Signature fields.</li>
<li>It can contain multiple object identifiers (OIDs) that indicate the
permitted uses of the certificate as noted in <xref target="RFC5216"
sectionFormat="of" section="5.3"/>. Most implementations verify the
presence of these OIDs for successful authentication.</li>
<li>It can contain multiple organization naming fields to reflect the
multiple group memberships of a user (in a client certificate).</li>
</ul>
<t>
A certificate chain (called a certification path in
<xref target="RFC5280" format="default"/>) in EAP-TLS
can commonly have 2 - 6 intermediate certificates
between the end-entity certificate and the trust
anchor.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="handle-large-cert-long-chain" numbered="true" toc="default"
>
<name>Handling of Large Certificates and Long Certificate Chains</name>
<t>
This section discusses some possible alternatives for overcoming
the challenge of large certificates and long certificate chains in EAP-TLS authe
ntication. <xref target="update-certs" format="default"/> considers recommendati
ons that require an update of the certificates or certificate chains used for EA
P-TLS authentication without requiring changes to the existing EAP-TLS code base
. It also provides some guidelines that should be followed when issuing certific
ates for use with EAP-TLS. <xref target="update-code" format="default"/> conside
rs recommendations that rely on updates to the EAP-TLS implementations and can b
e deployed with existing certificates. Finally, <xref target="update-APs" format
="default"/> briefly discusses what could be done to update or reconfigure authe
nticators when it is infeasible to replace deployed components giving a solution
that can be deployed without changes to existing certificates or code.
</t>
<section anchor="update-certs" numbered="true" toc="default">
<name>Updating Certificates and Certificate Chains</name>
<t>
Many IETF protocols now use elliptic curve crypto
graphy (ECC) <xref target="RFC6090" format="default"/> for the underlying crypto
graphic operations. The use of ECC can reduce the size of certificates and signa
tures. For example, at a 128-bit security level, the size of a public key with t
raditional RSA is about 384 bytes, while the size of a public key with ECC is on
ly 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 si
gnature algorithm (ECDSA) and the Edwards-curve digital signature algorithm (EdD
SA) <xref target="RFC8032" format="default"/>. Using certificates that use ECC c
an 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, TL
S 1.3 <xref target="RFC8446" format="default"/> requires implementations to supp
ort ECC. New cipher suites that use ECC are also specified for TLS 1.2 <xref tar
get="RFC8422" format="default"/>. Using ECC-based cipher suites with existing co
de can significantly reduce the number of messages in a single EAP session.
</t>
<section anchor="cert-guide" numbered="true" toc="default">
<name>Guidelines for Certificates</name>
<t>The general guideline of keeping the certificate size small by not
populating fields with excessive information can help avert the problems of fail
ed EAP-TLS authentication. More specific recommendations for certificates used w
ith EAP-TLS are as follows:
</t>
<ul spacing="normal">
<li>
<t>
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
<xref target="RFC5280" format="default"/> 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:
</t>
<ul spacing="normal">
<li>
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.
</li>
<li>
Every certificate policy (and qualifier) and any mappings to
another policy uses identifiers. Consider carefully what
policies apply.
</li>
</ul>
</li>
<li>
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.
</li>
<li>
Extensions are necessary to comply with <xref target="RFC5280"
format="default"/>, but the vast majority are
optional. Include only those that are necessary to operate.
</li>
<li>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).</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>Pre-distributing and Omitting CA Certificates</name>
<t>
<t>It can have long Public Key and Signature fiel The TLS Certificate message conveys the sending endpoint's
ds.</t> 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 <xref target="RFC8446"
sectionFormat="of" section="4.4.2"/>). When using TLS 1.2 or
earlier, only the self-signed certificate that specifies the
root certificate authority may be omitted (see <xref
target="RFC5246" sectionFormat="of" section="7.4.2"/>).
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.
</t>
</section>
<section numbered="true" toc="default">
<name>Using Fewer Intermediate Certificates</name>
<t>
The EAP peer certificate chain does not h
ave to mirror the organizational hierarchy. For successful EAP-TLS authenticatio
n, certificate chains <bcp14>SHOULD NOT</bcp14> contain more than 4 intermediate
certificates.
</t>
<t>
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.
</t>
<t>It can contain multiple object identifiers (OI D) that indicate the permitted uses of the certificate as noted in Section 5.3 o f <xref target="RFC5216"/>. Most implementations verify the presence of these OI Ds for successful authentication.</t> <!-- answer that unless there are specifically one of each, they can remain sing ular. if there are many more than that, then it should be "chains"-->
<t>It can contain multiple organization fields to </section>
reflect the multiple group memberships of a user (in a client certificate).</t> </section>
</list> <section anchor="update-code" numbered="true" toc="default">
</t> <name>Updating TLS and EAP-TLS Code</name>
<t>This section discusses how the fragmentation problem can be avoided b
y 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 simpl
y needs to be enabled.</t>
<section numbered="true" toc="default">
<name>URLs for Client Certificates</name>
<t>
<xref target="RFC6066" format="default"/>
defines the "client_certificate_url" extension, which allows TLS clients to sen
d a sequence of Uniform Resource Locators (URLs) instead of the client certifica
te chain. URLs can refer to a single certificate or a certificate chain. Using t
his extension can curtail the amount of fragmentation in EAP deployments thereby
allowing EAP sessions to successfully complete.
</t>
</section>
<section numbered="true" toc="default">
<name>Caching Certificates</name>
<t>
The TLS Cached Information Extension <xre
f target="RFC7924" format="default"/> specifies an extension where a server can
exclude transmission of certificate information cached in an earlier TLS handsha
ke. The client and the server would first execute the full TLS handshake. The cl
ient would then cache the certificate provided by the server. When the TLS clien
t 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 als
o include a fingerprint of the server certificate chain. If the server's certifi
cate has not changed, then the server does not need to send its certificate and
the corresponding certificate chain again. In case information has changed, whic
h can be seen from the fingerprint provided by the client, the certificate paylo
ad is transmitted to the client to allow the client to update the cache. The ext
ension, however, necessitates a successful full handshake before any caching. Th
is extension can be useful when, for example, a successful authentication betwee
n 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 ca
n use the Cached Information Extension to reduce the total number of messages.
</t>
<t>
However, if all authenticators drop the E
AP session for a given EAP peer and EAP server combination, a successful full ha
ndshake is not possible. An option in such a scenario would be to cache validate
d certificate chains even if the EAP-TLS exchange fails, but such caching is cur
rently not specified in <xref target="RFC7924" format="default"/>.
</t>
</section>
<section numbered="true" toc="default">
<name>Compressing Certificates</name>
<t>
The TLS Working Group has standardized an extension for TLS 1.3 <xref
target="RFC8879" format="default"/> 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.
</t>
</section>
<section numbered="true" toc="default">
<name>Compact TLS 1.3</name>
<t>
<xref target="I-D.ietf-tls-ctls" format="
default"/> defines a "compact" version of TLS 1.3 and reduces the message size o
f the protocol by removing obsolete material and using more efficient encoding.
It also defines a compression profile with which either side can define a dictio
nary of "known certificates". Thus, cTLS could provide another mechanism for EAP
-TLS deployments to reduce the size of messages and avoid excessive fragmentatio
n.
</t>
</section>
<section numbered="true" toc="default">
<name>Suppressing Intermediate Certificates</name>
<t>
For a client that has all intermediate ce
rtificates in the certificate chain, having the server send intermediates in the
TLS handshake increases the size of the handshake unnecessarily. <xref target="
I-D.thomson-tls-sic" format="default"/> proposes an extension for TLS 1.3 that a
llows 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 sendin
g intermediates, reducing the size of the TLS handshake. The mechanism is intend
ed to be complementary with certificate compression.
</t>
<t>
The Authority Information Access (AIA)
extension specified in <xref
target="RFC5280" format="default"/>
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).
</t>
</section>
<section numbered="true" toc="default">
<name>Raw Public Keys</name>
<t>
<xref target="RFC7250"
format="default"/> 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.
</t>
</section>
<section anchor="new-cert-format" numbered="true" toc="default">
<name>New Certificate Types and Compression Algorithms</name>
<t>
There is ongoing work to specify new certificate types that are
smaller than traditional X.509 certificates. For example, <xref
target="I-D.mattsson-cose-cbor-cert-compress" format="default"/>
defines a Concise Binary Object Representation (CBOR) <xref
target="RFC8949" format="default"/> encoding of X.509
Certificates. The CBOR encoding can be used to compress existing X.509
certificates or for natively signed CBOR certificates. <xref
target="I-D.tschofenig-tls-cwt" format="default"/> registers a new TLS
Certificate type that would enable TLS implementations to use CBOR
Web Tokens (CWTs) <xref target="RFC8392" format="default"/> 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.
</t>
</section>
</section>
<section anchor="update-APs" numbered="true" toc="default">
<name>Updating Authenticators</name>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
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 <xref target="RFC9190" format="default"/>.
</t>
<t>
Security considerations when compressing certificates
are specified in <xref target="RFC8879"
format="default"/>.
</t>
<t>
Specific security considerations of the referenced
documents apply when they are taken into use.
</t>
</section>
</middle>
<back>
<t> <displayreference target="I-D.thomson-tls-sic" to="TLS-SIC"/>
A certificate chain (called a certification path in <xref <displayreference target="I-D.ietf-tls-ctls" to="cTLS"/>
target="RFC5280"/>) in EAP-TLS can commonly have 2 - 6 intermediate certificate <displayreference target="I-D.tschofenig-tls-cwt" to="TLS-CWT"/>
s between the end-entity certificate and the trust anchor. <displayreference target="I-D.mattsson-cose-cbor-cert-compress" to="CBOR-CERT"/>
</t>
<t>
The size of certificates (and certificate chains) may als
o increase many-fold in the future with the introduction of quantum-safe cryptog
raphy. For example, lattice-based cryptography would have public keys of approxi
mately 1000 bytes and signatures of approximately 2000 bytes.
</t>
<t>
Many access point implementations drop EAP sessions that
do not complete within 40 - 50 round-trips. This means that if the chain is larg
er than ~ 60 kbytes, EAP-TLS authentication cannot complete successfully in most
deployments.
</t>
</section>
<section title="Handling of Large Certificates and Long Certificate Chain <references>
s" anchor="handle-large-cert-long-chain"> <name>References</name>
<t> <references>
This section discusses some possible alternatives for overcoming <name>Normative References</name>
the challenge of large certificates and long certificate chains in EAP-TLS authe <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ntication. <xref target="update-certs"/> considers recommendations that require FC.2119.xml"/>
an update of the certificates or certificate chains used for EAP-TLS authenticat
ion without requiring changes to the existing EAP-TLS code base. It also provide
s some guidelines that should be followed when issuing certificates for use with
EAP-TLS. <xref target="update-code"/> considers recommendations that rely on up
dates to the EAP-TLS implementations and can be deployed with existing certifica
tes. Finally, <xref target="update-APs"/> briefly discusses what could be done t
o update or reconfigure authenticators when it is infeasible to replace deployed
components giving a solution which can be deployed without changes to existing
certificates or code.
</t>
<section title="Updating Certificates and Certificate Chains" anc <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
hor="update-certs"> C.3748.xml"/>
<t>
Many IETF protocols now use elliptic curve crypto
graphy (ECC) <xref target="RFC6090"/> for the underlying cryptographic operation
s. The use of ECC can reduce the size of certificates and signatures. For exampl
e, 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. S
imilarly, the size of a digital signature with traditional RSA is 384 bytes, whi
le the size is only 64 bytes with elliptic curve digital signature algorithm (EC
DSA) and Edwards-curve digital signature algorithm (EdDSA) <xref target="RFC8032
"/>. Using certificates that use ECC can reduce the number of messages in EAP-TL
S authentication, which can alleviate the problem of authenticators dropping an
EAP session because of too many round-trips. In the absence of a standard applic
ation profile specifying otherwise, TLS 1.3 <xref target="RFC8446"/> requires im
plementations to support ECC. New cipher suites that use ECC are also specified
for TLS 1.2 <xref target="RFC8422"/>. Using ECC-based cipher suites with existin
g code can significantly reduce the number of messages in a single EAP session.
</t>
<section title="Guidelines for Certificates" anchor="cert <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
-guide"> C.4851.xml"/>
<t>The general guideline of keeping the certifica
te size small by not populating fields with excessive information can help avert
the problems of failed EAP-TLS authentication. More specific recommendations fo
r certificates used with EAP-TLS are as follows:
<list style="symbols">
<t>
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 relat
e. The Distinguished Encoding Rules (DER) specify that the first two integers al
ways occupy one octet and subsequent integers are base 128-encoded in the fewest
possible octets. OIDs are used lavishly in X.509 certificates <xref target="RFC
5280"/> and while not all can be avoided, e.g., OIDs for extensions or algorithm
s and their associate parameters, some are well within the certificate issuer’s
control:
<list style="symbols">
<t>
Each naming attri
bute in a DN (Directory Name) has one. DNs are used in the issuer and subject fi
elds as well as numerous extensions. A shallower naming 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, SN=B0A123499EFC.
</t>
<t>
Every certificate
policy (and qualifier) and any mappings to another policy uses identifiers. Con
sider carefully what policies apply.
</t>
</list>
</t>
<t>
DirectoryString and GeneralName t
ypes are used extensively to name things, e.g., the DN naming attribute O= (the
organizational naming attribute) DirectoryString includes “Example” for the Exam
ple organization and uniformResourceIdentifier can be used to indicate the locat
ion of the CRL, e.g., “http://crl.example.com/sfig2s1-128.crl", in the CRL Distr
ibution Point extension. For these particular examples, each character is a byte
. For some non-ASCII character strings in the DN, characters can be multi-byte.
Obviously, the names need to be unique, but there is more than one way to accomp
lish this without long strings. This is especially true if the names are not mea
nt to be meaningful to users.
</t>
<t>
Extensions are necessary to compl
y with <xref target="RFC5280"/>, but the vast majority are optional. Include onl
y those that are necessary to operate.
</t>
<t>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 provi
de any additional value and they can be shortened (for example: only including t
he department name instead of the full postal address).</t>
</list>
</t>
</section>
<section title="Pre-distributing and Omitting CA certific
ates">
<t>
The TLS Certificate message conveys the s
ending endpoint's certificate chain. TLS allows endpoints to reduce the size of
the Certificate message by omitting certificates that the other endpoint is know
n to possess. When using TLS 1.3, all certificates that specify a trust anchor k
nown by the other endpoint may be omitted (see Section 4.4.2 of <xref target="RF
C8446"/>). When using TLS 1.2 or earlier, only the self-signed certificate that
specifies the root certificate authority may be omitted (see Section 7.4.2 of <x
ref target="RFC5246"/> Therefore, updating TLS implementations to version 1.3 ca
n help to significantly reduce the number of messages exchanged for EAP-TLS auth
entication. The omitted certificates need to be pre-distributed independently of
TLS and the TLS implementations need to be configured to omit these pre-distrib
uted certificates.
</t>
</section>
<section title="Using Fewer Intermediate Certificates">
<t>
The EAP peer certificate chain does not h
ave to mirror the organizational hierarchy. For successful EAP-TLS authenticatio
n, certificate chains SHOULD NOT contain more than 4 intermediate certificates.
</t>
<t>
Administrators responsible for deployment
s using TLS-based EAP methods can examine the certificate chains and make rough
calculations about the number of round trips required for successful authenticat
ion. For example, dividing the total size of all the certificates in the peer an
d server certificate chain (in bytes) by 1020 bytes will indicate the minimum nu
mber of round trips required. If this number exceeds 50, then, administrators ca
n expect failures with many common authenticator implementations.
</t>
</section>
</section>
<section title="Updating TLS and EAP-TLS Code" anchor="update-cod <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
e"> C.5216.xml"/>
<t>This section discusses how the fragmentation problem c
an be avoided by updating the underlying TLS or EAP-TLS implementation. Note tha
t in some cases the new feature may already be implemented in the underlying lib
rary and simply needs to be taken into use.</t>
<section title="URLs for Client Certificates">
<t>
<xref target="RFC6066"/> defines the "cli
ent_certificate_url" extension which allows TLS clients to send a sequence of Un
iform Resource Locators (URLs) instead of the client certificate. URLs can refer
to a single certificate or a certificate chain. Using this extension can curtai
l the amount of fragmentation in EAP deployments thereby allowing EAP sessions t
o successfully complete.
</t>
</section>
<section title="Caching Certificates">
<t>
The TLS Cached Information Extension <xre
f target="RFC7924"/> specifies an extension where a server can exclude transmiss
ion of certificate information cached in an earlier TLS handshake. The client an
d the server would first execute the full TLS handshake. The client would then c
ache 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 "cach
ed_info" extension to the ClientHello message. This would allow the client to in
dicate that it has cached the certificate. The client would also include a finge
rprint of the server certificate chain. If the server's certificate has not chan
ged, 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 fro
m 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 ne
cessitates a successful full handshake before any caching. This extension can be
useful when, for example, a successful authentication between an EAP peer and E
AP server has occurred in the home network. If authenticators in a roaming netwo
rk are stricter at dropping long EAP sessions, an EAP peer can use the Cached In
formation Extension to reduce the total number of messages.
</t>
<t>
However, if all authenticators drop the E
AP session for a given EAP peer and EAP server combination, a successful full ha
ndshake is not possible. An option in such a scenario would be to cache validate
d certificate chains even if the EAP-TLS exchange fails, but such caching is cur
rently not specified in <xref target="RFC7924"/>.
</t>
</section>
<section title="Compressing Certificates">
<t>
The TLS working group is also working on
an extension for TLS 1.3 <xref target="I-D.ietf-tls-certificate-compression"/> t
hat allows compression of certificates and certificate chains during full handsh
akes. The client can indicate support for compressed server certificates by incl
uding this extension in the ClientHello message. Similarly, the server can indic
ate support for compression of client certificates by including this extension i
n the CertificateRequest message. While such an extension can alleviate the prob
lem 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 fr
om this extension.
</t>
</section>
<section title="Compact TLS 1.3">
<t>
<xref target="I-D.ietf-tls-ctls"/> define
s 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 ce
rtificates". Thus, cTLS could provide another mechanism for EAP-TLS deployments
to reduce the size of messages and avoid excessive fragmentation.
</t>
</section>
<section title="Suppressing Intermediate Certificates">
<t>
For a client that has all intermediate ce
rtificates in the certificate chain, having the server send intermediates in the
TLS handshake increases the size of the handshake unnecessarily. <xref target="
I-D.thomson-tls-sic"/> proposes an extension for TLS 1.3 that allows a TLS clien
t 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 compleme
ntary with certificate compression.
</t>
<t>
The Authority Information Access (AIA) ex
tension specified in <xref target="RFC5280"/> 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 th
e OCSP responder from where revocation status of the certificate (in which the e
xtension appears) can be checked. It can also be used to obtain the issuer certi
ficate. 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 enti
re issuer certificate. However, it requires the side receiving the certificate c
ontaining the extension to have network connectivity (unless the information is
already cached locally). Naturally, such indirection cannot be used for the serv
er certificate (since EAP peers in most deployments do not have network connecti
vity before authentication and typically do not maintain an up-to-date local cac
he of issuer certificates).
</t>
</section>
<section title="Raw Public Keys">
<t>
<xref target="RFC7250"/> defines a new ce
rtificate type and TLS extensions to enable the use of raw public keys for authe
ntication. Raw public keys use only a subset of information found in typical cer
tificates and are therefore much smaller in size. However, raw public keys requi
re an out-of-band mechanism to bind the public key with the entity presenting th
e key. Using raw public keys will obviously avoid the fragmentation problems res
ulting from large certificates and long certificate chains. Deployments can cons
ider their use as long as an appropriate out-of-band mechanism for binding publi
c keys with identifiers is in place. Naturally, deployments will also need to co
nsider the challenges of revocation and key rotation with the use of raw public
keys.
</t>
</section>
<section title="New Certificate Types and Compression Alg
orithms" anchor="new-cert-format">
<t>
There is ongoing work to specify new cert
ificate types which are smaller than traditional X.509 certificates. For example
, <xref target="I-D.mattsson-cose-cbor-cert-compress"/> defines a Concise Binary
Object Representation (CBOR) <xref target="RFC7049"/> encoding of X.509 Certifi
cates. The CBOR encoding can be used to compress existing X.509 certificate or f
or natively signed CBOR certificates. <xref target="I-D.tschofenig-tls-cwt"/> re
gisters a new TLS Certificate type which would enable TLS implementations to use
CBOR Web Tokens (CWTs) <xref target="RFC8392"/> as certificates. While these ar
e early initiatives, future EAP-TLS deployments can consider the use of these ne
w certificate types and compression algorithms to avoid large message sizes.
</t>
</section>
</section>
<section title="Updating Authenticators" anchor="update-APs"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<t> C.5280.xml"/>
There are several legitimate reasons that authent
icators may want to limit the number of round-trips/packets/octets that can be s
ent. The main reason has been to work around issues where the EAP peer and EAP s
erver end up in an infinite loop ACKing their messages. Another reason is that u
nlimited communication from an unauthenticated device using EAP could provide a
channel for inappropriate bulk data transfer. A third reason is to prevent denia
l-of-service attacks.
</t>
<t>
Updating the millions of already deployed access
points and switches is in many cases not realistic. Vendors may be out of busine
ss or no longer supporting the products and administrators may have lost the log
in information to the devices. For practical purposes the EAP infrastructure is
ossified for the time being.
</t>
<t>
Vendors making new authenticators should consider
increasing the number of round-trips allowed to 100 before denying the EAP auth
entication to complete. Based on the size of the certificates and certificate ch
ains currently deployed, such an increase would likely ensure that peers and ser
vers can complete EAP-TLS authentication. At the same time, administrators respo
nsible for EAP deployments should ensure that this 100 roundtrip limit is not ex
ceeded in practice.
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<t>This document includes no request to IANA.</t> C.5281.xml"/>
</section>
<section anchor="Security" title="Security Considerations"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<t> C.7170.xml"/>
Updating implementations to TLS version 1.3 allows omitti
ng all certificates with a trust anchor known by the other endpoint. TLS 1.3 add
itionally provides improved security, privacy, and reduced latency for EAP-TLS <
xref target="I-D.ietf-emu-eap-tls13"/>.
</t>
<t>
Security considerations when compressing certificates are
specified in <xref target="I-D.ietf-tls-certificate-compression"/>.
</t>
<t>
Specific security considerations of the referenced docume
nts apply when they are taken into use.
</t>
</section>
</middle>
<back> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<references title="Normative References"> C.8174.xml"/>
<?rfc include='reference.RFC.2119'?> <!-- Terminology -->
<?rfc include='reference.RFC.3748'?> <!-- EAP -->
<?rfc include='reference.RFC.4851'?> <!-- FAST -->
<?rfc include='reference.RFC.5216'?> <!-- EAP-TLS -->
<?rfc include='reference.RFC.5280'?> <!-- Certificates -->
<?rfc include='reference.RFC.5281'?> <!-- TTLS -->
<?rfc include='reference.RFC.7170'?> <!-- TEAP -->
<?rfc include='reference.RFC.8174'?> <!-- Terminology -->
<?rfc include='reference.RFC.8446'?> <!-- TLS 1.3 -->
<?rfc include='reference.I-D.ietf-emu-eap-tls13'?> <!-- EAP-TLS w
ith TLS 1.3 -->
</references>
<references title="Informative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<?rfc include='reference.RFC.2865'?> <!-- RADIUS --> C.8446.xml"/>
<?rfc include='reference.RFC.6090'?> <!-- ECC -->
<?rfc include='reference.RFC.6066'?> <!-- TLS Extensions --> <reference anchor='RFC9190'>
<?rfc include='reference.RFC.7924'?> <!-- TLS cached information <front>
extension --> <title>EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS
<?rfc include='reference.RFC.8032'?> <!-- EdDSA --> 1.3</title>
<?rfc include='reference.RFC.5246'?> <!-- TLS 1.2 -->
<?rfc include='reference.RFC.8392'?> <!-- CBOR Web Token --> <author initials='J.' surname='Preuß Mattsson' fullname='John Preuß Mattsson'>
<?rfc include='reference.RFC.7049'?> <!-- CBOR --> <organization />
<?rfc include='reference.RFC.7250'?> <!-- Raw Public Keys --> </author>
<?rfc include='reference.RFC.8422'?> <!-- TLS 1.2 ciphersuites --
> <author initials='M' surname='Sethi' fullname='Mohit Sethi'>
<?rfc include='reference.I-D.ietf-tls-certificate-compression'?> <organization />
<!-- TLS 1.3 extension --> </author>
<?rfc include='reference.I-D.thomson-tls-sic'?> <!-- TLS 1.3 exte
nsion --> <date month='February' year='2022' />
<?rfc include='reference.I-D.ietf-tls-ctls'?> <!-- Compact TLS 1.
3 --> </front>
<?rfc include='reference.I-D.tschofenig-tls-cwt'?> <seriesInfo name="RFC" value="9190"/>
<?rfc include='reference.I-D.mattsson-cose-cbor-cert-compress'?> <seriesInfo name="DOI" value="10.17487/RFC9190"/>
</reference>
<reference anchor="IEEE-802.1X">
<front>
<title>IEEE Standard for Local and metropolitan a
rea networks -- Port-Based Network Access Control</title>
<author>
<organization>Institute of Electrical and
Electronics Engineers</organization>
</author>
<date month="February" year="2010" />
</front>
<seriesInfo name="IEEE Standard 802.1X-2010" value="" />
</reference>
</references> </references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2865.xml"/>
<section title="Acknowledgements" numbered="false"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
<t> C.6090.xml"/>
This draft is a result of several useful discussions with Alan De
Kok, Bernard Aboba, Jari Arkko, Jouni Malinen, Darshak Thakore, and Hannes Tscho <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
fening. C.6066.xml"/>
</t>
</section> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
</back> C.7924.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8032.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5246.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8392.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8949.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7250.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8422.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8879.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D-
thomson-tls-sic.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D-
ietf-tls-ctls.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D-
tschofenig-tls-cwt.xml"/>
<!-- [I-D.mattsson-cose-cbor-cert-compress] full reference in order to
correct to the author's name preference -->
<reference anchor="TLS-EAP-TYPES">
<front>
<title>TLS-based EAP types and TLS 1.3</title>
<author initials="A" surname="DeKok" fullname="Alan DeKok">
<organization>FreeRADIUS</organization>
</author>
<date month="January" day="22" year="2022" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-emu-tls-eap-types-04" />
</reference>
<reference anchor="I-D.mattsson-cose-cbor-cert-compress">
<front>
<title>CBOR Encoded X.509 Certificates (C509 Certificates)</title>
<author initials="S." surname="Raza" fullname="Shahid Raza">
<organization>RISE AB</organization>
</author>
<author initials="J." surname="Höglund" fullname="Joel Höglund">
<organization>RISE AB</organization>
</author>
<author initials="G." surname="Selander" fullname="Göran Selander">
<organization>Ericsson AB</organization>
</author>
<author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattss
on">
<organization>Ericsson AB</organization>
</author>
<author initials="M." surname="Furuhed" fullname="Martin Furuhed">
<organization>Nexus Group</organization>
</author>
<date month="February" day="22" year="2021" />
</front>
<seriesInfo name="Internet-Draft" value="draft-mattsson-cose-cbor-cert-compre
ss-08" />
</reference>
<reference anchor="IEEE-802.1X">
<front>
<title>IEEE Standard for Local and Metropolitan Area
NNetworks--Port-Based Network Access Control</title>
<author>
<organization>IEEE</organization>
</author>
<date month="February" year="2020"/>
</front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9018454"/>
<seriesInfo name="IEEE Standard" value="802.1X-2020"/>
</reference>
<reference anchor="PEAP">
<front>
<title>[MS-PEAP]: Protected Extensible Authentication Protocol
(PEAP)</title>
<author>
<organization>Microsoft Corporation</organization>
</author>
<date month="June" year="2021"/>
</front>
</reference>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
This document is a result of several useful discussions with
<contact fullname="Alan DeKok"/>, <contact fullname="Bernard
Aboba"/>, <contact fullname="Jari Arkko"/>, <contact
fullname="Jouni Malinen"/>, <contact fullname="Darshak
Thakore"/>, and <contact fullname="Hannes Tschofening"/>.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 33 change blocks. 
545 lines changed or deleted 800 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/