 |
|
||||
|
 |
 |
|||
|
|
||||||||||||
|
|||||||||||||
|
|||||||||||||
|
|||||||||||||
|
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 :
Déroulement
Cette démonstration s'est déroulée comme suit :
Participants
 La liste des équipements mis en oeuvre est la suivante :
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 :
 Paramètres de phase 1 :
Paramètres de phase 2 :
Nous suggérons de tester les situations suivantes :
Résultats des tests
Le tableau ci-dessus résume les résultats obtenus au 5 novembre 2001 :
Légende :
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.
Pour l'ensemble des cases vertes ci-dessus, nous avons trouvé une configuration telle que :
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 :
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 :
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 :
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 :
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 :
Contraintes sur les champs des certificats Les exigences en matière de contenu des différents champs des certificats sont rares :
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 :
Restrictions sur les durées de vie
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. Les deux particularités suivantes ont été remarquées :
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. 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 |
|
]![[Veille]](/gif/icone.veille.png){kind=small}
]
]
![[Thème]](/gif/icone.theme.png){kind=small}
