Les protocoles de gestion des clés dans IPsec. ISAKMP en détails

Transcription

1 Solution transparente pour la constitution de réseaux privés virtuels (RPV) INEO.VPN Les protocoles de gestion des clés dans IPsec. ISAKMP en détails Tous droits réservés à INEOVATION. INEOVATION est une marque protégée.

2 Plan 2 Rappel : Services de Sécurité Couches et protocoles de sécurité Protocoles de gestion des clés à l IETF et autours de IPSEC Protocole de gestion des clés dans IPSEC Avant ISAKMP et IKEv1(Diffie-Hellman, Photuris, Oakley, SKEME) ISAKMP et IKEv1 Après ISAKMP et IKEv1 (SIGMA, JFK, IKEv2) Résumé: IPSEC ISAKMP/IKE Choix d implémentation

3 Rappel : Services de Sécurité Confidentialité : Protection de l information d un adversaire espionnant les communications. L authentification peut être assurer avec des algorithmes de chiffrements (DES, 3DES, AES, etc.) Authentification : L authentification de l origine des données garantit que les données reçues proviennent de l expéditeur déclaré. L authentification peut être assurée avec des fonctions HMAC (hachage+ chiffrement), certificat (PGP, X509, etc.), Non-Répudiation : comme l authentification mais avec garantie que l expéditeur ne pourra pas nier être à l origine de la transaction. La non répudiation est assurée par les standards de signature (PKCS #7, CMS, XML-DSIG, etc.) 3

4 Rappel : Services de Sécurité Intégrité : L intégrité garantit que les données n ont pas été modifiées durant leur transfert. L intégrité est assuré par des algorithmes de hachages. (SHA-1, MD5, MD2, etc.) Contrôle d accès : Assure que seulement des personnes autorisées peuvent obtenir l accès à des ressources protégées (Autorisations ou non d accès à des objets) 4

5 Couches et protocoles de sécurité Les couches selon l architecture OSI Protocoles de Internet 7 Application SMTP, POP, IMAP, HTTP(S), FTP(S) SET PKI ISAKMP, IKE, etc. XML-DSIG 6 Présentation MIME, HTML, XML, Base64, SMIME, Signature XML X509, PKCS8, PKCS10, PKCS12 CMS (Cryptographique Message Syntax) / PKCS7 5 Session TLS SSH 4 Transport TCP UDP 3 Réseau IP, ICMP, RIP, OSPF, IPSEC 2 Liaison PAP, CHAP, RADIUS Encapsulation IP ou PPP 1 Physique Pratiquement tout support de transmission en particulier les réseaux locaux, les réseaux téléphonique (commuté ou liaison spécialisée) 5

6 Protocoles de gestion des clés (IETF) Avant ISAKMP Après ISAKMP SIGMA 2002 JFK 2002 IKEv TLS Ext Oakley 1998 ISAKMP 1998 IKEv TLSv STS 1992 SKIP 1994 Photuris 1995 SKEME Diffie-Helman

7 Protocoles de gestion des clés autours de IPSEC SKEME Oakley Photuris Etc. Modèles de gestion de clés, Plusieurs développements Notions sous-jacentes Hachage Chiffrement Symétrique Chiffrement Asymétrique DH Certificat X509 Etc. ISAKMP IKEv1 IKEv2 DOI Cadre générique à la négociation des SA: Création, suppression, etc. Domain of Interpretation Définit les paramètres selon le contexte IPSEC: listes des algos, modes, IKE Utilisation particulière de ISAKMP avec le protocole IPSEC 7

8 Protocole de gestion des clés Avant ISAKMP 8

9 Diffie-Hellman (DH) (1/2) Inventé en 1976 par Whitfield DIFFIE et Martin HELLMAN. Le but est de permettre à deux tiers (Alice et Bob) de générer un secret partagé sans avoir aucune information préalable l un sur l autre. 9

10 Diffie-Hellman (DH) (2/2) Alice A et B se mettent d accord sur 2 nombres g et n très grands Bob Alice choisit un grand nombre a (privé) et calcule la valeur publique A. A = g^a mod n Bob choisit un grand nombre b (privé) et calcule la valeur publique B. B = g^b mod n Alice calcule K(A,B) = B^a mod n ; Bob Calcule K(B,A) = A^b mod n K(A,B) = K(B,A) = g^ab mod n est le secret partagé par Alice et Bob 10

11 Photuris (1/3) 11 Photuris Développé par Phil Karn de chez Qualcomm et William Simpson de chez DayDreamer (Basé sur STS, Station-To-Station) Protocol Basé sur la génération de secret partagé Diffie-Hellman puis authentification avec les clés publiques Protocol Orienté connexion, basé sur UDP port 468. Etat Actuel: Depuis 1995, fait l'objet d un draft à l IETF.

12 Photuris (2/3) Protocole en trois phases : Echange de cookies, pour garantir une faible authentification contre les attaques de type DOS(Denial of Service). Echange de valeurs publiques pour l établissement d une clé partagée. Echange d'identités pour une authentification mutuelle 12

13 Photuris (3/3) Les cookies sont basés sur: Adresses IP et port. Une secret local Cookie = hash (adresse IP source 1 et destination et port + secret local) 2 Client Client cookie Chosen Schemes Server cookie Offered Schemes Diffie-Hellman key generation Server 3 Client identity Authentication for previous data Server identity Authentication for previous data Les 3 phases dans Photuris 13

14 SKEME (1/2) SKEME (Secure Key Exchange) Développé en 1996 par Hugo Krawszyk de L IBM comme une extension de Photuris. SKEME est basé sur un échange DH mais propose aussi des méthodes additionnelles comme la distribution manuelle des clés ou par un system KDC (Key Distribution Center) 14

15 SKEME (2/2) SKEME fournit quatre modes d échange de clés: Un échange basé sur les clés publiques de Diffie- Hellman. Un échange basé sur l utilisation des clés publiques mais sans Diffie-Hellman. Un échange basé sur l utilisations d une secret partagée et sur Diffie-Hellman. Un échange rapide basé uniquement sur des algorithmes symétriques. 15

16 Oakley (1/3) Proposé par Hillarie Orman de l université d Arizona. Oakley est un protocole de la couche applicative basé sur Diffie-Hellman avec des fonctionnalités additionnelles contre certaines attaques cryptographiques. Etat actuel: Fait l objet d un draft dans le cadre du groupe IPSEC à l IETF. 16

17 Oakley (2/3) L utilisation actuelle de Oakley est avec le protocole ISAKMP pour la négociation des clés dans IPsec Oakley peut être utilisé avec ISAKMP (port 500) ou directement sur IP. Caractéristiques de Oakley: Oakley utilise les cookies contre les attaques de type DOS Oakley utilise un NONCE (des numéros aléatoires) contre les attaques de re-jeu des paquets. Assure une authentification des deux communicants contre les attaques de type «man-in-the-middle». Permet au deux entités de négocier des groupes DH. 17

18 Oakley (3/3) Trois méthodes d authentification: Signatures Digitales. Les deux entités signent les informations partagées entre eux. Encryptage avec les clés publiques. Les deux entités utilisent leurs clés privées pour chiffrer les données échangées entre elles. Clés partagés. 18

19 Les protocoles ISAKMP et IKEv1 ISAKMP, IKEv1, DOI 19

20 ISAKMP ( Internet Security Association and Key Management Protocol) ISAKMP développé par «National Security Agency» pour établir les paramètres de sécurité début du travaille en RFC 2408 en 1998 Ce protocole Sert à L établissement La modification La suppression Des associations de Sécurité (SA) ISAKMP ne définit pas les attributs nécessaires pour établir une association de sécurité. Cette tâche est laissée pour d autre documents; par exemple le RFC 2407 définit tous les domaines d interprétation (DOI) nécessaires pour ISAKMP, IKE,. ISAKMP est un protocole couche applicative basé sur UDP et utilise le port

21 Architecture d ISAKMP Architecture RFC 2407 RFC 2412 RFC 2408 RFC 2246 RFC 2406/

22 ISAKMP ( Internet Security Association and Key Management Protocol) ISAKMP gère les associations de sécurité (SA) entre les hôtes ISAKMP opère en deux phases: SA pour ISAKMP SA pour IPSEC (AH ou ESP) Il dispose de 13 «Payload ou blocs» pour gérer les SA. Il dispose de 5 scénarios d échanges de messages entre hôtes. 22

23 Deux Phases ISAKMP ISAKMP phase 1 : l établissement d une SA ISAKMP - Établissement d un canal sécurisé entre 2 entités. - Génération et échange des cookies, négociation des algorithmes de chiffrements et de hachages, échange des certificats, authentifications,..) - Duré de vie: longue (négociable) - Une SA ISAKMP est bidirectionnelle 23 ISAKMP phase 2 : établie un SA pour un protocole de sécurité (IPSec AH, TLS,..) - Tous les échanges sont sécurisés grâce aux paramètres négociées. - Duré de vie: courte, - Plusieurs phases 2 pour une seule phase 1

24 Les blocs d ISAKMP Les types de Payload: Il y a 13 différents types de payload dans ISAKMP (figure suivante), tous commencent avec un en-tête ISAKMP Le type du payload suivant le courant est mis dans le champ «next payload» 24

25 Les messages et les blocs de ISAKMP (1/2) Les messages ISAKMP sont constitués d un en-tête (Header) suivi d un nombre variable de blocs ( ou payload en anglais) Bit: Initiator Cookie Responder Cookie Next Payload MjVer MnVer ExchangeType Flags L entête ISAKMP contient : Message ID - Initiator et Responder Cookie: concaténation Length des adresses IP, UDP et les ports UDP source et destination avec une secret local. Entête ISAKMP - Next Payload: indique le type du bloc suivant (ex. SA, KE,..). - Version: divisé entre MajVer et MinVer qui prennent les valeurs 1 et 0 respectivement - ExchangeType: indique le type d échange étant utilisé (par ex. Identity Protection, ) - Flags: indique des options spécifiques comme l encryptage, la synchronisation des échanges,..) - Message ID: identificateur du message (reste 0 dans la phase 1) - Length: c est la longueur du message (entête + payload) 25

26 Les messages et les blocs de ISAKMP (2/2) L entête de chaque bloc s appelle «Generic Payload Header» Une trame ISAKMP peut contenir plusieurs blocs (payload) ISAKMP Next Payload RESERVED Payload Length Generic Payload Header Octet: Entête Entête Entête Entête Bloc Bloc Bloc Ethernet IP UDP ISAKMP Une trame ISAKMP #1 #2. #n 26

27 Les blocs d ISAKMP Type Security Association (SA) Proposal (P) Transform (T) Paramètres -Domain of Interpretation (DOI) par ex. IPSEC(1) -Situation: (ex. SIT_SECRECY) Proposal #, Protocol-ID, SPI Size, # of Transforms, SPI Transform #, Transform-ID, SA Attributes (Encryption Algorithm, Group-Desciption, Authentication-Method, Life-Type, Life Duration) Description ce bloc contient des champs qui indiquent le contexte de la négociation Paramètre DOI: 0 pour ISAKMP 1 pour IPSEC utilisé pendant la négociation du SA ; indique le protocole à utiliser (AH, ESP) et le nombre de transform. Ce bloc indique une transformation (algorithme de chiffrement, fonction de hachage, etc.) Key Exchange (KE) Key Exchange Data supporte une variété de techniques d'échange des clés (par ex, clés publiques) Identification (ID) ID type, ID data Utilisé pour échanger les informations d identifications (ex. Common name CN des certificats) Certificate (CERT) Cert Encoding, Certificate Data Utilisé pour transporter les certificats et autre informations reliés au certificat. 27

28 Les blocs de ISAKMP Type Certificate Request (CR) Paramètres # Cert Types, Certificate Types, # Cert Auths, Certificate Authorities. Description Utilisé pour demander des certificats ; indique les types des certificats demandés et des autorités acceptables de certification. Hash (HASH) Hash Data Contient des données hachées Signature (SIG) Signature Data Contient des données génères par une fonction de signature digitale Nonce (NONCE) Nonce Data Contient un nonce Notification (N) Delete (D) DOI, Protocol-ID, SPI Size, Notify Message Type, SPI, Notification Data DOI, Protocol-ID, SPI Size, Size, # of SPIs, SPI Utilisé pour transmettre des notifications comme les erreurs indique qu un SA n'est plus valide Vendor ID Vendor ID Utilisé pour faciliter au programmeur des infrastructures de reconnaître leur différentes implémentations. 28

29 Les blocs de ISAKMP Après un bloc SA Après un bloc P 1 ou plusieurs blocs P (Proposal) 1 ou plusieurs blocs T (Transform) SA P 1 T 11 T 12 P 2 T 21 T 22 T 23 P1 SPI T 11 algo 1 T 12 algo 2 T 11 algo 1 29

30 Un Exemple ISAKMP Bit: Initiator Cookie Responder Cookie «KE» MnVer MjVer ExchangeType Flags Message ID Length «NONCE» 0 KE payload Length KE payload data 0 0 Nonce payload Length Nonce payload data 30

31 ISAKMP ( Internet Security Association and Key Management Protocol) Caractéristiques des scénarios d échanges: Base Exchange: 4 messages Identity Protection Exchange : 6 messages Authentication Only Exchange : 3 messages Agressive Exchange : 3 messages Informational Exchange : 1 message Autres types d échanges peuvent être envisagés 31

32 L échange de Protection d identité Initiator HDR, SA HDR - Cookie-I = Cookie-a (8 oct.) - Cookie-R = 0 - Message-ID = 0 - SPI = 0 (Cookie-a, Cookie-b) SA: - DOI = IPSEC - Proposal = ex. ISAKMP, IPSec ESP, (plusieurs) - Transform (plusieurs) - méthode d authentification, signature digitale - pseudo-random functions HMAC-MD5 - algorithmes d encryptage DES-CBC (ex, RSA_WITH_RC4_128_SHA) Responder Sélection des attributs de SA 32

33 L échange de Protection d identité Initiator Attributs négociés HDR, SA HDR - Cookie-R = Cookie-b - Cookie-I = Cookie-a - Message-ID = 0 - SPI = 0 (Cookie-a, Cookie-b) SA - DOI = IPSEC - Proposal = PROTO_ISAKMP - Transform - méthode d authentification, signature digitale - pseudo-random functions HMAC-MD5 - algorithmes d encryptage DES-CBC Responder 33

34 L échange de Protection d identité Initiator HDR, KE, NONCE HDR - Cookie-I = Cookie-a - Cookie-R = Cookie-b - Message-ID = 0 (Message-ID reste zero dans toute la phase 1 de ISAKMP) - SPI = (Cookie-a, Cookie-b) KE - valeur public g^x en Diffie Helman de l initiateur ou x est la clé privé de l initiateur NONCE - Ni, un nombre aléatoire choisit à partir de formules mathématique très strictes Responder Calcul de la clé 34

35 L échange de Protection d identité Initiator Calcul de la clé HDR, KE, NONCE HDR - Cookie-I = Cookie-a - Cookie-R = Cookie-b - Message-ID = 0 - SPI = (Cookie-a, Cookie-b) KE - valeur public g^y en Diffie Helman de l initiateur où x est la clé privée du répondeur NONCE - Nr, un nombre aléatoire choisit à partir de formules mathématique très strictes Responder 35 Génération de la clé secret SKEYID a partir de Cookie-a, Cookie-b, Ni, Nr, g^xy

36 L échange de Protection d identité Initiator Responder HDR, IDinit, AUTH HDR (en Clair) - Cookie-I = Cookie-a - Cookie-R = Cookie-b - Message-ID = 0 - SPI = (Cookie-a, Cookie-b) IDii: (chiffré) - identité de l émetteur Auth : (chiffré) Vérification de l'authenticité - un message chiffré et signé pour qu il soit identifié au répondeur 36

