Internet Key Exchange (IKE) est un protocole utilisé pour configurer des attributs de sécurité d’associations de sécurité IPSec, tels que la clé de cryptage, l’algorithme de cryptage et le mode, entre homologues IPSec. Internet Key Exchange permet aux homologues IPSec d’échanger de manière dynamique des clés et de négocier des associations de sécurité IPSec. En utilisant Internet Key Exchange (IKE), les associations de sécurité IPSec peuvent être établies et supprimées de manière dynamique à un moment négocié.

Internet Key Exchange (IKE) est un protocole IETF et comporte deux versions, une ancienne version IKEv1 (RFC 2409, RFC 4109) et une version relativement nouvelle, IKEv2 (RFC 5996, RFC 7296 et RFC 7427).

Internet Key Exchange est un protocole hybride constitué des protocoles Oakley, SKEME (mécanisme polyvalent d’échange de clé sécurisé pour Internet) et ISAKMP (Internet Security Association and Key Management Protocol). Le protocole ISAKMP est un cadre d’échange de clés de chiffrement et de charges utiles d’association de sécurité.

IKE utilise UDP, numéro de port 500.

Internet Key Exchange Version 1 (IKEv1)


L’opération IKEv1 peut être décomposée en deux phases. 1) phase 1 (négociation IKE SA) et 2) phase 2 (négociation IPSec SA). La négociation SA de phase 1 d’IKEv1 sert à protéger IKE. La négociation SA de phase 2 IKEv1 sert à protéger IPSec (trafic d’utilisateur réel).

La négociation de phase 1 d’IKEv1 peut s’effectuer selon deux modes, soit en mode principal, soit en mode agressif. Le mode principal IKEv1 Phase 1 comporte trois paires de messages (six messages au total) entre homologues IPSec. Le mode agressif IKE Phase 1 ne comporte que trois échanges de messages. La phase 1 d’IKEv1 a pour but d’établir IKE SA.

IKEv1 Phase 2 (Mode rapide) n’a que trois messages. Le but de la phase 2 d’IKEv1 est d’établir IPSec SA.

La phase 1 sert à négocier les paramètres et le matériel clé nécessaires à l’établissement de l’association de sécurité IKE (SA) IKE entre deux homologues IPSec. Les associations de sécurité (SA) négociées lors de la phase 1 sont ensuite utilisées pour protéger les futures communications IKE.

L’explication suivante est basée sur l’hypothèse que les pairs utilisent une clé pré-partagée pour l’authentification.

Mode principal de la phase 1 d’IKEv1


Mode principal IKEv1 phase 1 – Message 1: Le premier couple de messages du mode principal IKEv1 est constitué des propositions d’association de sécurité IKEv1. L’initiateur (le périphérique qui initie IPSec) propose des stratégies en envoyant une ou plusieurs propositions d’association de sécurité. Le message de mode principal IKEv1 1 contient un en-tête IKE, une charge utile SA, une charge utile de proposition et une charge utile de transformation. IKE utilise différents types de « données utiles » pour partager des informations sur les associations et les clés de sécurité courantes. Payload a un en-tête et d’autres informations utiles à DOI. IKE peut être DOI pour Domain of Interpretation, dans ce cas, IPSec.

La charge SA est utilisée pour spécifier que cet échange ISAKMP est destiné à la négociation IPSec. IKE / ISAKMP est un protocole générique qui peut être utilisé pour négocier différents protocoles. Par conséquent, la charge utile SA contient un domaine d’interprétation (DOI), utilisé pour mentionner que la négociation IKE / ISAKMP concerne IPSec.

La charge utile de proposition contient un numéro de proposition, l’ID de protocole, la taille du SPI, le nombre de transformations et le SPI.

La charge utile de transformation contient le numéro de transformation, l’identifiant de transformation et les attributs SA SA tels que Authentification (clés pré-partagées ou certificats numériques), algorithmes de hachage (MD5 ou SHA1), cryptage (DES, 3DES ou AES), unité de durée de vie du tunnel (Secs), tunnel durée de vie en secondes, groupes Diffie-Hellman.

L’initiateur et le répondant doivent calculer une valeur appelée cookie. La valeur Cookie est utilisée pour protéger les homologues IPSec contre les attaques par DoS et Re-Play. RFC suggère une méthode pour créer le cookie en effectuant un hachage rapide (exemple MD5) sur l’adresse source et de destination IP, les ports source et de destination UDP et une valeur aléatoire secrète générée localement. Le champ « Initiator SPI », indiqué dans capture ci-dessous, correspond à la valeur du cookie générée par Initiator.La valeur du cookie de réponse est conservée vide, car il s’agit du tout premier message.

Mode principal IKEv1 de phase 1 – Message 2: Mode principal IKEv1 Le message 2 est la réponse du répondeur au paquet envoyé par l’initiateur. Le message 2 a pour but d’informer l’initiateur des attributs d’association de sécurité convenus. La plupart des champs sont les mêmes que dans le paquet envoyé par l’initiateur. Le message 2, qui correspond à la proposition et à la transformation de la charge utile, ne contient qu’une seule charge utile de transformation et de transformation. Notez également que les deux valeurs de cookie sont remplies.

Mode principal de la phase 1 d’IKEv1 – Message 3: Le troisième message est transmis par l’initiateur au répondeur. Ce message contient les données utiles Diffie-Hellman Key Exchange Payload et Nonce, de la part de l’initiateur.

Mode principal de la phase 1 d’IKEv1 – Message 4: Le quatrième message est transmis par le répondeur à l’initiateur. Ce message contient les données utiles Diffie-Hellman Key Exchange Payload et Nonce, provenant de Responder. Un nonce est un très grand nombre aléatoire utilisé dans IKE. Le nombre aléatoire IKE Nounce est également utilisé pour calculer le matériel de saisie.

Veuillez noter que les quatre premiers messages en mode principal IKEv1 Phase 1 ne sont pas cryptés.

Mode principal de la phase 1 d’IKEv1 – Message 5: Les deux homologues IPSec calculent le secret partagé de Diffie-Hellman. Trois clés sont générées par les deux pairs pour l’authentification et le chiffrement. Le 5ème message contient la charge d’identification et la charge de hachage de l’initiateur. Les données d’identification et les données utiles de hachage sont utilisées pour l’identification et l’authentification. Les données utiles d’identification et les données utiles de hachage sont envoyées cryptées en mode principal IKEv1 Phase 1.

Mode principal de la phase 1 d’IKEv1 – Message 6: Le 6e message contient la charge d’identification et la charge de hachage. Les données utiles d’identification et les données utiles de hachage sont utilisées pour l’identification et l’authentification auprès de Responder. Les données utiles d’identification et les données utiles de hachage sont envoyées cryptées en mode principal IKEv1 Phase 1.

Mode agressif IKEv1 phase 1


IKEv1 Phase 1, en mode agressif, utilise seulement trois messages pour établir SA SA. Les deux premiers messages en mode échange agressif incluent presque tout le nécessaire pour former IKE SA. Le mode agressif IKEv1 Phase1 est plus rapide que le mode principal, mais les identités des points d’extrémité sont échangées en texte clair. Lorsque vous comparez le mode principal et le mode agressif, le mode principal est considéré comme plus sécurisé que le mode agressif, car la charge d’identification est chiffrée en mode principal.

Mode agressif IKEv1 Phase 1 – Message 1: En mode agressif IKEv1 Phase1, toutes les informations nécessaires pour générer le secret partagé Diffie-Hellman sont échangées dans les deux premiers messages entre homologues. Le premier message envoyé par l’initiateur inclut les données utiles SA, les données utiles Proposition et les données utiles Transform, similaires au mode Principal. La principale différence en mode agressif réside dans le fait que le premier message comprend les données utiles Diffie-Hellman Key Exchange et les données utiles de Nonce. Les données d’identification sont également ajoutées dans le premier message. Notez que la charge d’identification est envoyée sous forme de texte en clair et non chiffrée.

Mode agressif IKEv1 phase 1 – Message 2: le répondeur peut maintenant générer le secret partagé Diffie-Hellman. Le répondeur génère le secret partagé Diffie-Hellman. Responder génère le hachage également à des fins d’authentification. Semblable au message 2 en mode principal IKEv1 Phase1, le message 2 en mode agressif IKEv1 Phase1 contient également la proposition convenue et la paire de transformation du répondeur. Il contient également les données utiles relatives à l’échange de clés, aux données utiles de Nounce, aux informations d’identification et au hachage d’authentification du répondeur.

Mode agressif IKEv1 Phase 1 – Message 3: l’initiateur peut maintenant générer le secret partagé Diffie-Hellman. L’initiateur génère le secret partagé Diffie-Hellman. L’initiateur génère le hachage également à des fins d’authentification. La charge utile de hachage est envoyée sous forme cryptée.

La phase 1 peut être négociée en mode principal (6 messages) ou en mode agressif (3 messages). Une fois que les messages de la phase 1 ont été échangés avec succès, le SA IKE est établi. Une fois qu’un SA IKE (utilisant le mode principal ou le mode agressif) est établi, il peut être utilisé pour générer des SA IPSec, en négociation de phase 2. À présent, les homologues échangent des messages de phase 2 (mode rapide) pour négocier IPSec SA.

IKEv1 Phase 2 – Mode rapide


La négociation de phase 2 d’IKEv2 s’effectue dans un seul mode, le mode rapide. IKEv1 Phase 2 (Quick Mode) consiste en 3 échanges de messages. Bien entendu, les échanges de messages en phase 2 (Quick Mode) sont protégés par un cryptage et une authentification, à l’aide des clés dérivées de la phase 1.

Si la fonction PFS (Perfect Forward Secrecy) est activée, de nouvelles clés partagées doivent être générées pour être utilisées. La génération de la clé Diffie-Hellman est à nouveau effectuée à l’aide de nouveaux nonces échangés entre pairs.

Étant donné qu’il est inutile de montrer des captures d’écran de capture cryptées, je ne joins aucune capture d’écran de capture Wireshark pour le mode rapide.

En mode rapide, les paramètres suivants sont négociés pour le SA IPSec.

• algorithme de cryptage (DES, 3DES, AES)
• Algorithme de hachage (MD5, SHA-1, SHA-2)
• Protocole d’encapsulation (AH ou ESP)
• Durée de vie SA (durée en secondes ou transfert de données en kilo-octets)
• Mode (tunnel, transport)

Une fois la négociation IKEv1 Phase 2 (Mode rapide) terminée, chaque association homologue génère un SA unidirectionnel. Chaque pair générera au moins deux SA. Un en direction entrante et sortante.

Show CommentsClose Comments

Leave a comment