Summary

  • A 2 November individual Internet-Draft proposes EAP-PQPAKE, a hybrid post-quantum password method for EAP. It is experimental work, with no formal IETF standards standing.
  • The proposal protects the authentication exchange and exported keys, but its unencrypted Start exposes the peer and server identities unless the whole method runs inside a protected tunnel. An anonymous outer EAP name alone will not hide them.
  • The server stores a full verifier. If that tuple is compromised, the draft says an attacker can guess passwords offline and impersonate the server to the peer; the affected credentials must be reprovisioned.

A strong lock with a nameplate on the front

The first identity field arrives before the cryptographic shelter. That is the awkward sentence in the new EAP-PQPAKE draft. Its authors propose a hybrid password exchange meant to keep a recorded session useful to neither a passive eavesdropper today nor a future quantum attacker under the stated assumptions. Yet the Start exchange is clear. A watcher can read the peer and server identities there. Giving the outer EAP exchange an anonymous identity does not cover the names repeated inside this method.

The distinction has an operational owner. A network operator choosing this method must decide whether the identity itself needs protection, then place the method in a protected tunnel if it does. The draft makes that boundary explicit. It does not supply an invisible privacy layer merely because the session keys are stronger.

The password also changes hands in a specific way. At registration, the server receives (v, pk, kem_blind) plus salt, configuration and registration identities. It must protect that material, and must not store the password-derived seed or the related KEM secret key. The verifier is not a harmless hash in a drawer. The draft says theft of the complete tuple enables offline password guessing and server impersonation to the peer. Theft alone does not give the attacker client impersonation without further secrets. Affected credentials need reprovisioning.

Online guessing has its own gate: the server must rate-limit failed authentications or use equivalent controls. Memory-hard stretching in the recommended configuration slows a stolen-verifier attack; it cannot meter live attempts against the login service. Those are two different budgets and two different failure logs.

This is an individual draft, intended as Experimental, and the underlying CPaceOQUAKE+ algorithm is itself still a draft. It reports no deployment, breach or measured adoption. The immediate news is a design choice written in public: future-proofing the key does not automatically protect the person named at the start or the credential material left on the server.

Original sources