IPsec
IPsec (Internet Protocol Security), 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
1
sécurité cryptographiques , 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
1
un cadre de standards ouverts . 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
Positionnement protocole IPsec
modèle OSI), ce qui le rend indépendant des applications, et veut
dans le modèle OSI
dire que les utilisateurs n'ont pas besoin de configurer chaque
1
application aux standards IPsec .
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
tunneling).
2
La mise en place d'une architecture sécurisée à base d'IPsec est détaillée dans la RFC 4301 .
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
(ISAKMP (en) pour Internet Security Association and Key Management Protocol).
Le protocole IKE (Internet Key Exchange) 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é (Security association) 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 (Internet Security Association and
Key Management Protocol).
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
3
services simultanément .
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, (Authentication Header) 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
3
modifiée .
le protocole no 50, ESP (Encapsulating Security Payload), 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 payload du paquet
IP) qui sont chiffrées et/ou authentifiées. Le reste Différence mode transport / mode tunnel
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 hash 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 (Host-to-Host).
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
4
par un mécanisme de négociation, tel que Internet Key Exchange (IKE) .
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 : PF_KEY Interface
RFC 2401 (remplacée par la RFC 4301) : Security Architecture for the Internet Protocol
RFC 2402 (remplacée par les RFC 4302 et RFC 4305) : Authentication Header
RFC 2403 : The Use of HMAC-MD5-96 within ESP and AH
RFC 2404 : The Use of HMAC-SHA-1-96 within ESP and AH
RFC 2405 : The ESP DES-CBC Cipher Algorithm With Explicit IV
RFC 2406 (remplacée par les RFC 4303 et RFC 4305) : Encapsulating Security Payload
RFC 2407 (remplacée par la RFC 4306) : IPsec Domain of Interpretation for ISAKMP
(IPsec DoI)
RFC 2408 (remplacée par la RFC 4306) : Internet Security Association and Key
Management Protocol (ISAKMP)
RFC 2409 (remplacée par la RFC 4306) : Internet Key Exchange (IKE)
RFC 2410 : The NULL Encryption Algorithm and Its Use With IPsec
RFC 2411 (remplacée par la RFC 6071) : IP Security Document Roadmap
RFC 2412 : The OAKLEY Key Determination Protocol
RFC 2451 : The ESP CBC-Mode Cipher Algorithms
RFC 2857 : The Use of HMAC-RIPEMD-160-96 within ESP and AH
RFC 3526 : More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key
Exchange (IKE)
RFC 3706 : A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
RFC 3715 : IPsec-Network Address Translation (NAT) Compatibility Requirements
RFC 3947 : Negotiation of NAT-Traversal in the IKE
RFC 3948 : UDP Encapsulation of IPsec ESP Packets
RFC 4106 : The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security
Payload (ESP)
RFC 4301 (remplace la RFC 2401) : Security Architecture for the Internet Protocol
RFC 4302 (remplace la RFC 2402) : IP Authentication Header
RFC 4303 (remplace la RFC 2406) : IP Encapsulating Security Payload (ESP)
RFC 4304 : Extended Sequence Number (ESN) Addendum to IPsec Domain of
Interpretation (DOI) for Internet Security Association and Key Management Protocol
(ISAKMP)
RFC 4305 : Cryptographic Algorithm Implementation Requirements for Encapsulating
Security Payload (ESP) and Authentication Header (AH)
RFC 4306 (remplace les RFC 2407, RFC 2408, et RFC 2409) : Internet Key Exchange
(IKEv2) Protocol
RFC 4307 : Cryptographic Algorithms for Use in the Internet Key Exchange Version 2
(IKEv2)
RFC 4308 : Cryptographic Suites for IPsec
RFC 4309 : Using Advanced Encryption Standard (AES) CCM Mode with IPsec
Encapsulating Security Payload (ESP)
RFC 4478 : Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
RFC 4543 : The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and
AH
RFC 4555 : IKEv2 Mobility and Multihoming Protocol (MOBIKE)
RFC 4621 : Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
RFC 4718 : IKEv2 Clarifications and Implementation Guidelines
RFC 4806 : Online Certificate Status Protocol (OCSP) Extensions to IKEv2
RFC 4809 : Requirements for an IPsec Certificate Management Profile
RFC 4835 (remplace la RFC 4305) : Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC 4945 : The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
RFC 6071 (remplace la RFC 2411) : IP Security (IPsec) and Internet Key Exchange (IKE)
Document Roadmap
Controverse
En décembre 2010, 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
5
clause de confidentialité de 10 ans . Cette pile a été réutilisée dans d'autres projets, bien que largement
modifiée depuis.
Notes et références
1. Dubrawski 2007, p. 83.
2. (en) « Security Architecture for the Internet Protocol ([Link] »,
Request for comments no 4301, décembre 2005
3. Dubrawski 2007, p. 85.
4. (en) « Cryptographic Algorithm Implementation Requirements for Encapsulating Security
Payload (ESP) and Authentication Header (AH) ([Link] », Request
for comments no 4835, avril 2007
5. « Le FBI aurait fait placer des backdoors dans le code de la pile IPSec d'OPENBSD ([Link]
[Link]/mailarchive/openbsd-tech/2010/12/14/6887148) »([Link] ([Link]
b/*/[Link] • Wikiwix ([Link]
[Link] • [Link] ([Link]
larchive/openbsd-tech/2010/12/14/6887148) • Google ([Link]
ttp://[Link]/mailarchive/openbsd-tech/2010/12/14/6887148) • Que faire ?), sur kernel trap ([Link]
[Link]/), 14 décembre 2010
Annexes
Bibliographie
[Dubrawski 2007] (en) Ido
Dubrawski, How to Cheat at Securing Your Network, Burlington,
MA, Syngress, novembre 2007, 432 p., 235 mm × 191 mm × 25 mm (ISBN 978-1-59749-231-7).
Articles connexes
Authentication Header
Encapsulating Security Payload
Ce document provient de « [Link] ».
