RFC 9427
TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3
RFC 9427 💖 TLS-Based EAP Types for Use with TLS 1.3
Okay bestie, here's the header 🦋. This is RFC 9427, written by A. DeKok from FreeRADIUS 💅. It came out in June 2023 and is in the Standards Track category, with ISSN 2070-1721. It updates RFC 4851, RFC 5281 and RFC 7170, so those three are getting tweaks 🎀. The header doesn't list anything it obsoletes, so nothing gets replaced ✨.
Abstract 🌸
Quick tea: EAP-TLS got its TLS 1.3 glow-up in RFC 9190 (RFC 5216 is the original) 💜. A bunch of other EAP Types depend on TLS too, like EAP-FAST (RFC 4851), EAP-TTLS (RFC 5281), and the Tunnel Extensible Authentication Protocol (TEAP) (RFC 7170) 🧚. It's also possible that lots of vendor-specific EAP methods, like the Protected Extensible Authentication Protocol (PEAP), depend on TLS 🔥. This document updates those methods so they can use the new key derivation methods that come with TLS 1.3 🔑. It also talks about the other changes TLS 1.3 made necessary, so yes, there's more tea ☕.
Status of This Memo ✨
Heads up, this one is an Internet Standards Track document 💅.
It's a product of the Internet Engineering Task Force (IETF), which means it represents the consensus of the IETF community 🫶. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more info on Internet Standards, check Section 2 of RFC 7841 📖.
For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9427 🌈.
Copyright Notice 🎀
Copyright (c) 2023 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) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document 🙈. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Revised BSD License 🔥.
Table of Contents 🍓
1. Introduction
1.1. Requirements Language
2. Using TLS-Based EAP Methods with TLS 1.3
2.1. Key Derivation
2.2. TEAP
2.2.1. Client Certificates
2.3. EAP-FAST
2.3.1. Client Certificates
2.4. EAP-TTLS
2.4.1. Client Certificates
2.5. PEAP
2.5.1. Client Certificates
3. Application Data
3.1. Identities
4. Resumption
5. Security Considerations
5.1. Handling of TLS NewSessionTicket Messages
5.2. Protected Success and Failure Indications
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Author's Address1. Introduction 🌸
EAP-TLS got its TLS 1.3 upgrade in [RFC9190]. Lots of other EAP Types depend on TLS too, like EAP-FAST [RFC4851], EAP-TTLS [RFC5281], and TEAP [RFC7170] 💖. It's possible that many vendor-specific EAP methods, like PEAP [PEAP], depend on TLS as well ✨. Here's the tea: all of these methods use key derivation functions that are no longer applicable to TLS 1.3, so these methods are incompatible with TLS 1.3 😭.
This document updates these methods so they can be used with TLS 1.3 🦋. The changes involve defining new key derivation functions. We also talk about implementation issues to highlight the differences between TLS 1.3 and earlier versions of TLS 🧚.
1.1. Requirements Language 💅
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 🎀.
2. Using TLS-Based EAP Methods with TLS 1.3 🫶
In general, all of the requirements in [RFC9190] apply to other EAP methods that wish to use TLS 1.3. Unless otherwise required herein, implementations of EAP methods that wish to use TLS 1.3 MUST follow the guidelines in [RFC9190] 👑.
There are still some differences between EAP-TLS and the other TLS-based EAP methods, and this document covers them 💜. The main one is that [RFC9190] uses the EAP-TLS Type (value 0x0D) in a number of calculations, whereas other method types use their own Type value instead of the EAP-TLS Type value. We talk more about this in Section 2.1 🌈.
Another difference: [RFC9190], Section 2.5 requires the EAP server to send a protected success result indication once the EAP-TLS handshake has completed 🔥. This indication is made up of one octet (0x00) of application data. Other TLS-based EAP methods use this result indication too, but only during resumption. When other TLS-based EAP methods use full authentication, the result indication is not needed or used 🙈. This topic is explained in more detail in Sections 3 and 4 ✨.
Finally, this document includes clarifications on how various TLS-based parameters are calculated when using TLS 1.3 🍓. These parameters are different for each EAP method, so they get discussed separately 🧚.
2.1. Key Derivation 🔑
The key derivation for TLS-based EAP methods depends on the value of the EAP Type as defined by [IANA] in the "Extensible Authentication Protocol (EAP) Registry". The most important definition is of the Type field, as first defined in [RFC3748], Section 2:
Type = value of the EAP Method typeFor the purposes of this specification, when we say logical Type, we mean one octet for values smaller than 254 (the value for the Expanded Type) 💖. When Expanded EAP Types are used, the logical Type is the concatenation of the fields needed to define the Expanded Type. That's the Type with value 0xfe, plus the Vendor-Id (in network byte order) and Vendor-Type fields (in network byte order), defined in [RFC3748], Section 5.7, as shown below 🦋:
Type = 0xFE || Vendor-Id || Vendor-TypeThis definition doesn't change the meaning of Type in [RFC3748] or the structure of EAP packets 🎀. It just lets us refer to EAP Types more simply, using a logical "Type" instead of saying "the Type field or the Type field with value 0xfe, plus the Vendor-ID and Vendor-Type". For example, the value of Type for PEAP is simply 0x19 ✨.
Note that unlike TLS 1.2 and earlier, the calculation of the TLS-Exporter function depends on the length passed to it. So implementations MUST pass the correct length instead of passing a large length and truncating the output 😭. Any output calculated using a larger length value and then truncated will be different from the output calculated using the correct length 💀.
Unless otherwise discussed below, the key derivation functions for all TLS-based EAP Types are defined in [RFC9190], Section 2.3, and reproduced here for clarity 💅. These definitions include ones for the Master Session Key (MSK) and the Extended Master Session Key (EMSK) 👑:
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
Type, 128)
Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",
Type, 64)
Session-Id = Type || Method-Id
MSK = Key_Material(0, 63)
EMSK = Key_Material(64, 127)These definitions reuse the EAP-TLS exporter labels and only change the derivation by adding a dependency on the logical Type 🌸. The reason is simplicity: including the EAP Type makes the derivation method specific, so there's no need for different labels for different EAP Types like there was earlier 🧚.
These definitions apply in their entirety to EAP-TTLS [RFC5281] and to PEAP as defined in [PEAP] and [MSPEAP] 💜. Some definitions apply to EAP-FAST and TEAP with exceptions, as noted below 🔥.
It is RECOMMENDED that vendor-defined and TLS-based EAP methods use the above definitions for TLS 1.3 ✨. There is no compelling reason to use different definitions 🙈.
2.2. TEAP 🦋
TEAP previously used a Protected Access Credential (PAC), which is functionally equivalent to the session tickets TLS 1.3 provides that contain a pre-shared key (PSK) along with other data 🧚. Because of that, the use of a PAC is deprecated for TEAP in TLS 1.3 😭. PAC provisioning, as defined in [RFC7170], Section 3.8.1, is also no longer part of TEAP when TLS 1.3 is used 💅.
[RFC7170], Section 5.2 defines the Inner Method Session Key (IMSK), which depends on the TLS Pseudorandom Function (PRF), also known as TLS-PRF 🌈. When the j'th inner method generates an EMSK, we update that definition for TLS 1.3 like this 🔑:
IMSK[j] = TLS-Exporter("TEAPbindkey@ietf.org", secret, 32)The secret is the EMSK or MSK from the j'th inner method. When an inner method doesn't provide an EMSK or MSK, IMSK[j] is 32 octets of zero 🎀.
The other key derivations for TEAP are given here. All derivations not given here are the same as the ones above in the previous section 💖. These derivations are also used for EAP-FAST, but with the EAP-FAST Type 👑.
The derivation of the IMSKs, Inner Method Compound Keys (IMCKs), and Compound Session Keys (CMKs) goes like this 🫶:
session_key_seed = TLS-Exporter("EXPORTER: teap session key seed",
Type, 40)
S-IMCK[0] = session_key_seed
For j = 1 to n-1 do
IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
S-IMCK[j-1] || IMSK[j], 60)
S-IMCK[j] = first 40 octets of IMCK[j]
CMK[j] = last 20 octets of IMCK[j]Note: In these definitions, || denotes concatenation. 🌸
In TLS 1.3, the derivation of IMCK[j] uses both a different label and a different order of concatenating fields than what TEAP used with TLS 1.2 🙈. Similarly, the session_key_seed in TLS 1.3 uses the Type as the context. In TLS 1.2, the context was a zero-length field 🧚.
The outer MSK and EMSK are then derived from the final ("n"th) inner method, as follows 💜:
MSK = TLS-Exporter(
"EXPORTER: Session Key Generating Function",
S-IMCK[n], 64)
EMSK = TLS-Exporter(
"EXPORTER: Extended Session Key Generating Function",
S-IMCK[n], 64)The TEAP Compound Message Authentication Code (MAC) defined in [RFC7170], Section 5.3 stays the same, but for TLS 1.3 the MAC is computed with the Hashed Message Authentication Code (HMAC) algorithm negotiated for the HMAC-based Key Derivation Function (HKDF) in the key schedule, as per [RFC8446], Section 7.1 ✨. That is, the MAC used is the MAC derived from the TLS handshake 🌈:
Compound-MAC = MAC( CMK[n], BUFFER )Here we define CMK[n] as the CMK taken from the final ("n"th) inner method 🍓.
For TLS 1.3, the MAC is computed with the HMAC algorithm negotiated for HKDF in the key schedule, as per [RFC8446], Section 7.1. That is, the MAC used is the MAC derived from the TLS handshake 💅.
The definition of BUFFER is unchanged from [RFC7170], Section 5.3 🦋.
2.2.1. Client Certificates 🎀
okay bestie, client certificates are still allowed with TEAP over TLS 1.3 ✨ but if the client certificate gets accepted, the EAP peer MUST proceed with more authentication in Phase 2, as per [RFC7170], Section 7.6. no Phase 2 data? then the EAP server MUST reject the session 💀
while [RFC5281], Section 7.6 lets you do "authentication of the client via client certificate during phase 1, with no additional authentication or information exchange required," that move is forbidden with TEAP + TLS 1.3 🙅♀️ if you need client certs with no inner tunnel methods, just use EAP-TLS instead of TEAP 🌸
[RFC7170], Section 7.4.1 suggests that client certificates should be sent in Phase 2 of the TEAP exchange "since TLS client certificates are sent in the clear". TLS 1.3 doesn't send client certificates in the clear anymore 👑 but TEAP implementations still need to tell User and Machine identities apart using the Identity-Type TLV (values 1 and 2, respectively) 🧚 and when a client certificate is sent outside the TLS tunnel, it MUST include Identity-Type as an outer TLV so it signals which type of identity that cert is for 🫶
2.3. EAP-FAST 🦋
for EAP-FAST, the session_key_seed is also part of the key_block as defined in [RFC4851], Section 5.1 💜
the definitions of S-IMCK[n], MSK, and EMSK are the same as the ones given above for TEAP. just remember we reiterate that the EAP-FAST Type must be used when deriving the session_key_seed and not the TEAP Type 🍓
unlike [RFC4851], Section 5.2, the definition of IMCK[j] puts the reference to S-IMCK after the textual label and then concatenates the IMSK instead of the MSK ✨
EAP-FAST used to rely on a PAC, which is functionally equivalent to session tickets provided by TLS 1.3 (they contain a PSK plus other data) 🌈 so the use of a PAC is deprecated for EAP-FAST in TLS 1.3 🥀 and PAC provisioning [RFC5422] is also no longer part of EAP-FAST when TLS 1.3 is used 🙈
the T-PRF given in [RFC4851], Section 5.5 is not used for TLS 1.3. instead, it's replaced with the TLS 1.3 TLS-Exporter function 🔥
2.3.1. Client Certificates 💅
client certificates are still permitted with EAP-FAST over TLS 1.3 ✨ but if the client certificate is accepted, the EAP peer MUST proceed with additional authentication of Phase 2, as per [RFC4851], Section 7.4.1. if there's no Phase 2 data, the EAP server MUST reject the session 😭
while [RFC4851] implicitly permits client certificates without going on to Phase 2, that's forbidden when EAP-FAST is used with TLS 1.3 🚫 and if you need client certs with no inner tunnel methods, use EAP-TLS instead of EAP-FAST 🫶
2.4. EAP-TTLS 🌸
[RFC5281], Section 11.1 defines an implicit challenge when the inner methods of the Challenge Handshake Authentication Protocol (CHAP) [RFC1994], MS-CHAP [RFC2433], or MS-CHAPv2 [RFC2759] are used. for TLS 1.3, the derivation is instead given as:
EAP-TTLS_challenge = TLS-Exporter("ttls challenge",, n)there's no "context_value" ([RFC8446], Section 7.5) passed to the TLS-Exporter function 🙅♀️ the value "n" is the length of the data required. [RFC5281] requires it to be 17 octets for CHAP ([RFC5281], Section 11.2.2) and MS-CHAPv2 ([RFC5281], Section 11.2.4), and 9 octets for MS-CHAP ([RFC5281], Section 11.2.3) 🧮
when the Password Authentication Protocol (PAP), CHAP, or MS-CHAPv1 are used as inner authentication methods, the EAP server has no chance to send a protected success indication, like the one in [RFC9190], Section 2.5 🥺 so when TLS session tickets are disabled, the response from the EAP server MUST be either EAP-Success or EAP-Failure. these responses are unprotected and can be forged by a skilled attacker 👀💀
when TLS session tickets are enabled, the EAP server's response may also continue TLS negotiation with a TLS NewSessionTicket message. since that message is protected by TLS, it can serve as the protected success indication ✨
so, it is RECOMMENDED that EAP servers always send a TLS NewSessionTicket message, even if resumption isn't configured 🎀 when the EAP peer tries to use the ticket, the EAP server can instead request a full authentication. as noted earlier, implementations SHOULD NOT send TLS NewSessionTicket messages until the "inner tunnel" authentication has completed, so you get the full benefit of it as a protected success indication 🍰
when resumption isn't used, the TLS NewSessionTicket message isn't available and some authentication methods won't have a protected success indication. we'd love to always have one 🥹 but limitations of the underlying protocols, implementations, and deployment requirements make that impossible 🌧️
EAP peers MUST continue running their EAP state machine until they receive either an EAP-Success or an EAP-Failure 🔁 receiving a TLS NewSessionTicket message in response to inner method PAP, CHAP, or MS-CHAP authentication is totally normal and MUST NOT be treated as a failure 💖
2.4.1. Client Certificates 🦋
[RFC5281], Section 7.6 permits "authentication of the client via client certificate during phase 1, with no additional authentication or information exchange required." that practice is forbidden when EAP-TTLS is used with TLS 1.3 🙅♀️ if you need client certs with no inner tunnel methods, use EAP-TLS instead of EAP-TTLS 🌈
client certificates are still permitted with EAP-TTLS over TLS 1.3 ✨ but if the client certificate is accepted, the EAP peer MUST proceed with additional authentication of Phase 2, as per [RFC5281], Section 7.2. if there's no Phase 2 data, the EAP server MUST reject the session 💅
2.5. PEAP 🧁
when PEAP uses crypto binding, it uses a different key calculation defined in [PEAP-MPPE] that consumes inner EAP method keying material 🔑 the PRF+ function used in [PEAP-MPPE] isn't taken from the TLS exporter. instead, it's calculated another way, given in [PEAP-PRF] 🧠 that derivation stays unchanged in this specification ✨
note that the above derivation uses SHA-1, which may be formally deprecated in the near future 🥀
the PRF+ calculation uses a PEAP Tunnel Key (TK), which [PEAP-TK] defines as:
| ... the TK is the first 60 octets of the Key_Material, as
| specified in [RFC5216]: TLS-PRF-128 (master secret, "client EAP
| encryption", client.random || server.random).the text in [PEAP-PRF] doesn't define Key_Material. instead, it defines TK as the first octets of Key_Material and gives a definition of Key_Material that fits TLS versions before TLS 1.3 🕰️
for TLS 1.3, the TK should be derived from the Key_Material defined here in Section 2.1 instead of using the TLS-PRF-128 derivation given in [PEAP-PRF] 🌷 and the method defined in [PEAP-TK] MUST NOT be used 🚫
2.5.1. Client Certificates 👑
just like with EAP-TTLS, [PEAP] permits client certificates in addition to inner tunnel methods 🫧 using client certificates with no "inner method" is forbidden when PEAP is used with TLS 1.3 🙅♀️ if you need client certs with no inner tunnel methods, use EAP-TLS instead of PEAP 💜
client certificates are still permitted with PEAP over TLS 1.3 ✨ but if the client certificate is accepted, the EAP peer MUST proceed with additional authentication of the inner tunnel. if there's no inner tunnel authentication data, the EAP server MUST reject the session 🙈
3. Application Data ✨
okay so TLS 1.3 is lowkey different from older versions 💅 It can keep negotiating after the first handshake is done. TLS 1.3 calls that state "CONNECTED" 🦋 Some implementations treat getting a Finished message as the signal that TLS is done and the "inner tunnel" session can start. That's not always true with TLS 1.3 😭
Older TLS versions didn't send application data along with Finished. So implementations could assume that getting Finished meant there was no application data waiting, and that another round trip was needed. That assumption breaks in TLS 1.3, and anything relying on it won't work right 🙈
So implementations MUST check for application data once the TLS session is established. This check MUST be performed before starting another round of TLS negotiation. TLS-based EAP methods like EAP-TTLS, PEAP, and EAP-FAST each have their own method-specific application data, and that data MUST be processed according to the EAP Type 🎀
TLS 1.3 in [RFC8446], Section 4.6.1 also lets NewSessionTicket messages be sent after the server has received the client Finished message. That's a change from earlier versions, and it can break implementations in a bunch of different ways if they depended on the old behaviour 💀
To fix that, we require that implementations MUST NOT send or expect to receive application data in the TLS session while the underlying TLS connection is still negotiating. Implementations MUST delay processing application data until TLS negotiation has finished. If negotiation succeeds, the application data can be examined. If negotiation fails, the application data is untrusted, so it MUST be discarded without being examined 🧚
Heads up: untrusted application data means no peeking. Discard it, no examining allowed 🙅♀️
The default in many TLS libraries is to send a NewSessionTicket immediately after, or together with, the Finished message. That ticket could be used for resumption even when the "inner tunnel" authentication hasn't been completed yet 😬 And if it could be used, a malicious EAP peer could completely skip the "inner tunnel" authentication. Not okay 🚫
So the EAP server MUST NOT let any session ticket successfully resume authentication unless the inner tunnel authentication has completed successfully. Otherwise an attacker could get a session ticket, immediately close the current session, and "resume" with that ticket to bypass authentication entirely. Main villain behaviour 👿
To stop that attack, implementations SHOULD NOT send NewSessionTicket messages until the "inner tunnel" authentication has completed. There's no point sending tickets that will later be invalidated or ignored 🗑️ We know this suggestion isn't always doable with every available TLS library, though. So EAP servers MUST take care to either invalidate or discard session tickets tied to sessions that end in EAP Failure 🔒
The NewSessionTicket message SHOULD also be sent along with other application data, if possible. Sending it on its own just drags out the packet exchange for no benefit 🐌 And using a separate NewSessionTicket message can also lead to implementations that don't interoperate, which is a whole mess nobody wants 😩
[RFC9190], Section 2.5 requires a protected result indication, which says that TLS negotiation has finished. Methods that use "inner tunnel" methods MUST instead begin their "inner tunnel" negotiation by sending Type-specific application data 🎯
3.1. Identities
okay identities are my favourite part 🥹 For EAP-TLS, Sections 2.1.3 and 2.1.7 of [RFC9190] recommend using anonymous Network Access Identifiers (NAIs) [RFC7542] in the EAP Response/Identity packet. But EAP-TLS doesn't send application data inside the TLS tunnel, so that spec doesn't cover "inner" identities for tunneled EAP methods. Those still have to be addressed, though, for the tunneled methods 🌸
Using an anonymous NAI for the outer identity, as per [RFC7542], Section 2.4, has a few perks ✨ An NAI lets the EAP session get routed through a AAA framework, as described in [RFC7542], Section 3. And an anonymous realm keeps user identifiers private 🫶
As for the inner identity, we define it generically as the identification info carried inside the TLS tunnel. For PEAP, that might be an EAP Response/Identity. For EAP-TTLS, it might be the User-Name attribute. Vendor-specific EAP methods that use TLS will usually have an inner identity too 🦋 That identity rides inside the TLS tunnel, so the outer identity gets it to the right destination, and TLS keeps it private. Iconic teamwork 👑
Basically, you can think of the outer TLS layer of tunneled EAP methods as a secure transport. Its whole job is getting the real inner authentication credentials safely from the EAP peer to the EAP server. The EAP server then uses the inner identity and inner authentication data to identify and authenticate a particular user 🔐
Since the authentication data gets routed to the right place, there's little reason for the inner identity to also carry a realm. So here are a few recommendations on the inner and outer identities, and how they relate to each other 💖
The outer identity SHOULD use an anonymous NAI realm that allows for both user privacy and for the EAP session to be routed through a AAA framework, as described in [RFC7542], Section 3. Where NAI realms aren't used, packets won't be routable outside the local organization 🚧
The inner identity MUST NOT use an anonymous NAI realm. If anonymous network access is wanted, EAP peers MUST use EAP-TLS without peer authentication, as per [RFC9190], Section 2.1.5. And EAP servers MUST cause authentication to fail if an EAP peer uses an anonymous "inner" identity for any TLS-based EAP method 🚫
Implementations SHOULD NOT use inner identities that contain an NAI realm. Lots of organizations only use one realm for all their user accounts anyway 🍓
That said, there are situations where it's useful for an inner identity to contain a realm 👀 Like, an organization might have several independent sub-organizations, each with its own unique realm. Those realms might be totally independent of each other, or they might be subdomains of the public outer realm 🌈
In that case, an organization can set up one public "routing" realm plus multiple separate "inner" realms. Splitting the realms this way also lets an organization sort users into logical groups by realm, which helps when the "user" part of the NAI would otherwise clash. For example, user@example.com and user@example.org are different NAIs, and both can be used as inner identities 💅
Using just one public realm keeps internal info private, and it makes realm management way easier for outside parties, since there are fewer realms to track 🧚
In most situations, routing identifiers should be associated with the authentication data they're routing. For example, if a user has the inner identity user@example.com, then it generally makes little sense to have an outer identity of @example.org. The authentication request would get routed to the example.org domain, which may have no clue what to do with credentials for user@example.com. At best, the request gets discarded. At worst, example.org could harvest user credentials and use them later for attacks on example.com 😱
When an EAP server receives an inner identity for a realm it isn't authoritative for, it MUST reject the authentication. One organization has no business authenticating users from a different, independent organization 🙅♀️
Also, tying inner and outer identities from different organizations together in the same EAP authentication session links otherwise unrelated realms, and that can make networks more fragile 🥀
For instance, an organization that uses a "hosted" AAA provider might pick the AAA provider's realm as the outer identity for user authentication. The inner identity can then be fully qualified, meaning username plus the organization's realm. This can result in successful authentications, but it's got practical difficulties 😬
Another case: an organization might host its own AAA servers but use a "cloud" identity provider to hold user accounts. In that situation, the organization could try to use its own realm as the outer (routing) identity, then use an identity from the "cloud" provider as the inner identity.
This practice is NOT RECOMMENDED. User accounts for an organization should be qualified as belonging to that organization, not to some unrelated third party. There's no reason to tie the configuration of user systems to public realm routing. That configuration belongs in the network 🏠
Both of these practices make changing "cloud" providers a pain 😩 When a change happens, every individual EAP peer has to be updated with a different outer identity that points to the new "cloud" provider. That can be super expensive, and some EAP peers might not be online during the changeover. The result could be devices or users who can't get network access, even when every relevant network system is online and working fine 💀
Further, standards like [RFC7585] allow dynamic discovery of home servers for authentication. This spec has been widely deployed, so routing authentication to a particular domain costs very little. The authentication can also be routed to a particular identity provider and switched whenever you like, with no loss of functionality. It's scalable too, since many systems don't need changes when a domain updates its configuration. Only one thing has to change, which is the domain's own configuration. Everything else gets discovered dynamically ⭐
So changing the configuration for one domain is way simpler and more scalable than changing it on potentially millions of end-user devices. Easy choice 💜
We know there may be existing use cases where the inner and outer identities use different realms, so we can't forbid that practice. We hope the discussion above shows not only why these practices are problematic, but also how alternative methods are more flexible, more scalable, and easier to manage 🌸✨
4. Resumption ✨
okay so resumption is how a session gets picked back up instead of starting from zero 🔄 [RFC9190], Section 2.1.3 defines the whole process. It's the same for every TLS-based EAP Type 💅 the only real difference is the value in the Type field. The rules on identities, TLS cipher suites, resumption, and so on all stay exactly the same as that document says 🫶
Quick heads up, though: if resumption happens, the EAP server MUST send the protected success result indication (one octet of 0x00) inside the TLS tunnel, as per [RFC9190]. The EAP peer MUST then check for that protected success result indication (one octet of 0x00) and make authentication fail if that octet isn't received 😤 If either the peer or the server starts an inner tunnel method instead, then that method MUST be followed, and inner authentication MUST NOT be skipped 🙅
All TLS-based EAP methods support resumption, since it's a property of the underlying TLS protocol 🧚 All EAP servers and peers MUST support resumption for all TLS-based EAP methods. Servers and peers can still choose not to resume any particular session, though. For example, EAP servers may forbid resumption for administrative or other policy reasons 👑
It is RECOMMENDED that EAP servers and peers enable resumption and use it where possible 💖 Resumption cuts down on the number of round trips used for authentication. That means lower latency and less load on the EAP server ⚡ It can also lighten the load on external systems, like databases that hold user credentials 🍓
Now here's the spicy part 🌶️ The packet flows for resumption are basically identical across all TLS-based EAP Types, so it's technically possible to authenticate with EAP-TLS (Type 13) and then resume using a different EAP Type, like EAP-TTLS (Type 21). But there's no practical benefit to that, it's not clear what it would even mean, and nobody knows what security issues might come with it. So this behavior is forbidden 🚫
EAP servers therefore MUST NOT resume sessions across different EAP Types, and EAP servers MUST reject resumptions in which the EAP Type value is different from the original authentication 🛑
5. Security Considerations 🛡️
[RFC9190], Section 5 is included here by reference 📖
Updating the above EAP methods to use TLS 1.3 is of high importance for the Internet community 🚨 Using the most recent security protocols can significantly improve the security and privacy of a network 🔐
For PEAP, some derivations use HMAC-SHA1 [PEAP-MPPE]. In the interests of interoperability and minimal changes, we do not change that derivation, since there are no known security issues with HMAC-SHA1 🤷♀️ Plus, the data derived from the HMAC-SHA1 calculations is exchanged inside the TLS tunnel and is visible only to users who have already successfully authenticated. So the security risks are minimal 💜
5.1. Handling of TLS NewSessionTicket Messages
In some cases, client certificates aren't used for TLS-based EAP methods. In those cases, the user is only authenticated after the inner tunnel authentication completes successfully. However, [RFC8446], Section 4.6.1 states that "at any time after the server has received the client Finished message, it MAY send a NewSessionTicket message." This message is sent by the server before the inner authentication method has run, so before the user has been authenticated 😬
This separation of data opens the door to a "time of use, time of check" security issue 💀 Malicious clients can begin a session and receive a NewSessionTicket message. The malicious client can then abort the authentication session and use that NewSessionTicket to "resume" the previous session. If the server allows the session to resume without verifying that the user was authenticated first, the malicious client can get network access without ever being authenticated. Yikes 😱
As a result, EAP servers MUST NOT assume that a user has been authenticated simply because a TLS session is being resumed 🙅 Even if a session is being resumed, an EAP server MAY have policies that still force the inner authentication methods to be run. For example, the user's password may have expired in the time between first authentication and session resumption 🔑
So the guidelines here describe situations where an EAP server is permitted to allow session resumption, rather than situations where an EAP server is required to allow it 🎀 An EAP server could simply refuse to issue session tickets, or it could run the full inner authentication even if a session was resumed.
Where session tickets are used, the EAP server SHOULD track the successful completion of an inner authentication and associate that status with any session tickets issued for that session 📝 This requirement can be met in a number of different ways.
One way is for the EAP server to not send any TLS NewSessionTicket messages until the inner authentication has completed successfully. The EAP server then knows that the existence of a session ticket is proof that a user was authenticated, so the session can be resumed ✅
Another way is for the EAP server to discard or invalidate any session tickets until after the inner authentication has completed successfully. Once the user is authenticated, a new TLS NewSessionTicket message can be sent to the client, and that new ticket can be cached and/or validated 🎟️
Another way is for the EAP server to associate the inner authentication status with each session ticket. When a session ticket is used, the authentication status is checked. When a session ticket shows that the inner authentication did not succeed, the EAP server MUST run the inner authentication method(s) in the resumed tunnel and only grant access based on the success or failure of those inner methods 🧐
Honestly though, the interaction between EAP implementations and any underlying TLS library can get complicated 🌀 So the EAP server may not be able to make the guarantees above. Where the EAP server is unable to determine the user's authentication status from the session ticket, it MUST assume that inner authentication has not completed, and it MUST run the inner authentication method(s) successfully in the resumed tunnel before granting access 🛑
This issue isn't relevant for EAP-TLS, which only uses client certificates for authentication in the TLS handshake. It's only relevant for TLS-based EAP methods that don't use the TLS layer to authenticate 🙌
5.2. Protected Success and Failure Indications
[RFC9190] provides for protected success and failure indications, as discussed in [RFC4137], Section 4.1.1. These result indications are provided for both full authentication and resumption ✨
Other TLS-based EAP methods provide these result indications only for resumption 🫤
For full authentication, the other TLS-based EAP methods do not provide for protected success and failure indications as part of the outer TLS exchange. That means the protected result indication isn't used, and there's no TLS-layer alert sent when the inner authentication fails. Instead, either an EAP-Success or an EAP-Failure is simply sent. This is the same as for previous TLS versions, so it introduces no new security issues 🧡
We note that most TLS-based EAP methods provide success and failure indications as part of the authentication exchange performed inside the TLS tunnel. These result indications are protected, since they can't be modified or forged 🔒
However, some inner methods don't provide success or failure indications. For example, EAP-TTLS with inner PAP, CHAP, or MS-CHAP 😵 Those methods send authentication credentials to the EAP server through the inner tunnel, with no way to signal success or failure inside the tunnel.
There are functionally equivalent authentication methods that can provide protected result indications 🔁 PAP can often be replaced with EAP-GTC, CHAP with EAP-MD5, and MS-CHAPv1 with MS-CHAPv2 or EAP-MSCHAPv2. All of the replacement methods offer similar functionality and have protected success and failure indications. The main cost of switching is additional round trips 🔄
It is RECOMMENDED that implementations deprecate inner tunnel methods that don't provide protected success and failure indications when TLS session tickets cannot be used 🗑️ Implementations SHOULD use EAP-GTC instead of PAP, and EAP-MD5 instead of CHAP. Implementations SHOULD use MS-CHAPv2 or EAP-MSCHAPv2 instead of MS-CHAPv1. New TLS-based EAP methods MUST provide protected success and failure indications inside the TLS tunnel 👑
When the inner authentication protocol indicates that authentication has failed, implementations MUST fail authentication for the entire session 🚫 There may be additional protocol exchanges to send more detailed failure indications, but the final result MUST be a failed authentication. As noted earlier, any session tickets for this failed authentication MUST be either invalidated or discarded 🧹
Similarly, when the inner authentication protocol indicates that authentication has succeeded, implementations SHOULD cause authentication to succeed for the entire session 🥳 There MAY be additional protocol exchanges that could still cause failure, so we cannot mandate sending success on successful authentication 🤞
In both of these cases, the EAP server MUST send an EAP-Failure or EAP-Success message, as indicated by Step 4 in Section 2 of [RFC3748]. Even though both parties have already determined the final authentication status, the full EAP state machine must still be followed 🧩
6. IANA Considerations 🧾
This section gives guidance to the Internet Assigned Numbers Authority (IANA) about registering values related to the TLS-based EAP methods for the TLS 1.3 protocol, per [RFC8126] 📋
IANA has added the following labels to the "TLS Exporter Label" registry defined by [RFC5705]. These labels are used in deriving Key_Material and Method-Id as defined above in Section 2, and they're used only for TEAP 🌸
+============================+=========+=============+===========+
| Value | DTLS-OK | Recommended | Reference |
+============================+=========+=============+===========+
| EXPORTER: teap session key | N | Y | RFC 9427 |
| seed | | | |
+----------------------------+---------+-------------+-----------+
| EXPORTER: Inner Methods | N | Y | RFC 9427 |
| Compound Keys | | | |
+----------------------------+---------+-------------+-----------+
| EXPORTER: Session Key | N | Y | RFC 9427 |
| Generating Function | | | |
+----------------------------+---------+-------------+-----------+
| EXPORTER: Extended Session | N | Y | RFC 9427 |
| Key Generating Function | | | |
+----------------------------+---------+-------------+-----------+
| TEAPbindkey@ietf.org | N | Y | RFC 9427 |
+----------------------------+---------+-------------+-----------+Table 1: TLS Exporter Labels Registry
7. References 📚
The reference list isn't included in the text I was given for this part, so there's nothing to list here yet 🫶
7.1. Normative References 💅
okay bestie, these are the docs this spec leans on for the must-knows. the key ones are the EAP base spec, EAP-TLS, TLS 1.3, and the EAP-TLS 1.3 one. 🦋
[IANA] IANA, "Method Types",
<https://www.iana.org/assignments/eap-numbers/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <https://www.rfc-editor.org/info/rfc5216>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the
Extensible Authentication Protocol with TLS 1.3",
RFC 9190, DOI 10.17487/RFC9190, February 2022,
<https://www.rfc-editor.org/info/rfc9190>.7.2. Informative References 🌸
these ones are more like extra reading, the vibes-and-background stuff that isn't strictly required. the PEAP ones are especially iconic for the Microsoft side of things 💜
[MSPEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP)", Protocol Revision 31.0,
June 2021,
<https://msdn.microsoft.com/en-us/library/cc238354.aspx>.
[PEAP] Palekar, A., Josefsson, S., Simon, D., Zorn, G., Salowey,
J., and H. Zhou, "Protected EAP Protocol (PEAP) Version
2", Work in Progress, Internet-Draft, draft-josefsson-
pppext-eap-tls-eap-10, 15 October 2004,
<https://datatracker.ietf.org/doc/html/draft-josefsson-
pppext-eap-tls-eap-10>.
[PEAP-MPPE]
Microsoft Corporation, "Key Management", Section 3.1.5.7,
October 2020, <https://learn.microsoft.com/en-
us/openspecs/windows_protocols/ms-peap/e75b0385-915a-
4fc3-a549-fd3d06b995b0>.
[PEAP-PRF] Microsoft Corporation, "Intermediate PEAP MAC Key (IPMK)
and Compound MAC Key (CMK)", Section 3.1.5.5.2.2, February
2019, <https://docs.microsoft.com/en-
us/openspecs/windows_protocols/MS-PEAP/0de54161-0bd3-424a-
9b1a-854b4040a6df>.
[PEAP-TK] Microsoft Corporation, "PEAP Tunnel Key (TK)",
Section 3.1.5.5.2.1, April 2021,
<https://docs.microsoft.com/en-
us/openspecs/windows_protocols/MS-PEAP/41288c09-3d7d-482f-
a57f-e83691d4d246>.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, DOI 10.17487/RFC1994, August
1996, <https://www.rfc-editor.org/info/rfc1994>.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, DOI 10.17487/RFC2433, October 1998,
<https://www.rfc-editor.org/info/rfc2433>.
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
RFC 2759, DOI 10.17487/RFC2759, January 2000,
<https://www.rfc-editor.org/info/rfc2759>.
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
"State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator", RFC 4137,
DOI 10.17487/RFC4137, August 2005,
<https://www.rfc-editor.org/info/rfc4137>.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851,
DOI 10.17487/RFC4851, May 2007,
<https://www.rfc-editor.org/info/rfc4851>.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
DOI 10.17487/RFC5281, August 2008,
<https://www.rfc-editor.org/info/rfc5281>.
[RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou,
"Dynamic Provisioning Using Flexible Authentication via
Secure Tunneling Extensible Authentication Protocol (EAP-
FAST)", RFC 5422, DOI 10.17487/RFC5422, March 2009,
<https://www.rfc-editor.org/info/rfc5422>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.
[RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for
RADIUS/TLS and RADIUS/DTLS Based on the Network Access
Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October
2015, <https://www.rfc-editor.org/info/rfc7585>.Acknowledgments 🫶
huge thanks to Jorge Vergara for the super detailed look at the requirements for the different EAP Types. ✨
also a big group hug to Jorge Vergara, Bruno Periera Vidal, Alexander Clouter, Karri Huhtanen, and Heikki Vatiainen 💖 for reviewing this doc and helping with the interoperability testing. literal legends. 👑
Author's Address 🎀
Alan DeKok The FreeRADIUS Server Project Email: aland@freeradius.org 🧚
📦 where this page comes from
- ietf: rfc9427 2023-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms