Zusammenfassung

  • RFC 1457 verstand ein Sicherheitslabel als Attribut von Daten. Erst eine verlässliche Bindung, eine bekannte semantische Autorität, eine bedeutungstreue Übersetzung und eine lokale Regel machten aus dem Feld eine handlungsfähige Anweisung.
  • Explizite oder implizite sowie paketweise oder verbindungsbezogene Labels verteilten nicht nur Overhead, sondern auch Nachweise und Fehlerarten an unterschiedliche Stellen des Systems.
  • Ein erhaltenes Label belegte weder Verschlüsselung noch Autorisierung oder sichere Zustellung. Parsen, Bedeutung auflösen, Richtlinie anwenden, Handlung durchsetzen und Ergebnis beobachten blieben getrennte Tatsachen.

Wiederholung oder Vererbung war eine Beweisfrage

RFC 1457 erschien im Mai 1993 als Informational Memo von Russell Housley. Der Titel Security Label Framework for the Internet bezeichnete einen Denkrahmen, keine universelle Kodierung und keinen Internetstandard. Protokollentwickler sollten zuerst entscheiden, ob ihr Protokoll überhaupt ein Label brauchte. Falls ja, mussten sie Form und Schicht nach der Entscheidung auswählen, die das Label ermöglichen sollte.

Eine zentrale Unterscheidung betraf verbindungslose und verbindungsorientierte Kommunikation. In einem verbindungslosen Verfahren reist ein explizites Label mit jeder Protokolldateneinheit. Ein Router oder Empfänger kann jedes Paket für sich behandeln, und ein Mitschnitt enthält zumindest die sichtbare Zuordnung. Dafür wird der knappe Kontrollraum immer wieder belegt.

Bei einer Verbindung, einem virtuellen Kanal oder einer Association lässt sich das Label dagegen einmal festlegen. Nachfolgende Daten erben die Zuordnung. Der laufende Verkehr wird schlanker, doch die Wahrheit über seine Behandlung liegt nun teilweise im Verbindungszustand. Wer ein späteres Paket untersucht, braucht auch den Aufbauvorgang, die zu diesem Zeitpunkt gültige Richtlinie und den Nachweis, dass die Verbindung nicht in einen anderen Kontext geriet.

Die ökonomische Einsparung tauscht daher eine Fehlerklasse gegen eine andere. Wird eine Verbindung für Daten mit abweichender Sensitivität wiederverwendet, geht ihr Einrichtungsdatensatz verloren oder bleibt sie nach einer Richtlinienänderung bestehen, können vollkommen gültige Pakete die falsche Behandlung erben. Das fehlende Feld ist kein Beleg für fehlende Klassifizierung, wenn die Architektur Bedeutung außerhalb des Pakets gespeichert hat.

Auch ein ungeschriebenes Label konnte entscheiden

Die zweite Achse verlief zwischen expliziten und impliziten Labels. Ein explizites Label steht als Bitfolge in der Protokollsteuerinformation. Ein implizites Label wird aus einem anderen Merkmal erschlossen: aus einem physischen Port, der Quellschnittstelle, einer Verbindung oder sogar dem für den Verkehr verwendeten kryptografischen Schlüssel.

In einer stabilen Ein-Niveau-Umgebung konnte diese Vererbung vernünftig sein. Alles, was über eine geschützte Leitung eintraf, erhielt denselben Kontext. Doch damit wanderte auch der Nachweis. Ein Paketmitschnitt konnte nicht mehr allein erklären, warum ein bestimmtes Label galt. Nötig waren zusätzlich die Portbelegung, die Schlüsselzuordnung oder der Verbindungszustand zum relevanten Zeitpunkt.

Umbauarbeiten wurden dadurch semantisch. Ein umgestecktes Kabel, ein neu belegter Port, ein rotierter Schlüssel oder eine länger als vorgesehen lebende Verbindung konnte die Behandlung ändern, ohne den Nutzdaten auch nur ein Byte hinzuzufügen. RFC 1457 machte sichtbar, dass Konfiguration nicht bloß Umgebung ist. Bei impliziter Kennzeichnung gehört sie zum bezeichneten Objekt und damit zum Audit.

Das Attribut musste an den richtigen Daten bleiben

Das Memo definierte das Sicherheitslabel als Attribut der Daten und nicht als Teil ihres gewöhnlichen Inhalts. Das Attribut beschrieb Anforderungen an Erhebung, Verarbeitung, Übertragung, Speicherung, Abruf und Verbreitung. Bewegten sich die Daten, sollte das Attribut mitgehen. Wurde es von einem Zwischensystem geändert, war diese Neukennzeichnung selbst eine sicherheitsrelevante Handlung.

Darum verlangte der Rahmen eine Bindung zwischen Label und Daten. Integritätsschutz war der allgemeine Weg, diese Bindung zu erhalten; fehlte er im umgebenden Protokoll, musste die Umgebung einen anderen Mechanismus bereitstellen. Ein korrektes Label am falschen Inhalt ist keine abgeschwächte Garantie. Es ist eine falsche Handlungsanweisung.

Fragmentierung, Wiederzusammensetzung, Kapselung und Gateway-Transformationen waren natürliche Bruchstellen. Ein Gateway konnte die Nutzlast unverändert weitergeben und die Kennzeichnung verlieren. Es konnte ein Label korrekt übertragen, es aber einem neu gebildeten Objekt ohne nachvollziehbare Abstammung zuordnen. Der relevante Nachweis lag deshalb nicht nur vor und nach der Grenze, sondern in der belegten Kontinuität durch sie hindurch.

Die Bindung setzte das Label zugleich von Kryptografie ab. Ein kryptografischer Mechanismus konnte die Integrität von Label und Inhalt schützen oder Verkehr auf einem Abschnitt verbergen. Er bestimmte nicht automatisch, welche Klassifikationspolitik galt, wer die Daten nach der Entschlüsselung sehen durfte oder welche weitere Nutzung erlaubt war.

Zwei Arten von Schutz, zwei Zustandsverläufe

RFC 1457 trennte Integritäts- von Sensitivitätslabels. Ein Integritätslabel beschrieb, welches Vertrauen den Informationen zukam und welchen Schutz sie gegen Veränderung oder Zerstörung benötigten. Ein Sensitivitätslabel beschrieb den möglichen Schaden einer Offenlegung und die Maßnahmen zu deren Verhinderung.

Ein Weg durch weniger vertrauenswürdige Komponenten konnte die Einschätzung der Integrität senken. Er machte vertrauliche Informationen nicht automatisch weniger sensibel. Die Zusammenführung mehrerer Datensätze konnte den Offenlegungsschaden sogar erhöhen, ohne ihre technische Integrität zu verändern.

Damit zerfiel die vermeintlich einheitliche Skala „Sicherheit“ in mindestens zwei unabhängige Verläufe. Die Frage, ob ein Bericht glaubwürdig ist, und die Frage, wer ihn lesen darf, haben andere Subjekte, Objekte und Folgen. Ein System, das nur einen Wert bewahrt, kann verschleiern, welchen der beiden Urteile es tatsächlich trägt.

Syntax erkennen hieß noch nicht Bedeutung teilen

Endsysteme konnten in Betriebssystemen oder Datenbanken lokale Labelformate verwenden, die nicht der Darstellung im Kommunikationsprotokoll entsprachen. Ein Empfänger musste das Netzformat deshalb in seine eigene Syntax übersetzen, ohne Bedeutung zu verlieren. Erst danach konnte eine vertrauenswürdige Rechenbasis prüfen, ob ein Prozess zur Annahme der Daten berechtigt war.

