Come ho capito, EAP-TTLS e PEAP condividono lo stesso livello di sicurezza quando implementati in reti wireless. Entrambi forniscono solo l'autenticazione lato server tramite certificato.

Lo svantaggio di EAP-TTLS può essere il supporto non nativo in Microsoft Windows, quindi ogni utente deve installare software aggiuntivo.

Il vantaggio di EAP-TTLS può essere il supporto per meccanismi di autenticazione meno sicuri (PAP, CHAP, MS-CHAP), ma perché ne avresti bisogno in un sistema wireless moderno e adeguatamente sicuro?

Quali sono le tue opinioni? Perché dovrei implementare EAP-TTLS anziché PEAP? Diciamo che ho la maggior parte degli utenti Windows, utenti Linux medi e almeno iOS, utenti OSX.

Puoi supportare entrambi, se il tuo back-end RADIUS lo supporta. Tuttavia, alcuni client "auto" si connettono (Mac OS X> = 10.7 + iOS, ad esempio) e potrebbero funzionare in modo non ottimale se si supporta più di un tipo, poiché provano solo combinazioni diverse fino a quando uno di loro funziona, ovvero si connettono con meno problemi se c'è un solo modo per connettersi.

In pratica: supporta solo PEAP o PEAP + TTLS se hai client che richiedono TTLS.

Restrizioni del cliente

• client iOS non supportano EAP-TTLScon PAP(solo MsCHAPv2) a meno che manualmente (tramite computer) installare un profilo.

• I client Windows non supporteranno EAP-TTLSimmediatamente (sarà necessario installare un software come secure2w), a meno che non dispongano di schede wireless Intel.

• Android supporta quasi tutte le combinazioni di EAPe PEAP.

Restrizioni al database delle password

Pertanto, il vero problema è come sono memorizzate le password.

Se sono in:

• Active Directory , quindi è possibile utilizzare EAP-PEAP-MsCHAPv2(caselle Windows) e EAP-TTLS-MsCHAPv2(con client iOS).

• Se memorizzi le password su LDAP , puoi utilizzare EAP-TTLS-PAP(caselle Windows) ma perderai iOS.

Importanti preoccupazioni per la sicurezza

• Entrambi EAP-TTLSe PEAPutilizzano TLS(Transport Layer Security) over EAP(Extensible Authentication Protocol).

Come forse saprai, TLSè una versione più recente di SSLe funziona sulla base di certificati firmati da un'autorità centrale di fiducia (Autorità di certificazione - CA).

Per stabilire un TLStunnel, il client deve confermare che sta comunicando con il server corretto (in questo caso, il server radius utilizzato per autenticare gli utenti). Lo fa controllando se il server ha presentato un certificato valido, emesso da una CA fidata.

Il problema è: normalmente, non avrai un certificato emesso da una CA fidata, ma uno rilasciato da una CA ad hoc che hai creato proprio per questo scopo. Il sistema operativo si lamenterà con gli utenti del fatto che non sa che CA e gli utenti (come orientati da te) lo accetteranno felicemente.

Ma ciò comporta un grave rischio per la sicurezza:

Qualcuno può configurare un AP non autorizzato all'interno della tua azienda (in una borsa o persino su un laptop), configurarlo per parlare con il proprio server radius (in esecuzione sul suo laptop o sul proprio AP non autorizzato).

Se i tuoi client trovano che questo AP ha un segnale più forte dei tuoi access point, proveranno a connettersi ad esso. Vedrà una CA sconosciuta (gli utenti accettano), stabilirà un TLStunnel, invierà informazioni di autenticazione su questo tunnel e il raggio canaglia lo registrerà.

Ora la parte importante: se si utilizza uno schema di autenticazione in testo semplice ( PAPad esempio), il server radius rogue avrà accesso alle password degli utenti.

Puoi risolverlo usando un certificato valido emesso da un'autorità di certificazione sia attendibile da iOS, Windows (e Android). In alternativa, è possibile distribuire il certificato radice CA ai propri utenti e informarli di rifiutare la connessione quando riscontrano problemi con il certificato (buona fortuna con quello).

