RFC 5836
Extensible Authentication Protocol (EAP) Early Authentication Problem Statement
RFC 5836 🎀 Extensible Authentication Protocol (EAP) Early Authentication Problem Statement
okay bestie, let's get into it 🦋 this one is an Informational doc (so not a Standards Track thing, it's published just to share info 💅). It's by Y. Ohba (Toshiba), Q. Wu, Ed. (Huawei), and G. Zorn, Ed. (Network Zen), and it came out in April 2010. It's part of the ISSN 2070-1721 series 🌸. It doesn't obsolete or update any other RFCs, so it's a fresh start 🌈.
The big idea is about EAP early authentication, which the doc defines as a mobile device using EAP to set up authenticated keying material on a target attachment point before it arrives there 🧚. Basically, get the handshake done early so the handover is smoother ✨.
Status of This Memo
this doc is not an Internet Standards Track spec, it's just published for info 💖. It's a product of the IETF and reflects the consensus of the IETF community 🫶. It went through public review and got approved by the IESG. Not everything the IESG approves ends up being a candidate for an Internet Standard, so check out Section 2 of RFC 5741 for the deets 🍓. You can find the current status, errata, and a place to give feedback at http://www.rfc-editor.org/info/rfc5836 💜.
Copyright Notice
Copyright (c) 2010 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 stood on the date of publication. Please actually read those, they spell out your rights and restrictions 🙈. Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in that license 💀.
This doc may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have let the IETF Trust allow modifications outside the IETF Standards Process 😭. So unless you get an adequate license from those copyright holders, this doc may not be modified outside the IETF Standards Process, and derivative works may not be made outside it either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Problem Statement ...............................................6
3.1. Handover Preparation .......................................6
3.2. Handover Execution .........................................6
3.2.1. Examples ............................................7
3.3. Solution Space .............................................7
3.3.1. Context Transfer ....................................7
3.3.2. Early Authentication ................................8
4. System Overview .................................................8
5. Topological Classification of Handover Scenarios ................9
6. Models of Early Authentication .................................10
6.1. EAP Pre-Authentication Usage Models .......................10
6.1.1. The Direct Pre-Authentication Model ................11
6.1.2. The Indirect Pre-Authentication Usage Model ........11
6.2. The Authenticated Anticipatory Keying Usage Model .........13
7. Architectural Considerations ...................................13
7.1. Authenticator Discovery ...................................13
7.2. Context Binding ...........................................14
8. AAA Issues .....................................................14
9. Security Considerations ........................................16
10. Acknowledgments ...............................................17
11. Contributors ..................................................17
12. References ....................................................17
12.1. Normative References .....................................17
12.2. Informative References ...................................181. Introduction 🌸
So picture this: a mobile device is in the middle of a session and moves from one access network to another, changing its attachment point 🦋. Boom, the session can get disrupted because of the handover delay 😭. How much delay a real-time app can handle depends on the app and its stuff, like how much delay and packet loss it can tolerate 💅.
For Voice over IP, ITU-T G.114 [ITU] recommends a steady-state end-to-end delay of 150 ms as the upper limit, and it says anything at 400 ms is generally unacceptable 🙈. For streaming, tolerable packet-error rates are anywhere from 0.1 down to 0.00001, with transfer delay under 300 ms ✨. So any help an optimized handoff can give toward those goals is useful 🫶. The ultimate dream is seamless handover with low latency, even when you're switching between different link technologies or between different Authentication, Authorization, and Accounting (AAA) realms 👑.
During a handover, the device gets delayed because its association gets rebound at or across several protocol layers, and because it needs extra round trips for a new EAP exchange 💀. Those delays hit the ongoing multimedia and data traffic on the client [WCM] 🎀.
Handover often needs authentication and authorization to get or change resources for the mobile device 🧚. Usually those checks talk to a central authority in a realm, and sometimes that authority is far away from the device 🌈. That extra auth time adds to handover latency and messes with ongoing app sessions [MQ7] 😭. So this doc focuses on cutting down the delay caused by EAP authentication 💖.
2. Terminology 💅
AAA : Authentication, Authorization, and Accounting (see below). RADIUS [RFC2865] and Diameter [RFC3588] are examples of AAA protocols defined in the IETF 🍓.
AAA realm : The set of access networks within the scope of a specific AAA server. So if a mobile device moves from one attachment point to another within the same AAA realm, it keeps being served by the same AAA server 🦋.
Accounting : The act of collecting information on resource usage for trend analysis, auditing, billing, or cost allocation [RFC2989] 💜.
Attachment Point : A device, like a wireless access point, that acts as a gateway between access clients and a network. In this doc, an attachment point must also support EAP authenticator functionality and may act as a AAA client 🌸.
Authentication : The act of verifying a claimed identity, in the form of a preexisting label from a mutually known name space, as the originator of a message (message authentication) or as the end-point of a channel (entity authentication) [RFC2989] 🔥.
Authenticator : The end of the link initiating EAP authentication [RFC3748] ✨.
Authorization : The act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential [RFC2989] 👑.
Candidate Access Network : An access network that can potentially become the target access network for a mobile device. Multiple access networks may be candidates at the same time 🌈.
Candidate Attachment Point (CAP) : An attachment point that can potentially become the target attachment point for a mobile device. Multiple attachment points may be candidates at the same time 🧚.
Candidate Authenticator (CA) : The EAP authenticator on the CAP 🎀.
EAP Server : The entity that terminates the EAP authentication method with the peer [RFC3748]. EAP servers are often, but not necessarily, co-located with AAA servers, using a AAA protocol to talk to remote pass-through authenticators 💖.
Inter-AAA-realm Handover (Inter-realm Handover) : A handover across multiple AAA realms 😭.
Inter-Technology Handover : A handover across different link-layer technologies 🦋.
Intra-AAA-realm Handover (Intra-realm Handover) : A handover within the same AAA realm. Intra-AAA-realm handover includes a handover across different authenticators within the same AAA realm 💅.
Intra-Technology Handover : A handover within the same link-layer technology 🌸.
Master Session Key (MSK) : Keying material derived between the EAP peer and server and exported by the EAP method [RFC3748] 🔑✨.
Peer : The entity that responds to the authenticator and requires authentication [RFC3748] 🫶.
Serving Access Network : An access network currently serving the mobile device 🍓.
Serving Attachment Point (SAP) : An attachment point currently serving the mobile device 💜.
Target Access Network : An access network that has been selected to become the new serving access network for a mobile device 🌈.
Target Attachment Point (TAP) : An attachment point that has been selected to become the new SAP for a mobile device 👑.
3. Problem Statement 🦋
The basic handover mechanism is a two-step procedure involving:
- handover preparation and
- handover execution
3.1. Handover Preparation 🧚
Handover preparation covers discovering candidate attachment points and picking an appropriate target attachment point from the candidate set. This is outside the scope of this document 💅.
3.2. Handover Execution 💖
Handover execution means setting up Layer 2 (L2) and Layer 3 (L3) connectivity with the TAP 🌸. Right now, handover execution includes network access authentication and authorization done directly with the target network, and that can include full EAP authentication when there's no special optimization for handover key management 😭. After a successful EAP authentication, a secure association procedure is typically run between the mobile device and the TAP to derive a new set of link-layer encryption keys from EAP keying material like the MSK 🔑. The handover latency from full EAP authentication has been shown to be higher than what's acceptable for real-time app scenarios [MQ7], so cutting handover latency due to EAP is a necessary goal for those scenarios 🫶🔥.
3.2.1. Examples 🎀
Part 1 ends here, more to come bestie 💕 stay tuned for Section 3.2.1 and everything after it ✨
3.2.1.1. IEEE 802.11 ✨
okay so in IEEE 802.11 Wireless Local Area Networks (WLANs) [IEEE.802-11.2007] 🛜, network access authentication and authorization means doing a brand new IEEE 802.1X [IEEE.802-1X.2004] message exchange with the authenticator in the TAP, and that exchange runs an EAP exchange with the authentication server [WPA] 🔐. bestie, there has been some optimization work done by the IEEE, but it's all scoped to IEEE link-layer technologies 🙈. the work from the IEEE 802.11f [IEEE.802-11F.2003] and 802.11r [IEEE.802-11R.2008] Task Groups only applies to intra-technology handovers, so it's not giving for the cross-tech situation 💀.
3.2.1.2. 3GPP TS33.402 🌸
so the Third Generation Partnership Project (3GPP) Technical Specification 33.402 [TS33.402] 📜 defines the authentication and key management procedures that happen during interworking between non-3GPP access networks and the Evolved Packet System (EPS) 🦋. network access authentication and authorization happens after the L2 connection is set up between the mobile device and a non-3GPP target access network, and it involves an EAP exchange between the mobile device and the 3GPP AAA server, routed through that non-3GPP target access network 🧚. these procedures are not really independent of link technology, since they assume either that the authenticator lives in the EPS network, or that separate authentications happen in the access network and then again in the EPS network 😭.
3.3. Solution Space 💜
as the examples in the preceding sections illustrate, we need a solution to enable EAP early authentication for inter-AAA-realm handovers and inter-technology handovers 🔥. a search for solutions at the IP level may offer the necessary technology independence 👑.
optimized solutions for secure inter-authenticator handovers can be seen either as security context transfer (e.g., using the EAP Extensions for EAP Re-authentication Protocol (ERP)) [RFC5296] 🎀, or as EAP early authentication 🫶.
3.3.1. Context Transfer 🍓
security context transfer means transferring reusable key context to the TAP, and it can take two forms: horizontal and vertical 💅.
horizontal security context transfer (e.g., from SAP to TAP) is NOT RECOMMENDED 🚫, because one compromised attachment point might lead to the compromise of another (the so-called domino effect, [RFC4962]) 😱.
⚠️ Vertical context transfer is similar to the initial establishment of keying material on an attachment point, in that the keys are sent from a trusted server to the TAP as a direct result of a successful authentication. ERP specifies vertical context transfer using existing EAP keying material obtained from the home AAA server during the initial authentication. A cryptographically independent re-authentication key is derived and transmitted to the TAP as a result of successful ERP authentication. This reduces handover delay for intra-realm handovers by eliminating the need to run full EAP authentication with the home EAP server.
however, in the case of inter-realm handover, either ERP is not applicable or an additional optimization mechanism is needed to establish a key on the TAP 🌈.
3.3.2. Early Authentication ⭐
in EAP early authentication, AAA-based authentication and authorization for a CAP is performed while ongoing data communication is in progress via the serving access network 📡. the goal is to complete AAA signaling for EAP before the mobile device moves 🏃♀️. the applicability of EAP early authentication is limited to scenarios where candidate authenticators can be discovered and an accurate prediction of movement can be easily made 🔮. also, the effectiveness of EAP early authentication may be less significant for particular inter-technology-handover scenarios where simultaneous use of multiple technologies is not a major concern 🤷♀️.
there are also several AAA issues related to EAP early authentication, discussed in Section 8 🧐.
- System Overview 🗺️
figure 1 shows the functional elements related to EAP early authentication 💖. these include a mobile device, a SAP, a CAP, and one or more AAA and EAP servers; for convenience, the AAA and EAP servers are shown as co-located 🤝. when the SAP and CAP belong to different AAA realms, the CAP may need a different set of user credentials than the ones the peer uses to authenticate to the SAP 🔑. alternatively, the CAP and the SAP may rely on the same AAA server, located in the home realm of the mobile device (MD) 🏠.
+------+ +-------+ +---------+ +---------+
| MD |------| SAP |------| | | |
+------+ +-------+ | IP | | EAP/AAA
. | |------| |
. Move | Network | | Server |
v +-------+ | | | |
| CAP |------| | | |
+-------+ +---------+ +---------+
Figure 1: EAP Early Authentication Functional Elementsa mobile device is attached to the serving access network 📶. before the MD hands over from the serving access network to a candidate access network, it does EAP early authentication with a candidate authenticator via the serving access network 🦋. the peer may do EAP early authentication with one or more candidate authenticators 💫. it is assumed that each attachment point has an IP address 🌷. it is assumed that there is at least one CAP in each candidate access network 🌟. the serving and candidate access networks may use different link-layer technologies 🎭.
each authenticator is either a standalone authenticator or a pass-through authenticator [RFC3748] 🧩. when an authenticator acts as a standalone authenticator, it also has the functionality of an EAP server 🦸♀️. when an authenticator acts as a pass-through authenticator, it talks to the EAP server, typically using a AAA transport protocol such as RADIUS [RFC2865] or Diameter [RFC3588] 🚀.
if the CAP uses an MSK [RFC5247] for generating lower-layer ciphering keys, EAP early authentication is used to proactively generate an MSK for the CAP 🔐✨.
- Topological Classification of Handover Scenarios 🗂️
the complexity of the authentication and authorization part of handover depends on whether it involves a change in EAP server 🤔. let's look at the case where the authenticators operate in pass-through mode, so the EAP server is co-located with an AAA server 🧠. then there's a strict hierarchy of complexity, as follows:
- inter-attachment-point handover with common AAA server: the CAP and SAP are different entities, but the AAA server is the same 👯. there are two sub-cases here:
(a) the AAA server is common because both attachment points lie within the same network, or
(b) the AAA server is common because AAA entities in the serving and candidate networks proxy to a AAA server in the home realm.
- inter-AAA-realm handover: the CAP and SAP are different entities, and the respective AAA servers also differ 🌍. as a result, authentication in the candidate network requires a second set of user credentials 🗝️.
a third case is where one or both authenticators are co-located with an EAP server 😬. this has some of the characteristics of an inter-AAA-realm handover, but offers less flexibility for resolving the early authentication problem 🙃.
orthogonally to this classification, one can tell apart intra-technology handover from inter-technology handover by looking at the link technologies involved 🧐. in the inter-technology case, it is highly probable that the authenticators will differ 💯. the most likely cases are 1(b) or 2 in the above list 🎯.
- Models of Early Authentication 🎀
as noted in Section 3, there are cases where early authentication is applicable while ERP does not work 🙅♀️. this section gives some models we can build our analysis of the EAP early authentication problem around 🧱. different usage models can be defined depending on whether
- the SAP is not involved in early authentication (direct pre-authentication usage model),
- the SAP interacts only with the CAP (indirect pre-authentication usage model), or
- the SAP interacts with the AAA server (the authenticated anticipatory keying usage model).
it is assumed that the CAP and SAP are different entities 🫶. it is further assumed in describing these models that there is no direct L2 connectivity between the peer and the candidate attachment point 🙅.
6.1. EAP Pre-Authentication Usage Models 💜
in the EAP pre-authentication model, the SAP does not interact with the AAA server directly 🙊. depending on how the SAP is involved in the pre-authentication signaling, the EAP pre-authentication usage model can be further categorized into the following two sub-models, direct and indirect 🌸.
6.1.1. The Direct Pre-Authentication Model 🍭
in this model, the SAP is not involved in the EAP exchange and only forwards the EAP pre-authentication traffic as it would any other data traffic 📦. the direct pre-authentication model is based on the assumption that the MD can discover candidate authenticators and establish direct IP communication with them 🔍. it is applicable to any of the cases described in Section 5 💅.
Mobile Candidate Attachment AAA Server
Device Point(CAP)
+-----------+ +-------------------------+ +------------+
| | | Candidate | | |
| Peer | | Authenticator | | EAP Server |
| | | | | |
+-----------+ +-------------------------+ +------------+
| MD-CAP |<-->| MD-CAP | | CAP-AAA |<-->| CAP-AAA |
| Signaling | | Signaling | | Signaling | | Signaling |
+-----------+ +-----------+ +-----------+ +------------+
Figure 2: Direct Pre-Authentication Usage Modelthe direct pre-authentication signaling for the usage model is shown in Figure 3 🧾.
Mobile Serving Candidate AAA/EAP
Device Attachment Point Authenticator Server
(SAP)
| | | |
| | | |
| EAP over MD-CAP Signaling (L3) | EAP over AAA |
|<------------------+------------------->|<----------------->|
| | | |
| | | |
Figure 3: Direct Pre-Authentication Signaling for the Usage Model6.1.2. The Indirect Pre-Authentication Usage Model ✨
okay so the indirect pre-authentication usage model is shown in Figure 4 🦋
Mobile Device Serving Candidate AAA
(MD) Attachment Point Attachment Point Server
(SAP) (CAP)
+----------+ +----------------+ +--------+
| | | | | |
| EAP Peer | | Candidate | | EAP |
| | | Authenticator | | Server |
| | | | | |
+----------+ +---------+-------+ +-------+--------+ +--------+
| MD-SAP |<->| MD-SAP |SAP-CAP|<->|SAP-CAP|CAP-AAA |<->|CAP-AAA |
+----------+ +---------+-------+ +-------+--------+ +--------+
{-----------------------------Signaling----------------------------}
Figure 4: Indirect Pre-Authentication Usage Modelso in this model, we assume there's a trust relationship between the serving network (or serving AAA realm) and the candidate network (or candidate AAA realm) 🫶 the SAP is the one involved in the EAP pre-authentication signaling. this model is needed when the peer can't discover the candidate authenticator's identity, OR when direct IP communication between the MD and CAP isn't possible because of security or network topology issues 💀
the SAP's job here is to forward the EAP pre-authentication signaling between the mobile device and the CAP ✨ and the CAP's job is to forward the EAP pre-authentication signaling between the peer (going through the SAP) and the EAP server, and then receive the transported keying material 🔥
the pre-authentication signaling for this model looks like Figure 5 🌸
Mobile Serving Candidate AAA/EAP
Device Attachment Point Attachment Point Server
(SAP) (CAP)
| | | |
| EAP over | EAP over | EAP over AAA |
| MD-SAP Signaling | SAP-CAP Signaling | |
| (L2 or L3) | (L3) | |
|<----------------->|<------------------<|<----------------->|
| | | |
| | | |
Figure 5: Indirect Pre-Authentication Signaling for the Usage Modelin this model, the pre-authentication signaling path between a peer and a candidate authenticator has two segments: peer-to-SAP signaling (over L2 or L3) and SAP-to-CAP signaling over L3 🦄
6.2. The Authenticated Anticipatory Keying Usage Model 🔐
in this model, there's no trust relationship between the SAP and the CAP 🙈 so the SAP has to talk to the AAA server directly. the authenticated anticipatory keying usage model is shown in Figure 6 ✨
Mobile Serving AAA Server Candidate
Device Attachment Point Attachment
(SAP) Point (CAP)
+---------+ +------------------+ +-----------------+ +--------+
| | | | | | | |
| Peer | | Authenticator | | EAP Server | | AAA |
| | | | | | | Client |
+---------+ +------------------+ +-----------------+ +--------+
| MD-SA |<->| MD-SAP |SAP-AAA |<->|SAP-AAA |CAP-AAA |<>|CAP-AAA |
+---------+ +------------------+ +--------+--------+ +--------+
{------------------------------Signaling---------------------------}
Figure 6: Authenticated Anticipatory Keying Usage Modelthe SAP is involved in the EAP authenticated anticipatory keying signaling 💅
the serving attachment point's role in this usage model is to talk to the peer on one side, and exchange authenticated anticipatory keying signaling with the EAP server on the other side 🌈 the candidate authenticator's role is to receive the transported keying materials from the EAP server, and then act as the serving attachment point once the handover happens 👑 the MD-SAP signaling runs over L2 or L3, and the SAP-AAA and AAA-CAP segments run over L3 🧚
7. Architectural Considerations 🏗️
okay so there are two architectural issues with early authentication: authenticator discovery and context binding 🎀
7.1. Authenticator Discovery 🔍
generally, early authentication needs the identity of a candidate attachment point to be discovered, either by a peer, by a serving attachment point, or by some other entity, before the handover happens 🫣 an attachment point discovery protocol is usually defined as its own separate protocol, apart from the early authentication protocol 💜 for example, the IEEE 802.21 Information Service (IS) [IEEE.802-21] gives you a link-layer-independent way to get neighboring network information. it does this by defining a set of Information Elements (IEs), and one of those IEs is defined to hold an IP address of an attachment point ✨ IEEE 802.21 IS queries for that IE can be used as a method for authenticator discovery 🦋
if IEEE 802.21 IS or something similar is used, authenticator discovery needs a database of information about the target network 📚 and provisioning a server with that database is its own separate issue 🙃
7.2. Context Binding 🧩
when a candidate authenticator uses different EAP transport protocols for normal authentication and early authentication, there needs to be a mechanism to bind the link-layer-independent context carried over early authentication signaling to the link-layer-specific context of the link that's going to be set up between the peer and the candidate authenticator 🔗 the link-layer-independent context includes the identities of the peer and authenticator, plus the MSK 🔑 the link-layer-specific context includes the link-layer addresses of the peer and the candidate authenticator 💖 this binding can happen before or after the peer changes its point of attachment 🌸
there are at least two possible approaches for context binding 🌟 the first one is based on communicating the link-layer context as opaque data over early authentication signaling. the second one is based on running EAP over the link layer of the candidate authenticator after the peer arrives at the authenticator, using short-term credentials generated through early authentication 🥹 in that case, the short-term credentials are shared between the peer and the candidate authenticator 🤝 in both approaches, the context binding has to be made securely between the peer and the candidate authenticator 🔐 and the peer isn't fully authorized by the candidate authenticator until it finishes the link-layer-specific secure association procedure with the authenticator, using link-layer signaling 🚨
8. AAA Issues 😤
most AAA documents today don't tell a normal authentication apart from an early authentication, and that creates a bunch of open issues 💀 here they are:
Early authentication authorization users may not be allowed to have more than one logon session at a time. that means while a user is actively in a session (from a previously valid authentication), they won't be able to do early authentication 😭 right now the AAA server has no way to tell a normal authentication request apart from an early authentication request 🙅♀️
Early authentication lifetime right now, AAA protocols define attributes that carry lifetime info for a normal authentication session 📋 even when a user profile and the AAA server support early authentication, the lifetime of an early authentication session is usually only valid for a short time, because the peer hasn't finished authenticating at the target link layer yet ⏳ it isn't currently possible for an AAA server to tell the AAA client or the peer how long an early authenticated session lasts, unless AAA protocols get extended to carry early authentication session lifetime information 🛠️ so basically, neither the peer nor the authenticator knows when the early authentication session will expire 😵💫
Early authentication retries usually, shortly after the early authentication process, the peer moves to the new point of attachment and turns its early authentication state into a normal authentication state (the procedure for that isn't the topic of this subsection) ✈️ but if the peer hasn't moved yet and sees that its early authentication session is about to expire, it might do another early authentication 🔁 we need some kind of limit so there isn't an unlimited number of early authentication attempts 🛑
Completion of network attachment once the peer has successfully attached to the new point of attachment, it needs to change its authentication state from early authenticated to fully attached and authorized 🎉 if the AAA server needs to tell early authentication apart from normal authentication, there may need to be a mechanism inside the AAA protocol to send that indication to the AAA server 💅 this could matter for billing, if the billing policy doesn't charge for an early authenticated peer until it's fully attached to the target authenticator 💸
Session resumption say the peer cycles from a network N1, which it has fully authenticated with, to another network N2, and then back to N1. in that case, it should be possible to just convert the fully authenticated state on N1 into an early authenticated state 🔄 the problems around handling session lifetime and keying material caching still need to be sorted out 🧠
Multiple candidate attachment points there may be situations where the peer needs to pick from several CAPs 🤔 in those cases, it's desirable for the peer to do early authentication with multiple candidate authenticators 🫠 this makes the difficulties from "Early authentication authorization" even worse 😩
Inter-AAA-realm handover support there may be situations where the peer moves out of its home AAA realm, or across different visited AAA realms 🌍 in those cases, early authentication should be done through the visited AAA realm, with the AAA server in the home AAA realm 🏠 this also means AAA in the visited realm needs to get the identity information of the home AAA realms, so it can route the EAP early authentication traffic 🗺️ knowing realm identities is required for both the peer and AAA, so they can generate the early authentication key for mutual authentication between the peer and the visited AAA server 🔑
Inter-technology support current specs on early authentication mostly deal with homogeneous 802.11 networks 📡 AAA attributes like Calling-Station-ID [RADEXT-WLAN] may need to be expanded to cover other access technologies 🌐 on top of that, inter-technology handovers may require changing the peer identifier as part of the handover 🆔 figuring out the best type of identifier for peers that support multiple access technologies is still required 🔍✨
9. Security Considerations ✨
okay so this section is where we talk about the scary stuff 🙈 it covers the threats that early authentication itself introduces to the EAP model. the general EAP and handover security issues live in other docs, like [RFC3748], [RFC4962], [RFC5169], and [RFC5247], so go read those too if you're curious 🧚
early authentication has to work across multiple attachment points, so any solution has to think about the following security threats. no cap, this is the part that matters 💀
First, there's a resource consumption denial-of-service attack 😭. an attacker who is NOT on the same IP link as the legitimate peer or the candidate authenticator can send unprotected early authentication messages to the legitimate peer or the candidate authenticator. the victim then burns computational and bandwidth resources processing the attacker's messages 💔. this works in both the direct and indirect pre-authentication scenarios.
how do we stop it? the candidate network or authenticator can apply non-cryptographic packet filtering, so that only early authentication messages from a specific set of serving networks or authenticators get processed 🫶. also, a simple solution for the peer side is to let the peer always initiate EAP early authentication, and not allow EAP early authentication initiation from an authenticator 👑.
the peer side fix is the main idea here: the peer starts it, the authenticator doesn't. 🔥
Second, we need to think about the channel binding problem from [RFC5247] 🦋. lack of channel binding may let an authenticator impersonate another authenticator, or communicate incorrect information through out-of-band mechanisms (like a AAA or lower-layer protocol) [RFC3748]. that is literally so unhinged 💅
and here's the spicy part: this impersonation attack is relatively easier to pull off for early authentication than for normal authentication 🙈. why? because the attacker does NOT need to be physically on the same link as the legitimate peer just to send an early authentication trigger to the peer. iykyk, it's giving "sneaky from across the room" energy 🌈
10. Acknowledgments 🎀
the editors want to thank Preetida Vinayakray, Shubhranshu Singh, Ajay Rajkumar, Rafa Marin Lopez, Jong-Hyouk Lee, Maryna Komarova, Katrin Hoeper, Subir Das, Charles Clancy, Jari Arkko, and Bernard Aboba for their valuable input 🫶💖 these queens literally helped make this happen, bestie, so shoutout to all of them ✨
11. Contributors 🌸
the following people all contributed to this document: Alper E. Yegin, Tom Taylor, Srinivas Sreemanthula, Madjid Nakhjiri, Mahalingam Mani, and Ashutosh Dutta 💜 main character contributors, obsessed 😭
12. References 📚
12.1. Normative References 💅
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.12.2. Informative References 🦋
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti,
"Handover Key Management and Re- Authentication Problem
Statement", RFC 5169, March 2008.
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP
Re-authentication Protocol (ERP)", RFC 5296, August 2008.
[RADEXT-WLAN]
Aboba, B., Malinen, J., Congdon, P., and J. Salowey,
"RADIUS Attributes for IEEE 802 Networks", Work
in Progress, February 2010.
[RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P.,
Shiino, H., Zorn, G., Dommety, G., C.Perkins, B.Patil,
D.Mitton, S.Manning, M.Beadles, P.Walsh, X.Chen,
S.Sivalingham, A.Hameed, M.Munson, S.Jacobs, B.Lim,
B.Hirschman, R.Hsu, Y.Xu, E.Campell, S.Baba, and E.Jaques,
"Criteria for Evaluating AAA Protocols for Network
Access", RFC 2989, November 2000.
[IEEE.802-1X.2004]
Institute of Electrical and Electronics Engineers,
"Port-Based Network Access Control", IEEE Standard 802.1X,
2004.
[IEEE.802-21]
Institute of Electrical and Electronics Engineers,
"Standard for Local and Metropolitan Area Networks: Media
Independent Handover Services", IEEE Standard 802.21,
2008.
[IEEE.802-11.2007]
Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications", IEEE Standard 802.11, 2007.
[IEEE.802-11R.2008]
Institute of Electrical and Electronics Engineers,
"Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications - Amendment 2: Fast BSS
Transition", IEEE Standard 802.11R, 2008.
[IEEE.802-11F.2003]
Institute of Electrical and Electronics Engineers, "IEEE
Trial-Use Recommended Practice for Multi-Vendor Access
Point Interoperability via an Inter-Access Point Protocol
Across Distribution Systems Supporting IEEE 802.11
Operation", IEEE Recommendation 802.11F, 2003.
[TS33.402] 3GPP, "System Architecture Evolution (SAE): Security
aspects of non-3GPP accesses (Release 8)", 3GPP
TS33.402 V8.3.1, 2009.
[ITU] ITU-T, "General Characteristics of International Telephone
Connections and International Telephone Circuits: One-Way
Transmission Time", ITU-T Recommendation G.114, 1998.
[WPA] The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)",
Wi-Fi WPA v3.1, 2004.
[MQ7] Lopez, R., Dutta, A., Ohba, Y., Schulzrinne, H., and A.
Skarmeta, "Network-layer Assisted Mechanism to Optimize
Authentication Delay During Handoff in 802.11 Networks",
The 4th Annual International Conference on Mobile and
Ubiquitous Systems: Computing, Networking and
Services (MOBIQUITOUS 2007), 2007.
[WCM] Dutta, A., Famorali, D., Das, S., Ohba, Y., and R. Lopez,
"Media-independent pre-authentication supporting secure
interdomain handover optimization", IEEE Wireless
Communications Volume 15, Issue 2, April 2008.Authors' Addresses 🌈
Yoshihiro Ohba
Toshiba Corporate Research and Development Center
1 Komukai-Toshiba-cho
Saiwai-ku, Kawasaki, Kanagawa, 212-8582
Japan
Phone: +81 44 549 2230
EMail: yoshihiro.ohba@toshiba.co.jp
Qin Wu (editor)
Huawei Technologies Co., Ltd
Huawei Nanjing R&D Center, Floor 1F, Software Avenue, No.101.,
Yuhua District
Nanjing, JiangSu 210012
China
Phone: +86 25 56622908
EMail: sunseawq@huawei.com
Glen Zorn (editor)
Network Zen
1463 East Republican Street
Seattle, Washington 98112
USA
EMail: gwz@net-zen.net📦 where this page comes from
- ietf: rfc5836 2010-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms