RFC 6677

Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods

📅 published July 2012, from ietf

RFC 6677: Channel-Binding Support for EAP Methods 🎀

Quick title-block tea, bestie ☕

  • RFC number: 6677
  • Title: Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods
  • Authors: S. Hartman, Ed. (Painless Security), T. Clancy (Virginia Tech), and K. Hoeper (Motorola Solutions, Inc.)
  • Category: Standards Track
  • Date: July 2012
  • ISSN: 2070-1721
  • Obsoletes and updates: The title block doesn't list anything this document obsoletes or updates 💅
  • Published by: Internet Engineering Task Force (IETF)

Abstract ✨

okay so this doc is all about how to build channel bindings for EAP methods 🔐. Its whole mission is to fix two sneaky problems: the "lying Network Access Service (NAS)" problem and the "lying provider" problem. Iconic, right? 🦋

Status of This Memo 📜

This is an Internet Standards Track document, so it's an official standard, not just an idea floating around 🌸

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741 📚

For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6677 🔗

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. So, unless you get an adequate license from those copyright holders, this document can't be modified outside the IETF Standards Process, and derivative works of it can't be made outside that process either. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈

Table of Contents 📑

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5
4.  Channel Bindings . . . . . . . . . . . . . . . . . . . . . . .  7
  4.1.  Types of EAP Channel Bindings  . . . . . . . . . . . . . .  8
  4.2.  Channel Bindings in the Secure Association Protocol  . . .  9
  4.3.  Channel-Binding Scope  . . . . . . . . . . . . . . . . . . 10
5.  Channel-Binding Process  . . . . . . . . . . . . . . . . . . . 12
  5.1.  Protocol Operation . . . . . . . . . . . . . . . . . . . . 12
  5.2.  Channel-Binding Consistency Check  . . . . . . . . . . . . 14
  5.3.  EAP Protocol . . . . . . . . . . . . . . . . . . . . . . . 15
    5.3.1.  Channel-Binding Codes  . . . . . . . . . . . . . . . . 17
    5.3.2.  Namespace Identifiers  . . . . . . . . . . . . . . . . 17
    5.3.3.  RADIUS Namespace . . . . . . . . . . . . . . . . . . . 18
6.  System Requirements  . . . . . . . . . . . . . . . . . . . . . 18
  6.1.  General Transport Protocol Requirements  . . . . . . . . . 18
  6.2.  EAP Method Requirements  . . . . . . . . . . . . . . . . . 19
7.  Channel-Binding TLV  . . . . . . . . . . . . . . . . . . . . . 19
  7.1.  Requirements for Lower-Layer Bindings  . . . . . . . . . . 19
  7.2.  EAP Lower-Layer Attribute  . . . . . . . . . . . . . . . . 20
8.  AAA-Layer Bindings . . . . . . . . . . . . . . . . . . . . . . 20
9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
  9.1.  Trust Model  . . . . . . . . . . . . . . . . . . . . . . . 21
  9.2.  Consequences of Trust Violation  . . . . . . . . . . . . . 23
  9.3.  Bid-Down Attacks . . . . . . . . . . . . . . . . . . . . . 24
  9.4.  Privacy Violations . . . . . . . . . . . . . . . . . . . . 24
10. Operations and Management Considerations . . . . . . . . . . . 25
11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
  11.1. EAP Lower Layers Registry  . . . . . . . . . . . . . . . . 26
  11.2. RADIUS Registration  . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
  13.1. Normative References . . . . . . . . . . . . . . . . . . . 27
  13.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A.  Attacks Prevented by Channel Bindings . . . . . . . . 29
  A.1.  Enterprise Subnetwork Masquerading . . . . . . . . . . . . 29
  A.2.  Forced Roaming . . . . . . . . . . . . . . . . . . . . . . 29
  A.3.  Downgrading Attacks  . . . . . . . . . . . . . . . . . . . 30
  A.4.  Bogus Beacons in IEEE 802.11r  . . . . . . . . . . . . . . 30
  A.5.  Forcing False Authorization in IEEE 802.11i  . . . . . . . 30

1. Introduction 🌷

Okay, the so-called "lying NAS" problem is a well-documented problem with the current Extensible Authentication Protocol (EAP) architecture [RFC3748] when it's used in pass-through authenticator mode 🙈. Here's the tea: a Network Access Server (NAS), or pass-through authenticator, can show one set of information (like network identity, capabilities, configuration, etc.) to the backend Authentication, Authorization, and Accounting (AAA) infrastructure, while showing totally different info to EAP peers. 💀 Another option is that the NAS gives the same false info to both the EAP peer and the EAP server. And a "lying" entity doesn't have to be the NAS. It can be anywhere on the AAA path between the NAS and the EAP server 🕵️‍♀️

This problem happens when the same credentials get used to access multiple services that differ in some interesting property. The EAP server learns which client credentials are in use ✨ The client knows which EAP credentials are used, but it can't tell apart servers that use those same credentials. For methods that do distinguish between client and server credentials, either using different server credentials for access to the different services, or having client credentials with access to a disjoint set of services, can potentially defend against the attack 🛡️

Here's a concrete example. Imagine an organization with two different IEEE 802.11 wireless networks 📶 One is a relatively low-security network for browsing the web, and the other has access to valuable confidential information. An access point on the web network could act as a lying NAS by sending the Service Set Identifier (SSID) of the confidential network in its beacons 👀 That access point could get an advantage by doing this if it tricks clients who want to connect to the confidential network into connecting to it and disclosing confidential information. Yikes 😭

A similar problem shows up in the context of roaming 🧳 Here, the lying entity sits in a visited service provider network, for example trying to lure peers to connect based on falsely advertised roaming rates. This is what the rest of the document calls the "lying provider" problem. The lying entity's motivation is often financial, since it may get paid whenever peers roam to its service 💸 But a lying entity in a provider network can also get access to traffic it might not otherwise see, which is a whole other level of messy 🙃

So this document defines and implements EAP channel bindings to solve both the "lying NAS" and "lying provider" problems 💜 The process has the EAP peer share information about the characteristics of the service the authenticator provides with the AAA server, which is protected inside the EAP method. That lets the server verify that the authenticator is giving the peer information consistent with what it received from that authenticator, as well as the information stored about that authenticator ✅ The "AAA Payloads" defined in [AAA-PAY] were the starting point for the mechanism this specification uses to carry this information 🌈

2. Terminology 📖

In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]. Those are the official rules-of-the-road words, so keep them in mind as you read the rest! 🫶

3. Problem Statement ✨

okay so, with an EAP authentication that follows [RFC4017], the EAP peer and EAP server both authenticate each other AND derive keying material 🔐 that's the good part. BUT when you're in pass-through mode, the EAP server can be SO far away from the authenticator, both in network distance and in how many entities you have to trust before you can talk securely 😭. A malicious or compromised authenticator could tell the peer totally wrong stuff about the network to mess with how it operates 💀. And even if the authenticator is clean, some other compromised thing in the network (like a proxy) could feed it false info that it just passes along to EAP peers 🙈. So the goal is making sure the authenticator is giving the EAP peer correct info during the initial network discovery, selection, and authentication 🎀.

There are two kinds of networks to think about: enterprise networks and service provider networks 🏢📶. In an enterprise network, which is one administrative domain, it's totally doable for the EAP server to know about every authenticator in the network 🧠. In service provider networks, global knowledge is basically impossible because of roaming and all the indirection that comes with it 🌍. When a peer is outside its home administrative domain, the goal is that the level of service it gets matches the contract between the two service providers 📜. The same EAP server might need to handle both types of networks at once 🫶. For example, an enterprise might have a roaming agreement that lets its users connect to networks run by third-party service providers, and in that situation the EAP server may authenticate for both the enterprise network and the provider network 🦋.

The following are example attacks that become possible when false network information is presented to peers 👀:

  • Enterprise network: A corporate network might have multiple virtual LANs (VLANs) spread across its campus network, with IEEE 802.11 access points hooked up to each VLAN 🏫. Say one VLAN connects users to the firewalled corporate network, and the other connects users to a public guest network 🛜. The corporate network is assumed to be free of adversarial elements, but the guest network is assumed to possibly have malicious elements 😈. Access points on both VLANs are served by the same EAP server, but they broadcast different SSIDs so people can tell them apart 🏷️. A compromised access point that's connected to the guest network but NOT the corporate network could advertise the corporate network's SSID to lure peers into connecting, giving them a false sense of security about their traffic 🪤. Conditions and further details of this attack can be found in the appendix 📖.
  • Enterprise network: The EAP Generic Security Service Application Program Interface (GSS-API) mechanism [GSS-API-EAP] provides a way to use EAP to authenticate to mail servers, instant messaging servers, and other non-network services 💌. Without EAP channel binding, an attacker could trick the user into connecting to a relatively untrusted service instead of a relatively trusted one 😱. For example, the instant messaging service could impersonate the mail server 💀.
  • Service provider network: An EAP-enabled mobile phone provider could advertise super competitive flat rates but send per-minute rates to the home server, luring peers to connect to its network and then overcharging them 💸. In more elaborate attacks, peers can be tricked into roaming without even knowing it 🫣. For example, a mobile phone provider operating along a geopolitical boundary could boost its cell towers' transmission power and advertise the network identity of the neighboring country's local provider 📡. This would make unsuspecting handsets associate with an operator they didn't intend to use, and as a result they'd be hit with high roaming fees without realizing they'd left their home provider's network 💅. These kinds of scenarios can be considered the "lying provider" problem, because here the provider configures its NAS to broadcast false information 🤥. For the purpose of channel bindings as defined in this document, it does not matter which local entity (or entities) is "lying" in a service provider network (local NAS, local authentication server, and/or local proxies) 🤷‍♀️, because the only information received from the visited network that is verified by channel bindings is the information the home authentication server received from the last hop in the communication chain 🔗. In other words, channel bindings let you detect inconsistencies in the information from a visited network, but they can't tell you which entity is lying 🕵️‍♀️. Naturally, channel bindings for EAP methods can only verify the endpoints; if that's desirable, intermediate hops need to be protected by the employed AAA protocol 🛡️.
  • Enterprise and provider networks: In a situation where an enterprise has roaming agreements with providers, a compromised access point in a provider network could masquerade as the enterprise network in an attempt to gain confidential information 🥺. Today this could potentially be solved by using different credentials for internal and external access 🔑. Depending on the type of credential, though, this may introduce usability or man-in-the-middle security issues 😬.

To address these problems, a mechanism is required to validate unauthenticated information advertised by EAP authenticators 🎯.

4. Channel Bindings

EAP channel bindings are all about authenticating information the authenticator gave to the EAP peer that was previously unauthenticated 🔍. They do this by letting the peer and server compare how they each see the network's properties, over a secure channel 🤝.

Heads up, the definition of EAP channel bindings is a little different from the channel bindings in [RFC5056] 👀. Those ones are about securely tying together the endpoints of a multi-layer protocol, so lower layers can protect data from higher layers 🧱. EAP channel bindings don't tie different layers of a session together, though. Instead, they make sure the info advertised to an EAP peer by an authenticator (acting as the pass-through device during an EAP execution) is accurate 🎯. The term "channel bindings" was independently picked up for these two related concepts, and by the time anyone noticed the clash, there was already a big body of literature for each usage 📚. EAP channel bindings could be used to provide [RFC5056] channel bindings 🔄. Specifically, an inner EAP method could be bound to an outer method by putting the [RFC5056] channel-binding data for the outer channel into the inner EAP method's channel bindings 🪆. Doing that would give you something similar to EAP cryptographic binding, except that a man-in-the-middle couldn't pull the inner method out of the tunnel 🚫. This specification doesn't weigh the pros of doing that or say how to do it; the example is only there to show how EAP channel binding and [RFC5056] channel binding overlap 💜.

4.1. Types of EAP Channel Bindings

There are two categories of approach to EAP channel bindings 🌈:

  • After keys have been derived during an EAP execution, the peer and server can, over an integrity-protected channel, swap plaintext info about the network with each other and check that it's consistent and correct ✅.
  • The peer and server can each uniquely encode their own view of the network information WITHOUT exchanging it, which gives you an opaque blob that gets included directly in the derivation of EAP session keys 🫥.

Both approaches only apply to key-deriving EAP methods, and both have advantages and disadvantages ⚖️. Various hybrid approaches are also possible 🍓. Advantages of exchanging plaintext information include:

  • It allows for policy-based comparisons of network properties, instead of needing exact matches for every field. That gets you policy-defined consistency rather than bitwise equality, which lets network operators decide which properties matter and can even be verified in their network 🎀.
  • EAP methods that support extensible, integrity-protected channels can easily add support for exchanging this network information 🧩. By contrast, putting it directly into the key derivation would take more extensive revisions to existing EAP methods, or a wrapper EAP method 🛠️.
  • Since it doesn't affect the key derivation, this approach makes debugging, incremental deployment, and backward compatibility a lot easier 🐣. It also allows a logging mode, where verification results are recorded but don't affect the rest of the EAP execution 📝. How the verification results get used can be decided by network policy 🗂️. On top of that, consistent information canonicalization and formatting for the key derivation approach would likely cause significant deployment problems 😩.

The following are advantages of directly including channel-binding information in the key derivation:

  • EAP methods that don't support extensible, integrity-protected channels could still be supported, either by revising their key derivation, revising EAP, or wrapping them in a universal method that supports channel binding 🦄.
  • It can guarantee proper channel information, because subsequent communication would be impossible if differences in channel information produced different session keys on the EAP peer and server 🔐✨.

