Access to the content		Beginning of the report
	Description		Report on the IETF 52, which took place in Salt Lake City on 9-14 December 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. 17 December 2001 - Report writing 16 April 2002 - Sending to the news monitoring service subscribers 22 April 2002 - Publication on HSC's web site
	Author		Hervé Schauer (Herve.Schauer@hsc.fr), Ghislaine Labouret
	Type
	Abstract & Table of content		1. Introduction 2. IPsec et IKE 3. IPsec Policy (IPSP) 4. Policy WG 5. PPVPN (Provider Provisioned Virtual Private Networks) 6. IODEF/INCH (Incident Handling) BOF 7. Sub-IP Area (MPLS) 8. Autres groupes sécurité 9. SAAG 10. Conclusion
	Related documents
	Copyright		© 2002, Hervé Schauer Consultants, all rights reserved.

L'IETF-52 s'est déroulé à Salt Lake City (USA) du 9 au 14 décembre. L'IETF est l'organisme de normalisation pour les protocoles Internet. L'évènement a réuni 1800 participants de 29 pays, malgré le 11 septembre. Pour comparaison l'IETF-49 à San Diego en avait réuni 2800 et à l'IETF-50 à Londres 45 pays étaient représentés.

Le groupe IPsec s'est réunion à deux reprises, la seconde réunion étant consacrée exclusivement aux discussions sur le successeur de IKE c'est-à-dire SoI (Son-of-IKE).

Trois propositions de remplacement de IKE ont été présentées :

• JFK (Just Fast Keying) par Bellovin/Keromytis (ATT)
  Steve Bellovin et Angelos Keromytis sont arrivés à la conclusion qu'il n'était pas possible de corriger le protocole IKE et que la meilleure solution était de repartir à zéro avec un tout nouveau protocole. Leur document est pour le moment très léger : il ne définit que le noyau cryptographique et ne rentre pas du tout dans les détails du protocole, qui ne semblent pas encore fixés. Cela rend difficile toute comparaison avec la proposition IKEv2.
  Les principales caractéristiques de JFK sont :
  • vise à posséder une sécurité mathématiquement prouvable
  • fait reposer l'authentification exclusivement sur des certificats
  • beaucoup plus simple que IKE : pas de négociation de paramètres, une seule phase, un seul mode d'utilisation
  Angelos Keromytis a annoncé que des implémentations "test" étaient disponibles, mais qu'elles n'interopéraient pas encore.

• SIGMA par Krawczyk/Bitan (Technion Israel)
  SIGMA est une proposition qui se concentre uniquement sur la partie cryptographique et doit ensuite être incluse dans un protocole réseau.
  Par exemple, l'incorporation de SIGMA dans JFK a été proposée par Hugo Krawczyk et Ran Cannetti sous le nom de LBJ (Less-Bulky Joint).

