Zusammenfassung

  • RFC 9867 ermöglicht das Einmischen eines PPK über IKE_INTERMEDIATE und CREATE_CHILD_SA, auch mit einem frischen PPK beim Erstellen oder Rekeying einer Child SA oder IKE SA.
  • Eine CREATE_CHILD_SA-Antwort kann die PPK-Identität auslassen und trotzdem nach normalem IKEv2 eine SA erzeugen. Widerspricht dieser Rückfall der zwingenden Policy des Initiators, darf er die neue SA sofort löschen.
  • Ein Beleg pro SA sollte Auswahl, Bestätigung, Autorisierung, Erstellung, Annahme, Nutzung und Löschung trennen. Das ist Daniel Kades redaktioneller Vorschlag, keine Vorgabe von RFC oder IETF.

„SA erstellt“ sieht wie ein vollständiges Ergebnis aus. Der Peer antwortete, Schlüsselmaterial wurde abgeleitet, Kennungen erschienen in der Zustandstabelle, und die Automatisierung kann einen Erfolg zählen. Später kann derselbe Datensatz in einem Migrationsbericht als Nachweis für postquantenfeste Verstärkung dienen.

RFC 9867 zeigt die Lücke. Die SA kann entstehen, obwohl der Responder die Erweiterung nicht unterstützt, nicht dafür konfiguriert ist, keine angebotene Identität kennt oder unter der scheinbar gleichen Identität einen anderen PPK-Wert führt. Ist PPK optional, ist das Fortsetzen vorgesehen. Protokollerfolg und Schutzbeleg fallen auseinander.

Eine IKE-Beziehung enthält mehrere Schlüsselstammbäume

IKEv2 erzeugt keinen einzigen unveränderlichen Tunnel. Es etabliert eine IKE SA, authentisiert die Peers, erzeugt Child SAs und kann beide Arten neu schlüsseln. Die Aussage „der Tunnel nutzt einen PPK“ verschweigt daher die entscheidenden Angaben: welche SA, welcher Austausch und welche Ableitung.

RFC 8784 definierte einen ersten Weg, einen Preshared Key in IKEv2-Sitzungsschlüssel einzumischen. Er setzt die Nutzung beim anfänglichen Aufbau voraus, schützt aber nicht die anfängliche IKE SA selbst mit diesem PPK gegen den betrachteten Quantenangreifer. RFC 9867 ersetzt diesen Weg nicht, sondern ergänzt zwei weitere.

Der erste nutzt IKE_INTERMEDIATE, den in RFC 9242 definierten Austausch vor der Authentisierung. Der Initiator bietet PPK-Identitäten an; der Responder kann eine auswählen und eine Bestätigung senden. Die Einmischung erfolgt vor IKE_AUTH und kann damit zum Schutz der anfänglichen IKE SA und der Authentisierung beitragen. Wenn weitere Zwischenaustausche Schlüssel neu berechnen, muss die PPK-Operation die letzte Neuberechnung vor dem nächsten Austausch sein. Die Reihenfolge ist Teil des Sicherheitsnachweises.

Der zweite Weg führt über CREATE_CHILD_SA. Ein frischer PPK kann beim Erstellen oder Rekeying einer Child SA oder beim Rekeying der IKE SA beitragen, ohne die gesamte bestehende Beziehung abzubauen. Das erleichtert Rotation, erzeugt aber unterschiedliche Stammbäume unter einer logischen Verbindung. Alte IKE SA, weiterlaufende Child SA, neue Child SA und erneuerte IKE SA dürfen nicht automatisch dasselbe Schutzetikett erben.

Die Mehrfachschlüsselaustausche aus RFC 9370 und die Hybridterminologie aus RFC 9838 liefern Kontext. Eine Algorithmenliste beweist Fähigkeit, ein Austauschereignis beweist Aktivität. Beides belegt allein nicht, dass ein bestimmter Beitrag die Schlüssel einer bestimmten SA erreicht hat.

Übereinstimmung ist noch keine Berechtigung

RFC 9867 verwendet zwei registrierte Benachrichtigungen: USE_PPK_INT mit Wert 16445 und PPK_IDENTITY_KEY mit Wert 16446. Das IANA-Register dokumentiert die Zuweisung. Diese sichtbaren Elemente sind Protokollhinweise, aber weder der geheime PPK noch eine Rechtfertigung, ihn zu protokollieren.

Die Bestätigung besteht aus den ersten acht Oktetten der vereinbarten Pseudozufallsfunktion über den definierten Kontext. Sie erkennt, wenn beide Seiten scheinbar dieselbe Identität auswählen, aber unterschiedliche PPK-Werte besitzen. Das ist stärker als ein gleicher Konfigurationsname. Es beweist dennoch nicht, dass der Schlüssel für den später authentisierten Peer zugelassen ist.

Während IKE_INTERMEDIATE muss der Responder möglicherweise auswählen, bevor er die authentisierte Identität des Initiators kennt. Nach der Authentisierung kann die lokale Policy feststellen, dass dieser PPK für den Peer ungeeignet ist. RFC 9867 empfiehlt dann den Abbruch, erlaubt aber die Fortsetzung, wenn die lokale Policy sie gestattet. Material finden, Wert bestätigen, Peer erkennen und Zuordnung erlauben sind vier Entscheidungen.

