認證算法號如何表示不需要wifi密碼？

在ASLEAP的威脅下，思科不得不開發壹種新的通過安全隧道柔性驗證的EAP方法，即EAP-FAST協議，並提交給IETF。根據思科的營銷宣傳，EAP-FAST是壹種“像PEAP壹樣安全，像LEAP壹樣方便”的協議。EAP-FAST可以建立壹個類似PEAP的安全加密通道來保護驗證線程中的用戶證書傳輸，而不需要客戶端甚至服務器擁有PKI。我對這種宣傳的第壹自然反應是懷疑。當然，其他的方法，比如安全密鑰加密，也可以在沒有PKI的情況下實現安全的密鑰交換，但是沒有壹種方法可以簡單的實現大規模部署。EAP-FAST真的能實現這個突破嗎？EAP-FAST階段EAP-FAST類似於正常操作模式下的PEAP，有兩個主要階段。第壹階段是建立安全的加密隧道，第二階段是通過MS-CHAPv2線程在驗證服務器上驗證客戶端的身份。由於MS-chapv2是壹個非常脆弱的協議，很容易被字典攻擊破解，所以第壹階段建立的安全加密隧道為MS-chapv2線程提供了壹個安全的環境。與PEAP不同，EAP-FAST使用PAC(受保護訪問證書)建立隧道，而PEAP使用服務器端數字證書建立TLS隧道(類似於安全Web服務器)。認證服務器的EAP-FASTMasterKey將為每個用戶提供壹個特殊的PAC文件。分發此PAC的過程可以視為“階段0”(即自動供應)，或者通過壹些其他方式，如通過移動存儲設備傳輸、管理員建立的共享文件夾或有用戶限制的共享文件夾。市場與現實如果妳仔細閱讀了思科提供給IETF的EAP-FAST協議草案，不難發現EAP-FAST與思科的市場推廣大相徑庭。盡管EAP-FAST在技術上像PEAP壹樣安全，像LEAP壹樣簡單，但思科的營銷活動並沒有指出用戶不能魚與熊掌兼得。事實上，EAP-FAST要想達到和PEAP壹樣的安全級別，必須在“0階段”采用“Diffie-Hellman模式的服務器端認證”，即需要壹個服務器端的數字證書。如果妳看過本系列之前的文章，妳就會知道，對服務器端數字證書的需求是很多用戶放棄PEAP的主要原因。雖然Cisco表示服務器端的數字證書不需要采用PAC方法，但幾乎手動的PAC文件分發存在壹些不確定性。另壹方面，EAP-FASTPAC引用機制雖然可以安全地自動提供密鑰，但也僅僅局限於維護PAC，並不能解決第壹個PAC文件釋放的問題。為了像LEAP壹樣簡單，EAP-FAST在“階段0”必須采用匿名Diffie-Hellman模式。匿名Diffie-Hellman密鑰交換意味著用戶不知道交換的另壹端是誰。在這種情況下，黑客可以偽裝成階段0的接入點和認證服務器，然後在階段0等待不知情的用戶連接，接收用戶以明文形式發送的用戶名和哈希密碼。因為服務器是偽造的，所以服務器壹定不會響應，階段訂單0會被用戶放棄。然而此時黑客已經獲得了足夠多的MS-CHAPv2線程的信息，他只需要使用ASLEAP進行離線字典攻擊。因為大部分用戶的密碼不夠強，黑客很快就能拿到用戶的證書，成功進入企業WLAN。根據EAP-FASTIETF草案，壹旦出現這種情況，用戶應該立即更改密碼。但是EAP-FAST客戶端並沒有對此給出明確的提示，也沒有自動警告用戶和管理員，或者強制修改密碼。雖然這種方便的EAP-FAST方法會在PAC的自動分發上有漏洞，但至少有兩個因素使其比LEAP更安全。◆首先，PAC文件的發布只會進行壹次，用於建立服務器和客戶端的PAC。之後建立的EAP-FAST線程將繞過“階段0”。而LEAP每次都面臨風險。每次用戶用radius服務器進行WLAN接入驗證，都會出現類似的風險。其次，在0階段的匿名Diffie-Hellman模式下，黑客要攻擊必須要主動，這樣會暴露黑客的行為。LEAP的攻擊比較隱蔽。雖然與LEAP相比，它已經取得了很大的進步，但EAP-FAST的安全性仍然不如EAP-TLS、EAP-TTLS或PEAP。但是，EAP-FAST的驗證線程速度更快，因為它使用對稱加密，而不是EAP-TLS、EAP-TTLS或PEAP使用的非對稱加密，但這種速度優勢沒有實際意義。我用了壹個266MHzPDA進行PEAP驗證測試，這是可以采用EAP驗證協議的最低配置，但是我並沒有感覺到PEAP驗證速度有任何延遲。我認為，如果用戶使用筆記本進行PEAP認證，速度可能比EAP-FAST認證只延遲幾毫秒。我關心的另壹個問題是部署速度，在這方面EAP-FAST仍然處於劣勢。EAP-FAST部署按照宣傳上的說法，EAP-FAST是“像飛躍壹樣簡單”，其實不然。根據思科自己的EAP-FAST開發指南，用戶不應該完全依賴PAC文件的自動分發，因為這會給黑客提供主動攻擊的機會。註意:由於階段0中的PAC分發受MS-CHAPv2身份驗證的保護，並且MS-CHAPv2容易受到字典攻擊，因此我們建議您在首次部署EAP-FAST時盡可能少地使用自動發布功能。在廣泛部署EAP-FAST後，應手動分發PAC，以確保PAC的最佳安全性。根據這些信息，我們可以發現EAP-FAST的部署並不是壹帆風順的。用戶最終會回到手動分發PAC文件的地步，以保證整個系統的安全。而合法用戶也必須承擔維護網絡安全的責任，因為誰都不希望看到多個用戶用同壹個PAC登錄。在閱讀了Cisco文檔中的手動PAC分配章節後，我們對安全部署EAP-FAST的工作量感到更加驚訝。根據我多年部署EAP-TLS和PEAP的經驗，我可以肯定的告訴妳，安全部署EAP-FAST，手動分發PAC，絕對是部署安全驗證項目最重要的物理活動。在部署PEAP的過程中，如果已經從CA獲得了數字證書，整個過程將會相當簡單。如果企業不願意每年花300美元從CA機構獲得數字證書，也可以自己建立CA，或者通過active directory生成自簽名數字證書。如果企業采用WindowsNT域或者是非Windows用戶，不支持根證書自動部署，那麽“.cer”公共證書文件也可以通過內網頁面發送到各個客戶端，然後客戶端可以手動將其添加到CTL (Certificate Trust List)中。對於最後壹種方法，完全沒有必要擔心”。cer”文件會被黑客利用，因為這個文件只包含1024bit的公鑰內容，根據這些內容，成功破解幾乎是不可能的。對於EAP-FAST的大規模部署和PAC的分發，您必須建立和管理數百個獨立的用戶私鑰。不要指望通過內網和active directory實現這些用戶私鑰的自動分發，因為每個PAC都是不壹樣的，必須在每個用戶的筆記本上手動輸入CiscoACU(AironetClientUtility)才能生效。我想當我看到思科的EAP-FAST口號“像飛躍壹樣簡單”時，妳會明白我為什麽會笑，因為EAP-FAST的部署甚至比受控環境下的EAP-TLS部署還要麻煩。CiscoEAP-FAST的局限性由於EAP-FAST不支持較老的CiscoWi-Fi設備，用戶需要使用近幾年推出的CiscoWi-Fi產品。CiscoEAP-FAST還需要用戶使用基於CiscoACS(AccessControlServer)的昂貴的認證平臺，不如微軟的Radioauthentication Services(互聯網認證服務)靈活易用。以上觀點均來自管理過這兩個平臺的IT人員。此外，思科的客戶端不支持“機器登錄”，該功能可以在用戶登錄Windows之前對系統進行身份驗證。對於企業來說，擁有這個功能是非常重要的，因為它可以讓登錄腳本和組策略更好地工作。思科的網站還建議，如果用戶需要使用機器登錄功能，可以選擇使用MicrosoftWirelessClient。EAP-FAST小結那麽，在沒有PKI的情況下，思科的EAP-FAST認證協議真的如其所說是壹個優秀的密鑰交換協議嗎？我想大家的答案肯定是否定的，看完這篇文章或者思科的EAP-FAST開發手冊，可能大家都會有這樣的疑問:為了避免在認證服務器上使用數字證書，為了不在企業安裝PKI認證機構或者為了不每年花300美元從CA機構獲取數字證書，采用CiscoEAP-FAST真的值得嗎？如果妳指望通過CiscoEAP-FAST來降低工作難度，那妳就大錯特錯了，因為如果妳想達到PEAP那樣的安全性，那絕對不會像思科宣傳的LEAP那麽簡單。在我看來，最好的解決方案是使用PEAP認證。