Résumé

  • RFC 5344 recense des cas d’usage de peering pour la présence et la messagerie instantanée ; ce texte informationnel ne définit ni protocole nouveau ni certificat de conformité d’une fédération.
  • L’authentification du réseau pair répond à « quel domaine est connecté ? ». Elle ne suffit pas à identifier l’observateur, à prouver son droit sur chaque attribut ni à démontrer que le filtrage a été exécuté correctement.
  • Quand l’application de la politique est confiée au pair distant, la preuve doit suivre l’identité utilisée, la version des règles, les transformations retenues et la vue effectivement remise.

Quatre identités dans une seule requête

Une demande interdomaines peut sembler n’en porter qu’une : le compte d’Alice dans un domaine souhaite observer le compte de Bob dans un autre. En réalité, l’opération réunit au moins quatre identités. Il y a le réseau d’Alice, le réseau de Bob, Alice en tant qu’observatrice et Bob en tant que personne qui fixe la politique de divulgation. Un centre de compensation ajoute parfois une cinquième entité.

RFC 5344 traite correctement le premier couple. Le réseau de Bob peut décider de n’accepter que les abonnements venant de ses propres utilisateurs ou de réseaux auxquels il fait confiance. Le réseau d’Alice relaie alors la demande, et celui de Bob renvoie les notifications par le même chemin administratif. Ce peering évite d’ouvrir le service à n’importe quelle origine.

La tentation consiste à faire porter cette confiance jusqu’au bout de la chaîne. Si le domaine est admis, l’identité d’Alice serait fiable ; si Alice est fiable, la notification serait autorisée ; si le message est envoyé, le contenu serait correct. Chaque flèche ajoute pourtant une proposition nouvelle.

Un certificat de serveur prouve une clé et un nom dans un cadre de validation. Un accord de fédération prouve une relation administrative. Une assertion d’identité peut représenter un utilisateur. Une règle de présence décide ce que cet utilisateur peut recevoir. Une transformation retire ou conserve des champs. Une notification sur le réseau n’est encore ni son affichage ni sa lecture. Ces objets ont des propriétaires, des durées et des erreurs différents.

Le domaine n’est pas la personne

Le modèle de politique commune de RFC 4745 utilise l’identité authentifiée du demandeur comme condition possible d’une règle. RFC 5025 précise ensuite comment une identité d’observateur est obtenue et comparée, et comment la politique contrôle les personnes, appareils, services, activités, humeurs, lieux, relations ou notes visibles.

Cette granularité interdit de résumer le résultat par « pair de confiance ». Une règle peut autoriser Alice à voir la disponibilité sans le lieu. Une autre peut autoriser un groupe de collègues pendant une période déterminée. Une troisième peut bloquer poliment une personne, c’est-à-dire conserver l’apparence d’un abonnement tout en renvoyant une vue pauvre. Le même canal légitime peut donc transporter plusieurs vues légitimes et incompatibles.

Les alias rendent l’écart concret. Une passerelle peut connaître l’identifiant externe d’Alice, tandis que la politique locale vise son identifiant interne. Une identité téléphonique et une URI SIP ne se correspondent pas automatiquement. Un domaine peut affirmer plusieurs URI. Une fusion de comptes peut rendre ancien un identifiant autrefois exact. Si le pair distant applique la règle sans conserver l’origine de l’identité et la logique de correspondance, il peut fournir une réponse syntaxiquement valide au mauvais principal.

Il faut donc distinguer trois reçus : le pair a été authentifié ; l’identité de l’observateur a été établie selon une méthode donnée ; cette identité a satisfait telles conditions de politique. Le premier ne remplace jamais les deux suivants.

La délégation déplace le serveur de politique

RFC 5344 décrit une optimisation ambitieuse. Quand de nombreux observateurs d’un réseau distant suivent la même personne, le réseau d’origine peut éviter l’envoi de multiples documents filtrés. Il partage la politique privée et un document complet ; le réseau destinataire fabrique ensuite la bonne vue pour chacun de ses observateurs.

Le gain de trafic est réel en théorie. Mais la fonction d’autorisation change de lieu. Le réseau d’origine n’est plus le dernier système à voir le document complet avant divulgation. Il dépend du moteur de règles du partenaire, de son interprétation des identités et de sa discipline de stockage. Le texte lui-même avertit qu’une fuite de politique pourrait révéler à quelqu’un qu’il figure sur la liste de blocage d’un proche.

RFC 6271 ajoute plus tard une exigence essentielle : le partage des réglages privés doit reposer sur le consentement exprès de l’utilisateur concerné. Ce consentement porte sur la transmission et le traitement de la politique. Il ne transforme pas le pair en auteur de la règle et ne valide pas à l’avance chaque décision future.

Une délégation exploitable doit donc être bornée. Quel partenaire peut exécuter la politique ? Pour quelle durée ? Sur quelle version ? Avec quel dictionnaire d’identités ? Quels attributs peuvent exister dans le document complet ? Combien de temps celui-ci est-il conservé ? Comment une révocation arrive-t-elle ? Que se passe-t-il si la politique et le document franchissent des chemins différents ? Sans ces réponses, le mot « fédération » masque le véritable centre de décision.

Une politique correcte peut arriver trop tard

L’autorisation n’est pas seulement une table ; c’est un état dans le temps. Bob peut retirer Alice de son cercle familial. Le réseau d’origine met à jour la règle, mais un pair distant conserve encore la version précédente. Un document de présence récent arrive avant la révocation. Le moteur applique impeccablement une politique périmée et révèle un lieu que Bob vient de masquer.

L’erreur inverse existe aussi. Une nouvelle autorisation arrive, mais le document associé est ancien. Le pair délivre correctement une vue devenue trompeuse. Dans les deux cas, chaque objet pris séparément peut être bien formé, signé ou transporté sur TLS. C’est leur liaison temporelle qui manque.

La trace utile associe version du document, version de la politique, identité de l’observateur, instant de décision et ensemble de champs produit. Elle indique si une révocation exige la fin d’un abonnement, l’envoi d’une nouvelle notification ou la suppression de caches. Une simple ligne « SUBSCRIBE accepté » ne peut pas reconstruire cette décision.

L’autre modèle évoqué par RFC 5344 envoie des documents différents avec des listes d’observateurs autorisés. Il évite de livrer toute la politique au pair, mais il crée une atomicité nouvelle : la liste et le document doivent rester liés. Si la liste change avant le document ou si le pair développe une URI de groupe avec un instant différent, l’autorisation glisse encore.

Les listes ne délèguent aucun mandat collectif

Un abonnement à une URI de liste paraît être une seule opération. Le service transforme pourtant une cible en plusieurs destinataires ou plusieurs presentities. RFC 5363 souligne que ce mécanisme peut amplifier le trafic et qu’il faut protéger intégrité, confidentialité et accès à la liste. RFC 5360 traite explicitement la traduction d’une URI en plusieurs URI comme un problème de consentement.

Une liste personnelle montre ce que l’observateur veut suivre. Elle ne dit pas ce que chaque personne accepte de montrer. Une liste publique est administrée, mais l’administrateur ne devient pas l’autorité de divulgation des membres. Une liste ad hoc peut évoluer pendant une conférence. Le contrôle doit donc s’effectuer après expansion et pour chaque relation, pas seulement à l’entrée de la liste.

Le reçu devrait conserver une empreinte de la composition utilisée. Cette exigence est pratique : lorsqu’une personne conteste une notification, l’opérateur doit pouvoir dire si elle était membre au moment de l’expansion, quelle règle du presentity s’appliquait et quel champ est sorti. L’adresse de la liste seule ne répond à rien de tout cela.

Le centre de compensation concentre des rôles

RFC 5344 envisage une fédération en étoile dans laquelle un centre de compensation fournit l’interconnexion autorisée, l’identification des réseaux, la journalisation, le chat à plusieurs ou l’interception légale. Le service central peut réduire le nombre d’accords bilatéraux. Il devient également un gardien d’identités, de politiques, de contenus et de journaux.

L’authentification du centre ne prouve pas l’exhaustivité de ses traces. Un journal peut manquer les refus, les retransmissions, les expansions de liste ou les transformations. Il peut compter une entrée au hub comme une remise au destinataire. Il peut conserver le corps complet alors que les pairs n’avaient convenu que de métadonnées. La preuve exige une spécification de couverture, une horloge, un ordre, des identifiants de transaction, une politique de rétention et un contrôle d’accès.

Le chiffrement du chemin ne répond pas non plus à la garde interne. RFC 5630 rappelle la nature conditionnelle de la protection SIPS et la confiance placée dans les intermédiaires. Un lien sécurisé protège contre certaines interceptions ; il ne garantit pas que le pair applique honnêtement la transformation ou efface sa copie.

Messagerie : ne pas appeler « livré » ce qui a été accepté

RFC 5344 réunit dans ses cas d’usage le MESSAGE SIP en mode pager et les sessions MSRP. Ce sont des mécanismes différents. Une réponse SIP peut attester qu’un serveur a accepté ou traité une requête à une étape. Elle ne prouve pas qu’un terminal l’a affichée, qu’un humain l’a lue ou que l’action souhaitée a suivi.

MSRP possède une session et des rapports propres. Un centre de compensation peut journaliser le passage d’un contenu sans observer son affichage. Un serveur distant peut accepter puis échouer plus tard. Un client peut recevoir hors ligne. Les tableaux de bord devraient afficher une échelle : remis au pair, accepté par le service, distribué au terminal, affiché, acquitté, suivi d’une réponse. Chaque degré a son producteur de preuve.

La sémantique peut encore varier. RFC 6271 cite le passage de « Ne pas déranger » à « Occupé » entre systèmes propriétaires. Un document PIDF standard ne garantit pas que la passerelle a préservé le sens. Il faut garder la valeur d’entrée, la table de correspondance et la valeur de sortie.

Limite des éléments disponibles

Ces sources décrivent des modèles, exigences et mécanismes de l’IETF. Elles ne démontrent le comportement actuel d’aucun produit, domaine, centre de compensation ou utilisateur nommé. Les scénarios sont des tests d’architecture, pas des incidents constatés. RFC 5344 dit lui-même que la solution de sécurité est hors de son champ.

La bonne utilisation d’un RFC est donc de définir ce qui devrait laisser des traces distinctes, puis d’exiger les traces de l’exploitation réelle. La référence au standard ne vaut pas mesure de déploiement.