RFC 6696
EAP Extensions for the EAP Re-authentication Protocol (ERP)
RFC 6696: EAP Extensions for the EAP Re-authentication Protocol (ERP) 🦋
okay bestie, this is RFC 6696 🎀. It's on the Standards Track (ISSN 2070-1721) and it was published in July 2012. The authors are Z. Cao (China Mobile), B. He (CATR), Y. Shi, Q. Wu, Ed. (Huawei), and G. Zorn, Ed. (Network Zen). It obsoletes RFC 5296 💀, and the header doesn't list an Updates line, so it doesn't update anything else. 💅
Abstract ✨
EAP is a generic framework that supports lots of different authentication methods 🧚. When EAP is used for authentication, it's desirable to avoid repeating the entire EAP exchange with another authenticator. So this doc specifies extensions to EAP and the EAP keying hierarchy 🔑. The goal is an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server, going through any authenticator. The re-authentication server may live in the home network or in the local network the peer is connecting to 🏠.
This memo obsoletes RFC 5296 🫶.
Status of This Memo 🎀
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF) 🌈. It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741 📚.
For the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6696 🔗.
Copyright Notice 🔒
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 🧾. Code Components extracted from this document must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚠️.
Table of Contents 📜
1. Introduction ....................................................4
1.1. Changes from RFC 5296 ......................................5
2. Terminology .....................................................5
3. ERP Description .................................................7
3.1. ERP with the Home ER Server ...............................10
3.2. ERP with a Local ER Server ................................11
4. ER Key Hierarchy ...............................................13
4.1. rRK Derivation ............................................13
4.2. rRK Properties ............................................14
4.3. rIK Derivation ............................................14
4.4. rIK Properties ............................................15
4.5. rIK Usage .................................................16
4.6. rMSK Derivation ...........................................16
4.7. rMSK Properties ...........................................17
5. Protocol Details ...............................................17
5.1. ERP Bootstrapping .........................................17
5.2. Steps in ERP ..............................................20
5.2.1. Multiple Simultaneous Runs of ERP ..................23
5.2.2. ERP Failure Handling ...............................23
5.3. EAP Codes .................................................25
5.3.1. EAP-Initiate/Re-auth-Start Packet ..................26
5.3.1.1. Authenticator Operation ...................27
5.3.1.2. Peer Operation ............................27
5.3.2. EAP-Initiate/Re-auth Packet ........................28
5.3.3. EAP-Finish/Re-auth Packet ..........................30
5.3.4. TV and TLV Attributes ..............................32
5.4. Replay Protection .........................................33
5.5. Channel Binding ...........................................34
6. Lower-Layer Considerations .....................................35
7. AAA Transport of ERP Messages ..................................36
8. Security Considerations ........................................36
9. IANA Considerations ............................................41
10. Contributors ..................................................41
11. Acknowledgments ...............................................42
12. References ....................................................42
12.1. Normative References .....................................42
12.2. Informative References ...................................42
Appendix A. RFC 5296 Acknowledgments ..............................45
Appendix B. Sample ERP Exchange ...................................461. Introduction 🌸
okay so EAP is an authentication framework that supports multiple authentication methods 🧚. Its main job is network access authentication, and a key-generating method gets used when the lower layer wants to enforce access control 🔐. The EAP keying hierarchy defines two keys that every key-generating EAP method derives: 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 an entity it controls, does the access enforcement 🚪. After a successful authentication, the EAP server hands the MSK to the EAP authenticator. Then the authenticator and the EAP peer set up Transient Session Keys (TSKs) using the MSK as the authentication key, key derivation key, or key transport key, and they use the TSK for per-packet access enforcement 💖.
when a peer moves from one authenticator to another, a full EAP authentication is not something you want, because it'd slow down the handover 😭. A full EAP exchange with another run of the EAP method can take several round trips and a lot of time, which means longer handover times. Some EAP methods reuse state from the initial authentication to speed up re-authentication by cutting the computational overhead (for example, EAP Authentication and Key Agreement (EAP-AKA) [RFC4187]). Still, method-specific re-authentication takes at least 2 round trips with the original EAP server in most cases 🙈. And honestly, several methods don't support re-authentication at all 💀.
Key sharing across authenticators is sometimes used as a practical way to lower handover times. The catch is that if one authenticator gets compromised, the key material established via other authenticators gets compromised too 😬. Other fast re-authentication solutions are out there in the literature. For example, see Lopez, et al. [MSKHierarchy]. Clancy, et al. also wrote up the EAP re-authentication problem statement in detail [RFC5169] 📖.
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 ⭐.
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). It supports EAP method-independent re-authentication for a peer that has valid, unexpired key material from a previously performed EAP authentication 🫶. The protocol and the key hierarchy needed for EAP re-authentication are described in this document 📘.
Heads up: lower-layer specs may need revising. To support ERP, they may need to allow EAP messages with a code value higher than 4, and to handle the peer-initiated nature of ERP 🚨. Specifically, the Internet Key Exchange (IKE) protocol [RFC5996] must be updated to carry ERP messages. Work on this is in progress [IKE-EXT-for-ERP] 🛠️.
1.1. Changes from RFC 5296 🦋
This document obsoletes RFC 5296, but it's fully backward compatible with that doc 💜. The changes focus on fixing issues that surfaced after the original ERP spec [RFC5296] was published. Here are some of the major ones:
- Co-location of the home EAP Re-authentication (ER) and EAP servers is no longer required (see the "ER Server" entry in Section 2) 🏡.
- The behavior of the authenticator and local ER server during bootstrapping has been clarified (Section 5.1). In particular, the authenticator and/or local ER server is now required to check for current possession of the root keys 🔑.
- The authenticator is now recommended, rather than just allowed, to start the ERP conversation with the
EAP-Initiate/Re-auth-Startmessage (Section 5.3.1.1) 🎬.
There are also tons of editorial changes to make the doc clearer and clear up any perceived ambiguities 🧹. A full list of changes isn't given here, for practical reasons 🙈.
2. Terminology ✨
okay bestie, first things first: the BCP 14 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119] 🎀
This doc uses the basic EAP terminology from [RFC3748] and the EMSK keying hierarchy terminology from [RFC5295]. On top of that, it defines a bunch of extra terms, and these are the ones you need to know 🦋
- ER Peer 💖: An EAP peer that supports the EAP Re-authentication Protocol. Every mention of "peer" in this document means an ER peer, unless it's specifically called out otherwise.
- ER Authenticator 🌸: An entity that supports the authenticator functionality for EAP re-authentication described in this document. Every mention of "authenticator" here means an ER authenticator, unless it's specifically noted otherwise.
- ER Server 👑: An entity that does the server part of ERP as described here. This entity may or may not be an EAP server. Every mention of "server" means an ER server, unless it's specifically noted otherwise. An ER server is a logical entity 🧚, so it may not necessarily be co-located with, or physically part of, a full EAP server.
- ERX ✨: EAP re-authentication extensions.
- ERP 💅: EAP Re-authentication Protocol. It uses the re-authentication extensions.
- rRK 🔑: re-authentication Root Key, derived from the EMSK or the Domain-Specific Root Key (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. Whether the rIK or DS-rIK is used for that is indicated by the EMSKname [RFC5295], the protocol (which is ERP), and the realm (which tells you the domain name of the ER server). The EMSKname gets copied into the username part of the Network Access Identifier (NAI).
- Domain 🌍: Refers to a "key management domain" as defined in Salowey, et al. [RFC5295]. To keep things simple, 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 might be attached to at any given time.
3. ERP Description 💜
okay so ERP lets a peer and a server mutually check proof of possession of key material from an earlier EAP method run 🔐, and then set up a security association between the peer and the authenticator. The authenticator acts as a pass-through for the re-authentication protocol, kind of like an EAP authenticator does, as described in Aboba, et al. [RFC3748]. ERP is one single round-trip exchange between the peer and the server, and it doesn't care about the lower layer or the EAP method that got used during the full EAP exchange. The ER server can live in the home domain, or in the same (visited) domain as the peer and the authenticator, which is the local domain 🏡
Figure 1 shows the protocol exchange 🦋 The first time the peer attaches to any network, it does a full EAP exchange (shown in Figure 2) with the EAP server, and as a result an MSK gets distributed to the EAP authenticator. The authenticator and the peer then use that MSK to establish TSKs as needed. During that initial EAP exchange, the peer and the server also derive an EMSK, which is used to derive an rRK. To be more precise, the rRK is derived from the EMSK, or from a DSRK, and the DSRK 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 🙈 An rIK is derived from the rRK too, and the peer and the ER server use the rIK to provide proof of possession while doing an ERP exchange. The rIK is also never handed out to any entity, and it's only available to the peer and the server 🔒
Peer ER Authenticator ER 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 1: ERP ExchangeEAP 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 2: EAP AuthenticationTwo EAP codes, EAP-Initiate and EAP-Finish, are specified in this document for EAP re-authentication 🎀 When the peer spots a target authenticator that supports EAP re-authentication, it runs an ERP exchange, as shown in Figure 1. That exchange can happen when the peer attaches to a new authenticator that supports EAP re-authentication, or before it attaches. The peer can start ERP all by itself, or it can do it in response to an EAP-Initiate/Re-auth-Start message from the new authenticator. That EAP-Initiate/Re-auth-Start message is how the authenticator gets to trigger the ERP exchange ⭐ The EAP-Finish message can also be used by the authenticator to announce the local domain name 📣
Here's the tricky part 😭 The authenticator might not know whether the peer supports ERP, or whether the peer already did a full EAP authentication through another authenticator. So the authenticator MAY initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start message, and if there's no response, it MAY send the EAP-Request/Identity message. Sending it this way avoids having two EAP messages in flight at the same time [RFC3748] 💫 The authenticator can send the EAP-Initiate/Re-auth-Start message and then wait a short, locally configured amount of time. That message tells the peer that the authenticator supports ERP. When the peer gets this trigger, it can start the ERP exchange by sending an EAP-Initiate/Re-auth message. If there's still no response from the peer after the necessary number of retransmissions (see Section 6), the authenticator MUST initiate EAP by sending an EAP-Request message, typically the EAP-Request/Identity message 🍓 Also, the authenticator might get an EAP-Initiate/Re-auth message after it already sent an EAP-Request/Identity message. If the authenticator supports ERP, it MUST proceed with the ERP exchange 💖 And when the 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 🙌
If the authenticator doesn't support ERP, it will silently discard EAP-Initiate/Re-auth messages (Section 5.3.2), since the EAP code of those packets is greater than 4 ([RFC3748], Section 4) 🙈 An ERP-capable peer will use up all its EAP-Initiate/Re-auth message retransmissions and then fall back to EAP authentication by responding to EAP-Request/Identity messages from the authenticator. If the peer doesn't support ERP, or it doesn't have unexpired key material from a previous EAP authentication, it drops EAP-Initiate/Re-auth-Start messages. If there's no response to the EAP-Initiate/Re-auth-Start message, the authenticator SHALL send an EAP-Request message (typically EAP-Request/Identity) to start EAP authentication 🌸 From that point on, the rules from RFC 3748 apply. Heads up, this may add a bit of delay before EAP starts. In some lower layers, the delay can be minimized or even skipped if the peer starts EAP itself by sending messages such as EAPoL-Start [IEEE_802.1X] ⚡
The peer sends an EAP-Initiate/Re-auth message that contains the keyName-NAI, which identifies the ER server's domain and the rIK used to protect the message, plus a sequence number for replay protection 🛡️ The EAP-Initiate/Re-auth message is integrity protected with the rIK. The authenticator uses the realm in the keyName-NAI field to send the message to the right ER server. The server uses the keyName to look up the rIK. Once the server has verified proof of possession of the rIK and the freshness of the message, it derives an rMSK from the rRK, using the sequence number as an input to the key derivation. Then the server updates the expected sequence number to the received sequence number plus one 🔢
In response to the EAP-Initiate/Re-auth message, 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. The rMSK gets transported in a similar way to the MSK, along with the EAP-Success message in a full EAP exchange. Hoeper, et al. [RFC5749] talk about an extra key distribution protocol that can be used to transport the rRK from an EAP server to one of many different ER servers that share a trust relationship with the EAP server 🤝
The peer MAY request the rMSK lifetime from the server. 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 ask the server for the rRK lifetime. If it does, the ER server sends the rRK lifetime in the EAP-Finish/Re-auth message 🕰️
The peer verifies the sequence number and the integrity of the message. Then it uses the sequence number in the EAP-Finish/Re-auth message to compute the rMSK. After this point, the lower-layer security association protocol is ready to be triggered 🦋✨
The ER server is located either in the home domain or in the visited domain. When the ER server is in the home domain and there's no local ER server in the visited domain, the peer and the server use the rIK and rRK derived from the EMSK. When the ER server is in the local domain, they use the DS-rIK and DS-rRK that correspond to the local domain 🌍 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 if the peer is in the home domain, or there's no local server in the same domain as the peer, it SHOULD start an ERP bootstrap exchange with the home ER server to get the domain name 🏠✨
the defined ER extensions let you run ERP with an ER server in the home domain. the home ER server can be co-located with a home Authentication, Authorization, and Accounting (AAA) server 🫶 ERP with the home ER server works kinda like the ERP exchange in Figure 1, just with the home server doing the honors 💅
Peer ER Authenticator Home ER 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)
Figure 3: ER Explicit Bootstrapping Exchange/ERP
with the Home ER Server3.2. ERP with a Local ER Server
ok this one is giving local hero era 🦋 the defined ER extensions let you run ERP with an ER server in the local domain (aka the access network) if the peer wanders out of the home domain and there's a local ER server in the visited domain 🧚 the local ER server can be co-located with a local AAA server too
the peer can find out about a local ER server, plus the local domain name (or ER server name), either from a lower-layer advertisement or through an ERP exchange 👀 then 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 when it does ERP in the local domain 💖 Figure 4 shows the ER implicit bootstrapping exchange through a local ER server, and Figure 5 shows ERP with a local ER server
EAP Authenticator Local AAA Agent
Peer /ER Authenticator /Local ER Server Home EAP Server
==== ================== ================ ===============
<-- EAP-Request/ --
Identity
-- EAP Response/-->
Identity --AAA(EAP Response/-->
Identity, --AAA(EAP Response/ -->
[domain name]) Identity,
[DSRK Request,
domain name])
<------------------------ EAP Method exchange------------------>
<---AAA(MSK, DSRK, ----
EMSKname,
EAP-Success)
<--- AAA(MSK, -----
EAP-Success)
<---EAP-Success-----
Figure 4: Implicit Bootstrapping ERP Exchange, Initial EAP ExchangePeer 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 5: Local ERP Exchangeas Figure 4 shows, the local ER server can sit in the path of the full EAP exchange (for example, it could be one of the AAA entities, like AAA proxies, between the EAP authenticator and the peer's home EAP server) 🛤️ in that case, the local ER server asks for the DSRK by sending the domain name to the home EAP server in an AAA message. the home EAP server then computes the DSRK by following the procedure in RFC 5295, and sends the DSRK plus the key name, EMSKname, to the ER server in the claimed domain (which is the local ER server, bestie) 📬 the local domain is responsible for announcing that same domain name to the peer over a lower layer. for example, that could be through DHCP-based local domain name discovery [RFC6440], or through the EAP-Initiate/Re-auth-Start message with the local ER server 🎀
once the local ER server gets 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 🔥 the peer also derives the DSRK, the DS-rRK, and the DS-rIK after it gets the domain name. 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 (starting at zero) for that specific keyName-NAI 🔢
if the peer later attaches to an authenticator inside the local domain, it MAY do an ERP exchange with the local ER server to get an rMSK for the new authenticator. ERP with the local ER server is similar to the ERP exchange shown in Figure 1 🦋
4. ER Key Hierarchy 👑
every time the peer re-authenticates to the network, the peer and the authenticator establish an rMSK. the rMSK does the same jobs that an MSK does, and an MSK is what you get from full EAP authentication 💜 to prove possession of the rRK, we specify the derivation of another key, the rIK. both of these keys come from the rRK, and together they make up the ER key hierarchy 🌈
the rRK is derived from either the EMSK or a DSRK, as specified in Section 4.1. for the purpose of rRK derivation, this document specifies derivation of a Usage-Specific Root Key (USRK) or a Domain-Specific USRK (DSUSRK) [RFC5295] for re-authentication. the USRK designated for re-authentication is the rRK, and a DSUSRK designated for re-authentication is the DS-rRK that's available to a local ER server in a particular domain. to keep things simple, the keys are called without the DS label for the rest of the document. but the scope of the various keys is limited to just the domains they were derived for, in the case of the domain-specific keys 🧠 based on which ER server the peer is doing the ERP exchange with, the peer knows which keys it has to use 🫶
the rRK is used to derive an rIK and rMSKs for one or more authenticators. here's the key hierarchy with the rRK, rIK, and rMSKs 🍓
rRK
|
+--------+--------+
| | |
rIK rMSK1 ...rMSKn
Figure 6: Re-authentication Key Hierarchythe derivations in this document come from RFC 5295, and key derivations and field encodings default to that document wherever this one doesn't say otherwise ✨
4.1. rRK Derivation
the rRK may be derived from the EMSK or a DSRK, and this section gives the relevant key derivations for that 🌸
the rRK is derived as specified in RFC 5295.
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, following the policy stated in RFC 5295 📋
the Key Derivation Function (KDF) and the algorithm agility for the KDF are both as defined in RFC 5295 🔐
an rRK derived from the DSRK is called a DS-rRK in the rest of the document. all of the key derivation and properties in this section stay the same for it 💅
4.2. rRK Properties
the rRK has the following properties. these apply to the rRK no matter which parent key was used to derive it 🦋
- 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 the derivation of the 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.
the rRK is only a root key for re-auth. it never protects data directly, so don't you dare use it for that 🙅♀️💀
4.3. rIK Derivation
the rIK is used for integrity protecting the ERP exchange. it works as the proof of possession of valid key material from a previous full EAP exchange by the peer to the server 🫶
the rIK is derived like this:
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, and it's encoded as specified in RFC 5295 🔢
the cryptosuite and the length of the rIK are both part of the input to the KDF. this makes sure keys stay cryptographically separate if different rIKs of different lengths (for example, for use with different Message Authentication Code (MAC) algorithms) get derived from the same rRK 🧁 the cryptosuite is encoded as an 8-bit number, and you can find the cryptosuite spec in Section 5.3.2 📖
the rIK is referred to by the EMSKname-NAI inside ERP messages. the username part of the EMSKname-NAI is the EMSKname, and the realm is the domain name of the ER server. with ERP against 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 got at the lower layer or through an ERP bootstrapping exchange 🌈
an rIK derived from a DS-rRK is called a DS-rIK in the rest of the document. all of the key derivation and properties in this section stay the same for it ⭐
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.
the rIK is locked to ERP authentication only and can't be used to derive any other keys. no cap, that's the whole point 🔒💜
4.5. rIK Usage 🔑✨
The rIK is the main character here 👑. It's the key that the peer and the ERP server each prove they hold when they talk to the other party. The peer shows it has the rIK by computing the integrity checksum over the EAP-Initiate/Re-auth message. The first time the peer uses the rIK, it gets to choose the integrity algorithm for that key. After that, the peer and the server MUST use the same integrity algorithm with a given rIK for every ERP message protected with that key. They save the algorithm info after the first use and keep using the same one for every later use of that rIK. No switching mid-friendship 🙅♀️💅
If the server's policy doesn't allow the cryptosuite the peer picked, the server SHALL reject the EAP-Initiate/Re-auth message. It SHOULD also send a list of acceptable cryptosuites in the EAP-Finish/Re-auth message. Iconic behaviour from the server, honestly 🫶
The rIK length doesn't have to match the key length an integrity algorithm needs, so there's some conversion going on 🧚
For hash-based MAC algorithms, the key gets hashed down to the required key length using the HMAC algorithm [RFC2104].
For cipher-based MAC algorithms, it depends on the length. 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 the algorithm requires. If the required key length is more than 32 octets, then the first k octets of the rIK are used by the cipher-based MAC algorithm instead 🌈
4.6. rMSK Derivation 🎀
The rMSK gets derived at the peer and the server, and then it's delivered to the authenticator 📬. It's derived following an ERP exchange, so it comes after the chat, not before.
Here's how the rMSK is derived:
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, and it's encoded as specified in RFC 5295 📏
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 called a DS-rIK for the rest of the document. The key derivation and properties in this section stay exactly the same for it 🦋
4.7. rMSK Properties 💜
The rMSK has the following properties, and yes, they're all important 🥹
- The length of the rMSK MUST be equal to the length of the rRK.
- The rMSK is delivered to the authenticator, and it's used for the same purposes an MSK serves when the MSK is used at an authenticator.
- The rMSK is cryptographically separate from any other keys derived from the rRK. Separation is everything 🔐
- 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. Old keys can hang on until they expire, bestie 🕰️
- A given rMSK MUST NOT be shared by multiple authenticators. One rMSK, one authenticator, no sharing 🙅♀️
5. Protocol Details 🌸
5.1. ERP Bootstrapping 🥾🌟
There are two types of bootstrapping for ERP: explicit and implicit 💫
In implicit bootstrapping, the ER-capable authenticator or the local ER server MUST verify whether it has a valid rMSK or rRK corresponding to the peer. If the ER-capable authenticator or the local ER server has the key material for that peer, it MUST be able to respond directly in the same way as the home AAA server does, without forwarding the DSRK Request to the home domain. If it doesn't have the key material, the ER-capable authenticator or the local ER server SHOULD include its domain name in the AAA message that carries the peer's first EAP Response message. It should also request the DSRK from the home EAP server during the initial EAP exchange 📨
If that EAP exchange is successful, the home EAP server sends the DSRK for the specified local AAA client or agent, along with EMSKname and the DSRK lifetime, together with the EAP-Success message. The DSRK is derived using the EMSK and the domain name, as specified in RFC 5295. The local AAA client or agent MUST extract the DSRK, EMSKname, and DSRK lifetime (if present) before it forwards the EAP-Success message to the peer 🎁
Note that the MSK also shows up with the EAP-Success message, and the EAP authenticator extracts it as usual. The peer learns the domain name either through the EAP-Initiate/Re-auth-Start message or through a lower-layer announcement (for example, DHCP [RFC6440]). Once the domain name is available to the peer, during or after the full EAP authentication, the peer attempts to use ERP when it associates with a new authenticator 🚪
If the peer knows there is no local ER server in the visited domain, it SHOULD start ERP explicit bootstrapping (an ERP exchange with the bootstrap flag turned on) with the home ER server to get the rRK 🏠 The peer MAY also start bootstrapping to fetch things like the rRK lifetime from the AAA server 🧾
Here's how ERP explicit bootstrapping goes down:
- The peer sends the
EAP-Initiate/Re-authmessage with the bootstrapping flag set (1). The bootstrap message is always sent to the home ER server, and the keyName-NAI attribute in it gets built like this: the username portion of the NAI contains the EMSKname, and the realm portion contains the home domain name. - The message MUST also 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 came from the claimed entity, which is the peer identified by the Peer-ID, or the rIKname 🕵️♀️
- The peer MAY additionally set the lifetime flag to request the key lifetimes 🕐
- When the ERP-capable authenticator gets the
EAP-Initiate/Re-authmessage from a peer, it checks whether it has the local domain name and valid key material for that peer. If it knows the local domain name and has valid key material for the peer, it MUST be able to respond directly the same way the home ER does, with the local domain name included. If not, it copies the contents of the keyName-NAI into the appropriate AAA attribute, and it may include its domain name in the AAA message that carries theEAP-Initiate/Re-authmessage from the peer. - When the home ER server gets an
EAP-Initiate/Re-authmessage, it checks whether the message is fresh or a replay. It does this by checking whether the received sequence number is equal to or greater than the expected sequence number for that rIK. Then it verifies that the cryptosuite the peer used is acceptable. After that, it verifies the integrity of the message by looking up the rIK and checking the integrity checksum in the Authentication Tag field. If any of the checks fail, the home ER server sends anEAP-Finish/Re-authmessage 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 the EAP authenticator and the peer may have received earlier. If theEAP-Initiate/Re-authmessage is well formed and valid, the server prepares theEAP-Finish/Re-authmessage. The bootstrap flag MUST be set to show 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-authmessage. - If the lifetime flag was set in the
EAP-Initiate/Re-authmessage, the ER server SHOULD include the rRK lifetime and the rMSK lifetime in theEAP-Finish/Re-authmessage. The server may have a local policy for the network to maintain and enforce lifetime unilaterally. In that case, the server need not respond to the peer's request for the lifetime. - If the bootstrap flag is set, the ER server MUST include the domain name to which the DSRK is being sent, along with the
EAP-Finish/Re-authmessage. - If the ER server verifies the authorization of a local ER server, it MAY include the Authorization Indication TLV to tell the peer that the server which received the DSRK, and which 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-authmessage originates at a server that possesses the rIK corresponding to the EMSKname-NAI.
- If the home ER server is involved in the ERP exchange and the exchange is successful, the home ER server SHOULD request the DSRK from the home EAP server. The home EAP server MUST provide the DSRK for the home ER server (derived using the EMSK and the domain name, as specified in RFC 5295), along with EMSKname and the DSRK lifetime, for inclusion in the AAA message. The home ER server SHOULD obtain them before it sends the
EAP-Finish/Re-authmessage 🙌 - The rMSK is also sent along with the
EAP-Finish/Re-authmessage, in an AAA attribute (for an example, see Bournelle, et al. [DIAMETER-ERP]) 📦 - The authenticator receives the rMSK 🎉
- When the peer receives an
EAP-Finish/Re-authmessage with the bootstrap flag set, it checks whether a local domain name is present. If it is, the peer MUST use that name to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName-NAI, and then 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 theEAP-Initiate/Re-auth-Startmessage. 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 ERP and obtaining the relevant keys using Diameter are specified in Bournelle, et al. [DIAMETER-ERP] 📚
Since ER bootstrapping is typically done right after the full EAP exchange, the process can be completed through the same entity that acted as the EAP authenticator for the full EAP exchange. In that case, the lower layer may already have established TSKs based on the MSK it received earlier. The lower layer may then choose to ignore the rMSK received during the ER bootstrapping exchange. Or it may choose to establish a new TSK using the rMSK instead. Either way, the authenticator and the peer know which key is in use based on whether or not a TSK establishment exchange is started 🤝
The bootstrapping exchange may also happen via a new authenticator. When that happens, the rMSK received SHOULD trigger a lower-layer TSK establishment exchange ⚡
5.2. Steps in ERP ✨
okay bestie, so when a peer that already has an active rRK and rIK connects to a new authenticator that supports ERP, it may run an ERP exchange with that authenticator 🦋. ERP is usually peer-initiated, which means it's an EAP-Initiate/Re-auth message followed by an EAP-Finish/Re-auth message 💅. The exchange can happen with a local ER server (if there is one) or with the original EAP server 🌸.
it's also totally plausible for the network to kick off the EAP re-auth process itself 🧚. An ERP-capable authenticator SHOULD send an EAP-Initiate/Re-auth-Start message to show that it supports ERP 🎀. The peer may or may not wait for those messages to arrive before it sends its EAP-Initiate/Re-auth message 🙈.
The EAP-Initiate/Re-auth-Start message SHOULD be sent by an ERP-capable authenticator. The authenticator may retransmit it a few times until it gets an EAP-Initiate/Re-auth message back from the peer 🔁. The peer's EAP-Initiate/Re-auth message might have been sent before it got an EAP-Request/Identity or an 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 those other messages 💀.
Operational Considerations at the Peer:
ERP needs the peer to keep retransmission timers running so the EAP re-auth messages get delivered reliably ⏰. The reliability considerations of Section 4.3 of RFC 3748 apply with the peer as the retransmitting entity 🫶.
ERP has the following steps 👑:
- The ERP-capable authenticator sends the EAP-Initiate/Re-auth-Start message to trigger the ERP exchange 🚀.
- 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 computed over the message.
- When the peer is performing 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 an appropriate attribute (e.g., User-Name [RFC2865]) in the AAA message to the ER server 📨.
- The ER 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 ER 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 ER server MUST then verify that the cryptosuite used by the peer is acceptable. The ER server then proceeds to verify the integrity of the message using the rIK, thereby verifying proof of possession of that key by the peer. If any of these verifications fail, the ER 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-Initiate/Re-auth message, the ER server MUST send an EAP-Finish/Re-auth message with the following contents:
- 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 ER 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 computed 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 ER server causes the rMSK along with this message to be transported to the authenticator. The rMSK is transported in a manner similar to the MSK and the EAP-Success message in a regular EAP exchange 🎁.
- The peer looks up the sequence number to verify whether it is expecting an EAP-Finish/Re-auth message with that sequence number protected by the keyName-NAI. It then verifies the integrity of the message. If the verifications fail, the peer logs an error and stops the process; otherwise, it proceeds 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 via all of them at the same time to the same ER server 🌈. In that case, the ERP messages may arrive out of order, which can make the ER server reject legitimate 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 sequence number values within a window of allowed values. Recall that the sequence number allows replay protection. Replay window maintenance mechanisms are a local matter 🪟.
5.2.2. ERP Failure Handling 💀
If the processing of 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 field of that message. 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; the server MAY include a list of acceptable cryptosuites in the message 🙅♀️.
The peer, upon receiving an EAP-Finish/Re-auth message with the Result flag set to '1', MUST verify the sequence number and, if possible, 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 included by the server. The peer MUST use the appropriate rIK for the subsequent ERP exchange by computing it with the corresponding cryptosuite, as specified in Section 4.3. If the Pseudo-Random Function (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 cannot verify the integrity of the received message, it MAY choose to retry the ERP exchange with one of the cryptosuites in the list of acceptable cryptosuites (in a TLV of Type 5), after a failure has been clearly determined 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 may also mean that the server and peer do not support the same cryptosuites; however, the peer cannot determine if that is the case. Hence, 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 sends an rMSK to the ER authenticator, however, and the peer SHALL run the TSK establishment protocol as usual 🧩.
5.3. EAP Codes 🎀
Two EAP codes are defined for the purpose of ERP: EAP-Initiate and EAP-Finish. The packet format for these messages follows the EAP packet format defined in Aboba, et al. [RFC3748] 📦.
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 7: EAP PacketCode
Two code values are defined for the purpose of ERP:
- 5 Initiate
- 6 Finish
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 an EAP-Finish message. Any new (non-retransmission) EAP-Initiate message MUST use a new Identifier field 🆔.
The Identifier field of the EAP-Finish message MUST match that of the currently outstanding EAP-Initiate message. A peer or authenticator receiving an EAP-Finish message whose Identifier value does not match that of the currently outstanding EAP-Initiate message MUST silently discard the packet 🤫.
In order 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 (Type 1) and Re-auth (Type 2) 🏷️.
Type-Data
The Type-Data field varies according to the value of the Type field in the re-authentication packet 🌟.
5.3.1. EAP-Initiate/Re-auth-Start Packet ✨
okay so the EAP-Initiate/Re-auth-Start packet has the fields in Figure 8 🦋
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 8: EAP-Initiate/Re-auth-Start Packet
Type = 1.- Reserved:
ReservedMUST be zero. Set to zero on transmission and ignored on reception. - One or more Type/Values (TVs) or TLVs are used to convey information to the peer. For example, the authenticator may send the domain name to the peer 💌
- TVs or TLVs: In the TV payloads, there is a 1-octet type payload and a value with type-specific length. In the TLV payloads, there is a 1-octet type payload and a 1-octet length payload. The length field indicates the length of the value expressed in number of octets.
- Domain name: This is a TLV payload with
Type = 4. The domain name is to be used as the realm in an NAI [RFC4282]. The Domain name TLV SHOULD be present in an EAP-Initiate/Re-auth-Start message.
- Domain name: This is a TLV payload with
In addition, channel binding information MAY be included. See Section 5.5 for discussion, and see Figure 12 for parameter specification 🎀
5.3.1.1. Authenticator Operation
To minimize ERP failure times, the authenticator SHOULD send the EAP-Initiate/Re-auth-Start message to indicate support for ERP to the peer. It should also initiate ERP if the peer has already performed full EAP authentication and has unexpired key material 🔥 The authenticator SHOULD include the Domain name TLV so the peer can learn the domain name without needing lower-layer support or the ERP bootstrapping exchange 🫶
The authenticator MAY include channel binding information so the server can verify whether the authenticator is claiming the same identity to both parties 👀
The authenticator MAY retransmit the EAP-Initiate/Re-auth-Start message a few times for reliable transport 🦋
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 does not recognize the EAP-Initiate code value, or if it has already sent the EAP-Initiate/Re-auth message to begin the ERP exchange, it MUST silently discard the EAP-Initiate/Re-auth-Start message 🙈
If the EAP-Initiate/Re-auth-Start message contains the domain name, and the peer does not already have the domain information, the peer SHOULD use that domain name to compute the DSRK. It should then use the corresponding DS-rIK to send an EAP-Initiate/Re-auth message and start an ERP exchange with the local ER server ✨ If there is a local ER server between the peer and the home ER server, and the peer has already initiated an ERP exchange with the local ER server, it SHOULD NOT start an ERP exchange with the home ER server 💅
5.3.2. EAP-Initiate/Re-auth Packet 🌈
The EAP-Initiate/Re-auth packet has the parameters shown 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-Initiate/Re-auth Packet
Type = 2.- Flags
- 'R': The R flag is set to 0 and ignored upon reception.
- 'B': The B flag is the bootstrapping flag. If it is turned on, the message is a bootstrap message.
- 'L': The L flag is used to request the key lifetimes from the server.
- The remaining 5 bits are set to 0 on transmission and ignored on reception.
- SEQ: An unsigned 16-bit sequence number used for replay protection. The SEQ field is initialized to 0 every time a new rRK is derived. The field is encoded in network byte order 🔢
- TVs or TLVs: In the TV payloads, there is a 1-octet type payload and a value with type-specific length. In the TLV payloads, there is a 1-octet type payload and a 1-octet length payload. The length field indicates the length of the value expressed in number of octets.
- keyName-NAI: This is carried in a TLV payload with
Type = 1. The NAI is variable in length and does not exceed 253 octets. The EMSKname is in the username part of the NAI and is encoded in hexadecimal values. The EMSKname is 64 bits long, so 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 of the NAI is the domain name used in the derivation of the DSRK. The NAI syntax is specified in Aboba, et al. [RFC4282]. Exactly one keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth packet 🦋
- keyName-NAI: This is carried in a TLV payload with
In addition, channel binding information MAY be included. See Section 5.5 for discussion, and see Figure 12 for parameter specification 🎀
- Cryptosuite: This field indicates the integrity algorithm used for ERP. Key lengths and output lengths are either indicated or obvious from the cryptosuite name. Some cryptosuites are specified below:
0 RESERVED1 HMAC-SHA256-642 HMAC-SHA256-1283 HMAC-SHA256-256
HMAC-SHA256-128 is mandatory to implement and SHOULD be enabled in the default configuration. That one's the main character 👑
- Authentication Tag: This field contains the integrity checksum over the ERP packet, excluding the Authentication Tag field itself. The length of the field is indicated by the cryptosuite 🔐
5.3.3. EAP-Finish/Re-auth Packet ✨
okay bestie, the EAP-Finish/Re-auth packet is the one that wraps everything up 💅 It carries the parameters shown in Figure 10 🎀
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 10: EAP-Finish/Re-auth PacketThe Type is Type = 2 🦋
Flags 🌸
- 'R' (the Result flag): when it's set to 0, that means success 🥳, and when it's set to '1', that means failure 💀
- 'B' (the bootstrapping flag): if this flag is turned on, the message is a bootstrap message 🧚
- 'L' (the flag for the rRK lifetime TLV): this one tells you the rRK lifetime TLV is there 🍓
The remaining 5 bits are set to 0 when sent and ignored when received. Lowkey simple, but super important 🙈
SEQ 🔥 This is an unsigned 16-bit sequence number used for replay protection. It gets reset to 0 every single time a new rRK is derived. It's encoded in network byte order 💜
TVs or TLVs 💅 TV payloads are a 1-octet type followed by a value with a type-specific length. TLV payloads are a 1-octet type, then a 1-octet length, then the value. The length field tells you how many octets long the value is ✨
Here's the full list of attributes that can show up:
keyName-NAI 🎀 This one is a TLV with Type 1. It's variable in length but never goes over 253 octets. The EMSKname lives in the username part of the NAI and is written in hexadecimal. The EMSKname is 64 bits, so 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 that was used when deriving that DSRK. NAI syntax is specified in [RFC4282]. Exactly one instance of the keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth message, no exceptions, periodt 🫶
rRK Lifetime ⭐ This is a TV with Type 2. Its value is an unsigned 32-bit integer in network byte order, and it tells you how long the rRK lasts in seconds. If the 'L' flag is set, the rRK Lifetime attribute SHOULD be present 🌈
rMSK Lifetime 🦋 This is a TV with Type 3. Same vibe as the rRK one: an unsigned 32-bit integer in network byte order, giving the lifetime of the rMSK in seconds. If the 'L' flag is set, the rMSK Lifetime attribute SHOULD be present 💖
Domain name 👑 This is a TLV with Type 4. The domain name gets used as the realm in an NAI [RFC4282]. 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 🌸 This is a TLV with Type 5. The value is a list of cryptosuites, each one 1 octet long, and the values are the ones listed in Figure 9. The server SHOULD include this attribute if the cryptosuite used in the EAP-Initiate/Re-auth message wasn't acceptable and the message is being rejected. In other cases, the server MAY include it. The server MAY also use it to show the peer what cryptographic algorithms it can handle 🧚
Authorization Indication 🔥 This is a TLV with Type 6. It MAY be included when a DSRK gets delivered to a local ER server, but only if the home EAP server can verify that the local ER server is allowed to advertise the domain name in the domain TLV in that same message. The value holds an authentication tag computed over the entire packet, starting from the first bit of the code field and ending at 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 this MUST be derived from the EMSK with the key label DSRK Delivery Authorized Key@ietf.org, and the optional data is an ASCII string naming the key management domain the DSRK is being derived for 🫶
Channel binding information MAY also be included, so check out Section 5.5 for the tea ☕ Figure 12 has the parameter specification. The server sends this info so the peer can verify what it saw at the lower layer, if channel binding is supported 💜
Cryptosuite 💅 This field tells you which integrity algorithm and PRF are used for ERP. Key lengths and output lengths are either spelled out or obvious from the cryptosuite name ✨
Authentication Tag 🌈 This field holds the integrity checksum over the ERP packet, leaving out the Authentication Tag field itself. The cryptosuite tells you how long this field is 🦋
5.3.4. TV and TLV Attributes 🎀
The TV attributes that can show up in 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 11: TV Attribute FormatThe TLV attributes that can show up in 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 12: TLV Attribute FormatThese are the Types defined in this document 🌈
'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 for carrying channel binding information in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth messages. Here are the current assignments, and yes, they're all TLVs 🫶
'128' - Called-Station-Id [RFC2865]'129' - Calling-Station-Id [RFC2865]'130' - NAS-Identifier [RFC2865]'131' - NAS-IP-Address [RFC2865]'132' - NAS-IPv6-Address [RFC3162]
The length field tells you how many octets long the value part of the attribute is 💅
5.4. Replay Protection 🔥
For replay protection, ERP uses sequence numbers, and they're tracked per rIK. They start at zero in both directions 🦋 In the first EAP-Initiate/Re-auth message, the peer uses a sequence number of zero or higher. The server expects a sequence number of zero or higher too. Note that when the sequence number wraps back to zero, the rIK MUST be changed by running a full EAP authentication. That's a hard reset, bestie 😭
When the server gets an EAP-Initiate/Re-auth message, it uses that same sequence number in the EAP-Finish/Re-auth message. After that, it sets its expected sequence number to the received one plus 1 ✨ The server MUST accept any sequence number greater than or equal to the expected one 💖
Now, if the peer sends an EAP-Initiate/Re-auth message and gets no response, it retransmits the request (with no changes to the message itself) a preconfigured number of times before giving up 🌸 But here's the twist: the server might have actually 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, but it may choose to increment by a larger number 🧚 And if the sequence number wraps back to zero, the peer MUST run full EAP authentication 👑
5.5. Channel Binding 🌈
ERP gives you a protected spot to carry channel binding (CB) information, following the guidelines from Aboba, et al. (see Section 7.15 of [RFC3748]) 🎀 The TLV type range of 128-191 is reserved for 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 a few examples of channel binding information listed in RFC 3748, and they're assigned values 128-132 🦋 Any additional values are managed by IANA, based on IETF Review (formerly called "IETF Consensus") [RFC5226] 💅
The authenticator MAY provide CB information to the peer through the EAP-Initiate/Re-auth-Start message. The peer then sends that info to the server in the EAP-Initiate/Re-auth message, and the server checks whether the authenticator identity available through AAA attributes matches 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 lower-layer security association establishment if the attributes match ✨ Otherwise, the peer SHALL NOT proceed with lower-layer security association establishment 💀
6. Lower-Layer Considerations 🌸
okay so the authenticator is in charge of resending the EAP-Initiate/Re-auth-Start messages 🔁. It MAY retransmit the message a few times, or keep going until it gets an EAP-Initiate/Re-auth message back from the peer. Here's the tea 🫣: the authenticator might not even know if the peer supports ERP. If it doesn't, the peer could be silently tossing those EAP-Initiate/Re-auth-Start packets, so 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 ✨. Two different IDs, no mix-ups!
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 new packets 🎀. By default, where the EAP-Initiate message is sent over an unreliable lower layer, the retransmission timer SHOULD be dynamically estimated. A maximum of 3-5 retransmissions is suggested [RFC3748]. Where the EAP-Initiate message is sent over a reliable lower layer, the retransmission timer SHOULD be set to an infinite value so that retransmissions do not occur at the EAP layer 🧚. Please refer to RFC 3748 for additional guidance on setting timers 📚.
The Identifier value in the EAP-Finish/Re-auth packet is the same as the Identifier value in the EAP-Initiate/Re-auth packet 🫶.
If an authenticator receives a valid duplicate EAP-Initiate/Re-auth message for which 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 this work, the authenticator SHALL store a copy of the EAP-Finish/Re-auth message for a finite amount of time. The actual value of time is a local matter, but this specification recommends a value of 100 milliseconds ⏱️.
The lower layer may provide facilities for exchanging information between the peer and the authenticator about support for ERP, so the authenticator can send the domain name information and channel binding information to the peer 🌈.
Heads up, bestie! To support ERP, lower-layer specifications may need to be revised. Specifically, RFC 5996 must be updated to include EAP code values higher than 4 so ERP can be used 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 🛠️.
Our analysis indicates that some EAP implementations are not RFC 3748 compliant. Instead of silently dropping EAP packets with code values higher than 4, they may consider it an error 💀. To accommodate these non-compliant EAP implementations, some extra guidance is included below. It also may not be easy to upgrade all the peers in some cases. In those cases, authenticators may be configured to not send EAP-Initiate/Re-auth-Start messages, 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 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, piggybacked on a beacon) or through negotiation 📡. Alternatively, clients may recognize environments where ERP is available based on preconfiguration. Other similar mechanisms may also be used. When ERP support cannot be verified, lower layers may mandate falling back to full EAP authentication, so that non-compliant EAP implementations are accommodated 🫠.
7. AAA Transport of ERP Messages 💌
AAA transport of ERP messages is specified by Hoeper, et al. [RFC5749] and Bournelle, et al. [DIAMETER-ERP] 🎀✨.
8. Security Considerations ✨
okay bestie, this is the serious security part 🫶 It analyzes the protocol against the AAA key management guidelines from Housley & Aboba [RFC4962], so let's go through the whole list 💅
Cryptographic algorithm independence
ERP slays this one 💖 The peer picks the algorithm for MAC generation and says so in the EAP-Initiate/Re-auth message. If that algorithm isn't acceptable, the EAP server sends back an EAP-Finish/Re-auth message indicating a failure. Algorithm agility for the KDF is covered in Salowey, et al. [RFC5295]. The server only goes ahead with deriving keys and checking the peer's proof of possession of the key material once the algorithms are deemed acceptable. A full negotiation of algorithms can't fit into a single round-trip protocol, so ERP has algorithm agility but not true negotiation 🦋
Strong, fresh session keys
ERP derives strong, fresh keys that are unique to each session 🔥 An rMSK is always derived on demand, whenever the peer needs a key for a new authenticator. That way, compromising one rMSK can't compromise another rMSK, at any time 👑
Limited key scope
The scope of every key ERP derives is well defined 🎀 The rRK and rIK are never shared with any entity and always stay on the peer and the server. The rMSK only goes to the authenticator the peer runs the ERP exchange through, and no other authenticator is allowed to use it 🙈
Replay detection mechanism
Replay protection for ERP messages uses a sequence number associated with the rIK 🔢 The peer and the server both maintain it, and it's initialized to zero when the rIK is generated. The peer adds one to the sequence number after sending an ERP message. After verifying that a received message is valid, the server sets its expected sequence number to the received one plus one, and then responds to the message 🧚
Authenticating all parties
ERP gives mutual authentication between the peer and the server 🫶 Both parties need the key material from an earlier EAP exchange in order to derive the required keys. Also, the EAP re-authentication Response and EAP re-authentication Information messages are both integrity protected, so the peer and server can verify each other. When the ERP exchange runs against a local ER server, the peer and that local server mutually authenticate each other through the 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 authenticator show that they have the same key material without disclosing it, as part of the lower-layer secure association protocol 🔐 Channel binding with ERP can be used to check that the identities match, when the identities used in the lower layer differ from the ones exchanged within the AAA protocol 🧐
Key material confidentiality
The peer and server derive keys independently, using parameters each entity knows 🗝️ The AAA server sends the DSRK of a domain to the corresponding local ER server over the AAA protocol. The ER server then sends the rMSK to the authenticator over the AAA protocol too.
Heads up, bestie: compromising the DSRK results in compromise of all keys derived from it 😭 There's also no forward secrecy within ERP, so compromising a DSRK retroactively compromises all ERP keys 💀
It is RECOMMENDED that the AAA protocol be protected using IPsec or Transport Layer Security (TLS), so the keys are protected in transit 🔒 Note, though, that keys may be exposed to AAA proxies along the way, and compromising any of those proxies may result in compromising the keys transported through them 😬
The home EAP 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 after the first time is the same entity that received it originally 🚫 If the home EAP server verifies authorization of a local domain server, it MAY hand out the DSRK to that domain more than once. In this case, the home EAP server includes the Authorization Indication TLV to assure the peer that DSRK delivery is secure ✨
Confirming cryptosuite selection
Cryptographic algorithms for integrity and key derivation in the context of ERP MAY be the same as those used by the EAP method. In that case, the EAP method is responsible for confirming the cryptosuite selection 🧁 The cryptosuite is 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 provide alternatives. When a suitable rIK isn't available for the peer, the alternatives may be sent unprotected. The peer can retry the exchange using one of the allowed cryptosuites. However, in this 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 within the context of ERP can be referred to uniquely, as specified in this document 🏷️ Also, the key names don't reveal any part of the key material 🤫
Preventing the domino effect
The compromise of one peer doesn't result in compromising key material held by any other peer 🫧 Also, the rMSK is meant for a single authenticator and isn't shared with any other authenticator. Hence, compromising one authenticator doesn't lead to compromise of sessions or keys held by any other authenticator in the system, and ERP prevents the domino effect by appropriately defining key scope 🧱
But if keys are transported using hop-by-hop protection, compromising a proxy may result in compromise of key material, e.g., the DSRK being sent to a local ER server 😱
Binding a 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 [RFC4962]. The key usage, lifetime, and the parties that have access to the keys are all specified 📋
Confidentiality of identity
Deployments where privacy is a concern may find that using the rIKname-NAI to route ERP messages meets their privacy requirements 🕵️ Note that it's plausible to associate multiple runs of ERP messages, since the rIKname isn't changed as part of ERP. There was no consensus on that requirement at the time this specification was developed 🤷 If the rIKname isn't used and the Peer-ID is used instead, the ERP exchange reveals the Peer-ID over the wire 👂
Authorization restriction
All the derived keys are limited in lifetime by that of the parent key or by server policy ⏳ Any domain-specific keys are further restricted to use only in the domain they're derived for 🌍 All the keys specified in this document are meant for use in ERP only 🎯 Other restrictions on the use of session keys may be imposed by the specific lower layer, but they're out of scope for this specification 🙃
Preventing a DoS attack
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 may be carried by the authenticator in an AAA-Request to the server. In response, the server may send an EAP-Finish/Re-auth message indicating failure in an AAA reply. Note that such attacks may be possible with the EAPoL-Start capability of IEEE 802.11 and other similar facilities in other link layers where the peer can initiate EAP authentication. An attacker may use such messages to start an EAP method run, which fails and may result in the server sending a rejection message, thus resulting 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 to allow two link-layer Security Associations (SAs) derived from different EAP key material for the same peer to exist, so that smooth migration from the current link-layer SA to the new one is possible during rekey 🔁 These mechanisms prevent the link-layer connections from being terminated when a re-authentication procedure fails due to a bogus EAP-Initiate/Re-auth message 🙌
Key material transport
When a DSRK is sent from the home EAP 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 for other entities to get access to keys being sent to an ER server in another domain 😳 This mode of key transport is similar to that of MSK transport in the context of EAP authentication. We further observe that ERP is for access authentication and doesn't 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 so the previous version of this doc, [RFC5296], did a bunch of IANA stuff, and it's giving registry glow-up 🧚💅
- It registered the Packet Codes
InitiateandFinishin the EAP Registry. This doc calls themEAP-InitiateandEAP-Finishall the way through 💜 - It made a Message Types table in the EAP Registry and added a few items to it. This doc calls those
Re-auth-startandRe-auth🎀 - It made an EAP-Initiate and Finish Attributes table in the EAP registry and added several items there. Those items are written up in Section 5.3.4 🦋
- It made a Re-authentication Cryptosuites table in the EAP registry and added several items. Those are recorded at the end of Section 5.3.2 🌸
- It added two items to the USRK Key Labels registry:
- Re-auth usage label
"EAP Re-authentication Root Key@ietf.org", which is recorded in this document in Section 4.1 ⭐ - DSRK-authorized delivery key
"DSRK Delivery Authorized Key@ietf.org", which is recorded in the description of "Authorization Indication" in Section 5.3.3 👑
- Re-auth usage label
10. Contributors 🫶
Barry Leiba contributed all of the text in Section 9 and, as Applications Area Director, insisted upon its inclusion as a condition of publication. Iconic behaviour, honestly 😭🔥
11. Acknowledgments 💖
This doc is largely based on RFC 5296, so huge thanks to everyone who helped with that one (see Appendix A) 🌈 Thanks also to Yaron Sheffer, Sebastien Decugis, Ralph Droms, Stephen Farrell, Charlie Kaufman, and Yoav Nir for their (mostly) useful comments and review 🍓
12. References 📚
12.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC5295] 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.12.2. Informative References
[DIAMETER-ERP]
Bournelle, J., Morand, L., Decugis, S., Wu, Q., and G.
Zorn, "Diameter Support for the EAP Re-authentication
Protocol (ERP)", Work in Progress, June 2012.
[IANA] "Internet Assigned Numbers Authority",
<http://www.iana.org/>.
[IEEE_802.1X]
Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and Metropolitan Area Networks:
Port-Based Network Access Control", IEEE Std 802.1X-2010,
February 2010.
[IKE-EXT-for-ERP]
Nir, Y. and Q. Wu, "An IKEv2 Extension for Supporting
ERP", Work in Progress, May 2012.
[MSKHierarchy]
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.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007.
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti,
"Handover Key Management and Re-Authentication Problem
Statement", RFC 5169, March 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP
Re-authentication Protocol (ERP)", RFC 5296, August 2008.
[RFC5749] Hoeper, K., Ed., Nakhjiri, M., and Y. Ohba, Ed.,
"Distribution of EAP-Based Keys for Handover and
Re-Authentication", RFC 5749, March 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication
Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440,
December 2011.Appendix A. RFC 5296 Acknowledgments 🌸
In writing this doc, we got so much from talking through the problem space and the protocol itself with a bunch of folks, 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 🫶 The idea to use EAP-Initiate/Re-auth-Start goes to Charles Clancy ✨ and the idea to use multiple link-layer SAs to mitigate DoS attacks goes to Yoshi Ohba 🔥 Katrin Hoeper suggested the windowing technique for handling multiple simultaneous ER exchanges 🦋 Many thanks to Pasi Eronen for suggesting hexadecimal encoding for the rIKname when it's sent as part of the keyName-NAI field 💜 Thanks to Bernard Aboba for suggestions on clarifying the EAP lock-step operation, and to Joe Salowey and Glen Zorn for help specifying AAA transport of ERP messages 🎀 Finally, thanks to Sam Hartman for the DSRK Authorization Indication mechanism 👑
Appendix B. Sample ERP Exchange 🦋
Here's the whole ERP flow in one picture, so you can see how the messages hop around 👀
0. Authenticator --> Peer:
EAP-Initiate/Re-auth-Start [Optional]
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 🌈
Zhen Cao
China Mobile
No. 32, Xuanwumenxi Ave., Xicheng District
Beijing 100053
P.R. China
EMail: caozhen@chinamobile.com
Baohong He
China Academy of Telecommunication Research
Beijing
P.R. China
Phone: +86 10 62300050
EMail: hebaohong@catr.cn
Yang Shi
Huawei Technologies Co., Ltd.
156 Beiqing Road, Zhongguancun, Haidian District
Beijing
P.R. China
Phone: +86 10 60614043
EMail: shiyang1@huawei.com
Qin Wu (editor)
Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District
Nanjing, JiangSu 210012
China
Phone: +86-25-84565892
EMail: bill.wu@huawei.com
Glen Zorn (editor)
Network Zen
227/358 Thanon Sanphawut
Bang Na, Bangkok 10260
Thailand
Phone: +66 (0) 909 201060
EMail: glenzorn@gmail.com📦 where this page comes from
- ietf: rfc6696 2012-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms