RFC 7029
Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding
RFC 7029: Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding 🎀 (Part 1 of 4)
okay bestie, the title block first because it's the ID card of this doc 🪪✨
- Series: Internet Engineering Task Force (IETF) 🌸
- RFC number: 7029 💖
- Authors: S. Hartman and M. Wasserman, both from Painless Security, plus D. Zhang from Huawei 🫶
- Category: Informational (not a Standards Track spec, just here to share info) 📚
- ISSN: 2070-1721
- Date: October 2013 🍓
- Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🙅♀️
Abstract
so EAP keeps evolving, and peers are relying more and more on what the EAP server tells them 👀 Extensions like channel binding or network posture info usually ride inside tunnel methods, and peers are likely to actually trust that info 🥺 Cryptographic binding is the thing from RFC 3748 that protects tunnel methods from man-in-the-middle attacks, BUT it's mostly focused on protecting the server and not the peer 💅 This memo digs into the attacks that show up when the peer isn't protected from MITM, and it recommends cryptographic binding based on an Extended Master Session Key. That's a brand new form of cryptographic binding that protects both the peer AND the server, plus some other mitigations 🦋 main character energy for sure ✨
Status of This Memo
this part is the legal-ish bit, but here's the tea 🫖 This doc is not an Internet Standards Track spec. It's published for informational purposes only 📖
It is a product of the IETF, meaning it reflects the consensus of the IETF community 🤝 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✅ Not every IESG-approved doc is eligible for any level of Internet Standard though, so check Section 2 of RFC 5741 if you're curious 🧐
You can find the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7029 🔗
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. ©️🌈
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc 📜 Any Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🫡
Table of Contents 🗺️
1. Introduction ....................................................3
1.1. Keywords for Requirement Levels ............................5
2. An Example Problem ..............................................5
3. The Server Insertion Attack .....................................6
3.1. Conditions for the Attack ..................................7
3.2. Mitigation Strategies ......................................8
3.2.1. Server Authentication ...............................8
3.2.2. Server Policy .......................................9
3.2.3. Existing Cryptographic Binding .....................12
3.2.4. Introducing EMSK-Based Cryptographic Binding .......12
3.2.5. Mix Key into Long-Term Credentials .................14
3.3. Intended Intermediates ....................................14
4. Recommendations ................................................15
4.1. Mutual Cryptographic Binding ..............................15
4.2. State Tracking ............................................15
4.3. Certificate Naming ........................................16
4.4. Inner Mixing ..............................................16
5. Survey of Tunnel Methods .......................................16
5.1. Tunnel EAP (TEAP) Method ..................................16
5.2. Flexible Authentication via Secure Tunneling (FAST) .......17
5.3. EAP Tunneled Transport Layer Security (EAP-TTLS) ..........17
6. Security Considerations ........................................17
7. Acknowledgements ...............................................18
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................181. Introduction ✨
okay so EAP [RFC3748] handles authentication between a peer (basically whoever is trying to access some service) and an authentication server 🔐 Traditionally, peers haven't leaned on info from EAP servers all that much 🙈 BUT facilities like EAP channel binding [RFC6677] give the peer confirmation about the resource it's actually accessing 🎯 And other stuff like EAP Posture Transport [PT-EAP] lets a peer and an EAP server chat about the security properties of the networks being accessed 🛡️ Here's the catch: both of these give peers info they need to rely on, AND they hand attackers who can impersonate an EAP server to a peer brand new ways to attack 😬
Instead of bolting these facilities onto every EAP method, people have focused on adding support to tunnel methods [RFC6678] 🚇 There are tons of tunnel methods, including [RFC4851] and [RFC5281], and there's work underway on a Standards Track tunnel method called [TEAP] 💜 Tunnel methods are extensible, so if you add an extension for something like channel binding to a tunnel method, that extension works with any inner method carried in the tunnel 🧚
Tunnel methods gotta be careful about man-in-the-middle attacks 🕵️♀️ Check out [RFC6678] (Sections 3.2 and 4.6.3) and [TUNNEL-MITM] for a detailed breakdown. For example, an attack can happen when a peer is willing to do authentication both inside and outside a tunnel. The attacker pretends to be the EAP server and offers the inner method to the peer 🎭 Then, on the other side, the attacker is a man-in-the-middle and opens a tunnel to the real EAP server 😭 Figure 1 shows this attack. By the end, the EAP server thinks it's talking to the peer. At the inner method level, that's true! At the outer method level, though, the server is actually talking to the attacker 💀
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+-------X-------->| |
| (Intercepted by an Attacker) | |
| | | |
| | Tunnel Establishment |
| |<-------------------------------->|
| | | |
| |..................................|
| | Tunnel |
| Non-Tunneled | | |
| Method | Tunneled Authentication Method |
|<===================>|<================================>|
| | | |
| |..................................|
| | | |
| | Attacker |<--- MSK keys --|
| | Connected as | |
| | Peer | |
| |<--------------->| |A classic tunnel attack where the attacker inserts an extra tunnel between the attacker and EAP server.
Figure 1: Classic Tunnel Attackthere are two mitigation strategies for this classic attack 🛠️ First, security policy can be set up so the same method isn't offered by a server both inside and outside a tunnel 🙅♀️ Second, there's a technical fix if the inner method is sufficiently strong: cryptographic binding 🔗 It's a security property of a tunnel method where the EAP server confirms that the inner and outer parties are the same person (well, the same party) 🫶 It's usually done by making the outer party, the other end of the tunnel, prove it knows the Master Session Key (MSK) of the inner method ✅ That proves to the server that both exchanges are with the same party. RFC 3748's definition of cryptographic binding also allows for an optional proof to the peer that the inner and outer exchanges are with the same party. But as we'll see below, proving knowledge of the MSK is not enough to prove that to the peer 🚨
1.1. Keywords for Requirement Levels 🎀
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]. 📏
That's the end of Part 1! Part 2 picks up with Section 2 and the example problem, so stay tuned 💅🌸
2. An Example Problem ✨
Okay so the GSS-EAP (Generic Security Service Extensible Authentication Protocol) mechanism [GSS-EAP] does application authentication using EAP 🦋. A peer could reasonably trust some apps way more than others. If the peer sends confidential info to certain apps, an attacker can get seriously big value by convincing the peer that they're the trusted app 😭. Channel bindings exist to tell the peer which application service they're actually connecting to 🫶. Before channel bindings, peers couldn't tell one Network Access Service (NAS) from another, so attacks where one NAS impersonated another were out of scope. BUT channel bindings add that ability, and that expands the threat model of EAP. So the GSS-EAP mechanism needs to be able to tell one service from another 👑.
Let's run an example. A pretty untrusted service, say a print server, gets compromised 💀. Meanwhile a user is trying to connect to a trusted service, like a financial app. Both the print server and the financial app use an Authentication, Authorization, and Accounting protocol (AAA) to carry EAP authentication back to the user's EAP server. The print server pulls off a man-in-the-middle attack on the user's connection to the financial app and claims to be the app 🙈.
The print server offers a tunnel method to the peer. Then it pulls the inner method out of the tunnel and sends it along to the AAA server. Channel binding happens at the tunnel method though, so the print server is totally happy to confirm that it's the financial application 🍓. After the inner method finishes, the EAP server sends the MSK to the print server over the AAA protocol. If only the MSK is needed for cryptographic binding, the print server can pass cryptographic binding and might be able to impersonate the financial application to the peer 😈.
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+----X----------->| |
| (Intercepted by an Attacker) | |
| | | |
| | | |
| Tunnel Establishment| | |
|<------------------->| | |
|.....................| | |
| Tunnel | | |
| | |
| Tunneled | Non-Tunneled |
| Method | Authentication Method |
|<===================>|<================================>|
| |(Same as Inner Method from Tunnel)|
|.....................| | |
| | | |
| Peer | | |
| Connected to |<----------------------MSK keys --|
| Attacker | | |
|<------------------->| | |
| | | |A modified tunnel attack when an extra server rather than extra client is inserted.
Figure 2: Channel Binding Requires More than Cryptographic Binding
This attack isn't specific to GSS-EAP, btw 🌈. The channel bindings specification [RFC6677] lays out a bunch of situations where channel bindings matter for network access. In those situations, one NAS could impersonate another using a similar attack 🎀.
3. The Server Insertion Attack
The previous section gave us an example of the server insertion attack 🧚. In this attack, one party adds a layer of tunneling so that, from the EAP peer's point of view, there are more methods than there are from the EAP server's point of view. This attack is most useful when the party inserting the extra tunnel is a legit NAS, so mitigations need to be able to stop a legitimate NAS from inappropriately adding a layer of tunneling 🔥. Some deployments use an intentional intermediary that adds an extra level of EAP tunneling between the peer and the EAP server. See Section 3.3 for a discussion of that 💜.
3.1. Conditions for the Attack
For an inserted server attack to be worth it, the attacker needs to gain an advantage from it. Here's how an attacker could get one ✨:
- The attacker can send information to a peer that the peer would trust from the EAP server but not from the attacker. Examples of this include channel-binding responses.
- The peer sends information to the attacker that was meant for the EAP server. For example, the inner user identity may disclose privacy-sensitive info. The channel-binding request may disclose which service the peer wants to connect to 🙈.
- The attacker may influence session parameters. For example, if the attacker can influence the MSK, then the attacker may be able to read or influence session traffic and mount an attack on the confidentiality or integrity of the resulting session 😬.
- An attacker may impact availability of the session. In practice though, an attacker that can pull off a server insertion attack is likely to be able to impact availability in other ways 💀.
For this attack to be possible, the following conditions need to hold:
- The attacker needs to be able to establish a tunnel method with the peer over which the peer will authenticate.
- The attacker needs to be able to respond to any inner authentication. For example, an attacker who is a legitimate NAS can forward the inner authentication over AAA towards the EAP server. Note that the inner authentication may not be EAP.
- Typically, the attacker needs to be able to complete the tunnel method after inner authentication. This may not be necessary if the attacker is gaining advantage from information sent by the peer over the tunnel.
- In some cases, the attacker may need to complete a Secure Association Protocol (SAP) or otherwise demonstrate knowledge of the MSK after the tunnel method successfully completes.
Attackers who are legitimate NASes are the primary focus of this memo 👑. Previous work has already provided mitigation against attackers who are not NASes, and those mitigations are briefly discussed.
3.2. Mitigation Strategies
3.2.1. Server Authentication
If the peer confirms the identity of the party that the tunnel method is established with, then the peer stops the first condition (an attacker establishing a tunnel method) 🫶. Lots of tunnel methods rely on Transport Layer Security (TLS) [RFC5281] [TEAP]. The specs for these methods tend to encourage or mandate certificate checking. If the TLS certificate validates back to a trust anchor and the identity of the tunnel method server is confirmed, then the first attack condition can't be met 🔒.
Lots of challenges make server authentication hard, honestly 😩. There isn't an obvious name to identify a tunnel method server by. It's not obvious where in the tunnel server certificate the name should be found. One especially problematic practice is using a certificate that names the host the tunnel server runs on. With a name like that, it's super hard for a peer to figure out whether that server is actually meant to be a tunnel method server for the realm.
It's also not clear which trust anchors to use for tunnel servers. Using commercial Certificate Authorities (CAs) is probably undesirable, because tunnel servers often operate in a closed community and are often provisioned with certificates issued by that community. Using commercial CAs can be especially problematic with peers that support hostnames in certificates. Then anyone who can get a certificate for any host in the domain being contacted can impersonate a tunnel server 🚨.
These difficulties lead to poor deployment of good certificate validation. Many peers make it easy to disable certificate validation. Other peers validate back to trust anchors but don't check certificate names. Which name types are supported, and what configuration is easy to set up, depend a lot on the peer in question 🌸.
Specifications make the problem worse too. For example, [RFC5281] says that the only impact of failing to perform certificate validation is that the inner method can be attacked. Administrators and implementors who believe this claim may think that protection from passive attacks is enough, which is not the vibe we want 😭.
Also, some deployments, such as provisioning or strong inner methods, are designed to work without certificate validation. Section 3.9 of the tunnel requirements document [RFC6678] discusses this requirement 📚.
3.2.2. Server Policy 🎀
Okay, so server policy can potentially stop the second condition (attacker being able to respond to inner authentication) from ever being possible 🔒. If the server only runs a particular inner authentication inside a tunnel, the attacker can't get a response to that inner auth unless there's a tunnel. The attacker might stack a second layer of tunnels, though (check out Figure 3 👀). The inner tunnel can also limit what the attacker can do. For example, if channel binding happens over tunnel t2 in the figure, then the attacker can't observe it or influence it 💅.
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+----X----------->| |
| (Intercepted by an Attacker) | |
| | | |
| | | |
| Tunnel Establishment| | |
|<------------------->| | |
|.....................| | |
| Tunnel t1 | | |
| | | |
|.......................................... .............|
| Tunnel t2 |
| |
| |
| Inner Method |
|<======================================================>|
| |
|.......................................... .............|
| | | |
|.....................| | |
| | | |
| Peer | | |
| Connected to |<----------------------MSK keys --|
| Attacker | | |
|<------------------->| | |
| | | |So picture it: tunnel t1 runs from the peer to the attacker and contains tunnel t2, which runs from the peer to the home EAP server. Inside t2 sits the inner authentication 🪆.
Figure 3: Multiple Layered Tunnels 🌈
Peer policy can team up with this server policy to help prevent conditions 1 (attacker can establish a tunnel the peer will use) and 2 (attacker can respond to inner authentication) 🫶. If the peer requires exactly one tunnel of a particular type, and the EAP server only performs inner authentication over a tunnel of that type, then the attacker can't establish tunnel t1 from the figure above. Heads up though: configuring this peer policy can be trickier than configuring policy on the EAP server 😭.
An attacker might still be able to pull off a more traditional man-in-the-middle attack in this situation, see Figure 4 👀. This policy on the peer and EAP server, combined with a tunnel method that supports cryptographic binding, lets the EAP server detect the attacker 🔥. That means the attacker can't act as a legitimate NAS and, in particular, doesn't get the MSK. So if the tunnel between the attacker and peer also requires cryptographic binding, and that binding requires both the EAP server and peer to prove knowledge of the inner MSK, then the authentication fails. If cryptographic binding isn't performed, though, this attack may succeed 💀.
Peer Attacker Service AAA Server
| | | |
| | | |
|Peer Initiates Connection to a Service | |
|---------------------+----X----------->| |
| (Intercepted by an Attacker) | |
| | | |
| | | |
| Tunnel Establishment| Tunnel Establishment |
|<------------------->|<-------------------------------->|
|.....................|.................... .............|
| Tunnel t1 | Tunnel t2 |
| | |
| Tunneled | |
| Method | Tunneled Method |
|<===================>|<================================>|
| | |
|.....................|..................................|
| | | |
| Peer | | |
| Connected to | | |
| Attacker | | |
|<------------------->| | |
| | | |Here, tunnel t1 goes from the peer to the attacker, and tunnel t2 goes from the attacker to the home EAP server. The attacker forwards the inner EAP authentication unmodified from tunnel t1 to tunnel t2, and the attacker can observe this inner authentication 👁️.
Figure 4: A Traditional Man-in-the-Middle Attack 🍓
Cryptographic binding only counts as a valuable part of a defense when the inner authentication is a key-deriving EAP method 🔑. Most tunnel methods also support non-EAP inner authentication, like Microsoft CHAP version 2 [RFC2759]. That can undermine cryptographic binding in a few ways 🙈. An attacker might be able to turn an EAP method into a compatible non-EAP form of the same credential, which suppresses cryptographic binding. Plus, an inner authentication might be available through a totally different route. For example, a Lightweight Directory Access Protocol [RFC4510] or other directory server could give an attacker a way to get challenges and provide responses for an authentication mechanism that's completely outside the AAA/EAP context. An attacker with that power might get around server policy that requires an inner authentication to be used only in a given type of tunnel 🧚.
To recap, the following policy conditions appear sufficient to prevent a server insertion attack ✨:
- Peer and EAP server require a particular inner EAP method used within a particular tunnel method.
- The inner EAP method's authentication is only available within the tunnel and through no other means, including non-EAP means.
- The inner EAP method produces a key.
- The tunnel method uses cryptographic binding and the peer requires the other end of the tunnel to prove knowledge of the inner MSK.
3.2.3. Existing Cryptographic Binding 💜
The most advanced cryptographic binding out there today works on two levels 🥹. First, the server and peer prove to each other that they know the inner MSK. Then the inner MSK gets combined with some outer key material to form the tunnel's EAP keys. This is enough to detect an inserted server or peer, as long as the attacker doesn't learn the inner MSK. That seems like enough to defend against attackers who can't act as a legitimate NAS 🛡️.
The definition of cryptographic binding in [RFC3748] doesn't require these steps, though. To meet that definition, it would be enough for a peer to prove knowledge of the inner key to the EAP server. But that would open up some extra attacks 😬. For example, an attacker might be able to mask a cryptographic binding failure by indicating success. The peer probably wouldn't be able to notice the failure, especially if only the tunnel key material is used for the final keys.
As we talked about in the previous section, cryptographic binding is only effective when the inner method is EAP 🌸.
3.2.4. Introducing EMSK-Based Cryptographic Binding 🦋
Cryptographic binding gets stronger when the inner EAP method supports an Extended Master Session Key (EMSK) 💪. The EMSK is never disclosed to any party other than the EAP server or peer, so even a legitimate NAS can't learn the EMSK. So if the same techniques used on the inner MSK get applied to the inner EMSK, then condition 3 (completing tunnel authentication) won't hold, because the attacker can't complete this new form of cryptographic binding 🙌. It doesn't stop the attacker from learning confidential stuff, though, like a channel-binding request sent over the tunnel before cryptographic binding happens 👀.
Obviously, just like all forms of cryptographic binding, this only works for key-deriving inner EAP methods 🔑. Also, some deployments (see Section 3.3) insert intermediates between the peer and the EAP server. EMSK-based cryptographic binding doesn't work with those deployments, because the intermediate can't learn the EMSK 🚫.
Formally, EMSK-based cryptographic binding is a security claim for EAP tunnel methods that holds when:
- The peer proves to the server that the peer participating in any inner method is the same as the peer for the tunnel method.
- The server proves to the peer that the server for any inner method is the same as the server for the tunnel method.
- The MSK and EMSK for the tunnel depend on the MSK and EMSK of inner methods.
- The peer MUST be able to force the authentication to fail if the peer is unable to confirm the identity of the server.
- Proofs offered need to be secure even against attackers who know the inner method MSK.
If EMSK-based cryptographic binding isn't an optional facility, it gives a strong defense against server insertion attacks and other tunnel man-in-the-middle (MITM) attacks, for inner methods that provide an EMSK 🏰. How strong the defense is depends on how strong the inner method is. EMSK-based cryptographic binding MAY be provided as an optional facility. Making it optional does weaken its value a bit, though 😅. It allows configurations where a peer uses other means to authenticate the server, as long as the peer has enough configured info to validate the EAP server's certificate and identity. Meanwhile, EMSK-based cryptographic binding still gets used in deployments where that's possible 💖.
If EMSK-based cryptographic binding is an optional facility, the negotiation of whether to use it MUST be protected by the inner MSK or EMSK. Typically the MSK will be used, because the main reason to make EMSK-based cryptographic binding optional is to let intermediates that only know the MSK decline to use it 🍵. The peer MUST have an opportunity to fail the authentication after the server declines to use EMSK-based cryptographic binding 🫣.
3.2.5. Mix Key into Long-Term Credentials ✨
okay so another defense against tunnel MITM attacks (and maybe server insertion attacks too 🕵️♀️) is to use a different credential for the tunneled methods than for everything else 🔐. This might stop the second condition (the attacker being able to answer the inner authentication) from ever happening 🙈. Like, if key material from the tunnel gets mixed into the shared secret or password that the inner authentication is built on, the attacker can't get past that condition unless they already know the shared secret 💅. The big perk is that this seems to be the only way to level up non-EAP inner authentications inside a tunnel 💜.
ngl there are some downsides 😭. Picking a function to mix the tunnel key material into the inner authentication depends a LOT on which inner authentication you're using 🧩. It also looks like a layering violation 🙃. Still, exploring this is super important, because it's the one thing that can work for inner authentications where nothing else will 🫶.
3.3. Intended Intermediates
okay this one's kinda iconic 🎀. Some deployments put a tunnel server in between the NAS and the EAP server that's separate from the EAP server 🧚. [RFC5281] has an example of this style of deployment, so check it out 🦋. The only real difference between one of these intermediates and an attacker is that the intermediate actually provides something useful to the peer or the EAP server, and the peer trusts it 🤝. If peers are set up with what they need to validate the certificates of these intermediates and confirm who they are, then tunnel MITM and inserted server attacks can be defended against 🛡️. The intermediates do need to be trusted for channel binding and any other services the peer relies on 💜.
Supporting trusted intermediates isn't a requirement under the tunnel method requirements, fr fr 💁♀️.
It seems reasonable to treat trusted intermediates as a special case if they're supported, and to focus on the case with no intermediates in the tunnel as the common case 🌸.
4. Recommendations ✨
4.1. Mutual Cryptographic Binding
The Tunnel EAP method [TEAP] should gain support for EMSK-based cryptographic binding 🔥.
As channel-binding support gets added to existing EAP methods, EMSK-based cryptographic binding (or some other form of cryptographic binding that protects against server insertion) should get added to those methods too 💅. Mutual cryptographic binding could also be really valuable once other services get added to EAP methods that make the peer trust an EAP server 🫶.
4.2. State Tracking
okay this is the main character section 👑. Right now, people think of mutual authentication in EAP as a security claim about a method. But in practice, it's really an attribute of one particular exchange 🎯. You can get mutual authentication by checking certificates, through mutual cryptographic binding, or (in very controlled cases) through carefully crafted peer and server policy combined with existing cryptographic binding 🧁. Services like channel binding, where the peer trusts the EAP server, should require that mutual authentication is present in the session 🔒.
So to make that happen, implementations that include channel binding or other peer services MUST track whether mutual authentication has happened 📋. They SHOULD default to not permitting these peer services unless mutual authentication has happened 🙅♀️. They SHOULD also support a configuration where the peer fails to authenticate unless mutual authentication takes place 💖. Whether this configuration should be recommended as a default is still up for discussion, and that discussion is required 🧐.
The Tunnel EAP method [TEAP] should let peers force an authentication failure if they can't do mutual authentication 🙅♀️. The protocol should allow this to wait until after mutual cryptographic binding has been considered ⏳.
Services such as channel binding should wait until after cryptographic binding or mutual cryptographic binding 🫷.
Here's where it gets a bit messy 🙈. When a tunnel method authenticates multiple parties (like both the peer machine and the peer user to the EAP server), only some of those parties might have confidence in the mutual authentication, depending on how it was achieved 🤔. For example, if a strong shared secret is used to mutually authenticate the user and the EAP server, the machine might not feel confident that the EAP server is really the party it authenticated. That's especially true if the machine can't trust the user not to leak the shared secret to an attacker 😬. In these cases, the parties that actually achieved mutual authentication need to be considered when deciding whether to use peer services 💅.
4.3. Certificate Naming
Work is required to promote interoperable deployment of server certificate validation by peers 🛠️. A standard way to name EAP servers is required. Recommendations for which name forms peers should implement are required too 📛.
4.4. Inner Mixing
More consideration of the proposal to mix some key material into inner authentications is desired 🤔. Right now the proposal is under-defined and pretty invasive 😵💫. Are there versions of it that would be valuable? And is there a way to view it more abstractly, so it doesn't end up as a combinatorial explosion from considering every specific tunnel and inner method? 🧠💥
5. Survey of Tunnel Methods 🌈
5.1. Tunnel EAP (TEAP) Method
The Tunnel EAP method [TEAP] has several features designed to limit man-in-the-middle vulnerabilities and provide a safe platform for peer services 🦋.
TEAP implementations support checking the Network Access Identifier (NAI) realm portion against a DNS subjectAlternativeName in the certificate of the TEAP server ✅. TEAP supports EMSK-based cryptographic binding as a way to achieve mutual cryptographic binding. It also supports MSK-based cryptographic binding for cases where the EMSK isn't available, but this kind of binding doesn't give enough assurance for peer services 🙃. TEAP gives recommendations on the conditions that need to be met before using peer services 📝. Those recommendations spell out when MSK-based cryptographic binding is enough, and when EMSK-based cryptographic binding is required 💜. TEAP meets the recommendations for implementations outlined in this memo 🎀.
5.2. Flexible Authentication via Secure Tunneling (FAST)
EAP-FAST [RFC4851] provides MSK-based cryptographic binding 🔐. EAP-FAST requires that server certificates be validated. However, no guidance is given on how servers are named, so the specification doesn't give enough guidance to enforce this requirement interoperably 😤.
EAP-FAST doesn't support channel binding or other peer services. The protocol is extensible though, so TLVs could be defined for peer services 🧩. If the certificates really get validated and the names get checked, EAP-FAST would provide security guarantees good enough to use these peer services 💅. But the cryptographic binding in EAP-FAST isn't strong enough to secure peer services if the server certificate isn't validated and name checked 🚫.
5.3. EAP Tunneled Transport Layer Security (EAP-TTLS)
The EAP Tunneled Transport Layer Security Version 0 (EAP-TTLS) [RFC5281] doesn't support cryptographic binding 🙈. It also doesn't support peer services such as channel binding, though they could be added using extensible AVPs 🧚.
EAP-TTLS recommends that implementations SHOULD validate certificates, but it gives no guidance on how to handle naming 📛. Even if certificates get validated, EAP-TTLS isn't really suited to peer services 😩. For example, EAP-TTLS doesn't include a protected result indication. So an unprotected EAP success packet can end the authentication 💀. It's also hard for a peer to request services like channel binding, because the server ends the authentication as soon as authentication succeeds 🙃.
A bunch of extensions, including EAP-TTLS version 1, help with some of these concerns ✨. The specification and implementation issues make those extensions tricky to analyze 🧐. For example, most implementations can be tricked into using EAP-TTLS version 0 😭.
6. Security Considerations 🔥
This memo looks at the security considerations of providing new classes of service within EAP methods 🛡️. Traditionally, the main focus of EAP is authenticating the peer to the network. But because the peer places trust in the EAP server, mutual authentication becomes even more important 💥. This memo examines the security of mutual authentication for EAP tunnel methods, and honestly it's a whole mood 😤.
7. Acknowledgements 🫶
The authors would like to thank Alan DeKok for helping to explore these attacks 💖. Alan focused the discussion on the importance of inner authentications that aren't EAP, and proposed mixing in key material as a way to resolve them 🧠.
Jari Arkko provided a review of the attack and valuable context on past efforts to develop cryptographic binding 👑.
Sam Hartman's and Margaret Wasserman's work on this memo is funded by Huawei 💜.
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.8.2. Informative References
[GSS-EAP] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the
Extensible Authentication Protocol", Work in Progress,
August 2012.
[PT-EAP] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport
(PT) Protocol For EAP Tunnel Methods", Work in Progress,
March 2013.
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC
2759, January 2000.
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, June
2006.
[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.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding
Support for Extensible Authentication Protocol (EAP)
Methods", RFC 6677, July 2012.
[RFC6678] Hoeper, K., Hanna, S., Zhou, H., and J. Salowey,
"Requirements for a Tunnel-Based Extensible Authentication
Protocol (EAP) Method", RFC 6678, July 2012.
[TEAP] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel EAP Method (TEAP) Version 1", Work in Progress,
September 2013.
[TUNNEL-MITM]
Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
in Tunnelled Authentication Protocols", Cryptology ePrint
Archive: Report 2002/163, November 2002.Authors' Addresses 💌
Sam Hartman
Painless Security
EMail: hartmans-ietf@mit.edu
Margaret Wasserman
Painless Security
EMail: mrw@painless-security.com
URI: http://www.painless-security.com/
Dacheng Zhang
Huawei
EMail: zhangdacheng@huawei.com📦 where this page comes from
- ietf: rfc7029 2013-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms