Zusammenfassung

  • Die Werte user, header, session, id und history bezeichneten verschiedene Zielbereiche; sie waren kein allgemeiner Auftrag, alle sensibel wirkenden Felder umzuschreiben.
  • Replaces und Target-Dialog waren keine direkten Ziele dieser Werte. Enthielten sie jedoch eine zuvor umgeschriebene Call-ID, konnte eine Korrektur aus der alten Transformation folgen, auch ohne neuen Privacy-Header.
  • Ein belastbarer Nachweis trennt Anforderung, Zielklassifikation, unabhängige Regel, Mutation, gespeicherten Zustand, semantische Kontinuität und beobachtete Offenlegung.

Eine Aktion ohne gegenwärtigen Auftrag

Ein Dienst erhält einen INVITE mit Call-ID C1 und sendet ihn aus Gründen der Privatsphäre mit C2 weiter. Später trifft ein Request mit Target-Dialog ein. Er enthält keinen Privacy-Header. Trotzdem muss der Dienst möglicherweise C2 wieder C1 zuordnen, damit der Zielendpunkt den bezeichneten Dialog erkennt.

Wer nur den aktuellen Request betrachtet, sieht keine Berechtigung zur Änderung. Wer die frühere Transformation kennt, sieht eine unerledigte Verpflichtung. Der Dienst handelt jetzt nicht aufgrund eines neuen Benutzerauftrags, sondern aufgrund des Zustands, den er selbst geschaffen hat.

RFC 5379 ordnete genau solche Grenzen. Das Dokument erschien im Februar 2010 als Informational-Beitrag des Independent Stream. Es erklärte die praktische Verwendung des Privacy-Mechanismus aus RFC 3323 sowie der Erweiterungen RFC 3325 und RFC 4244. Es erklärte ausdrücklich, weder den Mechanismus zu ändern noch neues normatives Verhalten einzuführen.

Seine Tabellen waren deshalb keine neue Machtquelle. Sie waren ein Instrument, um bestehende Aufträge präzise zu lesen und unabhängige Folgehandlungen nicht fälschlich demselben Auftrag zuzuschreiben.

Die Werte bildeten keine Stärke-Skala

user bezog sich auf vom Benutzer eingefügte Informationen. header betraf netzseitig hinzugefügte Signalisierungsdaten. session betraf die Sitzungsbeschreibung. id galt für P-Asserted-Identity im Vertrauensmodell von RFC 3325, history für History-Info. none und critical steuerten wiederum andere Entscheidungen.

Ein höher klingender Wert umfasste nicht automatisch die anderen. session bedeutete nicht „alles an diesem Gespräch“, und user bedeutete nicht „jedes Identitätsmerkmal im Paket“.

Die Matrix von RFC 5379 unterschied Löschen, Nicht-Hinzufügen, Anonymisieren, bedingte Behandlung und keine Aktion. Außerdem zählte die Richtung: Request, Response oder beide. Für SDP nannte Privacy:session die Zeilen c, m, o, i, u, e und p.

Ein Produkt, das nur privacy=true speichert, verwirft die entscheidenden Typinformationen. Es braucht Wert, Richtung, Feld, Aktion, Bedingung und normative Quelle, um später erklären zu können, warum eine Änderung zulässig war.

Nicht-Ziele konnten sehr wohl Informationen verraten

Identity/Identity-Info, Path, Replaces, Route, Service-Route und Target-Dialog waren ausdrücklich keine Ziele der aufgelisteten Werte. Ein Privacy-Dienst sollte sie nicht allein aufgrund eines Wertes im Privacy-Header anonymisieren oder ändern.

Das heißt nicht, dass sie unkritisch waren. Path kann eine besuchte Domäne verraten. Route nennt Proxys. Identity-Info verweist auf Signaturmaterial. Replaces und Target-Dialog korrelieren Dialoge.

Sensibilität ist aber ein Risikobefund, keine Änderungsbefugnis. Path ermöglicht die Erreichbarkeit eines registrierten User Agents. Route erzwingt einen bestimmten Proxy-Pfad. Eine kosmetische Anonymisierung kann die darin enthaltene Funktion zerstören.

Will ein Betreiber seine Topologie verbergen, braucht er dafür eine eigene Regel und eine funktionsfähige Technik. Der Benutzerauftrag darf nicht nachträglich als Quelle institutioneller Entscheidungen dienen. Zu jedem Feld gehören drei Fragen: Welche Regel erfasst es? Welche Semantik muss bleiben? Welcher Test beweist beides?

Ein Nicht-Ziel konnte aus anderem Grund verschwinden

Identity zeigt die Gegenrichtung. Im historischen Modell von RFC 4474 schützte die Signatur From, To, Call-ID, CSeq, Date, Contact und den Body. Veränderte der Privacy-Dienst ein geschütztes Feld rechtmäßig, war die vorhandene Signatur nicht mehr gültig.

Identity wurde dadurch nicht zum direkten Ziel des Privacy-Wertes. Dennoch konnte es notwendig sein, den ungültigen Nachweis zu entfernen. Die Befugnis stammte aus der Integritätsabhängigkeit, nicht aus einer Ausweitung des Benutzerauftrags.

Ein Audit sollte beide Schritte speichern: Ziel A wurde aufgrund des Wertes verändert; Nachweis B wurde dadurch ungültig und aufgrund einer separaten Integritätsregel entfernt. Die Kurzform „Privacy entfernte Identity“ löscht die Kausalität.

