Résumé

  • L’appartenance à un domaine de confiance était une propriété administrative de conformité à Spec(T), tandis que la confiance était une relation dirigée connue localement par le récepteur.
  • Une identité reçue d’un nœud auquel le récepteur ne faisait pas confiance ne devait être ni affichée, ni retransmise, ni utilisée par un service.

Le périmètre ne décidait pas à la place du récepteur

« Domaine de confiance » pourrait désigner une enceinte où toute parole devient vraie. RFC 3324 construit exactement l’inverse. Un nœud appartient au domaine T lorsqu’il est connu comme conforme à l’ensemble de règles et de configurations Spec(T). Des humains composent cet ensemble : un opérateur connaît ses équipements ; plusieurs opérateurs peuvent rapprocher leurs domaines au moyen d’accords bilatéraux. Cette appartenance ne fabrique aucune liaison sécurisée entre chaque paire de nœuds.

La confiance opérationnelle exige deux éléments au même endroit. B fait confiance à A si B dispose d’une connexion sécurisée avec A et d’une configuration indiquant qu’A appartient au domaine. La définition est orientée. B peut faire confiance à A sans que l’inverse soit vrai. Un agent utilisateur extérieur peut faire confiance à son proxy d’origine sans devenir lui-même membre du domaine. L’exemple graphique va plus loin : A, B et C sont membres du même domaine ; A fait confiance à C mais pas à B.

Le document refuse donc la phrase vague « reçu d’un nœud de confiance ». Aucun participant ne connaît nécessairement l’état complet de tous les autres membres. Il autorise la formulation locale : « reçu d’un autre nœud auquel il fait confiance ». L’écart grammatical est un modèle de preuve. La validité ne vient pas du nom du groupe, mais de la relation que ce récepteur peut démontrer avec cet émetteur immédiat.

L’identité conservait la provenance du trajet

Une identité affirmée par le réseau naît chez un intermédiaire SIP après une authentification. Elle peut prendre la forme d’un URI SIP, SIP sécurisé ou téléphonique pertinent pour le domaine ou la plage de numéros responsable. La méthode d’authentification, ou au moins sa robustesse, doit être décrite par Spec(T). L’utilisateur peut proposer une identité préférée ; la politique du domaine décide si elle peut influencer l’affirmation.

Le champ From n’offre pas cette preuve. SIP permet à un utilisateur d’y placer l’alias souhaité, et les agents ne possèdent pas toujours les clés nécessaires pour s’authentifier mutuellement. Le mécanisme à court terme confie donc la dérivation à un intermédiaire, puis transporte le résultat entre des nœuds reliés de manière sûre et accordés sur les mêmes procédures.

Mais l’affirmation n’est pas un jeton universel. Lorsqu’elle arrive depuis un nœud auquel le destinataire ne fait pas confiance, celui-ci ignore si Spec(T) a gouverné sa création et son transport. RFC 3324 dit qu’elle ne porte alors aucune garantie d’authenticité ou d’intégrité. La conséquence n’est pas une simple baisse de score : elle ne doit pas être affichée, transmise ou donnée en entrée à un service.

La connexion sécurisée répond elle aussi à une question limitée. Elle empêche un tiers de lire ou modifier silencieusement le message et permet à B de reconnaître A. La configuration de B relie ensuite A au domaine attendu. Ni l’une ni l’autre ne prouve, à elle seule, que l’authentification initiale était forte ou correctement exécutée. Cette confiance dépend encore de l’intermédiaire, de Spec(T) et des pratiques réelles.

Un ensemble compatible, non une identité Internet

Le champ d’application reste volontairement court. RFC 3324 vise une communauté d’équipements connus pour suivre les mêmes règles, ainsi qu’une transmission directe et sécurisée vers un nœud extérieur qui fait confiance à l’émetteur. Le transport général entre hôtes arbitraires de l’Internet est exclu. Hors de ce contexte, le texte avertit qu’il n’existe aucune garantie que l’information soit restée intacte, ni même qu’elle ait été correcte au départ.

Spec(T) n’est pas forcément un document public unique. C’est l’information convenue qui explique ce qui est affirmé, comment l’identité a été déterminée, quelle authentification suffit et quelles règles de confidentialité s’appliquent. Un en-tête visible sans cette convention ne révèle pas la qualité de la preuve.

La confidentialité ajoute une autre limite. Le message peut indiquer que l’identité ne doit pas être transmise à d’autres utilisateurs. Une indication distincte peut exprimer la demande propre de l’utilisateur, car la politique peut distinguer son intention d’une contrainte légale ou opérationnelle. L’identité peut donc circuler dans le réseau de confiance tout en restant cachée à l’usager extérieur. C’est compatible avec la confidentialité relative à l’observateur de RFC 3323, sans s’y réduire.

RFC 3325 a ensuite défini les extensions privées concrètes, puis RFC 5876 les a mises à jour. RFC 4474, RFC 8224 et RFC 8225 appartiennent à une autre lignée d’identité authentifiée et de PASSporT ; RFC 4916 traite l’identité connectée au cours du dialogue. Cette histoire confirme la prudence de RFC 3324 : une exigence de domaine n’est pas une preuve mondiale.

Sa leçon tient dans une arête. Le périmètre peut annoncer une compatibilité attendue. Seul le récepteur peut vérifier le pair immédiat, la liaison, la configuration et les règles qui donnent un sens à l’identité reçue.

Sources