Algorithmes pour l'échange de clé Internet version 1 (IKEv1)

Statut de ce mémoire

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (2005).

Résumé

Les algorithmes exigés et suggérés dans la spécification originale d'échange de clés Internet version 1 (IKEv1, Internet Key Exchange version 1) ne reflètent pas la réalité actuelle des exigences du marché pour IPsec. La spécification originale permet une sécurité faible et suggère des algorithmes qui ne sont que peu mis en œuvre. Le présent document met à jour la RFC 2409, la spécification d'origine, et est destinée à toutes les mises en œuvre de IKEv1 déployées à ce jour.

1. Introduction

La définition originale de IKEv1, la [RFC2409], a un ensemble d'exigences de niveau DOIT et DEVRAIT qui ne correspond pas aux besoins des utilisateurs de IPsec. Le présent document met à jour la RFC 2409 en changeant les exigences pour les algorithmes qui y sont définis.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

2. Anciennes exigences pour les algorithmes

La RFC 2409 a les exigences de niveau DOIT et DEVRAIT suivantes :

o DES pour le chiffrement DOIT être pris en charge.

o MD5 et SHA-1 pour le hachage et les fonctions HMAC DOIVENT être pris en charge.

o Les secrets pré-partagés pour l'authentification DOIVENT être pris en charge.

o Le groupe 1 MODP Diffie-Hellman (logarithme discret à 768 bits) DOIT être pris en charge.

o TripleDES pour le chiffrement DEVRAIT être pris en charge.

o Tiger pour le hachage DEVRAIT être pris en charge.

o DSA et RSA pour l'authentification avec signatures DEVRAIT être pris en charge.

o RSA pour l'authentification avec chiffrement DEVRAIT être pris en charge.

o Le groupe 2 MODP Diffie-Hellman (logarithme discret à 1024 bits) DEVRAIT être pris en charge.

La RFC 2409 donne deux niveaux d'exigence contradictoires pour les groupe MODP Diffie-Hellman à courbe elliptique. La Section 4 de cette spécification dit que "les mises en œuvre de IKE ... PEUVEN prendre en charge les groupes ECP et EC2N", mais les paragraphes 6.3 et 6.4 disent que les groupes MODP 3 et 4 pour les groupes EC2N DEVRAIENT être pris en charge.

3. Nouvelles exigences pour les algorithmes

On donne ici la liste des nouvelles exigences pour IKEv1. Noter que certaines des exigences sont les mêmes que celles de la RFC 2409, tandis que d'autres ont changé :

o TripleDES pour le chiffrement DOIT être pris en charge.

o AES-128 en mode CBC [RFC3602] pour le chiffrement DEVRAIT être pris en charge.

o SHA-1 pour le hachage et les fonctions HMAC DOIVENT être pris en charge.

o Les secrets pré partagés pour l'authentification DOIVENT être pris en charge.

o AES-128 en mode XCBC pour les fonctions PRF ([RFC3566] et [RFC3664]) DEVRAIT être pris en charge.

o Le groupe 2 MODP Diffie-Hellman (logarithme discret à 1024 bits) DOIT être pris en charge.

o Le groupe 14 MODP Diffie-Hellman (logarithme discret à 2048 bits) [RFC3526] DEVRAIT être pris en charge.

o RSA pour l'authentification avec signatures DEVRAIT être pris en charge.

Si des mises à jour supplémentaires sont faites à IKEv1 à l'avenir, il est alors très probable que la mise en œuvre de AES-128 en mode CBC pour le chiffrement deviendra obligatoire.

Les autres algorithmes qui figuraient sur la liste aux niveaux DOIT et DEVRAIT dans la RFC 2409 sont maintenant au niveau PEUT. Cela inclut DES pour le chiffrement, MD5 et Tiger pour le hachage, le groupe 1 MODP Diffie-Hellman, les groupes MODP Diffie-Hellman avec courbes elliptiques, DSA pour l'authentification avec signatures, et RSA pour l'authentification avec chiffrement.

DES pour le chiffrement, MD5 pour le hachage, et le groupe 1 MODP Diffie-Hellman sont rétrogradés au niveau PEUT à cause de leur faiblesse cryptographique.

Tiger pour le hachage, les groupes MODP Diffie-Hellman avec courbes elliptiques, DSA pour l'authentification avec signatures, et RSA pour l'authentification avec chiffrement sont abandonnés à cause de l'absence de déploiements significatifs et du manque d'interopérabilité.

4. Résumé

5. Considérations sur la sécurité

Le présent document est entièrement sur la sécurité. Tous les algorithmes qui sont soit de niveau DOIT, soit de niveau DEVRAIT dans la section "Nouvelles exigences pour les algorithmes" du présent document sont estimés assez robustes et sûrs au moment de cette rédaction.

6. Références normatives

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2409] D. Harkins et D. Carrel, "L'échange de clés Internet (IKE)", novembre 1998. (Obsolète, voir la RFC4306)

[RFC3526] T. Kivinen et M. Kojo, "Groupes supplémentaires d’exponentiation modulaire (MODP) Diffie-Hellman pour l’échange de clés Internet (IKE)", mai 2003.

[RFC3566] S. Frankel, H. Herbert, "L'algorithme AES-XCBC-MAC-96 et son utilisation avec IPsec", septembre 2003. (P.S.)

[RFC3602] S. Frankel, R. Glenn, S. Kelly, "Algorithme de chiffrement AES-CBC et utilisation avec IPsec", septembre 2003. (P.S.)

[RFC3664] P. Hoffman, "Algorithme AES-XCBC-PRF-128 pour le protocole d'échange de clés Internet (IKE)", janvier 2004. (Obsolète, voir RFC4434) (P.S.)

Adresse de l'auteur

Paul Hoffman

VPN Consortium

127 Segre Place

Santa Cruz, CA 95060

US

mél : paul.hoffman@vpnc.org

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org .

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.