RFC 9191

Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods

📅 published February 2022, from ietf

📜 RFC 9191: Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods 🎀

Okay bestie, this one is from the IETF 🌸 and the authors are M. Sethi, J. Preuß Mattsson (at Ericsson ✨), and S. Turner (at sn3rd 💜). It's dated February 2022 🦋 and its category is Informational 💅, so it's a "here's what you should know" doc and not a Standards Track spec. Its ISSN is 2070-1721 🧚. The title block doesn't say it obsoletes or updates anything, so there's nothing to track there 🙈.

Abstract ✨

Okay so the Extensible Authentication Protocol (EAP), which is defined in RFC 3748, gives us a standard way to support lots of different authentication methods 🔥. EAP-TLS and other TLS-based EAP methods are everywhere and do network access authentication, and they're iconic for it 💅. The problem is that big certificates plus long certificate chains, combined with authenticators that drop an EAP session after only 40 - 50 round trips, is a seriously major deployment problem 💀. This document dives deep into that problem and walks through the solutions that are available 🫶.

Status of This Memo ✨

This document is not an Internet Standards Track specification 🙈. It's published just for informational purposes 🌈.

This document is a product of the Internet Engineering Task Force (IETF) 👑. It represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication 💖. Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🔍.

For info on the current status of this document, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc9191 🦋.

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date this document was published 📜. Please read these carefully, because they spell out your rights and restrictions for this document 🫶. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License 🌸.

Table of Contents 🧚

1.  Introduction
2.  Terminology
3.  Experience with Deployments
4.  Handling of Large Certificates and Long Certificate Chains
  4.1.  Updating Certificates and Certificate Chains
    4.1.1.  Guidelines for Certificates
    4.1.2.  Pre-distributing and Omitting CA Certificates
    4.1.3.  Using Fewer Intermediate Certificates
  4.2.  Updating TLS and EAP-TLS Code
    4.2.1.  URLs for Client Certificates
    4.2.2.  Caching Certificates
    4.2.3.  Compressing Certificates
    4.2.4.  Compact TLS 1.3
    4.2.5.  Suppressing Intermediate Certificates
    4.2.6.  Raw Public Keys
    4.2.7.  New Certificate Types and Compression Algorithms
  4.3.  Updating Authenticators
5.  IANA Considerations
6.  Security Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🌸

Okay, so the Extensible Authentication Protocol (EAP), defined in [RFC3748], gives us a standard mechanism for supporting multiple authentication methods 💖. EAP-TLS [RFC5216] [RFC9190] leans on TLS [RFC8446] for strong mutual authentication with certificates [RFC5280], and it's widely deployed and often used for network access authentication 🔐. There are also lots of other standardized TLS-based EAP methods, like Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851], Tunneled Transport Layer Security (EAP-TTLS) [RFC5281], and the Tunnel Extensible Authentication Protocol (TEAP) [RFC7170] 🦋. Then there are several vendor-specific EAP methods, like the Protected Extensible Authentication Protocol (PEAP) [PEAP] 💅.

Certificates in EAP deployments can be pretty big, and the certificate chains can be long 😭. Unlike TLS on the web, where usually only the TLS server gets authenticated, EAP-TLS deployments usually authenticate both the EAP peer and the EAP server 🫶. From deployment experience, EAP peers also tend to have longer certificate chains than servers 🌈. That's because EAP peers often follow organizational hierarchies and end up with lots of intermediate certificates 👑. So EAP-TLS authentication usually involves way more octets than TLS used as part of HTTPS 🔥.

Section 3.1 of [RFC3748] says EAP implementations can assume a Maximum Transmission Unit (MTU) of at least 1020 octets from the lower layers 🧚. In typical deployments, the EAP fragment size is just 1020 - 1500 octets, since the maximum Ethernet frame size is ~ 1500 bytes 📏. So EAP-TLS authentication has to get fragmented into lots of smaller packets to travel over the lower layers 💀. That fragmentation doesn't just hurt latency, it also causes other headaches 😩. For example, some EAP authenticator (e.g., an access point) implementations will drop an EAP session if it hasn't finished after 40 - 50 round trips 🙈. This is a major problem, because in lots of situations the EAP peer can't do network access authentication even though both sides have valid credentials for successful authentication and key derivation 😭.

