RFC 5296
EAP Extensions for EAP Re-authentication Protocol (ERP)
RFC 5296: EAP Extensions for EAP Re-authentication Protocol (ERP) 🦋
- Network Working Group 🌸
- Authors: V. Narayanan and L. Dondeti, both at Qualcomm, Inc. 💖
- Category: Standards Track ✨
- Date: August 2008 🎀
Status of This Memo
okay so this one is an Internet standards track protocol for the whole Internet community, and it's inviting discussion and suggestions for improvements 💅 If you want to know where it stands in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📜 And the distribution of this memo is unlimited, so share it with everyone bestie 🫶
Abstract
the Extensible Authentication Protocol (EAP) is a generic framework that supports lots of different authentication methods 🌈 When EAP is being used for authentication, it's highly desirable not to repeat the whole EAP exchange with another authenticator 🙈 This document adds extensions to EAP and to the EAP keying hierarchy, so there's an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server, through any authenticator 🦋 The re-authentication server could be in the home network, or in the local network the peer is connecting to. ✨
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 6
3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 8
4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 11
4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 12
4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 12
4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 13
4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 14
4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 15
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 15
5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 20
5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 21
5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 22
5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 23
5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 25
5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 26
5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 29
5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 30
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 30
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 31
7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Example ERP Exchange . . . . . . . . . . . . . . . . 421. Introduction 🌸
okay so EAP (the Extensible Authentication Protocol) is an authentication framework that supports multiple authentication methods 💅 Its main job is network access authentication, and a key-generating method gets used whenever the lower layer wants to enforce access control 🔐 EAP's keying hierarchy says that every key-generating EAP method derives two keys: the Master Session Key (MSK) and the Extended MSK (EMSK) ✨ In the most common setup, an EAP peer and an EAP server authenticate each other through a third party called the EAP authenticator 🫶 The EAP authenticator, or something the authenticator controls, enforces access control. Once authentication succeeds, the EAP server hands the MSK over to the EAP authenticator. The EAP authenticator and the EAP peer then set up transient session keys (TSKs) using the MSK as the authentication key, key derivation key, or key transport key, and they use those TSKs for per-packet access enforcement 🦋
Now here's the problem 😭 When a peer moves from one authenticator to another, you really want to skip a full EAP authentication so handovers stay fast. A full EAP exchange, with another run of the EAP method, can take several round trips and a lot of time, which means slower handovers 🐢 Some EAP methods use state from the first authentication to make re-authentication cheaper on computation, but method-specific re-authentication still takes at least 2 round trips with the original EAP server in most cases (e.g., [6]). Also, lots of methods don't support re-authentication at all 🙈
Sharing keys across authenticators is sometimes used as a practical trick to lower handover times 🙃 The catch is that if one authenticator gets compromised, the keying material established through the other authenticators is compromised too 💀 Other fast re-authentication solutions exist in the literature [7] [8].
So to get low-latency handovers, we need a method-independent re-authentication protocol that finishes in less than 2 round trips, and ideally with a local server 🚀 The EAP re-authentication problem statement is described in detail in [9].
This document specifies EAP Re-authentication Extensions (ERXs) for efficient re-authentication using EAP ✨ The protocol that uses these extensions is called the EAP Re-authentication Protocol (ERP) 💖 ERP is EAP method-independent re-authentication for a peer that has valid, unexpired key material left over from an EAP authentication it already completed 🎀 This document describes the protocol and the key hierarchy that EAP re-authentication needs.
Heads up, though: to support ERP, the lower-layer specs might need revisions so they can carry EAP messages with a code value higher than 4, and so they can handle the peer-initiated nature of ERP 👑 Specifically, the IEEE802.1x specification must be revised, and RFC 4306 must be updated to carry ERP messages ⭐
2. Terminology 💜
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 RFC 2119 [1].
This document uses the basic EAP terminology [2] and the EMSK keying hierarchy terminology [3]. On top of that, it uses these terms, bestie 🧚
- ER Peer - An EAP peer that supports the EAP Re-authentication Protocol. Unless specifically noted otherwise, every reference to "peer" in this document means an ER peer 🌸
- ER Authenticator - An entity that supports the authenticator functionality for EAP re-authentication described in this document. Unless specifically noted otherwise, every reference to "authenticator" means an ER authenticator 🦋
- ER Server - An entity that performs the server portion of ERP described here. It may or may not be an EAP server 🤔 Unless specifically noted otherwise, every reference to "server" means an ER server. An ER server is a logical entity: the home ER server lives on the same backend authentication server as the EAP server in the home domain. The local ER server doesn't necessarily have to be a full EAP server 💅
- ERX - EAP re-authentication extensions. ✨
- ERP - EAP Re-authentication Protocol, which uses the re-authentication extensions. 💖
- rRK - re-authentication Root Key, derived from the EMSK or the DSRK. 🔑
- rIK - re-authentication Integrity Key, derived from the rRK. 🎀
- rMSK - re-authentication MSK. This is a per-authenticator key, derived from the rRK. 🌈
- keyName-NAI - ERP messages are integrity protected with the rIK or the DS-rIK. The use of rIK or DS-rIK for integrity protection of ERP messages is indicated by the
EMSKname[3]. The protocol part is ERP, and the realm part indicates the domain name of the ER server. TheEMSKnamegets copied into the username part of the NAI 🫶 - Domain - Refers to a "key management domain" as defined in [3]. For simplicity, this document just calls it "domain". The terms "home domain" and "local domain" tell apart the originating key management domain that does the full EAP exchange with the peer, and the local domain the peer may be attached to at any given time 🗺️
3. ERP Description 🧚♀️
okay so ERP lets a peer and a server mutually verify proof of possession of keying material from an earlier EAP method run, and then set up a security association between the peer and the authenticator 🤝 The authenticator is just a pass-through for the Re-authentication Protocol, kind of like an EAP authenticator described in RFC 3748 [2] 🫶 ERP is a single round-trip exchange between the peer and the server. It doesn't care about the lower layer or the EAP method used during the full EAP exchange 🙌 The ER server can be in the home domain, or in the same (visited) domain as the peer and the authenticator 🏠
Figure 2 shows the protocol exchange 📸 The very first time the peer attaches to any network, it does a full EAP exchange (shown in Figure 1) with the EAP server. As a result, an MSK gets distributed to the EAP authenticator, and the authenticator and the peer use that MSK to set up TSKs as needed 🔐 During that initial EAP exchange, the peer and the server also derive an EMSK, which gets used to derive a re-authentication Root Key (rRK) ✨ To be precise, the rRK is derived either from the EMSK, or from a Domain-Specific Root Key (DSRK) that is itself derived from the EMSK 🦋 The rRK is only available to the peer and the ER server, and it is never handed out to any other entity 🙅♀️ Next, a re-authentication Integrity Key (rIK) is derived from the rRK. The peer and the ER server use the rIK to provide proof of possession while they run an ERP exchange 💖 The rIK is never handed out to any entity either, and it's only available to the peer and the server 🎀
When the ER server is in the home domain, the peer and the server use the rIK and rRK derived from the EMSK. When the ER server is not in the home domain, they use the DS-rIK and DS-rRK that correspond to the local domain instead 🌍 The domain of the ER server is identified by the realm portion of the keyname-NAI in ERP messages 🌈
3.1. ERP With the Home ER Server ✨
okay so first, here's the regular full EAP dance so you can see what ERP is glowing up from 💅
EAP Peer EAP Authenticator EAP Server
======== ================= ==========
<--- EAP-Request/ ------
Identity
----- EAP Response/ --->
Identity ---AAA(EAP Response/Identity)-->
<--- EAP Method -------> <------ AAA(EAP Method -------->
exchange exchange)
<----AAA(MSK, EAP-Success)------
<---EAP-Success---------Figure 1: EAP Authentication
now the ERP version 🦋
Peer Authenticator Server
==== ============= ======
[<-- EAP-Initiate/ -----
Re-auth-Start]
[<-- EAP-Request/ ------
Identity]
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap])
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap])Note: [] brackets indicate optionality.
Figure 2: ERP Exchange
Two brand-new EAP codes show up here, EAP-Initiate and EAP-Finish, and they exist purely for EAP re-authentication 🎀 When a peer spots a target authenticator that supports EAP re-authentication, it runs the ERP exchange from Figure 2. That can happen when the peer attaches to a new authenticator, or even before it attaches. The peer can start ERP on its own, or it can answer when the new authenticator sends an EAP-Initiate/Re-auth-Start message to trigger it. Think of that message as the authenticator tapping you on the shoulder 👀
The authenticator might not know whether the peer even does ERP, or whether the peer already did a full EAP auth through some other authenticator. Kinda awkward ngl 💀 So the authenticator MAY start the ERP exchange by sending EAP-Initiate/Re-auth-Start, and if nobody answers, it sends EAP-Request/Identity. Why? It avoids having two EAP messages in flight at the same time [2], which is lowkey genius 🧠
The authenticator can send EAP-Initiate/Re-auth-Start and then wait a short, locally configured amount of time. If the peer doesn't already know, that message tells it the authenticator supports ERP. Once the peer gets the trigger, it can start ERP by sending an EAP-Initiate/Re-auth message. If there's still no answer after the necessary retransmissions (see Section 6), the authenticator MUST initiate EAP by sending an EAP-Request message, typically EAP-Request/Identity. The authenticator might get an EAP-Initiate/Re-auth after it already sent EAP-Request/Identity. If the authenticator supports ERP, it MUST proceed with the ERP exchange. When EAP-Request/Identity times out, the authenticator MUST NOT close the connection if an ERP exchange is in progress or has already succeeded in establishing a re-authentication MSK. That one's serious, bestie 🫶
If the authenticator doesn't support ERP, it drops EAP-Initiate/Re-auth messages [2] because the EAP code on those packets is greater than 4. An ERP-capable peer will use up its EAP-Initiate/Re-auth retransmissions and then fall back to EAP by answering EAP Request/Identity messages from the authenticator. If the peer doesn't support ERP, or it doesn't have unexpired key material from an earlier EAP authentication, it drops EAP-Initiate/Re-auth-Start messages. If there's no response to EAP-Initiate/Re-auth-Start, the authenticator SHALL send an EAP Request message (typically EAP Request/Identity) to start EAP authentication. From that point on, RFC 3748 rules apply. This may add some delay before EAP starts. On some lower layers, the peer can cut that delay by starting EAP itself with messages like EAPoL-Start from the IEEE 802.1X specification [10] ⚡
Here's the actual handshake. The peer sends an EAP-Initiate/Re-auth message that carries the keyName-NAI (to identify the ER server's domain) and the rIK used to protect the message, plus a sequence number for replay protection. The message is integrity protected with the rIK. The authenticator uses the realm in the keyName-NAI [4] field to route the message to the right ER server. The server uses the keyName to look up the rIK. After it verifies proof of possession of the rIK and the freshness of the message, the server derives an rMSK from the rRK, using the sequence number as an input to the key derivation. Then the server bumps its expected sequence number to the received sequence number plus one 🔥
In response to EAP-Initiate/Re-auth, the server sends an EAP-Finish/Re-auth message, which is integrity protected with the rIK. The server transports the rMSK to the authenticator along with this message. That works a lot like the MSK going along with EAP-Success in a full EAP exchange. Ongoing work in [11] describes an extra key distribution protocol that can move the rRK from an EAP server to one of many ER servers that share a trust relationship with that EAP server 🌈
The peer MAY request the server for the rMSK lifetime. If it does, the ER server sends the rMSK lifetime in the EAP-Finish/Re-auth message.
In an ERP bootstrap exchange, the peer MAY request the server for the rRK lifetime. If it does, the ER server sends the rRK lifetime in the EAP-Finish/Re-auth message.
Last step on this side: the peer verifies the replay protection and the integrity of the message. Then it uses the sequence number in the EAP-Finish/Re-auth message to compute the rMSK. After that point, the lower-layer security association protocol is ready to be triggered 💖
3.2. ERP with a Local ER Server 🏠
The ER extensions we just talked about also let you run ERP with an ER server in the local domain (the access network) 🌸 The local ER server may be co-located with a local AAA server. The peer may find out about the presence of a local ER server, plus the local domain name (or ER server name), either through the lower layer or through ERP bootstrapping. The peer uses the domain name and the EMSK to compute the DSRK, and from that key it gets the DS-rRK. It also uses the domain name in the realm portion of the keyName-NAI for ERP in the local domain. Figure 3 shows the full EAP plus the subsequent local ERP exchange, and Figure 4 shows it with a local ER server.
Peer EAP Authenticator Local ER Server Home EAP Server
==== ================= =============== ===============
<-- EAP-Request/ --
Identity
-- EAP Response/-->
Identity --AAA(EAP Response/-->
Identity) --AAA(EAP Response/ -->
Identity,
[DSRK Request,
domain name])
<------------------------ EAP Method exchange------------------>
<---AAA(MSK, DSRK, ----
EMSKname,
EAP-Success)
<--- AAA(MSK, -----
EAP-Success)
<---EAP-Success-----Figure 3: Local ERP Exchange, Initial EAP Exchange
Peer ER Authenticator Local ER Server
==== ================ ===============
[<-- EAP-Initiate/ --------
Re-auth-Start]
[<-- EAP-Request/ ---------
Identity]
---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ -------->
Re-auth Re-auth)
<--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/-------
Re-auth Re-auth)Figure 4: Local ERP Exchange
As Figure 4 shows, the local ER server may sit in the path of the full EAP exchange. For example, it might be one of the AAA entities (like AAA proxies) between the authenticator and the peer's home EAP server. In that case, the ER server requests the DSRK by sending the domain name to the EAP server. The EAP server then computes the DSRK by following the procedure in [3], and sends the DSRK and the key name, EMSKname, to the ER server in the claimed domain. The local domain is responsible for announcing that same domain name to the peer via the lower layer 📣
If the peer doesn't know the domain name (it didn't get it from the lower-layer announcement, maybe because it missed one, or because that lower layer doesn't support domain name announcements at all), it SHOULD initiate an ERP bootstrap exchange with the home ER server to get the domain name 🙈 The local ER server SHALL request the home AAA server for the DSRK by sending the domain name in the AAA message that carries the EAP-Initiate/Re-auth bootstrap message. The local ER server MUST be in the path from the peer to the home ER server. If it isn't, it can't request the DSRK. No path, no key, sad 😭
Once the local ER server receives the DSRK and the EMSKname, it computes the DS-rRK and the DS-rIK from the DSRK, as defined in Sections 4.1 and 4.3 below. After the peer receives the domain name, it derives the DSRK, the DS-rRK, and the DS-rIK too. These keys are referred to by a keyName-NAI formed like this: the username part of the NAI is the EMSKname, and the realm portion of the NAI is the domain name. Both parties also keep a sequence number (initialized to zero) for that specific keyName-NAI. Main character energy in the key management department 👑
Later on, when the peer attaches to an authenticator inside the local domain, it may perform an ERP exchange with the local ER server to get an rMSK for the new authenticator 🧚
4. ER Key Hierarchy ✨
Okay bestie, every single time the peer re-authenticates to the network, the peer and the authenticator set up a fresh rMSK 🔑. It does the same job an MSK does, the one you get from a full EAP authentication. To prove the peer really holds the rRK, we also derive another key called the rIK. Both come from the rRK, and together they make up the ER key hierarchy 💜.
The rRK comes from either the EMSK or a DSRK, as Section 4.1 explains. For this, the document follows [3] to derive a Usage-Specific Root Key (USRK) or a Domain-Specific USRK (DSUSRK) for re-authentication. The USRK designated for re-authentication is the re-authentication root key (rRK). A DSUSRK designated for re-authentication is the DS-rRK that a local ER server in a particular domain has access to. To keep things simple, the rest of the document calls them by their names without the DS label, but domain-specific keys only work within the domains they were derived for 🏰. Based on which ER server the peer is doing the ERP exchange with, the peer knows exactly which keys to use.
The rRK is used to derive an rIK and rMSKs for one or more authenticators. Here's the vibe:
rRK
|
+--------+--------+
| | |
rIK rMSK1 ...rMSKn
Figure 5: Re-authentication Key HierarchyThe derivations in this document follow [3]. Key derivations and field encodings, where unspecified, default to that document 📖.
4.1. rRK Derivation
The rRK may be derived from the EMSK or DSRK, and this section gives the key derivations for that 🌸.
The rRK is derived as specified in [3].
rRK = KDF (K, S), where
K = EMSK or K = DSRK and
S = rRK Label | "\0" | lengthThe rRK Label is an IANA-assigned 8-bit ASCII string:
EAP Re-authentication Root Key@ietf.orgIt's assigned from the "USRK key labels" name space in accordance with [3] 🎀.
The KDF and algorithm agility for the KDF are as defined in [3].
An rRK derived from the DSRK is referred to as a DS-rRK in the rest of the document. All the key derivation and properties specified in this section remain the same ✨.
4.2. rRK Properties
The rRK has the following properties. These apply to the rRK no matter which parent key it was derived from 💅.
- The length of the rRK MUST be equal to the length of the parent key used to derive it.
- The rRK is to be used only as a root key for re-authentication and never used to directly protect any data.
- The rRK is only used for derivation of rIK and rMSK as specified in this document.
- The rRK MUST remain on the peer and the server that derived it and MUST NOT be transported to any other entity.
- The lifetime of the rRK is never greater than that of its parent key. The rRK is expired when the parent key expires and MUST be removed from use at that time ⏳.
4.3. rIK Derivation
The re-authentication Integrity Key (rIK) is used for integrity protecting the ERP exchange. It's the proof of possession that the peer has valid keying material from a previous full EAP exchange, shown to the server 🦋.
The rIK is derived as follows:
rIK = KDF (K, S), where
K = rRK and
S = rIK Label | "\0" | cryptosuite | lengthThe rIK Label is the 8-bit ASCII string:
Re-authentication Integrity Key@ietf.orgThe length field refers to the length of the rIK in octets, encoded as specified in [3].
The cryptosuite and length of the rIK are part of the key derivation input. This keeps keys cryptographically separate if different rIKs of different lengths, for use with different Message Authentication Code (MAC) algorithms, are derived from the same rRK 🔐. The cryptosuite is encoded as an 8-bit number, and you'll find the cryptosuite specification in Section 5.3.2.
The rIK is referred to by EMSKname-NAI within ERP messages. The username part of EMSKname-NAI is the EMSKname, and the realm is the domain name of the ER server. With ERP to the home ER server, the peer uses the realm from its original NAI. With a local ER server, the peer uses the domain name it received at the lower layer or through an ERP bootstrapping exchange 🌈.
An rIK derived from a DS-rRK is referred to as a DS-rIK in the rest of the document. All the key derivation and properties specified in this section remain the same.
4.4. rIK Properties
The rIK has the following properties:
- The length of the rIK MUST be equal to the length of the rRK.
- The rIK is only used for authentication of the ERP exchange as specified in this document.
- The rIK MUST NOT be used to derive any other keys.
- The rIK must remain on the peer and the server and MUST NOT be transported to any other entity.
- The rIK is cryptographically separate from any other keys derived from the rRK.
- The lifetime of the rIK is never greater than that of its parent key. The rIK MUST be expired when the EMSK expires and MUST be removed from use at that time 💀.
4.5. rIK Usage
The rIK is the key whose possession the peer and the ERP server demonstrate to each other 🤝. The peer shows it has the rIK by computing the integrity checksum over the EAP-Initiate/Re-auth message. When the peer uses the rIK for the first time, it can choose the integrity algorithm to use with that rIK. The peer and the server MUST use the same integrity algorithm with a given rIK for all ERP messages protected with that key. They store the algorithm information after the first use and use the same algorithm for every later use of that rIK 🔥.
If the server's policy does not allow the cryptosuite the peer selected, the server SHALL reject the EAP-Initiate/Re-auth message and SHOULD send a list of acceptable cryptosuites in the EAP-Finish/Re-auth message 🙈.
The rIK length may be different from the key length an integrity algorithm requires. For hash-based MAC algorithms, the key is first hashed to the required key length, as specified in [5]. For cipher-based MAC algorithms, if the required key length is less than 32 octets, the rIK is hashed using HMAC-SHA256 and the first k octets of the output are used, where k is the key length required by the algorithm. If the required key length is more than 32 octets, the first k octets of the rIK are used by the cipher-based MAC algorithm 🧚.
4.6. rMSK Derivation
The rMSK is derived at the peer and the server and then delivered to the authenticator. It's derived following an EAP Re-auth Protocol exchange 🎀.
The rMSK is derived as follows:
rMSK = KDF (K, S), where
K = rRK and
S = rMSK label | "\0" | SEQ | lengthThe rMSK label is the 8-bit ASCII string:
Re-authentication Master Session Key@ietf.orgThe length field refers to the length of the rMSK in octets. It's encoded as specified in [3].
SEQ is the sequence number the peer sends in the EAP-Initiate/Re-auth message. This field is encoded as a 16-bit number in network byte order (see Section 5.3.2) 🔢.
An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest of the document. All the key derivation and properties specified in this section remain the same.
4.7. rMSK Properties
The rMSK has the following properties:
- The length of the rMSK MUST be equal to the length of the rRK.
- The rMSK is delivered to the authenticator and is used for the same purposes that an MSK is used at an authenticator.
- The rMSK is cryptographically separate from any other keys derived from the rRK.
- The lifetime of the rMSK is less than or equal to that of the rRK. It MUST NOT be greater than the lifetime of the rRK.
- If a new rRK is derived, subsequent rMSKs MUST be derived from the new rRK. Previously delivered rMSKs MAY still be used until the expiry of the lifetime.
- A given rMSK MUST NOT be shared by multiple authenticators 👑.
5. Protocol Details ✨
5.1. ERP Bootstrapping ✨
okay bestie, there are two flavors of ERP bootstrapping 🎀: explicit and implicit. In implicit bootstrapping, the local ER server SHOULD include its domain name and SHOULD request the DSRK from the home AAA server during the initial EAP exchange, in the AAA message encapsulating the first EAP Response message sent by the peer 💖. If the EAP exchange is successful, the server sends the DSRK for the local ER server (derived using the EMSK and the domain name as specified in [3]), EMSKname, and DSRK lifetime along with the EAP-Success message. The local ER server MUST extract the DSRK, EMSKname, and DSRK lifetime (if present) before forwarding the EAP-Success message to the peer, as specified in [12]. Note that the MSK (also present along with the EAP Success message) is extracted by the EAP authenticator as usual 🧚. The peer learns the domain name through the EAP-Initiate/Re-auth-Start message or via lower-layer announcements. When the domain name is available to the peer during or after the full EAP authentication, it attempts to use ERP when it associates with a new authenticator 🦋.
If the peer does not know the domain name (did not receive the domain name via the lower-layer announcement, due to a missed announcement or lack of support for domain name announcements in a specific lower layer), it SHOULD initiate ERP bootstrap exchange (ERP exchange with the bootstrap flag turned on) with the home ER server to obtain the domain name 🙈. The local ER server behavior is the same as described above. The peer MAY also initiate bootstrapping to fetch information such as the rRK lifetime from the AAA server 🌸.
The following steps describe the ERP explicit bootstrapping process 👑:
- The peer sends the EAP-Initiate/Re-auth message with the bootstrapping flag turned on. The bootstrap message is always sent to the home AAA server, and the keyname-NAI attribute in the bootstrap message is constructed as follows: the username portion of the NAI contains the EMSKname, and the realm portion contains the home domain name.
- In addition, the message MUST contain a sequence number for replay protection, a cryptosuite, and an integrity checksum. The cryptosuite indicates the authentication algorithm. The integrity checksum indicates that the message originated at the claimed entity, the peer indicated by the Peer-ID, or the rIKname.
- The peer MAY additionally set the lifetime flag to request the key lifetimes.
- When an ERP-capable authenticator receives the EAP-Initiate/Re-auth message from a peer, it copies the contents of the keyName-NAI into the User-Name attribute of RADIUS [13]. The rest of the process is similar to that described in [14] and [12].
- If a local ER server is present, the local ER server MUST include the DSRK request and its domain name in the AAA message encapsulating the EAP-Initiate/Re-auth message sent by the peer.
- Upon receipt of an EAP-Initiate/Re-auth message, the server verifies whether the message is fresh or is a replay by evaluating whether the received sequence number is equal to or greater than the expected sequence number for that rIK. The server then verifies to ensure that the cryptosuite used by the peer is acceptable. Next, it verifies the origin authentication of the message by looking up the rIK. If any of the checks fail, the server sends an EAP-Finish/Re-auth message with the Result flag set to '1'. Please refer to Section 5.2.2 for details on failure handling. This error MUST NOT have any correlation to any EAP-Success message that may have been received by the EAP authenticator and the peer earlier. If the EAP-Initiate/Re-auth message is well-formed and valid, the server prepares the EAP-Finish/Re-auth message. The bootstrap flag MUST be set to indicate that this is a bootstrapping exchange. The message contains the following fields:
- A sequence number for replay protection.
- The same keyName-NAI as in the EAP-Initiate/Re-auth message.
- If the lifetime flag was set in the EAP-Initiate/Re-auth message, the ER server SHOULD include the rRK lifetime and the rMSK lifetime in the EAP-Finish/Re-auth message. The server may have a local policy for the network to maintain and enforce lifetime unilaterally. In such cases, the server need not respond to the peer's request for the lifetime.
- If the bootstrap flag is set and a DSRK request is received, the server MUST include the domain name to which the DSRK is being sent.
- If the home ER server verifies the authorization of a local domain server, it MAY include the Authorization Indication TLV to indicate to the peer that the server (that received the DSRK and that is advertising the domain included in the domain name TLV) is authorized.
- An authentication tag MUST be included to prove that the EAP-Finish/Re-auth message originates at a server that possesses the rIK corresponding to the EMSKname-NAI.
- If the ERP exchange is successful, and the local ER server sent a DSRK request, the home ER server MUST include the DSRK for the local ER server (derived using the EMSK and the domain name as specified in [3]), EMSKname, and DSRK lifetime along with the EAP-Finish/Re-auth message.
- In addition, the rMSK is sent along with the EAP-Finish/Re-auth message, in a AAA attribute [12].
- The local ER server MUST extract the DSRK, EMSKname, and DSRK lifetime (if present), before forwarding the EAP-Finish/Re-auth message to the peer, as specified in [12].
- The authenticator receives the rMSK.
- When the peer receives an EAP-Finish/Re-auth message with the bootstrap flag set, if a local domain name is present, it MUST use that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName-NAI, and initialize the replay counter for the DS-rIK. If not, the peer SHOULD derive the domain-specific keys using the domain name it learned via the lower layer or from the EAP-Initiate/Re-auth-Start message. If the peer does not know the domain name, it must assume that there is no local ER server available.
- The peer MAY also verify the Authorization Indication TLV.
- The procedures for encapsulating the ERP and obtaining relevant keys using RADIUS and Diameter are specified in [12] and [15], respectively.
Since the ER bootstrapping exchange is typically done immediately following the full EAP exchange, it is feasible that the process is completed through the same entity that served as the EAP authenticator for the full EAP exchange 🫶. In this case, the lower layer may already have established TSKs based on the MSK received earlier. The lower layer may then choose to ignore the rMSK that was received with the ER bootstrapping exchange. Alternatively, the lower layer may choose to establish a new TSK using the rMSK. In either case, the authenticator and the peer know which key is used based on whether or not a TSK establishment exchange is initiated. The bootstrapping exchange may also be carried out via a new authenticator, in which case, the rMSK received SHOULD trigger a lower layer TSK establishment exchange 🔥.
5.2. Steps in ERP ✨
okay so, when a peer that already has an active rRK and rIK shows up at a new authenticator that supports ERP, it's allowed to run an ERP exchange with that authenticator 💖 ERP is usually peer-initiated, and it's basically an EAP-Initiate/Re-auth message followed by an EAP-Finish/Re-auth message 🦋 The exchange can go through a local ER server (if there is one) or straight to the original EAP server 🌸
It's also totally plausible for the network to kick off the EAP re-authentication process itself 🧚 An ERP-capable authenticator SHOULD send an EAP-Initiate/Re-auth-Start message to say "hey, I do ERP!" 💅 The peer may or may not wait for those messages to arrive before it sends its own EAP-Initiate/Re-auth message.
The EAP-Initiate/Re-auth-Start message SHOULD be sent by an ERP-capable authenticator, and it may send it a few times (retransmitting) until it gets an EAP-Initiate/Re-auth message back from the peer 🔁 The peer's EAP-Initiate/Re-auth message might have already been sent before the peer got an EAP-Request/Identity or EAP-Initiate/Re-auth-Start message from the authenticator. So the Identifier value in the EAP-Initiate/Re-auth message is independent of the Identifier value in the EAP-Initiate/Re-auth-Start or the EAP-Request/Identity messages. Totally separate vibes 🫶
Operational Considerations at the Peer:
ERP requires that the peer maintain retransmission timers for reliable transport of EAP re-authentication messages 🕰️ The reliability considerations of Section 4.3 of RFC 3748 apply, with the peer as the retransmitting entity.
The EAP Re-auth Protocol has the following steps, bestie 👑
The peer sends an EAP-Initiate/Re-auth message. At a minimum, the message SHALL include the following fields:
- a 16-bit sequence number for replay protection
- keyName-NAI as a TLV attribute to identify the rIK used to integrity protect the message.
- cryptosuite to indicate the authentication algorithm used to compute the integrity checksum.
- authentication tag over the message.
When the peer is doing ERP with a local ER server, it MUST use the corresponding DS-rIK it shares with the local ER server 🔐 The peer SHOULD set the lifetime flag to request the key lifetimes from the server. The peer can use the rRK lifetime to know when to trigger an EAP method exchange, and the rMSK lifetime to know when to trigger another ERP exchange ⏰
The authenticator copies the contents of the value field of the keyName-NAI TLV into the User-Name RADIUS attribute in the AAA message to the ER server 📨
The server uses the keyName-NAI to look up the rIK. It MUST first verify whether the sequence number is equal to or greater than the expected sequence number. If the server supports a sequence number window size greater than 1, it MUST verify whether the sequence number falls within the window and has not been received before. The server MUST then verify that the cryptosuite used by the peer is acceptable. The server then proceeds to verify the integrity of the message using the rIK, which verifies proof of possession of that key by the peer 🕵️♀️ If any of these verifications fail, the server MUST send an EAP-Finish/Re-auth message with the Result flag set to '1' (Failure). Please refer to Section 5.2.2 for details on failure handling. Otherwise, it MUST compute an rMSK from the rRK using the sequence number as the additional input to the key derivation.
In response to a well-formed EAP Re-auth/Initiate message, the server MUST send an EAP-Finish/Re-auth message with the following considerations:
- a 16-bit sequence number for replay protection, which MUST be the same as the received sequence number. The local copy of the sequence number MUST be incremented by 1. If the server supports multiple simultaneous ERP exchanges, it MUST instead update the sequence number window.
- keyName-NAI as a TLV attribute to identify the rIK used to integrity protect the message.
- cryptosuite to indicate the authentication algorithm used to compute the integrity checksum.
- authentication tag over the message.
- If the lifetime flag was set in the EAP-Initiate/Re-auth message, the ER server SHOULD include the rRK lifetime and the rMSK lifetime.
The server transports the rMSK along with this message to the authenticator 🚚 The rMSK is transported in a manner similar to how the MSK is transported along with the EAP-Success message in a regular EAP exchange.
The peer looks up the sequence number to check whether it's expecting an EAP-Finish/Re-auth message with that sequence number protected by the keyName-NAI. Then it verifies the integrity of the message. If the verifications fail, the peer logs an error and stops the process. Otherwise, it moves on to the next step 📝
The peer uses the sequence number to compute the rMSK 🧮
The lower-layer security association protocol can be triggered at this point 🌈
5.2.1. Multiple Simultaneous Runs of ERP
When a peer is within range of multiple authenticators, it may choose to run ERP through all of them at once to the same ER server 🌐 In that case, the ERP messages might arrive out of order, and the ER server could end up rejecting legit EAP-Initiate/Re-auth messages 😭
To make this work, an ER server MAY allow multiple simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth messages with SEQ number values within a window of allowed values 🪟 Remember, the SEQ number is what gives us replay protection. Replay window maintenance mechanisms are a local matter.
5.2.2. ERP Failure Handling
If processing the EAP-Initiate/Re-auth message results in a failure, the ER server MUST send an EAP-Finish Re-auth message with the Result flag set to '1' 🚫 If the server has a valid rIK for the peer, it MUST integrity protect the EAP-Finish/Re-auth failure message. If the failure is due to an unacceptable cryptosuite, the server SHOULD send a list of acceptable cryptosuites (in a TLV of Type 5) along with the EAP-Finish/Re-auth message. In this case, the server MUST indicate the cryptosuite used to protect the EAP-Finish/Re-auth message in the cryptosuite. The rIK used with the EAP-Finish/Re-auth message in this case MUST be computed as specified in Section 4.3 using the new cryptosuite. If the server does not have a valid rIK for the peer, the EAP-Finish/Re-auth message indicating a failure will be unauthenticated, and the server MAY include a list of acceptable cryptosuites in the message 🫣
When the peer gets an EAP-Finish/Re-auth message with the Result flag set to '1', it MUST verify the sequence number and the Authentication Tag to determine the validity of the message. If the peer supports the cryptosuite, it MUST verify the integrity of the received EAP-Finish/Re-auth message. If the EAP-Finish message contains a TLV of Type 5, the peer SHOULD retry the ERP exchange with a cryptosuite picked from the list the server included 🔄 The peer MUST use the appropriate rIK for the subsequent ERP exchange, computed with the corresponding cryptosuite as specified in Section 4.3. If the PRF in the chosen cryptosuite is different from the PRF originally used by the peer, it MUST derive a new DSRK (if required), rRK, and rIK before proceeding with the subsequent ERP exchange 🔑
If the peer can't verify the integrity of the received message, it MAY choose to retry the ERP exchange with one of the cryptosuites in the TLV of Type 5, but only after a failure has been clearly determined by following the procedure in the next paragraph 🤔
If the replay or integrity checks fail, the failure message may have been sent by an attacker 👀 It might also mean that the server and peer don't support the same cryptosuites, but the peer can't tell which one is true. So the peer SHOULD continue the ERP exchange per the retransmission timers before declaring a failure ⏳
When the peer runs explicit bootstrapping (ERP with the bootstrapping flag on), there may not be a local ER server available to send a DSRK Request and the domain name. In that case, the server cannot send the DSRK and MUST NOT include the domain name TLV. When the peer receives a response in the bootstrapping exchange without a domain name TLV, it assumes that there is no local ER server. The home ER server still sends an rMSK to the ER authenticator, though, and the peer SHALL run the TSK establishment protocol as usual 🎀
5.3. New EAP Packets 🦋
Two new EAP Codes are defined for ERP: EAP-Initiate and EAP-Finish 💜 The packet format for these messages follows the EAP packet format defined in RFC 3748 [2].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: EAP PacketCode
- 5 Initiate
- 6 Finish
Two new code values are defined for the purpose of ERP ✨
Identifier
The Identifier field is one octet. The Identifier field MUST be the same if an EAP-Initiate packet is retransmitted due to a timeout while waiting for a Finish message. Any new (non-retransmission) Initiate message MUST use a new Identifier field 🆕
The Identifier field of the Finish message MUST match that of the currently outstanding Initiate message. A peer or authenticator that receives a Finish message whose Identifier value does not match that of the currently outstanding Initiate message MUST silently discard the packet 🤫
To avoid confusion between new EAP-Initiate messages and retransmissions, the peer must choose an Identifier value that is different from the previous EAP-Initiate message, especially if that exchange has not finished. It is RECOMMENDED that the authenticator clear EAP Re-auth state after 300 seconds ⏲️
Type
This field indicates that this is an ERP exchange. Two type values are defined in this document for this purpose: Re-auth-Start (assigned Type 1) and Re-auth (assigned Type 2) 🌸
Type-Data
The Type-Data field varies with the Type of re-authentication packet 💅
5.3.1. EAP-Initiate/Re-auth-Start Packet 🎀
Okay so the EAP-Initiate/Re-auth-Start packet is the one that says "hey, I'm ERP-ready, wanna reauth?" 🦋 Here's its layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: EAP-Initiate/Re-auth-Start Packet
The vibe is: Type is 1 💅, and the Reserved field MUST be zero. Senders set it to zero, and receivers just ignore it 🙈
The packet carries one or more TVs or TLVs to pass info along to the peer. For example, the authenticator can send the domain name over, which is so helpful ✨
Quick recap on the TVs and TLVs 🌸: a TV payload has a 1-octet type and a value with a type-specific length. A TLV payload has a 1-octet type, a 1-octet length, and then the value. That length field tells you how many octets the value is.
Domain-Name 🌈 is a TLV payload with Type 4. The domain name is meant to be used as the realm in an NAI [4]. The Domain-Name attribute SHOULD be present in an EAP-Initiate/Re-auth-Start message.
Channel binding info MAY also be included, and we'll get into that in Section 5.5. For the parameter specification, check out Figure 11 🫶
5.3.1.1. Authenticator Operation
The authenticator MAY send the EAP-Initiate/Re-auth-Start message to say "yep, I support ERP" to the peer. It can also use this message to kick off ERP if the peer already did full EAP authentication and still has unexpired key material 🔥
The authenticator SHOULD include the domain name TLV, so the peer can learn the domain without needing lower-layer support or the ERP bootstrapping exchange. Very efficient, very iconic 👑
The authenticator MAY include channel binding information. That way the peer can pass it along to the server in the EAP-Initiate/Re-auth message, and the server can check whether the authenticator is claiming the same identity to both parties 🧚
The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start message a few times, for reliable transport. Persistence is a whole mood 💖
5.3.1.2. Peer Operation
The peer SHOULD send the EAP-Initiate/Re-auth message in response to the EAP-Initiate/Re-auth-Start message from the authenticator. If the peer doesn't recognize the Initiate code value, it silently discards the message 🙈 And if the peer has already sent an EAP-Initiate/Re-auth message to begin the ERP exchange, it also silently discards the message. No drama, no double-booking 💅
If the EAP-Initiate/Re-auth-Start message contains the domain name, and the peer doesn't already have the domain information, the peer SHOULD use that domain name to compute the DSRK. Then it uses the corresponding DS-rIK to send an EAP-Initiate/Re-auth message and start an ERP exchange with the local ER server 🦋
If the peer has already started an ERP exchange with the home ER server, it MAY choose not to start an ERP exchange with the local ER server. Ngl, that's a very reasonable way to avoid being extra 🌸
5.3.2. EAP-Initiate/Re-auth Packet 💜
This is the packet that actually starts the ERP exchange. Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|B|L| Reserved| SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: EAP-Initiate/Re-auth Packet
Type is 2 here 🎀
Flags 🍓 come in three flavours:
R: the R flag is set to0and ignored on reception.B: the B flag is the bootstrapping flag. If it's turned on, the message is a bootstrap message 🧚L: the L flag asks the server for the key lifetimes ⏰
The remaining 5 bits are set to 0 and ignored on reception.
SEQ 🔢 is a 16-bit sequence number used for replay protection. The SEQ field gets initialized to 0 every single time a new rRK is derived. Fresh key, fresh count, fresh start ✨
The TVs and TLVs work the same way as before: TVs have a 1-octet type plus a type-specific-length value, and TLVs have a 1-octet type, a 1-octet length, and a value 💖
keyName-NAI 🦋 is carried in a TLV payload with Type 1. It's variable in length and can't go over 253 octets. The EMSKname sits in the username part of the NAI, encoded in hexadecimal values. The EMSKname is 64 bits long, so the username portion takes up 128 octets 🤓
If the rIK is derived from the EMSK, the realm part of the NAI is the home domain name. If the rIK is derived from a DSRK, the realm part is the domain name that was used to derive the DSRK. The NAI syntax follows [4]. Exactly one keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth packet. Only one, no more, no less 🫶
Channel binding info MAY be included here too. Check Section 5.5 for the deets, and Figure 11 for the parameter specification 🌈
Cryptosuite 💅 tells you which integrity algorithm is used for ERP. The key lengths and output lengths are either spelled out or obvious from the cryptosuite name. These are the ones specified below:
0RESERVED1HMAC-SHA256-642HMAC-SHA256-1283HMAC-SHA256-256
HMAC-SHA256-128 is mandatory to implement, and it should be enabled in the default configuration. Main character energy, no question 👑
Authentication Tag 🔐 holds the integrity checksum over the ERP packet, excluding the authentication tag field itself. Its length is set by the cryptosuite. Yes, it's a checksum that protects everything except itself. Very clever, very slay 😭
5.3.3. EAP-Finish/Re-auth Packet ✨
okay bestie, the EAP-Finish/Re-auth packet is the big finale 💅 It carries all the parameters you can see in Figure 9 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|B|L| Reserved | SEQ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: EAP-Finish/Re-auth Packet
Here's the lineup 🦋 Type = 2.
The flags are where the vibes get a little complicated 🌸
'R'- The R flag is used as the Result flag. When set to 0, it indicates success, and when set to '1', it indicates a failure. ✅'B'- The B flag is used as the bootstrapping flag. If the flag is turned on, the message is a bootstrap message. 🌱'L'- The L flag is used to indicate the presence of the rRK lifetime TLV. 🧚
The rest of the 5 bits are set to 0 and ignored on reception. Nothing to see there, bestie 💜
SEQ is a 16-bit sequence number used for replay protection 🔁 The SEQ number field gets reset to 0 every single time a new rRK is derived, so it starts fresh 🌈
The TVs or TLVs part has its own little format. A TV payload is a 1-octet type plus a value with a type-specific length 🎀 A TLV payload is a 1-octet type plus a 1-octet length. That length field tells you how many octets the value is 🧮
Now the attributes, which are the real stars ⭐
- keyName-NAI is carried in a TLV payload, and its Type is 1 💖 The NAI is variable in length but doesn't go past 253 octets. The EMSKname sits in the username part of the NAI and is encoded in hexadecimal values. Because the EMSKname is 64 bits long, the username portion takes up 16 octets 🫶 If the rIK is derived from the EMSK, the realm part of the NAI is the home domain name. If the rIK is derived from a DSRK, the realm part is the domain name used in deriving that DSRK. The NAI syntax follows [4]. Exactly one instance of the keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth message. Only one, no more, no less 👑
- rRK Lifetime is a TV payload with Type 2 ⏳ Its value field is 32 bits and holds the lifetime of the rRK in seconds. If the 'L' flag is set, the rRK Lifetime attribute SHOULD be present 🍓
- rMSK Lifetime is a TV payload with Type 3 🕰️ Its value field is 32 bits and holds the lifetime of the rMSK in seconds. If the 'L' flag is set, the rMSK Lifetime attribute SHOULD be present 💅
- Domain-Name is a TLV payload with Type 4 🌐 The domain name gets used as the realm in an NAI [4]. The Domain-Name attribute MUST be present in an EAP-Finish/Re-auth message if the bootstrapping flag is set and the local ER server sent a DSRK request. Non-negotiable, bestie 😭
- List of cryptosuites is a TLV payload with Type 5 🔐 Its value field holds a list of cryptosuites, each 1 octet in size, and the cryptosuite values are as specified in Figure 8. The server SHOULD include this attribute if the cryptosuite used in the EAP-Initiate/Re-auth message was not acceptable and the message is being rejected. The server MAY include this attribute in other cases. The server MAY also use it to signal its cryptographic algorithm capabilities to the peer 🧁
- Authorization Indication is a TLV payload with Type 6 🔑 It MAY be included in the EAP-Finish/Re-auth message when a DSRK is delivered to a local ER server, and only if the home ER server can verify the local ER server is allowed to advertise the domain name in the domain TLV of that same message 🛡️ Its value field holds an authentication tag computed over the entire packet, from the first bit of the code field to the last bit of the cryptosuite field. For that computation, the value field of the Authorization Indication TLV is filled with all 0s. The key for the computation MUST be derived from the EMSK with key label "DSRK Delivery Authorized Key@ietf.org" and optional data containing an ASCII string that represents the key management domain the DSRK is being derived for 🌸
In addition, channel binding information MAY be included. See Section 5.5 for discussion, and see Figure 11 for parameter specification 🎀 The server sends this info so the peer can verify what it saw at the lower layer, if channel binding is going to be supported 🫶
- Cryptosuite is the field that tells you the integrity algorithm and the PRF used for ERP 🧠 Key lengths and output lengths are either indicated or obvious from the cryptosuite name ✨
- Authentication Tag holds the integrity checksum over the ERP packet, minus the authentication tag field itself 🦋 Its length is set by the Cryptosuite 🌈
5.3.4. TV and TLV Attributes ✨
Time for the attribute formats 🧚 The TV attributes that may be present in the EAP-Initiate or EAP-Finish messages look like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: TV Attribute Format
The TLV attributes that may be present in the EAP-Initiate or EAP-Finish messages look like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: TLV Attribute Format
These are the Types defined in this document, bestie 👑
'1'- keyName-NAI: This is a TLV payload. 💖'2'- rRK Lifetime: This is a TV payload. ⏳'3'- rMSK Lifetime: This is a TV payload. 🕰️'4'- domain name: This is a TLV payload. 🌐'5'- cryptosuite list: This is a TLV payload. 🔐'6'- Authorization Indication: This is a TLV payload. 🔑
The TLV type range of 128-191 is reserved to carry channel binding information in the EAP-Initiate and Finish/Re-auth messages. 🦋 Here are the current assignments (all of them are TLVs):
'128'- Called-Station-Id [13] 📞'129'- Calling-Station-Id [13] 📱'130'- NAS-Identifier [13] 🏷️'131'- NAS-IP-Address [13] 🌍'132'- NAS-IPv6-Address [16] 🌐
The length field tells you the length of the value part of the attribute in octets 🧮
5.4. Replay Protection
okay so, replay protection is ERP's bouncer 🚪💅 ERP uses sequence numbers for this. The sequence number is maintained per rIK and starts at zero in both directions 🔢 In the first EAP-Initiate/Re-auth message, the peer uses the sequence number zero or higher. Note that the when the sequence number rotates, the rIK MUST be changed by running EAP authentication. 🔄 The server expects a sequence number of zero or higher. When the server receives an EAP-Initiate/Re-auth message, it uses that same sequence number in the EAP-Finish/Re-auth message. Then it sets the expected sequence number to the received sequence number plus 1. The server accepts any sequence number greater than or equal to the expected one 🫶
Now the peer side, which is a little dramatic 😭 If the peer sends an EAP-Initiate/Re-auth message but doesn't get a response, it retransmits the request, with no changes to the message itself, a pre-configured number of times before giving up. But it's totally plausible that the server already responded and the response just got lost in transit 🥺 So the peer MUST increment the sequence number and use the new one for any later EAP re-authentication messages. The peer SHOULD increment the sequence number by 1, though it may choose to increment by a larger number 🧚 And when the sequence number rotates, the peer MUST run full EAP authentication 🌈
5.5. Channel Binding
ERP has a protected spot to carry channel binding (CB) information 🔒 It follows the guidelines in Section 7.15 of [2]. The TLV type range of 128-191 is reserved to carry CB information in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth messages. Called-Station-Id, Calling-Station-Id, NAS-Identifier, NAS-IP-Address, and NAS-IPv6-Address are examples of channel binding information listed in RFC 3748, and they're assigned values 128-132. Additional values are IANA managed based on IETF Consensus [17] 🎀
The authenticator MAY provide CB information to the peer via the EAP-Initiate/Re-auth-Start message. The peer then sends that information to the server in the EAP-Initiate/Re-auth message, and the server checks whether the authenticator identity available via AAA attributes is the same as the identity given to the peer 🕵️♀️
If the peer doesn't include the CB information in the EAP-Initiate/Re-auth message, and the local ER server's policy requires channel binding support, the server SHALL send the CB attributes so the peer can verify them 🫶 The peer tries to verify the CB information if the authenticator sent the CB parameters, and it goes ahead with the lower-layer security association establishment if the attributes match. Otherwise, the peer SHALL NOT proceed with the lower-layer security association establishment 🚫💜
6. Lower-Layer Considerations ✨
okay so the authenticator is the one in charge of retransmitting EAP-Initiate/Re-auth-Start messages 🔁. it MAY retransmit the message a few times, or until it gets an EAP-Initiate/Re-auth message back from the peer. ngl the authenticator might not know whether the peer supports ERP at all, so the peer could be silently dropping those EAP-Initiate/Re-auth-Start packets 🙈. that's why retransmitting them should be kept to a minimum. the exact number is up to each lower layer 🫶.
The Identifier value in the EAP-Initiate/Re-auth packet is independent of the Identifier value in the EAP-Initiate/Re-auth-Start packet. no mixing them up, bestie 💜.
The peer is responsible for retransmitting EAP-Initiate/Re-auth messages 📨.
Retransmitted packets MUST be sent with the same Identifier value so they can be told apart from brand-new packets 🦋. by default, when the EAP-Initiate message goes over an unreliable lower layer, the retransmission timer SHOULD be dynamically estimated ⏱️. a maximum of 3-5 retransmissions is suggested, based on the recommendation of [2] 🎀. when the EAP-Initiate message goes over a reliable lower layer, though, the retransmission timer SHOULD be set to an infinite value, so retransmissions don't happen at the EAP layer 🧚. for more tips on setting timers, check out RFC 3748 [2] 📚.
The Identifier value in the EAP-Finish/Re-auth packet is the same as the Identifier value in the EAP-Initiate/Re-auth packet 💖.
Now this part is so important 😭. if an authenticator gets a valid duplicate EAP-Initiate/Re-auth message and it has already sent an EAP-Finish/Re-auth message, it MUST resend the EAP-Finish/Re-auth message without reprocessing the EAP-Initiate/Re-auth message 🔥. to make that possible, the authenticator SHALL store a copy of the EAP-Finish/Re-auth message for a finite amount of time ⏳. how long is up to local choice, but this specification recommends 100 milliseconds 🌸.
The lower layer may provide facilities for the peer and the authenticator to exchange information about ERP support 🌈. it can also be used for the authenticator to send the domain name information and channel binding information to the peer 🍓.
heads up: to support ERP, some lower-layer specifications may need to be revised 👑. specifically, IEEE802.1x must be revised so it can carry EAP messages with the new codes defined in this document. similarly, RFC 4306 must be updated to include EAP code values higher than 4 if you want to use ERP with Internet Key Exchange Protocol version 2 (IKEv2) 💀. IKEv2 may also be updated to support peer-initiated ERP for optimized operation ✨. other lower layers may need similar revisions too 💅.
Our analysis shows that some EAP implementations are not RFC 3748 compliant. instead of silently dropping EAP packets with code values higher than 4, they may treat it as an error 😤. to accommodate those non-compliant implementations, extra guidance is provided below 🫶. it may also not be easy to upgrade all the peers in some cases, so authenticators may be configured to not send EAP-Initiate/Re-auth-Start, and peers may learn whether an authenticator supports ERP via configuration or from advertisements at the lower layer 🎀.
To accommodate implementations that are not compliant with RFC 3748, such lower layers SHOULD ensure that both parties support ERP 🧁. this is trivial when you're using a lower layer that is known to always support ERP 🙌. for lower layers where ERP support is not guaranteed, ERP support may be indicated through signaling (for example, piggy-backed on a beacon) or through negotiation 📡. you can also have clients recognize environments where ERP is available based on pre-configuration, and other similar mechanisms may be used too 🦋. when ERP support can't be verified, lower layers may mandate falling back to full EAP authentication, so non-compliant EAP implementations are still covered 🫧.
7. Transport of ERP Messages 🚀
AAA transport of ERP messages is specified in [11] and [12] 💜. go check those out for the full scoop 💅.
8. Security Considerations 🔐✨
Okay bestie, this part is the serious one 🥺 Section 8 is the security analysis, and it goes through the AAA key management requirements from [18] one by one. Let's get into it 💅
Cryptographic algorithm independence
The EAP Re-auth Protocol slays this requirement 👑 The algorithm the peer picks for MAC generation shows up in the EAP-Initiate/Re-auth message. If that algorithm is unacceptable, the EAP server sends back an EAP-Finish/Re-auth with a Failure indication. Algorithm agility for the KDF is specified in [3]. The server only moves on to deriving keys and checking the peer's proof of possession of the relevant keying material when the algorithms used are acceptable. A full-blown negotiation of algorithms can't fit into a single round trip, so ngl, the protocol has algorithm agility but it does not have true negotiation 🫶
Strong, fresh session keys
ERP derives strong, fresh keys that are unique to each session 🔥 An rMSK is always derived on-demand when the peer needs a key with a new authenticator. The derivation makes sure that compromising one rMSK doesn't compromise a different rMSK, at any time. Main character energy, literally 🦋
Limit key scope
The scope of every key ERP derives is well defined 🎀 The rRK and rIK are never shared with any entity, and they always stay on the peer and the server. The rMSK only goes to the authenticator the peer used for the ERP exchange. No other authenticator is allowed to use that rMSK 🙅♀️
Replay detection mechanism
For replay protection of ERP messages, a sequence number tied to the rIK gets used 🔢 The peer and the server both maintain it, and it starts at zero when the rIK is generated. The peer adds one to the sequence number after it sends an ERP message. After the server verifies that a received message is valid, it sets the expected sequence number to the received one plus one, and then it responds to the message ✨
Authenticate all parties
The EAP Re-auth Protocol gives you mutual authentication between the peer and the server 🤝 Both parties need the keying material from a previous EAP exchange to derive the required keys. The EAP re-authentication Response and the EAP re-authentication Information messages are both integrity protected, so the peer and the server can verify each other. When the ERP exchange runs with a local ER server, the peer and the local server mutually authenticate each other through that exchange in the same way. The peer and the authenticator authenticate each other in the secure association protocol run by the lower layer, just like in a regular EAP exchange 💖
Peer and authenticator authorization
The peer and the authenticator show they have the same key material without revealing it, as part of the lower-layer secure association protocol 🕵️♀️ Channel binding with ERP may be used to check that the identities exchanged are consistent, for when the identities used in the lower layer are different from the ones exchanged within the AAA protocol 🧚
Keying material confidentiality
The peer and the server derive the keys independently, using parameters that each entity knows 🔑 The AAA server sends the DSRK of a domain to the matching local ER server through the AAA protocol. The ER server then sends the rMSK to the authenticator through the AAA protocol too.
Note that compromising the DSRK means compromising every key derived from it 😭 Also, there's no forward secrecy within ERP, so compromising a DSRK retroactively compromises all ERP keys. Yikes.
It is RECOMMENDED that the AAA protocol be protected with IPsec or TLS so the keys are protected in transit 🛡️ Heads up though: keys may be exposed to AAA proxies along the way, and if any of those proxies gets compromised, the keys being transported through them may be compromised too.
The home ER server MUST NOT hand out a given DSRK to a local domain server more than once, unless it can verify that the entity receiving the DSRK the second time is the same one that got it originally 🚫 If the home ER server verifies the authorization of a local domain server, it MAY hand out the DSRK to that domain more than once. In that case, the home ER server includes the Authorization Indication TLV to assure the peer that the DSRK delivery is secure 🎀
Confirm cryptosuite selection
Crypto algorithms for integrity and key derivation in the context of ERP MAY be the same as the ones used by the EAP method 💅 When they are, the EAP method is responsible for confirming the cryptosuite selection. The cryptosuite gets included in the ERP exchange by the peer and confirmed by the server. The protocol lets the server reject the cryptosuite the peer selected and offer alternatives instead. When a suitable rIK isn't available for the peer, those alternatives may be sent unprotected 🙈 The peer can retry the exchange with one of the allowed cryptosuites. But in that case, any en route modifications to the list sent by the server will go undetected. If the server does have an rIK available for the peer, the list is provided in a protected manner and this issue doesn't apply 🌸
Uniquely named keys
Every key produced in the ERP context can be referred to uniquely, as specified in this document 🏷️ Also, the key names don't reveal any part of the keying material 🤫
Prevent the domino effect
Compromising one peer doesn't compromise the keying material held by any other peer in the system 🧱 The rMSK is meant for a single authenticator and isn't shared with any other authenticator, so compromising one authenticator doesn't lead to the compromise of sessions or keys held by any other authenticator in the system. Hence, the EAP Re-auth Protocol can prevent the domino effect by defining key scope properly 👑
However, if keys are transported using hop-by-hop protection, compromising a proxy may result in compromising key material, i.e., the DSRK being sent to a local ER server ⚠️
Bind key to its context
All the keys derived for ERP are bound to the appropriate context using appropriate key labels 🏷️ The lifetime of a child key is less than or equal to that of its parent key, as specified in RFC 4962 [18]. The key usage, lifetime, and the parties that have access to the keys are all specified ✨
Confidentiality of identity
Deployments where privacy matters may find that using the rIKname-NAI to route ERP messages meets their privacy requirements 🙈 Note that it's plausible to link multiple runs of ERP messages together, since the rIKname isn't changed as part of the ERP protocol. There was no consensus on that requirement when this specification was being developed. If the rIKname isn't used and the Peer-ID is used instead, the ERP exchange will reveal the Peer-ID over the wire 👀
Authorization restriction
Every key derived is limited in lifetime by that of its parent key or by server policy ⏳ Any domain-specific keys are further restricted to use only in the domain they were derived for 🏡 All the keys specified in this document are meant for use in ERP only. Any other restrictions on session keys may be imposed by the specific lower layer, and those are out of scope for this specification 🫶
A denial-of-service (DoS) attack on the peer may be possible when using the EAP Initiate/Re-auth message 🚨 An attacker may send a bogus EAP-Initiate/Re-auth message, which the authenticator may carry in a RADIUS-Access-Request to the server. In response, the server may send an EAP-Finish/Re-auth with a Failure indication in a RADIUS Access-Reject message. Note that such attacks may be plausible with the EAPoL-Start capability of IEEE 802.11 and other similar facilities in other link layers, wherever the peer can initiate EAP authentication. An attacker may use such messages to start an EAP method run that fails, which may result in the server sending a RADIUS Access-Reject message, and that results in the link-layer connections being terminated 😱
To prevent such DoS attacks, an ERP failure should not result in deletion of any authorization state established by a full EAP exchange 🛑 Alternatively, the lower layers and AAA protocols may define mechanisms that allow two link-layer security associations (SAs) derived from different EAP keying materials for the same peer to exist. That way, a smooth migration from the current link-layer SA to the new one is possible during rekey. These mechanisms stop the link-layer connections from being terminated when a re-authentication procedure fails because of a bogus EAP-Initiate/Re-auth message 💪
When a DSRK is sent from a home ER server to a local domain server, or when an rMSK is sent from an ER server to an authenticator, and there's no end-to-end security between the entity sending the key and the entity receiving it, it's plausible that other entities could get access to keys being sent to an ER server in another domain 👀 This mode of key transport is similar to MSK transport in the context of EAP authentication. We also observe that ERP is for access authentication and does not support end-to-end data security. In typical implementations, the traffic is in the clear beyond the access control enforcement point (the authenticator, or an entity delegated by the authenticator for access control enforcement). The model works as long as entities in the middle of the network don't use keys intended for other parties to steal service from an access network 🕶️ If that isn't achievable, key delivery must be protected in an end-to-end manner 🔒
9. IANA Considerations 📋✨
okay bestie, IANA time 🦋 this section is basically the registry paperwork, and it's SO important because it's how the numbers get locked in for everyone.
This doc asks IANA to register two new Packet Codes in the EAP registry:
5(Initiate)6(Finish)
These values follow [2] 💅
It also asks for a brand new table called Message Types in the EAP registry, with these numbers:
0Reserved1(Re-auth-Start, applies to Initiate Code only)2(Re-auth, applies to Initiate and Finish Codes)3-191IANA managed and assigned based on IETF Consensus [17]192-255Private use
Next up is another new table, EAP Initiate and Finish Attributes, tied to the EAP Initiate and Finish messages in the EAP registry. Here's how the numbers shake out:
0: Reserved- keyName-NAI: This is a TLV payload. The Type is
1. - rRK Lifetime: This is a TV payload. The Type is
2. - rMSK Lifetime: This is a TV payload. The Type is
3. - Domain name: This is a TLV payload. The Type is
4. - Cryptosuite list: This is a TLV payload. The Type is
5. - Authorization Indication: This is a TLV payload. The Type is
6. 7-127: Used to carry other non-channel-binding-related attributes. IANA managed and assigned based on IETF Consensus [17].- The TLV type range of
128-191is reserved to carry CB information in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth messages. Here are the current assignments (all of them are TLVs) 🎀:- Called-Station-Id:
128 - Calling-Station-Id:
129 - NAS-Identifier:
130 - NAS-IP-Address:
131 - NAS-IPv6-Address:
132 133-191: Used to carry other channel-binding-related attributes. IANA managed and assigned based on IETF Consensus [17].
- Called-Station-Id:
192-255: Reserved for Private use.
Then there's a registry called Re-authentication Cryptosuites 🔐
0: Reserved1: HMAC-SHA256-642: HMAC-SHA256-1283: HMAC-SHA256-2564-191: IANA managed and assigned based on IETF consensus [17]192-255: Reserved for Private use.
Last but not least, this doc registers a Re-auth usage label from the "USRK Key Labels" name space, with the value
EAP Re-authentication Root Key@ietf.organd a DSRK-authorized delivery key, also from the "USRK Key Labels" name space, with the value
DSRK Delivery Authorized Key@ietf.orgAll of that follows [3] 💖
10. Acknowledgments 🫶
The authors gave a huge shoutout to everyone they talked the problem space and the protocol through, including Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and the other participants of the HOKEY working group ✨
Some specific credit: the idea to use EAP-Initiate/Re-auth-Start goes to Charles Clancy 👑. The multiple link-layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba 🛡️. Katrin Hoeper suggested the windowing technique for handling multiple simultaneous ER exchanges 🌸. Pasi Eronen gets the win for suggesting hexadecimal encoding for rIKname when it's sent as part of the keyName-NAI field 🍓. Bernard Aboba helped clarify the EAP lock-step operation, and Joe Salowey and Glen Zorn helped specify AAA transport of ERP messages 🧚. And Sam Hartman came through with the DSRK Authorization Indication mechanism 💅
11. References 📚
11.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
- [3] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008.
- [4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
- [5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
11.2. Informative References
- [6] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
- [7] Lopez, R., Skarmeta, A., Bournelle, J., Laurent-Maknavicus, M., and J. Combes, "Improved EAP keying framework for a secure mobility access service", IWCMC '06, Proceedings of the 2006 International Conference on Wireless Communications and Mobile Computing, New York, NY, USA, 2006.
- [8] Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Work in Progress, October 2003.
- [9] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, "Handover Key Management and Re-Authentication Problem Statement", RFC 5169, March 2008.
- [10] Institute of Electrical and Electronics Engineers, "IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2004", December 2004.
- [11] Nakhjiri, M. and Y. Ohba, "Derivation, delivery and management of EAP based keys for handover and re-authentication", Work in Progress, February 2008.
- [12] Gaonkar, K., Dondeti, L., Narayanan, V., and G. Zorn, "RADIUS Support for EAP Re-authentication Protocol", Work in Progress, February 2008.
- [13] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
- [14] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
- [15] Dondeti, L. and H. Tschofenig, "Diameter Support for EAP Re-authentication Protocol", Work in Progress, November 2007.
- [16] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
- [17] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [18] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
Appendix A. Example ERP Exchange 🎬
Here's the whole ERP dance, step by step 💃
0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start]
1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI,
cryptosuite,Auth-tag*)
1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id,
EAP Initiate/Re-auth(SEQ,keyName-NAI,
cryptosuite,Auth-tag*)
2. ER-Server --> Authenticator: AAA-Response{rMSK,
EAP-Finish/Re-auth(SEQ,keyName-NAI,
cryptosuite,[CB-Info],Auth-tag*)
2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI,
cryptosuite,[CB-Info],Auth-tag*)
* Auth-tag computation is over the entire EAP Initiate/Finish
message; the code values for Initiate and Finish are different and
thus reflection attacks are mitigated.Authors' Addresses 🖊️
Vidya Narayanan
Qualcomm, Inc.
5775 Morehouse Dr.
San Diego, CA 92121
USA
Phone: +1 858-845-2483
EMail: vidyan@qualcomm.com
Lakshminath Dondeti
Qualcomm, Inc.
5775 Morehouse Dr.
San Diego, CA 92121
USA
Phone: +1 858-845-1267
EMail: ldondeti@qualcomm.comFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 💜
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 🦋
📦 where this page comes from
- ietf: rfc5296 2008-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms