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