RFC 4474 wurde später durch RFC 8224 abgelöst. Die konkrete alte Signatur ist keine aktuelle Einsatzanweisung. Das Abhängigkeitsprinzip bleibt: Wer Eingaben eines Nachweises ändert, muss ihn neu prüfen, widerrufen oder neu erzeugen.

Target-Dialog trug die alte Entscheidung weiter

Target-Dialog steht für denselben Grundkonflikt wie Replaces. Beide können eine Call-ID referenzieren, die der Absender nicht selbst erzeugt hat. Deshalb sind sie keine normalen Anonymisierungsziele des gegenwärtigen Benutzers.

Hat ein Dienst die zugrunde liegende Call-ID früher verändert, muss er die Referenz dennoch auswerten. Der spätere Request braucht keinen Privacy-Header, denn die Ursache liegt in der alten Abbildung C1–C2.

Die Transferbeispiele von RFC 5379 zeigen den Ausfall. Der erste INVITE durchläuft den Dienst, ein späterer REFER oder INVITE jedoch einen anderen Pfad. Der neue Request trägt die für eine Seite richtige, für die andere unbekannte Kennung. Die Dialogersetzung scheitert, obwohl jede einzelne Nachricht syntaktisch gültig sein kann.

Damit wird aus einer lokalen Mutation ein verteilter Zustandsvertrag. Abbildung, Lebensdauer, Replikation, Failover, Pfadabdeckung und Verhalten bei fehlendem Eintrag müssen vor der Änderung feststehen. Der Mutationsdienst besitzt diese Schuld bis zum Ende aller abhängigen Vorgänge.

Lokale Politik brauchte eigene Provenienz

RFC 5379 ließ Implementierungs- und Netzpolitik bei der konkreten Verschleierung zu. Es erkannte auch an, dass sensible Nicht-Ziele unabhängig vom angeforderten Wert behandelt werden könnten. Diese Flexibilität ist nur kontrollierbar, wenn jede Quelle sichtbar bleibt.

Topologieverbergung, P-Asserted-Identity an einer Vertrauensgrenze, das Entfernen ungültiger Integritätsdaten und das Wiederherstellen von Route nach einer Record-Route-Transformation haben verschiedene Urheber und Zwecke.

Ein gemeinsames Flag „Privacy angewendet“ macht sie ununterscheidbar. Bei einem Fehler lässt sich nicht feststellen, ob Benutzerwunsch, Betreiberpolitik, Integritätsbereinigung oder Korrelation verantwortlich war. Jede lokale Regel braucht Namen, Version, Eigentümer, Geltungsbereich und Ergebnis.

Der Privacy-Header bleibt Beleg für eine begrenzte Bitte. Die Matrix belegt die Auslegung. Das Service-Log belegt eine Aktion. Der Call-Trace belegt den Ablauf. Ein Beobachtertest belegt eine konkrete Offenlegung oder Nicht-Offenlegung. Kein Beleg darf sich als die anderen ausgeben.

Privatsphäre brauchte einen Beobachter

Auch ein erfolgreiches Gespräch beweist nicht das gewünschte Geheimnis. Der Angerufene sieht den Namen nicht, der Privacy-Dienst aber schon. SDP kann eine Adresse verraten. Abrechnung und Diagnose können Korrelation erhalten.

Eine belastbare Aussage nennt Information, Beobachter, Nachrichten, Medienfluss und Zeitraum. Sie nennt auch, welche internen Stellen weiterhin korrelieren können und wann der Zustand gelöscht wird.

Der Test muss Registrierung, ersten Dialogaufbau, Antworten, In-Dialog-Requests, Transfer, Rückruf und Ende abdecken. Er prüft gleichzeitig, dass der gewählte Beobachter die Information nicht erhält und dass die erwarteten Funktionen weiterlaufen.

Ein entferntes Feld beweist keine funktionierende Verbindung. Eine funktionierende Verbindung beweist keine Privatsphäre. Die Tabelle unterstützt konsistente Verarbeitung, ersetzt aber keinen End-to-End-Nachweis.

Dokumentstatus und Register blieben begrenzte Belege

Der Informational- und Independent-Stream-Status von RFC 5379 ist Teil seiner Aussage. Die normativen Formulierungen wurden aus bestehenden RFCs abgeleitet. Aktuelle Implementierungen müssen die jeweilige normative Quelle prüfen.

Auch die Zeitlinie zählt. RFC 4244 wurde durch RFC 7044, RFC 4474 durch RFC 8224 abgelöst. Historische Beispiele erklären das Problem, sind aber nicht automatisch die heutige Lösung.

Das IANA-Register für SIP-Parameter bestätigt Namen und Referenzen. Es bestätigt nicht, dass ein Produkt den Wert unterstützt, korrekt verarbeitet, Zustand erhält oder ein Datenschutzziel erreicht.

Ein minimaler Belegsatz enthält:

  • ursprüngliche Nachricht, Richtung, Auftraggeber und Zielbeobachter;
  • jeden Privacy-Wert und die gültige Spezifikation;
  • Zielentscheidung pro Feld;
  • unabhängige lokale oder protokollbedingte Regel;
  • Zustand vor und nach der Änderung;
  • ungültig gewordene oder erneuerte Nachweise;
  • Identitätsabbildung, Lebensdauer und zuständige Knoten;
  • nachfolgende Verbraucher der Abbildung;
  • Routing-, Dialog-, Transfer- und Medienergebnis;
  • Offenlegungstest pro Beobachter.

So bleibt ein Token eine Bitte, eine Änderung eine Aktion und ein Ergebnis ein separat bewiesener Zustand.