Zusammenfassung

  • Domänenmitgliedschaft bedeutete bekannte Konformität mit Spec(T); B vertraute A erst durch eine sichere Verbindung und B-seitige Konfiguration, die A als Mitglied auswies.
  • Eine Identitätsbehauptung von einem nicht vertrauten Knoten besaß keine Authentizitäts- oder Integritätsgarantie und durfte weder angezeigt noch weitergegeben noch für Dienste verwendet werden.

Mitgliedschaft war keine Vollvermaschung

SIP erlaubte einem Nutzer, im From-Feld den gewünschten Alias zu setzen. Gleichzeitig hatten User Agents nicht immer das Schlüsselmaterial, um einander direkt zu authentisieren. RFC 3324 beschrieb deshalb kurzfristige Anforderungen für eine vom Netz behauptete Identität: Ein Vermittler authentisierte den Ursprung, leitete daraus eine Identität ab und übergab sie über sicher verbundene Teilnehmer, die dieselben Regeln verstanden.

Die gefährliche Abkürzung wäre gewesen, jeden Teilnehmer innerhalb einer Grenze automatisch als glaubwürdig zu behandeln. Der Text definierte die Vertrauensdomäne T anders. Ein Knoten war Mitglied, wenn bekannt war, dass er die unter Spec(T) zusammengefassten Konfigurationen und Spezifikationen einhielt. Menschen bauten die Domäne. Ein Betreiber konnte seine eigenen Geräte kennen; mehrere Betreiber konnten kleinere Domänen durch bilaterale Vereinbarungen verbinden. Daraus entstand keine sichere Verbindung zwischen jedem Paar.

Operatives Vertrauen wurde beim Empfänger bestimmt. B vertraute A nur, wenn zwischen beiden eine sichere Verbindung bestand und B Konfigurationswissen besaß, dass A zur Domäne gehörte. Die Beziehung war gerichtet. B konnte A vertrauen, obwohl A B nicht vertraute. Ein externer User Agent konnte einen internen Vermittler vertrauen, ohne selbst Mitglied zu werden. In der Abbildung gehörten A, B und C zur selben Domäne; A vertraute C, aber nicht B.

Darum erklärte RFC 3324 die Formulierung „von einem vertrauten Knoten empfangen“ für ungültig. Ein einzelner Knoten kennt nicht den vollständigen Zustand aller Mitglieder. Zulässig war „von einem anderen Knoten empfangen, dem er vertraut“. Damit mussten Empfänger, unmittelbarer Absender, Verbindung und lokale Mitgliedskonfiguration erhalten bleiben. Ohne diese Angaben wurde eine prüfbare Kante zur bloßen Gruppenreputation.

Die Behauptung erbte ihren Weg

Eine Network Asserted Identity entstand bei einem SIP-Netzvermittler als Ergebnis einer Authentisierung. Sie konnte als SIP-, SIPS- oder Telefon-URI erscheinen und musste im zuständigen Bereich tatsächlich zum Nutzer oder zu dessen Dienstlogik führen. Das Authentisierungsverfahren, zumindest dessen Zuverlässigkeit und Stärke, war Bestandteil von Spec(T). Der Nutzer durfte eine bevorzugte Identität anbieten; die Domänenpolitik entschied über ihre Verwendung.

Kam die Behauptung von einem Peer, dem der Empfänger vertraute, durfte er annehmen, dass Erzeugung und Transport nach den vereinbarten Verfahren erfolgt waren. Doch ihre Güte war höchstens so stark wie diese Verfahren. Eine schwache Authentisierung wurde durch die Domänengrenze nicht stark. Die Grenze lieferte Kontext, in dem ein Empfänger die Behauptung bewerten konnte.

Kam sie von einem nicht vertrauten Knoten, fehlte genau dieser Kontext. Es gab keine Garantie für Authentizität oder Integrität, weil nicht bekannt war, ob Spec(T) angewendet worden war. Der RFC verlangte einen harten Ausschluss: nicht dem Nutzer anzeigen, nicht an andere Knoten weitergeben, nicht als Eingabe für Dienste nutzen. Eine Anzeige mit kleinem Warnsymbol hätte bereits die scheinbare Autorität des Namens in eine Entscheidung getragen.

Auch die sichere Verbindung beantwortete nur eine begrenzte Frage. Dritte durften Nachrichten nicht lesen oder unbemerkt verändern, und B musste A als unmittelbaren Absender erkennen. Die lokale Konfiguration verband A mit der erwarteten Domäne. Beides bewies nicht allein die korrekte ursprüngliche Authentisierung, die tatsächliche Einhaltung durch jeden Vermittler oder eine rechtliche Identität. Peer, Verfahren, Regelstand, Zeitpunkt und Dienstwirkung blieben getrennte Belege.

Kompatibilitätsmenge statt Internetpass

Der Geltungsbereich war absichtlich eng. Die Anforderungen betrafen eine Gemeinschaft von Geräten, die den Mechanismus bekanntermaßen befolgten, sowie eine direkte sichere Übergabe an einen externen Knoten, der dem internen Absender vertraute. Allgemeiner Transport zwischen beliebigen Internet-Hosts lag außerhalb des Umfangs. Bei anderer Verwendung gebe es keinerlei Garantie, dass die Information unverändert oder überhaupt ursprünglich richtig war.

Spec(T) musste auch kein einzelnes veröffentlichtes Dokument sein. Es war das vereinbarte Wissen darüber, was behauptet wurde, wie die Feststellung erfolgte, welche Authentisierung genügte, wie Integrität geschützt und Privatsphäre behandelt wurde. Ein sichtbarer Header ohne dieses Betriebswissen war Syntax, kein vollständiger Vertrauensbeleg.

Privatsphäre begrenzte die Weitergabe zusätzlich. Eine Nachricht konnte markieren, dass die Identität nicht an andere Nutzer gehen durfte. Eine getrennte Anzeige konnte den ausdrücklichen Wunsch des Nutzers festhalten, weil eine Politik diesen von rechtlichen oder betrieblichen Gründen unterscheiden konnte. Die Identität durfte innerhalb des vertrauten Netzes weiterlaufen und vor dem externen Nutzer verschwinden. Das passt zu RFC 3323, ist aber nicht dieselbe Aussage.

RFC 3325 lieferte später konkrete private SIP-Erweiterungen, RFC 5876 aktualisierte sie. RFC 4474, RFC 8224 und RFC 8225 entwickelten andere Linien für authentisierte Identität und PASSporT; RFC 4916 behandelte verbundene Identität. Diese Entwicklung macht aus RFC 3324 weder einen Bereitstellungsnachweis noch universelle Identität.

Die historische Leistung bestand in der präzisen Grenze. Eine Domäne konnte kompatibles Verhalten ordnen. Autorität entstand nur an der gerichteten Kante, die der jeweilige Empfänger erklären und prüfen konnte.

Quellen