Résumé

  • RFC 5197 compare plusieurs modes MIKEY précisément parce qu’ils ne donnent pas les mêmes garanties : le PSK est simple et performant, mais il n’offre pas de confidentialité persistante et seul l’initiateur produit le matériel de clé.
  • Il faut enregistrer, pour chaque session, le mode exécuté, ses prérequis, les contributions des deux parties, l’état anti-rejeu, la portée TGK/TEK, le moment où la clé devient utilisable et les propriétés effectivement obtenues.

La confidentialité persistante est une question rétrospective

La confidentialité persistante, ou PFS, ne décrit pas la solidité apparente d’un échange aujourd’hui. Elle demande ce qui arrivera aux sessions passées si un secret de longue durée est compromis demain. Cette différence temporelle explique pourquoi un contrôle effectué au moment de l’appel peut produire un résultat vert tout en préparant une perte future.

Dans MIKEY-PSK, un secret partagé à l’avance protège l’intégrité et le chiffrement du transport du matériel de clé. Le mode consomme peu de bande passante, évite une PKI et convient bien à de petits ensembles. RFC 3830 le rend obligatoire à implémenter. Aucun de ces avantages n’implique la PFS. RFC 5197 indique au contraire qu’elle n’est pas fournie et que l’initiateur seul génère le matériel.

Le mot « obligatoire » crée ici une confusion fréquente. Il qualifie une capacité d’interopérabilité de l’implémentation, pas le choix fait pour une session, encore moins le résultat cryptographique de cette session. Un produit peut prendre en charge PSK sans l’avoir sélectionné ; une session peut réussir en PSK sans satisfaire une politique exigeant PFS et contribution mutuelle.

Changer de mode change le modèle de pouvoir

Le mode RSA déplace le prérequis vers le certificat du répondant, qui doit être connu de l’initiateur avant l’échange. Il facilite une montée en charge fondée sur la PKI, mais ne fournit pas davantage de PFS et laisse encore l’initiateur créer le matériel de clé. La validation du certificat peut aussi dépendre d’un composant séparé ; un chemin valide ne prouve pas que l’état de révocation a été obtenu en temps réel.

DH-SIGN pose une autre structure. Les deux parties contribuent au secret partagé et le mode fournit la PFS. Les signatures protègent l’accord, mais le déploiement à grande échelle conserve une dépendance à une infrastructure de certificats digne de confiance. Le mode vise surtout le point à point et ne devient pas, par son seul nom, un mécanisme complet de conférence multipoint.

DH-HMAC garde la contribution bilatérale et la PFS tout en remplaçant la PKI par un secret prépartagé. C’est utile lorsqu’un serveur central de confiance partage déjà des secrets avec de nombreux clients. Ce n’est pourtant pas une victoire universelle : il faut toujours provisionner ces secrets et la prise en charge de groupes reste limitée.

RSA-R répond à une contrainte différente : le certificat du répondant peut arriver dans la bande, ce qui aide lorsque le destinataire final dépend d’un fork ou d’un retargeting. L’initiateur peut proposer un aléa, mais il ne peut pas contraindre le répondant à l’utiliser honnêtement. RFC 5197 refuse donc d’en déduire une vraie PFS. La commodité de découverte n’est pas une propriété de confidentialité.

La clé possède une histoire et une portée

MIKEY peut établir plusieurs Crypto Sessions dans un même Crypto Session Bundle. Elles peuvent partager une TGK et des paramètres tout en dérivant des TEK distinctes. Un journal limité à « CSB créé » ne suffit pas pour savoir quelle clé a protégé quel flux, ni quels répondants ont reçu un matériel commun.

Cette portée devient critique avec le forking SIP. Un message peut atteindre plusieurs destinations. Si deux branches utilisent la même TEK et choisissent le même SSRC de 32 bits, la dérivation SRTP peut produire les mêmes clés de session et vecteurs d’initialisation. RFC 5197 expose alors le risque de two-time pad. Ce n’est pas la probabilité abstraite d’une collision qu’il faut archiver, mais la liste des branches, la portée de la TEK et le résultat de la détection de collision.

Le temps compte aussi pour le rejeu. MIKEY combine des horodatages et un cache, sans échange challenge-réponse dédié. La synchronisation des horloges, la fenêtre de tolérance et la capacité du cache participent donc à la garantie. Après un redémarrage ou sous pression mémoire, la même validation de message peut reposer sur un état moins fort. Le reçu doit garder la source de temps, le skew admis, l’horizon du cache et la décision prise pour ce message.

Un reçu de propriétés, pas un label de produit

Le reçu commence avant l’échange : identités visées, mode choisi, PSK ou certificats disponibles, limites de confiance des couches inférieures. Il conserve ensuite le condensat de la transcription, la validation d’identité, la fraîcheur de révocation, les contributions d’aléa et la conclusion explicite sur la PFS.

Il rattache la TGK au CSB, les TEK à leurs Crypto Sessions et chaque branche à son répondant. Il enregistre l’horodatage, l’état du cache anti-rejeu, l’instant d’installation de la clé, le premier paquet SRTP et le premier déchiffrement réussi. Les valeurs secrètes n’ont pas à être divulguées ; leurs identités, leur portée et leur cycle de vie doivent l’être.

Cette construction n’est pas une exigence supplémentaire de RFC 5197. C’est la conséquence opérationnelle de son analyse : sélectionné, authentifié, terminé, installé et utilisable sont des états différents. La PFS est encore une autre propriété. Les réunir sous « sécurisé » donne au tableau de bord une autorité que l’échange ne lui a jamais confiée.

Sources

  1. RFC 5197 en HTML
  2. RFC 5197 en texte
  3. Fiche RFC 5197
  4. Datatracker IETF : RFC 5197
  5. Historique de RFC 5197
  6. Références de RFC 5197
  7. Errata de RFC 5197
  8. RFC 3830 — MIKEY
  9. RFC 3711 — SRTP
  10. RFC 4650 — MIKEY DH-HMAC
  11. RFC 4738 — MIKEY RSA-R
  12. RFC 4567 — extensions de gestion de clés
  13. RFC 4568 — descriptions de sécurité des flux
  14. RFC 5027 — préconditions de sécurité SDP
  15. RFC 4086 — exigences d’aléa
  16. RFC 4082 — TESLA
  17. RFC 4442 — amorçage de TESLA
  18. Heng Lu — couches de réalité et pouvoir symbolique
  19. Heng Lu — spécification initiale minimale
  20. Heng Lu — primauté du code en fonctionnement