Renouvellement de clé, reconnexion ou réauthentification : que vous faut-il ?

Une session ouverte depuis des heures ne gardera pas les mêmes clés indéfiniment, et c’est voulu. Trois événements différents sont décrits comme une rotation de clés : du nouveau matériel de session sous une association existante, une reconstruction complète de la connexion et une répétition du contrôle d’identité. Chacun a un déclencheur, un coût et une signature de panne différents. Choisissez le mauvais et le correctif ne fait rien ou coupe le tunnel sans raison.

La décision dépend de la couche qui a réellement expiré.

Trois opérations qu’on appelle rotation

Un renouvellement de clé crée de nouvelles clés de trafic au sein de la relation de contrôle existante, grâce au mécanisme défini par le protocole. IKEv2 le fait avec une nouvelle association de sécurité enfant, TLS 1.3 avec un message de mise à jour de clé, et WireGuard avec une nouvelle poignée de main dès que ses limites de temps ou de messages sont atteintes. Les adresses du tunnel et l’identité authentifiée restent où elles étaient.

Une reconnexion jette la connexion et la reconstruit depuis le début, ce qui répète l’attribution d’adresses, l’installation des routes et toute négociation effectuée par la première tentative.

La réauthentification répète la preuve d’identité elle-même, ce qui peut impliquer un identifiant, un certificat ou un second facteur. Elle peut se produire avec ou sans reconnexion, selon le produit.

Ce que les utilisateurs remarquent au renouvellement

Un renouvellement de clé devrait être presque invisible. Les identifiants d’association changent, les compteurs peuvent être réinitialisés et les applications conservent leurs sockets ; une brève pause dans un sens est normale pendant l’échange. Voir un nouvel identifiant dans une liste d’état n’est pas la preuve d’une panne. La ligne de journal qui suit l’échange est ce qui vous dit s’il s’est terminé.

Une vraie coupure au renouvellement pointe un endroit précis. Une incompatibilité de proposition, un identifiant expiré ou un changement de chemin produisent chacun une ligne de journal différente, et un seul d’entre eux se corrige en ajustant les durées de vie.

Où les trois divergent en pratique

Si seul le matériel de clé a expiré, renouvelez la clé. Si l’adresse du pair, la route ou la liaison NAT ont changé et que les paquets n’arrivent plus, reconnectez. Si l’organisation exige un contrôle d’identité périodique, c’est une réauthentification et aucun réglage des durées de vie ne la remplace.

Les valeurs par défaut des protocoles contiennent généralement la bonne réponse. WireGuard renouvelle ses clés après un seuil de temps et de volume de données sans action de l’utilisateur ; les durées de vie IKEv2 se négocient par association enfant ; les tunnels basés sur TLS font tourner les clés dans la session existante. Augmenter les durées de vie pour éviter une erreur récurrente ne fait que reporter la panne et allonge l’exposition si une clé est compromise.

Une réserve compte pour les sessions longues : la fréquence seule ne crée pas de confidentialité persistante. La propriété dépend de la relation entre les clés de session et les secrets de long terme, et de la destruction des anciennes clés, ce qui relève de la conception et de l’implémentation, pas d’un réglage.

Choisissez les valeurs par défaut, puis consignez l’étape

Gardez les valeurs par défaut du fournisseur sauf si une exigence documentée dit le contraire, et modifiez les durées de vie des deux côtés si vous les modifiez. Consignez ensuite l’étape atteinte par chaque événement, afin que l’occurrence suivante puisse être vérifiée au même point de la poignée de main.

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

Après une correction, effectuez un renouvellement contrôlé et envoyez du trafic applicatif neuf via la nouvelle association. Un tunnel qui se déclare établi mais ne transmet rien est la panne que ce contrôle existe pour attraper.