Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method
Extracted elements (30)
EAP-GPSK does not support fast reconnect because the protocol is already at or near the minimum feasible number of round trips and cryptographic operations; adding a fast reconnect path would not provide meaningful improvement.
EAP-GPSK uses only symmetric cryptography (no public-key operations) to minimize computational overhead, enabling deployment on constrained devices with limited processing power, memory, and battery. This also reduces the number of round trips required.
PSKs must be entered identically on both peer and server for interoperability. Validation of ID_Peer and ID_Server is by octet-wise comparison. PSKs must be cryptographically separated from keys used by other protocols, and must not be shared among multiple peers connecting to the same server.
Any EAP-GPSK packet that cannot be parsed MUST be silently discarded. Any unexpected packet (e.g., GPSK-3 received before GPSK-1) MUST be silently discarded. For GPSK-3, a peer MUST silently discard messages where RAND_Peer, ID_Server, or CSuite_Sel do not match those in GPSK-2.
Ciphersuite #1 (AES-CBC-128 / AES-CMAC-128 / GKDF) MUST be implemented by all EAP-GPSK implementations.
Senders MUST NOT reuse the same IV value across messages, use a sequence of values with low Hamming distance, or use ciphertext from a received message as an IV. If no encryption is used, IV Length MUST be 0.
The MAC in GPSK-4 MUST always be included regardless of whether PD_Payload_Block is present. If MAC validation fails on any GPSK-4 packet, the server MUST silently discard the packet.
The PSK management interface MUST support entering PSKs up to 64 octets as ASCII strings and in hexadecimal encoding; it SHOULD support non-ASCII octets for ID_Peer and ID_Server up to 254 octets. ID_Peer and ID_Server MUST be provisioned together with the PSK.
The PSK used by EAP-GPSK SHOULD be a strong key of at least 16 octets. Use of a password or passphrase as the PSK is NOT RECOMMENDED because EAP-GPSK is vulnerable to dictionary attacks.
The PSK used with ciphersuite #1 MUST be 128 bits (16 octets) in length; for ciphersuite #2 it MUST be 256 bits (32 octets). Keys longer than the required length are truncated.
When using ciphersuite #2 (NULL encryption), the protected data block MUST NOT carry confidential information, as no confidentiality protection is provided.
EAP-GPSK defines two ciphersuites: #1 (AES-CBC-128 encryption, AES-CMAC-128 integrity, GKDF, KS=16, ML=16) and #2 (NULL encryption, HMAC-SHA256 integrity, GKDF, KS=32, ML=32). Each ciphersuite specifies encryption, integrity/KDF-MAC, and key derivation algorithms.
EAP-GPSK derives a key hierarchy from the PSK: Master Key MK (KS octets), MSK (64 octets), EMSK (64 octets), session integrity key SK (KS octets), and optional session encryption key PK (KS octets). All keys are derived via the ciphersuite-specified KDF over inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server.
EAP-GPSK performs mutual authentication via a four-message exchange: GPSK-1 (server sends ID_Server, RAND_Server, CSuite_List), GPSK-2 (peer sends ID_Peer, RAND_Peer, MAC), GPSK-3 (server confirms with MAC), and GPSK-4 (peer finalizes). Two error messages, GPSK-Fail and GPSK-Protected-Fail, handle failure cases.
The Generalized Key Derivation Function (GKDF) iteratively applies the ciphersuite MAC function: for i=1 to ceiling(X/ML), result = result || MAC_Y(i || Z), then truncates to X octets. The counter i is a 2-octet network-byte-order integer.
IANA allocated EAP Type 51 for EAP-GPSK and created four new registries: 'EAP-GPSK Ciphersuites' (CSuite/Specifier, 16-bit), 'EAP-GPSK Protected Data Payloads' (PData/Specifier, 16-bit), 'EAP-GPSK Failure Codes' (32-bit), and 'EAP-GPSK OP Codes' (8-bit). New values require IETF Review.
The 'EAP-GPSK Failure Codes' registry is initialized with: 0x00000000 (Reserved), 0x00000001 (PSK Not Found), 0x00000002 (Authentication Failure), and 0x00000003 (Authorization Failure). The field is 32 bits; all other values require IANA registration.
The 'EAP-GPSK OP Codes' registry is initialized with: 0x00 (Reserved), 0x01 (GPSK-1), 0x02 (GPSK-2), 0x03 (GPSK-3), 0x04 (GPSK-4), 0x05 (GPSK-Fail), 0x06 (GPSK-Protected-Fail). The field is 8 bits; all other values require IANA registration.
An adversary may downgrade ciphersuite negotiation to force selection of a suite without confidentiality, exposing PD_Payload_Block in GPSK-2 in cleartext. Extensions that carry sensitive data in GPSK-2's PD_Payload_Block MUST indicate whether confidentiality is mandatory; if so, transmission should be deferred to GPSK-4.
EAP-GPSK does not provide dictionary attack protection. Users who derive the PSK from a password are not protected. The PSK SHOULD be drawn from a pool of at least 2^128 bits of uniformly random secrets.
EAP-GPSK does not provide identity protection; ID_Peer is transmitted in cleartext in GPSK-2. As a result, although the method provides confidentiality in protected data payloads, it cannot claim confidentiality per RFC 3748 Section 7.2.1.
EAP-GPSK does not provide perfect forward secrecy. Compromise of the PSK enables compromise of all recorded past sessions, future sessions, and allows impersonation of both peer and server.
EAP-GPSK provides replay protection via 32-octet random nonces RAND_Server and RAND_Peer; collision probability requires approximately 2^64 sessions before replay is feasible. Randomness quality (per RFC 4086) is critical for this guarantee.
The GPSK-Protected-Fail result indication leaks account existence information to attackers: a server can distinguish 'PSK Not Found' (no such user) from 'Authentication Failure' (wrong PSK) from 'Authorization Failure'. Implementers in sensitive environments should consider disabling protected result indications.
Ciphersuites are encoded as 6-octet arrays: a 4-octet CSuite/Vendor field (0x00000000 for IETF-standardized, or SMI enterprise number for vendor-specific) followed by a 2-octet CSuite/Specifier. CSuite_List is a variable-length concatenation of 6-octet entries; its length MUST be a multiple of 6.
GPSK-1 payload encodes: 2-octet length(ID_Server) followed by ID_Server, 32-octet RAND_Server, 2-octet length(CSuite_List) followed by CSuite_List.
GPSK-2 payload contains ID_Peer (length-prefixed), ID_Server (length-prefixed), 32-octet RAND_Peer, 32-octet RAND_Server, CSuite_List (length-prefixed), 6-octet CSuite_Sel, optional PD_Payload_Block (length-prefixed), and a trailing ML-octet payload MAC covering all preceding fields.
Protected Data payloads (PD_Payload) use a TLV structure: 4-octet PData/Vendor, 2-octet PData/Specifier, 2-octet PData/Length (value only, excluding type and length fields), followed by PData/Value. Multiple PD_Payloads are concatenated into a PD_Payload_Block.
The EAP-GPSK header contains the standard EAP fields (Code 1 octet, Identifier 1 octet, Length 2 octets, Type 1 octet) followed by a 1-octet OP-Code field (0x01–0x06 for GPSK-1 through GPSK-Protected-Fail) and the message-specific payload.
When encryption is used, PD_Payload_Block includes a 1-octet IV Length field followed by the Initialization Vector, the concatenated PD_Payloads, optional Padding (0–255 octets), and a 1-octet Pad Length. The PD_Payloads, Padding, and Pad Length are all encrypted. When no encryption is used, IV Length and Pad Length fields MUST still be present with value 0x00.