Zusammenfassung

  • RFC 3323 machte Privacy-Werte zu Anforderungen an einen Vermittler; ihr Vorhandensein allein belegte keine ausgeführte Anonymisierung.
  • Der Empfänger konnte eine anonyme Identität sehen, während Dienst, Authentisierung oder lokaler Betreiber den Ursprung weiterhin kannten.

Wunsch und Ausführung

header, session und user verlangten unterschiedliche Funktionen. Rechtliche Grenzen, fehlende Implementierung, Fehlkonfiguration oder Ausnahmen konnten ihre Erfüllung verhindern. Deshalb durfte Überwachung den Header nicht als Erfolg buchen.

Mit critical sollte eine nicht erfüllbare Anforderung zur Ablehnung führen. Weiterleitung hätte die Präferenz umgekehrt und Identität unwiderruflich offengelegt. none schützte den gegenteiligen Wunsch gegen automatische Profile und durfte von Vermittlern nicht verändert werden.

Funktionale Adressen blieben nötig

Ein Endgerät konnte in From Anonymous und die reservierte anonyme SIP-Domäne verwenden, optionale Felder entfernen und Call-ID neutral erzeugen. Contact und Via mussten häufig routbar bleiben; SDP konnte Netzadressen tragen. Falsche Werte hätten Folgemeldungen verhindert.

Der Datenschutzdienst schrieb solche Informationen um und übernahm den Rückweg. Für Sitzungsprivatsphäre konnte er Medien vermitteln. Was er vor dem Empfänger verbarg, musste er selbst kennen oder kontrollieren. Anonymität war daher eine Beziehung zu einem Beobachter, kein globaler Zustand.

TLS bis zum Dienst schützte vor Beobachtung oder Entfernung des Wunsches auf dem vorherigen Weg. Es verbarg die Identität nicht vor dem Dienst. Ein Medienrelay konnte die IP vor dem Gegenüber verbergen und zugleich unverschlüsselte Inhalte sehen.

Empfänger durften nicht identifizierbare Ursprünge ablehnen. Datenschutz erzwang keine Annahme. RFC 3325 behandelte parallel behauptete Identität im Vertrauensnetz; spätere Identitäts- und Verlaufsspezifikationen erweiterten andere Beweisketten. Bekannt in einer Domäne und verborgen in einer anderen waren vereinbar.

RFC 3323 machte aus „anonym“ eine prüfbare Kette aus Beobachter, Route, Dienst, Transformation und Fehlerverhalten. Ohne diese Felder ist ein sauberes From nur Oberfläche.

Der Rückweg musste vorher geplant sein

SIP-Antworten folgen dem Pfad der Anfrage. Nach Empfang konnte der antwortende Teilnehmer keinen neuen Datenschutzdienst in diesen Rückweg einsetzen. Sollte auch sein Contact oder Registrierungsort verborgen bleiben, musste er zuvor eine anonyme Rückruf-URI, eine Registrierung über den Dienst oder eine geschützte Dauerverbindung einrichten.

Privatsphäre war damit Routingarchitektur, keine nachträgliche Textbereinigung. Eine bereits anonymisierte Endnachricht belegt nicht, welche Vermittler das Original sahen oder ob der Rückweg gleich geschützt war.

Header und Sitzung waren getrennte Flächen

Entfernte From-, Via- oder Organization-Werte verbergen nicht automatisch SDP-Adressen und Medienpakete. Ein Medienrelay verbirgt eine IP vor dem Gegenüber, entfernt aber keinen User-Agent oder Call-ID aus SIP. header und session mussten deshalb unabhängig beantragt und geprüft werden.

Eine belastbare Prüfung beobachtet Signalisierung, Medienweg und Authentisierung getrennt und benennt für jedes Ergebnis den ausgeschlossenen Beobachter. „Für den Empfänger anonym, beim Anbieter authentisiert“ ist kein Widerspruch, sondern eine präzise Beschreibung unterschiedlicher Beziehungen.

Vertrauen wurde verschoben, nicht beseitigt

Ein zentraler Dienst konnte vor vielen Zielen schützen und sammelte dafür Ursprungsadressen, Routen und möglicherweise Medien. Ausfall, übermäßige Protokollierung oder rechtlicher Zugriff vergrößerten den Schaden an diesem Punkt. Der Dienst musste daher identifizierbar, ersetzbar und im Fehlerfall prüfbar sein.

Der wichtigste Test war negativ: Eine angeforderte Funktion absichtlich deaktivieren und prüfen, ob critical wirklich ablehnt. Ebenso musste none eine voreingestellte Anonymisierung verhindern. Nur so wurde aus einer Spezifikation nachweisbares Verhalten.

Auch interne Protokollierung blieb eine eigene Ebene. Ein Dienst konnte den äußeren Header korrekt anonymisieren und zugleich eine vollständige Zuordnung von Ursprung, Zeit und Ziel speichern. RFC 3323 legte weder eine Aufbewahrungsdauer noch Zugriffsrechte für solche Daten fest. Ein Betreiber musste daher die sichtbare Transformation von seiner Logpolitik trennen und durfte „anonym“ nicht als Aussage über interne Korrelation verwenden.

Mehrere verkettete Dienste waren ebenfalls kein automatischer Gewinn. Sie konnten fehlende Funktionen ergänzen, vergrößerten aber die Zahl der Stellen, die ursprüngliche oder abgeleitete Identität sahen. Auditierbar wurde die Kette erst mit dokumentierter Delegation, durchgehendem Transportschutz und klarer Zuständigkeit für den kritischen Fehler.

Genau darin lag der entscheidende Unterschied zwischen sichtbarem Versprechen und später überprüfbarem Betriebsnachweis.

Sources