37 L échange de Protection d identité Initiator Vérification de l'authenticité HDR, IDresp, AUTH HDR : (en Clair) - Cookie-R = Cookie-b - Cookie-I = Cookie-a - Message-ID = 0 - SPI = (Cookie-a, Cookie-b) IDir: (chiffré) - identité du récepteur Auth : (chiffré) - un message crypté et signé pour qu il soit identifié a l émetteur Responder 37

38 Les autres échanges ISAKMP Échange (1) I R: SA, NONCE (2) R I: SA; NONCE (3) I R: KE; IDI; AUTH (4) R I : KE; IDR; AUTH (1) I R: SA; NONCE (2) R I: SA; NONCE ; IDR ; AUTH (3) I R: IDI; AUTH Notation: HDR: entête du paquet ISAKMP SA = blocs SA + P + T Note Base Exchange Commence la négociation d'isakmp SA Acceptation du SA par le récepteur. Génération des clefs; vérification de l identité de l initiateur par le récepteur. Génération des clés; Vérification de l identité du récepteur par l initiateur; établissement du SA Authentication Only Exchange Commence la négociation d'isakmp SA Acceptation du SA par le récepteur; Vérification de l identité du récepteur par l initiateur; vérification de l identité de l initiateur par le récepteur; établissement du SA Description C est un type d échange basique ou les communiquant génèrent des clés et s authentifient, l identité passe en clair Dans cet échange, les deux communiquant échangent leur identité en clair et s authentifie sans génération de clés, ceci pour économiser le temps de calcul relatif à la génération des clefs 38

39 Échange Les autres échanges ISAKMP Note Description (1) I R: SA; KE; NONCE; ID(I) (2) R I: SA; KE; NONCE; ID(R); AUTH (3)* I R: AUTH Aggressive Exchange Commencez la négociation d'isakmp SA et échange des clefs. vérification de l identité d initiateur par le récepteur; génération des clefs; Acceptation du SA négocier. Vérification de l identité du récepteur par l initiateur; établissement du SA Informational Exchange (1) I R: N/D Notification d'erreur, ou suppression des SA Dans cette échange on regroupe en un seul message la négociation du SA, l échange des clefs et l authentification afin de réduire au maximum le nombre des messages échanges. On utilise ici soit un bloc Notification, soit un bloc Delete 39

40 Authentification dans ISAKMP Méthodes d authentification: 1. Signature numérique (RSA ou DSS) [AUTH]: <CERT> [SIG_R] 2. L utilisation d un secret partagé. [AUTH]: [HASH] = prf(skeyid, gxi gxr cookie-i cookie-r SA IDI). 3. Chiffrement à clé publique [AUTH]:[<IDii_b>PubKey_r][<Ni_b>PubKey_r] 4. Chiffrement à clé publique révisé [AUTH]: [<Ni_b>PubKey_r][<Ke_b>Ke_i] [<IDii_b>Ke_i]<<Cert-I_b>Ke_i>] 40

41 Domain Of Interpretation (DOI) (1/2) Domaine d'interprétation pour IPSec Ce document définit les paramètres négociés et les conventions pour l'utilisation du protocole ISAKMP dans le cadre d'ipsec. Exemple : Bloc P - définition du protocole de sécurité Dans le cadre de l'ipsec DOI, ce bloc peut prendre 4 valeurs :» ISAKMP» AH» ESP» IPCOMP (compression des données au niveau IP) 41

42 Domain Of Interpretation (DOI) (2/2) Phase 1 Phase 2 DOI Protocole Transformation Attributs Ø[0] IPsec[1] ISAKMP[1] AH [2] ESP [3] IPCOMP [4] KEY_OAKLEY [1] AH_MD5[2] AH_SHA[3] AH_DES[4] ESP_DES[2] ESP_3DES[3] ESP_RC5[4] Classe Cipher Algorithm Life Type Algo. Auth. Mode valeur DES-CBS IDEA-CBC Seconds Kbits HMAC_MD5 Tunnel Transport IPCOMP_OUI[1] IPCOMP_DEFLATE[2] IPCOMP_LZS[3] Bloc SA Bloc Proposal Bloc Transform 42

