Ipsec Tech PDF

IPSEC : PRSENTATION TECHNIQUE
Ghislaine Labouret
Herv Schauer Consultants (HSC)
142, rue de Rivoli
75001 Paris
FRANCE
http://www.hsc.fr/
IPsec : prsentation technique

Par Ghislaine LABOURET (Ghislaine.Labouret@hsc.fr)
Version du 16 juin 2000
Mots-clef : scurit, protocoles, IP, cryptographie, confidentialit, intgrit, authentification, gestion

des clefs, AH, ESP, ISAKMP, IKE
1998-2000, HERV SCHAUER CONSULTANTS
TABLE DES MATIRES

INTRODUCTION ........................................................................................................................................... 5
1. VUE DENSEMBLE ................................................................................................................................... 5
1.1. ARCHITECTURE DIPSEC ......................................................................................................................... 5
1.1.1. Les mcanismes AH et ESP ............................................................................................................ 5
1.1.2. La notion dassociation de scurit ................................................................................................ 5
1.1.3. La gestion des clefs et des associations de scurit........................................................................ 6
1.1.4. Politique de scurit ....................................................................................................................... 6
1.2. PRINCIPE DE FONCTIONNEMENT .............................................................................................................. 7
1.3. TYPES DUTILISATIONS POSSIBLES........................................................................................................... 8
1.3.1. quipement fournissant IPsec ........................................................................................................ 8
1.3.2. Modes de fonctionnement ............................................................................................................... 9
2. LES MCANISMES DE SCURIT : AH ET ESP.............................................................................. 10
2.1. RAPPELS SUR LES SERVICES DE SCURIT ET LES MCANISMES ASSOCIS ............................................. 10
2.1.1. Confidentialit .............................................................................................................................. 10
2.1.2. Authentification et intgrit .......................................................................................................... 11
2.2. AUTHENTICATION HEADER (AH).......................................................................................................... 12
2.3. ENCAPSULATING SECURITY PAYLOAD (ESP)........................................................................................ 13
3. LA GESTION DES CLEFS ...................................................................................................................... 16
3.1. CONCEPTS GNRAUX RELATIFS LA GESTION DES CLEFS .................................................................... 16
3.1.1. Types de clefs................................................................................................................................ 16
3.1.2. Infrastructures clef publique...................................................................................................... 16
3.1.3. change de clefs et authentification ............................................................................................. 17
3.1.4. Proprits des protocoles dchange de clef ................................................................................ 17
3.1.5. Diffie-Hellman .............................................................................................................................. 17
3.2. LES PROTOCOLES DAUTHENTIFICATION MUTUELLE AVEC CHANGE DE CLEF DVELOPPS POUR IP .... 18
3.2.1. SKIP.............................................................................................................................................. 19
3.2.2. Photuris ........................................................................................................................................ 20
3.2.3. SKEME ......................................................................................................................................... 21
3.2.4. Oakley........................................................................................................................................... 22
3.3. LA GESTION DES CLEFS POUR IPSEC : ISAKMP ET IKE........................................................................ 23
3.3.1. ISAKMP ........................................................................................................................................ 23
3.3.2. IPsec DOI ..................................................................................................................................... 29
3.3.3. IKE................................................................................................................................................ 31
ANNEXE A SIGLES ET ACRONYME ................................................................................................... 35
ANNEXE B GLOSSAIRE ......................................................................................................................... 37
ANNEXE C BIBLIOGRAPHIE COMMENTE.................................................................................... 45
C.1. CRYPTOGRAPHIE .................................................................................................................................. 45
C.1.1. Gnralits ................................................................................................................................... 45
C.1.2. Codes dauthentification de messages ......................................................................................... 45
C.1.3. change de clef ............................................................................................................................ 45
C.1.4. Scurit des rseaux et des changes........................................................................................... 46
C.2. IPSEC ................................................................................................................................................... 46
C.2.1. Architecture.................................................................................................................................. 47
C.2.2. Protocole AH ............................................................................................................................... 47
C.2.3. Protocole ESP .............................................................................................................................. 47
C.2.4. Algorithmes dauthentification..................................................................................................... 47
C.2.5. Algorithmes de chiffrement .......................................................................................................... 47
C.2.6. Gestion des clefs........................................................................................................................... 48
C.2.7. Cryptanalyse ................................................................................................................................ 49
IPsec : prsentation technique G. LABOURET
Introduction
Introduction
Le terme IPsec (IP Security Protocol) dsigne un ensemble de mcanismes destins protger le
trafic au niveau dIP (IPv4 ou IPv6). Les services de scurit offerts sont lintgrit en mode non
connect, lauthentification de lorigine des donnes, la protection contre le rejeu et la
confidentialit (confidentialit des donnes et protection partielle contre lanalyse du trafic). Ces
services sont fournis au niveau de la couche IP, offrant donc une protection pour IP et tous les
protocoles de niveau suprieur. Optionnel dans IPv4, IPsec est obligatoire pour toute
implmentation de IPv6. Une fois IPv6 en place, il sera ainsi possible tout utilisateur dsirant des
fonctions de scurit davoir recours IPsec.
IPsec est dvelopp par un groupe de travail du mme nom lIETF (Internet Engineering Task
Force), groupe qui existe depuis 1992. Une premire version des mcanismes proposs a t publie
sous forme de RFC en 1995, sans la partie gestion des clefs. Une seconde version, qui comporte en
plus la dfinition du protocole de gestion des clefs IKE, a t publie en novembre 1998. Mais IPsec
reste une norme non fige qui fait en ce moment mme lobjet de multiples Internet drafts,
notamment sur la protection des accs distants. Cette prsentation couvre uniquement les RFC de
novembre 1998.
1. Vue densemble
Cette partie prsente le principe de fonctionnement dIPsec, les diffrents lments qui le composent,
la faon dont ils interagissent et les diffrentes utilisations possibles.
1.1. Architecture dIPsec

Pour scuriser les changes ayant lieu sur un rseau TCP/IP, il existe plusieurs approches, en
particulier en ce qui concerne le niveau auquel est effectue la scurisation : niveau applicatif (mails
chiffrs par exemple), niveau transport (TLS/SSL, SSH), ou loppos niveau physique (botiers
chiffrant toutes les donnes transitant par un lien donn). IPsec, quant lui, vise scuriser les
changes au niveau de la couche rseau.
1.1.1. Les mcanismes AH et ESP

Pour cela, IPsec fait appel deux mcanismes de scurit pour le trafic IP, les protocoles AH et
ESP, qui viennent sajouter au traitement IP classique :
Authentication Header (AH) est conu pour assurer lintgrit et lauthentification des
datagrammes IP sans chiffrement des donnes (i.e. sans confidentialit).
Le principe de AH est dadjoindre au datagramme IP classique un champ supplmentaire
permettant la rception de vrifier lauthenticit des donnes incluses dans le datagramme.
Encapsulating Security Payload (ESP) a pour rle premier dassurer la confidentialit, mais peut
aussi assurer lauthenticit des donnes.
Le principe de ESP est de gnrer, partir dun datagramme IP classique, un nouveau datagramme
dans lequel les donnes et ventuellement len-tte original sont chiffrs.
Ces mcanismes peuvent tre utiliss seuls ou combins pour obtenir les fonctions de scurit
dsires. Ils seront dcrits plus en dtails au chapitre Les mcanismes de scurit : AH et ESP.
1.1.2. La notion dassociation de scurit

Les mcanismes mentionns ci-dessus font bien sr appel la cryptographie, et utilisent donc un
certain nombre de paramtres (algorithmes de chiffrement utiliss, clefs, mcanismes slectionns...)
Architecture dIPsec
sur lesquels les tiers communicants doivent se mettre daccord. Afin de grer ces paramtres, IPsec a
recours la notion dassociation de scurit (Security Association, SA).
Une association de scurit IPsec est une connexion simplexe qui fournit des services de scurit
au trafic quelle transporte. On peut aussi la considrer comme une structure de donnes servant
stocker lensemble des paramtres associs une communication donne.
Une SA est unidirectionnelle ; en consquence, protger les deux sens dune communication
classique requiert deux associations, une dans chaque sens. Les services de scurit sont fournis par
lutilisation soit de AH soit de ESP. Si AH et ESP sont tous deux appliqus au trafic en question,
deux SA (voire plus) sont cres ; on parle alors de paquet (bundle) de SA.
Chaque association est identifie de manire unique laide dun triplet compos de :
Ladresse de destination des paquets.
Lidentifiant dun protocole de scurit utilis (AH ou ESP).
Un index des paramtres de scurit (Security Parameter Index, SPI).
Un SPI est un bloc de 32 bits inscrit en clair dans len-tte de chaque paquet chang ; il est choisi
par le rcepteur.
Pour grer les associations de scurit actives, on utilise une base de donnes des associations de
scurit (Security Association Database, SAD). Elle contient tous les paramtres relatifs chaque
SA et sera consulte pour savoir comment traiter chaque paquet reu ou mettre.
1.1.3. La gestion des clefs et des associations de scurit

Comme nous lavons mentionn au paragraphe prcdent, les SA contiennent tous les paramtres
ncessaires IPsec, notamment les clefs utilises. La gestion des clefs pour IPsec nest lie aux
autres mcanismes de scurit de IPsec que par le biais des SA. Une SA peut tre configure
manuellement dans le cas dune situation simple, mais la rgle gnrale est dutiliser un protocole
spcifique qui permet la ngociation dynamique des SA et notamment lchange des clefs de session.
Dautre part, IPv6 nest pas destin supporter une gestion des clefs en bande, cest--dire o les
donnes relatives la gestion des clefs seraient transportes laide dun en-tte IPv6 distinct. Au lieu
de cela on utilise un systme de gestion des clefs dit hors bande, o les donnes relatives la
gestion des clefs sont transportes par un protocole de couche suprieure tel que UDP ou TCP.
Ceci permet le dcouplage clair du mcanisme de gestion des clefs et des autres mcanismes de
scurit. Il est ainsi possible de substituer une mthode de gestion des clefs une autre sans avoir
modifier les implmentations des autres mcanismes de scurit.
Le protocole de ngociation des SA dvelopp pour IPsec sappelle protocole de gestion des clefs
et des associations de scurit pour Internet (Internet Security Association and Key Management
Protocol, ISAKMP). ISAKMP est en fait inutilisable seul : cest un cadre gnrique qui permet
lutilisation de plusieurs protocoles dchange de clef et qui peut tre utilis pour dautres
mcanismes de scurit que ceux de IPsec. Dans le cadre de la standardisation de IPsec, ISAKMP est
associ une partie des protocoles SKEME et Oakley pour donner un protocole final du nom dIKE
(Internet Key Exchange). Ces protocoles seront dcrits en dtail au chapitre La gestion des clefs
page 15.
1.1.4. Politique de scurit

Les protections offertes par IPsec sont bases sur des choix dfinis dans une base de donnes de
politique de scurit (Security Policy Database, SPD). Cette base de donnes est tablie et
maintenue par un utilisateur, un administrateur systme ou une application mise en place par ceux-ci.
Elle permet de dcider, pour chaque paquet, sil se verra apporter des services de scurit, sil
sera autoris passer outre ou sera rejet.
La SPD contient une liste ordonne de rgles, chaque rgle comportant un certain nombre de critres
qui permettent de dterminer quelle partie du trafic est concerne. Les critres utilisables sont
Vue densemble
lensemble des informations disponibles par le biais des en-ttes des couches IP et transport. Ils
permettent de dfinir la granularit selon laquelle les services de scurit sont applicables et
influencent directement le nombre de SA correspondante. Dans le cas o le trafic correspondant une
rgle doit se voir attribuer des services de scurit, la rgle indique les caractristiques de la SA (ou
paquet de SA) correspondante : protocole(s), modes, algorithmes requis
1.2. Principe de fonctionnement

Le schma ci-dessous reprsente tous les lments prsents ci-dessus (en bleu), leurs positions et
leurs interactions.
Administrateur
Alertes
DOI
Configure
Oakley
SKEME
ISAKMP
Ngocie,
modifie,
supprime
Protocole applicatif
(HTTP, FTP, POP,
SMTP,)
IKE
Demande
cration SA
Pointe
vers
Application
Sockets
Transport (TCP, UDP)
SPD
Consulte
IP / IPsec (AH, ESP)
SAD
Consulte
Liaison
- Figure 1. Organisation de IPsec On distingue deux situations :

Trafic sortant
Lorsque la couche IPsec reoit des donnes envoyer, elle commence par consulter la base de
donne des politiques de scurit (SPD) pour savoir comment traiter ces donnes. Si cette base lui
indique que le trafic doit se voir appliquer des mcanismes de scurit, elle rcupre les
caractristiques requises pour la SA correspondante et va consulter la base des SA (SAD). Si la SA
ncessaire existe dj, elle est utilise pour traiter le trafic en question. Dans le cas contraire, IPsec
fait appel IKE pour tablir une nouvelle SA avec les caractristiques requises.
Trafic entrant
Lorsque la couche IPsec reoit un paquet en provenance du rseau, elle examine len-tte pour
savoir si ce paquet sest vu appliquer un ou plusieurs services IPsec et si oui quelles sont les
rfrences de la SA. Elle consulte alors la SAD pour connatre les paramtres utiliser pour la
vrification et/ou le dchiffrement du paquet. Une fois le paquet vrifi et/ou dchiffr, la SPD est
consulte pour savoir si lassociation de scurit applique au paquet correspondait bien celle
requise par les politiques de scurit.
Types dutilisations possibles
Dans le cas o le paquet reu est un paquet IP classique, la SPD permet de savoir sil a nanmoins
le droit de passer. Par exemple, les paquets IKE sont une exception. Ils sont traits par IKE, qui
peut envoyer des alertes administratives en cas de tentative de connexion infructueuse.
1.3. Types dutilisations possibles

Aprs avoir vu comment est constitu IPsec et comment il fonctionne, nous allons maintenant nous
intresser aux diffrentes faons de lutiliser. Un point important retenir est que le fait dintervenir
au niveau rseau rend la scurisation totalement transparente pour les applications.
1.3.1. quipement fournissant IPsec

IPsec peut tre utilis au niveau dquipements terminaux ou au niveau de passerelles de scurit
(security gateway), permettant ainsi des approches de scurisation lien par lien comme de bout en
bout. Trois configurations de base sont possibles :
IPsec
Rseau de
confiance
IPsec
Rseau de
confiance
Rseau
non fiable
Passerelle de scurit
IPsec
IPsec
Rseau
non fiable
Rseau de
confiance
quipement terminal
IPsec
IPsec
Rseau
non fiable
quipement terminal
quipement terminal
- Figure 2. Diffrentes configurations possibles suivant lquipement mettant IPsec en uvre La premire situation est celle o lon dsire relier des rseaux privs distants par lintermdiaire dun
rseau non fiable, typiquement Internet. Les deux passerelles de scurit permettent ici dtablir un
rseau priv virtuel (en anglais Virtual Private Network, VPN).
La deuxime situation correspond au cas o lon dsire fournir un accs scuris au rseau interne
pour des postes nomades. Le rseau non fiable peut tre Internet, le rseau tlphonique
Enfin, dans la troisime situation, deux tiers dsirent communiquer de faon scurise mais nont
aucune confiance dans le rseau qui les spare.
On peut galement imaginer des configurations plus complexes o plusieurs associations de scurit,
apportant ventuellement des services de scurit diffrents, se succderaient ou se superposeraient
partiellement :
Vue densemble
Association de scurit 2
Rseau
non fiable
Rseau de
confiance
IPsec
IPsec
IPsec
Rseau
non fiable
IPsec
Rseau de
confiance
IPsec
IPsec
- Figure 3. Exemples de double utilisation dIPsec Dans les exemples ci-dessus, la premire association peut servir assurer les services de scurit
requis par la politique de scurit externe (authentification et confidentialit par exemple), et la
seconde assurer les services requis par la politique de scurit interne (authentification vis--vis de
lhte final par exemple).
1.3.2. Modes de fonctionnement

Pour chacun des mcanismes de scurit dIPsec, il existe deux modes : le mode transport et le mode
tunnel.
En mode transport, seules les donnes en provenance du protocole de niveau suprieur et
transportes par le datagramme IP sont protges. Ce mode nest utilisable que sur des
quipements terminaux ; en effet, en cas dutilisation sur des quipements intermdiaires, on courrait
le risque, suivant les alas du routage, que le paquet atteigne sa destination finale sans avoir travers
la passerelle sense le dchiffrer.
En mode tunnel, len-tte IP est galement protg (authentification, intgrit et/ou confidentialit)
et remplac par un nouvel en-tte. Ce nouvel en-tte sert transporter le paquet jusqu la fin du
tunnel, o len-tte original est rtabli. Le mode tunnel est donc utilisable la fois sur des
quipements terminaux et sur des passerelles de scurit. Ce mode permet dassurer une protection
plus importante contre lanalyse du trafic, car il masque les adresses de lexpditeur et du
destinataire final.
Rappels sur les services de scurit et les mcanismes associs
Rsum et bibliographie
Ipsec est un systme de scurisation des changes au niveau IP qui repose sur deux
mcanismes (ou protocoles), AH (Authentication Header) et ESP (Encapsulating Security
Payload). Les paramtres ncessaires lutilisation de ces protocoles sont grs laide
dassociations de scurit (Security Association, SA), une association regroupant les paramtres
servant protger une partie donne du trafic. Les SA sont stockes dans la base de donne des
associations de scurit (Security Association Database, SAD) et gres laide du protocole IKE
(Internet Key Exchange). Les protections offertes par IPsec sont bases sur des choix dfinis dans
la base de donnes de politique de scurit (Security Policy Database, SPD). Cette liste de rgles
permet de dcider, pour chaque paquet, sil se verra apporter des services de scurit, sil sera
autoris passer outre ou sera rejet.
IPsec peut tre utilis au niveau dquipements terminaux ou au niveau de passerelles de scurit,
permettant ainsi des approches de scurisation lien par lien comme de bout en bout. IPsec peut
donc tre utilis, notamment, pour la cration de rseaux privs virtuels ou la scurisation des
accs distants. Enfin, IPsec comporte deux modes, le mode transport qui protge juste les
donnes transportes et le mode tunnel qui protge en plus len-tte IP.
Le document de base pour comprendre le fonctionnement dIPsec et le document intitul Security
Architecture for the Internet Protocol", dont la version la plus rcente est la [RFC 2401].
2. Les mcanismes de scurit : AH et ESP

Ainsi que nous lavons dj mentionn dans le chapitre prcdent, deux mcanismes de base
permettent dassurer lensemble des fonctions de scurit fournies par IPsec. Ce sont :
Authentication Header (AH), qui est conu pour assurer lintgrit et lauthentification des
datagrammes IP sans chiffrement des donnes (i.e. sans confidentialit).
Encapsulating Security Payload (ESP), dont le rle premier est dassurer la confidentialit.
Ces mcanismes peuvent tre utiliss seuls ou combins pour obtenir les fonctions de scurit
dsires.
Les mcanismes IPsec ne sont lis aucun algorithme cryptographique spcifique, donc ces
algorithmes peuvent tre modifis sans affecter les autres lments dune implmentation. Pour
assurer linteroprabilit, des algorithmes cryptographiques par dfaut sont toutefois indiqus. Par
ailleurs, les proprits de lalgorithme utilis influenceront les fonctions de scurit fournies.
Nous allons commencer par rappeler les quelques principes relatifs aux services et mcanismes de
scurit dans le cadre de la protection des changes, avant de dtailler le fonctionnement des
protocoles AH et ESP.
2.1. Rappels sur les services de scurit et les mcanismes associs

2.1.1. Confidentialit
La confidentialit est un service de scurit qui consiste sassurer que seules les personnes
autorises peuvent prendre connaissance dun ensemble de donnes. Le mcanisme qui permet
dobtenir ce service est gnralement le chiffrement des donnes concernes laide dun
algorithme cryptographique. Dans le cadre du chiffrement dchanges rseau, on utilise toujours, pour
des raisons de performance, des algorithmes de chiffrement symtriques.
Si seules les donnes transportes sont chiffres, un espion peut tout de mme observer des
caractristiques extrieures du trafic transitant sur un rseau afin de tenter den tirer des
informations : frquence des transmissions, identits des tiers communicants, quantits de donnes
transfres. Associes des informations de nature diffrente (date de rendez-vous, actualit...) ces
lments peuvent permettre aux adversaires de faire des dductions intressantes. On parle de
10
Les mcanismes de scurit : AH et ESP
protection contre lanalyse du trafic lorsquon tente dempcher lanalyse du trafic en cachant les
adresses source et destination, la taille des paquets, la frquence des changes...
2.1.2. Authentification et intgrit

On distingue deux types dauthentification :
Lauthentification dun tiers est laction qui consiste prouver son identit.
Ce service est gnralement rendu par lutilisation dun change dauthentification qui implique
un certain dialogue entre les tiers communiquants.
Lauthentification de lorigine des donnes sert prouver que les donnes reues ont bien t
mises par lmetteur dclar.
Lintgrit est un service de scurit qui consiste sassurer que seules les personnes autorises
pourront modifier un ensemble de donnes. Dans le cadre de communications, ce service consiste
permettre la dtection de laltration des donnes durant le transfert. On distingue deux types
dintgrit :
Lintgrit en mode non connect permet de dtecter des modifications sur un datagramme
individuel, mais pas sur lordre des datagrammes.
Lintgrit en mode connect permet en plus de dtecter la perte de paquets ou leur
rordonnancement.
Lorsque lon communique avec une autre personne au travers dun canal peu sr, on aimerait que le
destinataire puisse sassurer que le message mane bien de lauteur auquel il est attribu et
quil na pas t altr pendant le transfert. Les services correspondant sont lauthentification de
lorigine des donnes et lintgrit.
Les fonctions de hachage sens unique permettent dassurer lintgrit des donnes : applique
un ensemble de donnes, une telle fonction gnre un bloc de taille plus petite appele empreinte.
Toute modification des donnes entrane une modification de lempreinte, et il est trs difficile de
gnrer un message ayant la mme empreinte que loriginal. Si lon dispose dun canal sr (mais plus
coteux) en parallle du canal de communication normal, on peut communiquer lempreinte des
messages par lintermdiaire de ce canal. la rception, le destinataire recalcule lempreinte et la
compare loriginal pour vrifier que les donnes nont pas t modifies.
Sans canal sr, le problme se complique : si lon transfre lempreinte sur un canal de communication non sr, un intercepteur peut modifier les donnes puis recalculer lempreinte. Il convient donc
de trouver une mthode pour sassurer que seul lexpditeur est capable de calculer lempreinte. Pour
cela, on peut utiliser, par exemple, une fonction de hachage sens unique qui fonctionne de plus avec
une clef secrte ou prive. On remarquera que, ce faisant, on fournit galement lauthentification de
lorigine des donnes. Inversement, si on dsire fournir lauthentification de lorigine des donnes et
que lon utilise pour cela un moyen qui ne garantit pas lintgrit des donnes authentifies, un intrus
peut modifier le message et donc faire accepter comme authentifies des donnes quil a choisies.
Cest pourquoi intgrit et authentification de lorigine des donnes sont gnralement fournies
conjointement par un mme mcanisme. Le terme authenticit dsigne lintgrit jointe
lauthentification des donnes. Pas abus de langage, le terme authentification est galement
couramment utilis pour dsigner en fait authentification et intgrit.
Les deux mcanismes permettant dassurer lauthenticit des donnes transmises sont le scellement et
la signature.
Le scellement consiste adjoindre au message un sceau ou code dauthentification de message
(Message Authentication Code, MAC), qui est le rsultat dune fonction de hachage sens unique
clef secrte. Lempreinte dpend la fois des donnes et de la clef ; elle nest donc calculable que par
les personnes connaissant la clef.
La signature numrique assure galement lauthenticit des donnes et fournit en plus la nonrpudiation : lmetteur ne peut pas nier avoir mis un message quil a sign. Ce dernier point
11
Authentication Header (AH)
diffrencie la signature des codes dauthentification de message, et a pour consquence que la plupart
des algorithmes de signature utilisent la cryptographie clef publique. Dans le cadre de la protection
dchanges rseau, on utilise toujours, pour des raisons de performance, un mcanisme de scellement.
Enfin, la protection contre le rejeu est une forme partielle dintgrit en mode connect qui permet
de contrer les attaques au cours desquelles un adversaire envoie un message intercept prcdemment,
en esprant quil sera accept comme valide par le destinataire. Elle est gnralement assure par
lutilisation dun numro de squence.
Dans le cadre de la protection des changes rseau, les principaux services de scurit sont :
La confidentialit, qui est assure par le chiffrement des donnes.
Lauthenticit (authentification + intgrit), qui est

dauthentification de message chaque paquet transfr.
assure
par
lajout
dun
code
Les diffrents services et mcanismes intervenant dans la scurit des rseaux sont rfrencs de
faon formelle dans la norme [ISO 7498-2].
Pour plus de dtails sur les notions cryptographiques mentionnes ici, on pourra se rfrer la
bibliographie sur la cryptologie.
2.2. Authentication Header (AH)