PEAPv0, PEAPv1 e TTLS hanno le stesse proprietà di sicurezza.

PEAP è un wrapper SSL attorno a EAP con EAP. TTLS è un wrapper SSL attorno a TLV di diametro con attributi di autenticazione RADIUS.

EAP-TTLS-PAP può essere utile su EAP-PEAP se il database di autenticazione back-end archivia le credenziali in un formato hash non reversibile come bigcrypt o qualsiasi modulo non compatibile con MSCHAP (NT-OWF) In questo caso non è possibile eseguire l'autenticazione utilizzando uno qualsiasi dei metodi basati su CHAP.

Anche se potresti anche emulare PAP usando EAP-PEAPv1-GTC, questo non è così ampiamente supportato dai clienti.

PEAP ha aggiunto un po 'di bagaglio sul TTLS sotto forma di mal di testa di negoziazione della versione PEAP e incompatibilità storiche in PEAPv1 (come la magia del client quando si ricava la chiave master da PRF) che si sono fatti strada nelle prime implementazioni.

Normalmente vedo EAP-TTLS implementato in client embedded come moduli di abbonamento in dispositivi wireless con PEAP utilizzato maggiormente da computer portatili e portatili.

Storicamente EAP-TTLS non è stato supportato nei client Windows senza dover installare software di terze parti. EAP-TTLS è ora supportato a partire da Windows 8.

Alcuni pensieri aggiuntivi:

EAP-TTLS è stato inventato da un fornitore RADIUS. EAP-PEAPv0 è stato inventato da Microsoft. EAP-PEAPv1 è uscito dal processo IETF.

C'era un po 'di lavoro IETF aggiuntivo su un PEAPv2 che avrebbe reso il sistema più sicuro attraverso i collegamenti crittografici ai metodi di autenticazione interna. Questo non è andato da nessuna parte vicino come posso dire.

Come ha scritto il mangiatore di dischi, il motivo principale per cui le persone usano TTLS è che puoi consentire al tuo server radius di vedere la password in chiaro in quel modo, che può essere utile a seconda del back-end di autenticazione.

Una considerazione più recente che potrebbe favorire PEAP è che SoH è AFAICT presentato al server RADIUS solo se richiesto, e l'unico modo per richiederlo sui sistemi Microsoft è durante una sessione PEAP. Quindi, se si desidera ottenere una valutazione simile a quella di un agente fuori dalla valutazione senza agente (probabilmente sarà disponibile il supporto di più venditori AV), si desidera PEAP, tuttavia se si sta cercando di aggirare un back-end OAUTH a 1 fattore prendendo una password nuda (perché diamine, i grandi sfollati interni che non forniranno un servizio di tunnel interno meritano non meno e i loro utenti sono abbastanza all'oscuro da digitarli) usano TTLS.

Devi considerare quali metodi EAP sono supportati nativamente dal client rispetto a software aggiuntivo e quali metodi di autenticazione interna sono supportati dal server.

PEAP ed EAP-TTLS sono progettati per consentire di convalidare l'identificazione del server, ma è necessario assicurarsi che i client siano configurati correttamente per convalidare il certificato.

PEAP e MS-CHAPv2 sono ben supportati dai client, ma se il tuo server non supporta MS-CHAPv2 (perché non memorizzi password in chiaro), devi trovare un'altra soluzione. Questo è il motivo principale per cui vedrai le persone usare EAP-TTLS e PAP.

Penso che la connessione automatica trarrebbe beneficio da entrambe le opzioni, più opzioni meno seccature ... ad es. se la connessione automatica prova prima TTLS-PAP e poi PEAP-MSCHAP, la connessione automatica è più veloce con TTLS-PAP disponibile. Quindi in sostanza: supporta entrambi, non riesco a vedere uno svantaggio.

Poiché la sicurezza di MSCHAP è rotta (google per "crack mschap") pap con password in chiaro attraverso ttls ha lo stesso livello di sicurezza di PEAP-MSCHAP.

Non conosco differenze di sicurezza tra EAP-TTLS e PEAP, quindi in pratica dipende dal supporto, in cui PEAP è il vincitore.