Résumé

  • La RFC 2385 admettait un changement de clé synchronisé, mais ne fournissait ni négociation dans le protocole ni identifiant pour piloter ce changement.
  • Avec TCP-AO, KeyID désigne le MKT du segment envoyé, tandis que RNextKeyID annonce le MKT que l'émetteur est prêt à utiliser pour les futurs segments reçus.

Le risque apparaît au milieu de la vie d'une connexion. Deux routeurs ont établi une session authentifiée, des états utiles s'y sont accumulés, puis vient le moment de remplacer la clé. Une bascule à heure fixe laisse encore voyager des segments signés avec l'ancienne clé. Un décalage entre les deux extrémités transforme alors du trafic légitime en échec d'authentification. Reconnecter résout la discordance, mais détruit précisément la continuité recherchée.

La RFC 2385 avait répondu en 1998 au besoin de protéger notamment les sessions BGP. Son option plaçait un condensat MD5 de 16 octets dans chaque segment protégé, à partir d'un secret configuré indépendamment aux deux extrémités. Le texte permettait de changer ce secret pendant la connexion à condition de synchroniser l'opération. Il ne définissait pourtant aucun échange pour y parvenir : ni numéro de clé courante, ni annonce de la clé suivante.

La RFC 5925 a remplacé TCP MD5 par TCP-AO en donnant une forme explicite à cet état. Un Master Key Tuple, ou MKT, réunit les sélecteurs de connexion, les identifiants, la matière secrète, les algorithmes et leurs paramètres. Des clés de trafic unidirectionnelles sont ensuite dérivées pour la connexion. Le contenu d'un MKT déjà instancié ne change pas, tandis que l'ensemble des MKT disponibles peut évoluer et que la connexion peut choisir un autre tuple.

Le mécanisme tient dans deux champs d'un octet. KeyID désigne le MKT utilisé pour authentifier le segment envoyé. RNextKeyID annonce le MKT entrant que cet émetteur est prêt à utiliser pour les futurs segments reçus ; le pair s'appuie sur ce signal et sur l'automate de relève pour déterminer quand changer son propre MKT d'émission et son KeyID. Ces nombres ne sont ni des secrets ni des noms globaux : ils n'ont de sens que dans la configuration partagée par les deux extrémités. Les clés étant directionnelles, envoyer avec une clé et se déclarer prêt à en recevoir une autre sont deux décisions séparées.

La relève n'exige donc plus un instant magique commun. Une extrémité installe son prochain MKT de réception et annonce par RNextKeyID qu'elle est prête à l'utiliser. Le pair observe cette annonce et détermine selon l'automate de la RFC quand changer le KeyID de ses propres envois ; le signal n'impose pas une bascule dès le segment suivant. Une période de recouvrement permet encore de vérifier les segments partis avec l'ancienne clé. La progression devient un fait observable sur le fil, pas une supposition tirée uniquement des horloges.

TCP-AO n'organise cependant pas l'origine des secrets. Il ne négocie pas les clés maîtresses et ne décide pas qui peut les fournir. Les MKT proviennent d'une configuration statique ou d'un système externe hors bande. TCP coordonne l'usage de clés déjà autorisées ; il ne crée pas cette autorisation.

Une connexion TCP MD5 existante ne pouvait pas non plus être convertie sur place. TCP-AO emploie une autre option, et la RFC 5925 interdit les deux mécanismes sur une même connexion. TCP MD5 ne permettait pas de changer d'algorithme de sécurité après l'établissement. La migration vers TCP-AO reste donc une nouvelle connexion, même si les relèves ultérieures se font sans la casser.

La RFC 5926 fixe les profils cryptographiques nécessaires à l'interopérabilité ; elle ne fixe ni la clé de l'opérateur ni un calendrier universel. TCP-AO protège authenticité et intégrité et renforce la résistance au rejeu, mais ne chiffre pas les données applicatives.

Sources primaires