2.6. SPI et cookies IKE SA

Les deux premiers champs de huit octets de l'en-tête, appelés "IKE SPIs", sont utilisés comme identificateur de connexion au début des paquets IKE. Chaque extrémité choisit l'un des deux SPI et DOIT les choisir de manière à ce qu'ils soient des identificateurs uniques d'une IKE SA. Une valeur SPI de zéro est particulière : elle indique que la valeur SPI distante n'est pas encore connue de l'émetteur.

Les paquets IKE entrants sont associés à une IKE SA en utilisant uniquement le SPI du paquet, et non (par exemple) l'adresse IP source du paquet.

Contrairement à ESP et AH où seul le SPI du destinataire apparaît dans l'en-tête d'un message, dans IKE le SPI de l'émetteur est également envoyé dans chaque message. Comme le SPI choisi par l'initiateur original de la IKE SA est toujours envoyé en premier, une extrémité ayant plusieurs IKE SA ouvertes qui veut trouver la IKE SA appropriée en utilisant le SPI qu'elle a assigné doit examiner le drapeau Initiator dans l'en-tête pour déterminer si elle a assigné les huit premiers ou les huit derniers octets.

Dans le premier message d'un échange IKE initial, l'initiateur ne connaîtra pas la valeur SPI du répondeur et fixera donc ce champ à zéro. Lorsque l'échange IKE_SA_INIT ne produit pas la création d'une IKE SA à cause de INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN ou COOKIE (voir section 2.6), le SPI du répondeur sera également zéro dans le message de réponse. Toutefois, si le répondeur envoie un SPI de répondeur non nul, l'initiateur ne doit pas rejeter la réponse pour cette seule raison.

Deux attaques attendues contre IKE sont l'épuisement d'état et de CPU, où la cible est inondée de demandes d'initiation de session provenant d'adresses IP falsifiées. Ces attaques peuvent être rendues moins efficaces si un répondeur utilise un CPU minimal et ne valide aucun état pour une SA jusqu'à ce qu'il sache que l'initiateur peut recevoir des paquets à l'adresse à partir de laquelle il prétend les envoyer.

Lorsqu'un répondeur détecte un grand nombre de IKE SA semi-ouvertes, il DEVRAIT répondre aux demandes IKE_SA_INIT par une réponse contenant la notification COOKIE. Les données associées à cette notification DOIVENT avoir une longueur comprise entre 1 et 64 octets (inclus), et sa génération est décrite plus loin dans cette section. Si la réponse IKE_SA_INIT inclut la notification COOKIE, l'initiateur DOIT alors relancer la demande IKE_SA_INIT, et inclure la notification COOKIE contenant les données reçues comme premier payload, tous les autres payloads restant inchangés. L'échange initial sera alors le suivant :

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 n'affectent aucun état de l'initiateur ou du répondeur, sauf pour communiquer le cookie. En particulier, les numéros de séquence de message dans les quatre premiers messages seront tous zéro et les numéros de séquence de message dans les deux derniers messages seront un. 'A' est le SPI assigné par l'initiateur, tandis que 'B' est le SPI assigné par le répondeur.

Une implémentation IKE peut implémenter la génération de son cookie de répondeur de manière à ne nécessiter aucun état sauvegardé pour reconnaître son cookie valide lorsque le second message IKE_SA_INIT arrive. Les algorithmes et la syntaxe exacts utilisés pour générer les cookies n'affectent pas l'interopérabilité et ne sont donc pas spécifiés ici. Ce qui suit est un exemple de la façon dont un point terminal pourrait utiliser des cookies pour implémenter une protection DoS limitée.

Une bonne façon de procéder est de définir le cookie de répondeur ainsi :

Cookie = | Hash(Ni | IPi | SPIi | )

où est un secret généré aléatoirement, connu uniquement du répondeur et changé périodiquement, et | indique la concaténation. devrait être changé chaque fois que est régénéré. Le cookie peut être recalculé lorsque le IKE_SA_INIT arrive une seconde fois et comparé au cookie du message reçu. S'ils correspondent, le répondeur sait que le cookie a été généré depuis le dernier changement de et que IPi doit être identique à l'adresse source qu'il a vue la première fois. L'incorporation de SPIi dans le calcul garantit que si plusieurs IKE SA sont configurées en parallèle, elles obtiendront toutes des cookies différents (en supposant que l'initiateur choisit des SPIi uniques). L'incorporation de Ni dans le hash garantit qu'un attaquant qui ne voit que le message 2 ne peut pas falsifier avec succès un message 3. De plus, l'incorporation de SPIi dans le hash empêche un attaquant d'obtenir un cookie depuis l'autre extrémité, puis d'initier de nombreux échanges IKE_SA_INIT tous avec des SPI d'initiateur différents (et peut-être des numéros de port différents) de sorte que le répondeur pense qu'il y a beaucoup de machines derrière une seule box NAT qui tentent toutes de se connecter.

Si une nouvelle valeur pour est choisie alors qu'il y a des connexions en cours d'initialisation, un IKE_SA_INIT peut être renvoyé avec un autre que le courant. Le répondeur dans ce cas PEUT rejeter le message en envoyant une autre réponse avec un nouveau cookie ou il PEUT conserver l'ancienne valeur de pendant un court moment et accepter les cookies calculés à partir des deux. Le répondeur ne devrait pas accepter les cookies indéfiniment après que est changé, car cela annulerait une partie de la protection DoS. Le répondeur devrait changer la valeur de fréquemment, surtout s'il est sous attaque.

Lorsqu'une partie reçoit une demande IKE_SA_INIT contenant un cookie dont le contenu ne correspond pas à la valeur attendue, cette partie DOIT ignorer le cookie et traiter le message comme s'il n'avait aucun cookie inclus ; cela signifie généralement l'envoi d'une réponse contenant un nouveau cookie. L'initiateur devrait limiter le nombre d'échanges de cookies qu'il tente avant d'abandonner, en utilisant éventuellement un repli exponentiel. Un attaquant peut falsifier plusieurs réponses de cookie au message IKE_SA_INIT de l'initiateur, et chacune de ces réponses de cookie falsifiées entraînera l'envoi de deux paquets : un paquet de l'initiateur au répondeur (qui rejettera ces cookies), et une réponse du répondeur à l'initiateur incluant le cookie correct.

Une note sur la terminologie : le terme "cookies" provient de Karn et Simpson [PHOTURIS] dans Photuris, une proposition précoce de gestion de clés avec IPsec, et il a persisté. L'en-tête de message fixe du protocole ISAKMP (Internet Security Association and Key Management Protocol) [ISAKMP] inclut deux champs de huit octets appelés "cookies", et cette syntaxe est utilisée par IKEv1 et IKEv2, bien que dans IKEv2 ils soient désignés comme le "IKE SPI" et qu'il y ait un nouveau champ séparé dans un payload Notify contenant le cookie.

Il y a deux raisons courantes pour lesquelles l'initiateur peut avoir à relancer l'échange IKE_SA_INIT : le répondeur demande un cookie ou veut un groupe Diffie-Hellman différent de celui inclus dans le payload KEi. Si l'initiateur reçoit un cookie du répondeur, l'initiateur doit décider s'il inclut le cookie uniquement dans la prochaine relance de la demande IKE_SA_INIT, ou dans toutes les relances ultérieures également.

Si l'initiateur inclut le cookie uniquement dans la prochaine relance, un aller-retour supplémentaire peut être nécessaire dans certains cas. Un aller-retour supplémentaire est également nécessaire si l'initiateur inclut le cookie dans toutes les relances, mais le répondeur ne le supporte pas. Par exemple, si le répondeur inclut les payloads KEi dans le calcul du cookie, il rejettera la demande en envoyant un nouveau cookie.

Si les deux pairs supportent l'inclusion du cookie dans toutes les relances, un échange légèrement plus court peut se produire.

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 implémentations ne le supportent pas.