HSC
Cabinet de consultants en sécurité informatique depuis 1989 - Spécialisé sur Unix, Windows, TCP/IP et Internet
Mode texte : accès au contenu de la page
Hervé Schauer Consultants
Vous êtes ici : Accueil > Ressources > IPsec > Demo d'interop IPsec 2001
Accéder au : Site HSC des formations
Recherche :  
English version
   Services   
o Domaines de compétences
o Conseil & Expertise
o Prestations ISO 27001
o Veille en vulnérabilités
o Audit & Évaluation
o Tests d'intrusion
o Tests de vulnérabilités (TSAR)
o Analyse Forensique
o Certification ARJEL
o Formations
o E-learning
   Conférences   
o Agenda
o Interventions passées
o Tutoriels
   Ressources   
o Index thématique
o Brèves
o Présentations
o Cours
o Articles
o Outils (téléchargement)
o Veille en vulnérabilité
   Société   
o Hervé Schauer
o Offres d'emploi
o Références
o Historique
o Partenariats
o Associations
   Presse et
 communication
 
 
o Newsletter HSC
o Revue de presse
o Communiqués de presse
o Publications
   Contacts   
o Coordonnées
o Requêtes particulières
o Accès à nos locaux
o Hôtels proches de nos locaux
|>|Demo d'interop IPsec 2001  
> Description Informations concernant la mise en oeuvre de la plate-forme de démonstration IKE pour la conférence IPsec 2001 et résultats des tests effectués.
> Table des matières Introduction
Déroulement
Participants
Disposition réseau
Paramètres IKE/IPsec
Résultats des tests
   Tableau récapitulatif
   Succès
   Problèmes liés aux clefs publiques
   Problèmes divers
Fichiers de configuration
> Autres documents PDF Transparents de la présentation effectuée à la conférence IP Security de IIR [3 décembre 2001 - Anglais]
PDF Transparents de la présentation effectuée dans le cadre de la conférence IPsec 2001 [24 octobre 2001 - Anglais]
[Veille]  Compte-rendu de la conférence [29 octobre 2001 - Français]
dir  Compte-rendu de la démonstration d'IPsec 2000 [novembre 2000 - Français/Anglais]
[Thème]  Thème IPsec
> Auteur Ghislaine Labouret
> Droits d'auteur © 2001, Hervé Schauer Consultants, tous droits réservés.

 

IPsec 2001


Introduction

La conférence IPsec 2001, organisée par Upper Side , s'est accompagnée de la mise en oeuvre d'une plate-forme de démonstration et de tests d'interopérabilité IKE/IPsec. L'événement était coordonné par HSC , qui a joué le rôle d'intégrateur, et a surtout mis son expertise en sécurité informatique (et sur IPsec en particulier) au service des participants.

Les buts visés étaient de :

  • Faire au public une démonstration d'interopérabilité effective
  • Donner un aperçu du niveau de fonctionnalités des implémentations IPsec du marché
Cet événement n'est pas un bakeoff, son but n'était pas de faire des tests exhaustifs ou de fonctionnalités avancées.


Déroulement

Cette démonstration s'est déroulée comme suit :

  • Préparation dans les locaux d'HSC du mardi 16 au lundi 22 octobre (week-end exclus).
    • Mise en place du réseau
    • Tests afin de trouver des configurations fonctionnelles

  • Déplacement du matériel vers le centre de conférence (La Défense) le mardi 23 octobre à 7h30 (transporteur prévu à cet effet).
  • Démonstration lors de la conférence IPsec 2001, du mardi 23 (8h00) au jeudi 25 octobre (18h00)
    • La plate-forme était exposée dans le centre de conférence et les fournisseurs pouvaient répondre aux questions du public
    • Ghislaine Labouret du cabinet HSC a présenté la démonstration et passé en revue les résultats obtenus dans une intervention au début de la conférence (transparents)
    • Des journalistes étaient invités à venir voir la démonstration pendant la réception de bienvenue
  • Après la conférence
    • Les participants qui souhaiteraient effectuer des tests supplémentaires peuvent laisser leurs équipements dans le labo d'HSC pour quelques temps
    • Un compte-rendu est publié sur le site web d'HSC et sur celui d'Upper Side


Participants

