Zusammenfassung

  • RFC 3323 definierte Privatsphäre danach, vor welchen Gesprächspartnern Informationen verborgen werden – nicht als Zusicherung, dass eine SIP-Anfrage keinerlei Identität verrät.
  • Ein Dienst konnte Header verbergen und zugleich Routenzustand speichern und später wiederherstellen. Die Vertrauensgrenze verschwand nicht, sondern verlagerte sich zum Dienst.

Anonym – gegenüber wem?

2002 war SIP-Privatsphäre kein einzelner Schalter zwischen „identifiziert“ und „anonym“. RFC 3323 beschrieb sie als Zurückhalten von Informationen vor einer oder mehreren Parteien eines Dialogs. Ein Anrufer konnte seinen echten Namen vor dem Ziel verbergen und einem vertrauenswürdigen Dienst dennoch seine Identität offenlegen. In einer anderen Architektur sollten Netzdetails vor dem Nutzer verborgen bleiben. Entscheidend war die Frage: anonym für wen?

Ein anonymer From-Wert bedeutete nicht, dass eine Anfrage keine brauchbare Adresse enthalten durfte. Die Spezifikation empfahl anonymous.invalid für eine anonyme SIP-URI; spätere Anfragen im Dialog mussten trotzdem den richtigen Endpunkt erreichen können. Persönliche Identität ließ sich verbergen, während Contact, Via, Record-Route oder andere notwendige Sitzungsinformationen erhalten blieben. Privatsphäre steuerte den Blick auf den Protokollzustand – sie löschte ihn nicht.

Der Dienst musste sich merken, was er verbarg

RFC 3323 unterschied zwischen vom Nutzer gewünschter und vom Netz bereitgestellter Privatsphäre. Der Privacy-Header kann user, header oder session anfordern. none untersagt dem Dienst entsprechende Maßnahmen; bei critical muss die Anfrage scheitern, wenn der verlangte Schutz nicht verfügbar ist. Das sind politische Vorgaben für die Behandlung, keine Authentifizierung, Autorisierung, Medienverschlüsselung oder Belege für die Einhaltung durch jeden Vermittler.

Header-Privatsphäre machte den Betriebsaufwand sichtbar. Ein Dienst konnte als B2BUA identifizierende Header entfernen oder umschreiben, Contact durch seine eigene Adresse ersetzen und die ursprünglichen Routen lokal speichern. Bei späteren Dialognachrichten musste er die für die Fortsetzung nötigen Werte wiederherstellen. Der Empfänger sah weniger, doch der Dienst hielt mehr privilegierten Zustand. Gegenüber diesem Dienst war der Anrufer nicht anonym.

Session-Privatsphäre verlangte noch mehr: einen B2BUA und einen Medienvermittler oder Verkehrs-Anonymisierer. Weil der Dienst Teil des Kommunikationspfads wurde, warnte RFC 3323 vor diesem Ansatz ohne Ende-zu-Ende-Medienschutz wie SRTP. Das ist eine architektonische Warnung, keine Aussage über die Verbreitung.

Verbergen schafft einen neuen Kontrollpunkt

Der historische Konflikt liegt darin, dass geringere Sichtbarkeit für den Empfänger die Abhängigkeit von der verbergenden Komponente erhöhen kann. Der Dienst entscheidet, was entfernt, behalten, geändert und wiederhergestellt wird. Damit der Dialog weiterläuft, muss er vertrauenswürdig sein.

RFC 3261 liefert den Kontext zu SIP-Dialogen und Routensätzen. RFC 3325 behandelt später Asserted Identity innerhalb vertrauenswürdiger Netze und erklärt ausdrücklich, kein allgemeines Identitätsmodell zwischen Vertrauensdomänen festzulegen. Die Dokumente betreffen angrenzende Grenzen, aber keine universelle Privatsphäre-Lösung. RFC 3323 belegt weder Verbreitung noch Interoperabilität. Es dokumentiert eine Entwurfsentscheidung: weniger Wissen für eine Partei, genug Protokollzustand für die Fortsetzung – und einen benannten Vermittler, der diesen Ausgleich tragen muss.

Quellen