HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Techno-Watch >
Go to: HSC Trainings
Télécharger le catalogue des formations
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|  
> Access to the content HTML Beginning of the report  
> Description Report on the IETF 51, which took place in London on 5-10 August 2001.  
> Context & Dates Report made for our news monitoring service .
The difference between the report writing and publishing dates are generally due to corrections and proofreading by the different people who took part in the conference.
18 August 2001 - Report writing
30 August 2001 - Sending to the news monitoring service subscribers
28 February 2002 - Publication on HSC's web site  
> Author Hervé Schauer (Herve.Schauer@hsc.fr) 
> Type  
> Abstract &
Table of content
1. Introduction
2. Policy Framework WG
3. WebDAV (Web-based Distributed Authoring and Versioning)
4. PKIX (X.509 Public Key Infrastructure)
5. DNSEXT
6. HIP (Host Identity Payload)
7. TLS (Transport Layer Security)
8. IPsec
9. IPSRA (IPsec Remote Access)
10. IPSP (IPsec Security Policy)
11. PPVPN (Provider Provisioned Virtual Private Networks)
12. IP Storage
13. Autres groupes
14. SAAG (Security Area Advisory Group)
15. Conclusion
Annexe : Acronymes  
> Related documents
> Copyright © 2002, Hervé Schauer Consultants, all rights reserved.

 

Lors de cet IETF, le plus important en participants après San Diego, le groupe IPsec a décidé du remplacement de protocole de gestion de clés IKE, sans doute par un nouveau protocole qui sera à déterminer plutôt qu'une correction du IKE actuel. L'ensemble des groupes avancent, et on note une arrivée de la sécurité dans des groupes qui ne sont pas dans l'area sécurité. L'algorithme AES s'intègre dans tous les protocoles pouvant l'utiliser.


1. Introduction

L'IETF-51 s'est déroulé à Londres du 5 au 10 août. L'IETF est l'organisme de normalisation pour les protocoles Internet. L'évènement a réuni 2457 participants, soit la plus large participation pour un IETF après l'IETF-49 à San Diego qui en avait réuni 2768. C'est aussi le premier IETF de l'histoire où les Nord-américains ne sont plus la majorité des participants, les USA n'étaient déjà plus la majorité lors des 2 IETF précédents. C'est enfin le record du nombre de pays représentés avec 45.

Pour la première fois les coûts de l'organisation d'une telle semaine de travail ont été exposés, en session plénière. La conférence coûte 3,4 M$. La moitié du budget est consommé par la location des salles (en général 6 sessions en parallèles de 9h00 à 22h00) et les repas (petit déjeuner le matin et pause de l'après-midi), le quart finance le secrétariat de l'IETF, un tiers finance l'édition des RFCs (les normes), et le reste en dépenses diverses dont l'IANA qui enregistre les n° de protocoles. Les participants payent plus de 3/4 de ce budget, et un petit quart vient du sponsoring de l'ISOC. L'ISOC (Internet Society) est l'association de l'Internet. Il existe depuis 1995 un chapitre français et un groupe réunissant une partie des français allant à l'IETF.

HSC participe à l'ensemble des groupes concernant la sécurité, qui sont dans la Security Area de l'IETF, et également à d'autres groupes présentant un intérêt, comme IPv6 et PPVPN, ou ayant la sécurité dans leurs sujet de préoccupation (cette fois ci, c'est le cas de WebDAV, Mobile IP et IP Storage).

Les compte-rendu des groupes sont classé des couches hautes : la politique (Policy framework), les applications (WebDAV), l'infrastructure (PKIX) vers les couches basses : IP lui-même (IPv6) et les applications dans les couches sous IP qui se mettent désormais aussi dessus (ex : IP Storage avec SCSI sur IP).


2. Policy Framework WG

Le groupe Policy définit un modèle de données afin de représenter uniformément la configuration d'un réseau, avec une vue globale dans une approche qui tend à être 'top-down' : des besoins de l'entreprise jusqu'aux périphériques du réseau. La sélection de paquets (selectors), c'est-à-dire le filtrage IP, présent dans le document QoS (QDDIM) a été mise dans le document d'extension au modèle général PCIMe (Policy Core Information Model extensions). Ainsi la modélisation des filtres pour la QoS et la sécurité sera dérivée du même modèle.

Pour en savoir plus :


3. WebDAV (Web-based Distributed Authoring and Versioning)

Le groupe IETF WebDAV a pour objectif d'étendre le protocole HTTP, en vue de normaliser l'usage d'HTTP comme un protocole plus générique pour le travail collaboratif, voir un système de gestion de fichier pour l'Internet. Outre le contrôle d'accès, WebDAV propose le verrouillage de ressources, la gestion d'un espace de dénomination, et plus généralement la gestion de propriétés en XML.

Le draft "WebDAV access control extensions" propose un mécanisme interopérable de contrôle d'accès discrétionnaire pour accéder au contenu des serveurs web. Ce draft normalise des listes de contrôles d'accès dans HTTP, pour avoir une forme de système de gestion de fichier en client/serveur avec un contrôle d'accès normalisé, proche d'un contrôle d'accès Unix.

L'authentification de l'utilisateur est réalisée par toutes les méthodes possibles dans HTTP. Le draft WebDAV-ACL part du principe que l'utilisateur est authentifié, sachant que WebDAV impose le support au minimum de l'authentification par condensé (Digest Authentication) et n'utilise pas l'authentification basique où le mot de passe est en clair. A cette authentification est associée un identificateur fondamental (principal identifier), qui peut aussi représenter un groupe d'utilisateurs.

À une ressource sur le serveur web est associée une liste de contrôle d'accès qui contient un ensemble d'entrées : ACE (Access Control Entries) qui contiennent cet identificateur fondamental et les privilèges alloués ou refusés qui lui sont associés. Quand un identificateur fondamental soumet une opération (une commande HTTP ou WebDAV), le serveur évalue l'entrée associée dans l'ACL de la ressource demandée. Les privilèges supportés sont nombreux car spécifiques au type de ressource, mais en simplifiant il y a la lecture, l'écriture et le changement de propriétaire. Le système n'intègre pas de rôles. Dans un système de contrôle d'accès un rôle est une liste dynamique d'identifiants fondamentaux. Le groupe WebDAV de l'IETF a tenu sa première réunion de tests d'intéropérabilité les 19 et 20 juillet à Santa Cruz en Californie. 58 personnes de 20 organisations dont Adobe, Microsoft et Oracle, ont testé 35 implémentations de WebDAV : 17 clients et 18 serveurs, dont 5 serveurs Open-Source. Presque toutes les combinaisons ont été testées, peu d'entre elles ont fonctionné correctement à ces tous premiers tests, mais cela démontre la dynamique qui existe autour de WebDAV. A l'avenir ces extensions à HTTP pourraient constituer une manière d'étendre le partage de fichiers et le travail collaboratif en s'affranchissant des systèmes propriétaires et des développements spécifiques. Une technologie à considérer pour l'avenir.

Pour en savoir plus :


4. PKIX (X.509 Public Key Infrastructure)

Le groupe PKIX avance sur ses 36 drafts en cours, et n'hésite pas à ouvrir de nouveaux, notamment pour développer des documents de recommandations autour des PKI, en reprenant les documents réalisés à l'ETSI en documents de recommandation (Informational RFCs) :

  • Policy requirements for CAs
  • Security Management and Policy Requirements for CSPs issuing Time Stamps
  • Security Management and policy requirements for CSPs issuing other than Qualified Certificates
  • Electronic signature syntax and encoding formats in XML
  • Technical aspects of signature policies
  • Harmonised provision of status information on CSPs issuing qualified certificates
Les protocoles de validation en ligne des certificats n'ont pas étés traités à cet IETF, ni sur l'état de l'interopérabilité OCSPv1, ni sur OCSP v2 et SCVP, ils sont en cours de convergence vers un protocole unique.

Pour en savoir plus :


5. DNSEXT

Le groupe DNS extensions est celui qui normalise notamment DNSSEC, son principal travail. DNSSEC apporte une méthode de distribution de clés, une authentification de l'origine des données (ainsi que l'intégrité) et l'authentification des requêtes et des transactions. Pour cela les zones sont signées cryptographiquement. Les signatures sont stockées en tant que RR (Resource Record) dans le fichier de zone du serveur de noms. Le stockage des clés publiques et des certificats permet de vérifier les signatures et de distribuer des clés publiques.

Le groupe est en phase de réflexion, face à quatre possibilités :

  1. Terminer la normalisation actuelle de DNSSEC, sans modifications majeures, en y ajoutant que les quelques éléments manquants indispensables.
  2. Accepter quelques ajouts, sachant qu'il faut aussi décider lesquels
  3. Re-concevoir la totalité de DNSSEC avec des propositions nouvelles
  4. Recommencer à zéro, car certains pensent que l'approche actuelle ne fonctionnera jamais, et qu'il faut partir des besoins et de la conception actuelle.

Le groupe a également eu une réunion commune entre les deux groupes de travail DNSEXT & NGtrans, qui avait pour but de finaliser la représentation des adresses IPv6 dans le DNS. Deux méthodes existent pour représenter les adresses IPv6 dans le DNS ; A6 et AAAA. AAAA est plus ancien que A6 et il est le mode de représentation actuellement déployé au niveau IPv6. Le problèmes est que A6 est plus complexe que AAAA (qui reprend le concept du RR A d'IPv4) et peut dans certains cas poser des problèmes de sécurité (dénis de service en l'occurrence). L'autre problème posé par A6 est que seul Bind 9 le supporte alors que AAAA est supporté par à peu près toutes les mises en oeuvre de Bind (4, 8 et 9). De plus ceux qui ont déployé IPv6 ont déployé AAAA et non A6. L'avantage de A6 sur AAAA est qu'il est beaucoup plus facile de faire des re-numérotations de réseau complet. Le vote a été fait au 'hum' et non pas à mains levées mais le résultat est le suivant : déploiement de AAAA et A6 passe de standard a expérimental.

Pour en savoir plus :


6. HIP (Host Identity Payload)

HIP, est une proposition de Bob Moscowitz (TrueSecure, anciennement ICSA), qui vise à créer un nouvel espace de dénomination dans l'Internet, en remplaçant l'adresse IP par une clé publique (a cryptographic-based Host Identity). Cette clé publique permettrait d'identifier chaque noeud dans le réseau global de manière unique, indépendante de l'adressage IP. Cette technique pourrait permettre de faciliter l'usage d'IPsec au travers de la traduction d'adresse, et faciliter la combinaison d'IPsec avec la mobilité, sans être un remplacement à IKE.
Une BOF a été faite lors de l'IETF précédent et il avait été décidé de poursuivre les efforts dans le domaine a une large majorité. Cependant lors de la réunion à cet IETF, le groupe n'est pas encore clair sur les problèmes qu'il veut résoudre (échange de clé, mobilité, IPsec et NAT, la pluri-connectivité (multihoming), etc), et aucun charter (description du travail du groupe) n'a pu être effectué.
L'idée a aussi des détracteurs, car un tel projet pourrait mettre en cause la facilité avec laquelle il est possible actuellement de faire du filtrage IP dans le réseau. Une liste de discussion sera ouverte à cette adresse : hipsec-request@lists.freeswan.org

Pour en savoir plus :

  • Les drafts :
    • http://www.ietf.org/internet-drafts/draft-moskowitz-hip-04.txt
    • http://www.ietf.org/internet-drafts/draft-moskowitz-hip-arch-02.txt
    • http://www.ietf.org/internet-drafts/draft-moskowitz-hip-impl-01.txt
  • Le compte-rendu dans les actes de l'IETF-50
  • La liste électronique du groupe : hipsec-request@lists.freeswan.org


7. TLS (Transport Layer Security)

