Aller au contenu principal

2.6. IKE SA SPIs and Cookies

2.6. IKE SA SPIs and Cookies​

Les deux premiers champs de huit octets de l'en-tête, appelés « IKE SPI », identifient la connexion au début des paquets IKE. Chaque extrémité en choisit un et DOIT les choisir comme identifiants uniques d'une IKE SA. La valeur zéro est spéciale : l'émetteur ne connaît pas encore le SPI distant.

Les paquets IKE entrants sont associés à une IKE SA uniquement par le SPI du paquet, pas par exemple par l'adresse IP source.

Contrairement à ESP et AH où seul le SPI du destinataire apparaît, IKE envoie aussi le SPI de l'émetteur. Comme le SPI choisi par l'initiateur d'origine est toujours envoyé en premier, une extrémité avec plusieurs IKE SA doit consulter le drapeau Initiateur pour savoir si elle a assigné les huit premiers ou les huit suivants octets.

Dans le premier message d'un échange initial, l'initiateur ignore le SPI du répondant et met ce champ à zéro. Si IKE_SA_INIT n'aboutit pas à une IKE SA (INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, COOKIE), le SPI du répondant peut aussi être nul dans la réponse. Si le répondant envoie un SPI répondant non nul, l'initiateur ne devrait pas rejeter la réponse pour cette seule raison.

Deux attaques attendues sont l'épuisement d'état et de CPU par inondation de demandes d'ouverture depuis des adresses IP falsifiées. Un répondant qui n'engage presque pas de CPU ni d'état tant qu'il n'a pas vérifié que l'initiateur reçoit bien à l'adresse annoncée limite l'efficacité de l'attaque.

Lorsqu'un répondant détecte de nombreuses IKE SA semi-ouvertes, il DEVRAIT répondre aux IKE_SA_INIT par une réponse contenant la notification COOKIE. Les données associées DOIVENT faire entre 1 et 64 octets inclus ; leur génération est décrite plus bas. Si la réponse IKE_SA_INIT inclut COOKIE, l'initiateur DOIT réessayer IKE_SA_INIT en plaçant la notification COOKIE avec les données reçues en première charge, les autres charges inchangées. L'échange initial est alors :

Initiator                         Responder
-------------------------------------------------------------------
HDR(A,0), SAi1, KEi, Ni  -->
                                <--  HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1,
    KEi, Ni  -->
                                <--  HDR(A,B), SAr1, KEr,
                                         Nr, [CERTREQ]
HDR(A,B), SK {IDi, [CERT,]
    [CERTREQ,] [IDr,] AUTH,
    SAi2, TSi, TSr}  -->
                                <--  HDR(A,B), SK {IDr, [CERT,]
                                         AUTH, SAr2, TSi, TSr}

Les deux premiers messages ne modifient l'état que pour le cookie. Les numéros de séquence des quatre premiers messages sont nuls, ceux des deux derniers valent 1. « A » est le SPI de l'initiateur, « B » celui du répondant.

Une implémentation peut générer le cookie répondant sans état persistant pour reconnaître un cookie valide au second IKE_SA_INIT. Les algorithmes exacts n'affectent pas l'interopérabilité et ne sont pas spécifiés. Voici un exemple de protection DoS limitée :

Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

où <secret> est un secret aléatoire connu seulement du répondant, changé périodiquement, et | est la concaténation. <VersionIDofSecret> change quand <secret> est régénéré. Le cookie peut être recalculé au second IKE_SA_INIT et comparé. S'il correspond, le cookie date du dernier changement de <secret> et IPi doit être la source vue la première fois. SPIi distingue les ouvertures parallèles. Ni empêche de forger le message 3 en ne voyant que le message 2. SPIi empêche d'obtenir un cookie puis de lancer de nombreux IKE_SA_INIT avec des SPI différents pour simuler une armée derrière un NAT.

Si <secret> change pendant des initialisations en cours, un IKE_SA_INIT peut porter un ancien <VersionIDofSecret>. Le répondant PEUT rejeter avec un nouveau cookie ou PEUT garder brièvement l'ancien <secret> et accepter les deux. Il ne devrait pas accepter indéfiniment après rotation. Il devrait changer <secret> souvent, surtout sous attaque.

Si le cookie reçu ne correspond pas, la partie DOIT l'ignorer et traiter le message comme sans cookie (souvent nouvelle réponse avec cookie). L'initiateur devrait limiter les allers-retours cookie et utiliser un backoff exponentiel. Un attaquant peut provoquer deux paquets par faux cookie : rejet côté répondant puis réponse correcte.

Terminologie : « cookies » vient de Photuris [PHOTURIS]. ISAKMP [ISAKMP] nomme ainsi deux champs de huit octets ; IKEv2 les appelle « IKE SPI » et place le cookie dans une charge Notify séparée.

L'initiateur retente IKE_SA_INIT soit parce que le répondant exige un cookie, soit parce qu'il veut un autre groupe Diffie-Hellman que dans KEi. S'il reçoit un cookie, il doit décider de l'inclure seulement au prochain essai ou à tous les suivants.

Un aller-retour supplémentaire peut être nécessaire dans le premier cas, ou si tous les essais portent le cookie mais que le répondant ne le supporte pas (ex. : KEi inclus dans le calcul du cookie → nouveau cookie rejeté).

Si les deux pairs incluent le cookie à chaque reprise, l'échange peut être un peu plus court :

Initiator                   Responder
-----------------------------------------------------------
HDR(A,0), SAi1, KEi, Ni -->
                           <-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
                           <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
                           <-- HDR(A,B), SAr1, KEr, Nr

Les implémentations DEVRAIENT supporter cet échange plus court, mais NE DOIVENT PAS échouer si d'autres ne le supportent pas.

Dernière mise à jour le