<?xml version="1.0"?> <?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM 'rfc2629.dtd'[] > <?rfc compact="yes" ?> <?rfc iprnotified="yes" ?> <?rfc toc="yes" ?> <?rfc symrefs="yes" ?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfccategory="info"xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"docName="draft-ietf-emu-eaptlscert-08">docName="draft-ietf-emu-eaptlscert-08" number="9191" obsoletes="" updates="" submissionType="IETF" category="info" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <front> <title abbrev="Certificates inTLS-basedTLS-Based EAP Methods">Handling Large Certificates and Long Certificate Chainsin TLS‑based EAP Methods</title>in TLS&nbhy;Based EAP Methods</title> <seriesInfo name="RFC" value="9191"/> <author initials="M" surname="Sethi" fullname="Mohit Sethi"> <organization>Ericsson</organization> <address> <postal><street></street><street/> <city>Jorvas</city> <code>02420</code> <country>Finland</country> </postal><email>mohit@piuha.net</email><email>mohit@iki.fi</email> </address> </author> <authorinitials="J" surname="Mattsson"initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson"> <organization>Ericsson</organization> <address> <postal><street></street><street/> <city>Kista</city><code></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><street/> <city/> <code/> <country/> </postal> <email>sean@sn3rd.com</email> </address> </author> <date/>year="2022" month="February"/> <workgroup>Network Working Group </workgroup> <keyword>EAP-TLS</keyword> <keyword>X.509</keyword> <keyword>EAP authenticator</keyword> <keyword>Maximum Transmission Unit</keyword> <abstract> <t> The Extensible Authentication Protocol (EAP), defined inRFC3748,RFC 3748, provides a standard mechanism for support of multiple authentication methods.EAP-Transport Layer Security (EAP-TLS)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 - 50round-tripsround trips is a major deployment problem. This document looks at this problem in detail and describes the potential solutions available. </t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t> The Extensible Authentication Protocol (EAP), defined in <xreftarget="RFC3748"/>,target="RFC3748" format="default"/>, provides a standard mechanism for support of multiple authentication methods.EAP-Transport Layer Security (EAP-TLS)EAP-TLS <xreftarget="RFC5216"/>target="RFC5216" format="default"/> <xreftarget="I-D.ietf-emu-eap-tls13"/>target="RFC9190" format="default"/> relies on TLS <xreftarget="RFC8446"/>target="RFC8446" format="default"/> to provide strong mutual authentication with certificates <xreftarget="RFC5280"/>target="RFC5280" format="default"/> and is widely deployed and often used for network access authentication. There are also many other standardized TLS-based EAPmethods,methods such as Flexible Authentication via Secure Tunneling (EAP-FAST) <xreftarget="RFC4851"/>,target="RFC4851" format="default"/>, Tunneled Transport Layer Security (EAP-TTLS) <xreftarget="RFC5281"/>,target="RFC5281" format="default"/>, the Tunnel Extensible Authentication Protocol(EAP-TEAP)(TEAP) <xreftarget="RFC7170"/>, and possibly manytarget="RFC7170" format="default"/>, as well as several vendor-specific EAPmethods.methods such as the Protected Extensible Authentication Protocol (PEAP) <xref target="PEAP"/>. </t> <t> 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 isauthenticated;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. </t> <t>Section 3.1 of<xreftarget="RFC3748"/>target="RFC3748" sectionFormat="of" section="3.1"/> 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(access(e.g., an access point) implementations will drop an EAP session if it has not finished after 40 - 50round-trips.round trips. This is a major problem and meansthatthat, 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. </t> <t> Not all EAP deployments are constrained by the MTU of the lower layer. For example, some implementations support EAP over Ethernet"Jumbo""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 <xreftarget="RFC2865"/>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 <xreftarget="RFC2865"/>).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. It then discusses the solutions available to overcome these challenges. Many of the solutions require TLS 1.3 <xref target="RFC8446"/>. The IETF has standardized EAP-TLS 1.3 <xref target="RFC9190"/> and is working on specifications such as <xref target="TLS-EAP-TYPES"/> for how other TLS-based EAP methods use TLS 1.3. </t> </section> <sectiontitle="Terminology">numbered="true" toc="default"> <name>Terminology</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119"/>target="RFC2119" format="default"/> <xreftarget="RFC8174"/>target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here. </t> <t> Readers are expected to be familiar with the terms and concepts used in EAP <xreftarget="RFC3748"/>,target="RFC3748" format="default"/>, EAP-TLS <xreftarget="RFC5216"/>,target="RFC5216" format="default"/>, and TLS <xreftarget="RFC8446"/>.target="RFC8446" format="default"/>. In particular, this document frequently uses the following terms as they have been defined in <xreftarget="RFC5216"/>: <list style="hanging" hangIndent="6"> <t hangText="Authenticator">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.</t> <t hangText="EAP peer"></dd> <dt>EAP peer:</dt> <dd> The entity that responds to the authenticator. In <xreftarget="IEEE-802.1X"/>,target="IEEE-802.1X" format="default"/>, this entity is known as the supplicant. In EAP-TLS, the EAP peer implements the TLS client role.</t> <t hangText="EAP server"></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.</t> </list></dd> </dl> <t> The document additionally uses the terms "trust anchor" and "certification path" defined in <xreftarget="RFC5280"/>.target="RFC5280" format="default"/>. </t> </section> <sectiontitle="Experiencenumbered="true" toc="default"> <name>Experience withDeployments">Deployments</name> <t> 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:<list style="symbols"> <t>It</t> <ul spacing="normal"> <li>It can have a long Subject Alternative Namefield.</t> <t>Itfield.</li> <li>It can have long Public Key and Signaturefields.</t> <t>Itfields.</li> <li>It can contain multiple object identifiers(OID)(OIDs) that indicate the permitted uses of the certificate as noted inSection 5.3 of<xreftarget="RFC5216"/>.target="RFC5216" sectionFormat="of" section="5.3"/>. Most implementations verify the presence of these OIDs for successfulauthentication.</t> <t>Itauthentication.</li> <li>It can contain multiple organization naming fields to reflect the multiple group memberships of a user (in a clientcertificate).</t> </list> </t>certificate).</li> </ul> <t> A certificate chain (called a certification path in <xreftarget="RFC5280"/>)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 increasemany-foldmanyfold in the future with the introduction ofquantum-safepost-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 - 50round-trips.round trips. This means that if the chain is larger than ~ 60kbytes,kilobytes, EAP-TLS authentication cannot complete successfully in most deployments. </t> </section> <sectiontitle="Handlinganchor="handle-large-cert-long-chain" numbered="true" toc="default"> <name>Handling of Large Certificates and Long CertificateChains" anchor="handle-large-cert-long-chain">Chains</name> <t> This section discusses some possible alternatives for overcoming the challenge of large certificates and long certificate chains in EAP-TLS authentication. <xreftarget="update-certs"/>target="update-certs" format="default"/> 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. <xreftarget="update-code"/>target="update-code" format="default"/> considers recommendations that rely on updates to the EAP-TLS implementations and can be deployed with existing certificates. Finally, <xreftarget="update-APs"/>target="update-APs" format="default"/> briefly discusses what could be done to update or reconfigure authenticators when it is infeasible to replace deployed components giving a solutionwhichthat can be deployed without changes to existing certificates or code. </t> <sectiontitle="Updatinganchor="update-certs" numbered="true" toc="default"> <name>Updating Certificates and CertificateChains" anchor="update-certs">Chains</name> <t> Many IETF protocols now use elliptic curve cryptography (ECC) <xreftarget="RFC6090"/>target="RFC6090" format="default"/> 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) <xreftarget="RFC8032"/>.target="RFC8032" format="default"/>. 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 manyround-trips.round trips. In the absence of a standard application profile specifying otherwise, TLS 1.3 <xreftarget="RFC8446"/>target="RFC8446" format="default"/> requires implementations to support ECC. New cipher suites that use ECC are also specified for TLS 1.2 <xreftarget="RFC8422"/>.target="RFC8422" format="default"/>. Using ECC-based cipher suites with existing code can significantly reduce the number of messages in a single EAP session. </t> <sectiontitle="Guidelinesanchor="cert-guide" numbered="true" toc="default"> <name>Guidelines forCertificates" anchor="cert-guide">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 failed EAP-TLS authentication. More specific recommendations for certificates used with EAP-TLS are as follows:<list style="symbols"></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 arebase 128-encodedbase-128 encoded in the fewest possible octets. OIDs are used lavishly in X.509 certificates <xreftarget="RFC5280"/>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 certificateissuer’sissuer's control:<list style="symbols"> <t></t> <ul spacing="normal"> <li> Each naming attribute in a DN(Directory(Distinguished Name) has one. DNs are used in the issuer and subject fields as well as numerous extensions. A shallowernamingname 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.</t> <t></li> <li> Every certificate policy (and qualifier) and any mappings to another policy uses identifiers. Consider carefully what policies apply.</t> </list> </t> <t></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”"Example" for the Example organization and uniformResourceIdentifier can be used to indicate the location of theCRL,Certificate Revocation List (CRL), e.g.,“http://crl.example.com/sfig2s1-128.crl","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 characterstrings in the DN,strings, characters can bemulti-byte.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.</t> <t></li> <li> Extensions are necessary to comply with <xreftarget="RFC5280"/>,target="RFC5280" format="default"/>, but the vast majority are optional. Include only those that are necessary to operate.</t> <t>As</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 (forexample:example, only including the department name instead of the full postaladdress).</t> </list> </t>address).</li> </ul> </section> <sectiontitle="Pre-distributingnumbered="true" toc="default"> <name>Pre-distributing and Omitting CAcertificates">Certificates</name> <t> 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 (seeSection 4.4.2 of<xreftarget="RFC8446"/>).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 (seeSection 7.4.2 of<xreftarget="RFC5246"/>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 ofTLSTLS, and the TLS implementations need to be configured to omit these pre-distributed certificates. </t> </section> <sectiontitle="Usingnumbered="true" toc="default"> <name>Using Fewer IntermediateCertificates">Certificates</name> <t> The EAP peer certificate chain does not have to mirror the organizational hierarchy. For successful EAP-TLS authentication, certificate chainsSHOULD NOT<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 theminimumnumber of round trips required. If this number exceeds 50,then,then administrators can expect failures with many common authenticator implementations. </t> <!-- answer that unless there are specifically one of each, they can remain singular. if there are many more than that, then it should be "chains"--> </section> </section> <sectiontitle="Updatinganchor="update-code" numbered="true" toc="default"> <name>Updating TLS and EAP-TLSCode" anchor="update-code">Code</name> <t>This section discusses how the fragmentation problem can be avoided by updating the underlying TLS or EAP-TLS implementation. Note that in somecasescases, the new feature may already be implemented in the underlying library and simply needs to betaken into use.</t>enabled.</t> <sectiontitle="URLsnumbered="true" toc="default"> <name>URLs for ClientCertificates">Certificates</name> <t> <xreftarget="RFC6066"/>target="RFC6066" format="default"/> defines the "client_certificate_url"extensionextension, which allows TLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the clientcertificate.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. </t> </section> <sectiontitle="Caching Certificates">numbered="true" toc="default"> <name>Caching Certificates</name> <t> The TLS Cached Information Extension <xreftarget="RFC7924"/>target="RFC7924" format="default"/> 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. Theextension howeverextension, 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. </t> <t> 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 <xreftarget="RFC7924"/>.target="RFC7924" format="default"/>. </t> </section> <sectiontitle="Compressing Certificates">numbered="true" toc="default"> <name>Compressing Certificates</name> <t> The TLSworking group is also working onWorking Group has standardized an extension for TLS 1.3 <xreftarget="I-D.ietf-tls-certificate-compression"/>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> <sectiontitle="Compactnumbered="true" toc="default"> <name>Compact TLS1.3">1.3</name> <t> <xreftarget="I-D.ietf-tls-ctls"/>target="I-D.ietf-tls-ctls" format="default"/> 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. </t> </section> <sectiontitle="Suppressingnumbered="true" toc="default"> <name>Suppressing IntermediateCertificates">Certificates</name> <t> 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. <xreftarget="I-D.thomson-tls-sic"/>target="I-D.thomson-tls-sic" format="default"/> 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. </t> <t> The Authority Information Access (AIA) extension specified in <xreftarget="RFC5280"/>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 theOCSPOnline 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> <sectiontitle="Rawnumbered="true" toc="default"> <name>Raw PublicKeys">Keys</name> <t> <xreftarget="RFC7250"/>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> <sectiontitle="Newanchor="new-cert-format" numbered="true" toc="default"> <name>New Certificate Types and CompressionAlgorithms" anchor="new-cert-format">Algorithms</name> <t> There is ongoing work to specify new certificate typeswhichthat are smaller than traditional X.509 certificates. For example, <xreftarget="I-D.mattsson-cose-cbor-cert-compress"/>target="I-D.mattsson-cose-cbor-cert-compress" format="default"/> defines a Concise Binary Object Representation (CBOR) <xreftarget="RFC7049"/>target="RFC8949" format="default"/> encoding of X.509 Certificates. The CBOR encoding can be used to compress existing X.509certificatecertificates or for natively signed CBOR certificates. <xreftarget="I-D.tschofenig-tls-cwt"/>target="I-D.tschofenig-tls-cwt" format="default"/> registers a new TLS Certificate typewhichthat would enable TLS implementations to use CBOR Web Tokens (CWTs) <xreftarget="RFC8392"/>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> <sectiontitle="Updating Authenticators" anchor="update-APs">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 ofround-trips/packets/octetspackets / 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 practicalpurposespurposes, the EAP infrastructure is ossified for the time being. </t> <t> Vendors making new authenticators should consider increasing the number ofround-tripsround 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 100roundtripround-trip limit is not exceeded in practice. </t> </section> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>This documentincludeshas norequest to IANA.</t>IANA actions.</t> </section> <section anchor="Security"title="Security Considerations">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 <xreftarget="I-D.ietf-emu-eap-tls13"/>.target="RFC9190" format="default"/>. </t> <t> Security considerations when compressing certificates are specified in <xreftarget="I-D.ietf-tls-certificate-compression"/>.target="RFC8879" format="default"/>. </t> <t> Specific security considerations of the referenced documents apply when they are taken into use. </t> </section> </middle> <back><references title="Normative References"> <?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<displayreference target="I-D.thomson-tls-sic" to="TLS-SIC"/> <displayreference target="I-D.ietf-tls-ctls" to="cTLS"/> <displayreference target="I-D.tschofenig-tls-cwt" to="TLS-CWT"/> <displayreference target="I-D.mattsson-cose-cbor-cert-compress" to="CBOR-CERT"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4851.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5216.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5281.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7170.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <reference anchor='RFC9190'> <front> <title>EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS1.3 -->1.3</title> <author initials='J.' surname='Preuß Mattsson' fullname='John Preuß Mattsson'> <organization /> </author> <author initials='M' surname='Sethi' fullname='Mohit Sethi'> <organization /> </author> <date month='February' year='2022' /> </front> <seriesInfo name="RFC" value="9190"/> <seriesInfo name="DOI" value="10.17487/RFC9190"/> </reference> </references><references title="Informative References"> <?rfc include='reference.RFC.2865'?> <!-- RADIUS --> <?rfc include='reference.RFC.6090'?> <!-- ECC --> <?rfc include='reference.RFC.6066'?> <!-- TLS Extensions --> <?rfc include='reference.RFC.7924'?><references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2865.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6090.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7924.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8392.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7250.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8422.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.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"/> <!--TLS cached information extension --> <?rfc include='reference.RFC.8032'?> <!-- EdDSA --> <?rfc include='reference.RFC.5246'?> <!-- TLS 1.2 --> <?rfc include='reference.RFC.8392'?> <!-- CBOR Web Token --> <?rfc include='reference.RFC.7049'?> <!-- CBOR --> <?rfc include='reference.RFC.7250'?> <!-- Raw Public Keys --> <?rfc include='reference.RFC.8422'?> <!-- TLS 1.2 ciphersuites --> <?rfc include='reference.I-D.ietf-tls-certificate-compression'?> <!-- TLS 1.3 extension --> <?rfc include='reference.I-D.thomson-tls-sic'?> <!-- TLS 1.3 extension[I-D.mattsson-cose-cbor-cert-compress] full reference in order to correct to the author's name preference --><?rfc include='reference.I-D.ietf-tls-ctls'?> <!-- Compact<reference anchor="TLS-EAP-TYPES"> <front> <title>TLS-based EAP types and TLS1.3 --> <?rfc include='reference.I-D.tschofenig-tls-cwt'?> <?rfc include='reference.I-D.mattsson-cose-cbor-cert-compress'?>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ß Mattsson"> <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-compress-08" /> </reference> <reference anchor="IEEE-802.1X"> <front> <title>IEEE Standard for Local andmetropolitan area networks -- Port-BasedMetropolitan Area NNetworks--Port-Based Network Access Control</title> <author><organization>Institute of Electrical and Electronics Engineers</organization><organization>IEEE</organization> </author> <date month="February"year="2010" />year="2020"/> </front> <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9018454"/> <seriesInfo name="IEEEStandard 802.1X-2010" value="" />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> <sectiontitle="Acknowledgements" numbered="false">numbered="false" toc="default"> <name>Acknowledgements</name> <t> Thisdraftdocument is a result of several useful discussions withAlan DeKok, Bernard Aboba, Jari Arkko, Jouni Malinen, Darshak Thakore, and Hannes Tschofening.<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>