La normalisation de TLS se poursuit. TLS est le protocole de chiffrement entre TCP et les protocoles applicatifs, que l'on retrouve dans HTTPS, SMTP/TLS, LDAPS, etc.
Le travail à noter est le draft d'extension du protocole TLS, qui n'a pu passer en proposition de norme cette fois ci. Ce draft propose notamment des améliorations en vue de l'utilisation d'infrastructure de clés avec TLS sur des petits équipements comme les PDAs et les téléphones portables :

  • La négociation de l'URL du certificat client
  • L'envoi par le client de la liste des certificats racine qu'il possède; pour éviter une négociation longue avec plusieurs poignées de main (handshakes) qui dépassent les capacités mémoire de certains équipements
  • Et pour économiser la bande passante, la possibilité d'utiliser des MACs (hash) tronquées, et pour le serveur de renvoyer au client une réponse OCSP pour éviter d'avoir à transmettre une CRL.
Le groupe travaille activement pour l'intégration d'AES dans TLS.

Pour en savoir plus :

  • Le draft TLS-Extentions : http://www.ietf.org/internet-drafts/draft-ietf-tls-extensions-00.txt
  • L'intégration d'AES dans TLS : http://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-05.txt
  • Présentation sur SSL/TLS


8. IPsec

Le groupe de travail IPsec s'est réunit deux fois lors de cet IETF. Les drafts en cours comme la MIB IPsec suscitent peu de commentaires. Sheila Frankel (NIST) a présenté le nouveau standard américain de chiffrement (AES) pour IPsec ainsi que des différentes implications techniques. L'utilisation d'AES avec le mode dit counter mode fait l'objet de discussions. Pour le moment le seul mode utilisable est CBC (numéros assignés en phases 1 et 2, document publié depuis un moment), qui commence a être bien implémenté. Il est recommandé d'utiliser des groupes DH plus grands avec l'AES. Un document sur l'utilisation de SHA-2 est prévu.

Le groupe a poursuivi ses travaux sur l'utilisation d'IPsec avec SCTP, et sur la traversée de la traduction d'adresse par IPsec (NAT traversal). Les Internet Drafts sur ce sujet vont passer en Last Call. Les autres sujets qui impliqueraient des évolutions d'IKE ont étés éludés sans justification.

Une présentation sur le chiffrement opportuniste (opportunistic encryption) a été faite par Hugh Daniels du projet FreeS/WAN. Cette présentation a généré beaucoup de discussions lors de la session et sur la liste de discussion du groupe de travail. L'un de principaux problèmes à ce mécanisme est qu'il repose sur DNSSEC qui n'est pas déployé sauf dans de rares exceptions comme dans les pays nordiques. Pour en savoir plus : draft-richardson-ipsec-opportunistic-00.txt.

La seconde session IPsec a été consacrée à Son-of-IKE, le remplaçant du protocole de gestion de clés IKE.
Ce que l'on reproche à IKE :

  • IKE est trop complexe de manière générale, et notamment sa mise en oeuvre est complexe.
  • IKE impose une PKI pour un déploiement à grande échelle
  • IKE a trop d'options inutiles : par exemple main mode / aggressive mode, PFS ou non, authentification par signature ou chiffrement, RSA ou DSA, etc
  • IKE a des faiblesses en sécurité :
    • IKE est vulnérable à une attaque par dictionnaire si on utilise un mot de passe de petite taille dans les secrets partagés au préalable (PSK)
    • IKE est sensible à plusieurs attaques en dénis de service (draft-simpson-danger-isakmp-01.txt)
  • IKE pose des problèmes d'interopérabilité
    • Fonctionnalités non encore supportées :
      • Tunnels pour certains services seulement
      • Accès distants : beaucoup d'extensions propriétaires
    • Sources de problèmes :
      • Suppression et renouvellement des tunnels (SA)
      • Il y a encore des cas où les certificats sont mal supportés

Plusieurs propositions ont été faites afin d'améliorer IKE ou de le remplacer. À l'issue d'un vote, une majorité de personnes ne cherchent pas à obtenir une compatibilité descendante au sujet du code qui serait ainsi écrit (réutilisation de l'ancien code de IKE). Le sujet ayant à nouveau été traité en SAAG, il est résumé dans le paragraphe SAAG.


9. IPSRA (IPsec Remote Access)

Le draft DHCP étant passé en last call, le groupe IPSRA se concentre désormais sur la solution d'authentification utilisateur. Le vote conduit dans la liste ayant plus ou moins donné l'avantage à PIC, le travail se fait sur cette proposition. PIC (Pre-IKE credentials) sera la méthode normalisée pour supporter les tunnels sur les nomades avec une authentification de l'utilisateur par les méthodes habituelles (mot de passe, SecureID, etc). Le draft n'a pas encore été implémenté même par ses auteurs, mais le responsable du groupe envisage un last call, ainsi le groupe aura terminé son travail.


10. IPSP (IPsec Security Policy)

Le groupe IPsec Policy s'est concentré sur le modèle du DMTF et ses instanciations, qui avancent normalement.

Eric Vyncke (Cisco) a présenté la nouvelle version du draft "IPsec Policy Configuration Model" (IPCM), qui introduit quelques modifications, et rappelé les dépendances entre les différents modèles de l'IETF et du DMTF. Le draft devrait passer en last call (il devait déjà la dernière fois). Lee Rafalow (IBM) a enchaîné avec une présentation sur les conséquences pour IPSP des extensions au modèle plus général PCIMe du groupe policy framework. La principale discussion a été sur les sélecteurs (nom des listes de contrôles d'accès à l'IETF), et après débat le groupe a décidé de se conformer strictement au RFC2401 (IPsec) et de ne pas ajouter le filtrage des types et messages dans les paquets ICMP, ni le filtrage des protocoles dynamiques. Cela pourra être ajouté plus tard ou mieux ajouté au niveau IPsec compte tenu de la demande.

Les autres documents n'ont pas eu un grand intérêt au sein du groupe.

Pour en savoir plus : http://www.ietf.org/internet-drafts/draft-ietf-ipsp-config-policy-model-03.txt


11. PPVPN (Provider Provisioned Virtual Private Networks)

Le groupe a été un marathon d'une quarantaine de présentations dont 35 nouveaux drafts, avec des idées qui fusent dans tous les sens. Les deux présentations utiles étaient celle des utilisateurs expliquant pourquoi les VPNs leur avaient apporté un plus.

Laurent Perrin d'Equant a expliqué qu'ils utilisaient BGP et des VPN MPLS sur Cisco pour faire des IP VPN. Pour lui les IP VPN construits ainsi permettent plus facilement d'intégrer les besoins des utilisateurs que Frame-Relay ou ATM. Il n'y a pas de chiffrement sur leur IP VPN, car les utilisateurs préfèrent gérer leur chiffrement eux-mêmes CE-à-CE, et de manière générale approvisionner eux-mêmes leurs VPNs à partir d'une connectivité globale any-to-any. L'utilisation d'IPsec en plus entre CE n'empêchera pas en cas de mauvaise configuration qu'un client accède à la donnée d'un autre client.

Geoff Simonds de SAVVIS (un réseau global mondial, spécialisé dans les institutions financières) a expliqué qu'ils utilisaient le principe des routeurs virtuels et OSPF sur Nortel. Il pense qu'OSPF est très stable et qu'une telle architecture reste ouverte à IPsec et MPLS, en offrant une compatibilité avec les réseaux ATM existants et une connectivité Ethernet pour l'utilisateur final. Ils ont simulé plus de 1000 tunnels IP avec ce principe de routeur virtuel. Dans sont cas, les tunnels IPsec commencent juste après le PE et juste devant le PE. Les clés sont gérées par l'opérateur SAVVIS, et non pas par le client final comme chez Equant.

Cela a posé débat et il a classé les utilisateurs en 3 catégories :

  • sécurisation de base : tunnel IPsec de PE à PE géré par l'opérateur
  • réseau sécurisé et confiance dans l'opérateur : tunnel IPsec de CE à CE avec la gestion des clés chez l'opérateur
  • les clients qui veulent contrôler leur sécurité : tunnel IPsec de CE à CE avec la gestion des clés chez le client.

Pour en savoir plus :

  • <(http://ppvpn.francetelecom.com/) Le serveur web du groupe PPVPN, où sont publiés les présentations.


12. IP Storage

Le groupe IP Storage défini les protocoles nécessaires à l'utilisation de réseaux IP pour véhiculer des transferts de blocs, entre des CPUs et des unités de stockage. Bien que l'IETF coïncide avec une réunion ISO du groupe NCITS T11 qui normalise Fiber Channel le groupe se réuni 5 heures. Le groupe IETF IP Storage normalise le protocole iSCSI, qui est une encapsulation sur TCP/IP des protocoles SCSI utilisés pour accéder aux disques, lecteurs de bandes et autres périphériques de stockage. iSCSI est un protocole client/serveur ou le client est un Initiateur (Initiator) et le Serveur un Cible (Target). Les termes Initiateur et Cible sont utilisés par clarté et pour éviter la supposition courante que le serveur a plus de ressource que le client. Dans le cas d'iSCSI, c'est le contraire, le client est plutôt un gros serveur qui a plus de CPU que la baie de disque de l'autre coté.

Pour la première fois ce groupe a abordé l'aspect sécurité du protocole iSCSI par un premier draft de "requirements" sur le sujet.
L'Initiateur et la Cible iSCSI sont au niveau 5, indépendants des ports TCP et des adresses IP, avec leur propre dénomination. L'Initiateur utilise une procédure de "login" pour se connecter à la Cible, et les deux s'authentifient mutuellement. Cette procédure est encore l'objet de nombreuses discussions. Le groupe envisage d'utiliser une authentification IKE, mais sans chiffrer ce qui donne beaucoup d'incohérence, ou alors de chiffrer mais certains ne sont pas d'accord, IPsec et IKE ayant des fonctions inutiles ou inutilisables dans le contexte d'iSCSI.
Les membres du groupe sont soit des ex-cadors en sécurité, soit des novices en sécurité, et le draft "iSCSI security requirements" apparaît comme des souhaits d'ingénieurs et me semble très éloigné des besoins utilisateurs. Par exemple le contrôle d'accès n'est pas vraiment envisagé, ni la normalisation de l'affectation des adresses IP virtuelles aux partitions sur les cibles, ou des ports TCP aux processus sur les initiateurs. Pourtant, la migration vers IP des transferts entre CPU et unités de stockage rend possible l'utilisation des techniques de contrôle d'accès réseau entre processus et données, et il n'y a pas plus rapide qu'un filtrage matériel dans un commutateur. Pour en savoir plus :

  • Le comité T11 de NCITS
  • Le draft des besoins en sécurité pour iSCSI : http://www.ietf.org/internet-drafts/draft-black-ips-iscsi-security-00.txt


13. Autres groupes

Peu de nouveautés dans les autres groupes suivis. Kerberos a reprit de l'intérêt avec l'implémentation Microsoft mais discute de foule de détails qui gênent l'interopérabilité. ICMP Traceback poursuit ses travaux mais qu'il faudra du temps pour que les routeurs des ISPs le supporte. L'objectif d'ICMP Traceback est de permettre de retrouver la véritable origine d'un paquet avec une adresse source usurpée (spoofing).

Pour en savoir plus :

  • Le draft ICMP Traceback : http://www.ietf.org/internet-drafts/draft-ietf-itrace-00.txt


14. SAAG (Security Area Advisory Group)

L'IETF est découpé en 6 "area", et l'area sécurité est la seule a avoir une forme de session plénière avec le SAAG, qui fait un point rapide des activités des groupes et traite des sujets communs comme les algorithmes. A l'IETF-51, le protocole d'échange de clé pour IPsec IKE était le sujet principal.

Les chairs de l'area sécurité ont émis une semaine avant l'IETF un mémorandum sur IKE, stipulant que tout développement autour d'IKE n'était plus autorisé. IKE est déjà trop complexe, et possède des problèmes de sécurité liés à sa complexité, d'où cette décision. Le chair a ré-expliqué cette décision en accord avec les instances de l'IETF (IESG & IAB) en séance.

A mon avis, le problème à la source demeure la politique. ISAKMP (renommé IKE), dont les concepteurs travaillent pour la NSA, n'aurait jamais du être le protocole de gestion de clé choisi pour IPsec face aux autres propositions bien meilleure.

IKE a donc été au coeur des débats, et IKE sera sans doute remplacé par un autre algorithme de gestion de clés, pas un IKE v2 mais quelque chose de nouveau, même si cela n'a pas été formellement décidé. Il y a 5 à 6 propositions pour remplacer IKE, mais le remplaçant qui semble avoir gagné d'avance est JFK (Just Fast Keying) qui n'a encore jamais été publie. Les auteurs de JFK sont Matt Blaze, John Ioannidis, et Steven Bellovin d'AT&T research et Angelos D. Keromytis, Université de Pennsylvanie et bientôt Université de Columbia. Ils étaient plutôt des opposants historiques à ISAKMP. Une des autres propositions citées est SoI de Dan Harkins.

Je pense que la source du problème demeure puisque les jeux semblent déjà largement faits par la politique, sans porter de jugement sur la qualité intrinsèque de JFK qui n'est même pas connu. Comme l'a fait remarqué Sara Bitan il serait préférable de partir des besoins utilisateurs et de se mettre d'accord sur ceux-ci.

Un vote a également donné un très nette majorité en faveur de la normalisation de son-of-IKE dans un groupe séparé du groupe IPsec actuel. L'incidence sur les utilisateurs sera sans doute faible : encore très peu de réseaux utilisent IKE, il y en aura plus d'ici à ce que le nouveau protocole soit déployé, mais la migration est encore réaliste.

Les autres éléments clés sont AES dont c'est l'avènement : son intégration est en cours. Dans quasiment tous les groupes les drafts AES ont été faits : S/MIME, TLS, etc. Enfin il semble que beaucoup de groupes cherchent à fabriquer leur propre sous-ensemble d'IPsec et d'IKE, comme Mobile IP, IP storage, etc. Cette tendance est très certainement néfaste, et démontre que l'existant ne répond pas au besoin.


15. Conclusion

Si IPsec est confirmé, il est d'une part détourné et d'autre part en suspens. Détourné car beaucoup de groupes cherchent à fabriquer leur propre sous-ensemble d'IPsec et d'IKE dans leur situation. En suspens car IKE va être remplacé par un autre protocole et cela portera inévitablement préjudice à IPsec comme des confusions médiatiques l'on déjà fait. Le remplacement d'IKE est cependant nécessaire à la réussite d'IPsec.

A noter que suite à la présentation de la session plénière de Minneapolis faisant état de prévisions de difficultés de routage dans l'Internet, Randy Bush a présenté une vision beaucoup moins apocalyptique et plus rassurante.

Enfin, il semble que les difficultés de mobile IPv6 sont toujours d'actualité, il devient difficile de planifier la sortie d'IPv6 sur les mobiles 3G.

Remerciements

Merci à Ghislaine Labouret, Jean-Baptiste Marchand et Jean-Jacques Bernard pour leurs notes. Merci à Ghislaine Labouret pour sa relecture.


Annexe : Acronymes

AES
Advanced Encryption Standard
Voir: http://csrc.nist.gov/encryption/aes/

CE
Customer Equipment
L'équipement chez l'utilisateur final

HIP
Host Identity Payload

PE
Provider Edge
Le premier équipement chez l'opérateur

WebDAV
Web-based Distributed Authoring and Versioning
Last modified on 7 November 2007 at 16:59:52 CET - webmaster@hsc.fr
Mentions légales - Information on this server - © 1989-2013 Hervé Schauer Consultants