 |
|
||||
|
 |
 |
|||
|
|
||||||||||||
|
|||||||||||||
|
|||||||||||||
|
|||||||||||||
|
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) :
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 :
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.
Pour en savoir plus :
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.
Pour en savoir plus :
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.
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 :
Pour en savoir plus :
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.
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 :
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
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Dernière modification le 7 novembre 2007 à 16:59:52 CET - webmaster@hsc.fr
Informations sur ce serveur - © 1989-2010 Hervé Schauer Consultants |
|
