Zusammenfassung

  • RFC 2367 definierte eine privilegierte Socket-API zwischen Key-Management-Anwendung und lokalem Key Engine. Die Antwort bezeugt diese Schnittstelle, kein verteiltes Gesamtergebnis.
  • SADB_GET, SADB_DUMP sowie LARVAL, MATURE, DYING und DEAD beschreiben lokale Datensätze; sie belegen weder Peer-Autorität noch aktuelle Policy noch Paketnutzung.
  • Ein belastbares Urteil verbindet Prozessrecht, PF_KEY-Transaktion, Schlüsselverwahrung, entfernte Aushandlung, SPD, AH/ESP-Verarbeitung, Empfang und Anwendungsergebnis.

Das konzeptionelle Modell trennt drei Wege. Der Key-Management-Daemon nutzt PF_KEY zum lokalen Key Engine, PF_INET oder PF_INET6 zur entfernten Key-Management-Instanz und IPsec im Kernel eine weitere interne Schnittstelle zur SA. Erfolg auf dem ersten Weg beobachtet die beiden anderen nicht.

Mit SADB_ADD lässt sich eine vollständige SA einsetzen. Alternativ reserviert SADB_GETSPI den SPI und SADB_UPDATE vervollständigt den Eintrag. SADB_GET liest die lokale Kopie; ACQUIRE, EXPIRE, DELETE und FLUSH behandeln Bedarf, Ablauf und Entfernung. Standardisiert wurde damit ein lokales Kontrollvokabular.

Der Zustandsname bleibt lokal

LARVAL folgt GETSPI, MATURE folgt ADD oder UPDATE, DYING und DEAD folgen Soft- und Hard-Lifetime. Keiner dieser Namen sagt, dass der Peer seine Gegenrichtung installiert, die richtige Identität authentisiert und autorisiert oder ein Paket über diese SA verarbeitet hat.

Der SPI ist ein Suchwert, kein Ausweis. Eine Algorithmusnummer ist Konfiguration, kein Nachweis geschützter Schlüssel oder ausgeführter Kryptografie. Eine Lifetime ist lokale Buchführung. Null kann ausdrücklich bedeuten, dass Authentisierung oder Verschlüsselung für die SA nicht verwendet wird. Vollständige Felder ergeben nicht automatisch einen sicheren Tunnel.

SADB_DUMP wirkt umfassend, weil es die lokale Key Table einzeln zurückliefert und ihr Ende markiert. RFC 2367 erklärt den Vorgang jedoch zum Debugging-Werkzeug und verbietet eine Abhängigkeit im Grundbetrieb. Auch PF_KEY-Nachrichten können bei erschöpften Kernel- oder Socket-Puffern verloren gehen. Ein Snapshot kann lokal richtig und historisch unvollständig sein.

Schreibrecht ist Teil der Sicherheit

Nur vertrauenswürdige privilegierte Prozesse sollten den Raw Socket öffnen. Die manuelle Schnittstelle beherrscht lokale SAs weitgehend. Der RFC warnt: Kann ein unprivilegierter Benutzer Einträge erzeugen, lesen, ändern oder löschen, kann das Betriebssystem den betreffenden Sicherheitsdienst nicht liefern.

Darum beginnt die Prüfung bei Prozessidentität, Binary, Konfigurationsgeneration, Genehmigung und effektiven Rechten. Herkunft und Schutz des Schlüssels werden dokumentiert, ohne das Geheimnis offenzulegen. UPDATE-Antworten lassen Keying Material weg, weil Listener Status sehen dürfen, ohne Schlüssel lesen zu dürfen. Beobachtung und Verwahrung sind getrennt.

Policy und Paket sind weitere Belege

RFC 4301 lässt die SPD BYPASS, DISCARD oder PROTECT wählen. SAD-Einträge können nach Änderung ihrer SPD-Regel fortbestehen; manuelle SAs können ohne entsprechende Regel existieren. Vorhandensein beweist keine Anwendung.

RFC 7296 legt Peer-Authentisierung, PAD-Autorisierung, Traffic Selectors und gerichtete Child SAs in IKEv2. Bei Verlust können Endpunkte zeitweise unterschiedliche Zustände führen. Lokales MATURE rekonstruiert diese entfernten Entscheidungen nicht.

RFC 4303 verarbeitet ESP paketweise. Gewählte Dienste, Outbound-Transformation und Inbound-Prüfung sind eigene Ereignisse. Danach folgen Forwarding, Empfang, Transport und Anwendung.

Der belastbare Datensatz verbindet privilegierten Aufrufer, PF_KEY-Request und -Reply, SAD- und SPD-Generation, geschützte Schlüsselherkunft, authentisierte und autorisierte Aushandlung, Flow-Match, AH/ESP-Ergebnis, entfernte Beobachtung und Anwendungsantwort. Fehlende Verknüpfungen bleiben sichtbar.

Quellen