Gestion des clés pour Ipsec

Pascal Gachet –EIVD

pascal.gachet@eivd.ch
décembre 2001
 Gestion des clés pour Ipsec -2-

Avant-propos

Ce document est un complément au tutorial VPN créé par C.Tettamanti, qui a pour but
d’apporter plus d’informa tions sur les mécanismes d’échange des clés et d’authentification
rencontrés dans le protocole Ipsec.

Table des matières

Gestion des clés pour Ipsec...................................................................................................................................................... 1

Avant propos .............................................................................................................................................................................. 2
Table des matières ..................................................................................................................................................................... 2
La notion d’association de sécurité (SA) .......................................................................................................................... 2
Utilisation de IKE................................................................................................................................................................. 3
Protocole de gestion des clé ................................................................................................................................................ 4
Skeme ...................................................................................................................................................................................... 4
Echange basé sur Diffie-Helmann...................................................................................................................................... 4
Oakley ..................................................................................................................................................................................... 5
ISAKMP ................................................................................................................................................................................. 6
Bloc ISAKMP........................................................................................................................................................................ 7
Type d’échange ISAKMP.................................................................................................................................................... 9
ISAKMP spécifique à Ipsec.............................................................................................................................................. 10
IKE......................................................................................................................................................................................... 11
Référence .................................................................................................................................................................................. 14

La notion d’association de sécurité (SA)

Le mécanisme qui est implémenté dans Ipsec pour gérer l’intégrité et l’authentification des
datagrammes IP est le protocole AH.
Le protocole ESP, quant à lui, a le rôle d’assurer la confidentialité des données, mais peut
aussi assurer l’authentification des données.
Ces deux protocoles font appel à des algorithmes cryptographies , les algorithmes utilisés
ainsi que les paramètres requis par ceux-ci doivent être négociés de part et d’autre. Le résultat
de cette négociation porte le nom d’association de sécurité (SA). Les clés de session sont donc
contenues dans cette SA. To utes les SA sont stockées dans une base de données qui porte le
nom de SAD (Secure Association Database).
Il est possible de configurer la SA manuellement dans les cas simples, mais la configuration
automatique tend à devenir indispensable.

Le protocole de négociation automatique des SA pour Ipsec s’appelle ISAKMP (Internet

Security Association and Key Management Protocol). Celui-ci est en fait un cadre générique
qui permet l’utilisation de plusieurs protocoles d’échange de clés qui peuvent être utilisés par
d’autres protocoles que Ipsec. ISAKMP, en réalité, ne définit pas de protocole d’échange de
clés proprement dit, il est associé à plusieurs protocoles réalisant cette fonction. Ces deux
protocoles sont SKEME et Oakley. Cette association, pour des raisons de standardisation,
porte le nom de IKE.
 Gestion des clés pour Ipsec -3-

Utilisation de IKE
La protection apportée par Ipsec est basée sur des choix qui sont définis dans une base de
données de politique de sécurité (SPD Security Policy Database). Celle-ci est créée et
maintenue par un administrateur système.
Pour chaque paquet Ipsec la SPD sera consultée pour connaître le niveau de sécurité avec
lequel il doit être traité. Dans le cas où ce paquet doit être sécurisé, le SPD renverra celui-ci
vers la SA correspondante, qui se trouve dans la base de données SPA. (Figure 1)

Figure 1 Négociation SA

Pour mieux saisir le principe de base de ce protocole, deux scénarios peuvent être envisagés.

• Paquet entrant

La couche Ipsec examine l’entête du paquet entrant pour savoir si ce paquet est un paquet
Ipsec ; si c’est le cas, on détermine quels services Ipsec ont été implémentés sur ce paquet ;
puis il est alors possible de déterminer les références SA. La couche Ipsec consulte alors la
SAD pour connaître les paramètres à utiliser pour la vérification et le déchiffrement de ce
paquet. Une fois le paquet déchiffré, un dernier contrôle est effectué en consultant la SPD
pour savoir si la SA appliquée au paquet correspondait bien à la politique de sécurité requise.

• Paquet sortant
 Gestion des clés pour Ipsec -4-

Lorsque la couche Ipsec reçoit des données, la première étape consiste à consulter la SPD
pour déterminer comment traiter ces données. Si celle-ci lui indique que ces données doivent
être sécurisées, les références sur la SA est renvoyée, la SAD est alors à son tour consultée
pour connaître les algorithmes de chiffrement à appliquer sur ces données. Si la SA n’existe
pas encore, c’est à ce moment précis que Ipsec fait appel à IKE pour créer une SA avec les
caractéristiques requises.

