Thomas Moegli, profile picture
Téléchargé parThomas Moegli
6,577 vues

Protocole IKE/IPsec

Le document explique le fonctionnement des protocoles IKE et IPSec, qui assurent la mise en place de communications sécurisées dans des environnements non sécurisés. Il décrit les phases d'établissement des tunnels VPN et les mécanismes d'authentification, de négociation et de gestion des clés entre entités. Les protocoles incluent également des mesures contre divers types d'attaques et assurent la confidentialité, l'intégrité et l'authentification des données échangées.

Intégrer la présentation

Téléchargé 556 fois
Thomas Moegli Ing. HES Télécommunications - Réseaux et Sécurité IT Protocoles IKE/IPsec
Thomas Moegli ๏ IKE et IPsec fonctionnent ensemble pour permettre la mise en place de communications sécurisées sur un environnement non sécurisé Protocole IKE/IPsec 2 Cryptographie IPsec ISAKMP / IKE PKI Algorithmes de chiffrement Algorithmes de hachage Protocoles de tunneling Tunnel IPsec VPN Gestion et génération de clés Security Association Gestion et authentification d’une identité
Thomas Moegli ๏ IKE et IPsec fonctionnent ensemble pour permettre la mise en place de communications sécurisées sur un environnement non sécurisé Protocole IKE/IPsec 3 Négociation des paramètres de sécurité Etablissement des clés pour l’authentification Chiffrement, validation et authentification des données Validation et authentification des données ESP AH IKE Plande contrôle IKE Plandedonnées IPsec
Thomas Moegli ๏ Sert à assurer la gestion des clés entre les deux extrémités d’un tunnel VPN ๏ 2 versions : IKEv1 (RFC 2409) et IKEv2 (RFC 4306) qui ne sont pas interopérables entre eux ๏ Support des deux versions dans la plupart des équipements VPN ๏ Implémente certaines fonctionnalités de trois protocoles ๏ ISAKMP (Internet Security Association and Key Management Protocol) : Décrit un mécanisme d’authentification et d’échange de clés au moyen d’étapes sous forme de phases. ๏ Oakley : Décrit les différents séries d’échanges appelés modes et des services liés (PFS, Perfect Forward Secrecy, authentifcation, …). ๏ SKEME : Décrit une technique d’échange de clés permettant le renouvellement rapide des clés Protocole IKE/IPsec Protocole IKE 4 IKE Oakley Mécanisme d’échange de clés basée sur des phases SKEME Mécanisme pour un renouvellement rapide de clés ISAKMP Modes d’échanges et services liés (PFS, Authentification, …)
Thomas Moegli ๏ Une connexion VPN est composé de deux tunnels ๏ Un tunnel IKE pour l’échange de paramètres de sécurité entre entités ๏ Un tunnel IPSec qui sert au transfert de données entre entités ๏ IKE automatise le processus d’échange de clés entre entités pour la mise en oeuvre d’un tunnel lPsec ๏ Négociation des paramètres de sécurité au travers d’une SA (Security Association) ๏ Génération automatique des clés ๏ Renouvellement automatique des clés ๏ Sécurité avec IKE/ISAKMP ๏ Permet la protection contre les attaques Denial of Service (DoS), vol de connexion, attaques MitM (Man-in-the-Middle) Protocole IKE/IPsec Protocole IKE 5
Thomas Moegli ๏ Les clés générés par IKE servent à l’authentification et la protection du tunnel IKE, permettant ainsi l’échange de paramètres pour la négociation de clés IPSec ๏ Algorithme de Diffie-Hellman utilisé pour la mise en oeuvre d’une clé de session commune aux deux entités ๏ Les clés générés par IPSec servent au chiffrement des données ๏ Au bout d’un certain temps, les clés sont renouvelées ๏ Phase 1 IKE : négociation des clés IKE ๏ Phase 2 IKE : négociation des clés IPSec Protocole IKE/IPsec Protocole IKE 6 Etablissement du tunnel Trafic reçu Négociation IKE Main Mode Négociation IKE Quick Mode IKE IPsec Données
Thomas Moegli ๏ IPsec définit un protocole pour l’établissement et la gestion d’une communication privée entre deux entités ๏ L’établissement du tunnel IPsec s’effectue en négociant des paramètres entre entités via le tunnel IKE établi précédemment ๏ IPsec définit un lien sécurisé entre entités qui possède les propriétés suivantes ๏ Authentification des données ๏ Confidentialité ๏ Intégrité des données ๏ Anti-rejeu ๏ Utilisation d’un ou plusieurs protocoles pour atteindre ces buts ๏ AH (Authentication Header) ๏ ESP (Encapsulating Security Payload) Protocole IKE/IPsec Protocole IPsec 7 Application7 Présentation6 Session5 Transport4 Réseau3 Liaison de données2 Physique1 IPSec
Thomas Moegli ๏ Accord sur les paramètres de sécurité entre deux entités ๏ Il est nécessaire que les deux entités soient d’accord sur les réglages de sécurité ๏ L’ensemble de ces réglages est appelé Security Association (SA) ๏ Types de SA ๏ Unidirectionnel pour IKE ๏ Sur IPsec, une SA doit être définie pour chaque direction ๏ Contient ๏ Algorithme de chiffrement choisi ๏ Algorithme d’authentification choisi ๏ Clé de session partagée ๏ Lifetime ๏ Flux de donnés à protéger Protocole IKE/IPsec Security Association (SA) 8 IKE SA IPsec SA
Thomas Moegli ๏ Une caractéristique fondamentale d’IPsec est qu’une SA est définie pour chaque direction ๏ Dans l’exemple, il y a une SA entre Genève-Lausanne et une SA pour Lausanne-Genève ๏ Ces extrémités peuvent être également le point de terminaison d’autres tunnels (vers Fribourg et Bern dans l’exemple) ๏ Il peut également avoir plusieurs tunnels IPSec pour des paires de réseaux différents ๏ Ces tunnels peuvent avoir des réglages différents ๏ Ces réglages sont stockés dans une base de données appelée SAD (Security Association Database) Protocole IKE/IPsec Security Association Database (SAD) 9 Genève Fribourg Bern Lausanne
Thomas Moegli Protocole IKE/IPsec Contenu d’une SAD (Security Association Database) 10 Elément Description Security Parameter Index (SPI) Identification unique de la SA (valeur sur 32 bits) Utilisé en sortie pour construire les en-têtes ESP et AH, en entrée pour lier le trafic à une SA précise Sequence Number Compteur (64 bits) pour renseigner les champs des protocoles ESP et AH Anti-replay window Compteur (64 bits) pour détecter une attaque par rejeu Paramètres AH Spécifie les caractéristiques AH si celui-ci est choisi comme protocole Paramètres ESP Spécifie les caractéristiques ESP si celui-ci est choisi comme protocole Durée de vie Peut être exprimée en temps ou en bytes Mode IPsec Indique si la SA correspond à un trafic en mode tunnel ou transport Flags (Fragmentation, DF, …) Valeurs DSCP DSCP, Differentiated Services Code Point Valeurs autorisées dans la SA en sortie pour les codes permettant la QoS Bypass DSCP (Flag) Indique si on doit restreindre les flux sortants aux seuls paquets porteurs des valeurs DSCP indiquées plus haut Path MTU Décrit les MTU mis en place entre les deux extrémités de la SA Adresses source et destination Adresses IPv4 ou IPv6 figurant dans les en-têtes externes (en mode Tunnel)
Thomas Moegli ๏ Protocole en deux phases ๏ Phase 1 : Etablissement entre deux pairs d’un tunnel sécurisé et authentifié (Main Mode ou Agressive Mode) ๏ Phase 2 : Négociation et accord d’une SA IPsec entre pairs (Quick Mode) ๏ Chaque phase utilise une SA : ๏ ISAKMP SA (Phase 1, SA bidirectionnelle) ๏ Deux IPsec SA (Phase 2, SA unidirectionnelle, par paires d’entités) ๏ 1 Tunnel = 1 IKE SA + n * 2 IPsec SA (n = nombre de paires d’entités) Protocole IKE/IPsec IKE/IPsec et Security Association (SA) 11
Protocoles IKE/IPsec IKEv1
Thomas Moegli ๏ Modes IKE ๏ Main Mode : Authentification, établissement d’une IKE SA, chiffrement des identités (noms des entités communicants), 6 paquets ๏ Aggressive Mode : identique au Main Mode mais les identités ne sont pas chiffrés, 3 paquets ๏ Quick Mode : Génération de clés pour le tunnel IPsec, 3 paquets ๏ Informational Mode : Envoi de messages Notify (erreurs) ou messages Delete (fin de communication) ๏ Authentification IKE ๏ Signatures digitales ๏ Certificat X.509 échangé dynamiquement ๏ Chiffrement par clé publique ๏ Clés pré-partagées Protocole IKE/IPsec IKE 13
Thomas Moegli ๏ Etablissement du canal VPN en 2 phases Protocole IKE/IPsec IKE v1 14 Phase 1 (Canal ISAKMP SA) Etablissement d’un canal sécurisé avec authentification des deux entités Sert à l’échange d’informations nécessaires à l’établissement de la phase 2 Peut se dérouler selon deux modes Phase 2 (Canal IPsec SA) Etablissement de 2 canaux sécurisés pour l’échange de données Ne peut se faire que si la phase 1 s’est déroulé correctement Se déroule selon un seul mode Main Mode Aggressive Mode Quick Mode
Thomas Moegli Protocole IKE/IPsec IKE v1 15 Phase 1 : ISAKMP SA Main Mode (6 Messages) Aggressive Mode (3 Messages) Phase 2 : IPsec SA Quick Mode (3 Messages) Phase 2 : IPsec SA Quick Mode (3 Messages) …. Données protégéesA B Données protégéesA B
Thomas Moegli Protocole IKE/IPsec IKE v1 16 Main Mode (4 Premiers Messages) Quick Mode (3 Messages) Authentification Pre-Shared Keys (2 Messages) Authentification par certificat (2 Messages)
Thomas Moegli ๏ Structure d’un en-tête ISAKMP Protocole IKE/IPsec IKE v1 17 ๏ suivi d’une ou plusieurs charges (payload) commençant par cet en-tête : 32 Initiator Cookie Responder Cookie Next Payload Major Version Exchange Type Message ID Longueur Minor Version Flags 8 4 4 8 8 Next Payload Reserved Longueur 8 8 16
Thomas Moegli ๏ Exemple de structure complète ISAKMP Protocole IKE/IPsec IKE v1 18 32 Next Payload = Nonce 0 Données Payload IKE Longueur Payload IKE 8 Initiator Cookie Responder Cookie Next Payload Exchange Type Flags Major Version Minor Version 4 4 8 8 Message ID Longueur Next Payload = 0 0 Données Nonce Longueur Payload Nonce
Thomas Moegli ๏ Main Mode Protocole IKE/IPsec IKE v1 : Phase 1 19 INITIATEUR 1. HDR (CKi, 0), SA 2. HDR (CKi, CKr), SA Fin de la négociation des attributs SA 3. HDR (CKi, CKr), KE, nonce 4. HDR (CKi, CKr), KEy, nonce Calcul des secrets SKEYID, SKEYID_d, SKEYID_a, SKEYID_e) 5. HDR (CKi, CKr), IDi , HASHi 6. HDR (CKi, CKr), IDi , HASHr Les identités sont vérifiées et l’ISAKMP SA créée REPONDEUR Messages 1 et 2 Négociation de paramètres IKE SA / ISAKMP SA Messages 3 et 4 Echange d’informations requises pour la génération d’une clé avec l’algorithme Diffie-Hellman (DH) Messages 5 et 6 Echange d’informations d’authentification avec DH , SA , SA
Thomas Moegli 1er message ๏ Génération d’un Initiator Cookie par l’initiateur ๏ CKi = md5(src_ip,dest_ip, random number) ๏ Ajout d’une SA Payload permettant de négocier les paramètres de sécurisation des échanges ultérieurs ๏ Proposition de plusieurs suites de protection ๏ Chaque suite définit l’algorithme de chiffrement, hachage, méthode d’authentification et groupe Diffie-Hellman ainsi que des attributs optionnels (durée de vie de la ISAKMP SA) Protocole IKE/IPsec IKE v1 : Phase 1 20 INITIATEUR 1. HDR (CKi, 0), SA REPONDEUR Initiator Cookie Responder Cookie (= 0) SA Major version Minor version Exchange Type Flags Message ID Longueur (DOI et situation) Next Payload 1 SA Payload (Longueur) SA Payload Next Payload 1 Proposal Payload (Longueur) Proposal Payload Next Payload 1 Transform Payload (Longueur) Transform Payload Next Payload 1 Proposal Payload (Longueur) Proposal Payload 0 1 Transform Payload (Longueur) Transform Payload
Thomas Moegli INITIATEUR 2. HDR (CKi, CKr), SA REPONDEUR 2ème message ๏ Génération d’un Responder Cookie par le destinataire ๏ CKr = md5(src_ip,dest_ip, random number) ๏ Ajout d’une SA Payload précisant la suite retenue parmi celles proposées par l’inititateur Protocole IKE/IPsec IKE v1 : Phase 1 21 Initiator Cookie Responder Cookie SA Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 1 SA Payload (Longueur) SA Payload (DOI et situation) Next Payload 1 Proposal Payload (Longueur) Proposal Payload (Proposal #, Protocol ID, SPI Size, # of Transforms, SPI) 0 1 Transform Payload (Longueur) Transform Payload (Transform #, Transform ID, SA Attributes)
Thomas Moegli INITIATEUR 3. HDR (CKi, CKr), KE, nonce REPONDEUR 3ème message ๏ Génération de la valeur DH publique de l’initiateur ๏ Valeur DH publique : Xa ๏ Xa = ga mod p ๏ avec g (générateur), p (grand nombre premier) et a (valeur aléatoire privée) ๏ L’initiateur renvoie le cookie du destinataire, le sien, le nonce et les données d’échange de clés (symbolisé par KE) ๏ KE = Xa Protocole IKE/IPsec IKE v1 : Phase 1 22 Initiator Cookie Responder Cookie Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Nonce Payload (Longueur) KE Payload (inclut la valeur publique DH) Next Payload 0 KE Payload (Longueur) Nonce Payload (inclut Nonce)
Thomas Moegli 4ème message ๏ Génération de la valeur DH publique du responder ๏ Valeur DH publique : Xb ๏ Xb = gb mod p ๏ avec g (générateur), p (grand nombre premier) et b (valeur aléatoire privée) ๏ Le responder renvoie le cookie de l’initiateur, le sien, le nonce et les données d’échange de clés (symbolisé par KE) ๏ KE = Xb Protocole IKE/IPsec IKE v1 : Phase 1 23 Initiator Cookie Responder Cookie Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Nonce Payload (Longueur) KE Payload (inclut la valeur publique DH) Next Payload 0 KE Payload (Longueur) Nonce Payload (inclut Nonce) INITIATEUR 4. HDR (CKi, CKr), KEy, nonce REPONDEUR
Thomas Moegli Authentification par Pre-Shared Keys Messages 5 et 6 Protocole IKE/IPsec IKE v1 : Phase 1 24 Main Mode (4 Premiers Messages) Quick Mode (3 Messages) Authentification Pre-Shared Keys (2 Messages)
Thomas Moegli Calcul des secrets ๏ Les 4 premiers messages permettent d’éviter d’accepter des demandes IKE provenant d’adresses IP falsifiées ๏ Les calculs sont coûteux en ressources ๏ Les deux entités génèrent des informations gardées secrètes : ๏ On génère une clé SKEY_ID (Shared Key) ainsi
 SKEY_ID = hash(Pre-Shared Key, NonceI | NonceR) ๏ Puis on dérive les trois autres secrets ๏ SKEYIDd = hash(SKEYID, KE | CKI | CKR | 0)
 pour générer les clés pour IPsec SA ๏ SKEYIDa = hash(SKEYID, SKEYIDd | KE | CKI | CKR | 1)
 permet l’authentification des données IKE et de leur source ๏ SKEYIDe = hash(SKEYID, SKEYIDa | KE | CKI | CKR | 2)
 permet le chiffrement des messages IKE Protocole IKE/IPsec IKE v1 : Phase 1 25
Thomas Moegli INITIATEUR 5. HDR (CKi, CKr), IDi , HASHi REPONDEUR 5ème message ๏ Envoi du matériel d’authentification et son identifiant ๏ Le message est chiffré par la clé SKEYIDe ๏ Le message est authentifié par un hash appelé
 HASHi = hash(SKEYID, KE | CKi | CKr | SAr | IDi) Protocole IKE/IPsec IKE v1 : Phase 1 26 Initiator Cookie Responder Cookie Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Hash Payload (Longueur) SKEYID_e Identity Payload 0 0 Hash Payload Identity Payload (Longueur) ID Type DOI Specific ID Data
Thomas Moegli INITIATEUR 6. HDR (CKi, CKr), IDi , HASHr REPONDEUR 6ème message ๏ Envoi du matériel d’authentification et son identifiant ๏ Le message est chiffré par la clé SKEYIDe ๏ Le message est authentifié par un hash appelé
 HASHr = hash(SKEYID, KE | CKr | CKi | SAi | IDr) Protocole IKE/IPsec IKE v1 : Phase 1 27 Initiator Cookie Responder Cookie Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Hash Payload (Longueur) SKEYID_e Identity Payload 0 0 Hash Payload Identity Payload (Longueur) ID Type DOI Specific ID Data
Thomas Moegli Vérification des identités ๏ L’initiateur authentifie le Responder ๏ Déchiffrement du message avec SKEYIDe ๏ Identifie la Pre-Shared Key configurée en utilisant IDr ๏ Calcule de lui-même HASHr ๏ Compare HASHr avec la valeur HASHr reçue. Si les deux valeurs sont identiques, l’authentification est réussie ๏ Le Responder authentifie l’Initiator ๏ Déchiffrement du message avec SKEYIDe ๏ Identifie la Pre-Shared Key configurée en utilisant IDi ๏ Calcule de lui-même HASHi ๏ Compare HASHi avec la valeur HASHi reçue. Si les deux valeurs sont identiques, l’authentification est réussie Protocole IKE/IPsec IKE v1 : Phase 1 28
Thomas Moegli Authentification par certificat Dans les messages 3 et 4, l’initiateur et le responder s’envoient mutuellement une requête de certificat Messages 5 et 6 Protocole IKE/IPsec IKE v1 : Phase 1 29 Main Mode (4 Premiers Messages) Quick Mode (3 Messages) Authentification par certificat (2 Messages)
Thomas Moegli Initiator Cookie Responder Cookie Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Signature Payload (Longueur) SKEYID_e Identity Payload Next Payload 0 Signature Data Identity Payload (Longueur) ID Type DOI Specific ID Data Certificate Payload (Longueur)0 0 Certificate Data Certificate Encoding Certificate Data 5ème et 6ème message ๏ Envoi des certificats par l’initiateur et responder ๏ Le message est chiffré par la clé SKEYIDe ๏ Le message est signé
 SIGi = PRIVATE_KEYi (HASHi)
 SIGr = PRIVATE_KEYr (HASHr) Protocole IKE/IPsec IKE v1 : Phase 1 30
Thomas Moegli Protocole IKE/IPsec IKE v1 : Phase 1 31 Aggressive Mode (3 Premiers Messages) Quick Mode (3 Messages)
Thomas Moegli ๏ La protection contre les dénis de service est plus faible ๏ Les 3 échanges préalables mentionnés en mode Main n’existent pas ๏ Les calculs DH commencent dès la réception du premier cookie ๏ 3 messages échangés Protocole IKE/IPsec IKE v1 : Phase 1 32 1. HDR (CKi, 0), SA, KE, Noncei, IDi Identités vérifiées, IKE SA créée 2. HDR (CKi, CKr), SA, KE, Noncer, IDr, HASHr 3. HDR (CKi, CKr), HASHi REPONDEUR INITIATEUR Aggressive Mode
Thomas Moegli 1er message ๏ Contient les suites de protection, sa valeur publique DH, son nonce et son identité 2ème message ๏ Le répondeur retourne la suite de protection sélectionnée, sa valeur publique DH, son nonce, son identité et des données d’authentification (hachage pour une authentification par Pre-Shared Key, signature pour une authentification par certificat) 3ème message ๏ L’initiateur répond par ses propres données d’authentification Protocole IKE/IPsec IKE v1 : Phase 1 33
Thomas Moegli ๏ Ne comporte qu’un seul mode : Quick Mode (3 messages) ๏ Si PFS (Perfect Forward Secrecy) n’est pas demandé, le mode est rapide car ne demande pas de calculs DH ๏ Permet de générer les IPsec SA qui permettent de protéger les échanges de données entre entités du tunnel ๏ Possibilité d’avoir plusieurs SA, une par sens et par protocole ๏ Si PFS est activé, le nombre de messages ne change pas mais des paramètres supplémentaires sont échangés Protocole IKE/IPsec IKE v1 : Phase 2 34 REPONDEUR INITIATEUR Négociation IPsec Je veux protéger ip traffic from 10.1.3.0/24 à 10.2.5.0/24 J’offre : ESP avec AES et SHA ESP avec 3DES et SHA Voici mon Noncei PFS demandé; voici ga Ok, je protège ip traffic from 10.1.3.0/24 à 10.2.5.0/24 Je choisis : ESP avec AES et SHA Voici mon Noncer PFS ok; voici gb Ok, merci
Thomas Moegli Protocole IKE/IPsec IKE v1 : Phase 2 35 1. HDR (CKi, 0), HASH1, SA, Noncei, [KE], [IDi, IDr] Identités vérifiées, IPsec SA créées 2. HDR (CKi, CKr), HASH2, SA, [KE], [IDi, IDr] 3. HDR (CKi, CKr), HASH3 REPONDEUR INITIATEUR Négociation des IPsec SA (3 Premiers Messages) Quick Mode
Thomas Moegli ๏ Propriété permettant à une information chiffrée aujourd’hui de rester confidentielle en cas de compromission future de la clé privée d’un correspondant ๏ Coûteux en calculs ; de nombreux serveurs ne l’utilisent pas ๏ Google supporte depuis 2011 le PFS sur tous ses sites accessibles en HTTPS
 https://security.googleblog.com/2011/11/protecting-data-for-long-term-with.html Protocole IKE/IPsec PFS : Perfect Forward Secrecy 36
Thomas Moegli Activation de PFS ๏ Du côté de l’Initiator ๏ Nonce généré : Noncei ๏ Nouvelle valeur DH publique : Xa’ ๏ Xa’ = ga mod p ๏ avec g (générateur), p (grand nombre premier) et a (valeur aléatoire privée) Protocole IKE/IPsec IKE v1 : Phase 2 37 ๏ Du côté du Responder ๏ Nonce généré : Noncer ๏ Nouvelle valeur DH publique : Xb’ ๏ Xb’= gb mod p ๏ avec g (générateur), p (grand nombre premier) et a (valeur aléatoire privée)
Thomas Moegli 1. HDR (CKi, 0), HASH1, SA, Noncei, [KE], [IDi, IDr] REPONDEUR INITIATEUR 1er message ๏ Envoi du matériel d’authentification et son identifiant ๏ Proposition de plusieurs suites de protection Protocole IKE/IPsec IKE v1 : Phase 2 38 Initiator Cookie Responder Cookie KE Major version Minor version Exchange Type Flags Message ID Longueur …
Thomas Moegli SA 0 Hash Payload (Longueur) SKEYID_e Hash Payload Next Payload 0 SA Payload (inclut DOI et situation) Proposal Payload (Longueur) SA Payload (Longueur) Next Payload 0 Proposal Payload Next Payload 0 Transform Payload Transform Payload (Longueur) Proposal Payload (Longueur)Next Payload 0 Proposal Payload Next Payload 0 Transform Payload Transform Payload (Longueur) Next Payload 0 Keyload Payload (Longueur) KE Payload Next Payload 0 Nonce Payload (Noncei) Nonce Payload (Longueur) Next Payload 0 Identity Payload (Longueur) ID Type Identity Payload (IDs) DOI Specific ID Data Next Payload 0 Identity Payload (Longueur) ID Type Identity Payload (IDd) DOI Specific ID Data Proposal : ESP ou AH, SHA ou MD5, DH 1 ou 2, SPI (2 propositions dans cet exemple) Transform : Tunnel ou Transport IPsec Timeout KE Payload = Xa ’ IDs = Source Proxy IDd = Destination Proxy 1. HDR (CKi, 0), HASH1, SA, Noncei, [KE], [IDi, IDr] REPONDEUR INITIATEUR 1er message ๏ Envoi du matériel d’authentification et son identifiant ๏ Proposition de plusieurs suites de protection Protocole IKE/IPsec IKE v1 : Phase 2 39
Thomas Moegli 2. HDR (CKi, CKr), HASH2, SA, [KE], [IDi, IDr] REPONDEUR INITIATEUR Initiator Cookie Responder Cookie KE Major version Minor version Exchange Type Flags Message ID Longueur … 2ème message ๏ Envoi du matériel d’authentification et son identifiant ๏ Sélection d’une suite parmi celle proposées Protocole IKE/IPsec IKE v1 : Phase 2 40
Thomas Moegli 2. HDR (CKi, CKr), HASH2, SA, [KE], [IDi, IDr] REPONDEUR INITIATEUR 2ème message ๏ Envoi du matériel d’authentification et son identifiant ๏ Sélection d’une suite parmi celle proposées Protocole IKE/IPsec IKE v1 : Phase 2 41 SA 0 Hash Payload (Longueur) SKEYID_e Hash Payload Next Payload 0 SA Payload (inclut DOI et situation) Proposal Payload (Longueur) SA Payload (Longueur) Next Payload 0 Proposal Payload Next Payload 0 Transform Payload Transform Payload (Longueur) Next Payload 0 Keyload Payload (Longueur) KE Payload Next Payload 0 Nonce Payload (Noncer) Nonce Payload (Longueur) Next Payload 0 Identity Payload (Longueur) ID Type Identity Payload (IDs) DOI Specific ID Data Next Payload 0 Identity Payload (Longueur) ID Type Identity Payload (IDd) DOI Specific ID Data Proposal : Responder SPI KE Payload = Xb ’
Thomas Moegli Calcul DH (en cas d’activation PFD) ๏ Du côté de l’Initiator ๏ Calcul DH : KE = (Xb’)a mod p ๏ Clé de session IPsec : 
 key = PRF(SKEYIDd | protocol(ISAKMP) | KE | SPi | Noncei | Noncer) Protocole IKE/IPsec IKE v1 : Phase 2 42 ๏ Du côté du Responder ๏ Calcul DH : KE = (Xa’)b mod p ๏ Clé de session IPsec : 
 key = PRF(SKEYIDd | protocol(ISAKMP) | KE | SPi | Noncei | Noncer)
Thomas Moegli Initiator Cookie Responder Cookie KE Major version Minor version Exchange Type Flags Message ID Longueur SA 0 Hash Payload (Longueur) SKEYID_e Hash Payload 3. HDR (CKi, CKr), HASH3 REPONDEUR INITIATEUR 3ème message ๏ Le client valide la mise en place du tunnel IPsec en envoyant un dernier paquet Protocole IKE/IPsec IKE v1 : Phase 2 43
Protocoles IKE/IPsec IKEv2
Thomas Moegli ๏ RFC 4306 (décembre 2005)
 RFC 5996 (septembre 2010)
 RFC 6989 ( juillet 2013) ๏ On réduit les 8 échanges initiaux (Phase 1 et Phase 2) 
 à 4 échanges Protocole IKE/IPsec IKE v2 45 IKE_SA_INIT (2 à 4 Messages) IKE_AUTH (2 Messages) CREATE_CHILD_SA (2 Messages) Données protégéesA B Authentification du tunnel IKE_SA Négociation des paramètres Transmission et authentification des entités Génère le premier Child SA (similaire à IPsec SA) (Opt) Création d’un second Child SA si nécessaire
Thomas Moegli ๏ Support de méthodes d’authentification nouvelles au travers d’EAP (Extensible Authentication Protocol) ๏ Permet d’offrir d’autres méthodes que des clés partagés et des certificats ๏ Prise en charge de NAT Traversal (NAT-T) par le port 4500 Protocole IKE/IPsec IKE v2 46
Thomas Moegli 1er message ๏ Permet de négocier les paramètres de sécurité de la SA et de communiquer les valeurs de nonces et de Diffie- Hellman Protocole IKE/IPsec IKE v2 47 Initiator SPI Responder SPI Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 KE Payload (Longueur) KE Payload (inclut valeurs publiques DH) Next Payload SA Payload (inclut informations Proposal et Tranform) Nonce Payload (Longueur) SA Payload (Longueur) Next Payload Nonce C 0C 0C IKE_SA_INIT (2 à 4 Messages) REPONDEUR INITIATEUR
Thomas Moegli REPONDEUR INITIATEUR 2ème message ๏ Permet de négocier les paramètres de sécurité de la SA et de communiquer les valeurs de nonces et de Diffie- Hellman Protocole IKE/IPsec IKE v2 48 Initiator SPI Responder SPI Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 KE Payload (Longueur) KE Payload (inclut valeurs publiques DH) Next Payload SA Payload (inclut informations Proposal et Tranform) Nonce Payload (Longueur) SA Payload (Longueur) Next Payload Nonce C 0C 0C IKE_SA_INIT (2 à 4 Messages)
Thomas Moegli REPONDEUR INITIATEUR IKE_AUTH (2 Messages) Initiator SPI Responder SPI Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Auth Payload (Longueur) SK_e,SK_a Authentication Payload Next Payload ID Payload (contient Initiator ID) SA Payload (Longueur) ID Payload (Longueur) Next Payload SA Payload pour le premier CHILD_SA C 0C 0C TS Payload (Longueur) Traffic Selector Payload Next Payload TS Payload (Longueur)Next Payload Traffic Selector Payload 0C 0C 3ème message ๏ Transmission et authentification des identités ๏ Génère la première Child SA si tout se passe bien ๏ Child SA = équivalent à IPsec SA ๏ L’échange recouvre une partie de la phase 1 d’IKEv1 et une partie de la phase 2 (IPsec SA) Protocole IKE/IPsec IKE v2 49
Thomas Moegli IKE_AUTH (2 Messages) Initiator SPI Responder SPI Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Auth Payload (Longueur) SK_e,SK_a Authentication Payload Next Payload ID Payload (contient Initiator ID) SA Payload (Longueur) ID Payload (Longueur) Next Payload SA Payload pour le premier CHILD_SA C 0C 0C TS Payload (Longueur) Traffic Selector Payload Next Payload TS Payload (Longueur)Next Payload Traffic Selector Payload 0C 0C REPONDEUR INITIATEUR 4ème message ๏ Transmission et authentification des identités ๏ Génère la première Child SA si tout se passe bien ๏ Child SA = équivalent à IPsec SA ๏ L’échange recouvre une partie de la phase 1 d’IKEv1 et une partie de la phase 2 (IPsec SA) Protocole IKE/IPsec IKE v2 50
Thomas Moegli CREATE_CHILD_SA (2 Messages) 5ème message ๏ Permet de générer, si besoin, d’autres Child SA ๏ Echange du matériel d’authentification et identifiants Protocole IKE/IPsec IKE v2 51 REPONDEUR INITIATEUR Initiator SPI Responder SPI Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Nonce Payload (Longueur) SK_e,SK_a Nonce Next Payload SA Payload (inclut informations Proposal et Transform) SA Payload (Longueur)C 0C TS Payload (Longueur) Traffic Selector Payload Next Payload TS Payload (Longueur)Next Payload Traffic Selector Payload 0C 0C
Thomas Moegli CREATE_CHILD_SA (2 Messages) 6ème message ๏ Permet de générer, si besoin, d’autres Child SA ๏ Echange du matériel d’authentification et identifiants Protocole IKE/IPsec IKE v2 52 Initiator SPI Responder SPI Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Nonce Payload (Longueur) SK_e,SK_a Nonce Next Payload SA Payload (inclut informations Proposal et Transform) SA Payload (Longueur)C 0C TS Payload (Longueur) Traffic Selector Payload Next Payload TS Payload (Longueur)Next Payload Traffic Selector Payload 0C 0C REPONDEUR INITIATEUR
Protocoles IKE/IPsec IPsec
Thomas Moegli ๏ IPsec définit un protocole pour l’établissement et la gestion d’une communication privée entre deux entités ๏ IPsec définit un lien sécurisé entre entités qui possède les propriétés suivantes ๏ Authentification des données ๏ Confidentialité ๏ Intégrité des données ๏ Anti-rejeu ๏ Utilisation d’un ou plusieurs protocoles pour atteindre ces buts ๏ AH (Authentication Header) ๏ ESP (Encapsulating Security Payload) Protocole IKE/IPsec IPsec 54 Application7 Présentation6 Session5 Transport4 Réseau3 Liaison de données2 Physique1 IPSec
Thomas Moegli ๏ Défini sur plusieurs RFC ๏ Security Architecture for the Internet Protocol (RFC 2401) ๏ IP Security Document Road Map (RFC 2411) ๏ IP Authentication Header (AH) (RFC 2402) ๏ IP Encapsulating Security Payload (ESP) (RFC 2406) Protocole IKE/IPsec IPsec 55
Thomas Moegli ๏ L’application du protocole AH ou ESP dépend du mode d’opération IPsec ๏ Il existe deux modes d’opération ๏ Mode tunnel ๏ La totalité du paquet IP est chiffré et/ou authentifié ๏ Le paquet est ensuite encapsulé dans un nouveau paquet IP avec une nouvelle en-tête IP ๏ Mode transport ๏ Seules les données transférées (le payload du paquet IP) sont chiffrées et/ou authentifiées ๏ Le reste du paquet IP est inchangé Protocole IKE/IPsec Modes d’opération IPsec 56
Thomas Moegli Comparaison des modes Protocole IKE/IPsec Modes d’opération IPsec 57 IP Header Data IP Header DataIPsec Header Mode Transport IP Header Data New IP Header DataIPsec Header Mode Tunnel IP Header Peut être chiffré Peut être chiffré IPsec Footer IPsec Footer
Thomas Moegli ๏ Protocole permettant l’authentification et l’intégrité des données échangées ๏ N’est pas prévu pour assurer la confidentialité ๏ Défini par ๏ 2008 : RFC 4302 complété du RFC 4305 (remplacé par RFC 4835 en 2007) ๏ Version d’origine de 1998 (RFC 2402) ๏ Chaque paquet est authentifié et validé en utilisant des mécanismes de signatures numériques ๏ Algorithmes MD5, SHA1 Protocole IKE/IPsec Authentication Header (AH) 58
Thomas Moegli Intégration de l’en-tête AH dans un paquet IP (Mode tunnel) : ๏ Création d’un nouvel en-tête IP au début du paquet ๏ Valeur de protocole IP apparaissant dans l’en-tête IP externe : 51 (AH) ๏ Mode utilisé par défaut Protocole IKE/IPsec Authentication Header (AH) 59 Adresse IP Source Adresse IP Dst En-tête TCP (Protocole = 6) TCP Payload Adresse IP Source Adresse IP Dst En-tête TCP TCP Payload En-tête AH Next Header = 4 (IP) Nouvelle Adresse IP Source Nouvelle Adresse IP Dst Partie authentifiée
Thomas Moegli Intégration de l’en-tête AH dans un paquet IP (Mode transport) :
 
 
 
 
 
 
 ๏ Conservation de l’en-tête IP original avec insertion d’un en-tête AH ๏ Le Next Header de l’en-tête AH indique directement le protocole TCP (valeur = 6), UDP (valeur = 17), ICMP (valeur = 1) ou tout autre protocole transporté par IP Protocole IKE/IPsec Authentication Header (AH) 60 Adresse IP Source Adresse IP Dst En-tête TCP (Protocole = 6) TCP Payload Adresse IP Source Adresse IP Dst En-tête TCP TCP Payload En-tête AH Next Header = 6 (TCP) Partie authentifiée
Thomas Moegli ๏ Structure de l’en-tête AH : Protocole IKE/IPsec Authentication Header (AH) 61 Next Header Payload Length Security Parameter Index (SPI) Reserved 8 Authentication Data (Integrity Check Value) Sequence Number 8 16
Thomas Moegli Structure de l’en-tête AH : Protocole IKE/IPsec Authentication Header (AH) 62 Elément Description Next Header Numéro du protocole contenu dans la charge située immédiatement après l’en-tête AH En mode tunnel : il s’agit d’IPv4 ou IPv6 Longueur charge
 Payload length Représente la taille de l’en-tête AH SPI
 Security Parameter Index Numéro d’index dans la base SPD Permet de relier le paquet à une assic Sequence number Compteur permettant de détecter des paquets qui seraient rejoués après avoir été enregistrés. Est incrémenté de 1 à chaque envoi par l’émetteur. Lorsque la valeur max est atteinte (232), l’émetteur doit négocier la création d’une nouvelle SA Données pour authentification Résultat du calcul d’un MAC dénommé ICV (Integrity Check Value)
Thomas Moegli ๏ Le champ Données pour auth. permet d’assurer que la trame est authentique et non altéré ๏ Couvre tout le paquet IP d’origine, sauf les champs modifiables lors du routage : ๏ Champ TOS (Type Of Service) ๏ Champ Flags (don’t fragment…) ๏ Champ Fragment Offset ๏ Champ TTL (Time To Live) ๏ Champ IP Header Checksum ๏ Le calcul de l’ICV s’effectue en mettant tous les champs variables ci-dessus à zéro Protocole IKE/IPsec Authentication Header (AH) 63
Thomas Moegli ๏ Avantages de AH ๏ Protocole relativement léger car il ne chiffre pas les données ๏ Peut être utilisé en combinaison avec ESP si la confidentialité des données échangées est primordiale ๏ Limitations ๏ L’authentification se fait sur la quasi-totalité du paquet, dont les adresses IP externes.
 Impossible de mettre en œuvre le NAT (Network Address Translation) puisque les IP du paquet vont changer ๏ Nécessite d’utiliser l’encapsulation NAT-T ๏ Depuis 2005, les RFC sur IPsec ne requièrent plus qu’une implémentation IPsec doit supporter AH Protocole IKE/IPsec Authentication Header (AH) 64
Thomas Moegli ๏ Protocole permettant la confidentialité, l’intégrité des données, l’authentification et le 
 contrôle d’anti-rejeu ๏ Défini par ๏ 2005 : RFC 4305 ๏ Version d’origine de 1998 (RFC 2406) Protocole IKE/IPsec Encapsulation Security Payload (ESP) 65
Thomas Moegli ๏ Structure de l’en-tête ESP Protocole IKE/IPsec Encapsulation Security Payload (ESP) 66 Next Header Payload Length Security Parameter Index (SPI) Reserved 8 Padding Sequence Number 8 16 Payload Peut contenir en début un champ IV Payload Next HeaderPadding length Integrity Check Value (ICV) Authentication Data
Thomas Moegli Structure de l’en-tête ESP : Protocole IKE/IPsec Encapsulation Security Payload (ESP) 67 Elément Description SP Numéro d’index dans la base SPD Permet de relier le paquet à une association de sécurité (SA) Sequence Number Compteur permettant de détecter des paquets qui seraient rejoués après avoir été enregistrés. Est incrémenté de 1 à chaque envoi par l’émetteur. Lorsque la valeur max est atteinte (232), l’émetteur doit négocier la création d’une nouvelle SA IV 
 Initialisation Vector (Facultatif) Contient les 8 premiers octets de la zone « Données Protégées ». Certains modes de chiffrement (CBC par ex.) ne nécessitent pas d’IV Payload Données utilisateur transférées par le tunnel VPN Padding Bits de bourrage pour aligner les blocs à chiffrer (requis pour certains modes de chiffrement) ICV Ne sont présentes que si l’authentification est requise. Leur taille est variable, suivant l’algorithme choisi.
Thomas Moegli Intégration de l’en-tête ESP dans un paquet IP (Mode tunnel) : ๏ Création d’un nouvel en-tête IP au début du paquet et présence de champs ESP situés en fin de paquet ๏ Valeur de protocole IP apparaissant dans l’en-tête IP externe : 50 (ESP) Protocole IKE/IPsec Encapsulation Security Payload (ESP) 68 Adresse IP Source Adresse IP Dst En-tête TCP (Protocole = 6) TCP Payload Adresse IP Source Adresse IP Dst En-tête TCP TCP Payload En-tête ESP Next Header = 4 (IP) Nouvelle Adresse IP Source Nouvelle Adresse IP Dst Partie authentifiée En-queue ESP ICV ESP Authentification Partie chiffrée
Thomas Moegli Intégration de l’en-tête ESP dans un paquet IP (Mode tunnel) : Protocole IKE/IPsec Encapsulation Security Payload (ESP) 69 Adresse IP Source Adresse IP Dst En-tête TCP (Protocole = 6) TCP Payload Adresse IP Source Adresse IP Dst En-tête TCP TCP Payload En-tête ESP Next Header = 6 (TCP) Partie authentifiée En-queue ESP ICV ESP Authentification Partie chiffrée
Thomas Moegli ๏ Avantages de ESP ๏ Franchit les NAT ๏ Limitations ๏ N’authentifie pas les adresses IP externes du paquet (d’où la possibilité de franchir les NAT) ๏ Ne peut gérer PAT Protocole IKE/IPsec Encapsulation Security Payload (ESP) 70
Protocoles IKE/IPsec Extensions IKE
Thomas Moegli ๏ IKE Keepalive : Dead IKE Peer Detection (DPD) ๏ X-AUTH : Authentification dans une session IKE ๏ Mode Config : Envoi de paramètres IP aux clients ๏ NAT-T : Fonctionnement d’un VPN IPSec au travers d’un NAT Protocole IKE/IPsec Extensions IKE 72
Thomas Moegli ๏ Techniques permettant la détection de la perte d’un VPN et permettre la reconstruction d’un VPN opérationnel dans les plus brefs délais ๏ Deux méthodes : ๏ Méthode historique : IKE Keep-Alive ๏ Méthode plus récente, normalisée par le RFC 3706 : Dead Peer Detection (DPD) Protocole IKE/IPsec Extensions IKE : IKE Keep-Alive et DPD 73
Thomas Moegli ๏ Soit deux équipements A et B avec un tunnel VPN qui relie ces deux entités ๏ Une des entités (A ou B) émet régulièrement des requêtes (messages HELLO) vers l’autre extrémité ๏ Attente d’une réponse du voisin (message ACK) ๏ Sur certaines implémentations, il suffit qu’un des côtés (A) envoie régulièrement des HELLO pour que le lien soit considéré comme vivant par B ๏ Toutefois, A ne peut pas détecter la perte du VPN, il s’agit d’une détection unidirectionnelle ๏ Il est possible de mettre une détection sur chaque sens, mais les performances ne sont pas intéressantes ๏ Problèmes rencontrées ๏ Méthode non normalisée, est difficilement employable entre matériels de marque différentes ๏ Peut être très consommatrice de bande passante Protocole IKE/IPsec Extensions IKE : IKE Keep-Alive 74
Thomas Moegli ๏ Soit deux équipements A et B avec un tunnel VPN qui relie ces deux entités ๏ Si A et B échangent du trafic, c’est que le lien est vivant : il n’y a pas besoin d’autres preuves que le VPN est toujours présent ๏ Si aucun échange ne s’est produit récemment : ๏ Si A souhaite envoyer un flux vers B, il lance une requête vers B via un message IKE de type NOTIFY : R-U-THERE ๏ B doit répondre par un R-U-THERE-ACK ๏ Si B ne répond pas au bout d’un délai défini de son côté par A, A doit réitérer l’envoi de sa demande ๏ Si le nombre de tentatives défini par A est atteint, A peut décréter que le lien est perdu est supprimer de sa table les SA concernées Protocole IKE/IPsec Extensions IKE : Dead Peer Detection (DPD) 75 VPN Concentrator Application Server Données reçues Message DPD : R-U-THERE Aucune donnée reçue Message DPD : R-U-THERE-ACK Internet
Thomas Moegli ๏ B peut définir des critères de DPD qui soient différents de ceux de A ๏ Exemple : un VPN entre un site de fabrication et un site d’administration
 La liaison du site de fabrication vers le site d’administration est plus cruciale que le sens inverse ๏ Méthode plus performante que Keep-alive car moins coûteuse en échanges tout en assurant des détections très rapides ๏ Incorpore également des protections contre certaines attaques (Anti-rejeu) via l’utilisation de numéros de séquence ๏ Inconvénients : ๏ Fonction relativement récente, n’est pas forcément présente sur tous les matériels ๏ La détection de la perte d’un VPN ne se fait qu’au moment ou le trafic doit être envoyée, le délai de détection peut donc être relativement importante Protocole IKE/IPsec Extensions IKE : Dead Peer Detection (DPD) 76 Internet A B Je dois envoyer à B régulièrement des données. Je dois savoir rapideement si le tunnel vers B est ok Ce n’est pas très important si je perds la liaison vers A Le passage de trafic IPSec prouve que la liaison VPN est active DPD est asynchrone Chaque voisin définit ses critères DPD Vérification du voisin uniquement si nécessaire
Thomas Moegli Protocole IKE/IPsec Extensions IKE : Dead Peer Detection (DPD) 77 Initiator Répondeur R-YOU-THERE R-YOU-THERE-ACK 32 ISAKMP Header Next Payload Notify Payload LengthReserved 8 8 8 8 DOI = IPsec DOI SPI = CKYi | CKYr Protocol ID = ISAKMP Notify Message Type = R-U-THERE SPI Size Notification Data = Sequence Number 32 ISAKMP Header Next Payload Notify Payload LengthReserved 8 8 8 8 DOI = IPsec DOI SPI = CKYi | CKYr Protocol ID = ISAKMP Notify Message Type = R-U-THERE SPI Size Notification Data = Sequence Number
Thomas Moegli X-AUTH : Authentification dans une session IKE ๏ Génération d’une IKE SA dans la phase 1 ๏ Permet d’implémenter une authentification utilisateur entre la phase 1 et la phase 2 ๏ Appelé parfois Phase 1.5 Mode Config : Envoi de paramètres IP au client ๏ Permet de négocier des adresses IP au travers d’un tunnel sécurisé (similaire à un serveur DHCP) ๏ Requête ISAKMP_CFG_REQUEST envoyé de l’Initiator au Responder ๏ L’Initiator utilise ensuite les attributs IP et procède ensuite à la phase 2 pour la négociation des IPsec SA Protocole IKE/IPsec Extensions IKE : Mode Config et XAUTH 78
Thomas Moegli Protocole IKE/IPsec Extensions IKE : Mode Config et XAUTH 79 Phase 1 : ISAKMP SA Main Mode (6 Messages) Aggressive Mode (3 Messages) Phase 2 : IPsec SA Quick Mode (3 Messages) Phase 2 : IPsec SA Quick Mode (3 Messages) …. Données protégéesA B Données protégéesA B Phase 1.5 : XAUTH et/ou Mode Config
Thomas Moegli Protocole IKE/IPsec Extensions IKE : Authentification XAUTH 80 CHAP WAN Passerelle IPsec Client IPsec Serveur AAA Username/Password OTP S/Key Passerelle IPsec
Thomas Moegli Protocole IKE/IPsec Extensions IKE : Mode Config 81 CHAP WAN Passerelle IPsec Client IPsec Serveur AAA Username/Password OTP S/Key Passerelle IPsec ๏ Mécanisme utilisé pour envoyer les attributs IP aux clients IPsec distants Adresse IP interne Serveur DNS Serveur DHCP Attributs optionnels
Thomas Moegli Protocole IKE/IPsec Extensions IKE : Authentification XAUTH 82 IKE Phase 1 XAuth : Prompt = « Challenge 123DE4 » XAuth : Name = « Joe », Pwd = « 123ZDE » Mode Config : IP Address, DNS, WINS, …. IKE Phase 2 - IPsec SA Attribute Value Type XAUTH-TYPE 16520 Basic XAUTH-USER-NAME 16521 Variable ASCII string XAUTH-USER-PASSWORD 16522 Variable ASCII string XAUTH-PASSCODE 16523 Variable ASCII string XAUTH-MESSAGE 16524 Variable ASCII string XAUTH-CHALLENGE 16525 Variable ASCII string XAUTH-DOMAIN 16526 Variable ASCII string XAUTH-STATUS 16527 Basic XAUTH-NEXT-PIN 16528 Variable XAUTH-ANSWER 16529 Variable ASCII string
Thomas Moegli Merci de votre attention ! thomas.moegli@icloud.com Références ๏ Advanced Networks, Cours HEIG-VD (F. Bruchez) ๏ Les VPN : Fonctionnement, mise en oeuvre et maintenance des Réseaux Privés Virtuels, ENI Editions (J-P. Archier) ๏ Réseaux Privés Virtuels - VPN, Frameip [http://www.frameip.com/vpn/] (X. Lasserre, T. Klein, _SebF) 83

Contenu connexe

PPTX
Les Vpn
parmedalaa
 
PDF
configuration vpn-ipsec-routeur
parJULIOR MIKALA
 
PDF
VPN - Virtual Private Network
parjulienlfr
 
PPTX
présentation sur le vpn
parManuel Cédric EBODE MBALLA
 
PDF
Vpn d’acces avec cisco asa 5500 et client
parManassé Achim kpaya
 
PPTX
La sécurité des réseaux sans fil
parsmiste
 
PDF
Cours SNMP
parEL AMRI El Hassan
 
PDF
Mise en place du Firewall IPCop
parMohammed Zaoui
 
Les Vpn
parmedalaa
 
configuration vpn-ipsec-routeur
parJULIOR MIKALA
 
VPN - Virtual Private Network
parjulienlfr
 
présentation sur le vpn
parManuel Cédric EBODE MBALLA
 
Vpn d’acces avec cisco asa 5500 et client
parManassé Achim kpaya
 
La sécurité des réseaux sans fil
parsmiste
 
Cours SNMP
parEL AMRI El Hassan
 
Mise en place du Firewall IPCop
parMohammed Zaoui
 

Tendances

PDF
Protocoles SSL/TLS
parThomas Moegli
 
PPTX
SSL - Secure Sockets Layer - Présentation
parIkram Benabdelouahab
 
PDF
VPN site-to-site.pdf
pargorguindiaye
 
PPT
IPsec
parIvandro Ismael
 
PPTX
Vpn
parmalekoff
 
PDF
Ch_1 - Généralités sur la sécurité informatique.pdf
parNafissa11
 
PDF
Tuto VP IPSEC Site-to-site
parDimitri LEMBOKOLO
 
PDF
Diaporamas-Réseaux Informatiques.pdf
parEST-UMI de Meknès
 
DOC
mis en place dun vpn site à site
parManuel Cédric EBODE MBALLA
 
PPT
Vpn
parkwabo
 
PDF
Tp snmp-packet-tracer
parChris Dogny
 
PDF
Introduction aux réseaux locaux
parInes Kechiche
 
PDF
Présentation etherchannel
parLechoco Kado
 
PDF
Cours les technologies WAN
parEL AMRI El Hassan
 
PPT
Ccnp securite vpn
parsara ousaoud
 
PDF
Sécurité des réseaux
parSehla Loussaief Zayen
 
PPTX
Routage
parSirine Ibrahim
 
DOCX
Rapport mise en place d'un sevrer VPN .
parMouad Lousimi
 
DOCX
Tp securité des reseaux
parAchille Njomo
 
PDF
Mise en place de vlan au sein d'un réseau
parGeorges Amichia
 
Protocoles SSL/TLS
parThomas Moegli
 
SSL - Secure Sockets Layer - Présentation
parIkram Benabdelouahab
 
VPN site-to-site.pdf
pargorguindiaye
 
IPsec
parIvandro Ismael
 
Vpn
parmalekoff
 
Ch_1 - Généralités sur la sécurité informatique.pdf
parNafissa11
 
Tuto VP IPSEC Site-to-site
parDimitri LEMBOKOLO
 
Diaporamas-Réseaux Informatiques.pdf
parEST-UMI de Meknès
 
mis en place dun vpn site à site
parManuel Cédric EBODE MBALLA
 
Vpn
parkwabo
 
Tp snmp-packet-tracer
parChris Dogny
 
Introduction aux réseaux locaux
parInes Kechiche
 
Présentation etherchannel
parLechoco Kado
 
Cours les technologies WAN
parEL AMRI El Hassan
 
Ccnp securite vpn
parsara ousaoud
 
Sécurité des réseaux
parSehla Loussaief Zayen
 
Routage
parSirine Ibrahim
 
Rapport mise en place d'un sevrer VPN .
parMouad Lousimi
 
Tp securité des reseaux
parAchille Njomo
 
Mise en place de vlan au sein d'un réseau
parGeorges Amichia
 

Similaire à Protocole IKE/IPsec

PPTX
Vpn
parmalekoff
 
PDF
Alphorm.com Formation Réseaux Cisco 2/2 : Maîtriser la sécurité
parAlphorm
 
PDF
Protocoles_securité1.pdf un good course scurity
paryanguirania
 
PDF
PFE CONFIGURATION DE IPSEC ENTRE DES ROUTEURS CISCO.pdf
par43ryruah9
 
PPT
la sécurité dans la commerce electronique
parMouna Slama
 
PPTX
Etude des Vulnérabilités dans les réseaux 3G,4G et simulation d’attaques des ...
parDanaelmousawi
 
PPTX
Mise en place d’un VPN site à site avec PfSense et OpenVPN-1 (2) (1).pptx
parHassnaOuissoumour
 
PPTX
Cours SSI - Copie.pptx
pargorguindiaye
 
PPTX
Cours SSI - Copie.pptx
pargorguindiaye
 
PPTX
Cours SSI - Copie (1).pptx
pargorguindiaye
 
PDF
Reseaux Avancés Tunnel_Niveaux347.pdf
parSergeAKUE
 
PPTX
Chiffrement opportuniste
parAntoine Benkemoun
 
PPTX
Virtual Private Network
parmalekoff
 
PDF
Chapitre_5_Printable Chapitre_5_Printable
parmia884611
 
PDF
Cours si1
parHafsa Elfassi
 
PPTX
Cours SSI - Copie (1).pptx
pargorguindiaye
 
PPTX
Cours SSI - Copie (1).pptx
pargorguindiaye
 
PDF
Sécuriser les communications sur Internet de bout-en-bout avec le protocole DANE
parAfnic
 
Vpn
parmalekoff
 
Alphorm.com Formation Réseaux Cisco 2/2 : Maîtriser la sécurité
parAlphorm
 
Protocoles_securité1.pdf un good course scurity
paryanguirania
 
PFE CONFIGURATION DE IPSEC ENTRE DES ROUTEURS CISCO.pdf
par43ryruah9
 
la sécurité dans la commerce electronique
parMouna Slama
 
Etude des Vulnérabilités dans les réseaux 3G,4G et simulation d’attaques des ...
parDanaelmousawi
 
Mise en place d’un VPN site à site avec PfSense et OpenVPN-1 (2) (1).pptx
parHassnaOuissoumour
 
Cours SSI - Copie.pptx
pargorguindiaye
 
Cours SSI - Copie.pptx
pargorguindiaye
 
Cours SSI - Copie (1).pptx
pargorguindiaye
 
Reseaux Avancés Tunnel_Niveaux347.pdf
parSergeAKUE
 
Chiffrement opportuniste
parAntoine Benkemoun
 
Virtual Private Network
parmalekoff
 
Chapitre_5_Printable Chapitre_5_Printable
parmia884611
 
Cours si1
parHafsa Elfassi
 
Cours SSI - Copie (1).pptx
pargorguindiaye
 
Cours SSI - Copie (1).pptx
pargorguindiaye
 
Sécuriser les communications sur Internet de bout-en-bout avec le protocole DANE
parAfnic
 

Plus de Thomas Moegli

PDF
Cisco ASA
parThomas Moegli
 
PDF
EtherChannel
parThomas Moegli
 
PDF
Protocole OSPF
parThomas Moegli
 
PDF
Spanning-Tree
parThomas Moegli
 
PDF
Authentification des protocoles de routage
parThomas Moegli
 
PDF
Virtuals LAN
parThomas Moegli
 
PDF
Protocole EIGRP
parThomas Moegli
 
PDF
IPv6
parThomas Moegli
 
PDF
SSL/TLS : Faille Heartbleed
parThomas Moegli
 
PDF
Services IP
parThomas Moegli
 
PDF
JunOS - Fondamentaux
parThomas Moegli
 
Cisco ASA
parThomas Moegli
 
EtherChannel
parThomas Moegli
 
Protocole OSPF
parThomas Moegli
 
Spanning-Tree
parThomas Moegli
 
Authentification des protocoles de routage
parThomas Moegli
 
Virtuals LAN
parThomas Moegli
 
Protocole EIGRP
parThomas Moegli
 
IPv6
parThomas Moegli
 
SSL/TLS : Faille Heartbleed
parThomas Moegli
 
Services IP
parThomas Moegli
 
JunOS - Fondamentaux
parThomas Moegli
 

Dernier

PPTX
Support de cours systèmes embarqués.pptx
parbensaidyosr898
 
PPTX
Présentation du comité technique ITB Somme/Oise 2026 implantation.pptx
parInstitut Technique de la Betterave
 
PPTX
Le cours est inspirée du livre ‘clean agile’ de Robert C. Martin, un des fond...
parbatanga1
 
PPTX
Présentation du comité technique ITB Somme/Oise 2026 Azote.pptx
parInstitut Technique de la Betterave
 
PPTX
Présentation du comité technique ITB Somme/OIie 2026 protection fongicide.pptx
parInstitut Technique de la Betterave
 
PPTX
Présentation du comité technique ITB Somme/Oise 2026 désherbage dicots.pptx
parInstitut Technique de la Betterave
 
PDF
cours EIE 2020.pdf presentation environement
parhafssabenmachi
 
PDF
1-Définition des structures de chaussées.pdf
parELOUAFYABDERRAHIM
 
PDF
Optimisation de la gestion de stocks et de la planification des approvisionne...
parYounes Nokri
 
Support de cours systèmes embarqués.pptx
parbensaidyosr898
 
Présentation du comité technique ITB Somme/Oise 2026 implantation.pptx
parInstitut Technique de la Betterave
 
Le cours est inspirée du livre ‘clean agile’ de Robert C. Martin, un des fond...
parbatanga1
 
Présentation du comité technique ITB Somme/Oise 2026 Azote.pptx
parInstitut Technique de la Betterave
 
Présentation du comité technique ITB Somme/OIie 2026 protection fongicide.pptx
parInstitut Technique de la Betterave
 
Présentation du comité technique ITB Somme/Oise 2026 désherbage dicots.pptx
parInstitut Technique de la Betterave
 
cours EIE 2020.pdf presentation environement
parhafssabenmachi
 
1-Définition des structures de chaussées.pdf
parELOUAFYABDERRAHIM
 
Optimisation de la gestion de stocks et de la planification des approvisionne...
parYounes Nokri
 

Protocole IKE/IPsec

  • 1.
    Thomas Moegli Ing. HESTélécommunications - Réseaux et Sécurité IT Protocoles IKE/IPsec
  • 2.
    Thomas Moegli ๏ IKEet IPsec fonctionnent ensemble pour permettre la mise en place de communications sécurisées sur un environnement non sécurisé Protocole IKE/IPsec 2 Cryptographie IPsec ISAKMP / IKE PKI Algorithmes de chiffrement Algorithmes de hachage Protocoles de tunneling Tunnel IPsec VPN Gestion et génération de clés Security Association Gestion et authentification d’une identité
  • 3.
    Thomas Moegli ๏ IKEet IPsec fonctionnent ensemble pour permettre la mise en place de communications sécurisées sur un environnement non sécurisé Protocole IKE/IPsec 3 Négociation des paramètres de sécurité Etablissement des clés pour l’authentification Chiffrement, validation et authentification des données Validation et authentification des données ESP AH IKE Plande contrôle IKE Plandedonnées IPsec
  • 4.
    Thomas Moegli ๏ Sertà assurer la gestion des clés entre les deux extrémités d’un tunnel VPN ๏ 2 versions : IKEv1 (RFC 2409) et IKEv2 (RFC 4306) qui ne sont pas interopérables entre eux ๏ Support des deux versions dans la plupart des équipements VPN ๏ Implémente certaines fonctionnalités de trois protocoles ๏ ISAKMP (Internet Security Association and Key Management Protocol) : Décrit un mécanisme d’authentification et d’échange de clés au moyen d’étapes sous forme de phases. ๏ Oakley : Décrit les différents séries d’échanges appelés modes et des services liés (PFS, Perfect Forward Secrecy, authentifcation, …). ๏ SKEME : Décrit une technique d’échange de clés permettant le renouvellement rapide des clés Protocole IKE/IPsec Protocole IKE 4 IKE Oakley Mécanisme d’échange de clés basée sur des phases SKEME Mécanisme pour un renouvellement rapide de clés ISAKMP Modes d’échanges et services liés (PFS, Authentification, …)
  • 5.
    Thomas Moegli ๏ Uneconnexion VPN est composé de deux tunnels ๏ Un tunnel IKE pour l’échange de paramètres de sécurité entre entités ๏ Un tunnel IPSec qui sert au transfert de données entre entités ๏ IKE automatise le processus d’échange de clés entre entités pour la mise en oeuvre d’un tunnel lPsec ๏ Négociation des paramètres de sécurité au travers d’une SA (Security Association) ๏ Génération automatique des clés ๏ Renouvellement automatique des clés ๏ Sécurité avec IKE/ISAKMP ๏ Permet la protection contre les attaques Denial of Service (DoS), vol de connexion, attaques MitM (Man-in-the-Middle) Protocole IKE/IPsec Protocole IKE 5
  • 6.
    Thomas Moegli ๏ Lesclés générés par IKE servent à l’authentification et la protection du tunnel IKE, permettant ainsi l’échange de paramètres pour la négociation de clés IPSec ๏ Algorithme de Diffie-Hellman utilisé pour la mise en oeuvre d’une clé de session commune aux deux entités ๏ Les clés générés par IPSec servent au chiffrement des données ๏ Au bout d’un certain temps, les clés sont renouvelées ๏ Phase 1 IKE : négociation des clés IKE ๏ Phase 2 IKE : négociation des clés IPSec Protocole IKE/IPsec Protocole IKE 6 Etablissement du tunnel Trafic reçu Négociation IKE Main Mode Négociation IKE Quick Mode IKE IPsec Données
  • 7.
    Thomas Moegli ๏ IPsecdéfinit un protocole pour l’établissement et la gestion d’une communication privée entre deux entités ๏ L’établissement du tunnel IPsec s’effectue en négociant des paramètres entre entités via le tunnel IKE établi précédemment ๏ IPsec définit un lien sécurisé entre entités qui possède les propriétés suivantes ๏ Authentification des données ๏ Confidentialité ๏ Intégrité des données ๏ Anti-rejeu ๏ Utilisation d’un ou plusieurs protocoles pour atteindre ces buts ๏ AH (Authentication Header) ๏ ESP (Encapsulating Security Payload) Protocole IKE/IPsec Protocole IPsec 7 Application7 Présentation6 Session5 Transport4 Réseau3 Liaison de données2 Physique1 IPSec
  • 8.
    Thomas Moegli ๏ Accordsur les paramètres de sécurité entre deux entités ๏ Il est nécessaire que les deux entités soient d’accord sur les réglages de sécurité ๏ L’ensemble de ces réglages est appelé Security Association (SA) ๏ Types de SA ๏ Unidirectionnel pour IKE ๏ Sur IPsec, une SA doit être définie pour chaque direction ๏ Contient ๏ Algorithme de chiffrement choisi ๏ Algorithme d’authentification choisi ๏ Clé de session partagée ๏ Lifetime ๏ Flux de donnés à protéger Protocole IKE/IPsec Security Association (SA) 8 IKE SA IPsec SA
  • 9.
    Thomas Moegli ๏ Unecaractéristique fondamentale d’IPsec est qu’une SA est définie pour chaque direction ๏ Dans l’exemple, il y a une SA entre Genève-Lausanne et une SA pour Lausanne-Genève ๏ Ces extrémités peuvent être également le point de terminaison d’autres tunnels (vers Fribourg et Bern dans l’exemple) ๏ Il peut également avoir plusieurs tunnels IPSec pour des paires de réseaux différents ๏ Ces tunnels peuvent avoir des réglages différents ๏ Ces réglages sont stockés dans une base de données appelée SAD (Security Association Database) Protocole IKE/IPsec Security Association Database (SAD) 9 Genève Fribourg Bern Lausanne
  • 10.
    Thomas Moegli Protocole IKE/IPsec Contenud’une SAD (Security Association Database) 10 Elément Description Security Parameter Index (SPI) Identification unique de la SA (valeur sur 32 bits) Utilisé en sortie pour construire les en-têtes ESP et AH, en entrée pour lier le trafic à une SA précise Sequence Number Compteur (64 bits) pour renseigner les champs des protocoles ESP et AH Anti-replay window Compteur (64 bits) pour détecter une attaque par rejeu Paramètres AH Spécifie les caractéristiques AH si celui-ci est choisi comme protocole Paramètres ESP Spécifie les caractéristiques ESP si celui-ci est choisi comme protocole Durée de vie Peut être exprimée en temps ou en bytes Mode IPsec Indique si la SA correspond à un trafic en mode tunnel ou transport Flags (Fragmentation, DF, …) Valeurs DSCP DSCP, Differentiated Services Code Point Valeurs autorisées dans la SA en sortie pour les codes permettant la QoS Bypass DSCP (Flag) Indique si on doit restreindre les flux sortants aux seuls paquets porteurs des valeurs DSCP indiquées plus haut Path MTU Décrit les MTU mis en place entre les deux extrémités de la SA Adresses source et destination Adresses IPv4 ou IPv6 figurant dans les en-têtes externes (en mode Tunnel)
  • 11.
    Thomas Moegli ๏ Protocoleen deux phases ๏ Phase 1 : Etablissement entre deux pairs d’un tunnel sécurisé et authentifié (Main Mode ou Agressive Mode) ๏ Phase 2 : Négociation et accord d’une SA IPsec entre pairs (Quick Mode) ๏ Chaque phase utilise une SA : ๏ ISAKMP SA (Phase 1, SA bidirectionnelle) ๏ Deux IPsec SA (Phase 2, SA unidirectionnelle, par paires d’entités) ๏ 1 Tunnel = 1 IKE SA + n * 2 IPsec SA (n = nombre de paires d’entités) Protocole IKE/IPsec IKE/IPsec et Security Association (SA) 11
  • 12.
  • 13.
    Thomas Moegli ๏ ModesIKE ๏ Main Mode : Authentification, établissement d’une IKE SA, chiffrement des identités (noms des entités communicants), 6 paquets ๏ Aggressive Mode : identique au Main Mode mais les identités ne sont pas chiffrés, 3 paquets ๏ Quick Mode : Génération de clés pour le tunnel IPsec, 3 paquets ๏ Informational Mode : Envoi de messages Notify (erreurs) ou messages Delete (fin de communication) ๏ Authentification IKE ๏ Signatures digitales ๏ Certificat X.509 échangé dynamiquement ๏ Chiffrement par clé publique ๏ Clés pré-partagées Protocole IKE/IPsec IKE 13
  • 14.
    Thomas Moegli ๏ Etablissementdu canal VPN en 2 phases Protocole IKE/IPsec IKE v1 14 Phase 1 (Canal ISAKMP SA) Etablissement d’un canal sécurisé avec authentification des deux entités Sert à l’échange d’informations nécessaires à l’établissement de la phase 2 Peut se dérouler selon deux modes Phase 2 (Canal IPsec SA) Etablissement de 2 canaux sécurisés pour l’échange de données Ne peut se faire que si la phase 1 s’est déroulé correctement Se déroule selon un seul mode Main Mode Aggressive Mode Quick Mode
  • 15.
    Thomas Moegli Protocole IKE/IPsec IKEv1 15 Phase 1 : ISAKMP SA Main Mode (6 Messages) Aggressive Mode (3 Messages) Phase 2 : IPsec SA Quick Mode (3 Messages) Phase 2 : IPsec SA Quick Mode (3 Messages) …. Données protégéesA B Données protégéesA B
  • 16.
    Thomas Moegli Protocole IKE/IPsec IKEv1 16 Main Mode (4 Premiers Messages) Quick Mode (3 Messages) Authentification Pre-Shared Keys (2 Messages) Authentification par certificat (2 Messages)
  • 17.
    Thomas Moegli ๏ Structured’un en-tête ISAKMP Protocole IKE/IPsec IKE v1 17 ๏ suivi d’une ou plusieurs charges (payload) commençant par cet en-tête : 32 Initiator Cookie Responder Cookie Next Payload Major Version Exchange Type Message ID Longueur Minor Version Flags 8 4 4 8 8 Next Payload Reserved Longueur 8 8 16
  • 18.
    Thomas Moegli ๏ Exemplede structure complète ISAKMP Protocole IKE/IPsec IKE v1 18 32 Next Payload = Nonce 0 Données Payload IKE Longueur Payload IKE 8 Initiator Cookie Responder Cookie Next Payload Exchange Type Flags Major Version Minor Version 4 4 8 8 Message ID Longueur Next Payload = 0 0 Données Nonce Longueur Payload Nonce
  • 19.
    Thomas Moegli ๏ MainMode Protocole IKE/IPsec IKE v1 : Phase 1 19 INITIATEUR 1. HDR (CKi, 0), SA 2. HDR (CKi, CKr), SA Fin de la négociation des attributs SA 3. HDR (CKi, CKr), KE, nonce 4. HDR (CKi, CKr), KEy, nonce Calcul des secrets SKEYID, SKEYID_d, SKEYID_a, SKEYID_e) 5. HDR (CKi, CKr), IDi , HASHi 6. HDR (CKi, CKr), IDi , HASHr Les identités sont vérifiées et l’ISAKMP SA créée REPONDEUR Messages 1 et 2 Négociation de paramètres IKE SA / ISAKMP SA Messages 3 et 4 Echange d’informations requises pour la génération d’une clé avec l’algorithme Diffie-Hellman (DH) Messages 5 et 6 Echange d’informations d’authentification avec DH , SA , SA
  • 20.
    Thomas Moegli 1er message ๏Génération d’un Initiator Cookie par l’initiateur ๏ CKi = md5(src_ip,dest_ip, random number) ๏ Ajout d’une SA Payload permettant de négocier les paramètres de sécurisation des échanges ultérieurs ๏ Proposition de plusieurs suites de protection ๏ Chaque suite définit l’algorithme de chiffrement, hachage, méthode d’authentification et groupe Diffie-Hellman ainsi que des attributs optionnels (durée de vie de la ISAKMP SA) Protocole IKE/IPsec IKE v1 : Phase 1 20 INITIATEUR 1. HDR (CKi, 0), SA REPONDEUR Initiator Cookie Responder Cookie (= 0) SA Major version Minor version Exchange Type Flags Message ID Longueur (DOI et situation) Next Payload 1 SA Payload (Longueur) SA Payload Next Payload 1 Proposal Payload (Longueur) Proposal Payload Next Payload 1 Transform Payload (Longueur) Transform Payload Next Payload 1 Proposal Payload (Longueur) Proposal Payload 0 1 Transform Payload (Longueur) Transform Payload
  • 21.
    Thomas Moegli INITIATEUR 2. HDR(CKi, CKr), SA REPONDEUR 2ème message ๏ Génération d’un Responder Cookie par le destinataire ๏ CKr = md5(src_ip,dest_ip, random number) ๏ Ajout d’une SA Payload précisant la suite retenue parmi celles proposées par l’inititateur Protocole IKE/IPsec IKE v1 : Phase 1 21 Initiator Cookie Responder Cookie SA Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 1 SA Payload (Longueur) SA Payload (DOI et situation) Next Payload 1 Proposal Payload (Longueur) Proposal Payload (Proposal #, Protocol ID, SPI Size, # of Transforms, SPI) 0 1 Transform Payload (Longueur) Transform Payload (Transform #, Transform ID, SA Attributes)
  • 22.
    Thomas Moegli INITIATEUR 3. HDR(CKi, CKr), KE, nonce REPONDEUR 3ème message ๏ Génération de la valeur DH publique de l’initiateur ๏ Valeur DH publique : Xa ๏ Xa = ga mod p ๏ avec g (générateur), p (grand nombre premier) et a (valeur aléatoire privée) ๏ L’initiateur renvoie le cookie du destinataire, le sien, le nonce et les données d’échange de clés (symbolisé par KE) ๏ KE = Xa Protocole IKE/IPsec IKE v1 : Phase 1 22 Initiator Cookie Responder Cookie Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Nonce Payload (Longueur) KE Payload (inclut la valeur publique DH) Next Payload 0 KE Payload (Longueur) Nonce Payload (inclut Nonce)
  • 23.
    Thomas Moegli 4ème message ๏Génération de la valeur DH publique du responder ๏ Valeur DH publique : Xb ๏ Xb = gb mod p ๏ avec g (générateur), p (grand nombre premier) et b (valeur aléatoire privée) ๏ Le responder renvoie le cookie de l’initiateur, le sien, le nonce et les données d’échange de clés (symbolisé par KE) ๏ KE = Xb Protocole IKE/IPsec IKE v1 : Phase 1 23 Initiator Cookie Responder Cookie Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Nonce Payload (Longueur) KE Payload (inclut la valeur publique DH) Next Payload 0 KE Payload (Longueur) Nonce Payload (inclut Nonce) INITIATEUR 4. HDR (CKi, CKr), KEy, nonce REPONDEUR
  • 24.
    Thomas Moegli Authentification parPre-Shared Keys Messages 5 et 6 Protocole IKE/IPsec IKE v1 : Phase 1 24 Main Mode (4 Premiers Messages) Quick Mode (3 Messages) Authentification Pre-Shared Keys (2 Messages)
  • 25.
    Thomas Moegli Calcul dessecrets ๏ Les 4 premiers messages permettent d’éviter d’accepter des demandes IKE provenant d’adresses IP falsifiées ๏ Les calculs sont coûteux en ressources ๏ Les deux entités génèrent des informations gardées secrètes : ๏ On génère une clé SKEY_ID (Shared Key) ainsi
 SKEY_ID = hash(Pre-Shared Key, NonceI | NonceR) ๏ Puis on dérive les trois autres secrets ๏ SKEYIDd = hash(SKEYID, KE | CKI | CKR | 0)
 pour générer les clés pour IPsec SA ๏ SKEYIDa = hash(SKEYID, SKEYIDd | KE | CKI | CKR | 1)
 permet l’authentification des données IKE et de leur source ๏ SKEYIDe = hash(SKEYID, SKEYIDa | KE | CKI | CKR | 2)
 permet le chiffrement des messages IKE Protocole IKE/IPsec IKE v1 : Phase 1 25
  • 26.
    Thomas Moegli INITIATEUR 5. HDR(CKi, CKr), IDi , HASHi REPONDEUR 5ème message ๏ Envoi du matériel d’authentification et son identifiant ๏ Le message est chiffré par la clé SKEYIDe ๏ Le message est authentifié par un hash appelé
 HASHi = hash(SKEYID, KE | CKi | CKr | SAr | IDi) Protocole IKE/IPsec IKE v1 : Phase 1 26 Initiator Cookie Responder Cookie Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Hash Payload (Longueur) SKEYID_e Identity Payload 0 0 Hash Payload Identity Payload (Longueur) ID Type DOI Specific ID Data
  • 27.
    Thomas Moegli INITIATEUR 6. HDR(CKi, CKr), IDi , HASHr REPONDEUR 6ème message ๏ Envoi du matériel d’authentification et son identifiant ๏ Le message est chiffré par la clé SKEYIDe ๏ Le message est authentifié par un hash appelé
 HASHr = hash(SKEYID, KE | CKr | CKi | SAi | IDr) Protocole IKE/IPsec IKE v1 : Phase 1 27 Initiator Cookie Responder Cookie Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Hash Payload (Longueur) SKEYID_e Identity Payload 0 0 Hash Payload Identity Payload (Longueur) ID Type DOI Specific ID Data
  • 28.
    Thomas Moegli Vérification desidentités ๏ L’initiateur authentifie le Responder ๏ Déchiffrement du message avec SKEYIDe ๏ Identifie la Pre-Shared Key configurée en utilisant IDr ๏ Calcule de lui-même HASHr ๏ Compare HASHr avec la valeur HASHr reçue. Si les deux valeurs sont identiques, l’authentification est réussie ๏ Le Responder authentifie l’Initiator ๏ Déchiffrement du message avec SKEYIDe ๏ Identifie la Pre-Shared Key configurée en utilisant IDi ๏ Calcule de lui-même HASHi ๏ Compare HASHi avec la valeur HASHi reçue. Si les deux valeurs sont identiques, l’authentification est réussie Protocole IKE/IPsec IKE v1 : Phase 1 28
  • 29.
    Thomas Moegli Authentification parcertificat Dans les messages 3 et 4, l’initiateur et le responder s’envoient mutuellement une requête de certificat Messages 5 et 6 Protocole IKE/IPsec IKE v1 : Phase 1 29 Main Mode (4 Premiers Messages) Quick Mode (3 Messages) Authentification par certificat (2 Messages)
  • 30.
    Thomas Moegli Initiator Cookie ResponderCookie Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Signature Payload (Longueur) SKEYID_e Identity Payload Next Payload 0 Signature Data Identity Payload (Longueur) ID Type DOI Specific ID Data Certificate Payload (Longueur)0 0 Certificate Data Certificate Encoding Certificate Data 5ème et 6ème message ๏ Envoi des certificats par l’initiateur et responder ๏ Le message est chiffré par la clé SKEYIDe ๏ Le message est signé
 SIGi = PRIVATE_KEYi (HASHi)
 SIGr = PRIVATE_KEYr (HASHr) Protocole IKE/IPsec IKE v1 : Phase 1 30
  • 31.
    Thomas Moegli Protocole IKE/IPsec IKEv1 : Phase 1 31 Aggressive Mode (3 Premiers Messages) Quick Mode (3 Messages)
  • 32.
    Thomas Moegli ๏ Laprotection contre les dénis de service est plus faible ๏ Les 3 échanges préalables mentionnés en mode Main n’existent pas ๏ Les calculs DH commencent dès la réception du premier cookie ๏ 3 messages échangés Protocole IKE/IPsec IKE v1 : Phase 1 32 1. HDR (CKi, 0), SA, KE, Noncei, IDi Identités vérifiées, IKE SA créée 2. HDR (CKi, CKr), SA, KE, Noncer, IDr, HASHr 3. HDR (CKi, CKr), HASHi REPONDEUR INITIATEUR Aggressive Mode
  • 33.
    Thomas Moegli 1er message ๏Contient les suites de protection, sa valeur publique DH, son nonce et son identité 2ème message ๏ Le répondeur retourne la suite de protection sélectionnée, sa valeur publique DH, son nonce, son identité et des données d’authentification (hachage pour une authentification par Pre-Shared Key, signature pour une authentification par certificat) 3ème message ๏ L’initiateur répond par ses propres données d’authentification Protocole IKE/IPsec IKE v1 : Phase 1 33
  • 34.
    Thomas Moegli ๏ Necomporte qu’un seul mode : Quick Mode (3 messages) ๏ Si PFS (Perfect Forward Secrecy) n’est pas demandé, le mode est rapide car ne demande pas de calculs DH ๏ Permet de générer les IPsec SA qui permettent de protéger les échanges de données entre entités du tunnel ๏ Possibilité d’avoir plusieurs SA, une par sens et par protocole ๏ Si PFS est activé, le nombre de messages ne change pas mais des paramètres supplémentaires sont échangés Protocole IKE/IPsec IKE v1 : Phase 2 34 REPONDEUR INITIATEUR Négociation IPsec Je veux protéger ip traffic from 10.1.3.0/24 à 10.2.5.0/24 J’offre : ESP avec AES et SHA ESP avec 3DES et SHA Voici mon Noncei PFS demandé; voici ga Ok, je protège ip traffic from 10.1.3.0/24 à 10.2.5.0/24 Je choisis : ESP avec AES et SHA Voici mon Noncer PFS ok; voici gb Ok, merci
  • 35.
    Thomas Moegli Protocole IKE/IPsec IKEv1 : Phase 2 35 1. HDR (CKi, 0), HASH1, SA, Noncei, [KE], [IDi, IDr] Identités vérifiées, IPsec SA créées 2. HDR (CKi, CKr), HASH2, SA, [KE], [IDi, IDr] 3. HDR (CKi, CKr), HASH3 REPONDEUR INITIATEUR Négociation des IPsec SA (3 Premiers Messages) Quick Mode
  • 36.
    Thomas Moegli ๏ Propriétépermettant à une information chiffrée aujourd’hui de rester confidentielle en cas de compromission future de la clé privée d’un correspondant ๏ Coûteux en calculs ; de nombreux serveurs ne l’utilisent pas ๏ Google supporte depuis 2011 le PFS sur tous ses sites accessibles en HTTPS
 https://security.googleblog.com/2011/11/protecting-data-for-long-term-with.html Protocole IKE/IPsec PFS : Perfect Forward Secrecy 36
  • 37.
    Thomas Moegli Activation dePFS ๏ Du côté de l’Initiator ๏ Nonce généré : Noncei ๏ Nouvelle valeur DH publique : Xa’ ๏ Xa’ = ga mod p ๏ avec g (générateur), p (grand nombre premier) et a (valeur aléatoire privée) Protocole IKE/IPsec IKE v1 : Phase 2 37 ๏ Du côté du Responder ๏ Nonce généré : Noncer ๏ Nouvelle valeur DH publique : Xb’ ๏ Xb’= gb mod p ๏ avec g (générateur), p (grand nombre premier) et a (valeur aléatoire privée)
  • 38.
    Thomas Moegli 1. HDR(CKi, 0), HASH1, SA, Noncei, [KE], [IDi, IDr] REPONDEUR INITIATEUR 1er message ๏ Envoi du matériel d’authentification et son identifiant ๏ Proposition de plusieurs suites de protection Protocole IKE/IPsec IKE v1 : Phase 2 38 Initiator Cookie Responder Cookie KE Major version Minor version Exchange Type Flags Message ID Longueur …
  • 39.
    Thomas Moegli SA 0Hash Payload (Longueur) SKEYID_e Hash Payload Next Payload 0 SA Payload (inclut DOI et situation) Proposal Payload (Longueur) SA Payload (Longueur) Next Payload 0 Proposal Payload Next Payload 0 Transform Payload Transform Payload (Longueur) Proposal Payload (Longueur)Next Payload 0 Proposal Payload Next Payload 0 Transform Payload Transform Payload (Longueur) Next Payload 0 Keyload Payload (Longueur) KE Payload Next Payload 0 Nonce Payload (Noncei) Nonce Payload (Longueur) Next Payload 0 Identity Payload (Longueur) ID Type Identity Payload (IDs) DOI Specific ID Data Next Payload 0 Identity Payload (Longueur) ID Type Identity Payload (IDd) DOI Specific ID Data Proposal : ESP ou AH, SHA ou MD5, DH 1 ou 2, SPI (2 propositions dans cet exemple) Transform : Tunnel ou Transport IPsec Timeout KE Payload = Xa ’ IDs = Source Proxy IDd = Destination Proxy 1. HDR (CKi, 0), HASH1, SA, Noncei, [KE], [IDi, IDr] REPONDEUR INITIATEUR 1er message ๏ Envoi du matériel d’authentification et son identifiant ๏ Proposition de plusieurs suites de protection Protocole IKE/IPsec IKE v1 : Phase 2 39
  • 40.
    Thomas Moegli 2. HDR(CKi, CKr), HASH2, SA, [KE], [IDi, IDr] REPONDEUR INITIATEUR Initiator Cookie Responder Cookie KE Major version Minor version Exchange Type Flags Message ID Longueur … 2ème message ๏ Envoi du matériel d’authentification et son identifiant ๏ Sélection d’une suite parmi celle proposées Protocole IKE/IPsec IKE v1 : Phase 2 40
  • 41.
    Thomas Moegli 2. HDR(CKi, CKr), HASH2, SA, [KE], [IDi, IDr] REPONDEUR INITIATEUR 2ème message ๏ Envoi du matériel d’authentification et son identifiant ๏ Sélection d’une suite parmi celle proposées Protocole IKE/IPsec IKE v1 : Phase 2 41 SA 0 Hash Payload (Longueur) SKEYID_e Hash Payload Next Payload 0 SA Payload (inclut DOI et situation) Proposal Payload (Longueur) SA Payload (Longueur) Next Payload 0 Proposal Payload Next Payload 0 Transform Payload Transform Payload (Longueur) Next Payload 0 Keyload Payload (Longueur) KE Payload Next Payload 0 Nonce Payload (Noncer) Nonce Payload (Longueur) Next Payload 0 Identity Payload (Longueur) ID Type Identity Payload (IDs) DOI Specific ID Data Next Payload 0 Identity Payload (Longueur) ID Type Identity Payload (IDd) DOI Specific ID Data Proposal : Responder SPI KE Payload = Xb ’
  • 42.
    Thomas Moegli Calcul DH(en cas d’activation PFD) ๏ Du côté de l’Initiator ๏ Calcul DH : KE = (Xb’)a mod p ๏ Clé de session IPsec : 
 key = PRF(SKEYIDd | protocol(ISAKMP) | KE | SPi | Noncei | Noncer) Protocole IKE/IPsec IKE v1 : Phase 2 42 ๏ Du côté du Responder ๏ Calcul DH : KE = (Xa’)b mod p ๏ Clé de session IPsec : 
 key = PRF(SKEYIDd | protocol(ISAKMP) | KE | SPi | Noncei | Noncer)
  • 43.
    Thomas Moegli Initiator Cookie ResponderCookie KE Major version Minor version Exchange Type Flags Message ID Longueur SA 0 Hash Payload (Longueur) SKEYID_e Hash Payload 3. HDR (CKi, CKr), HASH3 REPONDEUR INITIATEUR 3ème message ๏ Le client valide la mise en place du tunnel IPsec en envoyant un dernier paquet Protocole IKE/IPsec IKE v1 : Phase 2 43
  • 44.
  • 45.
    Thomas Moegli ๏ RFC4306 (décembre 2005)
 RFC 5996 (septembre 2010)
 RFC 6989 ( juillet 2013) ๏ On réduit les 8 échanges initiaux (Phase 1 et Phase 2) 
 à 4 échanges Protocole IKE/IPsec IKE v2 45 IKE_SA_INIT (2 à 4 Messages) IKE_AUTH (2 Messages) CREATE_CHILD_SA (2 Messages) Données protégéesA B Authentification du tunnel IKE_SA Négociation des paramètres Transmission et authentification des entités Génère le premier Child SA (similaire à IPsec SA) (Opt) Création d’un second Child SA si nécessaire
  • 46.
    Thomas Moegli ๏ Supportde méthodes d’authentification nouvelles au travers d’EAP (Extensible Authentication Protocol) ๏ Permet d’offrir d’autres méthodes que des clés partagés et des certificats ๏ Prise en charge de NAT Traversal (NAT-T) par le port 4500 Protocole IKE/IPsec IKE v2 46
  • 47.
    Thomas Moegli 1er message ๏Permet de négocier les paramètres de sécurité de la SA et de communiquer les valeurs de nonces et de Diffie- Hellman Protocole IKE/IPsec IKE v2 47 Initiator SPI Responder SPI Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 KE Payload (Longueur) KE Payload (inclut valeurs publiques DH) Next Payload SA Payload (inclut informations Proposal et Tranform) Nonce Payload (Longueur) SA Payload (Longueur) Next Payload Nonce C 0C 0C IKE_SA_INIT (2 à 4 Messages) REPONDEUR INITIATEUR
  • 48.
    Thomas Moegli REPONDEUR INITIATEUR 2ème message ๏Permet de négocier les paramètres de sécurité de la SA et de communiquer les valeurs de nonces et de Diffie- Hellman Protocole IKE/IPsec IKE v2 48 Initiator SPI Responder SPI Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 KE Payload (Longueur) KE Payload (inclut valeurs publiques DH) Next Payload SA Payload (inclut informations Proposal et Tranform) Nonce Payload (Longueur) SA Payload (Longueur) Next Payload Nonce C 0C 0C IKE_SA_INIT (2 à 4 Messages)
  • 49.
    Thomas Moegli REPONDEUR INITIATEUR IKE_AUTH (2 Messages) InitiatorSPI Responder SPI Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Auth Payload (Longueur) SK_e,SK_a Authentication Payload Next Payload ID Payload (contient Initiator ID) SA Payload (Longueur) ID Payload (Longueur) Next Payload SA Payload pour le premier CHILD_SA C 0C 0C TS Payload (Longueur) Traffic Selector Payload Next Payload TS Payload (Longueur)Next Payload Traffic Selector Payload 0C 0C 3ème message ๏ Transmission et authentification des identités ๏ Génère la première Child SA si tout se passe bien ๏ Child SA = équivalent à IPsec SA ๏ L’échange recouvre une partie de la phase 1 d’IKEv1 et une partie de la phase 2 (IPsec SA) Protocole IKE/IPsec IKE v2 49
  • 50.
    Thomas Moegli IKE_AUTH (2 Messages) InitiatorSPI Responder SPI Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Auth Payload (Longueur) SK_e,SK_a Authentication Payload Next Payload ID Payload (contient Initiator ID) SA Payload (Longueur) ID Payload (Longueur) Next Payload SA Payload pour le premier CHILD_SA C 0C 0C TS Payload (Longueur) Traffic Selector Payload Next Payload TS Payload (Longueur)Next Payload Traffic Selector Payload 0C 0C REPONDEUR INITIATEUR 4ème message ๏ Transmission et authentification des identités ๏ Génère la première Child SA si tout se passe bien ๏ Child SA = équivalent à IPsec SA ๏ L’échange recouvre une partie de la phase 1 d’IKEv1 et une partie de la phase 2 (IPsec SA) Protocole IKE/IPsec IKE v2 50
  • 51.
    Thomas Moegli CREATE_CHILD_SA (2 Messages) 5èmemessage ๏ Permet de générer, si besoin, d’autres Child SA ๏ Echange du matériel d’authentification et identifiants Protocole IKE/IPsec IKE v2 51 REPONDEUR INITIATEUR Initiator SPI Responder SPI Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Nonce Payload (Longueur) SK_e,SK_a Nonce Next Payload SA Payload (inclut informations Proposal et Transform) SA Payload (Longueur)C 0C TS Payload (Longueur) Traffic Selector Payload Next Payload TS Payload (Longueur)Next Payload Traffic Selector Payload 0C 0C
  • 52.
    Thomas Moegli CREATE_CHILD_SA (2 Messages) 6èmemessage ๏ Permet de générer, si besoin, d’autres Child SA ๏ Echange du matériel d’authentification et identifiants Protocole IKE/IPsec IKE v2 52 Initiator SPI Responder SPI Next Payload Major version Minor version Exchange Type Flags Message ID Longueur Next Payload 0 Nonce Payload (Longueur) SK_e,SK_a Nonce Next Payload SA Payload (inclut informations Proposal et Transform) SA Payload (Longueur)C 0C TS Payload (Longueur) Traffic Selector Payload Next Payload TS Payload (Longueur)Next Payload Traffic Selector Payload 0C 0C REPONDEUR INITIATEUR
  • 53.
  • 54.
    Thomas Moegli ๏ IPsecdéfinit un protocole pour l’établissement et la gestion d’une communication privée entre deux entités ๏ IPsec définit un lien sécurisé entre entités qui possède les propriétés suivantes ๏ Authentification des données ๏ Confidentialité ๏ Intégrité des données ๏ Anti-rejeu ๏ Utilisation d’un ou plusieurs protocoles pour atteindre ces buts ๏ AH (Authentication Header) ๏ ESP (Encapsulating Security Payload) Protocole IKE/IPsec IPsec 54 Application7 Présentation6 Session5 Transport4 Réseau3 Liaison de données2 Physique1 IPSec
  • 55.
    Thomas Moegli ๏ Définisur plusieurs RFC ๏ Security Architecture for the Internet Protocol (RFC 2401) ๏ IP Security Document Road Map (RFC 2411) ๏ IP Authentication Header (AH) (RFC 2402) ๏ IP Encapsulating Security Payload (ESP) (RFC 2406) Protocole IKE/IPsec IPsec 55
  • 56.
    Thomas Moegli ๏ L’applicationdu protocole AH ou ESP dépend du mode d’opération IPsec ๏ Il existe deux modes d’opération ๏ Mode tunnel ๏ La totalité du paquet IP est chiffré et/ou authentifié ๏ Le paquet est ensuite encapsulé dans un nouveau paquet IP avec une nouvelle en-tête IP ๏ Mode transport ๏ Seules les données transférées (le payload du paquet IP) sont chiffrées et/ou authentifiées ๏ Le reste du paquet IP est inchangé Protocole IKE/IPsec Modes d’opération IPsec 56
  • 57.
    Thomas Moegli Comparaison desmodes Protocole IKE/IPsec Modes d’opération IPsec 57 IP Header Data IP Header DataIPsec Header Mode Transport IP Header Data New IP Header DataIPsec Header Mode Tunnel IP Header Peut être chiffré Peut être chiffré IPsec Footer IPsec Footer
  • 58.
    Thomas Moegli ๏ Protocolepermettant l’authentification et l’intégrité des données échangées ๏ N’est pas prévu pour assurer la confidentialité ๏ Défini par ๏ 2008 : RFC 4302 complété du RFC 4305 (remplacé par RFC 4835 en 2007) ๏ Version d’origine de 1998 (RFC 2402) ๏ Chaque paquet est authentifié et validé en utilisant des mécanismes de signatures numériques ๏ Algorithmes MD5, SHA1 Protocole IKE/IPsec Authentication Header (AH) 58
  • 59.
    Thomas Moegli Intégration del’en-tête AH dans un paquet IP (Mode tunnel) : ๏ Création d’un nouvel en-tête IP au début du paquet ๏ Valeur de protocole IP apparaissant dans l’en-tête IP externe : 51 (AH) ๏ Mode utilisé par défaut Protocole IKE/IPsec Authentication Header (AH) 59 Adresse IP Source Adresse IP Dst En-tête TCP (Protocole = 6) TCP Payload Adresse IP Source Adresse IP Dst En-tête TCP TCP Payload En-tête AH Next Header = 4 (IP) Nouvelle Adresse IP Source Nouvelle Adresse IP Dst Partie authentifiée
  • 60.
    Thomas Moegli Intégration del’en-tête AH dans un paquet IP (Mode transport) :
 
 
 
 
 
 
 ๏ Conservation de l’en-tête IP original avec insertion d’un en-tête AH ๏ Le Next Header de l’en-tête AH indique directement le protocole TCP (valeur = 6), UDP (valeur = 17), ICMP (valeur = 1) ou tout autre protocole transporté par IP Protocole IKE/IPsec Authentication Header (AH) 60 Adresse IP Source Adresse IP Dst En-tête TCP (Protocole = 6) TCP Payload Adresse IP Source Adresse IP Dst En-tête TCP TCP Payload En-tête AH Next Header = 6 (TCP) Partie authentifiée
  • 61.
    Thomas Moegli ๏ Structurede l’en-tête AH : Protocole IKE/IPsec Authentication Header (AH) 61 Next Header Payload Length Security Parameter Index (SPI) Reserved 8 Authentication Data (Integrity Check Value) Sequence Number 8 16
  • 62.
    Thomas Moegli Structure del’en-tête AH : Protocole IKE/IPsec Authentication Header (AH) 62 Elément Description Next Header Numéro du protocole contenu dans la charge située immédiatement après l’en-tête AH En mode tunnel : il s’agit d’IPv4 ou IPv6 Longueur charge
 Payload length Représente la taille de l’en-tête AH SPI
 Security Parameter Index Numéro d’index dans la base SPD Permet de relier le paquet à une assic Sequence number Compteur permettant de détecter des paquets qui seraient rejoués après avoir été enregistrés. Est incrémenté de 1 à chaque envoi par l’émetteur. Lorsque la valeur max est atteinte (232), l’émetteur doit négocier la création d’une nouvelle SA Données pour authentification Résultat du calcul d’un MAC dénommé ICV (Integrity Check Value)
  • 63.
    Thomas Moegli ๏ Lechamp Données pour auth. permet d’assurer que la trame est authentique et non altéré ๏ Couvre tout le paquet IP d’origine, sauf les champs modifiables lors du routage : ๏ Champ TOS (Type Of Service) ๏ Champ Flags (don’t fragment…) ๏ Champ Fragment Offset ๏ Champ TTL (Time To Live) ๏ Champ IP Header Checksum ๏ Le calcul de l’ICV s’effectue en mettant tous les champs variables ci-dessus à zéro Protocole IKE/IPsec Authentication Header (AH) 63
  • 64.
    Thomas Moegli ๏ Avantagesde AH ๏ Protocole relativement léger car il ne chiffre pas les données ๏ Peut être utilisé en combinaison avec ESP si la confidentialité des données échangées est primordiale ๏ Limitations ๏ L’authentification se fait sur la quasi-totalité du paquet, dont les adresses IP externes.
 Impossible de mettre en œuvre le NAT (Network Address Translation) puisque les IP du paquet vont changer ๏ Nécessite d’utiliser l’encapsulation NAT-T ๏ Depuis 2005, les RFC sur IPsec ne requièrent plus qu’une implémentation IPsec doit supporter AH Protocole IKE/IPsec Authentication Header (AH) 64
  • 65.
    Thomas Moegli ๏ Protocolepermettant la confidentialité, l’intégrité des données, l’authentification et le 
 contrôle d’anti-rejeu ๏ Défini par ๏ 2005 : RFC 4305 ๏ Version d’origine de 1998 (RFC 2406) Protocole IKE/IPsec Encapsulation Security Payload (ESP) 65
  • 66.
    Thomas Moegli ๏ Structurede l’en-tête ESP Protocole IKE/IPsec Encapsulation Security Payload (ESP) 66 Next Header Payload Length Security Parameter Index (SPI) Reserved 8 Padding Sequence Number 8 16 Payload Peut contenir en début un champ IV Payload Next HeaderPadding length Integrity Check Value (ICV) Authentication Data
  • 67.
    Thomas Moegli Structure del’en-tête ESP : Protocole IKE/IPsec Encapsulation Security Payload (ESP) 67 Elément Description SP Numéro d’index dans la base SPD Permet de relier le paquet à une association de sécurité (SA) Sequence Number Compteur permettant de détecter des paquets qui seraient rejoués après avoir été enregistrés. Est incrémenté de 1 à chaque envoi par l’émetteur. Lorsque la valeur max est atteinte (232), l’émetteur doit négocier la création d’une nouvelle SA IV 
 Initialisation Vector (Facultatif) Contient les 8 premiers octets de la zone « Données Protégées ». Certains modes de chiffrement (CBC par ex.) ne nécessitent pas d’IV Payload Données utilisateur transférées par le tunnel VPN Padding Bits de bourrage pour aligner les blocs à chiffrer (requis pour certains modes de chiffrement) ICV Ne sont présentes que si l’authentification est requise. Leur taille est variable, suivant l’algorithme choisi.
  • 68.
    Thomas Moegli Intégration del’en-tête ESP dans un paquet IP (Mode tunnel) : ๏ Création d’un nouvel en-tête IP au début du paquet et présence de champs ESP situés en fin de paquet ๏ Valeur de protocole IP apparaissant dans l’en-tête IP externe : 50 (ESP) Protocole IKE/IPsec Encapsulation Security Payload (ESP) 68 Adresse IP Source Adresse IP Dst En-tête TCP (Protocole = 6) TCP Payload Adresse IP Source Adresse IP Dst En-tête TCP TCP Payload En-tête ESP Next Header = 4 (IP) Nouvelle Adresse IP Source Nouvelle Adresse IP Dst Partie authentifiée En-queue ESP ICV ESP Authentification Partie chiffrée
  • 69.
    Thomas Moegli Intégration del’en-tête ESP dans un paquet IP (Mode tunnel) : Protocole IKE/IPsec Encapsulation Security Payload (ESP) 69 Adresse IP Source Adresse IP Dst En-tête TCP (Protocole = 6) TCP Payload Adresse IP Source Adresse IP Dst En-tête TCP TCP Payload En-tête ESP Next Header = 6 (TCP) Partie authentifiée En-queue ESP ICV ESP Authentification Partie chiffrée
  • 70.
    Thomas Moegli ๏ Avantagesde ESP ๏ Franchit les NAT ๏ Limitations ๏ N’authentifie pas les adresses IP externes du paquet (d’où la possibilité de franchir les NAT) ๏ Ne peut gérer PAT Protocole IKE/IPsec Encapsulation Security Payload (ESP) 70
  • 71.
  • 72.
    Thomas Moegli ๏ IKEKeepalive : Dead IKE Peer Detection (DPD) ๏ X-AUTH : Authentification dans une session IKE ๏ Mode Config : Envoi de paramètres IP aux clients ๏ NAT-T : Fonctionnement d’un VPN IPSec au travers d’un NAT Protocole IKE/IPsec Extensions IKE 72
  • 73.
    Thomas Moegli ๏ Techniquespermettant la détection de la perte d’un VPN et permettre la reconstruction d’un VPN opérationnel dans les plus brefs délais ๏ Deux méthodes : ๏ Méthode historique : IKE Keep-Alive ๏ Méthode plus récente, normalisée par le RFC 3706 : Dead Peer Detection (DPD) Protocole IKE/IPsec Extensions IKE : IKE Keep-Alive et DPD 73
  • 74.
    Thomas Moegli ๏ Soitdeux équipements A et B avec un tunnel VPN qui relie ces deux entités ๏ Une des entités (A ou B) émet régulièrement des requêtes (messages HELLO) vers l’autre extrémité ๏ Attente d’une réponse du voisin (message ACK) ๏ Sur certaines implémentations, il suffit qu’un des côtés (A) envoie régulièrement des HELLO pour que le lien soit considéré comme vivant par B ๏ Toutefois, A ne peut pas détecter la perte du VPN, il s’agit d’une détection unidirectionnelle ๏ Il est possible de mettre une détection sur chaque sens, mais les performances ne sont pas intéressantes ๏ Problèmes rencontrées ๏ Méthode non normalisée, est difficilement employable entre matériels de marque différentes ๏ Peut être très consommatrice de bande passante Protocole IKE/IPsec Extensions IKE : IKE Keep-Alive 74
  • 75.
    Thomas Moegli ๏ Soitdeux équipements A et B avec un tunnel VPN qui relie ces deux entités ๏ Si A et B échangent du trafic, c’est que le lien est vivant : il n’y a pas besoin d’autres preuves que le VPN est toujours présent ๏ Si aucun échange ne s’est produit récemment : ๏ Si A souhaite envoyer un flux vers B, il lance une requête vers B via un message IKE de type NOTIFY : R-U-THERE ๏ B doit répondre par un R-U-THERE-ACK ๏ Si B ne répond pas au bout d’un délai défini de son côté par A, A doit réitérer l’envoi de sa demande ๏ Si le nombre de tentatives défini par A est atteint, A peut décréter que le lien est perdu est supprimer de sa table les SA concernées Protocole IKE/IPsec Extensions IKE : Dead Peer Detection (DPD) 75 VPN Concentrator Application Server Données reçues Message DPD : R-U-THERE Aucune donnée reçue Message DPD : R-U-THERE-ACK Internet
  • 76.
    Thomas Moegli ๏ Bpeut définir des critères de DPD qui soient différents de ceux de A ๏ Exemple : un VPN entre un site de fabrication et un site d’administration
 La liaison du site de fabrication vers le site d’administration est plus cruciale que le sens inverse ๏ Méthode plus performante que Keep-alive car moins coûteuse en échanges tout en assurant des détections très rapides ๏ Incorpore également des protections contre certaines attaques (Anti-rejeu) via l’utilisation de numéros de séquence ๏ Inconvénients : ๏ Fonction relativement récente, n’est pas forcément présente sur tous les matériels ๏ La détection de la perte d’un VPN ne se fait qu’au moment ou le trafic doit être envoyée, le délai de détection peut donc être relativement importante Protocole IKE/IPsec Extensions IKE : Dead Peer Detection (DPD) 76 Internet A B Je dois envoyer à B régulièrement des données. Je dois savoir rapideement si le tunnel vers B est ok Ce n’est pas très important si je perds la liaison vers A Le passage de trafic IPSec prouve que la liaison VPN est active DPD est asynchrone Chaque voisin définit ses critères DPD Vérification du voisin uniquement si nécessaire
  • 77.
    Thomas Moegli Protocole IKE/IPsec ExtensionsIKE : Dead Peer Detection (DPD) 77 Initiator Répondeur R-YOU-THERE R-YOU-THERE-ACK 32 ISAKMP Header Next Payload Notify Payload LengthReserved 8 8 8 8 DOI = IPsec DOI SPI = CKYi | CKYr Protocol ID = ISAKMP Notify Message Type = R-U-THERE SPI Size Notification Data = Sequence Number 32 ISAKMP Header Next Payload Notify Payload LengthReserved 8 8 8 8 DOI = IPsec DOI SPI = CKYi | CKYr Protocol ID = ISAKMP Notify Message Type = R-U-THERE SPI Size Notification Data = Sequence Number
  • 78.
    Thomas Moegli X-AUTH :Authentification dans une session IKE ๏ Génération d’une IKE SA dans la phase 1 ๏ Permet d’implémenter une authentification utilisateur entre la phase 1 et la phase 2 ๏ Appelé parfois Phase 1.5 Mode Config : Envoi de paramètres IP au client ๏ Permet de négocier des adresses IP au travers d’un tunnel sécurisé (similaire à un serveur DHCP) ๏ Requête ISAKMP_CFG_REQUEST envoyé de l’Initiator au Responder ๏ L’Initiator utilise ensuite les attributs IP et procède ensuite à la phase 2 pour la négociation des IPsec SA Protocole IKE/IPsec Extensions IKE : Mode Config et XAUTH 78
  • 79.
    Thomas Moegli Protocole IKE/IPsec ExtensionsIKE : Mode Config et XAUTH 79 Phase 1 : ISAKMP SA Main Mode (6 Messages) Aggressive Mode (3 Messages) Phase 2 : IPsec SA Quick Mode (3 Messages) Phase 2 : IPsec SA Quick Mode (3 Messages) …. Données protégéesA B Données protégéesA B Phase 1.5 : XAUTH et/ou Mode Config
  • 80.
    Thomas Moegli Protocole IKE/IPsec ExtensionsIKE : Authentification XAUTH 80 CHAP WAN Passerelle IPsec Client IPsec Serveur AAA Username/Password OTP S/Key Passerelle IPsec
  • 81.
    Thomas Moegli Protocole IKE/IPsec ExtensionsIKE : Mode Config 81 CHAP WAN Passerelle IPsec Client IPsec Serveur AAA Username/Password OTP S/Key Passerelle IPsec ๏ Mécanisme utilisé pour envoyer les attributs IP aux clients IPsec distants Adresse IP interne Serveur DNS Serveur DHCP Attributs optionnels
  • 82.
    Thomas Moegli Protocole IKE/IPsec ExtensionsIKE : Authentification XAUTH 82 IKE Phase 1 XAuth : Prompt = « Challenge 123DE4 » XAuth : Name = « Joe », Pwd = « 123ZDE » Mode Config : IP Address, DNS, WINS, …. IKE Phase 2 - IPsec SA Attribute Value Type XAUTH-TYPE 16520 Basic XAUTH-USER-NAME 16521 Variable ASCII string XAUTH-USER-PASSWORD 16522 Variable ASCII string XAUTH-PASSCODE 16523 Variable ASCII string XAUTH-MESSAGE 16524 Variable ASCII string XAUTH-CHALLENGE 16525 Variable ASCII string XAUTH-DOMAIN 16526 Variable ASCII string XAUTH-STATUS 16527 Basic XAUTH-NEXT-PIN 16528 Variable XAUTH-ANSWER 16529 Variable ASCII string
  • 83.
    Thomas Moegli Merci devotre attention ! thomas.moegli@icloud.com Références ๏ Advanced Networks, Cours HEIG-VD (F. Bruchez) ๏ Les VPN : Fonctionnement, mise en oeuvre et maintenance des Réseaux Privés Virtuels, ENI Editions (J-P. Archier) ๏ Réseaux Privés Virtuels - VPN, Frameip [http://www.frameip.com/vpn/] (X. Lasserre, T. Klein, _SebF) 83