AH assure lintgrit des donnes en mode non connect, lauthentification de lorigine des
donnes et, de faon optionnelle, la protection contre le rejeu.
Labsence de confidentialit dans AH permet de sassurer que ce standard pourra tre largement
rpandu sur lInternet, y compris dans les endroits o lexportation, limportation ou lutilisation du
chiffrement dans des buts de confidentialit est restreint par la loi. Cela constitue lune des raisons de
lutilisation de deux mcanismes distincts.
Dans AH, intgrit et authentification sont fournies ensembles, laide dun bloc de donnes
supplmentaire adjoint au message protger. Ce bloc de donnes est appel valeur de
vrification dintgrit (Integrity Check Value, ICV),terme gnrique pour dsigner soit un code
dauthentification de message (Message Authentication Code, MAC), soit une signature numrique.
Pour des raisons de performances, les algorithmes proposs actuellement sont tous des algorithmes de
scellement (code d'authentification de message et non signature).
La protection contre le rejeu se fait grce un numro de squence ; elle nest disponible que si IKE
est utilis, car en mode manuel aucune ouverture de connexion ne permet dinitialiser le compteur.
Voici lorganisation de len-tte dauthentification :
En-tte suivant
longueur
Rserv
Index des paramtres de scurit (SPI)

Numro de squence
Donnes dauthentification (longueur variable)
- Figure 4. Format de AH Lexpditeur calcule les donnes dauthentification partir de lensemble des champs
invariants du datagramme IP final, AH compris, ce qui permet dtendre lauthentification au SPI
et au numro de squence notamment. Les champs variables (TTL, routage...) et le champ destin
recevoir les donnes dauthentification sont considrs comme gaux zro pour le calcul. Les
12
donnes dauthentification sont alors adjointes au paquet IP par le biais de len-tte dauthentification
(AH). Le rcepteur vrifie lexactitude de ces donnes la rception.
Les figures ci-dessous indiquent la position de AH et le service apport en fonction du mode choisi
(transport ou tunnel).
- Avant application de AHEn-tte IP
dorigine
Donnes
(protocole de niveau suprieur)
- Aprs application de AH AH
En-tte IP
dorigine
Donnes
Authentifi
(except pour les champs variables de len-tte)
- Figure 5. Position de AH en mode transport (IPv4) - Avant application de AHEn-tte IP

dorigine
Donnes
- Aprs application de AH Nouvel

en-tte IP
AH
En-tte IP
dorigine
Donnes
Authentifi
(except pour les champs variables du nouvel en-tte)
- Figure 6. Position de AH en mode tunnel (IPv4) Les algorithmes par dfaut que doit fournir toute ralisation de IPsec pour AH sont, au moment o ce
document est rdig, HMAC-MD5 et HMAC-SHA-1. Les autres algorithmes prvus sont KPDKMD5, DES-MAC et HMAC-RIPE-MD.
AH assure lauthenticit des donnes transportes et de len-tte IP par lajout dun code
dauthentification de message (HMAC-MD5, HMAC-SHA-1) au paquet protg. En configuration
dynamique via IKE, AH peut galement fournir une protection contre le rejeu.
AH est dcrit dans le document intitul IP Authentication Header, dont la dernire version est la
[RFC 2402].
Les algorithmes dauthentification utilisables avec AH sont lists dans le DOI IPsec [RFC 2407] et
font lobjet de divers documents (voir bibliographie page 47).
2.3. Encapsulating Security Payload (ESP)

ESP peut assurer, au choix, un ou plusieurs des services suivants :
confidentialit (confidentialit des donnes et protection partielle contre lanalyse du trafic si lon
utilise le mode tunnel),
13
Encapsulating Security Payload (ESP)
intgrit des donnes en mode non connect et authentification de lorigine des donnes,
protection contre le rejeu.
La confidentialit peut tre slectionne indpendamment des autres services, mais son utilisation
sans intgrit/authentification (directement dans ESP ou avec AH) rend le trafic vulnrable certains
types dattaques actives qui pourraient affaiblir le service de confidentialit. Comme dans AH,
authentification et intgrit sont deux services qui vont de pair et que lon dsigne souvent sous le
terme authentification ; ils sont fournis par lutilisation dune ICV (en pratique, un MAC). La
protection contre le rejeu ne peut tre slectionne que si lauthentification la t et que IKE est
utilis. Elle est fournie par un numro de squence que le destinataire des paquets vrifie.
Contrairement AH, o lon se contentait dajouter un en-tte supplmentaire au paquet IP, ESP
fonctionne suivant le principe de lencapsulation : les donnes originales sont chiffres puis
encapsules entre un en-tte et un trailer. Voici lorganisation de ESP :
Index des paramtres de scurit (SPI)
En-tte ESP
Numro de squence
Charge utile
(vecteur d'initialisation ventuel + donnes chiffres)
Bourrage
Charge utile
Trailer ESP
Longueur de bourrage
En-tte suivant
Authentification
ESP
Donnes d'authentification
- Figure 7. Format de ESP Le champ bourrage peut tre ncessaire pour les algorithmes de chiffrement par blocs ou pour aligner
le texte chiffr sur une limite de 4 octets.
Les donnes dauthentification ne sont prsentes que si ce service a t slectionn.
Voyons maintenant comment est applique la confidentialit dans ESP. Lexpditeur :
Encapsule, dans le champ charge utile de ESP, les donnes transportes par le datagramme
original et ventuellement len-tte IP (mode tunnel).
Ajoute si ncessaire un bourrage.
Chiffre le rsultat (donnes, bourrage, champs longueur et en-tte suivant).
Ajoute ventuellement des donnes de synchronisation cryptographiques (vecteur dinitialisation)
au dbut du champ charge utile.
Si elle a t slectionne, lauthentification est toujours applique aprs que les donnes ne soient
chiffres. Cela permet, la rception, de vrifier la validit du datagramme avant de se lancer
dans la coteuse tche de dchiffrement. Contrairement AH, lauthentification dans ESP est
applique uniquement sur le paquet (en-tte + charge utile + trailer) ESP et ninclut ni len-tte IP
ni le champ dauthentification.
14
Les figures ci-dessous indiquent la position de ESP et les services apports en fonction du mode
choisi (transport ou tunnel).
- Avant application de ESPEn-tte IP
dorigine
Donnes
- Aprs application de ESP En-tte IP

dorigine
En-tte
ESP
Donnes
Trailer
ESP
Donnes
dauthentification
Chiffr (confidentialit)
Authentifi
- Figure 8. Position de ESP en mode transport (IPv4) - Avant application de ESPEn-tte IP
dorigine
Donnes
- Aprs application de ESP Nouvel

en-tte IP
En-tte En-tte IP
ESP
dorigine
Donnes
Trailer
ESP
Donnes
dauthentification
Chiffr (confidentialit)
Authentifi
- Figure 9. Position de ESP en mode tunnel (IPv4) Les algorithmes prvus pour tre utiliss avec ESP sont, au moment o ce document est rdig :
Confidentialit : DES triple (obligatoire), DES, RC5, CAST, IDEA, IDEA triple, Blowfish, RC4 et
NULL pour le cas ou le chiffrement nest pas souhait.
Authentification : HMAC-MD5 (obligatoire), HMAC-SHA-1 (obligatoire), DES-MAC, HMACRIPE-MD, KPDK-MD5 et NULL pour le cas o lauthenticit nest pas slectionne.
ESP peut assurer, au choix, la confidentialit et/ou lauthenticit des donnes.
ESP est dcrit dans le document intitul "IP Encapsulating Security Payload (ESP)", dont la
dernire version est la [RFC 2406].
Les algorithmes dauthentification utilisables avec ESP sont dcrits dans les mmes documents
que pour AH.
Les algorithmes de chiffrement utilisables avec ESP sont lists dans le DOI IPsec [RFC 2407] et
font lobjet de divers documents (voir bibliographie page 47).
15
Concepts gnraux relatifs la gestion des clefs
3. La gestion des clefs

Les protocoles scuriss prsents dans le chapitre prcdent ont recours des algorithmes
cryptographiques et ont donc besoin de clefs. Un des problmes fondamentaux dutilisation de la
cryptographie est la gestion de ces clefs. Le terme gestion recouvre la gnration, la distribution, le
stockage et la suppression des clefs.
3.1. Concepts gnraux relatifs la gestion des clefs

Ce paragraphe a pour but de prsenter un certain nombre de concepts utiles pour la comprhension
des parties de cette prsentation relatives la gestion des clefs.
3.1.1. Types de clefs

On peut dfinir plusieurs types de clefs suivant leurs rles :
Clefs de chiffrement de clefs
Ces clefs servent exclusivement chiffrer dautres clefs et ont gnralement une dure de vie
longue. On notera que leur utilisation, restreinte au chiffrement de valeurs alatoires que sont des
clefs, rend les attaques par cryptanalyse plus difficiles leur niveau. La cryptographie clef
publique est souvent utilise pour le transport de clefs en chiffrant la clef transporter laide
dune clef publique.
Clefs matresses
Les clefs matresses sont des clefs qui ne servent pas chiffrer mais uniquement gnrer
dautres clefs par drivation. Une clef matresse peut ainsi tre utilise, par exemple, pour
gnrer deux clefs : une pour le chiffrement et une pour lauthentification.
Clefs de session ou de chiffrement de donnes
Dune dure dutilisation gnralement faible (elle peut aller jusqu changer chaque
message), une telle clef, par opposition aux prcdentes, sert chiffrer des donnes. Du fait de leur
lenteur, les algorithmes asymtriques sont trs peu utiliss en chiffrement de donnes, et les clefs
de session sont donc gnralement des clefs secrtes.
Il est noter que des abus de langage ont souvent lieu avec ces termes. Ainsi, on parle parfois de clef
de session pour dsigner en fait une clef matresse de mme dure de vie et servant gnrer plusieurs
clefs : une pour lauthentification, une pour le chiffrement...
3.1.2. Infrastructures clef publique

De nombreux protocoles et applications utilisent la cryptographie clef publique grande chelle et
doivent donc pouvoir grer des listes importantes de clefs publiques pour des systmes distribus.
Pour cela, ils ont recours des infrastructures cls publiques, systmes de gestion des cls
publiques prvus pour une utilisation grande chelle.
La plupart de ces systmes se basent sur des autorits de certification (Certificate Authorities, CA)
qui sont habilites dlivrer des certificats. Plus prcisment, elles vrifient et authentifient des cls
publiques. Ces autorits sont gnralement organises en une hirarchie qui permet une plus grande
souplesse pour la gestion des cls publiques par le biais de certificats signs par ces autorits et de
listes de rvocations de certificats (Certificate Revocation Lists, CRL).
Il existe de nombreuses PKI, la plupart en cours d'volution. Des exemples d'infrastructures clef
publiques sont PKIX (Public-Key Infrastructure X.509) et SPKI (Simple Public Key Infrastructure) et
DNSSEC (Domain Name System Security), qui font toutes trois l'objet d'une normalisation l'IETF.
16
La gestion des clefs
3.1.3. change de clefs et authentification

Pour tablir une communication scurise, on procde gnralement, en premier lieu, une
authentification des fins de contrle daccs. Puis, un change de clef permet lutilisation dun
mcanisme de scurisation des changes : lauthentification est ainsi tendue la suite de la
communication. Il va de soi que lchange de clef doit ncessairement tre authentifi. La
combinaison de l'authentification et de l'change de clef prend la forme d'un change de messages
appel protocole d'authentification mutuelle avec change de clef.
3.1.4. Proprits des protocoles dchange de clef

DIFFIE, VAN OORSCHOT et WIENER dfinissent, dans [DOW92], la notion de protocole
dauthentification mutuelle avec change de clef sr. Un protocole est dit sr si les deux conditions
suivantes sont valables dans chaque instance du protocole o lun des deux tiers, par exemple Alice,
excute le protocole honntement et accepte lidentit de lautre tiers :
Au moment o Alice accepte lidentit de Bob, les enregistrements des messages changs par les
deux tiers se correspondent (i.e. les messages nont pas t altrs en route).
Il est matriellement impossible pour toute personne autre que les tiers en prsence de retrouver la
clef change.
La proprit voque ci-dessus reprsente le minimum requis pour tout protocole. Cependant, dautres
proprits des protocoles d'change de clef peuvent tre souhaitables :
La proprit dite de Perfect Forward Secrecy (PFS) est garantie si la dcouverte par un
adversaire du ou des secrets long terme ne compromet pas les clefs de session gnres
prcdemment : les clefs de session passes ne pourront pas tre retrouves partir des secrets
long terme. On considre gnralement que cette proprit assure galement que la dcouverte
dune clef de session ne compromet ni les secrets long terme ni les autres clefs de session.
La proprit de Perfect Forward Secrecy peut tre fournie, par exemple, par la gnration des clefs
de session au moyen du protocole Diffie-Hellman (voir ci-dessous), o les exponentiels DiffieHellman sont des valeurs court terme.
La proprit dite de Back Traffic Protection est fournie si la gnration de chaque clef de session
se fait de manire indpendante : les nouvelles clefs ne dpendent pas des clefs prcdentes et la
dcouverte dune clef de session ne permet ni de retrouver les clefs de session passes ni den
dduire les clefs venir.
On dit quil y a authentification directe (Direct Authentication) si, la fin du protocole, les
valeurs servant gnrer le secret partag sont authentifies ou si chaque tiers a prouv
quil connaissait la clef de session. Par opposition, lauthentification est dite indirecte (Indirect
authentication) si elle nest pas garantie la fin du protocole, mais dpend de la capacit de chaque
tiers utiliser, dans la suite des changes, la ou les clefs mises en place prcdemment.
On parle de protection de lidentit (Identity Protection) lorsque le protocole garantit quun
attaquant espionnant les changes ne pourra pas connatre les identits des tiers
communicants.
Enfin, lutilisation du temps (Timestamps) afin dviter la rejouabilit est trs controverse du fait,
principalement, de sa trop grande dpendance dhorloges synchronises.
3.1.5. Diffie-Hellman
Invent en 1976 par DIFFIE et HELLMAN, ce protocole permet deux tiers de gnrer un secret
partag sans avoir aucune information pralable lun sur lautre. Il est bas sur la cryptologie
clef publique (dont il est dailleurs lorigine), car il fait intervenir des valeurs publiques et des
valeurs prives. Sa scurit dpend de la difficult de calculer des logarithmes discrets sur un corps
fini. Le secret gnr laide de ce protocole peut ensuite tre utilis pour driver une ou plusieurs
clefs (clef secrte, clef de chiffrement de clefs...).
17
Les protocoles dauthentification mutuelle avec change de clef dvelopps pour IP
Voici le droulement du protocole :

1. Alice et Bob se mettent daccord sur un grand entier n tel que (n-1)/2 soit premier et sur un entier g
primitif par rapport n. Ces deux entiers sont publics.
2. Alice choisit de manire alatoire un grand nombre entier a, quelle garde secret, et calcule sa
valeur publique, A = ga mod n. Bob fait de mme et gnre b et B = gb mod n.
3. Alice envoie A Bob ; Bob envoie B Alice.
4. Alice calcule KAB = Ba mod n ; Bob calcule KBA = Ab mod n. KAB = KBA = gab mod n est le secret
partag par Alice et Bob.
Une personne qui coute la communication connat g, n, A=ga mod n et B=gb mod n, ce qui ne lui
permet pas de calculer gab mod n : il lui faudrait pour cela calculer le logarithme de A ou B pour
retrouver a ou b.
En revanche, DIFFIEHELLMAN est vulnrable lattaque active dite attaque de lintercepteur.
Le principe de lattaque de lintercepteur (man-in-the-middle attack) est que, pendant que deux tiers
procdent un change de clef, en utilisant un protocole du type DIFFIEHELLMAN par exemple, un
adversaire se positionne entre les deux tiers et intercepte les changes. De cette faon, il procde
un change de clef avec chaque tiers. la fin du protocole, chaque tiers utilisera donc une clef
diffrente, chacune de ces clefs tant connue de lintercepteur. Pour chaque message transmis par la
suite, lintercepteur procdera son dchiffrement avec la clef correspondante puis le rechiffrera avec
lautre clef avant de lenvoyer son destinataire : les deux tiers croiront communiquer de faon sre
alors que lintercepteur pourra en fait lire tous les messages, voire mme forger de faux messages.
Voici comment se droule cette attaque dans le cas de DIFFIEHELLMAN :
1. Alice envoie sa valeur publique A = ga mod n Bob ; Ingrid lintercepteur remplace cette valeur
publique par la sienne. Bob reoit donc I = gi mod n.
2. Bob envoie sa valeur publique Alice ; Ingrid remplace l aussi cette valeur par la sienne.
3. Alice gnre le secret KAI = Ia mod n. Ingrid gnre le mme secret en calculant Ai mod n.
4. Bob gnre le secret KBI = Ib mod n. Ingrid gnre le mme secret en calculant Bi mod n.
Alice et Bob croient tous les deux tre en possession dun secret partag, mais en fait chacun deux
partage un secret diffrent avec Ingrid.
Une faon de contourner le problme de lattaque de lintercepteur est dauthentifier les valeurs
publiques utilises pour la gnration du secret partag. Cela peut se faire deux niveaux :
En utilisant des valeurs publiques authentifies, laide de certificats par exemple. Cette mthode
est notamment la base du protocole SKIP.
En authentifiant les valeurs publiques aprs les avoir changes, en les signant par exemple. Cette
mthode est utilise entre autres par le protocole Photuris.
Linconvnient, dans les deux cas, est que lon perd un gros avantage de DIFFIEHELLMAN, qui est la
possibilit de gnrer un secret partag sans aucune information pralable sur linterlocuteur. Mais, si
les valeurs publiques sont de courtes dure, Diffie-Hellman authentifi fournit la proprit de perfect
formard secrecy.
Bibliographie
Pour plus de dtails sur la scurit des changes, on pourra consulter [OPP98].
Pour plus de dtails sur les notions cryptographiques mentionnes ici, on pourra se rfrer la
bibliographie sur la cryptologie page 45.
3.2. Les protocoles dauthentification mutuelle avec change de clef

dvelopps pour IP
Il existe de nombreux protocoles dauthentification mutuelle avec change de clef, qui se
diffrencient suivant les prrequis quils imposent (secret partag pralable, infrastructure clef
publique...) et les proprits quils vrifient (direct authentication, perfect forward secrecy...).
18
Dans le cadre des protocoles dchange de clef dvelopps pour la scurisation des changes sous IP,
une distinction supplmentaire simpose entre les protocoles orients connexion et ceux sans
connexion. Dans le premier cas, on a recours un protocole dtablissement de clef de session
authentifie, hors bande, avant la communication. La clef rsultante est ensuite utilise pour
scuriser le trafic IP. Linconvnient de cette approche est quelle ncessite ltablissement et la
gestion dune pseudo couche session sous IP, alors quIP est un protocole sans connexion. Dans le
second cas, on a recours une gestion des clefs sans tat (stateless), qui ne ncessite donc pas de
connexion. Ceci est ralisable travers un systme en bande, o la clef ayant servi chiffrer le
paquet est transmise avec celui-ci, chiffre avec la clef publique du destinataire par exemple.
Linconvnient de ce systme est quil ajoute des donnes chaque paquet transmis.
Dautre part, DIFFIEHELLMAN est trs utilis dans tous les protocoles prsents ici, les diffrences
venant de la dure de vie des valeurs publiques utilises et de la faon dont elles sont authentifies et
changes.
3.2.1. SKIP
SKIP (Simple Key management for Internet Protocols) est un exemple de protocole qui ne se base
pas sur ltablissement dune connexion. En effet, aucun change pralable de messages nest
ncessaire avant de pouvoir envoyer un paquet chiffr et chaque paquet transporte linformation
qui permettra de le dchiffrer. Au niveau des couches rseau, cela se traduit par le fait que SKIP se
situe au niveau IP, et non au-dessus de TCP ou UDP comme la plupart des protocoles de gestion de
clefs.
Dautre part, SKIP se base sur une gnration de secret partag DIFFIEHELLMAN avec valeurs
publiques authentifies, donc le seul prrequis est que chaque participant doit tre en possession
dune valeur publique DIFFIEHELLMAN authentifie.
a/ Historique
SKIP a t cr en 1994 par Ashar AZIZ et Whitfield DIFFIE de SUN MICROSYSTEMS. Un brevet fut
dpos par SUN MICROSYSTEMS en juin 1994 puis plac dans le domaine public peu de temps aprs.
SKIP fut propos comme protocole de gestion des clefs standard pour IPsec, et un certain nombre
dInternet drafts furent publis dans ce sens jusquen aot 1996. cette poque, les deux standards
possibles pour la gestion des clefs avec IPsec taient SKIP et ISAKMP/Oakley. Un choix simposait,
et la question fut tranche en faveur de ISAKMP/Oakley en septembre 1996. Si ISAKMP/Oakley a
t choisi pour tre le protocole impos dans toute implmentation, lutilisation de SKIP nest pas
exclue. Cependant, la publication dInternet drafts son sujet a cess depuis cette date. SUN
MICROSYSTEMS continue dvelopper ce protocole et lintgrer dans un certain nombre de produits,
notamment SunScreen SKIP.SKIP est galement utilisable pour la gestion des clefs IPsec dans le
produit Firewall-1 de CHECK POINT.
b/ Principe
SKIP est bas sur le principe de gnration de secret partag DIFFIEHELLMAN, avec authentification
pour viter une possible attaque de lintercepteur. Les deux tiers possdant chacun une valeur
publique DIFFIEHELLMAN authentifie, ils peuvent, partir de la connaissance de la valeur
publique de linterlocuteur et de leur propre valeur prive, gnrer un secret partag.
Pour implmenter SKIP, chaque tiers doit donc possder une valeur publique DIFFIEHELLMAN
authentifie. Cette authentification peut tre obtenue de diffrentes faons : certificat X.509, DNS
scuris, clef PGP signe... D'autre part, pour communiquer avec un interlocuteur choisi, un tiers doit
obtenir sa valeur publique. Une faon de raliser cela est de distribuer les valeurs publiques laide
dun service dannuaire (directory service) ou laide du protocole de dcouverte de certificats
(Certificate Discovery Protocol, CDP).
19
Soient I et J les deux tiers. Les valeurs prives sont respectivement i et j et les valeurs publiques gi
mod p et gj mod p. Chaque tiers obtient le secret partag en levant la valeur publique de son
interlocuteur la puissance sa valeur prive : (gj mod p)i = (gi mod p)j. gij mod p est appel secret
partag long terme et sert driver une clef secrte Kij. En effet, gij mod p sera typiquement de
longueur 1024 bits ou plus, alors que Kij est une clef secrte de longueur 40 256 bits typiquement.
Dans SKIP, Kij est constitue des bits de poids faible de gij mod p.
Voil pour la partie change de clef proprement dite. SKIP va plus loin en prcisant comment cette
clef est ensuite utilise pour protger les changes entre I et J. Kij est en fait une clef de chiffrement de
clef, cest--dire quelle est utilise exclusivement pour chiffrer des clefs de dure de vie beaucoup
plus faible. En effet, Kij est utilise pour chiffrer une clef Kp, appele clef de paquet, qui est ellemme utilise pour gnrer deux clefs, servant respectivement au chiffrement et
lauthentification dun paquet IP ou dun ensemble rduit de paquets.
Le mode de fonctionnement de SKIP, sil ne requiert pas dchange pralable lenvoi de paquet
chiffr, implique en revanche une augmentation de la taille de chaque paquet. En effet, un en-tte
supplmentaire, dit en-tte SKIP, est adjoint au datagramme IP ; il sert notamment transmettre la
clef Kp (chiffre avec Kij) et indiquer les algorithmes utiliss.
c/ Extension pour la proprit de perfect forward secrecy

Le fonctionnement expos ci-dessus prsente le dfaut de ne pas fournir la proprit de perfect
forward secrecy. En effet, si Kij est dcouverte, lensemble des clefs de session Kp utilises par le
pass sont compromises. Une extension de SKIP garantissant cette scurit supplmentaire a donc
t dveloppe. Elle se prsente sous la forme dune gnration de clefs DIFFIEHELLMAN dite
phmre, car reposant sur des valeurs publiques court terme. Le secret partag ainsi gnr
remplace le secret partag long terme de la version classique de SKIP.
Lutilisation dune gnration de clefs DIFFIEHELLMAN phmre implique lchange de certificats
contenant les valeurs publiques correspondantes. Cet change se fait laide du protocole CDP
(Certificate Discovery Protocol) et utilise la clef Kij. Contrairement la version de base de SKIP,
lextension SKIP PFS requiert donc un change de donnes entre les tiers avant de leur permettre de
communiquer.
SKIP PFS fournit galement la protection des identits, ce que ne garantissait pas SKIP.
SKIP est un protocole de gestion des clefs en ligne spcifiquement prvu pour scuriser des
protocoles sans connexion comme IP. Il utilise une gnration de clef DIFFIEHELLMAN, base de
valeurs publiques authentifies. Le secret partag ainsi gnr sert de clef de chiffrement de clef
pour des clefs de session. Il ny a donc pas de perfect forward secrecy (PFS). Une extension de
SKIP a t dfinie qui fournit la proprit de PFS et la protection de lanonymat, au prix dchange
de certificats supplmentaires entre les entits.
La bibliographie sur SKIP se trouve page 48.
3.2.2. Photuris
a/ Contexte
Dvelopp depuis 1995 par Phil KARN de chez QUALCOMM et William Simpson de chez
DayDreamer, Photuris utilise le mme principe que le protocole STS (Station-To-Station) cr par
DIFFIE, VAN OORSCHOT et WIENER [DOW92]. Il a fait lobjet dInternet drafts puis de RFC
indpendants de tout groupe de travail, et est utilisable avec IPsec. Quelques implmentations
l'utilisent d'ailleurs actuellement, mme si IKE est bien plus rpandu.
20
Contrairement SKIP, Photuris est un protocole orient connexion au sens o il comporte un

certain nombre dchanges (pour la ngociation doptions et la gnration de clef) pralables tout
change de messages chiffrs. Photuris sest vu attribu le port UDP 468 par lIANA.
b/ Principe
Photuris est bas sur la gnration dun secret partag selon le principe de DIFFIEHELLMAN. Ce
secret partag a une dure de vie faible : il sert gnrer les clefs de session ncessaires pour
protger la suite des changes. Afin de contrer lattaque de lintercepteur laquelle est vulnrable
DIFFIEHELLMAN, lchange des valeurs servant gnrer le secret partag est suivi dune
authentification de ces valeurs laide des secrets long terme. Ces secrets servant uniquement
lauthentification, Photuris fournit la proprit de perfect forward secrecy.
Un problme de DIFFIEHELLMAN est que ce protocole requiert des oprations coteuses en
ressources systme, ce qui le rend vulnrable des attaques en dni de service appeles attaques par
inondation (flooding attacks). Afin de rendre de telles attaques plus difficiles, Photuris a recours
un change de cookies avant de procder lchange de valeurs DIFFIEHELLMAN. La valeur du
cookie dpend des tiers en prsence, en particulier par lintermdiaire de ladresse IP et du port UDP,
ceci afin dempcher un attaquant dobtenir un cookie valable puis de lutiliser pour inonder la
victime de requtes provenant dadresses IP et/ou de ports arbitraires. Dautre part, il ne doit pas tre
possible, pour un attaquant, de gnrer des cookies qui seront accepts par une entit comme gnrs
par elle-mme. Ceci implique que lentit mettrice utilise une information locale secrte dans la
gnration de ses cookies et dans leur vrification ultrieure.
Le protocole Photuris est compos des trois tapes suivantes :
1. Un change de cookies permet de contrer certaines attaques simples en dni de service. Chaque
tiers en prsence gnre un cookie, et les cookies sont rpts dans chaque message transmis.
2. Un change de valeurs publiques pour la gnration dun secret partag.
3. Un change didentits afin que les tiers sidentifient lun lautre et vrifient lauthenticit des
valeurs changes durant la phase prcdente. Cet change est protg en confidentialit grce
des clefs prives drives du secret partag et des cookies entre autres.
Dautres messages peuvent tre changs ultrieurement pour changer les clefs de session ou les
paramtres de scurit. Ces messages seront protgs en confidentialit de la mme faon que les
messages de lchange 3.
En parallle aux changes exposs ci-dessus, les tiers communicants se mettent daccord sur la
mthode de gnration du secret partag, puis sur un certain nombre de paramtres de scurit utiles
lassociation de scurit mise en place.
Photuris est un protocole orient connexion qui utilise une gnration de secret partag DIFFIE
HELLMAN, suivie dune authentification des valeurs publiques utilises, pour tablir une clef de
session. Photuris introduit le concept de cookie, mcanisme qui permet de contrer certaines
attaques en dni de service. Le protocole comporte trois phases : change de cookies, change
de valeurs publiques et change didentits.
La bibliographie sur Photuris se trouve page 48.
3.2.3. SKEME
a/ Contexte
Dvelopp spcifiquement pour IPsec, SKEME est une extension de Photuris propose en 1996 par
Hugo KRAWCZYK de lIBM T. J. WATSON RESEARCH CENTER. Contrairement Photuris, qui impose
un droulement prcis du protocole, SKEME fournit divers modes dchange de clef possibles.
21
b/ Principe
De la mme faon que les protocoles STS et Photuris, le mode de base de SKEME repose sur
lutilisation de clefs publiques et sur une gnration de secret partag DIFFIEHELLMAN. SKEME
nest cependant pas restreint lutilisation de clefs publiques, mais permet galement lutilisation
dune clef prcdemment partage. Cette clef peut avoir t obtenue par distribution manuelle ou
par lintermdiaire dun centre de distribution de clef (Key Distribution Center, KDC), comme pour
Kerberos. Le KDC permet aux entits communiquantes de partager un secret par lintermdiaire dun
tiers de confiance. Lutilisation de ce secret pour lauthentification du secret DIFFIEHELLMAN et non
directement en tant que clef de session diminue la confiance requise en le KDC. Enfin, SKEME
permet galement deffectuer des changes plus rapides en omettant dutiliser DIFFIEHELLMAN
lorsque la proprit de perfect forward secrecy nest pas requise.
En rsum, SKEME comporte quatre modes distincts :
Le mode de base, qui fournit un change de clef bas sur des clefs publiques et prsentant la
proprit de PFS grce DIFFIEHELLMAN.
Un change de clef bas sur lutilisation de clefs publiques, mais sans DIFFIEHELLMAN.
Un change de clef bas sur lutilisation dune clef partage prcdemment et sur DIFFIE
HELLMAN.
Un mcanisme de changement de clef rapide bas uniquement sur des algorithmes symtriques.
Dautre part, SKEME se dcompose en trois phases : SHARE, EXCH et AUTH.
Durant la phase de partage (SHARE), les tiers changent des demi-clefs, chiffres avec la clef
publique lun de lautre. Ces deux demi-clefs permettent de gnrer une clef secrte K. Si lon
dsire protger lanonymat des tiers en prsence, leur identit est galement chiffre. Dans le cas
o lon possde dj un secret partag, cette phase est saute.
La phase dchange (EXCH) est utilise, suivant le mode choisi, pour changer des valeurs
publiques DIFFIEHELLMAN ou des nombres alatoires. Le secret partag DIFFIEHELLMAN ne
sera calcul quaprs la fin des changes.
Les valeurs publiques ou nombres alatoires prcdents sont authentifies pendant la phase
dauthentification (AUTH), laide de la clef secrte tablie durant la phase SHARE.
Il va de soi que les messages correspondant ces trois phases ne se suivent pas ncessairement de la
faon dcrite ci-dessus, mais sont en pratique combin pour minimiser le nombre de messages
changer.
Une autre phase, dite phase COOKIES, peut tre ajoute avant la phase SHARE afin de protger
contre les attaques en dni de service en ayant recours au mcanisme des cookies introduit par
Photuris.
SKEME est un protocole orient connexion qui propose quatre modes dchange de clefs distincts
et se compose de trois phases : partage, change et authentification. SKEME peut galement
utiliser le mcanisme de cookies de Photuris.
La bibliographie sur SKEME se trouve page 48.
3.2.4. Oakley
a/ Contexte
Initialement propos par Hilarie ORMAN du dpartement informatique de luniversit dArizona,
Oakley a fait lobjet dune RFC dans le cadre du groupe IPsec et est, avec ISAKMP et SKEME, la
base de lchange de clef pour IPsec.
22
b/ Principe
Oakley est un protocole dchange de clef qui ressemble beaucoup SKEME, en ce sens quil
possde galement plusieurs modes, a recours aux cookies et ne ncessite pas le calcul du secret
partag DIFFIEHELLMAN avant la fin du protocole. Il se distingue des protocoles prsents jusqu
prsent par le fait quil permet explicitement aux tiers en prsence de se mettre daccord sur les
mcanismes dchange de clef, de chiffrement et dauthentification utiliss.
De fait, le but dOakley est de permettre le partage, de faon sre entre les tiers, dun ensemble
dinformations relatives au chiffrement : nom de la clef, clef secrte, identits des tiers, algorithmes
de chiffrement, dauthentification et fonction de hachage.
Plusieurs options sont disponibles dans Oakley. En plus du classique DIFFIEHELLMAN, Oakley peut
tre utilis pour driver une nouvelle clef dune clef ancienne ou pour distribuer une clef en la
chiffrant. Ces options se traduisent par lexistence de plusieurs modes.
Le principe gnral dOakley est que linitiateur de lchange commence par spcifier autant
dinformation quil le dsire dans un premier message. Son interlocuteur lui rpond en fournissant
galement autant dinformation quil le dsire. La conversation se poursuit jusqu ce que ltat
recherch soit atteint. Le choix de la quantit dinformation inclure dans chaque message dpend
des options slectionnes (utilisation de cookies sans tat, protection de lidentit, PFS, nonrpudiation...).
Les trois composants du protocole sont :
1. change de cookies (ventuellement sans tat),
2. change de valeurs publiques DIFFIEHELLMAN (optionnel),
3. authentification (options : anonymat, PFS sur les identits, non-rpudiation).
Oakley ressemble beaucoup SKEME, et permet en plus la ngociation dun ensemble de
paramtres.
Oakley est dcrit dans la [RFC 2412].
3.3. La gestion des clefs pour IPsec : ISAKMP et IKE

IKE (Internet Key Exchange) est un systme dvelopp spcifiquement pour IPsec qui vise fournir
des mcanismes dauthentification et dchange de clef adapts lensemble des situations qui
peuvent se prsenter sur lInternet. Il est compos de plusieurs lments : le cadre gnrique ISAKMP
et une partie des protocoles Oakley et SKEME. Lorsqu'il est utilis pour IPsec, IKE est de plus
complt par un domaine d'interprtation pour IPsec.
3.3.1. ISAKMP
Nous avons vu au dbut de cette prsentation que lapport de services de scurit passait par
lutilisation dassociations de scurit qui permettent de dfinir les paramtres (clefs, protocoles)
ncessaires la scurisation dun flux donn. ISAKMP (Internet Security Association and Key
Management Protocol) a pour rle la ngociation, ltablissement, la modification et la
suppression des associations de scurit et de leurs attributs.
a/ Indpendance vis vis des mcanismes : les domaines dinterprtation et les

phases
ISAKMP est un cadre gnrique indpendant des mcanismes en faveur desquels la ngociation
a lieu. En effet, ISAKMP est a priori utilisable pour ngocier, sous forme dassociations de scurit,
les paramtres relatifs nimporte quels mcanismes de scurit : IPsec, TLS Il est en effet prvu
pour supporter la ngociation de SA pour nimporte quel protocole de niveau suprieur ou gal IP.
23
La gestion des clefs pour IPsec : ISAKMP et IKE
Ceci est possible grce la faon dont les ngociations ont lieu. Tout dabord, ISAKMP est prvu
pour fonctionner indpendamment des mcanismes pour lesquels il travaille : les donnes relatives
la gestion des clefs seront transportes part. ISAKMP peut tre implment directement au-dessus
dIP, ou au-dessus de tout protocole de la couche transport. Il sest notamment vu attribuer le port 500
sur UDP par lIANA.
Ensuite, ISAKMP dfinit un cadre pour ngocier les associations de scurit, mais nimpose rien
quant aux paramtres qui les composent. Un document appel domaine dinterprtation
(Domain of Interpretation, DOI) doit dfinir les paramtres ngocis et les conventions relatives
lutilisation de ISAKMP dans un cadre prcis. Un identificateur de DOI est utilis pour
interprter le contenu des messages ISAKMP. La [RFC 2407] dfinit le DOI pour lutilisation de
ISAKMP avec IPsec. Nous reviendrons sur ce document dans le chapitre suivant.
Enfin, ISAKMP comporte deux phases, qui permettent une sparation nette de la ngociation des
SA pour un protocole donn et de la protection du trafic propre ISAKMP :
Durant la premire phase, un ensemble dattributs relatifs la scurit est ngoci, les identits
des tiers sont authentifies et des clefs sont gnres. Ces lments constituent une premire
association de scurit, dite SA ISAKMP. Contrairement aux SA IPsec, la SA ISAKMP est
bidirectionnelle. Elle servira scuriser lensemble des changes ISAKMP futurs.
La seconde phase permet de ngocier les paramtres de scurit relatifs une SA tablir pour
le compte dun mcanisme de scurit donn (par exemple AH ou ESP). Les changes de cette
phase sont scuriss (confidentialit, authenticit...) grce la SA ISAKMP. Celle-ci peut bien sr
tre utilise pour ngocier plusieurs SA destines dautres mcanismes de scurit.
Les paramtres de la SA ISAKMP peuvent tre propres ISAKMP seulement, ou comporter
galement des lments propres un protocole de scurit donn et dfinis dans le DOI
correspondant. Dans le premier cas, on parlera de Generic ISAKMP SA, et celle-ci pourra servir pour
la ngociation de SA pour nimporte quel protocole de scurit. Dans le second cas, la SA ISAKMP
ne pourra tre utilise que pour ngocier une SA dpendant du mme DOI.
b/ Indpendance vis vis du protocole de gestion des clefs : la construction des

messages par blocs
ISAKMP est galement indpendant de la mthode de gnration des clefs et des algorithmes de
chiffrement et dauthentification utiliss. Il est donc indpendant de tout protocole dchange de clef,
ce qui permet de sparer clairement les dtails de la gestion des associations de scurit des dtails de
lchange de clef. Diffrents protocoles dchange de clef, prsentant des proprits diffrentes sont
ainsi utilisables avec ISAKMP.
Ceci est possible cause du fait que ISAKMP nimpose pas un droulement fixe, bas sur la
dfinition dun ensemble de messages limit. ISAKMP est plutt une sorte de kit de construction,
puisque les messages dISAKMP sont constitus dun en-tte suivi dun nombre variable de
blocs. Ces blocs ( payloads en anglais) sont les briques de base dISAKMP.
Chaque message ISAKMP commence par un en-tte (ISAKMP Header) de longueur fixe. Celui-ci
comprend notamment deux cookies, linitiator cookie et le responder cookie, qui, en plus du rle
classique de protection contre le dni de service (anti-clogging), permettent didentifier
lassociation de scurit ISAKMP en cours (contrairement aux autres SA, elle nest pas identifie
pas un SPI).
Un champ Exchange Type permet de connatre le type dchange en cours (voir plus loin) et donc de
connatre lorganisation et le nombre des messages.
Len-tte ISAKMP comprend galement un champ, Next Payload, qui indique le type du premier bloc
du message. Chaque bloc commence son tour par un en-tte propre, qui indique la longueur du bloc
courant et le type du bloc suivant. Le dernier bloc du message indique 0 comme type de bloc suivant.
La construction des messages ISAKMP repose donc sur le chanage de blocs.
24
Le document de base sur ISAKMP dfinit 13 types de blocs diffrents :

Nom
Security Association
Proposal
Transform
Key Exchange
Identification
Certificate
Certificate Request
Hash
Signature
Nonce
Notification
Delete
Vendor ID
Sigle
SA
P
T
KE
ID
CERT
CR
HASH
SIG
NONCE
N
D
VID
Le bloc Security Association (SA) est utilis pour ngocier les attributs de scurit.
En lui-mme, il contient des champs qui indiquent le contexte de la ngociation (DOI et situation).
La situation est un paramtre qui dpend du DOI et qui permet dindiquer quel type de politique
de scurit on dsire utiliser. Une valeur de 0 pour le DOI pendant la phase 1 indique que lon
ngocie une SA ISAKMP gnrique. Une valeur de 1 indique le DOI IPsec.
Un bloc SA est toujours suivi dun ou plusieurs blocs Proposal, qui permettent de faire des
propositions (prsentes par ordre de prfrence) linterlocuteur.
Chaque bloc Proposal constitue une proposition dun ensemble dattributs relatifs une
association de scurit.
En lui-mme, le bloc Proposal indique le mcanisme de scurit que lon dsire utiliser (AH,
ESP) ainsi que le SPI associer la SA si cette proposition est retenue. Comme il est possible
de laisser le choix linterlocuteur en lui faisant plusieurs propositions, chaque bloc Proposal est
numrot. Lorsque plusieurs propositions constituent un tout (par exemple si lon veut ngocier
une protection par AH + ESP), elles portent le mme numro et rsulteront en la cration dun
paquet de SA.
Un bloc P est toujours suivi dun ou plusieurs blocs Transform, qui permettent de prciser les
attributs choisis pour la SA en question.
Chaque bloc Transform indique une transformation (algorithme de chiffrement, fonction de
hachage) et ses attributs. Ces lments dpendent bien sr du DOI et du mcanisme de scurit
slectionn dans les blocs prcdents.
Comme pour les blocs Proposal, les blocs Transform sont numrots : si deux blocs portent le
mme numro, ils forment un tout et doivent tre slectionns ensemble ; des blocs de numros
diffrents indiquent une possibilit de choix.
Ces trois premiers types de blocs ne sont pas indpendants et on peut considrer quils sont embots.
On dsigne donc souvent par le bloc SA seul lensemble des blocs SA, P et T.
SA
P1
T1.1
T1.2
T1.3
P2
T2.1
T2.2
! DOI
! Mcanisme ! Transfo. ! Transfo. ! Transfo. ! Mcanisme ! Transfo. ! Transfo.
! Situation ! SPI
! Attributs ! Attributs ! Attributs ! SPI
! Attributs ! Attributs
- Figure 10. Organisation des blocs SA, P et T

Lensemble reprsent dans le schma ci-dessus pourrait tre un ensemble de propositions envoy par
un tiers un autre. Le destinataire de ce message doit rpondre par une suite identique dans laquelle il
ne conserve que la proposition (ou le groupe de propositions) retenue. Lassociation de scurit (ou le
25
paquet dassociations de scurit) rsultant de cette ngociation se verra attribu le SPI de la

proposition retenue.
Le bloc Key Exchange sert transporter les donnes ncessaires la gnration de la clef de
session. Son interprtation dpend du DOI et du protocole dchange de clefs choisi.
Le bloc Identification sert transporter les donnes ncessaires lidentification des tiers.
Son interprtation dpend du DOI.
Un champ intitul ID Type indique le type de donne didentification contenu dans le bloc. Pour
ISAKMP ce sont une adresse IP (IPv4 ou IPv6) ou une plage dadresses IP (adresse / masque de
sous-rseau). Chaque DOI peut dfinir diffrents types didentification.
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 donne relative aux
certificats contenue dans le champ Certificate Data. Les types dfinis actuellement sont :
" PKCS #7 wrapped X.509 certificate
" PGP certificate
" DNS signed key
" X.509 certificate signature
" X.509 certificate key exchange
" Kerberos tokens
" Certificate revocation list (CRL)
" Authority revocation list (ARL)
" SPKI certificate
" X.509 certificate attribute
Le bloc Certificate Request permet un tiers de rclamer un certificat son interlocuteur.
Comme dans le bloc prcdent, un champ indique le type de certificat requis. Un second champ,
intitul Certificate Authority, contient les rfrences dune autorit de certification acceptable par
le demandeur. Ce champ est facultatif.
Le bloc Hash contient le rsultat de lapplication dune fonction de hachage slectionne au
pralable tout ou partie du message ou une variable dtat donne.
Ce bloc peut tre utilis des fins de vrification de lauthenticit dun message ISAKMP
dauthentification des tiers en prsence.
De mme, le bloc Signature contient le rsultat de lapplication dune fonction de signature
numrique slectionne au pralable tout ou partie du message ou une variable dtat
donne.
Lutilisation est la mme que pour le bloc Hash.
Le bloc Nonce sert transporter des alas.
Le bloc Notification sert vhiculer des messages derreur ou dinformation sur ltat actuel
des ngociations. Son interprtation dpendant du DOI, celui-ci est indiqu au dbut du bloc.
Le dbut du bloc contient galement les rfrences de lassociation de scurit
concerne (mcanisme et SPI). Le message est reprsent par deux champs : Notify Message Type
et Notification Data (facultatif).
Le bloc Delete permet lmetteur de signaler son interlocuteur quil vient de supprimer
une association de scurit et que celle-ci nest donc plus valable.
Un seul bloc permet ventuellement dindiquer plusieurs SA, conditions quelles soient toutes
relatives au mme mcanisme.
Dans ISAKMP, la modification des SA se fait en crant une nouvelle SA puis en supprimant
lancienne.
26
Le bloc Vendor ID peut tre utilis par un programmeur pour permettre deux instances de
son implmentation de se reconnatre et de pouvoir ensuite utiliser des lments propres cette
implmentation.
c/ Interoprabilit et ligne directrice : les types dchanges

partir de ces blocs, ISAKMP dfinit des types dchanges (exchange types). Un type dchange est
une spcification de lensemble des messages constituant un type dchange donn (nombre,
contenu,...). Chaque type dchange est conu pour fournir un certain nombre de services de scurit
spcifiques, comme lanonymat, la proprit de perfect forward secrecy, lauthentification mutuelle,...
Le document de base sur ISAKMP, [RFC 2408], dfinit, des fins dinteroprabilit et surtout pour
indiquer comment doivent tre utiliss les blocs dans le cadre dune ngociation donne, des types
dchanges par dfaut. Dautres types peuvent bien sr tre dfinis, en fonction du protocole
dchange de clef utilis et du DOI notamment. Dautre part, plusieurs propositions de types
dchanges supplmentaires pour ISAKMP font lobjet dInternet Drafts spars.
La spcification actuelle de ISAKMP comporte cinq types dchanges par dfaut : Base Exchange,
Identity Protection Exchange, Authentication-Only Exchange, Aggressive Exchange, Informational
Exchange. Seul ce dernier est obligatoire. Tous ces changes peuvent tre utiliss soit durant la phase
1, soit durant la phase 2. Dans les descriptions qui vont suivre, on utilisera les notations suivantes :
HDR
SA
KE
ID
AUTH
NONCE
*
ISAKMP Header
Security Association Payload
Key Exchange Payload
Identity Payload
Authentication Payload (HASH ou SIG)
Nonce Payload
Signifie que le message est chiffr
- Figure 11. Notations pour les changes ISAKMP Lchange de base (Base Exchange) est conu pour permettre le transfert simultan des donnes
didentification et des donnes servant la gnration de la clef, ce qui permet de rduire le
nombre total de messages ncessaires, au dtriment de la protection de lanonymat des tiers en
prsence. En effet ; les identits sont changes avant quun secret partag ne soit tabli et ne
permette de les chiffrer.
Initiator
Responder
HDR, SA, NONCE
1
Slectionne les attributs

de SA dsirs
HDR, SA, NONCE

2
Attributs de la SA ngocis
HDR, KE, IDi, AUTH
3
Vrifie lauthenticit
Vrifie lauthenticit
HDR, KE, IDr, AUTH

4
Clef calcule par les deux tiers, SA tablie

Les donnes changes au cours des messages 3 et 4 sont protges, par le biais du bloc AUTH, par la
fonction dauthentification slectionne au cours de la ngociation des messages 1 et 2.
27
Lchange de protection didentit (Identity Protection Exchange), quant--lui, repousse lenvoi

des donnes didentification aprs lchange des donnes permettant la gnration du secret
partag, assurant ainsi lanonymat des tiers.
Initiator
Responder
HDR, SA
1

de SA dsirs
HDR, SA
2
HDR, KE, NONCE
3
HDR, KE, NONCE
4
Clef calcule par les deux tiers
HDR*, IDi, AUTH
5
Vrifie lauthenticit
Vrifie lauthenticit
HDR*, IDr, AUTH

6
Lchange dauthentification seule (Authentication Only Exchange) est conu pour aboutir
uniquement lauthentification des tiers, vitant ainsi le temps de calcul engendr par la
gnration de clef lorsque celle-ci nest pas ncessaire. Cet change est particulirement utile
durant la seconde phase, o il sera protg par les services de scurit ngocis au cours de la
premire phase.
Initiator
Responder
HDR, SA, NONCE
1
Vrifie
lauthenticit

de SA dsirs
HDR, SA, NONCE, IDr, AUTH

2
HDR, IDi, AUTH
3
28
Vrifie lauthenticit
Lchange agressif (Aggressive Exchange) combine les donnes de ngociation de la SA,

dauthentification et dchange de clef en un seul message afin de rduire au maximum le nombre
de messages ncessaires. Tout comme pour lchange de base, lanonymat des tiers nest donc pas
prserv. De plus, le fait de ne pas sparer la ngociation de la SA de lenvoi du bloc KE empche
la ngociation du groupe Diffie-Hellman.
Initiator
Responder
HDR, SA, KE, NONCE, IDi
1
Vrifie
lauthenticit
HDR, SA, KE, NONCE, IDr, AUTH

2
Clef calcule, attributs de la SA ngocis
HDR*, AUTH
3
Vrifie lauthenticit
Lchange dinformation (Informational Exchange) est constitu dun seul message et sert
transmettre une information relative la gestion des SA : message derreur, information dtat,
annonce de suppression de SA Il utilise soit un bloc Notification, soit un bloc Delete. Ce
message est protg par la SA ISAKMP si celle-ci a dj t tablie, sinon il nest pas protg.
Initiator
Responder
HDR*, N/D
1
ISAKMP pose les bases permettant de construire divers protocoles de gestion des clefs (et plus
gnralement des associations de scurit). Il comporte trois aspects principaux :
Il dfinit une faon de procder, en deux tapes appeles phase 1 et phase 2 : dans la
premire, un certain nombre de paramtres de scurit propres ISAKMP sont mis en place,
afin dtablir entre les deux tiers un canal protg ; dans un second temps, ce canal est utilis
pour ngocier les associations de scurit pour les mcanismes de scurit que lon
souhaite utiliser (AH et ESP par exemple)
Il dfinit des formats de messages, par lintermdiaire de blocs ayant chacun un rle prcis et
permettant de former des messages clairs.
Il prsente un certain nombre dchanges types, composs de tels messages, qui permettant
des ngociations prsentant des proprits diffrentes : protection ou non de lidentit, perfect
forward secrecy,
ISAKMP est dcrit dans la [RFC 2408].
3.3.2. IPsec DOI

ISAKMP dfinit un cadre pour ngocier les associations de scurit, mais nimpose rien quant aux
paramtres qui les composent. Un document appel domaine dinterprtation (Domain of
Interpretation, DOI) dfinit les paramtres ngocis et les conventions relatives lutilisation de
ISAKMP dans un cadre prcis. Un identificateur de DOI est utilis pour interprter le contenu des
messages ISAKMP. La [RFC 2407] dfinit le DOI pour lutilisation de ISAKMP avec IPsec.
a/ Bloc SA : situation
Utilis dans le bloc SA de ISAKMP, le champ situation permet de prciser la situation laquelle doit
tre rattache la ngociation. Le DOI IPsec dfinit trois situations diffrentes :
29
Identity only, qui impose une identification des tiers par le biais dun bloc ID.
Secrecy, qui permet lutilisation dindicateurs de niveaux de confidentialit.
Integrity, qui permet lutilisation dindicateurs ne niveaux pour lintgrit.
Le DOI IPsec dfinit galement des champs supplmentaires dans le bloc SA pour transporter les
donnes relatives la situation : niveau de confidentialit, niveau dintgrit
b/ Bloc P : protocole de scurit

Les protocoles (ou mcanismes) qui entrent dans le cadre du DOI IPsec sont :
ISAKMP (pour une ngociation de phase 1 avec le DOI IPsec au lieu de Generic ISAKMP)
AH
ESP
IPCOMP
IPCOMP est un protocole de compression des donnes au niveau IP. Le chiffrement des donnes
rendant inefficace toute compression ultrieure, il peut tre intressant de compresser les donnes
avant de les chiffrer.
c/ Bloc T : transformation et attributs

chacun des quatre protocoles mentionns ci-dessus sont associes des transformations permettant
de faire des choix par le biais de blocs Transform.
Pour ISAKMP, cette mthode permet de choisir le protocole dchange de clef utiliser. Le seul
choix possible dans le cadre de IPsec est IKE.
Les transformations relatives AH sont MD5, SHA et DES. Cette information est complter, par le
biais du champ SA Attributes du bloc Transform, par la rfrence de lalgorithme utiliser. Do en
fait quatre possibilits : HMAC-MD5, KPDK-MD5, HMAC-SHA, DES-MAC.
Les transformations relatives ESP sont DES_IV32, DES_IV64 (DES en mode CBC avec un vecteur
dinitialisation de longueur 32 ou 64 respectivement), DES (DES en mode CBC, demande une
prcision par le biais dattributs), 3DES (demande une prcision par le biais dattributs), RC5, IDEA,
CAST, BLOWFISH, 3IDEA, RC4 et NULL (permet dutiliser ESP sans chiffrement des donnes).
Enfin, les transformations utilisables avec IPCOMP sont OUI (transformation propritaire, prciser
par le biais dun attribut), DEFLATE, LZS et V42BIS.
En plus des attributs mentionns ci-dessus, il est possible davoir recours divers attributs pour
prciser le groupe sur lequel effectuer les calculs relatifs DIFFIEHELLMAN, la dure de vie de la
SA, la longueur de la clef pour les algorithmes clef de longueur variable... Ces lments sont dcrits
en dtail dans [RFC 2407].
d/ Bloc ID
Le DOI IPsec ajoute au bloc ID les champs Protocol ID (UDP, TCP...) et Port, et dfinit les modes
didentification suivants :
Adresse IPv4, adresse IPv6
Sous rseau IPv4 ou IPv6 (adresse / masque de sous-rseau)
Plage dadresses IPv4 ou IPv6 (adresse de dbut, adresse de fin)
FQDN (foo.bar.com)
User FQDN (user@foo.bar.com)
Binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501]
binary DER encoding of an ASN.1 X.500 General Name [X.509]
KEY ID : information propre un fournisseur et permettant d'identifier le secret partag pralable
utiliser
30
e/ Bloc N
3 nouveaux messages de statut sont introduits :
RESPONDER-LIFETIME
REPLAY-STATUS
INITIAL-CONTACT
Le DOI IPsec est un document qui dfinit les paramtres ngocis et les conventions relatives
lutilisation de ISAKMP dans le cadre dIPsec.
Le domaine dinterprtation IPsec fait lobjet de la [RFC 2407].
3.3.3. IKE
Si le DOI IPsec prcise la contenu des blocs ISAKMP dans le cadre de IPsec, IKE en revanche utilise
ISAKMP, pour construire un protocole pratique. Le protocole de gestion des clefs associ ISAKMP
dans ce but est inspir la fois dOakley et de SKEME. Plus exactement, IKE utilise certains des
modes dfinis par Oakley et emprunte SKEME son utilisation du chiffrement clef publique pour
lauthentification et sa mthode de changement de clef rapide par change dalas. Dautre part, IKE
ne dpend pas dun DOI particulier mais peut utiliser tout DOI.
IKE comprend 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). Main Mode et Aggressive
Mode sont utiliss durant la phase 1, Quick Mode est un change de phase 2. New Group Mode est un
peu part : ce nest ni un change de phase 1, ni un change de phase 2, mais il ne peut avoir lieu
quune fois une SA ISAKMP tablie ; il sert se mettre daccord sur un nouveau groupe pour de
futurs changes DIFFIEHELLMAN.
a/ Phase 1 : Main Mode et Aggressive Mode