La liste des équipements mis en oeuvre est la suivante :

FournisseurÉquipementMis en oeuvre par
6WIND 6WINDGate 6200 Series 6WIND
Cisco PIX firewall, version 6.0(1) Ghislaine Labouret
VPN 3000, version 3.1
Routeur 2621, IOS version 12.2(1a) Netcelo
FreeS/WAN snapshot 20011016 (proche de la version 1.91) + X.509 patch v0.9.3 beta Andreas Steffen <andreas.steffen@zhwin.ch>
(auteur du patch X.509 pour FreeS/WAN)
Netasq F100, version 3.5.0 Netasq
Netcelo Netcelo VPN Gateway (isakmpd étendu tournant sur FreeS/WAN 1.91) Netcelo
NetScreen NetScreen NS 100a, version 2.6.1r1 Snaiso, revendeur français
Nortel Contivity Extranet Switch, 1500 version 4.0 Nortel
OpenBSD isakmpd d'OpenBSD-3.0 beta Ghislaine Labouret

Plusieurs vendeurs de solutions PKI ont été contactés pour cette démonstration ; le seul participant a été IDEALX, avec IDX-PKI.


Disposition réseau

Tous les équipements étaient directement interconnectés sur un réseau ethernet 10 base T, simplement constitué de concentrateurs. Un PC connecté au hub faisait office d'analyseur réseau (ethereal).

Nous avons utilisé des adresses IP fixes : chaque équipement s'est vu attribuer une adresse en 192.70.106.xxx et devait utiliser, pour son réseau interne, 10.xxx.0.0/16.

Ces adresses étaient renseignées dans un serveur DNS, avec le domaine ipsec2001.hsc.fr


Paramètres IKE/IPsec

Le cas testé est le suivant :

  • VPN passerelle-à-passerelle entièrement maillé
  • Protection de l'ensemble du trafic entre les réseaux situés derrière les passerelles (réseaux internes)
  • Utilisation de IKE (pas de IPsec manuel)

Paramètres de phase 1 :

  • Main Mode, 3DES, SHA-1, groupe DH 5 ou 2, durées de vie par défaut
  • Authentification des tiers :
    • Signature RSA
    • Certificat des équipements émis par une CA, elle même certifiée par une CA racine
    • recours aux PSK seulement si la signature RSA échoue

Paramètres de phase 2 :

  • Pas de PFS
  • Protection de l'ensemble du trafic entre les réseaux internes
  • Négociation d'ESP en mode tunnel (AES or 3DES, HMAC-SHA-1)
  • Pas de compression

Nous suggérons de tester les situations suivantes :

  • Négociation initiale
  • Renouvellement des clefs
  • Suppression volontaire de SA


Résultats des tests

Le tableau ci-dessus résume les résultats obtenus au 5 novembre 2001 :

Responder
Initiator
6WIND Cisco IOS Cisco PIX Cisco VPN 3000 FreeS/WAN Netasq Netcelo NetScreen Nortel OpenBSD
6WIND                    
Cisco IOS                   Cert local
Cisco PIX                   Cert local
Cisco VPN 3000                    
FreeS/WAN               PSK    
Netasq             N° transform     N° transform
Netcelo                    
NetScreen                    
Nortel                   CA vide
OpenBSD   Cert local
N° prop
Cert local
N° prop
N° proposal            

Légende :
  Succès : RSA_SIG avec échange de certificats en ligne
  Ok, mais en mode dégradé
  Échec : problème sans contournement trouvé, le trafic ne passe pas

Ces résultats ont évolué par rapport à ceux présentés durant la conférence, que vous pouvez consulter dans les transparents de la présentation effectuée le 24 octobre (PDF - 891Ko).

Ci-dessous sont donnés les détails de ces résultats, notamment l'ensemble des limitation, ajustements nécessaires, particularités et bugs détectés.
Voici un index par implémentation de ces points :

Succès

Pour l'ensemble des cases vertes ci-dessus, nous avons trouvé une configuration telle que :

  • La négociation IKE s'est bien déroulée
  • Un test de trafic simple (le plus souvent ping) fonctionne

Dans certains cas, nous avons utilisé des durées de vies courtes de façon à vérifier que le renouvellement des SA se passait bien, mais ces tests n'ont pas été exhaustifs et les résultats n'ont pas été enregistrée. Cependant, aucun bug majeur n'a été découvert à ce niveau

