IPSEC / IKEV2

[M02@rt37]

Présentation IPEC:

•  IPSec (IP Security Protocol) a été développé par l'IETF (Internet Engineering Task Force) dans le but de sécuriser TCP/IP au niveau de la couche 3 (couche réseau du modèle OSI)
•  RFC d’origines : « RFC 1825 : Architecture Details » - « RFC 1826 : Authentication Header » – « RFC 1827 : IP Encapsulation Security Payload »
•  Offre des services de sécurité totalement transparents pour les applications

Pourquoi IPSec ?

•  Premier constat sur l’aspect critique de la sécurité sur internet en 1994 (RFC 1636)         
•  Multiplications des attaques de type spoofing (usurpation d’identité) et d’écoute clandestine du contenu du trafic
•  Nécessité de concevoir des mécanismes d’authentification et de chiffrement pour IP

Quelques applications : 

•  Accès distant sécurisé sur internet. Accès sécurisé à un réseau distant (pour bénificier des services offerts par ce réseau)
•  Authenticité des paquets reçus. IPSec peut être utilisé pour assurer l’authentification lors des communications entre les machines concernées
•  Sécuriser une connexion de succursale sur Internet. Établir un réseau privé virtuel sécurisé

IPSEC En détail :

IPSec permet principalement:

•  l’authentification – cette fonctionnalité repose entre autre sur le concept de cookie et est basée sur des clés pré-partagées, adresses IP, noms FQDN, certificats X.509, ...
•  l’intégrité des données – via l’utilisation d’algorithmes de hachage, nous pouvons vérifier que les données n’ont pas été altérées entre le départ et l’arrivée. Cette intégrité repose sur deux types particuliers de fonctions de hachage : les MACs et les HMACs.
•  la non-répudiation – possibilité d’identifier formellement l’émetteur de manière à ce que ce dernier ne puisse nier être l’auteur du message. Cette option repose sur le concept de signature numérique
•  la confidentialité des données – via le cryptage, nous pouvons empêcher qu’un attaquant ne puisse lire nos données,
•  l’anti-rejeu - PFS (protection anti-rejeu).

Eléments principaux dans IPSec

Une famille de protocoles d’échanges de clés:

•  Internet Key Exchange (IKE)

 Deux protocoles de sécurité :

•  Authentication Header (AH) : Conçu pour assurer l’Intégrité et l’authentification des datagrammmes IP sans chiffrement des données (i.e. sans confidentialité)
•  Encapsulated Security Payload (ESP) : Protocole de confidentialité, d’authentification et d’intégrité des données. Le principe d’ESP est de générer un nouveau datagramme dans lequel les données et éventuellement l’en-tête original sont chiffrés
•  

 Deux modes :

•  Mode Transport : chiffrement de la charge utile IP
•  Mode Tunnel : chiffrement de la charge utile et de l’entête IP.

AH - Authentication Header :

•  Protocole pour l’authentification de l’émetteur et le contrôle d’intégrité
•  Essentiellement basé sur des données insérées dans une entête d’extension IP : entête AH code 51
•  RFC de base : RFC 2402 AH
•  AH authentifie et contrôle en intégrité : la totalité de la charge utile et la plus grande partie de l’entête IP.
  •  Permet de résister à l’usurpation d’adresse IP (IP address spoofing) car l’adresse source IP est authentifiée
  •  Permet de résister au rejeu de datagrammes anciens car un numéro de séquence est ajouté et authentifié
•  Utilisation d’un MAC (Message Authentication Codes) : donc nécessité d’une clé secrète partagée par les deux extrémités

Elle n'offre cependant pas de confidentialité,  les données peuvent être lues par une tierce personne car elles ne sont pas cryptées.

ESP – Encapsulation Security Protocol:

Confidentialité d’un datagramme:

•  en confidentialité le numéro de séquence n’est pas chiffré

Authentification/intégrité d’un datagramme:

•  pas d’authentification pour les champs d’entête extérieure
•  Confidentialité du flot de données en mode tunnel
•  Utilisation d’un chiffre à clé secrète (symétrique) et d’un MAC basé sur une clé secrète
•  ESP specifie une entête d’extension et une postface :
  •  Dans l’entête d’extension (code protocole 50): SPI et numéro de séquence

•   RFC de base : RFC 1826 ESP version en cours 2406

Mode Transport:

•  Assure la protection pour les protocoles de la couche transport (information utile d’un paquet IP)
•  ESP chiffre (et optionnellement authentifie) uniquement l’information utile du paquet IP (l’en-tête reste inchangé)
•  AH authentifie l’information utile IP et des parties de l’en-tête IP

Mode tunnel.

•  Assure la protection du paquet IP tout entier
•  Après l’ajout des champs AH ou ESP le paquet entier est traité comme l’information utile du paquet IP externe
•  Une (ou les deux) extrémité de l’AS (association de sécurité) doit être une passerelle de sécurité (firewall, passerelle implémentant IPSec, . . . )

Politique de sécurité :

•  SPD (Security Policy Database)

La RFC_2401 (Security Architecture for the Internet Protocol) décrit le protocole IPsec au niveau le plus élevé. En particulier, elle indique ce qu’une implémentation est censée permettre de configurer en termes de politique de sécurité (c’est-à-dire quels échanges IP doivent être protégés par IPsec et, le cas échéant, quel(s) protocole(s) utiliser). Sur chaque système capable d’utiliser IPsec doit être présente une SPD (security policy database), dont la forme précise est laissée au choix de l’implémentation, et qui permet de préciser la politique de sécurité à appliquer au système. Chaque entrée de cette base de données est identifiée par un SPI (security parameters index) unique (32 bits) choisi arbitrairement. 

La SPD est consultée pendant le traitement de tout datagramme IP, entrant ou sortant, y compris les datagrammes non-IPsec. Pour chaque datagramme, trois comportements sont envisageables : le rejeter, l’accepter sans traitement IPsec, ou appliquer IPsec. Dans le troisième cas, la SPD précise en outre quels traitements IPsec appliquer (ESP, AH, mode tunnel ou transport, quel(s) algorithme(s) de signature et/ou chiffrement utiliser). 

•  SA (Securité Association)

Une communication protégée à l’aide d’IPsec est appelée une SA (security association). Une SA repose sur une unique application de AH ou sur une unique application de ESP. Ceci n’exclut pas l’usage simultané de AH et ESP entre deux systèmes, ou par exemple l’encapsulation des datagrammes AH dans d’autres datagrammes AH, mais plusieurs SA devront alors être activées entre les deux systèmes. En outre, une SA est unidirectionnelle. La protection d’une communication ayant lieu dans les deux sens nécessitera donc l’activation de deux SA.

Les SA actives sont regroupées dans une SAD (security association database). Une SA est associée toute une série d’informations, notamment la clé partagée, l’identité de l’autre partie, le numéro de séquence courant, les services utilisés (intégrité uniquement, confidentialité + intégrité, algorithmes utilisés, etc…).

Une SA est identifiée de manière unique par trois paramètres :

• Security Parameter Index (SPI) : bloc de 32 bits inscrit en clair dans l’en-tête de chaque paquet échangé Il est utilisé pour sélectionner un SA pour traiter les paquets reçus
• IP de destination : peut-être l’adresse d’un routeur, peut être unicast ou multicast
• Security Protocol Identifier : indique si l’association est une AH SA ou un ESP SA

SA IPSec sous CISCO

# sh crypto ipsec sa

local crypto endpt.: 172.16.192.33, remote crypto endpt.: 10.0.0.1
plaintext mtu 1442, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0/1
current outbound spi: 0xAD170B03(2903968515)
PFS (Y/N): N, DH group: none

outbound esp sas:
spi: 0xAD170B03(2903968515)
transform: esp-256-aes esp-sha384-hmac ,
in use settings ={Transport, }
conn id: 2147, flow_id: Onboard VPN:147, sibling_flags 80000000, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4304010/28069)
IV size: 16 bytes
replay detection support: Y

•  Security Association Database (SAD)

Un système qui implémente IPsec conserve une base de données de SAs. Ainsi, pour envoyer un paquet vers une adresse IP X, l’émetteur recherche l’entrée correspondante dans sa base de données pour lui envoyer. Cette entrée fournira toutes les informations pour émettre vers X, à savoir le SPI, la clé, les algorithmes utilisés, le numéro de séquence courant etc… De même, à la réception d’un paquet, le SPI du paquet est utilisé pour trouver l’entrée correspondante dans la base de données des SAs. Le récepteur connaitra donc les paramètres pour décoder le paquet. Les paramètres associés à chaque SA sont les suivants :

•  AH information : IP source/destination, Algorithme d’authentification, clés,…
•  ESP information : IP source/destination, Algorithmes de chiffrement et d’authentification, clés,…
•  Sequence number counter : Utilisé pour générer le numéro de séquence courant
•  Anti-replay window : Utilisé pour détecter une attaque par rejeu
•  Lifetime of the SA : durée de vie du SA. Sequence counter overflow flag : indique ce qu’il faut faire si le numéro de séquence ne correspond pas (en général, fermer la SA)
•  IPsec protocol mode : Mode transport ou mode tunnel
•  Path MTU : MTU pour éviter la fragmentation dans les routeurs internes. Le premier routeur fragmente en paquets de taille MTU prédéfini. Cette MTU doit être assez petite pour éviter la fragmentation dans les routeurs intermédiaires
•  NB : Le MTU est la taille maximale d’un paquet pouvant être transmis en une seule fois (sans fragmentation)

PRESENTATION IKE v2:

•  IKE – Internet Key Exchange
•  IKE (RFC 2407, 2408, 2409, 2412) : protocole de négociation de paramètres de sécurité défini pour IPSEC mais utilisable dans d’autres contextes
•  IKE : un protocole de niveau session
  •  IKE est indépendant de IP
  •  IKE utilise le transport UDP sur le port 500
•  IKE négocie les IPSec associations de sécurité (SAs)
•  Ce processus nécessite que les systèmes IPSec s’authentifient entre eux et établissent les clefs IKE (=ISAKMP) partagées

Pourquoi IKE :

Un des problèmes cruciaux d'utilisation de la cryptographie est la gestion de clés.
Le terme "gestion" recouvre la génération, la distribution, le stockage et la suppression des clefs.
Les SA contiennent tous les paramètres nécessaires à IPsec, notamment les clés utilisées.

Comment se mettre d’accord sur les paramètres à utiliser pour les SA ?

Deux solutions :

•  Configuration manuelle : l’administrateur définit le contenu de la SA, y compris les clés
•  Négociation dynamique des SA et notamment l'échange des clés de session, au moyen d’un protocole spécifique (par exemple IKE)

IKEv2 en DETAIL :

IKE = Schéma de chiffrement ⇔ comment va se faire l’échange des informations entre les différents peers d’un VPN.

Pour réaliser ses services, IKE combine des éléments issus de protocoles différents.

•  ISAKMP : Internet Security Association and Key Management Protocol (RFC 2408) => la vision générique. Protocole pour la négociation préalable à l’établissement des associations de sécurité.
•  OAKLEY : Oakley Key Determination Protocol (RFC 2412) => une réalisation de ISAKMP (autres versions SKIP, Photuris, SKEME). Détermine le mécanisme pour l’échange automatique des clefs, le partage, de façon sûre entre les tiers, d'un ensemble d'informations relatives au chiffrement
•  DOI : IPSec Domain of Interpretation (RFC 2407) => pour interpréter le contenu des messages ISAKMP.

Objectifs généraux d’IKE

•  Protocole pour la négociation
  •  Des caractéristiques de sécurité
  •  Des paramètres des protocoles de sécurité
•  Protocole d’authentification des entités communicantes
  •  Les identités restent cachées
•  Protocole de génération et d’échange de clés secrètes de façon sécuritaire

•  IKE => la gestion dynamique des associations de sécurité : création, modification, destruction (vs manuelle)
•  Les attaques prises en compte
  •  Déni de service
  •  Rejeu
  •  Attaque du milieu (man in the middle)
  •  Secret parfait des clés (PFS Perfect Forward Secrecy) : des clés utilisées antérieurement ou postérieurement par le protocole ne peuvent être dérivées de la clé en cours d’utilisation (Diffie-Hellman)
•  IKE démarre avant IPSec:
  •  On a un tunnel IKE en premier
  •  Et un tunnel IPSec ensuite

ISAKMP : Internet Security Association and Key Management

•   ISAKMP : un cadre générique pour la négociation et l’échange de clés.
  •  Ce n’est pas un protocole concret c’est une manière de procéder
•  Deux phases successives :
•  Phase 1 : Négociation pour la phase 1, Echange de clés et authentification (ensemble d'attributs relatifs à la sécurité) – SA ISAKMP
  •  Négociation de l’association de sécurité utilisée pour les propres besoins de l’échange de clé (fonctions cryptographiques et protocoles utilisés par IKE)
  •  Echange de clé secrète (le plus souvent par le protocole de Diffie- Hellman mais aussi d’autres possibilités).
  •  Une session ISAKMP est authentifiée :

       - soit par une clef partagée (pre-shared key)

       - soit par RSA signature et chiffrement

  •  Phase 2 : Négociation des associations de sécurité – SA IPSec

  •  SA à établir pour le compte d'un mécanisme de sécurité donné (par exemple AH ou ESP)
  •  Échanges de cette phase sont sécurisés (confidentialité,authenticité...) grâce à la SA ISAKMP

IKE s’appuyant sur ISAKMP, les phases sont similaires:

•  Phase 1 d’IKE
  •  Il y a authentification des peers + établissement de la politique IKE (= IKE SA). L’algorithme principal de cette phase est Diffie-Hellman

•  Phase 2 d’IKE
  •  Il y a négociation des SA IPSec, et génération des clefs pour IPSec, L’émetteur offre une ou plusieurs transform-sets qui sont utilisés pour spécifier les différents algorithmes utilisés au sein du tunnel IPSec
  •  En d’autres termes, une SA IPSec c’est ce qui définit un VPN

Bilan des composants IPSec:

•  AH et ESP = mécanismes de sécurisation au niveau IP qui protègent les données transférées.
•  Les paramètres relatifs à ces mécanismes sont stockés dans des associations de sécurité (SA)
•  IKE = protocole utilisé par les équipements IPSec pour gérer les associations de sécurité.
•  Un ensemble de Politiques de sécurité qui sont des règles à appliquer au trafic traversant un équipement donné. C’est par elles que l’administrateur du réseau configure IPsec et notamment indique à IKE quels sont les tunnels sécurisés à créer.

Configuration IKEV2/IPSEC CISCO