RFC 9930
Tunnel Extensible Authentication Protocol (TEAP) Version 1
RFC 9930: Tunnel Extensible Authentication Protocol (TEAP) Version 1 🎀
okay bestie, let's start with the title block 💖 This is RFC 9930, published by the Internet Engineering Task Force (IETF) in February 2026. Here are the important facts:
- Authors: A. DeKok, Ed. (the Ed. means editor 🫶)
- Date: February 2026
- Category: Standards Track ✨
- ISSN: 2070-1721
- Obsoletes: 7170 (that's RFC 7170)
- Updates: 9427 (that's RFC 9427)
Abstract ✨
okay so TEAP is the Tunnel Extensible Authentication Protocol, version 1 💅 It's a tunnel-based EAP method that lets a peer and a server talk securely. It uses TLS to set up a mutually authenticated tunnel 🔐, and then, inside that tunnel, TLV objects carry the authentication-related data between the EAP peer and the EAP server. This doc obsoletes RFC 7170 and updates RFC 9427 by moving all the TEAP specs from those two documents into this one. it's giving consolidation 🧚
Status of This Memo 📜
This is an Internet Standards Track document. ✨
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🌈 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 📚
For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9930 🦋
Copyright Notice ⭐
Copyright (c) 2026 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 of publication. Please read these carefully, because they describe your rights and restrictions for 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. They're provided without warranty, as described in the Revised BSD License 🍓
Table of Contents 🗂️
1. Introduction
1.1. Interoperability Issues
1.2. Requirements Language
1.3. Terminology
2. Protocol Overview
2.1. Architectural Model
2.2. Protocol-Layering Model
2.3. Outer TLVs Versus Inner TLVs
3. TEAP Protocol
3.1. Version Negotiation
3.2. TEAP Authentication Phase 1: Tunnel Establishment
3.3. Server Certificate Requirements
3.4. Server Certificate Validation
3.4.1. Client Certificates Sent During Phase 1
3.5. Resumption
3.5.1. TLS Session Resumption Using Server State
3.5.2. TLS Session Resumption Using Client State
3.6. TEAP Authentication Phase 2: Tunneled Authentication
3.6.1. Inner Method Ordering
3.6.2. Inner EAP Authentication
3.6.3. Inner Password Authentication
3.6.4. EAP-MSCHAPv2
3.6.5. Limitations on Inner Methods
3.6.6. Protected Termination and Acknowledged Result
Indication
3.7. Determining Peer-Id and Server-Id
3.8. TEAP Session Identifier
3.9. Error Handling
3.9.1. Outer-Layer Errors
3.9.2. TLS Layer Errors
3.9.3. Phase 2 Errors
3.10. Fragmentation
3.11. Services Requested by the Peer
3.11.1. Certificate Provisioning Within the Tunnel
3.11.2. Certificate Content and Uses
3.11.3. Server Unauthenticated Provisioning Mode
3.11.4. Channel Binding
4. Message Formats
4.1. TEAP Message Format
4.2. TEAP TLV Format and Support
4.2.1. General TLV Format
4.2.2. Authority-ID TLV
4.2.3. Identity-Type TLV
4.2.4. Result TLV
4.2.5. NAK TLV
4.2.6. Error TLV
4.2.7. Channel-Binding TLV
4.2.8. Vendor-Specific TLV
4.2.9. Request-Action TLV
4.2.10. EAP-Payload TLV
4.2.11. Intermediate-Result TLV
4.2.12. PAC TLV
4.2.13. Crypto-Binding TLV
4.2.14. Basic-Password-Auth-Req TLV
4.2.15. Basic-Password-Auth-Resp TLV
4.2.16. PKCS#7 TLV
4.2.17. PKCS#10 TLV
4.2.18. Trusted-Server-Root TLV
4.2.19. CSR-Attributes TLV
4.2.20. Identity-Hint TLV
4.3. TLV Rules
4.3.1. Outer TLVs
4.3.2. Inner TLVs
5. Limitations of TEAPv1
5.1. Interoperable Inner Methods
5.2. Explanation and Background
5.3. Next Steps
6. Cryptographic Calculations
6.1. TEAP Authentication Phase 1: Key Derivations
6.2. Intermediate Compound Key Derivations
6.2.1. Generating the Inner Method Session Key
6.2.2. Generating S-IMCK
6.2.3. Choosing Inner Methods Securely
6.2.4. Managing and Computing Crypto-Binding
6.2.5. Unintended Side Effects
6.3. Computing the Compound MAC
6.4. EAP Master Session Key Generation
7. IANA Considerations
7.1. TEAP TLV Types
7.2. TEAP Error TLV (value 5) Error Codes
7.3. TLS Exporter Labels
7.4. Extended Master Session Key (EMSK) Parameters
7.5. Extensible Authentication Protocol (EAP) Registry
8. Security Considerations
8.1. Mutual Authentication and Integrity Protection
8.2. Method Negotiation
8.3. Separation of Phase 1 and Phase 2 Servers
8.4. Mitigation of Known Vulnerabilities and Protocol
Deficiencies
8.4.1. User Identity Protection and Verification
8.5. Dictionary Attack Resistance
8.5.1. Protection Against On-Path Attacks
8.6. Protecting Against Forged Cleartext EAP Packets
8.7. Use of Cleartext Passwords
8.8. Accidental or Unintended Behavior
8.9. Implicit Challenge
8.10. Security Claims
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Evaluation Against Tunnel-Based EAP Method
Requirements
A.1. Requirement 4.1.1: RFC Compliance
A.2. Requirement 4.2.1: TLS Requirements
A.3. Requirement 4.2.1.1.1: Cipher Suite Negotiation
A.4. Requirement 4.2.1.1.2: Tunnel Data Protection Algorithms
A.5. Requirement 4.2.1.1.3: Tunnel Authentication and Key
Establishment
A.6. Requirement 4.2.1.2: Tunnel Replay Protection
A.7. Requirement 4.2.1.3: TLS Extensions
A.8. Requirement 4.2.1.4: Peer Identity Privacy
A.9. Requirement 4.2.1.5: Session Resumption
A.10. Requirement 4.2.2: Fragmentation
A.11. Requirement 4.2.3: Protection of Data External to Tunnel
A.12. Requirement 4.3.1: Extensible Attribute Types
A.13. Requirement 4.3.2: Request/Challenge Response Operation
A.14. Requirement 4.3.3: Indicating Criticality of Attributes
A.15. Requirement 4.3.4: Vendor-Specific Support
A.16. Requirement 4.3.5: Result Indication
A.17. Requirement 4.3.6: Internationalization of Display Strings
A.18. Requirement 4.4: EAP Channel-Binding Requirements
A.19. Requirement 4.5.1.1: Confidentiality and Integrity
A.20. Requirement 4.5.1.2: Authentication of Server
A.21. Requirement 4.5.1.3: Server Certificate Revocation Checking
A.22. Requirement 4.5.2: Internationalization
A.23. Requirement 4.5.3: Metadata
A.24. Requirement 4.5.4: Password Change
A.25. Requirement 4.6.1: Method Negotiation
A.26. Requirement 4.6.2: Chained Methods
A.27. Requirement 4.6.3: Cryptographic Binding with the TLS
Tunnel
A.28. Requirement 4.6.4: Peer-Initiated EAP Authentication
A.29. Requirement 4.6.5: Method Metadata
Appendix B. Major Differences from EAP-FAST
Appendix C. Examples
C.1. Successful Authentication
C.2. Failed Authentication
C.3. Full TLS Handshake Using Certificate-Based Cipher Suite
C.4. Client Authentication During Phase 1 with Identity Privacy
C.5. Fragmentation and Reassembly
C.6. Sequence of EAP Methods
C.7. Failed Crypto-Binding
C.8. Sequence of EAP Method with Vendor-Specific TLV Exchange
C.9. Peer Requests Inner Method After Server Sends Result TLV
C.10. Channel Binding
C.11. PKCS Exchange
C.12. Failure Scenario
C.13. Client Certificate in Phase 1
Appendix D. Changes from RFC 7170
Acknowledgments
Contributors
Author's Address1. Introduction 🌸
okay so a tunnel-based Extensible Authentication Protocol (EAP) method is an EAP method that sets up a secure tunnel and then runs other EAP methods inside that protection 🔒 It can be used over any lower-layer protocol that supports EAP authentication ✨ A bunch of tunnel-based EAP methods already use Transport Layer Security (TLS) [RFC8446] to build that tunnel. These include Protected EAP (PEAP) [PEAP], EAP Tunneled Transport Layer Security (EAP-TTLS) [RFC5281], and EAP Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851]. But they're all either vendor-specific or informational, and the industry wants a Standards Track tunnel-based EAP method 😭 [RFC6678] lists the requirements for a standard tunnel-based EAP method 📋
This document describes TEAP version 1, which is based on EAP-FAST [RFC4851] 🦋 The changes from EAP-FAST to TEAP are mostly minor, so that TEAP meets the requirements in [RFC6678] for a standard tunnel-based EAP method 💖
This document also defines cryptographic derivations for use with TLS 1.2. When TLS 1.3 is used, the definitions of cryptographic derivations in [RFC9427] MUST be used instead of the ones given here 🔐
Heads up: TEAPv1 can technically be used with TLS 1.0 and TLS 1.1, but those protocols were deprecated in [RFC8996] 💀 So the definitions given here only apply to TLS 1.2 and TLS 1.3 🙅♀️
1.1. Interoperability Issues 🧩
This document has substantial changes from [RFC7170]. Mostly, these are clarifications and corrections to that specification 🎀
There's one major change from [RFC7170], though, and it's in the specification of the cryptographic-binding information 👀 There were multiple implementations of [RFC7170], and each one interpreted the text differently. So the implementations are interoperable, but only for a subset of the functionalities described in [RFC7170] 😬
This specification explains how TEAPv1 works in theory, and also which subset of TEAPv1 is currently interoperable 🧠 To keep the description of an already complex spec simple, all the interoperability issues are documented separately from the normal protocol operation 🫶
Please see Section 5 for more on interoperability issues 💅
1.2. 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 🌈
1.3. Terminology 📖
Most of the terminology in this document comes from [RFC3748] ✨ These extra terms are defined below:
- Type-Length-Value (TLV): TEAP uses objects in TLV format. The TLV format is defined in Section 4.2 🧚
- Inner Method: An authentication method that gets sent as application data inside a TLS exchange, which is carried over TEAP 🎀 The Inner Method can be an EAP authentication method, a username/password authentication, or a vendor-specific authentication method. And where the TLS connection is authenticated, the Inner Method could also be a Public Key Cryptography Standard (PKCS) exchange 🔐
2. Protocol Overview ✨
okay so bestie, TEAP authentication happens in two phases after the initial EAP Identity request/response exchange 🫶 In phase one, TEAP uses the TLS [RFC8446] handshake to do an authenticated key exchange and set up a protected tunnel 🔐 Once that tunnel exists, phase two starts, and the peer and server keep chatting to sort out the authentication and authorization policies they need. TEAP uses TLV objects to carry the inner authentication, results, and other stuff, like channel-binding information 💅
2.1. Identities and Session Setup
As discussed in Section 2.1.7 of [RFC9190] and Section 3.1 of [RFC9427], the outer EAP Identity SHOULD be an anonymous Network Access Identifier (NAI) as described in Section 2.4 of [RFC7542] 🎀 Section 5.1 of [RFC3748] puts no limits on what the Identity field can contain, but Section 2.6 of [RFC7542] says that Identities that don't follow the NAI format can't be sent through an Authentication, Authorization, and Accounting (AAA) proxy network 💀 So non-NAI Identities are likely to not work outside of limited, local networks. Lowkey a big deal!
Any inner identities (EAP or otherwise) SHOULD also follow the recommendations of [RFC9427], Section 3.1 about inner identities 🦋
[RFC7170] defined a Protected Access Credential (PAC) to mirror EAP-FAST [RFC4851]. However, implementation experience and analysis determined that the PAC wasn't necessary 🙈 Instead, TEAP does session resumption using the NewSessionTicket message, as defined in Sections 2.1.2 and 2.1.3 of [RFC9190] ✨ So the PAC has been deprecated, bye bye 👋
The TEAP conversation is used to establish or resume an existing session, typically to set up network connectivity between a peer and the network 🌸 When TEAP runs successfully, the EAP peer and EAP server both derive strong session key material (Master Session Key [RFC3748]) that can then be passed to the network access server (NAS) so it can set up a link-layer security association 🔥
2.1. Architectural Model
The network architectural model for TEAP usage looks like this 🧚
+----------+ +----------+ +----------+ +----------+
| | | | | | | Inner |
| Peer |<---->| Authen- |<---->| TEAP |<---->| Method |
| | | ticator | | server | | server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
Figure 1: TEAP Architectural ModelThe Peer and Authenticator are defined in [RFC3748], Section 1.2 🍓 The TEAP server is the "backend authentication server" defined in [RFC3748], Section 1.2 too. The "Inner Method server" is usually part of the TEAP server and handles the application data (Inner Methods, EAP, passwords, etc.) inside of the TLS tunnel 🔐
The entities above are logical entities, and they may or may not correspond to separate network components 💖 For example, the TEAP server and Inner Method server might be one single entity. The authenticator and TEAP server might be one entity too. Or the functions of the authenticator, TEAP server, and Inner Method server might all be combined into one physical device ✨ For instance, typical IEEE 802.11 deployments put the authenticator in an access point (AP), while a RADIUS server may provide the TEAP and inner method server components 📡 The diagram shows how the work is divided among entities in a general way, and how a distributed system might be built. Actual systems might be realized more simply, though 💅 The security considerations in Section 8.3 go deeper into what it means to separate the TEAP server from the Inner Method server, so go read that one, it's serious 😭
2.2. Protocol-Layering Model
TEAP packets are encapsulated within EAP, and EAP in turn needs a transport protocol 🌈 TEAP packets encapsulate TLS, which is then used to encapsulate user authentication information. So TEAP messaging can be described as a layered model, where each layer encapsulates the layer above it 🧁 Here's how the protocols fit together:
+------------------------------------------+
| Inner EAP Method | Other TLV information |
|------------------------------------------|
| TLV Encapsulation (TLVs) |
|------------------------------------------+---------------------+
| TLS | Optional Outer TLVs |
|----------------------------------------------------------------|
| TEAP |
|----------------------------------------------------------------|
| EAP |
|----------------------------------------------------------------|
| Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.) |
+----------------------------------------------------------------+
Figure 2: Protocol-Layering ModelThe TLV layer is a payload with TLV objects as defined in Section 4.2 🎀 TLV objects are used to carry arbitrary parameters between an EAP peer and an EAP server. All data exchanges in the TEAP-protected tunnel are encapsulated in a TLV layer, periodt 💜
Methods for encapsulating EAP within carrier protocols already exist. For example, IEEE 802.1X [IEEE.802-1X.2020] may be used to transport EAP between the peer and the authenticator. RADIUS [RFC3579] or Diameter [RFC4072] may be used to transport EAP between the authenticator and the EAP server 🦋
2.3. Outer TLVs Versus Inner TLVs
TEAP packets may include TLVs both inside and outside the TLS tunnel, defined as follows 👑
- Outer TLVs This term refers to optional TLVs outside the TLS tunnel, which are only allowed in the first two messages in the TEAP. That's the first EAP-server-to-peer message and the first peer-to-EAP-server message. If the message is fragmented, the whole set of fragments counts as one message 🧚
- Inner TLVs This term refers to TLVs sent within the TLS tunnel. In TEAP Phase 1, Outer TLVs are used to help establish the TLS tunnel, but no Inner TLVs are used. In Phase 2 of TEAP, TLS records may encapsulate zero or more Inner TLVs, but no Outer TLVs are used 🌸
3. TEAP Protocol 🎀
The operation of the protocol, including Phase 1 and Phase 2, is the topic of this section ✨ The format of TEAP messages is given in Section 4, and the cryptographic calculations are given in Section 6. Let's get into it!
3.1. Version Negotiation
TEAP packets contain a 3-bit Version field, following the TLS Flags field. This lets future TEAP implementations stay backward compatible with previous versions of the protocol 🦋 This specification documents the TEAP version 1 protocol, and implementations of this specification MUST use a Version field set to 1 💖
Version negotiation goes like this 💅
- In the first EAP-Request sent with EAP type=TEAP, the EAP server MUST set the Version field to the highest version it supports.
- If the EAP peer supports this version of the protocol, it responds with an EAP-Response of EAP type=TEAP, including the version number proposed by the TEAP server.
- If the TEAP peer does not support the proposed version but supports a lower version, it responds with an EAP-Response of EAP type=TEAP and sets the Version field to its highest supported version.
- If the TEAP peer only supports versions higher than the version proposed by the TEAP server, then use of TEAP will not be possible. In this case, the TEAP peer sends back an EAP-Nak either to negotiate a different EAP type or to indicate no other EAP types are available.
- If the TEAP server does not support the version number proposed by the TEAP peer, it MUST either terminate the conversation with an EAP Failure or negotiate a new EAP type.
- If the TEAP server does support the version proposed by the TEAP peer, then the conversation continues using the version proposed by the TEAP peer.
The version negotiation procedure guarantees that the TEAP peer and server will agree on the latest version supported by both parties 🔥 If version negotiation fails, use of TEAP won't be possible, and another mutually acceptable EAP method will need to be negotiated if authentication is going to proceed 😭
The TEAP version is not protected by TLS, so it can be modified in transit 🙈 To detect a bid-down attack on the TEAP version, the peers MUST exchange the TEAP version number received during version negotiation using the Crypto-Binding TLV described in Section 4.2.13. The receiver of the Crypto-Binding TLV MUST verify that the version received in the Crypto-Binding TLV matches the version sent by the receiver in the TEAP version negotiation. Bestie, this one is important 👑
Intermediate results are signaled via the Intermediate-Result TLV (Section 4.2.11). However, the Crypto-Binding TLV MUST be validated before any Intermediate-Result TLV or Result TLV is examined. If the Crypto-Binding TLV fails to be validated for any reason, then it's a fatal error and is handled as described in Section 3.9.3 🚨
The true success or failure of TEAP is conveyed by the Result TLV with value Success or Failure 🌈 But since EAP terminates with either a cleartext EAP Success or Failure, a peer will also receive a cleartext EAP Success or Failure. The received cleartext EAP Success or Failure MUST match the one received in the Result TLV. The peer SHOULD silently discard those cleartext EAP Success or Failure messages that don't coincide with the status sent in the protected Result TLV 🫶
3.2. TEAP Authentication Phase 1: Tunnel Establishment ✨
Okay so TEAP leans on the TLS handshake [RFC8446] to build an authenticated and protected tunnel 🔐💖. The TLS version that the peer and server offer MUST be TLS version 1.2 [RFC5246] or later 🌸. This version of the TEAP implementation MUST support these TLS cipher suites, no exceptions 💅:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Other cipher suites MAY be supported 🦋. Implementations MUST implement the recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2 and in [RFC8446], Section 9.1 for TLS 1.3 🧚.
It is REQUIRED that anonymous cipher suites, like TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC5246], only get used when the Inner Method gives you mutual authentication, key generation, and resistance to on-path and dictionary attacks 🙈. TLS cipher suites that don't provide confidentiality MUST NOT be used, period 🚫. During TEAP Phase 1, the TEAP endpoints MAY negotiate TLS compression 🎀. During TLS tunnel establishment, TLS extensions MAY be used too. For example, the Certificate Status Request extension [RFC6066] and the Multiple Certificate Status Request extension [RFC6961] can be used to work with a certificate-status protocol like the Online Certificate Status Protocol (OCSP) [RFC6960] to check that server certificates are still valid ✨. TLS renegotiation indications defined in [RFC5746] MUST be supported 🫶.
Use of TLS-PSK is NOT RECOMMENDED 💀. TEAP was never designed to work with TLS-PSK, and there have been no use cases, security analyses, or implementations for it. Whether TLS-PSK works with TEAP depends on the specific implementation, so it's not useful to deploy it 😭.
The EAP server kicks off the TEAP conversation with an EAP request containing a TEAP/Start packet 🍓. This packet has a set Start (S) bit, the TEAP version from Section 3.1, and an authority identity TLV. The TLS payload in that first packet is empty. The authority identity TLV (Authority-ID TLV) gives the peer a hint about the server's identity, which can help the peer pick the right credential to use 🔥. Assuming the peer supports TEAP, the conversation keeps going when the peer sends back an EAP-Response packet with EAP type of TEAP, the Start (S) bit clear, and the version from Section 3.1. This message carries one or more TLS handshake messages 👑. If the TEAP version negotiation works out, the TEAP conversation keeps going until the EAP server and EAP peer are ready to enter Phase 2 🌈. When the full TLS handshake is done, the first payload of TEAP Phase 2 MAY be sent along with a server-finished handshake message to cut down on round trips ⭐.
TEAP implementations MUST support mutual peer authentication during tunnel establishment, using the TLS cipher suites specified in this section 💜. The TEAP peer doesn't have to authenticate as part of the TLS exchange, though. It can be authenticated through extra exchanges in Phase 2 instead 🦋.
The TEAP tunnel keeps peer identity information from Phase 2 hidden from anyone outside the tunnel 🤫. If you want identity privacy for the peer, you really need to think hard about what gets revealed outside the tunnel before Phase 2 👀. TEAP implementations SHOULD support immediate renegotiation of a TLS session, so they can start a new handshake message exchange under the protection of the current cipher suite 🧁. This is what makes it possible to protect the peer's identity when TLS client authentication is in use. Appendix C has an example of exchanges that use TLS renegotiation to protect privacy 📖.
3.3. Server Certificate Requirements 🎀
Server certificates MUST include a subjectAltName extension, with the dnsName attribute holding a Fully Qualified Domain Name (FQDN) string 🌷. Server certificates MAY also include a SubjectDN with a single element, "CN=", which contains the server's FQDN. Heads up though: using SubjectDN like this is deprecated for TEAP and is forbidden in [RFC9525], Section 2 🙅♀️.
The KeyUsage extensions MAY be included, but they aren't required 🌸.
The Extended Key Usage extensions defined in [RFC5280] MAY also be included, but their use is discouraged 🙃. Systems SHOULD use a private Certification Authority (CA) for EAP instead of public CAs 🏢. The most commonly used public CAs are focused on the web, and those certificates aren't always suitable for EAP. Private CAs, on the other hand, can be designed for any purpose and restricted to an enterprise or some other organization 💼✨.
3.4. Server Certificate Validation 🔍
During TLS negotiation, the server usually presents a certificate to the peer 📜. In most cases the certificate does need validating, but there are a few situations where the EAP peer doesn't have to do certificate validation 🙌:
- when the peer has the server's End Entity (EE) certificate pinned or loaded directly into its trusted anchor information [RFC4949];
- when the peer is requesting server unauthenticated provisioning;
- when the peer is certain that it will be using an authenticated Inner Method.
In some cases, like onboarding (or "bootstrapping"), certificate validation can be delayed 🕰️. But once onboarding has happened, the validation steps described below MUST still be performed 🔒.
In all other cases, the EAP peer MUST validate the server certificate 💅. This validation works the same way it does for EAP-TLS, which is covered in [RFC9190], Section 5.3 and in [RFC5216], Section 5.3. For more on server identity validation, check [RFC9525], Section 6 🧠.
If the EAP peer has an NAI, EAP peers MUST use the realm to perform the DNS-ID validation, as per [RFC9525], Section 6 🪄. The realm gets used in two places: to build the list of reference identifiers defined in [RFC9525], Section 6, and as the "source domain" field of that same section 🌈.
When doing server certificate validation, implementations MUST also support the rules in [RFC5280] for validating certificates against a known trust anchor 🛡️. On top of that, implementations MUST support matching the realm portion of the peer's NAI against a SubjectAltName of type dnsName within the server certificate. Still, in certain deployments this comparison might not be appropriate or enabled 🤷♀️.
Most of the time the EAP peer won't have network access during authentication 📵. So it has no way to match the server identity in the certificate from the EAP server with a hostname, the way other protocols like HTTPS do 😩. That means that if the EAP peer has no preconfigured trust anchor, it will have few, if any, ways to validate the server's certificate 🥲.
3.4.1. Client Certificates Sent During Phase 1 🔐
Heads up: TLS client certificates are sent in the clear with TLS 1.2, so if you need identity protection, the TLS authentication can be renegotiated after the first server authentication 🙈. To make that happen, the server will typically not request a certificate in the server_hello. Then, after the server_finished message is sent and before TEAP Phase 2, the server MAY send a TLS hello_request 💫. This lets the peer do client authentication by sending a client_hello if it wants to, or by sending a no_renegotiation alert to the server to say it would rather continue with TEAP Phase 2 instead. If the peer allows renegotiation by sending a client_hello, the server responds with server_hello, certificate, and certificate_request messages. The peer replies with certificate, client_key_exchange, and certificate_verify messages 📨. Since this renegotiation happens inside the encrypted TLS channel, it doesn't reveal client certificate details 🤐. You can also do certificate authentication using EAP (for example, EAP-TLS) inside the TLS session in TEAP Phase 2, instead of using TLS handshake renegotiation 🦋.
When TLS 1.3 or later is in use, it is RECOMMENDED that client certificates get sent in Phase 1 instead of through Phase 2 and EAP-TLS 🚀. Doing that cuts down on round trips. More on this is in Section 3.6.5 below 👀.
3.5. Resumption 🔁
For resumption, [RFC9190], Section 5.7 talks about EAP-TLS resumption for all versions of TLS, and it's incorporated here by reference 📚. [RFC9427], Section 4 is also incorporated by reference, since it gives general discussion of resumption for TLS-based EAP methods when TLS 1.3 is used 🌟.
This document only describes TEAP-specific issues for resumption when TLS 1.2 or earlier is used. It also describes resumption issues that are specific to TEAP for TLS 1.3 🎯.
If the server agrees to resume the session, Phase 2 gets skipped entirely ⏭️. If the server doesn't agree, it rejects the resumption as per [RFC9190], Section 5.7, and then carries on with a full handshake. After the full TLS handshake is complete, both the EAP server and peer MUST proceed with Phase 2 🙌.
All TEAP implementations MUST support resumption 💖. Resumption can seriously boost the scalability and stability of authentication systems. For example, some environments like universities might have users re-authenticating several times a day, if not every hour 🎓. Without resumption, the load on the user database would go up by orders of magnitude, and that means unnecessary cost 💸.
The next sections describe how a TEAP session can be resumed based on server-side or client-side state 🧚♀️.
3.5.1. TLS Session Resumption Using Server State 🗄️
TEAP session resumption works the same way TLS session resumption does 🌸. To support it, the server and peer cache the Session ID, master secret, and cipher suite. The peer tries to resume a session by including a valid Session ID from a previous TLS handshake in its ClientHello message. If the server finds a match for the Session ID and is willing to establish a new connection using that session state, it responds with the same Session ID and carries on with TEAP Phase 1 tunnel establishment through a TLS abbreviated handshake 🦋.
3.5.2. TLS Session Resumption Using Client State 🎟️
TEAP supports resuming sessions based on state stored on the client side, using the TLS SessionTicket extension techniques described in [RFC5077] and [RFC9190] 💜.
3.6. TEAP Authentication Phase 2: Tunneled Authentication ✨
okay so Phase 2 is the second part of TEAP authentication, and it kicks off right after Phase 1 wraps up successfully 💖 It happens even if the peer and the authenticator were both already authenticated during the Phase 1 TLS negotiation 🫶 But Phase 2 MUST NOT happen if the Phase 1 TLS handshake fails, bestie, because the tunnel never got set up properly and that would seriously compromise security 😭 Phase 2 is a bunch of requests and responses wrapped up in TLV objects from Section 4.2 🎀 It MUST always finish with a Crypto-Binding TLV exchange (Section 4.2.13) and a protected termination exchange (Section 3.6.6) 💅
If the peer wasn't authenticated in Phase 1, the TEAP peer SHOULD send one or more Identity-Hint TLVs (Section 4.2.20) as soon as the TLS connection is up 🧚 This is lowkey important because it tells the TEAP server which kind of authentication fits that identity 👑 If the peer doesn't send an Identity-Hint TLV, the server has no idea which Inner Method the peer supports 🙈 So it has to pick an Inner Method and offer it, and the peer is allowed to say no to it 💀 Then the peer fails to authenticate and doesn't get network access, which is literally the worst outcome 😭
The TLV exchange can include zero or more inner methods running inside the protected tunnel, as described in Sections 3.6.2 and 3.6.3 🌈 A server MAY skip straight to the protected termination exchange with no inner authentication at all, if it doesn't want to ask the peer for anything else 🦋 A server MAY also request one or more authentications inside the tunnel 🍓 After each Inner Method finishes, the server decides whether to start another one or send a Result TLV ✨
Implementations MUST support at least two sequential Inner Methods, so machine and user authentication can both happen 💜 Implementations SHOULD also limit how many sequential inner authentications they do, because there's no good reason to run a huge pile of them in one TEAP conversation 🙈
Implementations that want their own proprietary authentication method can swap the EAP-Payload or Basic-Password-Auth-Req TLV in for the Vendor-Specific TLV, which carries that other method 🎀 Any vendor-specific method MUST support calculating the Crypto-Binding TLV, and it MUST use Intermediate-Result TLV and Result TLV the same way every other method does 💅
3.6.1. Inner Method Ordering 🦋
Due to the issues covered in Section 5, the order of Inner Methods matters for both security and interoperability 👑
When authentication is expected to use multiple Inner Methods, implementations SHOULD order them so that a method which derives an Extended Master Session Key (EMSK) goes first, before any other method 🔥 This ordering helps tie the Inner Method securely to the TLS session, and that can prevent attacks 🫶
Implementations SHOULD support both EAP and basic password authentication for inner methods ✨ Implementations that support multiple types of Inner Methods (User and Machine) MUST support all of those methods in any order or combination 💖 It's explicitly allowed to "mix and match" Inner Methods, so go wild 🌈
For example, a server can ask for user authentication and the peer can answer with machine authentication (or the other way around) 🍓 If the server is set up to accept machine authentication, it MUST accept that response 💅 If that authentication succeeds, then depending on local policy, the server SHOULD go ahead and request user authentication again 🧚
Similarly, a peer that supports multiple types of Inner Methods (User and Machine) can return a method other than the one the server asked for 🦋 The peer usually does this so it can order Inner Methods for better security 🔐 See Section 6.2.3 for more on this issue 💜
However, the peer and server MUST NOT assume that either one will skip Inner Methods or other TLV exchanges 😭 The other side might have a different security policy 🙈 The peer might have roamed onto a network that needs a different authentication policy, or the peer might ask the server to take extra action (for example, channel binding) using the Request-Action TLV defined in Section 4.2.9 🌸
The completion of each Inner Method is signaled by an Intermediate-Result TLV 🌟 If the Intermediate-Result TLV says failure, an Error TLV SHOULD also be included, using the most descriptive error code possible 💀 The Intermediate-Result TLV can come with another TLV saying the server wants to do a subsequent authentication 🎀 When every Inner Method is done, the server MUST send a Result TLV that says success or failure, instead of a TLV carrying an Inner Method 👑
3.6.2. Inner EAP Authentication 🫧
EAP [RFC3748] doesn't allow multiple authentication methods inside a single EAP conversation, which keeps on-path attacks in check 🧐 TEAP handles on-path attacks by cryptographically protecting the inner EAP exchange and cryptographically binding the inner EAP method(s) to the protected tunnel 🔒 Inner Methods run one after another in a sequence 🚶♀️ This version of TEAP does NOT support starting multiple Inner Methods at the same time in parallel 🙅♀️ The Inner Methods don't have to be different from each other 👯 For example, EAP-TLS ([RFC5216] and [RFC9190]) could run twice as an inner method, first with machine credentials and then again with user credentials 💅
When EAP is used as an Inner Method, the EAP messages ride inside EAP-Payload TLVs defined in Section 4.2.10 🎁 TEAP is basically just a carrier for EAP here, kind of like how RADIUS is a carrier for EAP 🚚 The full EAP state machine runs as normal and gets carried over the EAP-Payload TLV ✨ Each separate EAP authentication MUST be managed as its own EAP state machine 🦋
So a TEAP server MUST start an EAP authentication with an EAP-Request/Identity (carried in an EAP-Payload TLV) 🌸 But a TEAP server MUST NOT finish the EAP conversation with an EAP Success or EAP Failure packet 🙅♀️ The Intermediate-Result TLV does that job instead 💖
When each EAP authentication finishes inside the tunnel, the server MUST send an Intermediate-Result TLV showing the result of that authentication 🔥 If the result is success, it MUST come with a Crypto-Binding TLV 🫶 The peer MUST respond to the Intermediate-Result TLV with its own result 💅 Likewise, on success the peer MUST attach its own Crypto-Binding TLV 🌈 The peer MUST respond to the Intermediate-Result TLV with its own result, and on success it MUST attach its own Crypto-Binding TLV too 👑 The Crypto-Binding TLV gets more detail in Sections 4.2.13 and 6.3 🧚 Intermediate-Result TLVs can ride along with other TLVs that signal a subsequent authentication, or with the Result TLV used in the protected termination exchange 🎀
If both peer and server indicate success, the authentication counts as successful ✅ If either one indicates failure, the authentication counts as failed 🙈 A failed EAP authentication doesn't always mean the whole authentication has failed 💁♀️ If one Inner Method fails, the server may try authenticating the peer with a different method (EAP or password) 🦋
3.6.3. Inner Password Authentication 🔐
The authentication server (AS) starts password authentication by sending a Basic-Password-Auth-Req TLV defined in Section 4.2.14 🎀 If the peer wants to take part in password authentication, it replies with a Basic-Password-Auth-Resp TLV containing the username and password, as defined in Section 4.2.15 💖 If it doesn't want to do password authentication, it replies with a Negative Acknowledgment (NAK) TLV rejecting the Basic-Password-Auth-Req TLV 🙅♀️
This basic password authentication works a lot like EAP-TTLS [RFC5281] with inner password authentication 🌸 It has a similar security and risk analysis too 🧐
Multiple round trips of password requests and responses MAY be used for "housekeeping" stuff, like changing a password or PIN before a user counts as authenticated 🧹 Multiple rounds MAY also be used to send a user's password and, separately, a one-time password such as Time-Based One-Time Passwords (TOTPs) [RFC6238] 🔑
Implementations MUST limit the number of round trips for password authentication 🛑 One or two round trips is reasonable 👍 More round trips are likely to be a problem and SHOULD be avoided 🙈
The first Basic-Password-Auth-Req TLV received in a session MUST include a prompt, which the peer shows to the user 💬 Later rounds SHOULD include a prompt too, but it isn't always necessary ✨
When the peer first gets a Basic-Password-Auth-Req TLV, it should let the user enter both a username and a password, which then go into the Basic-Password-Auth-Resp TLV 🎀 If the peer gets later Basic-Password-Auth-Req TLVs in the same authentication session, it MUST NOT ask for a username and MUST only let the user enter a password 🙅♀️ The peer MUST copy the username from the first Basic-Password-Auth-Resp TLV into every later Basic-Password-Auth-Resp TLV 💅
Servers MUST track the username across multiple password rounds and reject authentication if the identity changes from one Basic-Password-Auth-Resp TLV to the next 🚫 There's no reason for a user (or machine) to switch identities in the middle of authentication 🙄
When the server receives a Basic-Password-Auth-Resp TLV in the tunnel, it MUST send an Intermediate-Result TLV showing the result 🔥 The peer MUST respond to the Intermediate-Result TLV with its result 💖 If the result is success, the Intermediate-Result TLV MUST come with a Crypto-Binding TLV 🫶 The Crypto-Binding TLV gets more detail in Sections 4.2.13 and 6.3 🧚
Intermediate-Result TLVs can be included with other TLVs that signal a subsequent authentication, or with the Result TLV used in the protected termination exchange 🌈
The use of EAP-FAST-GTC as defined in [RFC5421] is NOT RECOMMENDED with TEAPv1, because EAP-FAST-GTC isn't compliant with EAP-GTC defined in [RFC3748] 🙈 Implementations should use the password authentication TLVs defined in this specification instead 🎀
3.6.4. EAP-MSCHAPv2 🍓
If you're using EAP-MSCHAPv2 [KAMATH] as an inner EAP method, the EAP-FAST-MSCHAPv2 variant defined in [RFC5422], Section 3.2.3 MUST be used instead of the derivation defined in [MSCHAP] 💅 The difference is that the first and second 16 octets of the EAP-MSCHAPv2 Master Session Key (MSK) get swapped when they're used as the Inner Method Session Keys (IMSKs) for TEAP 🔄✨
3.6.5. Limitations on Inner Methods 🔒✨
okay bestie, inner methods need a bouncer 💅 Implementations SHOULD limit the permitted inner EAP methods to a small set, like EAP-TLS and the EAP-FAST-MSCHAPv2 variant of EAP-MSCHAPv2. These are the most commonly supported inner methods in TEAP and they're known to work together across multiple implementations 🫶
Other EAP methods like EAP-pwd, EAP-SIM, EAP-AKA, or EAP-AKA' can be used inside a TEAP tunnel 🦋 Any EAP method that derives both MSK and EMSK is likely to work as an Inner Method for TEAP, because EAP-TLS does that and it works, no cap. EAP methods that only derive MSK should work too, since EAP-FAST-MSCHAPv2 does that and it works. Anything else is untested, so it may or may not work 🤷♀️
Now the tea ☕ Tunneled EAP methods like PEAP [PEAP], EAP-TTLS [RFC5281], and EAP-FAST [RFC4851] MUST NOT be used for inner EAP authentication. There is zero reason to stack multiple layers of TLS just to protect a password exchange 💀
The EAP methods defined in [RFC3748], Section 5, like MD5-Challenge, One-Time Password (OTP), and Generic Token Card (GTC), don't derive an MSK or an EMSK, and they're vulnerable to on-path attacks 😭 The OTP and GTC methods make that attack less relevant, since the info being sent is usually a one-time token. But EAP-OTP and EAP-GTC give you nothing extra over the basic password authentication in Section 3.6.3, which also doesn't do crypto-binding of the Inner Method to the TLS session. So these aren't useful as Phase 2 methods in TEAP 🙅♀️
Other EAP methods are less widely used and are highly likely to not work as the inner EAP method for TEAP 🥀
To protect against on-path attacks, TEAP implementations MUST NOT permit the use of inner EAP methods that fail to perform crypto-binding of the Inner Method to the TLS session. Non-negotiable, periodt 👑
Implementations MUST NOT permit resumption for the inner EAP methods such as EAP-TLS. If the user or machine needs to be authenticated, it should use a method that provides full authentication. If the user or machine needs to do resumption, it can do a full authentication once and then rely on the outer TLS session for resumption 🌸 This restriction also applies to all TLS-based EAP methods that can tunnel other EAP methods. As a result, this document updates [RFC9427] ✨
In general, the reason to use a non-TLS-based EAP method inside a TLS-based EAP method like TEAP is privacy 🙈 Lots of previous EAP methods can leak info about user identity, and running the method inside a protected TLS tunnel stops those leaks. Iconic protection energy 🧚
EAP-TLS is permitted in Phase 2 for two use cases. The first is when TLS 1.2 is used, because the client certificate isn't protected the way it is in TLS 1.3. So it is RECOMMENDED that when TLS 1.3 is used for the outer TEAP exchange, the client certificate is sent in Phase 1 instead of doing EAP-TLS in Phase 2 🍓 That simplifies the authentication exchange and uses fewer round trips than doing EAP-TLS inside TEAP, which is so efficient, bestie 💖
The second use case for EAP-TLS in Phase 2 is where both the user and the machine use client certificates for authentication. TLS only lets one client certificate be presented, so only one certificate can be used in Phase 1. The second certificate then gets presented via EAP-TLS in Phase 2 🎀
For basic password authentication, it is RECOMMENDED that this method only be used for the exchange of one-time passwords 🔑 Password-based EAP methods like EAP-pwd ([RFC5931] and [RFC8146]) mean most cleartext password exchanges are unnecessary. The updates to EAP-pwd in [RFC8146] let it work with databases that store passwords in "salted" form, which greatly increases security 🛡️
Where no Inner Method provides an EMSK, the Crypto-Binding TLV offers little protection, because it can't tie the inner EMSK to the TLS session via the TLS-PRF 😬 So the TEAP session will be vulnerable to on-path active attacks. Implementations and deployments SHOULD adopt various mitigation strategies described in [RFC7029], Section 3.2. Implementations also need to implement the Inner Method ordering described in Section 6.1 to fully prevent on-path attacks 💅
3.6.6. Protected Termination and Acknowledged Result Indication 🎬
A successful TEAP Phase 2 conversation MUST always end in a successful Crypto-Binding TLV and Result TLV exchange. A TEAP server may start the Crypto-Binding TLV and Result TLV exchange without starting any Inner Methods in TEAP Phase 2 ✨ After the final Result TLV exchange, the TLS tunnel is terminated, and the server sends a cleartext EAP Success or EAP Failure. Peers implementing TEAP MUST NOT accept a cleartext EAP Success or Failure packet before the peer and server have reached synchronized protected result indication. No jumping the gun 🙅♀️
The Crypto-Binding TLV exchange proves that both the peer and the server took part in the tunnel establishment and the sequence of authentications 🤝 It also verifies the TEAP type, the version negotiated, and the Outer TLVs exchanged before the TLS tunnel was set up. Except as noted below, the Crypto-Binding TLV MUST be exchanged and verified before the final Result TLV exchange, whether or not there's an Inner Method. The Crypto-Binding TLV and Intermediate-Result TLV MUST be included to do cryptographic binding after each successful authentication in a sequence of one or more Inner Methods 💜 The server may send the final Result TLV along with an Intermediate-Result TLV and a Crypto-Binding TLV to show it wants to end the conversation. If the peer doesn't need anything else from the server, it responds with a Result TLV indicating success, plus a Crypto-Binding TLV and an Intermediate-Result TLV if needed. Then the server tears down the tunnel and sends a cleartext EAP Success or EAP Failure 🌈
If the peer gets a Result TLV indicating success from the server, but its authentication policies aren't satisfied (say, it needs a particular authentication mechanism to run), it may ask the server for further action using the Request-Action TLV 🥺 The Request-Action TLV is sent with a Status field showing which EAP Success/Failure result the peer would expect if the requested action isn't granted. The Action field's value says what the peer would like to do next. The format and values for the Request-Action TLV are defined in Section 4.2.9 📋
When the server gets the Request-Action TLV, it may process the request or ignore it, depending on its policy. If the server ignores it, it ends the tunnel and sends the cleartext EAP Success or Failure based on the Status field of the peer's Request-Action TLV. If the server honors and processes the request, it carries on with the requested action. The conversation finishes with a Result TLV exchange, and the Result TLV may be included with the TLV that completes the requested action 🏁
Error handling for Phase 2 is discussed in Section 3.9.3 🛠️
3.7. Determining Peer-Id and Server-Id 🪪
The Peer-Id and Server-Id [RFC5247] may be determined based on the types of credentials used during either the TEAP tunnel creation or the authentication 🔍 If there are multiple peer authentications, all authenticated peer identities and their matching identity types (Section 4.2.3) need to be exported. If there are multiple server authentications, all authenticated server identities need to be exported 👯♀️
When X.509 certificates are used for peer authentication, the Peer-Id is determined by the subject and subjectAltName fields in the peer certificate. As [RFC5280] puts it:
The subject field identifies the entity associated with the public key stored in the subject public key field. The subject name MAY be carried in the subject field and/or the subjectAltName extension. . . . If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical. Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN).
If an inner EAP authentication method is run, the Peer-Id comes from that inner EAP authentication method 🫧
When the server uses an X.509 certificate to set up the TLS tunnel, the Server-Id is figured out the same way as the Peer-Id above. So the subject and subjectAltName fields in the server certificate define the Server-Id 🖥️
3.8. TEAP Session Identifier 🆔
For TLS 1.2 and earlier, the EAP session identifier [RFC5247] is built using the tls-unique from the Phase 1 outer tunnel at the start of Phase 2, as defined by Section 3.1 of [RFC5929]. The Session-Id is defined like this:
Session-Id = teap_type | tls-uniqueWhere:
- | denotes concatenation,
- teap_type is the EAP Type assigned to TEAP, and
- tls-unique = tls-unique from the Phase 1 outer tunnel at the beginning of Phase 2 as defined by Section 3.1 of [RFC5929].
The Session-Id derivation for TLS 1.3 is given in [RFC9427], Section 2.1 ✨
3.9. Error Handling 🚨
TEAP uses the error-handling rules summed up below:
- Errors in the outer EAP packet layer are handled as defined in Section 3.9.1.
- Errors in the TLS layer are communicated via TLS alert messages in both phases of TEAP.
- The Intermediate-Result TLVs carry success or failure indications of the individual Inner Methods in TEAP Phase 2. Errors within an EAP conversation in Phase 2 are expected to be handled by the individual EAP authentication methods.
- Violations of the Inner TLV rules are handled using Result TLVs together with Error TLVs.
- Tunnel-compromised errors (errors caused by a failed or missing Crypto-Binding) are handled using Result TLVs and Error TLVs.
3.9.1. Outer-Layer Errors 📦
Errors on the TEAP outer-packet layer are handled in these ways:
- If Outer TLVs are invalid or contain unknown values, they will be ignored.
- The entire TEAP packet will be ignored if other fields (version, length, flags, etc.) are inconsistent with this specification. 💀
3.9.2. TLS Layer Errors 🔐✨
Okay so, if the TEAP server spots an error anywhere in the TLS handshake or the TLS layer, it SHOULD send a TEAP request that wraps a TLS record holding the matching TLS alert message 🚨. It does this instead of slamming the door and ending the TEAP exchange right away, so the peer gets a chance to tell the user what actually went wrong 🫶. The TEAP peer MUST send a TEAP response to an alert message 💌. The EAP-Response packet from the peer SHOULD contain a TEAP response with a zero-length message 🍓. And then the server MUST terminate the TEAP exchange with an EAP Failure packet no matter what the client says 💀.
If the TEAP peer runs into an error anywhere in the TLS layer, it SHOULD send a TEAP response that wraps a TLS record with the appropriate TLS alert message, and that record holds a zero-length message 🧚. The server then MUST terminate the conversation with an EAP failure, same as in the paragraph above 😭.
TLS 1.3 [RFC8446] allows the TLS conversation to be restarted, but it's not clear when that would be useful (or even used) for TEAP 🤷♀️. Fatal TLS errors make the TLS conversation fail. Non-fatal TLS errors can likely be ignored entirely 🌸. So TEAP implementations MUST NOT permit TLS restarts 🚫.
3.9.3. Phase 2 Errors 🧨
There are a LOT of situations where errors can pop up during Phase 2 processing 🙈. This section covers both the errors and the recommended way to process them 📝.
When the server gets a Result TLV with a fatal Error TLV from the peer, it MUST terminate the TLS tunnel and reply with an EAP Failure 💔.
When the peer gets a Result TLV with a fatal Error TLV from the server, it MUST respond with a Result TLV indicating failure 🥀. The server MUST discard any data it receives from the peer and reply with an EAP Failure 🙅. The final message from the peer is required by the EAP state machine. It only exists so the server can send that EAP Failure back to the peer 💅.
The following items describe specific errors and how they're processed, in more detail 👀.
Fatal Error processing a TLV: Any time the peer or the server finds a fatal error outside of the TLS layer during Phase 2 TLV processing, it MUST send a Result TLV of failure and an Error TLV using the most descriptive error code possible 🛑.
Fatal Error during TLV Exchanges: For errors involving the processing of the sequence of exchanges, such as a violation of TLV rules (e.g., multiple EAP-Payload TLVs), the error code is Unexpected TLVs Exchanged 🙃.
Fatal Error due to tunnel compromise: For errors involving a tunnel compromise, such as when the Crypto-Binding TLV fails validation, the error code is Tunnel Compromise Error 🚨🔓.
Non-Fatal Error due to Inner Method: If there is a non-fatal error while running the Inner Method, the receiving side SHOULD NOT silently drop the Inner Method exchange 🙅♀️. Instead, it SHOULD reply with an Error TLV using the most descriptive error code possible 💬.
If there's no error code that matches the particular issue, then the value Inner Method Error (1001) SHOULD be used 🎯. This response is a positive indication that there was an error processing the current Inner Method ✨. The side receiving a non-fatal Error TLV MAY decide to start a new and different Inner Method instead, or send back a Result TLV to terminate the TEAP authentication session 🦋.
3.10. Fragmentation 🧩
Fragmentation of EAP packets is discussed in [RFC5216], Section 2.1.5 📦. There is no special handling of fragments for TEAP, so nothing extra to worry about 💖.
3.11. Services Requested by the Peer 🎀
Several TEAP operations depend on the peer trusting the TEAP server 🥹. These include server unauthenticated provisioning, certificate provisioning, and channel binding. If the peer trusts the provided server certificate, then the server is authenticated 🔑.
Typically, this authentication process means the peer validates the certificate to a trust anchor. It verifies that the server presenting the certificate holds the private key, and confirms that the entity named by the certificate is the intended server 🕵️♀️. Server authentication also happens when the procedures in Section 3.2 are used to resume a session where the peer and server were previously mutually authenticated 🔄. Or, the server is deemed authenticated if an inner EAP method provides mutual authentication along with an MSK and/or EMSK. The Inner Method MUST also provide for cryptographic binding via the Compound Message Authentication Code (MAC), as discussed in Section 4.2.13 🔗. This issue is further described in Section 3.11.3 📖.
TEAP peers MUST track whether or not server authentication has taken place 📋. When the server cannot be authenticated, the peer MUST NOT request any services from it, such as certificate provisioning (Section 3.11.1) 🚫.
Unless the peer requests server unauthenticated provisioning, it MUST authenticate the server and fail the current authentication session 🙅♀️. The authentication session fails if the server cannot be authenticated 💀.
Here's a plot twist 🌀: an Inner Method can authenticate multiple parties, like both the peer machine and the peer user to the EAP server. Depending on how authentication is achieved, only some of these parties may have confidence in it 🤔. For example, say a strong shared secret is used to mutually authenticate the user and the EAP server. The machine may not have confidence that the EAP server is the authenticated party if the machine can't trust the user not to disclose the shared secret to an attacker 😱. In these cases, the parties who take part in the authentication need to be considered when evaluating whether the peer should request these services, or whether the server should provide them 🧐.
The server MUST also authenticate the peer before providing these services 🛡️. The alternative is sending provisioning data to unauthenticated and potentially malicious peers, which can have negative impacts on security 🙀.
When a device is provisioned via TEAP, any subsequent authorization MUST be done on the authenticated credentials 🪪. That means there may be no credentials (or anonymous credentials) passed in Phase 1, but there will be credentials passed or provisioned in Phase 2 ✨. If later authorizations are done on the Phase 1 identity, a device could obtain the wrong authorization 😬. If authorization is done on the authenticated credentials instead, then the device will obtain the correct kind of network access 🎉.
The correct authorization must also be applied to any resumption, as noted in [RFC9190], Section 5.7 🔁. However, since it's possible in TEAP for the credentials to change, the new credentials MUST be associated with the session ticket 🎟️. If this association can't be done, then the server MUST invalidate any session tickets for the current session 💥. That invalidation forces a full re-authentication on any subsequent connection. At that point, the correct authorization will be associated with any session ticket 🔄💖.
Note that re-provisioning a device is basically indistinguishable from any initial provisioning 👯. The device authenticates and obtains new credentials via the standard provisioning mechanisms. The only caveat is that the device SHOULD NOT discard the old credentials, unless either they are known to have expired or the new credentials have been verified to work 🗝️⚠️.
3.11.1. Certificate Provisioning Within the Tunnel 🔏
Provisioning a peer's certificate is supported in TEAP by performing the Simple PKI Request/Response from [RFC5272], using PKCS#10 and PKCS#7 TLVs, respectively 📜. A peer sends the Simple PKI Request using a PKCS#10 CertificationRequest [RFC2986] encoded into the body of a PKCS#10 TLV (see Section 4.2.17) 📨. The TEAP server issues a Simple PKI Response using a PKCS#7 [RFC2315] unsigned (i.e., degenerate) "Certificates Only" message. That message gets encoded into the body of a PKCS#7 TLV (see Section 4.2.16). The server only does this after an Inner Method has run and provided an identity proof on the peer, prior to a certificate is being issued 🪄.
To provide linking identity and proof-of-possession, the peer generating the request SHOULD include information specific to the current authenticated TLS session inside the signed certification request 🔗. It does this by obtaining the tls-unique value from the TLS subsystem, as defined in "Channel Bindings for TLS" [RFC5929] 🧷. The TEAP peer operations between obtaining the tls-unique value and generating the Certification Signing Request (CSR) that contains the current tls-unique value, plus the later verification of this value by the TEAP server, are the "phases of the application protocol during which application-layer authentication occurs". Those phases are protected by the synchronization interoperability mechanism described in the interoperability note in "Channel Bindings for TLS" ([RFC5929], Section 3.1) 🔐. When performing renegotiation, TLS "secure_renegotiation" [RFC5746] MUST be used 🔁.
The tls-unique value is base-64-encoded as specified in Section 4 of [RFC4648], and the resulting string is placed in the certification request challengePassword field ([RFC2985], Section 5.4.1) 🍬. The challengePassword field is limited to 255 octets (Section 7.4.9 of [RFC5246] indicates that no existing cipher suite would result in an issue with this limitation) 📏. If tls-unique information is not embedded within the certification request, the challengePassword field MUST be empty to indicate that the peer did not include the optional channel-binding information. Any value submitted is verified by the server as tls-unique information 🫙.
The server SHOULD verify the tls-unique information 🕵️. This makes sure the signed certificate request is being presented by an authenticated TEAP peer that is in possession of the private key 🗝️💅.
The Simple PKI Request/Response generation and processing rules of [RFC5272] SHALL apply to TEAP, with the exception of error conditions 🙌. In the event of an error, the TEAP server SHOULD respond with an Error TLV using the most descriptive error code possible. It MAY ignore the PKCS#10 request that generated the error 🫠.
3.11.2. Certificate Content and Uses
okay so bestie, it is NOT enough to check that the CSR the peer sends to the authenticator is from an authenticated user 🙅♀️ the CSR itself should also get examined by the authenticator or the CA before any certificate gets issued 🎀
A CSR is a seriously complex object with a whole pile of info in it 📄 and that info could be wrong 😬 like a user claiming a fake physical address or email address, or whatever. It is RECOMMENDED that the systems provisioning these certificates check that the CSR has the data they expect and does NOT have unexpected data 💅 For example, a CA could refuse to issue the certificate if the CSR had unknown fields, or if a known field had an unexpected or invalid value ✨ The CA can modify or refuse any CSR to fix these problems for any reasons, including local site policy 🫶 Also, the "A" in "CA" stands for "Authority" and the "R" in "CSR" stands for "Request" 🌸 There is NO requirement for a CA to sign every single CSR that shows up at its door 💀
Once an EAP peer gets the signed certificate, the peer could potentially be (ab)used in TLS contexts other than TEAP 😭 For example, the certificate could be used with EAP-TLS, or even with HTTPS. It is NOT RECOMMENDED to use certificates provisioned via TEAP for any non-TEAP purpose 🚫 One way to enforce this is to have different CAs (or different intermediate CAs) issue certificates for different uses 🦋 For example, TLS-based EAP methods could share one CA, and even use different intermediary CAs for different TLS-based EAP methods. HTTPS servers could use an entirely different CA 🌈 The different protocols could then be configured to validate client certificates only from their preferred CA, which would stop peers from using certificates outside of the intended use case 👑
Another way to limit what a certificate can be used for is to provision it with an appropriate value for the Extended Key Purpose field [RFC7299] 🧚 For example, the id-kp-eapOverLAN [RFC4334] value could be used to show that this certificate is intended for use only with EAP 💜
It is hard to give more detailed recommendations than that 🥲 Each CA or organization may have its own local policy about what is permitted or forbidden in a certificate. All we can do in this document is highlight the issues and make sure the reader knows they have to be addressed 🔥
3.11.3. Server Unauthenticated Provisioning Mode
so in Server Unauthenticated Provisioning Mode, an unauthenticated tunnel gets set up in Phase 1, and then the peer and server negotiate an Inner Method (or methods) in Phase 2 🌊 This Inner Method MUST support mutual authentication, provide key derivation, and be resistant to attacks such as on-path and dictionary attacks 🛡️ In most cases this Inner Method will be an EAP authentication method. Example Inner Methods that meet these criteria include EAP-pwd [RFC5931] and EAP-EKE [RFC6124], but NOT EAP-FAST-MSCHAPv2 🙅♀️
This provisioning mode lets you bootstrap peers when the peer can't authenticate the server during Phase 1 ✨ That includes both cases where the negotiated cipher suite doesn't provide authentication, and cases where it does provide authentication but the peer can't validate the server's identity for some reason 🥺
When the Inner Method finishes successfully in Phase 2, the peer and server exchange a Crypto-Binding TLV to bind the Inner Method to the outer tunnel and make sure an on-path attack wasn't attempted 🔐
Support for Server Unauthenticated Provisioning Mode is optional 💖 The cipher suite TLS_DH_anon_WITH_AES_128_CBC_SHA is RECOMMENDED when using this mode, but other anonymous cipher suites MAY be supported as long as the TLS pre-master secret is generated from contributions from both peers 🍓
When a strong Inner Method is NOT used with Server Unauthenticated Provisioning Mode, an attacker can perform an on-path attack 😱 Basically, this mode has similar security issues to just running the Inner Method in the open without TLS protection 💀 All of the information in the tunnel should be assumed to be visible to, and modifiable by, an attacker 👀
Implementations SHOULD exchange minimal data in Server Unauthenticated Provisioning Mode 🤏 Instead, they should use that mode to set up a secure, authenticated tunnel and then use that tunnel to do any needed data exchange 🫶
It is RECOMMENDED that client implementations and deployments authenticate TEAP servers if at all possible 🙏 Authenticating the server means a client can be provisioned securely, with no chance of an attacker eavesdropping on the connection 🕵️♀️
Note that server unauthenticated provisioning can only use anonymous cipher suites in TLS 1.2 and earlier 🕰️ These cipher suites have been deprecated in TLS 1.3 ([RFC8446], Appendix C.5). For TLS 1.3, the server MUST provide a certificate, and the peer performs server unauthenticated provisioning by NOT validating the certificate chain or any of its contents 🙈
3.11.4. Channel Binding
[RFC6677] defines channel bindings for EAP that solve the "lying NAS" and the "lying provider" problems 🕸️ It does this with a process where the EAP peer tells the Authentication, Authorization, and Accounting (AAA) server, which is protected inside the EAP authentication method, about the characteristics of the service the authenticator provides 🎯 This lets the server verify that the authenticator is giving the peer info that matches what it received from that authenticator, as well as what's stored about that authenticator 🔍
TEAP supports EAP channel binding using the Channel-Binding TLV defined in Section 4.2.7 💫 If the TEAP server wants the channel-binding info from the peer, it sends an empty Channel-Binding TLV to ask for it 🙋♀️ The peer answers by sending a Channel-Binding TLV that contains a channel-binding message as defined in [RFC6677]. The server validates that message and sends back a Channel-Binding TLV with a result code ✅ If the server didn't start the channel-binding request but the peer still wants to send the channel-binding info, it can do that by using the Request-Action TLV along with the Channel-Binding TLV 📨 The peer MUST only send channel-binding information after it has successfully authenticated the server and established the protected tunnel 🔒
4. Message Formats ✨
okay the next part is where we get into the actual bits and bytes 🤓 The following sections describe the message formats used in TEAP. Fields are transmitted from left to right in network byte order 💜
4.1. TEAP Message Format
4.1. TEAP Message Format
A summary of the TEAP Request/Response packet format is shown below 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Ver | Message Length :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Message Length | Outer TLV Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Outer TLV Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code 🔢 The Code field is one octet in length and is defined as follows:
1 Request
2 ResponseIdentifier 🪪 The Identifier field is one octet and helps match responses with requests. The Identifier field MUST be changed on each Request packet. The Identifier field in the Response packet MUST match the Identifier field from the corresponding request.
Length 📏 The Length field is two octets and indicates the length of the EAP packet, including the Code, Identifier, Length, Type, Flags, Ver, Message Length, TLS Data, and Outer TLVs fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception 🫧
Type 🎫 55 for TEAP
Flags 🚩
0 1 2 3 4
+-+-+-+-+-+
|L M S O R|
+-+-+-+-+-+L Length included; set to indicate the presence of the four-octet Message Length field. It MUST be present for the first fragment of a fragmented message. It MUST NOT be present for any other message.
M More fragments; set on all but the last fragment 🧩
S TEAP start; set in a TEAP Start message sent from the server to the peer 🚀
O Outer TLV length included; set to indicate the presence of the four-octet Outer TLV Length field. It MUST be present only in the initial request and response messages. If the initial message is fragmented, then it MUST be present only on the first fragment.
R Reserved (MUST be zero and ignored upon receipt) 🤐
Ver 🔖 This field contains the version of the protocol. This document describes version 1 (001 in binary) of TEAP 💅
Message Length 📦 The Message Length field is four octets and is present only if the L bit is set. This field provides the total length of the message, which may be fragmented over the data fields of multiple packets.
Outer TLV Length 📐 The Outer TLV Length field is four octets and is present only if the O bit is set. This field provides the total length of the Outer TLVs, if present.
TLS Data 🔐 When the TLS Data field is present, it consists of an encapsulated TLS packet in TLS record format. A TEAP packet with Flags and Version fields, but with a zero-length TLS Data field, is used to indicate TEAP acknowledgment for either a fragmented message, a TLS Alert message, or a TLS Finished message 🙌
Outer TLVs 🧁 The Outer TLVs consist of the optional data used to help establish the TLS tunnel, in TLV format. They are only allowed in the first two messages in the TEAP. That is, the first EAP-server-to-peer message and the first peer-to-EAP-server message. The start of the Outer TLVs can be derived from the EAP Length field and the Outer TLV Length field 💖
4.2. TEAP TLV Format and Support 💅
okay so TLVs are basically little TLV objects 🎀 and they can carry arbitrary parameters between the EAP peer and the EAP server, all tucked inside the protected TLS tunnel 🔐✨
not every peer is going to support every TLV the server knows, which is very real life 🙈 so TLVs have a way for the server to check if the peer supports one, using the NAK TLV 🦋 the mandatory bit tells you whether support for that TLV is required. if the peer or server doesn't support a TLV marked mandatory, it MUST send a NAK TLV in the response, and all the other TLVs in that message MUST be ignored 😭 if an EAP peer or server finds an unsupported TLV marked as optional, it's allowed to just ignore it 🫶 it MUST only send a NAK TLV for a TLV that is marked mandatory but isn't understood, and it MUST NOT otherwise send a NAK TLV 🚫 if every TLV in a message is marked optional and none of them are understood by the peer, then a Result TLV SHOULD be sent to the other side so the conversation can keep going 💜 it's also possible to send a NAK TLV when all TLVs in a message are marked optional.
ngl this part is so clever ✨
one more thing 👀 a peer or server might support a TLV with the mandatory bit set but still not understand what's inside it. the right response to that is defined by the individual TLV spec itself 🌸
EAP implementations that follow this spec MUST support TLV exchanges, plus the processing of the mandatory and optional settings on each TLV 👑 they also MUST support these TLVs, no exceptions:
- Authority-ID TLV
- Identity-Type TLV
- Result TLV
- NAK TLV
- Error TLV
- Request-Action TLV
- EAP-Payload TLV
- Intermediate-Result TLV
- Crypto-Binding TLV
- Basic-Password-Auth-Req TLV
- Basic-Password-Auth-Resp TLV
4.2.1. General TLV Format 🧚
TLVs are laid out like this, and the fields are sent from left to right 🍓
if a peer or server gets a TLV that isn't the correct format, the TLV MUST be discarded 💀 it's super helpful to log an error or debug message saying which TLV had the problem and what went wrong 📝 malformed TLVs are invalid though, so they can't be used at all, periodt.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+M0: Optional TLV1: Mandatory TLV
R: Reserved, set to zero (0)TLV Type: A 14-bit field that denotes the TLV type. The allocated types are:
0 Unassigned
1 Authority-ID TLV (Section 4.2.2)
2 Identity-Type TLV (Section 4.2.3)
3 Result TLV (Section 4.2.4)
4 NAK TLV (Section 4.2.5)
5 Error TLV (Section 4.2.6)
6 Channel-Binding TLV (Section 4.2.7)
7 Vendor-Specific TLV (Section 4.2.8)
8 Request-Action TLV (Section 4.2.9)
9 EAP-Payload TLV (Section 4.2.10)
10 Intermediate-Result TLV (Section 4.2.11)
11 PAC TLV (DEPRECATED)
12 Crypto-Binding TLV (Section 4.2.13)
13 Basic-Password-Auth-Req TLV (Section 4.2.14)
14 Basic-Password-Auth-Resp TLV (Section 4.2.15)
15 PKCS#7 TLV (Section 4.2.16)
16 PKCS#10 TLV (Section 4.2.17)
17 Trusted-Server-Root TLV (Section 4.2.18)
18 CSR-Attributes TLV (Section 4.2.19)
19 Identity-Hint TLV (Section 4.2.20)Length: the length of the Value field, in octets.Value: the value of the TLV.
4.2.2. Authority-ID TLV 🪪
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+M:0- Optional TLVR: Reserved, set to zero (0)TLV Type:1- Authority-IDLength: two octets, containing the length of the ID field in octets.ID: a hint about the identity of the server, to help the peer match up the credentials it has for that server. It should be unique across the deployment. 🔑
4.2.3. Identity-Type TLV 🎭
the Identity-Type TLV lets an EAP server send a hint that helps the EAP peer pick the right type of identity, like user or machine 👤🖥️ TEAPv1 implementations MUST support this TLV. only one Identity-Type TLV SHOULD be present in a TEAP request or response packet.
a server that sends the Identity-Type TLV MUST also include an EAP-Payload TLV or a Basic-Password-Auth-Resp TLV. a peer that sends an Identity-Type TLV MUST also include an EAP-Payload TLV or a Basic-Password-Auth-Resp TLV too 🫶
when an EAP peer gets an Identity-Type request, it SHOULD respond with an Identity-Type TLV holding the requested type. if the Identity-Type field doesn't contain one of the known values, or if the EAP peer doesn't have an identity matching the requested type, then the peer SHOULD respond with an Identity-Type TLV using one of the identity types it does have available 🌈
when a server gets an Identity-Type in the response, it MUST check that the value matches the Identity-Type it sent in the request. if they match, the server can go ahead with authentication ✅
if the values don't match, though, the server can only go ahead with authentication if both of these conditions are true. if either one of them isn't true, the server MUST respond with a Result TLV of Failure 😭
- The Identity-Type contains a value permitted by the server configuration.
- The Identity-Type value was not previously used for a successful authentication.
the first condition lets a server be set up to allow only user authentication, or only machine authentication 🔧 a server could also use an Identity-Hint TLV sent in the response to allow different types of authentication for different identities 🎀 it could even allow or forbid different kinds of authentication based on other info, like the outer EAP Identity, fields in an outer EAP client certificate, or other fields received in a RADIUS or Diameter packet along with the TEAP session 👀 there's no requirement that a server has to support both user and machine authentication for every TEAP session, so relax bestie 💅
the second condition makes sure that if a particular Inner Method succeeds, the server doesn't try a later Inner Method for the same Identity-Type 🙅♀️ for example, if a user is authenticated with an Inner Method of EAP-TLS, there's no point in also asking for extra authentication with a different Inner Method. same goes for repeating an authentication session for the same user, because the result won't change 🔁
this second condition also forbids multiple rounds of challenge/response authentication through the Basic-Password-Auth-Req TLV. TEAPv1 supports only one round of Basic-Password-Auth-Req followed by Basic-Password-Auth-Resp, and the result of that round MUST NOT be another Basic-Password-Auth-Req TLV 🛑
finally, this second condition also means that a server MUST NOT send an Identity-Hint TLV with the same value that was previously used for a successful authentication 🙅♀️
the Identity-Type TLV looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identity-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+M: Mandatory, set to one (1)R: Reserved, set to zero (0)TLV Type:2- Identity-Type TLVLength:2Identity-Type: two octets. The values are:1: User2: Machine
4.2.4. Result TLV 🏆
the Result TLV gives you acknowledged success and failure messages for protected termination within TEAP, so everybody knows how it ended 🎉 if the Status field doesn't contain one of the known values, the peer or EAP server MUST treat it as a fatal error of Unexpected TLVs Exchanged 💀 how the Result TLV behaves is discussed further in Sections 3.6.6 and 3.9.3.
a Result TLV indicating failure MUST NOT be accompanied by any of these TLVs: NAK, EAP-Payload, or Crypto-Binding 🚫 and a Result TLV indicating success MUST be accompanied by a Crypto-Binding TLV 🔐
the Result TLV is defined like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+M: Mandatory, set to one (1)R: Reserved, set to zero (0)TLV Type:3- Result TLVLength:2Status: two octets. The values are:1: Success2: Failure
4.2.5. NAK TLV 🦋
okay bestie, the NAK TLV is how one peer says "wait, I don't speak that TLV" 🙈 It lets a peer detect TLVs the other peer doesn't support 💅. A TEAP packet can hold 0 or more NAK TLVs ✨. A NAK TLV should not be accompanied by other TLVs, ngl that's giving minimalism. A NAK TLV MUST NOT be sent in response to a message containing a Result TLV 🚫. Instead you send a Result TLV of failure to say "nope," plus an Error TLV of Unexpected TLVs Exchanged 💀. Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK-Type | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+M: Mandatory, set to one (1) 🌟R: Reserved, set to zero (0)TLV Type:4 - NAK TLVLength:>=6Vendor-Id: This is four octets and holds the Vendor-Id of the TLV that wasn't supported 🏢. The high-order octet is 0. The low-order three octets are the Structure of Management Information (SMI) Network Management Private Enterprise Number of the Vendor, in network byte order. The Vendor-Id field MUST be zero for TLVs that are not Vendor-Specific TLVs.NAK-Type: This is two octets and holds the type of the TLV that wasn't supported. A TLV of this type MUST have been included in the previous packet.TLVs: This holds a list of zero or more TLVs, and each of them MUST NOT have the mandatory bit set. These optional TLVs are there for future extensibility, so you can communicate why the offending TLV was judged unsupported 🔮.
4.2.6. Error TLV 🚨
the Error TLV lets an EAP peer or server tell the other party about errors 💌. A TEAP packet can contain 0 or more Error TLVs. The Error-Code field describes the type of error. Error codes 1-999 are successful outcomes (informative messages) ✨, 1000-1999 are warnings ⚠️, and 2000-2999 are fatal errors 💀. A fatal Error TLV MUST be accompanied by a Result TLV indicating failure, and the conversation is terminated as described in Section 3.9.3.
A lot of the error codes below are about Inner Method processing, which you can only see if the inner method makes it available 🫶. Implementations MUST take care that error messages do not reveal too much information to an attacker 🕵️. For example, using error message 1031 (User account credentials incorrect) is NOT RECOMMENDED, because it lets an attacker figure out valid usernames by comparing that response to the others 😭. It should only be used for troubleshooting purposes.
Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+M: Mandatory, set to one (1)R: Reserved, set to zero (0)TLV Type:5 - Error TLVLength:4Error-Code: This is four octets. The currently defined values are below 🍓
1 User account expires soon
2 User account credential expires soon
3 User account authorizations change soon
4 Clock skew detected
5 Contact administrator
6 User account credentials change required
1001 Inner Method Error
1002 Unspecified authentication infrastructure problem
1003 Unspecified authentication failure
1004 Unspecified authorization failure
1005 User account credentials unavailable
1006 User account expired
1007 User account locked: try again later
1008 User account locked: admin intervention required
1009 Authentication infrastructure unavailable
1010 Authentication infrastructure not trusted
1011 Clock skew too great
1012 Invalid inner realm
1013 Token out of sync: administrator intervention required
1014 Token out of sync: PIN change required
1015 Token revoked
1016 Tokens exhausted
1017 Challenge expired
1018 Challenge algorithm mismatch
1019 Client certificate not supplied
1020 Client certificate rejected
1021 Realm mismatch between inner and outer identity
1022 Unsupported Algorithm In Certificate Signing Request
1023 Unsupported Extension In Certificate Signing Request
1024 Bad Identity In Certificate Signing Request
1025 Bad Certificate Signing Request
1026 Internal CA Error
1027 General PKI Error
1028 Inner Method's channel-binding data required but not
supplied
1029 Inner Method's channel-binding data did not include required
information
1030 Inner Method's channel binding failed
1031 User account credentials incorrect [USAGE NOT RECOMMENDED]
1032 Inner Method not supported
2001 Tunnel Compromise Error
2002 Unexpected TLVs Exchanged
2003 The Crypto-Binding TLV is invalid (Version, Received-Ver, or
Sub-Type)
2004 The first Inner Method did not derive EMSK
2005 The Crypto-Binding TLV did not include a required MSK
Compound MAC
2006 The MSK Compound MAC fails verification
2007 The Crypto-Binding TLV did not include a required EMSK
Compound MAC
2008 The EMSK Compound MAC fails verification
2009 The EMSK Compound MAC exists, but the Inner Method did not
derive EMSK4.2.7. Channel-Binding TLV 🌈
the Channel-Binding TLV carries channel-binding data from the peer to the EAP server, and the server's channel-binding response back to the peer, as described in [RFC6677]. TEAPv1 implementations MAY support this TLV, and it can't be answered with a NAK TLV 🙅. If the Channel-Binding data field doesn't contain one of the known values, or the EAP server doesn't support this TLV, then the server MUST ignore the value.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+M:0 - Optional TLVR: Reserved, set to zero (0)TLV Type:6 - Channel-Binding TLVLength:variableData: This field contains a channel-binding message as defined in Section 5.3 of [RFC6677] 🔐
4.2.8. Vendor-Specific TLV 💜
the Vendor-Specific TLV is the vendor playground 🧚, a spot for extended attributes that aren't really for general usage. It can hold one or more TLVs, called Vendor TLVs. The TLV type of a particular Vendor TLV is defined by the vendor. All the Vendor TLVs inside a single Vendor-Specific TLV belong to the same vendor, but there can be multiple Vendor-Specific TLVs from different vendors in the same message 🌸. Error handling in a Vendor TLV could use the vendor's own error-handling mechanism, or use the standard TEAP error codes defined.
Vendor TLVs may be optional or mandatory. Vendor TLVs sent with Result TLVs MUST be marked as optional. If the Vendor-Specific TLV is marked as mandatory, then the receiving side is expected to recognize the vendor ID, parse all Vendor TLVs within, and deal with error handling within the Vendor-Specific TLV as defined by the vendor 🫡.
Where a Vendor-Specific TLV carries an authentication protocol in the Inner Method, it MUST define values for MSK and EMSK. Where these values cannot be derived from cryptographic primitives, they MUST be set to zero, as happens when Basic-Password-Auth-Req is used 🔥.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+M:0 or 1R: Reserved, set to zero (0)TLV Type:7 - Vendor-Specific TLVLength:4 + cumulative length of all included Vendor TLVsVendor-Id: This is four octets and holds the Vendor-Id of the TLV. The high-order octet is 0, and the low-order 3 octets are the SMI Network Management Private Enterprise Number of the Vendor, in network byte order.Vendor TLVs: This field is of indefinite length. It contains Vendor-Specific TLVs, in a format defined by the vendor 🍬
4.2.9. Request-Action TLV ✨
okay so the Request-Action TLV is lowkey the "hey, can we do this too?" TLV 💅 It MAY be sent at any time 🫶 and it lets the peer or server ask the other side to negotiate additional Inner Methods, or to process TLVs that are tucked inside of it 🎀
The receiving side MUST process this TLV, and here's how that goes 👑
- The receiving entity MAY choose to process any of the TLVs that are included in the message.
- If the receiving entity chooses NOT to process any TLV in the list, then it sends back a Result TLV with the same code in the Status field of the Request-Action TLV.
- If multiple Request-Action TLVs are in the request, the session can continue if any of the TLVs in any Request-Action TLV are processed. ✨
- If multiple Request-Action TLVs are in the request and none of them is processed, then the most fatal status should be used in the Result TLV returned. If a status code in the Request-Action TLV is not understood by the receiving entity, then it SHOULD be treated as a fatal error. Otherwise, the receiving entity MAY send a Request-Action TLV containing an Error TLV of value 2002 (Unexpected TLVs Exchanged). 😭
- After processing the TLVs or Inner Method in the request, another round of Result TLV exchange MUST occur to synchronize the final status on both sides. 🔥
The peer or the server MAY send multiple Request-Action TLVs to the other side. Two Request-Action TLVs MUST NOT occur in the same TEAP packet if they have the same Status value. The order of processing multiple Request-Action TLVs is implementation dependent 🌈 If the receiving side processes the optional (non-fatal) items first, it is possible that the fatal items will disappear at a later time. If the receiving side processes the fatal items first, the communication time will be shorter. ⭐
ngl this ordering stuff is the drama of the whole TLV world 💀
The peer or the server MAY return a new set of Request-Action TLVs after one or more of the requested items have been processed and the other side has signaled it wants to end the EAP conversation. 🦋
The Request-Action TLV is laid out like this 🍓
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Action | TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-M
- Mandatory, set to one (1)
R
- Reserved, set to zero (0)
TLV Type
- 8 - Request-Action TLV
Length
- 2 + cumulative length of all included TLVs
Status
- The Status field is one octet. This indicates the result if the party who receives this TLV does not process the action. Values include:
- 1 Success
- 2 Failure
Action
- The Action field is one octet. Values include:
- 1 Process-TLV
- 2 Negotiate-EAP
TLVs
- This field is of indefinite length. It contains TLVs that the peer wants the server to process.
4.2.10. EAP-Payload TLV 🧚
so to let an EAP request or response hitch a ride with other TLVs, we get the EAP-Payload TLV 🚀 It carries an encapsulated EAP packet and a list of optional TLVs. Those optional TLVs are there for future extensibility, to give hints about the current EAP authentication. Only one EAP-Payload TLV is allowed in a message. Here's the layout 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP packet...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+M
- Mandatory, set to one (1)
R
- Reserved, set to zero (0)
TLV Type
- 9 - EAP-Payload TLV
Length
- length of embedded EAP packet + cumulative length of additional TLVs
EAP packet
- This field contains a complete EAP packet, including the EAP header (Code, Identifier, Length, Type) fields. The length of this field is determined by the Length field of the encapsulated EAP packet.
TLVs
- This (optional) field contains a list of TLVs associated with the EAP packet field. The TLVs MUST NOT have the mandatory bit set. The total length of this field is equal to the Length field of the EAP-Payload TLV, minus the Length field in the EAP header of the EAP packet field.
4.2.11. Intermediate-Result TLV 🎀
the Intermediate-Result TLV is how we flag intermediate Success and Failure messages for all inner methods 💅 It MUST be used for all Inner Methods, no exceptions bestie 😤
An Intermediate-Result TLV indicating success MUST be accompanied by a Crypto-Binding TLV. 🔐
An Intermediate-Result TLV indicating failure SHOULD be accompanied by an Error TLV that indicates why the authentication failed. 🙈
Same deal as before: the optional TLVs here are for future extensibility, to give hints about the current result ✨ Layout time 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+M
- Mandatory, set to one (1)
R
- Reserved, set to zero (0)
TLV Type
- 10 - Intermediate-Result TLV
Length
- 2 + cumulative length of the embedded associated TLVs
Status
- The Status field is two octets. Values include:
- 1 Success
- 2 Failure
TLVs
- This field is of indeterminate length and contains zero or more of the TLVs associated with the Intermediate Result TLV. The TLVs in this field MUST NOT have the mandatory bit set.
4.2.12. PAC TLV 🌸
okay this one is a bit of a sad story 🥺 [RFC7170] defined a Protected Access Credential (PAC) to mirror EAP-FAST [RFC4851]. But implementation experience and analysis found that the PAC wasn't actually necessary 💀 So instead, TEAP does session resumption using the NewSessionTicket message, as defined in Sections 2.1.2 and 2.1.3 of [RFC9190]. As such, the PAC TLV has been deprecated 🫶
since the PAC TLV is deprecated, an entity that receives it SHOULD send a Result TLV indicating failure and an Error TLV of Unexpected TLVs Exchanged 🙅♀️
4.2.13. Crypto-Binding TLV ✨
Okay bestie, this one is giving "proof of teamwork" 🤝 The Crypto-Binding TLV is how the peer and the server prove to each other that they both showed up for the tunnel setup and the whole sequence of authentications 💖 It also double-checks the TEAP type, the version that got negotiated, and the Outer TLVs that got exchanged before the TLS tunnel was set up. Iconic 👑
A Crypto-Binding MUST be accompanied by an Intermediate-Result TLV indicating success. 🎀
The Crypto-Binding TLV MUST be exchanged and validated before any Intermediate-Result or Result TLV value is examined, regardless of whether there is an Inner Method or not. It MUST be included with the Intermediate-Result TLV to perform cryptographic binding after each successful Inner Method in a sequence of inner methods, before proceeding with another Inner Method. If no MSK or EMSK has been generated and a Crypto-Binding TLV is required, then the MSK Compound MAC field contains the MAC using keys generated according to Section 6.3. 🔐
The Crypto-Binding TLV is valid only if the following checks pass on its contents:
- The Version field contain a known value. 🌸
- The Received-Ver field matches the TEAP version sent by the receiver during the EAP version negotiation. 🦋
- The Sub-Type field is set to the correct value for this exchange. ✨
- The Flags field is set to a known value. 💅
- The Compound MAC(s) verify correctly. 🫶
If any of the above checks fails, then the TLV is invalid. An invalid Crypto-Binding TLV is a fatal error and is handled as described in Section 3.9.3.
💀 Fatal error, bestie. Not a "maybe later" situation. If the Crypto-Binding TLV fails any check, it's invalid and the whole thing gets handled as a fatal error.
See Section 6 for a more detailed discussion of how the Compound MAC fields are constructed and verified. 🧚
The Crypto-Binding TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Version | Received-Ver.| Flags|Sub-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ EMSK Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MSK Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+M 🌟 Mandatory, set to one (1)
R 🌟 Reserved, set to zero (0)
TLV Type 🌟 12 - Crypto-Binding TLV
Length 🌟 76
Reserved 🌟 Reserved, set to zero (0)
Version 🌟 The Version field is a single octet, which is set to the version of Crypto-Binding TLV the TEAP method is using. For an implementation compliant with TEAPv1, the version number MUST be set to one (1). 💖
Received-Ver 🌟 The Received-Ver field is a single octet and MUST be set to the TEAP version number received during version negotiation. Note that this field only protects against downgrade attacks, where a version of EAP requiring support for this TLV is required on both sides. 🛡️
For TEAPv1, this version number MUST be set to one (1).
Flags 🌟 The Flags field is four bits. Defined values include:
1: EMSK Compound MAC is present2: MSK Compound MAC is present3: Both EMSK and MSK Compound MAC are present
All other values of the Flags field are invalid. 🙅♀️
Sub-Type 🌟 The Sub-Type field is four bits. Defined values include:
0: Binding Request1: Binding Response
All other values of the Sub-Type field are invalid. 🙅♀️
Nonce 🌟 The Nonce field is 32 octets. It contains a 256-bit nonce that is temporally unique, used for Compound MAC key derivation at each end. The nonce in a request MUST have its least significant bit set to zero (0), and the nonce in a response MUST have the same value as the request nonce except the least significant bit MUST be set to one (1). 🎲
EMSK Compound MAC 🌟 The EMSK Compound MAC field is 20 octets. This can be the Server MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the MAC is described in Section 6.3.
Note that this field is always 20 octets in length. Any larger MAC is simply truncated. All validations or comparisons MUST be done on the truncated value. ✂️
MSK Compound MAC 🌟 The MSK Compound MAC field is 20 octets. This can be the Server MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the MAC is described in Section 6.3.
Note that this field is always 20 octets in length. Any larger MAC is simply truncated. All validations or comparisons MUST be done on the truncated value. ✂️
4.2.14. Basic-Password-Auth-Req TLV 🔑
The Basic-Password-Auth-Req TLV is the authentication server asking the peer for a username and password, lowkey like "hey, who are you?" 🙋♀️ It can carry an optional user prompt message for the request. The peer is expected to grab the username and password and send them back in a Basic-Password-Auth-Resp TLV. 💌
The Basic-Password-Auth-Req TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prompt ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+M 🌟 Mandatory, set to one (1)
R 🌟 Reserved, set to zero (0)
TLV Type 🌟 13 - Basic-Password-Auth-Req TLV
Length 🌟 variable
Prompt 🌟 optional user prompt message in UTF-8 [RFC3629] format 💬
4.2.15. Basic-Password-Auth-Resp TLV 🧁
The Basic-Password-Auth-Resp TLV is the peer's reply to a Basic-Password-Auth-Req TLV, serving up a username and password. This TLV holds both, and they're both in UTF-8 [RFC3629] format. 🥰
The Basic-Password-Auth-Resp TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Userlen | Username
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Username ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Passlen | Password
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Password ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+M 🌟 Mandatory, set to one (1)
R 🌟 Reserved, set to zero (0)
TLV Type 🌟 14 - Basic-Password-Auth-Resp TLV
Length 🌟 variable
Userlen 🌟 Length of Username field in octets.
The value of Userlen MUST NOT be zero. 🚫
Username 🌟 Username in UTF-8 [RFC3629] format.
The content of Username SHOULD follow the guidelines set in [RFC9427], Section 3.1. 📋
Passlen 🌟 Length of Password field in octets.
The value of Passlen MUST NOT be zero. 🚫
Password 🌟 Password in UTF-8 [RFC3629] format.
Note that there is no requirement that passwords be humanly readable. Octets in a passwords may have values less than 0x20, including 0x00. 🤫
4.2.16. PKCS#7 TLV 📜
The PKCS#7 TLV is how the EAP server delivers certificate(s) to the peer. The format is a certificate or certificate chain in binary DER encoding [X.690], wrapped in a degenerate Certificates Only PKCS#7 SignedData Content as defined in [RFC5652]. Very organised, very cute 🎀
When the PKCS#7 TLV is used in response to a Trusted-Server-Root TLV request from the peer, the EAP server MUST send the PKCS#7 TLV inside a Trusted-Server-Root TLV. When it's used in response to a PKCS#10 certificate enrollment request from the peer, the EAP server MUST send the PKCS#7 TLV without a Trusted-Server-Root TLV. The PKCS#7 TLV is always marked as optional, which cannot be responded to with a NAK TLV. TEAP implementations that support the Trusted-Server-Root TLV or the PKCS#10 TLV MUST support this TLV. Peers MUST NOT assume that the certificates in a PKCS#7 TLV are in any order. 🧐
TEAP servers MAY return self-signed certificates. Peers that handle self-signed certificates or trust anchors MUST NOT implicitly trust these certificates merely due to their presence in the certificate bag.
🚨 Note: Peers are advised to take great care in deciding whether to use a received certificate as a trust anchor. The authenticated nature of the tunnel in which a PKCS#7 bag is received can provide a level of authenticity to the certificates contained therein. Peers are advised to take into account the implied authority of the EAP server and to constrain the trust it can achieve through the trust anchor received in a PKCS#7 TLV. 🛑
The PKCS#7 TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS#7 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-M 🌟 0 - Optional TLV
R 🌟 Reserved, set to zero (0)
TLV Type 🌟 15 - PKCS#7 TLV
Length 🌟 The length of the PKCS#7 Data field.
PKCS#7 Data 🌟 This field contains the DER-encoded X.509 certificate or certificate chain in a Certificates-Only PKCS#7 SignedData message. 💜
4.2.17. PKCS#10 TLV 🦄
The PKCS#10 TLV is how the peer kicks off the "Simple PKI" Request/Response from [RFC5272]. The format of the request is as specified in Section 6.4 of [RFC4945]. Like the PKCS#7 TLV, it's always marked as optional, which cannot be responded to with a NAK TLV. 🌈
The PKCS#10 TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS#10 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-M 🌟 0 - Optional TLV
R 🌟 Reserved, set to zero (0)
TLV Type 🌟 16 - PKCS#10 TLV
Length 🌟 The length of the PKCS#10 Data field.
PKCS#10 Data 🌟 This field contains the DER-encoded PKCS#10 certificate request. 🎀
4.2.18. Trusted-Server-Root TLV 🌸
Okay so the Trusted-Server-Root TLV is how a peer asks for a trusted server root certificate, and how it gets one back 🫶. It can show up in regular TEAP authentication mode or in provisioning mode ✨. It's always optional, so it can't be answered with a NAK TLV, no cap. It MUST only be sent as an Inner TLV, which means it has to live inside the protection of the tunnel 🔒.
Once the peer has figured out that it successfully authenticated the EAP server and validated the Crypto-Binding TLV, it MAY send one or more Trusted-Server-Root TLVs (marked as optional) to request the trusted server root certificates from the EAP server 💜. The EAP server MAY send one or more root certificates in a Public Key Cryptographic System #7 (PKCS#7) TLV inside the Trusted-Server-Root TLV. It MAY also choose not to honor the request, and that's giving "not me…" energy 💅.
The Trusted-Server-Root TLV lets the peer ask the EAP server for a list of trusted roots. The server may reply with one or more root certificates in PKCS#7 [RFC2315] format 🦋.
If the EAP server sets the credential format to PKCS#7-Server-Certificate-Root, then the Trusted-Server-Root TLV should contain the root of the certificate chain for the certificate issued to the EAP server, packaged in a PKCS#7 TLV. If the server certificate is self-signed, then the root is that self-signed certificate 🌈.
If the Trusted-Server-Root TLV credential format has a value the peer doesn't know, the EAP peer should ignore the TLV 🙈.
The Trusted-Server-Root TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credential-Format | Cred TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- M
- 0 - Optional TLV
- R
- Reserved, set to zero (0)
- TLV Type
- 17 - Trusted-Server-Root TLV
- Length
- >=2 octets
- Credential-Format
- The Credential-Format field is two octets. Values include:
- 1 - PKCS#7-Server-Certificate-Root
- Cred TLVs
- This field is of indefinite length. It contains TLVs associated with the credential format. The peer may leave this field empty when using this TLV to request server trust roots.
4.2.19. CSR-Attributes TLV 📝
The CSR-Attributes TLV is how the server tells the peer what to put in its certificate signing requests 🎀. The whole purpose of CSR attributes is described in Section 4.5 of [RFC7030], so go check that out if you're curious 🧐. Servers MAY send the CSR-Attributes TLV right after the TLS session is established. A server MAY also send, in that same message, a Request-Action frame for a PKCS#10 TLV. That's basically the server saying "hey, I'd love for you to renew your certificate using the parameters in this TLV" 🥰.
Servers shall construct the contents of the CSR-Attributes TLV as specified in [RFC7030], Section 4.5.2, with one exception: the DER encoding MUST NOT be encoded in base64. [RFC7030] uses base64 because its transport needs textual encoding. TEAP attributes can carry arbitrary binary data, so no base64 needed here, periodt ✨.
Servers and peers MUST follow the guidance in [RFC9908] when creating the CSR-Attributes TLV 📚. Peers MAY ignore the contents of the TLV if they're unable to handle it, but then servers may not process PKCS#10 certificate requests, for this or any other reason 😬.
The CSR-Attributes TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DER Encoded CSR Attributes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- M
- 0 - Optional TLV
- R
- Reserved, set to zero (0)
- TLV Type
- 18 - CSR-Attributes
- Length
- >=2 octets
4.2.20. Identity-Hint TLV 🧚
The Identity-Hint TLV is an optional TLV the peer can send to the server at the very start of the Phase 2 TEAP conversation 💖. Its whole job is to give a "hint" about which identity or identities the peer will use in the Inner Methods that follow.
Here's why it matters. To authenticate, the server has to pick an Inner Method, but it has no clue which methods the peer supports 🤷♀️. Without a hint, the server has to propose a method, wait for the peer to say "nope, not available," and then try again. That back-and-forth adds round trips to TEAP for no good reason 😭. With an Identity-Hint, the peer can say which identities it has, and the server can pick an Inner Method that fits that identity. Bestie, that's the bootstrapping problem solved ✨.
The peer SHOULD send an Identity-Hint TLV for each Identity-Type it has available 🌸. For example, if the peer can do both machine and user authentication, it can send two Identity-Hint TLVs, with the values host/name.example.com (for a machine with the hostname name.example.com) and user@example.com (for a person with the identity user@example.com).
The contents of the Identity-Hint TLV SHOULD be in NAI format [RFC7542]. But as the example above shows, machine identities might not follow that format 🤖. These identities are never used for AAA routing, as discussed in [RFC7542], Section 3, so their format and definition are entirely site local 🏠. Robust implementations MUST support arbitrary data in the content of this TLV, including binary octets 💪.
Since the Identity-Hint TLV is a "hint," server implementations are free to ignore the hints and do whatever their site-local policies require 🫠.
The Identity-Hint TLV is only a guide for picking which Inner Methods to use. It has no other meaning, and it MUST NOT be used for any other purpose 🚫. Specifically, server implementations MUST NOT compare the identities given in this TLV to the identities that come later in the Inner Methods. It's totally fine if the hints don't match whatever identity ends up being used 🙌.
The Identity-Hint TLV MUST NOT be used for server unauthenticated provisioning. This TLV is only a hint for normal authentication 🔐.
The Identity-Hint TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identity Hint |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- M
- 0 - Optional TLV
- R
- Reserved, set to zero (0)
- TLV Type
- 19 - Identity-Hint
- Length
- >=2 octets
4.3. TLV Rules 📜
To save round trips, multiple TLVs can be sent in one TEAP packet 🚀. But multiple EAP Payload TLVs, multiple Basic Password Authentication TLVs, or an EAP Payload TLV together with a Basic Password Authentication TLV in one single TEAP packet is not supported in this version, and it MUST NOT be sent 🙅♀️. If the peer or EAP server receives multiple EAP Payload TLVs, it MUST terminate the connection with the Result TLV 🛑. The order the TLVs are encoded in a TEAP packet doesn't matter. There is, however, an order in which the TLVs in a packet must be processed 👑:
- Crypto-Binding TLV
- Intermediate-Result TLV
- Result TLV or Request-Action TLV
- Identity-Type TLV
- EAP-Payload TLV (Identity-Request) or Basic-Password-Auth-Req TLV
- Other TLVs
That's the logic: cryptographic binding gets checked before any result is used, and identities get checked before an Inner Method is proposed, since the identity may influence which Inner Method gets chosen 🧠.
The following define the meaning of the table entries in the sections below 💅:
0This TLV MUST NOT be present in the message.0+Zero or more instances of this TLV MAY be present in the message.0-1Zero or one instance of this TLV MAY be present in the message.1Exactly one instance of this TLV MUST be present in the message.
4.3.1. Outer TLVs 🎀
The table below is a guide to which TLVs may be included in the TEAP packet outside the TLS channel, which kinds of packets they can ride in, and how many of each are allowed 🦋:
+=========+==========+=========+=========+=================+
| Request | Response | Success | Failure | TLVs |
+=========+==========+=========+=========+=================+
| 0-1 | 0 | 0 | 0 | Authority-ID |
+---------+----------+---------+---------+-----------------+
| 0-1 | 0-1 | 0 | 0 | Identity-Type |
+---------+----------+---------+---------+-----------------+
| 0+ | 0+ | 0 | 0 | Vendor-Specific |
+---------+----------+---------+---------+-----------------+
Table 1Outer TLVs MUST be marked as optional. Vendor TLVs inside a Vendor-Specific TLV MUST be marked as optional when they're included in Outer TLVs 🔖. Outer TLVs MUST NOT be included in messages after the first two TEAP messages, which are the first message from the EAP server to the peer and the first message from the peer to the EAP server 🚫. If a message is fragmented, the whole set of messages counts as one message 🧩. If Outer TLVs show up in messages after those first two TEAP messages, they MUST be ignored 🙈.
4.3.2. Inner TLVs ✨
Okay bestie, this table is the ultimate cheat sheet 🎀 for which Inner TLVs can be wrapped up in TLS during TEAP Phase 2, which kind of message they can ride in 🦋, and how many of each you're allowed to send 💅. Quick decoder: Request is a TEAP Request, Response is a TEAP Response, Success is a message with a successful Result TLV ✅, and Failure is a message with a failed Result TLV 💀.
+=======+==========+=========+=========+==========================+
|Request| Response | Success | Failure | TLVs |
+=======+==========+=========+=========+==========================+
|0-1 | 0-1 | 0 | 0 | Identity-Type |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0-1 | 1 | 1 | Result |
+-------+----------+---------+---------+--------------------------+
|0+ | 0+ | 0 | 0 | NAK |
+-------+----------+---------+---------+--------------------------+
|0+ | 0+ | 0+ | 0+ | Error |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0-1 | 0 | 0 | Channel-Binding |
+-------+----------+---------+---------+--------------------------+
|0+ | 0+ | 0+ | 0+ | Vendor-Specific |
+-------+----------+---------+---------+--------------------------+
|0+ | 0+ | 0+ | 0+ | Request-Action |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0-1 | 0 | 0 | EAP-Payload |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0-1 | 0-1 | 0-1 | Intermediate-Result |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0-1 | 0-1 | 0-1 | Crypto-Binding |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0 | 0 | 0 | Basic-Password-Auth-Req |
+-------+----------+---------+---------+--------------------------+
|0 | 0-1 | 0 | 0 | Basic-Password-Auth-Resp |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0 | 0-1 | 0 | PKCS#7 |
+-------+----------+---------+---------+--------------------------+
|0 | 0-1 | 0 | 0 | PKCS#10 |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0-1 | 0-1 | 0 | Trusted-Server-Root |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0 | 0 | 0 | CSR-Attributes TLV |
+-------+----------+---------+---------+--------------------------+
|0 | 0+ | 0 | 0 | Identity-Hint TLV |
+-------+----------+---------+---------+--------------------------+
Table 2NOTE 🚨: Vendor TLVs (the ones included in Vendor-Specific TLVs) that get sent with a Result TLV MUST be marked as optional. Also, the CSR-Attributes TLV is never transmitted by the peer, so this table treats it as a request. 🙈
5. Limitations of TEAPv1 🥺
Remember from Section 1.1 that TEAPv1 implementations are kinda limited in what they can do, compared to what the protocol could theoretically handle 😭. Because of that, only a small number of inner methods are fully supported by the existing TEAPv1 implementations.
Section 6 defines the cryptographic calculations for key derivation and crypto-binding. This section is different 💜: it documents which Inner Methods are known to work and why they work. Other Inner Methods might work too, but those results are likely to be implementation-specific.
We're going to talk about these issues without naming any particular implementations or making any negative assumptions about them 🫶. The implementations work well enough together in limited situations. Any interoperability problems come from the complexity and incompleteness of the definitions in [RFC7170], not from any one implementation.
The interoperability issues are limited to the use and derivation of the Compound MAC(s), which are derived from the inner MSK and EMSK. The short version: implementations are known to derive different Compound MAC(s) values when more than one Inner Method provides an EMSK. 💀
5.1. Interoperable Inner Methods
These Inner Methods are known to work, and they work for both User and Machine credentials ✨:
EAP-MSCHAPv2EAP-TLS
These combinations of Inner Methods are known to work, and they work for any order of User and Machine credentials 🌸:
EAP-MSCHAPv2followed byEAP-MSCHAPv2EAP-TLSfollowed byEAP-MSCHAPv2
These combinations are known to work when both the supplicant and the authenticator ignore the EMSK Compound MAC field of the Crypto-Binding TLV. They work for any order of User and Machine credentials 🦋:
EAP-MSCHAPv2followed byEAP-TLSEAP-TLSfollowed byEAP-TLS
5.2. Explanation and Background
The main reason the set of Inner Methods is so limited is that the most well-known TEAP supplicant only supports EAP-MSCHAPv2 and EAP-TLS as Inner Methods 🙃. On top of that, this implementation doesn't encode the EMSK Compound MAC field in all of the Crypto-Binding TLVs it sends, and it ignores that field in all of the Crypto-Binding TLVs it receives.
The known authenticator implementations support this client, but any other combination of Inner Methods was never tested 👀. So each authenticator ended up implementing a totally different derivation of the EMSK Compound MAC field of the Crypto-Binding TLV. That happened because the cryptographic derivations are super complicated and there wasn't much interoperability testing. The difference only got discovered after multiple implementations had been shipping for years 😭🔥.
5.3. Next Steps
Any attempt to change TEAPv1 to fix these issues would likely leave one or more implementations non-compliant with the updated specification 💀. Even worse, updates to this specification would result in multiple incompatible versions of TEAPv1.
That approach is not acceptable 🙅♀️.
To keep the known interoperability, this specification simply documents these issues instead of trying to correct them 🩹. Since TEAP and the Crypto-Binding TLV both contain a Version field, the better path forward is to publish this specification while clearly documenting the big caveats for TEAPv1. Any changes can then happen in a future TEAPv2 specification 🧚.
6. Cryptographic Calculations 🔐
The definitions in this section are known to work with all implementations, but only for a few Inner Methods, as described above in Section 5. To avoid adding even more complexity to an already complex process, these definitions are written as if they work for all possible Inner Methods 🤓.
Some interoperable implementations have been written from these definitions, and they support Inner Methods other than EAP-MSCHAPv2 and EAP-TLS 🌈. So it's useful to document the full operation of TEAPv1 despite the known issues. The only warning is that Inner Methods not listed above in Section 5 are likely to work with only a subset of existing TEAPv1 implementations ⚠️.
For key derivation and crypto-binding, TEAP uses the Pseudorandom Function (PRF) and MAC algorithms that were negotiated in the underlying TLS session. Those algorithms depend on the TLS version and cipher suite, so TEAP implementations need a mechanism to figure out the version and cipher suite in use for a particular session. The implementation can then use that information to pick the right PRF and MAC algorithm 💅.
6.1. TEAP Authentication Phase 1: Key Derivations
With TEAPv1, the TLS master secret is generated as specified in TLS. If session resumption is used, the master secret is obtained as described in [RFC5077] 🎀.
TEAPv1 uses the TLS Keying Material Exporters defined in [RFC5705] to derive the session_key_seed, like this 🔑:
session_key_seed = TLS-Exporter(
"EXPORTER: teap session key seed",, 40)No context data is used in the export process 🙅♀️.
The session_key_seed is used by the TEAP authentication Phase 2 conversation for two jobs: cryptographically binding the Inner Method(s) to the tunnel, and generating the resulting TEAP session keys 💖. The other TLS keying materials are derived and used as defined in [RFC8446].
6.2. Intermediate Compound Key Derivations
TEAP can run multiple Inner Methods, so there needs to be a way to cryptographically bind each Inner Method to the TLS tunnel, and also to bind each method to the previous one 🔗. This binding is done by deriving a bunch of intermediate keys and exchanging that info in the Crypto-Binding TLV.
The key derivation is complicated by a number of factors 😵💫. An inner method can derive an MSK, or (as with basic passwords) not derive an MSK at all. An Inner Method can derive an EMSK or maybe not derive one, and some EAP types may derive different EMSKs for the peer and the server. All of these cases must be accounted for, and recommendations have to be made for how peers and servers can interoperate.
There are a number of intermediate keys used to calculate the final MSK and EMSK for TEAP. Here's a brief overview to help you make sense of the detailed definitions below 📝. Since each Inner Method can derive an MSK (or not) and an EMSK (or not), there need to be separate intermediate key calculations for the MSK and for the EMSK. For this overview, we just describe the derivations at a high level, and the MSK/EMSK issue gets handled in the more detailed text below 🧠.
For each Inner Method, we derive an IMSK. This key depends on the inner key (MSK or EMSK) ✨. The IMSK is then tied to the TLS session via the TLS-PRF to derive an Inner Method Compound Key (IMCK). The IMCK is used to generate a Compound MAC key (CMK). The CMK is mixed with various data from the TEAP negotiation to create the Compound MAC field of the Crypto-Binding attribute. This TLV cryptographically binds the Inner Method to the protected tunnel and to the other fields that were negotiated 🫶. That cryptographic binding prevents on-path attacks 🛡️.
The IMCK for this Inner Method is then mixed with keys from previous Inner Methods, starting with the TEAP Phase 2 session_key_seed derived above, to yield a Secure IMCK (S-IMCK) for this round 🌀. The S-IMCK from the final round is then used to derive the MSK and EMSK for TEAP 👑.
We tell the Inner Methods apart by counting them starting from 0, and we use an index "j" to refer to an arbitrary inner method. For example, IMCK[0] is the IMCK for the first, or "0", Inner Method 🦋. While TEAPv1 is currently limited to one or two Inner Methods (j=0 or j=0,1), further updates could allow for more Inner Method exchanges 🌸.
6.2.1. Generating the Inner Method Session Key 🔑✨
okay bestie, so every Inner Method makes its own IMSK, and it depends on the EMSK (the preferred one) or the MSK if that exists. If neither exists, it's just all zeros 🙈 We call the IMSK for Inner Method "j" IMSK[j], obviously 💅
If an Inner Method can export an EMSK, then the IMSK SHOULD be derived from the EMSK, which is defined in [RFC5295]. The optional data parameter is not used in the derivation 🎀
BUT here's the tea 🫖 this part is not a requirement. Some peer implementations of TEAP are known to skip the EMSK and only derive IMSK from the MSK. To stay compatible with them, using EMSK here is not made mandatory. Periodt 💖
Some EAP methods let the peer and server derive different EMSKs 😭 If we made EMSK-based derivation mandatory there, interop would break, because the Crypto-Binding TLV contents that depend on EMSK couldn't be validated by either side. So those methods SHOULD NOT derive IMSK from EMSK unless the method has a way to negotiate how the EMSK is derived, along with a way to signal that both the peer and server derived the same EMSK 🧚
It is RECOMMENDED that for those EAP methods, implementations take the simpler route: ignore EMSK and always derive IMSK from MSK. Real talk, this is less secure, because IMSK no longer cryptographically binds the Inner Method to the TLS tunnel 💀 A better move is to suggest that deployments of TEAP SHOULD avoid such methods 🙅♀️
The derivation of IMSK[j] from the j'th EMSK goes like this:
IMSK[j] = First 32 octets of TLS-PRF(
EMSK[j],
"TEAPbindkey@ietf.org",
0x00 | 0x00 | 0x40)Where:
- "|" denotes concatenation 🔗
- The TLS-PRF is defined in [RFC5246] as:
PRF(secret, label, seed) = P_<hash>(secret, label | seed)- The secret is the EMSK from the j'th Inner Method. The usage label is "TEAPbindkey@ietf.org", which is the ASCII value for that label (without quotes). The seed is made of the
"\0"null delimiter (0x00) and a 2-octet unsigned integer length of 64 octets in network byte order (0x00 | 0x40), as specified in [RFC5295] 🌸
If an Inner Method doesn't export EMSK but does export MSK, then IMSK is copied from that Inner Method's MSK. If the MSK is longer than 32 octets, IMSK is copied from the first 32 octets and the rest of the MSK gets ignored. If the MSK is shorter than 32 octets, then the ISMK is copied from MSK and the remaining data in IMSK is padded with zeros to a length of 32 octets. IMSK[j] is then this derived value ✨
If the Inner Method doesn't provide either an MSK or an EMSK (like with basic password authentication, or when no Inner Method has run at all), then both MSK and IMSK[j] are set to all zeroes. In other words, IMSK[j] = MSK = 32 octets of 0x00s 🥹
Heads up: using an all-zero MSK opens TEAP up to on-path attacks, which is discussed in Section 8.3. So it is NOT RECOMMENDED to use Inner Methods that fail to generate an MSK or EMSK. Those methods should only be used alongside another Inner Method that does generate an MSK or EMSK 🚨
It is also RECOMMENDED that TEAP peers order their Inner Methods so that methods that generate EMSKs run before methods that don't. This ordering means the first Inner Method catches any on-path attackers, and any Inner Method after it is secure 🔥
For example, Phase 2 could do machine authentication with EAP-TLS first, then user authentication through the Basic Password Authentication TLVs. In that setup, EAP-TLS lets us catch an attacker before the user's password gets sent 😱
However, the peer and server sides might not have the same ability to export EMSK. To keep things maximally flexible while preventing downgrading attacks, the following mechanism is in place 🛡️
6.2.2. Generating S-IMCK 🧁
Once IMSK[j] is determined, it gets mixed via the TLS-PRF with the key S-IMCK[j-1] from a previous round. That mix derives a new key, IMCK[j]. This key is then used to derive both S-IMCK[j] for this round and CMK[j] for this round 💜
The derivation of S-IMCK works like this:
S-IMCK[0] = session_key_seed
For j = 1 to n-1 do
IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1],
"Inner Methods Compound Keys",
IMSK[j])
S-IMCK[j] = first 40 octets of IMCK[j]
CMK[j] = last 20 octets of IMCK[j]Here TLS-PRF is the PRF (described above) negotiated as part of the TLS handshake [RFC5246]. The value j refers to a matching Inner Method, from 1 through n. The special S-IMCK[0] value bootstraps the calculations, and it can be done as soon as the TLS connection is established, before any inner methods run 🚀
Okay, here's where it gets spicy 🌶️ Because we need either the MSK or the EMSK, an implementation MUST track two independent derivations of IMCK[j]: one that depends on the MSK and another that depends on the EMSK. So we end up with these values derived from the MSK:
IMSK_MSK[j]S-IMCK_MSK[j]CMK_MSK[j]
and these values derived from the EMSK:
IMSK_EMSK[j]S-IMCK_EMSK[j]CMK_EMSK[j]
When a Crypto-Binding TLV exchange finishes successfully, one S-IMCK[j] gets picked based on which Compound MAC value the client included in its Crypto-Binding TLV. If the EMSK Compound MAC was included, S-IMCK[j] is taken from S-IMCK_EMSK[j]. Otherwise, it's taken from S-IMCK_MSK[j] 🎯
6.2.3. Choosing Inner Methods Securely 🧠
To lock TEAP down even more, implementations can get smart about ordering their Inner Methods. When multiple Inner Methods are used, implementations SHOULD choose an ordering where the first Inner Method used is one that derives EMSK 👑
For an EAP server, it can pick an EMSK-deriving method to go first. Since ordering isn't otherwise important in EAP, any chosen order is supported by the peer that receives the request 💅
For an EAP peer, it can choose how to respond to the server's request for a particular type of authentication. The peer can ignore that request and return an Inner Method that derives EMSK. Again, ordering doesn't otherwise matter in EAP, so any chosen order is supported by the server that gets the response. Once the more secure authentication has succeeded, the server requests the other type of authentication, and the peer can respond with the type it chose 🦋
Implementations can also offer configuration flags, policies, or documented recommendations that control which types of Inner Methods get used, or that verify their order. These let implementations and admins control how exposed they are to on-path attackers 🕵️♀️
Implementations can let administrators configure TEAP so that these security checks are enforced:
- Verifying that the first Inner Method used is one that derives EMSK. If this isn't done, a fatal error can be returned 🙅
- Verifying that if any Inner Method derives EMSK, the received Crypto-Binding TLV for that method contains an EMSK Compound MAC. If an EMSK has been derived but no EMSK Compound MAC shows up, a fatal error can be returned 💀
The goal of these suggestions is to enforce use of the EMSK Compound MAC to protect the TEAP session from on-path attackers. If these suggestions aren't enforced, the TEAP session is vulnerable 🚨
Most of these suggestions are not normative, because some existing implementations are known not to follow them. Instead, they're here to inform new implementers and administrators about the issues around this topic 🫶
6.2.4. Managing and Computing Crypto-Binding ✨
okay so after an Inner Method finishes successfully and the inner keys are derived 🔑, the server sends a Crypto-Binding TLV to the peer 💌. if the Inner Method has failed, the server does not send a Crypto-Binding TLV at all 🙅♀️
the peer checks the Crypto-Binding TLV by applying the rules in Section 4.2.13 🧐. if it passes, the peer sends back its own Crypto-Binding TLV, and the server checks that one too. if verification fails at any point, whoever noticed it ends the session 🚫 no drama, just a hard stop.
the Crypto-Binding TLV usually rides along with other TLVs that carry intermediate or final results, or that kick off negotiation of a new Inner Method 🎀. starting that negotiation doesn't change anything about the Crypto-Binding TLV itself.
so Section 4.2.13 says the Compound MAC fields exist in the Crypto-Binding TLV, but it doesn't explain how those fields get derived and managed 🤷♀️ that part is kinda complicated, so it lives here with all the other key derivations 🧩
this section explains how the server and peer compute, send, and verify the Compound MAC fields in the Crypto-Binding TLV 💜. depending on the Inner Method and site policy, the Crypto-Binding TLV can hold only an MSK Compound MAC (Flags=2), only an EMSK Compound MAC (Flags=2), or both Compound MACs (Flags=3). each party in the TEAP session runs its own procedures to compute and verify those fields 🦋
what goes in the Crypto-Binding TLV is decided separately for each Inner Method 🍓. if a Compound MAC fails verification at any point, the party doing the check returns a fatal error, as described in Section 3.9.3 🚨
each peer and server has site policies that may or may not require the MSK Compound MAC and/or the EMSK Compound MAC 📋. these policies can apply globally to every Inner Method, or they can be set separately for each one 🌈. they could switch on automatically when the EAP method is known to always generate an EMSK, and otherwise they can be configurable ⚙️
the server starts crypto-binding by picking which Compound MAC(s) to use, computing their value(s), putting the result(s) into the Crypto-Binding TLV, and then sending it to the peer 🚀
here's what the server does, step by step 👑:
- If the Inner Method is known to generate only MSK, or if the server's policy is to not use EMSK Compound MACs:
- The server computes the MSK Compound MAC using the MSK of the Inner Method. The server does not use the EMSK Compound MAC field (Flags=2).
Otherwise, the EMSK is available.
- If the server's policy permits the use of the MSK Compound MAC:
- The sender computes the MSK Compound MAC along with the EMSK Compound MAC (Flags=3).
Otherwise, the server's policy does not allow the use of the MSK Compound MAC:
- The server computes only the EMSK Compound MAC (Flags=1).
the peer checks the Crypto-Binding TLV it got from the server 🔍. then it replies with its own crypto-binding response: it picks which Compound MAC(s) to use, computes their value(s), puts them in the Crypto-Binding TLV, and sends it back to the server 💌. the result is either a fatal error or one or more Compound MACs in the Crypto-Binding TLV that go to the server 💅
here's what the peer does while checking 🕵️♀️:
- If the peer's site policy requires the use of the EMSK Compound MAC:
- The peer checks whether the Flags field indicates the presence of the EMSK Compound MAC (Flags=1 or 3). If the Flags field has any other value, the peer returns a fatal error.
- The peer checks whether the Inner Method has derived an EMSK. If not, the peer returns a fatal error.
Otherwise, the peer's site policy does not require the use of the EMSK Compound MAC, and the EMSK may or may not exist.
- If the Inner Method is known to generate only MSK and not EMSK:
- The peer checks whether the Flags field indicates that only the MSK Compound MAC exists (Flags=2). If the Flags field has any other value, the peer returns a fatal error.
Otherwise, the MSK exists, the EMSK may or may not exist, and the peer allows the use of the EMSK Compound MAC. The peer may have received one or two Compound MACs (Flags=1,2,3). Any Compound MAC that is present is verified. The peer takes no further action if a particular Compound MAC is not present. The peer takes no further action if an unexpected Compound MAC is present.
Note that because the Flags field was already validated earlier (Section 4.2.13), at least one Compound MAC must now exist (Flags=1,2,3).
- If the peer has received an MSK Compound MAC, it verifies it and returns a fatal error if verification fails.
- If the EMSK is available and the peer has received an EMSK Compound MAC, it verifies it and returns a fatal error if verification fails.
the peer then builds its crypto-binding response by picking which Compound MAC(s) to use, computing their value(s), putting them in the Crypto-Binding TLV, and sending it to the server 🎀
here's what the peer does for the response 💖:
- If the peer received an MSK Compound MAC from the server:
- Since the MSK always exists, this step is always possible. The peer computes the MSK Compound MAC for the response (Flags=2).
- If the peer's site policy requires the use of the EMSK Compound MAC:
- The preceding steps taken by the peer ensure that the EMSK exists and that the server sent an EMSK Compound MAC. The peer computes the EMSK Compound MAC for the response. The Flags field is updated (Flags=1,3).
Otherwise, if the EMSK exists:
- The peer computes the EMSK Compound MAC for the response. The Flags field is updated (Flags=1,3).
and now the server checks the peer's response 👀:
- If the server's site policy requires the use of the EMSK Compound MAC:
- The server checks whether the Flags field indicates the presence of the EMSK Compound MAC (Flags=1 or 3). If the Flags field has any other value, the server returns a fatal error.
- The server checks whether the Inner Method has derived an EMSK. If not, the server returns a fatal error.
- If the Inner Method is known to generate only MSK and not EMSK:
- The server checks whether the Flags field indicates that only the MSK Compound MAC exists (Flags=2). If the Flags field has any other value, the server returns a fatal error.
Otherwise, the MSK exists and the EMSK may or may not exist. The server may have received one or two Compound MACs (Flags=1,2,3). Any Compound MAC that is present is verified. The server takes no further action if a particular Compound MAC is not present. The server takes no further action if an unexpected Compound MAC is present.
- If the server has received an MSK Compound MAC, it verifies it and returns a fatal error if verification fails.
- If the EMSK is available and the server has received an EMSK Compound MAC, it verifies it and returns a fatal error if verification fails.
once all of the above is done, the server either carries on authenticating with another Inner Method or sends a Result TLV 🏁
6.2.5. Unintended Side Effects 🙈
in earlier drafts of this document, the key derivation descriptions had issues that only showed up after TEAP was already widely implemented 😭 these issues need to be written down so implementations can interoperate.
as mentioned above, some inner EAP methods derive an MSK but not an EMSK. when there's no EMSK, it's not possible to derive IMCK_EMSK[j] from it. so the implementers went with a shortcut, defining:
IMCK_EMSK[j] = IMCK_EMSK[j - 1]this is really easy to implement: you just keep a cached copy of IMCK_EMSK in a data structure. if the EMSK is available, IMCK_EMCK gets updated from it via the TLS-PRF function defined above. if the EMSK is not available, the IMCK_EMSK value stays unchanged 🧁
this behavior wasn't explicitly planned in earlier drafts. it seems to be an accidental result of implementing the derivations above when the EMSK is missing 🤭 it's written down explicitly here so TEAP is fully documented.
another unintended consequence shows up in the calculation of the Crypto-Binding TLV 🧐. that TLV includes Compound MACs that depend on the MSK and EMSK of the current authentication method. when the current method doesn't provide an EMSK, the Crypto-Binding TLV doesn't include a Compound MAC that depends on the EMSK. when the current method doesn't provide an MSK, the Crypto-Binding TLV includes a Compound MAC that depends on a special "all zero" IMSK, as discussed earlier.
⚠️ the result is that the final Crypto-Binding TLV in an inner TEAP exchange may not include a Compound MAC that depends on the EMSK, even if earlier EAP methods in the Phase 2 exchange provided an EMSK. this likely has negative effects on security, though the full impact is unknown at the time of writing this document 💀
even so, these design flaws ended up in multiple interoperable implementations 🌸. those implementations seem to support only EAP-TLS and the EAP-FAST-MSCHAPv2 variant of EAP-MSCHAPv2. other inner EAP methods may work by accident but are not likely to work by design 🙃 for this document, all we can do is make sure TEAPv1's behavior is fully documented, even though that behavior was an unintended consequence of unclear text in earlier versions of this specification 🫶
we expect these issues to be addressed in a future revision of TEAP 🔮
6.3. Computing the Compound MAC
Okay bestie, this is the Compound MAC moment 🔐✨. For Inner Methods that generate keying material, you get extra protection against on-path attacks because the key material from TEAP Phase 1 and TEAP Phase 2 gets cryptographically locked together 💜. After each successful inner EAP authentication, the EMSK and/or MSKs get mixed with key material from Phase 1 to make a CMK 🌸. That CMK is used to calculate the Compound MAC inside the Crypto-Binding TLV (see Section 4.2.13), and it helps show that the same entities are involved in every part of TEAP 🫶. While the Compound MAC is being calculated, the MAC field is filled with zeros 🍓.
The formula is giving simple but iconic 💅:
Compound MAC = the first 20 octets of MAC( CMK[n], BUFFER )Here, n is the number of the last successfully executed inner method. MAC is the MAC function negotiated in TLS (for example, TLS 1.2 in [RFC5246]). BUFFER gets built by sticking these fields together in this exact order 🧚:
- The entire Crypto-Binding TLV attribute, with both the EMSK and MSK Compound MAC fields zeroed out.
- The EAP Type sent by the other party in the first TEAP message, which MUST be TEAP, encoded as one octet of 0x37.
- All the Outer TLVs from the first TEAP message sent by the EAP server to the peer. If a single TEAP message is fragmented into multiple TEAP packets, then the Outer TLVs in all the fragments of that message MUST be included.
- All the Outer TLVs from the first TEAP message sent by the peer to the EAP server. If a single TEAP message is fragmented into multiple TEAP packets, then the Outer TLVs in all the fragments of that message MUST be included.
If no Inner Method is run, then no MSK or EMSK will be generated 🙈. If an IMSK needs to be generated, then the MSK and therefore the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets of 0x00s).
Here's a sneaky detail 👀: there is no boundary marker between the fields in steps (3) and (4). Even so, the server builds the compound MAC from the Outer TLVs it sent and the Outer TLVs it received from the peer. The peer does the mirror move, building its compound MAC from the outer TLVs it sent and the Outer TLVs it received from the server. So if anyone messes with the Outer TLVs in transit, the two sides end up with different values for the compound MAC and that gets caught 🚨.
If no key-generating Inner Method is run, then no MSK or EMSK will be generated. If an IMSK needs to be generated, then the MSK and therefore the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets of 0x00s)
6.4. EAP Master Session Key Generation
TEAP authentication makes sure the MSK and EMSK coming out of a TEAP run are the combined result of all Inner Methods, and it does that by generating an IMCK 👑. The peer and the server both derive the IMCK together, as described in Section 6.2, by combining the MSKs from Inner Methods with key material from TEAP Phase 1 🤝. The final MSK and EMSK come from the last ("n"th) Inner Method, through the IMCK[n] key hierarchy, using this derivation 🦋:
MSK = the first 64 octets of TLS-PRF(S-IMCK[n],
"Session Key Generating Function")
EMSK = the first 64 octets of TLS-PRF(S-IMCK[n],
"Extended Session Key Generating Function")The secret is S-IMCK[n], where n is the number of the last generated S-IMCK[j] from Section 6.2. The label is the ASCII value of the string without quotes. The seed is empty (0 length) and gets left out of the derivation 🌈.
The EMSK is typically only known to the TEAP peer and the server, and it is not handed to a third party 🔒. Deriving additional keys, and getting those keys to a third party, is outside the scope of this document.
If no Inner Method has created an MSK or EMSK, then the MSK and EMSK get generated directly from the session_key_seed, meaning S-IMCK[0] = session_key_seed 🌸.
Plot twist 😭: not every Inner Method generates both an MSK and an EMSK. That means we have to keep two separate derivations of S-IMCK[j], one for MSK[j] and one for EMSK[j]. The final derivation using S-IMCK[n] has to pick just one of them 💅.
If the Crypto-Binding TLV contains an EMSK compound MAC, then the derivation is taken from the S-IMCK_EMSK[n]. Otherwise, it is taken from the S-IMCK_MSK[n] ✨.
7. IANA Considerations 📋
This section gives guidance to the Internet Assigned Numbers Authority (IANA) about registering values related to the TEAP protocol, following [BCP26] 🎀.
Except as noted below, IANA has updated the "Tunnel Extensible Authentication Protocol (TEAP) Parameters" registry so the Reference field in all tables now points from [RFC7170] to RFC 9930 🔄.
7.1. TEAP TLV Types
IANA updated the references in the "TEAP TLV Types" registry from [RFC7170] to RFC 9930 and added TLV 18 and TLV 19 🧁. That means the Unassigned values now start at 20 instead of 18.
+==========+====================+===========+
| Value | Description | Reference |
+==========+====================+===========+
| 18 | CSR-Attributes TLV | RFC 9930 |
+----------+--------------------+-----------+
| 19 | Identity-Hint TLV | RFC 9930 |
+----------+--------------------+-----------+
| 20-16383 | Unassigned |
+----------+--------------------------------+
Table 3IANA has closed the "TEAP PAC TLV (value 11) PAC Attribute Type Codes" and "TEAP PAC TLV (value 11) PAC-Type Type Codes" registries to new registrations 🚫. They got updated with this note:
| This registry has been closed. See RFC 9930.
7.2. TEAP Error TLV (value 5) Error Codes
IANA updated the "TEAP Error TLV (value 5) Error Codes" registry and added these entries 🚨:
+=======+=========================================+===========+
| Value | Description | Reference |
+=======+=========================================+===========+
| 1032 | Inner Method not supported | RFC 9930 |
+-------+-----------------------------------------+-----------+
| 2003 | The Crypto-Binding TLV is invalid | RFC 9930 |
| | (Version, or Received-Ver, or Sub-Type) | |
+-------+-----------------------------------------+-----------+
| 2004 | The first Inner Method did not derive | RFC 9930 |
| | EMSK | |
+-------+-----------------------------------------+-----------+
| 2005 | The Crypto-Binding TLV did not include | RFC 9930 |
| | a required MSK Compound MAC | |
+-------+-----------------------------------------+-----------+
| 2006 | The MSK Compound MAC fails verification | RFC 9930 |
+-------+-----------------------------------------+-----------+
| 2007 | The Crypto-Binding TLV did not include | RFC 9930 |
| | a required EMSK Compound MAC | |
+-------+-----------------------------------------+-----------+
| 2008 | The EMSK Compound MAC fails | RFC 9930 |
| | verification | |
+-------+-----------------------------------------+-----------+
| 2009 | The EMSK Compound MAC exists, but the | RFC 9930 |
| | Inner Method did not derive EMSK | |
+-------+-----------------------------------------+-----------+
Table 47.3. TLS Exporter Labels
IANA updated the "TLS Exporter Labels" registry so the Reference field for the Value "EXPORTER: teap session key seed" points to RFC 9930 🌷:
+==================+=========+=============+===========+
| Value | DTLS-OK | Recommended | Reference |
+==================+=========+=============+===========+
| EXPORTER: teap | N | Y | RFC 9930 |
| session key seed | | | |
+------------------+---------+-------------+-----------+
Table 57.4. Extended Master Session Key (EMSK) Parameters
IANA updated the "User Specific Root Keys (USRK) Key Labels" registry so the Reference field for the Value "TEAPbindkey@ietf.org" points to RFC 9930 🔑:
+======================+==========================+===========+
| Label | Description | Reference |
+======================+==========================+===========+
| TEAPbindkey@ietf.org | TEAP binding usage label | RFC 9930 |
+----------------------+--------------------------+-----------+
Table 67.5. Extensible Authentication Protocol (EAP) Registry
IANA updated the "Method Types" registry so the Reference field for Value "55" points to RFC 9930 🦄:
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 55 | TEAP | RFC 9930 |
+-------+-------------+-----------+
Table 78. Security Considerations 🚨
TEAP is designed with wireless media in mind, and wireless is basically eavesdropping territory 👀. With wired media, an attacker has to get physical access to the wire. With wireless media, anyone can capture information as it goes through the air, which means passive attacks are on the table 📡. So physical security can not be assumed, and the security risks are way bigger 😱. The threat model used for the security evaluation of TEAP is defined in EAP [RFC3748].
8.1. Mutual Authentication and Integrity Protection
Overall, TEAP provides message and integrity protection by setting up a secure tunnel to protect the inner method(s) 🔐. Confidentiality and integrity protection are defined by TLS, and they give the same security strengths that TLS gives when it uses a strong entropy shared master secret 💪. The integrity of the key generating Inner Methods run inside the TEAP tunnel is checked through the calculation of the Crypto-Binding TLV. This makes sure the tunnel endpoints are the same as the inner method endpoints 🫶.
Where server unauthenticated provisioning is performed, TEAP requires that the inner provisioning method provide for both peer and server authentication 🛡️.
8.2. Method Negotiation ✨
okay so bestie, EAP NAK messages that suggest a different EAP method are sent completely unprotected, which means they are totally spoofable 😭 an attacker can jump in and try to bid-down the connection to something weaker, like EAP-MD5, which only gives one-way authentication and doesn't derive a key. 💀 so the peer and the server both MUST NOT be willing to negotiate down to weaker methods, they should each have a method selection policy that stops it. The good news is that inner method negotiation happens inside the mutually authenticated TLS tunnel, so it's protected 🛡️ and choosing TEAP doesn't limit which inner methods you can use, so TEAP should be picked whenever it's available 💅
an attacker can't easily figure out which Inner Method is being used, unless they do traffic analysis 👀 and peers also need to be careful about using their credentials with a server that isn't authenticated or isn't authorized 🫶
8.3. Separation of Phase 1 and Phase 2 Servers 🎀
okay this one is a big deal 🙈 splitting TEAP Phase 1 from Phase 2 is NOT RECOMMENDED 🚫 if your Phase 1 conversation ends on a different server than your Phase 2 conversation, things can go wrong fast unless there's a proper trust relationship and protection between those two servers. the vulnerabilities to watch out for are:
- Loss of identity protection 😱
- Offline dictionary attacks 💀
- Lack of policy enforcement 🙅♀️
- On-path active attacks (as described in [RFC7029]) 🕸️
there can be situations where the two servers do have a trust relationship, like on a campus or between two offices of the same company, and there's no danger in revealing the peer's inner identity and credentials to the entities between them 🏫 in those cases, a proxy solution without end-to-end protection of TEAP MAY be used. 🌸 but the TEAP encrypting/decrypting gateway MUST, at a minimum, support IPsec, TLS, or something similar so the conversation between the gateway and the EAP server is confidential 🔐 also, splitting the TEAP servers and Inner servers means crypto-binding based on the Inner Method MSK can be thwarted, as described in [RFC7029]. if the Inner Method derives an EMSK, though, the threat is mitigated, because TEAP uses the Crypto-Binding TLV to tie the inner EMSK to the TLS session via the TLS-PRF, as described above in Section 6 ✨
but if the Inner Method is NOT deriving an EMSK (think password authentication or unauthenticated provisioning), the threat is still there 😬 so implementations need to limit the use of Inner Methods as discussed above in Section 3.6.5 🧚
8.4. Mitigation of Known Vulnerabilities and Protocol Deficiencies 👑
TEAP fixes a bunch of known deficiencies and weaknesses in some EAP authentication methods 🔥 by using a shared secret between the peer and server to set up a secured tunnel, TEAP gives you:
- Per-packet confidentiality and integrity protection 🔒
- User identity protection 🎭
- Better support for notification messages 📣
- Protected Inner Method negotiation, including EAP methods 🛡️
- Sequencing of Inner Methods, including EAP methods 🔢
- Strong mutually derived MSKs 🔑
- Acknowledged success/failure indication ✅
- Faster re-authentications through session resumption ⚡
- Mitigation of offline dictionary attacks 🙅♀️
- Mitigation of on-path attacks 🕵️♀️
- Mitigation of some denial-of-service attacks 🛡️
it should be noted that, like many other authentication protocols, TEAP can be hit by denial-of-service attacks, where adversaries send erroneous traffic to mess up the protocol 🌧️ this is a problem for lots of authentication and key agreement protocols, so it's noted for TEAP too 💅
TEAP was built with protected Inner Methods in mind, the ones that usually rely on weak credentials like password-based secrets 🔐 so the TEAP authentication helps with several vulnerabilities, such as offline dictionary attacks, by protecting that weak credential-based Inner Method. the protection comes from strong cryptographic algorithms in TLS that give message confidentiality and integrity 💖 the keys used for protection rely on strong random challenges from both peer and server, plus an established key with strong entropy 🌈 implementations SHOULD follow the recommendation in [RFC4086] when generating random numbers 🎲
8.4.1. User Identity Protection and Verification 🎀
the initial identity request/response exchange is sent in cleartext, outside the protection of TEAP 📮 usually, the NAI [RFC7542] in the identity response is only useful for the realm, which is what routes the authentication requests to the right EAP server 🗺️ so the identity response may contain an anonymous identity and just include realm information 🥷 in other cases the identity exchange can be skipped entirely if there are other ways to figure out the destination realm of the request 🙌
in no case should an intermediary trust the identity information in the identity response 🚫 it's unauthenticated and may have nothing to do with the authenticated identity 😤 TEAP implementations SHOULD NOT try to compare any identity disclosed in the initial cleartext EAP Identity response packet with the Identities authenticated in Phase 2 🙈
when the server is authenticated, identity request/response exchanges sent after the TEAP tunnel is established are protected from modification and eavesdropping by attackers 🛡️ for server unauthenticated provisioning, though, the outer TLS session gives little security, so the provisioning method has to provide that protection instead 🫶
when a client certificate is sent outside the TLS tunnel in Phase 1, the peer MUST include Identity-Type as an Outer TLV to signal what type of identity that client certificate is for 🏷️ and when a client certificate is sent outside the TLS tunnel, the server MUST proceed with Phase 2 💅 if there's no Phase 2 data, the EAP server MUST reject the session 🙅♀️
issues about the confidentiality of a client certificate are discussed above in Section 3.4.1 📜
note that the Phase 2 data could be as simple as a Result TLV with value Success, along with a Crypto-Binding TLV ✅ this Phase 2 data acts as a protected success indication, as discussed in [RFC9190], Section 2.1.1 ✨
8.5. Dictionary Attack Resistance 🌸
TEAP was built with protected Inner Methods in mind, the ones that typically rely on weak credentials like password-based secrets 💜 TEAP mitigates offline dictionary attacks by setting up a mutually authenticated, encrypted TLS tunnel that gives confidentiality and integrity to protect that weak credential-based Inner Method 🔐
TEAP also mitigates dictionary attacks by allowing Inner Methods, like EAP-pwd, that aren't vulnerable to dictionary attacks 🧚
TEAP implementations can mitigate online "brute force" dictionary attempts by limiting the number of failed authentication attempts for a particular identity 🚧
8.5.1. Protection Against On-Path Attacks 🕵️♀️
TEAP protects against on-path attacks in a few ways:
- By using a certificate or a session ticket to mutually authenticate the peer and server during the TEAP authentication Phase 1 establishment of a secure TLS tunnel 🎫
- When the TLS tunnel is not secured, by using the keys generated by the Inner Method (if the Inner Methods are key generating) in the crypto-binding exchange and in the generation of the key material exported by the Inner Method described in Section 6 🔑
TEAP crypto-binding does NOT guarantee protection from on-path attacks if the client allows a connection to an untrusted server 😱 for example, if the client doesn't properly validate the server's certificate 🙈 if the TLS cipher suite derives the master secret solely from one side's secret data (like cipher suites based on RSA key transport), then an attacker who can convince the client to connect and go through authentication can impersonate the client to another server, even if a strong Inner Method runs inside the tunnel 💀 but if the TLS cipher suite derives the master secret from secrets contributed by both sides (like cipher suites based on Diffie-Hellman), then crypto-binding can detect an attacker in the conversation when a strong Inner Method is used 🕵️♀️
TEAP crypto-binding does NOT guarantee protection from on-path attacks when the client doesn't verify the server AND the Inner Method doesn't produce an EMSK 😭 the only way to close this vulnerability is to define TEAPv2, which would have different crypto-binding derivations 🦋
8.6. Protecting Against Forged Cleartext EAP Packets 🙅♀️
EAP Success and EAP Failure packets are generally sent in cleartext, and an attacker can forge them without being detected 👻 forged EAP Failure packets can be used to try to convince an EAP peer to disconnect 😵 forged EAP Success packets can be used to try to convince a peer that authentication worked, even though the authenticator never authenticated itself to the peer 😱
TEAP protects against these attacks by providing message confidentiality and integrity 🛡️ once the peer and authentication server (AS) start TEAP authentication Phase 2, compliant TEAP implementations MUST silently discard all cleartext EAP messages, unless both the TEAP peer and server have indicated success or failure using a protected mechanism 🤫 protected mechanisms include the TLS alert mechanism and the protected termination mechanism described in Section 3.6.6 🔐
the success/failure decisions inside the TEAP tunnel show the final decision of the TEAP authentication conversation 🏁 after a success/failure result has been indicated by a protected mechanism, the TEAP peer can process unprotected EAP Success and EAP Failure messages, BUT the peer MUST ignore any unprotected EAP Success or Failure messages where the result doesn't match the result of the protected mechanism 🙅♀️
to abide by [RFC3748], the server sends a cleartext EAP Success or EAP Failure packet to end the EAP conversation 📨 however, EAP Success and EAP Failure packets are not retransmitted, so the final packet might get lost 😬 a TEAP-protected EAP Success or EAP Failure packet SHOULD NOT be the final packet in a TEAP conversation, but it may still happen based on the conditions above, so an EAP peer SHOULD NOT rely on the unprotected EAP Success and Failure messages 🫶
8.7. Use of Cleartext Passwords 🔑
TEAP can carry cleartext passwords in the Basic-Password-Auth-Resp TLV 😳 implementations SHOULD take care to protect this data 🛡️ for example, passwords should not normally be logged, and password data should be securely scrubbed from memory once it's no longer needed 🧼✨
8.8. Accidental or Unintended Behavior 🙈
okay so TEAP is SO complex, and there was a long gap between [RFC7170] and any real implementation, so ngl there are a bunch of accidental or unintended behaviors floating around in the protocol 💀
The first one is that EAP-FAST-MSCHAPv2 is used instead of EAP-MSCHAPv2. [RFC7170] said TEAP was supposed to use EAP-MSCHAPv2, but an early implementor (or a few) went with EAP-FAST-MSCHAPv2 instead. So for this document, we could either define a new version of TEAP that used EAP-MSCHAPv2, or write down what's already implemented. We went with documenting running code 🫶
⚠️ the next bit is a big deal bestie. The issues discussed in Section 6.2.5 could have security impacts, but no analysis has been performed. The choice of using a special "all zero" IMSK in Section 6.2 was made for simplicity, but it could also have negative security impacts 😭
The definition of the Crypto-Binding TLV means the final Crypto-Binding TLV values might not depend on all previous values of MSK and EMSK. This limitation could have negative security impacts too, but again, no analysis has been performed. Iconic behavior from a protocol that's still figuring itself out 💅
We suggest that TEAP be revised to TEAP version 2, which could address these issues. There are proposals right now for better ways to derive the various keying materials and cryptographic binding derivations. Still, since we're documenting running code, we're publishing this document knowing there are improvements to be made 🦋
8.9. Implicit Challenge 🌸
Some authentication protocols use a challenge/response mechanism, but the challenge material isn't generated by the authentication server. So that material may need some special handling, ya feel? For EAP-TTLS, these challenges are defined in [RFC5281], Section 11.1 ✨
In EAP-MSCHAPv2, the authenticator issues a challenge to the supplicant. Then the supplicant hashes the challenge with the password and forwards the response to the authenticator. The response also includes a Peer-Challenge, which the supplicant creates. Since the challenge is random, it isn't associated with the TLS tunnel, so the protocol may be susceptible to a replay attack. Not me getting a replay vibe here 😬
The Crypto-Binding TLV protects against intermediaries, but it does not protect against a replay attack. We suggest that any TEAPv2 specification correct this issue 🔥
8.10. Security Claims 💜
This section gives the security claim requirement for EAP [RFC3748] that the document needs. Here's the full breakdown, bestie:
Auth. mechanism:Certificate-based, shared-secret-based, and various tunneled authentication mechanisms.Cipher Suite negotiation:YesMutual authentication:YesIntegrity protection:Yes. Any method executed within the TEAP tunnel is integrity protected. The cleartext EAP headers outside the tunnel are not integrity protected. Server unauthenticated provisioning provides its own protection mechanisms.Replay protection:YesConfidentiality:YesKey derivation:YesKey strength:See Note 1 below.Dictionary attack prot.:See Note 2 below.Fast reconnect:YesCryptographic binding:YesSession independence:YesFragmentation:YesKey Hierarchy:YesChannel binding:Yes
Notes:
- Note 1. [BCP86] offers advice on appropriate key sizes. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [NIST-SP-800-57]. [RFC3766], Section 6 advises use of the following required RSA or Diffie-Hellman (DH) module and Digital Signature Algorithm (DSA) subgroup size in bits for a given level of attack resistance in bits. Based on the table below, a 2048-bit RSA key is required to provide 112-bit equivalent key strength 🔑
+==========================+===================+==============+
| Attack Resistance (bits) | RSA or DH Modulus | DSA subgroup |
| | size (bits) | size (bits) |
+==========================+===================+==============+
| 70 | 947 | 129 |
+--------------------------+-------------------+--------------+
| 80 | 1228 | 148 |
+--------------------------+-------------------+--------------+
| 90 | 1553 | 167 |
+--------------------------+-------------------+--------------+
| 100 | 1926 | 186 |
+--------------------------+-------------------+--------------+
| 150 | 4575 | 284 |
+--------------------------+-------------------+--------------+
| 200 | 8719 | 383 |
+--------------------------+-------------------+--------------+
| 250 | 14596 | 482 |
+--------------------------+-------------------+--------------+
Table 8- Note 2. TEAP protects against offline dictionary attacks when secure Inner Methods are used. TEAP protects against online dictionary attacks by limiting the number of failed authentications for a particular identity 🛡️
9. References 📚
9.1. Normative References
[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>.[RFC2985]Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, DOI 10.17487/RFC2985, November 2000,<https://www.rfc-editor.org/info/rfc2985>.[RFC2986]Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000,<https://www.rfc-editor.org/info/rfc2986>.[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>.[RFC5077]Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008,<https://www.rfc-editor.org/info/rfc5077>.[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>.[RFC5246]Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008,<https://www.rfc-editor.org/info/rfc5246>.[RFC5295]Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, DOI 10.17487/RFC5295, August 2008,<https://www.rfc-editor.org/info/rfc5295>.[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>.[RFC5746]Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,<https://www.rfc-editor.org/info/rfc5746>.[RFC5929]Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,<https://www.rfc-editor.org/info/rfc5929>.[RFC6677]Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012,<https://www.rfc-editor.org/info/rfc6677>.[RFC7030]Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013,<https://www.rfc-editor.org/info/rfc7030>.[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>.[RFC8996]Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,<https://www.rfc-editor.org/info/rfc8996>.[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>.[RFC9427]DeKok, A., "TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3", RFC 9427, DOI 10.17487/RFC9427, June 2023,<https://www.rfc-editor.org/info/rfc9427>.[RFC9525]Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023,<https://www.rfc-editor.org/info/rfc9525>.[RFC9908]Richardson, M., Ed., Friel, O., von Oheimb, D., and D. Harkins, "Clarification and Enhancement of the CSR Attributes Definition in RFC 7030", RFC 9908, DOI 10.17487/RFC9908, January 2026,<https://www.rfc-editor.org/info/rfc9908>.
9.2. Informative References 📚✨
okay bestie, these are the extra reads 🫶 they're here to back things up, not the must-read basics. the complete list is below, all the details included 💅
[BCP26] Best Current Practice 26, <https://www.rfc-editor.org/info/bcp26>. At the time of writing, this BCP comprises the following:
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>.
[BCP86] Best Current Practice 86, <https://www.rfc-editor.org/info/bcp86>. At the time of writing, this BCP comprises the following:
Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, DOI 10.17487/RFC3766, April 2004, <https://www.rfc-editor.org/info/rfc3766>.
[IEEE.802-1X.2020] IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Port-Based Network Access Control", IEEE Std 802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, February 2020, <https://doi.org/10.1109/IEEESTD.2020.9018454>.
[KAMATH] Kamath, V. and A. Palekar, "Microsoft EAP CHAP Extensions", Work in Progress, Internet-Draft, draft-kamath-pppext-eap-mschapv2-02, 19 June 2007, <https://datatracker.ietf.org/doc/html/draft-kamath-pppext-eap-mschapv2-02>.
[MSCHAP] Microsoft Corporation, "Master Session Key (MSK) Derivation", 23 April 2024, <https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-chap/5a860bf5-2aeb-485b-82ee-fac1e8e6b76f>.
[NIST-SP-800-57] Barker, E., "Recommendation for Key Management: Part 1 - General", NIST SP 800-57 Part 1 Rev. 5, DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, <https://doi.org/10.6028/NIST.SP.800-57pt1r5>.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)", 24 June 2021, <https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4-beec-fb367325c0f9>.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, <https://www.rfc-editor.org/info/rfc2315>.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, DOI 10.17487/RFC3579, September 2003, <https://www.rfc-editor.org/info/rfc3579>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, DOI 10.17487/RFC4017, March 2005, <https://www.rfc-editor.org/info/rfc4017>.
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, DOI 10.17487/RFC4072, August 2005, <https://www.rfc-editor.org/info/rfc4072>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", RFC 4334, DOI 10.17487/RFC4334, February 2006, <https://www.rfc-editor.org/info/rfc4334>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[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>.
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, DOI 10.17487/RFC4945, August 2007, <https://www.rfc-editor.org/info/rfc4945>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, DOI 10.17487/RFC4962, July 2007, <https://www.rfc-editor.org/info/rfc4962>.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, DOI 10.17487/RFC5247, August 2008, <https://www.rfc-editor.org/info/rfc5247>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, <https://www.rfc-editor.org/info/rfc5272>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[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>.
[RFC5421] Cam-Winget, N. and H. Zhou, "Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", RFC 5421, DOI 10.17487/RFC5421, March 2009, <https://www.rfc-editor.org/info/rfc5421>.
[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>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", RFC 5931, DOI 10.17487/RFC5931, August 2010, <https://www.rfc-editor.org/info/rfc5931>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6124] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol", RFC 6124, DOI 10.17487/RFC6124, February 2011, <https://www.rfc-editor.org/info/rfc6124>.
[RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: Time-Based One-Time Password Algorithm", RFC 6238, DOI 10.17487/RFC6238, May 2011, <https://www.rfc-editor.org/info/rfc6238>.
[RFC6678] Hoeper, K., Hanna, S., Zhou, H., and J. Salowey, Ed., "Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method", RFC 6678, DOI 10.17487/RFC6678, July 2012, <https://www.rfc-editor.org/info/rfc6678>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, <https://www.rfc-editor.org/info/rfc6961>.
[RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding", RFC 7029, DOI 10.17487/RFC7029, October 2013, <https://www.rfc-editor.org/info/rfc7029>.
[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>.
[RFC7299] Housley, R., "Object Identifier Registry for the PKIX Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, <https://www.rfc-editor.org/info/rfc7299>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <https://www.rfc-editor.org/info/rfc7542>.
[RFC8146] Harkins, D., "Adding Support for Salted Password Databases to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017, <https://www.rfc-editor.org/info/rfc8146>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, <https://www.rfc-editor.org/info/rfc9325>.
[X.690] ITU-T, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", February 2021, <https://www.itu.int/rec/T-REC-X.690>.
Appendix A. Evaluation Against Tunnel-Based EAP Method Requirements 🦋
this appendix is the scorecard 📋 it checks every tunnel-based EAP method requirement from [RFC6678] against TEAP version 1, one by one 💅
This section evaluates all tunnel-based EAP method requirements described in [RFC6678] against TEAP version 1.
A.1. Requirement 4.1.1: RFC Compliance ✨
TEAPv1 meets this requirement by being compliant with [RFC3748], [RFC4017], [RFC5247], and [RFC4962]. It is also compliant with the "cryptographic algorithm agility" requirement by leveraging TLS 1.2 for all cryptographic algorithm negotiation. 🔥
A.2. Requirement 4.2.1: TLS Requirements 🎀
TEAPv1 meets this requirement by mandating TLS version 1.2 support as defined in Section 3.2. 💜
A.3. Requirement 4.2.1.1.1: Cipher Suite Negotiation 🌸
TEAPv1 meets this requirement by using TLS to provide protected cipher suite negotiation. 🫶
A.4. Requirement 4.2.1.1.2: Tunnel Data Protection Algorithms 👑
TEAPv1 meets this requirement by mandating cipher suites as defined in Section 3.2. 😭
A.5. Requirement 4.2.1.1.3: Tunnel Authentication and Key Establishment ✨
okay so TEAPv1 nails this one 💅 It only allows cipher suites that use strong cryptographic algorithms, so the weak stuff is just not on the menu. It also leaves out cipher suites that give you mutually anonymous authentication, and it leaves out the static Diffie-Hellman cipher suites from Section 3.2. no cap, very clean 🔐
A.6. Requirement 4.2.1.2: Tunnel Replay Protection 🦋
TEAPv1 gets this one by using TLS to provide enough replay protection. TLS is doing the heavy lifting here, and it's giving reliable 🫶
A.7. Requirement 4.2.1.3: TLS Extensions 🎀
TEAPv1 lets you use TLS extensions while the TLS tunnel is being set up. The examples are the TLS Certificate Status Request extension [RFC6066] and the SessionTicket extension [RFC5077]. Super flexible, very iconic 👑
A.8. Requirement 4.2.1.4: Peer Identity Privacy 🙈
TEAPv1 handles this by setting up the TLS tunnel and by protecting identities that are specific to the Inner Method. On top of that, the peer certificate can be sent confidentially, which means encrypted 🔒 Privacy bestie behavior.
A.9. Requirement 4.2.1.5: Session Resumption 🌸
TEAPv1 makes sure session resumption is supported by requiring TLS session resumption as defined in Section 3.5.1. It also does TLS session resumption using the methods defined in [RFC9190]. Double coverage, we love to see it 🙌
A.10. Requirement 4.2.2: Fragmentation 🧚
TEAPv1 leans on the fragmentation support that TLS already has, as defined in Section 3.10. Why reinvent the wheel when TLS has it covered? 💅
A.11. Requirement 4.2.3: Protection of Data External to Tunnel 🔥
TEAPv1 meets this by putting the TEAP version number it received into the computation of the Crypto-Binding TLV, as defined in Section 4.2.13. So the version number is locked into the math 🧮✨
A.12. Requirement 4.3.1: Extensible Attribute Types 🌈
TEAPv1 uses an extensible TLV data layer inside the tunnel, as defined in Section 4.2. Extensible means it can grow with you, and that's so relatable 💖
A.13. Requirement 4.3.2: Request/Challenge Response Operation 🍓
TEAPv1 lets you send multiple TLVs in a single EAP request or response packet. It still keeps the half-duplex operation that is typical of EAP, so the back-and-forth stays in order 🔁
A.14. Requirement 4.3.3: Indicating Criticality of Attributes ⭐
Every TLV has a mandatory bit. That bit says whether the receiver has to support that TLV or not, as defined in Section 4.2. Super clear signals, no mixed messages 🙅♀️
A.15. Requirement 4.3.4: Vendor-Specific Support 💜
TEAPv1 has a Vendor-Specific TLV so vendors can define their own attributes, as defined in Section 4.2.8. Everyone gets to express themselves 🎨
A.16. Requirement 4.3.5: Result Indication 👑
TEAPv1 has a Result TLV for swapping the final result of the TEAP authentication. That way the peer and the server both end up with a synchronized state, as defined in Section 4.2.4. Nobody is left on read 📱✅
A.17. Requirement 4.3.6: Internationalization of Display Strings 🌍
TEAPv1 supports the UTF-8 format in the Basic-Password-Auth-Req TLV, as defined in Section 4.2.14, and in the Basic-Password-Auth-Resp TLV, as defined in Section 4.2.15. Every language gets to slay 💅🌏
A.18. Requirement 4.4: EAP Channel-Binding Requirements 🔗
TEAPv1 has a Channel-Binding TLV that exchanges the EAP channel-binding data, as defined in Section 4.2.7. It's the bond between the layers, honestly so sweet 🥹
A.19. Requirement 4.5.1.1: Confidentiality and Integrity 🔐
TEAPv1 runs the password authentication inside a protected TLS tunnel. So the password stays private and untouched in transit, which is the vibe 🫶
A.20. Requirement 4.5.1.2: Authentication of Server 🛡️
TEAPv1 requires the server to be authenticated before the protected TLS is established. After that it runs inner password authentication, as defined in Section 3.2. Server gets checked at the door first, then we talk secrets 🚪✨
A.21. Requirement 4.5.1.3: Server Certificate Revocation Checking 🧾
TEAPv1 supports the TLS Certificate Status Request extension [RFC6066] during tunnel establishment. So revoked certs can get caught 🙅♀️
A.22. Requirement 4.5.2: Internationalization 🌺
TEAPv1 supports the UTF-8 format in the Basic-Password-Auth-Req TLV, as defined in Section 4.2.14, and in the Basic-Password-Auth-Resp TLV, as defined in Section 4.2.15. Same energy as A.17, just a different angle 🦋
A.23. Requirement 4.5.3: Metadata 🏷️
TEAPv1 supports the Identity-Type TLV, as defined in Section 4.2.3. It tells you whether the authentication is for a user or a machine. Labels are everything 🎀
A.24. Requirement 4.5.4: Password Change 🔑
TEAPv1 supports multiple Basic-Password-Auth-Req TLV and Basic-Password-Auth-Resp TLV exchanges inside one EAP authentication. That makes room for "housekeeping" stuff, like changing your password. Spring cleaning, but make it secure 🧹✨
A.25. Requirement 4.6.1: Method Negotiation 🤝
TEAPv1 supports inner EAP method negotiation inside the protected TLS tunnel. Methods can be negotiated privately, which is lowkey iconic 🕵️♀️
A.26. Requirement 4.6.2: Chained Methods 🔗
TEAPv1 supports inner EAP method chaining inside protected TLS tunnels, as defined in Section 3.6.2. One method after another, all wrapped up safe 🎀
A.27. Requirement 4.6.3: Cryptographic Binding with the TLS Tunnel 💞
TEAPv1 supports cryptographically binding the inner EAP method keys to the keys derived from the TLS tunnel, as defined in Section 4.2.13. The keys are literally bonded together, the most loyal energy 💍
A.28. Requirement 4.6.4: Peer-Initiated EAP Authentication 🙋♀️
TEAPv1 supports the Request-Action TLV, as defined in Section 4.2.9. That lets a peer start another inner EAP method on its own. Speaking up for yourself is main character energy 📣
A.29. Requirement 4.6.5: Method Metadata 🏷️
TEAPv1 supports the Identity-Type TLV, as defined in Section 4.2.3. Same as before: it tells you whether the authentication is for a user or a machine. Labels, labels, labels 💅
Appendix B. Major Differences from EAP-FAST 🦋
okay so this document is a brand new standard tunnel EAP method. It's based on the revision of EAP-FAST version 1 [RFC4851], and it's way more flexible, especially when it comes to negotiating cryptographic algorithms. The big changes are:
- The EAP method name changed from EAP-FAST to TEAP. Because of that, a new EAP Type has to be assigned. New name, new ID, new era 🌟
- This version of TEAP MUST support TLS 1.2 [RFC5246]. TLS 1.1 and earlier MUST NOT be used with TEAP. No going back to the old stuff 🙅♀️
- The key derivation now uses TLS keying material exporters [RFC5705] and the PRF and hash function negotiated in TLS. This makes implementation simpler and makes it easier to swap cryptographic algorithms later 🔄
- TEAP is in full conformance with the SessionTicket extension [RFC5077]. Full compliance, no drama 💖
- Optional Outer TLVs can be passed in the first two message exchanges. This is in addition to the Authority-ID TLV data that EAP-FAST already had 📦
- Basic password authentication on the TLV level has been added, on top of the existing inner EAP method 🔑
- Two new TLV types were added to support EAP channel binding and metadata. They are the Identity-Type TLV and the Channel-Binding TLVs, defined in Section 4.2 🏷️🔗
Appendix C. Examples 🎀
C.1. Successful Authentication 🎉
okay so this shows a successful TEAP authentication with basic password authentication. Here's how the conversation goes:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
TLS channel established
(messages sent within the TLS channel)
<- Basic-Password-Auth-Req TLV, Challenge
Basic-Password-Auth-Resp TLV, Response with both
username and password) ->
optional additional exchanges (new pin mode,
password change, etc.) ...
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Crypto-Binding TLV(Response),
Result TLV (Success) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-SuccessC.2. Failed Authentication 🙈
okay so this one shows a failed TEAP authentication because the user credentials were wrong. Oof 😭 Here's how it goes:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
TLS channel established
(messages sent within the TLS channel)
<- Basic-Password-Auth-Req TLV, Challenge
Basic-Password-Auth-Resp TLV, Response with both
username and password) ->
<- Intermediate-Result TLV (Failure),
Result TLV (Failure)
Intermediate-Result TLV (Failure),
Result TLV (Failure) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-FailureC.3. Full TLS Handshake Using Certificate-Based Cipher Suite 🎀
okay so picture this 💅 in TEAP Phase 1, the peer first tries an abbreviated TLS handshake, and if that resumption gets rejected, it falls back to the full certificate-based handshake. here's how the convo goes 🦋
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route
the authentication request to EAP server, instead of the
full user identity.
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello with
SessionTicket extension)->
// If the server rejects the session resumption,
it falls through to the full TLS handshake.
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
EAP-Payload TLV[EAP-Request/
Identity])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel.
EAP-Payload TLV
[EAP-Response/Identity (MyID2)]->
// identity protected by TLS.
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
// Method X exchanges followed by Protected Termination
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Crypto-Binding TLV (Response),
Result TLV (Success) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-SuccessC.4. Client Authentication During Phase 1 with Identity Privacy 🔐
this one's for when a certificate-based TLS handshake happens inside TEAP Phase 1, the client needs certificate authentication, and identity privacy is wanted too. so TLS renegotiation is used to send the peer credentials through the protected TLS tunnel. the convo for TLS 1.2 looks like this 🌸
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route
the authentication request to EAP server, instead of the
full user identity.
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_key_exchange,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
EAP-Payload TLV[EAP-Request/
Identity])
// TLS channel established
(EAP Payload messages sent within the TLS channel)
// peer sends TLS client_hello to request TLS renegotiation
TLS client_hello ->
<- TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done
[TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished ->
<- TLS change_cipher_spec,
TLS finished,
Crypto-Binding TLV (Request),
Result TLV (Success)
Crypto-Binding TLV (Response),
Result TLV (Success)) ->
//TLS channel torn down
(messages sent in cleartext)
<- EAP-SuccessC.5. Fragmentation and Reassembly 🧩
when TEAP fragmentation is needed, the convo goes like this. lots of little pieces, all getting put back together at the end, so it's giving puzzle energy 🧩✨
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
(Fragment 1: L, M bits set)
EAP-Response/
EAP-Type=TEAP, V=1 ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(Fragment 2: M bit set)
EAP-Response/
EAP-Type=TEAP, V=1 ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(Fragment 3)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished)
(Fragment 1: L, M bits set)->
<- EAP-Request/
EAP-Type=TEAP, V=1
EAP-Response/
EAP-Type=TEAP, V=1
(Fragment 2)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
[EAP-Payload TLV[
EAP-Request/Identity]])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel.
EAP-Payload TLV
[EAP-Response/Identity (MyID2)]->
// identity protected by TLS.
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
// Method X exchanges followed by Protected Termination
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Crypto-Binding TLV (Response),
Result TLV (Success) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-SuccessC.6. Sequence of EAP Methods ✨
okay so bestie, this one shows what happens when TEAP runs a sequence of EAP methods, method X first and then method Y 🦋 the flow is giving main character energy 💅
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
Identity-Type TLV,
EAP-Payload TLV[
EAP-Request/Identity])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel
Identity_Type TLV
EAP-Payload TLV
[EAP-Response/Identity] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
// Optional additional X Method exchanges...
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X]->
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Request),
Identity-Type TLV,
EAP-Payload TLV[
EAP-Request/Identity])
// Compound MAC calculated using keys generated from
EAP method X and the TLS tunnel.
// Next EAP conversation started (with EAP-Request/Identity)
after successful completion of previous method X. The
Intermediate-Result and Crypto-Binding TLVs are sent in
the next packet to minimize round trips.
Intermediate Result TLV (Success),
Crypto-Binding TLV (Response),
EAP-Payload TLV [EAP-Response/Identity (MyID2)] ->
// Optional additional EAP method Y exchanges...
<- EAP Payload TLV [
EAP-Type=Y]
EAP Payload TLV
[EAP-Type=Y] ->
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Crypto-Binding TLV (Response),
Result TLV (Success) ->
// Compound MAC calculated using keys generated from EAP
methods X and Y and the TLS tunnel. Compound keys are
generated using keys generated from EAP methods X and Y
and the TLS tunnel.
// TLS channel torn down (messages sent in cleartext)
<- EAP-SuccessC.7. Failed Crypto-Binding ✨
next up is the sad path 🥀 this one shows a crypto-binding validation that doesn't pass 😭 the convo goes like this:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS Client Key Exchange
TLS change_cipher_spec,
TLS finished)
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec
TLS finished)
EAP-Payload TLV[
EAP-Request/Identity])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel.
EAP-Payload TLV/
EAP Identity Response ->
<- EAP Payload TLV, EAP-Request,
(EAP-FAST-MSCHAPV2, Challenge)
EAP Payload TLV, EAP-Response,
(EAP-FAST-MSCHAPV2, Response) ->
<- EAP Payload TLV, EAP-Request,
(EAP-FAST-MSCHAPV2, Success Request)
EAP Payload TLV, EAP-Response,
(EAP-FAST-MSCHAPV2, Success Response) ->
<- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate-Result TLV (Success),
Result TLV (Failure)
Error TLV with
(Error Code = 2001) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-FailureC.8. Sequence of EAP Method with Vendor-Specific TLV Exchange ✨
this one is a sequence of EAP methods that then wraps up with a Vendor-Specific TLV exchange 🎀 very organised, very iconic 💖
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
EAP-Payload TLV[
EAP-Request/Identity])
// TLS channel established
(messages sent within the TLS channel)
// First EAP Payload TLV is coalesced with the TLS Finished as
Application Data and protected by the TLS tunnel.
EAP-Payload TLV
[EAP-Response/Identity] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X]->
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Request),
Vendor-Specific TLV,
// Vendor-Specific TLV exchange started after successful
completion of previous method X. The Intermediate-Result
and Crypto-Binding TLVs are sent with Vendor-Specific TLV
in next packet to minimize round trips.
// Compound MAC calculated using keys generated from
EAP method X and the TLS tunnel.
Intermediate Result TLV (Success),
Crypto-Binding TLV (Response),
Vendor-Specific TLV ->
// Optional additional Vendor-Specific TLV exchanges...
<- Vendor-Specific TLV
Vendor-Specific TLV ->
<- Result TLV (Success)
Result TLV (Success) ->
// TLS channel torn down (messages sent in cleartext)
<- EAP-SuccessC.9. Peer Requests Inner Method After Server Sends Result TLV ✨
last one in this part! 🧚 here the peer is authenticated during Phase 1 and the server sends back a Result TLV, but the peer still wants to ask for another Inner Method 🙈 the peer is not done yet, and honestly iconic for it ⭐ it goes like this:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route
the authentication request to EAP server, instead of the
full user identity. TLS client certificate is also sent.
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
[TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
Crypto-Binding TLV (Request),
Result TLV (Success))
// TLS channel established
(TLV Payload messages sent within the TLS channel)
Crypto-Binding TLV(Response),
Request-Action TLV
(Status=Failure, Action=Negotiate-EAP)->
<- EAP-Payload TLV
[EAP-Request/Identity]
EAP-Payload TLV
[EAP-Response/Identity] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X] ->
<- EAP-Payload TLV
[EAP-Request/EAP-Type=X]
EAP-Payload TLV
[EAP-Response/EAP-Type=X]->
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Request),
Result TLV (Success)
Intermediate Result TLV (Success),
Crypto-Binding TLV (Response),
Result TLV (Success)) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-SuccessC.10. Channel Binding ✨
okay so this one is a successful TEAP auth with basic password auth and channel binding, using a Request-Action TLV 🎀 the convo goes like this:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
TLS channel established
(messages sent within the TLS channel)
<- Basic-Password-Auth-Req TLV, Challenge
Basic-Password-Auth-Resp TLV, Response with both
username and password) ->
optional additional exchanges (new pin mode,
password change, etc.) ...
<- Crypto-Binding TLV (Request),
Result TLV (Success),
Crypto-Binding TLV(Response),
Request-Action TLV
(Status=Failure, Action=Process TLV,
TLV=Channel-Binding TLV)->
<- Channel-Binding TLV (Response),
Result TLV (Success),
Result TLV (Success) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Success💖 the vibe here is: basic password auth goes first, then the crypto-binding and Request-Action TLVs do the channel-binding dance, and then everything gets torn down into cleartext for the EAP-Success finale. iconic 😭🫶
C.11. PKCS Exchange 🦋
okay so this exchange has the peer sending a PKCS#10 TLV and the server sending back a PKCS7 TLV 🌸 it assumes the EAP peer already got authenticated in Phase 1, either through bidirectional certificate exchange or some other TLS method like a proof of knowledge (TLS-POK). here's how the convo goes:
,----. ,-------.
|Peer| |AuthSrv|
`-+--' `---+---'
| EAP-Request / Identity |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response / Identity (MYID1) |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| EAP-Request/EAP-Type=TEAP, |
| V=1(TEAP Start, |
| S bit set, |
| Authority-ID) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, |
| V=1(TLS client_hello) |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| EAP-Request/ EAP-Type=TEAP, |
| V=1(TLS server_hello, |
| TLS certificate, |
| TLS certificate_request, |
| TLS finished) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, |
| V=1(TLS change_cipher_spec, |
| TLS certificate, |
| TLS finished) TLS channel established |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| Send Request-Action TLV |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| Send PKCS10 TLV |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| Sign the CSR and send PKCS7 TLV Intermediate-Result|
| TLV request(Success), |
| Crypto-Binding TLV(Request), |
| Result TLV(Success) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| Intermediate-Result TLV response(Success), |
| Crypto-Binding TLV(Response), |
| Result TLV(Success) |
| - - - - - - - - - - - - - - - - - - - - - - - - - >
| |
| EAP Success |
| <- - - - - - - - - - - - - - - - - - - - - - - - - -C.12. Failure Scenario 💀
this one is the failure scenario, aka the "it's not giving it, bestie" version 🙈 the convo goes like this:
,----. ,-------.
|Peer| |AuthSrv|
`-+--' `---+---'
| EAP-Request / Identity |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response / Identity (MYID1) |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP-Request/EAP-Type=TEAP, V=1 |
| (TEAP Start, S bit set, Authority-ID) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, V=1(TLS client_hello) |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP-Request/ EAP-Type=TEAP, V=1 |
| (TLS server_hello,(TLS change_cipher_spec, TLS finished)|
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, V=1 |
| (TLS change_cipher_spec, |
| TLS finished) |
| TLS channel established |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| Request-Action TLV |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| Bad PKCS10 TLV |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| Intermediate-Result TLV request(Failure), |
| Result TLV(Failure) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| |
| Intermediate-Result TLV response(Failure), |
| Result TLV(Failure) |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP Failure |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - -⚠️ the main thing to notice: the server sends a Request-Action TLV, the peer sends a Bad PKCS10 TLV, and then both sides end up with Failure results and an EAP Failure. no drama, just a clean exit 🫠
C.13. Client Certificate in Phase 1 🌈
okay so this scenario has the client certificate sent in Phase 1, and then there's no extra authentication or provisioning in Phase 2 ✨ the convo goes:
,----. ,-------.
|Peer| |AuthSrv|
`-+--' `---+---'
| EAP-Request / Identity |
| <- - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response / Identity (MYID1) |
| - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP-Request/EAP-Type=TEAP, |
| V=1(TEAP Start, |
| S bit set, |
| Authority-ID) |
| <- - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, |
| V=1(TLS client_hello) |
| - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP-Request/ EAP-Type=TEAP, |
| V=1(TLS server_hello, |
| TLS certificate, |
| TLS certificate_request, |
| TLS change_cipher_spec, |
| TLS finished) |
| <- - - - - - - - - - - - - - - - - - - - -
| |
| EAP-Response/EAP-Type=TEAP, |
| V=1(TLS certificate, |
| TLS change_cipher_spec, |
| TLS finished) TLS channel established |
| - - - - - - - - - - - - - - - - - - - - ->
| |
| Crypto-Binding TLV(Request), |
| Result TLV(Success) |
| <- - - - - - - - - - - - - - - - - - - - -
| |
| Crypto-Binding TLV(Response), |
| Result TLV(Success) |
| - - - - - - - - - - - - - - - - - - - - ->
| |
| EAP Success |
| <- - - - - - - - - - - - - - - - - - - - -Appendix D. Changes from RFC 7170 🎀
okay so bestie, this is the changelog section and it's giving "here's everything we fixed and why" 💅✨
Alan DeKok was added as an editor. Iconic promotion, he earned it 👑
The document was converted to Markdown from the [RFC7170] text output. 🌸
Any formatting changes from [RFC7170] may have resulted from changing from XML to Markdown as the source file when editing the draft. So if the layout looks different, that's why 🙈
The IANA Considerations section was replaced with a note to change the IANA registry references to this document. 🦋
A new section was added to explain that the inner EAP-MSCHAPv2 derivation follows EAP-FAST. This is the largest technical change from the previous revision of this document and follows existing implementations. Main character energy for sure 🔥
Many small changes have been made throughout the document to correct inconsistencies and to address mistakes. At a high level:
- All open errata have been addressed. 💖
- A new term "Inner Method" has been defined. 🧚
- The definitions and derivation of IMSK, S-IMCK, etc. have been corrected and clarified. ✨
- The diagrams in Appendix C have been updated to match the TEAP state machine. 🌈
All uses of the PAC were removed. It had not been implemented, and there were no plans by implementors to use it. Bye bye PAC 💀
Text was added on recommendations for inner and outer identities. 🫶
Section 6.2.5 was added late in the document life cycle in order to document accidental behavior that could result in interoperability issues. Late-stage glow-up, but make it useful 🍓
Acknowledgments 💜
Nearly all of the text in this document was taken directly from [RFC7170]. We are grateful to the original authors and reviewers for that document. The acknowledgments given here are only for the changes that resulted in this document. Credit where credit is due, ngl 🙏
Alexander Clouter provided substantial and detailed technical feedback on nearly every aspect of the specification. The corrections in this document are based on his work. He really did the thing 😭🫶
We wish to thank the many reviewers and commenters in the EMU WG, including Eliot Lear, Joe Salowey, Heikki Vatiainen, Bruno Pereria Vidal, and Michael Richardson. Many corner cases and edge conditions were caught and corrected as a result of their feedback. The whole squad showed up 🦋
Jouni Malinin initially pointed out the issues with [RFC7170]. Those comments resulted in substantial discussion on the EMU WG mailing list, and eventually this document. Jouni also made substantial contributions in analyzing corner cases, which resulted in the text in Section 6.2.5. Lowkey the reason 6.2.5 exists at all 🌟
Contributors 🌸
Han Zhou
Joseph Salowey Email: joe@salowey.net
Nancy Cam-Winget Email: ncamwing@cisco.com
Steve Hanna Email: steve.hanna@infineon.com
Author's Address 🎀
Alan DeKok (editor) Email: alan.dekok@inkbridge.io
That's the whole doc, bestie. Thanks for hanging out with me through all 24 parts 🥹💖✨
📦 where this page comes from
- ietf: rfc9930 2026-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms