EAP-PSK-256: A Quantum resistant version of EAP-PSK
draft-eap-psk-256-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Bruno ROHEE , Emmanuel KONAN , Michael Le Clerc , Clément Devun | ||
| Last updated | 2026-06-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| On agenda | emu at IETF-126 | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-eap-psk-256-01
Internet Engineering Task Force B. ROHEE
Internet-Draft SIGINFO
Intended status: Experimental E. KONAN
Expires: 24 December 2026 Ornisec
M. LE CLERC
C. DEVUN
Enedis
22 June 2026
EAP-PSK-256: A Quantum resistant version of EAP-PSK
draft-eap-psk-256-01
Abstract
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-108.
* 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.
Status of This Memo
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/.
ROHEE, et al. Expires 24 December 2026 [Page 1]
Internet-Draft EAP-PSK-256 June 2026
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 24 December 2026.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Design goals . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Relationship to EAP-PSK . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Description . . . . . . . . . . . . . . . . . . . . 7
2.1. Cryptography of EAP-PSK-256 . . . . . . . . . . . . . . . 7
2.1.1. Cryptographic Primitives . . . . . . . . . . . . . . 8
2.1.2. Cryptographic Keys . . . . . . . . . . . . . . . . . 10
2.2. The Key Setup . . . . . . . . . . . . . . . . . . . . . . 12
2.3. The Authenticated Key Exchange . . . . . . . . . . . . . 13
2.3.1. Authentication process . . . . . . . . . . . . . . . 13
2.3.2. Session Key Derivation . . . . . . . . . . . . . . . 14
2.4. The Protected Channel . . . . . . . . . . . . . . . . . . 15
2.4.1. Nonce N . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2. Header H . . . . . . . . . . . . . . . . . . . . . . 17
2.4.3. Payload and Tag . . . . . . . . . . . . . . . . . . . 17
2.4.4. Rationale for EAX . . . . . . . . . . . . . . . . . . 17
3. EAP-PSK-256 Messages . . . . . . . . . . . . . . . . . . . . 18
3.1. Message Flows . . . . . . . . . . . . . . . . . . . . . . 18
3.1.1. EAP-PSK-256 Standard Authentication . . . . . . . . . 19
3.1.2. EAP-PSK-256 Extended Authentication . . . . . . . . . 21
3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 23
3.3. EAP-PSK-256 First Message . . . . . . . . . . . . . . . . 23
ROHEE, et al. Expires 24 December 2026 [Page 2]
Internet-Draft EAP-PSK-256 June 2026
3.4. EAP-PSK-256 Second Message . . . . . . . . . . . . . . . 24
3.5. EAP-PSK-256 Third Message . . . . . . . . . . . . . . . . 26
3.6. EAP-PSK-256 Fourth Message . . . . . . . . . . . . . . . 28
3.7. EAP-PSK-256 message flag field . . . . . . . . . . . . . 30
4. Rules of Operation for the EAP-PSK-256 Protected Channel . . 31
4.1. Protected Result Indications . . . . . . . . . . . . . . 31
4.1.1. CONT . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.2. DONE_SUCCESS . . . . . . . . . . . . . . . . . . . . 33
4.1.3. DONE_FAILURE . . . . . . . . . . . . . . . . . . . . 33
4.2. Extended Authentication . . . . . . . . . . . . . . . . . 33
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
6. Security Considerations . . . . . . . . . . . . . . . . . . . 35
6.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 35
6.2. Protected Result Indications . . . . . . . . . . . . . . 35
6.3. Integrity of the Protected Channel . . . . . . . . . . . 36
6.4. Session Independence and Replay Protection . . . . . . . 36
6.5. Reflection Attacks . . . . . . . . . . . . . . . . . . . 37
6.6. Exhaustive Search and Dictionary Attacks . . . . . . . . 38
6.7. Resistance to Quantum Search (Grover's Algorithm) . . . . 38
6.8. Key Derivation and Security . . . . . . . . . . . . . . . 38
6.9. Downgrade Attack Protection . . . . . . . . . . . . . . . 39
6.10. Denial-of-Service Resistance . . . . . . . . . . . . . . 39
6.11. Protection of Shared Keys . . . . . . . . . . . . . . . . 40
6.12. PSK Generation . . . . . . . . . . . . . . . . . . . . . 40
6.13. Random generation . . . . . . . . . . . . . . . . . . . . 41
6.14. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 41
7. Security Claims . . . . . . . . . . . . . . . . . . . . . . . 41
8. Normative References . . . . . . . . . . . . . . . . . . . . 42
9. Informative References . . . . . . . . . . . . . . . . . . . 42
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction
1.1. 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 [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.
ROHEE, et al. Expires 24 December 2026 [Page 3]
Internet-Draft EAP-PSK-256 June 2026
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
[EAP-PSK].
* The protocol SHOULD maintain all security properties provided by
[EAP-PSK].
* 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.
1.2. 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 [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.
1.3. 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
[RFC2119] and [RFC8174] when, and only when, they appear in all
capitals, as shown here.
ROHEE, et al. Expires 24 December 2026 [Page 4]
Internet-Draft EAP-PSK-256 June 2026
1.4. Terminology
The following terms and abbreviations are used in this document. For
broader definitions of EAP-related terms, please refer to [RFC3748].
Authentication, Authorization, and Accounting (AAA)
Defined in [RFC2904].
Advanced Encryption Standard (AES)
A block cipher specified in [FIPS-197].
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 [AKEP2]
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 [SP800-38B].
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 [EAX].
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.
ROHEE, et al. Expires 24 December 2026 [Page 5]
Internet-Draft EAP-PSK-256 June 2026
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 [SP800-108], 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
[RFC7542] .
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.
1.5. 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
[SP800-108] .
|| Concatenation operator.
MAC(K, S) Denotes the Message Authentication Code of string S under
ROHEE, et al. Expires 24 December 2026 [Page 6]
Internet-Draft EAP-PSK-256 June 2026
the key K. The algorithm used in this document is CMAC-AES-256
(see Section 2.1.1.2).
[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.
2. Protocol Description
2.1. 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 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| |
| +-----------+ +==========+============+ +----------+ |
| | |
| +----------------------+----------------------+ |
ROHEE, et al. Expires 24 December 2026 [Page 7]
Internet-Draft EAP-PSK-256 June 2026
| 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 | |
| +------------+ +--------------+ |
| |
+------------------------------------------------------------------+
Figure 1: EAP-PSK-256 Overview
2.1.1. Cryptographic Primitives
2.1.1.1. 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 [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].
ROHEE, et al. Expires 24 December 2026 [Page 8]
Internet-Draft EAP-PSK-256 June 2026
2.1.1.2. 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 [SP800-38B].
2.1.1.3. Key Derivation Function (KDF)
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:
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.
2.1.1.3.1. 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.
2.1.1.3.2. 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.
2.1.1.3.3. 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.
ROHEE, et al. Expires 24 December 2026 [Page 9]
Internet-Draft EAP-PSK-256 June 2026
2.1.1.3.4. Output Length (L)
L specifies the requested length (in bits) of the derived keying
material. Its binary representation, is 2 octets long.
2.1.2. Cryptographic Keys
2.1.2.1. 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.
2.1.2.2. 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
Section 2.2).
* 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.
ROHEE, et al. Expires 24 December 2026 [Page 10]
Internet-Draft EAP-PSK-256 June 2026
2.1.2.3. 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
Section 2.2).
* 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.
2.1.2.4. 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 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.
2.1.2.5. Master Session Key (MSK)
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].
2.1.2.6. Extended Master Session Key (EMSK)
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].
ROHEE, et al. Expires 24 December 2026 [Page 11]
Internet-Draft EAP-PSK-256 June 2026
2.2. 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 [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:
* *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.
ROHEE, et al. Expires 24 December 2026 [Page 12]
Internet-Draft EAP-PSK-256 June 2026
+---------------------------+
| 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) |
+---------------------------+ +---------------------------+
Figure 2: Derivation of AK and KDK from the PSK
2.3. The Authenticated Key Exchange
2.3.1. Authentication process
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] |
|<-------------------------------------------+
| |
Figure 3: AKEP2 Based Authentication Protocol Workflow
ROHEE, et al. Expires 24 December 2026 [Page 13]
Internet-Draft EAP-PSK-256 June 2026
* 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.
2.3.2. Session Key Derivation
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) |
+------------+ +------------+ +------------+
Figure 4: Derivation of Session Keys from KDK
The KDF parameters are defined as follows:
* *K_IN:* The 32-octet Key Derivation Key (KDK).
* *Label:* The octet string "SESSION_KEYS".
ROHEE, et al. Expires 24 December 2026 [Page 14]
Internet-Draft EAP-PSK-256 June 2026
* *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 [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:
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.
2.4. 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.
ROHEE, et al. Expires 24 December 2026 [Page 15]
Internet-Draft EAP-PSK-256 June 2026
+----------+ +-----------+ +------------+ +------------+
| 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) |
+------------+ +------------+
Figure 5: 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.
2.4.1. 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.
ROHEE, et al. Expires 24 December 2026 [Page 16]
Internet-Draft EAP-PSK-256 June 2026
2.4.2. 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 [RFC3748] Section 7.5.
2.4.3. 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.
2.4.4. 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.
ROHEE, et al. Expires 24 December 2026 [Page 17]
Internet-Draft EAP-PSK-256 June 2026
3. 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.
3.1. 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.
ROHEE, et al. Expires 24 December 2026 [Page 18]
Internet-Draft EAP-PSK-256 June 2026
3.1.1. EAP-PSK-256 Standard Authentication
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 |
+--------------------------------------------------------->|
| |
Figure 6: EAP-PSK-256 Standard Authentication
* 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.
ROHEE, et al. Expires 24 December 2026 [Page 19]
Internet-Draft EAP-PSK-256 June 2026
* 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.
ROHEE, et al. Expires 24 December 2026 [Page 20]
Internet-Draft EAP-PSK-256 June 2026
3.1.2. 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).
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) |
+--------------------------------------------------------->|
| |
Figure 7: EAP-PSK-256 Extended Authentication
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:
ROHEE, et al. Expires 24 December 2026 [Page 21]
Internet-Draft EAP-PSK-256 June 2026
* 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.
ROHEE, et al. Expires 24 December 2026 [Page 22]
Internet-Draft EAP-PSK-256 June 2026
* 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.
3.2. 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 Figure 8, Figure 9, Figure 10, and Figure 14.
3.3. 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 Figure 8.
ROHEE, et al. Expires 24 December 2026 [Page 23]
Internet-Draft EAP-PSK-256 June 2026
|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 :
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: 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 Section 6.14 ).
3.4. 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 Figure 9.
ROHEE, et al. Expires 24 December 2026 [Page 24]
Internet-Draft EAP-PSK-256 June 2026
|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 :
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: 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.
ROHEE, et al. Expires 24 December 2026 [Page 25]
Internet-Draft EAP-PSK-256 June 2026
* 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 Flags field format is presented in Figure 15.
3.5. 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 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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: EAP-PSK-256 Third Message
It consists of:
* A 1-octet Flags field.
ROHEE, et al. Expires 24 December 2026 [Page 26]
Internet-Draft EAP-PSK-256 June 2026
* 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|
+-+-+-+-+-+-+-+-+
Figure 11: The PCHANNEL Field with E=0
If there is an extension, the PCHANNEL field includes a variable
length EXT field.
ROHEE, et al. Expires 24 December 2026 [Page 27]
Internet-Draft EAP-PSK-256 June 2026
|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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: The PCHANNEL Field with E=1
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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: The EXT Field
3.6. 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 Figure 14.
ROHEE, et al. Expires 24 December 2026 [Page 28]
Internet-Draft EAP-PSK-256 June 2026
|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 :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: 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 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.
ROHEE, et al. Expires 24 December 2026 [Page 29]
Internet-Draft EAP-PSK-256 June 2026
* 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 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 Figure 13.
3.7. EAP-PSK-256 message flag field
The Flags field has the format presented in Figure 15.
|0 |
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
| T | Reserved |
+-+-+-+-+-+-+-+-+
ROHEE, et al. Expires 24 December 2026 [Page 30]
Internet-Draft EAP-PSK-256 June 2026
Figure 15: 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 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.
4. 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.
4.1. 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.
ROHEE, et al. Expires 24 December 2026 [Page 31]
Internet-Draft EAP-PSK-256 June 2026
* 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.
4.1.1. 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.
ROHEE, et al. Expires 24 December 2026 [Page 32]
Internet-Draft EAP-PSK-256 June 2026
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.
4.1.2. 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 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.
4.1.3. 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.
4.2. Extended Authentication
An extended authentication can only be started by the server.
ROHEE, et al. Expires 24 December 2026 [Page 33]
Internet-Draft EAP-PSK-256 June 2026
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.
ROHEE, et al. Expires 24 December 2026 [Page 34]
Internet-Draft EAP-PSK-256 June 2026
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.
5. IANA Considerations
TO DO: This memo includes no request to IANA.
6. Security Considerations
6.1. 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.
6.2. Protected Result Indications
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.
ROHEE, et al. Expires 24 December 2026 [Page 35]
Internet-Draft EAP-PSK-256 June 2026
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 [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.
6.3. 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.
6.4. Session Independence and Replay Protection
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.
ROHEE, et al. Expires 24 December 2026 [Page 36]
Internet-Draft EAP-PSK-256 June 2026
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.
6.5. Reflection Attacks
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.
ROHEE, et al. Expires 24 December 2026 [Page 37]
Internet-Draft EAP-PSK-256 June 2026
6.6. 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.
6.7. Resistance to Quantum Search (Grover's Algorithm)
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.
6.8. Key Derivation and Security
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.
ROHEE, et al. Expires 24 December 2026 [Page 38]
Internet-Draft EAP-PSK-256 June 2026
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.
6.9. 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.
6.10. 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.
ROHEE, et al. Expires 24 December 2026 [Page 39]
Internet-Draft EAP-PSK-256 June 2026
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.
6.11. 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.
6.12. 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
ROHEE, et al. Expires 24 December 2026 [Page 40]
Internet-Draft EAP-PSK-256 June 2026
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.
6.13. 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.
6.14. 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 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.
7. 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.
ROHEE, et al. Expires 24 December 2026 [Page 41]
Internet-Draft EAP-PSK-256 June 2026
* *Secure Session Key Derivation:* All session keys are generated
using a [SP800-108] 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*.
8. Normative References
[RFC2119] Internet Engineering Task Force, "Key words for use in
RFCs to Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Internet Engineering Task Force, "Ambiguity of Uppercase
vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May
2017, <https://www.rfc-editor.org/info/rfc8174>.
9. Informative References
[RFC7542] Deokattey, S. and A. DeKok, "The Network Access
Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Steenbakkers, M.,
and S. Hansen, "AAA Authorization Framework", RFC 2904,
DOI 10.17487/RFC2904, August 2000,
<https://www.rfc-editor.org/info/rfc2904>.
ROHEE, et al. Expires 24 December 2026 [Page 42]
Internet-Draft EAP-PSK-256 June 2026
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282,
DOI 10.17487/RFC4282, December 2005,
<https://www.rfc-editor.org/info/rfc4282>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, STD 62, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.
[EAP-PSK] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
Pre-Shared Key Extensible Authentication Protocol (EAP)
Method", RFC 4764, DOI 10.17487/RFC4764, January 2007,
<https://www.rfc-editor.org/info/rfc4764>.
[PQC-CRIT] Dr. Dustin Moody (National Institute of Standards and
Technology, Gaithersburg, MD), "Post-Quantum Cryptography
PQC - Security (Evaluation Criteria)", 11 December 2025,
<https://csrc.nist.gov/projects/post-quantum-cryptography/
post-quantum-cryptography-standardization/evaluation-
criteria/security-(evaluation-criteria)>.
[GROV96] Grover L.K., Proceedings, 28th Annual ACM Symposium on the
Theory of Computing, p. 212, "A fast quantum mechanical
algorithm for database search", May 1996,
<https://dl.acm.org/doi/10.1145/237814.237866>.
[SP800-38B]
Dworkin MJ (National Institute of Standards and
Technology, Gaithersburg, MD), NIST SP 800-38b-upd1,
"Recommendation for Block Cipher Modes of Operation: the
CMAC Mode for Authentication",
DOI https://doi.org/10.6028/NIST.SP.800-38B, 6 October
2016, <https://csrc.nist.gov/pubs/sp/800/38/b/upd1/final>.
[NIST_SP800-88r2]
Chandramouli, R. and E. Hibbard, "Guidelines for Media
Sanitization", NIST Special Publication 800-88 Revision 2,
DOI 10.6028/NIST.SP.800-88r2, September 2025,
<https://doi.org/10.6028/NIST.SP.800-88r2>.
[SP800-133]
Elaine Barker (NIST), Allen Roginsky (NIST), Richard Davis
(NSA), "Recommendation for Cryptographic Key Generation",
NIST Special Publication 800-133 Revision 2,
DOI 10.6028/NIST.SP.800-133r2, June 2020,
<https://csrc.nist.gov/publications/detail/sp/800-133/rev-
2/final>.
ROHEE, et al. Expires 24 December 2026 [Page 43]
Internet-Draft EAP-PSK-256 June 2026
[SP800-108]
Chen L (National Institute of Standards and Technology,
Gaithersburg, MD), NIST SP 800-108r1-upd1, "Recommendation
for Key Derivation Using Pseudorandom Functions",
DOI https://doi.org/10.6028/NIST.SP.800-108r1-upd1, 2
February 2024,
<https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final>.
[FIPS-197] National Institute of Standards and Technology (Department
of Commerce, Washington, D.C.), FIPS PUB-197-upd1,
"Advanced Encryption Standard (AES)",
DOI https://doi.org/10.6028/NIST.FIPS.197-upd1, 9 May
2023, <https://csrc.nist.gov/pubs/fips/197/final>.
[AKEP2] Bellare, M. and P. Rogaway, "Entity Authentication and Key
Distribution", CRYPTO 93, Springer-Verlag LNCS 773, 1994,
<https://link.springer.com/content/
pdf/10.1007/3-540-48329-2_21.pdf>.
[EAX] Bellare, M., Rogaway, P., and D. Wagner, "The EAX Mode of
Operation", FSE 2004, Springer-Verlag LNCS 3017, 2004,
<https://link.springer.com/
chapter/10.1007/978-3-540-25937-4_2>.
[HalpernMoses1990]
Halpern, J. and Y. Moses, "Knowledge and Common Knowledge
in a Distributed Environment", Journal of the ACM 37(3),
1990, <https://dl.acm.org/doi/10.1145/79147.79161>.
Acknowledgements
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.
Contributors
Thanks to all of the contributors.
Vincent Maury
Trialog
France
Email: vincent.maury@trialog.com
ROHEE, et al. Expires 24 December 2026 [Page 44]
Internet-Draft EAP-PSK-256 June 2026
Authors' Addresses
Bruno ROHEE
SIGINFO
France
Email: bruno.rohee@siginfo.fr
Emmanuel KONAN
Ornisec
France
Email: emmanuel.konan.contact@gmail.com
Michael Le Clerc
Enedis
France
Email: michael.le-clerc@enedis.fr
Clement DEVUN
Enedis
France
Email: clement.devun@enedis.fr
ROHEE, et al. Expires 24 December 2026 [Page 45]