4.2. Channel Bindings in the Secure Association Protocol 🦋

okay so this section is about a different route for channel bindings ✨ this doc describes sending the channel-binding info as part of an integrity-protected exchange inside an EAP method. but some future doc could specify a way to carry channel bindings inside the lower layer's secure association protocol 💅 that spec would need to explain how the bindings get exchanged over the lower-layer protocol between the peer and authenticator. and bc the EAP exchange wraps up before the secure association protocol even starts 😭, a way to move the channel bindings from the authenticator to the EAP server also needs to be specified. a mechanism for sending a protected result from the EAP server, through the authenticator, back to the peer needs to be specified too 🫶

the channel bindings MUST be transported with integrity protection based on a key known only to the peer and EAP server. the channel bindings SHOULD be confidentiality protected using a key known only to the peer and EAP server. for the system to work at all, the EAP server or AAA server needs access to the channel-binding info from the peer 🔐 plus the AAA attributes and a local database (we'll get to that one later in this doc) 💜

so the big upside of sending channel bindings in the secure association protocol is that EAP methods don't need to change 🎀 the downside is that you need a brand new AAA exchange, and secure association protocols need to be changed too. and since the results of the secure association protocol change, every NAS needs upgrading to support channel bindings inside it 😩

for a lot of deployments, changing all the NASes is super expensive 💸 so adding channel-binding support to enough EAP methods to hit the deployment's goals is the cheaper move. but for a brand new piece of equipment, or especially a brand new lower-layer technology, changing the NASes might actually be cheaper than changing EAP methods 🌈 like, if a deployment needed to support a huge number of EAP methods, sending channel bindings in the secure association protocol might totally make sense 🙌 and it can even work with the EAP Re-authentication Protocol (ERP) [RFC5296], where previously established EAP key material gets used for the secure association protocol without running any EAP method during re-authentication. main character energy ✨

if somebody does specify channel bindings using a secure association protocol, the semantics and the set of info that peers exchange can be shared with the mechanism described in this document 🧚

4.3. Channel-Binding Scope 🌸

okay this one is important bestie 🧠 the scope of EAP channel bindings is kinda different depending on what kind of deployment you're in. in enterprise networks, they can be used to authenticate really specific properties of the authenticator (like the Medium Access Control (MAC) address, supported link types and data rates, etc.) 🏢 but in service provider networks, they can generally only authenticate broader stuff about a roaming partner's network (like the network name, roaming info, link security requirements, etc.) 🌍 the reason for the difference comes down to how much info about the authenticator and/or network the home EAP server is expected to have access to. in roaming cases, the home server is likely to only have access to whatever is contained in their roaming agreements 📜

with any multi-hop AAA infrastructure, a lot of the NAS-specific AAA attributes get obscured by the AAA proxy that's decrypting, reframing, and retransmitting the underlying AAA messages 🙈 service provider networks especially feel this, and the AAA info received from the last hop may not contain much verifiable info after the AAA proxies have done their thing. for example, info carried in AAA attributes like the NAS IP address may have been lost in transition, so the EAP server doesn't know it 💀 even worse, info might still be there but be totally useless, like representing the identity of a device on a private network or a middlebox 😭 this affects the EAP server's ability to verify specific NAS properties. however, verifying the MAC or IP address of the NAS is often not useful for improving the overall security posture of a network 🤷‍♀️ more often, the best approach is to make policy decisions about the services being offered to peers. like, in an IEEE 802.11 network, the EAP server might want to make sure peers connecting to the corporate intranet are using secure link-layer encryption, while link-layer security requirements for peers connecting to the guest network could be less strict 🔥 these kinds of policy decisions can be made without knowing or being able to verify the IP address of the NAS the peer is connecting through ✨

the properties of the network that the peer wants to validate depend on the specific deployment 📱 in a mobile phone network, peers generally don't care what the name of the network is, as long as they can make their call and get charged the expected amount 💅 but in an enterprise network, the administrators of a peer may care more about the specifics of where their network traffic gets routed and what VLAN is in use 🛤️ to set policies around these requirements, administrators would capture some attribute, like the SSID, to describe the network properties they care about. channel bindings could validate the SSID 🎯 the administrator would need to make sure the network guarantees that when an authenticator trusted by the AAA infrastructure to offer a particular SSID to clients does offer that SSID, the network has the intended properties. generally, it's not possible for channel bindings to detect lying NAS behavior when the NAS is authorized to claim a particular service 🫠 like, if the same physical authenticator is allowed to advertise two networks, the AAA infrastructure is unlikely to be able to tell when that authenticator is lying 👀

as the next section explains, some of the most important info to verify can't come from AAA attributes and instead comes from local configuration 📝 for example, in the mobile phone case, the expected roaming rate can't come from the roaming provider without being checked against the contract between the two providers 📄 similarly, in an enterprise, the SSID that a particular access point is expected to advertise comes from configuration rather than an AAA exchange (which can be confirmed with channel binding) 🔍

okay the trust part is so good 🥹 the peer and authenticator don't start out with any basis for trust. the peer has a credential with the EAP server, and that's what forms the basis for trust 🔑 the EAP server and authenticator have a potentially indirect trust path through the AAA infrastructure 🛣️ channel binding leverages the trust between the peer and EAP server to build trust in certain attributes between the peer and authenticator 🧩

channel bindings can be super important for forming areas of trust, especially when provider networks are involved and exact info isn't available to the EAP server 🌐 without channel bindings, every entity in the system has to be held to the standards of the most trusted entity that could be reached using the EAP credential 👑 otherwise, a less trusted entity can impersonate a more trusted entity 😱 but when channel bindings are used, the EAP server can use info supplied by the peer, AAA protocols, and the local database to tell less trusted entities apart from more trusted ones ✨ one possible deployment involves verifying a bunch of characteristics about relatively trusted entities, while for other entities, it just verifies that they're less trusted 💖

any deployment of channel bindings should take into consideration both what info the EAP server is likely to know or have access to, and what type of network info the peer would want and need authenticated 🫶

5. Channel-Binding Process ✨

this section defines the process for verifying channel-binding info during an EAP authentication 🔎 the protocol uses an approach where plaintext data is exchanged, since that lets channel bindings be used more flexibly across different deployment models (see Section 4.1) 🎀 the first subsection outlines the general communication infrastructure, specifies the messages used for channel-binding verifications, and defines the protocol flows 🧚 the second subsection digs into the difficulties of checking the different pieces of info exchanged during the channel-binding protocol for consistency 🤔 and the third subsection describes the info carried in the EAP exchange 💜

5.1. Protocol Operation ✨

okay so channel bindings are always set up between two endpoints, the EAP peer and the EAP server 💖. They talk through an authenticator, which is usually just passing things along in pass-through mode 🦋. The spec treats the AAA server and the EAP server as separate entities, but there's no standardized protocol for them to chat with each other 🙃. So for the channel-binding protocol in this doc to work, the EAP server needs to reach two things: info from the AAA server that got used during the EAP session (that's i2, more on it below) and a local database 🧩. The EAP server and the database can be co-located with the AAA server, like in Figure 1. There's also an alternate setup where the EAP server tells the AAA server which channel-binding attributes it was given, and the AAA server tells the EAP server which attributes it looked at when making its decision 🌈

                                     + -------------------------+
  --------        -------------      |   ----------     ______  |
 |EAP peer|<---->|Authenticator|<--> |  |EAP Server|___(______) |
  --------        -------------      |   ----------    | DB   | |
     .                 .             |AAA              (______) |
     .       i1        .             +--------------------------+
     .<----------------.      i2     .       .
     .                 .------------>        .
     .                  i1                   .
     .-------------------------------------->.
     .     CB_success/failure(i1, i2,info)   .
     .<--------------------------------------.