Not every EAP deployment is limited by the MTU of the lower layer 🌸. For example, some implementations support EAP over Ethernet "jumbo" frames, which can easily allow very large EAP packets ✨. Bigger packets naturally help cut down the number of round trips needed for successful EAP-TLS authentication 💖. But deployment experience has shown that these jumbo frames aren't always implemented correctly 🫠. On top of that, the EAP fragment size is also restricted by protocols like RADIUS [RFC2865], which carry EAP messages between an authenticator and an EAP server 🔁. RADIUS can generally carry only about 4000 octets of EAP in a single message, since the maximum length of a RADIUS packet is restricted to 4096 octets in [RFC2865] 📦.

This document looks at related work and potential tools for overcoming the deployment challenges caused by large certificates and long certificate chains 🔍. Then it talks through the solutions available to beat these challenges 🏆. Many of the solutions need TLS 1.3 [RFC8446] 🧚. The IETF has standardized EAP-TLS 1.3 [RFC9190], and it's working on specs like [TLS-EAP-TYPES] to describe how other TLS-based EAP methods use TLS 1.3 💜.

2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀.

Readers are expected to already know the terms and concepts used in EAP [RFC3748], EAP-TLS [RFC5216], and TLS [RFC8446] 🤓. In particular, this document often uses the following terms, as they're defined in [RFC5216] 💅:

  • Authenticator: The entity that starts EAP authentication 🚪. It's typically built into a network switch or a wireless access point 📡.
  • EAP peer: The entity that responds to the authenticator 🙋. In [IEEE-802.1X], this entity is called the supplicant 🌸. In EAP-TLS, the EAP peer plays the TLS client role 💖.
  • EAP server: The entity that ends the EAP authentication method with the peer 🏁. If there's no backend authentication server, the EAP server is part of the authenticator 🧩. If the authenticator runs in pass-through mode, the EAP server lives on the backend authentication server 🔁. In EAP-TLS, the EAP server plays the TLS server role 👑.

The document also uses the terms "trust anchor" and "certification path", which are defined in [RFC5280] 🦋.

3. Experience with Deployments 🌈

As we said earlier, the EAP fragment size in typical deployments is just 1020 - 1500 octets 📏. A certificate can still be large for a bunch of reasons, though 😳:

  • It can have a long Subject Alternative Name field 📛.
  • It can have long Public Key and Signature fields 🔑.
  • It can contain multiple object identifiers (OIDs) that show the permitted uses of the certificate, as noted in Section 5.3 of [RFC5216] 🏷️. Most implementations check that these OIDs are present for successful authentication 👀.
  • It can contain multiple organization naming fields to show a user's multiple group memberships (in a client certificate) 👯.

A certificate chain (called a certification path in [RFC5280]) in EAP-TLS can commonly have 2 - 6 intermediate certificates between the end-entity certificate and the trust anchor 🔗.

The size of certificates (and certificate chains) may also grow manyfold in the future, thanks to post-quantum cryptography 🚀. For example, lattice-based cryptography would have public keys of approximately 1000 bytes and signatures of approximately 2000 bytes 🧠.

Heads up, bestie: many access point implementations drop EAP sessions that don't finish within 40 - 50 round trips. So if the chain is larger than ~ 60 kilobytes, EAP-TLS authentication can't complete successfully in most deployments 😱.

4. Handling of Large Certificates and Long Certificate Chains 🛠️

Okay so this section talks through some possible options for beating the challenge of large certificates and long certificate chains in EAP-TLS authentication 💪. Section 4.1 covers recommendations that need an update to the certificates or certificate chains used for EAP-TLS authentication, but they don't need changes to the existing EAP-TLS code base 📝. It also gives some guidelines that should be followed when issuing certificates for use with EAP-TLS 🎀. Section 4.2 covers recommendations that rely on updates to EAP-TLS implementations, and they can be deployed with existing certificates 🧩. Finally, Section 4.3 briefly covers what could be done to update or reconfigure authenticators when it's not feasible to replace deployed components 🔧. That gives a solution you can deploy without changing existing certificates or code 🌟.

to be continued in part 2 💖✨

4.1. Updating Certificates and Certificate Chains

Okay so, a lot of IETF protocols now use elliptic curve cryptography (ECC) [RFC6090] for their crypto math, and it's giving smaller certificates and signatures ✨. At a 128-bit security level, a public key with traditional RSA is about 384 bytes, but an ECC public key is only 32-64 bytes 🦋. Signatures are the same vibe: 384 bytes with RSA, but only 64 bytes with the elliptic curve digital signature algorithm (ECDSA) and the Edwards-curve digital signature algorithm (EdDSA) [RFC8032] 💅. Using ECC certificates can cut the number of messages in EAP-TLS authentication, which helps with the problem of authenticators dropping an EAP session because there were too many round trips 🙈. Unless a standard application profile says otherwise, TLS 1.3 [RFC8446] requires implementations to support ECC 🔥. New ECC cipher suites are also specified for TLS 1.2 [RFC8422] 🌸. Honestly, switching existing code over to ECC-based cipher suites can significantly reduce the number of messages in a single EAP session 😭.

4.1.1. Guidelines for Certificates

The big-picture guideline is to keep certificates small by not stuffing fields with excessive info. That helps avert failed EAP-TLS authentication 🎀. Here are some more specific tips for certificates used with EAP-TLS:

  • Object Identifier (OID) is an ASN.1 data type that defines unique identifiers for objects 🧚. The OID's ASN.1 value is a string of integers, and that value is used to name the objects it relates to. The Distinguished Encoding Rules (DER) say the first two integers always occupy one octet, and subsequent integers are base-128 encoded in the fewest possible octets 🤓. OIDs are used everywhere in X.509 certificates [RFC5280]. Not all of them can be avoided (think OIDs for extensions, or for algorithms and their associated parameters), but some are totally within the certificate issuer's control 💜:
    • Each naming attribute in a DN (Distinguished Name) has one 🏷️. DNs show up in the issuer and subject fields, plus lots of extensions. A shallower name will be smaller. For example, C=FI, O=Example, SN=B0A123499EFC is way slimmer than C=FI, O=Example, OU=Division 1, SOPN=Southern Finland, CN=Coolest IoT Gadget Ever, and SN=B0A123499EFC. Main character energy is keeping it short 👑.
    • Every certificate policy (and qualifier), plus any mappings to another policy, uses identifiers. Think carefully about which policies actually apply 🧐.
  • DirectoryString and GeneralName types are used a lot to name things 🍓. For instance, the DN naming attribute O= (the organizational naming attribute) DirectoryString includes "Example" for the Example organization. A uniformResourceIdentifier can point to the location of the Certificate Revocation List (CRL) in the CRL Distribution Point extension, like http://crl.example.com/sfig2s1-128.crl. In these examples, each character is a single byte. Some non-ASCII strings use several bytes per character 🌈. The names do need to be unique, but there's more than one way to do that without long strings, and that's especially true when the names aren't meant to be meaningful to users 🫶.
  • Extensions are necessary to comply with [RFC5280], but the vast majority of them are optional. Only include the ones you actually need to operate ✨.
  • As mentioned earlier, the certificate chains of the EAP peer often follow organizational hierarchies 🏢. In that case, info in intermediate certificates (like postal addresses) doesn't add any extra value, so it can be shortened. For example, you could just include the department name instead of the full postal address 📮.

4.1.2. Pre-distributing and Omitting CA Certificates

The TLS Certificate message carries the sending endpoint's certificate chain 📜. TLS lets endpoints shrink that message by leaving out certificates the other endpoint is already known to have 🦋. With TLS 1.3, any certificate that specifies a trust anchor known by the other endpoint may be omitted (see Section 4.4.2 of [RFC8446]) 💖. With 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 [RFC5246]) 🥺. So updating TLS implementations to version 1.3 can really help cut down 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 those pre-distributed certificates 🧩.

4.1.3. Using Fewer Intermediate Certificates

The EAP peer certificate chain doesn't have to mirror the organizational hierarchy 🙅‍♀️. For successful EAP-TLS authentication, certificate chains SHOULD NOT contain more than 4 intermediate certificates 🛑.

Admins running TLS-based EAP methods can look at the certificate chains and make rough calculations for how many round trips authentication will take 🧮. For example, divide the total size of all the certificates in the peer and server certificate chain (in bytes) by 1020 bytes. That gives you the number of round trips required. If that number goes over 50, admins can expect failures with many common authenticator implementations 💀.

4.2. Updating TLS and EAP-TLS Code

Here we talk about how the fragmentation problem can be dodged by updating the underlying TLS or EAP-TLS implementation 🔧. Heads up: in some cases the new feature might already be implemented in the underlying library and just needs to be turned on 💅✨.

4.2.1. URLs for Client Certificates

[RFC6066] defines the client_certificate_url extension, which lets TLS clients send a sequence of Uniform Resource Locators (URLs) instead of the client certificate chain 🔗. URLs can point to a single certificate or to a whole certificate chain. Using this extension can curtail the amount of fragmentation in EAP deployments, which lets EAP sessions actually complete 🎉.

4.2.2. Caching Certificates

The TLS Cached Information Extension [RFC7924] specifies an extension where a server can skip sending certificate info that was cached in an earlier TLS handshake 💾. Here's how it goes: the client and server first run a full TLS handshake, and then the client caches the certificate the server gave it. Later, when that TLS client connects to the same server without using session resumption, it can attach the cached_info extension to the ClientHello message 🦋. That tells the server the client has cached the certificate. The client also includes a fingerprint of the server certificate chain. If the server's certificate hasn't changed, the server doesn't need to send its certificate and the corresponding certificate chain again 🙌. If the info has changed (the client can tell from the fingerprint), the certificate payload is sent over so the client can update its cache 🔄.

There's a catch though 🙈: the extension needs a successful full handshake before any caching can happen. This can be super useful when, for example, an EAP peer and EAP server already authenticated successfully on the home network 🏠. If the authenticators in a roaming network are stricter about dropping long EAP sessions, an EAP peer can use the Cached Information Extension to cut down the total number of messages 📉.

But here's the tricky part 😩: if all authenticators drop the EAP session for a given EAP peer and EAP server combo, a successful full handshake isn't possible. One option for that situation would be to cache validated certificate chains even when the EAP-TLS exchange fails. Such caching is currently not specified in [RFC7924] 🥲.

4.2.3. Compressing Certificates

The TLS Working Group has standardized an extension for TLS 1.3 [RFC8879] that lets you compress certificates and certificate chains during full handshakes 🗜️. A client can signal support for compressed server certificates by including this extension in its ClientHello message. Similarly, a server can signal support for compressing client certificates by including the extension in its CertificateRequest message 🤝. This can totally help with excessive fragmentation in EAP-TLS, but it can only be used with TLS version 1.3 and higher. Deployments relying on older versions of TLS can't benefit from it 😤.

4.2.4. Compact TLS 1.3

[cTLS] defines a "compact" version of TLS 1.3 that reduces the message size by removing obsolete material and using more efficient encoding 🪶. It also defines a compression profile where either side can define a dictionary of "known certificates" 📚. So cTLS could be another way for EAP-TLS deployments to shrink their messages and avoid excessive fragmentation 💜.

4.2.5. Suppressing Intermediate Certificates

If a client already has all the intermediate certificates in its certificate chain, having the server send intermediates during the TLS handshake just makes the handshake bigger for no reason 🙃. [TLS-SIC] proposes an extension for TLS 1.3 that lets a TLS client with access to the complete set of published intermediate certificates tell servers so. Then the server can skip sending intermediates, which shrinks the TLS handshake 🌷. This mechanism is meant to be complementary with certificate compression 🫶.

The Authority Information Access (AIA) extension in [RFC5280] can be used with end-entity and CA certificates to access info about the issuer of the certificate the extension appears in 🔍. For example, it can give you the address of the Online Certificate Status Protocol (OCSP) responder, which is where you check the revocation status of that certificate. It can also be used to get the issuer certificate itself 📜. So the AIA extension can shrink the certificate chain by including just a pointer to the issuer certificate instead of the entire thing ✨. The catch is that the side receiving the certificate with the extension needs network connectivity (unless the info is already cached locally) 📡. And this kind of indirection can't be used for the server certificate 😭, since EAP peers in most deployments don't have network connectivity before authentication and typically don't keep an up-to-date local cache of issuer certificates 🙅‍♀️.

4.2.6. Raw Public Keys 🔑✨

[RFC7250] defines a new certificate type and TLS extensions so you can use raw public keys for authentication. okay so raw public keys only carry a subset of what a typical certificate has, which makes them way smaller 🦋. The catch is that they need an out-of-band mechanism to bind the public key to the entity presenting it, so you can't just wing it 💅. Using raw public keys will obviously dodge the fragmentation problems that come with large certificates and long certificate chains 😭. Deployments can consider them as long as an appropriate out-of-band mechanism for binding public keys with identifiers is in place. And ngl, deployments will also have to deal with the challenges of revocation and key rotation when using raw public keys 💀.

4.2.7. New Certificate Types and Compression Algorithms 🧚

There's ongoing work on new certificate types that are smaller than traditional X.509 certificates. For example, [CBOR-CERT] defines a Concise Binary Object Representation (CBOR) [RFC8949] encoding of X.509 Certificates. The CBOR encoding can be used to compress existing X.509 certificates or for natively signed CBOR certificates. [TLS-CWT] registers a new TLS Certificate type that would let TLS implementations use CBOR Web Tokens (CWTs) [RFC8392] as certificates. These are early initiatives, but future EAP-TLS deployments can consider these new certificate types and compression algorithms to avoid large message sizes 🌈.

4.3. Updating Authenticators 🚪

There are several legit reasons authenticators may want to limit the number of packets / octets / round trips that can be sent. The big one has been working 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 be a channel for inappropriate bulk data transfer. A third reason is preventing denial-of-service attacks 🚨.

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 admins may have lost the login info to the devices. For practical purposes, the EAP infrastructure is ossified for the time being 🪨.

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 👑.

5. IANA Considerations 📋

This document has no IANA actions 🫶.

6. Security Considerations 🚨

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 [RFC9190] 💜.

Security considerations when compressing certificates are specified in [RFC8879].

Specific security considerations of the referenced documents apply when they are taken into use. ⚠️ Read them before you ship anything, bestie 😭.

7. References 📚

7.1. Normative References

7.2. Informative References

Acknowledgements 🫶

This document is a result of several useful discussions with Alan DeKok, Bernard Aboba, Jari Arkko, Jouni Malinen, Darshak Thakore, and Hannes Tschofening 💖.

Authors' Addresses 🌸

Mohit Sethi
Ericsson
FI-02420 Jorvas
Finland

Email: mohit@iki.fi


John Preuß Mattsson
Ericsson
Kista
Sweden

Email: john.mattsson@ericsson.com


Sean Turner
sn3rd

Email: sean@sn3rd.com

And that's the whole spec, bestie 🌈✨👑 you did it!!

📦 where this page comes from