Zusammenfassung

  • Für request-contained URI lists gilt eine Alles-oder-nichts-Regel: Fehlt eine Permission, stoppt 470 Consent Needed die Übersetzung. Eine teilweise Zustellung wäre eine andere Policy und ein anderer Beleg.
  • HTTP 202 bestätigt nur, dass eine Listenänderung bearbeitet wird. Erst ein authentifiziertes Permission Document, gebunden an Sender, Target URI und endgültigen Recipient, darf den Relay-Zustand verändern.
  • Eine Empfänger-URI pro Transaktion, Refresh, Entfernung und Trigger-Consent begrenzen Verstärkung und veraltete Rechte. Sie beweisen weder korrektes Fan-out noch Zustellung, menschliche Wahrnehmung oder einen abgeschlossenen Widerruf.

470 zieht die Autoritätsgrenze vor dem Fan-out

Eine request-contained URI list entsteht zur Kommunikationszeit. Der Relay hält einen größeren Bestand bereits erteilter Permissions und prüft die konkrete Liste des eingehenden Requests dagegen.

Wenn auch nur für eine URI die Permission fehlt, soll keine Übersetzung stattfinden. Die Antwort 470 Consent Needed meldet die fehlende Autorität; Permission-Missing bezeichnet die betroffenen URIs.

Der wichtige Punkt ist die Unteilbarkeit. Ein Relay, der an bereits genehmigte Empfänger sendet und die anderen still verwirft, hat eine andere Entscheidung getroffen. Er erzeugt Traffic trotz unvollständiger Autorität und kann über unterschiedliche Ergebnisse die Gruppenzusammensetzung verraten.

Ein belastbarer Nachweis enthält den Hash der eingegangenen Liste, die Version des Permission Sets, jedes einzelne Match, die 470-Antwort und den offengelegten fehlenden Satz. Auch dieser Satz kann sensibel sein und gehört nicht in allgemein zugängliche Logs.

Die gesicherte Errata-Seite zeigt einen technischen Bericht im Status Reported: Bei mehrdeutiger Interpunktion sollen URIs in Permission-Missing durch spitze Klammern abgegrenzt werden. Das ist ein datierter Änderungsvorschlag, keine stillschweigend bereits geltende Neufassung.

Der Relay ist der Ort der Entscheidung

Ein Relay nimmt einen Request an eine Target URI entgegen und übersetzt ihn in eine oder mehrere Recipient URIs. Er kann Proxy, B2BUA oder Mischform sein. Registrierung, Liste und lokale Regeln liefern den Abbildungszustand.

Die Permission muss an diesem Ausführungspunkt liegen. Ein Eintrag in der Administrationsoberfläche ist eine vorgeschlagene Konfiguration, aber noch keine Erlaubnis für spätere ausgehende Requests.

Solange ein Recipient nicht zugestimmt hat, wird er bei der Übersetzung ignoriert. Nach einem Grant muss jeder spätere Runtime Match genau die gespeicherte Permission-Version und ihren Scope verwenden.

Ein Screenshot belegt die Listenänderung. Eine authentifizierte Antwort belegt eine begrenzte Entscheidung. Keines von beiden zeigt, welche Übersetzung der Relay beim späteren INVITE oder MESSAGE tatsächlich ausführte.

Der Ausführungsbeleg verbindet Sender, Target, finalen Recipient, Permission-Version und ausgehende Request-ID. Bei einem B2BUA muss außerdem sichtbar bleiben, wo eine Nachricht beendet und neu erzeugt wurde.

Der Administrator kann Zustimmung nicht delegieren

Der Client muss authentifiziert und für die Listenpflege autorisiert sein. Diese Kontrolle verhindert unbefugte Änderungen, verleiht aber kein Verfügungsrecht über die URI eines anderen Menschen.

RFC 5360 hält zwei Entscheidungen auseinander. Die Policy erlaubt dem Administrator, eine Aufnahme vorzuschlagen. Der Recipient entscheidet, ob der Relay in diesem Kontext zu seiner URI übersetzen darf.

Das Audit braucht beide Spuren: Wer änderte die Liste, welche Regel erlaubte es, welche Recipient-Identität wurde gefragt, welche Darstellung sah sie und wie wurde Grant oder Deny authentifiziert?

„Von einem berechtigten Benutzer hinzugefügt“ lässt gerade den Schutz verschwinden, den der Consent-Mechanismus schaffen soll.

Besitz des Gruppennamens, Betrieb des Relays und Zustimmung jedes Empfängers sind verschiedene Kompetenzen. Eine kollektive Adresse besitzt nicht automatisch die Personen dahinter.

HTTP 202 ist ein Arbeitsbeleg

Im Grundablauf bittet A den Relay, B hinzuzufügen. Der Dienst nimmt die Operation mit HTTP 202 an und setzt B auf pending.

Damit übernimmt er die weitere Bearbeitung. Noch nicht belegt sind Zustellung der Permission-Anfrage, Entscheidung von B, Authentifizierung, Installation, späteres Match, ausgehender Request oder Empfang.

Das Pending-Additions-Event-Paket existiert, weil diese Ergebnisse später eintreffen. pending, waiting, error, denied und granted sind nicht austauschbar. Ohne Store-and-forward kann schon die MESSAGE an einen offline befindlichen B scheitern.

Speichern Sie Manipulation-ID, Target, Recipient, 202, Version des Pending-Zustands und jede spätere NOTIFY-Änderung. Der Übergang zu granted muss auf Dokument und Authentifizierung verweisen.

Wenn eine Oberfläche nur „akzeptiert“ meldet, leiht sie der Verwaltungsentscheidung die Bedeutung der Empfängerzustimmung.

Permission ist eine Beziehung, kein allgemeines Ja

Das Permission Document enthält Sender, ursprünglichen Empfänger beziehungsweise Target URI, finalen Recipient sowie Grant- und Deny-Capabilities.

Der Sender-Scope kann breit sein, und das Target kann im Dokumentmodell wildcardfähig sein. Der finale Recipient darf nicht wildcard sein. Dadurch kann eine Zustimmung nicht auf beliebige künftige Ziele übertragen werden.

Formale Gültigkeit garantiert trotzdem kein Verständnis. Wurde ein Wildcard angezeigt? Entsprach der menschliche Text dem maschinenlesbaren Dokument? Wurde ein Target-Alias später umgebogen? Hat eine neue Identity Policy den Sender-Kreis erweitert?

Bewahren Sie die exakten Bytes, Hash, Formatversion, Relay-Identität, Sender, Target, Recipient, Capability-Hashes und den Hash der Darstellung auf. Ein späterer Request muss gegen diesen eingefrorenen Scope geprüft werden.

Ein boolesches consented=true kann weder Beziehung noch Reichweite oder zeitlichen Kontext rekonstruieren.

Die Grant-Capability braucht den richtigen Principal

Der Recipient sendet ein SIP PUBLISH oder HTTP GET mit leerem Body an die Grant- oder Deny-URI. Der leere Body ist nicht kontextlos: Die Capability referenziert eine bestimmte Permission.

Der Relay muss prüfen, ob der Originator Eigentümer der finalen Recipient URI ist. RFC 5360 beschreibt SIP Identity, P-Asserted-Identity innerhalb einer vertrauenswürdigen Domäne, SIP Digest bei einem Shared Secret und Return Routability.

Die Verfahren haben unterschiedliche Beweisketten. Eine Domain Assertion hängt an der Verwaltungsgrenze, Digest am Geheimnis und Challenge State, eine Signatur am anwendbaren Identitätsmechanismus. Return Routability belegt enger den Besitz einer geheimen, geschützten Capability.

Speichern Sie nicht bloß authenticated=true. Benötigt werden Methode, behaupteter Principal, geprüfter Recipient, Trust Domain oder Credential-Kontext, Capability-Hash, Policy-Version und Entscheidung.

Gültige Anmeldedaten einer anderen Person sind weiterhin keine Zustimmung des Recipients.

Return Routability belegt Erreichbarkeit, nicht Daueridentität

Der Relay erzeugt eine nicht erratbare URI und liefert sie mit der Permission-Anfrage. Wer sie zurücksendet, kann unter den Bedingungen des Frameworks als authentifiziert gelten.

Die MESSAGE muss an eine SIPS URI gehen, Grant und Deny müssen SIPS oder HTTPS sein, und der Zufallsteil braucht mindestens 32 Bits kryptographische Randomness.

Selbst dann ist der Schluss begrenzt. Nachgewiesen ist der Besitz einer Capability, die einen erreichbaren Endpoint erreichte. Nicht nachgewiesen sind bürgerliche Identität, dauerhafte Kontrolle, informierte Zustimmung oder das Fehlen einer weitergeleiteten Kopie.

Das Ledger hält Erzeugungsqualität, Entropiebehauptung, Capability-Hash statt wiederverwendbarem Klartext, geschützten Zustellweg, Redemption-Zeit und Replay-Behandlung fest.

Ein späterer Wechsel zu stärkerer Identity braucht eine neue Policy-Version. Historische Entscheidungen dürfen nicht rückwirkend als gleichwertig umetikettiert werden.

Eine URI pro Transaktion ist Bandbreitenkredit

Auch die Consent-Anfrage kann verstärkt werden. Ein Angreifer könnte mit einer kleinen Änderung viele Empfänger vorschlagen und den Relay zu vielen MESSAGEs veranlassen.

XCAP-Clients dürfen deshalb höchstens einen Recipient pro HTTP-Transaktion hinzufügen. Für REGISTER gilt im beschriebenen Framework ebenfalls ein Contact pro Transaktion.

Der Antragsteller erzeugt damit ungefähr so viele Requests, wie der Relay Permission-Anfragen erzeugen soll. Die unmittelbare Asymmetrie verschwindet.

Das ist kein globales Rate Limit. Viele einzelne Transaktionen, verteilte Identitäten und zeitlich gestreckte Angriffe bleiben möglich. Zusätzlich braucht es Budgets pro Principal, Target und Destination.

Erfassen Sie Client, Target, Recipient, Eingangsbytes, erwartete Ausgangsbytes, Rate und Ablehnung. Ein 409 oder 403 belegt die Transaktionsregel, nicht die Sicherheit der Gesamtlast.

Widerruf endet erst mit Zustandswechsel

Der Recipient kann seine Deny-Capability verwenden. Ist sie verloren, kann ein später übersetzter Request Trigger-Consent und das Target enthalten. Der Recipient fordert ein neues Dokument an und lehnt dann ab.

Dieser Wiederherstellungsweg bedeutet nicht, dass der alte Grant schon verschwunden ist. Ein 200 für den Trigger nimmt die Wiederherstellung an. Eine MESSAGE liefert ein neues Dokument. Erst authentifiziertes Deny und Löschung aus der aktiven Translation Logic ändern die Autorität.

Das Ledger verbindet Widerrufswunsch, Trigger, neues Dokument, Deny, Zustandsversion, Cutover-Zeit und letzten ausgehenden Request unter dem alten Grant. Für konkurrierende Requests braucht es eine Regel.

Auch der Kontext kann enden. Entfernung des Recipients soll die Permission löschen; Ablauf einer Registration soll die Contact-Permission entfernen; fehlender Refresh soll gemäß Policy zur Löschung führen.

„Nicht ausdrücklich widerrufen“ ist keine zeitlose Genehmigung.

Third-party REGISTER trennt Binding und Permission

Beim gewöhnlichen REGISTER können Registrant und Empfänger dieselbe Partei sein. Ein Third-party REGISTER kann dagegen ein Address of Record auf den Contact eines Opfers abbilden und unerwünschten Traffic dorthin lenken.

Ein 202 darf die Bearbeitung annehmen, während der Contact pending bleibt und der Registrar Zustimmung einholt. Pending Additions berichtet später den Status.

Das verlangt nicht für jede normale Registrierung eine Zusatzzeremonie. Der RFC unterscheidet einen User Agent, der auf derselben Connection registriert und empfängt, von einem Registrar mit Drittregistrierungen.

Der Nachweis nennt AoR, Contact, authentifizierten Registrant, Connection-Beziehung, Third-party-Flag, Pending State, Permission Tuple und Forwarding-Entscheidung.

„REGISTER erfolgreich“ kann also bloß angenommene Arbeit bedeuten, nicht Autorität zur Weiterleitung.

Verschlüsselung schützt nicht die Bedeutung

Permission-Dokumente und Pending-Status verraten Beziehungen. Eine Manipulation kann jemanden etwas anderes gewähren lassen, als die Oberfläche zeigt.

Der RFC empfiehlt starke Integrität und Vertraulichkeit, darunter Ende-zu-Ende-Schutz wie S/MIME und TLS/SIPS hop-by-hop, wenn stärkere Mittel fehlen. Store-and-forward braucht geschützte Verwahrung.

Diese Kontrollen schützen Bytes und Transport unter ihren Annahmen. Sie beweisen nicht, dass Human-readable und Machine-readable übereinstimmen, Wildcards sichtbar waren, der richtige Mensch verstand oder der Relay dieselbe Tuple installierte.

Binden Sie die Darstellung an den Dokument-Hash und protokollieren Sie Kanal- und Bedeutungsnachweis getrennt. Testen Sie Mutation, Replay, Capability-Leakage, stale Pending State und Policy-Wechsel.

Eine Syntaxaktualisierung ist kein Deployment-Beleg

RFC 8217 aktualisiert RFC 5360 und weitere SIP-Dokumente, um den Einsatz der name-addr-Produktion zu klären. Das verändert die normative Parsergrundlage betroffener Felder.

Es beweist nicht, dass ein konkreter Relay die Änderung implementiert hat. Zu jedem Lauf gehören Softwareversion, Konfiguration und maßgeblicher Dokumentensatz.

Auch Proposed Standard ist ein Dokumentstatus, kein Beleg für Produkteinsatz, Interoperabilität oder Betrieb in einem benannten Dienst.