Zusammenfassung

  • Das Initiator-/Responder-Cookie-Paar bezeichnete eine ISAKMP-SA; die Message ID bezeichnete laufenden Phase-2-Zustand; Proposal- und Laufzeit-SPIs hatten weitere Bereiche. Keiner dieser Schlüssel war ein Ausweis.
  • Die zweiphasige Wiederverwendung sparte Authentisierungskosten, konnte aber unterschiedliche Subjekte betreffen. Für einen belastbaren Nachweis blieben Credential-Bindung, lokale Richtlinie, Installation, Paketverarbeitung und Anwendungsergebnis getrennt.

Eine Phase-1-SA kann gesund sein, während eine Phase-2-Verhandlung scheitert. Eine Phase-2-Auswahl kann korrekt sein, während die Installation im Kernel fehlschlägt. Eine installierte SA kann existieren, ohne dass ein relevanter Datenstrom ihren Selektor trifft.

RFC 2408 schuf für diese Unterschiede verschiedene Zustandsräume. Das Cookie-Paar identifizierte die ISAKMP-SA. Die Message ID identifizierte eine Phase-2-Verhandlung darunter. Proposal-SPIs bezeichneten die auszuhandelnden Protokoll-SAs. Spätere ESP- oder AH-Pakete nutzten ihren Header-SPI für den ausführbaren Zustand.

Der Baum war kein unnötiger Formalismus. Er erlaubte mehreren Phase-2-Vorgängen, unter einem Elternkanal gleichzeitig zu laufen. Nahezu gleichzeitige Initiierungen sollten unterschiedliche, unabhängig erzeugte Message IDs erhalten. In Phase 1 musste der Wert null sein, weil dort das Cookie-Paar genügte.

Wer alle Ebenen zu einer „Tunnel-ID“ zusammenfasst, kann den Fehler nicht mehr lokalisieren. Ein Elternkontext, ein Kindvorgang, eine vorgeschlagene SA und eine Laufzeit-SA sind miteinander verbunden, aber nicht austauschbar.

Vor dieser Zustandsfunktion war das Cookie ein Anti-Clogging-Token. Der Empfänger sollte einen billigen Test durchführen können, bevor er teure Public-Key-Operationen ausführt. Die Erzeugung musste von den Parteien abhängen, ein lokales Geheimnis verwenden und schnell bleiben.

Als mögliche Eingaben nannte RFC 2408 Adressen, UDP-Ports, ein lokales Zufallsgeheimnis und Zeit. Der acht Oktette lange Wert sollte für jede SA-Etablierung einzigartig sein und so auch Replay erschweren.

Das beweist die Wiedererkennbarkeit eines vom Aussteller erzeugten Tokens. Es beweist nicht die dauerhafte Identität dessen, der es zurücksendet. Eine Adresse ist ein Eingabewert, kein Zertifikat. Ein lokales Geheimnis schützt die Token-Erzeugung, nicht automatisch die Identitätsbehauptung im späteren Payload.

Auch die Ressourcenwirkung blieb begrenzt. Absolute DoS-Abwehr sei unmöglich, schrieb der RFC. Gefälschte Pakete konnten weiterhin Zustand erzeugen, weshalb Garbage Collection und aggressive Speicherverwaltung nötig waren. Ein gültiges Cookie war kein Kapazitätsbericht.

Beim Beginn der Phase 1 stand nur das Initiator Cookie im Header; Responder Cookie und Message ID waren null. Die Antwort ergänzte das zweite Cookie. Nach Abschluss trugen spätere Nachrichten beide Werte und fanden so die ISAKMP-SA.

Authentisierung lag dennoch separat. RFC 2408 verlangte starke Authentisierung und warnte, dass einer Identifikation ohne sie nicht vertraut werden konnte. Der Server konnte seinen Cookie-Zustand erkennen, bevor er wusste, welches Credential den Peer band.

Die Zweiphasigkeit verstärkte die Notwendigkeit sauberer Subjektangaben. Phase 1 konnte Server oder Hosts authentisieren, Phase 2 Benutzer oder Anwendungsprogramme. Derselbe Elternkanal garantierte nicht, dass jedes Kind dieselbe Autorität trug.

Ein Prüfprotokoll muss deshalb Phase, Subjekt, Credential, Richtlinie und Message ID gemeinsam speichern. Sonst wird aus der Wiederverwendung eines teuren, geschützten Kanals eine unbemerkte Wiederverwendung von Berechtigungen.

Der feste Header war zugleich Parservertrag. Exchange Type bestimmte Nachrichten- und Payload-Reihenfolge. Next Payload zeigte auf den ersten Baustein, jeder generische Payload-Header auf den nächsten. Version, Flags und Länge hatten eigene Regeln.

