Protocoles IKE/IPsec

Thomas Moegli
Ing. HES Télécommunications - Réseaux et Sécurité IT
Protocole IKE/IPsec
๏ IKE et IPsec fonctionnent ensemble pour permettre la mise en place de communications sécurisées sur un
environnement non sécurisé

PKI
Gestion et authentification d’une identité

ISAKMP / IKE
Gestion et génération de clés
Security Association

IPsec
Tunnel IPsec VPN

Algorithmes de Algorithmes de Protocoles de Cryptographie

chiffrement hachage tunneling

Thomas Moegli 2
Protocole IKE/IPsec
๏ IKE et IPsec fonctionnent ensemble pour permettre la mise en place de communications sécurisées sur un
environnement non sécurisé
contrôle
Plan de

Négociation des paramètres de sécurité

IKE

IKE
Etablissement des clés pour l’authentification

Chiffrement, validation et authentification des

Plan de données

ESP
données
IPsec

AH Validation et authentification des données

Thomas Moegli 3
Protocole IKE/IPsec
Protocole IKE
๏ 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
Oakley SKEME ISAKMP
๏ Support des deux versions dans la plupart des équipements VPN Mécanisme d’échange de clés Mécanisme pour un Modes d’échanges et services
basée sur des phases renouvellement rapide de clés liés (PFS, Authentification, …)

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

๏ 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

Thomas Moegli 4
Protocole IKE/IPsec
Protocole IKE

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

Thomas Moegli 5
Protocole IKE/IPsec
Protocole IKE

Trafic reçu
๏ Les clés générés par IKE servent à l’authentification et
la protection du tunnel IKE, permettant ainsi l’échange Négociation IKE Main Mode

de paramètres pour la négociation de clés IPSec

Négociation IKE Quick Mode
๏ Algorithme de Diffie-Hellman utilisé pour la mise en
oeuvre d’une clé de session commune aux deux entités Etablissement du tunnel

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

๏ Phase 2 IKE : négociation des clés IPSec IPsec

Données

Thomas Moegli 6
Protocole IKE/IPsec
Protocole IPsec

๏ 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 7 Application
๏ Confidentialité
6 Présentation
๏ Intégrité des données
5 Session
๏ Anti-rejeu
4 Transport
๏ Utilisation d’un ou plusieurs protocoles pour atteindre ces buts
3 Réseau IPSec
๏ AH (Authentication Header)

๏ ESP (Encapsulating Security Payload) 2 Liaison de données

1 Physique

Thomas Moegli 7
Protocole IKE/IPsec
Security Association (SA)
๏ 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 IKE SA

๏ Sur IPsec, une SA doit être définie pour chaque direction IPsec SA

๏ Contient
๏ Algorithme de chiffrement choisi

๏ Algorithme d’authentification choisi

๏ Clé de session partagée

๏ Lifetime

๏ Flux de donnés à protéger

Thomas Moegli 8
Protocole IKE/IPsec
Security Association Database (SAD)
๏ 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 Genève Lausanne

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

Database)

Thomas Moegli 9
Protocole IKE/IPsec
Contenu d’une SAD (Security Association Database)
Elément Description
Identification unique de la SA (valeur sur 32 bits)
Security Parameter Index (SPI)
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, …)
DSCP, Differentiated Services Code Point
Valeurs DSCP
Valeurs autorisées dans la SA en sortie pour les codes permettant la QoS
Indique si on doit restreindre les flux sortants aux seuls paquets porteurs des valeurs DSCP indiquées plus
Bypass DSCP (Flag)
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 10
Protocole IKE/IPsec
IKE/IPsec et Security Association (SA)

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

Thomas Moegli 11
Protocoles IKE/IPsec

IKEv1
Protocole IKE/IPsec
IKE

๏ 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

Thomas Moegli 13
Protocole IKE/IPsec
IKE v1
๏ Etablissement du canal VPN en 2 phases

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
Main Mode Aggressive Mode

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

Thomas Moegli 14
Protocole IKE/IPsec
IKE v1
Phase 1 : ISAKMP SA

Main Mode Aggressive Mode

(6 Messages) (3 Messages)

Phase 2 : IPsec SA Phase 2 : IPsec SA

Quick Mode …. Quick Mode

(3 Messages) (3 Messages)

Données Données
A protégées B A protégées B

Thomas Moegli 15
Protocole IKE/IPsec
IKE v1

Main Mode
(4 Premiers Messages)

Authentification Pre-Shared Keys Authentification par certificat

(2 Messages) (2 Messages)

Quick Mode
(3 Messages)

Thomas Moegli 16
Protocole IKE/IPsec
IKE v1

๏ Structure d’un en-tête ISAKMP

8 4 4 8 8
32

Initiator Cookie

Responder Cookie

Major Minor
Next Payload Exchange Type Flags
Version Version

Message ID

Longueur

๏ suivi d’une ou plusieurs charges (payload) commençant par cet en-tête :

8 8 16

Next Payload Reserved Longueur

Thomas Moegli 17
Protocole IKE/IPsec
IKE v1
๏ Exemple de structure complète ISAKMP
32
8 4 4 8 8

Initiator Cookie

Responder Cookie
Major Minor
Next Payload Exchange Type Flags
Version Version

Message ID

Longueur
Next Payload =
0 Longueur Payload IKE
Nonce

Données Payload IKE

Next Payload = 0 0 Longueur Payload Nonce

Données Nonce

Thomas Moegli 18
Protocole IKE/IPsec
IKE v1 : Phase 1
๏ Main Mode

1. HDR (CKi, 0),

, SA
SA Messages 1 et 2
Négociation de paramètres IKE SA / ISAKMP SA
2. HDR (CKi, CKr),
, SA
SA

Fin de la négociation des attributs SA

REPONDEUR
3. HDR (CKi, CKr), KE, nonce Messages 3 et 4
INITIATEUR

Echange d’informations requises pour la génération d’une clé avec

4. HDR (CKi, CKr), KEy, nonce l’algorithme Diffie-Hellman (DH)

Calcul des secrets SKEYID, SKEYID_d, SKEYID_a, SKEYID_e)

5. HDR (CKi, CKr), IDi , HASHi Messages 5 et 6
Echange d’informations d’authentification avec DH
6. HDR (CKi, CKr), IDi , HASHr
Les identités sont vérifiées et l’ISAKMP SA créée

Thomas Moegli 19
Protocole IKE/IPsec
IKE v1 : Phase 1

REPONDEUR
INITIATEUR

1. HDR (CKi, 0), SA Initiator Cookie

Responder Cookie (= 0)
Major Minor
SA Exchange Type Flags
version version
Message ID

1er message Longueur (DOI et situation)

๏ Génération d’un Initiator Cookie par l’initiateur Next Payload 1 SA Payload (Longueur)

SA Payload
๏ CKi = md5(src_ip,dest_ip, random number)
Next Payload 1 Proposal Payload (Longueur)
๏ Ajout d’une SA Payload permettant de négocier les
Proposal Payload
paramètres de sécurisation des échanges ultérieurs Next Payload 1 Transform Payload (Longueur)

๏ Proposition de plusieurs suites de protection Transform Payload

๏ Chaque suite définit l’algorithme de chiffrement, hachage, Next Payload 1 Proposal Payload (Longueur)

méthode d’authentification et groupe Diffie-Hellman ainsi Proposal Payload

que des attributs optionnels (durée de vie de la ISAKMP SA) 0 1 Transform Payload (Longueur)

Transform Payload

Thomas Moegli 20
Protocole IKE/IPsec
IKE v1 : Phase 1

REPONDEUR
INITIATEUR

2. HDR (CKi, CKr), SA

Initiator Cookie

Responder Cookie
Major Minor
SA Exchange Type Flags
version version
Message ID

Longueur
2ème message Next Payload 1 SA Payload (Longueur)

๏ Génération d’un Responder Cookie par le destinataire SA Payload (DOI et situation)

๏ CKr = md5(src_ip,dest_ip, random number) Next Payload 1 Proposal Payload (Longueur)

Ajout d’une SA Payload précisant la suite retenue parmi

Proposal Payload (Proposal #, Protocol ID, SPI Size, # of Transforms, SPI)
๏
0 1 Transform Payload (Longueur)
celles proposées par l’inititateur
Transform Payload (Transform #, Transform ID, SA Attributes)

Thomas Moegli 21
Protocole IKE/IPsec
IKE v1 : Phase 1

REPONDEUR
INITIATEUR

3. HDR (CKi, CKr), KE, nonce

Initiator Cookie

3ème message Responder Cookie

Major Minor
Next Payload Exchange Type Flags
๏ Génération de la valeur DH publique de l’initiateur version version
Message ID
๏ Valeur DH publique : Xa
Longueur

๏ Xa = g mod pa
Next Payload 0 KE Payload (Longueur)

๏ avec g (générateur), p (grand nombre premier) et a (valeur KE Payload (inclut la valeur publique DH)

aléatoire privée) Next Payload 0 Nonce Payload (Longueur)

Nonce Payload (inclut Nonce)

๏ 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

Thomas Moegli 22
Protocole IKE/IPsec
IKE v1 : Phase 1

REPONDEUR
INITIATEUR

4. HDR (CKi, CKr), KEy, nonce

Initiator Cookie

4ème message Responder Cookie

Major Minor
Next Payload Exchange Type Flags
๏ Génération de la valeur DH publique du responder version version
Message ID
๏ Valeur DH publique : Xb
Longueur

๏ Xb = g mod pb
Next Payload 0 KE Payload (Longueur)

๏ avec g (générateur), p (grand nombre premier) et b (valeur KE Payload (inclut la valeur publique DH)

aléatoire privée) Next Payload 0 Nonce Payload (Longueur)

Nonce Payload (inclut Nonce)

๏ 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

Thomas Moegli 23
Protocole IKE/IPsec
IKE v1 : Phase 1

Main Mode
(4 Premiers Messages)

Authentification par Pre-Shared Keys Authentification Pre-Shared Keys

Messages 5 et 6 (2 Messages)

Quick Mode
(3 Messages)

Thomas Moegli 24
Protocole IKE/IPsec
IKE v1 : Phase 1
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

Thomas Moegli 25
Protocole IKE/IPsec
IKE v1 : Phase 1

REPONDEUR
INITIATEUR

5. HDR (CKi, CKr), IDi , HASHi

Initiator Cookie

Responder Cookie
Major Minor
Next Payload Exchange Type Flags
version version
Message ID

5ème message Longueur

Envoi du matériel d’authentification et son identifiant

Next Payload 0 Identity Payload (Longueur)
๏
ID Type DOI Specific ID Data

SKEYID_e
๏ Le message est chiffré par la clé SKEYIDe Identity Payload

๏ Le message est authentifié par un hash appelé
 0 0 Hash Payload (Longueur)

HASHi = hash(SKEYID, KE | CKi | CKr | SAr | IDi) Hash Payload

Thomas Moegli 26
Protocole IKE/IPsec
IKE v1 : Phase 1

REPONDEUR
INITIATEUR

6. HDR (CKi, CKr), IDi , HASHr

Initiator Cookie

Responder Cookie
Major Minor
Next Payload Exchange Type Flags
version version
Message ID

6ème message Longueur

Envoi du matériel d’authentification et son identifiant

Next Payload 0 Identity Payload (Longueur)
๏
ID Type DOI Specific ID Data

SKEYID_e
๏ Le message est chiffré par la clé SKEYIDe Identity Payload

๏ Le message est authentifié par un hash appelé
 0 0 Hash Payload (Longueur)

HASHr = hash(SKEYID, KE | CKr | CKi | SAi | IDr) Hash Payload

Thomas Moegli 27
Protocole IKE/IPsec
IKE v1 : Phase 1

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

Thomas Moegli 28
Protocole IKE/IPsec
IKE v1 : Phase 1

Main Mode
(4 Premiers Messages)

Authentification par certificat

Dans les messages 3 et 4, l’initiateur et le responder Authentification par certificat
s’envoient mutuellement une requête de certificat (2 Messages)

Messages 5 et 6

Quick Mode
(3 Messages)

Thomas Moegli 29
Protocole IKE/IPsec
IKE v1 : Phase 1

Initiator Cookie

Responder Cookie
Major Minor
Next Payload Exchange Type Flags
version version
5ème et 6ème message Message ID

๏ Envoi des certificats par l’initiateur et responder Longueur

Next Payload 0 Identity Payload (Longueur)

๏ Le message est chiffré par la clé SKEYIDe
ID Type DOI Specific ID Data

๏ Le message est signé
 Identity Payload

SIGi = PRIVATE_KEYi (HASHi)


SKEYID_e
Next Payload 0 Signature Payload (Longueur)

SIGr = PRIVATE_KEYr (HASHr) Signature Data

0 0 Certificate Payload (Longueur)

Certificate Encoding Certificate Data

Certificate Data

Thomas Moegli 30
Protocole IKE/IPsec
IKE v1 : Phase 1

Aggressive Mode
(3 Premiers Messages)

Quick Mode
(3 Messages)

Thomas Moegli 31
Protocole IKE/IPsec
IKE v1 : Phase 1
Aggressive Mode

REPONDEUR
INITIATEUR

๏ La protection contre les dénis de service est plus faible

๏ Les 3 échanges préalables mentionnés en mode Main
1. HDR (CKi, 0), SA, KE, Noncei, IDi
2. HDR (CKi, CKr), SA, KE, Noncer, IDr, HASHr n’existent pas
3. HDR (CKi, CKr), HASHi ๏ Les calculs DH commencent dès la réception du premier
Identités vérifiées, IKE SA créée cookie
๏ 3 messages échangés

Thomas Moegli 32
Protocole IKE/IPsec
IKE v1 : Phase 1

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

Thomas Moegli 33
Protocole IKE/IPsec
IKE v1 : Phase 2
Je veux protéger
ip traffic from 10.1.3.0/24 à 10.2.5.0/24
J’offre : Ok, je protège
ESP avec AES et SHA ip traffic from 10.1.3.0/24 à 10.2.5.0/24
ESP avec 3DES et SHA Je choisis :
Voici mon Noncei ESP avec AES et SHA
PFS demandé; voici g a Voici mon Noncer
PFS ok; voici g b
Ok, merci

REPONDEUR
INITIATEUR

Négociation IPsec

๏ 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

Thomas Moegli 34
Protocole IKE/IPsec
IKE v1 : Phase 2
Quick Mode

REPONDEUR
INITIATEUR

1. HDR (CKi, 0), HASH1, SA, Noncei, [KE], [IDi, IDr]

Négociation des IPsec SA
2. HDR (CKi, CKr), HASH2, SA, [KE], [IDi, IDr] (3 Premiers Messages)
3. HDR (CKi, CKr), HASH3
Identités vérifiées, IPsec SA créées

Thomas Moegli 35
Protocole IKE/IPsec
PFS : Perfect Forward Secrecy

๏ 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

Thomas Moegli 36
Protocole IKE/IPsec
IKE v1 : Phase 2

Activation de PFS
๏ Du côté de l’Initiator ๏ Du côté du Responder
๏ Nonce généré : Noncei ๏ Nonce généré : Noncer

๏ Nouvelle valeur DH publique : Xa’ ๏ Nouvelle valeur DH publique : Xb’

๏ Xa’ = ga mod p ๏ Xb’= gb mod p
๏ avec g (générateur), p (grand nombre premier) et a (valeur ๏ avec g (générateur), p (grand nombre premier) et a
aléatoire privée)
(valeur aléatoire privée)

Thomas Moegli 37
Protocole IKE/IPsec
IKE v1 : Phase 2

REPONDEUR
INITIATEUR

1. HDR (CKi, 0), HASH1, SA, Noncei, [KE], [IDi, IDr]

Initiator Cookie

Responder Cookie
Major Minor
KE Exchange Type Flags
version version
Message ID

1er message Longueur

Envoi du matériel d’authentification et son identifiant

…
๏

๏ Proposition de plusieurs suites de protection

Thomas Moegli 38
Protocole IKE/IPsec
IKE v1 : Phase 2
SA 0 Hash Payload (Longueur)

Hash Payload

REPONDEUR
INITIATEUR

Next Payload 0 SA Payload (Longueur)

1. HDR (CKi, 0), HASH1, SA, Noncei, [KE], [IDi, IDr]
SA Payload (inclut DOI et situation)

Next Payload 0 Proposal Payload (Longueur)

Proposal Payload

Next Payload 0 Transform Payload (Longueur)

Proposal :
ESP ou AH, SHA ou MD5,
Transform Payload DH 1 ou 2, SPI
(2 propositions dans cet exemple)
Next Payload 0 Proposal Payload (Longueur)

Proposal Payload Transform :

Tunnel ou Transport

SKEYID_e
Next Payload 0 Transform Payload (Longueur) IPsec Timeout
1er message Transform Payload

Envoi du matériel d’authentification et son identifiant

Next Payload 0 Keyload Payload (Longueur)
๏ KE Payload = Xa’
KE Payload

๏ Proposition de plusieurs suites de protection Next Payload 0 Nonce Payload (Longueur)

Nonce Payload (Noncei)

Next Payload 0 Identity Payload (Longueur)

ID Type DOI Specific ID Data

Identity Payload (IDs)

Next Payload 0 Identity Payload (Longueur) IDs = Source Proxy

IDd = Destination Proxy
ID Type DOI Specific ID Data

Identity Payload (IDd)

Thomas Moegli 39
Protocole IKE/IPsec
IKE v1 : Phase 2

REPONDEUR
INITIATEUR

2. HDR (CKi, CKr), HASH2, SA, [KE], [IDi, IDr]

Initiator Cookie

Responder Cookie
Major Minor
KE Exchange Type Flags
version version
Message ID

2ème message Longueur

Envoi du matériel d’authentification et son identifiant

…
๏
๏ Sélection d’une suite parmi celle proposées

Thomas Moegli 40
Protocole IKE/IPsec
IKE v1 : Phase 2

REPONDEUR
SA 0 Hash Payload (Longueur)
INITIATEUR

2. HDR (CKi, CKr), HASH2, SA, [KE], [IDi, IDr] Hash Payload

Next Payload 0 SA Payload (Longueur)

SA Payload (inclut DOI et situation)

Next Payload 0 Proposal Payload (Longueur)

Proposal Payload

Next Payload 0 Transform Payload (Longueur)

Proposal :
Responder SPI
Transform Payload

SKEYID_e
Next Payload 0 Keyload Payload (Longueur)
KE Payload = Xb’
2ème message KE Payload

Next Payload 0 Nonce Payload (Longueur)

๏ Envoi du matériel d’authentification et son identifiant
Nonce Payload (Noncer)

๏ Sélection d’une suite parmi celle proposées Next Payload 0 Identity Payload (Longueur)

ID Type DOI Specific ID Data

Identity Payload (IDs)

Next Payload 0 Identity Payload (Longueur)

ID Type DOI Specific ID Data

Identity Payload (IDd)

Thomas Moegli 41
Protocole IKE/IPsec
IKE v1 : Phase 2

Calcul DH (en cas d’activation PFD)

๏ Du côté de l’Initiator ๏ Du côté du Responder
๏ Calcul DH : KE = (Xb’)a mod p ๏ Calcul DH : KE = (Xa’)b mod p
๏ Clé de session IPsec : 
 ๏ Clé de session IPsec : 

key = PRF(SKEYIDd | protocol(ISAKMP) | KE | SPi key = PRF(SKEYIDd | protocol(ISAKMP) | KE
| Noncei | Noncer) | SPi | Noncei | Noncer)

Thomas Moegli 42
Protocole IKE/IPsec
IKE v1 : Phase 2

REPONDEUR
INITIATEUR

3. HDR (CKi, CKr), HASH3

Initiator Cookie

Responder Cookie
Major Minor
KE Exchange Type Flags
version version
Message ID
3ème message Longueur

๏ Le client valide la mise en place du tunnel IPsec en

SKEYID_e
SA 0 Hash Payload (Longueur)

envoyant un dernier paquet Hash Payload

Thomas Moegli 43
Protocoles IKE/IPsec

IKEv2
Protocole IKE/IPsec
IKE v2

IKE_SA_INIT Authentification du tunnel IKE_SA

(2 à 4 Messages) Négociation des paramètres

๏ RFC 4306 (décembre 2005)


RFC 5996 (septembre 2010)
 IKE_AUTH
(2 Messages)
Transmission et authentification des entités
Génère le premier Child SA (similaire à IPsec SA)

RFC 6989 ( juillet 2013)

๏ On réduit les 8 échanges initiaux (Phase 1 et Phase 2) 
 (Opt) Création d’un second Child SA si nécessaire
CREATE_CHILD_SA
(2 Messages)

à 4 échanges
A Données protégées B

Thomas Moegli 45
Protocole IKE/IPsec
IKE v2

๏ 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

Thomas Moegli 46
Protocole IKE/IPsec
IKE v2

REPONDEUR
INITIATEUR

Initiator SPI

Responder SPI
Major Minor
Next Payload Exchange Type Flags
version version

1er message Message ID

Longueur
๏ Permet de négocier les paramètres de sécurité de la SA
Next Payload C 0 SA Payload (Longueur)
et de communiquer les valeurs de nonces et de Diffie- SA Payload (inclut informations Proposal et Tranform)

Hellman Next Payload C 0 KE Payload (Longueur)

KE Payload (inclut valeurs publiques DH)

Next Payload C 0 Nonce Payload (Longueur)

IKE_SA_INIT Nonce
(2 à 4 Messages)

Thomas Moegli 47
Protocole IKE/IPsec
IKE v2

REPONDEUR
INITIATEUR

Initiator SPI

Responder SPI
Major Minor
Next Payload Exchange Type Flags
version version

2ème message Message ID

Longueur
๏ Permet de négocier les paramètres de sécurité de la SA
Next Payload C 0 SA Payload (Longueur)
et de communiquer les valeurs de nonces et de Diffie- SA Payload (inclut informations Proposal et Tranform)

Hellman Next Payload C 0 KE Payload (Longueur)

KE Payload (inclut valeurs publiques DH)

Next Payload C 0 Nonce Payload (Longueur)

IKE_SA_INIT Nonce
(2 à 4 Messages)

Thomas Moegli 48
Protocole IKE/IPsec
IKE v2

REPONDEUR
INITIATEUR

Initiator SPI

Responder SPI
Major Minor
Next Payload Exchange Type Flags
version version
Message ID

3ème message Longueur

๏ Transmission et authentification des identités Next Payload C 0 ID Payload (Longueur)

ID Payload (contient Initiator ID)

๏ Génère la première Child SA si tout se passe bien Next Payload C 0 Auth Payload (Longueur)

๏ Child SA = équivalent à IPsec SA Authentication Payload

SK_e, SK_a
๏ L’échange recouvre une partie de la phase 1 d’IKEv1 et une Next Payload C 0 SA Payload (Longueur)

partie de la phase 2 (IPsec SA)

SA Payload pour le premier CHILD_SA

Next Payload C 0 TS Payload (Longueur)

Traffic Selector Payload

IKE_AUTH Next Payload C 0 TS Payload (Longueur)

(2 Messages)
Traffic Selector Payload

Thomas Moegli 49
Protocole IKE/IPsec
IKE v2

REPONDEUR
INITIATEUR

Initiator SPI

Responder SPI
Major Minor
Next Payload Exchange Type Flags
version version
Message ID

4ème message Longueur

๏ Transmission et authentification des identités Next Payload C 0 ID Payload (Longueur)

ID Payload (contient Initiator ID)

๏ Génère la première Child SA si tout se passe bien Next Payload C 0 Auth Payload (Longueur)

๏ Child SA = équivalent à IPsec SA Authentication Payload

SK_e, SK_a
๏ L’échange recouvre une partie de la phase 1 d’IKEv1 et une Next Payload C 0 SA Payload (Longueur)

partie de la phase 2 (IPsec SA)

SA Payload pour le premier CHILD_SA

Next Payload C 0 TS Payload (Longueur)

Traffic Selector Payload

IKE_AUTH Next Payload C 0 TS Payload (Longueur)

(2 Messages)
Traffic Selector Payload

Thomas Moegli 50
Protocole IKE/IPsec
IKE v2

REPONDEUR
INITIATEUR

Initiator SPI

Responder SPI
Major Minor
Next Payload Exchange Type Flags
version version
Message ID

Longueur
5ème message Next Payload C 0 SA Payload (Longueur)

๏ Permet de générer, si besoin, d’autres Child SA SA Payload (inclut informations Proposal et Transform)

Echange du matériel d’authentification et identifiants

Next Payload C 0 Nonce Payload (Longueur)
๏

SK_e, SK_a
Nonce

Next Payload C 0 TS Payload (Longueur)

Traffic Selector Payload

Next Payload C 0 TS Payload (Longueur)

CREATE_CHILD_SA Traffic Selector Payload

(2 Messages)

Thomas Moegli 51
Protocole IKE/IPsec
IKE v2

REPONDEUR
INITIATEUR

Initiator SPI

Responder SPI
Major Minor
Next Payload Exchange Type Flags
version version
Message ID

Longueur
6ème message Next Payload C 0 SA Payload (Longueur)

๏ Permet de générer, si besoin, d’autres Child SA SA Payload (inclut informations Proposal et Transform)

Echange du matériel d’authentification et identifiants

Next Payload C 0 Nonce Payload (Longueur)
๏

SK_e, SK_a
Nonce

Next Payload C 0 TS Payload (Longueur)

Traffic Selector Payload

Next Payload C 0 TS Payload (Longueur)

CREATE_CHILD_SA Traffic Selector Payload

(2 Messages)

Thomas Moegli 52
Protocoles IKE/IPsec

IPsec
Protocole IKE/IPsec
IPsec

๏ 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
7 Application
๏ Confidentialité

๏ Intégrité des données 6 Présentation

๏ Anti-rejeu 5 Session

๏ Utilisation d’un ou plusieurs protocoles pour atteindre ces buts 4 Transport

๏ AH (Authentication Header) 3 Réseau IPSec

๏ ESP (Encapsulating Security Payload)
2 Liaison de données

1 Physique

Thomas Moegli 54
Protocole IKE/IPsec
IPsec

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

Thomas Moegli 55
Protocole IKE/IPsec
Modes d’opération IPsec

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

Thomas Moegli 56
Protocole IKE/IPsec
Modes d’opération IPsec

Comparaison des modes

IP Header Data
Mode Transport

IP Header IPsec Header Data IPsec Footer

Peut être chiffré

IP Header Data

Mode Tunnel

New IP Header IPsec Header IP Header Data IPsec Footer

Peut être chiffré

Thomas Moegli 57
Protocole IKE/IPsec
Authentication Header (AH)

๏ 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

Thomas Moegli 58
Protocole IKE/IPsec
Authentication Header (AH)

Intégration de l’en-tête AH dans un paquet IP (Mode tunnel) :

En-tête TCP
Adresse IP Source Adresse IP Dst TCP Payload
(Protocole = 6)

En-tête AH Nouvelle Nouvelle

Adresse IP Source Adresse IP Dst En-tête TCP TCP Payload
Next Header = 4 (IP) Adresse IP Source Adresse IP Dst

Partie authentifiée

๏ 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

Thomas Moegli 59
Protocole IKE/IPsec
Authentication Header (AH)

Intégration de l’en-tête AH dans un paquet IP (Mode transport) :




En-tête TCP

 Adresse IP Source Adresse IP Dst
(Protocole = 6)
TCP Payload







En-tête AH


Adresse IP Source Adresse IP Dst En-tête TCP TCP Payload
Next Header = 6 (TCP)

Partie authentifiée

๏ 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

Thomas Moegli 60
Protocole IKE/IPsec
Authentication Header (AH)

๏ Structure de l’en-tête AH :

8 8 16

Next Header Payload Length Reserved

Security Parameter Index (SPI)

Sequence Number

Authentication Data
(Integrity Check Value)

Thomas Moegli 61
Protocole IKE/IPsec
Authentication Header (AH)

Structure de l’en-tête AH :
Elément Description
Numéro du protocole contenu dans la charge située immédiatement après l’en-tête AH
Next Header
En mode tunnel : il s’agit d’IPv4 ou IPv6
Longueur charge

Représente la taille de l’en-tête AH
Payload length
SPI
 Numéro d’index dans la base SPD
Security Parameter Index Permet de relier le paquet à une assic
Compteur permettant de détecter des paquets qui seraient rejoués après avoir été enregistrés.
Sequence number 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 62
Protocole IKE/IPsec
Authentication Header (AH)

๏ 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

Thomas Moegli 63
Protocole IKE/IPsec
Authentication Header (AH)

๏ 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

Thomas Moegli 64
Protocole IKE/IPsec
Encapsulation Security Payload (ESP)

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

Thomas Moegli 65
Protocole IKE/IPsec
Encapsulation Security Payload (ESP)

๏ Structure de l’en-tête ESP

8 8 16

Next Header Payload Length Reserved

Security Parameter Index (SPI)

Sequence Number

Payload
Peut contenir en début un champ IV

Payload
Padding

Padding length Next Header

Integrity Check Value (ICV)

Authentication Data

Thomas Moegli 66
Protocole IKE/IPsec
Encapsulation Security Payload (ESP)

Structure de l’en-tête ESP :

Elément Description
Numéro d’index dans la base SPD
SP
Permet de relier le paquet à une association de sécurité (SA)
Compteur permettant de détecter des paquets qui seraient rejoués après avoir été enregistrés.
Sequence Number 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 

(Facultatif ) Contient les 8 premiers octets de la zone « Données Protégées ».
Initialisation Vector 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 67
 Protocole IKE/IPsec
Encapsulation Security Payload (ESP)

Intégration de l’en-tête ESP dans un paquet IP (Mode tunnel) :

En-tête TCP
Adresse IP Source Adresse IP Dst TCP Payload
(Protocole = 6)

En-tête ESP Nouvelle Nouvelle ICV ESP

Adresse IP Source Adresse IP Dst En-tête TCP TCP Payload En-queue ESP
Next Header = 4 (IP) Adresse IP Source Adresse IP Dst Authentification

Partie chiffrée
Partie authentifiée

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

Thomas Moegli 68
Protocole IKE/IPsec
Encapsulation Security Payload (ESP)

Intégration de l’en-tête ESP dans un paquet IP (Mode tunnel) :

En-tête TCP
Adresse IP Source Adresse IP Dst TCP Payload
(Protocole = 6)

En-tête ESP ICV ESP

Adresse IP Source Adresse IP Dst En-tête TCP TCP Payload En-queue ESP
Next Header = 6 (TCP) Authentification

Partie chiffrée
Partie authentifiée

Thomas Moegli 69
Protocole IKE/IPsec
Encapsulation Security Payload (ESP)

๏ 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

Thomas Moegli 70
Protocoles IKE/IPsec

Extensions IKE
Protocole IKE/IPsec
Extensions IKE

๏ 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

Thomas Moegli 72
Protocole IKE/IPsec
Extensions IKE : IKE Keep-Alive et DPD

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

Thomas Moegli 73
Protocole IKE/IPsec
Extensions IKE : IKE Keep-Alive

๏ 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

Thomas Moegli 74
Protocole IKE/IPsec
Extensions IKE : Dead Peer Detection (DPD)
๏ 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

Internet

VPN Concentrator

Application Server
Données reçues

Aucune donnée
reçue
Message DPD : R-U-THERE
Message DPD : R-U-THERE-ACK

Thomas Moegli 75
Protocole IKE/IPsec
Extensions IKE : Dead Peer Detection (DPD)
๏ 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
Je dois envoyer à B
régulièrement des données. Ce n’est pas très important
Le passage de trafic IPSec prouve que la liaison
Je dois savoir rapideement
si le tunnel vers B est ok
si je perds la liaison vers A VPN est active
DPD est asynchrone
A B
Chaque voisin définit ses critères DPD
Internet
Vérification du voisin uniquement si nécessaire
Thomas Moegli 76
Protocole IKE/IPsec
Extensions IKE : Dead Peer Detection (DPD)
32
8 8 8 8

ISAKMP Header

Next Payload Reserved Notify Payload Length

DOI = IPsec DOI

Protocol ID = Notify Message Type =
SPI Size
ISAKMP R-U-THERE

SPI = CKYi | CKYr

Notification Data = Sequence Number

R-YOU-THERE
Initiator Répondeur

R-YOU-THERE-ACK

32
8 8 8 8

ISAKMP Header

Next Payload Reserved Notify Payload Length

DOI = IPsec DOI

Protocol ID = Notify Message Type =
SPI Size
ISAKMP R-U-THERE

SPI = CKYi | CKYr

Notification Data = Sequence Number

Thomas Moegli 77
Protocole IKE/IPsec
Extensions IKE : Mode Config et XAUTH

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

Thomas Moegli 78
Protocole IKE/IPsec
Extensions IKE : Mode Config et XAUTH
Phase 1 : ISAKMP SA

Main Mode Aggressive Mode

(6 Messages) (3 Messages)

Phase 1.5 : XAUTH et/ou Mode Config

Phase 2 : IPsec SA Phase 2 : IPsec SA

Quick Mode …. Quick Mode

(3 Messages) (3 Messages)

Données Données
A protégées B A protégées B

Thomas Moegli 79
Protocole IKE/IPsec
Extensions IKE : Authentification XAUTH

Passerelle
Passerelle
IPsec
IPsec Client IPsec
WAN

Serveur AAA

Username/Password

CHAP

OTP

S/Key

Thomas Moegli 80
Protocole IKE/IPsec
Extensions IKE : Mode Config
๏ Mécanisme utilisé pour envoyer les attributs IP aux clients IPsec distants

Passerelle
Passerelle
IPsec
IPsec Client IPsec
WAN

Serveur AAA

Adresse IP interne
Username/Password

Serveur
CHAPDNS

Serveur
OTPDHCP

Attributs optionnels
S/Key

Thomas Moegli 81
Protocole IKE/IPsec
Extensions IKE : Authentification XAUTH
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 82
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)

Thomas Moegli 83