RFC 6630
EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)
RFC 6630: EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) 💖
Bestie, here's the title block tea ☕. This is an IETF document (Internet Engineering Task Force 🌸) dated June 2012, and it's RFC number 6630. The authors are Z. Cao and H. Deng from China Mobile, Q. Wu from Huawei, and G. Zorn, Ed. from Network Zen 🫶. It's a Standards Track doc, which is the most official vibe possible, and its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so there's no drama there 💅.
Abstract
Okay so the Extensible Authentication Protocol (EAP) is a generic framework 🧚 that supports multiple types of authentication methods.
The EAP Re-authentication Protocol (ERP) adds extensions to EAP and to the EAP keying hierarchy 🔑. The result is an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server, through any authenticator ✨.
Authenticated Anticipatory Keying (AAK) is a method where cryptographic keying material can be established upon one or more Candidate Attachment Points (CAPs) before handover 🦋. AAK uses the AAA infrastructure for key transport.
This document specifies the extensions needed to enable AAK support in ERP 💅.
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 has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 5741 📚.
Info about the current status of this document, any errata, and how to give it feedback is at http://www.rfc-editor.org/info/rfc6630 🌈.
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) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.
Table of Contents 🎀
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ERP/AAK Description . . . . . . . . . . . . . . . . . . . . . 4
4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 7
4.1. Derivation of the pRK and pMSK . . . . . . . . . . . . . . 8
5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 9
5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 9
5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 10
5.3. EAP-Finish/Re-auth Packet and TLV Extension . . . . . . . 12
5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 14
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 15
7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 191. Introduction ✨
EAP [RFC3748] is the generic framework that supports a whole bunch of authentication methods 💅. When EAP is used for authentication, it's really desirable not to repeat the entire EAP exchange with another authenticator 🙈.
ERP [RFC5296] is where things get good. It adds extensions to EAP and the EAP keying hierarchy so you get an EAP method-independent protocol for efficient re-authentication between the EAP re-authentication peer and an EAP re-authentication server, through any authenticator 🦋. The re-authentication server can live in the home network or in the local network that the mobile host (aka the EAP re-authentication peer) is connecting to 🌸.
AAK [RFC5836] is a method where cryptographic keying material can be established upon one or more Candidate Attachment Points (CAPs) before handover 🧚. AAK uses the AAA infrastructure for key transport, so the keys travel through infrastructure that's already there ✨.
This document specifies the extensions needed to enable AAK support in ERP 👑.
2. Terminology 💜
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those words are the official rule words, so treat them seriously 🔥.
2.2. Acronyms
The following acronyms are used in this document. See the references for more details 🍓.
AAA
Authentication, Authorization, and Accounting [RFC3588]
CAP
Candidate Attachment Point [RFC5836]
DSRK
Domain-Specific Root Key [RFC5295]
EA
Abbreviation for "ERP/AAK"
EA Peer
An EAP peer that supports the ERP/AAK. Note that all
references to "peer" in this document imply an EA peer,
unless specifically noted otherwise.
NAI
Network Access Identifier [RFC4282]
pMSK
pre-established Master Session Key
pRK
pre-established Root Key
rIK
re-authentication Integrity Key [RFC5296]
rRK
re-authentication Root Key [RFC5296]
SAP
Serving Attachment Point [RFC5836](Part 1 of 4 💖 Part 2 picks up with Section 3, ERP/AAK Description, and it's going to be so good 🎀)
3. ERP/AAK Description ✨
okay so ERP/AAK is basically how the peer gets its keys ready early 🧚 Upon request by the peer, it lets the network set up cryptographic keying materials on one single Candidate Attachment Point (CAP) before the peer even shows up at the Candidate Access Network (CAN). main character energy, honestly 💅
In this document we just assume the peer supports ERP/AAK 🫶 We also assume the peer has already finished full EAP authentication, and that either the peer or the SAP knows who the neighboring attachment points are. Also, ngl, what a peer does when it doesn't support the ERP-AAK scheme defined here is totally out of scope for this doc 🙈 Figure 1 shows the overall exchange where the keying material gets set up on the CAP:
+------+ +-----+ +-----+ +-----------+
| Peer | | SAP | | CAP | | EA Server |
+--+---+ +--+--+ +--+--+ +-----+-----+
| | | |
a. | [EAP-Initiate/ | | |
| Re-auth-start | | |
| (E flag)] | | |
|<---------------| | |
| | | |
b. | EAP-Initiate/ | | |
| Re-auth | | |
| (E flag) | | |
|--------------->| | |
c. | | AAA(EAP-Initiate/Re-auth(E flag))|
| |--------------------------------->|
| | | +---------+---------+
| | | | CA authorized & |
d. | | | | and EA Keying |
| | | | Distribution |
| | | +---------+---------+
| | | |
| | | |
f. | | AAA (EAP-Finish/Re-auth(E flag)) |
| |<---------------------------------|
g. | EAP-Finish/ | | |
| Re-auth(E flag)| | |
|<---------------| | |
| | | | +-----------+ +---------+
| | | |
| EA Server | | CAP |
| | | |
+-----|-----+ +----|----+
| |
| |
| AAA Request (pMSK) |
e.1|------------------------->|
| |
| |
| |
| AAA Response (Success) |
e.2|<-------------------------|
| |
| |
| |Figure 1 is the ERP/AAK Exchange and Figure 2 is the Key Distribution for ERP/AAK 🎀
ERP/AAK reuses the packet format from ERP, but it adds a new flag so you can tell early authentication apart from EAP re-authentication 🦋 The peer can start ERP/AAK on its own with no external trigger, or it can start ERP/AAK in response to an EAP-Initiate/Re-Auth-Start message from the SAP.
In that second case, the SAP MAY send the identity of one or more Candidate Attachment Points that the SAP is adjacent to, to the peer, inside the EAP-Initiate/Re-auth-Start message (that's step a in Figure 1). The peer SHOULD override the CAP identity(ies) carried in the EAP-Initiate/Re-auth-Start message by sending EAP-Initiate/Re-auth with the E flag set, as long as it knows which CAP it's going to move to 💖 And if the peer doesn't support the EAP-Initiate/Re-auth-Start packet, it MUST be silently discarded 💀
If the peer starts ERP/AAK, the peer MAY send an early-authentication request message (EAP-Initiate/Re-auth with the E flag set). This message carries the keyName-NAI, the CAP-Identifier, rIK, and a sequence number (that's step b in Figure 1) 🍓 The realm inside the keyName-NAI field is used to find the peer's ERP/AAK server. The CAP-Identifier is used to identify the CAP. The re-authentication Integrity Key (rIK) is defined by Narayanan & Dondeti in [RFC5296], and it protects the integrity of the message. The sequence number is there for replay protection 🔥
The SAP SHOULD verify the integrity of this message at step b. If that verification fails, the SAP MUST send an EAP-Finish/Re-auth message with the Result flag set to '1' (Failure). If the verification succeeds, the SAP SHOULD wrap the early-authentication message into an AAA message and send it to the peer's ERP/AAK server, in the realm named in the keyName-NAI field (that's step c in Figure 1) ✨
When the ERP/AAK server gets the message, it MUST first use the keyName from the keyName-NAI to look up the rIK, and then check the integrity and freshness of the message. After that, the ERP/AAK server MUST verify the peer's identity by checking the username portion of the KeyName-NAI. If any of those checks fail, the server MUST send an early-authentication finish message (EAP-Finish/Re-auth with the E flag set) with the Result flag set to '1' 😭 Next, the server MUST authorize the CAP named in the CAP-Identifier TLV. In the success case, the server MUST derive a pMSK from the pRK for the CAP carried in the CAP-Identifier field, using the sequence number associated with the CAP-Identifier as an input to the key derivation (that's step d in Figure 1) 👑
Then the ERP/AAK server MUST transport the pMSK to the authorized CAP over AAA (see Section 7), like the diagram above shows (steps e.1 and e.2 in Figure 2) 🫶 Heads up, the key distribution in Figure 2 is just one part of step d in Figure 1, so they're not the same thing 🙈
Finally, in response to the EAP-Initiate/Re-auth message, the ERP/AAK server SHOULD send the early-authentication finish message (EAP--Finish/Re-auth with the E flag set) to the peer via the SAP. That message carries the identity of the authorized CAP along with the lifetime of the pMSK. If the peer also asks for the rRK Lifetime, the ERP/AAK server SHOULD send the rRK Lifetime in the EAP-Finish/Re-auth message (that's steps f and g in Figure 1) 🌈
4. ERP/AAK Key Hierarchy 🔑
ERP/AAK uses a key hierarchy that's pretty similar to ERP's 💜 The ERP/AAK pre-established Root Key (pRK) is derived from either the EMSK or the DSRK, as described below (see Section 4.1). Generally speaking, the pRK comes from the EMSK if the peer is in its home AAA realm, and from the DSRK if the peer is in a visited realm. The DSRK gets delivered from the EAP server to the ERP/AAK server as specified in [KEYTRAN]. If the peer was already authenticated by ERP or ERP/AAK, the DSRK SHOULD be directly reused 🧚
DSRK EMSK
| |
+---+---+---+---+
|
pRK ...
Figure 3: ERP/AAK Root Key DerivationSimilarly, the pre-established Master Session Key (pMSK) is derived from the pRK 🌸 The pMSK gets established for the CAP when the peer early authenticates to the network. The hierarchy is illustrated in Figure 4, below.
pRK
|
+--------+--------+
|
pMSK ...
Figure 4: ERP/AAK Key Hierarchy4.1. Derivation of the pRK and pMSK 🦋
The rRK is derived as specified in [RFC5295].
pRK = KDF (K, S), where
K = EMSK or K = DSRK and
S = pRK Label | "\0" | length
The pRK Label is an IANA-assigned 8-bit ASCII string:
EAP Early-Authentication Root Key@ietf.org
It gets assigned from the "User Specific Root Keys (USRK) Key Labels" name space, in accordance with Salowey, et al. [RFC5295]. The KDF and the algorithm agility for the KDF are also defined in RFC 5295. The KDF algorithm is indicated in the cryptosuite field or in the list of cryptosuites TLV payload, as specified in Sections 5.2 and 5.3 💅
The pMSK uses the same KDF as the pRK, and it's derived like this:
pMSK = KDF (K, S), where
K = pRK and
S = pMSK label | "\0" | SEQ | length
The pMSK label is the 8-bit ASCII string:
EAP Early-Authentication Master Session Key@ietf.org
The length field refers to the length of the pMSK in octets, encoded as specified in RFC 5295. SEQ is sent by either the peer or the server in the ERP/AAK message, using the SEQ field or the Sequence number TLV. It's encoded as a 16-bit number, as specified in Sections 5.2 and 5.3 ✨
5. Packet and TLV Extension 🎀
This section describes the packet and TLV extensions for the ERP/AAK exchange 💖
5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension 🧚
Figure 5 shows the new parameters contained in the EAP-Initiate/Re-auth-Start packet defined in [RFC5296].
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 |E| Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: EAP-Initiate/Re-auth-Start ExtensionFlags
'E' - The E flag is used to indicate early authentication. This field MUST be set to '1' if early authentication is in use, and it MUST be set to '0' otherwise.
The rest of the 7 bits (Reserved) MUST be set to 0 and ignored on reception.
Type/Values (TVs) and TLVs
CAP-Identifier: Carried in a TLV payload. The format is identical to that of a DiameterIdentity [RFC3588]. It is used by the SAP to advertise the identity of the CAP to the peer. Exactly one CAP-Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start packet if the SAP has performed CAP discovery 🦋
If the EAP-Initiate/Re-auth-Start packet is not supported by the peer, it SHOULD be discarded silently 💜
5.2. EAP-Initiate/Re-auth Packet and TLV Extension 🎀
okay so Figure 6 shows the new bits that get tucked into the EAP-Initiate/Re-auth packet from [RFC5296] 💅
Figure 6: EAP-Initiate/Re-auth Extension
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|x|L|E|Resved | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flags 🦋
'x' - The x flag is reserved. It MUST be ignored on receipt. 🙈
'L' - As defined in Section 5.3.2 of [RFC5296], this bit is used to request the key lifetimes from the server. 🔑
'E' - The E flag is used to indicate early authentication. ⭐
The first bit (R) and final 4 bits (Resved) MUST be set to 0 and ignored on reception. bestie, the R and Resved bits are a vibe check: zeros go in, and they get ignored on the way out 💜
SEQ 🌸
As defined in Section 5.3.2 of [RFC5296], this field is a 16-bit sequence number used for replay protection. 🛡️
TVs and TLVs 🧚
keyName-NAI: As defined in [RFC5296], this is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. The username part of the NAI is the EMSKname used to identify the peer. The realm part of the NAI is the peer's home domain name if the peer talks to the home EA server, or the domain the peer is currently attached to (aka the local domain name) if the peer talks to a local EA server. The SAP figures out whether the KeyName-NAI carries the local domain name by comparing the domain name in the KeyName-NAI with the local domain name associated with the SAP. Exactly one keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth packet, and the realm part of it SHOULD follow the use of internationalized domain names defined in [RFC5890]. 🌍
CAP-Identifier: Carried in a TLV payload. The Type is 11. This field indicates the Fully Qualified Domain Name (FQDN) of a CAP. The value field MUST be encoded as specified in Section 8 of [RFC3315]. Exactly one instance of the CAP-Identifier TLV MUST be present in the ERP/AAK-Key TLV. 🍓
Sequence number: The Type is 7. The value field is a 16-bit field used in the derivation of the pMSK for a CAP. ✨
Cryptosuite 💖
This field indicates the integrity algorithm used for ERP/AAK. Key lengths and output lengths are either indicated or obvious from the cryptosuite name. For example, HMAC-SHA256-128 denotes Hashed Message Authentication Code (HMAC) computed using the SHA-256 function [RFC4868] with a 256-bit key length and the output truncated to 128 bits [RFC2104]. We specify some cryptosuites below:
0-1 RESERVED
2 HMAC-SHA256-128
3 HMAC-SHA256-256HMAC-SHA256-128 is REQUIRED to implement, and it SHOULD be enabled in the default configuration. this one is the main character 👑
Authentication Tag 🔐
This field contains an integrity checksum over the ERP/AAK packet, from the first bit of the Code field to the last bit of the Cryptosuite field, excluding the Authentication Tag field itself. The value field is calculated using the integrity algorithm indicated in the Cryptosuite field and the rIK specified in [RFC5296] as the secret key. The length of the field is indicated by the Cryptosuite.
The peer uses the Authentication Tag to determine the validity of the EAP-Finish/Re-auth message from the server.
If the message doesn't pass verification, or the Authentication Tag is not included in the message, the message SHOULD be discarded silently. 🫥
If the EAP-Initiate/Re-auth packet is not supported by the SAP, it SHOULD be discarded silently. The peer MUST maintain retransmission timers for reliable transport of the EAP-Initiate/Re-auth message. If there is no response to the EAP-Initiate/Re-auth message from the server after the necessary number of retransmissions (see Section 6), the peer MUST assume that ERP/AAK is not supported by the SAP. ⏰
5.3. EAP-Finish/Re-auth Packet and TLV Extension 🌈
Figure 7 shows the new parameters in the EAP-Finish/Re-auth packet from [RFC5296]. 🦋
Figure 7: EAP-Finish/Re-auth Extension
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|x|L|E|Resved | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flags 🎀
'R' - As defined in Section 5.3.3 of [RFC5296], this bit is used as the Result flag. This field MUST be set to '1' to indicate success, and it MUST be set to '0' otherwise. the R bit is the yes/no of the whole thing 🥹
'x' - The x flag is reserved. It MUST be ignored on receipt.
'L' - As defined in Section 5.3.3 of [RFC5296], this bit is used to request the key lifetimes from the server.
'E' - The E flag is used to indicate early authentication.
The final 4 bits (Resved) MUST be set to 0 and ignored on reception.
SEQ 🌷
As defined in Section 5.3.3 of [RFC5296], this field is a 16-bit sequence number used for replay protection. 🔁
TVs and TLVs 🍬
keyName-NAI: As defined in [RFC5296], this is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. Exactly one keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth packet. 🌟
ERP/AAK-Key: Carried in a TLV payload for the key container. The Type is 8. Exactly one ERP/AAK-Key SHALL be present in an EAP-Finish/Re-auth packet. 🧁
The ERP/AAK-Key grammar is:
ERP/AAK-Key ::=
{ sub-TLV: CAP-Identifier }
{ sub-TLV: pMSK Lifetime }
{ sub-TLV: pRK Lifetime }
{ sub-TLV: Cryptosuites }CAP-Identifier: Carried in a sub-TLV payload. The Type is 11 (less than 128). This field indicates the identifier of the candidate authenticator. The value field MUST be encoded as specified in Section 8 of [RFC3315]. At least one instance of the CAP-Identifier TLV MUST be present in the ERP/AAK-Key TLV. 🪄
pMSK Lifetime: Carried in a sub-TLV payload of the EAP-Finish/Re-auth message. The Type is 10. The value field is an unsigned 32-bit field and contains the lifetime of the pMSK in seconds. This value is calculated by the server after performing the pRK Lifetime computation upon receiving the EAP-Initiate/Re-auth message. The rIK SHOULD share the same lifetime as the pMSK. If the 'L' flag is set, the pMSK Lifetime attribute MUST be present. ⏳
pRK Lifetime: Carried in a sub-TLV payload of the EAP-Finish/Re-auth message. The Type is 9. The value field is an unsigned 32-bit field and contains the lifetime of the pRK in seconds. This value is calculated by the server before performing the pMSK Lifetime computation upon receiving an EAP-Initiate/Re-auth message. If the 'L' flag is set, the pRK Lifetime attribute MUST be present. 🕰️
List of Cryptosuites: Carried in a sub-TLV payload. The Type is 5 [RFC5296]. The value field contains a list of cryptosuites (at least one cryptosuite SHOULD be included), each 1 octet in length. The allowed cryptosuite values are as specified in Section 5.2. 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 use this attribute to signal its cryptographic algorithm capabilities to the peer. 📜
Cryptosuite 💫
This field indicates the integrity algorithm and PRF used for ERP/AAK. HMAC-SHA256-128 is REQUIRED to implement, and it SHOULD be enabled in the default configuration. Key lengths and output lengths are either indicated or obvious from the cryptosuite name. 💅
Authentication Tag 🥰
This field contains the integrity checksum over the ERP/AAK packet, from the first bit of the Code field to the last bit of the Cryptosuite field, excluding the Authentication Tag field itself. The value field is calculated using the integrity algorithm indicated in the Cryptosuite field and the rIK [RFC5296] as the integrity key. The length of the field is indicated by the corresponding Cryptosuite.
The peer uses the authentication tag to determine the validity of the EAP-Finish/Re-auth message from a server.
If the message doesn't pass verification, or the authentication tag is not included in the message, the message SHOULD be discarded silently. 🙅♀️
If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is discarded silently. The peer MUST maintain retransmission timers for reliable transport of the EAP-Initiate/Re-auth message. If there is no response to the EAP-Initiate/Re-auth message from the server after the necessary number of retransmissions (see Section 6), the peer MUST assume that ERP/AAK is not supported by the SAP. 💀
5.4. TV and TLV Attributes 🧸
With the exception of the rRK Lifetime and rMSK Lifetime TV payloads, the attributes specified in Section 5.3.4 of [RFC5296] also apply to this document. This document defines new attributes that may be present in the EAP-Initiate and EAP-Finish messages, as below: 🍭
- Sequence number: This is a TV payload. The Type is 7.
- ERP/AAK-Key: This is a TLV payload. The Type is 8.
- pRK Lifetime: This is a TV payload. The Type is 9.
- pMSK Lifetime: This is a TV payload. The Type is 10.
- CAP-Identifier: This is a TLV payload. The Type is 11.
6. Lower-Layer Considerations 🌙
Similar to ERP, some lower-layer specifications may need to be revised to support ERP/AAK. Refer to Section 6 of [RFC5296] for additional guidance. 🪐
7. AAA Transport Considerations 🚀
The AAA transport of ERP/AAK messages is the same as that of the ERP message [RFC5296]. In addition, this document requires AAA transport of the ERP/AAK keying materials delivered by the ERP/AAK server to the CAP. Hence, a new AAA message for the ERP/AAK application should be specified to transport the keying materials. 🔥
8. Security Considerations 🔒
Okay bestie, this part is serious, so let's go. This section checks ERP-AAK against the AAA key management requirements in [RFC4962], one bullet at a time 💅
- Cryptographic algorithm independence: ERP-AAK passes this one. The peer picks the algorithm for calculating the authentication tag 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 with a Failure indication. Not okay, not allowed 🙅♀️
- Strong, fresh session keys: ERP-AAK derives strong, fresh keys that are unique for each CAP ✨ A pMSK only gets derived on demand, whenever the peer needs a key for a new CAP. And compromising one pMSK can't compromise a different pMSK, at any time. Main character energy 👑
- Limit key scope: The scope of every key ERP-AAK derives is well defined 📏 The pRK is used to derive the pMSK for the CAP. Different sequence numbers for each CAP MUST be used to derive a unique pMSK.
- Replay detection mechanism: For replay protection, a sequence number tied to the pMSK gets used 🔁 After the peer sends an ERP/AAK message, it bumps the sequence number up by one. The server sets its expected sequence number to the received one plus one, but only after it has checked that the message is valid. Then it responds to the message.
- Authenticate all parties: ERP gives mutual authentication of the peer and the server 🤝 The peer and the SAP are authenticated through ERP, and the SAP authenticates and trusts the CAP.
- Peer and authenticator authorization: The peer and the authenticator show they have the same keying material without ever revealing it. This happens as part of the lower-layer secure authentication protocol 🫶
- Keying material confidentiality: The peer and the server each derive the keys on their own, using parameters both of them already know 🙈
- Uniquely named keys: Every key made inside the ERP context can be referred to uniquely, the way this document specifies 🏷️
- Prevent the domino effect: Different sequence numbers for each CAP MUST be used to derive the unique pMSK, so compromising one pMSK can't hurt any other CAP 🛑 No domino drama here 🙅♀️
- Bind key to its context: The pMSKs are bound to the context in which the sequence numbers get sent 📌
- Confidentiality of identity: This is the same as with ERP [RFC5296] 🕵️♀️
- Authorization restriction: Every key derived is limited in lifetime by its parent key or by server policy, whichever applies ⏳ Any domain-specific keys are also restricted so they can only be used in the domain they were derived for. Any other restrictions on session keys may be imposed by the specific lower layer, and those are out of scope for this specification. Not our problem, bestie 💁♀️
9. IANA Considerations 📋
IANA assigned five TLVs from the registry of EAP Initiate and Finish Attributes, which lives at http://www.iana.org/assignments/eap-numbers/. Here are the numbers:
- Sequence number: This is a TV payload, and its Type is 7 🔢
- ERP/AAK-Key: This is a TLV payload, and its Type is 8 🔑
- pRK Lifetime: This is a TLV payload, and its Type is 9 ⏱️
- pMSK Lifetime: This is a TLV payload, and its Type is 10 ⏳
- CAP-Identifier: This is a TLV payload, and its Type is 11 🪪
This document reuses the cryptosuites that were created for "Re-authentication Cryptosuites" in [RFC5296] 🔁
IANA also added a new label to the "User Specific Root Keys (USRK) Key Labels" sub-registry of the "Extended Master Session Key (EMSK) Parameters" registry, and it reads exactly like this:
EAP Early-Authentication Root Key@ietf.org
A brand-new registry for the flags in the EAP Initiate/Re-auth-Start message got created, called the "EAP Initiate/Re-auth-Start Flags" 🚩 It has a new flag, (E), set to 0x80. The other values in this 8-bit field are reserved. New values can be assigned by Standards Action or IESG Approval [RFC5226] ✨
There's also a registry for the flags in the EAP Initiate/Re-auth message, called the "EAP Initiate/Re-auth Flags" 🏳️🌈 The following flags are reserved:
This document assigns a new flag, (E), set to 0x10. The other values in the 8-bit field are reserved. New values can be assigned by Standards Action or IESG Approval.
Finally, this document creates a registry for the flags in the EAP Finish/Re-auth message, called the "EAP Finish/Re-auth Flags" 🎀 The following values get assigned:
This document also assigns the new flag (E), set to 0x10. The other values in the 8-bit field are reserved. New values can be assigned by Standards Action or IESG approval.
10. Acknowledgements 🫶
Yungui Wang contributed to early versions of this document 🌱 We also got reviews from lots of experts in the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang, Semyon Mizikovsky, Stephen Farrell, Radia Perlman, Miguel A. Garcia, and Sujing Zhou. Sorry if we forgot anyone, we love you all 💖
11. References 📚
11.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
- [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [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.
- [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-authentication Protocol (ERP)", RFC 5296, August 2008.
11.2. Informative References
- [KEYTRAN] Zorn, G., Wu, W., and V. Cakulev, "Diameter Attribute-Value Pairs for Cryptographic Key Transport", Work in Progress, August 2011.
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
- [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
- [RFC5836] Ohba, Y., Wu, Q., and G. Zorn, "Extensible Authentication Protocol (EAP) Early Authentication Problem Statement", RFC 5836, April 2010.
- [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
Authors' Addresses 🌸
Zhen Cao China Mobile 53A Xibianmennei Ave., Xuanwu District Beijing, Beijing 100053 P.R. China EMail: zehn.cao@gmail.com
Hui Deng China Mobile 53A Xibianmennei Ave., Xuanwu District Beijing, Beijing 100053 P.R. China EMail: denghui02@gmail.com
Qin Wu Huawei Floor 12, HuiHong Mansion, No. 91 BaiXia Rd. Nanjing, Jiangsu 210001 P.R. China Phone: +86 25 56623633 EMail: sunseawq@huawei.com
Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand Phone: +66 (0) 87-040-4617 EMail: glenzorn@gmail.com
📦 where this page comes from
- ietf: rfc6630 2012-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms