Massimo wrote: > Ciao, > solo un paio di considerazioni personalissime: > alcune documentazioni dicono che il wpa/wpa2 non supporta le smart > card, altre lasciano intendere il contrario, io propendo per la prima > ipotesi visto che di solito le smart card chiedono il pin per accedere > alla chiave privata, il che mi sembra incompatibile con wpa che > normalmente effettua numerose riautenticazioni in background.
Ciao Massimo, credo che la la smart card funga solo da store sicuro (2-factor) per il certificato digitale lato client richiesto dal metodo TLS di EAP (autenticazione 802.1x), che permette di stabilire una connessione cifrata (TLS) e autenticata mutualmente (validità/purpose/trust dei certificati) tra supplicant e Radius server, non vedo una relazione "diretta" WPAx e certificato digitale, ovvero - WPA vuole 802.1x per l'autenticazione - 802.1x richiede EAP come protocollo - TLS è uno dei metodi previsti da EAP - TLS richiede certificati digitali - il certificato può stare su di una smart card... ...quindi non capisco che cosa si intenda per "WPA che non supporta smart card", WPA credo veda solo 802.1x, dovrebbe ignorare o meno l'esistenza di smart-card. Alcuni links... sempre meglio riportarli quando si citano! ;-) http://technet.microsoft.com/en-us/library/bb457068.aspx "For computers running Windows XP with no service packs installed, you must have user certificates stored on the computer for user authentication (rather than using smart cards). For computers running Windows Vista, Windows XP with Service Pack 2 (SP2), Windows XP with Service Pack 1 (SP1), or Windows Server 2003, you can use either user certificates stored on the computer or a smart card for user authentication". http://technet.microsoft.com/en-us/library/cc773343(WS.10).aspx "Use of the TLS authentication type with EAP (EAP-TLS) reduces latency for authentication requests because, during the first authentication attempt, TLS caches certificate properties on the access client and on the IAS server. For subsequent authentication attempts, TLS uses the cached certificate properties instead of reading the certificate from the certificate store on the IAS server or client computer." "The user is prompted for a smart card PIN on this initial association. The next time the client computer associates with an AP that is a RADIUS client to this RADIUS server, the user is not prompted for the PIN. When the TLS cache expires, the user is prompted to reenter the PIN" > L'autenticazione del computer non l'ho mai usata, ma da quanto leggo > sembra che non serva allo scopo che descrivi, in sostanza sembrerebbe > una autenticazione aggiuntiva che se fallisce non impedisce all'utente > di collegarsi alla rete ma se ha successo consente al dominio di > assoggettare il computer alle group policy, o giù di li, un documento > che ho letto descrive la cosa come "full wired experience". > In ogni caso è scritto chiaramente che l'autenticazione computer, o > meglio "machine authentication", è gestita da entrambi i protocolli. In un dominio AD un computer account è come uno user account, ha un set di credenziali (non visibili) e si autentica sul dominio come un utente, anzi, nella "condizione standard" fintanto che la macchina non si è autenticata sul dominio, l'utente non può fare login. Pertanto credo sia possibile impostare un policy Radius che gestisca il computer alla stessa stregua di uno user, ovvero che si autentichi nel caso di PEAP-MSCHAPV2 tramite password (storata in AD). In EAP-TLS la "machine authentication" è implicita, visto il requirement del certificato macchina la cui CA root deve essere trustata dal Radius server. Inoltre credo sia persino possibile fare una policy Radius ulteriore che verifichi che tale computer faccia anche parte di un sercurity group di AD, quindi controllo: A) che sia un computer membro del dominio, quindi tipicamente trusted (domain machine authentication) B) che faccia inoltre parte di un gruppo di macchine alle quali do il grant access explicito > Un'altra cosa che leggo sul sito MS, che quindi tenderei a considerare > affidabile, è che il supplicant 802.1x di MS non gestisce i certificati > protetti da password, il che riporta alla mia prima considerazione ma > soprattutto rende la cosa molto più debole, in quanto un certificato > non protetto da password mi risulta sia facilmente esportabile, quindi > forse meno sicuro di una login. Nota: un certificato, sia esso rilasciato tramite autoenrollment o web-enrollment di Microsoft, può essere storato nel Protected Store del profilo utente di Windows come "Not Exportable". > PEAP è soggetto a problematiche di tipo MITM, ma solo se non imposti il > check del certificato server sui client. Disabilitare il check del certificato Radius sul client credo sia una cosa "insana", anche perchè con una PKI Microsoft integrata in AD, il "Trusted Root Certification Authorities Certificate" store viene popolato automaticamente con la chiave pubblica della/e CA del dominio (quindi tutti i certificati emessi sono trusted by default) o comunque posso via GPO aggiungere come "trusted" altre eventuali CA "private" non integrate nel domino, dato che quelle pubbliche sono già trustate di default da qualsiasi OS. > Un altro potenziale problema con PEAP, che non dovrebbe avere TLS, è > che sniffando il traffico radius è teoricamente possibile estrarre le > credenziali, ma parliamo di un attacco già più complesso e comunque > anche questo è neutralizzabile utilizzando ad esempio ipsec. Ho appreso che PEAP stabilisce un canale cifrato TLS proprio come fa EAP-TLS (ovviamente con certificato server only), quindi anche la mia domanda originale sul rischio di "eavesdropping" di EAP-TLS vs. PEAP-MSCHAPV2 non era molto sensata! Usano lo stesso canale cifrato! :-) > Segnalo anche la possibilità di utilizzare dei sw che impediscono > l'accesso alla rete da parte di mac address non conosciuti, sappiamo > che è tutto meno che una sicurezza definitiva, ma in combinazione con > tools che tengono d'occhio l'associazione mac/ip può rappresentare un > bel campanello d'allarme, un esempio è questo: > http://www.manageengine.com/products/wifi-manager/index.html Wi-Fi Manager sembra un bel tool per la gestione centralizzata, però generalmente per la sicurezza preferisco l'approccio "prevention" piuttosto che "detection" :-))) Ancora non sono riuscito a trovare un buon motivo che giustifichi l'implementazione dell'oneroso EAP-TLS su PEAP-MSCHAPV2. Qualsiasi suggerimento in questo senso è ben accetto! Cordialità - Gabriele. ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
