1.3. The CREATE_CHILD_SA Exchange
1.3 The CREATE_CHILD_SA Exchange
L'échange CREATE_CHILD_SA sert à créer de nouvelles Child SAs et à rekey les IKE SAs et Child SAs. Il consiste en une seule paire requête/réponse ; une partie de sa fonction était appelée échange de Phase 2 dans IKEv1. Il PEUT être initié par chaque extrémité de l'IKE SA après les échanges initiaux.
On rekey une SA en créant une nouvelle SA puis en supprimant l'ancienne. Cette section décrit la première partie du rekey, la création des nouvelles SA ; la section 2.8 traite la mécanique du rekey, y compris la migration du trafic et la suppression des anciennes SA. Les deux sections doivent être lues ensemble.
Chaque extrémité peut initier CREATE_CHILD_SA ; ici initiator désigne l'extrémité qui initie cet échange. Une implémentation PEUT refuser toutes les requêtes CREATE_CHILD_SA dans une IKE SA.
La requête CREATE_CHILD_SA PEUT optionnellement contenir une charge KE pour un échange Diffie-Hellman supplémentaire afin de renforcer la forward secrecy de la Child SA. Le matériel de clé de la Child SA dépend de SK_d établi avec l'IKE SA, des nonces échangés pendant CREATE_CHILD_SA et de la valeur Diffie-Hellman (si des charges KE sont présentes).
Si l'échange inclut KEi, au moins une offre SA DOIT inclure le groupe Diffie-Hellman de KEi. Ce groupe DOIT faire partie de ceux que l'initiator attend que le responder accepte (d'autres groupes peuvent être proposés). Si le responder choisit une proposition avec un autre groupe (autre que NONE), il DOIT rejeter la requête et indiquer son groupe préféré dans INVALID_KE_PAYLOAD. Deux octets de données accompagnent cette notification : le numéro de groupe accepté en big endian. L'échange échoue alors ; l'initiator réessaiera probablement avec KEi dans le groupe indiqué.
Le responder envoie NO_ADDITIONAL_SAS pour indiquer qu'il refuse d'autres Child SAs sur cette IKE SA. Cette notification peut aussi rejeter le rekey de l'IKE SA. Certaines implémentations minimales n'acceptent qu'une Child SA lors de l'échange initial.
1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange
Une Child SA peut être créée par une requête CREATE_CHILD_SA :
Initiator Responder
-------------------------------------------------------------------
HDR, SK {SA, Ni, [KEi,]
TSi, TSr} -->
L'initiator envoie des offres SA, un nonce Ni, optionnellement KEi, et les Traffic Selectors proposés dans TSi et TSr.
La réponse pour créer une Child SA :
<-- HDR, SK {SA, Nr, [KEr,]
TSi, TSr}
Le responder répond (même Message ID) avec l'offre acceptée, Nr, et KEr si KEi était présent et la suite inclut ce groupe.
Les Traffic Selectors du trafic sur cette SA figurent dans les charges TS de la réponse, éventuellement en sous-ensemble de la proposition.
La notification USE_TRANSPORT_MODE PEUT figurer dans une requête qui demande aussi une Child SA. Elle demande le mode transport plutôt que tunnel. Si la requête est acceptée, la réponse DOIT aussi inclure USE_TRANSPORT_MODE. Si le responder refuse, la Child SA est en tunnel ; si l'initiator n'accepte pas, il DOIT supprimer la SA. Sauf négociation explicite du mode transport, toutes les Child SAs utilisent le tunnel.
ESP_TFC_PADDING_NOT_SUPPORTED indique que l'extrémité n'acceptera pas de paquets avec remplissage TFC sur la Child SA négociée. Si aucune extrémité n'accepte le remplissage TFC, la notification est dans requête et réponse. Si elle n'est que dans un sens, le TFC peut encore être envoyé dans l'autre sens.
NON_FIRST_FRAGMENTS_ALSO contrôle la fragmentation ; voir [IPSECARCH]. Les deux parties doivent accepter d'envoyer des fragments non initiaux. C'est actif seulement si la notification est dans la requête et la réponse. Si le responder refuse, il omet la notification dans la réponse sans rejeter toute la création.
Une notification IPCOMP_SUPPORTED (section 2.22) peut aussi être incluse.
Un échec de création de Child SA NE DEVRAIT PAS détruire l'IKE SA. Voir la section 2.21 pour les erreurs possibles.
1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
Requête de rekey IKE SA :
Initiator Responder
-------------------------------------------------------------------
HDR, SK {SA, Ni, KEi} -->
L'initiator envoie des offres SA, Ni et KEi. KEi DOIT être présent. Un nouveau SPI initiator est dans le champ SPI de SA. Après réception ou envoi d'une requête de rekey IKE SA, on NE DEVRAIT PAS lancer de nouveaux CREATE_CHILD_SA sur l'IKE SA en cours de rekey.
Réponse :
<-- HDR, SK {SA, Nr, KEr}
Le responder répond avec l'offre acceptée, Nr, KEr si la suite l'exige, et un nouveau SPI responder.
La nouvelle IKE SA a ses compteurs à 0 ; les premières requêtes ont Message ID 0. L'ancienne IKE SA garde sa numérotation. La fenêtre de la nouvelle IKE SA est remise à 1 ; l'initiator de ce rekey est le nouvel « original initiator ».
La section 2.18 détaille aussi le rekey IKE SA.
1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange
Requête de rekey Child SA :
Initiator Responder
-------------------------------------------------------------------
HDR, SK {N(REKEY_SA), SA, Ni, [KEi,]
TSi, TSr} -->
L'initiator envoie offres SA, Ni, KEi optionnel, TSi et TSr.
Les notifications de la section 1.3.1 peuvent aussi apparaître ; par exemple USE_TRANSPORT_MODE pour une SA en mode transport.
REKEY_SA DOIT être inclus si l'échange remplace une SA ESP ou AH existante. Le SPI dans Notify identifie la SA ; c'est le SPI attendu en entrée ESP/AH. Pas de données associées. Le Protocol ID correspond au protocole (3 pour ESP, 2 pour AH).
Réponse :
<-- HDR, SK {SA, Nr, [KEr,]
TSi, TSr}
Le responder répond comme pour la création ; les TS de la réponse peuvent être un sous-ensemble de la proposition.