Restrictions pour les clients

• Clients iOS ne supportera pas EAP-TTLS con PAP (seulement MsCHAPv2 ), sauf si vous installez manuellement (via un ordinateur) un profil.

• Clients Windows ne supportera pas EAP-TTLS (vous devrez installer un logiciel comme secure2w), à moins qu'ils n'aient des cartes sans fil Intel.

• Android supportent presque toutes les combinaisons de EAP y PEAP .

Restrictions de la base de données par mot de passe

Le vrai problème est donc la façon dont vos mots de passe sont stockés.

S'ils y sont :

• Active Directory alors vous pouvez 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 pour iOS.

Importants problèmes de sécurité

• Les deux sites EAP-TTLS y PEAP utiliser TLS (Transport Layer Security) sur EAP (Extensible Authentication Protocol).

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

Pour établir un TLS le client doit confirmer qu'il parle au bon serveur (dans ce cas, le serveur radius utilisé pour authentifier les utilisateurs). Pour ce faire, il vérifie si le serveur présente un certificat valide, émis par une autorité de certification de confiance.

Le problème est le suivant : normalement, vous n'aurez pas un 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 juste dans ce but. Le système opérationnel se plaindra aux utilisateurs qu'il ne connaît pas cette AC et les utilisateurs (orientés par vous) accepteront volontiers cela.

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

Quelqu'un peut installer un point d'accès pirate dans votre entreprise (dans un sac ou même sur un ordinateur portable), le configurer pour qu'il communique avec son propre serveur radius (exécuté sur son ordinateur portable ou sur le point d'accès pirate).

Si vos clients trouvent que cet AP a un signal plus fort que vos points d'accès, ils essaieront de s'y connecter. Ils verront un CA inconnu (les utilisateurs acceptent), établiront une TLS enverra l'information d'authentification sur ce tunnel et le rogue radius l'enregistrera.

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

Vous pouvez résoudre ce problème en utilisant un certificat valide émis par une autorité de certification à laquelle iOS, Windows (et Android) font confiance. Ou bien, vous pouvez distribuer le certificat racine de l'autorité de certification à vos utilisateurs et les informer de refuser de se connecter lorsqu'ils constatent des problèmes de certificat (bonne chance pour cela).

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

Le PEAP est une enveloppe SSL autour de l'EAP transportant l'EAP. TTLS est une enveloppe SSL autour des TLV de diamètre transportant les attributs d'authentification RADIUS.

EAP-TTLS-PAP peut être utile (plutôt que EAP-PEAP ou EAP-TTLS) si la base de données d'authentification dorsale stocke les informations d'identification dans un format de hachage non réversible tel que bigcrypt ou toute forme non compatible avec MSCHAP (NT-OWF). Dans ce cas, il n'est pas possible de s'authentifier en utilisant l'une des méthodes basées sur CHAP.

Bien que vous puissiez également émuler PAP en utilisant EAP-PEAPv1-GTC, cette méthode n'est pas aussi largement supportée par les clients.

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

Je vois généralement EAP-TTLS mis en œuvre dans les clients intégrés tels que les modules d'abonnés dans les équipements sans fil, tandis que PEAP est davantage utilisé par les ordinateurs portables et les combinés mobiles.

Historiquement, EAP-TTLS n'a pas été supporté par les clients Windows sans avoir à installer un 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 de RADIUS. EAP-PEAPv0 a été inventé par Microsoft. EAP-PEAPv1 est issu du processus de l'IETF.

L'IETF a également travaillé sur un PEAPv2 qui aurait rendu le système plus sûr grâce à des liaisons cryptographiques avec les méthodes d'authentification internes. Pour autant que je sache, cela n'a pas abouti.

Comme l'a écrit disk eater, la principale raison pour laquelle les gens utilisent TTLS est que vous pouvez autoriser votre serveur radius à voir le mot de passe en 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 n'est AFAICT présenté au serveur RADIUS que s'il le demande, et la seule façon de le demander sur les systèmes Microsoft est pendant une session PEAP. Donc, si vous voulez obtenir une évaluation de type agent à partir d'une évaluation sans agent (le support par un plus grand nombre de fournisseurs AV est probablement à venir), vous devriez utiliser PEAP, mais si vous cherchez à contourner un backend OAUTH à 1 facteur en prenant un mot de passe nu (parce que les grands IDP qui ne fournissent pas un service de tunnel interne ne méritent pas moins et leurs utilisateurs sont assez ignorants pour le taper), utilisez TTLS.

Vous devez prendre en compte les méthodes EAP que le client prend en charge de manière native ou avec un logiciel supplémentaire et les méthodes d'authentification interne que le serveur prend en charge.

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 supportés par les clients, mais si votre serveur ne supporte pas MS-CHAPv2 (parce que vous ne stockez pas de mots de passe en clair), vous devez trouver une autre solution. C'est la raison principale pour laquelle vous verrez des gens utiliser EAP-TTLS et PAP.