• IKEv2 par Harkins/Perlman/Kaufman
  Radia Perlman a présenté une proposition de réécriture et de nettoyage complet du protocole IKE. IKEv2 est décrit dans un document unique qui regroupe les informations précédemment réparties dans les RFC 2407 (domaine d'interprétation), 2408 (ISAKMP) et 2409 (IKE). Les possibilités d'extensions associées à la conception modulaire de IKE seraient abandonnées au profit d'un protocole d'un seul tenant, plus simple.
  IKEv2 prend en compte les nombreuses remarques faites au cours du temps sur IKEv1, cherche à clarifier au maximum l'utilisation du protocole et à rendre son implémentation plus facile. Mais IKEv2 introduit aussi une refonte importante, puisque par exemple elle propose de passer à un échange en quatre messages. De fait, le nouveau protocole serait tellement différent de l'actuel qu'il ne serait pas compatible, d'où le changement de numéro de version majeur.

Un problème de fond est que ces propositions arrivent avant que le cahier des charges ne soit complet, puisqu'un tout premier brouillon a été présenté par Cheryl Madson (Cisco) à ce même IETF. Le planning proposé conserve une décision finale à la réunion de Yokohama en juillet 2002.

Les autres points principaux évoqués à cette réunion sont :

• Le draft sur SCTP est pratiquement bouclé : il va être modifié pour une petite correction et passera en last call juste après
• William Dixon a donné un retour d'expérience suites aux tests d'implémentations du draft NAT-Traversal au dernier bakeoff par 8 fournisseurs. Quelques problèmes ont été découverts à cette occasion, notamment la fragmentation due à des certificats de taille trop importante.
• Le groupe IP storage a adopté IPsec/IKE pour sécuriser iSCSI, FCIP et iFCP, il demande au groupe IPsec de commenter son document.
• L'utilisation de l'AES avec IPsec se précise : il y a actuellement un document pour le chiffrement et deux pour l'authenticité des données (SHA-2 et AES-XCBC-MAC-96)
• Steve Kent a proposé une nouvelle version révisée de ESP qui prenne en compte les retours d'expérience et l'évolution des besoins (exemple : augmenter la taille du numéro de séquence pour les hauts débits). Steve prévoit également une nouvelle version de AH et du document d'architecture. Bref, IKE n'est pas le seul à faire peau neuve.

Le modèle de configuration rédigé par Eric Vyncke (Cisco), progresse avec de nombreuses corrections. Il applique à l'approvisionnement de tunnels IPsec le modèle général de gestion de politiques du groupe Policy. Le draft est : http://www.ietf.org/internet-drafts/draft-ietf-ipsp-config-policy-model-04.txt

Cliff Wang (Smartpipes) a présenté un modèle simpliste pour configurer des ensembles de politiques de sécurité de tunnels IPsec : http://www.ietf.org/internet-drafts/draft-wang-cevpn-group-00.txt, proche du Cisco Blueprint sur comment mettre en oeuvre des tunnels IPsec. Cela pourrait être le premier pas vers un document de type "best practice", le groupe n'a rien décidé.

Enfin, le groupe a décidé de normaliser un protocole de découverte de passerelle IPsec, en se basant sur le protocole propriétaire de Cisco TED (Tunnel Endpoint Discovery), déjà disponible sur les routeurs Cisco.
HSC relève cependant qu'il n'y a pas de cahier des charges, pas de document justifiant la nécessité d'un tel protocole, ni encore d'étude sur les risques qu'entraîne un protocole de signalisation pour la découverte automatique. Cette piste de l'auto-découverte des passerelles IPsec avait été explorée au début du groupe, mais n'avait pas abouti. Enfin il n'y a pas de proposition concurrente à celle de Cisco. Pour en savoir plus, les documents suivants peuvent aider :

• Configuring IPSec Tunnel End-point Discovery
• Le document de référence du déploiement IPsec
• La spécification de TED n'est pas disponible sur le web de Cisco.

L'activité et la participation au groupe baissent considérablement.

Le principal document en vie est l'application de Policy Framework à IPsec (voir dans le groupe IPSP), alors qu'il y a peu c'était la configuration de la qualité de service dans l'ensemble d'un réseau qui était l'orientation principale du groupe Policy. Les documents d'approvisionnement de la QoS avancent lentement.

L'approvisionnement de chemins MPLS pourrait donner un nouveau champ d'application aux travaux du groupe. Cependant rien n'a encore été proposé dans ce domaine.

Les modèles normalisés par le groupe Policy ne remportent pas le succès espéré et ne sont pas implémentés par le marché. Le modèle tel qu'il a été défini, au lieu de s'approcher de l'expression du besoin par un décideur, n'est qu'une amélioration à la gestion de réseau telle qu'elle existe. Le modèle est sans doute trop précis et trop lié aux périphériques en tant que tels. Il ne permet pas une véritable vision globale du système d'information tel que cela était proposé lors de la création du groupe en août 1998 (BOF à l'IETF-42).

Sans l'apport d'une vision globale, de tels modèles sont difficiles à déployer sur des réseaux existants, car ils n'apportent pas assez de différence pour faire l'effort de les déployer sur un réseau de production.

À terme, pour pouvoir ajouter un firewall ou un tunnel IPsec aussi facilement que l'on ajoute un nouveau téléphone, il faudra bien que de tels modèles d'approvisionnement soient déployés.

33 drafts ont étés présentés. Parmi ceux-ci, plusieurs concernent l'approvisionnement de tunnels IPsec comme http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-ce-based-01.txt par Cliff Wang (Smartpipes), qui a expliqué que l'on ne pouvait pas configurer un tunnel IPsec avec un utilisateur (CE-based IPsec VPN) sans en même temps configurer le routage. Il semble cohérent lors de l'approvisionnement d'un équipement chez l'utilisateur de le configurer globalement.

