Résumé

  • RFC 3329 faisait échanger au terminal et à son premier saut des listes de capacités, activer le mécanisme commun préféré, puis renvoyer toute la liste statique du serveur dans Security-Verify sous la protection choisie.
  • Le procédé rendait une suppression détectable sans garantir la meilleure sécurité moderne : sa résistance reposait sur l’intégrité et l’anti-rejeu du mécanisme le plus faible encore autorisé.

Il fallait choisir la protection dans un message non protégé

Un réseau ne remplace pas tous ses terminaux le même jour. Certains appareils SIP pouvaient connaître HTTP Digest, d’autres TLS ou IPsec. Imposer une configuration identique à chaque extrémité rendait la migration rigide. Essayer les mécanismes les uns après les autres créait une autre faiblesse : un faux échec pouvait faire passer une capacité disponible pour une capacité absente.

La négociation semblait naturelle. Le client annonçait ses moyens, le serveur classait les siens, puis les deux retenaient le meilleur mécanisme commun. Mais les annonces initiales arrivaient avant l’ouverture de la protection. Un intermédiaire pouvait retirer TLS, conserver Digest et laisser les deux pairs conclure que l’autre n’avait jamais proposé le chiffrement. L’attaque paraissait compatible parce qu’elle ménageait une solution plus faible.

RFC 3329 a réparti la preuve dans le temps. Le client envoyait Security-Client à son prochain saut. Le serveur répondait avec une liste Security-Server statique et ordonnée par préférence, accompagnée des éléments nécessaires au démarrage. Le client choisissait le mécanisme connu ayant la préférence la plus élevée, l’activait, puis renvoyait la liste reçue dans Security-Verify. Le serveur comparait ce reçu à sa propre politique.

La comparaison portait sur les mécanismes, leur ordre et leurs paramètres. Si un attaquant avait supprimé l’option la plus forte dans la première réponse, le client retournait une liste raccourcie. Le serveur, dont la liste statique était restée complète, constatait l’écart et refusait de traiter la requête.

Pour dissimuler l’écart, l’attaquant devait aussi modifier le second message. Or celui-ci empruntait désormais le mécanisme choisi. Une suppression triviale devenait une falsification en temps réel de l’intégrité établie. Le premier échange n’était pas rétroactivement sûr ; sa manipulation devenait vérifiable plus tard.

Une politique statique permettait une vérification sans mémoire de session

Le serveur ne devait pas calculer sa liste à partir de Security-Client. Sinon, l’attaquant aurait pu réduire l’offre du client, faire adapter la réponse du serveur et obtenir deux listes cohérentes mais abaissées. La liste du serveur restait indépendante de l’entrée. Plusieurs listes pouvaient exister, par exemple une par interface, mais chacune représentait une politique déterminée.

Cette règle évitait aussi un nouvel état SIP par client. Le serveur comparait le reçu à sa configuration, sans conserver un défi personnalisé. Le mécanisme sous-jacent gardait éventuellement un état — connexion TLS ou association IPsec — mais la vérification de la liste ne nécessitait pas sa propre table de négociation.

Les valeurs q devaient être distinctes. Le client choisissait, parmi les mécanismes qu’il connaissait, celui qui portait la préférence maximale du serveur. Une altération de la liste cliente pouvait empêcher le serveur de fournir les paramètres d’initiation ou conduire les pairs à des choix différents. L’échec signalait alors une attaque possible, non une identité coupable démontrée.

La portée était le terminal et son prochain saut SIP. Pour lancer l’accord côté serveur, une seule entrée Via devait apparaître ; plusieurs Via prouvaient qu’il ne s’agissait plus du premier saut. Le mécanisme ne protégeait donc ni toute la chaîne de mandataires, ni automatiquement le corps du message, ni la communication de bout en bout.

Les codes 421 et 494 racontaient des états différents

Dans l’initiative cliente, la requête non protégée contenait Security-Client ainsi que Require et Proxy-Require avec sec-agree. Le serveur répondait 494 Security Agreement Required et envoyait sa liste même lorsqu’aucun mécanisme commun n’existait.

Un serveur pouvait également imposer l’accord par politique locale. Un client qui ne signalait pas le support recevait 421 Extension Required. Un client qui annonçait sec-agree mais n’avait pas encore achevé l’accord recevait 494. Les deux réponses incluaient les capacités du serveur et les données de lancement nécessaires.

Ces codes n’étaient pas des verdicts d’incident. Un 421 pouvait désigner un vieux terminal ou une option perdue. Un 494 pouvait être le début normal, la réaction à une divergence ou la reprise d’un état expiré. Le dossier utile devait conserver les deux listes, le choix, la protection, la comparaison et la décision.

L’activation dépendait du mécanisme. TLS ouvrait une connexion protégée selon les règles de localisation SIP, en traitant l’URI comme sécurisée une fois TLS choisi. Digest réutilisait l’authentification et couvrait la liste du serveur dans son calcul de vérification. IPsec-IKE lançait IKE ; IPsec manuel dépendait de clés et de politiques hors bande. RFC 3310 ajoutait un voisin Digest fondé sur AKA, sans remplacer le retour de la liste.

La durée restait propre à chaque association : fermeture TLS, durée négociée par IKE, nouveau défi Digest ou règle hors bande. Dire que l’accord avait réussi sans identifiant d’association ni condition de fin laissait la moitié du fait hors du registre.

La compatibilité la plus faible fixait le plancher

La limite de sécurité était explicite. Le mécanisme le plus faible proposé devait encore protéger l’intégrité et empêcher le rejeu de Security-Verify. Si un adversaire pouvait le briser, il ne devait pas rester une option acceptable. La négociation supprimait le déclassement facile ; elle ne réparait pas un algorithme faible.

Elle ne promettait pas non plus le chiffrement. Digest pouvait authentifier et protéger des valeurs sans masquer le contenu SIP. TLS protégeait un saut. IPsec dépendait de l’association réellement établie. Une liste égale prouvait une correspondance entre politique et reçu à un point donné, pas la confidentialité globale.

Le temps a déplacé le minimum acceptable. Publié en janvier 2003, RFC 3329 a été mis à jour par RFC 8996, qui interdit désormais TLS 1.0 et TLS 1.1. RFC 8446 décrit TLS 1.3 et RFC 7616 modernise Digest. Le mécanisme historique reste lisible, mais le mot tls ne valide pas toutes ses anciennes versions.

Les errata imposent aussi de distinguer norme et exemple. Deux passages illustratifs mettent Security-Verify dans ACK, alors que le tableau normatif le rend inapplicable ; leur correction est retenue pour une future mise à jour. Un erratum vérifié corrige la longueur du SPI ipsec-3gpp. Le registre IANA documente les noms, sans démontrer leur usage ni leur sûreté actuelle.

La leçon durable de RFC 3329 est celle d’une preuve différée. Quand la capacité de protéger arrive après l’offre, il faut transporter l’offre jusqu’au moment où elle peut être rendue et comparée. Le reçu intact prouve une continuité bornée. La qualité de la politique demeure une question distincte.

Sources