Figure 1: Overview of Channel-Binding Protocol

Okay, now the info part 👀. During network advertisement, selection, and authentication, the authenticator shows the peer some unauthenticated info about the network, labeled i1 🛜. i1 could include an authenticator identifier and the identity of the network it represents, plus advertised stuff like offered services and roaming info. Some info, like the type of media in use, might be communicated implicitly in i1. And here's the tea: there's no established trust relationship between the peer and authenticator, so the peer has no way to validate any of this 😬

During the transaction, the authenticator also presents a bunch of info properties as AAA attributes about itself and the current request 📦. These AAA attributes may or may not be accurate, and this info is labeled i2. i2 is whatever the AAA server gets from the last hop in the AAA proxy chain, which isn't necessarily the authenticator itself 🤔

AAA hops between the authenticator and the AAA server can validate some of i2 ✅. Whether the AAA server can actually rely on that depends a lot on the business deals with those proxies and how the AAA network is built 💼

Now the local database. It's honestly the MVP of this whole system 👑. For the EAP server or AAA server to know whether i1 and i2 are correct, they need trustworthy info, because an authenticator could put false info in both i1 and i2 💀. There are more reasons the database is needed for channel bindings, and we get into those in the next subsection. The info in the database can also involve wildcards. For example, you could use this to check whether IEEE 802.11 access points on a particular IP subnet all use a specific SSID. The exact IP address doesn't matter, as long as it's on the correct subnet 🎀

During an EAP method run with channel bindings, the peer sends i1 to the EAP server using the mechanism in Section 5.3 💌 The EAP server then checks that i1 from the peer, i2 from the authenticator, and the info in the local database all line up 🔍. Once it's done checking, the EAP server sends the peer a message saying whether the channel-binding validation check succeeded or failed, and it includes the attributes that were used in the check. That message flow is what Figure 1 shows 🦋

Above, the EAP server is described as the one doing the channel-binding validation. In most deployments, that's going to be a necessary implementation constraint 🫶. The EAP exchange needs to include an indication of channel-binding success or failure. Most existing implementations don't have a way to exchange messages with another AAA entity while the EAP server is processing a single EAP message 😭. But another AAA entity can still hand info to the EAP server so it can make its decision ✨

If the compliance of i1 or i2 info with the authoritative policy source is mandatory and a consistency check fails, then after sending a protected indication of failed consistency, the EAP server MUST send an EAP-Failure message to terminate the session. If the EAP server is configured otherwise, it MUST allow the EAP session to complete normally and leave the decision about network access up to the peer's policy. If i1 or i2 doesn't comply with policy, the EAP server MUST NOT list the info that failed to comply in the set of info used to perform channel binding. In this case, the EAP server SHOULD indicate channel-binding failure; this requirement may be upgraded to a MUST in the future. 🚨

5.2. Channel-Binding Consistency Check 🔍

The validation check at the heart of the channel-binding protocol from the previous subsection has two parts 💅. The server checks whether:

  1. the authenticator is lying to the peer, i.e., i1 contains false information, and
  2. the authenticator or any entity on the AAA path to the AAA server provides false information in the form of AAA attributes, i.e., i2 contains false information.

These checks let the EAP server catch lying NASes or authenticators in enterprise networks, and lying providers in service provider networks 🕵️‍♀️ (rude but iconic)

Checking that i1 and i2 are consistent is nontrivial, as [HC07] already pointed out 🧠. First, i1 can contain any type of info the authenticator passes along, whereas i2 is limited to info that can be carried in AAA attributes. Second, the authenticator usually talks to the peer and the AAA infrastructure over different link layers, so both endpoints may have been shown different types of identifiers and addresses 🌸. The EAP server or AAA server can't directly check whether those different identifiers and addresses belong to the same device without extra info. Finally, i2 might differ from what the authenticator originally sent, because of en route processing or malicious modifications 😤. So, in the service provider model, the i1 info the EAP server has can usually only be verified against the last-hop part of i2, or against values passed along by proxy servers 🔁. Plus, checking i1 and i2 against each other isn't enough on its own, because an authenticator could lie to both the peer and the EAP server, meaning i1 and i2 could be consistent and still both be false 🙈

A local database is needed to get around those shortcomings and support the consistency and validation checks 💜. Specifically, info stored for each NAS/authenticator (the enterprise scenario) or each roaming partner (the service provider scenario) lets you compare anything received in i1 with the AAA attributes in i2, along with any additionally stored AAA attributes that might have been lost in transit 🍓. And only a database like this lets the EAP server and AAA server check received info against trusted info about the network, including roaming agreements 🌈

Section 7 describes the lower-layer-specific properties that can be exchanged as part of i1 🧚. Section 8 describes specific AAA attributes that can be included and evaluated in i2 💖. The EAP server reports back the results of the channel-binding validation check, which compares the consistency of all the values against those in the local database 🦋. The challenges of setting up such a local database are discussed in Section 10 🎀

5.3. EAP Protocol 🎀

Okay so EAP methods that do channel binding the way this spec wants give you two things: a way to send channel-binding data from the peer to the EAP server, and a way for the server to send a channel-binding response back to the peer. 📨 How that actually travels depends on the method, but the content of the channel-binding data and response is defined right here. ✨

Usually the lower layer hands the EAP implementation on the peer a set of attributes that should be part of channel binding. 💅 Sometimes the EAP side has to tell the lower layer "nope, I can't send channel-binding info," and that can happen if the method you picked doesn't support channel binding at all, or if the channel-binding data is too big for that method. 🙈 Peers SHOULD provide appropriate policy controls to select channel binding or mandate its success, so you're not left guessing whether it actually happened. 🔥