43 IKEv1 ( Internet Key Exchange) Dans le cadre de la standardisation de IPsec, ISAKMP est associé à une partie des protocoles SKEME et Oakley pour donner un protocole final du nom de Internet Key Exchange, IKE (IETF - RFC 2409). IKEv1 (Internet Key Exchange) est le protocole de gestion des clés et des ASs retenu par l IETF : IKEv1 = ISAKMP + Oakley + DOI. 43

44 IKEv1 ( Internet Key Exchange) IKE comprend quatre modes : mode principal (Main Mode) mode agressif (Aggressive Mode) mode rapide (Quick Mode) mode nouveau groupe (New Group Mode) 44

45 Les échanges d IKE IKE définit 3 types d échanges basée sur ISAKMP Secret Partagé Certificat Phase 1 Main Mode Négociation des SA IKE Agressive Mode Phase 2 Négociation des SA pour AH et ESP Quick Mode Phase Opérationnelle AH ESP 45

46 IKE main mode (phase 1) Main Mode est une instance de l'échange ISAKMP Identity Protection Exchange. Messages 1 et 2 négocient les paramètre des Association de Sécurité Message 3 et 4 vont établir une clé secrète (SKEYID) Message 5 et 6 échangent des signatures digitales, et optionnellement des certificats. Initiateur Répondeur Négociation des paramètres IKE Génération des valeurs DH et des aléas *Authentification mutuelle 46

47 IKE aggressive mode (phase 1) Aggressive Mode est une instance de l'échange ISAKMP Aggressive Exchange. Le mode aggressive mode ne contient que trois messages. 47

48 IKE quick mode (phase 2) Les échanges de cette phase sont protégés en confidentialité et en authenticité grâce à la SA ISAKMP établie lors de la phase 1. La phase 2 a pour but de mettre en oeuvre les SA (ou les paquets de SA) pour IPSec. Chaque négociation donne lieu à deux SA (les SA IPSec étant unidirectionnelles). Initiateur HDR, HASH SA, NONCE, [KE], [IDinit, IDresp] HDR, HASH, SA, NONCE, [KE], [IDinit, IDresp], AUTH Répondeur *HDR, HASH 48

49 Génération des clés (1/2) A partir de la clé secrète DH (gxy) et des Nonces (Ni, Nr), nous obtenons la clé session : SKEYID La génération de cette clé diffère suivant le méthode d authentification: Cas d'utilisation d une clé partagée: SKEYID = prf(preshared-key, NONCEI NONCER) Cas d'utilisation de la signature avec les clés publiques : SKEYID = prf(noncei NONCER, gxy) Cas d utilisation d un chiffrement avec les clés publiques: SKEYID = prf(hash(noncei NONCER), cookie-i cookie-r) 49

50 Génération des clés (2/2) A partir de la clé SKEYID, et après la terminaison de phase 1 de IKE, trois nouvelles clés sont générées: SKEYIDd utilisé pour dériver des nouveaux clés dans IKE phase 1 et 2 SKEYIDd = prf(skeyid, gxy cookie-i cookie-r 0). SKEYIDa utilisé pour authentifier les messages phase 2 de IKE SKEYIDa = prf(skeyid, SKEYIDd gxy cookie-i cookie-r 1). SKEYIDe utilisé pour chiffrer les messages 5 et 6 de ILE main mode et tous les messages de IKE phase 2 SKEYIDe = prf(skeyid, SKEYIDa gxy cookie-i cookie-r 2). 50

51 Attaques sur ISAKMP et IKEv1 Dénie de service en mode «Aggressive» Absence des Cookies Dénie de service en mode «Quick» Utilisation de l option «PFS» L attaque «Cookie Crumb Attack» L attaque «Cookie Race» L attaque «Cookie Jar» 51

52 Après ISAKMP/IKEv1 Les successeurs de IKEv1 52

53 Les successeurs de IKEv1: SIGMA Pourquoi un successeur? Support de fonctions de IKEv1 Simplification et clarification Faciliter l évaluation des implémentations IKEv1 Support du NAT, paramètres d accès distants Trois propositions: JFK, SIGMA, IKEv2 Le WINNER : IKEv2 53

