IKE v2

mars 14, 2013  |   Blog   |     |   Commentaires fermés sur IKE v2

IPsec (Internet Protocol Security), standard ouvert défini par l’IETF, est un ensemble de protocoles qui permet de sécuriser les communications IP. Il fournit la confidentialité ainsi que l’intégrité des données envoyées et permet l’authentification mutuelle entre les participants de la communication. Ces services sont assurés par le maintien d’un état partagé entre la source et la destination. Cet état défini entre autres les services spécifiques fournis aux paquets, les algorithmes de chiffrement utilisés par ces services et les clés utilisées par ces algorithmes.

La mise en place d’un état partagé manuellement passe difficilement l’échelle. Des protocoles dynamiques sont donc nécessaires. IKEv2 est un de ces protocoles.

Présentation IKEv2

IKEv2 (Internet Key Exchange version 2) établit et maintient de manière dynamique un état partagé entre les participants d’une communication. Ce protocole est une norme de fait défini dans la RFC 5996 (mise à jour de la RFC 4306 qui définit également ce même protocole).

Une association de sécurité (SA, pour Security Association en anglais) contient des attributs de sécurité partagés entre 2 entités d’un réseau afin qu’elles puissent supporter des communications sécurisées. Une SA est unidirectionnelle.

IKEv2 accomplit l’authentification mutuelle entre 2 parties et établit une SA IKEv2. Celle ci contient:

  • un secret partagé qui est utilisé pour établir les SAs IPsec pour ESP et/ou AH
  • une suite d’algorithmes de chiffrement qui sera utilisé par les SAs IPsec pour protéger les données transportées.

 

Fonctionnement IKEv2

Tous les messages IKEv2 fonctionnent par paire: une requête et une réponse. Chaque paire représente un échange.

Pour plus d’informations sur les échanges IKE v2, vous pouvez consulter la RFC 5996 http://tools.ietf.org/html/rfc5996

IKEv2 vs IKEv1

Le format des entêtes IKE des versions 1 et 2 sont différents ce qui rend IKEv2 et IKEv1 non interopérables.

Durée de vie d’une SA

Avec IKEv1, celle-ci est négociée. Avec IKEv2, chaque terminal est responsable de la durée de vie d’une SA: si les règles de l’une définissent une durée de vie (lifetime) inférieure à celle de l’autre, c’est la lifetime la plus courte qui sera à l’origine de la demande de renouvellement de la SA.

Support d’EAP

Avec IKEv1, l’authentification n’était possible que par secret préalablement partagé (PSK, pre-shared key) ou par certificat. IKEv2 inclut en plus le support d’EAP (Extensible Authentication Protocol): cela permet de s’intégrer plus facilement dans le système d’authentification existant dans le réseau.

Besoin en bande passante

IKEv2 réduit les besoins en bande passante en réduisant le nombre de messages lors de la négociation: dans IKEv1, la phase 1 nécessite 8 messages, contre 4 pour la version 2.

Résistance aux attaques DoS

Avec IKEv2, une requête n’est pas traité avant que son émetteur soit authentifier ce qui résout une partie des problèmes de Déni de Service (DoS) dans IKEv1.
Par exemple, dans le cas des attaques DoS où la cible pourrait être floodée de messages d’initialisation de connexion depuis une adresse IP spoofée, le récepteur peut utiliser des cookies de négociation pour se protéger : aucune action ne sera effectuée tant qu’il n’est pas vérifié que l’initiateur de la connexion puisse recevoir les paquets à l’adresse IP indiquée.
La méthode de négociation avec cookie est optionnelle: elle engendre l’utilisation d’échanges supplémentaires ce qui augmente les délais de connexion.

Visibilité sur le trafic IPsec: WESP [RFC5840]

Des labels spécifiques sont ajoutés aux paquets ESP , qui sont authentifiés mais non cryptés, pour faciliter l’analyse des flux par certains outils comme IDS.
L’encapsulation WESP (Wrapped-ESP) utilise le protocole 141 et ajoute un entête entre l’entête IP et l’entête ESP permettant aux nœuds intermédiaires de déterminer si le trafic est chiffré ou pas.

wesp header

Le bit E dans les flags WESP indique si le trafic est crypté ou pas . Si E=1 , le trafic est crypté, si E= 0, ESP est utilisé uniquement pour assurer l’intégrité du paquet.

Support NAT traversal

IKEv2 est conçu pour supporter NAT-T par défaut. Une extension est définie dans IKEv1 pour pour pouvoir le supporter.

Check alive / Dead Peer Detection

Il existe par défaut dans IKEv2 une fonctionnalité permettant de vérifier qu’un tunnel IPsec est toujours up et de le ré-établir si ce n’est plus le cas: cette fonctionnalité se nomme “Dead Peer Detection” (DPD) .

Support SCTP, MOBIKE

Supporté par la version 2 mais pas par la version 1.

Fiabilité et load-balancing

L’utilisation des numéros de séquences et d’acquittements par IKEv2 fournit de la fiabilité supplémentaire non apporté par IKEv1.
Un mécanisme de redirection des requêtes est implémenté dans IKEv2 permettant de distribuer la charge (load-balancing) entre différents nœuds.

Nouvelles CipherSuites

Au niveau des algorithmes de chiffrement, IKEv2 supporte en plus Camelia Counter et Camelia-CCM. Au niveau des algorithmes d’intégrité, IKEv2 supporte en plus MD5 128 bit et SHA1 160 bits

Support de la QoS et sélecteurs de trafic

IKEv2 permet l’existence de SA parallèles avec différents sélecteurs de trafic (plusieurs paires d’IPs, plusieurs ports) entre 2 mêmes terminaux. Ces terminaux peuvent avoir des sélecteurs de trafic différents avec un terminal restreignant le sélecteur de l’autre
IKEv1 ne permet pas d’avoir plus d’une SA avec des sélecteurs de trafic différent. De plus, 2 mêmes terminaux doivent avoir exactement le même sélecteur de trafic.
Sources:

http://tools.ietf.org/html/rfc4306
http://tools.ietf.org/html/rfc5996
http://en.wikipedia.org/wiki/Internet_Key_Exchange
http://www.differencebetween.net/technology/protocols-formats/difference-between-ikev1-and-ikev2/
http://www.vocal.com/secure-communication/internet-key-exchange-v-2/
http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/15-2mt/sec-cfg-ikev2-flex.html#GUID-6548042E-1E4C-416A-8347-00DCF96F04DF
http://wiki.strongswan.org/projects/strongswan/wiki/IKEv1CipherSuites
http://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites
http://www.ietf.org/mail-archive/web/ipsec/current/msg06998.html
http://tools.ietf.org/html/rfc5840#section-2.3

Les commentaires sont fermés.