protocole ike/ipsec

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)


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


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


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


….

DonnéesprotégéesA B Données

protégéesA B

Thomas Moegli


16

Main Mode(4 Premiers Messages)


Authentification Pre-Shared Keys(2 Messages)

Authentification par certificat(2 Messages)

Thomas Moegli

๏ Structure d’un en-tête ISAKMP


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


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)


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


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


21

Initiator Cookie

Responder Cookie

SA Major version


Message ID

Longueur

Next Payload 1 SA Payload (Longueur)

SA Payload (DOI et situation)


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


22

Initiator Cookie

Responder Cookie

Next Payload Major version


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


23

Initiator Cookie

Responder Cookie



Message ID

Longueur

Next Payload 0


KE Payload (inclut la valeur publique DH)

Next Payload 0


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


24



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


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)


26

Initiator Cookie

Responder Cookie



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



๏ Le message est authentifié par un hash appeléHASHr = hash(SKEYID, KE | CKr | CKi | SAi | IDr)


27

Initiator Cookie

Responder Cookie



Message ID

Longueur

Next Payload 0

Hash Payload (Longueur)SKEY

ID_e

Identity Payload

0 0

Hash Payload



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


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


29



Authentification par certificat(2 Messages)

Thomas Moegli

Initiator Cookie

Responder Cookie



Message ID

Longueur

Next Payload 0

Signature Payload (Longueur)

SKEY

ID_e

Identity Payload

Next Payload 0

Signature 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 signéSIGi = PRIVATE_KEYi (HASHi)SIGr = PRIVATE_KEYr (HASHr)


30

Thomas Moegli


31

Aggressive Mode(3 Premiers 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


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


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


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


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



37

๏ Du côté du Responder ๏ Nonce généré : Noncer

๏ Nouvelle valeur DH publique : Xb’

๏ Xb’= gb mod p


Thomas Moegli


REPONDEU

RINITIATE

UR

1er message


๏ Proposition de plusieurs suites de protection


38

Initiator Cookie

Responder Cookie

KE Major version


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


Next Payload 0 Keyload Payload (Longueur)

KE Payload

Next Payload 0

Nonce Payload (Noncei)


Next Payload 0 Identity Payload (Longueur)

ID Type

Identity Payload (IDs)

DOI Specific ID Data


ID Type

Identity Payload (IDd)


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


REPONDEU

RINITIATE

UR

1er message


๏ Proposition de plusieurs suites de protection


39

Thomas Moegli

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

REPONDEU

RINITIATE

UR

Initiator Cookie

Responder Cookie

KE Major version


Message ID

Longueur

…

2ème message


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


40

Thomas Moegli

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

REPONDEU

RINITIATE

UR

2ème message


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


41


SKEY

ID_e

Hash Payload

Next Payload 0

SA Payload (inclut DOI et situation)

Proposal Payload (Longueur)


Next Payload 0

Proposal Payload

Next Payload 0

Transform Payload


Next Payload 0 Keyload Payload (Longueur)

KE Payload

Next Payload 0

Nonce Payload (Noncer)



ID Type

Identity Payload (IDs)



ID Type

Identity Payload (IDd)


Proposal :Responder SPI

KE Payload = Xb’

Thomas Moegli

Initiator Cookie

Responder Cookie

KE Major version


Message ID

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


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


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


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


47

Initiator SPI

Responder SPI



Message ID

Longueur

Next Payload 0


KE Payload (inclut valeurs publiques DH)

Next Payload

SA Payload (inclut informations Proposal et Tranform)



Next Payload

Nonce

C

0C

0C


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


48

Initiator SPI

Responder SPI



Message ID

Longueur

Next Payload 0


KE Payload (inclut valeurs publiques DH)

Next Payload

SA Payload (inclut informations Proposal et Tranform)



Next Payload

Nonce

C

0C

0C


Thomas MoegliREPO

NDEU

RINITIATE

UR


Initiator SPI

Responder SPI



Message ID

Longueur

Next Payload 0

Auth Payload (Longueur)

SK_e, SK_a

Authentication Payload

Next Payload

ID Payload (contient Initiator ID)


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


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)


49

Thomas Moegli


Initiator SPI

Responder SPI



Message ID

Longueur

Next Payload 0

Auth Payload (Longueur)

SK_e, SK_a

Authentication Payload

Next Payload

ID Payload (contient Initiator ID)


ID Payload (Longueur)

Next Payload

SA Payload pour le premier CHILD_SA

C

0C

0C



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


50

Thomas Moegli


5ème message

๏ Permet de générer, si besoin, d’autres Child SA ๏ Echange du matériel d’authentification et identifiants


51REPO

NDEU

RINITIATE

UR

Initiator SPI

Responder SPI



Message ID

Longueur

Next Payload 0


SK_e, SK_a

Nonce

Next Payload

SA Payload (inclut informations Proposal et Transform)

SA Payload (Longueur)C

0C



Next Payload



0C

0C

Thomas Moegli


6ème message

๏ Permet de générer, si besoin, d’autres Child SA ๏ Echange du matériel d’authentification et identifiants


52

Initiator SPI

Responder SPI



Message ID

Longueur

Next Payload 0


SK_e, SK_a

Nonce

Next Payload

SA Payload (inclut informations Proposal et Transform)

SA Payload (Longueur)C

0C



Next 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


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


60



Adresse IP Source Adresse IP Dst En-tête TCP TCP PayloadEn-tête AHNext Header = 6 (TCP)


Thomas Moegli

๏ Structure de l’en-tête 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 :


62


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


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


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


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 :


67


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)


68



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


En-queue ESPICV ESP

Authentification

Partie chiffrée

Thomas Moegli

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


69



Adresse IP Source Adresse IP Dst En-tête TCP TCP PayloadEn-tête ESPNext Header = 6 (TCP)


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


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


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


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


Phase 2 : IPsec SA


….

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

protocole ike/ipsec

Engineering