Résumé

  • P-Preferred-Identity était une indication permettant de choisir parmi les identités valides du sujet authentifié ; le proxy devait la supprimer de tout message retransmis.
  • Une P-Asserted-Identity venant d’une source non fiable devait être remplacée par une identité construite après authentification ou être retirée, car le nom de l’en-tête ne conférait aucune autorité.

Le choix entrait, la preuve sortait

Le champ From de SIP permettait au correspondant de présenter l’alias souhaité. Ce comportement servait la conversation, mais ne suffisait pas aux réseaux de téléphonie qui voulaient fournir l’identité appelante, tracer l’origine ou préserver certaines fonctions tout en masquant l’identité au destinataire. RFC 3325 ajouta deux champs privés dont la proximité lexicale pouvait cacher une différence de pouvoir.

P-Preferred-Identity venait de l’agent utilisateur. Elle disait au proxy : parmi les identités qui m’appartiennent réellement après authentification, je préfère celle-ci. P-Asserted-Identity venait du réseau de confiance. Elle disait qu’un intermédiaire avait authentifié l’origine ou accepté le résultat d’un pair de confiance. From, préférence et affirmation n’étaient donc pas trois versions graduées d’un même nom, mais trois actes attribués à des autorités différentes.

Lorsqu’un proxy recevait une préférence d’une entité qu’il ne considérait pas comme fiable, il pouvait s’en servir comme indication seulement. Il devait comparer la valeur à l’ensemble des identités valides connues pour l’utilisateur authentifié. Si aucune ne correspondait, il pouvait produire une autre affirmation ou rejeter la requête. Il ne pouvait pas transformer le souhait en vérité par simple copie.

Après la décision, le proxy devait supprimer la P-Preferred-Identity fournie par l’utilisateur de chaque message qu’il retransmettait. Cette destruction préservait la provenance. En aval, il ne restait que l’identité affirmée par le réseau, non la suggestion qui avait participé au choix. Si les deux survivaient, une archive ou un service pourrait plus tard compter le même renseignement deux fois : une fois comme préférence et une fois comme confirmation.

Une fausse affirmation devait être reconstruite

La règle était encore plus stricte pour P-Asserted-Identity reçue d’un élément non fiable. Si le proxy voulait ajouter une affirmation, il devait d’abord authentifier l’expéditeur et employer l’identité issue de cette authentification. Un utilisateur capable d’écrire correctement le nom du champ ne devenait pas pour autant une autorité.

Si l’entrée non fiable comportait déjà une identité SIP ou SIPS, le proxy devait la remplacer par une seule valeur SIP ou SIPS qu’il construisait, ou supprimer le champ. La valeur téléphonique suivait la même règle. La solution ne consistait pas à conserver la valeur et à ajouter un marqueur de confiance. L’ancienne autorité devait être détruite ou entièrement refaite à partir d’éléments que le proxy maîtrisait.

Une affirmation venant d’un nœud que le proxy faisait confiance pouvait au contraire être utilisée comme s’il avait lui-même authentifié l’utilisateur. Ce raccourci héritait de RFC 3324 : connexion sûre, appartenance configurée et Spec(T) décrivant authentification, sécurité, membres, politique de confidentialité et conformité. Il ne transformait pas le champ en certificat cryptographique de bout en bout.

L’énoncé d’applicabilité l’admettait sans détour. Les identités affirmées n’étaient pas certifiées cryptographiquement et n’indiquaient pas quel acteur précis les affirmait ; on devait attribuer l’affirmation au domaine. Hors de l’architecture déclarée, elles restaient exposées à la falsification, au rejeu et à la contrefaçon. Le mécanisme n’était pas un modèle général pour l’Internet.

La confidentialité exigeait une deuxième suppression

Après la reconstruction à l’entrée, chaque proxy devait qualifier le prochain saut. Vers un nœud fiable, il conservait les affirmations qu’il avait produites ou reçues d’une source fiable. Vers un nœud non fiable, il examinait Privacy.

La valeur id obligeait à retirer toutes les P-Asserted-Identity avant transmission. La valeur opposée none interdisait cette suppression. Sans champ Privacy, Spec(T) devait fixer la politique. RFC 3325 recommandait en principe de garder l’identité pour éviter l’échec de services, mais avertissait que sa transmission pouvait révéler des informations que l’utilisateur n’avait ni demandées ni les moyens d’empêcher si le service de confidentialité n’était pas accessible.

Une ou deux identités affirmées pouvaient être présentes : avec deux, l’une devait être SIP ou SIPS et l’autre téléphonique. Lorsque la confidentialité s’appliquait, toutes devaient disparaître. Supprimer une seule représentation laisserait passer le même sujet sous une autre forme.

Le serveur utilisateur conservait la même discipline. Si le message venait d’un élément précédent non fiable, il ne devait utiliser P-Asserted-Identity d’aucune manière. Dans le domaine approprié, le service pouvait choisir son affichage ; le RFC n’imposait pas comment résoudre plusieurs valeurs typées.

RFC 5876 a ensuite mis à jour le mécanisme. RFC 4474, RFC 8224 et RFC 8225 ont développé d’autres formes d’identité authentifiée et PASSporT ; RFC 4916 a traité l’identité connectée. Ces suites ne changent pas la leçon initiale : l’autorité n’était pas dans l’orthographe du champ, mais dans une transformation contrôlée, accompagnée de suppressions vérifiables.

RFC 3325 montre ainsi qu’une entrée légitime peut influencer une décision sans devenir elle-même une preuve. Le proxy ne produisait une affirmation qu’en refusant de laisser le souhait de l’utilisateur survivre comme s’il était son propre résultat.

Sources