Résumé

  • RFC 5360 rattache la permission à la logique de traduction du relais. Un administrateur peut demander l’ajout d’un destinataire et recevoir HTTP 202, tandis que l’adresse reste en attente et ne doit pas encore participer à la diffusion.
  • Le document de permission lie l’émetteur, la cible d’origine, le destinataire final et les capacités d’accorder ou de refuser. L’authentification du choix, son installation et sa correspondance lors d’une requête ultérieure sont des reçus différents.
  • L’ajout unitaire, le code 470, les rafraîchissements et Trigger-Consent limitent amplification et autorité périmée. Ils ne prouvent ni la bonne expansion de la liste, ni la livraison, ni l’attention humaine, ni l’arrêt effectif après révocation.

Le carnet propose, le relais décide d’exécuter

Un relais reçoit une requête visant une URI cible et la transforme en une ou plusieurs URI destinataires. Il peut être proxy, B2BUA ou hybride. La liste administrée fournit une partie de cette logique, mais c’est le relais qui crée les requêtes sortantes.

La localisation de la permission est donc déterminante. Le consentement ne doit pas rester comme commentaire dans l’interface du gestionnaire. Il doit être disponible au point où la traduction est exécutée, associé à la version de la logique qui sera consultée.

Lorsqu’une adresse n’a pas accordé sa permission, le relais l’ignore pendant la traduction. Ce comportement distingue deux autorités : le gestionnaire est autorisé à proposer la composition ; le destinataire est autorisé à accepter ou refuser que le relais traduise vers lui.

Une capture du carnet d’adresses prouve seulement ce que l’administrateur a tenté de configurer. Une réponse du destinataire prouve une décision délimitée. Pour un appel ultérieur, il faut encore relier l’identité de l’émetteur, l’URI cible, le destinataire final, la permission active et la requête sortante.

Sans cette jointure, un tableau de bord peut annoncer « membre autorisé » alors qu’il montre une intention ancienne, une permission expirée ou une autre version de la liste.

HTTP 202 accepte du travail, pas le destinataire

Dans le scénario principal, A demande l’ajout de B avec XCAP. Le relais répond HTTP 202 puis place B en état pending. Il doit ensuite envoyer un MESSAGE de demande de permission, éventuellement par l’intermédiaire d’un serveur store-and-forward.

Le code 202 n’affirme pas que B a lu la demande, qu’il l’a comprise, qu’il a accordé la permission ou que la traduction est installée. C’est le reçu de l’opération administrative acceptée pour traitement.

RFC 5360 s’appuie sur le paquet d’événements Pending Additions afin d’exposer les étapes ultérieures : pending, waiting, error, denied ou granted. Un utilisateur hors ligne sans stockage intermédiaire peut provoquer une erreur ; le demandeur doit l’apprendre au lieu d’hériter d’un succès imaginaire du 202.

Conservez l’identifiant de la manipulation, la cible, l’adresse proposée, la réponse initiale, la version d’état et chaque NOTIFY. Le passage à granted doit être relié au document de permission et à la décision authentifiée.

Une file d’attente acceptée n’est pas une permission empruntée à son futur destinataire.

Un administrateur authentifié peut ajouter une personne réticente

Le relais doit authentifier et autoriser les clients qui modifient sa configuration. Cette protection empêche des tiers quelconques de réécrire les listes. Elle ne répond pas à la question du consentement.

Un gestionnaire parfaitement légitime peut ajouter une personne qui ne souhaite pas recevoir les appels ou messages de la cible. L’autorité sur la liste n’absorbe pas l’autorité de la personne sur sa propre URI finale.

L’audit doit garder les deux décisions : quelle identité a manipulé la liste, selon quelle politique, puis quelle identité finale a accordé quelle traduction. La formule « ajout par un administrateur autorisé » est trop large si elle masque la seconde décision.

Cette distinction protège aussi les organisations. Un propriétaire de groupe peut gérer le nom collectif sans pouvoir engager les adresses personnelles de tous les futurs membres. L’échelle ne transforme pas une délégation de configuration en consentement individuel.

Une permission est un tuple, pas un oui général

Le document de permission contient l’identité de l’émetteur, l’identité du destinataire d’origine — l’URI cible —, l’identité du destinataire final et les URI permettant d’accorder ou de refuser.

Certains champs peuvent contenir des jokers. L’émetteur est souvent large ; la cible peut l’être selon le modèle. L’URI finale ne doit pas être remplacée par un joker. Le consentement doit toujours aboutir à un destinataire déterminé.

Cette structure évite qu’un clic signifie « j’accepte tout trafic de tout service ». Mais la syntaxe ne suffit pas : l’interface a-t-elle montré la portée de l’émetteur et de la cible ? La partie lisible correspondait-elle exactement au document machine ? Le canal empêchait-il une modification ?

Archivez les octets du document, son empreinte, son interprétation normalisée, le relais émetteur, la version de format, la partie présentée à l’humain et les capacités grant/deny sous forme non réutilisable.

Lors de l’exécution, le relais doit produire un reçu de correspondance entre la requête entrante et ce tuple. Une permission correctement créée peut être mal appliquée si un alias, un joker ou une cible a changé de sens.

Accorder par PUBLISH ou GET reste un acte authentifié

Le destinataire peut envoyer un PUBLISH SIP ou un GET HTTP vide vers une URI d’accord ou de refus. Le corps vide ne rend pas l’acte dépourvu de contexte : le secret ou l’adresse de capacité porte le lien avec la permission.

Le relais doit vérifier que l’action vient du propriétaire de l’URI finale. Le texte décrit SIP Identity, P-Asserted-Identity à l’intérieur d’un domaine de confiance, Digest lorsqu’un secret est partagé et un test de joignabilité.

Ces méthodes ne donnent pas le même reçu. Une identité affirmée dépend de la frontière administrative. Digest dépend de la possession du secret et du défi. Une identité signée doit être comparée au propriétaire. La joignabilité prouve surtout que l’acteur a reçu une capacité imprévisible.

Ne conservez pas seulement authenticated=true. Gardez la méthode, le principal, l’URI finale vérifiée, le domaine de confiance, la capacité hachée, la version de politique et la décision.

Des identifiants valides appartenant à une autre personne ne deviennent pas la permission du destinataire demandé.

La joignabilité prouve une possession étroite

RFC 5360 présente le return routability comme moins fort que SIP Identity, mais utilisable lorsque ce dernier n’était pas disponible. Le relais crée une URI imprévisible, la livre au destinataire, puis accepte l’utilisation de cette URI comme preuve.

Le mécanisme dépend d’exigences précises : envoi du MESSAGE vers une URI SIPS, capacités d’accord et de refus sécurisées, et partie aléatoire d’au moins 32 bits.

Même respectées, ces exigences ne prouvent pas une identité civile durable. Elles prouvent que quelqu’un a reçu et utilisé une capacité secrète sur le chemin prévu. Une copie exposée par le stockage intermédiaire ou une fuite ultérieure peut produire un acte formellement valide sans la personne attendue.

Le journal doit enregistrer génération, entropie déclarée, empreinte de la capacité, chemin protégé, instant d’utilisation, prévention de rejeu et résultat. Ne stockez pas la capacité réutilisable en clair dans des logs ordinaires.

Une migration vers une identité plus forte change aussi la règle. Versionnez-la ; ne réinterprétez pas rétrospectivement les anciens reçus comme équivalents.

Un destinataire par transaction paie le coût de sollicitation

La demande de consentement peut elle-même amplifier. Une petite opération ajoutant mille URI pourrait obliger le relais à envoyer mille MESSAGE.

Le cadre impose donc une forme de crédit en bande passante. Avec XCAP, une transaction HTTP ne peut ajouter qu’un destinataire ; avec REGISTER, une transaction ne peut enregistrer qu’un contact dans ce contexte. Le coût du client devient comparable au coût sortant du relais.

Ce mécanisme n’est pas une limite globale de débit et ne prouve pas une intention bénigne. Un acteur peut émettre de nombreuses transactions, répartir ses identités ou ralentir la campagne. La règle supprime une asymétrie immédiate, pas toutes les formes d’abus.

Mesurez l’identité du client, la cible, la taille, le destinataire, les octets entrants et sortants, la cadence et les rejets 409 ou 403. Ajoutez des budgets par compte, cible et destination si le risque l’exige.

Un test réussi doit aussi vérifier que retries et store-and-forward ne recréent pas une amplification invisible.

Le code 470 interdit la traduction partielle

Avec une liste d’URI contenue dans la requête, le relais choisit les destinataires au moment de la communication. Il maintient auparavant un ensemble plus large d’URI ayant accordé leur permission.