Die Reihenfolge lässt sich nicht abkürzen. Parsen stellt fest, dass eine Form erkannt wurde. Übersetzen bildet sie auf ein lokales Vokabular ab. Autorisieren wendet die lokale Regel auf Subjekt und Objekt an. Zustellen oder Verwerfen setzt die Entscheidung um. Eine erfolgreiche Stufe ist kein Ersatzbeleg für die nächste.

Semantischer Verlust konnte sich hinter gültiger Syntax verbergen. Ein Quelldomänenmodell konnte mehrere Compartments unterscheiden, die das Ziel zu einer Kategorie zusammenfasste. Eine Ausnahme hatte vielleicht kein Gegenstück. Zwei Behörden konnten dieselbe Zahl für verschiedene Pflichten verwenden oder verschiedene Zahlen für dieselbe Pflicht. Das Ergebnis blieb maschinenlesbar und war gerade deshalb gefährlich: Es sah nicht wie ein Übertragungsfehler aus.

RFC 1457 bevorzugte eine gemeinsame explizite Syntax mit registrierter Semantik, wenn sich Übersetzung dadurch vermeiden ließ. Eine gemeinsame Struktur erlaubte wiederverwendbare Parser, während registrierte Bedeutungsräume die zuständige Autorität auffindbar machten. Registrierung bedeutete jedoch keine globale Herrschaft. Die lokale Richtlinie blieb lokal, und zwischen beteiligten Stellen musste weiterhin eine tragfähige Übereinkunft bestehen.

Wo eine Transformation unvermeidbar war, konnte ein Application Gateway übersetzen. Die Internet- und OSI-Protokollfamilien boten in Transport-, Sitzungs- oder Darstellungsschicht keine allgemeine Funktion, die beliebige lokale Labelformen versöhnte. Das Gateway wurde so zum Ort, an dem Semantik, Betrieb und Vertrauen zusammenliefen. Eine undurchsichtige Übersetzungstabelle war nicht nur ein technisches Detail, sondern ein Kontrollpunkt.

Zwischenstationen brauchten nur einen Ausschnitt

Endsysteme und Zwischenstationen hatten unterschiedliche Aufgaben. Ein Router oder eine Bridge benötigte eventuell nur den Teil des Labels, der eine zugelassene Route auswählte oder ein Paket verwarf. Das Endsystem brauchte unter Umständen die vollständige Bedeutung, um vor der Zustellung an einen Prozess über den Zugriff zu entscheiden.

Würde jede Zwischenstation alle anwendungsspezifischen Compartments verstehen müssen, stiegen Parsingaufwand und Headerdruck; zugleich würden Richtliniendetails an Komponenten offengelegt, die sie nicht benötigten. Bliebe alles bis zur Anwendung verborgen, käme die Information für Routing oder vertrauenswürdiges Demultiplexing zu spät.

Der Rahmen behandelte Platzierung daher als Zuordnung von Fähigkeit. Routingrelevante Teile mussten dort sichtbar sein, wo weitergeleitet oder verworfen wurde. Informationen für ein Trusted Computing Base mussten vor der Übergabe an einen weniger vertrauenswürdigen Prozess ankommen. Rein anwendungsspezifische Regeln gehörten in das Anwendungsprotokoll.

Der zeitliche Punkt war entscheidend. Ein Label, das erst nach der Übergabe in der Anwendung sichtbar wird, kann späteres Verhalten lenken. Es kann aber nicht rückwirkend verhindern, dass ein unberechtigter Prozess den Inhalt bereits gesehen hat. Die Schicht entscheidet somit nicht nur über Komfort, sondern über den überhaupt noch kontrollierbaren Übergang.

Die sieben Schichten als Karte der Zuständigkeit

RFC 1457 ging die OSI-Schichten durch, ohne daraus ein Ritual zu machen. Auf der Bitübertragungsschicht gab es keinen Protokollkontrollraum für ein explizites Label, wohl aber eine implizite Bedeutung der physischen Verbindung. Auf der Sicherungsschicht konnte ein Frame-Label eine Bridge leiten. Auf der Vermittlungsschicht konnte eine IP-Option einen Router erreichen und früh genug für bestimmte Formen vertrauenswürdiger Demultiplexierung eintreffen.

