Algorithmes cryptographiques à utiliser dans l’échange de clés Internet version 2 (IKEv2)

Statut de ce mémo

Le présent document spécifie un protocole de normalisation Internet pour la communauté de l'Internet, qui appelle à la discussion et à des suggestions pour son amélioration. Prière de se reporter à l'édition en cours des "Normes de protocole officielles de l'Internet" (STD 1) sur l'état de la normalisation et le statut de ce protocole. La distribution du présent mémo n'est soumise à aucune restriction.

Notice de Copyright

Copyright (C) The Internet Society (2005).

Résumé

La série de protocoles IPsec utilise divers algorithmes cryptographiques pour fournir des services de sécurité. L’échange de clé Internet (IKE, Internet Key Exchange (RFC 2409) et IKEv2) propose un mécanisme pour négocier quels algorithmes devraient être utilisés dans toute association donnée. Cependant, pour assurer l’interopérabilité entre des mises en oeuvre disparates, il est nécessaire de spécifier un ensemble d’algorithmes de mise en oeuvre obligatoire pour garantir qu’il y ait au moins un algorithme qui soit disponible pour toutes les mises en oeuvre. Le présent document définit l’ensemble d’algorithmes qu’il est actuellement obligatoire de mettre en oeuvre au titre de IKEv2, ainsi que les algorithmes qui devraient être mis en oeuvre parce qu’ils pourraient devenir obligatoires dans un avenir proche.

1 Introduction

Le protocole d’échange de clés Internet traite de la négociation des algorithmes cryptographiques entre les deux points d’extrémité d’une association cryptographique. Des mises en oeuvre différentes d’IPsec et d’IKE peuvent fournir des algorithmes différents. Cependant, l’IETF désire que toutes les mises en oeuvre aient les moyens d’interopérer. En particulier, cela exige que IKE définisse un ensemble d’algorithmes d’application obligatoire parce que IKE lui-même utilise de tels algorithmes au titre de ses propres négociations. Il est donc nécessaire de spécifier un ensemble d’algorithmes comme "d’application obligatoire" pour IKE.

La nature de la cryptographie fait que de nouveaux algorithmes apparaissent continuellement et que les algorithmes existants sont continuellement attaqués. Un algorithme supposé être fort aujourd’hui sera prouvé faible demain. Cela étant, le choix d’algorithmes d’application obligatoire devrait être prudent de façon à minimiser la probabilité qu’il soit rapidement compromis. Il faut aussi penser aux considérations de performances car de nombreuses utilisations de IPsec sont dans des environnements où la performance est un souci constant.

Finalement, il est nécessaire de reconnaître que le ou les algorithmes d’application obligatoire doivent changer avec le temps pour s’adapter aux changements de l’environnement. Pour cette raison, la sélection des algorithmes d’application obligatoire a été retirée de la spécification IKEv2 principale et placée dans le présent document. Lorsque le choix des algorithmes changera, ce seul document devrait avoir à être mis à jour.

Dans l’idéal, l’algorithme d’application obligatoire de demain devrait déjà être disponible dans la plupart des mises en oeuvre de IPsec au moment où il sera rendu obligatoire. Pour faciliter cela, nous allons essayer d’identifier dans ce document les algorithmes (connus aujourd’hui). Il n’est pas garanti que les algorithmes dont nous pensons aujourd’hui qu’ils seront obligatoires à l’avenir le deviendront réellement. Tous les algorithmes connus aujourd’hui sont soumis à des attaques cryptographiques et peuvent être cassés à l’avenir.

2 Exigences terminologiques

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRAIT", "NE DEVRAIT PAS", et "PEUT" qui apparaissent dans le présent document sont à interpréter comme décrit dans la [RFC2119].

Quelques termes supplémentaires sont définis :

DEVRAIT+ : Ce terme signifie la même chose que DEVRAIT. Cependant, il est vraisemblable qu’un algorithme marqué DEVRAIT+ sera promu à l’avenir en DOIT.

Devrait- : Ce terme signifie la même chose que DEVRAIT. Cependant, il est vraisemblable qu’un algorithme marqué DEVRAIT- sera dégradé en PEUT dans une future version du présent document.

DOIT- : Ce terme signifie la même chose que DOIT. Cependant, on s’attend jusqu’à un certain point à ce que cet algorithme ne reste pas un DOIT dans un document futur. Bien que ce statut doive être déterminé ultérieurement, il est raisonnable de s’attendre à ce que si une future révision du document altère le statut d’un algorithme DOIT-, il restera au moins un DEVRAIT ou un DEVRAIT-.

3 Sélection d’algorithmes

3.1 Sélection d’algorithmes IKEv2

3.1.1 Algorithmes de chiffrement de charge utile

La charge utile chiffrée de IKEv2 exige à la fois un algorithme de confidentialité et un algorithme d’intégrité. Pou la confidentialité, les mises en oeuvre DOIVENT- mettre en oeuvre 3DES-CBC et DEVRAIENT+ mettre en oeuvre AES-128-CBC. Pour l’intégrité, HMAC-SHA1 DOIT être mis en oeuvre.

