Zusammenfassung

  • P-Preferred-Identity war ein Hinweis des Nutzers, welche seiner gültigen Identitäten der vertrauenswürdige Proxy auswählen sollte; der Hinweis war kein Beweis und musste vor jeder Weiterleitung verschwinden.
  • Eine P-Asserted-Identity aus einer nicht vertrauenswürdigen Quelle musste nach Authentifizierung ersetzt oder vollständig entfernt werden, weil der korrekt geschriebene Header keine Autorität verlieh.

Drei Felder, drei verschiedene Sprecher

SIP besaß bereits From. Dort konnte ein Teilnehmer den Namen oder Alias präsentieren, der zur Unterhaltung passte. Für Telefonnetze reichte diese Selbstdarstellung nicht aus: Sie brauchten eine Identität für Rufnummernanzeige, Dienststeuerung oder Nachverfolgung. Gleichzeitig konnte der Anrufer verlangen, dass der Empfänger diese betriebliche Identität nicht erfuhr. RFC 3325 verstärkte deshalb nicht einfach From, sondern trennte Präsentation, Präferenz und Behauptung.

P-Preferred-Identity stammte vom User Agent. Wenn ein authentifizierter Teilnehmer mehrere gültige Nummern oder SIP-Identitäten besaß, konnte er dem ersten vertrauenswürdigen Proxy mitteilen, welche davon er bevorzugte. Das Feld bezeichnete eine Auswahl, nicht das Ergebnis einer Prüfung. P-Asserted-Identity stammte dagegen vom Netz: Der Proxy hatte den Ursprung authentifiziert oder die Aussage eines vertrauten Nachbarn akzeptiert.

Kam die Präferenz von einem nicht vertrauenswürdigen Element, durfte der Proxy sie nur als Hinweis behandeln. Er musste zuerst den Absender authentifizieren und den Wert dann mit der Menge der für dieses Subjekt gültigen Identitäten vergleichen. Gab es keinen Treffer, konnte er eine andere gültige Aussage bilden oder die Anfrage ablehnen. Er durfte den Wunsch nicht durch bloßes Kopieren in eine Tatsache verwandeln.

Nach der Auswahl musste der Proxy die vom Nutzer gelieferte P-Preferred-Identity aus jeder weitergeleiteten Nachricht entfernen. Diese Löschung war keine kosmetische Bereinigung. Sie schützte die Herkunft der Information. Blieben Wunsch und Behauptung nebeneinander erhalten, könnten Protokolle oder Anwendungen dieselbe Eingabe später als zwei unabhängige Bestätigungen lesen: einmal als Nutzerangabe und einmal als Netzbeleg.

Der Wunsch durfte also eine Entscheidung beeinflussen, erhielt aber kein eigenständiges Weiterleben als Quittung. Hinter der Vertrauensgrenze sollte nur sichtbar sein, wofür das Netz tatsächlich Verantwortung übernommen hatte.

Eine gefälschte Behauptung musste zerstört werden

Noch schärfer war die Regel für P-Asserted-Identity, wenn ein nicht vertrauenswürdiges Endgerät das Feld selbst einsandte. Den reservierten Namen schreiben zu können, machte niemanden zum Sprecher der Vertrauensdomäne. Wollte der Proxy eine Behauptung hinzufügen, musste er den Ursprung authentifizieren und eine daraus hervorgehende Identität verwenden.

Enthielt die nicht vertrauenswürdige Eingabe bereits eine behauptete SIP- oder SIPS-Identität, musste der Proxy sie durch genau eine selbst konstruierte SIP- oder SIPS-Identität ersetzen oder den Header entfernen. Für eine Telefonidentität galt dasselbe. Den alten Wert zu behalten und nur ein Vertrauensmerkmal anzuhängen, hätte die Fälschung durch den sicheren Eingang geschleust. Die vorgetäuschte Autorität musste verschwinden oder aus kontrollierten Belegen neu entstehen.

Eine P-Asserted-Identity von einem vertrauten Knoten durfte ein Proxy dagegen so verwenden, als hätte er den Nutzer selbst authentifiziert. Diese Abkürzung übernahm jedoch alle Voraussetzungen der in RFC 3324 beschriebenen Trust Domain: einen geschützten Empfangsweg, konfigurierte Mitgliedschaft und eine Spec(T), die Authentifizierung, Kanalschutz, Mitglieder, Datenschutzvorgaben und Einhaltung regelte. Der Header war kein kryptografisches Zertifikat.

Die Anwendbarkeitserklärung zog die Grenze ausdrücklich. Die behaupteten Identitäten waren nicht kryptografisch zertifiziert und bezeichneten nicht das einzelne Element, das die Aussage abgegeben hatte. Die gesamte Domäne musste dafür einstehen. Außerhalb einer Architektur mit diesen Annahmen waren Fälschung, Wiederholung und Verfälschung möglich. RFC 3325 bot kein allgemeines Identitätsmodell für das offene Internet.

Datenschutz verlangte eine zweite Löschung

Nach dem Neuaufbau am Eingang musste jeder Proxy den nächsten Hop bewerten. War das Ziel vertrauenswürdig, durfte er lokal erzeugte oder von einer vertrauenswürdigen Quelle empfangene Aussagen erhalten. War es nicht vertrauenswürdig, entschied der Privacy-Header.

Das neue Token id verlangte, sämtliche P-Asserted-Identity-Werte vor der Weitergabe an das nicht vertrauenswürdige Element zu entfernen. Der Gegenwert none verlangte, die behaupteten Identitäten nicht aus Datenschutzgründen zu löschen. Fehlte Privacy, musste die Domänenpolitik in Spec(T) entscheiden. RFC 3325 empfahl grundsätzlich den Erhalt, wenn die Politik ihn zuließ, weil das Entfernen Dienste beschädigen konnte. Zugleich warnte es, die Weitergabe könne Informationen offenlegen, deren Veröffentlichung der Nutzer weder verlangt noch verhindern könne, wenn kein geeigneter Datenschutzdienst verfügbar sei.

Der Header konnte eine Identität enthalten oder zwei, sofern eine SIP beziehungsweise SIPS und die andere telefonisch war. Galt Datenschutz, mussten alle Werte entfernt werden. Nur eine Darstellung zu löschen, hätte dieselbe Person in einer anderen Form durchsickern lassen.

Auch der empfangende User Agent hatte eine harte Grenze. War das vorherige Element nicht vertrauenswürdig, durfte er P-Asserted-Identity überhaupt nicht verwenden. Innerhalb der passenden Trust Domain konnten Implementierung oder Dienst entscheiden, wie der Wert angezeigt wurde; die Spezifikation legte keine Auflösung mehrerer typisierter Werte fest.

RFC 5876 aktualisierte später Einzelheiten von RFC 3325. RFC 4474, RFC 8224 und RFC 8225 entwickelten andere Verfahren für authentifizierte Identität und PASSporT, RFC 4916 behandelte die verbundene Identität im Dialog. Diese späteren Ansätze ändern die historische Lektion nicht: Autorität entstand nicht durch einen privilegiert klingenden Feldnamen, sondern durch eine kontrollierte Kette aus Authentifizierung, Begrenzung, Auswahl, Neubildung, Löschung der Präferenz, Klassifizierung des nächsten Hops und datenschutzbedingter Löschung der Aussage.

RFC 3325 zeigt damit eine anspruchsvolle Form der Evidenzhygiene. Eine legitime Eingabe kann für eine Entscheidung wichtig sein, ohne selbst ein Beleg für das Ergebnis zu werden. Der Proxy machte die Aussage erst zu seiner eigenen, indem er sich weigerte, die Wahl des Nutzers wie eine zweite Bestätigung weiterleben zu lassen.

Quellen