Die Transportschicht konnte reichere verbindungsbezogene Informationen tragen, wurde von Zwischenstationen aber gewöhnlich nicht ausgewertet. Sitzungs- und Darstellungsschicht boten theoretische Plätze für Endsystembedeutung, obwohl der Internet-Stack keine eigene Sitzungsschicht und das Memo keine standardisierten Darstellungslabels vorfand. Auf Anwendungsebene war die feinste Fachsemantik möglich, allerdings zu spät für Router, Bridges und manche Zustellgrenzen.

Daraus entstanden keine maximalistischen Vorgaben. Die routingrelevante Information sollte für die Weiterleitung sichtbar sein, anwendungsspezifische Information im Anwendungsprotokoll bleiben und Demultiplexierungsinformation rechtzeitig vor der Prozessübergabe vorliegen. Label und Daten mussten gebunden bleiben. Übersetzungen sollten durch gemeinsame Syntax und registrierte Semantik vermieden werden, wo dies realistisch war. Und die erste Prüfung lautete weiterhin: Wird überhaupt ein Label benötigt?

RFC 1108 zeigte den Anteil lokaler Politik

RFC 1108 hatte konkrete Sicherheitsoptionen des US-Verteidigungsministeriums für IPv4 beschrieben. Die Basic Security Option trug eine Klassifizierungsstufe und Kennungen von Schutzbehörden. Sie war ein explizites, verbindungsloses Beispiel auf der Vermittlungsschicht.

Entscheidende Regeln lagen dennoch in lokaler Konfiguration. Portparameter bestimmten, ob ausgehende Daten ein Label tragen mussten, ob unlabeled Eingang akzeptiert wurde und welches implizite Label Daten über einen bestimmten Port erhielten. Ein empfangenes Bitmuster enthielt also weder die gesamte Zulässigkeitsregel noch den Beleg ihrer Anwendung.

RFC 1457 nutzte den Fall als Architekturmaterial, nicht als globale Internetpolitik. Ebenso blieb er von RFC 1455 abzugrenzen. Dort konnte ein Absender eine physisch schwerer zu beobachtende Route anfordern. Hier ging es um Handhabungsanforderungen, die Daten als Attribut begleiteten. Routenwunsch, Sensitivitätsangabe, kryptografischer Schutz und Autorisierung waren verschiedene Aussagen.

Spätere Entwürfe machten den Kontext sichtbarer

RFC 5570 beschrieb 2009 mit CALIPSO ein explizites IPv6-Sensitivitätslabel und führte einen Domain of Interpretation als sichtbaren Bezugspunkt. Eine Stufe namens „SECRET“ hatte allein keine brauchbare Bedeutung; der Empfänger musste wissen, welche Organisation und welches System von Stufen und Compartments sie definierte. Die Domänenkennung verwies auf den Politikkontext, enthielt aber weder die ganze Politik noch deren Durchsetzung.

CALIPSO setzte auch eine klare Einsatzgrenze. Es war für vertrauenswürdige, geschlossene Multi-Level-Secure-Netze gedacht und ausdrücklich nicht für das globale öffentliche Internet geeignet. Der historische Vergleich ist daher keine Empfehlung für eine heutige öffentliche Einführung.

RFC 4301 liefert eine andere Trennlinie. In der IPsec-Architektur treffen Paketmerkmale auf eine lokal konfigurierte Security Policy Database, die PROTECT, BYPASS oder DISCARD auswählt; Security Associations tragen dann konkreten kryptografischen Verarbeitungszustand. Ein Label kann Eingang einer Richtlinie sein, ist aber weder Security Association noch Algorithmus, Peer-Nachweis oder Beleg, dass Schutz tatsächlich stattfand.

Metadaten können eine erforderliche Behandlung benennen. Durch ihre bloße Existenz führen sie sie nicht aus.