Résumé
- Le projet RSVP Cryptographic Authentication v2 est en dernière consultation du groupe de travail TEAS jusqu'au 30 septembre 2026. Sa version 02 date du 27 septembre ; aucun RFC final n'en résulte encore.
- Si une autre association de sécurité valide existe, un message signé avec l'ancienne association expirée doit être écarté. Si toutes ont expiré, le texte propose de vérifier le message avec la dernière et de prolonger exceptionnellement son usage.
- La prolongation n'est ni un passage au trafic non authentifié ni une preuve que l'ancienne clé est saine : elle crée un devoir de signalement, de remplacement et de clôture explicite.
Le problème commence dans une salle d'exploitation, pas dans une table d'algorithmes. Une association de sécurité RSVP arrive à expiration ; la nouvelle n'a pas été installée partout. Couper brutalement les messages risque de perturber les réservations dont dépend la signalisation. Le projet TEAS choisit de ne pas abandonner l'authentification pour préserver ce service. Il décrit plutôt ce que peut faire un système quand il ne lui reste aucune association encore dans sa période de validité.
La procédure de réception fixe d'abord une frontière nette. Un paquet associé à une clé expirée doit être rejeté sans même lancer sa vérification cryptographique si une autre association valide est disponible. À l'inverse, en l'absence de remplaçante valide à l'heure de réception, l'ancienne association sert à vérifier le paquet.
L'article 5.4 du projet traite ensuite du cas extrême où toutes les associations applicables ont expiré : le système devrait alerter le responsable du réseau et traiter la dernière association comme si sa durée était infinie, jusqu'à prolongation, suppression par l'exploitation ou configuration d'une nouvelle association.
Ce choix ne transforme pas une signature périmée en autorisation neuve. Le contrôle cryptographique du message demeure ; c'est la borne de durée de l'association qui devient exceptionnelle. Il faut donc séparer deux assertions souvent confondues : « le paquet correspond à la clé connue » et « l'emploi de cette clé respecte encore le calendrier prévu ». La première peut être vérifiée par le protocole. La seconde relève désormais d'une décision de continuité dont il faut garder la trace.
Le même projet donne les moyens d'éviter normalement cette situation. Chaque interface ou voisin protégé doit pouvoir conserver au moins deux associations actives pour permettre une transition. Des durées qui se chevauchent compensent les écarts d'horloge ; l'identifiant de clé et l'adresse de l'émetteur permettent de retrouver l'association voulue. Mais une capacité exigée d'une implémentation n'atteste ni la préparation des opérateurs, ni la présence d'une seconde clé, ni la réussite d'un basculement réel.
La chronologie des travaux est limitée. Le groupe TEAS a ouvert sa consultation le 16 septembre, avec une échéance au 30. Le 21, un relecteur de la direction Sécurité a jugé la version 01 prête, estimant que le compromis du cas pathologique était désormais expliqué. La version 02, publiée le 27, ajoute surtout des références et des ajustements rédactionnels, ainsi qu'une note au registre proposé ; l'exception de la dernière association existait déjà. Cet avis individuel n'est pas une approbation de l'IESG, encore moins une mesure sur les réseaux en service.
Le texte de base reste indépendant d'un algorithme obligatoire. Le registre IANA qu'il propose mentionne HMAC-MD5 avec le statut SHOULD et une note indiquant son caractère ancien, voué à être abandonné. Un autre projet du même groupe précise HMAC-SHA2. Ni cette juxtaposition ni l'état du registre ne permettent de déduire quelle transformation cryptographique fonctionne dans un routeur donné.
Pour rendre l'exception responsable, un journal local pourrait dater l'alerte, identifier les voisins concernés, conserver les observations de messages acceptés pendant la période de grâce et montrer à quel moment la nouvelle association a réellement pris le relais. C'est une proposition d'analyse de Daniel Kade, non une prescription du groupe TEAS. La continuité est défendable comme choix circonstancié ; elle ne devrait pas devenir un renouvellement tacite et perpétuel.
Sources
- https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-auth-v2/
- https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-auth-v2/history/
- https://www.ietf.org/archive/id/draft-ietf-teas-rsvp-auth-v2-02.txt
- https://www.ietf.org/archive/id/draft-ietf-teas-rsvp-auth-v2-01.txt
- https://datatracker.ietf.org/doc/review-ietf-teas-rsvp-auth-v2-01-secdir-early-emery-2026-09-21/
- https://mailarchive.ietf.org/arch/msg/saag/Cf5W9PszpNce8EXLiuxgHMBKnm8/
- https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-hmac-sha2/
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

