]> SIGINFO

France bruno.rohee@siginfo.fr

Ornisec

France emmanuel.konan.contact@gmail.com

Enedis

France michael.le-clerc@enedis.fr

Enedis

France clement.devun@enedis.fr

General Internet Engineering Task Force eap eap-psk eap-psk-256 Pre-shared key authentication 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:

• Quantum resistance: Legacy EAP-PSK uses the symmetric algorithm AES-128, which is theoretically vulnerable to Grover's cryptographic attack. This document specifies a new EAP protocol that uses quantum-resistant symmetric algorithms.
• Regulatory Alignment: EAP-PSK-256 replaces the key generation mechanism used in EAP-PSK with a standardized key derivation mechanism from NIST SP800-38B.
• Enhanced Entropy: Unlike EAP-PSK, which relied solely on Peer randomness (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.

Introduction

Design goals This document specifies a new Extensible Authentication Protocol (EAP) method, designated as EAP-PSK-256. This method is proposed as an evolution of 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 . Moreover the 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:

• The protocol SHOULD preserve the fundamental logic and workflow of .
• The protocol SHOULD maintain all security properties provided by .
• The method MUST provide resistance against Post-Quantum Cryptography (PQC) threats.
• The messages payload size SHOULD NOT exceed that of EAP-PSK.
• The protocol SHOULD minimize memory overhead. The protocol SHOULD operate on constrained devices, requiring no more than a few tens of kilobytes of RAM and only limited code size.

Please contact the authors if you believe that any of these goals cannot be met.

Relationship to EAP-PSK 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 . For the sake of backward compatibility and ease of implementation, EAP-PSK-256 maintains the fundamental structure and message flow of . 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.

Requirements Language 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 and when, and only when, they appear in all capitals, as shown here.

Terminology The following terms and abbreviations are used in this document. For broader definitions of EAP-related terms, please refer to .

Authentication, Authorization, and Accounting (AAA)

Defined in .

Advanced Encryption Standard (AES)

A block cipher specified in .

Authentication Key (AK)

A 32-octet key derived from the PSK that the EAP peer and server use to mutually authenticate.

AKEP2

An authenticated key exchange protocol; please refer to for more details.

Backend Authentication Server

An entity that provides an authentication service to an Authenticator. This server typically executes EAP methods for the Authenticator.

Cipher-based Message Authentication Code (CMAC)

A message authentication code based on a symmetric key block cipher, as specified in .

EAP Authenticator

The end of the EAP link initiating the EAP authentication process.

EAP Peer

The end of the EAP link that responds to the Authenticator.

EAP Server

The entity that terminates the EAP authentication with the peer.

EAX

An Authenticated Encryption with Associated Data (AEAD) mode of operation for block ciphers .

Extended Master Session Key (EMSK)

Additional keying material derived between the EAP peer and server that is exported by the EAP method. EAP-PSK-256 generates a 64-octet EMSK.

Key-Derivation Function (KDF)

A cryptographic function used to derive one or more cryptographically strong keys from a secret source, such as a Pre-Shared Key (PSK). This document utilizes the KDF in Double-Pipeline Iteration Mode as specified in , using CMAC-AES-256 as the underlying Pseudo-Random Function (PRF).

Key-Derivation Key (KDK)

A 32-octet key derived from the PSK used to derive session keys (TEK, MSK, and EMSK).

Master Session Key (MSK)

Keying material derived between the EAP peer and server and exported by the EAP method for use by the lower layer. EAP-PSK-256 generates a 64-octet MSK.

Network Access Identifier (NAI)

The user identity in the form of 'user@realm' as defined in .

Perfect Forward Secrecy (PFS)

The property that the compromise of long-term keys does not compromise past session keys. EAP-PSK-256 does not provide PFS.

Pre-Shared Key (PSK)

A static symmetric key shared between the peer and server. In EAP-PSK-256, the PSK is 32 octets in length.

Pseudorandom function (PRF)

A pseudorandom function (PRF) is the basic building block for constructing a key-derivation function in this Recommendation

Transient EAP Key (TEK)

A 32-octet session key used to protect the EAP conversation using the AES-EAX-256 ciphersuite.

Conventions All numbers presented in this document are considered in network-byte order (big-endian).

KDF-DP

Key Derivation Function in Double-Pipeline Iteration Mode .

||

Concatenation operator.

MAC(K, S)

Denotes the Message Authentication Code of string S under the key K. The algorithm used in this document is CMAC-AES-256 (see ).

[S]

Denotes the concatenation of string S with the MAC of string S calculated as specified by the context. With key K specified by the context: [S] = S || MAC(K, S).

**

denotes integer exponentiation.

[i]_n

Denotes the n-octet binary representation of i.

Protocol Description

Cryptography of EAP-PSK-256 The EAP-PSK-256 :

• Introduces KDF-DP-CMAC-AES-256 for key derivation.
• Replaces AES-128-EAX by AES-256-EAX in EAP-PSK protected channel.

EAP-PSK-256 Overview + 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 | | | +------------+ +--------------+ | | | +------------------------------------------------------------------+ ]]>

Cryptographic Primitives

Advanced Encryption Standard (AES) 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 can reduce the effective security strength of symmetric primitives by half. Consequently, AES-128, the primitive utilized in 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 .

Cipher-based Message Authentication Code (CMAC) 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 .

Key Derivation Function (KDF) EAP-PSK-256 utilizes the KDF in Double-Pipeline Iteration Mode as specified in . 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 . The KDF requires the following parameters:

h:

The length of the output of a single invocation of the PRF in bits. For CMAC-AES-256, h = 128.

r:

The length of the binary representation of the counter i. This specification uses r = 32.

Input:

K_IN, Label, Context, and L.

K_IN 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.

Context (C) 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.

Label The label is an octet string that distinguishes between different purposes for the derived keying material. EAP-PSK-256 defines the following labels:

• "KEY_SET_UP": Used to derive the AK and KDK for the initial key setup.
• "SESSION_KEYS": Used to derive the session keys, including the TEK, MSK, and EMSK.

Output Length (L) L specifies the requested length (in bits) of the derived keying material. Its binary representation, denoted [L]₂ in , is 2 octets long.

Cryptographic Keys

Pre-Shared Key (PSK) 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:

• Authentication Key (AK): Used for mutual authentication.
• Key-Derivation Key (KDK): Used for session key derivation.

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.

Authentication Key (AK) EAP-PSK-256 uses the AK to provide mutual authentication between the EAP peer and the EAP server.

• The AK is a static, long-lived key derived from the PSK (see ).
• The AK is NOT a session key and MUST NOT be used as such.

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.

Key-Derivation Key (KDK) EAP-PSK-256 uses the KDK to derive the session-specific keying material shared by the peer and server.

• The KDK is used to derive the TEK, MSK, and EMSK.
• The KDK is a static, long-lived key derived from the PSK (see ).
• Like the AK, the KDK is NOT a session key.

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.

Transient EAP Key (TEK) 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 ). 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.

Master Session Key (MSK) EAP-PSK-256 derives an MSK using the KDK and the session nonces as specified in . The MSK is 64 octets in length, which complies with the requirements for keying material export defined in . The usage of the MSK is specified in .

Extended Master Session Key (EMSK) EAP-PSK-256 derives an EMSK using the KDK and the session nonces as specified in . The EMSK is 64 octets in length, which complies with . The usage of the EMSK is specified in .

The Key Setup 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 for guidance on secure deletion). The derivation of AK and KDK from the PSK is performed using the KDF specified in with the following inputs:

• K_IN: The Pre-Shared Key (PSK).
• Label (L): The octet string "KEY_SET_UP".
• Context (C): C = "EAP-PSK-256" || 0x00 || NAI_P. Where NAI_P designates the network access identifier of the peer.
• Output Length (L): 512 bits.

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.

Derivation of AK and KDK from the PSK + | +-----------+ | "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

Authentication process The Authenticated Key Exchange (AKE) for EAP-PSK-256 is based on the AKEP2 protocol as described in . The message sequence is defined as follows:

AKEP2 Based Authentication Protocol Workflow | | | | [ID_S || RAND_P] | |<-------------------------------------------+ | | ]]>

• RAND_P and RAND_S MUST be 16-octet random numbers (nonces) chosen by the peer and server, respectively.
• ID_P and ID_S represent the peer and server identities.
• The notation "[...]" denotes a Message Authentication Code (MAC). In this protocol, the MAC MUST be computed using CMAC-AES-256 with the AK as the key, producing a 16-octet tag.

This adaptation of AKEP2 allows both parties to learn each other's identities. Note that this is a simplified version of the exchange.

Session Key Derivation Following successful mutual authentication, session keys are derived using the KDF in Double-Pipeline Iteration Mode . The derivation uses the KDK to produce 1280 bits of keying material.

Derivation of Session Keys from KDK + | +-----------+ | "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:

• K_IN: The 32-octet Key Derivation Key (KDK).
• Label: The octet string "SESSION_KEYS".
• Context (C): The concatenation of the protocol identifier, a separator, the identities, and the session nonces: C = "EAP-PSK-256" || 0x00 || NAI_P || NAI_S || RAND_P || RAND_S. Where NAI_P designates the network access identifier of the peer and NAI_S the one of the server.
• Output Length (L): 1280 bits.

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 , which only utilized RAND_P for session key derivation (see Figure 7 of ). The 160-octet (1280-bit) output of the KDF is partitioned into three distinct session keys:

TEK (Token Encryption Key):

Octets 0 to 31 (32 octets). Used for protecting the EAP-Payload in subsequent messages.

MSK (Master Session Key):

Octets 32 to 95 (64 octets). Exported to the lower layer authenticator (e.g., an Access Point) for data link protection.

EMSK (Extended Master Session Key):

Octets 96 to 159 (64 octets). Reserved for future EAP-method-specific extensions.

The Protected Channel 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.

The Protected Channel

The protected channel provides the following security properties:

• Provides replay protection via a monotonic sequence number.
• Encrypts and authenticates a Plain Text Payload to produce a Cipher Text Payload. The Plain Text Payload MUST NOT exceed 960 octets.
• Authenticates the Header (H), which is transmitted in the clear.

EAX is instantiated with AES-256 as the underlying block cipher, keyed with the 32-octet TEK.

Nonce N 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.

Header H 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 Section 7.5.

Payload and Tag 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.

Rationale for EAX 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:

Backward Compatibility:

Maintaining the same mode of operation as the original EAP-PSK specification simplifies the transition to the 256-bit variant for existing implementations.

Primitive Reuse:

EAX is built upon CMAC. Since CMAC is already required for the EAP-PSK-256 KDF and mutual authentication, using EAX allows implementers to reuse the same cryptographic code, reducing the overall footprint of the method.

Simplicity and Robustness:

The design of EAX is straightforward to implement securely and it remains a "misuse-resistant" alternative to simpler modes.

Provable Security:

The mode is backed by a formal security proof and provides strong security guarantees for both privacy and authenticity.

IPR-Free:

Like the underlying AES and CMAC primitives, EAX is free of Intellectual Property Rights claims.

EAP-PSK-256 Messages 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.

Message Flows EAP-PSK-256 may consist of two different types of message flows:

The "standard authentication", which is:

• Mandatory to implement.
• Fully specified in this document.
• The simpler type of message flow, which is expected to be used most frequently.

The "extended authentication", which is:

• Optional to implement (i.e., there are no mandatory extensions).
• Partly specified in this document since it depends on extensions and none are currently specified, let alone in this document.
• The type of message flow that should be used when extensions of EAP-PSK-256 are needed by more sophisticated usage scenarios and are available.

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 EAP-PSK-256 standard authentication is comprised of four messages, i.e., two round-trips; see .

EAP-PSK-256 Standard Authentication | | | | 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:
  • Send a 16-octet random challenge (RAND_S).
  • State its identity (ID_S).
• The second message is sent by the peer to the server to:
  • Send another 16-octet random challenge (RAND_P).
  • State its identity (ID_P).
  • Authenticate to the server by proving that it is able to compute a particular MAC (MAC_P), which is a function of the two challenges and AK: MAC_P = CMAC-AES-256(AK, ID_P||ID_S||RAND_S||RAND_P).
• The third message is sent by the server to the peer to:
  • Authenticate to the peer by proving that it is able to compute another MAC (MAC_S), which is a function of the peer's challenge and AK: MAC_S = CMAC-AES-256(AK, ID_S||RAND_P).
  • Set up the protected channel (P_CHANNEL_S_0) to confirm that it has derived session keys (at least the TEK) and give a protected result indication of the authentication.
• 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 , 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 . 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 . 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.

EAP-PSK-256 Extended Authentication 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). presents the message sequence for EAP-PSK-256 extended authentication.

EAP-PSK-256 Extended Authentication | | | | 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 . 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 , 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 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 . 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 . 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 . 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.

Message Format 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 , , , and .

EAP-PSK-256 First Message The first EAP-PSK-256 message is sent by the server to the peer. It has the format presented in .

EAP-PSK-256 First Message

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 ).

EAP-PSK-256 Second Message The second EAP-PSK-256 message is sent by the peer to the server. It has the format presented in .

EAP-PSK-256 Second Message

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 , 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 ).

The Flags field format is presented in .

EAP-PSK-256 Third Message The third EAP-PSK-256 message is sent by the server to the peer. It has the format presented in .

EAP-PSK-256 Third Message

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.

The PCHANNEL Field with E=0

If there is an extension, the PCHANNEL field includes a variable length EXT field.

The PCHANNEL Field with E=1

The EXT field format is presented in .

The EXT Field

EAP-PSK-256 Fourth Message The fourth EAP-PSK-256 message is sent by the peer to the server. It has the format presented in .

EAP-PSK-256 Fourth Message

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 . The PCHANNEL field has the following structure, which was already described in . If there is no extension, i.e., if the authentication is standard, the PCHANNEL field consists of:

• A 4-octet Nonce N (see ).
• A 16-octet Tag (see ).
• 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 ). If there is no extension, PCHANNEL has the format presented in . If there is an extension, i.e., if the authentication is extended, the PCHANNEL field consists of:

• A 4-octet Nonce N (see ).
• A 16-octet Tag (see ).
• 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 ). If there is an extension, PCHANNEL has the format presented in . This EXT field is split into two subfields:

• The EXT_Type subfield, which indicates the type of the extension.
• The EXT_Payload subfield, which consists of the payload of the extension. The EXT_Payload length is derived from the EAP Length field. EXT_Payload must have a bit length that is a multiple of 8 bits and must not exceed 960 octets.

The format of the EXT field is presented in .

EAP-PSK-256 message flag field The Flags field has the format presented in .

EAP-PSK-256 Flags Field

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 .
  • T=1 for the second EAP-PSK-256 message presented in .
  • T=2 for the third EAP-PSK-256 message presented in .
  • T=3 for the fourth EAP-PSK-256 message presented in 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 ) 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.

Rules of Operation for the EAP-PSK-256 Protected Channel In this section, the rules of operation of the EAP-PSK-256 protected channel are presented:

• How protected result indications are implemented.
• How an extended authentication works in detail.

Protected Result Indications 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:

• 01 to mean CONT
• 10 to mean DONE_SUCCESS
• 11 to mean DONE_FAILURE

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.

CONT 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 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 ).
• 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 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.

Extended Authentication 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.

IANA Considerations TO DO: This memo includes no request to IANA.

Security Considerations

Mutual Authentication 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.

Protected Result Indications EAP-PSK-256 provides protected result indications via its 2-bit R flag (see ). This 2-bit R flag is protected because it is encrypted and integrity protected by the protected channel mechanism (see ). 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:

• A server sends a DONE_SUCCESS to a peer.
• The peer replies with a DONE_SUCCESS.

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 ) 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.

Integrity of the Protected Channel 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:

• The protocol integrity-protects the EAP header, which contains the Request/Response indication. This prevents an attacker from reflecting an unauthenticated message back to its sender.
• The protocol uses two distinct nonce spaces: the EAP server only accepts messages containing odd-valued nonces, whereas the EAP peer only accepts messages containing even-valued nonces. This strict separation ensures that a message originating from one side cannot be reflected back in a valid form to the other side.

Exhaustive Search and Dictionary Attacks 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.

Resistance to Quantum Search (Grover's Algorithm) The migration to 256-bit keys specifically addresses the theroritical threat posed by Grover's algorithm (see ). 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 . The use of KDF-DP () 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 (). 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 (). 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 . 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.

Downgrade Attack Protection 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 Resistance 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.

Protection of Shared Keys 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.

PSK Generation 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 . 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.

Random generation 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.

Fragmentation 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 ). This should not be a limitation in practice (see Section 2.2 of for more considerations on NAI length).
• The maximum length for the EXT_Payload field used in EAP-PSK-256 is 960 octets (see and ).

Per Section 3.1 of , 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.

Security Claims The following security properties are explicitly claimed for EAP-PSK-256:

• Mutual Authentication: Both entities provide cryptographic proof of their identity by demonstrating knowledge of the PSK through the modified AKEP2 exchange.
• Secure Session Key Derivation: All session keys are generated using a compliant KDF, ensuring that the resulting keys possess 256 bits of cryptographic strength.
• Integrity and Authenticity: The protocol ensures that any modification to messages either during authentication or within the protected channel is detected via 16-octet MAC tags.
• Dictionary Attack Resistance: While the protocol is computationally resistant to exhaustive search due to its 256-bit primitives, security remains dependent on the initial PSK entropy.
• Security Against Theoretical Grover Attack: The use of 256-bit keys maintains a 128-bit security margin against quantum search algorithms.
• Replay Protection: Re-use of captured packets is prevented through the use of session nonces and a monotonically increasing sequence number.
• Key Separation and Session Independence: Cryptographic separation ensures that the compromise of one session or subkey does not reveal the long-term PSK or keys from other sessions.

Any other security feature or property not explicitly listed above is not guaranteed.

Normative References Internet Engineering Task Force Internet Engineering Task Force Informative References In order to provide roaming services, it is necessary to have a standard method for identifying users and the realm for which they are intended. This document defines the syntax for the Network Access Identifier (NAI), the standard identifier used in the Extensible Authentication Protocol (EAP) and RADIUS. This document describes a framework for authorization within the Authentication, Authorization, and Accounting (AAA) architecture. It defines a set of terminology and a set of sequences of authorization events. In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network access authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802.11 Wireless LANs without requiring IP. This document defines EAP-PSK, an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). It provides a protected communication channel when the mutual authentication is successful. Dr. Dustin Moody (National Institute of Standards and Technology, Gaithersburg, MD) Grover L.K., Proceedings, 28th Annual ACM Symposium on the Theory of Computing, p. 212 Dworkin MJ (National Institute of Standards and Technology, Gaithersburg, MD), NIST SP 800-38b-upd1 National Institute of Standards and Technology National Institute of Standards and Technology Media sanitization refers to a process that renders access to target data on the media infeasible for a given level of effort. This guide will assist organizations and system owners in setting up a media sanitization program with proper and applicable techniques and controls for sanitization and disposal based on the sensitivity of their information. Elaine Barker (NIST), Allen Roginsky (NIST), Richard Davis (NSA) Chen L (National Institute of Standards and Technology, Gaithersburg, MD), NIST SP 800-108r1-upd1 National Institute of Standards and Technology (Department of Commerce, Washington, D.C.), FIPS PUB-197-upd1

Acknowledgements This document is heavily based on the original EAP-PSK specification, . 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.

Contributors Thanks to all of the contributors. Trialog

France vincent.maury@trialog.com