Durées de vie des SA dans IKEv2 : renouvellement de clés doux, expiration dure, réauthentification séparée

Les minuteries décident quand les clés d'un tunnel sont remplacées, et les deux seuils impliqués sont souvent lus comme un seul. Ils ne le sont pas. Une durée de vie douce demande au pair de construire un remplacement tant que l'association de sécurité actuelle transporte encore du trafic, et une durée de vie dure est l'échéance après laquelle l'ancienne association a disparu, que le remplacement ait fonctionné ou non. Entre les deux se trouve une fenêtre de chevauchement qui existe pour que les paquets ne tombent pas dans un trou.

Ce que borne réellement une durée de vie

Une association de sécurité IPsec est un ensemble d'état cryptographique : des clés pour une direction, un index de paramètres de sécurité, un jeu d'algorithmes et un sélecteur. La durée de vie borne combien de temps cet état peut être utilisé, ce qui limite la quantité de trafic qu'une clé protège. C'est une mesure de confinement pour la clé, pas une affirmation sur la durée que devrait avoir une session utilisateur.

Les associations de contrôle IKE ont leurs propres clés et leurs propres durées de vie, distinctes des associations enfant qui transportent les données. C'est le premier endroit où l'on confond deux calendriers.

Le doux lance le remplacement, le dur termine l'ancien état

Quand le seuil doux approche, le pair lance un remplacement. Les implémentations se déclenchent généralement tôt et randomisent le moment pour qu'un concentrateur avec des centaines de tunnels ne renouvelle pas toutes les clés d'un coup. Dans IKEv2, le remplacement est un échange CREATE_CHILD_SA portant de nouveaux nonces, plus un échange Diffie-Hellman quand la confidentialité persistante est configurée. Le résultat est une nouvelle paire d'associations avec de nouvelles clés.

Le chevauchement compte. Pendant un court moment, le pair peut garder l'ancienne et la nouvelle association, et une capture peut montrer deux jeux d'identifiants. C'est le mécanisme qui fonctionne, pas une panne.

Le seuil dur ne pardonne pas. Si le remplacement n'est pas terminé à ce moment-là, l'ancienne association doit être retirée et le trafic protégé par elle seule s'arrête. Des renouvellements de clés ratés à répétition qui vont jusqu'à l'expiration dure sont le signal opérationnel à examiner, car le tunnel est maintenu debout par une échéance à chaque cycle.

Les limites d'usage peuvent se déclencher avant toute horloge

Le temps n'est pas la seule borne. Les implémentations peuvent plafonner les octets ou les paquets protégés par une clé, et un tunnel chargé atteindra une limite d'usage bien avant une minuterie de plusieurs heures. strongSwan expose des réglages distincts de durée de vie et de marge pour le temps, les octets et les paquets, ce qui signifie que le point de renouvellement effectif est le seuil qui arrive en premier, moins la marge configurée.

Quand un tunnel se renouvelle bien plus souvent que ne le suggèrent ses heures configurées, vérifiez les limites d'octets et de paquets avant de blâmer l'horloge. Un lien saturé et un lien inactif avec les mêmes réglages de temps auront des taux de renouvellement visiblement différents, et un seul des deux suit la minuterie.

Chaque pair applique sa propre politique

IKEv2 ne négocie pas une durée de vie unique que les deux pairs devraient afficher à l'identique. Chaque côté applique sa politique locale et peut lancer le remplacement quand sa propre limite approche, comme décrit dans RFC 7296 section 2.8. Un écart entre les heures configurées de deux pairs n'est donc pas automatiquement un défaut, même si des valeurs très différentes peuvent provoquer de l'agitation si un côté remplace sans cesse un état que l'autre vient d'installer.

Coordonner signifie un comportement compatible : des fenêtres de chevauchement assez longues pour l'échange, des marges qui laissent de la place aux nouvelles tentatives et une supervision qui montre quel côté a lancé chaque renouvellement.

Renouveler les clés n'est pas réauthentifier

Un renouvellement de clés rafraîchit les clés dans le cadre de la relation authentifiée existante. Une réauthentification répète la vérification d'identité, qu'il s'agisse d'un échange de certificats ou d'une conversation EAP. Les deux fonctionnent selon des calendriers distincts et un renouvellement réussi ne dit rien sur la question de savoir si le compte devrait toujours avoir accès.

Cette distinction compte pour la révocation. Désactiver un compte, révoquer un certificat ou mettre fin à une session sont des décisions d'accès qui exigent une politique explicite dans l'implémentation ; elles ne découlent pas de la minuterie de la SA, et un renouvellement peut continuer tranquillement pour une identité déjà dépouillée de ses droits.

Ce qu'il faut consigner par tunnel

Consignez quelle association a déclenché le renouvellement, les identifiants ancien et nouveau, quel seuil s'est déclenché et si le remplacement s'est achevé dans le chevauchement. Ces quatre champs rendent un problème de renouvellement visible avant qu'il ne devienne une panne, et ils distinguent une politique agressive d'une politique qui échoue.

Gardez le calendrier de retrait d'accès à côté de cet enregistrement plutôt qu'à l'intérieur. L'hygiène cryptographique et la politique d'identité sont des contrôles différents, et un tunnel qui fait tourner les clés à temps peut encore détenir une session que personne ne comptait conserver.