IPsec
Modèle:À sourcer Modèle:Méta bandeau d'avertissement{{#ifeq:||{{#ifeq:||[[{{#ifexist:Catégorie:Article à vérifier{{#if:informatique|/informatique}}|Catégorie:Article à vérifier{{#if:informatique|/informatique}}|Catégorie:Article à vérifier}}|IPsec]]{{#if:septembre 2016||}}}}|}}
IPsec (Modèle:Lang), défini par l'IETF comme un cadre de standards ouverts pour assurer des communications privées et protégées sur des réseaux IP, par l'utilisation des services de sécurité cryptographiquesModèle:Sfn, est un ensemble de protocoles utilisant des algorithmes permettant le transport de données sécurisées sur un réseau IP. IPsec se différencie des standards de sécurité antérieurs en n'étant pas limité à une seule méthode d'authentification ou d'algorithme et c'est la raison pour laquelle il est considéré comme un cadre de standards ouvertsModèle:Sfn. De plus, IPsec opère à la couche réseau (couche 3 du modèle OSI) contrairement aux standards antérieurs qui opéraient à la couche application (couche 7 du modèle OSI), ce qui le rend indépendant des applications, et veut dire que les utilisateurs n'ont pas besoin de configurer chaque application aux standards IPsecModèle:Sfn.
Présentation
Réalisée dans le but de fonctionner avec le protocole IPv6, la suite de protocoles IPsec a été adaptée pour l'actuel protocole IPv4.
Son objectif est d'authentifier et de chiffrer les données : le flux ne pourra être compréhensible que par le destinataire final (confidentialité) et la modification des données par des intermédiaires ne pourra être possible (Intégrité).
IPsec est souvent un composant de VPN, il est à l'origine de son aspect sécurité (canal sécurisé ou Modèle:Lang).
La mise en place d'une architecture sécurisée à base d'IPsec est détaillée dans la Modèle:RFC.
Fonctionnement
Lors de l'établissement d'une connexion IPsec, plusieurs opérations sont effectuées :
- Échange des clés
- un canal d'échange de clés, sur une connexion UDP depuis et vers le port 500 (Modèle:Lien pour Modèle:Lang).
Le protocole IKE (Modèle:Lang) est chargé de négocier la connexion. Avant qu'une transmission IPsec puisse être possible, IKE est utilisé pour authentifier les deux extrémités d'un tunnel sécurisé en échangeant des clés partagées. Ce protocole permet deux types d'authentifications, PSK (secret prépartagé ou secret partagé) pour la génération de clefs de sessions RSA ou à l'aide de certificats.
Ces deux méthodes se distinguent par le fait que l'utilisation d'un certificat signé par une tierce-partie appelée Autorité de certification (CA) assure l'authentification. Tandis qu'avec l'utilisation de clefs RSA, une partie peut nier être à l'origine des messages envoyés.
IPsec utilise une association de sécurité (Modèle:Lang) pour dicter comment les parties vont faire usage de AH (Authentication header), protocole définissant un format d'en-tête spécifique portant les informations d'authentification, et de l'encapsulation de la charge utile d'un paquet.
- Une association de sécurité (SA) est l'établissement d'information de sécurité partagée entre deux entités de réseau pour soutenir la communication protégée. Une SA peut être établie par une intervention manuelle ou par ISAKMP (Modèle:Lang).
- ISAKMP est défini comme un cadre pour établir, négocier, modifier et supprimer des SA entre deux parties. En centralisant la gestion des SA, ISAKMP réduit la quantité de fonctionnalité reproduite dans chaque protocole de sécurité. ISAKMP réduit également le nombre d'heures exigé par l'installation de communications, en négociant tous les services simultanémentModèle:Sfn.
- Transfert des données
Un ou plusieurs canaux de données par lesquels le trafic du réseau privé est véhiculé, deux protocoles sont possibles :
- le protocole no 51, AH, (Modèle:Lang) fournit l'intégrité et l'authentification. AH authentifie les paquets en les signant, ce qui assure l'intégrité de l'information. Une signature unique est créée pour chaque paquet envoyé et empêche que l'information soit modifiéeModèle:Sfn.
- le protocole no 50, ESP (Modèle:Lang), en plus de l'authentification et l'intégrité, fournit également la confidentialité par l'entremise de la cryptographie.
Modes de fonctionnement
IPsec peut fonctionner dans un mode transport hôte à hôte ou bien dans un mode tunnel réseau.
- Mode transport
Dans le mode transport, ce sont uniquement les données transférées (la partie Modèle:Lang du paquet IP) qui sont chiffrées et/ou authentifiées. Le reste du paquet IP est inchangé et de ce fait le routage des paquets n'est pas modifié. Néanmoins, les adresses IP ne pouvant pas être modifiées par le NAT sans corrompre le Modèle:Lang de l'en-tête AH généré par IPsec, AH ne peut pas être utilisé dans un environnement nécessitant ces modifications d'en-tête. En revanche, il est possible d'avoir recours à l'encapsulation NAT-T pour encapsuler IPSec ESP. Le mode transport est utilisé pour les communications dites hôte à hôte (Modèle:Lang).
- Mode tunnel
En mode tunnel, c'est la totalité du paquet IP qui est chiffré et/ou authentifié. Le paquet est ensuite encapsulé dans un nouveau paquet IP avec un nouvel en-tête IP. Au contraire du mode transport, ce mode supporte donc bien la traversée de NAT quand le protocole ESP est utilisé. Le mode tunnel est utilisé pour créer des réseaux privés virtuels (VPN) permettant la communication de réseau à réseau (c.a.d. entre deux sites distants), d'hôte à réseau (accès à distance d'un utilisateur) ou bien d'hôte à hôte (messagerie privée.)
Algorithmes cryptographiques
Pour que les réalisations d'IPsec interopèrent, elles doivent avoir un ou plusieurs algorithmes de sécurité en commun. Les algorithmes de sécurité utilisés pour une association de sécurité ESP ou AH sont déterminés par un mécanisme de négociation, tel que Internet Key Exchange (IKE)Modèle:RFC.
Les algorithmes de chiffrement et d'authentification pour IPsec encapsulant le protocole ESP et AH sont :
- HMAC-SHA1-96 (RFC 2404)
- AES-CBC (RFC 3602)
- Triple DES-CBC (RFC 2451)
- AES-GCM (RFC 4106)
- ChaCha20 + Poly1305 (RFC 8439)
En référence avec la RFC 8221
Liste des RFC relatives à IPsec
- RFC 2367 : Modèle:Lang
- RFC 2401 (remplacée par la RFC 4301) : Modèle:Lang
- RFC 2402 (remplacée par les RFC 4302 et RFC 4305) : Modèle:Lang
- RFC 2403 : Modèle:Lang
- RFC 2404 : Modèle:Lang
- RFC 2405 : Modèle:Lang
- RFC 2406 (remplacée par les RFC 4303 et RFC 4305) : Modèle:Lang
- RFC 2407 (remplacée par la RFC 4306) : Modèle:Lang
- RFC 2408 (remplacée par la RFC 4306) : Modèle:Lang
- RFC 2409 (remplacée par la RFC 4306) : Modèle:Lang
- RFC 2410 : Modèle:Lang
- RFC 2411 (remplacée par la RFC 6071) : Modèle:Lang
- RFC 2412 : Modèle:Lang
- RFC 2451 : Modèle:Lang
- RFC 2857 : Modèle:Lang
- RFC 3526 : Modèle:Lang
- RFC 3706 : Modèle:Lang
- RFC 3715 : Modèle:Lang
- RFC 3947 : Modèle:Lang
- RFC 3948 : Modèle:Lang
- RFC 4106 : Modèle:Lang
- RFC 4301 (remplace la RFC 2401) : Modèle:Lang
- RFC 4302 (remplace la RFC 2402) : Modèle:Lang
- RFC 4303 (remplace la RFC 2406) : Modèle:Lang
- RFC 4304 : Modèle:Lang
- RFC 4305 : Modèle:Lang
- RFC 4306 (remplace les RFC 2407, RFC 2408, et RFC 2409) : Modèle:Lang
- RFC 4307 : Modèle:Lang
- RFC 4308 : Modèle:Lang
- RFC 4309 : Modèle:Lang
- RFC 4478 : Modèle:Lang
- RFC 4543 : Modèle:Lang
- RFC 4555 : Modèle:Lang
- RFC 4621 : Modèle:Lang
- RFC 4718 : Modèle:Lang
- RFC 4806 : Modèle:Lang
- RFC 4809 : Modèle:Lang
- RFC 4835 (remplace la RFC 4305) : Modèle:Lang
- RFC 4945 : Modèle:Lang
- RFC 6071 (remplace la RFC 2411) : Modèle:Lang
Controverse
En Modèle:Date-, Gregory Perry (ex directeur technique de la société NETSEC) a prétendu dans un mail adressé à l’équipe de développement d’OpenBSD que des portes dérobées auraient été placées dans le framework OCF d'OpenBSD à la demande du FBI dans les années 2000, n'étant plus sous le coup d'une clause de confidentialité de 10 ans<ref>Modèle:Lien brisé</ref>. Cette pile a été réutilisée dans d'autres projets, bien que largement modifiée depuis.