Négociation

Introduction

Jusqu’ici nous avons vu les différentes méthodes pour transporter les données et abordé très brièvement les algorithmes mises en jeux (DES, md5 etc …) sans parler des durées de vies …

Tout ça c’est bien beau sur le papier mais on se doute bien que ça ne fonctionne pas par magie. Pour pouvoir parler, il faut s’entendre sur la langue … pour IPsec c’est la même chose.

Le but étant donc de négocier, les algorithmes de chiffrement, d’authentification, les durées de vie. Sans parler de l’authentification en elle même.

Une dernière chose … et pour cela il faut se remettre dans le contexte de IPSEC.

Le but est contruire comme communication sécurisé à travers Internet … Un réseau pollué ou les plus méchants des pas beaux sont prêts à tout pour intercepter vos données …

Bon c’est un peu démesuré mais il y a du vrai.

Donc le but est bien d’établir cette communication de manière sécurisé. Nous savons pour chiffrer ces données, nous utilisons des algorithmes de chiffrement symétriques (utilisant la même clef pour chiffrer et déchiffrer les données). Sans parler de l’authentification.

Voici ce que ça implique :

Faire transiter la clef de chiffrement de manière sécurisé
Jouer l’authentification de manière sécurisé
Sécurisé la négociation du canal sécurisé

A tout cela, nous avons donc :

IKE (Internet Key Exchange) : Protocole de niveau 6 transporté par UDP (port 500). Il est basé sur le standart ISAKMP.

Sa fonction est association de sécurité (SA :security association) comprenant les algorithmes (de chiffrement, de hash ainsi que la puissance de chiffrement), les durées de vies ainsi que l’authentification

Deux phases. La phase 1 appelé “ike” et la phase appelé “phase 2″ … Cette dernière assurant la négociation du tunnel chiffré. La phase 1 servant à protégé la négociation de phase 2.

Phase 1 “IKE”

Pour facilité les choses … Cette phase à deux modes :

Main Mode
Agressive mode

Main mode

Explication :

les deux premiers échanges permettent de sélectionner les algorithmes (de chiffrement et de résumé), les durées de vie de la clef de chiffrement ainsi que la méthode d’authentification.
Les deux suivants vont permettre d’avoir la même clef de chiffrement sans jamais la faire transiter (ni en clair, ni chiffré). C’est une méthode mathématique appelé Diffie-Hellman. Le but ici n’est pas d’expliquer cette méthode mais si cela vous intéresse, je vous invite à suivre ce lien “http://fr.wikipedia.org/wiki/Échange_de_clés_Diffie-Hellman”
Les deux derniers échanges sont pour là pour authentifier les deux parties. Nous verrons cela un peu plus en détails

Avantage :

Permet de protégé l’authentification. En effet, les quatre premiers échanges nous ont permis de négocier une politique de chiffrement ainsi que d’une clef de chiffrement. Cela va nous permettre de chiffrer l’authentification. Un pirate pourra toujours faire les quatre premiers échanges mais ne pourra pas rejouer l’authentification.

Inconvénient :

Peut-être un peu long. Nous avons tout de même six échanges contre trois en agressive mode.

Utilisé :

Utilisé dans les connexion site à site. Ce mode ne peut-être utilisé qu’avez un type d’identité de type “adresse IP” qui correspond à l’adresse réel (et routable)

Agressive mode

Explication :

Ici, nous avons deux échanges qui vont recouper les cinq premiers échanges du main mode. Nous allons donc choisir la politique de chiffrement, envoyé les nombres aléatoires (pour la clef). Vous remarquerez que contrairement au main mode, c’est le correspondant qui va initier l’authentification.

Avantage :

Rapidité de l’échange. tous types d’identité.

Inconvénient

Authentification non chiffré. ATTENTION : Cela ne veut pas dire qu’elle sera en claire mais qu’elle sera susceptible d’être rejoué.

Utilisé

Principalement les clients VPN. Le contexte client/serveur implique le plus souvent que le client soit un nomade (son adresse IP va changer en fonction de sa localisation). Il en découle qu’il n’est pas possible d’utilisé l’identité de type “adresse IP” puisqu’elle se base sur l’adresse réel … Ce qui n’est pas possible (nous ne pouvons envisager de changer l’identité à chaque déplacement du nomade)

Authentification

C’est la partie un peu “chaude” d’IPsec. Si il est vraiment que IKE supporte pas moins de huit types d’authentification, en pratique nous en utilisons peut-être que deux …

Voici les huits (source IETF):

Pre-shared key (secret partagé)
Signature RSA (certificat X.509)
Signature DSS
Chiffrement avec RSA
Revised encryptation with RSA
chiffrement avec El-Gamal
Revised encryptation with El-Gamal
Signature ECDSA

Nous utilisons le plus souvent le secret partagé (en fixe ou avec un secure ID) et le certificat X.509 (en PKCS12 ou via un token usb)

Le certificat X.509 repose sur RSA avec une architecture clef publique / privé. L’authentification est en général à double sens. Il fonctionne de la même manière que SSL. Cela nécessite une Authorité de Certification (PKI).

Pour le mode PSK (secret partagé), c’est le principe de signature digitale. Le paquet IKE qui va servir à l’authentification sera haché, signé par la PSK et concaténé au paquet.

Pour info, l’authentification des paquets ESP et AH fonctionnera de la même manière à la différence que le haché sera signé par une clef temporaire (négocié en phase 2)

Phase 2

La phase va nous servir à monter nos deux tunnels IPsec. Deux tunnels car une connexion représente deux tunnels (ou deux SA de phase 2) … Un pour le trafic entrant et l’autre pour le trafic sortant.

Concernant le fonctionnement, il est globalement le même que la phase 1 à ceci prêt :

La clef de chiffrement sera dérivé de celle de phase 1
Pas d’authentification.

Néanmoins, la méthode appelé PFS (Perfect Forward Secrecy) permet de générer de nouvelles clefs de chiffrement en lançant à nouveau l’algorithme de Diffie-Hellman.

Il n’existe qu’un seul mode de phase 2 appelé Quick Mode.

Association de sécurité (SA)

Un petit point pour ceux qui serait un peu perdu.

Une SA contient est une entrée dans la SAD (Security Association Database). Chaque SA est indentifié par sa SPI (Security Protection Index).

Voici la structure de la SAD :

  -SPI
  -Protocole IPSEC
  -Fenêtre d'anti-rejeu
  -Algorithme d'intégrité AH
  -Algorithme de chiffrement ESP
  -Algorithme d'intégrité d'ESP
  -Algorithme ESP mode combiné
  -Durée de vie de la SA
  -Mode IPSEC (transport / Tunnel)
  -Adresse IP source et destination en mode Tunnel.

  -Pointeur dans la base SPD

La SPD (Security Policy Database) est en quelques sortes un filtrage par paquet qui va décider quel est l’action à réaliser sur tous les paquets envoyés et reçus.

Voici la structure de la SPD

  -Adresse Local (du réseau local)
  -Adresse distante (du réseau local distant)
  -Protcole transporté
  -Port Source (TCP / UDP) , type de message ICMP /code
  -Port Destination, type de message ICMP /code

Et voici les actions

  -PROTECT (envoi dans le module de chiffrement)
  -BYPASS  (Ne fait rien) 
  -Discard (supprime le paquet)

Mais comment ça communique tout ça et pourquoi un paquets doit partir ou pas dans le module IPSEC.

Chaque paquet sortant sera confronté à la SPD. La SPD en fonction des couples IP source/destination et ports source/destination réalisera une action spécifique. Si un paquet doit être envoyé à IPSEC, il consultera la base SAD. Si une SA active correspondante existe, le paquet sera directement transmis. Si aucune SA active n’est trouvée, il initiera la négociation pour créer une SA.

Chaque paquet entrant est confronté à la SAD. Si le triplet IP destination / SPI / Protocole (esp / ah) est trouvé dans la SAD (active ou non active), le paquet sera alors envoyé dans la SPD à l’aide du pointeur dans la SAD. A noté que tous les paquets IP sont confrontés à cette base à l’exception de IKE et ESP/AH (qui seront confronté à la SAD).

Négociation

Pages

Blogoliste