Les attributs suivants sont utiliss par IKE et ngocis durant la phase 1 : un algorithme de
chiffrement, une fonction de hachage, une mthode dauthentification et un groupe pour DIFFIE
HELLMAN.
Trois clefs sont gnres lissue de la phase 1 : une pour le chiffrement, une pour
lauthentification et une pour la drivation dautres clefs. Ces clefs dpendent des cookies, des
alas changs et des valeurs publiques DIFFIEHELLMAN ou du secret partag pralable. Leur calcul
fait intervenir la fonction de hachage choisie pour la SA ISAKMP et dpend du mode
dauthentification choisi. Pour connatre les formules exactes, rfrez-vous [RFC 2409].
Compos de six messages, Main Mode est une instance de lchange ISAKMP Identity Protection
Exchange :
Les deux premiers messages servent ngocier les paramtres IKE : algorithme de chiffrement,
fonction de hachage, mthode dauthentification des tiers et groupe pour DIFFIEHELLMAN.
- Figure 12. Main Mode : exemple de premier change Les quatre mthodes dauthentification possibles sont la signature numrique, deux formes
dauthentification par chiffrement clef publique et lutilisation dun secret partag pralable.
31
Les deux seconds messages permettent ltablissement dun secret partag via lutilisation de
lchange de valeurs publiques DIFFIEHELLMAN.
- Figure 13. Main Mode : second change Le secret partag sert driver des clefs de session, deux dentre elles tant utilises pour
protger la suite des changes avec les algorithmes de chiffrement et de hachage ngocis
prcdemment.
Les deux derniers messages servent lauthentification de des valeurs publiques.
- Figure 14. Main Mode : troisime et dernier change Aggressive Mode est une instance de lchange ISAKMP Aggressive Exchange : il combine les
changes dcrits ci-dessus pour Main Mode de faon ramener le nombre total de messages trois.
Dans ces deux cas, la mthode choisie pour lauthentification influence le contenu des messages et la
mthode de gnration de la clef de session. La [RFC 2409] dtaille les messages changs dans
chaque cas et les formules de calcul des signatures et empreintes.
b/ Phase 2 : Quick Mode

Les messages changs durant la phase 2 sont protgs en authenticit et en confidentialit
grce aux lments ngocis durant la phase 1. Lauthenticit des messages est assure par lajout
dun bloc HASH aprs len-tte ISAKMP, et la confidentialit est assure par le chiffrement de
lensemble des blocs du message.
Quick Mode est utilis pour la ngociation de SA pour des protocoles de scurit donns comme
IPsec. Chaque ngociation aboutit en fait deux SA, une dans chaque sens de la communication.
Plus prcisment, les changes composant ce mode ont le rle suivant :
Ngocier un ensemble de paramtres IPsec (paquets de SA)
changer des nombres alatoires, utiliss pour gnrer une nouvelle clef qui drive de celle de la
SA ISAKMP. De faon optionnelle, il est possible davoir recours un nouvel change
DIFFIE-HELLMAN, afin daccder la proprit de Perfect Forward Secrecy, qui nest pas
fournie si on se contente de gnrer une nouvelle clef partir de lancienne et des alas.
Optionnellement, identifier le trafic que ce paquet de SA protgera, au moyen de slecteurs (blocs
optionnels IDi et IDr ; en leur absence, les adresses IP des interlocuteurs sont utilises)
32
Les changes composant ce mode sont les suivants :
- Figure 15. Quick Mode Ou, en terme de composition des messages par blocs :
Initiator
Responder
HDR*, HASH, SA, NONCE [, KE] [, IDi, IDr]
1
HDR*, HASH, SA, NONCE [, KE] [, IDi, IDr]
2
Clef calcule, attributs de la SA ngocis
HDR*, HASH
3
c/ Les groupes : New Group Mode

Le groupe utiliser pour DIFFIE-HELLMAN peut tre ngoci, par le biais du bloc SA, soit au cours du
Main Mode, soit ultrieurement par le biais du New Group Mode. Dans les deux cas, il existe deux
faons de dsigner le groupe utiliser :
Donner la rfrence dun groupe prdfini : il en existe actuellement quatre, les quatre groupes
Oakley (deux groupes MODP et deux groupes EC2N).
Donner les caractristiques du groupe souhait : type de groupe (MODP, ECP, EC2N), nombre
premier ou polynme irrductible, gnrateurs
33
d/ Phases et modes
Au final, le droulement d'une ngociation IKE suit le diagramme suivant :
Combinaison d'ISAKMP, Oakley et SKEME, IKE (Internet Key Exchange), est le protocole de
gestion de paramtres de scurit utilis par IPsec.
IKE comporte diffrents modes et options :
Durant la phase 1, la ngociation d'une SA ISAKMP peut se faire soit avec Main Mode (6
messages), soit avec Aggressive Mode (3 messages). L'authentification des tiers peut se faire
par secret partag pralable, chiffrement clef publique ou signature.
Durant la phase 2, la ngociation de SA pour IPsec utilise Quick Mode, avec ou sans option de
Perfect Forward Secrecy.
IKE est dcrit dans la [RFC 2409].
34
Annexe A Sigles et acronyme

3DESE
Triple-DES Encryption protocol
AFNOR
AH
Association Franaise de Normalisation

Authentication Header
CAM
CBC
Code dAuthentification de Message

Cipher Block Chaining
DES
DH
DOI
Data Encryption Standard

DIFFIEHELLMAN
Domain Of Interpretation
ESP
Encapsulating Security Payload
FAQ
Frequently Asked Questions
GSS-API
Generic Security Service API
HMAC
a MAC mechanism based on cryptographic Hash functions
IANA
ICMP
ICV
IDEA
IETF
IKE
IP
IPng
IPPCP
IPsec
IPv4
IPv6
ISAKMP
ISO
IV
Internet Assigned Numbers Authority

Internet Control Message Protocol
Integrity Check Value
International Data Encryption Algorithm
Internet Engineering Task Force
Internet Key Exchange
Internet Protocol
IP new generation
IP Payload Compression Protocol
IP security protocol
IP version 4
IP version 6
Internet Security Association and Key Management Protocol
International Standardization Organization
Initialization Vector
MAC
MDn
Message Authentication Code

Message Digest n
OSI
Open Systems Interconnection
PFS
Perfect Forward Secrecy
RACE
RCn
RFC
RIPE
RIPE-MD
RSA
Research and development in Advanced Communication technologies in Europe

RIVESTS Code n
Request For Comments
RACE Integrity Primitives Evaluation
RIPE Message Digest
RIVEST, SHAMIR, ADLEMAN
35
36
SA
SAD
SHA
SKEME
SKIP
SPD
SPI
SSH
SSL
Security Association
Security Association Database
Secure Hash Algorithm
a Versatile Secure Key Exchange Mechanism for Internet
Simple Key management for Internet Protocols
Security Policy Database
Security Parameter Index
Secure SHell
Secure Socket Layer
TCP
TLS
TTL
Transmission Control Protocol

Transport Layer Security
Time To Live
UDP
User Datagram Protocol
VPN
Virtual Private Network
Annexe B Glossaire
Algorithme cryptographique ou de chiffrement
Procd ou fonction mathmatique utilise pour le chiffrement et le dchiffrement. Dans la
cryptographie moderne, lalgorithme est souvent public et le secret du chiffre dpend dun
paramtre appel clef.
Analyse du trafic
Observation des caractristiques extrieures du trafic transitant sur un rseau afin de tenter den
tirer des informations : frquence des transmissions, identits des tiers communicants, quantits
de donnes transfres. Associes des informations de nature diffrente (date de rendez-vous,
actualit...) ces lments peuvent permettre aux adversaires de faire des dductions
intressantes.
Association de scurit (Security Association, SA)
Connexion simplexe (unidirectionnelle) cre pour scuriser des changes. Tout le trafic qui
traverse une SA se voit appliquer les mmes services de scurit. Une SA correspond donc un
ensemble de paramtres, qui caractrisent les services fournis au travers de mcanismes de
scurit comme AH et ESP.
# Voir les chapitres La notion dassociation de scurit page 5 et La gestion des clefs pour
IPsec : ISAKMP et IKE page 23.
Authenticit
Terme utilis dans ce document pour dsigner le service de scurit qui consiste assurer la
fois lintgrit et lauthentification de lorigine des donnes.
Authentification
On distingue deux types dauthentification :
Authentification dun tiers.
Cest laction qui consiste prouver son identit.
Ce service est gnralement rendu par lutilisation dun change dauthentification qui
implique un certain dialogue entre les tiers communicants.
Authentification de lorigine des donnes
Elle sert prouver que les donnes reues ont bien t mises par lmetteur dclar.
Dans ce cas, lauthentification dsigne souvent la combinaison de deux services :
authentification et intgrit en mode non connect. Ces deux services nont en effet pas de
sens sparment et sont souvent fournis conjointement.
Bump-in-the-stack
Une implmentation est dite de type bump-in-the-stack si elle sintercale entre deux couches de
la pile de protocole (par exemple, entre PPP et le modem). La logique ainsi insre est perue
par la couche de rang n comme tant celle de rang n-1 et rciproquement.
CAM - Voir Code dauthentification de message
Certificat
Document lectronique qui renferme la clef publique dune entit, ainsi quun certain nombre
dinformations la concernant, comme son identit. Ce document est sign par une autorit de
certification ayant vrifi les informations quil contient.
37
Chiffrement, chiffrer
Application dun algorithme cryptographique un ensemble de donnes appeles texte en clair
afin dobtenir un texte chiffr.
Le chiffrement est un mcanisme de scurit permettant dassurer la confidentialit des
donnes.
Clef (secrte, publique, prive)
Paramtre dun algorithme de chiffrement ou de dchiffrement, sur lequel repose le secret.
On distingue deux types de clefs :
les clefs secrtes, utilises par les algorithmes symtriques, pour lesquels la clef de
chiffrement et de dchiffrement sont gales.
les couples (clef publique, clef prive), utiliss par les algorithmes asymtriques, pour
lesquels clef de chiffrement et de dchiffrement sont distinctes.
Clef de chiffrement de clefs
Clef utilise exclusivement pour chiffrer dautres clefs, afin de les faire parvenir un interlocuteur. Une clef de chiffrement de clef a gnralement une dure de vie assez longue, par
opposition aux clefs quelle sert chiffrer.
# Voir le chapitre Types de clefs page 16.
Clef de session
Clef ayant une dure de vie trs limite, gnralement une session.
Les clefs de session sont gnralement des clefs secrtes, utilises pour chiffrer les donnes
transmises, et que les tiers communicants gnrent en dbut de communication.
Clef matresse
Clef servant gnrer dautres clefs.
Code dauthentification de message (CAM)
Rsultat dune fonction de hachage sens unique clef secrte. Lempreinte dpend la fois
des donnes et de la clef ; elle nest donc calculable que par les personnes connaissant la clef.
Adjointe aux donnes sur lesquelles elle a t calcule, elle permet de vrifier leur authenticit
(authentification + intgrit).
Confidentialit
Service de scurit qui consiste sassurer que seules les personnes autorises peuvent prendre
connaissance dun ensemble de donnes.
Le mcanisme qui permet dobtenir ce service est gnralement le chiffrement des donnes
concernes laide dun algorithme cryptographique.
On parle aussi de confidentialit du trafic lorsquon dsire empcher lanalyse du trafic en
cachant les adresses source et destination, la taille des paquets, la frquence des changes...
Connexion
Relation logique tablie entre deux entits.
Chaque couche rseau fournit aux couches suprieures un certain nombre de services dont
certains sont dits sans connexion et dautres orients connexion. Dans un service sans
connexion, chaque message est considr comme totalement indpendant des autres et peut tre
envoy tout moment, sans procdure pralable et sans que le destinataire final soit
38
ncessairement prsent ce moment. Cest le cas par exemple de IP, qui noffre quun service
de type remise de datagrammes. Dans un service orient connexion, linitiateur de la
communication doit dabord tablir un lien logique avec lentit avec laquelle il dsire
communiquer. Cette procdure est appele ouverture de la connexion et implique gnralement
de se mettre daccord sur un certain nombre doptions.
Contrle daccs
Service de scurit permettant de dterminer, aprs avoir authentifi un utilisateur, quels sont
ses privilges et de les appliquer. Ce service a pour but dempcher lutilisation dune ressource
(rseau, machine, donnes...) sans autorisation approprie.
Cryptage, crypter
Termes drivs de langlais to encrypt et souvent employs incorrectement la place de
chiffrement et chiffrer. En toute rigueur, ces termes nexistent pas dans la langue franaise.
Si le cryptage existait, il pourrait tre dfini comme linverse du dcryptage, cest--dire
comme laction consistant obtenir un texte chiffr partir dun texte en clair sans connatre la
clef. Un exemple concret pourrait tre de signer un texte choisi en reproduisant un chiffrement
avec la clef prive de la victime. Mais on prfre parler dans ce cas de contrefaon.
Cryptanalyse ou analyse cryptographique
Science qui tudie la scurit des procds cryptographiques pour tenter de trouver des
faiblesses et pouvoir en particulier effectuer un dcryptement avec succs.
Analyse dun systme cryptographique, et/ou de ses entres et sorties, pour en dduire des
variables confidentielles et/ou des donnes sensibles (y compris un texte en clair). [ISO
7498-2]
Cryptogramme
Aussi appel texte chiffr. Donnes obtenues par application dun algorithme de chiffrement.
Le contenu smantique de ces donnes nest pas comprhensible.
Cryptographie
tude du chiffrement et du dchiffrement, ainsi que des procds permettant dassurer
lintgrit, lauthentification...
Discipline incluant les principes, moyens et mthodes de transformation des donnes, dans le
but de cacher leur contenu, dempcher que leur modification passe inaperue et/ou dempcher
leur utilisation non autorise. [ISO 7498-2]
Cryptologie
tude scientifique de la cryptographie et de la cryptanalyse.
Datagramme
Les datagrammes sont des paquets totalement indpendants les uns des autres et circulant en
mode non connect. Par exemple, les paquets dIP et ceux dUDP sont des datagrammes.
Chaque paquet de type datagramme transite travers le rseau avec lensemble des informations ncessaires son acheminement, et notamment les adresses de lexpditeur et du
destinataire. Le routage tant effectu sparment pour chaque datagramme, deux datagrammes
successifs peuvent donc suivre des chemins diffrents et tre reus par le destinataire dans un
ordre diffrent de celui dmission. De plus, en cas de problme dans le rseau, des
datagrammes peuvent tre perdus. Le destinataire doit donc rordonner les datagrammes pour
reconstituer les messages et contrler quaucun datagramme nest perdu.
39
Dchiffrement
Action inverse du chiffrement, lorsque celui-ci est rversible : laide dun algorithme
cryptographique et dune clef, on reconstruit le texte en clair partir du texte chiffr.
Dcryptement, dcryptage
Action qui consiste casser le chiffrement dun texte de faon retrouver le texte en clair
sans connatre la clef qui permet son dchiffrement normal.
Dni de service
Impossibilit daccs des ressources pour des utilisateurs autoriss ou introduction dun
retard pour le traitement doprations critiques. [ISO 7498-2]
Disponibilit
Service de scurit qui assure une protection contre les attaques visant dgrader ou rendre
impossible laccs un service.
Empreinte (digest)
Aussi appel condens.
Chane de taille fixe obtenue par application dune fonction de hachage un ensemble de
donnes.
Encapsulation, encapsuler
Technique qui consiste inclure un paquet dun protocole lintrieur dun paquet dun autre
protocole afin que ce dernier transporte le premier paquet. Lintrt peut tre soit de rendre
possible lutilisation du protocole encapsul sur une liaison possdant le protocole encapsulant,
soit de faire profiter le protocole encapsul des services rendus par le protocole encapsulant. La
faon la plus logique dutiliser lencapsulation est dencapsuler un protocole de niveau
suprieur dans un protocole de niveau infrieur, mais il est galement possible de faire
linverse.
Fonction sens unique
Une fonction sens unique est une fonction facile calculer mais difficile inverser.
La cryptographie clef publique repose sur lutilisation de fonctions sens unique brche
secrte : pour qui connat le secret (i.e. la clef prive), la fonction devient facile inverser.
Fonction de hachage
Aussi appele fonction de condensation.
Fonction qui convertit une chane de longueur quelconque en une chane de taille infrieure et
gnralement fixe ; cette chane est appele empreinte (digest en anglais) ou condens de la
chane initiale.
Fonction de hachage sens unique
Fonction de hachage qui est en plus une fonction sens unique : il est ais de calculer
lempreinte dune chane donne, mais il est difficile dengendrer des chanes qui ont une
empreinte donne. On demande gnralement en plus une telle fonction dtre sans collision,
cest--dire quil soit impossible de trouver deux messages ayant la mme empreinte.
ICV (Integrity Check Value)
Valeur de vrification dintgrit. Cette valeur est calcule par lexpditeur sur lensemble
des donnes protger. LICV est alors envoye avec les donnes protges. En utilisant le
mme algorithme, le destinataire recalcule lICV sur les donnes reues et la compare lICV
originale. Si elles se correspondent, il en dduit que les donnes nont pas t modifies.
40
# Voir le chapitre Authentication Header (AH) page 12.

Implmenter
Anglicisme, de to implement : mettre en uvre, raliser.
Intgrit
Service de scurit qui consiste sassurer que seules les personnes autorises pourront modifier un ensemble de donnes. Dans le cadre de communications, ce service consiste
permettre la dtection de laltration des donnes durant le transfert.
On distingue deux types dintgrit :
Lintgrit en mode non connect permet de dtecter des modifications sur un datagramme
individuel, mais pas sur lordre des datagrammes.
Lintgrit en mode connect permet en plus de dtecter la perte de paquets ou leur
rordonnancement.
Lintgrit est trs lie lauthentification de lorigine des donnes, et les deux services sont
souvent fournis conjointement.
MAC (Message Authentication Code) - Voir Code dauthentification de message
Mascarade (Masquerade, spoofing)
Acte de prtendre tre une autre entit dans le but daccder aux ressources de celle-ci ;
incident au cours duquel un tiers non autoris prtend tre le vritable utilisateur.
Message
Dans le monde des rseaux, un message est une suite de donnes binaires formant un tout
logique pour les tiers communiquants.
Lorsquun message est trop long pour tre transmis dun seul bloc, il est segment et chaque
segment est envoy sparment dans un paquet distinct.
Non-rejouabilit
Garantie quun adversaire ayant intercept des messages au cours dune communication ne
pourra pas les faire passer pour des messages valides en les injectant soit dans une autre
communication, soit plus tard dans la mme communication.
Paquet
Un paquet est une suite de donnes binaires ne pouvant pas dpasser une longueur fixe. Il est
obtenu en dcoupant un message en plusieurs segments et en ajoutant chaque segment un entte contenant un certain nombre dinformations utiles lacheminement de ce paquet sur le
rseau (options, destinataire...).
Donnes de longueur quelconque
Message
Paquet
En-tte
Segment 1
En-tte
Segment 2
En-tte
Segment 3
La taille maximale dun paquet dpend du rseau ; un paquet peut correspondre un message
entier si celui-ci est court, mais en gnral il ne forme pas un tout logique pour le destinataire.
Les paquets sont achemins sparment jusquau destinataire, qui attend la rception de tous les
paquets pour pouvoir reconstituer le message.
41
Passerelle de scurit (security gateway)

Une passerelle de scurit est un systme intermdiaire (par exemple un routeur ou un gardebarrire) qui agit comme interface de communication entre un rseau externe considr comme
non fiable et un rseau interne de confiance. Elle fournit, pour les communications traversant le
rseau non fiable, un certain nombre de services de scurit.
Dans IPsec, une passerelle de scurit est un quipement sur lequel sont implments AH et/ou
ESP de faon fournir des services de scurit aux htes du rseau interne lorsquils
communiquent avec des htes externes utilisant aussi IPsec (soit directement soit par
lintermdiaire dune autre passerelle de scurit).
# Voir le chapitre quipement fournissant IPsec page 8.
Perfect Forward Secrecy (PFS)
Proprit dun protocole dchange de clef selon laquelle la dcouverte, par un attaquant, du ou
des secrets long terme utiliss ne permet pas de retrouver les clefs de sessions.
# Voir le chapitre Proprits des protocoles dchange de clef page 17.
Rejeu
Action consistant envoyer un message intercept prcdemment, en esprant quil sera
accept comme valide par le destinataire.
Rpudiation
Le fait, pour une des entits impliques dans la communication, de nier avoir particip aux
changes, totalement ou en partie. [ISO 7498-2]
Rseau priv virtuel
Rseau compos par un ensemble dhtes et dquipements qui utilisent des protocoles
spcifiques pour scuriser leurs communications.
# Voir le chapitre quipement fournissant IPsec page 8.
RFC (Request For Comment)
Littralement, Appel commentaires. Cest en fait un document dcrivant un des aspects
dInternet de faon relativement formelle (gnralement, spcification dun protocole). Ces
documents sont destins tre diffuss grande chelle dans la communaut Internet et servent
souvent de rfrence. On peut les trouver sur la plupart des sites FTP.
Sans connexion - Voir Connexion
Scellement (seal) - Voir aussi Code dauthentification de message
Mcanisme de scurit permettant dassurer lintgrit et lauthentification de lorigine des
donnes.
Security gateway - Voir Passerelle de scurit
Signature numrique
Donnes ajoutes une unit de donnes, ou transformation cryptographique dune unit de
donnes, permettant un destinataire de prouver la source et lintgrit de lunit de donnes et
protgeant contre la contrefaon (par le destinataire, par exemple). [ISO 7498-2].
Une signature numrique fournit donc les services dauthentification de lorigine des donnes,
dintgrit des donnes et de non-rpudiation. Ce dernier point la diffrencie des codes
dauthentification de message, et a pour consquence que la plupart des algorithmes de
signature utilisent la cryptographie clef publique.
42
Dautre part, la signature peut prendre deux formes :

