2.8. Regénération de clés (Rekeying)

2.8. Regénération de clés (Rekeying)

La regénération de clés (rekeying) consiste à remplacer une SA existante par une nouvelle SA sans interrompre la communication. Cela se fait généralement lorsque l'ancienne SA approche de son expiration. Pendant la regénération de clés, les deux parties DOIVENT s'accorder sur de nouvelles données de clé. Les deux parties DOIVENT être capables de traiter simultanément les paquets provenant de l'ancienne et de la nouvelle SA. La section 2.8 décrit la regénération de clés pour les child SA, tandis que la section 2.18 décrit la regénération de clés pour la parent SA (IKE SA).

Bien que la regénération de clés soit fréquemment utilisée, l'échange associé n'est pas REQUIS d'être implémenté. Les implémentations disposant de la fonctionnalité de regénération de clés DOIVENT prendre en charge l'échange CREATE_CHILD_SA décrit dans ce document. Les implémentations ne disposant pas de la fonctionnalité de regénération de clés DOIVENT simplement envoyer, dans le payload SA de l'échange IKE_SA_INIT, une proposition ne contenant aucun attribut spécifique à la regénération de clés, afin que le pair ne tente pas de regénérer les clés. Les implémentations ne prenant pas en charge la regénération de clés DOIVENT rejeter un échange CREATE_CHILD_SA contenant l'attribut REKEY_SA, et envoyer une réponse avec la notification NO_ADDITIONAL_SAS.

Lorsque l'initiateur souhaite regénérer les clés, il initie un échange CREATE_CHILD_SA contenant une proposition pour la nouvelle SA, et incluant l'attribut REKEY_SA spécifiant la SA à regénérer. La valeur SPI dans l'attribut REKEY_SA est le SPI utilisé dans le sens d'émission de la SA à regénérer. Un payload SA avec l'attribut REKEY_SA peut également être utilisé pour regénérer une SA supprimée, auquel cas la valeur SPI est le SPI d'émission de la SA supprimée. Dans l'échange CREATE_CHILD_SA, l'ancienne SA [fade-out] est toujours en cours d'utilisation (c'est-à-dire que l'ancienne SA n'est pas supprimée de la base de données de SA (SAD) jusqu'à ce que l'échange de regénération soit terminé), et la nouvelle SA [fade-in] est établie. L'initiateur utilisera la SA qui vient d'être établie comme nouvelle SA, et marquera l'ancienne SA comme « morte » (c'est-à-dire à supprimer dès que possible). Le répondeur marquera l'ancienne SA comme « vivante », mais utilisera la nouvelle SA établie comme nouvelle SA. En d'autres termes, les deux parties basculent de l'utilisation de l'ancienne SA à celle de la nouvelle SA, mais le répondeur DOIT attendre une confirmation avant de pouvoir le faire.

Le détenteur de la SA actuelle (c'est-à-dire la partie qui a envoyé la proposition SA dans l'échange IKE_SA_INIT) DOIT être l'initiateur dans l'échange de regénération de clés, car la nouvelle SA DOIT être proposée par le détenteur. Cela évite un blocage d'échanges de regénération simultanés. Pour regénérer une SA, l'échange CREATE_CHILD_SA DOIT être initié par le détenteur de la SA.

Avant qu'une implémentation accepte une SA sur le point d'être utilisée, elle peut attendre la confirmation que l'ancienne SA a été supprimée de la SAD du pair. Dans ce cas, l'implémentation DOIT attendre la notification de suppression dans un échange INFORMATIONAL (voir sections 2.4 et 3.11). Avant de recevoir une telle notification de suppression, l'implémentation DOIT conserver l'ancienne SA, car le pair peut encore l'utiliser. Cette attente est la responsabilité de l'initiateur comme du répondeur. Les implémentations ne devraient pas (SHOULD NOT) conserver l'ancienne SA indéfiniment, mais elles DOIVENT la conserver jusqu'à ce que la notification de suppression arrive, ou jusqu'à ce que la durée de vie de la SA (déterminée par la durée de vie négociée de cette SA) expire.

Si une implémentation disposant de la fonctionnalité de regénération de clés reçoit une proposition avec l'attribut REKEY_SA pendant l'échange IKE_SA_INIT, elle DOIT rejeter la proposition avec une réponse contenant la notification NO_ADDITIONAL_SAS. Si l'implémentation ne prend pas en charge la regénération de clés, elle DOIT rejeter un échange CREATE_CHILD_SA contenant l'attribut REKEY_SA, et envoyer une réponse avec la notification NO_ADDITIONAL_SAS. Une proposition contenant l'attribut REKEY_SA reçue pendant l'échange IKE_SA_INIT est une erreur ; cependant, une proposition contenant l'attribut REKEY_SA reçue pendant un échange CREATE_CHILD_SA est valide.

Si l'échange de regénération de clés échoue (par exemple, à cause de NO_ADDITIONAL_SAS ou d'une proposition invalide), l'ancienne SA est toujours disponible et une regénération de clés PEUT être tentée plus tard. Si l'ancienne SA expire, la communication est interrompue, et si la politique des deux parties le permet, une nouvelle SA (peut-être une IKE SA entièrement nouvelle) PEUT être établie.

L'épuisement des ressources est une attaque par déni de service où l'attaquant consomme les ressources de la victime en demandant trop de SA. Pour éviter cette attaque, les implémentations DEVRAIENT limiter le nombre de SA en cours de regénération de clés à un moment donné, ainsi que le nombre de child SA établies par une seule IKE SA.

2.8.1. Regénération de clés simultanée

La regénération de clés simultanée se produit lorsque les deux pairs initient un échange de regénération de clés. Pour éviter un blocage lorsque deux échanges CREATE_CHILD_SA indépendants se produisent simultanément, et pour éviter le problème potentiel de deux nouvelles SA négociant des ID incohérents, les implémentations DOIVENT suivre les règles suivantes :

1. Le détenteur original de la SA DOIT rester l'initiateur du nouvel échange CREATE_CHILD_SA.

2. Si le répondeur reçoit un échange CREATE_CHILD_SA qui tente de regénérer une SA pour laquelle il a déjà émis une demande de regénération de clés, alors le répondeur DOIT donner la priorité à la demande de regénération du pair sur la sienne. Dans ce cas, le répondeur DEVRAIT supprimer la SA qu'il a lui-même initiée, et utiliser la SA créée par le pair. Le répondeur DOIT envoyer le nouveau SPI à l'initiateur afin que l'initiateur sache quel SPI utiliser.

3. À un moment donné, il ne devrait pas (SHOULD NOT) y avoir plus de deux SA actives liées à la même SA originale.

Pour éviter la regénération de clés simultanée, les implémentations PEUVENT attendre un délai aléatoire avant de commencer l'échange de regénération de clés. Si elles reçoivent une demande de regénération de clés initiée par le pair alors qu'elles n'ont pas encore commencé leur propre regénération, elles DEVRAIENT donner la priorité à la demande du pair sur la leur.