3.1.2 Groupes Diffie-Hellman

L’utilisation de plusieurs groupes exponentiels modulaires (MODP, Modular Exponential) est définie dans IKEv2. Ils sont définis à la fois dans le document de base [IKEv2] et dans le document d’extension MODP. Ils sont identifiés par un numéro de groupe. Tous les groupes qui ne figurent pas sur la présente liste sont considérés comme "PEUVENT être mis en oeuvre".

3.1.3 Algorithmes IKEv2 de transformation de type 1

IKEv2 définit plusieurs algorithmes possibles pour le transfert de type 1 (chiffrement). Ils sont définis ci-dessous avec leur statut de mise en oeuvre.

3.1.4 Algorithmes IKEv2 de transformation de type 2

Les algorithmes de transfert de type 2 sont des fonctions pseudo aléatoires utilisées pour générer des valeurs aléatoires lorsque nécessaire.

3.1.5 Algorithmes IKEv2 de transformation de type 3

Les algorithmes de transfert de type 3 sont des algorithmes d’intégrité utilisés pour protéger les données contre l’altération.

4 Considérations sur la sécurité

La sécurité des systèmes fondés sur la cryptographie dépend à la fois de la force des algorithmes cryptographiques choisis et de la force des clés utilisées avec ces algorithmes. La sécurité dépend aussi de l’ingénierie du protocole utilisé par le système pour s’assurer qu’il n’y a pas de moyens non cryptographiques pour contourner la sécurité du système global.

Le présent document concerne lui-même la sélection des algorithmes cryptographiques à utiliser avec IKEv2, et plus précisément la sélection des algorithmes "d’application obligatoire". Les algorithmes identifiés dans ce document comme "DOIT mettre en oeuvre" ou "DEVRAIT mettre en oeuvre" ne sont pas connus pour avoir été cassés à l’heure actuelle, et la recherche cryptographique jusqu’à ce jour nous conduit à penser qu’ils resteront vraisemblablement sûrs dans l’avenir prévisible. Cependant, ceci n’est pas forcément pour toujours. Nous nous attendons donc à ce que des révisions du présent document interviennent de temps en temps pour refléter les meilleures pratiques en cours dans ce domaine.

5 Références normatives

[RFC2409] Harkins, D. et D. Carrel, "L’échange de clés sur Internet (IKE)", RFC 2409, novembre 1998.

[IKEv2] Kaufman, C., Ed., "Protocole d’échange de clés sur Internet (IKEv2)", RFC 4306, décembre 2005.

[RFC2119] Bradner, S., "Mots clés à utiliser dans les RFC pour indiquer les niveaux d’exigences", BCP 14, RFC 2119, mars 1997.

[RFC3526] Kivinen, T. et M. Kojo, "Plus de groupes exponentiels modulaires (MODP) Diffie-Hellman pour l’échange de clés sur Internet (IKE)", RFC 3526, mai 2003.

[RFC2451] Pereira, R. et R. Adams, "Les algorithmes de chiffrement ESP en mode CBC", RFC 2451, novembre 1998.

[RFC2410] Glenn, R. et S. Kent, "L’algorithme de chiffrement NULL et son utilisation avec IPsec", RFC 2410, novembre 1998.

[AES-CBC] Frankel, S., Glenn, R., et S. Kelly, "L’algorithme de chiffrement AES-CBC et son utilisation avecIPsec", RFC 3602, septembre 2003.

[AES-CTR] Housley, R., "Utilisation du mode Contre de la norme de chiffrement évoluée (AES) avec l’encapsulation de charge utile de sécurité (ESP) IPsec", RFC 3686, janvier 2004.

[RFC2104] Krawczyk, H., Bellare, M., et R. Canetti, "HMAC : Hachage de clés pour l’authentification de message", RFC 2104, février 1997.

[AESPRF] Hoffman, P., "L’algorithme AES-XCBC-PRF-128 pour le protocole d’échange de clés sur Internet (IKE)", RFC 3664, janvier 2004.

RFC2403] Madson, C. et R. Glenn, "Utilisation de HMAC-MD5-96 au sein de ESP et AH", RFC 2403, novembre 1998.

[RFC2404] Madson, C. et R. Glenn, "Utilisation de HMAC-SHA-1-96 au sein de ESP et AH", RFC 2404, novembre 1998.

[AES-MAC] Frankel, S. et H. Herbert, "L’algorithme AES-XCBC-MAC-96 et son utilisation avec IPsec", RFC 3566, septembre 2003.

Adresse de l’auteur

Jeffrey I. Schiller
Massachusetts Institute of Technology
Room W92-190
77 Massachusetts Avenue
Cambridge, MA 02139-4307
USA
Tél : +1 (617) 253-0161
mél : jis@mit.edu

Déclaration de copyright

Copyright (C) The Internet Society (2006).

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 y 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 fourni par la Administrative Support Activity (IASA) de l'IETF.