54 Les successeurs de IKEv1: SIGMA La signification originale de SIGMA était «SIGN-and-MAC» qui a été conçu en 1994 par Hugo Krawczyk pour l inclusion dans Photuris et qui est devenu plus tard, la base pour la mode de signature de IKEv1 En novembre 2000, proposé par à l IETF comme successeur de IKEv1 54

55 Les successeurs de IKEv1: SIGMA Fonctionnement: Basé sur les clés publiques DH authentifies: Signature et Mac pour lier les identités aux valeurs publique DH Cryptographiquement sécurisé. Mécanisme optionnel contre les DOS Initiateur HDR, SA, KE, Ni, OIDii Initiateur Initiateur Répondeur HDR, RC HDR, SA, KE, Ni, OIDii HDR, SA, KE, Ni, OIDii, RC HDR, SA, KE, Nr, Idir*, CERT*, SIGi* HDR, SA, KE, Nr, IDir*, CERT*, SIGr* HDR, IDii*, CERT*, SIGi* HDR, IDii*, CERT*, SIGi* 55

56 Les successeurs de IKEv1: JFK Just Fast Keying ou JFK est un protocole de négociation de clés développé par le laboratoire de recherche AT&T. Son but est de simplifier le mécanisme de négociation des clés de IPSEC et de résister contre les attaques de dénie de services. Incorpore l approche de protection d identité du répondeur. 56 Les messages JFK ne sont pas basés sur

57 Les successeurs de IKEv1: IKEv2 But: Regroupe les informations précédemment réparties dans les RFC 2407 (domaine d'interprétation), 2408 (ISAKMP) et 2409 (IKE). Simplifie le protocole IKEv1. Enlever les conditions inutiles de ISAKMP et IKEv1. Neutraliser les ambiguïtés (Commit_bit, signification du majeur et du mineur de versions). Corriger les bugs. Préserver l'anonymat des deux parties Autoriser les cookies stateless. Incorporer de nouvelles fonctionnalités dans le protocole IPsec. La constitution d'une SA pour le protocole hébergé peut se faire en 4 messages Un rafraîchissement peut se faire en 2 messages. Utilisation au-dessus de UDP avec les portes 500 et KEv2 = ISAKMP + DOI +IKEv1

58 Les successeurs de IKEv1: IKEv2 L échange de IKEv2 In itia te u r In itia te u r 1 H D R, S A i1, K E, N i 2 H D R, S A r1, K E, N r, [C E R T R E Q ] 3 H D R, S K { ID i, [C E R T,] [C E R T R E Q,] [ID r,] A U T H, S A i2, T S i, T S r} H D R, S K {ID r, [C E R T,] A U T H, S A r2, T S r} Child-SA 4 58

59 Les successeurs de IKEv1: IKEv2 Comparaison entre IKEv1 et IKEv2 IKEv1 # méthodes d authentification 8 2 IKEv2 # modes Phase1 Main et agressive 1 :anonymat Sélection de trafic Plages d adresses + protocoles et ports Duré de vie négociée Choix en local Clés Phase1 Mêmes dans les deux sens ; Dépendent du mode authentification Clé Phase2 Proposition d une plage d adresses Groupe clés par protocole et par SPI Si la plage ne convient pas, rejet de la proposition Différentes pour chaque sens ; ne dépendent pas du mode authentification. Utilisation de la chaîne pseudo aléatoire pour le tirage de clés Possibilité de proposer une sous plage 59

60 Bibliographie Toutes les RFC sont consultables sur le site de l'ietf : SKIP (A. Aziz, T. Markson & H. Prafullchandra) SKEME : A Versatile Secure Key Exchange Mechanism for Internet (Hugo Krawczyk) RFC 2412 : The OAKLEY Key Determination Protocol (H. Orman) RFC 2408 : Internet Security Association and Key Management Protocol (D. Maughan, M. Schertler, M. Schneider & J. Turner) RFC 2407 : The Internet IP Security Domain of Interpretation for ISAKMP (D. Piper) 60

61 Nous contacter Pour plus d'informations, consultez le site