Résumé

  • La RFC 3323 définit la confidentialité selon les parties auxquelles certaines informations sont cachées, et non comme une absence garantie de toute donnée identifiable.
  • Le service chargé de masquer des en-têtes peut devoir mémoriser puis rétablir l’état de routage du dialogue : la confiance se déplace vers l’intermédiaire.

L’anonymat dépend de l’observateur

En 2002, la confidentialité dans SIP n’était pas un choix binaire entre identité déclarée et anonymat. La RFC 3323 la décrit comme la rétention d’informations vis-à-vis d’une ou plusieurs parties d’un dialogue. L’appelant peut vouloir cacher son nom réel au destinataire tout en le révélant à un service de confiance. Dans une autre architecture, ce sont des détails du réseau qui sont dissimulés. Il faut donc toujours demander : invisible pour qui ?

L’exemple d’un champ From anonyme ne signifie pas que la requête ne transporte aucune adresse utile. Le document recommande anonymous.invalid pour un URI SIP anonyme, mais les requêtes ultérieures du dialogue doivent encore atteindre le bon terminal. La requête peut cacher une identité personnelle tout en conservant Contact, Via, Record-Route ou des informations de session nécessaires au fonctionnement. La confidentialité contrôle une vue de l’état du protocole ; elle n’efface pas cet état.

Le service doit se souvenir de ce qu’il cache

La RFC distingue la confidentialité demandée par l’utilisateur de celle fournie par le réseau. Le champ Privacy prévoit notamment user, header et session. none interdit au service d’appliquer ces transformations ; critical exige l’échec de la requête si le niveau demandé n’est pas disponible. Ces valeurs expriment une politique, pas une authentification, une autorisation, un chiffrement des médias ni la preuve que chaque intermédiaire l’a respectée.

La confidentialité des en-têtes révèle le coût opérationnel. Un service peut agir en B2BUA, supprimer ou réécrire les en-têtes identifiants, remplacer Contact par sa propre adresse et conserver localement les routes originales. Lorsqu’un message ultérieur revient, il doit rétablir les valeurs nécessaires à la suite du dialogue. Le destinataire voit moins, mais le service conserve davantage d’état privilégié. L’appelant n’est donc pas anonyme pour ce service.

La confidentialité de session va plus loin : elle exige un B2BUA et un équipement intermédiaire de média ou d’anonymisation du trafic. Comme le service entre dans le chemin de communication, la RFC déconseille cette protection sans chiffrement de bout en bout, par exemple SRTP. C’est une mise en garde de conception, pas une statistique d’adoption.

Cacher l’identité crée un nouveau point de contrôle

La leçon historique tient en une tension : moins le destinataire apprend, plus il peut dépendre du composant qui masque les données. Ce service choisit quoi retirer, conserver, réécrire et restaurer ; il doit être digne de confiance pour préserver la continuité du dialogue.

La RFC 3261 définit le contexte des dialogues et des routes SIP. La RFC 3325 traite ensuite de l’identité affirmée à l’intérieur d’un réseau de confiance, sans prétendre fournir un modèle général entre domaines de confiance. Ces textes couvrent des frontières voisines, pas une solution universelle. La RFC 3323 ne démontre ni déploiement ni interopérabilité. Elle documente un arbitrage précis : limiter ce qu’une partie voit tout en préservant l’état nécessaire à l’appel, et rendre visible l’intermédiaire qui porte cette responsabilité.

Sources