Beim Empfang wurden Cookies, Next Payload, Version, Exchange Type, Flags und Message ID geprüft, bevor die Kette verarbeitet wurde. Erfolg in einer Stufe sagte nichts über die nächste. Syntaktische Lesbarkeit war weder Signaturprüfung noch Richtlinienentscheidung.

Bei Fehlern wurde verworfen. Ob ein Ereignis protokolliert oder eine Informational Notification gesendet wurde, blieb häufig optional und richtliniengesteuert. Gemeinsame Fehlernamen wie INVALID-COOKIE und INVALID-MESSAGE-ID schufen keine gemeinsame Aufbewahrungspraxis.

ISAKMP war bewusst vom konkreten Schlüsselaustausch getrennt. Es definierte Verfahren und Formate zum Einrichten, Aushandeln, Ändern und Löschen von SAs, ohne eine einzige Schlüsseltechnik, Verschlüsselung oder Authentisierung vorzuschreiben. Der Rahmen transportierte Garantien; er erzeugte sie nicht alle selbst.

Auch die Auswahl blieb lokal. Ein Initiator konnte nur einen Vorschlag anbieten oder mehrere nach Präferenz. Bei mehreren wählte der Responder gemäß eigener Richtlinie. Die Message ID brachte seine Antwort zur richtigen Verhandlung, legitimierte aber nicht seine Regel.

Danach musste der Zustand installiert werden. Die akzeptierte Proposal-Antwort mit SPI war ein Verhandlungsergebnis. Sie war kein Beleg, dass die Kernel-Schnittstelle erfolgreich war, die Selektoren stimmten oder Pakete von der Anwendung angenommen wurden.

Das Commit-Bit adressierte diese Lücke teilweise. Der andere Peer wartete auf eine geschützte Informational Exchange mit CONNECTED, deren Message ID auf die ursprüngliche Phase-2-Verhandlung zeigte. So ließ sich das Bereitschaftssignal zuordnen.

Doch die letzte Nachricht konnte verloren gehen. RFC 2408 standardisierte keine einzige Wiederherstellung. Ein Peer konnte verifizierbaren geschützten Verkehr als Indiz nehmen oder die letzte Nachricht erneut senden. CONNECTED war Synchronisation unter Verlustbedingungen, kein allwissender Betriebsnachweis.

Delete hatte eine ähnlich begrenzte Semantik. Der Sender teilte mit, dass er eine SA aus seiner eigenen Datenbank entfernt hatte. Die Nachricht war keine Aufforderung an den Empfänger, und eine Bestätigung wurde nicht erwartet. Lokale Richtlinie bestimmte die Fortsetzung.

Ein Delete-Paket beweist daher keine entfernte Löschung. Erforderlich sind Schutzprüfung, Empfängerentscheidung, Datenbankänderung, betroffene SPIs und Selektoren, nachfolgende Paketverdicts und Wiederaufbau. Sender- und Empfängerzustand bleiben getrennte Tatsachen.

Lu Hengs Realitätsschichten ordnen die Belege. Cookie bedeutet Korrelation und Ressourcenprüfung. Message ID bedeutet Protokollzustand. Payload-Kette bedeutet Syntax. Credential bedeutet Identitätsbindung. Richtlinie bedeutet Erlaubnis. Installierte SA bedeutet ausführbaren Zustand. Paket und Anwendung bedeuten Wirkung.

Das Agency-Problem entsteht, wenn der Daemon für alle spricht. Credential Authority, Richtlinieninhaber, Aushandlungsprozess, Kernel und Anwendung besitzen unterschiedliche Entscheidungen. Ein grünes „connected“ macht ihre Grenzen unsichtbar.

Running-Code-Primat verlangt eine durchgängige Spur: Cookie-Paar, Message ID, Authentisierungsergebnis, Credential-Fingerprint, Richtlinienversion, Auswahl, Installationsquittung, Laufzeit-SPI, Selektoren, Zähler, Paketentscheidung und Anwendungsmessung. Die Zustandsnummer bleibt wichtig, aber nur als Anfang der Spur.

RFC 2408 erschien im November 1998. RFC 4306 ersetzte 2407/2408/2409 im Jahr 2005 durch IKEv2. 2023 wurde IKEv1 Historic; RFC 9395 schloss die zugehörigen Registries. RFC 7296 wurde später Internet Standard für IKEv2. Die Analyse beschreibt Geschichte, nicht heutige Algorithmuswahl.

Der Cookie fand den Zustand. Das war ein echter Erfolg. Identität, Berechtigung, Installation und Wirkung verlangten weiterhin eigene Beweise.

Quellen