The EAP server is the one that receives the channel-binding data and checks it. ✅ The EAP method gives it a way to send a response back, and that response uses the same basic format as the data. 🦋

                0                   1                   2                   3
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |     Code      |             Length            |      NSID     |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |                       NS-Specific...
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |             Length            |      NSID     | NS-Specific...
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |                                ...
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                Figure 2: Channel-Binding Encoding

Both the channel-binding data and the response use the layout in Figure 2. 🧚 The whole thing kicks off with a one-byte code (more on that in Section 5.3.1). After that, for each type of attribute in the channel-binding data, you encode the following stuff:

  • Length: Two octets of length in network byte order, which tell you how long the NS-Specific data is. The NSID and length octets don't count. 📏
  • NSID: The namespace identifier. One octet that describes which namespace the attributes come from. Check Section 5.3.3 for how to encode RADIUS attributes in channel-binding data and responses. RADIUS uses a namespace identifier of 1. 🌈
  • NS-Specific: The encoding of the attributes, done in whatever way fits that attribute type. 🍓

A given NSID MUST NOT appear more than once in a channel-binding data or channel-binding response. 🙅‍♀️ Instead, all the NS-Specific data for one NSID has to live inside a single set of fields (NSID, Length, and NS-Specific). If you've got multiple namespaces, you can repeat that set of fields once per namespace. 💜

In channel-binding data, the code is set to 1 (channel-binding data), and the full attributes and values that the peer wants the EAP server to validate are included. 🌸

In a channel-binding response, the server is the one that picks the code (see Section 5.3.1). For successful channel binding, the server returns code 2. 🎉 Which attributes come back depends on the code. For success, the server returns the attributes it actually considered when deciding that the channel bindings were validated. Attributes the server couldn't check, or that didn't validate against what the peer sent, MUST NOT be returned in a success response. 🚫 Generally, servers won't send a success response if any attribute they checked failed to match what the peer specified. 😬 There are special situations, like a new attribute being phased in at a server, where the server MAY have to return success even when that attribute fails to validate. 🦄 And whenever the server returns an attribute in a channel-binding response, it uses the value the peer supplied. 🫶

For channel-binding failure (code 3), the server SHOULD include any attributes that it successfully validated. 💀 This code means the server's policy says the attributes the client sent don't accurately describe the authenticator. Servers MAY include no attributes in this response. For example, if the server checked the attributes from the peer and they didn't line up, it can send back a response with no attributes at all. 🙃

Peers MUST treat unknown codes as channel-binding failure. 🚨 Peers MUST ignore differences between attribute values sent in the channel-binding data and those sent in the response. Peers and servers MUST ignore any attributes contained in a field with an unknown NSID. 👀 And peers MUST ignore any attributes in a response that weren't present in the channel-binding data. 💅

5.3.1. Channel-Binding Codes 🦋

               +------+-----------------------------------+
               | Code | Meaning                           |
               +------+-----------------------------------+
               | 1    | Channel-binding data from client  |
               | 2    | Channel-binding response: success |
               | 3    | Channel-binding response: failure |
               +------+-----------------------------------+

5.3.2. Namespace Identifiers 🌷

            +-----+--------------------------+---------------+
            | ID  | Namespace                | Reference     |
            +-----+--------------------------+---------------+
            | 1   | RADIUS                   | Section 5.3.3 |
            | 255 | Reserved for Private Use |               |
            +-----+--------------------------+---------------+

5.3.3. RADIUS Namespace 📡

RADIUS attribute-value pairs (AVPs) are encoded as a one-octet attribute type, followed by a one-octet length, followed by the value of the RADIUS attribute being encoded. 🧮 The length counts the type and length octets too, so the minimum legal length is 3. Attributes get concatenated to form the namespace-specific portion of the packet. 🔗

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

                    Figure 3: RADIUS AVP Encoding

The full value of an attribute is included in both the channel-binding data and the response. 💖

6. System Requirements 🛠️

This section lays out the requirements for the components used to implement the channel-bindings protocol. 📋

The channel-binding protocol defined in this document must be transported after keying material has been derived between the EAP peer and server, and before the peer would suffer adverse effects from joining an adversarial network. 🕵️‍♀️ This document describes a protocol for doing channel binding within EAP methods. As discussed in Section 4.2, another way to meet this requirement is to do the channel bindings during the secure association protocol of the lower layer. 🔐

6.1. General Transport Protocol Requirements 🚚

