RFC 5422
Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)
RFC 5422: Dynamic Provisioning Using Flexible Authentication via Secure Tunneling EAP (EAP-FAST) 💖
Network Working Group 🌸 Standards track vibes, but actually Informational (so it's not a mandatory standard, just a helpful doc 🧚)
Authors: N. Cam-Winget, D. McGrew, J. Salowey, and H. Zhou, all from Cisco Systems 👑
Date: March 2009 📅
Obsoletes / Updates: This title block doesn't list any RFCs that it obsoletes or updates, so it's just doing its own thing ✨
Status of This Memo ✨
okay so this memo is giving "info for the internet community" 💅 It is NOT an Internet standard of any kind, and it can be shared freely with no restrictions on distribution 🦋
Copyright Notice 🎀
Copyright (c) 2009 IETF Trust and the people listed as the document authors. All rights reserved 🔒
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which are the rules in effect on the publication date. Read them carefully, bestie, because they explain what you can and can't do with this doc 📜 You can find them at http://trustee.ietf.org/license-info.
Some of the material in here came from IETF Documents or IETF Contributions that were published or made public before November 10, 2008 🌈 The people who own the copyright on some of that older stuff may not have given the IETF Trust permission to modify it outside of the IETF Standards Process. So unless you get a proper license from those copyright holders, you can't modify this document outside the IETF Standards Process, and you can't make derivative works outside of it either. The one exceptions are formatting it for RFC publication or translating it into languages other than English 🫶
IESG Note 🔥
EAP-FAST has been implemented by lots of vendors and it's actually being used on the Internet, so this publication is here to promote interoperability by documenting how existing EAP methods are being used inside EAP-FAST 🍓
Now the tea ☕ The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type code that was assigned to EAP-MSCHAPv2 (26) for authentication inside an anonymous TLS tunnel. To keep the risk of an anonymous tunnel low, changes were made to the method that are not interoperable with EAP-MSCHAPv2. EAP-MSCHAPv2 doesn't support method-specific version negotiation, so using EAP-FAST-MSCHAPv2 is implied any time you're using an anonymous EAP-FAST tunnel. This can cause problems for implementations that need the unaltered EAP-MSCHAPv2 running inside an anonymous EAP-FAST tunnel 😭 Supporting that requires special-case execution of a method within a tunnel, which also makes things complicated for implementations that use the same method code both inside and outside the tunnel 💀 If EAP-FAST were designed today, all of these headaches could be avoided by using unique EAP Type codes 🧚 So given all of this, assigned method types must not be re-used with different meaning inside tunneled methods in the future 🙈
Abstract 🦋
The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method lets a peer and a server talk securely by using Transport Layer Security (TLS) to set up a mutually authenticated tunnel ✨ EAP-FAST also lets you provision credentials or other info through that protected tunnel 🔐 This document describes how to use EAP-FAST for dynamic provisioning 💜
Table of Contents 📚
1. Introduction ....................................................4
1.1. Specification Requirements .................................4
1.2. Terminology ................................................4
2. EAP-FAST Provisioning Modes .....................................5
3. Dynamic Provisioning Using EAP-FAST Conversation ................6
3.1. Phase 1 TLS Tunnel .........................................7
3.1.1. Server-Authenticated Tunnel .........................7
3.1.2. Server-Unauthenticated Tunnel .......................7
3.2. Phase 2 - Tunneled Authentication and Provisioning .........7
3.2.1. Server-Authenticated Tunneled Authentication ........8
3.2.2. Server-Unauthenticated Tunneled Authentication ......8
3.2.3. Authenticating Using EAP-FAST-MSCHAPv2 ..............8
3.2.4. Use of Other Inner EAP Methods for EAP-FAST
Provisioning ........................................9
3.3. Key Derivations Used in the EAP-FAST Provisioning
Exchange ..................................................10
3.4. Peer-Id, Server-Id, and Session-Id ........................11
3.5. Network Access after EAP-FAST Provisioning ................11
4. Information Provisioned in EAP-FAST ............................12
4.1. Protected Access Credential ...............................12
4.1.1. Tunnel PAC .........................................13
4.1.2. Machine Authentication PAC .........................13
4.1.3. User Authorization PAC .............................13
4.1.4. PAC Provisioning ...................................14
4.2. PAC TLV Format ............................................15
4.2.1. Formats for PAC Attributes .........................16
4.2.2. PAC-Key ............................................16
4.2.3. PAC-Opaque .........................................17
4.2.4. PAC-Info ...........................................18
4.2.5. PAC-Acknowledgement TLV ............................20
4.2.6. PAC-Type TLV .......................................21
4.3. Trusted Server Root Certificate ...........................21
4.3.1. Server-Trusted-Root TLV ............................22
4.3.2. PKCS#7 TLV .........................................23
5. IANA Considerations ............................................24
6. Security Considerations ........................................25
6.1. Provisioning Modes and Man-in-the-Middle Attacks ..........25
6.1.1. Server-Authenticated Provisioning Mode and
Man-in-the-Middle Attacks ..........................26
6.1.2. Server-Unauthenticated Provisioning Mode
and Man-in-the-Middle Attacks ......................26
6.2. Dictionary Attacks ........................................27
6.3. Considerations in Selecting a Provisioning Mode ...........28
6.4. Diffie-Hellman Groups .....................................28
6.5. Tunnel PAC Usage ..........................................28
6.6. Machine Authentication PAC Usage ..........................29
6.7. User Authorization PAC Usage ..............................29
6.8. PAC Storage Considerations ................................29
6.9. Security Claims ...........................................31
7. Acknowledgements ...............................................31
8. References .....................................................31
8.1. Normative References ......................................31
8.2. Informative References ....................................32
Appendix A. Examples .............................................33
A.1. Example 1: Successful Tunnel PAC Provisioning .............33
A.2. Example 2: Failed Provisioning ............................35
A.3. Example 3: Provisioning an Authentication Server's
Trusted Root Certificate ..................................371. Introduction ✨
okay so EAP-FAST [RFC4851] is an EAP method that lets the peer and server mutually authenticate each other 🫶 The catch is that credentials like a pre-shared key, a certificate trust anchor, or a Protected Access Credential (PAC) must be provisioned to the peer before it can do mutual authentication with the server 😩 In lots of cases, getting that provisioning done is a whole deployment hurdle. So by using the protected TLS [RFC5246] tunnel, EAP-FAST can do dynamic in-band provisioning, which solves those deployment obstacles and literally saves everyone's time 🌸
1.1. Specification Requirements 📋
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 in this doc comes from [RFC3748] ✨ The terms "peer" and "server" are used interchangeably with "EAP peer" and "EAP server," respectively. A few more terms are defined below 💅
Man in the Middle (MITM)
An adversary that can successfully inject itself between a peer and an EAP server. The MITM succeeds by impersonating a valid peer or server. Major villain behavior 😈
Provisioning
Giving a peer a trust anchor, a shared secret, or other appropriate information it needs to establish a security association 🔑
Protected Access Credential (PAC)
Credentials handed out to a peer for future optimized network authentication 🦋 A PAC has at most three components: a shared secret, an opaque element, and optional information. The shared secret part holds the secret key shared between the peer and the server. The opaque part contains the shared secret, encrypted by a private key that only the server knows, and it's given to the peer and sent back to the server whenever the peer wants access to network resources 🔐 Finally, a PAC may optionally include other information that could be useful to the peer 🌈
Tunnel PAC
A set of credentials that the peer stores and that both the peer and the server use to set up a TLS tunnel 🎀
User Authorization PAC
A User Authorization PAC is server-encrypted data containing authorization information tied to a user who was previously authenticated 💜 It doesn't contain a key. Instead, it's generally bound to a Tunnel PAC, and the two are used together 🫶
Machine Authentication PAC
A Machine Authentication PAC contains server-encrypted data with authorization information tied to a device 🖥️ It can be used instead of a Tunnel PAC to set up the TLS tunnel, so the machine gets authenticated and authorized. It's super useful when a machine needs to be authenticated and authorized to access the network before any user has logged in 👑
2. EAP-FAST Provisioning Modes 🎀
okay so EAP-FAST has two provisioning modes, and I'm obsessed with both of them 💅
- Server-Authenticated Provisioning Mode: provisioning happens inside a TLS tunnel that gives you server-side authentication 🔒
- Server-Unauthenticated Provisioning Mode: provisioning happens inside an anonymous TLS tunnel 🫣
Both modes run EAP-FAST phase 2 inside a secure TLS tunnel that gets set up during phase 1. If you want the deeper tea on the EAP-FAST phases, [RFC4851] explains them in way more detail 📚
In the Server-Authenticated Provisioning Mode, the peer has already authenticated the EAP server during EAP-FAST phase 1 (that's the TLS tunnel setup part) ✅. Extra exchanges MAY happen inside the tunnel so the EAP server can authenticate the EAP peer before any information gets provisioned. Main character energy for the server, honestly 👑
In the Server-Unauthenticated Provisioning Mode, the EAP-FAST phase 1 tunnel is set up without authenticating the server 🙈. The peer MUST negotiate a TLS anonymous Diffie-Hellman-based ciphersuite to signal that it wants to use this mode. This is the mode for bootstrapping peers who don't have strong credentials they can use for mutual authentication with the server. Literally built for the "I have nothing yet" era 🍓
Here's the catch: since the server isn't authenticated in this mode, an attacker could possibly intercept the TLS tunnel 😬. So if an anonymous tunnel is used, the peer and server MUST negotiate and successfully complete an EAP method that supports mutual authentication and key derivation, as described in Section 6. After that, the peer uses the Crypto-Binding TLV to validate the integrity of the TLS tunnel, which verifies that the exchange wasn't hit by a man-in-the-middle attack 🛡️. Iykyk, that's the safety net.
The Server-Authenticated Provisioning Mode protects against man-in-the-middle attacks, but the peer needs to be provisioned with the credentials required to authenticate the server first 🗝️. So if an environment is cool trading some man-in-the-middle risk for easier deployment, it can choose the Server-Unauthenticated Provisioning Mode. Valid tradeoff, no judgment 💖
If the inner EAP method and the Crypto-Binding TLV exchange both succeed, the server then provides credential information. That could be a shared key delivered through a PAC TLV, or the trusted certificate root(s) of the server delivered through a Server-Trusted-Root TLV 🎁. Once the EAP-FAST provisioning conversation wraps up, the peer is expected to use those provisioned credentials in its later EAP-FAST authentications ✨
3. Dynamic Provisioning Using EAP-FAST Conversation 🦋
Provisioning happens in a few steps. They're explained in the sections below and in RFC 4851, so no skipping ahead 🙃. First, the EAP-FAST phase 1 TLS tunnel gets established. During that process, extra material is pulled out of the TLS key derivation to use as challenges in the next authentication exchange 🔑. Then an inner EAP method, like EAP-FAST-MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2), runs inside the EAP-FAST phase 2 TLS tunnel. It authenticates the client using the challenges derived from the phase 1 TLS exchange 🤝.
After successful authentication and the Crypto-Binding TLV exchange, the server provisions the peer with PAC information, which includes the secret PAC-Key and the PAC-Opaque 🎀. Finally, the EAP-FAST conversation ends with Result TLV exchanges, as defined in RFC 4851 🏁. The exported EAP Master Session Key (MSK) and Extended MSK (EMSK) come from a mix of the tunnel key material and the key material from the inner EAP method exchange 🌈. Such a layered glow-up 💅
3.1. Phase 1 TLS Tunnel
3.1.1. Server-Authenticated Tunnel
The provisioning EAP-FAST exchange follows the same sequence as EAP-FAST authentication phase 1 to set up a protected TLS tunnel 🧚. Implementations that support this version of the Server-Authenticated Provisioning Mode MUST support the following TLS ciphersuites, which are defined in [RFC5246]:
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHAOther TLS ciphersuites that provide server authentication and encryption MAY be supported 🌸. The server MAY authenticate the peer during the TLS handshake in the Server-Authenticated Provisioning Mode. To follow best security practices, the peer MUST validate the server's certificate chain when it does server-side authentication 🔐. That's how you get the full security benefits of Server-Authenticated provisioning, so don't skip it, bestie 😭
3.1.2. Server-Unauthenticated Tunnel
Implementations that support this version of the Server-Unauthenticated Provisioning Mode MUST support the following TLS ciphersuite, which is defined in [RFC5246]:
TLS_DH_anon_WITH_AES_128_CBC_SHAAnonymous ciphersuites SHOULD NOT be allowed outside of the EAP-FAST Server-Unauthenticated Provisioning Mode 🙅♀️. Any ciphersuites used for the Server-Unauthenticated Provisioning Mode MUST provide a key agreement contributed by both parties. That means ciphersuites based on RSA key transport MUST NOT be used for this mode 🚫. Ciphersuites used for provisioning MUST provide encryption too 🔒.
3.2. Phase 2 - Tunneled Authentication and Provisioning
Once a protected tunnel is set up and the server is unauthenticated, the peer and server MUST run additional authentication and perform integrity checks on the TLS tunnel 🔍. Even if both parties were authenticated during TLS tunnel establishment, the peer and server MAY want to do extra authentication inside the tunnel 💜. As defined in [RFC4851], the authentication exchange is followed by an Intermediate-Result TLV and a Crypto-Binding TLV, if the EAP method succeeded. The Crypto-Binding TLV checks the integrity of the tunnel with respect to the endpoints of the EAP method 🧐. If all of that goes through, a provisioning exchange MAY happen. It uses a PAC TLV exchange if a PAC is being provisioned, and a Server-Trusted-Root TLV if a trusted root certificate is being provisioned 📦.
The provisioning MAY be solicited by the peer, or it MAY be unsolicited ✨. The PAC TLV exchange works like this: the server sends the PAC in a corresponding PAC TLV to the peer, and the peer confirms it got it with a final PAC TLV Acknowledgement message 📨. The peer may also use the PAC TLV to ask the server to send a PAC 🙋♀️. The provisioning TLVs MAY be piggybacked onto the Result TLV 🎀.
Here's a big one: many implementations process TLVs in the order they arrive, so for proper provisioning, the Result TLV MUST come before the TLVs being provisioned (for example, Tunnel PAC, Machine Authentication PAC, and User Authorization PAC) 📋. A PAC TLV MUST NOT be accepted if it isn't encapsulated in an encrypted TLS tunnel 🔐. Non-negotiable, period 💀
A fresh PAC MAY be distributed if the server notices the PAC is expiring soon 🌅. In-band PAC refreshing goes through the PAC TLV mechanism. The server decides whether or not to refresh the PAC. Based on the PAC-Opaque information, the server MAY decide not to refresh a peer's PAC, even if the PAC-Key has expired 🫶.
3.2.1. Server-Authenticated Tunneled Authentication
If the Server-Authenticated Provisioning Mode is in use, then any EAP method may be used within the TLS tunnel to authenticate the peer, as long as the peer's policy allows it 🗝️.
3.2.2. Server-Unauthenticated Tunneled Authentication
If the Server-Unauthenticated Provisioning Mode is in use, the peer authenticates the server and the server authenticates the peer inside the tunnel 🤜🤛. The only authentication method defined in this version of EAP-FAST is EAP-FAST-MSCHAPv2 (used in a special way, as described in the following section). Other methods could be defined to do this authentication in the future 🔮.
3.2.3. Authenticating Using EAP-FAST-MSCHAPv2
EAP-FAST-MSCHAPv2 is a specific instantiation of EAP-MSCHAPv2 [EAP-MSCHAPv2], defined for use within EAP-FAST 🎀. The 256-bit inner session key (ISK) is generated from EAP-FAST-MSCHAPv2 by combining the 128-bit master keys derived according to RFC 3079 [RFC3079]. The MasterSendKey provides the first 16 octets, and the MasterReceiveKey provides the last 16 octets 🔑.
Implementations of this version of the EAP-FAST Server-Unauthenticated Provisioning Mode MUST support EAP-FAST-MSCHAPv2 as the inner authentication method 💖. Other authentication methods exist, but EAP-FAST-MSCHAPv2 was picked for a few reasons:
- It can slow down an active attack, because it uses a hash-based challenge-response protocol 🐢.
- Its challenge-response design, like MSCHAPv2, gives some ability to detect a man-in-the-middle attack during Server-Unauthenticated Provisioning Mode 🕵️♀️.
- It's already supported by a large deployed base 🌍.
- It allows password change during the EAP-FAST provisioning modes 🔄.
When an anonymous Diffie-Hellman (DH) key agreement is used, the challenges MUST be generated as defined in Section 3.3. This creates a binding between the tunnel and the EAP-FAST-MSCHAPv2 exchanges. It does this by using keying material from the EAP-FAST tunnel establishment as the EAP-FAST-MSCHAPv2 challenges, instead of the challenges exchanged within the protocol itself 🪢. The exchanged challenges are zeroed upon transmission and ignored upon reception, and the challenges derived from the TLS key exchange are used in the calculations 🧮. When EAP-FAST-MSCHAPv2 is used inside a tunnel set up with a ciphersuite that doesn't provide anonymous key agreement, the randomly generated EAP-FAST-MSCHAPv2 challenges MUST be exchanged and used 🎲.
The EAP-FAST-MSCHAPv2 exchange forces the server to give a valid ServerChallengeResponse. That response has to be a function of the server challenge, the peer challenge, and the password 🔐. This shrinks the window of vulnerability to a man-in-the-middle attack that spoofs the server, because the attacker would have to break the password within the peer's challenge-response time limit ⏱️. Smart design, ngl 🧠
3.2.4. Use of Other Inner EAP Methods for EAP-FAST Provisioning
Once a protected tunnel is set up, the peer typically authenticates itself to the server before the server can provision the peer 🤳. If the authentication mechanism doesn't support mutual authentication and protection from man-in-the-middle attacks, then the Server-Authenticated Provisioning Mode MUST be used 🛡️. Inside a server-side authenticated tunnel, authentication mechanisms such as EAP-FAST-GTC (Generic Token Card) [RFC5421] MAY be used. This lets peers using other authentication mechanisms, like password databases and one-time passwords, get provisioned in-band too 🙌.
This version of the EAP-FAST provisioning mode implementation MUST support both EAP-FAST-GTC and EAP-FAST-MSCHAPv2 inside the tunnel in the Server-Authenticated Provisioning Mode 💜.
It should be noted that the Server-Authenticated Provisioning Mode gives significant security advantages over the Server-Unauthenticated Provisioning Mode, even when EAP-FAST-MSCHAPv2 is the inner method 📣. It protects the EAP-FAST-MSCHAPv2 exchanges from potential active man-in-the-middle attacks by verifying the server's authenticity before EAP-FAST-MSCHAPv2 runs 🔒. The Server-Authenticated Provisioning Mode is the recommended provisioning mode 🌟. The EAP-FAST peer MUST use the Server-Authenticated Provisioning Mode whenever it's configured with a valid trust root for a particular server 🎀✨
3.3. Key Derivations Used in the EAP-FAST Provisioning Exchange 🔑
okay so the TLS tunnel key gets calculated according to whichever TLS version you're using, and then there's an extra 72 octets of key material that gets pulled from the end of the key_block 🧚. Some of those extra octets feed the EAP-FAST provisioning exchange session key seed, and the rest become the random challenges in the EAP-FAST-MSCHAPv2 exchange ✨
to make the key material, you compute:
key_block = PRF(master_secret,
"key expansion",
server_random +
client_random);and you keep going until you've got enough output 💅
for example, the key_block for TLS 1.0 [RFC2246] gets partitioned like this:
client_write_MAC_secret[hash_size]
server_write_MAC_secret[hash_size]
client_write_key[Key_material_length]
server_write_key[key_material_length]
client_write_IV[IV_size]
server_write_IV[IV_size]
session_key_seed[40]
ServerChallenge[16]
ClientChallenge[16]and the key_block for later versions gets partitioned like this:
client_write_MAC_secret[hash_size]
server_write_MAC_secret[hash_size]
client_write_key[Key_material_length]
server_write_key[key_material_length]
session_key_seed[40]
ServerChallenge[16]
ClientChallenge[16]so in the extra key material, session_key_seed is used for the EAP-FAST Crypto-Binding TLV exchange 🦋, while ServerChallenge and ClientChallenge line up with the authentication server's EAP-FAST-MSCHAPv2 challenge and the peer's EAP-FAST-MSCHAPv2 challenge, respectively. The ServerChallenge and ClientChallenge only get used for the EAP-FAST-MSCHAPv2 exchange when Diffie-Hellman anonymous key agreement is used in the EAP-FAST tunnel establishment 🎀
3.4. Peer-Id, Server-Id, and Session-Id 🎀
the provisioning modes don't change the general EAP-FAST protocol, so how the Peer-Id, Server-Id, and Session-Id get determined is based on the [RFC4851] techniques 🧁
Section 3.4 of [RFC4851] describes how the Peer-Id and Server-Id are determined, and Section 3.5 describes how the Session-Id is generated 💜
3.5. Network Access after EAP-FAST Provisioning 🚪
after successful provisioning, network access MAY be granted or denied depending on the server policy 🤷♀️ For example, in the Server-Authenticated Provisioning Mode, access can be granted after the EAP server has authenticated the peer and provisioned it with a Tunnel PAC (a PAC used to mutually authenticate and establish the EAP-FAST tunnel). Additionally, peer policy MAY instruct the peer to disconnect the current provisioning connection and start a new EAP-FAST exchange to authenticate using the newly provisioned information. At the end of the Server-Unauthenticated Provisioning Mode, network access SHOULD NOT be granted, because this conversation is only for provisioning and no network access is authorized 🙅♀️ The server MAY grant access at the end of a successful Server-Authenticated provisioning exchange ✨
if access to the network is denied after successful provisioning, the EAP Server SHOULD conclude with an EAP Failure 💀 The EAP server SHALL NOT grant network access or distribute any session keys to the Network Access Server (NAS) if this exchange is not intended to provide network access. Even though the provisioning mode completes with a successful inner termination (e.g., a successful Result TLV), the server policy defines whether or not the peer gains network access. so it's feasible that the server, while providing a successful Result TLV, may conclude that its authentication policy was not satisfied and end the conversation with an EAP Failure 😭
denying network access after EAP-FAST provisioning may cause disruption in scenarios like wireless devices (e.g., in IEEE 802.11 devices, an EAP Failure may trigger a full 802.11 disassociation). 😱
while a full EAP restart can be performed, a smoother transition to the subsequent EAP-FAST authentications that enable network access can be achieved 🦋 by the peer or server initiating TLS renegotiation, where the newly provisioned credentials can be used to establish a server-authenticated or mutually authenticated TLS tunnel for authentication. Either the peer or server may reject the request for TLS renegotiation. Once the TLS negotiation and subsequent authentication are done, normal network access policy on EAP-FAST authentication can be applied 👑
4. Information Provisioned in EAP-FAST 🎁
multiple types of credentials MAY be provisioned within EAP-FAST 🌈 The most common credential is the Tunnel PAC, which is used to establish the EAP-FAST phase 1 tunnel. On top of the Tunnel PAC, other types of credentials and information can also be provisioned through EAP-FAST, like trusted root certificates, PACs for specific purposes, and user identities, to name a few. Typically, provisioning is invoked after both the peer and server authenticate each other and after a successful Crypto-Binding TLV exchange. However, depending on what's being provisioned, mutual authentication MAY not be needed 🤔
at a minimum, either the peer or server must prove authenticity before credentials are provisioned, so that information isn't freely handed to or from adversaries 🛡️ For example, the EAP server may not need to authenticate the peer to provision it with trusted root certificates. However, the peer SHOULD authenticate the server before it can accept a trusted server root certificate 🫶
4.1. Protected Access Credential 🔐
a Protected Access Credential (PAC) is a security credential generated by the server that holds information specific to a peer 💖 The server distributes all PAC information through a PAC TLV. Different types of PAC information are identified by the PAC Type and other PAC attributes defined in this section. This document defines three types of PACs: a Tunnel PAC, a Machine Authentication PAC, and a User Authorization PAC 🌸
4.1.1. Tunnel PAC 🧁
the server distributes the Tunnel PAC to the peer, which uses it in later attempts to set up a secure EAP-FAST TLS tunnel with the server. The Tunnel PAC includes a secret key (PAC-Key), data that is opaque to the peer (PAC-Opaque), and other information (PAC-Info) that the peer can interpret 🍓 The opaque data is generated by the server and cryptographically protected, so it can't be modified or interpreted by the peer 🔒 The Tunnel PAC conveys the server policy of what must and can occur in the protected phase 2 tunnel.
it's up to the server policy to include whatever is needed in a PAC-Opaque to enforce that policy in subsequent TLS handshakes. For example, a user identity, I-ID, can be included as part of the server policy. This I-ID information limits the inner EAP methods to be carried only on the specified user identity. Other types of information can also be included, such as which EAP method(s) and which TLS ciphersuites are allowed. If the server policy isn't included in a PAC-Opaque, then the PAC doesn't impose any limitation on the use of inner EAP methods or user identities inside the tunnel established by that PAC 🙈
4.1.2. Machine Authentication PAC 🤖
the Machine Authentication PAC contains information in the PAC-Opaque that identifies the machine ⚙️ It's meant to be used by a machine when network access is required and no user is logged in. Typically, a server will only grant the minimal amount of access a machine needs without a user present, based on the Machine Authentication PAC. The Machine Authentication PAC MAY be provisioned during the authentication of a user. It SHOULD be stored by the peer in a location that is only accessible to the machine. This type of PAC typically persists across sessions 💜
the peer can use the Machine Authentication PAC as the Tunnel PAC to establish the TLS tunnel. The EAP server MAY have a policy to bypass an additional inner EAP method and grant limited network access based on information in the Machine Authentication PAC. The server MAY request additional exchanges to validate the machine's other authorization criteria, such as posture information, before granting network access 🧚
4.1.3. User Authorization PAC 👑
the User Authorization PAC contains information in the PAC-Opaque that identifies a user and provides authorization information. This type of PAC does not contain a PAC-Key 🫠 The PAC-Opaque portion of the User Authorization PAC is presented within the protected EAP-FAST TLS tunnel to provide user information during stateless session resume, so user authentication MAY be skipped. The User Authorization PAC MAY be provisioned after user authentication. It's meant to be short-lived and not persisted across logon sessions. The User Authorization PAC SHOULD only be available to the user it was provisioned for. The User Authorization PAC SHOULD be deleted from the peer when the local authorization state of a user's session changes, such as when the user logs out 🚪
once the EAP-FAST phase 1 TLS tunnel is established, the peer MAY present a User Authorization PAC to the server in a PAC TLV. This is sent as TLS application data, but it MAY be included in the same message as the Finished Handshake message sent by the peer. The User Authorization PAC MUST only be sent within the protection of an encrypted tunnel to an authenticated entity 🔐 The server decrypts the PAC and evaluates the contents. If the contents are valid and the server policy allows the session to be resumed based on this information, then the server completes the session resumption and grants access to the peer without requiring an inner authentication method. This is called stateless session resume in EAP-FAST ✨ In this case, the server sends the Result TLV indicating success without the Crypto-Binding TLV, and the peer sends back a Result TLV indicating success. If the User Authorization PAC fails the server validation or the server policy, the server MAY either reject the request or continue with performing full user authentication within the tunnel 💅
4.1.4. PAC Provisioning ✨
okay so bestie, here's how a peer asks for a PAC 🎀 It sends a PAC TLV with a PAC attribute whose PAC Type is set to the right value: 1 for a Tunnel PAC, 2 for a Machine Authentication PAC, and 3 for a User Authorization PAC 🦋 The request MAY be sent once the peer has decided the EAP server authenticated it successfully and has validated the Crypto-Binding TLV, so the TLS tunnel's integrity is intact 🔒 Anonymous DH ciphersuites are only allowed for provisioning a Tunnel PAC, so if an anonymous ciphersuite gets negotiated, the server MAY provision the Tunnel PAC automatically 💜
The peer MUST send separate PAC TLVs for each type of PAC it wants, but the PAC TLVs can all ride in the same packet or be spread across different packets 📦 When requesting a Machine Authentication PAC, the peer SHOULD include an I-ID TLV containing the machine name prefixed by "host/" 🖥️ The EAP server sends the PACs once its internal policy is satisfied. If the policy says otherwise, it MAY ignore the request or ask for additional authentications instead 🙅♀️ And if a peer gets a PAC with a type it doesn't recognise, it MUST ignore it 💅
A PAC-TLV containing the PAC-Acknowledge attribute MUST be sent by the peer to acknowledge receipt of the Tunnel PAC ✅ A PAC-Acknowledge TLV MUST NOT be used to acknowledge receipt of any other type of PAC, so don't mix them up, bestie 🫶
Please see Appendix A.1 for an example of the packet exchanges used to provision a Tunnel PAC 🧚
4.2. PAC TLV Format
okay the PAC TLV is what supports provisioning the Protected Access Credential (PAC) defined within [RFC4851] 👑 It carries the PAC and its related info inside PAC attribute fields. The peer MAY also use the PAC TLV to request provisioning of a PAC of the type named in the PAC Type PAC attribute 🌸 A PAC TLV MUST only be used in a protected tunnel that provides encryption and integrity protection 🔐 The general layout looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAC Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field does:
- M
0- Non-mandatory TLV1- Mandatory TLV
- R: Reserved, set to zero (
0) 🫧 - TLV Type:
11- PAC TLV - Length: Two octets containing the length of the PAC attributes field in octets.
- PAC Attributes: A list of PAC attributes in the TLV format.
4.2.1. Formats for PAC Attributes 🎀
Each PAC attribute in a PAC TLV is formatted as a TLV, like so:
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: The Type field is two octets and denotes the attribute type. Allocated Types include:
1 - PAC-Key
2 - PAC-Opaque
3 - PAC-Lifetime
4 - A-ID
5 - I-ID
6 - Reserved
7 - A-ID-Info
8 - PAC-Acknowledgement
9 - PAC-Info
10 - PAC-Type- Length: Two octets containing the length of the Value field in octets.
- Value: The value of the PAC attribute.
4.2.2. PAC-Key 🔑
The PAC-Key is a secret key distributed in a PAC attribute of type PAC-Key. The server includes the PAC-Key attribute inside the PAC TLV whenever it wants to issue or renew a PAC that's bound to a key, like a Tunnel PAC 💖 The key is a randomly generated octet string that's 32 octets long. Whoever generates the key is the issuer of the credential, and that issuer is identified by the Authority Identifier (A-ID) ✨
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type:
1- PAC-Key - Length: A 2-octet length indicating a 32-octet key.
- Key: The value of the PAC-Key.
4.2.3. PAC-Opaque 🫧
The PAC-Opaque attribute is included within the PAC TLV whenever the server wants to issue or renew a PAC, or whenever the client wants to present a User Authorization PAC to the server 💜
The PAC-Opaque is opaque to the peer, so the peer MUST NOT attempt to interpret it 🙈 A peer that's been issued a PAC-Opaque by a server stores that data and presents it back to the server according to its PAC Type. The Tunnel PAC is used in the ClientHello SessionTicket extension field defined in [RFC5077]. If a peer has opaque data issued to it by multiple servers, it stores the data issued by each server separately, according to the A-ID 🗂️ This requirement lets the peer maintain and use each opaque datum as an independent PAC pairing, with a PAC-Key mapping to a PAC-Opaque identified by the A-ID. Since there's a one-to-one correspondence between the PAC-Key and PAC-Opaque, the peer figures out the PAC-Key and corresponding PAC-Opaque based on the A-ID provided in the EAP-FAST/Start message and the A-ID provided in the PAC-Info when it was provisioned with a PAC-Opaque 🧩
The PAC-Opaque attribute format looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type:
2- PAC-Opaque - Length: The Length filed is two octets, which contains the length of the Value field in octets.
- Value: The Value field contains the actual data for the PAC-Opaque. It is specific to the server implementation.
4.2.4. PAC-Info 📋
The PAC-Info is made up of a set of PAC attributes as defined in Section 4.2.1. The PAC-Info attribute MUST contain the A-ID, A-ID-Info, and PAC-Type attributes 👑 Other attributes MAY be included in the PAC-Info to give the peer more information 🌈 The PAC-Info attribute MUST NOT contain the PAC-Key, PAC-Acknowledgement, PAC-Info, or PAC-Opaque attributes 🚫 The server includes the PAC-Info attribute inside the PAC TLV whenever it wants to issue or renew a PAC.
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type:
9- PAC-Info - Length: A 2-octet Length field containing the length of the attributes field in octets.
- Attributes: The attributes field contains a list of PAC attributes. Each mandatory and optional field type is defined as follows:
3- PAC-LIFETIME: This is a 4-octet quantity representing the expiration time of the credential, expressed as the number of seconds, excluding leap seconds, after midnight UTC, January 1, 1970. This attribute MAY be provided to the peer as part of the PAC-Info ⏳4- A-ID: The A-ID is the identity of the authority that issued the PAC. It's intended to be unique across all issuing servers so there are no namespace collisions 🏷️ The peer uses the A-ID to decide which PAC to employ. The A-ID is treated as an opaque octet string. This attribute MUST be included in the PAC-Info attribute. The A-ID MUST match the A-ID the server used to establish the tunnel. Since many existing implementations expect the A-ID to be 16 octets long, it is RECOMMENDED that the length of an A-ID be 16 octets for maximum interoperability 💅 One method for generating the A-ID is to use a high-quality random number generator to produce a 16-octet random number. An alternate method is to take the hash of the public key or public key certificate belonging to a server represented by the A-ID.5- I-ID: The Initiator identifier (I-ID) is the peer identity associated with the credential 🪪 This identity is derived from the inner EAP exchange, or from the client-side authentication during tunnel establishment if inner EAP method authentication isn't used. The server uses the I-ID in the EAP-FAST phase 2 conversation to validate that the same peer identity used to run EAP-FAST phase 1 is also used in at minimum one inner EAP method in EAP-FAST phase 2. If the server is enforcing the I-ID validation on the inner EAP method, then the I-ID MUST be included in the PAC-Info, so the peer can also enforce a unique PAC for each unique user 🧑🤝🧑 If the I-ID is missing from the PAC-Info, it is assumed that the Tunnel PAC can be used for multiple users, and the peer will not enforce the unique-Tunnel-PAC-per-user policy.7- A-ID-Info: The Authority Identifier Information is intended to provide a user-friendly name for the A-ID. It may contain the enterprise name and server name in a human-readable format 🏢 This TLV helps the peer better inform the end-user about the A-ID. The name is encoded in UTF-8 [RFC3629] format. This attribute MUST be included in the PAC-Info.10- PAC-type: The PAC-Type is intended to provide the type of PAC 🎟️ This attribute SHOULD be included in the PAC-Info. If the PAC-Type isn't present, it defaults to a Tunnel PAC (Type 1).
4.2.5. PAC-Acknowledgement TLV ✨
Okay bestie, the PAC-Acknowledgement is how the peer says "got it!" 💌 after receiving a Tunnel PAC from the server. The peer slips the PAC-Acknowledgement TLV into a PAC-TLV that goes back to the server, and it reports how processing and storing the newly provisioned Tunnel PAC went. This TLV only shows up when a Tunnel PAC is being provisioned. 🎀
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 💖:
8is PAC-Acknowledgement. - Length 📏: two octets, and the value is
2. - Result ✅: the value MUST be one of these:
1- Success2- Failure
4.2.6. PAC-Type TLV 🦋
The PAC-Type TLV is the one that says which kind of PAC is being asked for. The peer tucks it into a PAC-TLV sent to the server to request PAC provisioning. 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAC Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 💅:
10is PAC-Type. - Length 📏: a 2-octet Length field with the value
2. - PAC Type 🌈: this 2-octet field tells you which PAC is being requested or provisioned. These values are defined:
1- Tunnel PAC2- Machine Authentication PAC3- User Authorization PAC
4.3. Trusted Server Root Certificate 🔐
The Server-Trusted-Root TLV is how you request and receive a trusted server root certificate. It can show up in regular EAP-FAST authentication mode or in provisioning mode. It's always marked as optional, and you can't reply to it with a Negative Acknowledgement (NAK) TLV. Also, the Server-Trusted-Root TLV MUST only be sent as an inner TLV, which means it has to live inside the protection of the tunnel. 🛡️
Once the peer has decided it successfully authenticated the EAP server and validated the Crypto-Binding TLV, it MAY send one or more Server-Trusted-Root TLVs (marked as optional) to ask the EAP server for trusted server root certificates. The EAP server MAY send one or more root certificates wrapped in a Public Key Cryptographic System #7 (PKCS#7) TLV inside the Server-Trusted-Root TLV. The EAP server MAY also choose not to honor the request. 🙈 For an example of a server provisioning a server trusted root certificate, check out Appendix A.3. 💜
4.3.1. Server-Trusted-Root TLV 🌸
The Server-Trusted-Root TLV lets the peer ask the EAP server for a list of trusted roots. The server can answer with one or more root certificates in PKCS#7 [RFC2315] format. 🍓
If the EAP server sets the credential format to PKCS#7-Server-Certificate-Root, then the Server-Trusted-Root TLV should contain the root of the certificate chain for the certificate issued to the EAP server, packaged in a PKCS#7 TLV. If the server certificate is self-signed, then the root is that self-signed certificate. 🎀
If the Server-Trusted-Root TLV credential format has a value the peer doesn't know, the EAP peer should ignore the TLV. 🙃
Here's how the Server-Trusted-Root TLV is defined:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credential-Format | Cred TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- M 🧚:
0means Non-mandatory TLV. - R 🫶: Reserved, set to zero (
0). - TLV Type 👑:
18is Server-Trusted-Root TLV [RFC4851]. - Length 📏:
>=2 octets. - Credential-Format 💜: this field is two octets. Its values include:
1- PKCS#7-Server-Certificate-Root
- Cred TLVs 🌈: this field is of indefinite length and holds TLVs that go with the credential format. The peer may leave this field empty when it uses this TLV just to request server trust roots.
4.3.2. PKCS#7 TLV 🧁
The PKCS#7 TLV is sent by the EAP server to the peer inside the Server-Trusted-Root TLV. It carries PKCS#7-wrapped [RFC2315] X.509 certificates. The format is a certificate or certificate chain in a Certificates-Only PKCS#7 SignedData message, as defined in [RFC2311]. 📜
The PKCS#7 TLV is always marked as optional, and it can't be answered with a NAK TLV. EAP-FAST server implementations that claim to support the dynamic provisioning defined in this document SHOULD support this TLV. EAP-FAST peer implementations MAY support this TLV. 💅
If the PKCS#7 TLV has a certificate or certificate chain that isn't acceptable to the peer, then the peer MUST ignore the TLV. 🙅♀️
Here's how the PKCS#7 TLV is defined:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS #7 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- M 🌷:
0means Optional TLV. - R 🫧: Reserved, set to zero (
0). - TLV Type 💖:
20is PKCS#7 TLV [RFC4851]. - Length 📏: the length of the PKCS #7 Data field.
- PKCS #7 Data 🔥: this field holds the X.509 certificate or certificate chain in a Certificates-Only PKCS#7 SignedData message.
5. IANA Considerations 🗂️
This section explains the criteria IANA should use when assigning Type values in the PAC attribute, PAC Type values in the PAC-Type TLV, and Credential-Format values in the Server-Trusted-Root TLV. The "Specification Required" policy applies here, with the meaning defined in BCP 26 [RFC5226]. 📋
A registry called "EAP-FAST PAC Attribute Types" has been created for the PAC attribute types. Its initial values are:
1- PAC-Key2- PAC-Opaque3- PAC-Lifetime4- A-ID5- I-ID6- Reserved7- A-ID-Info8- PAC-Acknowledgement9- PAC-Info10- PAC-Type
Values from 11 to 63 are allocated for management by Cisco. Values 64 to 255 are assigned with a "Specification Required" policy. 🌸
A registry called "EAP-FAST PAC Types" has been created for PAC-Type values used in the PAC-Type TLV. Its initial values are:
1- Tunnel PAC2- Machine Authentication PAC3- User Authorization PAC
Values from 4 to 63 are allocated for management by Cisco. Values 64 to 255 are assigned with a "Specification Required" policy. 🦋
A registry called "EAP-FAST Server-Trusted-Root Credential Format Types" has been created for Credential-Format values used in the Server-Trusted-Root TLV. Its initial value is:
1- PKCS#7-Server-Certificate-Root
Values from 2 to 63 are allocated for management by Cisco. Values 64 to 255 are assigned with a "Specification Required" policy. 💜
6. Security Considerations 🚨
Okay, this part is serious, so let's go! 😭 The Dynamic Provisioning EAP-FAST protocol shares the same security considerations outlined in [RFC4851]. On top of that, it has its own unique security considerations, described below. 🔐
6.1. Provisioning Modes and Man-in-the-Middle Attacks 🕵️♀️
EAP-FAST can be invoked in two different provisioning modes: Server-Authenticated Provisioning Mode and Server-Unauthenticated Provisioning Mode. Each mode gives a different level of resistance to man-in-the-middle attacks. Here are some of the problems linked to a man-in-the-middle attack:
- Disclosure of secret information such as keys, identities, and credentials to an attacker 😱
- Spoofing of a valid server to a peer and the distribution of false credentials 💀
- Spoofing of a valid peer and receiving credentials generated for that peer 🙈
- Denial of service 🚫
6.1.1. Server-Authenticated Provisioning Mode and Man-in-the-Middle Attacks 🛡️
In Server-Authenticated Provisioning Mode, the TLS handshake assures protected communications with the server, because the peer must have been securely pre-provisioned with the trust roots and/or other authentication information it needs to authenticate the server during the handshake. This pre-provisioning step prevents an attacker from inserting themselves as a man-in-the-middle of the communications. Unfortunately, secure pre-provisioning can be difficult to achieve in many environments. 😤
Cryptographic binding of inner authentication mechanisms to the TLS tunnel provides additional protection from man-in-the-middle attacks that come from tunneling authentication mechanisms. 🔗
Server-Authenticated Provisioning Mode provides a high degree of protection from man-in-the-middle attacks. 👑
6.1.2. Server-Unauthenticated Provisioning Mode and Man-in-the-Middle Attacks
okay so in Server-Unauthenticated Provisioning Mode 🥺, the TLS handshake does NOT actually guarantee protected comms with the server 💀. that's because either an anonymous handshake gets negotiated, or the peer just doesn't have the info it needs to finish authenticating the server. so an attacker can literally slide right into the middle of the TLS conversation 🙈 (the man-in-the-middle, MITM, era is real).
EAP-FAST Server-Unauthenticated Provisioning Mode fights back against the MITM with a couple of techniques 💪✨:
- Binding the phase 2 authentication method to secret values derived from the phase 1 TLS exchange:
okay this one is so clever 🧠. with EAP-FAST-MSCHAPv2 running over an anonymous Diffie-Hellman ciphersuite, the challenges for the EAP-FAST-MSCHAPv2 exchange are derived from the TLS handshake, and they're NOT sent over the air inside the EAP-FAST-MSCHAPv2 exchange 🤯. so the MITM doesn't know those challenges, and it can't successfully impersonate the server unless it manages to crack the EAP-FAST-MSCHAPv2 message from the peer before the peer times out. bestie that's a whole fail 😤.
- Cryptographic binding of secret values derived from the phase 2 authentication exchange with secret values derived from the phase 1 TLS exchange:
this one uses the cryptographic binding exchange that's already defined inside EAP-FAST 🔐. it's how the protocol spots a MITM, by binding secret info from the phase 2 EAP-FAST-MSCHAPv2 exchange with secret info from the phase 1 TLS exchange. if the two don't line up, somebody's lurking 👀.
so technically the cryptographic binding alone would be enough to mitigate the MITM 🙌. BUT binding the EAP-FAST-MSCHAPv2 random challenge derivations to the TLS key agreement protocol means you get EARLY detection of a MITM 🚨. this guards against adversaries who would otherwise just relay the inner EAP authentication messages between the real peer and the real server 🕵️♀️, because the adversary has to successfully respond with a valid challenge response. no cheating allowed, periodt 💅.
The ciphersuite used to establish phase 1 of the Server- Unauthenticated Provisioning Mode MUST be one in which both the peer and server provide contribution to the derived TLS master key 🔑. ciphersuites that use RSA key transport do NOT meet this requirement 🙅♀️. the authenticated and anonymous ephemeral Diffie-Hellman ciphersuites do provide this type of key agreement ✨.
This document specifies EAP-FAST-MSCHAPv2 as the inner authentication exchange 🎀. however, it's possible other inner authentication mechanisms to authenticate the tunnel may be developed in the future 🔮. the strength of the man-in-the-middle protection is directly dependent on the strength of the inner method, so it is RECOMMENDED that any inner method used provide at least as much resistance to attack as EAP-FAST-MSCHAPv2 💪. cleartext passwords MUST NOT be used in Server-Unauthenticated Provisioning Mode 🚫. also, an active man-in-the-middle attack may observe the phase 2 authentication method exchange until the point that the peer determines that authentication mechanism fails or is aborted 😭. that means sensitive info like identity or authentication protocol exchanges can get disclosed to the MITM. not it 💀.
6.2. Dictionary Attacks
it's giving password vibes 🔐. a lot of phase 2 authentication mechanisms are based on password credentials, and those exchanges can be vulnerable to both online and off-line dictionary attacks 😬. the two provisioning modes give different levels of protection from these attacks 🫶.
In online dictionary attacks, the attacker tries to discover the password by repeatedly attempting authentication with a guessed password 🎲. neither mode prevents this type of attack by itself 🙃. implementations should provide controls that limit how often an attacker can execute authentication attempts 🛑.
In off-line dictionary attacks, the attacker captures information that can be processed off-line to recover the password 🕵️♀️. Server-Authenticated Provisioning Mode provides effective mitigation here because the peer will not engage in phase 2 authentication without first authenticating the server during phase 1 🙌. Server-Unauthenticated Provisioning Mode IS vulnerable to this type of attack 😤. if, during phase 2 authentication, a peer receives no response or an invalid response from the server, then there is a possibility that a man-in-the-middle attack is in progress 🚨. implementations SHOULD log these events and, if possible, provide warnings to the user 📝. implementations are also encouraged to provide controls, appropriate to their environment, that limit how and where Server-Unauthenticated Provisioning Mode can be performed 🧠. for example, an implementation may limit this mode to be used only on certain interfaces, or require user intervention before allowing this mode if provisioning has succeeded in the past 🙋♀️.
Another mitigation technique that should not be overlooked is choosing good passwords 💖. you want sufficient complexity and length, plus a password-changing policy that requires regular password changes 🔄.
6.3. Considerations in Selecting a Provisioning Mode
okay so Server-Authenticated Provisioning Mode gives MUCH better protection from attacks than Server-Unauthenticated Provisioning Mode 🏆. so Server-Authenticated Provisioning Mode SHOULD be used whenever possible 🙌. BUT Server-Unauthenticated Provisioning Mode is still a viable option 🌸, because there may be deployments that can physically confine devices during provisioning, or that are willing to accept the risk of an active dictionary attack 🤷♀️. it's also the ONLY option that enables zero-touch provisioning, and it facilitates simpler deployments that need little to no peer configuration 🧚. the peer MAY choose to use alternative secure out-of-band mechanisms for PAC provisioning that afford better security than the Server Unauthenticated Provisioning Mode 🦋.
6.4. Diffie-Hellman Groups
to encourage interoperability 🤝, implementations of EAP-FAST, anonymous provisioning modes MUST support the 2048-bit group "14" in [RFC3526] 🔢.
6.5. Tunnel PAC Usage
the basic usage of the Tunnel PAC is to establish the TLS tunnel 🚇. in this operation it does NOT have to provide user authentication, because user authentication is expected to happen in phase 2 of EAP-FAST 🙅♀️. the EAP-FAST Tunnel PAC MAY contain information about the identity of a peer, to prevent a particular Tunnel PAC from being used to establish a tunnel that can perform phase 2 authentication for other peers 🔒. while it's possible for the server to accept the Tunnel PAC as authentication for the peer, many current implementations do not do this 🤓. the ability to use PAC to authenticate peers and provide authorizations will be the subject of a future document 🔮. [RFC5077] gives an example PAC-Opaque format in the Recommended Ticket Construction section 🎟️.
6.6. Machine Authentication PAC Usage
in general, the Machine Authorization PAC is expected to provide the minimum access a machine needs without a user 🤖. this will typically be a subset of the privilege a registered user has 💅. the server provisioning the PAC should include the information needed to validate it at a later point in time 🗓️. this would include expiration information ⏰. the Machine Authentication PAC includes a key, so it can be used as a Tunnel PAC 🗝️. the PAC-Key MUST be kept secret by the peer 🤫.
6.7. User Authorization PAC Usage
the User Authorization PAC provides the privilege associated with a user 👑. the server provisioning the PAC should include the information needed to validate it at a later point in time 📅. this includes expiration and other info associated with the PAC 🧾. the User Authorization PAC is a bearer credential, so it does not have a key that is used to authenticate its ownership 🎫. for this reason, this type of PAC MUST NOT be sent in the clear 🚫. for additional protection, the PAC MAY be bound to a Tunnel PAC used to establish the TLS tunnel 🔗. on the peer, the User Authorization PAC SHOULD only be accessible by the user for whom it is provisioned 🙋♀️.
6.8. PAC Storage Considerations
the main goal of EAP-FAST is to protect the authentication stream over the media link 🛡️. BUT host security is still an issue 😬. some care should be taken to protect the PAC on both the peer and the server 🔐. the peer must securely store both the PAC-Key and PAC-Opaque, while the server must secure storage of its security association context used to consume the PAC-Opaque 🗄️. also, if alternate provisioning is employed, the transportation mechanism used to distribute the PAC must be secured too 🚚.
most of the attacks described here would take a fair amount of effort to pull off, conceivably more effort than they're worth 💤. so the main focus should be making sure proper protections are used on both the peer and server 💖. there are a number of potential attacks against secure key storage to keep in mind 👀:
- Weak Passphrases
on the peer side, keys are usually protected by a passphrase 🔑. in some environments, this passphrase may be tied to the user's password 😵. either way, if an attacker can obtain the encrypted key for a range of users, they may be able to successfully attack a weak passphrase 💀. the tools are already in place today to let an attacker easily go after all users in an enterprise environment through email viruses and other techniques 📧🦠.
- Key Finding Attacks
key finding attacks are usually mentioned in reference to web servers 🖥️. the private Secure Socket Layer (SSL) key may be stored securely, but at some point it has to be decrypted and stored in system memory 🧠. an attacker with access to system memory can actually find the key by identifying its mathematical properties 🔍. to date, this attack appears to be purely theoretical, and it mainly acts to argue strongly for secure access controls on the server itself, to prevent unauthorized code from executing 🔒.
- Key duplication, Key substitution, Key modification
once keys are accessible to an attacker on either the peer or server, they fall under three forms of attack: key duplication, key substitution, and key modification 😱. the first option would be the most common, letting the attacker masquerade as the user in question 🎭. the second option could have some use if an attacker could implement it on the server 🖥️. alternatively, an attacker could use one of the latter two attacks on either the peer or server to force a PAC re-key, and take advantage of the potential MITM/dictionary attack vulnerability of the EAP-FAST Server-Unauthenticated Provisioning Mode ⚠️.
another consideration is the use of secure mechanisms afforded by the particular device 📱. for instance, some laptops enable secure key storage through a special chip 💻. it would be worthwhile for implementations to explore the use of such a mechanism 🌈.
6.9. Security Claims
the [RFC3748] security claims for EAP-FAST are given in Section 7.8 of [RFC4851] 📜. when using anonymous provisioning mode, there's a greater risk of off-line dictionary attack, since it's possible for a man-in-the-middle attack to capture the beginning of the inner EAP-FAST-MSCHAPv2 conversation 😭. HOWEVER, as noted previously, it IS possible to detect the man-in-the-middle attack 🕵️♀️✨.
7. Acknowledgements 🦋
okay so the EAP-FAST design came from a squad of brilliant people, and the authors gave them all the credit 🫶 Pad Jakkahalli, Mark Krischer, Doug Smith, Ilan Frenkel, Max Pritikin, Jan Vilhuber, and Jeremy Steiglitz all brought ideas and contributions that shaped the design and the protocol spec. The authors also thanked Jouni Malinen, Pasi Eronen, Jari Arkko, Chris Newman, Ran Canetti, and Vijay Gurbani for reviewing the document. literal legends 👑✨
8. References 📚
8.1. Normative References
These are the docs you NEED to read to actually understand the protocol, bestie 💅
[EAP-MSCHAPv2]Microsoft Corporation, "MS-CHAP: Extensible Authentication Protocol Method for Microsoft Challenge Handshake Authentication Protocol (CHAP) Specification", January 2009. http://msdn2.microsoft.com/en-us/library/cc224612.aspx[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.[RFC2311]Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.[RFC2315]Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.[RFC3079]Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)", RFC 3079, March 2001.[RFC3526]Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.[RFC3629]Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.[RFC3748]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.[RFC4851]Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007.[RFC5077]Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.[RFC5246]Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.[RFC5421]Cam-Winget, N. and H. Zhou, "Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", RFC 5421, March 2009.
8.2. Informative References
Nice-to-know reading, not required, but very cute if you do 🌸
[RFC5226]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
Appendix A. Examples 🧚
Okay this is the fun part!! These examples walk through the whole conversation step by step, so you can see exactly who says what and when 🎀
A.1. Example 1: Successful Tunnel PAC Provisioning ✨
This one shows anonymous DH with a successful EAP-FAST-MSCHAPv2 exchange inside phase 2 to provision a Tunnel PAC. Here's how the conversation 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 without
PAC-Opaque in SessionTicket extension)->
<- EAP-Request/EAP-FAST
(TLS Server Hello,
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
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// First EAP Payload TLV is piggybacked on the TLS Finished as
Application Data and protected by the TLS tunnel
EAP Payload TLV
(EAP-Response/Identity) ->
<- EAP Payload TLV
(EAP-Request/EAP-FAST-MSCHAPv2
(Challenge))
EAP Payload TLV
(EAP-Response/EAP-FAST-MSCHAPv2
(Response)) ->
<- EAP Payload TLV
(EAP-Request/EAP-FAST-MSCHAPv2)
(Success))
EAP Payload TLV
(EAP-Response/EAP-FAST-MSCHAPv2
(Success)) ->
<- Intermediate Result TLV(Success)
Crypto-Binding-TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC)
Intermediate Result TLV (Success)
Crypto-Binding-TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC)
PAC-TLV (Type=1)
<- Result TLV (Success)
PAC TLV
Result TLV (Success)
PAC Acknowledgment ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-FailureA.2. Example 2: Failed Provisioning 💀
This one shows a failed EAP-FAST-MSCHAPv2 exchange inside phase 2, where the peer failed to authenticate the server. Oof, rough day 😭
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
SessionTicket extension)->
<- EAP-Request/EAP-FAST
(TLS Server Hello
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
(Subsequent messages sent within the TLS channel,
encapsulated within EAP-FAST)
// First EAP Payload TLV is piggybacked on the TLS Finished as
Application Data and protected by the TLS tunnel
EAP Payload TLV
(EAP-Response/Identity)->
<- EAP Payload TLV
(EAP-Request/EAP-FAST-MSCHAPv2
(Challenge))
EAP Payload TLV
(EAP-Response/EAP-FAST-MSCHAPv2
(Response)) ->
<- EAP Payload TLV
(EAP-Request EAP-FAST-MSCHAPv2
(Success))
// peer failed to verify server MSCHAPv2 response
EAP Payload TLV
(EAP-Response/EAP-FAST-MSCHAPv2
(Failure)) ->
<- Result TLV (Failure)
Result TLV (Failure) ->
TLS channel torn down
(messages sent in cleartext)
<- EAP-FailureA.3. Example 3: Provisioning an Authentication Server's Trusted Root Certificate 🔐
This one shows a successful provisioning of a server trusted root certificate, using anonymous DH and an EAP-FAST-MSCHAPv2 exchange inside phase 2. The conversation goes like this:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Requese/EAP-FAST
(s=1, A-ID)
EAP-Response/EAP-FAST
(TLS Client Hello without
SessionTicket extension)->
<- EAP-Request/EAP-FAST
(TLS Server Hello,
(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 on the TLS Finished as
Application Data and protected by the TLS tunnel
EAP-Payload TLV
(EAP-Response/Identity) ->
<- EAP Payload TLV
(EAP-Request/EAP-FAST-MSCHAPv2
(Challenge))
EAP Payload TLV
(EAP-Response/EAP-FAST-MSCHAPv2
(Response)) ->
<- EAP Payload TLV
(EAP-Request/EAP-FAST-MSCHAPv2
(success))
EAP Payload TLV
(EAP-Response/EAP-FAST-MSCHAPv2
(Success) ->
<- Intermediate Result TLV(Success)
Crypto-Binding TLV (Version=1,
EAP-FAST Version=1, Nonce,
CompoundMAC),
Intermediate Result TLV(Success)
Crypto-Binding TLV (Version=1
EAP-FAST Version=1, Nonce,
CompoundMAC)
Server-Trusted-Root TLV
(Type = PKCS#7) ->
<- Result TLV (Success)
Server-Trusted-Root TLV
(PKCS#7 TLV)
Result TLV (Success) ->
// TLS channel torn down
(messages sent in cleartext)
<- EAP-FailureAuthors' Addresses 💖
The four brilliant authors, all from Cisco Systems, so you know who to thank when this all works 🍓
Nancy Cam-Winget
Cisco Systems
3625 Cisco Way
San Jose, CA 95134
US
EMail: ncamwing@cisco.comDavid McGrew
Cisco Systems
3625 Cisco Way
San Jose, CA 95134
US
EMail: mcgrew@cisco.comJoseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
US
EMail: jsalowey@cisco.comHao Zhou
Cisco Systems
4125 Highlander Parkway
Richfield, OH 44286
US
EMail: hzhou@cisco.com📦 where this page comes from
- ietf: rfc5422 2009-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms