Internet Key Exchange
Introduction à IKE
Internet Key Exchange (IKE) est un protocole de gestion des clés sécurisé utilisé pour configurer un canal de communication sécurisé et authentifié entre deux équipements.
IKE effectue les opérations suivantes :
Négocie et gère les paramètres IKE et IPsec
Authentifie l’échange de clés sécurisé
Fournit une authentification mutuelle par les pairs au moyen de secrets partagés (et non de mots de passe) et de clés publiques
Protection de l’identité (en mode principal)
Utilise les méthodes Diffie-Hellman et est facultatif dans IPsec (les clés partagées peuvent être saisies manuellement aux points de terminaison).
IKE Versions
Deux versions des normes IKE sont disponibles :
IKE version 1 - Protocole IKE défini dans la RFC 2409.
IKE version 2 - IKE version 2 (IKEv2) est la dernière version du protocole IKE défini dans la RFC 7296.
Internet Key Exchange version 2 (IKEv2) est la dernière version du protocole Internet Key Exchange (IKE) défini dans la RFC 7296. Un pair VPN est configuré en tant que IKEv1 ou IKEv2. Lorsqu’un homologue est configuré en tant que IKEv2, il ne peut pas revenir à IKEv1 si son homologue distant lance une négociation IKEv1.
Les avantages d’IKEv2 par rapport à IKEv1 sont les suivants :
Remplace huit échanges initiaux par un seul échange de quatre messages.
Réduit la latence de la configuration IPsec SA et augmente la vitesse d’établissement de la connexion.
Plus de robustesse contre les attaques DOS.
Améliore la fiabilité grâce à l’utilisation de numéros de séquence, d’accusés de réception et de correction des erreurs.
Améliore la fiabilité, car tous les messages sont des demandes ou des réponses. L’initiant est responsable de la retransmission s’il ne reçoit pas de réponse.
Interaction entre IKE et IPSec
IPsec peut établir un VPN de l’une des manières suivantes :
Protocole Internet Key Exchange (IKE) : IPsec prend en charge la génération et la négociation automatisées de clés et d’associations de sécurité à l’aide du protocole IKE. L’utilisation d’IKE pour négocier des VPN entre deux terminaux offre plus de sécurité que l’échange manuel de clés.
Échange manuel de clés : IPsec prend en charge l’utilisation et l’échange manuel de clés (par exemple : par téléphone ou par e-mail) des deux côtés pour établir un VPN.
Échange de messages IKEv1
La négociation IKE comprend deux phases :
Phase 1 : Échange de propositions negotiat pour l’authentification et la sécurisation du canal.
Phase 2 : négociez les associations de sécurité (AS) pour sécuriser les données qui transitent par le tunnel IPsec.
Phase 1 de la négociation du tunnel IKE
La phase 1 d’un tunnel IKE (AutoKey Internet Key Exchange) consiste à échanger des propositions pour identifier et sécuriser le canal. Les participants échangent des propositions pour des services de sécurité acceptables tels que :
Algorithmes de chiffrement : Data Encryption Standard (DES), Triple Data Encryption Standard (3DES) et Advanced Encryption Standard (AES). (Voir Présentation IPsec.)
Algorithmes d’authentification : Message Digest 5 (MD5) et Secure Hash Algorithm (SHA). (Voir Présentation IPsec.)
Groupe Diffie-Hellman (DH). (Voir Présentation IPsec.)
Clé prépartagée ou certificats RSA/DSA. (Voir Présentation IPsec.)
Une négociation de phase 1 réussie se termine lorsque les deux extrémités du tunnel acceptent d’accepter au moins un ensemble des paramètres de sécurité de la phase 1 proposés, puis de les traiter. Les équipements Juniper Networks prennent en charge jusqu’à quatre propositions pour les négociations de phase 1, ce qui vous permet de définir la restriction d’une gamme de paramètres de sécurité pour les négociations clés que vous accepterez. Junos OS fournit des ensembles prédéfinis de propositions de phase 1 standard, compatibles et de base. Vous pouvez également définir des propositions de phase 1 personnalisées.
Les échanges de phase 1 peuvent avoir lieu en mode principal ou en mode agressif. Vous pouvez choisir votre mode lors de la configuration de la stratégie IKE.
Cette rubrique comprend les sections suivantes :
Mode principal
En mode principal, l’initiant et le destinataire envoient trois échanges bidirectionnels (six messages au total) pour accomplir les services suivants :
Premier échange (messages 1 et 2) : propose et accepte les algorithmes de chiffrement et d’authentification.
Deuxième échange (messages 3 et 4) : exécute un échange DH, et l’initiatrice et le destinataire fournissent chacun un numéro pseudorandom.
Troisième échange (messages 5 et 6) : envoie et vérifie l’identité de l’instigateur et du destinataire.
Les informations transmises dans le troisième échange de messages sont protégées par l’algorithme de chiffrement établi dans les deux premiers échanges. Ainsi, les identités des participants sont chiffrées et ne sont donc pas transmises « en clair ».
Mode agressif
En mode agressif, l’initiant et le destinataire atteignent les mêmes objectifs qu’avec le mode principal, mais en seulement deux échanges, avec un total de trois messages :
Premier message : l’initiant propose l’association de sécurité (SA), lance un échange DH et envoie un numéro pseudorandom et son identité IKE.
Lorsque vous configurez le mode agressif avec plusieurs propositions pour les négociations de la phase 1, utilisez le même groupe DH dans toutes les propositions, car le groupe DH ne peut pas être négocié. Jusqu’à quatre propositions peuvent être configurées.
Deuxième message : le destinataire accepte le SA ; authentifie l’initiant ; et envoie un numéro pseudo-réseau, son identité IKE et, si vous utilisez des certificats, le certificat du destinataire.
Troisième message : l’instigateur authentifie le destinataire, confirme l’échange et, s’il utilise des certificats, envoie le certificat de l’instigateur.
Parce que les identités des participants sont échangées en clair (dans les deux premiers messages), le mode agressif ne protège pas l’identité.
Les modes principaux et agressifs ne s’appliquent qu’au protocole IKEv1. Le protocole IKEv2 ne négocie pas en utilisant les modes principaux et agressifs.
Voir également
Phase 2 de la négociation du tunnel IKE
Une fois que les participants ont établi un canal sécurisé et authentifié, ils passent à la phase 2, au cours de laquelle ils négocient des associations de sécurité (AS) pour sécuriser les données à transmettre via le tunnel IPsec.
À l’instar du processus de la phase 1, les participants échangent des propositions pour déterminer quels paramètres de sécurité utiliser dans l’AS. Une proposition de phase 2 comprend également un protocole de sécurité (ESP) ou AH (Encapsulating Security Payload) et des algorithmes de chiffrement et d’authentification sélectionnés. La proposition peut également spécifier un groupe Diffie-Hellman (DH), si perfect forward secrecy (PFS) est souhaité.
Quel que soit le mode utilisé dans la phase 1, la phase 2 fonctionne toujours en mode rapide et implique l’échange de trois messages.
Cette rubrique comprend les sections suivantes :
Proxy IDs
Au cours de la phase 2, les pairs échangent des IDs proxy. Un ID proxy se compose d’un préfixe d’adresse IP locale et distante. L’ID proxy des deux pairs doit correspondre, ce qui signifie que l’adresse IP locale spécifiée pour un homologue doit être la même que l’adresse IP distante spécifiée pour l’autre homologue.
Confidentialité de transfert parfaite
Le PFS est une méthode permettant de dériver des clés de phase 2 indépendantes des clés précédentes et sans rapport avec elles. La proposition de phase 1 crée également la clé (la clé SKEYID_d) à partir de laquelle toutes les clés de la phase 2 sont dérivées. La clé SKEYID_d peut générer des clés de phase 2 avec un minimum de traitement du processeur. Malheureusement, si une partie non autorisée accède à la clé SKEYID_d, toutes vos clés de chiffrement sont compromises.
Le PFS répond à ce risque de sécurité en forçant un nouvel échange de clés DH pour chaque tunnel de phase 2. L’utilisation du PFS est donc plus sécurisée, même si la procédure de re-clé de la phase 2 peut prendre un peu plus de temps avec pfS activé.
Protection contre les replays
Une attaque par rejeu se produit lorsqu’une personne non autorisée intercepte une série de paquets et les utilise plus tard soit pour inonder le système, soit pour provoquer un déni de service (DoS) ou pour accéder au réseau de confiance. Junos OS fournit une fonctionnalité de protection par rejeu qui permet aux équipements de vérifier chaque paquet IPsec pour vérifier s’il a été reçu précédemment. Si des paquets arrivent en dehors d’une plage de séquences spécifiée, Junos OS les rejette. L’utilisation de cette fonctionnalité ne nécessite pas de négociation, car les paquets sont toujours envoyés avec des numéros de séquence. Vous avez simplement la possibilité de vérifier ou de ne pas vérifier les numéros de séquence.
Voir également
Échange de messages IKEv2
IKE version 2 est le successeur de la méthode IKEv1. Il fournit un canal de communication VPN sécurisé entre les équipements VPN homologues et définit la négociation et l’authentification pour les associations de sécurité (AS) IPsec de manière protégée.
IKEv2 n’inclut pas les phases 1 et 2 similaires à IKEv1, mais quatre échanges de messages ont lieu pour négocier un tunnel IPsec avec IKEv2. Les messages échangés dans IKEv2 sont les suivants :
Négocie les attributs de sécurité pour établir le tunnel IPsec. Cela inclut l’échange des protocoles/paramètres utilisés et des groupes Diffie-Hellman.
Chaque pair établit ou authentifie son identité pendant que le tunnel IPsec est établi.
Pairs pour créer des associations de sécurité supplémentaires entre eux.
Les pairs effectuent une détection en direct, suppriment les relations SA et signalent des messages d’erreur.
- Charge utile de configuration IKEv2
- IKEv2 Rekeying et reauthentification
- IKEv2 Fragmentation
- Sélecteurs de trafic pour IKEv2
Charge utile de configuration IKEv2
La charge utile de configuration est une option IKEv2 proposée pour propager les informations de provisionnement d’un répondeur à un initateur. La charge utile de configuration IKEv2 est prise en charge uniquement avec les VPN basés sur le routage.
La RFC 5996, Internet Key Exchange Protocol version 2 (IKEv2) définit 15 attributs de configuration différents qui peuvent être retournés à l’instigateur par le répondeur.
IKEv2 Rekeying et reauthentification
Avec IKEv2, la re-clé et la réauthentification sont des processus distincts.
La nouvelle clé établit de nouvelles clés pour l’association de sécurité IKE (SA) et réinitialise les compteurs d’ID de message, mais elle ne réauthentification pas les pairs.
La réauthentification vérifie que les pairs VPN conservent leur accès aux informations d’authentification. La réauthentification établit de nouvelles clés pour l’IKE SA et les SA enfants ; les clés d’un IKE SA ou d’un enfant SA en cours ne sont plus nécessaires. Une fois les nouveaux IKE et les SAs enfants créés, les anciens IKE et les SAs enfants sont supprimés.
La réauthentification IKEv2 est désactivée par défaut. Vous activez la réauthentification en configurant une valeur de fréquence de réauthentification comprise entre 1 et 100. La fréquence de réauthentification est le nombre de clés IKE qui se produisent avant la réauthentification. Par exemple, si la fréquence de réauthentification configurée est 1, la réauthentification se produit chaque fois qu’une clé IKE est re-clé. Si la fréquence de réauthentification configurée est 2, la réauthentification se produit à chaque autre clé IKE. Si la fréquence de réauthentification configurée est 3, la réauthentification se produit à chaque re-clé IKE sur trois, et ainsi de suite.
IKEv2 Fragmentation
Lorsque l’authentification basée sur des certificats est utilisée, les paquets IKEv2 peuvent dépasser le chemin MTU si plusieurs certificats sont transmis. Si la taille du message IKE dépasse le chemin MTU, les messages sont fragmentés au niveau IP. Certains équipements réseau, tels que les équipements NAT, ne laissent pas passer les fragments IP, ce qui empêche l’établissement de tunnels IPsec.
La fragmentation des messages IKEv2, telle que décrite dans la RFC 7383, Fragmentation des messages IKEv2 (Internet Key Exchange Protocol Version 2), permet à IKEv2 d’opérer dans des environnements où les fragments IP peuvent être bloqués et où les pairs ne seraient pas en mesure d’établir une association de sécurité IPsec (SA). La fragmentation IKEv2 divise un grand message IKEv2 en un ensemble de messages plus petits afin qu’il n’y ait pas de fragmentation au niveau de l’IP. La fragmentation a lieu avant que le message d’origine ne soit chiffré et authentifié, de sorte que chaque fragment est chiffré et authentifié séparément. Sur le récepteur, les fragments sont collectés, vérifiés, déchiffrés et fusionnés dans le message d’origine.
Sélecteurs de trafic pour IKEv2
Vous pouvez configurer les sélecteurs de trafic dans IKEv2 utilisé lors de la négociation IKE. Un sélecteur de trafic est un accord entre pairs IKE pour autoriser le trafic à travers un tunnel VPN si le trafic correspond à une paire spécifiée d’adresses locales et distantes. Seul le trafic conforme à un sélecteur de trafic est autorisé par l’association de sécurité associée (SA). Des sélecteurs de trafic sont utilisés lors de la création du tunnel pour configurer le tunnel et déterminer quel trafic est autorisé à traverser le tunnel.
ID de proxy
Un ID proxy est utilisé lors de la phase 2 des négociations sur le réseau privé virtuel (VPN) Internet Key Exchange (IKE). Les deux extrémités d’un tunnel VPN ont soit un ID proxy configuré manuellement (VPN basé sur le routage) ou utilisent simplement une combinaison d’IP source, d’ADRESSE IP de destination et de service dans une stratégie de tunnel. Lorsque la phase 2 de l’IKE est négociée, chaque extrémité compare l’ID proxy local et distant configuré avec ce qui est réellement reçu.
Sélecteurs de trafic
L’ID de proxy est pris en charge à la fois pour les VPN basés sur les routes et les stratégies. Toutefois, l’ID multi-proxy n’est pris en charge que pour les VPN basés sur le routage. L’ID multi-proxy est également connu sous le nom de sélecteur de trafic. Un sélecteur de trafic est un accord entre pairs IKE pour autoriser le trafic à traverser un tunnel, si le trafic correspond à une paire spécifiée d’adresses locales et distantes. Vous définissez un sélecteur de trafic dans un VPN basé sur un routage spécifique, ce qui peut entraîner plusieurs SPsec de phase 2. Seul le trafic conforme à un sélecteur de trafic est autorisé via une SA. Le sélecteur de trafic est généralement requis lorsque les équipements de passerelle distants ne sont pas des équipements Juniper Networks.
Traduction des adresses réseau (NAT-T)
La traduction des adresses réseau (NAT-T) est une méthode permettant de contourner les problèmes de traduction d’adresses IP rencontrés lorsque les données protégées par IPsec passent par un équipement NAT pour la traduction d’adresses.
Toute modification de l’adressage IP, qui est la fonction de NAT, conduit IKE à rejeter des paquets. Après avoir détecté un ou plusieurs équipements NAT le long du chemin de données lors des échanges de phase 1, NAT-T ajoute une couche d’encapsulation UDP (User Datagram Protocol) aux paquets IPsec afin qu’ils ne soient pas jetés après la traduction d’adresses. NAT-T encapsule à la fois le trafic IKE et ESP dans UDP avec le port 4500 utilisé à la fois comme port source et de destination. Les équipements NAT vieillissants par des traductions UDP obsolètes, les messages de maintien sont nécessaires entre les pairs.
L’emplacement d’un équipement NAT peut être tel que :
Seul l’instigateur IKEv1 ou IKEv2 se trouve derrière un équipement NAT. Plusieurs initiants peuvent se retrouver derrière des équipements NAT distincts. Les initiants peuvent également se connecter au répondeur via plusieurs équipements NAT.
Seul le répondeur IKEv1 ou IKEv2 se trouve derrière un équipement NAT.
L’instigateur IKEv1 ou IKEv2 et le répondeur sont tous deux derrière un équipement NAT.
Suite B et suites cryptographiques PRIME
La suite B est un ensemble d’algorithmes cryptographiques désignés par la National Security Agency des États-Unis pour permettre aux produits commerciaux de protéger le trafic classé au niveau secret ou top secret. Les protocoles de la suite B sont définis dans la RFC 6379, Suites cryptographiques suite B pour IPsec. Les suites cryptographiques de la suite B offrent l’intégrité et la confidentialité des charges utiles de sécurité (ESP) encapsulantes et doivent être utilisées lorsque la protection de l’intégrité et le chiffrement ESP sont tous deux requis. Protocol Requirements for IP Modular Encryption (PRIME), un profil IPsec défini pour les réseaux du secteur public au Royaume-Uni, est basé sur la suite cryptographique suite B, mais utilise AES-GCM plutôt qu’AES-CBC pour les négociations IKEv2.
Les suites cryptographiques suivantes sont prises en charge :
Suite-B-GCM-128
ESP: Chiffrement AES (Advanced Encryption Standard) avec des clés de 128 bits et une valeur de contrôle de l’intégrité (ICV) de 16 octets en mode de compteur Galois (GCM).
IKE: Chiffrement AES avec clés 128 bits en mode de chaînage de blocs de chiffrement (CBC), intégrité à l’aide de l’authentification SHA-256, établissement des clés à l’aide du groupe 19 de Diffie-Hellman (DH) et authentification à l’aide de signatures de courbe elliptique 256 bits ECDSA (Elliptic Curve Digital Signature Algorithm) 256 bits.
Suite-B-GCM-256
ESP: Chiffrement AES avec clés 256 bits et ICV de 16 octets dans GCM pour ESP.
IKE: Chiffrement AES avec clés 256 bits en mode CBC, intégrité à l’aide de l’authentification SHA-384, établissement des clés à l’aide du groupe DH 20 et authentification à l’aide de signatures de courbe elliptique ECDSA 384 bits.
PRIME-128
ESP: Chiffrement AES avec clés 128 bits et ICV de 16 octets dans GCM.
IKE: Chiffrement AES avec des clés 128 bits dans GCM, établissement des clés à l’aide du groupe DH 19 et authentification à l’aide de signatures de courbe elliptique ECDSA 256 bits.
PRIME-256
ESP: Chiffrement AES avec clés 256 bits et ICV de 16 octets dans GCM pour ESP.
IKE: Chiffrement AES avec des clés 256 bits dans GCM, établissement des clés à l’aide du groupe DH 20 et authentification à l’aide de signatures de courbe elliptique ECDSA 384 bits.
Les suites cryptographiques suite B prennent en charge IKEv1 et IKEv2. Les suites cryptographiques PRIME prennent uniquement en charge IKEv2.