EAP協議類型
——*——Stonex CWNP無線網絡
可擴展身份認證協議（Extensible Authentication Portocol，EAP）最早定義在RFC2284中，是一種支持多種認證方法的認證框架，而不是一個認證機制。EAP最初被設計用於PPP，後來被RFC 3748更新，用於基於端口的802.1X訪問控制，最後又被RFC 5247所更新。
EAP是一種非常靈活的二層協議，包括多種類型。有些EAP類型是產商私有的，有些EAP類型是標準的，如LEAP是Cisco私有的，PEAP是公有的標準。有些EAP僅能提供單向認證，而有些EAP可提供雙向認證（mutual authenticaiton）。在雙向認證中，不僅認證服務器需要對請求方的身份進行認證，請求方也必須對認證服務器的身份進行認證，以防止自己提供的用戶名和密碼被非法或假冒的認證服務器竊取。大部分要求雙向認證的EAP採用服務器證書對認證服務器的身份進行驗證。下表列出了各種EAP的特點和具體特性：
表-1 EAP類型
1. “弱”EAP協議
傳統的EAP類型極容易受到各種攻擊，包括社會工程學和離線字典的攻擊。這些傳統的EAP類型是企業WLAN絕對不可能接受的解決方案，包括EAP-MD5和EAP-LEAP。
1.1 EAP-MD5
EAP-MD5是一種相當簡單的EAP類型，很長一段時間在有線網絡中用於端口認證，因此也成爲第一個用於WLAN中的EAP類型。然而，由於EAP-MD5的存在幾大缺點，因此在企業WALN環境中不建議EAP-MD5，這幾大缺點是：
• 單向認證： 只有請求方被認證，服務器不需要被認證。相互認證需要創建動態加密密鑰，如果選擇EAP-MD5爲身份驗證方法，則加密方法只能是靜態WEP，或根本沒有加密；
• 用戶名明文： 請求方的用戶名總是明文可見，如果黑客知道用戶的身份，黑客可以嘗試使用社會工程學技術獲取到密碼。因此，EAP-MD5很容易受到社會工程學攻擊；
• 弱MD5哈希：請求方的密碼使用MD5哈希功能，但其很容易受到各種黑客工具所破解。因此，EAP-MD5極容易受到離線字典攻擊；
下圖描述了EAP-MD5的認證過程：
圖-1 EAP-MD5的認證過程
1.2 EAP-LEAP
EAP-LEAP也被簡稱爲LEAP（Lightweight Extensible Authentication
Protocol， 輕量級可擴展身份認證協議），是多年來被企業WLAN使用的一個非常成功的EAP類型。LEAP很容易部署，所有終端用戶可使用相同的身份憑證：用戶名和密碼。
與EAP-MD5不同，LEAP使用動態生成的WEP密鑰對數據傳輸進行加密，並執行一種類型的僞雙向認證，儘管許多文檔聲稱LEAP支持雙向認證。MS-CHAP和MS-CHAPv2在雙向認證的過程中使用相同的密碼進行哈希以認證對方，但這不是真正的雙向認證。LEAP有以下幾大缺點：
• 用戶名明文：請求方的用戶名總是明文可見，如果黑客知道用戶的身份，黑客可以嘗試使用社會工程學技術獲取到密碼。因此，EAP-MD5很容易受到社會工程學攻擊；
• 弱MS-CHAPv2哈希：請求方的密碼使用MS-CHAPv2哈希功能，但其很容易受到各種黑客工具所破解。因此，EAP-MD5極容易受到離線字典攻擊；
• 僞雙向認證：LEAP使用MS-CHAPv2協議支持一種“類型”的雙向認證；
儘管LEAP可以使用強大和複雜的密碼抵禦攻擊，但強制終端用戶使用強大的密碼策略是一個挑戰。爲了企業WLAN的安全，不建議在企業WLAN中部署使用LEAP。
下圖描述了EAP-LEAP的認證過程：
圖-2 EAP-LEAP的認證過程
2. “強”EAP協議
“強”EAP類型使用基於TLS的身份認證或TLS隧道化身份認證，與EAP-MD5/EAP-LEAP只使用一個請求方身份不同，基於隧道身份驗證的EAP類型使用兩個請求方身份：外層身份（outer identity）和內層身份（inner identity）。外層身份只是一個有效的虛假用戶名（通常爲anonymous），而內層身份是請求方的真實身份。外層身份以明文出現在加密TLS隧道外，而內層身份被TLS隧道所保護。
注意：所有的請求方都有能力配置外層身份的虛假用戶名，除了Microsoft WZC請求方。WZC請求認證時內層和外層身份都使用相同的用戶名。因此，真正的用戶名可見，這是爲什麼建議不是用Microsoft內置的WZC請求方。
2.1 EAP-PEAP
EAP-PEAP簡稱爲PEAP（Protected Extensible Authentication
Protocol，受保護的可擴展身份驗證協議），其創建一個加密的TLS隧道，並在該TLS隧道內驗證請求方內層身份。由於PEAP的高安全性，因此，PEAP是企業WLAN中最常用也是使用最廣泛的的EAP類型。
PEAP最開始由Csico、Microsoft、RSA
Security三家公司所聯合提議，但是據報道Microsoft和Cisco沒有完全同意提議的每一個細節。Microsoft實施PEAPv0使用MS-CHAPv2作爲內部認證方法，MS-CHAPv2是Microsoft自由的CHAP版本，隨着微軟在客戶端和服務器操作系統佔有的統治地位，並內置支持MS-CHAPv2，因此這也導致了EA-PEAPv0（EAP-MSCHAPv2）的成功。而Cisco從原始的標準中分離出PEAPv1，其使用EAP-GTC作爲內部認證方法。PEAP包括三個主要版本：
• EAP-PEAPv0(EAP-MSCHAPv2)
微軟的EAP-PEAPv0 （EAP-MSCHAPv2）是最常用的一種PEAP類型，使用EAP-MSCHAPv2協議作爲隧道內部的認證方法，其使用用戶名和密碼作爲用戶憑證。
• EAP-PEAPv0(EAP-TLS)
EAP-PEAPv0（EAP-TLS）是微軟的另一種類型的PEAP，使用EAP-TLS協議作爲隧道內部的認證方法，其使用客戶端證書作爲用戶憑證。EAP-TLS也可以作爲一個單獨的EAP認證協議使用。
• EAP-PEAPv1(EAP-GTC)
EAP-PEAPv1（EAP-GTC）是Cisco版本的一種PEAP類型，使用EAP-GTC（EAP-GenericToken Card，通用令牌卡）協議作爲隧道內部的認證方法。EAP-GTC定義在RFC3748中，然後被發展成與現有的安全令牌系統提供互操作性，如RSA的SecurID解決方案的OTP。EAP-GTC方法建議使用安全令牌設備，但是其身份憑證也可以爲明文的用戶名和密碼。因此，當EAP-GTC被用於PEAPv1的隧道中，通常其身份憑證是一個簡單的明文用戶名和密碼。
由於在TLS隧道中使用的PEAP內部認證協議是另一種類型的EAP，所以PEAP通常也被稱爲”EAP inside EAP“認證，唯一的區別就是使用在TLS隧道中的內部EAP協議不同。
PEAP操作的關鍵點是建立TLS隧道，這需要一個服務器端證書(server-side certificate)。EAP-PEAP認證過程包括兩個階段，下面以EAP-PEAPv0 (EAP-MSCHAPv2) 來說明，下圖描述了EAP-PEAP的認證過程：
圖-3 EAP-PEAP的認證過程
注意：加密TLS隧道只會存在幾毫秒，用於保護用戶身份憑證，而不是用於加密802.11數據幀。
2.2 EAP-TTLS
EAP-TTLS（EAP-Tunneled Transport Layer Security，隧道傳輸層安全）由Certicom和FunkSoftware設計，定義在RFC 5281中。與PEAP一樣，EAP-TTLS也使用TLS隧道保護相對不安全的內層認證方法。如下圖所示，EAP-TTLS與PEAP相似，認證過程也包含兩個階段。
圖-4 EAP-TTLS的認證過程
EAP-TTLS與EAP-PEAP的區別相當小，最大的不同就是EAP-TTLS支持更多的內層認證協議。EAP-TTLS支持傳統的認證方法PAP、 CHAP、MS-CHAP和MS-CHAPv2，也支持使用EAP協議作爲內層認證方法，支持使用客戶端證書作爲身份憑證，而EAP-PEAP只支持EAP協議作爲內層認證方法。
EAP-TTLS曾被廣泛部署過，在許多企業WLAN中也能遇到。然而，EAP-TTLS與EAP-PEAP幾乎相同，且不被Microsoft WZC所支持。因此，相對其他的EAP協議類型來說市場較小。如果不使用Microsoft WZC作爲請求方，EAP-TTLS是可考慮的一種選擇。
2.3 EAP-TLS
EAP-TLS（EAP-Transport Layer Security，傳輸層安全）定義在RFC 5216中，是使用最廣泛，也是WLAN中最安全的一種EAP類型。EAP-TLS除了與EAP-PEAP和EAP-TTLS一樣需要服務器端證書外，還需要客戶端證書。
部署服務器端證書並不需要太大的負擔，然而爲每一個客戶端部署唯一的數字證書需要企業PKI基礎設施，這對企業來說是一個負擔。因此，除非企業已經存在PKI基礎設施，否議在企業WLAN中部署EAP-TLS不是第一建議。下圖描述了EAP-TLS的認證過程：
圖-5 EAP-TLS的認證過程
使用客戶端數字證書作爲身份憑證是EAP-TTLS和EAP-PEAP的可選項，然而在TLS隧道中使用客戶端證書是不必要的。因此，只建議在部署EAP-TLS時使用客戶端數字證書。認證服務器配置EAP-TLS時，通常允許通過比較用戶數字證書中包含的一個或多個信息來驗證客戶端證書，這些信息包括：
• 證書持有者別名（Certificate Subject Alternative Name ，SAN）
• 證書持有者通用名稱（Certificate Subject Common Name ，CN）
• 證書二進制（Certificate Binary）
2.4 EAP-FAST
EAP-FAST（EAP-Flexible Authentication via Secure Tunneling，基本安全隧道的靈活認證）由Cisco所開發設計，用於取代易破解的LEAP。EAP-FAST目前已經被標準化定義在RFC 4851中，並在2009年，與EAP-AKA一起加入到Wi-Fi聯盟的WPA2互操作認證中。
EAP-FAST與EAP-PEAP和EAP-TTLS一樣，提供雙向認證和隧道化認證。但是EAP-FAST並不使用基於X.509標準的數字證書去建立TLS隧道，而是使用PAC（Protected Authentication Credential，受保護的接入憑證）。
PAC是一種類數字證書，實際上是一個共享密鑰，主要包含以下三部分：
• Shared Secret—The PAC-Key：客戶端與認證服務器之間的一個預共享密鑰，是一個強32字節的密鑰,由認證服務器隨機產生,是建立TLS隧道的先期主密鑰；
• Opaque Element—The PAC-Opaque：在隧道建立時發送給認證服務的一個可變長度的數據元素，這樣認證服務器就可以解碼所需的信息來驗證客戶端的身份；
• Other Information—PAC-Info：是一個可變長度的數據元素，,能夠以最簡潔方式的提供認證服務器或PAC發佈者的身份(A-ID)。爲了避免混繞,各個認證服務器的A-ID是不同的。PAC-Info還可能包括其他的有用但非強制的信息,例如,PAC-Key生存時間,也可能在PAC分發或更新時被服務器傳遞到申請者。
以上三個部分統一構成了一個完整的PAC證書,在EAP-FAST認證之前由認證服務器一次性產生並通過安全的方式送給申請者,完成PAC的發放。
EAP-FAST的認證過程包含3個階段：其中階段1是一個可選的階段，如下圖所示：
圖-6 EAP-FAST認證過程
• EAP-FAST 階段0 —— 此階段用於自動分發部署PAC，是一個可選的階段，所有的PAC可以通過手動方式安裝在每個客戶端上。
• EAP-FAST 階段1 —— 客戶端請求方發送外層僞裝的身份ID給認證服務器，讓認證服務器知道有客戶端嘗試認證。客戶端和認證服務器之間使用對稱密鑰加密進行協商，建立起一個加密的TLS隧道；
• EAP-FAST階段2 —— 在加密隧道內進行客戶端請求方的身份驗證。EAP-FAST支持多種內層認證方法，但通常使用的內層認證協議爲EAP-GTC，使用用戶名和密碼進行驗證。
階段0執行的自動分發部署PAC文件是使用一個匿名的Diffie-Hellman交換，客戶端僅是簡單的信任提供PAC文件的。因此，EAP-FAST如果是使用自動分發部署PAC文件，很容易遭受到中間人攻擊。如果不經過階段0，則手動安裝PAC文件到每個客戶端上則是一件很繁重的任務，還不如使用已經被廣泛部署過的EAP-TLS和EAP-PEAP。
3. 其他EAP協議
除了以上介紹的EAP協議外，還有多種其他EAP協議的存在。如EAP-POTP協議，用於移動電話產業的EAP-SIM和EAP-AKA等，這裏不做詳細介紹。