2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange (Recléage IKE SA via CREATE_CHILD_SA)

2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange (Recléage IKE SA via CREATE_CHILD_SA)

CREATE_CHILD_SA peut recléer une IKE SA existante (sections 1.3.2 et 2.8). Les nouveaux SPI initiateur et répondant sont dans les champs SPI des structures Proposal des charges SA (pas ceux de l'en-tête IKE). Les charges TS sont omises pour recléer l'IKE SA. SKEYSEED de la nouvelle IKE SA utilise SK_d de l'ancienne:

SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr)

g^ir (new) est le secret DH éphémère de cet échange (octets big-endian, zéros si besoin), Ni et Nr sans en-têtes.

L'ancienne et la nouvelle IKE SA peuvent avoir des PRF différentes. Comme l'échange de recléage appartient à l'ancienne IKE SA, c'est la PRF de l'ancienne qui génère SKEYSEED.

Le recléage vise à empêcher qu'une compromission d'anciennes clés révèle les actuelles, et inversement. Les implémentations DOIVENT effectuer un nouvel échange Diffie-Hellman lors du recléage IKE SA. L'initiateur NE DOIT PAS proposer "NONE" pour la transformation DH, et le répondant NE DOIT PAS l'accepter. Un recléage réussi inclut toujours KEi/KEr.

La nouvelle IKE SA DOIT remettre ses compteurs de messages à 0.

SK_d, SK_ai, SK_ar, SK_ei et SK_er se calculent depuis SKEYSEED comme en section 2.14 avec SPIi, SPIr, Ni, Nr du nouvel échange et la PRF de la nouvelle IKE SA.