Latest revision as of 14:26, 13 February 2006

Association de sécurité

Table des matières

Extension de confidentialité ESP

L'extension d'authentification (AH : Authentication Header) décrite dans le RFC 2402 permet de s'assurer que l'émetteur du message est bien celui qu'il prétend être. Elle sert aussi au contrôle d'intégrité pour garantir au récepteur que personne n'a modifié le contenu d'un message lors de son transfert sur le réseau. Elle peut optionnellement être utilisée pour détecter les rejeux.

Le principe de l'authentification est relativement simple. L'émetteur calcule un authentificateur sur un datagramme et l'émet avec le datagramme sur lequel il porte. Le récepteur récupère cette valeur et vérifie qu'elle est correcte. C'est-à-dire, si un MAC est utilisé, il lui suffit de calculer de son côté le MAC sur le même datagramme à l'aide de la clé symétrique partagée et de le comparer avec le MAC reçu. Si le mécanisme de signature numérique est employé, le récepteur doit alors récupérer la signature, la déchiffrer avec la clé publique de l'émetteur et comparer le condensat ainsi obtenu avec celui calculé de son côté sur le datagramme reçu. Si les deux MAC, ou les deux condensats diffèrent, soit l'émetteur ne possède pas la bonne clé, soit le message a subi des modifications en chemin.

Positionnement de l'extension AH

Le positionnement de l'extension AH dans les datagrammes IP est étudié ici, avec l'étendue de la protection assurée dans les modes transport et tunnel.

• L'extension AH en mode transport permet entre autres de rendre le service d'intégrité sur les paquets IP. En fait, l'intégrité du paquet n'est assurée que pour les données de niveau transport et les champs -- en-tête du paquet et extensions -- qui ne sont pas amenés à subir de modifications de la part du réseau lors de leur transfert. L'extension AH doit être placée après l'en-tête IPv6, les extensions proche-en-proche, routage, fragmentation et avant les données de niveau transport, comme le montre la figure Positionnement de l'extension AH en modes transport et tunnel. Seule l'extension destination peut être introduite avant ou après l'extension AH.

• Le mode tunnel consiste à encapsuler le paquet IP original constitué d'un en-tête original et du champ données dans un nouveau paquet IP, dont les adresses source et destination sont celles des équipements mettant en oeuvre IPsec. L'extension AH permet alors de protéger en intégrité/authentification/détection de rejeu la totalité du paquet IP original et la partie du nouvel en-tête/extensions du paquet IP qui n'est pas amenée à subir de modifications en cours de transit. Il est placé après les extensions propres au nouveau paquet IP formé (cf. figure Positionnement de l'extension AH en modes transport et tunnel).

Contenu de l'extension AH

L'extension AH est composée des champs suivants (cf. figure Format de l'extension d'authentification AH) :

File:CS130.gif

• Le champ longueur de l'extension indique la longueur du champ authentificateur exprimée en nombre de mots de 32 bits.
• Le champ réservé est réservé pour une utilisation future et est mis à 0 à l'émission.
• Le champ indice des paramètres de sécurité (SPI) combiné à l'adresse du (des) destinataire(s) et du protocole IPsec (AH ou ESP), identifie l'association de sécurité utilisée pour construire cette extension.
• Le numéro de séquence sur 32 bits permet de détecter les rejeux de paquet IP.
• Le champ authentificateur garantit l'intégrité du paquet ; il est calculé sur le datagramme IP à l'aide de l'algorithme et de la clé correspondant à l'association de sécurité (SPI + adresse(s) de destination + AH). C'est également l'association de sécurité qui précise la taille de ce champ.

L'extension AH n'offre pas le service de confidentialité. Elle ne permet pas de chiffrer les données transportées dans le paquet et ne protège donc pas ces données contre d'éventuelles écoutes effectuées sur le réseau.

La détection de rejeu est optionnelle du fait que l'équipement de sécurité qui produit l'extension AH doit remplir le champ numéro de séquence correctement tandis que l'équipement qui extrait l'extension n'est pas tenu de vérifier la bonne valeur de ce champ. La détection consiste en un numéro de séquence incrémenté à chaque paquet. Le récepteur peut vérifier sa croissante stricte ou mieux, gérer une fenêtre en rejetant tous les paquets avec un numéro de séquence déjà reçu. L'association de sécurité doit être renégociée quand le numéro de séquence atteint la valeur maximale. Une détection de rejeu n'est donc possible que si le récepteur est doté d'un module de gestion des associations de sécurité IKE qui renégociera automatiquement une association de sécurité le moment venu.

Les algorithmes utilisés pour le calcul de l'authentificateur doivent être particulièrement robustes. L'IETF fait la distinction entre les communications point-à-point et point-à- multipoint et propose, pour protéger les communications point-à-point, que les équipements de sécurité disposent au moins du MAC (Message Authentication Code) basé sur des algorithmes symétriques (par exemple DES) et des fonctions de hachage (RFC 2403, RFC 2404) du type MD5 (Message Digest 5) ou SHA-1 (Secure Hash Standard). On parle alors des algorithmes HMAC-MD5 et HMAC-SHA-1. Noter que la préférence est donnée à l'algorithme HMAC-SHA1 car SHA-1 fournit un résultat sur 20 octets (contre 16 octets pour MD5) et de ce fait rend plus difficile l'attaque visant à partir d'un condensat à trouver une chaîne binaire satisfaisante. Pour la protection des communications point-à-multipoint, l'IETF préconise l'usage de fonctions de hachage combinées à des algorithmes asymétriques, ceci pour échapper au difficile problème de gestion des clés de groupe (symétriques).

Pour générer l'extension AH, un équipement de sécurité calcule un authentificateur sur un datagramme sous la forme qu'il aurait à la réception finale (une extension de routage aura donc les adresses dans un ordre particulier) avec tous les champs pouvant changer en chemin mis à zéro (c'est-à-dire les champs classe, identificateur de flux, et nombre de sauts). Le champ authentificateur est également mis à zéro pour ce calcul. La vérification se fait par le même procédé.

Du fait que les champs considérés comme "non modifiables" par le schéma d'authentification n'incluent pas les adresses IP, la traduction d'adresses (NAT : Network Address Translator) et l'utilisation de l'extension AH ne sont pas toujours exploitables simultanément, en particulier lorsque les équipements IPsec communiquent au travers d'un traducteur d'adresses. En effet, l'authentificateur est calculé sur les adresses IP des paquets. Comme le traducteur d'adresses modifie l'adresse source ou destination des paquets IP, l'authentificateur reçu par l'un ou l'autre des équipements IPsec sera toujours invalide et le paquet sera tout le temps rejeté. Une architecture avec deux équipements IPsec de part et d'autre d'un traducteur d'adresses est courante aujourd'hui. Typiquement, il peut s'agir d'un nomade IPsec qui se connecte depuis un aéroport équipé d'un NAT à son réseau d'entreprise via un VPN IPsec.

Face à ce problème d'incompatibilité avec le NAT et à l'impossibilité de faire du chiffrement de contenu avec AH, les entreprises bien souvent préfèrent configurer leurs équipements IPsec avec l'extension ESP. Ainsi l'extension AH se trouve confiner à certains usages particuliers comme la protection des messages de découverte de routeurs (router advertisement).

Évolutions prévues

Dans sa prochaine version du [RFC2402bis], l'extension AH distingue l'identification qui doit être faite d'une association de sécurité suivant qu'elle est d'usage unicast ou multicast. Contrairement au RFC 2402, une association de sécurité unicast peut être identifiée par la seule valeur du SPI ou bien par le couple : SPI et protocole IPsec. Quant à l'association de sécurité multicast, elle est identifiée par la valeur du SPI, l'adresse de destination et optionnellement l'adresse source.

Pour les communications à très haut-débits, un numéro de séquence de 32 bits peut s'avérer insuffisant car un cycle sur ce numéro de séquence peut être atteint rapidement. Pour exemple, au débit de 1Gb/s nécessiterait qu'une nouvelle association de sécurité soit négociée toutes les heures. Pour éviter un renouvellement fréquent d'associations de sécurité, il a été décidé dans la prochaine version de AH d'avoir la possibilité d'avoir un numéro de séquence sur 64 bits au lieu de 32. Noter que la taille du numéro de séquence est négociée sous la forme d'une extension de numéro de séquence (ESN : Extended Sequence Number) grâce au protocole de gestion des associations de sécurité. Noter qu'astucieusement, la taille du numéro de cette extension ESN n'a aucun impact sur le format de l'extension AH. En effet, dans le cas de la sélection de ESN, seuls les 32 bits de poids faible sont transmis dans l'extension AH ; les 32 bits de poids fort sont en effet maintenus de part et d'autre sur les équipements IPsec comme compteur local et servent au calcul de l'authentificateur.

Association de sécurité

Table des matières

Extension de confidentialité ESP