RFC 4851
The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)
RFC 4851: EAP-FAST, the Flexible Authentication via Secure Tunneling Method 🎀
okay bestie, this one is RFC 4851, and it's all about EAP-FAST (Flexible Authentication via Secure Tunneling), an EAP method that sets up a mutually authenticated TLS tunnel so the peer and server can talk securely 🔐✨
Four people from Cisco Systems wrote it: N. Cam-Winget, D. McGrew, J. Salowey, and H. Zhou. It's Informational (so it provides info for the Internet community and is not an Internet standard 💅), and it was published in May 2007. The title block doesn't list anything it obsoletes or updates, so it doesn't replace or tweak any earlier RFCs 🦋
Status and copyright: the memo provides information for the Internet community and doesn't specify an Internet standard of any kind. Distribution is unlimited. The copyright belongs to The IETF Trust (2007) 🌸
Abstract ✨
so the abstract says EAP-FAST is an EAP method where a peer and a server set up a mutually authenticated tunnel using TLS (Transport Layer Security) 🔐. Once that tunnel exists, they swap Type-Length-Value (TLV) objects to share auth-related data 💖
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Specification Requirements . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Architectural Model . . . . . . . . . . . . . . . . . . . 6
2.2. Protocol Layering Model . . . . . . . . . . . . . . . . . 7
3. EAP-FAST Protocol . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Version Negotiation . . . . . . . . . . . . . . . . . . . 8
3.2. EAP-FAST Authentication Phase 1: Tunnel Establishment . . 9
3.2.1. TLS Session Resume Using Server State . . . . . . . . 10
3.2.2. TLS Session Resume Using a PAC . . . . . . . . . . . . 10
3.2.3. Transition between Abbreviated and Full TLS
Handshake . . . . . . . . . . . . . . . . . . . . . . 12
3.3. EAP-FAST Authentication Phase 2: Tunneled
Authentication . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1. EAP Sequences . . . . . . . . . . . . . . . . . . . . 13
3.3.2. Protected Termination and Acknowledged Result
Indication . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Determining Peer-Id and Server-Id . . . . . . . . . . . . 14
3.5. EAP-FAST Session Identifier . . . . . . . . . . . . . . . 15
3.6. Error Handling . . . . . . . . . . . . . . . . . . . . . . 15
3.6.1. TLS Layer Errors . . . . . . . . . . . . . . . . . . . 15
3.6.2. Phase 2 Errors . . . . . . . . . . . . . . . . . . . . 16
3.7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 16
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. EAP-FAST Message Format . . . . . . . . . . . . . . . . . 18
4.1.1. Authority ID Data . . . . . . . . . . . . . . . . . . 20
4.2. EAP-FAST TLV Format and Support . . . . . . . . . . . . . 20
4.2.1. General TLV Format . . . . . . . . . . . . . . . . . . 21
4.2.2. Result TLV . . . . . . . . . . . . . . . . . . . . . . 22
4.2.3. NAK TLV . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.4. Error TLV . . . . . . . . . . . . . . . . . . . . . . 24
4.2.5. Vendor-Specific TLV . . . . . . . . . . . . . . . . . 25
4.2.6. EAP-Payload TLV . . . . . . . . . . . . . . . . . . . 26
4.2.7. Intermediate-Result TLV . . . . . . . . . . . . . . . 28
4.2.8. Crypto-Binding TLV . . . . . . . . . . . . . . . . . . 29
4.2.9. Request-Action TLV . . . . . . . . . . . . . . . . . . 31
4.3. Table of TLVs . . . . . . . . . . . . . . . . . . . . . . 32
5. Cryptographic Calculations . . . . . . . . . . . . . . . . . . 32
5.1. EAP-FAST Authentication Phase 1: Key Derivations . . . . . 32
5.2. Intermediate Compound Key Derivations . . . . . . . . . . 33
5.3. Computing the Compound MAC . . . . . . . . . . . . . . . . 34
5.4. EAP Master Session Key Generation . . . . . . . . . . . . 35
5.5. T-PRF . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
7. Security Considerations . . . . . . . . . . . . . . . . . . . 37
7.1. Mutual Authentication and Integrity Protection . . . . . . 37
7.2. Method Negotiation . . . . . . . . . . . . . . . . . . . . 38
7.3. Separation of Phase 1 and Phase 2 Servers . . . . . . . . 38
7.4. Mitigation of Known Vulnerabilities and Protocol
Deficiencies . . . . . . . . . . . . . . . . . . . . . . . 39
7.4.1. User Identity Protection and Verification . . . . . . 39
7.4.2. Dictionary Attack Resistance . . . . . . . . . . . . . 40
7.4.3. Protection against Man-in-the-Middle Attacks . . . . . 40
7.4.4. PAC Binding to User Identity . . . . . . . . . . . . . 41
7.5. Protecting against Forged Clear Text EAP Packets . . . . . 41
7.6. Server Certificate Validation . . . . . . . . . . . . . . 42
7.7. Tunnel PAC Considerations . . . . . . . . . . . . . . . . 42
7.8. Security Claims . . . . . . . . . . . . . . . . . . . . . 43
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Normative References . . . . . . . . . . . . . . . . . . . 44
9.2. Informative References . . . . . . . . . . . . . . . . . . 45
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 46
A.1. Successful Authentication . . . . . . . . . . . . . . . . 46
A.2. Failed Authentication . . . . . . . . . . . . . . . . . . 47
A.3. Full TLS Handshake using Certificate-based Ciphersuite . . 48
A.4. Client Authentication during Phase 1 with Identity
Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.5. Fragmentation and Reassembly . . . . . . . . . . . . . . . 52
A.6. Sequence of EAP Methods . . . . . . . . . . . . . . . . . 53
A.7. Failed Crypto-Binding . . . . . . . . . . . . . . . . . . 56
A.8. Sequence of EAP Method with Vendor-Specific TLV
Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 57
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 60
B.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 60
B.2. Crypto-Binding MIC . . . . . . . . . . . . . . . . . . . . 621. Introduction ✨
okay so network access needs auth that's easy for users and easy to deploy 🌈 that means strong mutual authentication that still works with weaker user credentials. This doc defines an EAP method that first builds a TLS tunnel using TLS 1.0 [RFC2246], TLS 1.1 [RFC4346], or a successor version of TLS, always using the latest version both parties support 🔒. After the tunnel is up, the two sides trade type, length, and value (TLV) objects to do the rest of the auth 💅
EAP-FAST also supports the TLS extension from [RFC4507], which lets the tunnel get re-established fast without the server keeping per-session state 🦋. [EAP-PROV] describes EAP-FAST-based mechanisms for provisioning the credential behind that extension, which is called a Protected Access Credential (PAC) 🎀
EAP-FAST's design goals were:
- Mutual authentication: the EAP server has to be able to verify the peer's identity and authenticity, and the peer has to be able to verify the EAP server's authenticity too 🫶
- Immunity to passive dictionary attacks: lots of auth protocols make the peer give up a password (in cleartext or hashed) to the EAP server 😭. At the very least, the weak credential, like a password, has to be safe from eavesdroppers.
- Immunity to man-in-the-middle (MitM) attacks: when setting up a mutually authenticated protected tunnel, the protocol has to stop adversaries from sneaking info into the convo between peer and server 👀
- Flexibility to support most password authentication interfaces: there are a LOT of password interfaces out there, like Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), Lightweight Directory Access Protocol (LDAP), One-Time Password (OTP), and more 🍓. The protocol has to support them seamlessly.
- Efficiency: especially on wireless, peers have limited computing and power, so the protocol has to keep network access computationally lightweight 🔋
With those main goals set, there are also some secondary design criteria 💖
- Flexibility to extend communications inside the tunnel: as network infrastructure gets more complicated, the need for authentication, authorization, and accounting keeps evolving 📈. For example, several existing auth protocols might be needed to get mutual authentication. Different protected conversations might also be needed to get the right authorization once a peer has authenticated successfully.
- Minimize the authentication server's per-user authentication state: big deployments usually have lots of servers acting as auth servers for lots of peers 🧚. It's also really nice when a peer can use the same shared secret to secure a tunnel, kind of like how it uses a username and password to get onto the network. So the protocol has to let peers use a single strong shared secret while servers keep the per-user and per-device state they cache and manage to a minimum 👑
1.1. Specification Requirements
here's the official key-word bit 📜. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
1.2. Terminology
a lot of the terminology here comes from [RFC3748], and there are a few extra terms defined below 🌸
Protected Access Credential (PAC)
Credentials handed to a peer for future optimized network authentication 🔑. A PAC has, at most, three components: a shared secret, an opaque element, and optionally other information. The shared secret component is the pre-shared key between the peer and the authentication server. The opaque part is given to the peer and gets presented to the authentication server when the peer wants access to network resources. A PAC may also optionally include other information the peer might find useful. The opaque part of the PAC is the same type of data as the ticket in [RFC4507], and the shared secret is used to derive the TLS master secret 🎀
2. Protocol Overview ✨
okay so EAP-FAST is an authentication protocol that's basically giving EAP-TLS [RFC2716] 💅 It does mutual authentication and sets up cryptographic context by using the TLS handshake protocol 🔐 The extra slay is that it lets the established TLS tunnel get reused for more authentication exchanges. It uses TLVs to carry out those inner authentication exchanges 🎀 The tunnel then protects weaker inner methods (the ones that might be password-based 👀) and carries the results of the authentication back.
EAP-FAST uses the TLS enhancements in [RFC4507] to get an optimized TLS tunnel session resume while keeping server state minimal 🦋 The secret key is called the Protected Access Credential key (or PAC-Key), and it's what mutually authenticates the peer and the server when securing a tunnel 🔑 The ticket is called the Protected Access Credential opaque data (or PAC-Opaque) 🎟️ The secret key and ticket used to establish the tunnel can be provisioned through mechanisms that don't involve the TLS handshake. It is RECOMMENDED that implementations support the capability to distribute the ticket and secret key within the EAP-FAST tunnel as specified in [EAP-PROV] ✨
The EAP-FAST conversation is used to establish or resume an existing session, typically to set up network connectivity between a peer and the network. When EAP-FAST runs successfully, both the EAP peer and the EAP server derive strong session key material 🔥 That key material can then be passed to the network access server (NAS) so it can be used to set up a link layer security association 🌸
2.1. Architectural Model
Here's the network architectural model for EAP-FAST usage 🧚
+----------+ +----------+ +----------+ +----------+
| | | | | | | Inner |
| Peer |<---->| Authen- |<---->| EAP-FAST |<---->| Method |
| | | ticator | | server | | server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
EAP-FAST Architectural ModelThese entities are logical entities, and they may or may not be separate network components 🫶 For example, the EAP-FAST server and the inner method server might be one single entity. The authenticator and the EAP-FAST server might be one single entity too. Or the authenticator, EAP-FAST server, and inner method server might all be squished into one physical device 💜 Typical 802.11 deployments put the Authenticator in an access point (AP), while a Radius server may provide the EAP-FAST and inner method server components 📡 The diagram shows how the jobs get divided up in a general way and how a distributed system might be built. Real systems might be realized more simply, though 🙈 The security considerations Section 7.3 provides an additional discussion of the implications of separating the EAP-FAST server from the inner method server. Don't skip that one, bestie 😭
2.2. Protocol Layering Model
EAP-FAST packets are encapsulated within EAP, and EAP in turn needs a carrier protocol for transport 🎀 EAP-FAST packets encapsulate TLS, and that TLS then encapsulates the user authentication information. So EAP-FAST messaging can be described as a layered model, where each layer wraps the layer above it 🍓 Here's how the protocols stack up:
+---------------------------------------------------------------+
| Inner EAP Method | Other TLV information |
|---------------------------------------------------------------|
| TLV Encapsulation (TLVs) |
|---------------------------------------------------------------|
| TLS |
|---------------------------------------------------------------|
| EAP-FAST |
|---------------------------------------------------------------|
| EAP |
|---------------------------------------------------------------|
| Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.) |
+---------------------------------------------------------------+
Protocol Layering ModelThe TLV layer is a payload made of Type-Length-Value (TLV) Objects, which are defined in Section 4.2 💖 TLV objects are used to carry arbitrary parameters between an EAP peer and an EAP server. All conversations in the EAP-FAST protected tunnel must be encapsulated in a TLV layer, no exceptions 🚫
There are already methods for encapsulating EAP within carrier protocols, so you don't have to invent them. For example, IEEE 802.1X [IEEE.802-1X.2004] 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-FAST server 🦋
3. EAP-FAST Protocol 💅
EAP-FAST authentication happens in two phases ✨ In the first phase, EAP-FAST uses the TLS handshake to provide an authenticated key exchange and to set up a protected tunnel. Once the tunnel is up, the second phase begins, with the peer and server having further conversations to establish the required authentication and authorization policies 🔐 The operation of the protocol, including Phase 1 and Phase 2, is what this section is all about. The format of EAP-FAST messages is in Section 4, and the cryptographic calculations are in Section 5 🤓
3.1. Version Negotiation
EAP-FAST packets contain a 3-bit version field, which follows the TLS Flags field. This lets EAP-FAST implementations stay backward compatible with previous versions of the protocol 🔄 This specification documents the EAP-FAST version 1 protocol, and implementations of this specification MUST use a version field set to 1. No skipping this, periodt 💀
Version negotiation goes like this:
- In the first EAP-Request sent with EAP type=EAP-FAST, the EAP server must set the version field to the highest supported version number 👑
- If the EAP peer supports this version of the protocol, it MUST respond with an EAP-Response of EAP type=EAP-FAST, and the version number proposed by the EAP-FAST server.
- If the EAP-FAST peer does not support this version, it responds with an EAP-Response of EAP type=EAP-FAST and the highest supported version number.
- If the EAP-FAST server does not support the version number proposed by the EAP-FAST peer, it terminates the conversation. Otherwise the EAP-FAST conversation continues.
The version negotiation procedure guarantees that the EAP-FAST peer and server will agree on the latest version that both parties support 🎉 If version negotiation fails, then EAP-FAST just won't be possible, and another mutually acceptable EAP method will need to be negotiated if authentication is going to proceed. Rip, but that's life 😭
The EAP-FAST version is not protected by TLS, so it can be modified in transit 🚨 To detect a modification of the EAP-FAST version, the peers MUST exchange the EAP-FAST version number received during version negotiation using the Crypto-Binding TLV described in Section 4.2.8. 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 EAP-FAST version negotiation. Double-checking is giving main character energy 💜
3.2. EAP-FAST Authentication Phase 1: Tunnel Establishment
EAP-FAST is based on the TLS handshake [RFC2246] to set up an authenticated and protected tunnel 🦋 The TLS version offered by the peer and server MUST be TLS v1.0 or later. This version of the EAP-FAST implementation MUST support the following TLS ciphersuites:
TLS_RSA_WITH_RC4_128_SHATLS_RSA_WITH_AES_128_CBC_SHA[RFC3268]TLS_DHE_RSA_WITH_AES_128_CBC_SHA[RFC3268]
Other ciphersuites MAY be supported 🌈 It is RECOMMENDED that anonymous ciphersuites, such as TLS_DH_anon_WITH_AES_128_CBC_SHA, only be used in the context of the provisioning described in [EAP-PROV]. Care must be taken to address potential man-in-the-middle attacks when ciphersuites that do not provide authenticated tunnel establishment are used. Yikes, that's a whole vibe 😬 During the EAP-FAST Phase 1 conversation, the EAP-FAST endpoints MAY negotiate TLS compression 🔥
The EAP server kicks off the EAP-FAST conversation with an EAP request containing an EAP-FAST/Start packet 🚀 This packet includes a set Start (S) bit, the EAP-FAST version as specified in Section 3.1, and an authority identity. The TLS payload in the initial packet is empty. The authority identity (A-ID) 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 EAP-FAST, the conversation continues with the peer sending an EAP-Response packet with EAP type of EAP-FAST, with the Start (S) bit clear and the version as specified in Section 3.1. This message encapsulates one or more TLS records containing the TLS handshake messages. If the EAP-FAST version negotiation is successful, the EAP-FAST conversation keeps going until the EAP server and EAP peer are ready to enter Phase 2 🙌 When the full TLS handshake is performed, the first payload of EAP-FAST Phase 2 MAY be sent along with the server-finished handshake message, which cuts down on the number of round trips ⭐
After the TLS session is established, another EAP exchange MAY occur within the tunnel to authenticate the EAP peer 💖 EAP-FAST implementations MUST support client authentication during tunnel establishment using the TLS ciphersuites specified in Section 3.2. EAP-FAST implementations SHOULD also support immediate renegotiation of a TLS session, which starts a new handshake message exchange under the protection of the current ciphersuite. This is what allows the peer's identity to be protected 🥹 Note that the EAP peer does not need to authenticate as part of the TLS exchange, since it can alternatively be authenticated through additional EAP exchanges carried out in Phase 2.
The EAP-FAST tunnel protects peer identity information from being disclosed outside the tunnel 🙈 Implementations that want to provide identity privacy for the peer identity must carefully consider what information is disclosed outside the tunnel. Privacy is not a vibe you can wing 🔒
The following sections describe resuming a TLS session based on server-side or client-side state 🧚
3.2.1. TLS Session Resume Using Server State
EAP-FAST session resumption works the same way TLS session resume works 🌸 To support session resumption, the server and peer must, at a minimum, cache the SessionID, master secret, and ciphersuite. The peer tries to resume a session by including a valid SessionID from a previous handshake in its ClientHello message. If the server finds a match for the SessionID and is willing to establish a new connection using that session state, the server responds with the same SessionID and goes on with the EAP-FAST Authentication Phase 1 tunnel establishment based on a TLS abbreviated handshake. After a successful conclusion of the EAP-FAST Authentication Phase 1 conversation, the conversation continues on to Phase 2 ✨
3.2.2. TLS Session Resume Using a PAC ✨
okay so bestie, EAP-FAST can resume sessions using client-side state, following the ideas in [RFC4507] 🎀. BUT this version doesn't hand out tickets with the SessionTicket handshake message 🙈. Instead it uses a ticket called a Protected Access Credential (PAC), which is described in [EAP-PROV] 💖. Implementations are allowed to provision the PAC in other ways too, like manual config 🌸. Because this PAC is for setting up the TLS Tunnel, we call it specifically the Tunnel PAC 🧚. The Tunnel PAC is a security credential that the EAP server gives to a peer, and it has three parts:
- PAC-Key: a 32-octet key the peer uses to set up the EAP-FAST Phase 1 tunnel 🔑. It's used to derive the TLS premaster secret, as described in Section 5.1 ✨. The EAP server randomly generates it so it has strong entropy, and it's 32 octets long 💅. The PAC-Key is a secret and it MUST be treated accordingly 😭. For example, since the PAC-Key is its own component the server gives out to set up a secure tunnel, the server may deliver it over a secure channel, and the peer MUST store it securely 🫶.
- PAC-Opaque: a variable-length field sent to the EAP server during Phase 1 tunnel setup 🦋. Only the EAP server can interpret it, to pull out the info the server needs to validate the peer's identity and authentication 👑. For example, the PAC-Opaque includes the PAC-Key and may contain the PAC's peer identity 💜. Its format and contents depend on the PAC issuing server 🌈. The PAC-Opaque may be sent in the clear, so an attacker MUST NOT be able to gain useful information from the PAC-Opaque itself 💀. The server issuing it must make sure it's protected with strong cryptographic keys and algorithms 🔥.
- PAC-Info: a variable-length field used to give, at minimum, the authority identity of the PAC issuer ⭐. Other useful-but-not-mandatory info, like the PAC-Key lifetime, may also be passed to the peer by the PAC issuing server during PAC provisioning or refreshment 🍓.
Using the PAC is based on the SessionTicket extension from [RFC4507] 🧚. The EAP server kicks off the EAP-FAST conversation as normal ✨. Once the peer gets the A-ID from the server, it checks whether it already has a valid PAC-Key and PAC-Opaque for that server 👀. If it does, it grabs the PAC-Opaque and puts it in the SessionTicket extension in the ClientHello 💅. It is RECOMMENDED in EAP-FAST that the peer include an empty Session ID in a ClientHello containing a PAC-Opaque 🎀. EAP-FAST doesn't currently support the SessionTicket Handshake message, so an empty SessionTicket extension MUST NOT be included in the ClientHello 🙅. If the PAC-Opaque in the SessionTicket extension is valid and the EAP server allows the abbreviated TLS handshake, the server picks the ciphersuite that's allowed, using info from inside the PAC, and finishes with the abbreviated TLS handshake 🦋. If the server gets a Session ID and a PAC-Opaque in the SessionTicket extension in a ClientHello, it SHOULD put the same Session ID in the ServerHello when it's resuming a session based on the PAC-Opaque 🌸. The conversation then follows [RFC4507] until the handshake completes or a fatal error happens 🫶. After the abbreviated handshake completes, the peer and server are ready to start Phase 2 💖. Note that when a PAC is used, the TLS master secret is calculated from the PAC-Key, client random, and server random, as described in Section 5.1 🔥.
The specific details for the Tunnel PAC format, provisioning, and security considerations are best described in [EAP-PROV] 📚.
3.2.3. Transition between Abbreviated and Full TLS Handshake ✨
If session resumption based on server-side or client-side state fails, the server can gracefully fall back to a full TLS handshake 🦋. If the ServerHello the peer gets back has an empty Session ID, or a Session ID that's different from the one in the ClientHello, the server may be falling back to a full handshake 👀. The peer can tell whether the server intends a full or abbreviated handshake by checking the next TLS handshake messages in the server's response to the ClientHello 💅. If ChangeCipherSpec follows the ServerHello in response to the ClientHello, then the server accepted the session resumption and intends an abbreviated handshake 🎀. Otherwise, the server intends a full TLS handshake 🌸. A peer can request a new PAC be provisioned after the full TLS handshake and mutual authentication of the peer and server 🧚. To make fallback to a full handshake easier, the peer SHOULD include ciphersuites that allow for a full handshake and possibly PAC provisioning, so the server can pick one of those if session resumption fails 💖. An example of the transition is shown in Appendix A 📚.
3.3. EAP-FAST Authentication Phase 2: Tunneled Authentication ✨
The second part of EAP-FAST Authentication happens right after Phase 1 finishes successfully 🌈. Phase 2 happens even if both the peer and authenticator were already authenticated in the Phase 1 TLS negotiation 👑. Phase 2 MUST NOT occur if the Phase 1 TLS handshake fails 🙅. Phase 2 is a series of requests and responses wrapped in TLV objects defined in Section 4.2 🫶. Phase 2 MUST always end with a protected termination exchange, described in Section 3.3.2 💅. The TLV exchange may include running zero or more EAP methods inside the protected tunnel, as described in Section 3.3.1 🦋. A server MAY go straight to the protected termination exchange if it doesn't want to request further authentication from the peer 🌸. However, the peer and server must not assume that either will skip inner EAP methods or other TLV exchanges 👀. The peer may have roamed to a network that requires a different authentication policy, or the peer may ask the server to take extra action using the Request-Action TLV 🔥.
3.3.1. EAP Sequences ✨
EAP [RFC3748] doesn't allow multiple authentication methods in a single EAP conversation, to limit vulnerability to man-in-the-middle attacks 🚫. EAP-FAST handles man-in-the-middle attacks by cryptographically protecting the inner EAP exchange and cryptographically binding the inner authentication method(s) to the protected tunnel 🔐. EAP methods run serially, one after another 🧚. This version of EAP-FAST doesn't support starting multiple EAP methods at the same time in parallel 🙈. The methods don't need to be distinct 💖. For example, EAP-TLS could run twice as an inner method, first with machine credentials and then with a second instance using user credentials 🌈.
EAP method messages are carried in EAP-Payload TLVs, defined in Section 4.2.6 📦. If more than one method is going to run in the tunnel, then when a method completes, a server MUST send an Intermediate-Result TLV indicating the result 🎀. The peer MUST respond to the Intermediate-Result TLV indicating its result 🫶. If the result indicates success, the Intermediate-Result TLV MUST be accompanied by a Crypto-Binding TLV 🔥. The Crypto-Binding TLV is discussed further in Section 4.2.8 and Section 5.3 ✨. Intermediate-Result TLVs can be included with other TLVs, such as EAP-Payload TLVs starting a new EAP conversation, or with the Result TLV used in the protected termination exchange 🦋. In the case where only one EAP method is run in the tunnel, the Intermediate-Result TLV MUST NOT be sent with the Result TLV 🙅. In this case, the status of the inner EAP method is represented by the final Result TLV, which also represents the result of the whole EAP-FAST conversation 💅. This keeps things backward compatible with existing implementations 👑.
If both peer and server indicate success, the method is considered complete 🎉. If either indicates failure, the method is considered failed 💀. A failed EAP method does not always mean the overall authentication failed 🌸. If one authentication method fails, the server may try to authenticate the peer with a different method 🧚.
3.3.2. Protected Termination and Acknowledged Result Indication ✨
A successful EAP-FAST Phase 2 conversation MUST always end in a successful Result TLV exchange 💖. An EAP-FAST server may start the Result TLV exchange without starting any EAP conversation in EAP-FAST Phase 2 🦋. After the final Result TLV exchange, the TLS tunnel is terminated and the server sends a clear text EAP-Success or EAP-Failure 🫶. The format of the Result TLV is described in Section 4.2.2 📚.
A server starts a successful protected termination exchange by sending a Result TLV indicating success 🌈. The server may send the Result TLV along with an Intermediate-Result TLV and a Crypto-Binding TLV 🔥. If the peer needs nothing more from the server, it responds with a Result TLV indicating success, accompanied by an Intermediate-Result TLV and Crypto-Binding TLV if necessary 💅. The server then tears down the tunnel and sends a clear text EAP-Success 🎀.
If the peer gets a Result TLV indicating success from the server, but its authentication policies aren't satisfied (for example, it requires a particular authentication mechanism to run, or it wants to request a PAC), it may ask the server for further action using the Request-Action TLV 👀. The Request-Action TLV is sent along with the Result TLV, indicating what EAP Success/Failure result the peer would expect if the requested action isn't granted 💜. The value of the Request-Action TLV indicates 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 receives the Request-Action TLV, it may process the request or ignore it, based on its policy 🌸. If the server ignores the request, it terminates the tunnel and sends the clear text EAP Success or Failure message based on the value of the peer's Result TLV 🙈. If the server honors and processes the request, it continues with the requested action 🔥. The conversation completes with a Result TLV exchange 💖. The Result TLV may be included with the TLV that completes the requested action ✨.
Error handling for Phase 2 is discussed in Section 3.6.2 🫶.
3.4. Determining Peer-Id and Server-Id 🎀
okay so the Peer-Id and Server-Id can be figured out from whatever kinds of credentials got used, either when the EAP-FAST tunnel is being created or when authentication happens 💅
When X.509 certificates are used for peer authentication, the Peer-Id comes from the subject or subjectAltName fields in the peer certificate. As noted in [RFC3280] (updated by [RFC4630]):
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 method is run, then the Peer-Id gets pulled from the inner method 🫶
When the server uses an X.509 certificate to set up the TLS tunnel, the Server-Id gets worked out in a similar way to the Peer-Id. So the subject or subjectAltName field in the server certificate is what defines the Server-Id ✨
3.5. EAP-FAST Session Identifier 🦋
the EAP session identifier is built from the random values that the peer and server each bring to the TLS tunnel setup, which is so cute ngl. The Session-Id is defined like this:
Session-Id = 0x2B || client_random || server_random)
client_random = 32 byte nonce generated by the peer
server_random = 32 byte nonce generated by the server3.6. Error Handling 🙈
EAP-FAST uses the following error handling rules, which are summarized below:
- Errors in the TLS layer are communicated via TLS alert messages in all phases of EAP-FAST.
- The Intermediate-Result TLVs carry success or failure indications of the individual EAP methods in EAP-FAST Phase 2. Errors within the EAP conversation in Phase 2 are expected to be handled by individual EAP methods.
- Violations of the TLV rules are handled using Result TLVs together with Error TLVs.
- Tunnel compromised errors (errors caused by Crypto-Binding failed or missing) are handled using Result TLVs and Error TLVs.
3.6.1. TLS Layer Errors
If the EAP-FAST server detects an error at any point in the TLS Handshake or the TLS layer, the server SHOULD send an EAP-FAST request encapsulating a TLS record containing the appropriate TLS alert message. It does this instead of immediately ending the conversation, so the peer can tell the user what went wrong and maybe restart the conversation 🌸 The peer MUST send an EAP-FAST response to an alert message. The EAP-Response packet sent by the peer may encapsulate a TLS ClientHello handshake message, in which case the EAP-FAST server MAY allow the EAP-FAST conversation to be restarted. Or it MAY contain an EAP-FAST response with a zero-length message, in which case the server MUST terminate the conversation with an EAP-Failure packet. It is up to the EAP-FAST server whether to allow restarts, and if so, how many times the conversation can be restarted. An EAP-FAST Server implementing restart capability SHOULD impose a limit on the number of restarts, so as to protect against denial-of-service attacks 🚨
If the EAP-FAST peer detects an error at any point in the TLS layer, the EAP-FAST peer should send an EAP-FAST response encapsulating a TLS record containing the appropriate TLS alert message. The server may restart the conversation by sending an EAP-FAST request packet encapsulating the TLS HelloRequest handshake message. The peer may allow the EAP-FAST conversation to be restarted, or it may terminate the conversation by sending an EAP-FAST response with an zero-length message 🍓
3.6.2. Phase 2 Errors
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 with the appropriate error code. 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. For errors involving a tunnel compromise, the error-code is Tunnel_Compromise_Error. Upon sending a Result TLV with a fatal Error TLV, the sender terminates the TLS tunnel. Note that a server will still wait for a message from the peer after it sends a failure. However, the server does not need to process the contents of the response message 👀
If a server receives a Result TLV of failure with a fatal Error TLV, it SHOULD send a clear text EAP-Failure. If a peer receives a Result TLV of failure, it MUST respond with a Result TLV indicating failure. If the server has sent a Result TLV of failure, it ignores the peer response, and it SHOULD send a clear text EAP-Failure 💅
3.7. Fragmentation 🧩
A single TLS record may be up to 16384 octets in length, but a TLS message may span multiple TLS records. A TLS certificate message may in principle be as long as 16 MB. That's bigger than the maximum size for a message on most media types, so it is desirable to support fragmentation. Note that in order to protect against reassembly lockup and denial-of-service attacks, it may be desirable for an implementation to set a maximum size for one such group of TLS messages. Since a typical certificate chain is rarely longer than a few thousand octets, and no other field is likely to be anywhere near as long, a reasonable choice of maximum acceptable message length might be 64 KB. That is still a fairly large message packet size, so an EAP-FAST implementation MUST provide its own support for fragmentation and reassembly 🔥
Since EAP is a lock-step protocol, fragmentation support can be added in a simple manner. In EAP, fragments that are lost or damaged in transit will be retransmitted. Sequencing information is provided by the Identifier field in EAP, so there is no need for a fragment offset field 🌈
EAP-FAST fragmentation support is provided through the addition of flag bits within the EAP-Response and EAP-Request packets, as well as a TLS Message Length field of four octets. The flags include the Length included (L), More fragments (M), and EAP-FAST Start (S) bits. The L flag is set to indicate the presence of the four-octet TLS Message Length field, and MUST be set for the first fragment of a fragmented TLS message or set of messages. The M flag is set on all but the last fragment. The S flag is set only within the EAP-FAST start message sent from the EAP server to the peer. The TLS Message Length field is four octets, and provides the total length of the TLS message or set of messages that is being fragmented. This simplifies buffer allocation 🧚
When an EAP-FAST peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type of EAP-FAST and no data. This serves as a fragment ACK. The EAP server must wait until it receives the EAP-Response before sending another fragment. In order to prevent errors in processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer must include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value 🔁
Similarly, when the EAP-FAST server receives an EAP-Response with the M bit set, it must respond with an EAP-Request with EAP-Type of EAP-FAST and no data. This serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. In order to prevent errors in the processing of fragments, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP-Response 💜
4. Message Formats 🦋
The following sections describe the message formats used in EAP-FAST. The fields are transmitted from left to right in network byte order.
4.1. EAP-FAST Message Format 🌸
A summary of the EAP-FAST 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 | Data... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code
The code field is one octet in length, 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, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception 💅
Type
43 for EAP-FAST ✨
Flags
0 1 2 3 4
+-+-+-+-+-+
|L M S R R|
+-+-+-+-+-+L: Length included; set to indicate the presence of the four-octet Message Length fieldM: More fragments; set on all but the last fragmentS: EAP-FAST start; set in an EAP-FAST Start messageR: Reserved (must be zero)
Ver
This field contains the version of the protocol. This document describes version 1 (001 in binary) of EAP-FAST 🌈
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 that may be fragmented over the data fields of multiple packets 🧁
Data
In the case of an EAP-FAST Start request (i.e., when the S bit is set), the Data field consists of the A-ID described in Section 4.1.1. In other cases, when the Data field is present, it consists of an encapsulated TLS packet in TLS record format. An EAP-FAST packet with Flags and Version fields, but with zero-length data field, is used to indicate EAP-FAST acknowledgement for either a fragmented message, a TLS Alert message, or a TLS Finished message 🫶
4.1.1. Authority ID Data ✨
Okay, bestie, this is the Authority ID TLV, and it's giving "hint" energy. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x04) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 🎀: two octets, set to
0x0004for Authority ID. - Length 🧁: two octets, holding the length of the ID field in octets.
- ID 🔮: a hint of the server's identity. It should be unique across the deployment, so no two servers in the same setup get the same vibe 💅.
4.2. EAP-FAST TLV Format and Support 🦋
Okay, so TLVs are standard Type-Length-Value objects, and they're basically the secret notes passed around inside the protected TLS tunnel between the EAP peer and the EAP server. They can carry arbitrary parameters, which is so iconic 🫶.
The peer doesn't have to implement every TLV the server supports, so the TLV system has a built-in way to check. The server can use the NAK TLV to find out whether the peer supports a given TLV 🕵️♀️. The mandatory bit tells you whether support is required. If the peer or server doesn't support a mandatory TLV, it MUST send a NAK TLV in the response, and every other TLV in that message MUST be ignored. If an EAP peer or server runs into an unsupported TLV that's marked optional, it can just ignore it, no drama 🙄. It MUST NOT send a NAK TLV for a TLV that isn't marked mandatory.
Also, a peer or server might support a TLV with the mandatory bit set and still not understand what's inside. What it does next is up to the individual TLV's spec, not me 🤷♀️.
Implementations that follow this spec MUST support TLV exchanges, and they MUST handle the mandatory and optional settings on each TLV. They MUST also support these TLVs, no exceptions 💖:
- Result TLV
- NAK TLV
- Error TLV
- EAP-Payload TLV
- Intermediate-Result TLV
- Crypto-Binding TLV
- Request-Action TLV
4.2.1. General TLV Format 🌸
Here's how every TLV is built. The fields go left to right, so read it like a book 📖.
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- M 🔥:
0means Optional TLV, and1means Mandatory TLV. - R 🫧: Reserved, set to zero (
0). - TLV Type 🗂️: a 14-bit field for the TLV type. These are the allocated types right now:
0 Reserved
1 Reserved
2 Reserved
3 Result TLV (Section 4.2.2)
4 NAK TLV (Section 4.2.3)
5 Error TLV (Section 4.2.4)
7 Vendor-Specific TLV (Section 4.2.5)
9 EAP-Payload TLV (Section 4.2.6)
10 Intermediate-Result TLV (Section 4.2.7)
11 PAC TLV [EAP-PROV]
12 Crypto-Binding TLV (Section 4.2.8)
18 Server-Trusted-Root TLV [EAP-PROV]
19 Request-Action TLV (Section 4.2.9)
20 PKCS#7 TLV [EAP-PROV]- Length 📏: the length of the Value field, in octets.
- Value 💌: the TLV's actual contents.
4.2.2. Result TLV 🏆
The Result TLV is how you get acknowledged success and failure messages for protected termination inside EAP-FAST, which is honestly the cleanest way to end a convo 🎀. If the Status field has a value that isn't one of the known ones, the peer or EAP server MUST treat it as a fatal error of Unexpected_TLVs_Exchanged. You can read more about how this TLV behaves in Section 3.3.2 and Section 3.6.2 🧐. A Result TLV that signals failure MUST NOT come with any of these: NAK, EAP-Payload TLV, or Crypto-Binding TLV. Not in this house 🙅♀️.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- M 💪: Mandatory, set to one (
1). - R 🫧: Reserved, set to zero (
0). - TLV Type 🏷️:
3for Result TLV. - Length 📏:
2. - Status ✅: two octets. The values are:
1Success 🎉2Failure 💀
4.2.3. NAK TLV 🙈
The NAK TLV lets one peer tell the other which TLVs it doesn't support 🫣. An EAP-FAST packet can hold 0 or more NAK TLVs. A NAK TLV should not come with other TLVs. A NAK TLV MUST NOT be sent in response to a message that has a Result TLV. Instead, you send a Result TLV of failure, plus an Error TLV of Unexpected_TLVs_Exchanged. Scandalous, I know 😤.
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 🏷️:
4for NAK TLV. - Length 📏:
>=6. - Vendor-Id 🏢: four octets, holding the Vendor-Id of the TLV that wasn't supported. The high-order octet is
0, and the low-order three octets are the Structure of Management Information (SMI) Network Management Private Enterprise Code of the Vendor, in network byte order. The Vendor-Id field MUST be zero for any TLV that isn't a Vendor-Specific TLV 🙅♀️. - NAK-Type 🔢: two octets, holding the Type of the TLV that wasn't supported. A TLV of this Type MUST have been included in the previous packet 👀.
- TLVs 🧩: a list of zero or more TLVs. Each one MUST NOT have the mandatory bit set. These optional TLVs are there for future extensibility, so they can explain why the offending TLV was judged unsupported 🌈.
4.2.4. Error TLV 🚨
The Error TLV is how an EAP peer or server tells the other party that something went wrong 😬. An EAP-FAST packet can hold 0 or more Error TLVs. The Error-Code field says what kind of error it is. Error Codes 1-999 are successful outcomes (informative messages), 1000-1999 are warnings, and 2000-2999 are fatal errors 💅. A fatal Error TLV MUST come with a Result TLV that says failure, and the conversation MUST be terminated as described in Section 3.6.2. It's the end of the line, babe 💀.
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 🏷️:
5for Error TLV. - Length 📏:
4. - Error-Code ❌: four octets. The currently defined values are:
2001Tunnel_Compromise_Error 😱2002Unexpected_TLVs_Exchanged 🫠
4.2.5. Vendor-Specific TLV 🏢✨
The Vendor-Specific TLV is there so vendors can add their own extended attributes that aren't meant for general use 🧑💻. One Vendor-Specific TLV can hold one or more TLVs, called Vendor TLVs. The TLV type of a Vendor TLV is set by the vendor. Every Vendor TLV inside a single Vendor-Specific TLV belongs to the same vendor. A single message can have several Vendor-Specific TLVs from different vendors 🤝.
Vendor TLVs can be optional or mandatory. Vendor TLVs sent alongside Result TLVs MUST be marked as optional 🙏.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- M 💪:
0or1. - R 🫧: Reserved, set to zero (
0). - TLV Type 🏷️:
7for Vendor Specific TLV. - Length 📏:
4 + cumulative length of all included Vendor TLVs. - Vendor-Id 🏢: four octets, holding 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 Code of the Vendor, in network byte order. - Vendor TLVs 🧃: this field has an indefinite length. It holds vendor-specific TLVs, in whatever format the vendor defined.
4.2.6. EAP-Payload TLV 🎁
okay so the EAP-Payload TLV is how we hitch an EAP request or response onto other TLVs 🚗💖 it wraps up an encapsulated EAP packet along with a list of optional TLVs. Those optional TLVs are there for future extensibility, so they can drop hints about the current EAP authentication 🔮 and only one EAP-Payload TLV is allowed in a message, periodt ✨ 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 (1)
- R 🫧: Reserved, set to zero (0)
- TLV Type 🏷️: 9 for EAP-Payload TLV
- Length 📏: length of embedded EAP packet + cumulative length of additional TLVs
- EAP packet 📦: this field holds 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 field holds a list of zero or more 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.7. Intermediate-Result TLV 🌟
the Intermediate-Result TLV is what makes acknowledged intermediate Success and Failure messages possible between multiple inner EAP methods within EAP 🙌 and a success one MUST be accompanied by a Crypto-Binding TLV, no exceptions 🔒 any optional TLVs riding along are there for future extensibility, to give hints about the current result. Here's the shape:
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 (1)
- R 🫧: Reserved, set to zero (0)
- TLV Type 🏷️: 10 for Intermediate-Result TLV
- Length 📏: 2 + cumulative length of the embedded associated TLVs
- Status ✅❌: the Status field is two octets. Values include:
1Success 🎉2Failure 💔
- 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.8. Crypto-Binding TLV 🔐
this one is the big proof-of-vibes TLV 💅 it shows that both the peer and the server took part in the tunnel establishment and the sequence of authentications. It also verifies the EAP-FAST version that got negotiated before the TLS tunnel was set up, see Section 3.1 🕵️♀️
The Crypto-Binding TLV MUST be included with the Intermediate-Result TLV to do Cryptographic Binding after each successful EAP method in a sequence of EAP methods. It can also be issued at other times 🤷♀️
The Crypto-Binding TLV is only valid if all of these checks pass:
- The Crypto-Binding TLV version is supported
- The MAC verifies correctly
- The received version in the Crypto-Binding TLV matches the version sent by the receiver during the EAP version negotiation
- The subtype is set to the correct value
If any of those checks fail, the TLV is invalid 🚫 and an invalid Crypto-Binding TLV is a fatal error, handled as described in Section 3.6.2. Yikes 😭
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. | Sub-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- M 💪: Mandatory, set to (1)
- R 🫧: Reserved, set to zero (0)
- TLV Type 🏷️: 12 for Crypto-Binding TLV
- Length 📏: 56
- Reserved 🫧: Reserved, set to zero (0)
- Version 🔢: a single octet, set to the version of Crypto-Binding TLV the EAP method is using. For an implementation compliant with this version of EAP-FAST, the version number MUST be set to 1.
- Received Version 🛡️: a single octet that MUST be set to the EAP version number received during version negotiation. This field only protects against downgrade attacks, where a version of EAP requiring support for this TLV is required on both sides. Smart, right? 🧠
- Sub-Type 🪪: one octet. Defined values include:
0Binding Request 📨1Binding Response 📬
- Nonce 🎲: 32 octets, a 256-bit nonce that is temporally unique and used for compound MAC key derivation at each end. The nonce in a request MUST have its least significant bit set to 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 1.
- Compound MAC 🧁: 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 5.3.
4.2.9. Request-Action TLV 🙋♀️
the Request-Action TLV MAY be sent by the peer along with a Result TLV in response to a server's successful Result TLV 💖 it lets the peer ask the EAP server to negotiate additional EAP methods or to process TLVs specified in the response packet. The server MAY ignore this TLV, so no drama if it does 🫶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- M 💪: Mandatory set to one (1)
- R 🫧: Reserved, set to zero (0)
- TLV Type 🏷️: 19 for Request-Action TLV
- Length 📏: 2
- Action 🎬: the Action field is two octets. Values include:
- Process-TLV
- Negotiate-EAP
4.3. Table of TLVs 📋
this table is your cheat sheet for which TLVs can show up in which kinds of messages, and how many of each 🗂️ the messages are: Request is an EAP-FAST Request, Response is an EAP-FAST Response, Success is a message containing a successful Result TLV, and Failure is a message containing a failed Result TLV.
Request Response Success Failure TLVs
0-1 0-1 0-1 0-1 Intermediate-Result
0-1 0-1 0 0 EAP-Payload
0-1 0-1 1 1 Result
0-1 0-1 0-1 0-1 Crypto-Binding
0+ 0+ 0+ 0+ Error
0+ 0+ 0 0 NAK
0+ 0+ 0+ 0+ Vendor-Specific [NOTE1]
0 0-1 0-1 0-1 Request-Action[NOTE1] Vendor TLVs (included in Vendor-Specific TLVs) sent with a Result TLV MUST be marked as optional. 🏷️ don't skip this one!
the table entries mean the following 👇
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.
5. Cryptographic Calculations 🔑✨
5.1. EAP-FAST Authentication Phase 1: Key Derivations 🗝️
the EAP-FAST Authentication tunnel key is calculated similarly to the TLS key calculation, except there's an extra 40 octets (called the session_key_seed) generated 🧪 that extra seed then gets used in the Session Key calculation during the EAP-FAST Tunneled Authentication conversation.
to generate the key material for the EAP-FAST Authentication tunnel, we use this construction from [RFC4346]:
key_block = PRF(master_secret, "key expansion",
server_random + client_random)where '+' denotes concatenation. 🔗
The PRF function used to generate keying material is defined by [RFC4346]. 🧮
For example, if the EAP-FAST Authentication employs 128-bit RC4 and SHA1, the key_block is 112 octets long and gets partitioned like this 🍰
client_write_MAC_secret[20]
server_write_MAC_secret[20]
client_write_key[16]
server_write_key[16]
client_write_IV[0]
server_write_IV[0]
session_key_seed[40]The session_key_seed is used by the EAP-FAST Authentication Phase 2 conversation for two jobs: cryptographically binding the inner method(s) to the tunnel, and generating the resulting EAP-FAST session keys 💅 the other quantities are used as they're defined in [RFC4346].
The master_secret is generated as specified in TLS, unless a PAC is used to establish the TLS tunnel 🎀 when a PAC is used, the master_secret is calculated from the specified client_random, server_random, and PAC-Key like so:
master_secret = T-PRF(PAC-Key, "PAC to master secret label hash",
server_random + client_random, 48)where T-PRF is described in Section 5.5. 🦋
5.2. Intermediate Compound Key Derivations 🔑
okay so the session_key_seed from EAP-FAST Phase 2 gets used to make an Intermediate Compound Key (IMCK) 🦋 This key checks that the TLS tunnel is still intact after every successful inner authentication, and it also feeds into the MSK and EMSK from [RFC3748] 💜 Quick reminder: the IMCK has to be recalculated after each successful inner EAP method, no skipping!
First up, you build the base compound key, IMCK[n], from the session_key_seed plus any session keys from the n inner EAP methods that worked. Those inner methods might hand back Master Session Keys, MSK1..MSKn, one for each method from 1 through n. An MSK longer than 32 octets gets cut down to 32, and one shorter than 32 gets padded out to 32 with zeros 🌸 If an inner method doesn't make an MSK, its MSKi just becomes 32 zero octets (0x00s). And if an inner method fails, it doesn't get counted at all ✨ Here's how the S-IMCK math goes:
S-IMCK[0] = session_key_seed
For j = 1 to n-1 do
IMCK[j] = T-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
MSK[j], 60)
S-IMCK[j] = first 40 octets of IMCK[j]
CMK[j] = last 20 octets of IMCK[j]T-PRF is explained in Section 5.5 🎀
5.3. Computing the Compound MAC 🧚
okay this part is so important bestie 😭 When an authentication method makes keying material, you get extra protection against man-in-the-middle attacks. The keys from EAP-FAST Phase 1 and Phase 2 are both cryptographically binding, which is giving "same people all the way through" energy 💅 After each successful inner EAP authentication, the EAP MSKs get mixed with key material from Phase 1 to make a compound session key, CMK. That CMK is what calculates the Compound MAC inside the Crypto-Binding TLV from Section 4.2.8 🔥 While the Compound-MAC is being calculated, the MAC field gets filled with zeros, no exceptions 🙈
Here's the computation:
CMK = CMK[j]
Compound-MAC = HMAC-SHA1( CMK, Crypto-Binding TLV )where j is the number of the last successfully executed inner EAP method.
5.4. EAP Master Session Key Generation 👑
EAP-FAST authentication makes sure the master session key (MSK) and Extended Master Session Key (EMSK) coming out of the EAP method are the result of every authentication conversation, because it builds an Intermediate Compound Key (IMCK) 💖 Both the peer and the server derive the IMCK together, as described in Section 5.2, by combining the MSKs from the inner EAP methods with key material from EAP-FAST Phase 1 ✨ The final MSK and EMSK come out of the IMCKn key hierarchy like this:
MSK = T-PRF(S-IMCK[j], "Session Key Generating Function", 64)
EMSK = T-PRF(S-IMCK[j],
"Extended Session Key Generating Function", 64)where j is the number of the last successfully executed inner EAP method.
The EMSK usually stays between the EAP-FAST peer and server only 🤫 It doesn't get handed to any third party. Deriving extra keys and getting them to a third party is out of scope for this document, so that's a different story 🌈
If no EAP methods were negotiated inside the tunnel, or none of them finished successfully, the MSK and EMSK are generated straight from the session_key_seed. In other words, S-IMCK = session_key_seed 🧁
5.5. T-PRF 🌸
EAP-FAST uses this PRF prototype and definition:
T-PRF = F(key, label, seed, outputlength)The label is supposed to be a unique label for each different use of the T-PRF 🦋 The outputlength parameter is a two-octet value stored in big endian order. Also, the seed is allowed to be optional, and it can be left out completely, like in the MSK derivation from Section 5.4 💅
To make however many outputlength octets of key material you need, the T-PRF works like this:
S = label + 0x00 + seed
T-PRF output = T1 + T2 + T3 + ... + Tn
T1 = HMAC-SHA1 (key, S + outputlength + 0x01)
T2 = HMAC-SHA1 (key, T1 + S + outputlength + 0x02)
T3 = HMAC-SHA1 (key, T2 + S + outputlength + 0x03)
Tn = HMAC-SHA1 (key, Tn-1 + S + outputlength + 0xnn)Here '+' means concatenation 🎀 Every Ti gives you 20 octets of keying material, and the last Tn can be cut short to fit whatever length outputlength asks for ✨
6. IANA Considerations 📋
This section gives the Internet Assigned Numbers Authority (IANA) its marching orders for registering values related to the EAP-FAST protocol, following BCP 26 and [RFC2434] 💜
EAP-FAST already got the EAP Method Type number 43, so it's officially claimed 👑
The document sets up a registry for EAP-FAST TLV types. These can be handed out through Specification Required, as defined in [RFC2434] 🌈 Section 4.2 lists the TLV types that fill the registry at the start. Here's a quick summary of the EAP-FAST TLV types:
0 Reserved
1 Reserved
2 Reserved
3 Result TLV
4 NAK TLV
5 Error TLV
7 Vendor-Specific TLV
9 EAP-Payload TLV
10 Intermediate-Result TLV
11 PAC TLV [EAP-PROV]
12 Crypto-Binding TLV
18 Server-Trusted-Root TLV [EAP-PROV]
19 Request-Action TLV
20 PKCS#7 TLV [EAP-PROV]The Error-TLV from Section 4.2.4 needs an error-code. EAP-FAST Error-TLV error-codes are handed out on a Specification Required basis, as defined in [RFC2434]. The starting list of error codes looks like this:
2001 Tunnel_Compromise_Error
2002 Unexpected_TLVs_ExchangedThe Request-Action TLV from Section 4.2.9 carries an action code, which is also assigned on a Specification Required basis, as defined in [RFC2434] 🔥 The first actions defined are:
1 Process-TLV
2 Negotiate-EAPThe different values under Vendor-Specific TLV are assigned by Private Use, so IANA doesn't need to assign them 🫶
7. Security Considerations 🚨
okay, security time, and I'm not playing 💀 EAP-FAST is designed with wireless media in mind, and wireless media is basically built for eavesdropping. On wired media, an attacker has to physically get access to the wire. With wireless, anyone can capture what's being sent over the air, which makes passive attacks super easy 😭 So physical security can't be assumed, and the vulnerabilities are way bigger. The threat model used to evaluate EAP-FAST's security is defined in [RFC3748] 🔐
7.1. Mutual Authentication and Integrity Protection 🫶
EAP-FAST as a whole gives you message and integrity protection by setting up a secure tunnel to protect the authentication method(s) 💖 TLS defines the confidentiality and integrity protection, and it gives you the same security strength TLS gets when it uses a strong, high-entropy shared master secret ✨ The integrity of the key-generating authentication methods run inside the EAP-FAST tunnel gets checked through the Crypto-Binding TLV calculation. That makes sure the tunnel endpoints are the same as the inner method endpoints, which is so iconic 👑
The Result TLV is protected, and it carries the real Success or Failure of EAP-FAST, so it should be used as the indicator of success or failure. But here's the twist: EAP has to finish with a clear text EAP Success or Failure, so a peer will also get a clear text EAP Success or Failure 🙃 The clear text one has to match what came in the Result TLV. If a clear text EAP Success or Failure doesn't match the status sent in the protected Result TLV, the peer SHOULD silently discard it 🙈
7.2. Method Negotiation 🦋
Just like with any negotiated EAP protocol, NAK packets used to suggest an alternate authentication method are sent unprotected, so they can be spoofed 😱 During unprotected EAP method negotiation, an attacker can inject NAK packets as active attacks to push things down to a weaker form of authentication, like EAP-MD5 (which only gives one-way authentication and doesn't derive a key) 💀 Both the peer and the server should have a method selection policy that stops them from negotiating down to weaker methods. Inner method negotiation is protected, though, because it runs inside the mutually authenticated TLS tunnel that got set up 🛡️ Picking EAP-FAST as your authentication method doesn't limit which inner authentication methods you can use, so EAP-FAST should be selected whenever it's available 🌸
An attacker can't easily tell which inner EAP method is being used, except maybe through traffic analysis 👀 It's also important that peer implementations limit how credentials get used with a server that isn't authenticated or authorized 🔥
7.3. Separation of Phase 1 and Phase 2 Servers 🚫
Splitting the EAP-FAST Phase 1 conversation from the Phase 2 conversation is not recommended 🙅♀️ If the Phase 1 conversation ends at a different server than the Phase 2 one, that can open up vulnerabilities when there's no proper trust relationship and no protection for the protocol between the two servers. Some of the vulnerabilities are:
- Loss of identity protection
- Offline dictionary attacks
- Lack of policy enforcement
There can be situations where a trust relationship does exist between the Phase 1 and Phase 2 servers, like on a campus or between two offices in the same company. In those cases, there's no danger in revealing the peer's inner identity and credentials to entities sitting between the two servers. So a proxy solution without end-to-end protection of EAP-FAST MAY be used 🧚 Even so, the EAP-FAST encrypting/decrypting gateway SHOULD, at a minimum, support IPsec or something similar, so the part of the conversation between the gateway and the EAP server stays confidential 🫶
7.4. Mitigation of Known Vulnerabilities and Protocol Deficiencies ✨
okay bestie, EAP-FAST is literally here to fix the known problems with EAP 💅 By using a shared secret between the peer and server to set up a secured tunnel, it gets you:
- Per packet confidentiality and integrity protection
- User identity protection
- Better support for notification messages
- Protected EAP inner method negotiation
- Sequencing of EAP methods
- Strong mutually derived master session keys
- Acknowledged success/failure indication
- Faster re-authentications through session resumption
- Mitigation of dictionary attacks
- Mitigation of man-in-the-middle attacks
- Mitigation of some denial-of-service attacks
ngl, a denial-of-service attack can still be pulled off with EAP-FAST, same as with lots of other authentication protocols 😭 adversaries can send erroneous traffic to mess up the protocol. This is a problem in many authentication or key agreement protocols, so it's noted for EAP-FAST too, no cap 🙈
EAP-FAST was built with a focus on protected authentication methods that usually rely on weak credentials, like password-based secrets 🔐 So the EAP-FAST Authentication mitigates a bunch of vulnerabilities, like dictionary attacks, by shielding that weak credential-based method. The protection comes from strong cryptographic algorithms in TLS, which give you message confidentiality and integrity. The keys used for that protection rely on strong random challenges from both the peer and the server, plus an established key with strong entropy. Implementations should follow the recommendation in [RFC4086] when generating random numbers 🎀
7.4.1. User Identity Protection and Verification
the initial identity request and response exchange is sent in cleartext, outside the protection of EAP-FAST 🫣 Usually the Network Access Identifier (NAI) [RFC4282] in the identity response is only useful for the realm information, which is what routes the authentication requests to the right EAP server. So the identity response may contain an anonymous identity and just the realm information. In other cases, the identity exchange can be skipped altogether if there are other ways to figure out the destination realm of the request 🧚 In no case should an intermediary place any trust in the identity information in the identity response, because it's unauthenticated and may not have any relevance to the authenticated identity. EAP-FAST implementations should not attempt to compare any identity disclosed in the initial cleartext EAP Identity response packet with those identities authenticated in Phase 2 🚫
Identity request-response exchanges sent after the EAP-FAST tunnel is established are protected from modification and eavesdropping by attackers 🔒
Here's the tea 🍵 TLS client certificates are sent in the clear, so if identity protection is required, the TLS authentication can be re-negotiated after the first server authentication. To do this, the server will usually not request a certificate in the server_hello. Then, after the server_finished message is sent and before EAP-FAST Phase 2, the server MAY send a TLS hello_request. This lets the client do client authentication by sending a client_hello if it wants to, or send a no_renegotiation alert to the server to say it wants to carry on with EAP-FAST Phase 2 instead. Assuming the client allows renegotiation by sending a client_hello, the server responds with server_hello, a certificate and certificate_request messages. The client replies with certificate, client_key_exchange and certificate_verify messages. Since this re-negotiation happens inside the encrypted TLS channel, it doesn't reveal client certificate details, which is so iconic 🦋 It's also possible to do certificate authentication using an EAP method (for example: EAP-TLS) inside the TLS session in EAP-FAST Phase 2, instead of using TLS handshake renegotiation ✨
7.4.2. Dictionary Attack Resistance
EAP-FAST was built with a focus on protected authentication methods that usually rely on weak credentials, like password-based secrets 💜 EAP-FAST mitigates dictionary attacks by setting up a mutually authenticated, encrypted TLS tunnel that gives confidentiality and integrity to protect the weak credential-based authentication method. Main character energy for real 👑
7.4.3. Protection against Man-in-the-Middle Attacks
Letting methods run both with and without the protection of a secure tunnel opens the door to a man-in-the-middle attack 😱 To avoid that, it is recommended to always deploy authentication methods with the protection of EAP-FAST. EAP-FAST protects against man-in-the-middle attacks even when a deployment chooses to run inner EAP methods both with and without EAP-FAST protection, and it prevents this attack in two ways:
- By using the PAC-Key to mutually authenticate the peer and server during EAP-FAST Authentication Phase 1 establishment of a secure tunnel.
- By using the keys generated by the inner authentication method (if the inner methods are key generating) in the crypto-binding exchange and in the generation of the key material exported by the EAP method described in Section 5.
7.4.4. PAC Binding to User Identity
A PAC may be bound to a user identity 🎀 A compliant implementation of EAP-FAST MUST validate that an identity obtained in the PAC-Opaque field matches at minimum one of the identities provided in the EAP-FAST Phase 2 authentication method. This validation gives another binding, making sure the intended peer (based on identity) has successfully completed EAP-FAST Phase 1 and proved their identity in the Phase 2 conversations 🫶
7.5. Protecting against Forged Clear Text EAP Packets
okay this part is sus 🚨 EAP Success and EAP Failure packets are, in general, sent in clear text and can be forged by an attacker without anyone noticing. 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 has succeeded, even though the authenticator never authenticated itself to the peer 💀
By providing message confidentiality and integrity, EAP-FAST protects against these attacks ✨ Once the peer and AS start EAP-FAST Authentication Phase 2, compliant EAP-FAST implementations must silently discard all clear text EAP messages, unless both the EAP-FAST 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.3.2.
The success/failure decisions inside the EAP-FAST tunnel show the final decision of the EAP-FAST authentication conversation. After a success/failure result has been indicated by a protected mechanism, the EAP-FAST peer can process unprotected EAP success and EAP failure messages. However, 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 must send a clear text EAP Success or EAP Failure packet to end the EAP conversation. However, since EAP Success and EAP Failure packets are not retransmitted, the final packet may get lost. While an EAP-FAST protected EAP Success or EAP Failure packet should not be the final packet in an EAP-FAST conversation, it may happen based on the conditions stated above. So an EAP peer should not rely on the unprotected EAP success and failure messages 🥺
7.6. Server Certificate Validation
As part of the TLS negotiation, the server presents a certificate to the peer 📜 The peer MUST verify the validity of the EAP server certificate, and SHOULD also examine the EAP server name presented in the certificate, so it can figure out whether the EAP server can be trusted 🔍 Heads up: when the EAP authentication is remote, the EAP server won't live on the same machine as the authenticator. That means the name in the EAP server's certificate can't be expected to match the intended destination. In this case, a more suitable test might be whether the EAP server's certificate is signed by a CA controlling the intended domain, and whether the authenticator can be authorized by a server in that domain 🌈
7.7. Tunnel PAC Considerations
Since the Tunnel PAC is stored by the peer, the peer needs special care to keep its overall security locked down 🔐 The Tunnel PAC must be securely stored by the peer to prevent theft or forgery of any of its components.
In particular, the peer must securely store the PAC-Key and protect it from disclosure or modification. If the PAC-Key is disclosed, an attacker can establish the EAP-FAST tunnel. However, disclosing the PAC-Key does not reveal the peer or server identity, and it doesn't compromise any other peer's PAC credentials 💖 Modifying the PAC-Key or PAC-Opaque components of the Tunnel PAC may also lead to denial of service, since tunnel establishment will fail 😤
The PAC-Opaque component is the effective TLS ticket extension used to establish the tunnel using the techniques of [RFC4507]. So the security considerations defined by [RFC4507] also apply to the PAC-Opaque 🧠
The PAC-Info may contain information about the Tunnel PAC, such as the identity of the PAC issuer and the Tunnel PAC lifetime, which helps with managing the Tunnel PAC. The PAC-Info should be securely stored by the peer to protect it from disclosure and modification 🫧
7.8. Security Claims 💅
okay so this section is the EAP security claims checklist, and it's basically EAP [RFC3748] asking "so what can you actually do?" 🎀 EAP-FAST's answers are all right here:
Auth. mechanism: Certificate based, shared secret based and
various tunneled authentication mechanisms.
Ciphersuite negotiation: Yes
Mutual authentication: Yes
Integrity protection: Yes, Any method executed within the EAP-FAST
tunnel is integrity protected. The
cleartext EAP headers outside the tunnel are
not integrity protected.
Replay protection: Yes
Confidentiality: Yes
Key derivation: Yes
Key strength: See Note 1 below.
Dictionary attack prot.: Yes
Fast reconnect: Yes
Cryptographic binding: Yes
Session independence: Yes
Fragmentation: Yes
Key Hierarchy: Yes
Channel binding: No, but TLVs could be defined for this.The one that needs a little extra care is integrity protection 👀. Anything running inside the EAP-FAST tunnel is integrity protected, but the cleartext EAP headers outside the tunnel are not. So the tunnel is where the protection lives, and the outside bits don't get that same coverage 🔒.
Notes
- BCP 86 [RFC3766] gives advice on appropriate key sizes. The National Institute for Standards and Technology (NIST) also gives advice on appropriate key sizes in [NIST.SP800-57]. [RFC3766] Section 5 lays out the RSA or DH module and DSA subgroup sizes (in bits) you'd want for a given level of attack resistance (also in bits). Looking at the table below, a 2048-bit RSA key is what you need to get 128-bit equivalent key strength 🧠✨
Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits)
----------------- ----------------- ------------
70 947 129
80 1228 148
90 1553 167
100 1926 186
150 4575 284
200 8719 383
250 14596 4828. Acknowledgements 🫶
EAP-FAST's design and protocol spec come from the ideas and hard work of Pad Jakkahalli, Mark Krischer, Doug Smith, and Glen Zorn of Cisco Systems, Inc. Iconic team, honestly 👑
The TLV processing was inspired by work on the Protected Extensible Authentication Protocol version 2 (PEAPv2), done with Ashwin Palekar, Dan Smith, and Simon Josefsson. Helpful review comments came from Russ Housley, Jari Arkko, Bernard Aboba, Ilan Frenkel, and Jeremy Steiglitz 🌸
9. References 📚
9.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
- [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
- [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 4507, May 2006.
9.2. Informative References
- [EAP-PROV] Cam-Winget, N., "Dynamic Provisioning using EAP-FAST", Work in Progress, January 2007.
- [IEEE.802-1X.2004] "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, December 2004.
- [NIST.SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management", Special Publication 800-57, May 2006.
- [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
- [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
- [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
- [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
- [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
- [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
- [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
- [RFC4630] Housley, R. and S. Santesson, "Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4630, August 2006.
Appendix A. Examples 🧚
In these examples, the version field in EAP Fast is always assumed to be 1. The S, M, and L bits are assumed to be 0 unless otherwise specified 🦋
A.1. Successful Authentication
This walkthrough shows a successful EAP-FAST authentication with optional PAC refreshment. The conversation goes like this 💖
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello with
PAC-Opaque in SessionTicket extension)->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
EAP-Response/EAP-FAST
(TLS change_cipher_spec,
TLS finished) ->
TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
<- EAP Payload TLV
(EAP-Request/EAP-GTC(Challenge))
EAP Payload TLV (EAP-Response/
EAP-GTC(Response with both
user name and password)) ->
optional additional exchanges (new pin mode,
password change etc.) ...
<- Intermediate-Result TLV (Success)
Crypto-Binding TLV (Request)
Intermediate-Result TLV (Success)
Crypto-Binding TLV(Response) ->
<- Result TLV (Success)
[Optional PAC TLV]
Result TLV (Success)
[PAC TLV Acknowledgment] ->
TLS channel torn down
(messages sent in clear text)
<- EAP-SuccessA.2. Failed Authentication
This one shows a failed EAP-FAST authentication because of wrong user credentials. Oof 😭 Here's how that conversation plays out:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello with
PAC-Opaque in SessionTicket extension)->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS change_cipher_spec,
TLS finished)
EAP-Response/EAP-FAST
(TLS change_cipher_spec,
TLS finished) ->
TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
<- EAP Payload TLV (EAP-Request/
EAP-GTC (Challenge))
EAP Payload TLV (EAP-Response/
EAP-GTC (Response with both
user name and password)) ->
<- EAP Payload TLV (EAP-Request/
EAP-GTC (error message))
EAP Payload TLV (EAP-Response/
EAP-GTC (empty data packet to
acknowledge unrecoverable error)) ->
<- Result TLV (Failure)
Result TLV (Failure) ->
TLS channel torn down
(messages sent in clear text)
<- EAP-FailureA.3. Full TLS Handshake using Certificate-based Ciphersuite ✨
okay so, when the abbreviated TLS handshake tries and flops, and EAP-FAST Phase 1 falls back to a full certificate-based TLS handshake 🫶, the convo 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.
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello
with PAC-Opaque extension)->
// Peer sends PAC-Opaque of Tunnel PAC along with a list of
ciphersuites supported. If the server rejects the PAC-
Opaque, it falls through to the full TLS handshake
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// First EAP Payload TLV is piggybacked to 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/Method X)
EAP-Payload-TLV
(EAP-Response/Method X) ->
// Method X exchanges followed by Protected Termination
<- Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result TLV (Success)
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result-TLV (Success) ->
// TLS channel torn down
(messages sent in clear text)
<- EAP-SuccessA.4. Client Authentication during Phase 1 with Identity Privacy 🎀
so here's the vibe: a certificate-based TLS handshake happens inside EAP-FAST Phase 1, and the client wants certificate auth and identity privacy 🙈 💜 Main character energy. Here's how it plays out:
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-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello)->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
(TLS client_key_exchange,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,TLS Hello-Request)
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// TLS Hello-Request is piggybacked to the TLS Finished as
Handshake Data and protected by the TLS tunnel
// Subsequent messages are protected by the TLS Tunnel
EAP-Response/EAP-FAST
(TLS client_hello) ->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
Result TLV (Success))
EAP-Response/EAP-FAST
(Result-TLV (Success)) ->
//TLS channel torn down
(messages sent in clear text)
<- EAP-SuccessA.5. Fragmentation and Reassembly 🧩
last one, and it's a big one 😭 When EAP-FAST fragmentation is needed, the messages get split up and reassembled along the way, and the flow looks like this:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello)->
<- EAP-Request/EAP-FAST
(L=1,M=1, TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,])
EAP-Response/EAP-FAST ->
<- EAP-Request/EAP-FAST
(M=1,
[TLS certificate_request(con't),])
EAP-Response/EAP-FAST ->
<- EAP-Request/EAP-FAST
([TLS certificate_request(con't),]
TLS server_hello_done)
EAP-Response/EAP-FAST,
(L=1,M=1,[TLS certificate,])->
<- EAP-Request/EAP-FAST
EAP-Response/EAP-FAST
([TLS certificate(con't),]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished))->
<- EAP-Request/EAP-FAST
( TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// First EAP Payload TLV is piggybacked to 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/Method X)
EAP-Payload-TLV
(EAP-Response/Method X) ->
// Method X exchanges followed by Protected Termination
<- Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result TLV (Success)
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result-TLV (Success) ->
// TLS channel torn down
(messages sent in clear text)
<- EAP-SuccessA.6. Sequence of EAP Methods ✨
okay so bestie, this one shows what happens when EAP-FAST is negotiated and then you chain a sequence of EAP method X followed by method Y 🦋 the whole convo goes down like this:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello)->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV(
EAP-Request/Identity))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
EAP-Payload-TLV
(EAP-Response/Identity) ->
<- EAP-Payload-TLV
(EAP-Request/Method X)
EAP-Payload-TLV
(EAP-Response/Method X) ->
// Optional additional X Method exchanges...
<- EAP-Payload-TLV
(EAP-Request/Method X)
EAP-Payload-TLV
(EAP-Response/EAP-Type X)->
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Version=1
EAP-FAST Version=1, Nonce,
CompoundMAC),
EAP Payload TLV (EAP-Request/Method Y)
// Next EAP conversation started after successful completion
of previous method X. The Intermediate-Result and Crypto-
Binding TLVs are sent in this packet to minimize round-
trips. In this example, identity request is not sent
before negotiating EAP-Type=Y.
// Compound MAC calculated using Keys generated from
EAP methods X and the TLS tunnel.
Intermediate Result TLV (Success),
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
EAP-Payload-TLV (EAP-Response/Method Y) ->
// Optional additional Y Method exchanges...
<- EAP Payload TLV
(EAP-Request/Method Y)
EAP Payload TLV
(EAP-Response/Method Y) ->
<- Intermediate-Result-TLV (Success),
Crypto-Binding TLV (Version=1
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result TLV (Success)
Intermediate-Result-TLV (Success),
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result-TLV (Success) ->
// Compound MAC calculated using Keys generated from EAP
methods X and Y and the TLS tunnel. Compound Keys
generated using Keys generated from EAP methods X and Y;
and the TLS tunnel.
// TLS channel torn down (messages sent in clear text)
<- EAP-SuccessA.7. Failed Crypto-Binding 💔
these exchanges show a failed crypto-binding validation, so it's the "oof, that didn't work" version 😭 the convo looks like this:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello without
PAC-Opaque extension)->
<- EAP-Request/EAP-FAST
(TLS Server Key Exchange,
TLS Server Hello Done)
EAP-Response/EAP-FAST
(TLS Client Key Exchange,
TLS change_cipher_spec,
TLS finished)->
<- EAP-Request/EAP-FAST
(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 piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
EAP-Payload TLV
(EAP-Response/Identity) ->
<- EAP Payload TLV (EAP-Request/
EAP-MSCHAPV2 (Challenge))
EAP Payload TLV (EAP-Response/
EAP-MSCHAPV2 (Response)) ->
<- EAP Payload TLV (EAP-Request/
EAP-MSCHAPV2 (Success Request))
EAP Payload TLV (EAP-Response/
EAP-MSCHAPV2 (Success Response)) ->
<- Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Result TLV (Success)
Result TLV (Failure),
Error TLV (Error Code = 2001) ->
// TLS channel torn down
(messages sent in clear text)
<- EAP-FailureA.8. Sequence of EAP Method with Vendor-Specific TLV Exchange 🎀
last example in this section, and it's giving "method first, then a vendor-specific TLV exchange" 💅 where EAP-FAST is negotiated with an EAP method followed by a Vendor-Specific TLV exchange, the convo goes:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(S=1, A-ID)
EAP-Response/EAP-FAST
(TLS client_hello)->
<- EAP-Request/EAP-FAST
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/EAP-FAST
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/EAP-FAST
(TLS change_cipher_spec,
TLS finished,
EAP-Payload-TLV
(EAP-Request/Identity))
// TLS channel established
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// First EAP Payload TLV is piggybacked to the TLS Finished as
Application Data and protected by the TLS tunnel
EAP-Payload-TLV
(EAP-Response/Identity) ->
<- EAP-Payload-TLV
(EAP-Request/Method X)
EAP-Payload-TLV
(EAP-Response/Method X) ->
<- EAP-Payload-TLV
(EAP-Request/Method X)
EAP-Payload-TLV
(EAP-Response/Method X)->
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Version=1
EAP-FAST Version=1, Nonce,
CompoundMAC),
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 this packet to minimize round-trips.
// Compound MAC calculated using Keys generated from
EAP methods X and the TLS tunnel.
Intermediate Result TLV (Success),
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
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 clear text)
<- EAP-SuccessAppendix B. Test Vectors 🧪
okay this is the test vectors appendix, aka the hex dumps you can check your own math against 🤓 every value is copied exactly, so don't go changing a single byte 🫶
B.1. Key Derivation 🔑
here's how the keys get derived, step by step, with all the hex 💜
PAC KEY:
0B 97 39 0F 37 51 78 09 81 1E FD 9C 6E 65 94 2B
63 2C E9 53 89 38 08 BA 36 0B 03 7C D1 85 E4 14
Server_hello Random
3F FB 11 C4 6C BF A5 7A 54 40 DA E8 22 D3 11 D3
F7 6D E4 1D D9 33 E5 93 70 97 EB A9 B3 66 F4 2A
Client_hello Random
00 00 00 02 6A 66 43 2A 8D 14 43 2C EC 58 2D 2F
C7 9C 33 64 BA 04 AD 3A 52 54 D6 A5 79 AD 1E 00
Master_secret = T-PRF(PAC-Key,
"PAC to master secret label hash",
server_random + Client_random,
48)
4A 1A 51 2C 01 60 BC 02 3C CF BC 83 3F 03 BC 64
88 C1 31 2F 0B A9 A2 77 16 A8 D8 E8 BD C9 D2 29
38 4B 7A 85 BE 16 4D 27 33 D5 24 79 87 B1 C5 A2
Key_block = PRF(Master_secret,
"key expansion",
server_random + Client_random)
59 59 BE 8E 41 3A 77 74 8B B2 E5 D3 60 AC 4D 35
DF FB C8 1E 9C 24 9C 8B 0E C3 1D 72 C8 84 9D 57
48 51 2E 45 97 6C 88 70 BE 5F 01 D3 64 E7 4C BB
11 24 E3 49 E2 3B CD EF 7A B3 05 39 5D 64 8A 44
11 B6 69 88 34 2E 8E 29 D6 4B 7D 72 17 59 28 05
AF F9 B7 FF 66 6D A1 96 8F 0B 5E 06 46 7A 44 84
64 C1 C8 0C 96 44 09 98 FF 92 A8 B4 C6 42 28 71
Session Key Seed
D6 4B 7D 72 17 59 28 05 AF F9 B7 FF 66 6D A1 96
8F 0B 5E 06 46 7A 44 84 64 C1 C8 0C 96 44 09 98
FF 92 A8 B4 C6 42 28 71
IMCK = T-PRF(SKS,
"Inner Methods Compound Keys",
ISK,
60)
Note: ISK is 32 octets 0's.
16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80
4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1
18 40 7B 56 BE EA A7 C5 76 5D 8F 0B C5 07 C6 B9
04 D0 69 56 72 8B 6B B8 15 EC 57 7B
[SIMCK 1]
16 15 3C 3F 21 55 EF D9 7F 34 AE C8 1A 4E 66 80
4C C3 76 F2 8A A9 6F 96 C2 54 5F 8C AB 65 02 E1
18 40 7B 56 BE EA A7 C5
MSK = T-PRF(S-IMCKn,
"Session Key Generating Function",
64);
4D 83 A9 BE 6F 8A 74 ED 6A 02 66 0A 63 4D 2C 33
C2 DA 60 15 C6 37 04 51 90 38 63 DA 54 3E 14 B9
27 99 18 1E 07 BF 0F 5A 5E 3C 32 93 80 8C 6C 49
67 ED 24 FE 45 40 A0 59 5E 37 C2 E9 D0 5D 0A E3
EMSK = T-PRF(S-IMCKn,
"Extended Session Key Generating Function",
64);
3A D4 AB DB 76 B2 7F 3B EA 32 2C 2B 74 F4 28 55
EF 2D BA 78 C9 57 2F 0D 06 CD 51 7C 20 93 98 A9
76 EA 70 21 D7 0E 25 54 97 ED B2 8A F6 ED FD 0A
2A E7 A1 58 90 10 50 44 B3 82 85 DB 06 14 D2 F9B.2. Crypto-Binding MIC ✨
Okay bestie, here are the Crypto-Binding MIC test values 🧮🦋
[Compound MAC Key 1]
76 5D 8F 0B C5 07 C6 B9 04 D0 69 56 72 8B 6B B8
15 EC 57 7B
[Crypto-Binding TLV]
80 0C 00 38 00 01 01 00 D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE
21 14 4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58 43 24 6E 30
92 17 6D CF E6 E0 69 EB 33 61 6A CC 05 C5 5B B7
[Server Nonce]
D8 6A 8C 68 3C 32 31 A8 56 63 B6 40 21 FE 21 14
4E E7 54 20 79 2D 42 62 C9 BF 53 7F 54 FD AC 58
[Compound MAC]
43 24 6E 30 92 17 6D CF E6 E0 69 EB 33 61 6A CC
05 C5 5B B7Authors' Addresses 🫶
Meet the crew! 💅 Here's where the authors live 🌸
Nancy Cam-Winget
Cisco Systems
3625 Cisco Way
San Jose, CA 95134
US
EMail: ncamwing@cisco.com
David McGrew
Cisco Systems
San Jose, CA 95134
US
EMail: mcgrew@cisco.com
Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
US
EMail: jsalowey@cisco.com
Hao Zhou
Cisco Systems
4125 Highlander Parkway
Richfield, OH 44286
US
EMail: hzhou@cisco.comFull Copyright Statement 💜
Copyright (C) The IETF Trust (2007). 🌈
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Intellectual Property 🎀
Okay so the IETF is not picking a side on whether any Intellectual Property Rights might cover the tech in this doc, or whether you can get a license for it. It also doesn't claim it went hunting for those rights itself 🙈 If you want the rules on this stuff, check out BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, plus any promises of licenses, or the results of trying to get a general license or permission to use those proprietary rights for implementers or users of this spec, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. 🔥
The IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 🧚
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 👑
📦 where this page comes from
- ietf: rfc4851 2007-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms