Aller au contenu principal

2.8. Rekeying

2.8. Rekeying​

Les IKE, ESP et AH Security Associations utilisent des clés secrètes pour une durée et un volume de données limités, ce qui borne la durée de vie de la SA. Une SA expirée NE DOIT PAS être utilisée. De nouvelles SA PEUVENT être créées si nécessaire. Le remplacement des SA expirées s'appelle « rekeying ».

Pour les implémentations IPsec minimales, le rekey sans redémarrer toute l'IKE SA est optionnel. Une implémentation PEUT refuser tous les CREATE_CHILD_SA dans une IKE SA. Si une SA a expiré ou va expirer et que le rekey échoue, l'implémentation DOIT fermer l'IKE SA et les Child SA associées, puis PEUT en créer de nouvelles. Le rekey sur place améliore les performances et réduit souvent la perte de paquets.

Pour rekey un Child SA dans une IKE SA existante, créer une SA équivalente (Section 2.17), puis supprimer l'ancienne une fois la nouvelle établie. Lors d'un rekey, le nouveau Child SA NE DEVRAIT PAS différer par sélecteurs de trafic ni algorithmes.

Pour rekey une IKE SA, établir une nouvelle IKE SA équivalente (Section 2.18) via CREATE_CHILD_SA dans l'IKE SA actuelle. Elle hérite de tous les Child SA ; la nouvelle IKE SA porte le trafic de contrôle. Après création, l'initiateur supprime l'ancienne IKE SA ; la charge Delete pour soi-même DOIT être la dernière requête sur l'ancienne IKE SA.

Le rekey doit être proactif : la nouvelle SA avant expiration de l'ancienne, avec marge pour basculer le trafic.

IKEv1 négociait les durées de vie ; en IKEv2 chaque extrémité applique sa propre politique. Si les politiques diffèrent, celle au plus court délai demandera toujours le rekey. SA inactive longtemps : l'extrémité PEUT fermer plutôt que rekey à expiration, ou s'il n'y a pas eu de trafic depuis le dernier rekey.

IKEv2 autorise des SA parallèles avec les mêmes Traffic Selectors (QoS, voir [DIFFSERVFIELD], [DIFFSERVARCH], [DIFFTUNNEL] §4.1). Contrairement à IKEv1, extrémités + sélecteurs n'identifient pas toujours une SA ; l'heuristique IKEv1 de suppression par sélecteurs dupliqués NE DEVRAIT PAS être utilisée.

Avec pertes de paquets, les extrémités peuvent désaccorder sur l'état d'une SA. Le répondant à CREATE_CHILD_SA DOIT accepter des messages sur une SA avant d'envoyer sa réponse de création. L'initiateur PEUT émettre dès traitement de la réponse mais ne peut recevoir sur la nouvelle SA qu'après réception et traitement de cette réponse. Le répondant PEUT émettre dès envoi de sa réponse (correct en interop) mais PEUT différer pour éviter des pertes inutiles.

Le répondant sait que l'initiateur est prêt à recevoir si (1) il a reçu un message valide sur l'autre moitié de la paire, ou (2) la nouvelle SA rekey une existante et une requête IKE ferme l'ancienne. Lors d'un rekey, le répondant continue sur l'ancienne SA jusqu'à l'un de ces événements. Nouvelle SA : il PEUT attendre un message entrant ou un timeout. Si l'initiateur reçoit sans avoir eu la réponse CREATE_CHILD_SA, il retransmet. Il PEUT envoyer un paquet ESP factice sur un nouvel ESP SA vide pour signaler sa disponibilité.

2.8.1. Simultaneous Child SA Rekeying​

Mêmes politiques de durée : rekey simultané possible (SA redondantes). Les demandes DEVRAIENT être jitterées.

Plusieurs SA similaires peuvent coexister brièvement ; un nœud DOIT accepter les paquets sur l'une ou l'autre SA éligible. En cas de collision, la SA créée avec le plus petit des quatre nonces DEVRAIT être fermée par son créateur. « Plus petit » = comparaison octet par octet ; si une nonce se termine avant, elle est plus petite. Le nœud qui a initié la SA rekey survivante DEVRAIT supprimer l'ancienne après établissement.

Exemple avec A et B et paire (SPIa1,SPIb1) :

Host A                            Host B
-------------------------------------------------------------------
send req1: N(REKEY_SA,SPIa1),
    SA(..,SPIa2,..),Ni1,..  -->
                                <--  send req2: N(REKEY_SA,SPIb1),
                                         SA(..,SPIb2,..),Ni2
recv req2 <--

A sait qu'un rekey simultané se produit mais pas encore quel nonce est minimal.

send resp2: SA(..,SPIa3,..),
     Nr1,..  -->
                                -->  recv req1

B le sait aussi et répond.

                              <--  send resp1: SA(..,SPIb3,..),
                                       Nr2,..
recv resp1 <--
                              -->  recv resp2

Trois paires existent. Si Nr1 dans resp2 est minimal, B (req2) supprime le nouveau redondant, A supprime l'ancien.

send req3: D(SPIa1) -->
                                <--  send req4: D(SPIb2)
                                -->  recv req3
                                <--  send resp3: D(SPIb1)
recv req4 <--
send resp4: D(SPIa3) -->

Avec perte du premier req1 de A :

Host A                            Host B
-------------------------------------------------------------------
send req1: N(REKEY_SA,SPIa1),
    SA(..,SPIa2,..),
    Ni1,..  -->  (lost)
                                <--  send req2: N(REKEY_SA,SPIb1),
                                         SA(..,SPIb2,..),Ni2
recv req2 <--
send resp2: SA(..,SPIa3,..),
    Nr1,.. -->
                                -->  recv resp2
                                <--  send req3: D(SPIb1)
recv req3 <--
send resp3: D(SPIa1) -->
                                -->  recv resp3

B croit le rekey terminé sans savoir que A retransmettra req1.

resend req1 -->
                                -->  recv req1

B répond par exemple CHILD_SA_NOT_FOUND.

                               <--  send resp1: N(CHILD_SA_NOT_FOUND)
recv resp1 <--

A peut ignorer l'erreur s'il sait déjà qu'un rekey simultané a eu lieu.

2.8.2. Simultaneous IKE SA Rekeying​

Le cas le plus complexe : rekey simultané de IKE_SA. La Section 2.8 s'applique ; les Child SA doivent hériter de la bonne IKE_SA.

Si les deux extrémités détectent le simultané, comme pour Child SA : trois IKE SA après CREATE_CHILD_SA. La nouvelle IKE SA au nonce minimal DEVRAIT être supprimée par son créateur ; l'autre nouvelle IKE SA DOIT hériter de tous les Child SA.

Cas particulier : une extrémité termine avant de remarquer l'autre. Sans détection des deux côtés, pas de SA redondantes. L'extrémité qui n'a pas vu le simultané et reçoit un rekey d'une IKE SA déjà rekeyée DEVRAIT renvoyer TEMPORARY_FAILURE (IKE SA en cours de fermeture). Si l'autre extrémité reçoit la suppression de l'ancienne IKE SA, elle comprend que le pair n'a pas vu le simultané et peut abandonner sa propre tentative.

Host A                      Host B
-------------------------------------------------------------------
send req1:
     SA(..,SPIa1,..),Ni1,.. -->
                          <-- send req2: SA(..,SPIb1,..),Ni2,..
                          --> recv req1
                          <-- send resp1: SA(..,SPIb2,..),Nr2,..
recv resp1 <--
send req3: D() -->
                          --> recv req3

B voit la fermeture IKE_SA ; il répond. B devrait cesser de retransmettre req2 car A supprimera l'état après resp3.

                          <-- send resp3: ()

TEMPORARY_FAILURE n'était pas dans RFC 4306 et n'est pas négocié ; les pairs RFC 4306 l'ignorent comme erreur inconnue et arrêtent l'échange, sans effet néfaste si l'autre a déjà rekeyé.

2.8.3. Rekeying the IKE SA versus Reauthentication​

Rekey IKE SA et réauthentification diffèrent : le rekey change les clés et remet les Message ID sans nouvelle authentification (pas d'AUTH/EAP). La réauthentification vérifie souvent davantage les identités à long terme.

IKEv2 ne prévoit pas de réauthentification dédiée : nouvelle IKE SA complète (IKE_SA_INIT/IKE_AUTH sans REKEY_SA), nouveaux Child SA sans REKEY_SA, suppression de l'ancienne IKE SA.

La réauthentification change aussi les clés ; on ne peut pas avoir une « durée d'authentification » plus courte que la « durée de clé » de manière cohérente.

Création d'une nouvelle IKE SA : soit l'initiateur soit le répondant d'origine peut lancer, mais EAP / Configuration impose en pratique le même côté qu'à l'origine. Le répondant ne peut pas encore demander la réauthentification ; des extensions comme [REAUTH] existent.

Dernière mise à jour le