Zusammenfassung

  • Quick Mode führte für jede Phase-2-Instanz einen eigenen Message ID und eine eigene IV-Kette. HASH(1), HASH(2) und HASH(3) belegten authentifizierten Fortschritt innerhalb dieser Zustandsmaschine.
  • Empfang, Entschlüsselung, Prüfung, Zustandsfortschritt, Schlüsselableitung, SA-Installation und Paketwirkung waren verschiedene Ereignisse. Die dritte Nachricht erhielt der Responder; eine vierte Bestätigung und zwei Kernelbelege gehörten nicht zum Basisaustausch.

Ein gültiges Chiffrat durfte den Zustand nicht automatisch verändern. Diese Regel war keine Randnotiz, sondern eine präzise Aussage darüber, wann empfangene Bytes zu Protokollwirklichkeit werden.

RFC 2409 setzte IKE aus dem ISAKMP-Rahmen von RFC 2408, dem IPsec-DOI-Vokabular von RFC 2407 und Verfahren aus Oakley und SKEME zusammen. ISAKMP hatte Formate und Verwaltung beschrieben, ohne eine einzige Authentisierungs- und Schlüsselaustauschmethode vorzuschreiben. IKE lieferte konkrete Abläufe.

Phase 1 erzeugte eine authentisierte, bidirektionale ISAKMP SA. Main Mode musste implementiert werden, Aggressive Mode sollte implementiert werden. Beide gewannen authentisiertes Schlüsselmaterial aus einem ephemeren Diffie-Hellman-Austausch, unterschieden sich aber in Reihenfolge und Identitätsschutz.

Quick Mode war ausschließlich Phase 2. Er nutzte die bestehende Phase-1-Beziehung, um nicht-ISAKMP SAs zu verhandeln. Ein teurer Elternkanal konnte dadurch viele kürzere AH- oder ESP-Verhandlungen tragen.

Die Cookie-Paarung identifizierte die Eltern-SA. Ein Message ID identifizierte eine einzelne Quick-Mode-Instanz. Der erste IV wurde aus dem letzten Phase-1-CBC-Ausgabeblock und diesem Message ID gewonnen.

Mehrere Quick Modes konnten gleichzeitig laufen. Jede Instanz besaß eine unabhängige IV-Kette. Eine verzögerte oder wiederholte Nachricht in A durfte den Verschlüsselungszustand von B nicht verschieben.

Der Message ID authentisierte dennoch nichts allein. Er wählte den richtigen Zustand aus und wurde in die HASH-Berechnungen aufgenommen. So wurde der Zustandszeiger an den Transcript gebunden, ohne selbst zur Identität oder Berechtigung zu werden.

Die erste Nachricht enthielt HASH(1), den SA-Vorschlag und Ni, optional zusätzlich KE sowie IDci und IDcr. Alle Payloads nach dem ISAKMP-Header waren durch die Phase-1-SA verschlüsselt.

HASH(1) umfasste den Message ID und die vollständige Nachricht nach dem Hash, einschließlich Payload-Header und ohne Verschlüsselungspadding. Der Responder konnte damit den konkreten Vorschlag dem Besitzer des authentisierten Elternzustands zuordnen.

Zuordnung war keine Annahme. Die lokale Richtlinie des Responders entschied weiterhin. Und selbst ein akzeptabler Vorschlag war noch kein Eintrag in einer SAD.

Die zweite Nachricht brachte HASH(2), die ausgewählte SA und Nr. Die Berechnung fügte Ni vor dem übrigen Antworttext ein. RFC 2409 nannte dies einen Liveness-Beleg.

Nach erfolgreicher Prüfung wusste der Initiator, dass der Inhaber des Phase-1-Zustands seinen Nonce gesehen, eine Auswahl getroffen und einen eigenen Nonce erzeugt hatte. Beide Seiten besaßen nun die Eingaben für kompatibles KEYMAT.

Die dritte Nachricht war HDR*, HASH(3). In die PRF gingen ein Nulloktett, Message ID, Ni und Nr ein. Der Responder konnte prüfen, dass der Initiator Nr empfangen hatte und weiterhin den authentisierten Zustand kontrollierte.

Diese letzte Kenntnis war gerichtet. Der Responder empfing HASH(3). Der Initiator sandte ihn. Im Basis-Quick-Mode kam keine vierte Nachricht zurück, die Empfang und Prüfung bestätigte.

Das ist eine begrenzte Folgerung aus der definierten Dreierfolge, kein behaupteter Normsatz über einen Protokollfehler. Wiederholung, geschützter Verkehr oder weitere Synchronisationsmechanismen konnten zusätzliche Indizien liefern. Sie waren nicht Bestandteil des dritten Hashes.

Commit und CONNECTED aus RFC 2408 behandelten Bereitschaft gesondert und kannten selbst die Gefahr einer verlorenen Schlussnachricht. Sie bilden Kontext, aber nicht den eigenen Gegenstand dieses Beitrags.

Auch eine vierte Netzwerkbestätigung hätte keine zwei Kernelinstallationen bewiesen. Der IKE-Daemon verhandelte. Kernel oder Beschleuniger installierten SPI, Schlüssel, Algorithmen, Lebensdauer, Selektoren und Replay-Zustand.

Ein empfangenes Datagramm ist keine erfolgreiche Entschlüsselung. Erfolgreiche Entschlüsselung ist keine HASH-Prüfung. HASH-Prüfung ist kein Zustandsfortschritt. Zustandsfortschritt ist keine Installation. Installation ist kein verarbeitetes Paket. Ein Paket ist kein Anwendungsergebnis.

