| Internet-Draft | Abbreviated Title | June 2026 |
| ROHEE, et al. | Expires 20 December 2026 | [Page] |
This document proposes a lightweight, quantum-resistant protocol for mutual authentication and secret key establishment based on a shared secret over a network. While the existing EAP-PSK protocol provides mutual authentication and key establishment, it faces significant limitations due to evolving security standards. EAP-PSK-256 addresses these vulnerabilities through the following rationales:¶
RAND_P)
for session keys derivation, EAP-PSK-256 strengthens these keys by mixing entropy from
both the Peer and the Server (RAND_S). This ensures that both parties contribute
to the cryptographic randomness of the session.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 December 2026.¶
Copyright (c) 2026 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document specifies a new Extensible Authentication Protocol (EAP) method, designated as EAP-PSK-256. This method is proposed as an evolution of [EAP-PSK] to address anticipated cryptographic transitions. With the projected advancement of quantum computing, current standards utilizing AES-128, the foundation of EAP-PSK key establishment, may become vulnerable to brute-force attacks [GROV96]. Moreover the [EAP-PSK] authors emphasis that the protocol should be deprecated the moment AES-128 is.¶
The primary design goal for EAP-PSK-256 is to provide a direct, quantum-resistant replacement for EAP-PSK while achieving the highest NIST security category. To maintain compatibility with the resource-constrained environments where EAP-PSK is typically deployed, the following requirements are established:¶
Please contact the authors if you believe that any of these goals cannot be met.¶
The protocol specified in this document is designed specifically to provide quantum resistance in resource-constrained environments. Implementations that do not require protection against quantum cryptographic threats SHOULD continue to use [EAP-PSK].¶
For the sake of backward compatibility and ease of implementation, EAP-PSK-256 maintains the fundamental structure and message flow of [EAP-PSK]. The primary modifications are localized to the cryptographic primitives and key lengths. This document ensures that the security properties provided by the original protocol are preserved while introducing post-quantum resistance according to current best practices.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terms and abbreviations are used in this document. For broader definitions of EAP-related terms, please refer to [RFC3748].¶
All numbers presented in this document are considered in network-byte order (big-endian).¶
The EAP-PSK-256 :¶
+------------------------------------------------------------------+ | EAP-PSK-256 Key Hierarchy | +------------------------------------------------------------------+ | | | +--------------+ | | | PSK | | | | (32 bytes) | | | +------+-------+ | | | | | v | | +-----------+ +==========+============+ +----------+ | | | label L1 +------>+ KDF-DP-CMAC-AES-256 +<------+context C1| | | +-----------+ +==========+============+ +----------+ | | | | | +------------------+ | | v v | | +------+-----+ +------+-----+ | | | AK | | KDK | | | | (32 bytes) | | (32 bytes) | | | +------------+ +------+-----+ | | | | | v | | +-----------+ +==========+============+ +----------+ | | | label L2 +------>+ KDF-DP-CMAC-AES-256 +<------+context C2| | | +-----------+ +==========+============+ +----------+ | | | | | +----------------------+----------------------+ | | v v v | | +------+-----+ +------+-----+ +------+-----+ | | | TEK | | MSK | | EMSK | | | | (32 bytes) | | (64 bytes) | | (64 bytes) | | | +------+-----+ +------------+ +------------+ | | | | | +-------------+ | | | | | +------------+ | +-----------+ | | | Header H +----+ | +------------+ Nonce N | | | | (22 bytes) | | | | | (4 bytes) | | | +------------+ | | | +-----------+ | | v v v | | +===+==+==+===+ +-----------+ | | | AES-256-EAX +<-------+ Plaintext | | | +=+=========+=+ +-----------+ | | / \ | | v v | | +--------+---+ +---+----------+ | | | Tag | | Ciphertext | | | | (16 bytes) | | Payload | | | +------------+ +--------------+ | | | +------------------------------------------------------------------+¶
The Advanced Encryption Standard (AES) is defined in three key lengths: 128, 192, and 256 bits. Among these, AES-256 is recognized as providing sufficient security margins against quantum computing threats. Specifically, a theoretical attack based on Grover's algorithm [GROV96] can reduce the effective security strength of symmetric primitives by half. Consequently, AES-128, the primitive utilized in EAP-PSK [EAP-PSK], would provide only 64 bits of security in the presence of a cryptographically relevant quantum computer (CRQC).¶
While the practical implementation of such an attack remains a future challenge, EAP-PSK-256 adopts a proactive security posture. By utilizing AES-256 for all symmetric operations, this protocol targets a post-quantum security strength of Level 5 according to the NIST Post-Quantum Cryptography classification [PQC-CRIT].¶
CMAC is used for message integrity and as a pseudo-random function (PRF). This protocol utilizes AES-256 as the underlying block cipher for CMAC operations, as specified in [SP800-38B].¶
EAP-PSK-256 utilizes the KDF in Double-Pipeline Iteration Mode as specified in [SP800-108]. CMAC-AES-256 is used as the underlying PRF for this KDF. To ensure security, derived keys MUST NOT overlap, as specified in Section 6.5 of [SP800-108].¶
The KDF requires the following parameters:¶
K_IN is the Key-derivation key used as an input key for CMAC-AES-256. In the context of EAP-PSK-256, K_IN MUST be 32 octets long.¶
The context (C) is an octet string that provides information regarding the specific session and entities involved. It ensures that the derived keying material is unique to the current exchange. The context is formed by the concatenation of a protocol-specific string, the Network Access Identifiers (NAI) of the peer and the server, a counter, and a random nonce depending of the use case.¶
The label is an octet string that distinguishes between different purposes for the derived keying material. EAP-PSK-256 defines the following labels:¶
L specifies the requested length (in bits) of the derived keying material. Its binary representation, denoted [L]2 in [SP800-108], is 2 octets long.¶
The Pre-Shared Key (PSK) is a long-term secret shared exclusively between the EAP peer and the EAP server. EAP-PSK-256 assumes that this key is known only to these two entities; its security properties are compromised in the event of unauthorized distribution.¶
The protocol assumes that the server and peer can identify the correct PSK using their respective Network Access Identifiers (NAIs). Consequently, there MUST be at most one PSK shared between a specific server NAI and a specific peer NAI.¶
The PSK is used during the "Key Setup" phase to derive two 32-octet static subkeys:¶
This derivation SHOULD be performed only once. Because the inputs to the KDF during Key Setup are static, multiple invocations would produce identical outputs. Furthermore, EAP-PSK-256 utilizes the derived AK and KDK for all subsequent cryptographic operations rather than the PSK itself. Performing this derivation once at provisioning or at the start of the first session preserves computational resources.¶
EAP-PSK-256 uses the AK to provide mutual authentication between the EAP peer and the EAP server.¶
Entities identify the correct AK based on the NAIs provided during the initial exchange. The EAP peer selects the AK based on the server identity (ID_S) received in the first EAP-PSK-256 message and the peer identity (ID_P) it includes in the second message.¶
EAP-PSK-256 uses the KDK to derive the session-specific keying material shared by the peer and server.¶
The selection of the KDK follows the same NAI-based logic as the AK. Since both keys are derived from the same unique PSK associated with the ID_P/ID_S pair, identifying the PSK effectively identifies both the AK and KDK.¶
EAP-PSK-256 derives a 32-octet TEK using the KDK and the session nonces (RAND_P and RAND_S) exchanged during the Authenticated Key Exchange (see Section 2.3.2).¶
The TEK is used to establish a protected channel between the EAP peer and server. This channel provides confidentiality and integrity for the EAP-Payload in subsequent messages using the AES-EAX-256 authenticated encryption ciphersuite.¶
EAP-PSK-256 derives an MSK using the KDK and the session nonces as specified in Section 2.3.2. The MSK is 64 octets in length, which complies with the requirements for keying material export defined in [RFC3748]. The usage of the MSK is specified in [RFC3748].¶
EAP-PSK-256 derives an EMSK using the KDK and the session nonces as specified in Section 2.3.2. The EMSK is 64 octets in length, which complies with [RFC3748]. The usage of the EMSK is specified in [RFC3748].¶
EAP-PSK-256 requires two cryptographically separated 32-octet subkeys, the Authentication Key (AK) and the Key Derivation Key (KDK), for distinct purposes. The AK is utilized for mutual authentication, while the KDK is used for the subsequent derivation of session keys.¶
The PSK is used exclusively to derive the AK and KDK. This derivation SHOULD be performed only once, immediately after the PSK has been provisioned. Once the AK and KDK are successfully derived, the PSK MAY be deleted. If deleted, the PSK MUST be removed securely (refer to [NIST_SP800-88r2] for guidance on secure deletion).¶
The derivation of AK and KDK from the PSK is performed using the KDF specified in Section 2.1.1.3 with the following inputs:¶
The 512-bit output of the KDF is divided into two 256-bit strings. The first 256 bits (octets 0-31) represent the AK, and the subsequent 256 bits (octets 32-63) represent the KDK.¶
+---------------------------+
| K_IN (32 bytes) |
| (PSK) |
+-------------+-------------+
|
v
+----------------+ +=============+=============+
| Label +---->+ | +-----------+
| "KEY_SET_UP" | | Parameters: h=128, r=32 | | L = 512 |
+----------------+ | +<----+ (2 bytes) |
| Context +---->+ KDF-DP-CMAC-AES-256 | +-----------+
| "EAP-PSK-256" | | |
| || 0x00 | +==+=====================+==+
| || NAI_P | | |
+----------------+ | |
| |
K[0:31] K[32:63]
| |
v v
+-----------------+---------+ +---------+-----------------+
| AK | | KDK |
| (32 bytes) | | (32 bytes) |
+---------------------------+ +---------------------------+
¶
The Authenticated Key Exchange (AKE) for EAP-PSK-256 is based on the AKEP2 protocol as described in [AKEP2][EAP-PSK]. The message sequence is defined as follows:¶
Peer (P) Server (S) | | | ID_S || RAND_S | |<-------------------------------------------+ | | | [ID_P || ID_S || RAND_S || RAND_P] | +------------------------------------------->| | | | [ID_S || RAND_P] | |<-------------------------------------------+ | |¶
This adaptation of AKEP2 allows both parties to learn each other's identities. Note that this is a simplified version of the exchange.¶
Following successful mutual authentication, session keys are derived using the KDF in Double-Pipeline Iteration Mode [SP800-108]. The derivation uses the KDK to produce 1280 bits of keying material.¶
+---------------------------+
| K_IN (32 bytes) |
| (KDK) |
+-------------+-------------+
|
v
+----------------+ +=============+=============+
| Label +---->+ | +-----------+
| "SESSION_KEYS" | | Parameters: h=128, r=32 | | L = 1280 |
+----------------+ | +<----+ (2 bytes) |
| Context +---->+ KDF-DP-CMAC-AES-256 | +-----------+
| "EAP-PSK-256" | | |
| || 0x00 | +==+===========+==========+=+
| || NAI_P | | | |
| || NAI_S | | | |
| || RAND_P | K[0:31] K[32:95] K[96:159]
| || RAND_S | | | |
+----------------+ v v v
+---------+--+ +------+-----+ +--+---------+
| TEK | | MSK | | EMSK |
| (32 bytes) | | (64 bytes) | | (64 bytes) |
+------------+ +------------+ +------------+
¶
The KDF parameters are defined as follows:¶
Note that the input for session key derivation includes entropy from both the Peer and
the Server. Specifically, EAP-PSK-256 increases the cryptographic randomness by
incorporating both RAND_P and RAND_S into the context. This is a
significant departure from legacy EAP-PSK [EAP-PSK], which only utilized RAND_P for session key derivation
(see Figure 7 of [EAP-PSK]).¶
The 160-octet (1280-bit) output of the KDF is partitioned into three distinct session keys:¶
The protected channel in EAP-PSK-256 remains architecturally identical to that of EAP-PSK, with the primary modification being the upgrade of the underlying block cipher from AES-128 to AES-256.¶
EAP-PSK-256 provides a protected channel for both parties to communicate over upon successful mutual authentication. This channel is currently utilized to exchange protected result indications and is available for future protocol extensions.¶
EAP-PSK-256 employs the EAX mode of operation to provide this protected channel.¶
+----------+ +-----------+ +------------+ +------------+
| Nonce N | | Header H | | Plaintext | | TEK |
| 4 bytes | | 22 bytes | | Payload L | | 32 bytes |
+----+-----+ +-----+-----+ +-----+------+ +-----+------+
| | | |
v v v v
+====+=============+=============+==============+======+
| |
| EAX (using AES-256) |
| |
+==============+====================+==================+
| |
v v
+------+-----+ +------+-----+
| Ciphertext | | Tag |
| Payload | | (16 bytes) |
+------------+ +------------+
¶
The protected channel provides the following security properties:¶
EAX is instantiated with AES-256 as the underlying block cipher, keyed with the 32-octet TEK.¶
The nonce N provides cryptographic security for encryption, data origin authentication, and replay protection. N is a 4-octet sequence number starting at 0, monotonically incremented for each EAP-PSK-256 message within a single EAP dialog (excluding retransmissions).¶
A 4-octet length is used for N to simplify implementation. Since EAX requires a 16-octet nonce, N is padded with 96 zero bits in the high-order positions.¶
For cryptographic integrity, N MUST NOT wrap around. If a server reaches a value of 2**32-2, it MUST NOT send further messages on the channel. The conversation MUST finish at 2**32-1 or be aborted.¶
The Header H consists of the first 22 octets of the EAP Request or Response packet (comprising the EAP Code, Identifier, Length, and Type fields, followed by the EAP-PSK-256 Flags and RAND_S fields). Protecting these fields at the method layer follows the recommendations in [RFC3748] Section 7.5.¶
The Tag is a Message Authentication Code (MAC) protecting both the Header and the Plain Text Payload. Tag verification MUST be performed after Nonce verification. If the Tag is valid, the payload is decrypted; otherwise, the process is aborted and the failure SHOULD be logged. The tag length is 16 octets.¶
While other Authenticated Encryption with Associated Data (AEAD) modes such as OCB are currently patent-free and offer high performance, EAX was selected for EAP-PSK-256 based on the following criteria:¶
As stated in the introduction, message of EAP-PSK-256, is widely the same as that of EAP-PSK-256. For those already familiar to EAP-PSK-256, transition would be transparent concerning EAP message flow and format. For those who discover this protocol, for the sake of auto portability we prefered gathering all the information in this draft instead of referring to EAP-PSK.¶
EAP-PSK-256 may consist of two different types of message flows:¶
EAP-PSK-256 introduces the concept of a session to facilitate its analysis and provide a cleaner interface to other layers. A session is a particular instance of an EAP-PSK-256 dialog between two parties. This session is identified by a session identifier.¶
In the first EAP-PSK-256 message, the EAP server asserts its identity. Given that the EAP-Request/Identity and EAP-Response/Identity may not be assumed to have occurred prior to this sending and that the response included in EAP-Response/Identity (if this EAP Identity exchange takes place) may not contain the actual NAI the peer shall use with EAP-PSK-256, this means that an EAP server implementing EAP-PSK-256 must use the same EAP server NAI for all EAP-PSK-256 dialogs with any EAP peer implementing EAP-PSK-256.¶
EAP-PSK-256 standard authentication is comprised of four messages, i.e., two round-trips; see Figure 6 .¶
Peer (P) Server (S) | | | Flags||RAND_S||ID_S | |<---------------------------------------------------------+ | | | Flags||RAND_S||RAND_P||MAC_P||ID_P | +--------------------------------------------------------->| | | | Flags||RAND_S||MAC_S||PCHANNEL_S_0 | |<---------------------------------------------------------+ | | | Flags||RAND_S||PCHANNEL_P_1 | +--------------------------------------------------------->| | |¶
The first message is sent by the server to the peer to:¶
The second message is sent by the peer to the server to:¶
The third message is sent by the server to the peer to:¶
The fourth message is sent by the peer to the server to finish the setup of the protected channel (P_CHANNEL_P_1) to confirm that it has derived session keys and give a protected result indication.¶
This standard message flow could be comprised of only three messages, like AKEP2, were it not for the request/response nature of EAP that prevents the third message from being the last one. Since the fourth message is mandatory, EAP-PSK-256 chose to take advantage of this and set up a protected channel.¶
The standard message flow also includes a statement by the peer of its identity, in addition to the EAP-Response/Identity it may have sent. This behavior follows Section 5.1 of [RFC3748], which recommends that the EAP-Response/Identity be used primarily for routing purposes and selecting which EAP method to use, and therefore that EAP methods include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response.¶
When a party receives an EAP-PSK-256 message, it checks that the message is syntactically valid in accordance with the message formats defined in Section 3.2. If the message is syntactically incorrect, then it is silently discarded. Then it checks the cryptographic validity of this message, i.e., it checks the MAC(s) as follows:¶
If the received message is the first EAP-PSK-256 message, there is no MAC to check as none is included in message 1.¶
If the received message is the second EAP-PSK-256 message, the validity of MAC_P is checked.¶
If the received message is the third EAP-PSK-256 message, the validity of MAC_S is checked and then the validity of the Tag included in P_CHANNEL_S_0 is checked. The validity checks must be done in this order to avoid unnecessarily deriving TEK, MSK, and EMSK in case MAC_S is invalid, meaning that mutual authentication has failed. Indeed, TEK is used to verify the validity of the Tag included in P_CHANNEL_S_0.¶
If the received message is the fourth EAP-PSK-256 message, the validity of the Tag included in P_CHANNEL_P_1 is checked.¶
If a validity check fails, the message is silently discarded. There can be a counter to track the number of silently discarded messages per Section 6.10. If there is an encrypted payload in the message (namely, in the PCHANNEL attribute), then the encrypted payload is decrypted. Then, if the decrypted payload is syntactically incorrect, the message is silently discarded.¶
To remain simple and yet be extensible to meet future requirements, EAP-PSK-256 provides an extension mechanism within its protected channel: the payload of the protected channel may contain an optional extension field (EXT).¶
Figure 7 presents the message sequence for EAP-PSK-256 extended authentication.¶
Peer (P) Server (S) | | | Flags||RAND_S||ID_S | |<---------------------------------------------------------+ | | | Flags||RAND_S||RAND_P||MAC_P||ID_P | +--------------------------------------------------------->| | | | Flags||RAND_S||MAC_S||PCHANNEL_S_0(EXT) | |<---------------------------------------------------------+ | | | Flags||RAND_S||PCHANNEL_P_1(EXT) | +--------------------------------------------------------->| | | : : | Flags||RAND_S||PCHANNEL_S_2i(EXT) | |<---------------------------------------------------------+ | | | Flags||RAND_S||PCHANNEL_P_2i+1(EXT) | +--------------------------------------------------------->| | |¶
Extended authentication MUST be supported, i.e., any EAP-PSK-256 implementation MUST support sending and reception of an EXT attribute according to rules of operation described in Section 4. Yet, although support of the EXT field is mandatory, there is no mandatory extension type to support. This means that if a server engages in EAP-PSK-256 extended authentication, as only the server can start extended authentication per Section 4, a peer will recognize the attempt to start extended authentication through its EXT support. If the peer does not support the particular extension type used by the server, the peer will still be able to conclude the EAP-PSK-256 dialog.¶
The mandatory support of the EXT field is dictated:¶
To guarantee a robust behavior in the future where some peers might support some extensions and others not. All peers will thus be able to understand that an extended authentication is being attempted and indicate whether or not they support the extension that is tried.¶
To ensure that all implementations will indeed be extensible.¶
No extension is currently defined. At most, one extension may be run within a single EAP-PSK-256 dialog: there can neither be sequences of extensions nor interleaved extensions. However, extensions may take a variable number of round-trips to complete. Only the server can start an extension and, if it does so, it must start it in the first payload it sends over the protected channel.¶
Please refer to Section 4 for more details on how extended authentication works.¶
The PCHANNEL_S_2j and PCHANNEL_P_2j+1 fields of the EAP-PSK-256 messages (where j varies from 0 to i) contain a MAC computed thanks to TEK that protects the integrity of the messages. For a detailed list of the fields of the messages that are integrity protected, please refer to Section 2.4.¶
When a party receives an EAP-PSK-256 message, it checks that the message is syntactically valid in accordance with the message formats defined in Section 3.2. If the message is syntactically incorrect, then it is silently discarded. Then it checks the cryptographic validity of this message, i.e., it checks the MAC(s) as follows:¶
If the received message is the first EAP-PSK-256 message, there is no MAC to check as none is included in message 1.¶
If the received message is the second EAP-PSK-256 message, the validity of MAC_P is checked.¶
If the received message is the third EAP-PSK-256 message, the validity of MAC_S is checked and then the validity of the Tag included in P_CHANNEL_S_0 is checked. The validity checks must be done in this order to avoid unnecessarily deriving TEK, MSK, and EMSK in case MAC_S is invalid, meaning that mutual authentication has failed. Indeed, TEK is used to verify the validity of the Tag included in P_CHANNEL_S_0.¶
If the received message is the fourth EAP-PSK-256 message, the validity of the Tag included in P_CHANNEL_P_1 is checked.¶
If the received message is an EAP-PSK-256 message different from the first four ones, then validity of the Tag included in P_CHANNEL is checked.¶
If a validity check fails, the message is silently discarded. There can be a counter to track the number of silently discarded messages per Section 6.10. If there is an encrypted payload in the message (namely in the PCHANNEL attribute), then the encrypted payload is decrypted. Then, if the decrypted payload is syntactically incorrect, the message is silently discarded.¶
For the sake of simplicity, EAP-PSK-256 uses a fixed message format. There are four different types of EAP-PSK-256 messages:¶
The first EAP-PSK-256 message, which is sent by the server to the peer.¶
The second EAP-PSK-256 message, which is sent by the peer to the server.¶
The third EAP-PSK-256 message, which is sent by the server to the peer.¶
The fourth EAP-PSK-256 message, which is sent by the peer to the server. This is also the type of message that the peer further sends to the server in case of an extended authentication. This is also essentially the type of message that the server further sends to the peer in case of an extended authentication: the only slight modification that occurs in this last case is the setting of the EAP Code to 1 instead of 2 in the other cases.¶
For the sake of clarity, the whole EAP packet that encapsulates the EAP-PSK-256 message (i.e., the EAP-PSK-256 message plus its EAP headers) is depicted in Figure 8, Figure 9, Figure 10, and Figure 14.¶
The first EAP-PSK-256 message is sent by the server to the peer. It has the format presented in Figure 8.¶
|0 |1 |2 |3 | |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=1 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Flags | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | RAND_S | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | : ID_S : | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
While IANA allocated EAP method type 47 for legacy EAP-PSK, the Type field for EAP-PSK-256 is TBD.¶
The first EAP-PSK-256 message consists of:¶
A 1-octet Flags field.¶
A 16-octet random number: RAND_S.¶
A variable length field that conveys the server's NAI: ID_S. The length of this field is deduced from the EAP length field. The length of this NAI must not exceed 966 octets. This restriction aims at avoiding fragmentation issues (see Section 6.14 ).¶
The second EAP-PSK-256 message is sent by the peer to the server. It has the format presented in Figure 9.¶
|0 |1 |2 |3 | |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Flags | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | RAND_S | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | RAND_P | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ + | | + + | MAC_P | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ + | | : ID_P : | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
It consists of:¶
A 1-octet Flags field.¶
The 16-octet random number sent by the server in the first EAP-PSK-256 message (RAND_S) that serves as a session identifier.¶
A 16-octet random number: RAND_P.¶
A 16-octet MAC: MAC_P. As specified in Section 2.3, this is computed using CMAC-AES-256.¶
A variable length field that conveys the peer's NAI: ID_P. The length of this field is deduced from the EAP length field. The length of this NAI must not exceed 966 octets. This restriction aims at avoiding fragmentation issues (see Section 6.14 ).¶
The third EAP-PSK-256 message is sent by the server to the peer. It has the format presented in Figure 10.¶
|0 |1 |2 |3 | |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=1 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Flags | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | RAND_S | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | MAC_S | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ + | | : PCHANNEL : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
It consists of:¶
A 1-octet Flags field.¶
The 16-octet random number sent by the server in the first message (RAND_S).¶
A 16-octet MAC: MAC_S (computed via CMAC-AES-256).¶
A variable length field that constitutes the protected channel: PCHANNEL.¶
If there is no extension, the PCHANNEL field consists of:¶
A 4-octet Nonce N.¶
A 16-octet Tag.¶
A 2-bit result indication flag R.¶
A 1-bit extension flag E, which is set to 0.¶
A 5-bit Reserved field.¶
|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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Tag | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R |0| Reserved| +-+-+-+-+-+-+-+-+¶
If there is an extension, the PCHANNEL field includes a variable length EXT field.¶
|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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Tag | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R |1| Reserved| | +-+-+-+-+-+-+-+-+ + | | : EXT : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The EXT field format is presented in Figure 13.¶
|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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EXT_Type | | +-+-+-+-+-+-+-+-+ + | | : EXT_Payload : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The fourth EAP-PSK-256 message is sent by the peer to the server. It has the format presented in Figure 14.¶
|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=2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Flags | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | RAND_S | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | : PCHANNEL : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
It consists of:¶
A 1-octet Flags field.¶
The 16-octet random number sent by the server in the first EAP-PSK-256 message (RAND_S) that is used as a session identifier.¶
A variable length field that constitutes the protected channel: PCHANNEL.¶
The Flags field format is presented in Figure 15.¶
The PCHANNEL field has the following structure, which was already described in Section 3.5 .¶
If there is no extension, i.e., if the authentication is standard, the PCHANNEL field consists of:¶
A 4-octet Nonce N (see Section 2.4).¶
A 16-octet Tag (see Section 2.4).¶
A 2-bit result indication flag R.¶
A 1-bit extension flag E, which is set to 0.¶
A 5-bit Reserved field, which is set to zero on emission and ignored on reception.¶
R, E, and Reserved are sent encrypted by the protected channel (see Section 2.4). If there is no extension, PCHANNEL has the format presented in Figure 11.¶
If there is an extension, i.e., if the authentication is extended, the PCHANNEL field consists of:¶
A 4-octet Nonce N (see Section 2.4).¶
A 16-octet Tag (see Section 2.4).¶
A 2-bit result indication flag R.¶
A 1-bit extension flag E, which is set to 1.¶
A 5-bit Reserved field, which is set to zero on emission and ignored on reception.¶
A variable length EXT field.¶
R, E, Reserved, and EXT are sent encrypted by the protected channel (see Section 2.4). If there is an extension, PCHANNEL has the format presented in Figure 12.¶
This EXT field is split into two subfields:¶
The Flags field has the format presented in Figure 15.¶
|0 | |0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+ | T | Reserved | +-+-+-+-+-+-+-+-+¶
The Flags field is comprised of two subfields:¶
A 2-bit T subfield, which indicates the type of EAP-PSK-256 message:¶
T=0 for the first EAP-PSK-256 message presented in Section 3.3 .¶
T=1 for the second EAP-PSK-256 message presented in Section 3.4 .¶
T=2 for the third EAP-PSK-256 message presented in Section 3.5 .¶
T=3 for the fourth EAP-PSK-256 message presented in Section 3.6 and the subsequent EAP-PSK-256 messages that may be exchanged during extended authentication.¶
A 6-bit Reserved subfield that is set to zero on transmission and ignored on reception.¶
The PCHANNEL Nonce field N (see Section 3.5) is used to distinguish between the different EAP-PSK-256 messages that may be exchanged during extended authentication that all have T set to 3, i.e., the fourth EAP-PSK-256 message and possibly the next ones.¶
In this section, the rules of operation of the EAP-PSK-256 protected channel are presented:¶
The R flag of the PCHANNEL field in the third and fourth types of EAP-PSK-256 messages is used to provide result indications.¶
Since this 2-bit flag is communicated over the protected channel, it is:¶
Encrypted so that only the peer and the server can know its value.¶
Integrity-protected so that it cannot be modified by an attacker without the peer or the server detecting this modification.¶
Protected against replays.¶
This 2-bit R flag can take the following values:¶
The peer and the server each remember some information about both the values of R that they have sent and the values of R they have received. It is the conjunction of both sent and received R values that indicate the success or the failure of the EAP-PSK-256 dialog.¶
In the case of a standard authentication, the following values of R should be exchanged:¶
Either the server sends a DONE_SUCCESS in the PCHANNEL of the third EAP-PSK-256 message, to which the peer replies with a DONE_SUCCESS in the PCHANNEL of the fourth EAP-PSK-256 message, which successfully ends the EAP-PSK-256 dialog.¶
Or the server sends a DONE_FAILURE in the PCHANNEL of the third EAP-PSK-256 message, to which the peer replies with a DONE_FAILURE in the PCHANNEL of the fourth EAP-PSK-256 message, which unsuccessfully ends the EAP-PSK-256 dialog.¶
In the case of an extended authentication, more complex exchanges may occur, which is why the CONT value was introduced.¶
The rules of operation for each value that R may take are detailed below.¶
The server and the peer each initialize the values of R they intend to send and receive as CONT.¶
Here CONT stands for "Continue". It indicates that the EAP-PSK-256 dialog is not yet successful and that the party sending it wants to continue the dialog to try and reach success.¶
Indeed, although the peer and the server must have successfully authenticated each other, thanks to MAC_P and MAC_S, before they start communicating over the protected channel, the EAP-PSK-256 dialog may not yet be deemed successful after this mutual authentication because of authorization issues. For instance, a prepaid customer of a wireless Hot-Spot might have successfully authenticated but has to refill its account, e.g., with a credit card transaction over the protected channel, before it is authorized.¶
DONE_SUCCESS indicates that the party that sent it deems the EAP-PSK-256 dialog successful and therefore proposes to end this dialog.¶
Once the server has sent a DONE_SUCCESS, it must keep sending this value for R. The peer must first receive a DONE_SUCCESS from the server before it is allowed to send a DONE_SUCCESS.¶
After the peer has received a DONE_SUCCESS from the server, it may:¶
Send a CONT to the server if it has not reached success on its side. The server that receives a CONT should continue the EAP-PSK-256 dialog (see Section 6.2 ).¶
Send a DONE_SUCCESS to the server, which will end the EAP-PSK-256 dialog with success.¶
Send a DONE_FAILURE to the server, which will end the EAP-PSK-256 dialog with failure.¶
DONE_FAILURE indicates that the party that sent it deems the EAP-PSK-256 dialog unsuccessful and proposes to end this dialog because nothing will make it change its mind.¶
If the server is the first to send a DONE_FAILURE, then the peer that receives this DONE_FAILURE must reply with a DONE_FAILURE and fail, which ends the EAP-PSK-256 dialog.¶
If the peer is the first to send a DONE_FAILURE, then the server that receives this DONE_FAILURE must immediately end this EAP-PSK-256 dialog without sending any further EAP-PSK-256 message, and fail.¶
An extended authentication can only be started by the server.¶
Exactly one extension (identified by the EXT_Type subfield of the EXT field) must be run during an EAP-PSK-256 extended authentication dialog. The extension is run over the protected channel: it can assume confidentiality, integrity, and replay protection.¶
To start an extended authentication, the server sets the PCHANNEL E flag to 1 and includes the EXT_Payload of the extension it has chosen.¶
Since EAP-PSK-256 does not provide fragmentation, the extension must not send an EXT_Payload larger than 960 octets, which corresponds to the 1020-octet EAP MTU that may minimally be assumed.¶
Moreover, an extension must not send an empty EXT_Payload (because this has a particular meaning for EAP-PSK-256; see below).¶
When the peer receives the third EAP-PSK-256 message with the E flag set to 1, it checks whether it is able to process the proposed extension. If the peer is not able to process the proposed extension (i.e., it does not recognize the EXT_Type), it sets E=1 in its reply (the fourth EAP-PSK-256 message) and includes an EXT field of the same EXT_Type but with an empty EXT_Payload.¶
Depending on the values taken by the R flags, the EAP-PSK-256 dialog may:¶
End¶
If the peer's policy mandates that it fails in the case of an unrecognized extension, it sends a DONE_FAILURE in the fourth EAP-PSK-256 message.¶
If the server has sent a DONE_SUCCESS in the third EAP-PSK-256 message, and the peer's policy authorizes it to succeed even if the extension is not recognized, the peer sends a DONE_SUCCESS.¶
Continue for exactly one round-trip¶
In case the server has sent a CONT in the third EAP-PSK-256 message and the peer's policy authorizes it to succeed even if the extension is not recognized, the peer replies with a CONT in the fourth EAP-PSK-256 message. The server must then, depending on its policy, send either a DONE_SUCCESS or a DONE_FAILURE to the peer in the fifth EAP-PSK-256 message. If the server sent a DONE_SUCCESS in the fifth message, the peer must send a DONE_SUCCESS in the sixth message. All these messages must have the E flag set to 1 with an EXT field with the EXT_Type of the extension that was proposed and an empty EXT_Payload.¶
If the peer is able to process the proposed extension, then it does so. In this case, the extension must be aware of the R values sent and received and able to propose to update them. All the subsequent messages exchanged between the peer and the server must have the E flag set to 1 with an EXT field of the EXT_Type of the extension that was proposed and a non-empty EXT_Payload.¶
TO DO: This memo includes no request to IANA.¶
EAP-PSK-256 achieves bilateral verification through the exchange of cryptographic tags. The server validates the peer's identity via a computed MAC, while the peer confirms the server's authenticity through a secondary MAC verification.¶
This mechanism is based on the AKEP2 framework and the CMAC algorithm, both of which are supported by formal security proofs. For entity authentication, a 16-octet tag length is utilized. The security foundation of this process rests on the AES-256 block cipher.¶
The Authentication Key (AK) is dedicated solely to this exchange, ensuring cryptographic separation from session encryption. Robustness depends on the use of a strong, pairwise PSK; without sufficient entropy or proper key distribution, the authentication guarantees are void, consistent with standard symmetric-key protocols.¶
EAP-PSK-256 provides protected result indications via its 2-bit R flag (see Section 4.1). This 2-bit R flag is protected because it is encrypted and integrity protected by the protected channel mechanism (see Section 2.4 ).¶
Care may be taken against Byzantine failures, for instance, when a peer tries to force a server to engage in a never-ending conversation. This could be done by a peer that keeps sending a CONT after it has received a DONE_SUCCESS from the server. A policy may limit the number of rounds in an EAP-PSK-256 extended authentication to mitigate this threat, which is outside our threat model.¶
It should also be noted that the cryptographic protection of the result indications does not prevent message deletion. For instance, consider a scenario in which:¶
In the case that the last message from the peer is intercepted, and an EAP Success is sent to the peer before any retransmission from the server reaches it, or the retransmissions from the server are also deleted, the peer will believe that it has successfully authenticated to the server while the server will fail.¶
This behavior is well known (see [HalpernMoses1990]) and in a sense unavoidable. There is a trade-off between efficiency and the "level" of information sharing that is attainable. EAP-PSK-256 specifies a single round-trip of DONE_SUCCESS because it is believed that:¶
If there is an adversary capable of disrupting the communication channel, it can do so whenever it wants (be it after 1 or 10 round-trips or even during data communication).¶
Other layers/applications will generally start by doing a specific key exchange and confirmation procedure using the keys derived by EAP-PSK-256. This is typically done by IEEE 802.11i "four-way handshake". In case the error is not detected by EAP-PSK-256, it should be detected then.¶
The EAX mode provides authenticated encryption for the protected channel. This prevents bit-flipping and ciphertext manipulation attacks. A 16-octet tag is used to ensure that any modification to the payload or the associated header results in a MAC failure, causing the packet to be discarded before decryption occurs.¶
Unique session keys are ensured through the inclusion of two independent 128-bit random nonces, RAND_P and RAND_S, within the key derivation context. Because these nonces are freshly generated and unpredictable, knowledge of session keys from a previous execution provides no advantage in decrypting or authenticating later sessions, even when the long-term PSK remains unchanged.¶
EAP-PSK-256 provides replay protection for its mutual authentication exchange through the random values RAND_S and RAND_P. Since RAND_S is 128 bits long, an attacker would need to record on the order of 2^64 successful authentications (See Birthday paradox) before a replay becomes statistically possible. Replay protection is therefore ensured as long as both values are generated using a cryptographically strong random source. Randomness is critical for security.¶
During the protected channel phase, EAP-PSK-256 ensures replay protection by means of a monotonically increasing nonce (N). The server initializes this nonce to 0, and each party increments it by 1 whenever it receives a valid EAP-PSK-256 message. For example, if the peer receives a message from the server with N = x, it responds with a message containing N = x + 1 and then expects the following server message to contain N = x + 2.¶
A retransmitted server message containing a previously seen nonce value (e.g., N = x) would only cause the peer's EAP layer to retransmit the earlier message with N = x + 1. This behavior renders replay attempts ineffective and transparent to the EAP-PSK-256 layer.¶
The EAP peer MUST verify that the server initializes the nonce to 0 at the beginning of the protected channel establishment.¶
EAP-PSK-256 provides protection against reflection attacks during extended authentication for the following reasons:¶
Because the authentication exchange is visible to an observer, the PSK is vulnerable to offline dictionary attacks. An adversary can verify PSK candidates by recalculating the MACs seen in the AKE process. While the 256-bit primitives increase the computational cost per attempt, the security of the method remains fundamentally bound to the entropy of the initial PSK.¶
The migration to 256-bit keys specifically addresses the theroritical threat posed by Grover's algorithm (see [GROV96]). In a post-quantum scenario, a large-scale quantum computer could reduce the effective security of a 128-bit key to 64 bits. By utilizing AES-256 and deriving 256-bit internal keys (AK, KDK, TEK), EAP-PSK-256 maintains a 128-bit security margin against quantum-accelerated brute-force searches.¶
EAP-PSK-256 supports key derivation. The key hierarchy is specified in Figure 1.¶
The use of KDF-DP ([SP800-108]) ensures that even if one derived key (such as the TEK) is compromised, the parent KDK and other sibling keys remain secure. This hierarchical one-way derivation prevents upward compromise and maintains the 256-bit security level across all functional subkeys.¶
The underlying cryptographic primitives, CMAC and AES-256, are widely believed to constitute a secure block-cipher-based construction.¶
A first key derivation occurs to compute AK and KDK from the PSK; this is referred to as the key setup (Section 2.2). It uses the PSK as the key to a modified counter mode. As a consequence, AK and KDK are cryptographically separated and are computable only by entities that possess the PSK.¶
A second key derivation is then performed to generate the session keys TEK, MSK, and EMSK (Section 6.13). This derivation uses KDK as the key for the modified counter mode.¶
The protocol design explicitly assumes that neither AK nor KDK are shared beyond the two parties that use them. If AK is shared, it no longer authenticates the peer and server to each other. Likewise, the derived TEK, MSK, and EMSK lose their security value if KDK is disclosed to any third party.¶
It should be emphasized that the peer maintains control over the session keys derived by EAP-PSK-256. The peer selects the final random contribution (RAND_P) used in the derivation.¶
This design choice was made because preventing the peer from influencing the session key derivation would have increased protocol complexity (for example, by requiring an additional one-way AES-based function in the derivation). Moreover, it is assumed that the peer has no incentive to force the server into using predetermined session key values. Such an attack lies outside the intended threat model and offers little benefit compared to the peer simply disclosing its PSK.¶
However, this behavior does not align with the recommendation stated in Section 7.10 of [RFC3748].¶
Because session key derivation requires cryptographic computation, it is recommended that TEK, MSK, and EMSK be derived only after successful mutual authentication. That is, the server must have verified MAC_P and the peer must have verified MAC_S.¶
Implementations must take great care to ensure that derived keys are never exposed if the EAP-PSK-256 dialog fails (for example, if it terminates with DONE_FAILURE).¶
The TEK MUST NOT be made available to any party other than the current EAP-PSK-256 session.¶
EAP-PSK-256 is not subject to downgrade attacks when used as a replacement for EAP-PSK. Protocol negotiation should be carried out by the higher-level protocol that uses this method for authentication. Because EAP-PSK and EAP-PSK-256 are assigned different EAP Method Type numbers, they cannot be confused if the higher-level protocol is implemented correctly.¶
However, as EAP-PSK-256 is intended as a mostly drop-in replacement for EAP-PSK, care must be taken to protect against downgrade attacks if an implementation decides to support both EAP-PSK and EAP-PSK-256 simultaneously.¶
Denial of Service (DoS) resistance has not been a primary design goal for EAP-PSK-256. It is, however, believed that EAP-PSK-256 does not provide any obvious and avoidable venue for such attacks.¶
It is worth noting that the server must perform a cryptographic calculation and maintain state when it engages in an EAP-PSK-256 conversation; specifically, it must generate and store the 16-octet RAND_S. However, this should not lead to resource exhaustion as this state and the associated computation (AES-256) are fairly lightweight.¶
Both the peer and the server must commit to their RAND_S and RAND_P to protect their partners from flooding attacks.¶
It is recommended that EAP-PSK-256 not allow EAP notifications to be interleaved in its dialog to prevent potential DoS attacks. Since EAP notifications are not integrity protected, they can easily be spoofed by an attacker. Such an attacker could force a peer to engage in a discussion that would delay authentication or result in unexpected actions.¶
The implementation of EAP-PSK-256, or the local policy of the peer and server, specifies the maximum number of failed cryptographic checks allowed. For instance, the reception of a bogus MAC_P in the second EAP-PSK-256 message could be treated as a fatal error or discarded to wait for a valid response. This presents a trade-off between allowing multiple forgery attempts and risking a direct DoS if the first error is fatal.¶
For the sake of simplicity and denial-of-service resilience, EAP-PSK-256 does not include any error messages. Consequently, an "invalid" EAP-PSK-256 message is silently discarded. While this may complicate interoperability testing and debugging, it leads to simpler implementations and avoids creating venues for denial-of-service attacks.¶
The PSK MUST be handled as a long-term sensitive secret. Compromise of the PSK allows an attacker to impersonate both the peer and the server. Implementations SHOULD use hardware security modules (HSMs) or secure enclaves where possible and limit the PSK's exposure in memory during the derivation process.¶
The Pre-Shared Key (PSK) SHOULD NOT be a password or any string derived from low-entropy sources. Such sources result in a PSK that is susceptible to brute-force or dictionary attacks, effectively reducing the security of the method to the strength of the password. The PSK MUST be a high-entropy, randomly generated value shared using a reliable and secure out-of-band process. For specific guidance on generating cryptographically strong keys, implementations should refer to [SP800-133].¶
In the context of EAP-PSK-256, the PSK MUST have a security strength of at least 256 bits to match the underlying AES-256 cryptographic primitives and ensure the cryptographic chain of trust is not weakened by the initial keying material.¶
Since RAND_P and RAND_S are used in the "Session Key Derivation" phase, it's essential that they are generated with cryptographic grade random generators. Otherwise, sessions keys (TEK, MSK, EMSK) could be predictable.¶
EAP-PSK-256 does not support fragmentation and reassembly.¶
Indeed, the largest EAP-PSK-256 frame is at most 1015 octets long, because:¶
The maximum length for the peer NAI identity used in EAP-PSK-256 is 966 octets (see Section 3.4). This should not be a limitation in practice (see Section 2.2 of [RFC4282] for more considerations on NAI length).¶
The maximum length for the EXT_Payload field used in EAP-PSK-256 is 960 octets (see Section 3.5 and Section 3.6 ).¶
Per Section 3.1 of [RFC3748], the lower layers over which EAP may be run are assumed to have an EAP MTU of 1020 octets or greater. Since the EAP header is 5 octets long, supporting fragmentation for EAP-PSK-256 is unnecessary.¶
Extensions that require sending a payload larger than 960 octets should provide their own fragmentation and reassembly mechanism.¶
The following security properties are explicitly claimed for EAP-PSK-256:¶
Any other security feature or property not explicitly listed above is not guaranteed.¶
This document is heavily based on the original EAP-PSK specification, [EAP-PSK]. The authors would like to acknowledge the foundational work of Florent Bersani and Hannes Tschofenig, whose design and documentation of the EAP-PSK method made this 256-bit variant possible.¶
This document also uses extracts from templates written by Pekka Savola, Elwyn Davies, and Henrik Levkowetz.¶
Thanks to all of the contributors.¶