Auteurs : R. Thayer, N.
Doraswamy et R. Glenn
Version française
: Guillaume Desgeorge - http://www.guill.net/
- guill@guill.net
Catégorie :
Information
November 1998
Statut de ce
document
Ce document spécifie
une piste de standards Internet pour la communauté
Internet, et ne sera éprouvé qu'après
plusieurs discussions et suggestions. Referez-vous à l'édition
courante de "Internet Official Protocol Standards" (STD
1) pour savoir l'état de sa standardisation et son statut.
La distribution de cette note illimitée.
Note de Copyright :
Copyright (C) The Internet Society (1998). Tous droits réservés.
Résumé
La suite de protocoles
IPsec est utilisée pour apporter des services
d'authentification et de vie privée sur la couche IP. De
nombreux documents sont utilisés pour décrire cette
suite de protocoles. Les relations et l'organisation de ces divers
documents couvrants le protocole IPsec sont discutés ici.
On trouvera une explication sur que trouver et dans quel document,
et sur quoi inclure dans les nouveaux documents sur les
algorithmes d'authentification et de chiffrement
Table des matières
1.
Introduction
2.
Relations entre les documents IPsec
3.
Les clefs matérielles
4.
Contenu recommandé dans les documents d'algorithme
4.1
Algorithmes d'authentification et de chiffrement
4.2
Algorithmes de chiffrement
4.3
Algorithmes d'authentification
5.
Considérations en terme de sécurité
6.
Remerciements
7.
Références
8.
Adresses des auteurs
9.
Note originale de Copyright
1.
Introduction
Ce document tente de donner
une ligne de conduite pour le développement de spécifications
collatérales décrivant l'utilisation de nouveaux
algorithmes de chiffrement avec le protocole ESP, décrit
dans [ESP] et nouveaux algorithmes de d'authentification utilisés
dans le protocole AH, décrit dans [AH]. ESP et AH font
partie de l'architecture de sécurité d'IP décrite
dans [Arch]. Il y a une recommandation par une procédure
bien connue qui peut être utilisée pour ajouter de
nouveaux algorithmes de chiffrement ou d'authentification à
ESP et AH, pas seulement lorsque l'on construit le document, mais
aussi après que les documents de base ont atteints le
statut de RFC. Suivre la ligne de conduite discutée ci-après
simplifie l'ajout de nouveaux algorithmes et réduit
l'accumulation de documents redondants.
L'objectif, lorsqu'on écrit
un document sur un nouvel algorithme de chiffrement ou
d'authentification est de se concentrer sur l'application de cet
algorithme particulier à AH et ESP. Les concepts généraux
d'AH et d'ESP, les définitions, et les possibilités
sont vus dans les documents ESP et AH. Les algorithmes eux-mêmes
ne sont pas décrits dans ces documents. Cela donne la
possibilité d'ajouter de nouveaux algorithmes et de spécifier
comment un algorithme donné peut interagir avec d'autres
algorithmes. Le but est d'arriver à éviter la
duplication de l'information et un nombre excessif de documents,
appelé aussi l'effet "draft explosion".
2.
Relations entre les documents IPsec
Les documents décrivant
l'ensemble des protocoles IPsec sont divisés en sept
groupes. Ceci est montré par la Figure 1. Il y a un
document principal traitant de l'Architecture, et couvrant les
concepts généraux, les recommandations de sécurité,
les définitions, et les mécanismes qui définissent
la technologie IPsec.
Il y a un document pour le
protocole ESP et un autre pour le protocole AH qui couvrent le
format du paquet et les possibilités générales
de leur protocole respectif. Ces document sur les protocoles
contiennent également des valeurs par défaut lorsque
qu'il y en a, de même que des contenus de bourrage par défaut,
et des conditions pour implémenter des algorithmes. Ces
documents donnent quelques valeurs du document Domain Of
Interpretation [DOI]. Notez que le document DOI fait lui-même
partie du mécanisme des nombres assignés IANA et
donc que les valeurs décrites dans le DOI sont bien
connues. Voir [DOI] pour plus d'informations sur le mécanisme.
L'ensemble des documents "Algorithmes
de chiffrement", représenté sur la gauche, est
l'ensemble des documents décrivant comment les différents
algorithmes de chiffrement sont utilisés pour ESP. Ces
documents sont à leur place dans ce guide et doivent éviter
de répéter le document du protocole ESP et les
documents Algorithmes d'authentification. Des exemples de ces
documents sont [DES-Detroit] et [CBC]. Quand ces algorithmes de
chiffrement, ou d'autres, sont utilisés dans ESP, le
document DOI doit donner certaines valeurs, comme l'identifiant
d'algorithme de chiffrement, donc ces documents doivent être
entrée dans le DOI.
L'ensemble des documents "Algorithmes
d'authentification", représenté sur la droite,
est l'ensemble des documents décrivant comment les
algorithmes d'authentification sont utilisés par ESP et AH.
Ces documents sont à leur place dans ce guide, et doivent éviter
de répéter le document du protocole AH et les
documents Algorithmes de chiffrement. Des exemples de ces
documents sont [HMAC-MD5], et [HMAC-SHA-1]. Quand ces algorithmes,
ou d'autres, sont utilisés pour AH ou ESP, le document DOI
doit donner certaines valeurs, comme le type d'algorithme, donc
ces documents doivent être entrée dans le DOI.
Les "Documents de
gestion de clefs", présenté en bas, sont les
documents qui décrivent les standards IETF de gestion de
clefs. Ces documents offrent également quelques valeurs
pour le DOI. Notez que les objectifs de la gestion de clefs
devraient être indiqués ici, et non, par exemple,
dans les documents des protocoles AH et ESP. Actuellement, ce
cadre représente [ISAKMP], [Oakley], et [Resolution].
Le document DOI, représenté
au milieu , contient les valeurs nécessaires aux autres
documents pour interagir entre eux. Cela comprend par exemple les
algorithmes de chiffrement, les algorithmes d'authentification, et
les paramètres d'exécution comme les durées
de vie des clefs.
+--------------+
| Architecture |
+--------------+
v v
+<-<-<-<-+
+->->->->->-+
v
v
+-----------+
+-----------+
| Protocole |
| Protocole |
| ESP |
| AH |
+-----------+
+-----------+
v v
v v
v +->->->->->->->->->-+
v v
v v
v v
v
v v
v v
v
v +---------------+
+------------------+ v
v | +---------------+ | +------------------+ v
v | | Algorithme de | | | Algorithme d'
| v
v +-| chiffrement | +-|
Authentification | v
v +---------------+
+------------------+ v
v v
v v
v v
+-----+
v v
+>->->->-+->->->->| DOI |-<-<-<-<-<-+-<-<-<-<-<-+
+-----+
^
^
+-----------+
| GESTION |
| DES CLEFS |
+-----------+
Figure 1. Guide des documents IPsec.
3.
Les clefs matérielles (Keying Material)
Le fait de décrire
les algorithmes d'authentification et de chiffrement dans divers
documents soulève le problème de savoir comment les
protocoles de gestion des clefs savent quelle longueur de clef matérielle
est nécessaire pour les différents algorithmes quand
ils sont utilisés avec ESP. Cela soulève également
le problème de savoir comment diviser les clefs matérielles.
Ceci est désigné sous le terme d'information de "découpage
en tranche" ("slicing and dicing")
Chaque document traitant
d'un algorithme de chiffrement ou d'authentification devrait spécifier
les attributs de leurs clefs respectives (par exemple, comment
effectuer le bourrage, où sont les bits de parité,
ordre des clefs pour les algorithmes à plusieurs clefs, et
leur longueur). Les protocoles de gestion de clefs devraient
utiliser la longueur des clefs spécifiée dans leur
document respectif d'algorithme pour générer les
clefs matérielles de la bonne longueur.
Le protocole de gestion de
clefs génère des clefs matérielles
suffisamment fortes et longues pour générer les
clefs des divers algorithmes. Le document d'Architecture IPsec spécifie
comment les clefs sont extraites d'un simple bloc de clefs matérielles
quand plusieurs clefs sont requises (par exemple, avec
l'authentification ESP). Les documents des algorithmes de
chiffrement et d'authentification sont responsables de la spécification
de la taille des clefs et de leur force pour chaque algorithme.
Quoiqu'il en soit, soit la clef matérielle entière
est passée au noyau pour effectuer le découpage en
tranche, soit les clefs sont découpées par le
protocole de gestion de clefs, ce qui revient à un problème
d'implémentation. Le document du protocole AH ne contient
pas ces spécifications.
4.
Contenu recommandé dans les documents d'algorithmes
Le document décrivant
comment un algorithme spécifique d'authentification et de
chiffrement est utilisé devrait contenir les informations
relatives à cet algorithme d'authentification et de
chiffrement. Cette section énumère les informations
qui devraient être donné. L'objectif de ce guide des
documents est que :
- Les informations générales
sur le protocole vont dans les documents respectifs d'AH et d'ESP.
- L'information sur la
gestion des clefs va dans le document de gestion des clefs.
- Les valeurs assignées
et les constantes des objets négociables vont dans le
document DOI.
Les algorithmes
d'authentification et de chiffrement requièrent des
ensembles de paramètres optionnels ou ont des modes d'exécution
optionnels (comme IVs, longueurs des données
d'authentification, et longueurs des clefs). Pour éliminer
une partie de la complexité engendrée par la gestion
des clefs, qui doit négocier beaucoup de paramètres
spécifique à chaque algorithme, les documents
traitant d'algorithmes de chiffrement et d'authentification
choisiront des valeurs fixes pour ces paramètres dès
que c'est techniquement raisonnable et faisable.
Notez que les informations
qui suivent entendent ne donner qu'une ligne de conduite générale.
4.1
Algorithmes de chiffrement et d'authentification
Cette section décrit
les informations qui doivent être inclues dans les documents
traitant d'algorithmes d'authentification et de chiffrement.
Clefs matérielles
- Taille des clefs, dont
les tailles minimum, maximum, recommandées ou/et requises.
Remarque : la section "Considération sur la sécurité"
doit révéler toute faille relative à une
taille spécifique.
- Techniques et
attributs du générateur de nombres pseudo-aléatoires
recommandés ou requis pour apporter des clefs suffisamment
fortes. [RANDOM] donne des recommandations pour générer
de l'aléatoire fort pour une utilisation avec la sécurité.
- Format des clefs matérielles.
- Clefs faibles connues
ou référence à une documentation sur les
clefs faibles connues.
- Traitement recommandé
ou requis en entrée des clefs matérielles comme la génération
ou la vérification de parité.
- Recommandations et/ou
conditions sur les durées de vie des clefs matérielles.
Considérations en
terme de performance
- Toute estimation
disponible sur la performance de cet algorithme.
- Toute donnée
disponible permettant une comparaison (par exemple, face à
DES ou MD5).
- Taille de l'entrée
ou toute autre considération pouvant éprouver ou dégrader
la performance.
Considérations sur
l'environnement ESP
- Toute information
concernant l'interaction entre cet algorithme et les autres
aspects d'ESP, comme l'utilisation de certaines possibilités
d'authentification. Remarque : Comme de nouveaux documents
traitant d'algorithmes de chiffrement et d'authentification sont
appliqués à ESP, des documents futurs devront répondre
à l'interaction avec les algorithmes spécifiés
précédemment.
Contenu de l'entête
et description du format
- Spécifications
de la taille, de la position, et du contenu des champs spécifiques
à l'algorithme non définies dans les documents des
protocoles ESP ou AH (par exemple, IV).
Considérations en
terme de sécurité
- Parler de toute
attaque connue.
- Parler de toute
faiblesse d'implémentation classique et connue, comme
l'utilisation de générateur de nombre aléatoires
faibles.
- Parler de toute procédure
de validation, comme les vecteurs tests. [RFC-2202] est un
document exemple contenant les vecteurs tests pour un ensemble
d'algorithmes d'authentification.
4.2
Algorithmes de chiffrement
Cette section décrit
les informations qui doivent être inclues dans un document
traitant d'un algorithme de chiffrement.
Description de l'algorithme
de chiffrement
- Informations générales
sur comment cet algorithme de chiffrement doit être utilisé
avec ESP.
- Description du
contexte matériel et description formelle de l'algorithme.
- Fonctions de cet
algorithme de chiffrement en étant utilisé avec ESP,
en incluant le chiffrement et/ou l'authentification.
- Mention de toutes les
informations de disponibilité comme les considérations
sur la Propriété Intellectuelle.
- Références,
dans le style de l'IETF, au contexte matériel comme les
documents FIPS.
Modes d'exécution de
l'algorithme
- Description de la façon
dont l'algorithme est exécuté, soit en mode bloc, en
mode flux, ou autre.
- Conditions sur les
formats des blocs entrants et sortants.
- Conditions sur le
bourrage pour cet algorithme. Remarque : Il y a une solution par défaut
pour le bourrage, spécifiée dans le document de base
d'ESP, donc ceci est nécessaire si cette solution par défaut
ne peut pas être utilisée.
- Tout paramètre
d'exécution spécifique à l'algorithme, comme
le nombre de boucles.
- Identifier les paramètres
optionnels et les méthodes optionnelles d'exécution
et choisir des valeurs fixes raisonnables et des méthodes
avec des explications techniques explicites.
- Identifier ces paramètres
optionnels pour lesquels les valeurs et les méthodes
deviennent optionnelles avec des explications techniques
explicites expliquant pourquoi ces valeurs fixées et ces méthodes
devraient ne pas être utilisées.
- Intervalles par défaut
ou requis sur les paramètres optionnels spécifiques à
l'algorithme ne pouvant être fixés.
4.3
Algorithmes d'authentification
Cette section décrit
les informations qui doivent être inclues dans un document
traitant d'un algorithme d'authentification. Dans la pluaprt des
cas, un algorithme d'authentification sera exécuté
de la même façon avec AH et ESP. Cela pourrait être
représenté dans un document d'algorithme
d'authentification unique.
Description de l'algorithme
d'authentification
- Informations générales
sur comment cet algorithme de chiffrement doit être utilisé
avec ESP.
- Description du
contexte matériel et description formelle de l'algorithme.
- Fonctions de cet
algorithme d'authentification en étant utilisé avec
ESP, en incluant le chiffrement et/ou l'authentification.
- Mention de toutes les
informations de disponibilité comme les considérations
sur la Propriété Intellectuelle.
- Références,
dans le style de l'IETF, au contexte matériel comme les
documents FIPS et descriptions définitives des algorithmes
précédents
Modes d'exécution de
l'algorithme
- Description de la façon
dont l'algorithme est exécuté.
- Tout paramètre
d'exécution spécifique à l'algorithme, comme
le nombre de boucles, ou le format des blocs entrants et sortants.
- Conditions sur le
bourrage implicite et explicite pour cet algorithme. Remarque : Il
y a une solution par défaut pour le bourrage, spécifiée
dans le document du protocole AH. Ceci n'est nécessaire que
si cette solution par défaut ne peut pas être utilisée.
- Identifier les paramètres
optionnels et les méthodes optionnelles d'exécution
et choisir des valeurs fixes raisonnables et des méthodes
avec des explications techniques explicites.
- Identifier ces paramètres
optionnels pour lesquels les valeurs et les méthodes
deviennent optionnelles avec des explications techniques
explicites expliquant pourquoi ces valeurs fixées et ces méthodes
devraient ne pas être utilisées.
- Intervalles par défaut
ou requis sur les paramètres optionnels spécifiques à
l'algorithme ne pouvant être fixés.
- Critères de
comparaison des données d'authentification pour cet
algorithme. Remarque : Il y a une solution par défaut pour
la vérification des données d'authentification, spécifiée
dans le document du protocole AH. Ceci n'est nécessaire que
si cette solution par défaut ne peut pas être utilisée
(par exemple, lors de l'utilisation d'un hachage signé)
5.
Considérations en terme de sécurité
Ce document donne un guide
et une ligne de conduite pour écrire des documents traitant
d'algorithmes de chiffrement et d'authentification. Le lecteur
devrait suivre toutes les procédures et lignes de conduite
sur la sécurité décrites dans les documents
Architecture IPsec, Protocole ESP, Protocole AH, Algorithme de
chiffrement, Algorithme d'authentification. Notez que beaucoup
d'algorithmes de chiffrement ne sont pas considérés
sûrs s'ils ne sont pas utilisés avec une sorte de mécanisme
d'authentification.
6.
Remerciements
De nombreux documents
Internet ont été référencés
lors de l'écriture de ce document. En fonction de l'état
des documents par rapport à l'ensembles des standards de
l'IETF, ils ne sont pas forcement disponible dans les RFC de
l'IETF. Dans certains cas, le lecteur peut vouloir savoir quelle
version de ces documents sont référencées.
Ces documents sont :
- DES-Detroit : le style
ANX Workshop d'ESP, basé sur le document Hughes tel qu'il a
été modifié par Cheryl Madson et publié
sur la liste de diffusion ANX
- DOI :
draft-ietf-ipsec-ipsec-doi-02.txt.
- 3DES : c'est <the
Triple-DES shim document>.
- CAST : c'est
draft-ietf-ipsec-esp-cast-128-cbc-00.txt, tel qu'il a été
modifié en relation avec ce document
- ESP :
draft-ietf-ipsec-esp-04.txt, envoyé sur la liste de
diffusion de l'IETF en Mai/Juin 1997.
- AH :
draft-ietf-ipsec-auth-05.txt, envoyé sur la liste de
diffusion de l'IETF en Mai/Juin 1997.
- HUGHES : c'est
draft-ietf-ipsec-esp-des-md5-03.txt
- ISAKMP : Il y a trois
documents décrivant ISAKMP. Ce sont
draft-ietf-ipsec-isakmp-07.txt,
draft-ietf-ipsec-isakmp-oakley-03.txt, et
draft-ietf-ipsec-ipsec-doi-02.txt.
7.
Références
[CBC] Periera, R., and R.
Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451,
Novembre 1998.
[Arch] Kent, S, and R
Atkinson, "Security Architecture for the Internet Protocol",
RFC 2401, Novembre 1998
[DES-Detroit] Madson, C,
and N Doraswamy, "The ESP DES-CBC Cipher Algorithm With
Explicit IV", RFC 2405, Novembre 1998.
[DOI] Piper, D., "The
Internet IP Security Domain of Interpretation for ISAKMP",
RFC 2407, Novembre 1998.
[AH] Kent, S., and R.
Atkinson, "IP Authentication Header", RFC 2402, Novembre
1998.
[ESP] Kent, S., and R.
Atkinson, "IP Encapsulating Security Payload (ESP)", RFC
2406, Novembre 1998.
[HMAC] Krawczyk, K.,
Bellare, M., and R. Canetti, "HMAC : Keyed-Hashing for
Message Authentication", RFC 2104, Février 1997.
[HMAC-MD5] Madson, C.,
and R. Glenn, "The Use of HMAC-MD5 within ESP and AH",
RFC 2403, Novembre 1998.
[HMAC-SHA-1] Madson, C.,
R. Glenn, "The Use of HMAC-SHA-1 within ESP and AH", RFC
2404, Novembre 1998.
[RANDOM] Eastlake, D.,
Crocker, S., and J. Schiller, "Randomness Recommendations for
Security", RFC 1750, Décembre 1994.
[RFC-2202] Cheng, P.,
and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1",
RFC 2202, Mars 1997.
8.
Adresses des auteurs
Rodney
Thayer
Sable Technology
Corporation
246 Walnut Street
Newton, Massachusetts
02160
EMail:
rodney@sabletech.com |
Rodney
Thayer
Sable Technology
Corporation
246 Walnut Street
Newton, Massachusetts
02160
EMail:
rodney@sabletech.com |
Rob
Glenn
NIST
EMail:
rob.glenn@nist.gov |
9.
Note originale de Copyright
Copyright (C) The Internet
Society (1998). Tous droits réservés.
This document and
translations of it may be copied and furnished to others, and
derivative works that comment on or otherwise explain it or assist
in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions
granted above are perpetual and will not be revoked by the
Internet Society or its successors or assigns.
This document and the
information contained herein is provided on an "AS IS"
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|