Die Nonces erfüllten eine andere Aufgabe. Ni und Nr erzeugten Frische und verhinderten, dass ein wiederholter alter Austausch falsche neue SAs erzeugte. Ohne KE im Quick Mode wurde KEYMAT aus SKEYID_d, Protokoll, SPI und beiden Nonces gewonnen.

Dieses Verfahren erneuerte Phase-2-Material, bot aber keine von der Phase-1-Exponentiation unabhängige PFS. Mit optionalem KE führten die Parteien ein zusätzliches Diffie-Hellman aus und mischten dessen Geheimnis in KEYMAT.

KE musste unterstützt, aber nicht in jeder Verhandlung genutzt werden. Bei Nutzung musste die Gruppe über alle betroffenen Proposals und Transforms konsistent sein. Client-Identitäten mussten ebenfalls für alle gemeinsam verhandelten SAs gelten.

PFS ist eine Aussage über historische Vertraulichkeit bei späterer Kompromittierung. Sie sagt nichts über einen erfolgreichen SAD-Schreibvorgang, einen aktiven SPD-Selektor, Hardwareprogrammierung oder den ersten geschützten Datenstrom.

Die optionalen Client-Identitäten zeigten die Autorisierungsgrenze. Phase 1 konnte ein Gateway authentisieren; IDci und IDcr konnten Hosts, Netze oder Protokolle beschreiben, für die das Gateway verhandelte.

Eine authentisierte Gateway-Identität berechtigte nicht automatisch jede Clientbeziehung. Der HASH band die Felder an den Transcript. Die lokale Richtlinie entschied, ob der authentisierte Peer genau diese Selektoren einrichten durfte.

Der Responder wählte Transform und SPI und authentisierte die Auswahl in HASH(2). Der Initiator bestätigte den Empfang durch HASH(3). Danach konnten Speicher, Selektorkonflikte, Lebensdauerumrechnung, Treiber, Hardwaregrenzen oder spätere Richtlinienprüfung die Installation verhindern.

Solche Ergebnisse konnten nicht rückwirkend in einen zuvor berechneten Hash eingehen. Wenn eine Oberfläche „Quick Mode complete“ als Kernelbeleg ausgab, erweiterte sie die Behauptung über den Protokollinhalt hinaus.

Die IV-Regel verlangte deshalb eine echte Zustandsentscheidung. Nach dem ersten IV verwendeten Folgemeldungen den letzten CBC-Block der vorherigen Nachricht derselben Instanz. Der laufende IV durfte erst nach grundlegender Prüfung fortgeschrieben werden.

Eine kryptografisch gültige Wiederholung war kein neuer Fortschritt. Eine Fälschung mit gültigen Cookies durfte die IV-Kette nicht verschieben. Die Implementierung musste Nachricht und Wirkung unterscheiden.

UDP machte die Schlusskante praktisch. HASH(3) konnte verloren gehen. Der Initiator konnte wiederholen, wenn er keinen geschützten Verkehr oder anderen Fortschritt sah. Der Responder musste die Wiederholung erkennen und durfte lokale Effekte nicht doppelt anwenden.

Für Betrieb und Forensik braucht jede Seite eigene Meilensteine. Initiator: HASH(2) geprüft, HASH(3) gesandt, Schlüssel abgeleitet, ein- und ausgehende SA installiert, Zähler bewegt. Responder: HASH(3) empfangen und geprüft, komplementäre SAs installiert, Selektoren und Zähler aktiv.

Lu Hengs Modell der Realitätsschichten ordnet diese Belege. Message ID ist Korrelation. HASH ist authentisierter Transcript. Nonce und Diffie-Hellman sind Ableitung. Richtlinie ist Autorität. SAD/SPD sind ausführbarer Zustand. Zähler sind Paketverarbeitung. Anwendungstest ist Ergebnis.

Das Agency-Problem entsteht beim Übergang. Credential-Verwaltung bindet Phase-1-Identität. Richtlinienverantwortliche erlauben Phase-2-Selektoren. Der IKE-Daemon führt den Austausch. Kernel und Beschleuniger installieren. Betrieb beobachtet Pakete. Der Service-Eigner beurteilt Nutzen.

Eine minimale gemeinsame Spezifikation musste nicht jede lokale Richtlinie und Kernel-API vereinheitlichen. Sie musste Nachrichten und Berechnungen interoperabel machen. Lokale Freiheit blieb erhalten und erzeugte die Pflicht zu lokalen Belegen.

Primat des laufenden Codes bedeutet, die Kette zu speichern: Cookies, Phase-1-Credential und Authentisierung, Message ID, IV-Ursprung, Ni, Nr, KE, Vorschläge, SPIs, HASH-Ergebnisse, Richtlinienversion, Installationsanforderung und -antwort, Runtime-SA, Selektoren, Zähler und Anwendungstest.

Mit dieser Kette wird die Fehlerlage präzise. Fehlt HASH(3) beim Responder, endet der Transcript dort nicht. Sind beide Daemons fertig, aber eine SA fehlt, scheitert die Installation. Zählen beide Seiten Pakete und der Dienst versagt, liegt die Störung nach IPsec.

RFC 2409 erschien im November 1998. RFC 4109 aktualisierte später IKEv1-Algorithmusanforderungen. RFC 4306 ersetzte die Familie 2407/2408/2409 durch IKEv2; RFC 7296 wurde später IKEv2 Internet Standard. 2023 wurde IKEv1 Historic, und RFC 9395 verwarf IKEv1 und schloss zugehörige Register.

Die alte Zustandsdisziplin bleibt nützlich: Erst eine Prüfung durfte den Zustand weiterrücken. Auch heute darf ein Protokollstatus nicht ungeprüft die Wirklichkeit von zwei Kerneln vertreten.

Quellen