RFC 2411 : La sécurité d'IP : Guide des documents

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.

-= From guill.net =-