Zusammenfassung

  • RFC 2407 definierte DOI 1, Situation-Bits, Identitätstypen, Protokolle, Transforms, SA-Attribute und Statusmeldungen. Die gemeinsamen Kennungen machten eine Verhandlung lesbar, nicht automatisch zulässig oder wirksam.
  • Das Dokument ließ konkrete Sicherheitspolitik ausdrücklich beim Host. Eine belastbare Aussage musste Verhandlung, authentisierte Bindung, lokale Regel, Auswahl, Kernel-Installation und gemessenen Verkehr verbinden.

Zwischen einem privilegierten IKE-Prozess und dem Kernel liegt eine Übergabe. RFC 2407 erwähnte, dass eine formalisierte API dafür wünschenswert sein könne, legte aber weder Struktur noch Ablauf fest. Genau an dieser Naht konnte eine erfolgreiche Verhandlung enden, ohne dass ein Paket je den erwarteten Schutz erhielt.

Der im November 1998 veröffentlichte RFC setzte das allgemeine ISAKMP-Framework für IPsec ein. ISAKMP lieferte Austauschformen und Payloads. Der Domain of Interpretation lieferte Nummernräume und die Bedeutung der IPsec-spezifischen Inhalte. Der registrierte DOI-Wert war 1.

Damit konnten unabhängige Implementierungen dieselben Protocol IDs, AH-/ESP-/IPComp-Transforms, SA-Attribute, Identity Types, Label Domains und Notify Types lesen. Für bewusst kooperierende private Systeme blieben eigene Bereiche reserviert.

Die Registry besaß Eindeutigkeit, nicht Betriebshoheit. Ein ESP-Identifier sagte nicht, welche Authentisierung, Schlüssellänge, Gruppe, Kapselung und Laufzeit dazugehörten. Manche Transform/Attribut-Kombinationen waren definiert, andere ausdrücklich nicht. Der Name allein war kein vollständiger Schutzsatz.

Die Proposal-Syntax erlaubte mehrere Phase-II-Suiten zugleich. Welche Protokolle zusammen verhandelt werden durften, war laut RFC eine Host-Policy-Entscheidung. Der Daemon konnte Alternativen transportieren; die Organisation musste ihre zulässige Menge selbst besitzen.

Auch Situation blieb Eingabe. SIT_IDENTITY_ONLY erforderte eine Identification Payload. SIT_SECRECY und SIT_INTEGRITY ergänzten Label-Domain, Level und Kategorien. Ein nicht unterstützter Fall musste zum Abbruch führen.

Die Labeled Domain Identifier bezeichnete den Namensraum, in dem Levels und Kategorien existierten. Sie enthielt nicht die zugehörige Richtlinie. Eine IANA-Zuweisung konnte ohne verpflichtende Dokumentation erfolgen. Das verhinderte Nummernkollisionen, bewies aber weder gemeinsame Semantik noch lokale Durchsetzung.

RFC 2407 erklärte die Grenze selbst: Der IPsec DOI stellte keine konkreten Policy-Anforderungen, Host-Policy lag außerhalb des Dokuments. Als Beispiele erschienen einfache Adress-/Maskenlisten ebenso wie Regeln mit Wildcard-Namen, Richtung und Proxy-Firewall. Kein Modell wurde zum globalen Entscheider.

Identification Payloads konnten Adressen, Netze, Bereiche, FQDNs, Benutzer-FQDNs, ASN.1-Namen oder opaque Key IDs tragen. Der Responder sollte die Initiatoridentität für lokale Policy verwenden. Doch die Form war keine Authentisierung.

Bei zertifikatsbasierter Authentisierung sollten alle für Policy verwendeten IDs im authentisierenden Zertifikat enthalten sein. Das verband Aussage und Berechtigungsnachweis. ID_KEY_ID konnte dagegen ein herstellerspezifischer opaque Selektor für einen Pre-Shared Key bleiben.

Nach der Auswahl begann der lokale Pfad: Key Manager, Kernel-API, SA-Datenbank, Selector und Paketverarbeitung. Ein positiver IKE-Abschluss belegte nicht automatisch, dass jeder Schritt gelang. Ohne Installations- und Verkehrsnachweis blieb er eine bestätigte Absicht.

RESPONDER-LIFETIME meldete die tatsächlich gewählte Laufzeit. REPLAY-STATUS teilte die Empfängerentscheidung zur Replay-Prüfung mit. Ein Sequence Number im Datenpaket ersetzte diese Information nicht.

INITIAL-CONTACT zeigte die Gefährlichkeit einer semantisch klaren, faktisch begrenzten Nachricht. Der Sender erklärte eine erste SA. Der Empfänger konnte einen Neustart annehmen und alte SAs löschen. Die Nachricht authentisierte den Sprecher, nicht den Neustart als unabhängiges Ereignis.

Selbst der Schutz der Statusmeldung hing vom Austausch ab. Aggressive Mode war mangels Bindung ausgeschlossen. Main Mode konnte nur Teilaspekte schützen, Quick Mode bezog die ganze Notification in den Hash ein. Der gleiche Code stand in unterschiedlichen Beweisumgebungen.

Lu Hengs Running-Code-Maßstab richtet den Blick auf die Nahtstellen. Eine registrierte Zahl ist symbolische Koordination. Eine authentisierte Payload ist eine gebundene Aussage. Erst Policy-Match, Installation und Paketbehandlung sind laufende Wirkung. Ein Dashboard darf diese Ebenen nicht zu einem grünen Feld verschmelzen.

Das Agency-Problem verteilt Verantwortung weiter. IANA verwaltet Werte, Zertifikatsstellen Bindungen, der Daemon die Verhandlung, der Policy-Eigentümer die Erlaubnis, der Kernel die Ausführung und die Anwendung den Nutzen. Wer Auditdaten verwirft, entscheidet später über Beweisbarkeit.

RFC 4306 ersetzte 2005 RFC 2407, 2408 und 2409 durch das zusammengeführte IKEv2. 2023 stufte die IESG das IKEv1-Paket als Historic ein: IKEv2 war breit eingeführt, IKEv1 lange unverändert und wies unter anderem Amplification-Probleme auf. RFC 7296 ist der spätere Internet Standard.

RFC 2407 ist deshalb kein heutiger Algorithmusratgeber. Seine dauerhafte Lehre ist organisatorisch: Der Daemon konnte eine gemeinsame Sprache sprechen. Die Richtlinie, ihre Installation und ihr Ergebnis brauchten weiterhin eigene Eigentümer und Belege.

Quellen