transformation chiffre : un algorithme cryptographique modifie directement le message
(par exemple chiffrement du message avec une clef prive).
donnes annexes : des donnes supplmentaires sont adjointes au message (par exemple
une empreinte, chiffre avec une clef prive).
Somme de contrle
Condens dun ensemble de donnes, calcul par lexpditeur avant lenvoi des donnes et
recalcul par le destinataire la rception pour vrifier lintgrit des donnes transmises.
SPI (Security Parameter Index)
Bloc de 32 bits qui, associ une adresse de destination et au nom dun protocole de scurit
(par exemple AH ou ESP), identifie de faon unique une association de scurit (SA). Le SPI
est transport dans chaque paquet de faon permettre au destinataire de slectionner la SA qui
servira traiter le paquet. Le SPI est choisi par le destinataire la cration de la SA.
# Voir le chapitre La notion dassociation de scurit page 5.
Texte chiffr
Aussi appel cryptogramme.
Donnes obtenues par application dun algorithme de chiffrement. Le contenu smantique de
ces donnes nest pas comprhensible.
Texte en clair
Donnes intelligibles, dont la smantique est comprhensible.
Tunneling
Technique consistant crer un tunnel entre deux points du rseau en appliquant une
transformation aux paquets une extrmit (gnralement, une encapsulation dans un protocole
appropri) et en les reconstituant lautre extrmit.
Vecteur dinitialisation (Initialization Vector, IV)
Bloc de texte de valeur quelconque servant initialiser un chiffrement avec chanage de blocs,
et donc faire en sorte que deux messages identiques donnent des cryptogrammes distincts.
Virtual Private Network (VPN) - Voir Rseau priv virtuel
43
Annexe C Bibliographie commente
Cette bibliographie liste les principaux documents utiliss pour la ralisation de cette prsentation,
classs par thme. Lindex permet de retrouver rapidement un document daprs sa rfrence.
La plupart des documents cits ci-dessous sont disponibles en ligne. Ainsi, on trouvera les RFC sur de
nombreux sites FTP (par exemple ftp://ftp.normos.org/ietf/rfc/) et les Internet Drafts sur le site de
lIETF (http://www.ietf.org/). Ladresse laquelle trouver un article est indique lorsque celui-ci est
accessible en ligne. ce sujet, la page de la compagnie CRYPTOGRAPHY RESEARCH intitule
Cryptography Author Sites (http://www.cryptography.com/resources/authors/) liste les pages web de
nombreux auteurs, permettant ainsi daccder de nombreux articles.
C.1. Cryptographie
C.1.1. Gnralits
[SCH96]
SCHNEIER Bruce, Cryptographie applique - Algorithmes, protocoles et codes source en C - 2me
dition, International Thomson Publishing France, 1997.
Ce livre est une traduction, le titre original est Applied Cryptography - Protocols, Algorithms, and
Source Code in C - 2nd Edition.
# Livre de rfrence sur la cryptographie moderne.
[RSA - FAQ]
RSA LABORATORIES, Frequently Asked Questions About Todays Cryptography - Version 4.1,
2000.
$ http://www.rsasecurity.com/rsalabs/faq/
# Prsentation rapide de nombreux points de cryptographie sous forme de FAQ.
[LAB98]
LABOURET Ghislaine, Introduction la cryptologie, document de synthse personnel, 1998.
$ http://www.multimania.com/labouret/realisations/cryptologie/
C.1.2. Codes dauthentification de messages

[TSU92]
TSUDIK Gene, Message Authentication with One-Way Hash Functions, ACM Computer Communication Review, Vol. 22, pp. 29-38, 1992.
$ http://www.isi.edu/~gts/paps/t92.ps.gz
# Mthodes du prfixe secret, du suffixe secret et de lenveloppe secrte.
[RFC 2104]
KRAWCZYK Hugo, BELLARE Mihir, CANETTI R, HMAC: Keyed-Hashing for Message
Authentication, RFC 2104, fvrier 1997.
# HMAC.
C.1.3. change de clef

[DOW92]
DIFFIE Whitfield, VAN OORSCHOT Paul C., WIENER Michael J., Authentication and Authenticated
Key Exchanges, Designs, Codes and Cryptography, 2, pp. 107-125, Kluwer Academic Publishers,
1992.
45
# Les protocoles dauthentification mutuelle avec change de clef : dfinition dun protocole sr,
les proprits souhaites pour de tels protocoles, prsentation du protocole STS.
C.1.4. Scurit des rseaux et des changes

[OPP98]
OPPLIGER Rolf, Internet and Intranet Security, Artech House, 1998.
# Prsentation des principales techniques existantes pour scuriser les rseaux TCP/IP. Ce livre
comporte notamment :
un rappel sur le modle OSI et larchitecture TCP/IP,
une introduction rapide la cryptographie,
une prsentation de diffrentes techniques de contrle daccs (gardes-barrires, filtres,
relais),
une prsentation de protocoles scuriss au niveau IP (IPsec et les protocoles de gestion des
clefs correspondants), au niveau transport (SSH, SSL), et au niveau applicatif.
[ISO 7498-2]
International Standardization Organization, Systmes de traitement de linformation :
interconnexion de systmes ouverts - Modle de rfrence de base - Partie 2 : architecture de
scurit, NOR Z 70-102 (NF ISO 7498-2), AFNOR, 1989.
# Description gnrale des services de scurit OSI et des mcanismes associs, et notamment
dfinitions formelles des termes relatifs la scurit des rseaux et des changes.
C.2. IPsec
La prsentation de IPsec dans ce document est base sur les RFC de novembre 1998 du groupe IPsec
lIETF.
Pour obtenir la liste des Internet drafts relatifs IPsec, je vous conseille de consulter la page web du
groupe de travail sur IPsec lIETF (http://www.ietf.org/html.charters/ipsec-charter.html) ou
directement
la
page
listant
les
relatifs
IPsec
Internet
drafts
(http://www.ietf.org/ids.by.wg/ipsec.html).
[RFC 2411]
THAYER Rodney, DORASWAMY Naganand, GLENN R., IP Security Document Roadmap, RFC
2411, novembre 1998.
# Ce document explicite lorganisation des documents qui servent dcrire IPsec.
Voici une reproduction du schma de cette organisation :
46
- Figure 16. Organisation des documents sur IPsec -
C.2.1. Architecture
[RFC 2401]
ATKINSON Randall, KENT Stephen, Security Architecture for the Internet Protocol, RFC 2401,
novembre 1998.
# Prsentation de larchitecture densemble de IPsec et notamment de la notion dassociation de
scurit (Security Association, SA).
C.2.2. Protocole AH
[RFC 2402]
KENT Stephen, ATKINSON Randall, IP Authentication Header, RFC 2402, novembre 1998.
C.2.3. Protocole ESP

[RFC 2406]
KENT Stephen, ATKINSON Randall, IP Encapsulating Security Payload (ESP), RFC 2406,
novembre 1998.
C.2.4. Algorithmes dauthentification

[RFC 1828]
METZGER P., SIMPSON W., IP Authentication using Keyed MD5, RFC 1828, aot 1995.
# Keyed-MD5
[RFC 1852]
METZGER P., SIMPSON W., IP Authentication using Keyed SHA, RFC 1852, septembre 1995.
# Keyed-SHA
[RFC 2403]
MADSON C., GLENN R., The Use of HMAC-MD5-96 within ESP and AH, RFC 2403, novembre
1998.
[RFC 2404]
MADSON C., GLENN R., The Use of HMAC-SHA-1-96 within ESP and AH, RFC 2404, novembre
1998.
[RFC 2857]
PROVOS Niels, KEROMYTIS Angelos, The Use of HMAC-RIPEMD-160-96 within ESP and AH,
RFC 2857, juin 2000.
C.2.5. Algorithmes de chiffrement

[RFC 1829]
KARN P., METZGER P., SIMPSON W., The ESP DES-CBC Transform, RFC 1829, aot 1995.
[RFC 2405]
DORASWAMY Naganand, MADSON C., The ESP DES-CBC Cipher Algorithm With Explicit IV,
RFC 2405, novembre 1998.
47
[RFC 2451]
ADAMS R., PEREIRA R., The ESP CBC-Mode Cipher Algorithms, RFC 2451, novembre 1998.
# CAST-128, RC5, IDEA, Blowfish, DES triple
[RFC 2410]
KENT Stephen, GLENN R., The NULL Encryption Algorithm and Its Use With IPsec, RFC 2410,
novembre 1998.
C.2.6. Gestion des clefs

a/ SKIP
Le dveloppement autour de SKIP se fait actuellement chez Sun Microsystems (www.sun.com) ; Les
informations sur SKIP sont accessibles par le site www.skip.org.
[AMP97]
AZIZ Ashar, MARKSON Tom, PRAFULLCHANDRA Hemma, Simple Key-Management for Internet
Protocols (SKIP), Sun Microsystems Laboratories, avril 1997.
$ http://www.skip.org/spec/SKIP.html
# Spcifications techniques de SKIP ; ce document reprend lInternet draft de SKIP, qui a expir
en 1997.
[draft-ietf-ipsec-skip-07]
AZIZ Ashar, MARKSON Tom, PRAFULLCHANDRA Hemma, Simple Key-Management for Internet
Protocols (SKIP), Internet Draft, a expir, aot 1996.
$ http://www.skip.org/drafts/draft-ietf-ipsec-skip-07.txt
# Le dernier Internet draft de SKIP en date.
[AZI98]
AZIZ Ashar, SKIP Extension for Perfect Forward Secrecy (PFS), Sun Microsystems Laboratories,
fvrier 1998.
$ http://www.skip.org/spec/EPFS.html
# Extension de SKIP pour fournir la proprit de perfect forward secrecy.
b/ PHOTURIS
[RFC 2522]
SIMPSON W. A., KARN Phil, Photuris: Session-Key Management Protocol, RFC 2522, mars 1999.
[RFC 2523]
SIMPSON W. A., KARN Phil, Photuris: Extended Schemes and Attributes, RFC 2523, mars 1999.
c/ SKEME
[KRA96]
KRAWCZYK Hugo, SKEME: A Versatile Secure Key Exchange Mechanism for Internet,
Symposium on Network and Distributed System Security, fvrier 1996.
$ http://info.isoc.org/conferences/ndss96/krawczyk.ps
d/ IKE (ISAKMP/Oakley)
[RFC 2408]
MAUGHAN Douglas, SCHERTLER Mark, SCHNEIDER Mark, TURNER Jeff, Internet Security
Association and Key Management Protocol (ISAKMP), RFC 2408, novembre 1998.
# ISAKMP
48
[RFC 2412]
ORMAN Hilarie, The OAKLEY Key Determination Protocol, RFC 2412, novembre 1998.
# Oakley
[RFC 2409]
HARKINS D., CARREL D., The Internet Key Exchange (IKE), RFC 2409, novembre 1998.
# IKE = ISAKMP/Oakley
e/ Domaine dinterprtation
[RFC 2407]
PIPER Derrell, The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407,
novembre 1998.
C.2.7. Cryptanalyse
[FS99]
FERGUSON Niels, SCHNEIER Bruce, A Cryptographic Evaluation of IPsec, dcembre 1999.
$ http://www.counterpane.com/ipsec.html
[BEL97]
BELLOVIN Steven M., Probable Plaintext Cryptanalysis of the IP Security Protocols, Proceedings
of the Symposium on Network and Distributed System Security, pp. 155-160, fvrier 1997.
$ http://www.research.att.com/~smb/papers/probtxt.ps
[BEL96]
BELLOVIN Steven M., Problem Areas for the IP Security Protocols, Proceedings of the Sixth
Usenix Unix Security Symposium, pp. 1-16, juillet 1996.
$ http://www.research.att.com/~smb/papers/badesp.ps
49

Ipsec Tech PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ipsec Tech PDF

Transféré par

Droits d'auteur :

Formats disponibles

IPSEC : PRSENTATION TECHNIQUE

IPsec : prsentation technique

Mots-clef : scurit, protocoles, IP, cryptographie, confidentialit, intgrit, authentification, gestion

1998-2000, HERV SCHAUER CONSULTANTS

TABLE DES MATIRES

IPsec : prsentation technique G. LABOURET

1.1. Architecture dIPsec

1.1.1. Les mcanismes AH et ESP

1.1.2. La notion dassociation de scurit

IPsec : prsentation technique G. LABOURET

1.1.3. La gestion des clefs et des associations de scurit

1.1.4. Politique de scurit

1998-2000, HERV SCHAUER CONSULTANTS

1.2. Principe de fonctionnement

IP / IPsec (AH, ESP)

- Figure 1. Organisation de IPsec On distingue deux situations :

IPsec : prsentation technique G. LABOURET

Types dutilisations possibles

1.3. Types dutilisations possibles

1.3.1. quipement fournissant IPsec

1998-2000, HERV SCHAUER CONSULTANTS

1.3.2. Modes de fonctionnement

IPsec : prsentation technique G. LABOURET

Rappels sur les services de scurit et les mcanismes associs

2. Les mcanismes de scurit : AH et ESP

2.1. Rappels sur les services de scurit et les mcanismes associs

1998-2000, HERV SCHAUER CONSULTANTS

Les mcanismes de scurit : AH et ESP

2.1.2. Authentification et intgrit

IPsec : prsentation technique G. LABOURET

Authentication Header (AH)

La confidentialit, qui est assure par le chiffrement des donnes.

Lauthenticit (authentification + intgrit), qui est

2.2. Authentication Header (AH)

Index des paramtres de scurit (SPI)

1998-2000, HERV SCHAUER CONSULTANTS

Les mcanismes de scurit : AH et ESP

- Figure 5. Position de AH en mode transport (IPv4) - Avant application de AHEn-tte IP

- Aprs application de AH Nouvel

(except pour les champs variables du nouvel en-tte)

2.3. Encapsulating Security Payload (ESP)

IPsec : prsentation technique G. LABOURET

Encapsulating Security Payload (ESP)

1998-2000, HERV SCHAUER CONSULTANTS

Les mcanismes de scurit : AH et ESP

- Aprs application de ESP En-tte IP

- Aprs application de ESP Nouvel

IPsec : prsentation technique G. LABOURET

Concepts gnraux relatifs la gestion des clefs

3. La gestion des clefs

3.1. Concepts gnraux relatifs la gestion des clefs

3.1.1. Types de clefs

3.1.2. Infrastructures clef publique

1998-2000, HERV SCHAUER CONSULTANTS

La gestion des clefs

3.1.3. change de clefs et authentification

3.1.4. Proprits des protocoles dchange de clef

IPsec : prsentation technique G. LABOURET

Les protocoles dauthentification mutuelle avec change de clef dvelopps pour IP

Voici le droulement du protocole :

3.2. Les protocoles dauthentification mutuelle avec change de clef

1998-2000, HERV SCHAUER CONSULTANTS

La gestion des clefs