Zusammenfassung

  • RFC 5344 sammelt Anwendungsfälle für Presence- und IM-Peering. Das Informational-Dokument definiert kein neues Protokoll und bescheinigt keiner Föderation eine gelöste Sicherheitslage.
  • TLS oder SIPS kann einen Transportabschnitt und einen Gegenpunkt unter bestimmten Vertrauensannahmen schützen. Es beweist nicht, dass der Peer die richtige Watcher-Identität, Policy-Version und Feldtransformation verwendet hat.
  • Wer Privacy Enforcement an einen Partner delegiert, braucht Ausführungsnachweise: Eingangsdokument, Nutzerzustimmung, Regelversion, Identitätsabbildung, erzeugte Sicht und wirksamen Widerruf.

Zwei grüne Anzeigen, zwei verschiedene Aussagen

Ein Netzwerkmonitor prüft, ob die TLS-Verbindung steht. Ein Anwendungstest prüft, ob ein bestimmter Watcher genau die erlaubten Presence-Felder erhält. Beide können grün sein, rot sein oder voneinander abweichen. Nur wenn sie getrennt bleiben, lässt sich die Ursache einer Abweichung finden.

RFC 5344 setzt bei einem administrativen Problem an. Eine Peer Network B will Subscriptions und Nachrichten nur von eigenen Nutzern oder vertrauten Peer Networks akzeptieren. Peer Network A übermittelt deshalb die Subscription von Alice zu Bob. B sendet spätere Notifications über A zurück.

Die abgesicherte Verbindung beantwortet, welcher administrative Teilnehmer verbunden ist und ob Bytes auf einem Abschnitt vor Veränderung oder Mitlesen geschützt sind. Bobs Freigaberegel beantwortet, welche Daten Alice sehen darf. Dazwischen liegen Alices Nutzeridentität, die Policy-Auswertung und die Bildung der gefilterten Sicht.

Wer aus einem erfolgreichen Handshake auf eine erlaubte Offenlegung schließt, überträgt eine Eigenschaft des Kanals auf den Inhalt. Das ist kein kleiner semantischer Fehler: Es verlagert Autorität vom Nutzer zur Infrastruktur.

Der Partner wird zum Policy-Server

Die anspruchsvollste Optimierung in RFC 5344 ist die Authorization Migration. Beobachten viele Nutzer in einer entfernten Domain dieselbe Person, müsste die Heimatdomain wegen unterschiedlicher Privacy-Regeln zahlreiche Fassungen versenden. Stattdessen kann sie ein vollständiges Presence-Dokument und die Privacy-Information an den entfernten Peer geben. Dort entstehen die individuellen Sichten.

Die Zahl der Übertragungen sinkt. Die Stelle der Entscheidung wechselt. Der entfernte Peer muss nun die Identität des Watchers im selben Sinn verstehen, den richtigen Regelsatz laden, Regeln kombinieren, die richtige Transformation anwenden und auf Widerrufe reagieren.

RFC 6271 macht eine Voraussetzung ausdrücklich: Das Teilen der Privacy-Einstellungen muss mit ausdrücklicher Zustimmung des betroffenen Nutzers erfolgen. Diese Zustimmung ist kein Blankoscheck. Sie sollte Empfänger, Zweck, Dauer, Datenumfang und Widerruf abgrenzen.

RFC 4745 beschreibt Policies mit Conditions, Actions und Transformations. RFC 5025 macht daraus feingranulare Presence-Sichten für Person, Gerät, Dienst, Aktivität, Stimmung, Ort, Beziehung und weitere Attribute. Ein zugelassener Watcher darf nicht automatisch alles sehen.

Damit wird das vollständige Dokument zu einem besonders sensiblen Zwischenprodukt. Es kann mehr enthalten als jede einzelne berechtigte Sicht. Verschlüsselter Transport schützt dieses Objekt unterwegs; nicht jedoch vor falscher Anwendung, internen Zugriffen oder überlanger Speicherung beim Partner.

Ein Ausführungsbeleg braucht Eingabe und Ausgabe

Ein brauchbarer Nachweis beginnt nicht bei „Policy erfolgreich“, sondern bei einem gebundenen Satz von Fakten: Presentity, Dokumentversion und Freshness; Policy-Version; Ursprung der Watcher-Identität; passende Regeln; Transformationen; ausgegebene Felder; Zeitpunkt und ausführende Komponente.

Ohne Eingang und Ausgang kann ein Auditor nur sehen, dass Code lief. Er kann nicht feststellen, ob ein fehlendes Feld bereits in der Quelle fehlte, durch Privacy entfernt wurde, wegen unbekannter Semantik verschwand oder aus einem veralteten Dokument stammte.

Die Versionen sind besonders wichtig. Eine aktuelle Presence-Aktualisierung kann auf eine alte Policy treffen und zu viel preisgeben. Eine aktuelle Policy kann ein altes Dokument korrekt filtern und dennoch einen falschen Zustand zeigen. TLS schützt beide Objekte und löst ihre zeitliche Bindung trotzdem nicht.

Widerruf ist ebenfalls eine Ausgabe. Nach einer Policy-Änderung muss messbar sein, ob eine Subscription beendet, eine neue NOTIFY-Sicht erzeugt und ein vollständiger Cache gelöscht wurde. „Konfiguration synchronisiert“ ist kein Beleg für die bereits offengelegten oder noch gespeicherten Daten.

Netzwerkidentität und Watcher-Identität

RFC 5344 verlangt, dass Administratoren prüfen können, ob der Gegenüber wirklich das behauptete Peer Network ist, ob Kanäle authentisch und vertraulich sind und ob Peer oder Clearing House Daten weder unbefugt weitergeben noch verfälschen.

Diese Anforderungen enden nicht bei derselben Identität. Ein Serverzertifikat identifiziert keinen Menschen. Föderationsmitgliedschaft autorisiert nicht jedes Nutzerkonto. Ein Alias kann auf einen anderen lokalen Principal zeigen; SIP- und tel-URIs sind nicht automatisch gleich; Konten können zusammengelegt werden.

Der Nachweis sollte daher Zertifikat und Peer-ID getrennt von der behaupteten Nutzer-ID, deren Aussteller, Prüfung und Normalisierung halten. Erst die für das Policy Matching verwendete Identität erklärt, warum eine Regel galt. Ein korrekt authentifizierter Peer kann eine technisch gültige Behauptung über den falschen Nutzer senden.

Listen vervielfachen auch Fehler

Persönliche, öffentliche und Ad-hoc-Listen erlauben eine Subscription gegen eine URI. RFC 5363 beschreibt, dass ein URI-List-Dienst aus einer Anfrage viele erzeugt und deshalb Integrität, Vertraulichkeit, Zulassung und Amplification beherrschen muss. RFC 5360 ordnet die Übersetzung zu mehreren Empfängern als Consent-Problem ein.

Die Liste selbst ist keine kollektive Privacy-Erlaubnis. Die persönliche Liste zeigt Alices Interesse. Der Administrator einer öffentlichen Liste kontrolliert Mitglieder, nicht deren Offenlegung. Eine Konferenzliste verändert sich während der Veranstaltung.

Nach der Expansion ist für jede Beziehung zu prüfen, was erlaubt ist. Der Datensatz braucht Membership-Version oder Digest, Expansionszeit und Einzelergebnisse. Eine aggregierte Erfolgsmeldung darf partielle Ablehnungen nicht verschlucken. Umgekehrt kann eine detaillierte Liste abgelehnter Ziele Mitgliedschaften offenlegen.

Bei Multiple-Recipient MESSAGE nimmt der Dienst zusätzlich Identitäts- und Privacy-Entscheidungen vor. RFC 5365 behandelt deshalb From, P-Asserted-Identity und Privacy nicht als bloß zu kopierende Leitungsdaten.

Das Clearing House ist kein neutraler Allwissender

Eine zentrale Föderation kann autorisierte Interconnection, Peer-Identifikation, Logging, Mehrparteien-Chat und Lawful Interception anbieten. Sie reduziert bilaterale Komplexität, konzentriert aber Inhalt, Metadaten und Regeln.

Ihr Log beweist nur seine definierte Beobachtung. Es kann einen Eingang am Hub erfassen, nicht die spätere Ablehnung. Es kann eine Listen-URI sehen, nicht deren entfernte Expansion. Es kann Retries deduplizieren oder nur das vollständige Dokument speichern, ohne die gefilterte Ausgabe zu kennen.

Vollständigkeit entsteht durch Spezifikation und Abgleich: Welche Ereignisse, Uhr, Reihenfolge, IDs, Ausschlüsse und Aufbewahrung gelten? Danach werden Zähler und Transaktionen von Ursprung, Hub und Ziel verglichen. Abweichungen bleiben sichtbar und werden mit Retry, Expiry, Deduplication oder Policy-Rejection erklärt.

Auch ein zentraler Logdienst sollte nicht mehr Daten behalten als nötig. Vollständiges Presence-Dokument, Policy-Bundle, Watcher-Liste, Message-Body und Transportmetadaten brauchen getrennte Aufbewahrungs- und Zugriffsregeln.

Akzeptiert ist nicht gelesen

RFC 5344 nennt Pager-Mode SIP MESSAGE und session-basiertes MSRP. Ein SIP-Response belegt eine Protokolldisposition an einer Stelle. Er belegt weder Anzeige noch menschliches Lesen. MSRP hat eine Session und eigene Transaktions- oder Reportsemantik; beide Modi dürfen nicht in einem generischen delivered verschwinden.

Die Anzeige sollte unterscheiden: zum Peer geroutet, vom entfernten Dienst akzeptiert, zum Client verteilt, verarbeitet oder angezeigt, bestätigt, beantwortet. Presence braucht eine eigene Kette aus Publish, Subscription, Policy-Entscheid, View, NOTIFY und Clientzustand.

Semantik kann trotz erfolgreicher Zustellung abweichen. RFC 6271 nennt das Mapping von „Do Not Disturb“ zu „Busy“. Ein PIDF-Dokument kann syntaktisch korrekt sein, während eine Gateway-Tabelle die Bedeutung verändert. Eingangs-, Mapping- und Ausgangswert gehören in den Transformationsbeleg.

Erkenntnisgrenze

Die Quellen beschreiben IETF-Modelle, Anforderungen und Mechanismen. Sie belegen kein aktuelles Verhalten eines benannten Produkts, Peers, Hubs oder Nutzerkontos. Die Szenarien sind Prüfmodelle, keine gemeldeten Vorfälle. RFC 5344 stellt die Sicherheitslösungen ausdrücklich außerhalb seines Umfangs.

Der Standard zeigt, welche Belege getrennt werden sollten. Ob ein Deployment sie erzeugt, muss gemessen werden.