hostapd wpa_supplicant madwifi詳細分析（十二）——EAP（RFC3748）及EAP狀態機分析（RFC4137）
這篇文章分兩個部分：EAP（RFC3748）及EAP狀態機分析（RFC4137），其中主要內容來自RFC以及網路文章。
一、EAP拓展認證協議
EAP的可拓展性主要表現在它的method可拓展，EAP只是一個載體，傳送不同method間的互動。
EAP可用於專用的連結，以及開關電路和有線和無線鏈路。到目前為止，EAP已經通過連線交換電路或撥號鏈路使用PPP協議，實施在主機和路由器上。同時也通過使用IEEE802協議，應用在交換機和接入點。在IEEE802有線媒體封裝的EAP在IEEE802.1X中得以描述，並且在IEEE無線區域網中封裝，由IEEE802.11i描述。
EAP架構的優勢之一就是它的靈活性。EAP是用來選擇一個專門的認證機制，通常是在驗證請求需要更多的資訊來確認專門的認證方法被使用，而不是需要驗證者需要更新來支援每個新的驗證方法，EAP允許使用後臺認證伺服器，他可以實現一些或所有認證方法，當認證者為部分或所有的方法和對等體作為一個傳遞。
·Authenticator（驗證者）：簡單點說，Authenticator就是響應認證請求的實體（Entity）。對無線網路來說，Authenticator往往是AP。
·Supplicant（驗證申請者①）發起驗證請求的實體。對於無線網路來說，Supplicant就是智慧手機。
·BAS（Backend Authentication Server，後端認證伺服器）：某些情況下（例如企業級應用）Authenticator並不真正處理身份驗證，它僅僅將驗證請求發給後臺認證伺服器去處理。正是這種架構設計拓展了EAP的適用範圍。
·AAA（Authentication、Authorization and Accounting，認證、授權和計費）：另外一種基於EAP的協議。實現它的實體屬於BAS的一種具體形式，AAA包括常用的RADIUS伺服器等。在RFC3748中，AAA和BAS的概念可互相替代。
·EAP Server：表示真正處理身份驗證的實體。如果沒有BAS，則EAP Server功能就在Authenticator中，否則該功能由BAS實現。
下圖是EAP認證的架構：
由圖可知，EAP沒有強制定義位於最底層（Lower Layer，LL）的傳輸層。目前支援EAP協議的網路有PPP、有線網（EAPOL，也就是802.1X協議）、無線網路（即802.11 WLAN）、TCP、UDP等。另外，由於EAP報文是由LL層進行封裝的，LL可能是EAPOL或直接驅動轉發，LL本身的特性（例如乙太網和無線網都支援資料重排及分片的特性）會影響其上一層EAP的具體實現。
·EAP Layer用於收發資料，同時處理資料重傳及重複（Duplicate）包。
·EAP Supplicant/Authenticator Layer根據收到EAP資料包中Type欄位（見下文介紹）的不同，將其轉給不同的EAP Method處理。
·EAP Method屬於具體的身份驗證演算法層。不同的身份驗證方法有不同的MethodType。
通過IEEE802壓縮EAP被定義在IEEE802.1X。在IEEE802封裝的EAP不包含PPP,IEEE802.1X不包含對鏈路的支援，或網路層的協商。因此，在IEEE802.1X中，不可能通過非EAP的認證方法，例如PAP或CHAP。
2.EAP認證交換過程如下：
[1] 認證器（Authenticator）傳送了一個請求來認證對等端（supplicant/peer）。這個請求有一個型別欄位來指出什麼正在被請求。請求的例子包括身份、MD5的挑戰等。MD5挑戰的型別與CHAP認證協議對應密切。通常情況下，認證器將傳送一個最初的身份認證請求，然而，一個最初的身份請求是不需要的，可能被掠過。例如，在對等端已經確定連線到埠時，或身份被另外的方式獲得時，身份就不需要了。
[2] 對等端傳送一個迴應包來回複合法的請求。和請求包一樣，迴應包包含了一個型別欄位，與請求的型別欄位相對應。
[3] 認證器返送一個附加的請求包，對等體回覆一個數據包。請求和回覆的序列繼續和需要的一樣長。EAP是一個鎖步協議，因此除了初始請求外，一個新的請求不能夠在收到有效相應之前被提前傳送。認證器像對重傳請求包有責任。經過適當數量的轉發後，認證器應該結束EAP談話，認證器不能夠傳送成功或者失敗資料包，當重傳或它沒有從對等端收到迴應。
[4] 通訊繼續知道認證器不能認證對等端，在這種情況下，必須傳送一個EAP失敗。或者，認證談話繼續直到認證成功認證，在這種情況下，認證器必須傳送一個EAP成功。
圖中第三和第四步時，Authenticator要求使用MD5質詢法進行身份驗證，但Supplicant不支援，故其回覆NAK訊息，並通知Authenticator使用GTC方法進行身份驗證。第六步中，如果Supplicant回覆了錯誤的GTC密碼時，Authenticator可能會重新發送Request訊息以允許Supplicant重新嘗試身份驗證。一般認證失敗超過3次才會回覆Failure訊息。
3. EAP報文格式
由於EAP僅僅定義了程式碼1-4，EAP資料包其他的程式碼被認證器和對等端默默的丟棄。
（2）Identifier：訊息編號（ID），用於配對Request和Response（3）Length：2位元組，用於表示EAP訊息包長度（包括EAP頭和資料的長度）。長度欄位是兩個位元組，顯示了長度，位元組數，EAP資料包包含程式碼，識別符號，長度和資料欄位。位元組外的長度欄位範圍應該被當作資料鏈路層填料，一旦接受必須被忽略。帶有長度欄位的訊息的位元組數大於接收到的位元組數是，必須被默默的丟棄。
（3）Type：就是EAP Method Type。EAP Method Type取值如下。
1：代表Identity。用於Request訊息中。其Type Data欄位一般將攜帶申請者的一些資訊。一般簡寫為EAP-Request/Identity或者Request/Identity。
2：代表Notification。Authenticator用它傳遞一些訊息（例如密碼已過期、賬號被鎖等）給Supplicant。一般簡寫為Request/Notification。
3：代表Nak，僅用於Response幀，表示否定確認。例如Authenticator用了Supplicant不支援的驗證型別發起請求，Supplicant可利用Response/Nak訊息以告知Authenticator其支援的驗證型別。
4：代表身份驗證方法中的MD5質詢法。Authenticator將傳送一段隨機的明文給Supplicant。Supplicant收到該明文後，將其和密碼一起做MD5計算得到結果A，然後將
結果A返回給Authenticator。Authenticator再根據正確密碼和MD5質詢文做MD5計算得到結果B。A和B一比較就知道Supplicant使用的密碼是否正確。
5：代表身份驗證方法為OTP（One Time Password，一次性密碼）。這是目前最安全的身份驗證機制。相信網購過的讀者都用過它，例如網銀付費時系統會通過簡訊傳送一
個密碼，這就是OTP。
6：代表身份驗證方法為GTC（Generic Token Card，通用令牌卡）。GTC和OTP類似，只不過GTC往往對應一個實際的裝置，例如許多國內銀行都會給申請網銀的使用者一
個動態口令牌。它就是GTC。
254：代表擴充套件驗證方法（Expanded Types）。
255：代表其他試驗性用途（Experimental Use）。
（4）Data：EAP中具體的資料（Payload）。當Code為Request或Response的時候，Data欄位還可細分為Type以及Type Data。
4. 關於EAP加密的安全性分析請引數RFC3748，這裡就不相信描述了。
二、EAP狀態機分析
wpa_supplicant/hostapd程式裡面的核心部分，應該要算它的狀態機了，前面分析了WPS的實現過程，但是在看程式碼的時候，不管是加密部分還是WSC部分，都繞不過它的狀態機，它就像路上的一塊石頭，如果不搬開它，很難繼續往下走。下面是wpa_supplicant 模組結構圖，紅線部分是狀態機模組，它就像一個橋架在那裡，如果左邊進來的的資料想要到右邊去實現加密或者解密，就必須經過這座橋，而且這座橋有三條道，不幸的是，這三條道並不是直線的，這是一條立交橋，三條道是交織在一起的，他們相互關聯，相互串通，相互協作。
這篇文章先分析EAP狀態機，更加詳細的描述都在RFC4137裡面，個人建議查詢資料儘量去找官方文件，經過別人整理的東西有可能出錯，而且像部落格、個人筆記這種文章更容易不負責任的出錯，知識總結是給自己的，標準才是給大家的。
根據RFC4317的定義，對應supplicant來說，其實它的EAP加密過程是分層的，一些包需要通過觸發event loop 來啟動EAPOL SM，而一些包則可以直接觸發EAPOL SM，下面這個圖就是一些包經過driver i/f直接轉給EAPOL SM的處理過程。supplicant SM分三層，最底層是LowerLayer（LL），在wpa_supplicant中其實就是EAPOL層，這一層的作用是接收和傳送EAP包。位於中間的SUPP SM層實現了Supplican狀態機。最上層是EAP Method（EM）層，它實現了具體的EAP方法。
SUPP SM將接收到的資料一步一步往上傳，要傳送的資料一步一步往下走。一個最典型的互動例子就是LL收到EAP資料包後，將該資料包交給EAP層去處理。如果該EAP包需要EM層處理（例如具體的驗證演算法需要EM完成），則SUPP SM層將該包交給EM。EM處理完的結果將由EAP轉交給LL去傳送。
需要說明的是，雖然在wpa_supplicant中有對EAP的加密方法進行分層，但是他們都是工作在鏈路層的。
EAPOL層和EAP層的互動比較簡單，主要包括三個步驟。
1）EAPOL層收到EAP資料包後，將其儲存在eapReqData變數中，然後設定eapReq變數為TRUE。這個變數的改變對EAP層來說是一個觸發訊號（signal）。EAP可能
會發生狀態轉換。
2）EAP層從eapReqData中取出資料後進行處理。如果有需要回復的資料，則設定eapResp值為TRUE，否則設定eapNoResp值為TRUE。回覆資料儲存在eapRespData
中。EAPOL層將傳送此回覆包。
3）如果EAP完成身份驗證後，它將設定eapSuccess或eapFailure變數以告知EAPOL層其驗證結果。eapSuccess為TRUE，表明驗證成功。eapFailure為TRUE，則驗證失
敗。
這篇文章主要對EAP層進行分析，EAP METHODs不分析，這個只要在具體應用的時候再看就好了，畢竟eap methods 太多了，不同的場合有用不同的method。後面將會用新的文章分析EAPOL層。
下面是wpa_supplicant EAP層的狀態機轉移圖：
1. 狀態機圖中每一個狀態都是由一個方框來表示的，上面用大寫的部分表示當前的狀態，而下面綠色的部分表示進入這個狀態後將會執行的虛擬碼。箭頭上的資料表示條件，UTC表示無條件轉移（unconditional transition）
下面就是EAP Peer State Machine，也就是peer的EAP狀態轉移圖，peer可以看作是前面文章中的Enrollee或者supplicant，當然還有EAP Stand-Alone Authenticator State Machine和EAP Backend Authenticator State Machine，分析這些圖表大同小異，這裡就只分析peer的狀態機轉移。
當lower layer（LL鏈路層）需要將訊息傳遞給EAP peer狀態機的時候，它會將資料存放在eapReqData結構體中，同時將eapReq設為TURE。值得注意的是，eapReq設為TURE並不代表接收到的一定是Request訊息，它有可能收到的是Success訊息或者Failure訊息，儘管這個變數這樣命名，實際上LL層並沒有檢查EAP包中的內容。
當EAP peer狀態機處理完成接收到的訊息後，它就會根據實際情況設定eapResp or eapNoResp位。如果eapResp置1，那麼對應的response包就會存在eapRespData結構體中，那麼LL層就會給對方傳送這個訊息。如果EAP peer狀態機完成了認證，它就會將eapSuccess or eapFailure置1，用來告訴LL層認證成功或者失敗。
一些重要的結構體及變數：
1.EAPOL層傳給EAP狀態機的變數(Lower Layer to Peer)
eapReq (boolean)：由LL層設為TURE，或者由Peer state machine設為FALSE，用來表明LL層是否有請求到達
eapReqData (EAP packet)：當eapReq設為TURE的時候，會將請求包中的內容存放在這個結構體中
portEnabled (boolean)：置為1的時候表示EAP peer state machine已經準備好了通訊，如果EAP對話由LL層觸發開始，這個值就會設為TURE。如果在對話過程中，埠或session不再可用，那麼portEnabled就會設為FALSE，同時狀態機也會切換成DISABLED狀態。為了避免不必要的重置，當LL層能夠確信只是暫時的關閉而且馬上能夠恢復的情況下，LL層可能不會設斷開標誌(see [RFC3748],Section 7.12)。在這種情況下，portEnabled的值可能和LL層的link up標識並不一直保持相等。
idleWhile (integer)：它是一個外部計時器，用來表示peer狀態機在等待一個請求時剩餘的超時時間。
eapRestart (boolean)：表示LL層可能要重啟認證過程
altAccept (boolean)：
altReject (boolean)：
這兩個變數取名為lowerLayerSuccess和lowerLayerFailure更合適，它們用於通知LL層Success或Failure資訊。
·當supplicant收到Disassociate幀或者Deauthenticate幀時，表示lowerLayerFailure。
·當收到4-Way Handshake第一個Message時(WPA KEY handshake)，表示lowerLayerSuccess。
這兩個變數是EAPOL狀態機傳給EAP狀態機的，用來確認EAPOL和EAP層都成功時，表示成功，只要其中有一個失敗，就表示失敗。
2.EAP傳給EAPOL層的變數(peer to lower layer)
eapResp (boolean)：在peer state machine中置為TURE，在LL層中置為FALSE。這個值用來表示將要傳送一個response包
eapNoResp (boolean)：在peer state machine中置為TURE，在LL層中置為FALSE。表示請求已經被處理，但是沒有EAP response包要傳送
eapSuccess (boolean):在peer state machine中置為TURE，在LL層中置為FALSE。表示peer進入SUCCESS狀態
eapFail (boolean)：在peer state machine中置為TURE，在LL層中置為FALSE。表示peer進入FAILURE狀態
eapRespData (EAP packet)：當eapResp為TURE時，它指向response資料
eapKeyData (EAP key)：當key相關的資料可用時，會在peer state machine中的METHOD狀態設定這個值。RFC4137裡面沒有定義“EAP key”結構體，但是定義在【Keying】裡面
eapKeyAvailable (boolean)：在SUCCESS狀態時設定，如果key相關的屬性可用，則會設為TURE，相關的資料存放在eapKeyData裡面
ClientTimeout (integer):表示EAP request訊息的超時時間，它和idleWhile相對應，ClientTimeout表示固定的總時間，idleWhile表示還剩多少時間
3. EAP層和EAP METHODS層之間的互動變數
下圖來自《深入理解Android：WiFi模組 NFC和GPS卷》
注意，methodState和decision的值由具體的認證方法（即Method）來確定。對EAP SUPP SM來說，methodState和decision的取值情況才是最重要的，因為它
們會直接影響EAP的狀態切換。
4. EAP層，Peer State Machine本地變數
（1）長久型變數（在資料包之間維護）
selectMethod(EAP Type): 在GET_METHOD狀態中設定，表示peer在當前處理過程中所選的方法
methodState（列舉型別）：同上
lastID（整型）：0-255或空，在SEND_RESPONSE狀態中設定，表示上一次EAP包的標記（identifier）
lastRespData（EAP 包）：在SEND_RESPONSE狀態中設定，表示上一次傳送的EAP Packet
decision（列舉型別）：同上表
（2）短暫型變數（一次用完後將不再維護）
rxReq(bool):表示當前接收的EAP包型別為EAP Request包
rxSuccess(bool):表示當前接收的EAP包型別為EAP Success包
rxFailure（bool）：表示當前接收的EAP包型別為EAP Fail包
reqID（int）：表示當前EAP請求的ID
reqMethod（EAP type）：表示當前EAP請求包的認證方法（EAP METHOD）
ignore（bool）：在Method狀態設定，表示是否丟棄當前EAP包
5. EAP層，Peer State Machine相關函式
下圖來自《深入理解Android：WiFi模組 NFC和GPS卷》
6. EAP層，Peer State Machine的相關狀態
下圖來自《深入理解Android：WiFi模組 NFC和GPS卷》
這裡分析的wpa_supplicant的EAP狀態機，關於hostapd的部分可以自己查閱RFC4137，其實都是大同小異。