Introduction à IPSec

—— EN COURS ——-

Introduction

Ce document est une introduction généraliste au protocole IPSec. Il s'agit en grande partie d'une traduction française du très bon article de Peter MATULIS : http://www.papamike.ca/tutorials/pub/obsd_ipsec.html

Généralités

Le protocole IPSec est composé de deux sous-protocoles :

  • ESP : IP Encapsulating Security Payload, RFC 4303)
  • AH : IP Authentication Header, RFC 4302)

Il en existe un troisième qui peut s'avérer utile dans certaines configurations : IPComp (IP Payload Compression Protocol, RFC 3173). Comme son nom le suggère, il est utilisé pour réduire la taille des datagrammes IP grâce aux techniques de compression. Il permet d'augmenter le rendement protocolaire entre deux entités (station, ou réseau). IPComp est intéressant dans le cas de liaison bas débit, et si les deux entités ont assez de puissance cpu.

Les fonctions d'IPSec

Le protocole IPSec fournit les fonctions suivants :

  • confidentialité : seul le récepteur prévu doit comprendre les données (protocole ESP)
  • intégrité : les données ne doivent pas pouvoir être changées en cours de route (protocole ESP et AH)
  • authentification : les données viennent d'un expéditeur connu (protocole ESP et AH)
  • anti-rejoue : les données peuvent être lues une seule fois. Cette fonction est considérée par certains comme une forme d'intégrité (protocole ESP et AH)

Toutes ces fonctions manquent à IPv4, c'est pourquoi IPSec est utilisé. IPv6, en revanche, intègre IPSec nativement.

L'énoncé précédent souligne que différentes fonctions sont présentes à la fois dans les protocoles ESP et AH. C'est le signe qu'IPSec est complexe, donc potentiellement dangereux ! A ce sujet, N.Ferguson est B. Schneier ont écrit un article, disponible à l'adresse : http://www.schneier.com/paper-ipsec.html.

L'exigence de la confidentialité, qui implique un chiffrage PKE/PKI quand elle est utilisée avec un mécanisme de clés automatique, rend nécessaire l'utilisation d'un protocole suplémentaire d'échange de clés. Le plus communément utilisé est le protocole IKE (Internet Key Exchange, RFC 2409). Le protocole IKE lui-même coopère avec le protocole ISAKMP (Iternet Security Association and Key Managment Protocol, RFC 2408). ISAKMP fournit un cadre pour l'échange de clés et l'authentification, mais ne les définis pas. Il requière un autre protocole pour l'échange de clés et c'est généralement un mixe entre l'Oalkey Key Determination Protocol (RFC 2412) et le Versatile Secure Key Exchange Mecanism for Internet (SKEME).

Pour palier à ce gigantesque empilement, il existe certaines alternatives à IKE : IKEv2 (RFC 4306) et JFK (Just Fast Keying, encore à l'état de draft, http://www3.ietf.org/proceedings/02mar/I-D/draft-ietf-ipsec-jfk-01.txt).

De nos jours, le protocole AH n'est presque plus utilisé. Bien qu'il soit possible de combiner les protocoles ESP et AH, en général les configurations déployées utilisent ESP à la fois pour la confidentialité et l'intégrité (qui inclue l'autentification et l'anti-rejoue). De plus, l'authentification d'ESP est concidérée comme plus performante que celle d'AH. Enfin, AH est incompatible avec les mécanismes (très répandus) de translation d'adresses (Network Address Translation, NAT).

Les associations de sécurités (SA)

Les fonctions d'IPSec sont configurées et placées dans ce que l'on appelle des Associations de Sécurité (Security Associations, SA). Un SA est défini par protocole (ESP, AH) et seulement pour un flux uni-directionnel de données. Ainsi, chaque entité communiquante doit posséder deux SA par protocole utilisé, chacun de ces SA est identifiable par un triplet :

  • adresse IP destination
  • un nombre arbitraire compris entre 0×100 et 0xffffff), appelé le Security Parameter Index
  • le numéro du protocole (50 pour ESP, 51 pour AH)

Ainsi, une entité IPSec qui communique avec de nombreuses autres entités (par exemple une passerelle IPsec dans un réseau de sites distants, avec des utilisateurs nomades) possède de multiples SA. Ces SA sont contenus dans la Base des Associations de Sécurité (Security Association Database, SAD). Dans cette base, chaque entrée est dédiée à un SA. Beaucoup d'informations sont stockées par SA. Les trois éléments cités plus haut permettent d'identifier clairement un SA.

Dans le cas d'un échange de clé automatique, un autre SA (celui-ci bi-directionnel) est configuré pour l'authentification des entités et le mécanisme d'échange des clés.

Mode transport et mode tunnel

IPSec peut fonctionner en mode tunnel ou en mode transport. Le mode tunnel est la configuration la plus répandue. Elle est mise en oeuvre à chaque fois qu'un réseau est impliqué dans la transmission. Un tunnel est un lien point à point bi-directionnel entre deux entitées. Le mode transport est utilisé quand deux stations veulent communiquer. Un SA (Security Association) contient les informations nécessaires pour identifier s'il s'agit d'une communication en mode tunnel ou transport. Pour le mode tunnel il contient en plus, les valeurs à intégrer aux en-têtes des datagrammes IP sortants.

IPsec est capable de déterminer seul le mode à utiliser, il n'est donc pas nécessaire de le spécifier. En revanche, il est possible de forcer l'utilisation du mode tunnel. Cela permet d'augmenter la sécurité de la communication dans certaines situations.

IPsec processing and the SPD

Naturally, traffic requires processing somewhere along the line. All traffic is brought under the scrutiny of the Security Policy Database (SPD). The SPD can be thought of as a packet filter whose entries utilize three keywords: DISCARD, BYPASS, PROTECT. RFC 4301 informs us:

An SPD must discriminate among traffic that is afforded IPsec protection and traffic that is allowed to bypass IPsec. This applies to the IPsec protection to be applied by a sender and to the IPsec protection that must be present at the receiver. For any outbound or inbound datagram, three processing choices are possible: DISCARD, BYPASS IPsec, or PROTECT using IPsec. The first choice refers to traffic that is not allowed to traverse the IPsec boundary (in the specified direction). The second choice refers to traffic that is allowed to cross the IPsec boundary without IPsec protection. The third choice refers to traffic that is afforded IPsec protection, and for such traffic the SPD must specify the security protocols to be employed, their mode, security service options, and the cryptographic algorithms to be used.

Regarding the connection between an SA and the SPD, again, RFC 4301 enlightens us :

An SA is a management construct used to enforce security policy for traffic crossing the IPsec boundary. Thus, an essential element of SA processing is an underlying Security Policy Database (SPD) that specifies what services are to be offered to IP datagrams and in what fashion. […] The SPD, or relevant caches, must be consulted during the processing of all traffic (inbound and outbound), including traffic not protected by IPsec, that traverses the IPsec boundary. This includes IPsec management traffic such as IKE.

So the SPD needs to know what sort of traffic is allowed so it can make decisions when it detects movement in its domain (when packets cross the IPsec boundary). Legitimate IPsec traffic must be configured either manually or automatically using a keying method (see below). The result of said configuration is a collection of IPsec flows.

Gestion des clés

Pour chaque flux de commnunication, les données peuvent être échangées quand les deux entités de dialogue partagent le même SA. C'est déterminé en utlisant l'une des deux méthode suivante :

  • manuelle (encryption symétrique)
  • automatisée (encryption asymmetrique)

Dans l'échange de clés manuel, la protection anti-rejoue n'est pas assurée par le protocole. Elle peut, ou non, être disponible. De plus, quand elle est disponible, la protection anti-rejoue est utilisée à la discrétion du destinataire. Il n'y a pas de négociation client-serveur.

La RFC 4301 fournit les directives pour utiliser une gestion des clés manuelle et automatique. Voici certains extraits :

Manual Techniques The simplest form of management is manual management, in which a person manually configures each system with keying material and SA management data relevant to secure communication with other systems. Manual techniques are practical in small, static environments but they do not scale well. […] If the number of sites is small, and since all the sites come under the purview of a single administrative domain, this might be a feasible context for manual management techniques. In this case, the security gateway might selectively protect traffic to and from other sites within the organization using a manually configured key, while not protecting traffic for other destinations. It also might be appropriate when only selected communications need to be secured. […] Manual management techniques often employ statically configured, symmetric keys, though other options also exist.

Automated SA and Key Management Widespread deployment and use of IPsec requires an Internet-standard, scalable, automated, SA management protocol. Such support is required to facilitate use of the anti-replay features of AH and ESP, and to accommodate on-demand creation of SAs, e.g., for user- and session-oriented keying. (Note that the notion of “rekeying” an SA actually implies creation of a new SA with a new SPI, a process that generally implies use of an automated SA/key management protocol.)

Le protocole de gestion des SA, tel que l'IKE pour la gestion automatique des clés, est connecté au SPD via la Peer Authorization Database (PAD). La PAD aide à mettre en application les fonctions essentielles suivantes :

  • indentifier le pair, ou le groupe de pairs, qui sont autorisés à communiquer avec l'entité IPSec locale.
  • spécifer le protocole et la méthode utilisée pour authentifier chaque pair
  • fournir les données d'authentification pour chaque pair
  • contraindre les types et les valeurs d'identifications qui peuvent être affirmées par un pair lors de la création d'un SA fils
  • l'information de localisation de la passerelle du pair peut être inclue pour les pairs qui sont situés derrière un firewall.

Un des paramètre important du SA quand on utilise une gestion de clé automatique est le durée de vie des clés. Elle fixe la limite pendant laquelle une clé (et son SA associé) est concidérée comme valide. Cette limite peut être exprimée en temps ou en volume de données échangées.

Résumé

IPSec fournit un moyen de n'autoriser que le destinataire voulu à recevoir l'information originale. Dans la majorité des cas on utilise le protocole ESP coordonné aux Security Associations (SAs). Un SA, qui est stocké dans la Security Association Database (SADB) et identifié uniquement par son Security Parameters Index (SPI), est utilisé quand le trafic satisfait les paramètres donnés dans le flow IPSec. Cette inspection implique la consultation de la Security Policy Database (SPD) qui va déterminer la bonne action à entreprendre. Deux pairs IPSec ne peuvent communiquer que s'ils possèdent chacun des SAs identiques. Cette détermination est basée sur la méthode de gestion de clés utilisée : manuelle ou automatique. Dans le premier cas, les SAs et les flows sont pré-construit, tandis que dans le second, ils sont créés dynamiquement par le serveur de gestion de clés qui communique avec IPSec via la Peer Authorization Database (PAD).

Structure des paquets IPSec

IPsec packet architecture differences in transport and tunnel modes

The Authentication Header (AH)

The Encapsulating Security Payload (ESP)

Introduction à l'échange automatique de clés

Liens

 
doc/unix/ipsec.txt · Dernière modification: 2009/12/23 22:36 (édition externe)     Haut de page