Cisco- Protocoles Ikeipsec-ok.pdf

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é

Gestion et génération de clés Security Association

ISAKMP / IKE

IPsec Tunnel IPsec VPN

Algorithmes de chiffrement

Thomas Moegli

Algorithmes de hachage

Protocoles de tunneling

Cryptographie

2

Protocole IKE/IPsec ๏

IKE et IPsec fonctionnent ensemble pour permettre la mise en place de communications sécurisées sur un

Thomas Moegli

IKE

IKE

Négociation des paramètres de sécurité Etablissement des clés pour l’authentification

ESP

Chiffrement, validation et authentification des données

AH

Validation et authentification des données

IPsec

Plan de données

Plan de contrôle

environnement non sécurisé

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 ๏ Support des deux versions dans la plupart des équipements VPN

๏

Oakley

SKEME

ISAKMP

Mécanisme d’échange de clés basée sur des phases

Mécanisme pour un renouvellement rapide de clés

Modes d’échanges et services 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 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

Trafic reçu Négociation IKE Main Mode Négociation IKE Quick Mode 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

๏

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

IKE 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 ๏ Confidentialité ๏ Intégrité des données ๏ Anti-rejeu

๏

Utilisation d’un ou plusieurs protocoles pour atteindre ces buts

7

Application

6

Présentation

5

Session

4

Transport IPSec

๏ AH (Authentication Header)

3

๏ ESP (Encapsulating Security Payload)

2 Liaison de données 1

Thomas Moegli

Réseau

Physique

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 ๏ Sur IPsec, une SA doit être définie pour chaque direction

๏

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

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 Bypass DSCP (Flag)

DSCP, Differentiated Services Code Point 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 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 2 : Négociation et accord d’une SA IPsec entre pairs (Quick Mode)

Chaque phase utilise une SA :

๏

๏

Phase 1 : Etablissement entre deux pairs d’un tunnel sécurisé et authentifié (Main Mode ou Agressive Mode)

๏

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 (6 Messages)

Aggressive Mode (3 Messages)

Phase 2 : IPsec SA ….

Quick Mode (3 Messages)

A

Thomas Moegli

Données protégées

Phase 2 : IPsec SA

B

Quick Mode (3 Messages)

A

Données protégées

B

15

Protocole IKE/IPsec

IKE v1 Main Mode (4 Premiers Messages)

Authentification Pre-Shared Keys (2 Messages)

Authentification par certificat (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

Exchange Type

Flags

32

Initiator Cookie Responder Cookie Next Payload

Major Version

Minor Version

Message ID Longueur

๏

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

Thomas Moegli

8

8

16

Next Payload

Reserved

Longueur

17

Protocole IKE/IPsec

IKE v1 ๏

Exemple de structure complète ISAKMP 8

4

4

32

8

8

Initiator Cookie Responder Cookie Next Payload

Major Version

Minor Version

Exchange Type

Flags

Message ID Longueur Next Payload = Nonce

0

Longueur Payload IKE

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

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

REPONDEUR

INITIATEUR

Fin de la négociation des attributs 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

Les identités sont vérifiées et l’ISAKMP SA créée

Thomas Moegli

19

Protocole IKE/IPsec

1. HDR (CKi, 0), SA

REPONDEUR

INITIATEUR

IKE v1 : Phase 1 Initiator Cookie Responder Cookie (= 0) SA

Major version

Minor version

Exchange Type

Flags

Message ID

1er message ๏

Génération d’un Initiator Cookie par l’initiateur

Longueur (DOI et situation) Next Payload

1 SA Payload

๏ 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

Next Payload

1

Next Payload

1

Transform Payload (Longueur) Transform Payload

Next Payload

1

méthode d’authentification et groupe Diffie-Hellman ainsi que des attributs optionnels (durée de vie de la ISAKMP SA)

Proposal Payload (Longueur) Proposal Payload

๏ Proposition de plusieurs suites de protection ๏ Chaque suite définit l’algorithme de chiffrement, hachage,

SA Payload (Longueur)

Proposal Payload (Longueur) Proposal Payload

0

1

Transform Payload (Longueur) Transform Payload

Thomas Moegli

20

Protocole IKE/IPsec

2. HDR (CKi, CKr), SA

REPONDEUR

INITIATEUR

IKE v1 : Phase 1 Initiator Cookie Responder Cookie SA

Major version

Minor version

Exchange Type

Flags

Message ID

2ème message ๏

Next Payload

Génération d’un Responder Cookie par le destinataire ๏ CKr = md5(src_ip,dest_ip, random number)

๏

Longueur

Ajout d’une SA Payload précisant la suite retenue parmi celles proposées par l’inititateur

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

21

Protocole IKE/IPsec

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

REPONDEUR

INITIATEUR

IKE v1 : Phase 1

Initiator Cookie

3ème message ๏

Génération de la valeur DH publique de l’initiateur

Responder Cookie Next Payload

Major version

Minor version

๏ Xa = g mod p

Longueur Next Payload

๏ 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

Flags

Message ID

๏ Valeur DH publique : Xa a

Exchange Type

0

KE Payload (Longueur)

KE Payload (inclut la valeur publique DH) Next Payload

0

Nonce Payload (Longueur)

Nonce Payload (inclut Nonce)

nonce et les données d’échange de clés (symbolisé par KE) ๏ KE = Xa

Thomas Moegli

22

Protocole IKE/IPsec

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

REPONDEUR

INITIATEUR

IKE v1 : Phase 1

Initiator Cookie

4ème message ๏

Génération de la valeur DH publique du responder

Responder Cookie Next Payload

Major version

Minor version

๏ Xb = g mod p

Longueur Next Payload

๏ 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

Flags

Message ID

๏ Valeur DH publique : Xb b

Exchange Type

0

KE Payload (Longueur)

KE Payload (inclut la valeur publique DH) Next Payload

0

Nonce Payload (Longueur)

Nonce Payload (inclut Nonce)

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 Messages 5 et 6

Authentification Pre-Shared Keys (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

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

REPONDEUR

INITIATEUR

IKE v1 : Phase 1

Initiator Cookie Responder Cookie Next Payload

Major version

Minor version

Exchange Type

Flags

Message ID

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)

Thomas Moegli

Next Payload

SKEYID_e

๏

Longueur 0

Identity Payload (Longueur)

ID Type

DOI Specific ID Data Identity Payload

0

0

Hash Payload (Longueur) Hash Payload

26

Protocole IKE/IPsec

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

REPONDEUR

INITIATEUR

IKE v1 : Phase 1

Initiator Cookie Responder Cookie Next Payload

Major version

Minor version

Exchange Type

Flags

Message ID

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)

Thomas Moegli

Next Payload

SKEYID_e

๏

Longueur 0

Identity Payload (Longueur)

ID Type

DOI Specific ID Data Identity Payload

0

0

Hash Payload (Longueur) Hash Payload

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 s’envoient mutuellement une requête de certificat

Authentification par 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 Next Payload

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)

Minor version

Exchange Type

Flags

Message ID Longueur Next Payload

0

Identity Payload (Longueur)

ID Type

DOI Specific ID Data Identity Payload

SKEYID_e

๏

Major version

Next Payload

0

Signature Payload (Longueur) Signature Data

0 Certificate Encoding

0

Certificate Payload (Longueur) 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

1. HDR (CKi, 0), SA, KE, Noncei, IDi

REPONDEUR

INITIATEUR

Aggressive Mode

๏

๏ Les 3 échanges préalables mentionnés en mode Main

n’existent pas

2. HDR (CKi, CKr), SA, KE, Noncer, IDr, HASHr

๏ Les calculs DH commencent dès la réception du premier

3. HDR (CKi, CKr), HASHi

cookie

Identités vérifiées, IKE SA créée

๏

Thomas Moegli

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

3 messages échangés

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 : ESP avec AES et SHA ESP avec 3DES et SHA Voici mon Noncei PFS demandé; voici g a

Négociation IPsec

REPONDEUR

INITIATEUR

Ok, merci

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

๏

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

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

REPONDEUR

INITIATEUR

Quick Mode

Négociation des IPsec SA (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

๏ avec g (générateur), p (grand nombre premier) et a (valeur

aléatoire privée)

Thomas Moegli

๏ Xb’= gb mod p ๏

avec g (générateur), p (grand nombre premier) et a (valeur aléatoire privée)

37

Protocole IKE/IPsec

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

REPONDEUR

INITIATEUR

IKE v1 : Phase 2

Initiator Cookie Responder Cookie KE

Major version

Minor version

Exchange Type

Flags

Message ID

1er message ๏

Envoi du matériel d’authentification et son identifiant

๏

Proposition de plusieurs suites de protection

Thomas Moegli

Longueur …

38

Protocole IKE/IPsec

IKE v1 : Phase 2 1. HDR (CKi, 0), HASH1, SA, Noncei, [KE], [IDi, IDr]

0

Hash Payload (Longueur) Hash Payload

REPONDEUR

INITIATEUR

SA

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

Next Payload

0

Proposal Payload (Longueur)

๏ ๏

message Envoi du matériel d’authentification et son identifiant Proposition de plusieurs suites de protection

SKEYID_e

Proposal Payload

1er

Next Payload

0

Proposal : ESP ou AH, SHA ou MD5, DH 1 ou 2, SPI (2 propositions dans cet exemple)

Transform Payload (Longueur)

Transform : Tunnel ou Transport IPsec Timeout

Transform Payload Next Payload

0

Keyload Payload (Longueur) KE Payload

Next Payload

0

KE Payload = Xa’

Nonce Payload (Longueur) Nonce Payload (Noncei)

Next Payload

0 ID Type

Identity Payload (Longueur) DOI Specific ID Data Identity Payload (IDs)

Next Payload

0 ID Type

Thomas Moegli

Identity Payload (Longueur)

IDs = Source Proxy IDd = Destination Proxy

DOI Specific ID Data Identity Payload (IDd)

39

Protocole IKE/IPsec

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

REPONDEUR

INITIATEUR

IKE v1 : Phase 2

Initiator Cookie Responder Cookie KE

Major version

Minor version

Exchange Type

Flags

Message ID

2ème message ๏

Envoi du matériel d’authentification et son identifiant

๏

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

Thomas Moegli

Longueur …

40

Protocole IKE/IPsec

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

REPONDEUR

INITIATEUR

IKE v1 : Phase 2 SA

0

Hash Payload (Longueur) 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

2ème message ๏

Envoi du matériel d’authentification et son identifiant

๏

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

SKEYID_e

Transform Payload Next Payload

0

Keyload Payload (Longueur) KE Payload

Next Payload

0

KE Payload = Xb’

Nonce Payload (Longueur) Nonce Payload (Noncer)

Next Payload

0 ID Type

Identity Payload (Longueur) DOI Specific ID Data Identity Payload (IDs)

Next Payload

0 ID Type

Identity Payload (Longueur) 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

3. HDR (CKi, CKr), HASH3

REPONDEUR

INITIATEUR

IKE v1 : Phase 2

Initiator Cookie Responder Cookie KE

๏

Minor version

message

Le client valide la mise en place du tunnel IPsec en envoyant un dernier paquet

Thomas Moegli

Exchange Type

Flags

Message ID Longueur

SKEYID_e

3ème

Major version

SA

0

Hash Payload (Longueur) Hash Payload

43

Protocoles IKE/IPsec

IKEv2

Protocole IKE/IPsec

IKE v2

Authentification du tunnel IKE_SA Négociation des paramètres

IKE_SA_INIT (2 à 4 Messages)

๏

RFC 4306 (décembre 2005)
 RFC 5996 (septembre 2010)


Transmission et authentification des entités Génère le premier Child SA (similaire à IPsec SA)

IKE_AUTH (2 Messages)

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

Thomas Moegli

Données protégées

B

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 INITIATEUR

REPONDEUR

Initiator SPI Responder SPI Next Payload

Major version

Minor version

1er message ๏

Exchange Type

Flags

Message ID

Permet de négocier les paramètres de sécurité de la SA et de communiquer les valeurs de nonces et de DiffieHellman

Longueur Next Payload

C

0

SA Payload (Longueur)

SA Payload (inclut informations Proposal et Tranform) Next Payload

C

0

KE Payload (Longueur)

KE Payload (inclut valeurs publiques DH) Next Payload

IKE_SA_INIT (2 à 4 Messages)

Thomas Moegli

C

0

Nonce Payload (Longueur) Nonce

47

Protocole IKE/IPsec

IKE v2 INITIATEUR

REPONDEUR

Initiator SPI Responder SPI Next Payload

Major version

Minor version

2ème message ๏

Exchange Type

Flags

Message ID

Permet de négocier les paramètres de sécurité de la SA et de communiquer les valeurs de nonces et de DiffieHellman

Longueur Next Payload

C

0

SA Payload (Longueur)

SA Payload (inclut informations Proposal et Tranform) Next Payload

C

0

KE Payload (Longueur)

KE Payload (inclut valeurs publiques DH) Next Payload

IKE_SA_INIT (2 à 4 Messages)

Thomas Moegli

C

0

Nonce Payload (Longueur) Nonce

48

Protocole IKE/IPsec

IKE v2 INITIATEUR

REPONDEUR

Initiator SPI Responder SPI Next Payload

Major version

Minor version

Exchange Type

Flags

Message ID

message

Longueur

๏

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)

Next Payload

C

0

ID Payload (Longueur)

ID Payload (contient Initiator ID) Next Payload

C

0

Auth Payload (Longueur)

Authentication Payload

SK_e, SK_a

3ème

Next Payload

C

0

SA Payload (Longueur)

SA Payload pour le premier CHILD_SA Next Payload

C

0

TS Payload (Longueur)

Traffic Selector Payload

IKE_AUTH (2 Messages)

Next Payload

C

0

TS Payload (Longueur)

Traffic Selector Payload

Thomas Moegli

49

Protocole IKE/IPsec

IKE v2 INITIATEUR

REPONDEUR

Initiator SPI Responder SPI Next Payload

Major version

Minor version

Exchange Type

Flags

Message ID

message

Longueur

๏

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)

Next Payload

C

0

ID Payload (Longueur)

ID Payload (contient Initiator ID) Next Payload

C

0

Auth Payload (Longueur)

Authentication Payload

SK_e, SK_a

4ème

Next Payload

C

0

SA Payload (Longueur)

SA Payload pour le premier CHILD_SA Next Payload

C

0

TS Payload (Longueur)

Traffic Selector Payload

IKE_AUTH (2 Messages)

Next Payload

C

0

TS Payload (Longueur)

Traffic Selector Payload

Thomas Moegli

50

Protocole IKE/IPsec

IKE v2 INITIATEUR

REPONDEUR

Initiator SPI Responder SPI Next Payload

Major version

Minor version

Exchange Type

Flags

Message ID Longueur

message

Next Payload

๏

Permet de générer, si besoin, d’autres Child SA

๏

Echange du matériel d’authentification et identifiants

C

0

SA Payload (Longueur)

SA Payload (inclut informations Proposal et Transform) Next Payload

SK_e, SK_a

5ème

C

0

Nonce Payload (Longueur) Nonce

Next Payload

C

0

TS Payload (Longueur)

Traffic Selector Payload Next Payload

CREATE_CHILD_SA (2 Messages)

Thomas Moegli

C

0

TS Payload (Longueur)

Traffic Selector Payload

51

Protocole IKE/IPsec

IKE v2 INITIATEUR

REPONDEUR

Initiator SPI Responder SPI Next Payload

Major version

Minor version

Exchange Type

Flags

Message ID Longueur

message

Next Payload

๏

Permet de générer, si besoin, d’autres Child SA

๏

Echange du matériel d’authentification et identifiants

C

0

SA Payload (Longueur)

SA Payload (inclut informations Proposal et Transform) Next Payload

SK_e, SK_a

6ème

C

0

Nonce Payload (Longueur) Nonce

Next Payload

C

0

TS Payload (Longueur)

Traffic Selector Payload Next Payload

CREATE_CHILD_SA (2 Messages)

Thomas Moegli

C

0

TS Payload (Longueur)

Traffic Selector Payload

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

๏

๏ Confidentialité

7

Application

๏ Intégrité des données

6

Présentation

๏ Anti-rejeu

5

Session

4

Transport

Utilisation d’un ou plusieurs protocoles pour atteindre ces buts ๏ AH (Authentication Header) ๏ ESP (Encapsulating Security Payload)

3

IPSec

2 Liaison de données 1

Thomas Moegli

Réseau

Physique

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) : Adresse IP Source

Adresse IP Source

Adresse IP Dst

En-tête TCP (Protocole = 6)

Adresse IP Dst

En-tête AH Next Header = 4 (IP)

Nouvelle Adresse IP Source

TCP Payload

Nouvelle Adresse IP Dst

En-tête TCP

TCP Payload

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


Adresse IP Source

Adresse IP Dst

Adresse IP Source

Adresse IP Dst

En-tête TCP (Protocole = 6)

TCP Payload


 
 
 


En-tête AH Next Header = 6 (TCP)

En-tête TCP

TCP Payload

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

Next Header

Description

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

Numéro d’index dans la base SPD 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) : Adresse IP Source

Adresse IP Source

Adresse IP Dst

Adresse IP Dst

En-tête ESP Next Header = 4 (IP)

En-tête TCP (Protocole = 6)

Nouvelle Adresse IP Source

TCP Payload

Nouvelle Adresse IP Dst

En-tête TCP

TCP Payload

En-queue ESP

ICV ESP 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) : Adresse IP Source

Adresse IP Dst

Adresse IP Source

En-tête TCP (Protocole = 6)

Adresse IP Dst

TCP Payload

En-tête ESP Next Header = 6 (TCP)

En-tête TCP

TCP Payload

En-queue ESP

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

Message DPD : R-U-THERE

Aucune donnée reçue

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

A

B

Internet

Chaque voisin définit ses critères DPD Vérification du voisin uniquement si nécessaire

Thomas Moegli

76

Protocole IKE/IPsec

Extensions IKE : Dead Peer Detection (DPD) 8

32

8

8

8

Notify Payload

Length

ISAKMP Header Next Payload

Reserved

DOI = IPsec DOI Protocol ID = ISAKMP

Notify Message Type = R-U-THERE

SPI Size

SPI = CKYi | CKYr Notification Data = Sequence Number

Initiator

R-YOU-THERE

Répondeur

R-YOU-THERE-ACK

8

32

8

8

8

Notify Payload

Length

ISAKMP Header Next Payload

Reserved

DOI = IPsec DOI Protocol ID = ISAKMP

SPI Size

Notify Message Type = 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 (6 Messages)

Aggressive Mode (3 Messages)

Phase 1.5 : XAUTH et/ou Mode Config

Phase 2 : IPsec SA ….

Quick Mode (3 Messages)

A

Thomas Moegli

Données protégées

Phase 2 : IPsec SA

B

Quick Mode (3 Messages)

A

Données protégées

B

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 Username/Password Adresse IP interne

CHAPDNS Serveur

OTPDHCP Serveur

S/Key Attributs optionnels

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 !

[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) Thomas Moegli

83