Si j'ai bien compris, EAP-TTLS et PEAP partagent le même niveau de sécurité lorsqu'ils sont mis en œuvre dans des réseaux sans fil. Les deux ne fournissent qu'une authentification côté serveur via un certificat.

L'inconvénient d'EAP-TTLS peut être une prise en charge non native dans Microsoft Windows, de sorte que chaque utilisateur doit installer des logiciels supplémentaires.

L'avantage d'EAP-TTLS peut être la prise en charge de mécanismes d'authentification moins sécurisés (PAP, CHAP, MS-CHAP), mais pourquoi en auriez-vous besoin dans un système sans fil moderne et correctement sécurisé?

Quelles sont vos opinions? Pourquoi devrais-je implémenter EAP-TTLS au lieu de PEAP? Disons que j'ai la plupart des utilisateurs Windows, des utilisateurs Linux moyens et moins des utilisateurs iOS, OSX.

Vous pouvez prendre en charge les deux, si votre serveur RADIUS le prend en charge. Cependant, certains clients se connectent "automatiquement" (Mac OS X> = 10.7 + iOS par exemple), et ils peuvent fonctionner moins qu'optimaux si vous prenez en charge plusieurs types, car ils essaient simplement différentes combinaisons jusqu'à ce que l'un d'eux fonctionne, c'est-à-dire qu'ils se connectent avec moins de tracas s'il n'y a qu'une seule façon de se connecter.

Donc, en gros: supportez PEAP uniquement, ou PEAP + TTLS si vous avez des clients qui nécessitent TTLS.

Restrictions client

• les clients iOS ne soutiendront pas EAP-TTLSavec PAP(seulement MsCHAPv2) à moins que vous manuellement (via un ordinateur) installer un profil.

• Les clients Windows ne prendront pas en charge EAP-TTLSles produits prêts à l'emploi (vous devrez installer un logiciel tel que secure2w), sauf s'ils disposent de cartes sans fil Intel.

• Android prend en charge presque toutes les combinaisons de EAPet PEAP.

Restrictions de la base de données de mots de passe

Ainsi, le vrai problème est de savoir comment vos mots de passe sont stockés.

S'ils sont en:

• Active Directory , vous pouvez alors utiliser EAP-PEAP-MsCHAPv2(boîtes Windows) et EAP-TTLS-MsCHAPv2(avec les clients iOS).

• Si vous stockez des mots de passe sur LDAP , vous pouvez utiliser EAP-TTLS-PAP(boîtes Windows) mais vous serez perdu sur iOS.

Problèmes de sécurité importants

• Les deux EAP-TTLSet PEAPutiliser TLS(Transport Layer Security) sur EAP(Extensible Authentication Protocol).

Comme vous le savez peut-être, TLSest une version plus récente de SSLet fonctionne sur la base de certificats signés par une autorité centrale de confiance (autorité de certification - CA).

Pour établir un TLStunnel, le client doit confirmer qu'il parle au bon serveur (dans ce cas, le serveur radius utilisé pour authentifier les utilisateurs). Il le fait en vérifiant si le serveur a présenté un certificat valide, émis par une autorité de certification de confiance.

Le problème est: normalement, vous n'aurez pas de certificat émis par une autorité de certification de confiance, mais un certificat émis par une autorité de certification ad hoc que vous avez créée à cette fin. Le système opérationnel se plaindra aux utilisateurs qu'il ne sait pas que l'autorité de certification et les utilisateurs (selon votre orientation) accepteront volontiers cela.

Mais cela pose un risque majeur pour la sécurité:

Quelqu'un peut configurer un AP escroc dans votre entreprise (dans un sac ou même sur un ordinateur portable), le configurer pour parler à son propre serveur Radius (fonctionnant sur son ordinateur portable ou sur son propre AP escroc).

Si vos clients trouvent que ce point d'accès a un signal plus fort que vos points d'accès, ils essaieront de s'y connecter. Verra une autorité de certification inconnue (les utilisateurs acceptent), établira un TLStunnel, enverra des informations d'authentification sur ce tunnel et le rayon escroc l'enregistrera.

Maintenant, la partie importante: si vous utilisez un schéma d'authentification en texte brut ( PAPpar exemple), le serveur Rogue Ray aura accès aux mots de passe de vos utilisateurs.

Vous pouvez résoudre ce problème en utilisant un certificat valide délivré par une autorité de certification à la fois iOS, Windows (et Android). Ou, vous pouvez distribuer le certificat racine de l'autorité de certification à vos utilisateurs et les informer de refuser la connexion lorsqu'ils voient des problèmes de certificat (bonne chance avec ça).

PEAPv0, PEAPv1 et TTLS ont les mêmes propriétés de sécurité.

PEAP est un wrapper SSL autour d'EAP portant EAP. TTLS est un wrapper SSL autour de TLV de diamètre portant des attributs d'authentification RADIUS.

EAP-TTLS-PAP peut être utile sur EAP-PEAP si les informations d'identification du magasin de la base de données d'authentification principale sont dans un format de hachage non réversible tel que bigcrypt ou tout autre format non compatible avec MSCHAP (NT-OWF) Dans ce cas, il n'est pas possible de s'authentifier à l'aide de l'une des méthodes basées sur CHAP.

Bien que vous puissiez également émuler PAP en utilisant EAP-PEAPv1-GTC, ce n'est pas aussi largement pris en charge par les clients.

PEAP a quelques bagages supplémentaires sur TTLS sous la forme de maux de tête de négociation de version PEAP et d'incompatibilités historiques dans PEAPv1 (comme la magie du client lors de la dérivation de la clé principale de PRF) qui ont fait leur chemin dans les premières implémentations.

Je vois normalement EAP-TTLS implémenté dans les clients intégrés tels que les modules d'abonné en équipement sans fil avec PEAP utilisé davantage par les ordinateurs portables et les combinés mobiles.

EAP-TTLS n'a historiquement pas été pris en charge dans les clients Windows sans avoir à installer de logiciel tiers. EAP-TTLS est désormais pris en charge à partir de Windows 8.

Quelques réflexions supplémentaires:

EAP-TTLS a été inventé par un fournisseur RADIUS. EAP-PEAPv0 a été inventé par Microsoft. EAP-PEAPv1 est issu du processus IETF.

Il y avait un travail supplémentaire de l'IETF sur un PEAPv2 qui aurait rendu le système plus sécurisé par le biais de liaisons cryptographiques aux méthodes d'authentification internes. Cela n'est allé nulle part aussi près que je peux dire.

Comme l'a écrit Disk Eeater, la principale raison pour laquelle les gens utilisent TTLS est que vous pouvez autoriser votre serveur radius à voir le mot de passe en texte clair de cette façon, ce qui peut être utile en fonction de votre backend d'authentification.

Une considération plus récente qui pourrait favoriser PEAP est que SoH est AFAICT uniquement présenté au serveur RADIUS s'il le demande, et la seule façon de le demander sur les systèmes Microsoft est lors d'une session PEAP. Donc, si vous souhaitez obtenir une évaluation de type agent de l'évaluation sans agent (le soutien de plus de fournisseurs AV sera probablement à venir), vous voudrez PEAP, cependant si vous cherchez à contourner un backend OAUTH à 1 facteur en prenant un mot de passe nu (parce que diable, les grands déplacés internes qui ne fourniront pas un service de tunnel intérieur ne méritent rien de moins et leurs utilisateurs n'ont pas la moindre idée de le saisir) utilisent TTLS.

Vous devez considérer les méthodes EAP que le client prend en charge nativement par rapport à des logiciels supplémentaires et les méthodes d'authentification interne prises en charge par le serveur.

PEAP et EAP-TTLS sont conçus pour vous permettre de valider l'identité du serveur, mais vous devez vous assurer que les clients sont correctement configurés pour valider le certificat.

PEAP et MS-CHAPv2 sont bien pris en charge par les clients, mais si votre serveur ne prend pas en charge MS-CHAPv2 (parce que vous ne stockez pas de mots de passe en texte clair), vous devez trouver une autre solution. C'est la principale raison pour laquelle vous verrez des gens utiliser EAP-TTLS et PAP.

Je pense que la connexion automatique bénéficierait des deux options, plus il y a d'options, moins les tracas ... par exemple. si la connexion automatique essaie d'abord TTLS-PAP puis PEAP-MSCHAP, la connexion automatique est plus rapide avec TTLS-PAP disponible. Donc en gros: soutenir les deux, je ne vois pas d'inconvénient.

Étant donné que la sécurité MSCHAP est rompue (google pour "crack mschap") pap avec un mot de passe en texte clair via ttls a le même niveau de sécurité que PEAP-MSCHAP.

Je ne connais aucune différence de sécurité entre EAP-TTLS et PEAP, donc cela se résume essentiellement à la prise en charge, où PEAP est le gagnant.