Zusammenfassung

  • Am 24. August 2026 billigte die IESG draft-ietf-ipsecme-ikev2-pqc-auth-12 als Proposed Standard. Beim Quellenabschluss am 27. August war der Text weiterhin ein aktiver Internet-Draft in der RFC-Editor-Warteschlange und noch kein nummerierter RFC.
  • Das Dokument beschreibt reine ML-DSA- und SLH-DSA-Signaturen innerhalb der vorhandenen IKEv2-Methode Digital Signature. Es belegt nicht, dass ein Gateway diese Verfahren auswählte, große Authentisierungsnachrichten über den realen Pfad brachte, AUTH prüfte, eine IKE SA aufbaute oder eine Child SA autorisierte.

Gleicher Status, unterschiedliche Verbindung

In einer Migrationsprüfung erscheinen zwei VPN-Gateways mit demselben grünen Vermerk: „postquantenbereit“. Beide führen eine ML-DSA-Berechtigung im Bestand, beide erkennen den Algorithmus. Für das Inventar ist der Zustand gleich.

Die Paketdaten widersprechen. Bei der ersten Verbindung erlaubt die lokale Richtlinie einen Rückfall; im AUTH steht tatsächlich ECDSA. Beim zweiten Gateway entstehen die größeren Postquanten-Nachrichten, doch der operative Pfad liefert keinen vollständig wieder zusammensetzbaren Satz von Fragmenten. Keine der beiden IKE SAs wurde durch ML-DSA authentisiert.

Das Beispiel ist konstruiert und keinem Produkt zugeordnet. Es zeigt die neue Beweisfrage: Wann darf ein Betreiber nicht nur ein Gerät, sondern eine konkrete Verbindung als postquanten-authentisiert bezeichnen?

Beschlossen ist ein Veröffentlichungsweg

Die IESG-Mitteilung vom 24. August billigt Revision 12 von „Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC“ als Proposed Standard. Das Dokument stammt aus der Arbeitsgruppe IP Security Maintenance and Extensions. Es ersetzt IKEv2 nicht, sondern bindet Postquanten-Signaturen in den bereits vorhandenen allgemeinen Signaturrahmen ein.

Der Verfahrensstand gehört zur Nachricht. Am 27. August führte der Datatracker den Text als „RFC Ed Queue“; Referenzprüfung und Formatierung standen noch aus. Der Draft trägt das Datum 21. August und nennt den 22. Februar 2027 als Ablaufdatum. Bis zur Veröffentlichung sind Änderungen möglich. Von einem veröffentlichten RFC zu sprechen, wäre verfrüht.

Der Draft fordert zudem keine neuen IANA-Zuweisungen. Er verbindet bestehende Werte: Digital Signature ist Authentisierungsmethode 14, IKEV2_FRAGMENTATION_SUPPORTED Notify 16430, SIGNATURE_HASH_ALGORITHMS 16431, SUPPORTED_AUTH_METHODS 16443 und Identity Hash 5. Diese Einträge koordinieren Syntax und Bedeutung; sie protokollieren keine Sitzung.

Die gewählte Signatur steht im AUTH

IKE_SA_INIT handelt kryptografische Parameter aus, übermittelt Nonces und führt den Schlüsselaustausch durch. IKE_AUTH transportiert Identitäten und Nachweise und handelt gewöhnlich die erste Child SA aus. Schlüsselerzeugung und Authentisierung liegen nahe beieinander, sind aber nicht austauschbar.

RFC 7427 definiert die allgemeine Methode Digital Signature. In den Authentication Data steht zuerst ein DER-kodierter AlgorithmIdentifier, danach der Signaturwert. Dieser im konkreten AUTH beobachtete Bezeichner weist das tatsächliche Signaturverfahren und dessen Parameter aus.

Der neue Draft verwendet ML-DSA und SLH-DSA im reinen Modus. Die sitzungsspezifischen Signed Octets werden ohne externes Vorhashen an das Verfahren gegeben. Deshalb müssen beide Peers Identity Hash 5 in SIGNATURE_HASH_ALGORITHMS ankündigen. Ein Verfahren, das Identity benötigt, darf gegenüber einem Peer ohne diese Ankündigung nicht eingesetzt werden.

Identity 5 benennt jedoch nicht ML-DSA-44 oder eine SLH-DSA-Variante. Es beschreibt die Eingabebehandlung. Der Wert in beiden Richtungen ist eine Voraussetzung; Auswahl und Annahme folgen aus AlgorithmIdentifier, Zertifikat und Prüfergebnis.

