Internet Key Exchange
Introduction à IKE
Internet Key Exchange (IKE) est un protocole de gestion de clé sécurisé utilisé pour établir un canal de communication sécurisé et authentifié entre deux appareils.
IKE effectue les opérations suivantes :
Négocie et gère les paramètres IKE et IPsec
Authentifie l’échange sécurisé de clés
Fournit une authentification mutuelle par les pairs au moyen de secrets partagés (pas 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 au niveau des 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 homologue 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 initie la négociation IKEv1.
Les avantages de l’utilisation d’IKEv2 par rapport à IKEv1 sont les suivants :
Remplace huit échanges initiaux par un seul échange de quatre messages.
Réduit la latence pour la configuration IPsec SA et augmente la vitesse d’établissement de la connexion.
Augmente la 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 d’erreurs.
Améliore la fiabilité, car tous les messages sont des requêtes ou des réponses. L’initiateur 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 points de terminaison 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 manuels de clés (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 : négocier l’échange de propositions sur la manière d’authentifier et de sécuriser le canal.
Phase 2 : négociez les associations de sécurité (SA) 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’une négociation de tunnel IKE (AutoKey Internet Key Exchange) consiste en l’échange de propositions sur la manière d’authentifier et de sécuriser le canal. Les participants échangent des propositions pour des services de sécurité acceptables tels que :
Algorithmes de chiffrement : norme de chiffrement des données (DES), triple norme de chiffrement des données (3DES) et norme de chiffrement avancée (AES). (Reportez-vous à la section Présentation d’IPsec.)
Algorithmes d’authentification : Message Digest 5 (MD5) et Secure Hash Algorithm (SHA). (Reportez-vous à la section Présentation d’IPsec.)
Groupe Diffie-Hellman (DH). (Reportez-vous à la section Présentation d’IPsec.)
Clé pré-partagée ou certificats RSA/DSA. (Reportez-vous à la section Présentation d’IPsec.)
Une négociation de phase 1 réussie se termine lorsque les deux extrémités du tunnel conviennent 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 le degré de restriction d’une plage de paramètres de sécurité pour la négociation de clé 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 la 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’initiateur 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.
Second exchange (messages 3 et 4) : exécute un échange DH, et l’initiateur et le destinataire fournissent chacun un nombre pseudo-aléatoire.
Troisième échange (messages 5 et 6) : envoie et vérifie l’identité de l’initiateur et du destinataire.
Les informations transmises lors du troisième échange de messages sont protégées par l’algorithme de chiffrement établi lors des deux premiers échanges. Ainsi, l’identité des participants est cryptée et n’est donc pas transmise « en clair ».
Mode agressif
En mode agressif, l’initiateur et le destinataire accomplissent les mêmes objectifs qu’en mode principal, mais en seulement deux échanges, avec un total de trois messages :
Premier message : l’initiateur propose l’association de sécurité (SA), initie un échange DH et envoie un nombre pseudo-aléatoire et son identité IKE.
Lors de la configuration du mode agressif avec plusieurs propositions pour les négociations de phase 1, utilisez le même groupe DH dans toutes les propositions, car le groupe DH ne peut pas être négocié. Il est possible de configurer jusqu’à quatre propositions.
Deuxième message : le destinataire accepte l’AS ; authentifie l’initiateur ; et envoie un nombre pseudo-aléatoire, son identité IKE et, s’il s’agit de certificats, le certificat du destinataire.
Troisième message : l’initiateur authentifie le destinataire, confirme l’échange et, s’il utilise des certificats, envoie le certificat de l’initiateur.
Étant donné que l’identité des participants est échangée en clair (dans les deux premiers messages), le mode agressif n’offre pas de protection de l’identité.
Les modes principal et agressif ne s’appliquent qu’au protocole IKEv1. Le protocole IKEv2 ne négocie pas en utilisant les modes principal et agressif.
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 par la phase 2, au cours de laquelle ils négocient des associations de sécurité (SA) 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 les paramètres de sécurité à utiliser dans l’AS. Une proposition de phase 2 comprend également un protocole de sécurité, soit une charge utile de sécurité encapsulée (ESP), soit un en-tête d’authentification (AH), ainsi que des algorithmes de chiffrement et d’authentification sélectionnés. La proposition peut également spécifier un groupe Diffie-Hellman (DH), si la confidentialité persistante parfaite (PFS) est souhaitée.
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 :
ID de proxy
Au cours de la phase 2, les pairs échangent des ID de proxy. Un ID de proxy se compose d’un préfixe d’adresse IP locale et distante. L’ID de proxy des deux homologues 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é persistante parfaite
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 celles-ci. Alternativement, la proposition de phase 1 crée la clé (la clé SKEYID_d) à partir de laquelle toutes les clés de 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 CPU. Malheureusement, si une partie non autorisée accède à la clé SKEYID_d, toutes vos clés de chiffrement sont compromises.
PFS résout ce risque de sécurité en forçant un nouvel échange de clés DH pour chaque tunnel de phase 2. L’utilisation de PFS est donc plus sûre, bien que la procédure de redéfinition des clés de la phase 2 puisse prendre un peu plus de temps lorsque PFS est activé.
Protection contre le rejeu
Une attaque par rejeu se produit lorsqu’une personne non autorisée intercepte une série de paquets et les utilise ultérieurement soit pour inonder le système, provoquant un déni de service (DoS), soit pour pénétrer dans le réseau de confiance. Junos OS fournit une fonctionnalité de protection contre la relecture qui permet aux périphériques de vérifier chaque paquet IPsec pour voir 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 non 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 périphériques VPN homologues et définit la négociation et l’authentification pour les associations de sécurité (SA) IPsec de manière protégée.
IKEv2 n’inclut pas les phases 1 et 2 similaires à IKEv1, mais il existe quatre échanges de messages 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 l’établissement du tunnel IPsec.
Peers pour créer des associations de sécurité supplémentaires entre eux.
Les homologues détectent la vivacité, suppriment les relations SA et signalent les messages d’erreur.
- Charge utile de configuration IKEv2
- Redéfinition des clés et réauthentification IKEv2
- 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 initiateur. 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 renvoyés à l’initiateur par le répondeur.
Redéfinition des clés et réauthentification IKEv2
Avec IKEv2, la ressaisie et la réauthentification sont des processus distincts.
La ressaisie é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éauthentifie pas les homologues.
La réauthentification vérifie que les homologues VPN conservent leur accès aux informations d’identification d’authentification. La réauthentification établit de nouvelles clés pour la SA IKE et les SA enfants ; Il n’est plus nécessaire de refaire les clés de toute SA IKE ou enfant en attente. Une fois que le nouvel IKE et les SA enfants sont créés, l’ancien IKE et les SA enfants sont supprimés.
La réauthentification IKEv2 est désactivée par défaut. Pour activer la réauthentification, configurez une fréquence de réauthentification comprise entre 1 et 100. La fréquence de réauthentification correspond au nombre de nouvelles clés IKE qui se produisent avant que la réauthentification ne se produise. Par exemple, si la fréquence de réauthentification configurée est égale à 1, la réauthentification se produit chaque fois qu’il y a une nouvelle clé IKE. Si la fréquence de réauthentification configurée est égale à 2, la réauthentification a lieu tous les deux renouvellements de clés IKE. Si la fréquence de réauthentification configurée est égale à 3, la réauthentification se produit tous les trois renouvellements de clés IKE, et ainsi de suite.
IKEv2 Fragmentation
Lorsque l’authentification basée sur les certificats est utilisée, les paquets IKEv2 peuvent dépasser la MTU du chemin si plusieurs certificats sont transmis. Si la taille du message IKE dépasse la MTU du chemin, les messages sont fragmentés au niveau de l’adresse IP. Certains équipements réseau, tels que les périphériques NAT, n’autorisent pas le passage des fragments IP, ce qui empêche l’établissement de tunnels IPsec.
La fragmentation des messages IKEv2, telle que décrite dans la RFC 7383, Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation, permet à IKEv2 de fonctionner dans des environnements où les fragments IP peuvent être bloqués et les homologues ne peuvent pas établir d’association de sécurité IPsec (SA). La fragmentation IKEv2 divise un message IKEv2 volumineux en un ensemble de messages plus petits afin qu’il n’y ait pas de fragmentation au niveau 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és lors de la négociation IKE. Un sélecteur de trafic est un accord entre des homologues IKE pour autoriser le trafic à passer par 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 le biais de l’association de sécurité (SA) associée. Les 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.
Proxy ID
Un ID proxy est utilisé pendant la phase 2 des négociations de réseau privé virtuel (VPN) IKE (Internet Key Exchange). Les deux extrémités d’un tunnel VPN disposent soit d’un ID proxy configuré manuellement (VPN basé sur le routage), soit d’une combinaison d’adresses 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 de 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 pour les VPN basés sur l’itinéraire et les VPN basés sur des 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 des homologues 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 au sein d’un VPN basé sur le routage spécifique, ce qui peut entraîner plusieurs SA IPsec de phase 2. Seul le trafic conforme à un sélecteur de trafic est autorisé par le biais d’une SA. Le sélecteur de trafic est généralement requis lorsque les périphériques de passerelle distante sont des équipements non-Juniper Networks.
Traversée de traduction d’adresses réseau (NAT-T)
La traduction et la traversée d’adresses réseau (NAT-T) sont une méthode permettant de contourner les problèmes de traduction d’adresses IP rencontrés lorsque des données protégées par IPsec transitent par un périphérique NAT pour la traduction d’adresses.
Toute modification de l’adressage IP, qui est la fonction de NAT, entraîne la suppression des paquets par IKE. Après avoir détecté un ou plusieurs périphériques NAT le long du chemin de données au cours 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 supprimés après la traduction de l’adresse. 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. Étant donné que les périphériques NAT expirent les traductions UDP obsolètes, des messages keepalive sont nécessaires entre les homologues.
L’emplacement d’un périphérique NAT peut être tel que :
Seul l’initiateur IKEv1 ou IKEv2 se trouve derrière un périphérique NAT. Plusieurs initiateurs peuvent se trouver derrière des périphériques NAT distincts. Les initiateurs peuvent également se connecter au répondeur par le biais de plusieurs périphériques NAT.
Seul le répondeur IKEv1 ou IKEv2 se trouve derrière un périphérique NAT.
L’initiateur IKEv1 ou IKEv2 et le répondeur se trouvent tous deux derrière un périphérique NAT.
Suites cryptographiques Suite B et PRIME
La Suite B est un ensemble d’algorithmes cryptographiques désignés par la Sécurité nationale des États-Unis pour permettre aux produits commerciaux de protéger le trafic classifié à des niveaux secret ou top secret. Les protocoles de la suite B sont définis dans la RFC 6379, Suite B Cryptographic Suites for IPsec. Les suites cryptographiques de la suite B assurent l’intégrité et la confidentialité de la charge utile de sécurité d’encapsulation (ESP) et doivent être utilisées lorsque la protection de l’intégrité et le chiffrement de l’ESP sont tous deux requis. PRIME (Protocol Requirements for IP Modular Encryption), 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 d’intégrité (ICV) de 16 octets en mode compteur de Galois (GCM).
IKE: Chiffrement AES avec des clés de 128 bits en mode CBC (cipher block chaining), intégrité à l’aide de l’authentification SHA-256, établissement de clés à l’aide du groupe 19 de Diffie-Hellman (DH) et authentification à l’aide des signatures à courbe elliptique ECDSA (Elliptic Curve Digital Signature Algorithm) 256 bits.
Suite-B-GCM-256
ESP: Chiffrement AES avec des clés de 256 bits et ICV de 16 octets dans GCM pour ESP.
IKE: Chiffrement AES avec des clés de 256 bits en mode CBC, intégrité à l’aide de l’authentification SHA-384, établissement de clés à l’aide du groupe DH 20 et authentification à l’aide de signatures ECDSA à courbe elliptique de 384 bits.
PRIME-128
ESP: Chiffrement AES avec des clés de 128 bits et un ICV de 16 octets dans GCM.
IKE: Chiffrement AES avec des clés de 128 bits dans GCM, établissement de clés à l’aide du groupe DH 19 et authentification à l’aide de signatures à courbe elliptique ECDSA de 256 bits.
PRIME-256
ESP: Chiffrement AES avec des clés de 256 bits et ICV de 16 octets dans GCM pour ESP.
IKE: Chiffrement AES avec des clés de 256 bits dans GCM, établissement de clés à l’aide du groupe DH 20 et authentification à l’aide de signatures à courbe elliptique ECDSA de 384 bits.
Les suites cryptographiques Suite-B prennent en charge IKEv1 et IKEv2. Les suites cryptographiques PRIME ne prennent en charge qu’IKEv2.