Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Networld+Interop 2004 - Les nouveaux mécanismes...

Networld+Interop 2004 - Les nouveaux mécanismes de sécurité 802.11, déploiement expérimental

Laurent Butti

November 04, 2004
Tweet

More Decks by Laurent Butti

Other Decks in Technology

Transcript

  1. D1 Le présent document contient des informations qui sont la

    propriété de France Télécom. L'acceptation de ce document par son destinataire implique, de la part de ce dernier, la reconnaissance du caractère confidentiel de son contenu et l'engagement de n'en faire aucune reproduction, aucune transmission à des tiers, aucune divulgation et aucune utilisation commerciale sans l'accord préalable écrit de France Télécom R&D Les nouveaux mécanismes de sécurité pour IEEE 802.11 Déploiement expérimental à France Télécom Div. R&D Networld+Interop, 4 novembre 2004 Laurent BUTTI – France Télécom Division R&D laurent.butti AT francetelecom.com
  2. La communication de ce document est soumise à autorisation de

    France Télécom R&D D2 Agenda s Motivations d’une solution à base de WPA s Description des contraintes et des choix réalisés s Description de l’architecture déployée s Retour d’expérience s Conclusions Cette présentation ne traite pas la problématique des points d’accès illégitimes interconnectés à des réseaux d’entreprise !
  3. La communication de ce document est soumise à autorisation de

    France Télécom R&D D3 Déploiement entreprise – motivations s La solution actuellement déployée à France Télécom Div. R&D est basée sur IPsec QAuthentification forte par certificat sur carte à puce grâce notre PKI QIPsec est considéré comme robuste (si bien utilisé !) – Revu par de nombreux experts en cryptographie s Mais… QLe trafic broadcast/multicast ne transite pas à travers IPsec QLes protocoles non-IP ne transitent pas à travers IPsec (IPX, NetBEUI) QLa sécurité globale repose sur le « mode bloquant » du client IPsec – Il existe de plus une fenêtre de vulnérabilité lorsque le « mode bloquant » n’est pas activé… QL’architecture réseau est ouverte : points d’accès, commutateurs, DHCP, DNS, concentrateur IPsec sont accessibles… – Failles d’implémentations – Quid des attaques par sauts de VLANs (VLAN hopping) ? QAutres points critiques : performances, coûts… – En particulier pour des architectures importantes
  4. La communication de ce document est soumise à autorisation de

    France Télécom R&D D4 Déploiement entreprise – contraintes s Les contraintes en termes de sécurité sont très fortes ! QAuthentification robustes QMécanismes de confidentialité et d’intégrité robustes QArchitecture de réseaux étanche s Mais, les contraintes d’impacts utilisateurs sont plus souples… QLes OS peuvent être migrés QLes OS peuvent être configurés en « dur » QLes utilisateurs peuvent être sensibilisés aux aspects « ergonomie » s Réutilisation des bases d’authentification existantes QLe mécanisme d’authentification doit être choisi en fonction de sa robustesse et des bases d’authentification existantes – PKI Ö EAP-TLS – Shared secret Ö PEAP w/ username/password EAP method; EAP-PSK; EAP-FAST –Prendre en considération l’utilisation de méthodes One Time Password
  5. La communication de ce document est soumise à autorisation de

    France Télécom R&D D5 Déploiement expérimental FT R&D – choix réalisés s Authentification mutuelle et robuste basée sur EAP-TLS QBasée sur notre PKI QJetons d’authentification stockés sur carte à puce QGestion des listes de révocation QPolitique de sécurité : perte de token, … s Chiffrement et intégrité robustes QBasé sur TKIP obligatoire s Mécanisme de gestion des clés robuste QNe pas utiliser WPA en mode « backward-compatible » s Segmentation logique grâce à IEEE 802.1Q QVLAN dédié au trafic utilisateur – Mappage VLAN par SSID QVLAN dédié au trafic d’administration/supervision – VLANs d’expérimentation contrôlés par un mécanisme de filtrage
  6. La communication de ce document est soumise à autorisation de

    France Télécom R&D D6 Déploiement expérimental FT R&D – architecture sRADIUS : QFreeRADIUS QLinux Debian sAdministration : QLinux Debian – SSH, TFTP, SYSLOG – Scripts d’analyse sAccess points : QCisco AP 12xx sClients : QSupplicants : Windows XP SP1 + Patch, tests expérimentaux avec Odyssey Client sur OS Windows 2000 QCartes Wi-Fi : Linksys, Cisco, Centrino
  7. La communication de ce document est soumise à autorisation de

    France Télécom R&D D7 Déploiement expérimental FT R&D – architecture CRL Retrieval Access Point 802.11 AAA VLAN_AAA_ext Trunks 802.1Q SSID mappé VLAN_Utilisateurs _Issy Client 802.11 VLAN_Admin_Issy ADMIN VLAN_Admin_Issy EAP- TLS Switches VLANs VLAN_AAA_ext VLAN_Admin_Issy Access Point 802.11 SSID mappé VLAN_Utilisateurs _Issy VLAN_Utilisateurs_Issy Interco. FT R&D PKI FT R&D Interco. Admin. Réseau FT R&D VLAN_Admin_Rennes DATA EAP Success Keying Material EAP over 802.11 EAP over RADIUS Deriving Session Keys Deriving Session Keys EAP Success 4-way handshake Group key handshake
  8. La communication de ce document est soumise à autorisation de

    France Télécom R&D D8 Déploiement expérimental FT R&D – retour d’expérience s Disponibilité des matériels et des logiciels ! QMatériel certifié WPA n’implique pas disponibilité des firmwares et drivers – Difficile de trouver du matériel réellement utilisable à la date du début du déploiement (en 2003, i.e. ce n’est plus le cas maintenant) QSeul Windows XP (SP1 + patch) supporte WPA – Peut représenter un point bloquant par rapport au parc existant –Migration ? –Coût supplémentaire de logiciel tiers pour OS 98/Me/2000 –Développement logiciel tiers ou s’appuyer sur brique fournie par certains constructeurs de cartes s PKI : problématiques classiques ! QRécupération de la CRL côté réseau (révocation des certificats clients) – Workaround : la récupérer régulièrement ou à chaque authentification QRécupération de la CRL côté client (révocation du certificat serveur) – Workaround : la récupérer après authentification EAP-TLS (cf. RFC 2716), mais pas parfait… QQuid des implémentations des extensions OCSP TLS côté client et serveur ?
  9. La communication de ce document est soumise à autorisation de

    France Télécom R&D D9 Déploiement expérimental FT R&D – retour d’expérience s L’authentification peut être longue (interrogation de la carte à puce) QLa première n’est pas critique car il faut rentrer son code PIN ! QLes jetons sont cachés – Pas besoin de rentrer à nouveau le code PIN s Le hand-over peut être problématique QNécessite une re-authentification complète : maximum ~ 1 seconde – Solution : utiliser TLS session resumption –Evite une session TLS complète – Non supporté dans FreeRADIUS, à développer… QEntraîne une perte de connectivité niveau 2 dans certains cas – Pertes de connexions lors de hand-over longs… QRésolution de ces problématiques dans IEEE 802.11i et dans le Fast roaming Study Group
  10. La communication de ce document est soumise à autorisation de

    France Télécom R&D D10 Conclusions sLes nouveaux mécanismes de sécurité sont déployables sous conditions QChoix techniques considérés comme robustes sur l’authentification et la confidentialité QArchitecture réseau robuste sIls apportent de nouvelles solutions complémentaires à la solution IPsec QSupport du broadcast/multicast, protocoles non-IP… sLa principale barrière au déploiement de WPA est le support côté client ! QSeul Windows XP (SP1 + patch) supporte WPA – Coût en termes de migration ou d’achat de logiciels tiers QMatériel certifié WPA n’implique pas disponibilité des firmwares, drivers et applicatifs – Surtout le cas en 2003
  11. La communication de ce document est soumise à autorisation de

    France Télécom R&D D11 Conclusions sMais aussi, quid de la motivation de passer d’IPsec à WPA ? QPerformances, coûts, usages, hype ? sFaut-il attendre IEEE 802.11i avant de déployer WPA ? QUsages à court terme QDisponibilité des produits WPA et WPA2 QEst-ce que les améliorations de IEEE 802.11i sont critiques dans votre environnement (AES, fast roaming…) QProblématiques de migration vers IEEE 802.11i