Protocole de gestion des clé

Comme déjà mentionné, ISAKMP s’associe dans le cadre de IKE à deux protocoles pour
résoudre le problème de la gestion des clés, SKEME et OAKLEY. Bien que ces deux
protocoles ne soient pas implémentés complètement dans le cadre de IKE, voici la description
complète de ceux ci.

Skeme
Développé spécifiquement pour Ipsec SKEME est une extension du protocole Photuris
proposé par IBM en 1996.
Skeme est un protocole orienté connexion, c’est à dire qu’il comporte un certain nombre
d’échanges pour la négociation d’option et la génération de clé, avant que le l’échange de
messages chiffrés puisse avoir lieu.
Il présente divers modes d’échange de clés possibles.

Echange basé sur Diffie-Helmann

Cet échange est basé sur l’utilisation de clé publique RSA pour générer un secret partagé
DIFFIE-HELLMANN, avec authentification pour éviter une possible attaque de
l’intercepteur. Les deux tiers possèdent chacun une valeur publique Diffie-Hellmann
authentifiée ; ils peuvent, à partir de la connaissance de la valeur publique du correspondant et
de leur propre valeur privée, générer un secret partagé.
L’authentification des valeurs publiques peut se faire de divers façon : certificat x.509, dns
sécurisé, clé PGP signée, pki, etc.
Ce secret partagé ainsi généré va servir à créer la clé de session par dérivation.

Pour assurer la PFS (perfect forward secrecy), la génération de la clé maîtresse Diffie-
Helmann est éphémère, c’est-à-dire que les valeurs publiques diffie- helmann sont modifiées à
court terme pour générer une nouvelle clé maîtresse régulièrement.

Le problème de Diffie- helmann est que ce protocole requiert des opérations coûteuses en
ressources système pour le calcul de la clé maîtresse, ce qui le rend très sensible aux attaques
dites de déni de service, c’est-à-dire aux inondations de données (flooding attacks). Ces
attaques ne compromettent pas la sécurité proprement dite du système, mais peuvent le
déstabiliser, voire le paralyser.
Il n’est pas possible d’éviter ce genre d’attaques, mais pour rendre leur réalisation plus
difficile, un échange de cookies a lieu avant l’échange des valeurs publiques diffie- helmann.
 Gestion des clés pour Ipsec -5-

Ce cookie est composé de l’adresse IP du destinataire ainsi que du port UDP utilisé pour la
connexion, ainsi que d’une information locale secrète, par exemple l’heure du système.
Un utilisateur malintentionné ne disposant que de peu de ressources ne pourra pas générer un
cookie valable, donc il ne pourra pas inonder la victime de requêtes provenant d’adresses IP et
de port arbitraire.

Un autre mode d’échange possible de SKEME peut s’effectuer sans utiliser de clé publique
pour générer le secret partagé Diffie-Hellman. L’échange des éléments publiques DH se fait à
l’aide d’une clé précédemment partagée hors ligne (Pre Shared Key). Cette clé peut avoir été
obtenue de divers façon, soit par une distribution manuelle soit par l’intermédiaire d’un centre
de distribution de clé (Key Distribution Centrer, KDC). Kerberos est un exemple d’un KDC.

Il existe enfin un mode de SKEME plus rapide qui n’utilise pas Diffie-Helmann, mais dans ce
cas la propriété PFS n’est pas assurée.

En résumé.

SKEME comporte quatre modes distincts :

• Le mode de base qui utilise un échange de clé à clé publique qui assure la PFS grâce à
Diffie-Hellman.
• Un échange de clé à base de clé publique mais sans Diffie-Hellman.
• Un échange de clé à l’aide d’une clé précédemment partagée et basée sur
Diffie_Hellmann.
• Un mécanisme d’échange de clé rapide basé uniquement sur des algorithme symétrique.

En plus de ces quatre modes , SKEME comporte quatre phases de fonctionnement.

• Dans la première phase dite de COOKIE chaque tiers génère un cookie, qui sera transmis
dans chaque message afin de contrer les attaques simples en déni. Cette phase est
cependant optionnelle.
• Dans la phase de partage (SHARE), les tiers échangent des demi-clés, chiffrées avec la clé
publique l’un de l’autre. Ces deux demi clés permettent de générer une clé secrète. Dans le
cas où l’on utilise le mode basé sur un secret préalablement partagé, cette phase est sautée.
• La phase d’échange (EXCH) est utilisée suivant le mode choisi, afin d’échanger les
valeurs publiques Diffie-Hellman si le mode PFS est désiré, ou des valeurs aléatoires dans
le cas contraire.
• Les valeurs publiques qui ont été échangées dans la phase EXCH sont ensuite
authentifiées dans la phase d’authentification (AUTH), à l’aide de la clé secrète générée
durant la phase SHARE ou à l’aide du secret préalablement partagé.

Oakley
 Gestion des clés pour Ipsec -6-

Décrit dans le RFC2412, ce protocole est à la base d’échange de clés pour Ipsec. Il ressemble
beaucoup à SKEME dans la mesure où il possède plusieurs modes de fonctionnement basés
ou non sur l’utilisation d’un secret partagé Diffie-Helmannm, il a également recours à des
cookies.

Ce qui le distingue SKEME de Oakley est la possibilité de négociation des options

Toutes ces options sont définies dans l’existence de divers modes Oakley.

Les options ou mode Oakley sont les suivants.

• Possibilité de négocier la PFS, soit la clé secrète est générée par un échange DH
garantissant la PFS, soit la nouvelle clé est dérivée de l’ancienne. La durée de vie de la clé
est négociable dans cette dernière option.

• Négociation des paramètres Diffie-Hellman, c’est-à-dire la taille des entiers n et g,

l’opération arithmétique et les nombres générateurs. Une combinaison de ces paramètres
est déjà définie et forme ce qui est appelé un groupe Diffie-Hellman, mais il est possible
de créer un nouveau groupe en spécifiant les valeurs des paramètres souhaitées.
Les groupes prédéfinis utilisent des entiers de tailles fixes, 768bit, 1024bits, et 2048bit.

• Négociation des paramètres d’authentification, protection de l’identité, utilisation de

cookies, non répudiation.

Le principe de Oakley est que l’initiateur de l’échange commence par spécifier autant
d’options qu’il désire négocier dans un premier message. L’interlocuteur lui répond en
fournissant également toutes les options qu’il désire. La conversation se poursuit jusqu’à ce
que l’état recherché soit atteint.

ISAKMP
Ce protocole, comme déjà mentionné, ne définit qu’un cadre générique permettant la
négociation des paramètres de sécurité pour n’importe quel protocole de sécurité, Ipsec,
TLS … Il est prévu pour supporter la négociation de SA pour tout protocole de niveau
supérieur ou égal à IP. C’est-à-dire qu’il peut être implémenté immédiatement au-dessus d’IP
ou au-dessus de tout protocole de la couche transport ; il dispose de ce fait du port UDP 500.

ISAKMP définit uniquement le cadre dans lequel va s’effectuer la négociation de la SA, mais
n’impose aucun paramètre. Les paramètres négociés et les conventions relatives à l’utilisation
de ISAKMP dans un cadre précis sont définis dans un document nommé DOI (Domain of
Interpretation). Le RFC 2407 définit l’utilisation de ISAKMP avec Ipsec.
L’utilisation propre de ISAKMP dans le cadre de Ipsec par l’intermédiaire d’un DOI sera
décrite plus en détail par la suite, cette section ne définissant que la partie générique de
ISAKMP.
 Gestion des clés pour Ipsec -7-

Le protocole ISAKMP définit deux phases qui perme ttent une séparation entre la négociation
des SA pour un protocole donné comme Ipsec et la protection des données propres à
ISAKMP.

• Dans une première phase, le protocole constitue une SA ISAKMP, contrairement à la SA

Ipsec, cette association est bidirectionnelle, elle a pour but la protection des échanges
ISAKMP future. Cette SA ISAKMP est réalisée par une négociation d’option propre à la
sécurité, les identités des tiers sont authentifiées dans cette phase et des clés sont générées.

• Dans la deuxième phase, la négociation des paramètres de sécurité relative à une SA

précise est négociée, par exemple les mécanismes AH est ESP sont négociés pour une SA
Ipsec. Les échanges de cette seconde phase sont protégés par la SA ISAKMP établie
pendant la première phase.

Bloc ISAKMP
Outre le fait que ISAKMP est indépendant de la SA qui va être générée, ce protocole est
également indépendant de la méthode de génération des clés et du procédé d’authentification
qui sera utilisé. De ce fait, tout protocole ou ensemble de protocoles nécessaire pour la
génération des clés pourra être implémenté sur ISAKMP, dans le cas de Ipsec ces protocoles
seront Oakley et Skeme. (Figure 2)

Figure 2 Couche ISAKMP

Les messages ISAKMP sont composés d’un header et d’un nombre variable de blocs, ces
blocs sont les briques de base du protocole, qui constitue en fait un chaînage de blocs.
 Gestion des clés pour Ipsec -8-

Un header de taille fixe débute le train de bloc, il contient deux cookies, en plus de leur rôle
de protection dans le cas d’un déni de service, ces cookies permettent d’identifier la SA
ISAKMP en cours, car contrairement à des SA Ipsec, elle ne sont pas identifiées par un SPI.

Voici les différents blocs que peut contenir un chaînage ISAKMP. (Figure 3)

Nom Sigle
Security Association SA
Proposal P
Transform T
Key Exchange KE
Identification ID
Certificate CERT
Certificate Request CR
Hash HASH
Signature SIG
Nonce NONCE
Notification N
Delete D
Vendor ID VID

Figure 3 Bloc ISAKMP

• Le bloc SA (Security Associtaion) est utilisé pour négocier les attributs de

sécurité.
Il contient des champs qui indiquent le contexte de la négociation, c’est-à-dire les
conditions définies dans le DOI. Par exemple une valeur de 1 indique qu’il s’agit d’un
DOI Ipsec.

• Le bloc Proposal contient un ensemble de propositions d’options concernant

l’association de sécurité définie dans le bloc SA. Ce bloc indique quel mécanisme de
sécurité sera utilisé, par exemple AH, ESP, ainsi que le SPI à associer à la SA. Comme le
nom du bloc l’indique, il s’agit là d’une proposition, c’est-à-dire que plusieurs bloc
Proposal seront présentés à l’interlocuteur, celui-ci choisira celui qui lui convient.

• Les compléments à chaque bloc Proposal sont définis dans un ou plusieurs blocs
Transform, ceux-ci contiennent les algorithmes de chiffrement et les fonctions de
hachages à utiliser pour la SA.

• Le bloc key Echange sert à transporter les données nécessaires à la génération de la clé
de session. Ce bloc dépend du DOI et du protocole d’échanges de clé choisi ; dans le
cadre d’un DOI Ipsec, seul IKE peut être implementé.
 Gestion des clés pour Ipsec -9-

• Le bloc Identification sert à transporter les données nécessaires à l’identification des

tiers.
Son interprétation dépend du DOI. Un champ ID type indique le type de données
d’identification contenu dans le bloc, pour ISAKMP ce sont une adresse IP ou une plage
d’adresse.

• Le bloc Certificate fournit un moyen de transporter des certificats ou toute autre

information en relation avec les certificats. Un champ intitulé Certificate Encoding
indique le type de certificat ou de données relatives aux certificats contenue dans le champ
Certificate Data. Les types définis sont :
PKCS#7, PGP certificate, DNS signed key, x509 certificate, Kerberos tokens, CRL, ARL,
SPKI certificate.

• Le bloc Certificate Request permet de réclamer un certificat à son interlocuteur.

Comme précédemment, un champ permet d’indiquer le type de certificat requis, et un
champ Certificate Authority contient des références sur une autorité de
certification acceptable.

• Le bloc hash contient le résultat de l’application d’une fonction de hachage sélectionnée

au préalable à tout ou partie du message.
Ce bloc peut être utilisé pour vérifier l’authenticité des tiers en présence.

• Le bloc Signature a la même fonction que le bloc Hash, il contient le résultat d’une
fonction de hachage signée.

• Le bloc Nonce sert à transporter des aléas.

• Le bloc Notification sert à véhiculer des messages d’erreur ou d’information sur l’état
actuel des négociations.

• Le bloc Delete permet de spécifier qu’une SA va être supprimée , elle n’est donc plus
utilisable. Pour supprimer une SA il est nécessaire de créer une nouvelle SA avant de
supprimer l’ancienne.

• Le bloc Vendor ID permet à deux installations de même marque de se reconnaître pour

pouvoir utiliser des implémentations propres.

Type d’échange ISAKMP

Le document RFC 2408 définit ces différents types d’échanges.
A partir des bloc définit ci-dessus, ISAKMP définit différents type d’échanges suivant la
sécurité désirée, un type spécifie comment vont être utilisés les blocs ISAKMP.
Par exemple pour assurer l’anonymat ou non, pour garantir la PFS, etc..
 Gestion des clés pour Ipsec - 10 -

Il existe cinq types d’échanges possibles

Base Exchange

Cet échange permet de transférer simultanément des données d’identification et des données
servant à la génération de la clé. Cet échange permet de réduire le nombre de messages au
détriment de la protection de l’anonymat.

Identity Protection Exchange

Cet échange repousse l’envoi des données d’identification au delà de l’échange des données
permettant la génération du secret partagé. Assurant comme son nom l’indique l’anonymat
des tiers

Authentication Only Exchange

Cet échange est conçu pour aboutir uniquement à l’authentification des tiers , évitant ainsi le
temps de calcul engendré par la génération de clé. Cet échange est utile durant la seconde
phase, ou il sera protégé par les services de sécurité négociés au cours de la première phase.

Aggressive Exchange

Cet échange permet de réduire au maximum le nombre de messages échangés en combinant

les données de négociation de la SA, l’authentification et l’échange de clé en un seul message.
L’anonymat n’est pas préservé, et la négociation du groupe DH n’est pas possible.

Information Exchange

Cet échange est constitué d’un seul message et sert à transmettre de l’information relative à la
SA.

ISAKMP spécifique à Ipsec

Comme déjà signalé, le DOI permet de définir pour quel protocole spécifique ISAKMP va
être utilisé, mais il spécifie et redéfinit certains éléments d’ISAKMP. Ces points sont définis
dans le RFC 2407.

Les spécifications propres à l’utilisation de ISAKMP pour Ipsec sont les suivantes.

• Dans le bloc SA, il existe un champ situation, le DOI définit trois situations possibles pour
une SA Ipsec. Identity only, Secrecy et Integrity.

• Dans le bloc Proposal, il devra être spécifié que c’est Ipsec et non le cadre générique
qui va être utilisé. Donc les protocoles AH et ESP vont également être spécifiés dans ce
bloc.
 Gestion des clés pour Ipsec - 11 -

• Dans le bloc Transform, on spécifie pour les protocoles définis dans le bloc Proposal
quels vont être les algorithmes de chiffrement et d’échange de clés à utiliser.
Pour l’échange des clés il n’y a pas le choix, car seul IKE est défini dans le DOI Ipsec, par
contre pour le protocole AH, les algorithmes de cryptage suivants sont disponible : MD5,
SHA et DES.
Et pour ESP il y a le choix entre DES_IV32, DES_IV64 (c’est-à-dire mode CBC avec
vecteur d’initialisation de 32 ou 64 bits), 3DES (DES avec trois clés 128bits),
RD5,IDEA,CAST,BLOWFISH,3IDEA,RC4.
En plus de ces attributs, c’est dans ce bloc que l’on va définir le groupe dans lequel les
valeurs diffie- hellman vont être générées, ainsi que la durée de vie de la SA et la longueur
des clés.

• Le DOI Ipsec ajoute au bloc Identity des nouveaux champs, le champ protocole ID qui
définit soit UDP soit TCP, ainsi que le champ Port. Ainsi que plusieurs modes
d’identification.
Les modes d’identification sont les suivants :

1) Adresse Ipv4, adresse Ipv6

2) Sous-réseaux IPV4 ou IPV6
3) FQDN (par exemple foo.bar.com)
4) User FQDN (par exemple user@foo.bar.com)
5) Binary DER encoding of an ASN.1 x500 DN [x509]
6) KEY ID : information propre à un fournisseur et permettant d’identifier le secret
partagé à utiliser.

• Dans le bloc Notification, le DOI Ipsec ajoute 3 nouveaux messages de statut.

Responder- lifetime, replay-status, initial-contact.

En résumé, ISAKMP est un cadre générique permettant de construire divers protocoles de

gestions de clés. Il comporte deux étapes appelées phase 1 et phase 2.
La première phase consiste à échanger différents paramètres propres à ISAKMP pour établir
un canal sécurisé et une SA ISAKMP. Puis en utilisant les différents blocs ISAKMP dont la
spécification à été définie dans le DOI, il est possible d’utiliser ce protocole pour un échange
de clés sécurisés. Toutefois l’échange de clés proprement dit n’est nullement défini par
ISAKMP.

IKE
Ce protocole est cons titué par l’association de ISAKMP, de SKEME et Oakley. De ces
protocoles IKE utilisera ISAKMP pour le cadre des négociations, certains modes définis par
 Gestion des clés pour Ipsec - 12 -

Oakley, et empruntera à SKEME son utilisation de chiffrement à clé publique pour

l’authentification et sa méthode de changement de clé rapide.

De ce fait IKE définit quatre modes.

Le mode principal (Main mode) le mode agressif (Aggressive mode) le mode rapide
(Quick mode ) et le mode nouveau groupe (New Group mode).
Durant la phase 1, les modes possibles sont Main mode et agressive mode, quick mode
est réservé pour la phase 2 alors que le mode new group est un mode à part.

Le déroulement d’une négociation IKE suit le diagramme suivant (Figure 4)

PHASE 1
Négociation
ISAKMP SA
Main mode Aggressive mode

PHASE 2 Quick mode avec Quick mode sans

Négociation PFS PFS
de SA pour
AH et ESP

Figure 4 IKE

Phase 1 : Main mode

Durant cette phase, les attributs suivants sont négociés : un algorithme de chiffrement, une
fonction de hachage, une méthode d’authentification et un groupe Diffie-Hellman.

Trois clés sont générées, une clé de chiffrement, une clé pour l’authentification et une clé
pour la dérivation d’autres clés.
Le RFC 2409 définit comment les clés sont créées, c’est-à-dire suivant le mode
d’authentification choisie et suivant la fonction de hachage.

Le main mode est une instance de l’échange ISAKMP Identity Protection. Le deux
premiers messages servent à négocier les paramètres IKE. C’est à dire algorithme de
chiffrement, fonction de hachage méthode d’authentification des tiers et groupe DH.
 Gestion des clés pour Ipsec - 13 -

Il existe quatre méthodes d’authentification, le secret partagé (PSK), la signature numérique,

et deux méthodes d’authentification par clé publique.

Les deux messages suivants permettent l’établissement d’un secret partagé DH via
l’utilisation des valeurs publiques DH.
Le secret partagé DH sert à dériver des clés de session qui seront utilisées pour protéger la
suite des échanges.

Les deux derniers messages servent à l’authentification des valeurs publiques. Cette
authentification se base sur le méthode d’authentification négociée précédemment.

Phase 1 : Aggressive mode

Il s’agit d’une instance de l’échange ISAKMP Aggresive Exchange, qui permet de

combiner les échanges de Main mode pour ramener le nombre de messages à trois.
La méthode d’authentification choisie influencera le contenu des messages et la méthode de
génération de la clé de session.

Phase 2 : Quick mode

Les messages échangés durant la phase 2 sont protégés en authenticité et en confidentialité

grâce aux éléments négociés durant la phase 1. L’authenticité est assurée par l’ajout d’un bloc
HASH après l’en-tête ISAKMP, et la confidentialité est assurée par le chiffrement de
l’ensemble des blocs du message.

Quick mode est utilisé pour la négociation de SA pour des protocoles de sécurité donnés
comme Ipsec. Chaque négociation aboutit en fait à deux SA, une dans chaque sens de la
communication.

Les rôles des échanges de quick mode sont les suivants

1) Négociation d’un ensemble de paramètres Ipsec.

2) Echange de nombres aléatoires utilisés pour générer une nouvelle clé qui dérive de
celle de la SA ISAKMP. Il est possible d’avoir recours à un nouvel échange DH, afin
d’accéder à la propriété de PFS
 Gestion des clés pour Ipsec - 14 -

Référence
[1] IPsec: from Fundamentals to the IKE Protocol
http://www.hsc.fr/ressources/presentations/websec2000/index.html.en
[2] Ipsec overview
http://www.hsc.fr/ressources/presentations/ip.net/index.html.en
[3] IPsec and key management
http://www.hsc.fr/ressources/presentations/ipsec/index.html.en
[4] RFC 2401 : Architecture de sécurité pour IP
http://www.guill.net/reseaux/rfc/Rfc2401.html
[5] RFC 2402 , IP Authentication Header (AH)
http://www.twi.ch/~sna/research/VPN/rfc/rfc2402.txt
[6] RFC 2403, The Use of HMAC-MD5-96 within ESP and AH
http://www.twi.ch/~sna/research/VPN/rfc/rfc2403.txt
[7] RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP
http://www.twi.ch/~sna/research/VPN/rfc/rfc2407.txt
[8] RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)
http://www.twi.ch/~sna/research/VPN/rfc/rfc2408.txt
[9] RFC 2409, The Internet Key Exchange (IKE)
http://www.twi.ch/~sna/research/VPN/rfc/rfc2409.txt
[10] RFC, 2412 The OAKLEY Key Determination Protocol
http://www.twi.ch/~sna/research/VPN/rfc/rfc2412.txt