Summary

  • On 24 August 2026, the IESG approved draft-ietf-ipsecme-ikev2-pqc-auth-12 as a Proposed Standard. At the 27 August evidence freeze, it remained an active Internet-Draft in the RFC Editor queue, not a numbered RFC.
  • The document specifies how pure-mode ML-DSA and SLH-DSA signatures can use IKEv2's existing Digital Signature method. It does not prove that any gateway selected those algorithms, carried the large authentication messages across its real path, verified AUTH, established an IKE SA or authorized a Child SA.

Two green dashboards, two different tunnels

A migration review opens with two gateways marked “post-quantum ready.” Both have an ML-DSA credential in inventory. Both expose software that recognizes the algorithm. The labels appear identical.

The packet evidence is not. One IKE_AUTH exchange selects a traditional ECDSA signature after an allowed fallback. The other begins to carry a much larger post-quantum authentication message but never completes across the operative path. Neither tunnel was authenticated by ML-DSA, although neither dashboard is technically lying about installed capability.

This is an illustrative control-room test, not a reported product incident. It isolates the operational question created by the IETF news: what exact evidence authorizes the words “post-quantum authenticated”?

The answer cannot be a standards announcement or a configuration screen. It must be the chain from document revision to credential, signaling, selected signature, message delivery, verification and the resulting security associations.

What the IESG approved

The IESG announcement of 24 August says that revision 12 of “Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC” was approved as a Proposed Standard. The IP Security Maintenance and Extensions Working Group produced the document. Its mechanism is deliberately generic: it brings post-quantum signature schemes into the authentication framework already defined for IKEv2 and specifies ML-DSA and SLH-DSA as concrete cases.

The procedural boundary matters. On 27 August, the Datatracker listed the document in the RFC Editor queue, awaiting reference checking and formatting. It was still an active Internet-Draft dated 21 August and expiring on 22 February 2027. The draft may be edited during publication. Calling it an RFC now would erase a real stage in the evidence.

The document also makes no new IANA request. It composes values already in the IKEv2 registries with algorithm identifiers defined elsewhere. IANA already lists Digital Signature as authentication method 14, IKEV2_FRAGMENTATION_SUPPORTED as notification 16430, SIGNATURE_HASH_ALGORITHMS as 16431, SUPPORTED_AUTH_METHODS as 16443 and Identity as hash value 5. Those rows make an interoperable vocabulary visible. They do not report which bytes a gateway sent.

The signature choice lives inside AUTH

IKEv2 separates the first exchange from the authentication exchange. IKE_SA_INIT negotiates cryptographic parameters, carries nonces and performs key exchange. IKE_AUTH transmits identities, proves knowledge of the corresponding secrets and normally negotiates the first Child SA.

RFC 7427 supplies the bridge used by the new work. Its generic Digital Signature method places a DER-encoded AlgorithmIdentifier in the Authentication Data, followed by the signature. The identifier says which signature scheme and parameters actually produced that AUTH value.

The new draft chooses pure-mode ML-DSA and SLH-DSA. These algorithms operate on the raw session-specific signed material rather than on an externally selected pre-hash. Therefore each peer supporting the covered use must advertise Identity hash value 5 in SIGNATURE_HASH_ALGORITHMS; an implementation must not use such a scheme with a peer that did not advertise Identity.

That notification still does not answer the whole question. Identity 5 describes how input reaches the signature scheme. It does not name ML-DSA-44, ML-DSA-65, ML-DSA-87 or a particular SLH-DSA parameter set. The observed AUTH AlgorithmIdentifier supplies the selected algorithm evidence.

An audit that records only “hash 5 supported” has captured a prerequisite, not a result.

Announcing a method is not selecting it

The draft identifies two mechanisms that can help peers choose compatible credentials. A Certificate Request can indicate acceptable certification authorities. RFC 9593's SUPPORTED_AUTH_METHODS can announce an ordered set of authentication methods or signature schemes.

RFC 9593 makes both sending the notification and using its contents optional. That is a useful design boundary. An announcement reduces blind trial and mismatch when a peer has several credential types, but it is not a negotiated commitment. The later AUTH payload, the presented credential, the trust path and the receiving policy decide what was attempted and accepted.

NIST standardization sits one layer earlier still. FIPS 204 defines ML-DSA and FIPS 205 defines SLH-DSA. RFC 9881 and RFC 9909 define identifiers and PKIX encodings used for keys and signatures. None of these documents installs a private key, provisions a certificate chain, configures an IKE policy or proves that two products interoperate.

The operational inventory therefore needs more than an algorithm name. It needs the key identifier, certificate fingerprint, issuing chain, key usage, cryptographic provider and software build bound to the exact connection policy.

Large authentication material turns the path into evidence

Post-quantum signatures make a familiar IKEv2 weakness impossible to hide behind a checkbox: message size. The draft gives concrete examples. An ML-DSA-44 public key is 1,312 bytes and its signature is 2,420 bytes. Even the smallest SLH-DSA signature is about 7,856 bytes. Certificate chains add more.

For that reason, peers implementing this mechanism must support IKEv2 message fragmentation. RFC 7383 advertises support during IKE_SA_INIT and fragments later messages that contain an Encrypted payload. IKE_SA_INIT itself cannot use that fragmentation format.

Support advertisement is not delivery evidence. A gateway may know how to fragment while a firewall, NAT, load balancer or lossy path prevents a complete reassembly. A reliable transport or a sufficiently known path MTU can change whether fragmentation is needed. Retransmissions can conceal intermittent failure in a laboratory and become a production capacity problem at scale.

The useful record is concrete: whether both peers advertised fragmentation support, how many encrypted fragments carried IKE_AUTH, their sizes, whether reassembly completed, how many retransmissions occurred and which final response ended the exchange. “The firmware supports fragmentation” is not the same statement.

A quantum-resistant key exchange is not a quantum-resistant signature

Migration reports often collapse two asymmetric functions into one badge. Key establishment creates shared secret material. Signature authentication proves the peer under a credential and transcript. IKEv2 can improve one without changing the other.

RFC 9370 defines multiple key exchanges and explicitly says its urgent focus is confidentiality; it does not address authentication. RFC 8784 mixes an additional preshared key into the exchange, but it preserves rather than replaces IKEv2's existing authentication checks. A trace can therefore show a post-quantum or hybrid contribution to key establishment while AUTH still uses ECDSA or RSA.

The reverse distinction matters too. A post-quantum signature does not tell an operator which key-exchange groups protected confidentiality. A credible label must state both axes.

AUTH success still is not the final business result

A verified signature authenticates the session-specific signed octets under the accepted credential. It does not automatically authorize every traffic selector, user, subnet or application. IKE_AUTH can establish an IKE SA even if the first Child SA fails. Local policy still decides which protected traffic may exist.

The evidence chain therefore ends after, not at, the signature check:

  1. record the exact IETF document or RFC revision implemented;
  2. bind software, provider, private-key reference and certificate chain to the connection policy;
  3. capture Identity hash and authentication-method announcements in both directions;
  4. record the AUTH AlgorithmIdentifier and credential actually sent;
  5. prove fragment delivery, reassembly and signature verification;
  6. identify the authenticated IKE SA and any fallback decision;
  7. record Child SA selectors and authorization;
  8. confirm protected traffic on the intended path.

That sequence converts “ready” from a product adjective into a falsifiable operating claim.

Sources