The transport protocol that carries channel-binding information MUST support end-to-end message integrity protection (that's between the EAP peer and server) so an adversarial NAS or AAA device can't mess with the transported data. 🛡️ The transport protocol SHOULD provide confidentiality too. Why? Because channel bindings can contain private info, including peer identities, and that stuff SHOULD be protected. 🤫 And if confidentiality can't be provided, private information MUST NOT be sent as part of the channel-binding information. 🙅‍♀️

Any transport needs to be careful not to exceed the MTU for its lower-layer medium. 📦 Here's the tricky bit: if channel-binding information gets exchanged inside protected EAP method channels, those methods may or may not support fragmentation. So to work with all methods, the channel-binding messages have to fit within the available payload. For example, say the EAP MTU is 1020 octets, EAP - Generalized Pre-Shared Key (EAP-GPSK) is the authentication method, and you're using maximal-length identities. Then only a maximum of 384 octets is available for conveying channel-binding information. 😵 Other methods, like EAP Tunneled Transport Layer Security (EAP-TTLS), support fragmentation and could carry significantly longer payloads. 🚀

6.2. EAP Method Requirements 🧩

When data is transported directly within an EAP method, the method MUST be able to carry integrity-protected data from the EAP peer to the server and from the EAP server to the peer. 🔒 EAP methods MUST exchange channel-binding data with the AAA subsystem hosting the EAP server. 🏠 And EAP methods MUST be able to import channel-binding data from the lower layer on the EAP peer. 📥

7. Channel-Binding TLV 💜

This section defines some channel-binding TLVs. ✨ Message i1 isn't limited to AAA attributes, but for the sake of tangible attributes that are already in place, this section talks about AAA AVPs that are good for carrying channel bindings (i.e., data from i1 in Section 5). 🧁

For any lower-layer protocol, network information that the peer and server care about can be encapsulated in AVPs or other defined payload containers. 🎁 Which AVPs are appropriate depends on the lower-layer protocol, on the network type (enterprise network or service provider network), and on the application. 🏢

7.1. Requirements for Lower-Layer Bindings 🌈

Lower-layer protocols MUST support EAP so they can support EAP channel bindings. 🫧 These lower layers MUST support EAP methods that derive keying material, because otherwise there's no integrity-protected channel to run the channel-bindings protocol over. 🔑 Lower-layer protocols don't need to support traffic encryption, since that's independent of the authentication phase. 🙌

The data conveyed within the AVP type MUST NOT conflict with the externally defined usage of the AVP. 🚧 Additional TLV types MAY be defined for values that aren't communicated within AAA attributes. 🍬

In general, lower layers will need to specify what information should be included in i1. Existing lower layers will probably need new documents to specify this info. 📚 Lower-layer specifications need to include enough information in i1 to uniquely identify which lower layer is involved. The preferred way to do that is to include the EAP-Lower-Layer attribute, which is defined in the next section. 🎯 This MUST be included in i1 unless an attribute specific to a particular lower layer is included in i1. 💅

7.2. EAP Lower-Layer Attribute 🎀

okay so there's a brand new RADIUS attribute that tells the server which EAP lower layer is being used for this authentication 🦋 it describes the link that EAP is actually riding on. the NAS is allowed (MAY) to send it in an Access-Request or an Accounting-Request packet 💅 here's the layout, read left to right:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Value (cont.)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

the code is 163, the length is 6, and the value is a 32-bit unsigned integer in network byte order 🔥 that value tells you which EAP lower layer is in use, and the possible values come from the IANA registry set up in Section 11.1 ✨

8. AAA-Layer Bindings 🧚

this section is all about which AAA attributes in an AAA Access-Request message can and should be validated by an EAP server (aka the data from i2 in Section 5) 🫶 as we said before, proxies can mess with this data, either to make things work (like stripping realm info after a message got proxied) or to be sneaky (hello, lying provider 💀). so it can't always be validated easily 😭 still, you should do as thorough a validation as you possibly can to catch attacks 🛡️

  • NAS-IP-Address: this is usually the IP address of the authenticator 💖 but in a proxied connection it probably won't match the source IP address of the Access-Request. a consistency check MAY verify the subnet of the IP address was correct based on the last-hop proxy 🌸
  • NAS-IPv6-Address: same vibe, but for the IPv6 address 🧚 this is usually the IPv6 address of the authenticator, but through a proxy it likely won't match the source IPv6 address of the Access-Request. a consistency check MAY verify the subnet of the IPv6 address was correct based on the last-hop proxy 🌈
  • NAS-Identifier: this is an identifier the NAS fills in so the AAA server can identify it 🍓 it SHOULD be validated against the local database 💅
  • NAS-Port-Type: this one tells you the underlying link technology ⭐ it SHOULD be validated against the value received from the peer in the information exchange, and against a database of authorized link-layer technologies 👑

9. Security Considerations 🔥

okay this is the serious part bestie 😭 this section talks about the security stuff around using EAP channel bindings, so read it all 🫶

9.1. Trust Model 💜

in the trust model we're considering, the EAP peer and the authentication server are honest 🌸 but the authenticator is maliciously sending false info to the peer and/or the server 💀 in this model the peer and server trust each other, which is not an unreasonable assumption since they already have a trust relationship with each other 🦋 here are the trust relationships:

  • The server trusts that the channel-binding information received from the peer is the information that the peer received from the authenticator. 🫶
  • The peer trusts the channel-binding result received from the server. 💖
  • The server trusts the information contained within its local database. 🍓

to set up the first two trust relationships during an EAP execution, an EAP method MUST provide the following:

  • mutual authentication between peer and server
  • derivation of keying material including a key for integrity protection of channel-binding messages known to the peer and EAP server but not the authenticator
  • transmission of the channel-binding request from peer to server over an integrity-protected channel
  • transmission of the channel-binding result from server to peer over an integrity-protected channel
this trust model is a big departure from the standard EAP model 🚨 in lots of EAP deployments today, attacks where one authenticator impersonates another aren't a huge concern, because all the authenticators offer the same service 💅 an authenticator doesn't get much advantage from impersonating another one. but if different authenticators give different services, an attacker who can impersonate an authenticator may get more advantage 👀 so you need to analyze the whole system to evaluate cases where one authenticator impersonates another, and to figure out how bad that impersonation would be 🔍

one attractive way to implement channel binding is to add channel-binding support to a tunnel method that can tunnel an inner EAP authentication ✨ that way you can get channel binding with any method that can work as an inner method, even if that inner method has no native channel-binding support 🧚 the mutual authentication and key derivation requirement lives at the layer of EAP that actually does the channel binding 💜 tunnel methods sometimes use cryptographic binding, which is where a peer proves that the peer for the outer method is the same as the peer for an inner method, so that authentication at one layer is tied to the inner layer 🎀 but cryptographic binding doesn't always give you mutual authentication, because its definition doesn't require the server to prove that the inner server and outer server are the same 😬 even when cryptographic binding does try to confirm the inner and outer servers are the same, the Master Session Key (MSK) from the inner method is typically used to protect the binding 🔑 an attacker, like an authenticator who wants to subvert channel binding, could set up an outer tunnel that terminates at the authenticator 💀 if the outer method tunnel terminates on the authenticator, the MSK is disclosed to the authenticator, and that can typically be used to attack cryptographic binding 🙈 if the authenticator controls cryptographic binding, it typically controls the channel-binding parameters and results too 😭 and if channel binding is used to tell one authenticator apart from another, then the authenticator can claim to support services it wasn't authorized for 🚫 this attack wasn't in scope for the existing threat models for cryptographic binding, because telling authenticators apart wasn't a consideration back then 📜 so existing cryptographic binding doesn't typically give you the mutual authentication of the inner-method server that channel binding needs 💔 other methods besides cryptographic binding can give you the mutual authentication channel binding requires 🫶 for example, if server certificates are validated and names are checked, the tunnel itself can provide mutual authentication directly 🔐

9.2. Consequences of Trust Violation 💅

if any of the trust relationships listed in Section 9.1 get violated, channel binding can't be provided 😭 in other words, if mutual authentication with key establishment as part of the EAP method, plus protected database access, aren't provided, then getting channel binding isn't feasible 🙅‍♀️

dishonest peers can only manipulate the first message, i1, of the channel-binding protocol 👀 in this scenario, a peer sends i1' to the server. if i1' is invalid, the channel-binding validation fails 💀 but if i1' passes validation, then either the original i1 was wrong and i1' fixed the problem, or both i1 and i1' are valid information 🤔 a peer could potentially get an advantage in auditing or charging if both are valid and information from i1' gets used for auditing or charging 💸 such peers can be detected by including the information in i2 and checking i1 against i2 🕵️‍♀️

if information from i1 doesn't validate, an EAP server generally can't figure out whether the authenticator advertised incorrect information or whether the peer is dishonest 🤷‍♀️ so think about this before using channel-binding validation failures to judge the reputation of the peer or the authenticator ⚖️

dishonest servers can send EAP-Failure messages and abort the EAP authentication even when the received i1 is valid 😤 but servers can always abort any EAP session, whether or not channel binding was offered 🙄 on the flip side, dishonest servers can claim a successful validation even if i1 contains invalid information 🚩 this can be seen as the authenticator and server colluding 🫠 channel binding can neither prevent nor detect such attacks 💔 in general, these attacks can't be prevented by cryptographic means, so they should be handled with policies that make servers liable for the information and services they provide 📋

additional network entities, like proxies, might be on the communication path between peer and server and may try to manipulate the channel-binding protocol 👻 if those entities don't have the keying material used to integrity-protect the channel-binding messages, the same threat analysis applies as for dishonest authenticators 🧐 so those entities can't manipulate a single channel-binding message or the outcome 🙌 but entities that do have access to the keying material must be treated like a server in a threat analysis 🚨 so those entities can manipulate the channel-binding protocol without being detected 😱 that said, needing the keying material is unlikely, since channel binding is executed before the EAP method is completed, and so before keying material is typically transported to other entities ⏳

9.3. Bid-Down Attacks 🙈

EAP methods that add channel binding will typically negotiate whether it's used 🤝 even for brand-new EAP methods designed with channel binding from the first version, some deployments may not use it 🤷‍♀️ it's desirable to protect against attacks on the negotiation of channel bindings 🛡️ an attacker, including the NAS, SHOULD NOT be able to stop a peer and server that support channel bindings from using them 🚫

unfortunately, existing EAP methods may make it difficult or impossible to protect against attacks on negotiation 😩 for example, lots of EAP state machines will accept a success message at any point after key derivation to end authentication 🏁 EAP success messages aren't integrity protected, so an attacker who could insert a message can generate one 💀 the NAS is always in a position to generate a success message 😬 common EAP servers take advantage of state machines accepting success messages even in cases where an EAP method might support a protected indication of success 📉 it may be challenging to define channel-binding support for existing EAP methods in a way that lets peers tell apart an old EAP server that sends a success indication and doesn't support channel binding from an attacker injecting a success indication 🤯

9.4. Privacy Violations 🙈

okay so the channel-binding info that goes between the EAP peer and the EAP server (that's i1 and the result message) has to be integrity protected, but it doesn't have to be encrypted 👀. If those messages carry identifiers for the peer or the network, the privacy of the EAP method can get wrecked 💀. So to keep the method private, the channel-binding info you swap should be encrypted. If encryption isn't available, then private info just doesn't go in the channel-binding info at all, as described in Section 6.1 🔒.

The attributes you pick for channel binding have privacy consequences too, and you have to think about them 🧐. Say you channel-bind the username attribute. The peer sends an anonymous identifier in its EAP identity message (good for privacy 🦋), but then sends the full username in the protected i1 message. The authenticator really wants to know the full username, so it takes a wild guess and sends that guess in i2 instead of the anonymous identifier. If the EAP server checks this and fails whenever the peer's username doesn't match i2, then congrats, the server just confirmed the authenticator's guess 😭. Any time one party can guess the channel-binding info another party sent, you can get similar privacy leaks, so keep that in mind 🚨.

10. Operations and Management Considerations 🛠️

as with any extension to existing protocols, it's going to affect existing systems 🌸. The goal is usually to build an extension that has the smallest possible impact on both developing and deploying the new system, while still meeting the system requirements ✨. This section talks about the impact on existing devices that already use EAP, assuming the channel-binding info gets carried inside the EAP method execution 💅.

The EAP peer needs an API between the EAP lower layer and the EAP method 🔌. This API exposes the info the NAS needs to validate over to the EAP peer, and then the peer can feed that info into the EAP methods so it can get transported 🚚. For example, an IEEE 802.11 system would need to make its various information elements that need validating available to the EAP peer. The peer would format them properly and pass them along to the EAP method 🧚. On top of that, the EAP peer will need updated EAP methods that can transport channel-binding info. Most method docs are written in a modular way that lets you add arbitrary protected info, but the implementations of those methods would still need revising to support these extensions 🛠️. Driver updates are needed too, so the methods can get to the info they require 💜.

No changes to the pass-through authenticator are required 🙌.

The EAP server needs an API between the database that stores NAS info and the individual EAP server 🗄️. The database might already exist on the AAA server. If so, the EAP server just passes the parameters over to the AAA server for validation 🎀. The EAP methods also need to be able to export the received channel-binding info to the EAP server, so the server can validate it 🔍.

11. IANA Considerations 📋

okay, a brand new top-level registry got created for "Extensible Authentication Protocol (EAP) Channel Binding Parameters" 🎉. It's made up of a few sub-registries 💖.

The "EAP Channel-Binding Codes" sub-registry holds values for the code field in the channel-binding data and channel-binding response packets 🌈. Check the table in Section 5.3.1 for the initial registrations 💅. New registrations in this registry need Standards Action [RFC5226], but early allocation [RFC4020] is allowed 🦋. There's an extra reference column in the table that points all the initial codes back to this spec ✨. The valid values in this sub-registry go from 0 to 255, and 0 is reserved 🙈.

The "EAP Channel-Binding Namespaces" sub-registry has the registrations for the NSID field in the channel-binding data and channel-binding response 🫶. You'll find the initial registrations in the table in Section 5.3.2. New registrations here need IETF Review 🧐. The valid values are 0 to 255, and 0 is reserved again 💜. Just like the codes sub-registry, there's a reference column pointing to this document for the initial registrations 📚.

11.1. EAP Lower Layers Registry 🌐

there's a new sub-registry in the EAP Numbers registry at http://www.iana.org/assignments/eap-numbers, made for EAP Lower Layers 🎀. Registration needs Expert Review [RFC5226]. The expert's main job is to stop multiple registrations for the same lower layer 🛑.

Here are the initial registrations for this registry 💖:

+-------+----------------------------------------+
| Value | Lower Layer                            |
+-------+----------------------------------------+
| 1     | Wired IEEE 802.1X                      |
| 2     | IEEE 802.11 (no-pre-auth)              |
| 3     | IEEE 802.11 (pre-authentication)       |
| 4     | IEEE 802.16e                           |
| 5     | IKEv2                                  |
| 6     | PPP                                    |
| 7     | PANA (no pre-authentication) [RFC5191] |
| 8     | GSS-API [GSS-API-EAP]                  |
| 9     | PANA (pre-authentication) [RFC5873]    |
+-------+----------------------------------------+

11.2. RADIUS Registration 📡

a new RADIUS attribute gets registered under the name EAP-Lower-Layer, with the number 163 🔢. You can find the RADIUS attributes in the registry at http://www.iana.org/assignments/radius-types 🗂️.

12. Acknowledgments 🫶

the authors and editor want to give a huge thank you to Bernard Aboba, Glen Zorn, Joe Salowey, Stephen Hanna, and Klaas Wierenga 👑. Their valuable input helped shape and improve this document over time ✨.

Sam Hartman's work on this specification was funded by JANET(UK) 💜.

The EAP-Lower-Layer attribute was taken from "RADIUS Attributes for IEEE 802 Networks" [RADIUS-WLAN] 🌸.

13. References 📚

13.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.

[RFC4020]      Kompella, K. and A. Zinin, "Early IANA Allocation of
               Standards Track Code Points", BCP 100, RFC 4020,
               February 2005.

[RFC5226]      Narten, T. and H. Alvestrand, "Guidelines for Writing
               an IANA Considerations Section in RFCs", BCP 26,
               RFC 5226, May 2008.

13.2. Informative References 🦋

[AAA-PAY]      Clancy, T., Lior, A., Ed., Zorn, G., and K. Hoeper,
               "EAP Method Support for Transporting AAA Payloads",
               Work in Progress, May 2010.

[GSS-API-EAP]  Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism
               for the Extensible Authentication Protocol", Work in
               Progress, June 2012.

[HC07]         Hoeper, K. and L. Chen, "Where EAP Security Claims
               Fail", Institute for Computer Sciences, Social
               Informatics and Telecommunications Engineering
               (ICST), The Fourth International Conference on
               Heterogeneous Networking for Quality, Reliability,
               Security and Robustness (QShine 2007), August 2007.

[RADIUS-WLAN]  Aboba, B., Malinen, J., Congdon, P., and J. Salowey,
               "RADIUS Attributes for IEEE 802 Networks", Work in
               Progress, October 2011.

[RFC4017]      Stanley, D., Walker, J., and B. Aboba, "Extensible
               Authentication Protocol (EAP) Method Requirements for
               Wireless LANs", RFC 4017, March 2005.

[RFC5056]      Williams, N., "On the Use of Channel Bindings to
               Secure Channels", RFC 5056, November 2007.

[RFC5191]      Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and
               A. Yegin, "Protocol for Carrying Authentication for
               Network Access (PANA)", RFC 5191, May 2008.

[RFC5296]      Narayanan, V. and L. Dondeti, "EAP Extensions for EAP
               Re-authentication Protocol (ERP)", RFC 5296,
               August 2008.

[RFC5873]      Ohba, Y. and A. Yegin, "Pre-Authentication Support for
               the Protocol for Carrying Authentication for Network
               Access (PANA)", RFC 5873, May 2010.

Appendix A. Attacks Prevented by Channel Bindings 🛡️

in this appendix, we're going to see how the channel bindings we've presented can stop attacks from malicious authenticators (the "lying NAS" problem) and malicious visited networks (the "lying provider" problem) 😈. This document only covers part of the solution you need to defend against these attacks 🧩. Lower-layer protocols also need to describe which attributes should go in channel-binding requests 📝. EAP methods need to be updated to describe how the channel-binding request and response get carried 🚚. And deployments may need to decide what info goes in the local database 🗄️. The next sections describe the types of attacks this framework can prevent, given the right lower-layer attributes in the channel bindings, EAP methods with channel-binding support, and the right local database info on the EAP server ✨.

A.1. Enterprise Subnetwork Masquerading 🎭

as outlined in Section 3, an enterprise network can have multiple VLANs that give different levels of security 🏢. In this attack, a malicious NAS connects to a guest network with weaker protection and broadcasts the SSID of a more protected subnetwork 😬. That can make peers think they're connected over secure links, so they might send confidential info they'd never send over a weakly protected connection 😭. This attack only works if peers use the same set of credentials to authenticate to the different kinds of VLANs, and if the VLANs support at least one EAP method in common 🔑. If those conditions aren't met, the EAP server won't authorize the peers to connect to the guest network, because the peers used credentials and/or an EAP method tied to the corporate network 🙅‍♀️.

A.2. Forced Roaming 📶

mobile phone providers have, in the past, boosted their cell towers' transmission power to pull in more users 📱. A bigger transmission range, combined with a NAS sending a false network identity, can lure users onto the network without them realizing they're roaming 🫣.

channel bindings can catch the bogus network identifier, because the network identifier sent to the authentication server in i1 won't match i2 or the stored data 🔍. The verification fails because the info in i1 claims to come from the peer's home network, but the home authentication server knows the connection is coming through a visited network outside the home domain 🚫. Along the same lines, channel bindings can power a "home zone" feature that tells users every time they're about to connect to a NAS outside their home domain 🏠💕.

A.3. Downgrading Attacks 💅

okay so picture this 😭 a sneaky authenticator edits the list of EAP methods it advertises in its beacon so the peer can only pick from the weakest methods the authentication server still accepts. instead of a choice between EAP-MD5-CHAP, EAP-FAST, and some other methods, the authenticator shrinks it down to just the weaker EAP-MD5-CHAP. 💀 if the server still supports those weak methods, this downgrade can let the authenticator attack the integrity and confidentiality of the rest of the EAP execution and/or break the authentication and key exchange. not it. 🙅‍♀️

the good news 🎀 the channel bindings in this doc stop this, because peers send the offered EAP method selection they got in the beacon as part of i1 to the authentication server. so the server notices the change when it compares that info to the matching info in its policy database. this assumes that every acceptable EAP method supports channel binding and that an attacker can't break the EAP method in real-time. 🔥

A.4. Bogus Beacons in IEEE 802.11r 🧚

in IEEE 802.11r, the SSID is bound into the TSK calculations, so the TSK has to match the SSID advertised in the authenticator's beacon. that stops outsiders from spoofing a beacon, but it doesn't stop a "lying NAS" from sending a bogus beacon and calculating the TSK to match. 🫠

by implementing channel bindings (as described in this doc) in IEEE 802.11r, the authentication server's verification can catch the inconsistencies between what the authenticator sent the peer and what the server received from the authenticator and stored in its policy database. ✨

A.5. Forcing False Authorization in IEEE 802.11i 👑

in IEEE 802.11i, a malicious NAS can modify the beacon so the peer thinks it's connected to a different network than the one it's actually on. 😳

on top of that, a malicious NAS can force an authentication server into authorizing access by sending an incorrect Called-Station-ID that belongs to an authorized NAS in the network. this could make the server think it granted access to a different network, or even a different provider, than the one the peer actually got access to. 💅

both attacks can be prevented by implementing channel bindings, because the server can compare the information sent to the peer, the information it received from the authenticator during the AAA communication, and the information stored in its policy database. 🎀

Authors' Addresses 🦋

Sam Hartman (editor)
Painless Security
356 Abbott St.
North Andover, MA  01845
USA

EMail: hartmans-ietf@mit.edu
T. Charles Clancy
Virginia Polytechnic Institute and State University
Electrical and Computer Engineering
900 North Glebe Road
Arlington, VA  22203
USA

EMail: tcc@vt.edu
Katrin Hoeper
Motorola Solutions, Inc.
1301 E. Algonquin Road
Schaumburg, IL  60196
USA

EMail: khoeper@motorolasolutions.com

that's the whole thing bestie, the authors really did all of this 🫶🌈

📦 where this page comes from