Automatisierung komprimiert sie leicht. Der Schlüsselspeicher meldet „gefunden“, die Bestätigung „gleicher Wert“, die Authentisierung „dieser Peer“. Erst die Policy sagt „zulässig“. Ein einziges Erfolgsbit löscht Reihenfolge und Verantwortlichkeit.

Erst erstellt, dann abgelehnt und gelöscht

Der deutlichste Fall liegt in CREATE_CHILD_SA. Der Initiator fordert einen frischen PPK. Ist der Responder ohne Unterstützung, Konfiguration oder passende Identität, oder stimmt der Wert nicht, fehlt PPK_IDENTITY_KEY in der Antwort. Die normale IKEv2-Verarbeitung kann die neue SA trotzdem erzeugen.

Bei optionaler PPK-Policy kann der Initiator sie annehmen und nutzen. Bei zwingender Policy ist dieselbe SA unzulässig und darf sofort gelöscht werden. Beide Peers können standardkonform handeln, doch ein Erstellungszähler bewertet das kurzlebige Objekt als abgeschlossene Verstärkung.

Mindestens drei Zeitpunkte sind getrennt zu halten: Erstellung, Policy-Bewertung des fehlenden PPK-Belegs und Annahme oder Löschung. Auch die Datenebene zählt. Liefen Pakete im Zwischenraum? Installierte ein Failover die SA? Hielt der entfernte Peer sie nach lokaler Löschung weiter für aktiv? Der Standard definiert den Austausch; die Belege für die betriebliche Behauptung gehören dem Betreiber.

„Zwingend“ braucht Eigentümer und Geltungsbereich. Die Regel kann nur für einen Peer, eine Verkehrsklasse, ein Rekeying oder eine Migrationsphase gelten. PPK-Unterstützung im Produkt macht sie nicht automatisch verpflichtend. Optionaler Rückfall kann eine bewusste Interoperabilitätsentscheidung sein. Der Governance-Fehler besteht darin, ihn als Nachweis des stärkeren Zustands auszugeben.

Ein Beleg über den Übergang, niemals über das Geheimnis

Der hier vorgeschlagene PPK-Einmischungsbeleg ist ein redaktionelles Kontrollmittel. Er ist kein RFC-Feld, keine Protokollerweiterung und kein Sammelmandat; der PPK selbst gehört niemals hinein.

Für jede erstellte oder erneuerte SA verzeichnet er den Austauschtyp und den Stammbaum der übergeordneten IKE SA. Er unterscheidet RFC 8784 von den RFC-9867-Pfaden. Er kann eine nicht geheime Identität oder datensparsame Kennung, Angebots- und Auswahlzustand, Bestätigungsergebnis und Zeitpunkt der bekannten authentisierten Identität bewahren. Hinzu kommen die beobachtbare zwingende oder optionale Policy, ihre Version, ihr Entscheider und der Ausnahmeeigentümer.

Danach folgt die Ableitungsreihenfolge. War die PPK-Operation bei mehreren Zwischenberechnungen wie gefordert die letzte? SPI und SA-Kennungen binden den Beleg an sein Objekt, beweisen aber nicht selbst die Rechnung. Erstellt, installiert, angenommen, erstes Paket, letztes Paket und gelöscht bleiben getrennte Zustände, ergänzt um Rückfallgrund, Rollback und Prüftermin.

Die Beobachtungsgrenze muss sichtbar bleiben. Ein Paketmitschnitt zeigt Benachrichtigungen und Verkehr, aber womöglich nicht den privaten Schlüsselplan einer Implementierung. Die Implementierung kann den Beitrag bestätigen, ohne das Geheimnis offenzulegen. Herstellerübergreifende Aussagen erfordern begrenztes Vertrauen. Der Beleg nennt deshalb die Quelle jeder Beobachtung und markiert Schlussfolgerungen als solche.

Migrationsaussagen an der SA-Grenze schließen

Auch die Postquantenmotivation braucht Grenzen. RFC 9867 erläutert, dass symmetrische Primitive derzeit nicht als in gleicher Weise von einem kryptografisch relevanten Quantencomputer betroffen gelten wie die diskutierten Public-Key-Verfahren. Ein starker PPK vor der Authentisierung kann einen Schutzpfad ergänzen. Das behauptet weder die Existenz einer solchen Maschine noch einen Termin oder die Sicherheit eines Produkts.

„Frisch“ muss zudem verschieden bedeuten. Derselbe alte PPK gibt dem neuen Rotationsweg keinen Sinn. Entropie, Verwahrung, Verteilung und Reaktion auf Kompromittierung bleiben operative Pflichten, die Austauschserfolg nicht bescheinigt.

Ein belastbarer Bericht zählt daher konkrete SAs und Ergebnisse: RFC 8784, IKE_INTERMEDIATE, Rekeying mit frischem PPK, optionaler Rückfall, Bestätigungsfehler oder Erstellung mit anschließender Pflichtlöschung. Diese Vielfalt ist kein statistischer Schmutz, sondern die tatsächliche Entscheidungsfläche.

Das Protokoll darf trotz ungleicher Fähigkeiten fortfahren, weil das Netz funktionieren muss. Governance muss festhalten, wie es fortfuhr. RFC 9867 bietet einen flexiblen Übergang, verwandelt „erstellt“ aber nicht in einen nie erhobenen Beweis.

Quellen