Zusammenfassung

  • Ein individueller Internet-Draft vom 27. Oktober schlägt vor, für jeden erforderlichen BPSec-Dienst an jedem Zielblock die zuständige Sicherheitsquelle und ihren Schlüssel vorab festzulegen. Ein anderer legitimer Knoten kann diese Anforderung nicht mit seiner eigenen gültigen Sicherung erfüllen.
  • Der Integritätsblock der Nutzlast muss den Primärblock selbst abdecken. Zwei separat geprüfte echte Blöcke belegen noch nicht, dass sie aus demselben Bundle stammen.

Ein gültiger Ausweis für das falsche Amt

Bei einer verzögerungstoleranten Verbindung wandert ein Bundle über Zwischenstationen. Solche Stationen können eigene Schlüssel besitzen und für bestimmte Aufgaben Sicherheitsblöcke hinzufügen. Genau daraus entsteht das heikle Beispiel: Ein Zwischenknoten ersetzt die ursprünglich geschützte Nutzlast und versieht die neue Fassung mit einem Block Integrity Block, kurz BIB, unter seinem eigenen Schlüssel. Der Empfänger prüft, ob ein legitimer Teilnehmer den Block erstellt hat. Das Ergebnis lautet ja. Die ursprüngliche Quelle hat das neue Paket dennoch nie autorisiert.

RFC 9172 beschreibt diese Ersetzung durch einen legitimen Knoten in Abschnitt 8.2.2. Der Standard erlaubt mehrere Sicherheitsquellen innerhalb eines Bundles und überlässt die Richtlinien dem jeweiligen Einsatz. Die dort vorgeschlagene Kombination aus BIB und äußerem Block Confidentiality Block, BCB, schützt die innere Sicherung. Akzeptiert der Empfänger aber einen äußeren BCB von beliebigen zugelassenen Quellen, kann ein anderer legitimer Knoten Inhalt und Sicherung neu zusammenstellen. Die Kryptografie bestätigt dann eine wahre Aussage über den falschen Auftrag.

Der Entwurf von N. D. S. Gupthaa verlegt die entscheidende Kontrolle zum Empfänger. Für jeden Zielblock und jeden dort geforderten Sicherheitsdienst soll die lokale Richtlinie eine zuständige Security Source und das zugehörige Schlüsselmaterial festhalten. Erst wenn der empfangene BIB oder BCB mit genau diesem Material verifiziert wird, gilt die Anforderung als erfüllt. Dass ein anderer Knoten an anderer Stelle der Infrastruktur berechtigt ist, verleiht ihm keine Vollmacht für diesen Block.

Im IETF Datatracker steht Version 00 als individueller Internet-Draft ohne RFC-Stream und ohne IETF-Billigung. Der Text beschreibt vorgeschlagene Empfängerregeln, keine dokumentierte Einführung in einem benannten Netz.

Wer auf der Liste steht, darf nicht alles unterschreiben

R1 bis R4 des Entwurfs legen die Grenze in vier Schritten fest. R1 fordert die erwartete Quelle und den Schlüssel für jeden Dienst und jeden Zielblock. R2 verwirft einen Ersatzblock von einer anderen Quelle, selbst wenn diese Quelle sonst zugelassen ist. R3 lässt den geforderten Dienst scheitern, wenn kein passender Block vorhanden ist. R4 verhindert, dass eine Berechtigung zum erneuten Sichern an einem Gateway auf den Inhalt anderer Quellen übergreift.

In der Praxis wird aus diesen vier Zeilen eine Machtfrage. Ein Relay darf weiterleiten. Ein Gateway darf für einen bestimmten Zweck neu verschlüsseln. Ein ausdrücklich beauftragter Zeuge darf vielleicht für ein abgegrenztes Quellmuster sprechen. Diese Funktionen teilen sich Hardware und gelegentlich sogar Personal; ihre Befugnisse teilen sie nicht automatisch. Eine einzige Spalte „vertrauenswürdiger Knoten“ ist eine Mitarbeiterliste, keine Zuständigkeitsordnung.

Auch das Security-Source-Feld im eingehenden Block darf die Entscheidung nicht selbst treffen. Der Entwurf behandelt es als unzuverlässigen Suchhinweis. Der Block benennt seinen mutmaßlichen Urheber; die vorher bestehende Empfängerrichtlinie prüft, ob dieser Urheber für den verlangten Dienst vorgesehen war. Eine eingehende Nachricht darf nicht ihre eigene Prüfungsordnung aussuchen.

Die Regel setzt Quellschlüssel voraus, die tatsächlich unterscheidbar sind. RFC 9172 hält fest, dass bei einem gemeinsamen Schlüssel für alle Knoten jeder legitime Schlüsselinhaber faktisch privilegiert ist. Eine fein formulierte Empfängerregel kann nicht rückwirkend herausfinden, welcher Inhaber einen Block erstellt hat. Wer die Herkunft trennen will, muss zuerst die Schlüsselverwaltung trennen.

Zwei echte Blätter ergeben keine gemeinsame Urkunde

R5 behandelt ein zweites Montageproblem. Ein BIB schützt die Nutzlast, ein anderer BIB den Primärblock. Beide Prüfungen können gelingen. Beide Blöcke können sogar vom selben ursprünglichen Absender stammen. Trotzdem können sie aus zwei verschiedenen Bundles zusammengesetzt sein. Zwei Echtheitsnachweise für einzelne Teile sind kein Nachweis für deren Verbindung.

Der Nutzlast-BIB muss deshalb den Primärblock in seinen eigenen Integritätsumfang einbeziehen. RFC 9173, Abschnitt 3.3.3, definiert dafür Bit 0 der Scope-Flags; fehlt der Parameter, gilt der Standardwert 7, der dieses Bit enthält. Ein gesonderter BIB über den Primärblock heilt die fehlende gemeinsame Sicherung nicht. RFC 9171 beschreibt die Bundle-Struktur: Der Primärblock enthält Angaben zur Identität und Behandlung des Bundles, die Nutzlast die Anwendungsdaten. Ein Empfänger muss wissen, ob genau diese Angaben und genau diese Daten gemeinsam geschützt wurden.

Die nächste Frage hinter „gültig“

Der Entwurf berichtet von Tamarin-Modellen und einem Konfigurationsprüfer, deren Artefakt noch veröffentlicht werden soll und auf Anfrage verfügbar sei. Das öffentliche Dokument enthält weder eine unabhängig prüfbare Modellsammlung noch ein Ergebnis aus einem benannten Betrieb. Eine offengelegte Empfängerkonfiguration samt reproduzierbarer Ersetzungsspur würde den praktischen Anspruch genauer testen.

Für Betreiber ist die Handlungsfrage schon jetzt scharf genug: Welcher Dienst wurde auf welchem Block verlangt, welche Quelle und welcher Schlüssel waren vorgesehen, und welchen Umfang deckte der tatsächliche BIB ab? Ein grüner Haken für eine gültige Signatur ist eine Antwort auf nur einen Teil dieser Frage. Mit dem falschen Teilstück wird er zur Quittung für die Verwechslung.

Quellen