RFC 5433
Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method
RFC 5433 🎀 is titled Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method. It's a Standards Track doc from the Network Working Group 🌸, dated February 2009, written by T. Clancy (LTS) and H. Tschofenig (Nokia Siemens Networks) 👑. The title block doesn't list any RFCs it obsoletes or updates. ✨
Status of This Memo 📋
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋.
Copyright Notice ©️
Copyright (c) 2009 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, as in effect on the date of publication. Read these carefully, because they describe your rights and restrictions for this document 📜. The license info lives at http://trustee.ietf.org/license-info.
Abstract 🌙
This memo defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK) 🔐. It's a lightweight shared-key authentication protocol that supports mutual authentication and key derivation. Very main character energy 👑.
Table of Contents 📑
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................6
4. Key Derivation ..................................................8
5. Key Management .................................................11
6. Ciphersuites ...................................................11
7. Generalized Key Derivation Function (GKDF) .....................12
8. Ciphersuites Processing Rules ..................................13
8.1. Ciphersuite #1 ............................................13
8.1.1. Encryption .........................................13
8.1.2. Integrity ..........................................13
8.2. Ciphersuite #2 ............................................14
8.2.1. Encryption .........................................14
8.2.2. Integrity ..........................................14
9. Packet Formats .................................................15
9.1. Header Format .............................................15
9.2. Ciphersuite Formatting ....................................16
9.3. Payload Formatting ........................................16
9.4. Protected Data ............................................21
10. Packet Processing Rules .......................................24
11. Example Message Exchanges .....................................25
12. Security Considerations .......................................28
12.1. Security Claims ..........................................28
12.2. Mutual Authentication ....................................29
12.3. Protected Result Indications .............................29
12.4. Integrity Protection .....................................29
12.5. Replay Protection ........................................30
12.6. Reflection Attacks .......................................30
12.7. Dictionary Attacks .......................................30
12.8. Key Derivation and Key Strength ..........................31
12.9. Denial-of-Service Resistance .............................31
12.10. Session Independence ....................................32
12.11. Compromise of the PSK ...................................32
12.12. Fragmentation ...........................................32
12.13. Channel Binding .........................................32
12.14. Fast Reconnect ..........................................33
12.15. Identity Protection .....................................33
12.16. Protected Ciphersuite Negotiation .......................33
12.17. Confidentiality .........................................34
12.18. Cryptographic Binding ...................................34
13. IANA Considerations ...........................................34
14. Contributors ..................................................35
15. Acknowledgments ...............................................36
16. References ....................................................37
16.1. Normative References .....................................37
16.2. Informative References ...................................381. Introduction ✨
EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method that defines a generalized pre-shared key authentication technique 🗝️. Mutual authentication happens through a nonce-based exchange that's secured by a pre-shared key 🫶.
EAP-GPSK covers a large number of design goals, because the aim is to be useful across a broad range of usage scenarios 🌈. The main design goals are:
- Simplicity 🧸: EAP-GPSK should be easy to implement.
- Security Model 🛡️: EAP-GPSK is designed for a threat model where the attacker has full control over the communication channel. This EAP threat model is presented in Section 7.1 of [RFC3748]. Honestly, the attacker gets the whole channel and it's still safe, iconic 😭.
- Efficiency ⚡: EAP-GPSK doesn't use public key cryptography and relies fully on symmetric cryptography. Limiting itself to symmetric operations keeps the computational overhead low, so EAP-GPSK is lightweight and a great fit for any type of device, especially ones with processing power, memory, and battery constraints 🔋. It also tries to minimize the number of round trips 🦋.
- Flexibility 🎨: EAP-GPSK offers cryptographic flexibility. At the beginning, the EAP server proposes a list of ciphersuites, and then the client selects one. The current version includes two ciphersuites, but additional ones can be easily added 💅.
- Extensibility 🧩: The design allows the EAP peer and the EAP server to securely exchange information using protected data fields. These fields might be used to exchange channel binding information or to support identity confidentiality 🔒.
2. Terminology 💅
In this document, several words are used to signify the requirements of the specification. They're often capitalized 🔠. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📖.
This section explains the various variables and functions used in the EAP-GPSK method 🧮.
Variables:
CSuite_List: An octet array listing the available ciphersuites (variable length).CSuite_Sel: The ciphersuite selected by the peer (6 octets).ID_Peer: The peer Network Access Identifier (NAI) [RFC4282].ID_Server: The server identity, as an opaque blob.KS: An integer representing the input key size, in octets, of the selected ciphersuiteCSuite_Sel. The key size is one of the ciphersuite parameters.ML: An integer representing the length of the Message Authentication Code (MAC) output, in octets, of the selected ciphersuiteCSuite_Sel.PD_Payload: Data carried within the protected data payload.PD_Payload_Block: A block of possibly multiplePD_Payloads carried by a GPSK packet.PL: An integer representing the length of the PSK in octets (2 octets).PLMUST be larger than or equal toKS. Big rule, don't skip it 🙅♀️.RAND_Peer: A random integer generated by the peer (32 octets).RAND_Server: A random integer generated by the server (32 octets).
Operations:
A || B: Concatenation of octet stringsAandB.A**B: Integer exponentiation.truncate(A,B): Returns the firstBoctets ofA.ENC_X(Y): Encryption of messageYwith a symmetric keyX, using a defined block cipher.KDF-X(Y): A Key Derivation Function that generates an arbitrary number of octets of output, using secretXand seedY.length(X): Returns the length of inputXin octets, encoded as a 2-octet integer in network byte order.MAC_X(Y): A keyed message authentication code computed overYwith symmetric keyX.SEC_X(Y):SECis a function that provides integrity protection based on the chosen ciphersuite. It uses the algorithm defined by the selected ciphersuite and applies it to the message contentYwith keyX. In short,SEC_X(Y) = Y || MAC_X(Y)🔐.X[A..B]: Notation representing octetsAthroughBof the octet arrayX, where the first octet of the array has index zero.
Keying material abbreviations:
EMSK: The Extended Master Session Key, exported by the EAP method (64 octets).MK: A session-specific Master Key between the peer and EAP server, from which all other EAP method session keys are derived (KSoctets).MSK: The Master Session Key, exported by the EAP method (64 octets).PK: A session key generated from theMKand used during the protocol exchange to encrypt protected data (KSoctets).PSK: The long-term key shared between the peer and the server (PLoctets) 🗝️.SK: A session key generated from theMKand used during the protocol exchange to demonstrate knowledge of thePSK(KSoctets).
Part 1 of 8 is done, bestie 🦋 more parts are coming, so stay tuned ✨💖
3. Overview ✨
okay bestie, let's get into how EAP actually flows 🦋 EAP has a framework (see Section 1.3 of [RFC3748]) and there are three basic steps that happen during an EAP conversation between the EAP peer, the Authenticator, and the EAP server 💅
- first up is discovery, which the underlying protocol handles, e.g., IEEE 802.1X as used by IEEE 802.11 [80211] 🌸
- then comes the EAP authentication phase, and EAP-GPSK is what this document defines 💜
- last are the secure association distribution and secure association phases, which get handled differently depending on the underlying protocol ✨
so EAP-GPSK gives you mutual authentication between the EAP peer ("Peer") and the EAP server ("Server") using a pre-shared key (PSK) 🔥 the whole thing is a set of message exchanges (GPSK-1, ..., GPSK-4) where both sides swap nonces and their identities, then compute and swap a Message Authentication Code (MAC) over the stuff they already exchanged, keyed with the PSK. that MAC counts as proof of possession of the PSK 🫶 there are also two extra messages, GPSK-Fail and GPSK-Protected-Fail, for when things go sideways 💀
here's a successful exchange in Figure 1 🎀
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-3 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-4 | |
| |------------------------------------>| |
| | | |
| | EAP-Success | |
| |<------------------------------------| |
+--------+ +--------+
Figure 1: EAP-GPSK: Successful Exchangethe full EAP-GPSK protocol looks like this 🧚
GPSK-1:
ID_Server, RAND_Server, CSuite_ListGPSK-2:
SEC_SK(ID_Peer, ID_Server, RAND_Peer, RAND_Server, CSuite_List,
CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] )GPSK-3:
SEC_SK(RAND_Peer, RAND_Server, ID_Server, CSuite_Sel, [
ENC_PK(PD_Payload_Block) ] )GPSK-4:
SEC_SK( [ ENC_PK(PD_Payload_Block) ] )the EAP server kicks things off by picking a random number RAND_Server and encoding the supported ciphersuites into CSuite_List 🌈 a ciphersuite is made of an encryption algorithm, a key derivation function, and a message authentication code 🍓
in GPSK-1, the EAP server sends its identity ID_Server, a random number RAND_Server, and its list of supported ciphersuites, CSuite_List 💖 which ciphersuite to offer and which one to pick is policy- and implementation-dependent, so it's totally outside the scope of this document 🙈
in GPSK-2, the peer sends its identity ID_Peer and a random number RAND_Peer ✨ it also repeats the GPSK-1 parameters it got (ID_Server, RAND_Server, CSuite_List) plus the ciphersuite it selected, and then computes a Message Authentication Code over all the transmitted parameters 🫶
the EAP server checks the MAC it received, plus the consistency of the identities, nonces, and ciphersuite parameters sent in GPSK-1 👑 if that checks out, the EAP server computes a MAC over the session parameter and sends it back to the peer inside GPSK-3 🔥 during GPSK-2 and GPSK-3, the EAP peer and EAP server can also exchange encrypted protected data parameters, which is iconic 💅
the peer checks the MAC it received, plus the consistency of identities, nonces, and ciphersuite parameters sent in GPSK-2 💜 if that verification works, GPSK-4 gets prepared, and this message can optionally carry the peer's protected data parameters ✨
once GPSK-4 arrives, the server processes any included PD_Payload_Block 🦋 then the EAP server sends an EAP Success message to say the authentication worked 🎀
4. Key Derivation
okay this part is about the keys 🔑 EAP-GPSK does key derivation in line with the requirements of [RFC3748] and [RFC5247] ✨ heads up, this section is an abstract description of the key derivation procedure, and it has to get instantiated with a specific ciphersuite 🌸
the long-term credential shared between the EAP peer and EAP server SHOULD be a strong pre-shared key PSK of at least 16 octets 💖 its length and entropy can vary. you can use a password or passphrase, but doing that is NOT RECOMMENDED, because EAP-GPSK is vulnerable to dictionary attacks 💀 not the move, bestie 🙅♀️
during an EAP-GPSK authentication, three keys get derived using the ciphersuite-specified KDF and the data exchanged during the protocol: a Master Key MK, a Session Key SK, and a Protected Data Encryption Key PK (only if you're using an encrypting ciphersuite) 🧚 the input is 'RAND_Peer || ID_Peer || RAND_Server || ID_Server', which we call inputString for short 🌈
when the exchange completes successfully, EAP-GPSK derives and exports an MSK and an EMSK, and each of them is 64 octets long 💜
the notation goes like this: KDF-X(Y, Z)[A..B], where
Xis the length, in octets, of the desired output,Yis a secret key,Zis the inputString,[A..B]pulls out the string of octets starting with octet A and finishing with octet B from the output of the KDF function.
the keying material is derived with the ciphersuite-specified KDF like so 🫶
- inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server
- MK = KDF-KS(PSK[0..KS-1], PL || PSK || CSuite_Sel || inputString)[0..KS-1]
- MSK = KDF-{128+2*KS}(MK, inputString)[0..63]
- EMSK = KDF-{128+2*KS}(MK, inputString)[64..127]
- SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS]
- PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using an encrypting ciphersuite)
the value for PL (the length of the PSK in octets) gets encoded as a 2-octet integer in network byte order ✨ and remember, KS is the length of the ciphersuite input key size in octets 🍓
also, the EAP keying framework [RFC5247] needs a Method-ID, Session-ID, Peer-ID, and Server-ID defined 🦋 so here they are 👑
- Method-ID = KDF-16(PSK[0..KS-1], "Method ID" || EAP_Method_Type || CSuite_Sel || inputString)[0..15]
- Session-ID = EAP_Method_Type || Method_ID
- Peer-ID = ID_Peer
- Server-ID = ID_Server
EAP_Method_Type is the 1-octet, IANA-allocated EAP Type code value 🌸
Figure 2 shows the EAP-GPSK key derivation procedure 🎀
+-------------+ +-------------------------------+
| PL-octet | | RAND_Peer || ID_Peer || |
| PSK | | RAND_Server || ID_Server |
+-------------+ +-------------------------------+
| | |
| +------------+ | |
| | CSuite_Sel | | |
| +------------+ | |
| | | |
v v v |
+--------------------------------------------+ |
| KDF | |
+--------------------------------------------+ |
| |
v |
+-------------+ |
| KS-octet | |
| MK | |
+-------------+ |
| |
v v
+---------------------------------------------------+
| KDF |
+---------------------------------------------------+
| | | |
v v v v
+---------+ +---------+ +----------+ +----------+
| 64-octet| | 64-octet| | KS-octet | | KS-octet |
| MSK | | EMSK | | SK | | PK |
+---------+ +---------+ +----------+ +----------+
Figure 2: EAP-GPSK Key Derivation5. Key Management
okay, key management time 🗝️ PSKs have to be entered the same way on both the peer and the server, or interop is gonna be a mess 💅 the management interface for entering PSKs MUST support entering PSKs up to 64 octets in length as ASCII strings and in hexadecimal encoding 🌈
ALSO 🫶 the ID_Peer and ID_Server MUST be provisioned with the PSK, and they get validated with an octet-wise comparison ✨ the management interface SHOULD support entering non-ASCII octets for the ID_Peer and ID_Server, up to 254 octets in length 🦋 for more info, go read Section 2.4 of RFC 4282 [RFC4282] 💜
6. Ciphersuites ✨
Okay so EAP-GPSK lets both sides negotiate their cryptographic algorithms and key sizes during the protocol run, and those combos are called ciphersuites 💅. It's giving flexible. You can use block-based or hash-based ciphersuites, and it's extensible, so new ciphersuites can be added later. This document only specifies an initial set 🦋. The CSuite/Specifier column in Figure 3 is what uniquely identifies each ciphersuite 🔥.
For a vendor-specific ciphersuite, the first four octets are the vendor-specific enterprise number. That's the IANA-assigned "SMI Network Management Private Enterprise Codes" value (see [ENTNUM]), encoded in network byte order 🎀. The last two octets are assigned by the vendor for that specific ciphersuite. A vendor code of 0x00000000 means the ciphersuite was standardized by the IETF and lives in an IANA-maintained registry 🌸.
Here are the ciphersuites specified in this document. Quick reminder that KS is the length of the ciphersuite input key length in octets, and ML is the length of the MAC output in octets ✨
+-----------+----+-------------+----+--------------+----------------+
| CSuite/ | KS | Encryption | ML | Integrity / | Key Derivation |
| Specifier | | | | KDF MAC | Function |
+-----------+----+-------------+----+--------------+----------------+
| 0x0001 | 16 | AES-CBC-128 | 16 | AES-CMAC-128 | GKDF |
+-----------+----+-------------+----+--------------+----------------+
| 0x0002 | 32 | NULL | 32 | HMAC-SHA256 | GKDF |
+-----------+----+-------------+----+--------------+----------------+Figure 3: Ciphersuites
Ciphersuite 1 is built on the Advanced Encryption Standard (AES) as its cryptographic primitive, and it MUST be implemented 🫶. This document also specifies a second ciphersuite, which MAY be implemented 💖. Both ciphersuites make use of the Generalized Key Derivation Function (GKDF), as defined in Section 7. To make sure the PSK going into the GKDF is long enough, keep these in mind 👑:
- The PSK used with ciphersuite 1 MUST be 128 bits in length. Keys longer than 128 bits will be truncated.
- The PSK used with ciphersuite 2 MUST be 256 bits in length. Keys longer than 256 bits will be truncated.
- It is RECOMMENDED that 256 bit keys be provisioned in all cases to provide enough entropy for all current and many possible future ciphersuites ⭐.
Ciphersuites defined in the future that make use of the GKDF need to specify a minimum PSK size, just like the ciphersuites listed in this document do 🧚.
7. Generalized Key Derivation Function (GKDF) 🧚
Every ciphersuite needs to specify a key derivation function 🌈. The ciphersuites in this document use the Generalized Key Derivation Function (GKDF), which runs on the MAC function defined in the ciphersuite. Future ciphersuites can use any other formally specified KDF that takes a key and a seed value as arguments and produces at least 128+2*KS octets of output 💜.
GKDF has the following structure:
GKDF-X(Y, Z)
X length, in octets, of the desired output
Y secret key
Z inputStringGKDF-X (Y, Z)
{
n = ceiling integer of ( X / ML );
/* determine number of output blocks */
result = "";
for i = 1 to n {
result = result || MAC_Y (i || Z);
}
return truncate(result, X)
}Note that the variable 'i' in M_i is represented as a 2-octet value in network byte order 🍓.
8. Ciphersuites Processing Rules 💅
8.1. Ciphersuite #1
8.1.1. Encryption
Okay, so with this ciphersuite, all the cryptography is built around one cryptographic primitive, AES-128 ([AES]) 🔥. Inside the protected data frames, AES-128 runs in the Cipher Block Chaining (CBC) mode of operation (see [CBC]). This EAP method uses encryption in a single payload, which is the protected data payload (see Section 9.4) 🦋.
In a nutshell, CBC mode goes like this 🎀. The IV gets XORed with the first plaintext block before that block is encrypted. Then, for each successive block, the previous ciphertext block is XORed with the current plaintext before it gets encrypted ✨.
8.1.2. Integrity
Ciphersuite 1 uses CMAC as its Message Authentication Code. CMAC is recommended by NIST, and iconically, it can work with messages of arbitrary length 💖. You can find a detailed description of CMAC in [CMAC] 📚.
The following instantiation is used. AES-CMAC-128(SK, Input) denotes the MAC of Input under the key SK, where Input refers to the following content 🫶:
- Parameter within SEC_SK(Parameter) in message GPSK-2
- Parameter within SEC_SK(Parameter) in message GPSK-3
- Parameter within SEC_SK(Parameter) in message GPSK-4
8.2. Ciphersuite #2
8.2.1. Encryption
Ciphersuite 2 does not include an algorithm for encryption 🙈. With a NULL encryption algorithm, encryption is defined as:
E_X(Y) = YWhen you use this ciphersuite, the data exchanged inside the protected data block is not encrypted. So this mode MUST NOT be used if confidential information appears inside the protected data block 💀.
8.2.2. Integrity
Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash algorithm (see [RFC4634]) 🌸.
For integrity protection, the following instantiation is used. HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK, where Input refers to the following content 🎀:
- Parameter within SEC_SK(Parameter) in message GPSK-2
- Parameter within SEC_SK(Parameter) in message GPSK-3
- Parameter within SEC_SK(Parameter) in message GPSK-4
9. Packet Formats 🦋
This section defines the packet format of the EAP-GPSK messages 🧚.
9.1. Header Format
The EAP-GPSK header has the following structure ✨:
--- bit offset --->
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 | OP-Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: EAP-GPSK Header
The Code, Identifier, Length, and Type fields are all part of the EAP header and are defined in [RFC3748] 📖. The Type field in the EAP header MUST be the value allocated by IANA for EAP-GPSK 🫶.
The OP-Code field is one of 6 values 💅:
0x00 : Reserved0x01 : GPSK-10x02 : GPSK-20x03 : GPSK-30x04 : GPSK-40x05 : GPSK-Fail0x06 : GPSK-Protected-Fail
All other values of this OP-Code field are available via IANA registration 🌈.
9.2. Ciphersuite Formatting
Ciphersuites are encoded as 6-octet arrays 🍓. The first four octets indicate the CSuite/Vendor field. For vendor-specific ciphersuites, this represents the vendor enterprise number, which is the IANA-assigned "SMI Network Management Private Enterprise Codes" value (see [ENTNUM]), encoded in network byte order. The last two octets indicate the CSuite/Specifier field, which identifies the particular ciphersuite. The 4-octet CSuite/Vendor value 0x00000000 indicates ciphersuites allocated by the IETF 💜.
Graphically, they look like this ✨:
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite/Vendor = 0x00000000 or enterprise number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite/Specifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: Ciphersuite Formatting
CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and CSuite/Specifier pair 🎀.
CSuite_List is a variable-length octet array of ciphersuites. It is encoded by concatenating encoded ciphersuite values. Its length in octets MUST be a multiple of 6 🦋.
9.3. Payload Formatting ✨
okay so payload formatting is literally built on the protocol exchange we already went over in Section 3 🎀 if you remember the exchange, this part is just the outfit each message wears 💅
Here's the GPSK-1 payload layout 🦋
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Server) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(CSuite_List) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... CSuite_List ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: GPSK-1 Payload 🌸
Now the GPSK-2 payload, which is a bigger look 👑
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Peer) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Peer ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Server) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Peer ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(CSuite_List) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... CSuite_List ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite_Sel |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | length(PD_Payload_Block) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload_Block ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: GPSK-2 Payload 🦋
If the optional protected data payload isn't included, then length(PD_Payload_Block)=0 and the PD payload is excluded 🙈 The payload MAC covers the entire packet, from the ID_Peer length through the optional PD_Payload_Block. so it's the whole thing, start to finish 💖
Next up is the GPSK-3 payload ✨
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Peer ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... 32-octet RAND_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Server) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite_Sel |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | length(PD_Payload_Block) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload_Block ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: GPSK-3 Payload 🧚
Same deal with the optional protected data payload: if it isn't included, then length(PD_Payload_Block)=0 and the PD payload is excluded 💅 This time the payload MAC covers the entire packet, from the RAND_Peer through the optional PD_Payload_Block.
Now the GPSK-4 payload, which is the smallest of the bunch 🌈
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(PD_Payload_Block) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... optional PD_Payload_Block ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: GPSK-4 Payload 🍓
If the optional protected data payload isn't included, then length(PD_Payload_Block)=0 and the PD payload is excluded. Here's the part that's non-negotiable 🚨 The MAC MUST always be included, regardless of the presence of PD_Payload_Block. The payload MAC covers the entire packet, from the PD_Payload_Block length through the optional PD_Payload_Block.
the MAC is a MUST, bestie. even when there's no PD payload at all, it's still getting shipped 💀
Okay, now the GPSK-Fail payload, which is tiny and to the point 🥀
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: GPSK-Fail Payload 💜
And the GPSK-Protected-Fail payload, which is the same energy but with a MAC attached 🔐
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ML-octet payload MAC ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: GPSK-Protected-Fail Payload ✨
The Failure-Code field is one of three values, but it can be extended 🌸 Here's the lineup:
0x00000000 : Reserved0x00000001 : PSK Not Found0x00000002 : Authentication Failure0x00000003 : Authorization Failure
All other values of this field are available via IANA registration 🧾 so if you want a new code, you go through the registry, no freelancing 🙅♀️
Here's what the three main ones mean, iykyk 👑
"PSK Not Found" means a key for a particular user couldn't be located, so authentication is impossible 😭 "Authentication Failure" means there's a MAC failure because of a PSK mismatch 💔 And "Authorization Failure" means the PSK being used is correct, but the user just isn't authorized to connect. the key is valid, the person is simply not on the list 💅
9.4. Protected Data 🎀
okay so the protected data blocks are the generic way the peer and server can securely swap data with each other 🔐 if the ciphersuite has a NULL encryption primitive, then this channel only gives you authenticity, not confidentiality. so nobody can tamper with it, but people can still read it 👀
these payloads are built by concatenating type-length-value (TLV) triples called PD_Payloads ✨
Type values are encoded as a 6-octet string 💅 it's split into a 4-octet vendor field and a 2-octet specifier field. the vendor field tells you whether the type is standards-specified or vendor-specific 🦋
if those four octets are 0x00000000, the value is standards-specified. any other value is a vendor-specific enterprise number 🌸
the specifier field tells you the actual type. for vendor field 0x00000000, IANA maintains the specifier field. for any other vendor field, the vendor maintains it 💜
Length fields are 2-octet integers in network byte order. they only reflect the length of the value and do NOT include the length of the type and length fields 🙈
here's the picture:
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PData/Vendor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PData/Specifier | PData/Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... PData/Value ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Protected Data Payload (PD_Payload) Formattingthese PD_Payloads get concatenated together to form a PD_Payload_Block 🧚 if the CSuite_Sel includes support for encryption, then the PD_Payload_Block also has fields for an Initialization Vector (IV) and the padding it needs. it looks like this:
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV Length | |
+-+-+-+-+-+-+-+-+ Initialization Vector +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... PD_Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload, etc ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Protected Data Block (PD_Payload_Block)
Formatting if Encryption is Supportedthe Initialization Vector is a randomly chosen value, and its length matches the specified IV Length 🌈 the ciphersuite defines the required length. Recipients MUST accept any value. Senders SHOULD either pick this value pseudo-randomly and independently for each message, or use the final ciphertext block of the previous message sent. Senders MUST NOT use the same value for each message, use a sequence of values with low hamming distance (e.g., a sequence number), or use ciphertext from a received message. IVs should be selected per the security requirements of the underlying cipher. If the data is not being encrypted, then the IV Length MUST be 0. If the ciphersuite does not require an IV, or has a self-contained way of communicating the IV, then the IV Length field MUST be 0. In these cases, the ciphersuite definition defines how the IV is encapsulated in the PD_Payload. 😭
the concatenated PD_Payloads, along with the padding and padding length, are all encrypted using the negotiated block cipher. if no block cipher is specified, then those fields are not encrypted 🔥
The Padding field MAY contain any value chosen by the sender. For block-based cipher modes, the padding MUST have a length that makes the combination of the concatenated PD_Payloads, the Padding, and the Pad Length a multiple of the encryption block size. If the underlying ciphersuite does not require padding (e.g., a stream-based cipher mode) or no encryption is being used, then the padding length MUST still be present and be 0. 💅
The Pad Length field is the length of the Padding field. The sender SHOULD set the Pad Length to the minimum value that makes the combination of the PD_Payloads, the Padding, and the Pad Length a multiple of the block size (in the case of block-based cipher modes), but the recipient MUST accept any length that results in proper alignment. This field is encrypted with the negotiated cipher. ✨
If the negotiated ciphersuite does not support encryption, then the IV field MUST be of length 0 and the padding field MUST be of length 0. The IV length and padding length fields MUST still be present, and contain the value 0. The reason they still need the length fields is so implementations can be modular, with the crypto processing staying independent of the payload processing. Here's how that looks:
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | |
+-+-+-+-+-+-+-+-+ PD_Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload, etc +-+-+-+-+-+-+-+-+
| | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Protected Data Block (PD_Payload_Block)
Formatting Without EncryptionFor PData/Vendor field 0x00000000, these PData/Specifier fields are defined:
0x0000: Reserved
All other values of this field are available via IANA registration. 🦋
10. Packet Processing Rules ✨
okay this section is the bouncer 💅 it defines how the EAP peer and EAP server MUST behave when a received packet is deemed invalid 🚫
Any EAP-GPSK packet that cannot be parsed by the EAP peer or the EAP server MUST be silently discarded. An EAP peer or EAP server that receives any unexpected packet (e.g., an EAP peer receiving GPSK-3 before receiving GPSK-1 or before transmitting GPSK-2) MUST silently discard the packet. 🙈
GPSK-1 has no MAC protection, so as long as it parses properly, the peer MUST accept it. If the EAP peer has no ciphersuites in common with the server, or decides the ID_Server belongs to an Authentication, Authorization, and Accounting (AAA) server it doesn't want to authenticate to, the EAP peer MUST respond with an EAP-NAK. 🌸
For GPSK-2, if the ID_Peer is for an unknown user, the EAP server MUST send either a "PSK Not Found" GPSK-Fail message or an "Authentication Failure" GPSK-Fail, depending on its policy. If the MAC validation fails, the server MUST transmit a GPSK-Fail message specifying "Authentication Failure". If the RAND_Server or CSuite_List field in GPSK-2 does not match the values in GPSK-1, the server MUST silently discard the packet. If server policy determines the peer is not authorized and the MAC is correct, the server MUST transmit a GPSK-Protected-Fail message indicating "Authorization Failure", and discard the received packet. 💀
A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in response to a GPSK-2 message MUST replay the received GPSK-Fail / GPSK-Protected-Fail message. Then, the EAP server returns an EAP-Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message to correctly finish the EAP conversation. If MAC validation on a GPSK-Protected-Fail packet fails, then the received packet MUST be silently discarded. 🔥
For GPSK-3, a peer MUST silently discard messages where the RAND_Peer, ID_Server, or the CSuite_Sel fields do not match those transmitted in GPSK-2. An EAP peer MUST silently discard any packet whose MAC fails. 👑
For GPSK-4, a server MUST silently discard any packet whose MAC fails validation. 🫶
If a decryption failure of a protected payload is detected, the recipient MUST silently discard the GPSK packet. 💜
11. Example Message Exchanges 🎬
okay so this section is giving little show-and-tell 🎀 it walks through a couple of example message flows, and the diagrams are literally the best part ✨
A successful EAP-GPSK message exchange is shown in Figure 1.
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/EAP-NAK | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 15: EAP-GPSK: Unsuccessful Exchange
(Unacceptable AAA Server Identity; ID_Server) +--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-Fail | |
| | (PSK Not Found or Authentication | |
| | Failure) | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-Fail | |
| | (PSK Not Found or Authentication | |
| | Failure) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 16: EAP-GPSK: Unsuccessful Exchange (Unknown User) +--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-Fail | |
| | (Authentication Failure) | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-Fail | |
| | (Authentication Failure) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 17: EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2) +--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/ | |
| | GPSK-Protected-Fail | |
| | (Authorization Failure) | |
| |<------------------------------------| |
| | | |
| | EAP-Request/ | |
| | GPSK-Protected-Fail | |
| | (Authorization Failure) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
Figure 18: EAP-GPSK: Unsuccessful Exchange (Authorization Failure)12. Security Considerations 🔐
okay this is the serious part, bestie, so no skipping 😭 [RFC3748] literally calls out a bunch of attacks that can hit EAP, and that's because EAP on its own doesn't give you any security at all 💀
this section covers the security properties EAP-GPSK claims to have, plus the vulnerabilities and security recommendations that come up in the threat model of [RFC3748] 🛡️
12.1. Security Claims
here's the whole vibe check in one table 📋
Authentication mechanism: Shared Keys
Ciphersuite negotiation: Yes (Section 12.16)
Mutual authentication: Yes (Section 12.2)
Integrity protection: Yes (Section 12.4)
Replay protection: Yes (Section 12.5)
Confidentiality: No (Section 12.17, Section 12.15)
Key derivation: Yes (Section 12.8)
Key strength: Varies (Section 12.8)
Dictionary attack protection: No (Section 12.7)
Fast reconnect: No (Section 12.14)
Cryptographic binding: N/A (Section 12.18)
Session independence: Yes (Section 12.10)
Fragmentation: No (Section 12.12)
Channel binding: Extensible (Section 12.13)12.2. Mutual Authentication 🤝
EAP-GPSK gives you mutual authentication, so both sides get to be sure about each other 🫶
the server thinks the peer is legit once it successfully verifies the MAC in the GPSK-2 message, and the peer thinks the server is legit once it successfully verifies the MAC it gets with the GPSK-3 message ✨
the key used for mutual authentication is derived from the long-term secret PSK, nonces from both parties, and some other parameters 🔑 the long-term secret PSK has to bring sufficient entropy, and therefore sufficient strength 💪 the nonces (RAND_Peer and RAND_Server) need to be fresh and unique for every session 🌸 so honestly, EAP-GPSK is giving the same energy as other authentication protocols based on pre-shared keys 💅
12.3. Protected Result Indications 📣
EAP-GPSK supports protected result indications through the GPSK-Protected-Fail message 📨 this lets a server tell the peer why a session failed, and to do it in an authenticated way (if that's possible) 🔐 specifically, the server can point out a missing PSK (account not present), failed authentication (PSK incorrect), or an authorization failure (account disabled or unauthorized) 🙈 only the third message could be integrity protected, fyi.
ngl this is where it gets tricky 😬 these options make debugging network and account errors way easier, but they also leak info about accounts to attackers. an attacker can figure out whether a particular ID_Peer is a valid user on the network or not 💀 so implementers should be careful about turning this option on for their servers. if they're in an environment where these attacks are a concern, protected result indication capabilities should be disabled 🚫
12.4. Integrity Protection 🧱
EAP-GPSK provides integrity protection based on the ciphersuites suggested in this document ✅ integrity protection is a minimum feature that every ciphersuite must provide, so it's non-negotiable 💖
12.5. Replay Protection 🔁
EAP-GPSK provides replay protection for its mutual authentication part, thanks to the random numbers RAND_Server and RAND_Peer 🎲 since RAND_Server is 32 octets long, you'd expect to have to record 264 (i.e., approximately 1.84*1019) EAP-GPSK successful authentications before a protocol run can be replayed 🤯 so replay protection holds as long as RAND_Server and RAND_Peer are chosen at random. randomness is critical here, periodt 🫠 [RFC4086] describes techniques for producing random quantities, so go read that one 📚
12.6. Reflection Attacks 🪞
reflection attacks happen in bi-directional, challenge-response, mutual authentication protocols. the attacker gets issued a challenge by an authenticator, responds by sending the same challenge back to the authenticator, gets the response, and then "reflects" that same response back to the original challenge 😳
EAP-GPSK is protected against reflection attacks because the message formats for the challenges are different 🙌 the protocol isn't two independent authentications, the authentications are tightly coupled 🧶
also, EAP-GPSK doesn't give MAC protection for the OP-Code field 👀 but again, since each message is built differently, you couldn't change the OP-Code of a valid message and still have the recipient parse and accept it 🚫
12.7. Dictionary Attacks 📖
EAP-GPSK relies on a long-term shared secret (PSK) that SHOULD be based on at least 16 octets of entropy to be fully secure 🔑 the EAP-GPSK protocol makes no special provisions to make sure keys based on passwords are used securely, so users who base their PSK on passwords are not protected against dictionary attacks 💀 deriving the long-term shared secret from a password is strongly discouraged, no cap 🙅♀️
the success of a dictionary attack against EAP-GPSK depends on how strong the long-term shared secret (PSK) is. the PSK used by EAP-GPSK SHOULD be drawn from a pool of secrets that is at least 2^128 bits large and whose distribution is uniformly random 🎰 but note that this does NOT mean it's resistant to dictionary attacks. it just means the probability of success in such an attack is acceptably remote 🌙
12.8. Key Derivation and Key Strength 🗝️
EAP-GPSK supports key derivation as shown in Section 4 ✨
every key used within EAP-GPSK is based on the security of the PSK it came from. PSKs SHOULD have at least 16 octets of entropy 🌟 and even without knowing RAND_Peer and RAND_Server, the keys are derived with enough input entropy to be as secure as the underlying KDF output key length. that's the iconic part, fr fr 👑
12.9. Denial-of-Service Resistance 🛡️
okay so there are three kinds of denial-of-service (DoS) attacks that matter for this doc 😭:
- attacks that make a server allocate a ginormous amount of state 💀
- attacks that try to stop the peer and server from talking to each other 🙅♀️
- attacks that go after computational resources 🔥
so in an EAP-GPSK conversation, the server has to keep state around, namely the 32-octet RAND_Server, when it sends the GPSK-1 message to the peer. which means an adversary could just flood a server with a huge pile of EAP-GPSK attempts 😩. the fix is that an EAP server can make sure any established state times out after a fairly short time when no more messages show up. it's basically garbage collection, and it's giving tidy house energy ✨🧹
clients have to hold onto some state too, after they get the GPSK-1 message. to stop a replay attack, the client only needs to make sure RAND_Peer stays consistent between GPSK-2 and GPSK-3. and GPSK-3 has all the stuff needed to recompute the keying material, so if a client wants to add this client-side DoS protection, it can manage RAND_Peer and CSuite_Sel per server it knows, instead of per message 🦋
attacks that mess with communication between the peer and server get handled by silently discarding messages with invalid MACs 🤫. attacks on computational resources get handled by having super light-weight cryptographic operations in each protocol round 🌸
and the security considerations of EAP itself, see Sections 5.2 and 7 of RFC 3748 [RFC3748], also apply to this spec (like, for example, the stuff about EAP-based notifications) 📬
12.10. Session Independence 💜
thanks to its key derivation mechanisms, EAP-GPSK gives you session independence ✨. passive attacks (like capturing the EAP conversation) or active attacks (including compromise of the MSK or EMSK) do NOT let anyone break subsequent or prior MSKs or EMSKs 🙌. the assumption that RAND_Peer and RAND_Server are random is central to the security of EAP-GPSK in general, and to session independence in particular 🎲
12.11. Compromise of the PSK 💔
EAP-GPSK does not give you perfect forward secrecy 😬. if the PSK gets compromised, recorded past sessions get compromised too.
compromising the PSK lets an attacker impersonate both the peer and the server, and it lets the adversary compromise future sessions as well 👀
EAP-GPSK offers no protection against a legit peer sharing its PSK with a third party 🙃. that kind of protection could come from appropriate repositories for the PSK, but picking those is outside the scope of this doc. the PSK used by EAP-GPSK must only be shared between two parties: the peer and the server. in particular, this PSK must not be shared by a group of peers (e.g., those with different ID_Peer values) talking to the same server 🚫
the PSK used by EAP-GPSK must be cryptographically separated from keys used by other protocols, otherwise the security of EAP-GPSK may be compromised 🔐
12.12. Fragmentation 🧩
EAP-GPSK does not support fragmentation and reassembly, since the message size is relatively small 🐣. however, it's worth noting that this affects how long the protected data payloads attached to messages can be. also, if the EAP frame is bigger than the MTU of the underlying transport, and that transport doesn't support fragmentation, the frame will most likely not get transported 😭. so implementers and deployers should take care to make sure EAP-GPSK frames are short enough to work properly on the target underlying transport mechanism 💅
12.13. Channel Binding 🔗
this doc enables the ability to exchange channel binding information 🙌. it does NOT, however, define how channel binding information gets encoded here 🤷♀️
12.14. Fast Reconnect ⚡
EAP-GPSK does not provide fast reconnect capability, since this method is already at (or close to) the lower limit of roundtrips and cryptographic operations 🏃♀️💨
12.15. Identity Protection 🕵️♀️
identity protection is not specified in this doc. extensions can be defined to enhance this protocol and add that feature 🧚
12.16. Protected Ciphersuite Negotiation 🎀
EAP-GPSK gives you protected ciphersuite negotiation: the server indicates which ciphersuites are available in the first message, and then the peer confirms its choice in the next message 💖
but here's the tea ☕. the GPSK-2 message may optionally contain a payload, ENC_PK(PD_Payload_Block), protected with an algorithm based on a selected ciphersuite, before the ciphersuite list has actually been authenticated 😳. in the classic downgrading attack, an adversary would pick a ciphersuite so weak it can be broken in real time, or would try to disable cryptographic protection altogether. the latter isn't possible, since any ciphersuite defined for EAP-GPSK must at least provide authentication and integrity protection. confidentiality protection is optional 🫣.
when, at some point in the future, a ciphersuite contains algorithms that can be broken in real time, a policy on peers and the server needs to indicate that such a ciphersuite must not be selected by any of the parties 🚨
there's also the sneaky move where an adversary modifies the ciphersuite selection so the client picks one that doesn't provide confidentiality protection. that would make the content of PD_Payload_Block go out in cleartext 😱. when protocol designers extend EAP-GPSK to carry info in the PD_Payload_Block of the GPSK-2 message, they must indicate whether confidentiality protection is mandatory. if an extension requires a ciphersuite with confidentiality protection, then the policy at the peer must be to NOT transmit that extension's info in the PD_Payload_Block of the GPSK-2 message. the peer may, if possible, delay sending that info element until the GPSK-4 message, where the ciphersuite negotiation has already been confirmed 🌈. in general, when a ciphersuite is selected that doesn't provide confidentiality protection, then info that demands confidentiality protection must not be included in any of the PD_Payload_Block objects 🙅♀️
12.17. Confidentiality 🤐
even though EAP-GPSK provides confidentiality in its protected data payloads, it can't claim to do so, per Section 7.2.1 of [RFC3748], since it doesn't support identity protection 🥲
12.18. Cryptographic Binding 🔒
since EAP-GPSK doesn't tunnel another EAP method, it doesn't implement cryptographic binding 🙆♀️
13. IANA Considerations 📋
IANA has allocated a new EAP Type for EAP-GPSK (51) 🎉
IANA has created a new registry for ciphersuites, protected data types, failure codes, and op-codes 🗂️. IANA has added the specified ciphersuites, protected data types, failure codes, and op-codes to these registries as defined below. values defining ciphersuites (block-based or hash-based), protected data payloads, failure codes, and op-codes can be added or modified per IETF Review [RFC5226] 🔍
Figure 3 represents the initial contents of the "EAP-GPSK Ciphersuites" registry. the CSuite/Specifier field is 16 bits long. all other values are available via IANA registration. each ciphersuite needs to provide processing rules and needs to specify how the following algorithms are instantiated: encryption, integrity, key derivation, and key length 🧁
the initial contents of the "EAP-GPSK Protected Data Payloads" registry are:
0x0000 : Reserved
the PData/Specifier field is 16 bits long, and all other values are available via IANA registration. each extension needs to indicate whether confidentiality protection for transmission between the EAP peer and the EAP server is mandatory 🔐
the initial contents of the "EAP-GPSK Failure Codes" registry are:
0x00000000 : Reserved0x00000001 : PSK Not Found0x00000002 : Authentication Failure0x00000003 : Authorization Failure
the Failure-Code field is 32 bits long, and all other values are available via IANA registration 🙃
the initial contents of the "EAP-GPSK OP Codes" registry are:
0x00 : Reserved0x01 : GPSK-10x02 : GPSK-20x03 : GPSK-30x04 : GPSK-40x05 : GPSK-Fail0x06 : GPSK-Protected-Fail
the OP-Code field is 8 bits long, and all other values are available via IANA registration 💜
14. Contributors 🫶
this work is a joint effort of the EAP Method Update (EMU) design team of the EMU Working Group, which was created to develop a mechanism based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC 4017 [RFC4017] requirements 🌟. the design team members (in alphabetical order) were:
- Jari Arkko
- Mohamad Badra
- Uri Blumenthal
- Charles Clancy
- Lakshminath Dondeti
- David McGrew
- Joe Salowey
- Sharma Suman
- Hannes Tschofenig
- Jesse Walker
and finally, a big thank-you to Thomas Otto for his reviews, feedback, and text contributions 🥰
15. Acknowledgments 💐
we would like to thank:
- Jouni Malinen and Bernard Aboba for their early comments on the document in June 2006. Jouni Malinen developed the first prototype implementation 👩💻
- Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela Vanderveen, and Ray Bell for their input to the ciphersuite discussions between July and August 2006 🙏
- Lakshminath Dondeti for his detailed review (sent to the EMU mailing list on 12 July 2006) 📨
- Based on a review requested from NIST, Quynh Dang suggested changes to the GKDF function (December 2006) 🔢
- Jouni Malinen and Victor Fajardo for their review in January 2007 ✅
- Jouni Malinen for his suggestions regarding the examples and the key derivation function in February 2007 🧠
- Bernard Aboba and Jouni Malinen for their review in February 2007 👏
- Vidya Narayanan for her review in March 2007 🌷
- Pasi Eronen for his IESG review in March and July 2008 🕊️
- Dan Harkins for his review in June 2008 🍓
- Joe Salowey, the EMU working group chair, provided a document review in April 2007. Jouni Malinen also reviewed the document during the same month 🦋
- We would like to thank Paul Rowe, Arnab Roy, Prof. Andre Scedrov, and Prof. John C. Mitchell for their analysis of EAP-GPSK, for their input to the key derivation function, and for pointing us to a client-side DoS attack and to a downgrading attack. Based on their input, the key derivation function has been modified and the text in the security considerations section has been updated 🔥👑
- Finally, we would like to thank our working group chair, Joe Salowey, for his support and for the time he spent discussing open issues with us 💖
16. References 📚
16. References ✨
16.1. Normative References 💅
okay so this is the list of stuff the spec literally can't work without, bestie 📚
- [AES] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", Federal Information Processing Standards (FIPS) 197, November 2001. 🔐
- [CBC] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Encryption -- Methods and Techniques", Special Publication (SP) 800-38A, December 2001. 🎀
- [CMAC] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", Special Publication (SP) 800-38B, May 2005. 🦋
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 👑
- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 🌸
- [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. 🧚
- [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. 🔥
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 🍓
- [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008. 💜
16.2. Informative References 🌈
these ones are the extra reading, not required to implement, but honestly so worth a peek 🫶
- [80211] "Information technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11-2007, March 2007. 📡
- [ENTNUM] IANA, "SMI Network Management Private Enterprise Codes", Private Enterprise Numbers,
<http://www.iana.org>. 🌐 - [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005. 📶
- [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. 🎲
Authors' Addresses 🎀
T. Charles Clancy 💖 DoD Laboratory for Telecommunications Sciences 8080 Greenmead Drive College Park, MD 20740 USA
EMail: clancy@ltsnet.net
Hannes Tschofenig 🦋 Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
EMail: Hannes.Tschofenig@gmx.net
and that's the whole spec, bestie! we made it through all 8 parts 🎉👑✨
📦 where this page comes from
- ietf: rfc5433 2009-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms