3.1.3 La gestion de clés : IKEv2
IKE (Internet Key Exchange) est un protocole qui
permet, lorsque deux noeuds souhaitent communiquer entre eux via un canal
IPsec, l'authentification et la négociation du matériel
cryptographique en accord avec les SP respectives, pour enfin la mise en place
des SA. Il est implémenté sous la forme d'un démon. La
spécification de IKEv2 [4] synthétise les différentes
fonctionnalités de IKEv1 (documenté dans plusieurs RFCs) ainsi
que des fonctionnalités introduites par les diverses
implémentations de IKEv1 (comme par exemple les extensions permettant
l'utilisation d'IPsec à travers les réseau NAT, l'héritage
d'authentification...). Ainsi, IKEv2 est une récriture de IKEv1 [4.1]
qui préserve la plus part des
|
Etude d'IPsec
Projet d'une API_IPSEC pour
la Mobilite et le Multihoming
|
|
|
fonctions d'IKEv1 (cacher l'identité, deux
phases, négociation cryptographique...), qui fixe plusieurs
problèmes d'IKEv1 trouvés pendant sont déploiement ou
analyse, et qui améliore le protocole afin de la rendre plus efficace,
plus robuste et plus interoperable.
Le principe du protocole IKE
Le principe devient justement le même qu'on
applique pour le trafic sortant (expliqué dans le point
antérieur). Il existe une exception à ce principe : les paquets
IKE ne sont jamais soumis à IPsec par un ajout d'une règle
précisant de ne pas utiliser IPsec dans ce cas. Cela permet de casser le
problème de l'oeuf ou de la poule (pour mettre en place IPsec, on ne
peut pas utiliser IPsec). A noter qu'IKE effectue ses échanges au-dessus
du niveau transport (UDP, port 500, en général). Cela permet bien
de découpler la négociation IPsec des fonctionnalités
d'IPsec.
Les phases d'IKE
IKEv2 se décompose en deux phases pour
négocier les SA:
- La première phase permet de vérifier
l'identité des entités en présence. On choisit les
algorithmes de cryptographie utilisés pour les futures
négociations. Á la fin de cette phase, chaque entité doit
disposer d'une clé de chiffrement, d'une clé d'authentification
et d'un secret partagé qui servira de "graine" dans la phase suivante
(on produit une clé en fonction de valeurs déjà
calculées).
- La deuxième phase permet de négocier
les attributs plus spécifiques à IPsec (utilisation d'AH ou d'ESP
par exemple), ces échanges sont chiffrés et authentifiés
grâce aux éléments décidés lors de le
première phase.
Il y a un intérêt à ce
découpage. La première phase fait appel à de la
cryptographie asymétrique lente, elle est de plus utilisée qu'une
seule fois pour définir les paramètres qui vont permettre de
sécuriser les échanges de phase 2. La phase 2 est en revanche
appelée plusieurs fois. En effet, les clés qui servent à
chiffrer deviennent vulnérables avec le temps ou quand on s'en sert
beaucoup. Cette phase est donc régulièrement re-effectuée
pour changer certaines clés de sessions.
Implémentations d'IKEv2 : on choisit
strongSwan et OpenIKEv2
Il existe plusieurs implémentations d'Open Source
d'IKEv2, qui utilisent une interface IPsec basée soit en XFRM soit en
PFKEY2. Voici une comparative actualisée qui détaille ses
fonctionnalités:
Features
|
openikev2
|
racoon2
|
ikev2
|
strongSwan
|
Version
|
0.94
|
20/07/2007
|
2.0alpha
|
4.1.2
|
Cookies; Negotiation: DH group, Proposal, Traffic
selector
|
Yes
|
Yes
|
Yes
|
Yes
|
Narrowing
|
Yes
|
No
|
Yes
|
Yes
|
Preshared-Key & Certificate
Authentication
|
Yes
|
Yes
|
Yes
|
Yes
|
Child_SA/IKE_SA Rekeying, Deletion
|
Yes
|
Yes
|
Yes
|
Yes
|
Configuration Payload (Dynamic Addressing)
|
Yes
|
?
|
No
|
Yes
|
|
|
Etude d'IPsec
Projet d'une API_IPSEC pour
la Mobilite et le Multihoming
|
|
|
Features
|
openikev2
|
racoon2
|
ikev2
|
strongSwan
|
NAT Traversal
|
No
|
Yes
|
Yes
|
Yes
|
EAP Support
|
Yes
|
No
|
Yes
|
Yes
|
Tunnel / Transport Mode IPSec
|
Yes
|
Yes
|
Yes
|
Yes
|
IPSec Interface
|
XFRM
|
PFKEYv2
|
PFKEYv2
|
XFRM
|
Perfect Forward Secrecy for CHILD_SAs
|
Yes
|
Yes
|
No
|
Yes
|
IPv6 support
|
Yes
|
Yes
|
Yes
|
Yes
|
Different configuration per peer
|
Yes
|
Yes
|
Yes
|
Yes
|
Repeated Authentication (RFC4478)
|
Yes
|
No
|
No
|
Yes
|
External API
|
Yes
|
No
|
No
|
No
|
|
Table 1. Comparative des implémentations
IKEv2
Pour ce projet on a besoin de choisir des
implémentations pour accomplir deux buts différents :
- Le premier consiste à étudier la
viabilité d'intégrer IKEv2, totalement ou partiellement, dans
l'API_IPsec. Dans ce cas on a la motivation de choisir «
OpenIKEv2 » parce qu'il est programmé en C++ (on peut
arriver à compiler l'API_IPsec développé en C avec
OpenIKEv2) et c'est l'unique implémentation qui fournit une API externe
d'IKE avec une bonne sorte de fonctions, d'objets et d'interfaces relativement
facile à utiliser.
- Le deuxième consiste à
réaliser des tests afin de comparer IKE et l'API_IPsec. Dans ce cas on
choisit une ancienne implémentation
«strongSwan» qui présente l'avantage
d'être largement documenté au niveau des configurations des
noeuds.
En conséquence, ces deux implémentations,
OpenIKEv2 et strongSwan,
sont installées, analysés et utilisés plus tard, chacune
à sa tourne.
| 