Pour en savoir plus : (http://ppvpn.francetelecom.com/) Le serveur web du groupe PPVPN : Le site n'existe plus.

Un nouveau groupe va être créé dans la sécurité : IODEF: Incident Object Description and Exchange Format. Il a ensuite changé son nom en INCH (Incident Handling) lors du SAAG. Ce groupe va normaliser le format d'échange entre les CSIRT. Il s'agit des échanges lorsqu'un incident de sécurité arrive. Le travail a été réalisé à l'origine par TERENA, association des réseaux européens de recherche. La première BOF de ce groupe a conclu à un intérêt général. Cette activité est complémentaire à ce qu'avait réalisé Tristan Debeaupuis sur les avis de vulnérabilités dans le groupe GRIP (http://www.hsc.fr/ressources/normalisation/saf/draft-debeaupuis-saf-00.txt) et ce que fait le groupe IDWG qui normalise un évènement de détection d'intrusion entre des sondes et des analyseurs.

CSIRT : Computer Security Incident Response Team

Pour en savoir plus :

• Incident Taxonomy and Description Working Group at TERENA
• RFC 3067: Incident Object Description and Exchange Format Requirements
• Le prochain premier draft du nouveau groupe, dans sa version TERENA
• La liste du groupe : inch@nic.surfnet.nl

L'area sub-IP en est à se demander si MPLS devrait être normalisé à l'IETF ou pas, si oui dans l'area sub-IP ou une autre. Le groupe n'a pas statué, mais le débat surprends. MPLS se déploie et devient un enjeu de gestion pour les fournisseurs de service.

SECSH (Secure Shell) avance bien et sans accroc, les drafts noyau passent en last call. Le groupe se concentre maintenant sur les extensions et travaille notamment sur la normalisation de SSH File Transfert Protocol.

PKIX (Public-Key Infrastructure X.509) continue à avoir un rythme de travail soutenu avec 24 documents en cours, dont 3 sur le point de passer en RFC (Certificate Profile, CRL Profile, Algorithmes) et 10 qui sont discutés activement par le groupe. Le groupe se concentre sur la notion de service de validation complet (delegated path validation), qui est une extension de l'idée introduite par OCSP ; le cahier des charges est bien avancé et devrait être finalisé pour l'IETF suivant.

Le groupe de travail Kerberos a fait l'objet d'un débat : les vendeurs font inévitablement des extensions au protocole, par exemple Microsoft. Le développement d'un nouveau protocole incompatible a un coût très élevé, aussi de nombreux membres du groupe souhaitent un modèle extensible qui minimise les changements. Le débat porte sur la manière de prévoir ces extensions tout en préservant l'interopérabilité, et éviter l'interopérabilité perdue comme entre MS-Kerberos et MIT-Kerberos. Depuis l'IETF 38, 6 extensions ont été réalisées au protocole Kerberos, aucune ne marche de manière interopérable, à l'exception du choix de l'algorithme de chiffrement. Elles ont finalement toutes été supprimées. Il faut donc voir le problème des extensions globalement plutôt qu'au cas par cas. Sam Hartman (Mekinok) propose d'ajouter des "extention markers" en ASN.1 à la majorité des messages Kerberos, avec un mécanisme pour déterminer la capacité du destinataire à recevoir ou non des messages au nouveau format.

KINK (Kerberized Internet Negotiation of Keys) s'est interrogé sur l'impact de Son-of-IKE sur son protocole et a conclu qu'il n'y en avait pas. Le protocole va passer en last call. Cinq fournisseurs différents ont manifesté leur intention d'implémenter ce protocole.

IDWG (Intrusion Detection Exchange Format) a bouclé ses trois drafts (IDXP, Tunnel et surtout IDMEF). Il n'y a plus de commentaires, ils sont proposés en RFC. Seul NAI est intéressé par créer des extensions à la norme actuelle, ce n'est pas suffisant. Donc sauf incident dans la publication des RFCs, le groupe a terminé son travail et ne se réunira plus.

SMIME (S/MIME Mail Security) a bientôt complété son travail ; les algorithmes obligatoires ont été validés et sont :

• Vérification de signature : DSA et RSA (PKCS#1 v1.5)
• Génération de Signature : DSA ou RSA (PKCS#1 v1.5)
• Fonction de hachage : SHA-1
• Gestion des clefs : RSA (PKCS#1 v1.5)
• Chiffrement : Triple-DES CBC

Le sujet principal de la réunion de l'area sécurité était le signalement des vulnérabilités. Ce sujet a été suscité par un message de Chris Wysopal (@stake) et Steve Christey (Mitre) dans la liste de discussion. Avant l'IETF, Microsoft avait annoncé à grands renforts de publicité qu'il allait tenter d'interdire la publication des failles de sécurité, notamment en faisant publier un RFC le statuant. Contrairement à ce qui était annoncé, ni Microsoft, ni ceux qui l'avaient rejoint dans cette idée (Mitre et @stake) n'ont présenté une proposition de draft interdisant la publication des vulnérabilités. Perry Metzger a rappelé que la situation avant bugtraq et les CERT était désastreuse, donc que la preuve existait que la publication des vulnérabilités contribuait à l'amélioration de la sécurité.

L'IETF demeure assez insensible aux évènements externes et n'est pas ébranlé par la morosité ambiante, il continue son travail. La refonte d'IKE annonce peut-être la maturité pour IPsec et sa généralisation chez les fournisseurs de service.