Eine Ankündigung ist keine Auswahl

Der Draft nennt Certificate Request und SUPPORTED_AUTH_METHODS aus RFC 9593 als Hilfen bei der Wahl kompatibler Schlüsseltypen. Die Notify-Nachricht kann eine geordnete Liste unterstützter Methoden oder Signaturschemata übertragen.

Senden und Verwenden sind auf beiden Seiten optional. Die Liste kann Fehlversuche reduzieren, verpflichtet das spätere AUTH aber nicht. Ein Gateway kann ML-DSA ankündigen und nach lokaler Richtlinie ECDSA wählen, eine nicht vertrauenswürdige Kette senden oder bei der Prüfung scheitern.

FIPS 204 standardisiert ML-DSA, FIPS 205 SLH-DSA. RFC 9881 und RFC 9909 definieren Bezeichner, PKIX-Kodierung und Schlüsselverwendung. Diese Grundlagen liefern weder privaten Schlüssel noch Zertifikat, Vertrauensanker, HSM-Leistung oder nachgewiesene Produktinteroperabilität.

Eine belastbare Bestandsaufnahme bindet daher Schlüsselkennung, Zertifikatsfingerabdruck, Ausstellerkette, key usage, Kryptografieanbieter, Software-Build und Verbindungsrichtlinie zusammen.

Die Größe macht den Netzpfad zum Prüfschritt

Der Draft nennt konkrete Größen. Ein öffentlicher ML-DSA-44-Schlüssel umfasst 1.312 Byte, die Signatur 2.420 Byte. Selbst die kleinste SLH-DSA-Signatur liegt bei ungefähr 7.856 Byte. Zertifikatsketten kommen hinzu.

Peers mit diesem Mechanismus müssen deshalb IKEv2-Nachrichtenfragmentierung unterstützen. RFC 7383 lässt IKEV2_FRAGMENTATION_SUPPORTED während IKE_SA_INIT ankündigen und zerlegt spätere Nachrichten mit Encrypted Payload. IKE_SA_INIT selbst kann dieses Format nicht nutzen.

Unterstützung ist noch keine Zustellung. Firewall, NAT, Load Balancer oder verlustbehafteter Pfad können die Wiederzusammensetzung verhindern. Bei zuverlässigem Transport oder bekannter ausreichender PMTU ist Fragmentierung womöglich unnötig. Der Nachweis umfasst daher beide Ankündigungen, Zahl und Größe der verschlüsselten Fragmente, Wiederholungen, Reassemblierung und die abschließende Antwort.

Postquanten-Schlüsselaustausch ist keine Postquanten-Signatur

Die Bezeichnung „postquantensicheres VPN“ vermischt häufig Vertraulichkeit und Authentisierung. Der Schlüsselaustausch erzeugt gemeinsames Geheimnis. Die Signatur bindet einen Peer über Identität, Berechtigung und Sitzungstranskript.

RFC 9370 führt mehrere Schlüsselaustausche ein und erklärt ausdrücklich, dass der dringende Schwerpunkt auf Vertraulichkeit liegt; Authentisierung behandelt er nicht. RFC 8784 mischt einen zusätzlichen vorab vereinbarten Schlüssel ein, ersetzt aber keine vorhandene Authentisierungsprüfung. Eine IKE SA kann also einen Postquanten-Beitrag beim Schlüsselaustausch besitzen und AUTH dennoch mit ECDSA oder RSA signieren.

Umgekehrt sagt eine ML-DSA-Signatur nichts über die verwendeten Schlüsselaustauschgruppen aus. Beide Achsen benötigen eigene Belege.

Nach AUTH folgt weiterhin Autorisierung

Eine gültige Signatur bestätigt die Signed Octets dieser Sitzung unter der akzeptierten Berechtigung. Sie erlaubt nicht automatisch jedes Subnetz, jeden Traffic Selector, Benutzer oder Anwendungszugriff. Eine IKE SA kann sogar bestehen, obwohl die erste Child SA scheitert.

Eine prüfbare Aussage verbindet daher: genaue implementierte Revision; Software und Kryptografieanbieter; Schlüssel und Zertifikatskette; Ankündigungen in beiden Richtungen; tatsächlichen AlgorithmIdentifier; Fragmente, Reassemblierung und Prüfung; authentisierte IKE-SA-Identität samt Rückfall; Child-SA-Richtlinie, Selektoren und geschützten Verkehr. Erst am Ende beschreibt „postquanten-authentisiert“ einen ausgeführten Zustand.

Quellen