Nous avons eu l'occasion de tester les nouvelles fonctionnalités suivantes :

  • IPv6 : 6WIND & OpenBSD ; il existe un patch pour FreeS/WAN, mais il n'a pas été testé
  • Groupe DH 7 (ECC) : Nortel Contivity & Cisco VPN 3000
  • AES en phase 2 : Netasq (128/256), NetScreen (128), OpenBSD (128/256)
Toutes ses fonctionnalités ont fonctionné au premier essai.

Problèmes liés aux clefs publiques

Le but visé pour cette démonstration était de faire fonctionner les équipements avec une authentification par signature RSA, avec échange de certificats en ligne.

Protocole d'enregistrement

Cette partie concerne la récupération du certificat de la CA et de son propre certificat par un équipement. Les méthodes disponibles étaient :

  • À base de fichiers (PKCS#10 + copier-coller/FTP/disquette) : supporté par tous les équipements excepté Cisco IOS et Cisco PIX.
  • SCEP : Cisco IOS, Cisco PIX, Netcelo, NetScreen
  • CMP : Nortel
IDEALX a implémenté le support de SCEP (Simple Certificate Enrolment Protocol) dans leur PKI pendant la semaine de préparation. CMP n'était pas disponible et n'a donc pas été testé.

Limitations sur les longueurs de clefs

À l'origine, nous avons utilisé pour les CA des clefs de longueur 4096 bits. Bien que les messages d'erreur ne mettent pas explicitement en cause la longueur de clefs, des erreurs sont apparues sur certains équipements :

  • A la réception du certificat d'un interlocuteur, le boîtier Nortel émettait une erreur de vérification de signature.
  • Les équipements Cisco IOS et PIX refusaient le certificat de la CA.

Hiérarchie de certification et CA multiples

Nous avons utilisé une hiérarchie de certification comportant deux CA : une autorité racine (certificat auto-signé) et une autorité opérationnelle (certificat signé par l'autorité racine).

Tous les équipements acceptent sans problème cette hiérarchie simple, à l'exception de Cisco PIX et IOS, qui n'acceptent qu'un certificat de CA unique et auto-signé. Pour ces équipements, nous avons donc généré un certificat auto-signé pour l'autorité opérationnelle. [Note : Depuis la version 12.1(5)T, Cisco IOS supporte le chaînage de certificat.]

Les tests qu'il aurait fallu mener à ce niveau mais pour lesquels nous avons manqué de temps sont :

  • Validation de chemin : regarder de quel(s) certificat(s) de CA l'équipement à besoin.
    A priori, les équipements n'envoient que leur certificat personnel, sans le certificat de la CA émettrice. Donc l'interlocuteur doit posséder les certificats de l'ensemble des CA opérationnelles. Il peut ensuite soit faire confiance directement à ces certificats (cas le plus courant), soit avoir besoin du certificat racine pour les valider.

  • Utilisation de plusieurs CA opérationnelles
    La raison pour laquelle une hiérarchie de certification peut être nécessaire est pour pouvoir déléguer l'émission de certificats à plusieurs CA opérationnelles, toutes certifiées par une CA racine à laquelle les équipements font confiance. On peut aussi utiliser de la certification croisée pour faire interopérer des équipements initialement configurés avec des certificats d'autorités différences. La plupart des équipements participants doivent pouvoir supporter plusieurs CA et peuvent même posséder plusieurs certificats locaux.

Requêtes de certificat

Pendant la négociation IKE, chaque interlocuteur peut demander à l'autre de lui envoyer son certificat par l'inclusion d'un bloc de type CERT_REQ dans un message IKE. Plusieurs comportements sont possibles à ce niveau :

  • Envoi ou non de CERT_REQ
    • La plupart du temps, l'envoi de la requête est systématique. Sur certains équipements (Netasq, Netcelo), l'envoi de CERT_REQ est paramétrable.
    • FreeS/WAN et OpenBSD n'envoient pas de CERT_REQ (fonctionnalité non implémentée). Avec la plupart des équipements, cela ne pose pas de problème, car ils retournent tout de même leur certificat. Mais Cisco IOS et PIX se montrent plus proches de la norme et ne renvoient pas leur certificat dans ce cas. Les solutions suivantes ont été mises en place pour contourner ce problème :
      • FreeS/WAN : Andreas Steffen a implémenté l'envoi de CERT_REQ pendant la préparation de la démonstration. Cette fonctionnalité sera disponible à partie de la version 0.9.3 du patch X.509.
      • OpenBSD : il est possible de palier l'absence d'envoi de certificat en ligne en fournissant une copie locale du certificat ou de la clef publiques de l'interlocuteur. Il s'agit là d'un mode dégradé, d'où la case jaune dans le tableau des résultats.

  • Types de certificat
    Le bloc CERT_REQ comporte un champ permettant d'indiquer le type de certificat requis.
    • L'ensemble des équipements supporte le type X.509-SIG (type 4), c'est ce type que nous avons utilisé. NetScreen supporte aussi PKCS#7 (type 1).
    • Par défaut, NetScreen envoie une requête pour un certificat de type non spécifié (type = 0). Les autres équipements ne supportent pas ce type et retournent une erreur INVALID-CERT-ENCODING. Il faut donc configurer explicitement NetScreen pour utiliser le type 4.

  • Désignation de la CA
    Le bloc CERT_REQ peut optionnellement préciser le nom de l'émetteur souhaité pour le certificat.
    • Pour renvoyer son certificat, Cisco doit recevoir soit une requête sans CA, soit une requête précisant la CA configurée localement (i.e. la CA opérationnelle dans notre cas).
    • OpenBSD présent un bug qui le stoppe au moment de la sélection du certificat à retourner s'il reçoit une requête sans CA (c'est le cas avec Nortel, et NetScreen en configuration par défaut).
    • Les autres équipements ne se soucient pas de la CA et renvoient leur certificat de toute façon.

Contraintes sur les champs des certificats

Les exigences en matière de contenu des différents champs des certificats sont rares :

  • OpenBSD requiert un champ subjectAltName unique, sans quoi une erreur se produit au moment de la lecture du certificat.
  • Nortel requiert les keyUsage digitalSignature et keyEncipherment, mais cette vérification peut désormais être désactivée.

Listes de révocation

La PKI utilisée comportait un serveur web permettant aux équipements de télécharger les listes de révocation.

Le seul problème rencontré a été le suivant : Au début, le boîtier NetScreen, à la réception du certificat d'un interlocuteur, cherchait à se connecter à un serveur LDAP pour récupérer la CRL associée et la validation du certificat échouait, ce qui explique les résultats en PSK seule dans la présentation du 24 octobre. Après avoir manuellement fourni la CRL de la CA opérationnelle au boîtier, il a accepté les certificats et les tests ont pu être repris avec des certificats. Le seul cas qui ne marche toujours pas est FreeS/WAN initiant vers NetScreen, où un nouveau blocage se produit à la fin de la phase 1 côté NetScreen.

Vérification des certificats (autres que validation)

Outre la validation du certificat de l'interlocuteur (dates, signature de la CA, CRL...), il faut s'assurer que le certificat présenté est acceptable pour la négociation en cours. En effet, si l'on peut, dans certains cas, se contenter d'autoriser tout interlocuteur présentant un certificat valide de monter un tunnel avec des droits d'accès communs (accès distants par exemple), il peut aussi être souhaitable de vérifier l'identité de l'interlocuteur afin de savoir quelles autorisations lui accorder En d'autres termes, quand des interlocuteurs différents correspondent à des politiques différentes, ce qui est presque toujours le cas dans un scénario de VPN, la vérification de l'identité est requise ; quand l'authentification repose sur un certificat, cela implique de prendre en compte l'identité annoncée dans le certificat.

Les vérifications suivantes sont effectuées par les différents équipements testés :

  • FreeS/WAN : Le contenu du bloc ID (identifiant) doit être présent dans un des champs du certificat (DN, subjectAltName), l'identifiant étant la clef qui sert à accepter ou non une connexion et qui détermine la politique associée. Il est possible de définir une connexion sans identifiant (i.e. tout certificat valide donne accès), typiquement pour gérer facilement les accès distants.
  • OpenBSD : Le contenu du bloc ID doit être égal au subjectAltName. En supprimant la définition de l'identifiant dans le descriptif de la connexion, cette vérification n'est plus effectuée. La vérification des politiques (et des identifiants) est déléguée au système keynote, qui permet de nombreuses vérifications optionnelles.
  • Autres : Non connues.

Problèmes divers

Restrictions sur les durées de vie

  • Certains équipements (Cisco IOS, 6WIND en configuration par défaut...) n'acceptent pas de durée de vie supérieure à celle configurée localement. Pour interopérer dans les deux sens, ils doivent donc être configurés avec une durée de vie identique.
  • La durée de vie maximale codée en dur dans FreeS/WAN est plus petite que la durée de vie par défaut de certains équipements.

Bloc ID - FQDN versus DER_ASN1_DN

Certains équipements ne supportent qu'un seul de ces deux types, et il n'est parfois pas possible de configurer ce qui sera envoyé. Cela aurait pu causer des problèmes d'interopérabilité, mais ça n'a pas été le cas, soit parce que l'identifiant n'est pas vérifié par l'équipement, soit parce qu'il est possible de désactiver sa vérification. En effet, lors d'une authentification par certificat, les champs du certificats sont généralement préférés au bloc ID pour l'identification de l'interlocuteur.

Bloc ID - Codage du DN

Les deux particularités suivantes ont été remarquées :

  • VPN 3000 utilise le codage T61STRING au lieu du plus classique PRINTABLESTRING pour les champs O et CN. Cela pose problème à FreeS/WAN lors d'une comparaison avec un DN défini en ASCII dans son fichier de configuration ; nous avons donc dû définir le DN en format binaire dans le fichier de configuration de FreeS/WAN.
  • Nortel modifie l'ordre des RDN dans le bloc ID par rapport au contenu du certificat ; ceci a également posé problème à FreeS/WAN, qui a besoin du DN dans le bon ordre.

Proposal versus transform

Un bug un peu complexe détecté pendant les tests et pour lequel un contournement a été trouvé...

Symptômes

Lors des premiers tests entre OpenBSD et les équipements Cisco (IOS, PIX, VPN 3000), un bug étrange s'est produit : lorsque Cisco initiait, tout se passait bien ; mais lorsqu'OpenBSD initiait, l'association de sécurité crée dans le sens Cisco -> OpenBSD l'était avec des SPI différents sur les deux équipements. Le trafic ne pouvait donc passer dans ce sens.

Explication

La configuration de phase 2 côté OpenBSD consistait à proposer deux choix : (1) AES, (2) 3DES. Les équipements Cisco n'acceptent que le 3DES.

Le comportement par défaut d'OpenBSD dans ce cas est d'envoyer, dans le premier message QM, 2 blocs proposal contenant chacun 1 bloc transform (le comportement plus répandu étant d'envoyer 1 seul bloc proposal contenant 2 blocs transform) :

17:57:53.355921 openbsd.ipsec2001.hsc.fr.isakmp> pix.ipsec2001.hsc.fr.isakmp:  [udp sum ok] isakmp v1.0 exchange QUICK_MODE
	cookie: d52e131d5f9b76f9->2eb316965f3c20ec msgid: 4755b931 len: 188
	payload: HASH len: 24
	payload: SA len: 84 DOI: 1(IPSEC) situation: IDENTITY_ONLY
	    payload: PROPOSAL len: 36 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x5ef2ffef
	        payload: TRANSFORM len: 24
	            transform: 1 ID: AES
	                attribute LIFE_TYPE = SECONDS
	                attribute LIFE_DURATION = 1800
	                attribute ENCAPSULATION_MODE = TUNNEL
	                attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
	    payload: PROPOSAL len: 36 proposal: 2 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x8f03ed24
	        payload: TRANSFORM len: 24
	            transform: 1 ID: 3DES
	                attribute LIFE_TYPE = SECONDS
	                attribute LIFE_DURATION = 1800
	                attribute ENCAPSULATION_MODE = TUNNEL
	                attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
	payload: NONCE len: 20
	payload: ID len: 16 type: IPV4_ADDR_SUBNET = 10.200.0.0/255.255.0.0
	payload: ID len: 16 type: IPV4_ADDR_SUBNET = 10.198.0.0/255.255.0.0 [ttl 0] (id 1)
Quand les équipements Cisco reçoivent ce message, ils sélectionnent correctement la proposition en 3DES, mais leur réponse précise le mauvais numéro (1 au lieu de 2) :
17:57:53.366018 pix.ipsec2001.hsc.fr.isakmp> openbsd.ipsec2001.hsc.fr.isakmp:  [udp sum ok] isakmp v1.0 exchange QUICK_MODE
	cookie: d52e131d5f9b76f9->2eb316965f3c20ec msgid: 4755b931 len: 188
	payload: HASH len: 24
	payload: SA len: 48 DOI: 1(IPSEC) situation: IDENTITY_ONLY
	    payload: PROPOSAL len: 36 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x10fb6346
	        payload: TRANSFORM len: 24
	            transform: 1 ID: 3DES
	                attribute ENCAPSULATION_MODE = TUNNEL
	                attribute LIFE_TYPE = SECONDS
	                attribute LIFE_DURATION = 1800
	                attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
	payload: NONCE len: 24
	payload: ID len: 16 type: IPV4_ADDR_SUBNET = 10.200.0.0/255.255.0.0
	payload: ID len: 16 type: IPV4_ADDR_SUBNET = 10.198.0.0/255.255.0.0
	payload: NOTIFICATION len: 28
	    notification: RESPONDER LIFETIMESPI: 0x10fb6346
	        attribute LIFE_TYPE = KILOBYTES
	        attribute LIFE_DURATION = 00465000 [ttl 0] (id 1)
Après enquête, il s'avère que cette modification du numéro de proposition dans la réponse n'est pas interdite par la norme. En effet, le fait de conserver le numéro de proposition original est seulement en SHOULD dans la RFC 2408 (section 4.2 Security Association Establishment) :
   When responding to a Security Association payload, the responder MUST
   send a Security Association payload with the selected proposal, which
   may consist of multiple Proposal payloads and their associated
   Transform payloads.  Each of the Proposal payloads MUST contain a
   single Transform payload associated with the Protocol.  The responder
   SHOULD retain the Proposal # field in the Proposal payload and the
   Transform # field in each Transform payload of the selected Proposal.

OpenBSD est fautif, car il devrait vérifier le contenu de la proposition retournée par Cisco :

   Retention of Proposal and Transform numbers should speed the
   initiator's protocol processing by negating the need to compare the
   respondor's selection with every offered option.  These values enable
   the initiator to perform the comparison directly and quickly.  The
   initiator MUST verify that the Security Association payload received
   from the responder matches one of the proposals sent initially.

Mais OpenBSD ne fait pas de vérification et instancie la SA (telle que décrite par Cisco, en 3DES), mais avec le SPI choisi pour la proposition numéro 1 (AES). Cisco, quant à lui, instancie la SA avec le bon SPI, à savoir celui de la proposition numéro 2. D'où la différence de SPI.

Ce bug a été remonté à OpenBSD et à Cisco.

Solution

Une première solution rapide est de configurer OpenBSD pour n'envoyer qu'une seule proposition, 3DES.

Il est également possible de configurer OpenBSD pour envoyer ses deux propositions dans un seul bloc proposal contenant deux transform (voir le fichier de configuration). Dans ce cas tout se déroule normalement.

Cas de NetScreen

NetScreen utilise la même approche qu'OpenBSD en phase 2, mais associe le même SPI aux deux propositions. En conséquence, la SA s'établit correctement, mais cela semble impliquer que NetScreen ne vérifie pas non plus la proposition sélectionnée.

Numérotation des transform

Quand Netasq envoie plusieurs blocs transform, il leur attribue le même numéro à tous, alors que la RFC 2408 impose une numérotation strictement croissante. OpenBSD et Netcelo détectent cette erreur et refusent la proposition. La solution consiste à ne faire envoyer qu'un seul transform par Netasq. Il s'agit d'un bug déjà connu de racoon, corrigé par un patch.


Fichiers de configuration

Avertissements : Les configurations suivantes sont des configurations de test, elles ne sont pas optimisées et leur sécurité n'est pas garantie

Dernière modification le 15 février 2005 à 09:45:26 CET - webmaster@hsc.fr
Informations sur ce serveur - © 1989-2010 Hervé Schauer Consultants