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驗證。