對於系統管理員和企業CIO來說，企業無線局域網的安全問題一直是他們關注的重心。今天我們將向大家介紹Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)，即通過安全隧道靈活驗證的EAP方式 。
在ASLEAP的威脅下，Cisco不得不開發了新的通過安全隧道靈活驗證的EAP方式，即EAP-FAST協議，並將其提交給了IETF。根據 Cisco的市場銷售宣傳，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-FAST Master Key會爲每個用戶提供一個特殊的PAC文件。而配發這個PAC的過程可以被認作是“階段0”（也就是自動提供），或者通過其他一些方式，比如通過移動存儲設備傳輸，通過管理員建立的共享文件夾，或者有用戶限制的共享文件夾。
市場vs現實
如果仔細閱讀Cisco提供給IETF的EAP-FAST協議草案，不難發現，EAP-FAST與Cisco的市場宣傳還是有比較大的出入的。雖然從技術上說，EAP-FAST“可以”和PEAP一樣安全，也“可以”和LEAP一樣簡單，但是Cisco的市場宣傳並沒有指出，用戶不可能魚與熊掌兼得。
事實上，爲了讓EAP-FAST達到與PEAP相同的安全級別，它必須採用在“階段0”採用“服務器端驗證的Diffie-Hellman模式”，即需要服務器端的數字證書。如果看過本系列的前幾篇文章，你就會知道，對於服務器端數字證書的需求是很多用戶放棄PEAP的主要原因。雖然Cisco表示採用PAC方式並不需要服務器端的數字證書，但是近乎手動實現的PAC文件配發，其中的不確定因素更多。另一方面，雖然EAP-FAST PAC參考機制可以通過安全的方式自動提供密鑰 ，但它僅限於維護PAC，並不能解決首次的PAC文件發佈問題。
爲了要實現如LEAP般的簡單，EAP-FAST必須在“階段0”採用匿名的Diffie-Hellman模式。而匿名的Diffie-Hellman密鑰交換意味着用戶並不知道交換的另一端到底是誰。在這種情況下，黑客可以假裝成階段0的接入點和驗證服務器，然後等待對此毫不懷疑的用戶進行階段0的連接，接收用戶以明文發送的用戶名和經過哈希計算的密碼。由於服務器是僞造的，因此服務器必定無法響應，此時階段令0會被用戶放棄。不過這時候黑客已經獲取了足夠多的MS-CHAPv2線程的信息了，他只需要使用ASLEAP進行離線的字典攻擊即可。由於大多數用戶的密碼不夠強壯，因此很快黑客就可以獲取到用戶的證書併成功進入企業無線局域網。
根據EAP-FAST IETF草案的說明，一旦出現這種情況，用戶應該立即更換密碼。但是EAP-FAST客戶端對此並沒有明確的提示，也沒有自動警告用戶和管理員，或是強制進行密碼修改。雖然這種比較便利的EAP-FAST方式在自動配發PAC是會出現漏洞，但是起碼有兩個因素使得他比LEAP要更安全一些。
◆首先，PAC文件的發佈只會執行一次，用來建立服務器和客戶端的PAC。之後建立的EAP-FAST線程都會繞過“階段0”。而LEAP則是每次都要面臨風險。每次用戶在與radius服務器進行無線局域網接入驗證時，都會出現類似的風險。
◆其次，就在在階段0的匿名Diffie-Hellman模式下，黑客如果要攻擊必須採用主動方式，這就會暴露黑客的行爲。而LEAP的攻擊要相對隱蔽。
雖然與LEAP相比進步很大，但是EAP-FAST的安全性仍然不如EAP-TLS, EAP-TTLS,或PEAP。不過EAP-FAST的驗證線程速度較快，因爲它採用的是對稱加密，而不是EAP-TLS, EAP-TTLS,或PEAP所採用的非對稱加密，但是這這種速度優勢並沒有什麼實際意義。我曾經使用一款266 MHz PDA進行PEAP驗證測試，這是能採用EAP驗證協議的最低端配置，但是我並沒有感覺PEAP驗證速度有任何延遲。我覺得，如果用戶使用筆記本進行PEAP驗證，與EAP-FAST驗證相比，速度可能僅僅會延遲幾個毫秒。我所關心的另一個問題是部署的速度，在這方面EAP-FAST依然處於劣勢。
EAP-FAST部署問題
根據宣傳，EAP-FAST是“像LEAP一樣簡單”的，但是事實上並非如此。根據Cisco自己的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或者通過活動目錄生成一個自簽名的數字證書。如果企業採用的是Windows NT域，或者是非Windows用戶，並不支持自動部署根證書，那麼PEAP服務器的“.cer”公共證書文件也可以通過企業內部網頁發送到每個客戶端，再由客戶端手動添加到CTL（證書信任列表）中。對於最後一種方法，我們也完全沒有必要擔心“.cer”文件會被黑客利用，因爲這個文件中僅包含了1024bit的公鑰內容，根據這些內容，幾乎沒有可能成功破解。
對於大範圍部署EAP-FAST和配發PAC，你必須建立和管理成百上千個獨立的用戶私鑰。不要指望可以通過企業內部網絡和活動目錄實現這些用戶私鑰的自動配發，因爲每個PAC都是不同的，必須手動輸入到每個用戶的筆記本中的Cisco ACU（Aironet Client Utility）中纔可以生效。我想你也會理解爲什麼我一看到Cisco的EAP-FAST宣傳語“像LEAP一樣簡單”就會發笑，因爲EAP-FAST的部署甚至比在一個受控環境中部署EAP-TLS還要麻煩。
Cisco EAP-FAST的更多侷限
由於EAP-FAST不支持較老的Cisco Wi-Fi設備，因此用戶需要使用近年來推出的Cisco Wi-Fi產品。Cisco EAP-FAST還需要用戶使用基於Cisco ACS (Access Control Server)的昂貴的驗證平臺，這種平臺的靈活性和易用性都不如微軟的RADIUS server IAS (Internet Authentication Service)。以上觀點都是來自那些管理過這兩種平臺的IT人員。另外，Cisco的客戶端還不支持“機器登錄”，這種方式可以在用戶還沒有登錄Windows時就對該系統進行身份驗證。對於企業來說，有這種功能是相當重要的，因爲它可以使登錄腳本以及組策略更好的工作。Cisco的網站上也建議用戶，如果需要使用機器登錄功能，可以選擇使用Microsoft Wireless Client。
有關EAP-FAST的總結
那麼，在沒有PKI的環境下，Cisco的EAP-FAST驗證協議真的如其所說是一種優秀的密鑰交換協議嗎？我想大家的答案肯定都是否定的。讀過了這篇文章或者Cisco的EAP-FAST開發手冊，也許大家都會有這樣一個疑問：爲了在驗證服務器上避免使用數字證書，爲了不在企業內部安裝PKI Certificate Authority或者不希望每年花300美元獲取CA機構的數字證書，而採用Cisco EAP-FAST，是否真的值得呢？如果你指望通過Cisco EAP-FAST來降低工作的難度，那你就大錯特錯了，因爲如果你要實現PEAP那樣的安全性，就絕不會像Cisco宣傳的那樣“像LEAP一樣簡單”。 在我看來，最佳的解決方案就是使用PEAP驗證。