Si une seule URI de la requête n’a pas de permission, le relais ne doit exécuter aucune traduction. Il devrait répondre 470 Consent Needed et fournir Permission-Missing.

Cette atomicité évite qu’une partie du groupe reçoive le contenu tandis que le demandeur croit à un simple échec. Une diffusion partielle peut aussi révéler la composition ou créer des effets irréversibles avant le refus.

Conservez l’empreinte de la liste entrante, la version de l’ensemble de permissions, le résultat par URI et la réponse 470. La liste des URI manquantes est elle-même sensible et ne doit pas être exposée sans besoin.

La page d’errata capturée affiche un rapport technique Reported sur les chevrons nécessaires lorsque la ponctuation d’une URI rend Permission-Missing ambigu. Ce cliché daté n’est ni une correction vérifiée ni un droit de modifier silencieusement la RFC.

La révocation doit atteindre la logique active

Le destinataire peut utiliser l’URI de refus reçue initialement. S’il l’a perdue, une requête traduite ultérieure peut porter Trigger-Consent avec l’URI cible. Il sollicite alors un nouveau document et utilise une nouvelle capacité de refus.

Ce parcours montre que l’intention de révoquer et la suppression effective sont séparées. La personne peut devoir recevoir une nouvelle requête non désirée pour retrouver le chemin. Le relais doit corréler le trigger avec le bon destinataire et la bonne cible.

Un 200 au PUBLISH de déclenchement ne prouve pas que l’ancienne permission a disparu. Enregistrez l’intention, le trigger, le nouveau document, le refus authentifié, la version de logique, l’instant de coupure et la dernière requête émise sous l’ancien état.

La permission doit aussi suivre son contexte. Retirer un destinataire devrait supprimer sa permission. L’expiration d’un contact enregistré devrait faire de même. Le rafraîchissement périodique est recommandé, sans intervalle universel imposé.

« Jamais révoqué » n’est donc pas synonyme de « toujours valide ». L’existence du service, la composition, la fraîcheur et la politique participent à l’autorité.

REGISTER par un tiers dissocie liaison et consentement

Dans le cas ordinaire, la même entité enregistre son contact et reçoit ensuite le trafic, souvent sur la même connexion. La liaison et l’autorisation ont historiquement été réalisées ensemble.

Une inscription par un tiers permet au contraire d’associer l’AoR de l’attaquant à l’adresse de contact d’une victime. La victime reçoitrait du trafic qui visait initialement l’attaquant.

RFC 5360 traite cette inscription comme traduction. Un 202 laisse le contact en attente, le registrar demande la permission et Pending Additions rapporte la décision ultérieure.

Le rapport doit donc nommer le cas : AoR, contact, principal du registrant, relation de connexion, statut tiers, document de permission et décision finale de routage.

« REGISTER a réussi » peut seulement signifier que la demande est prise en charge, pas que le registrar possède déjà l’autorité de transférer vers ce contact.

Chiffrer le document ne garantit pas sa signification

Les documents de permission et les états pending révèlent les relations entre émetteurs, cibles et destinataires. Une modification peut faire accorder autre chose que ce que l’interface montre.

La spécification recommande intégrité et confidentialité fortes, évoquant S/MIME de bout en bout ou TLS/SIPS par saut. Les serveurs store-and-forward doivent protéger la livraison même lorsque leur interface client n’utilise pas SIP.

Ces moyens protègent un transport dans leurs limites. Ils ne prouvent pas l’égalité entre partie lisible et partie machine, l’affichage d’un joker, l’identité de la personne qui clique, l’installation du même tuple ni la bonne correspondance ultérieure.

Comparez les deux représentations avant affichage, liez le texte présenté à l’empreinte machine et testez modification, rejeu, fuite de capacité et état périmé.

La sécurité du canal mérite son reçu ; elle ne doit pas emprunter l’autorité de l’interprétation.

Une mise à jour de syntaxe n’est pas un reçu de déploiement

RFC 8217 met à jour RFC 5360 pour clarifier l’emploi de la production SIP name-addr. Cela fait évoluer le contexte normatif des champs concernés.

La relation documentaire ne prouve pas qu’un relais a installé ce comportement, ni qu’une trace ancienne peut être relue sans connaître parser et version. Conservez l’ensemble de RFC gouvernant chaque essai.

Le statut Proposed Standard établit lui aussi une autorité documentaire. Il ne démontre ni adoption, ni interopérabilité, ni résultat actuel d’un service nommé.