Présentation des protocoles IKE et IPsec utilisés dans la mise en oeuvre de tunnels VPN Site-to-Site et Remote Access. Fonctionnement du protocole IKEv1, différences avec IKEv2 Fonctionnement du protocole IPsec et de la mise en place d’un tunnel VPN Extensions du protocole IKEv1 (KeepAlive, DPD, NAT-T. Mode Config, XAUTH)

1. Thomas Moegli
Ing. HES Télécommunications - Réseaux et Sécurité IT
Protocoles IKE/IPsec

2. 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é

3. 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

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
๏ 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

6. 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

7. 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

8. 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

9. 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

10. 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)

11. 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

12. Protocoles IKE/IPsec
IKEv1

13. 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

14. 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

15. 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

16. 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)

17. 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

18. 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

19. 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

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 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)

25. 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

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 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

29. 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)

30. 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

31. Thomas Moegli
Protocole IKE/IPsec
IKE v1 : Phase 1
31
Aggressive Mode
(3 Premiers Messages)
Quick Mode
(3 Messages)

32. 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

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
๏ 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

35. 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

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 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)

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 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

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
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

44. Protocoles IKE/IPsec
IKEv2

45. 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

46. 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

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)
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

50. 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

51. 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

52. 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

53. Protocoles IKE/IPsec
IPsec

54. 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

55. 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

56. 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

57. 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

58. 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

59. 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

60. 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

61. 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

62. 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)

63. 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

64. 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

65. 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

66. 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

67. 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.

68. 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

69. 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

70. 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

71. Protocoles IKE/IPsec
Extensions IKE

72. 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

73. 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

74. 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

75. 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

76. 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

77. 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

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
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

80. 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

81. 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

82. 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

83. 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