802.11r協議理解

首先閱讀了相關協議內容整理出了以下的802.11r時序圖所謂基礎，而後會詳細理解其中的每個步驟：

802.11鏈路認證：
1.OSA open System 基於MCA地址的身份驗證
2.Shared-key authentication使用WEP 一共使用四個幀完成認證

關聯過程：AP必須爲STA在網絡上註冊，使分佈式系統可以記錄每一個STA的位置
爲了節省時間，在AP接收到關聯請求的時候會當即給STA一個關聯響應，可是若是AC最後響應不容許關聯，此時能夠將STA下線
若是STA支持80211r則會在關聯報文中添加MDIE，若是支持80211i則添加RSNIE，AP收到assoc req幀後會拿這兩個信息元素和自身的MDIE，RSNIE對比（也就是寫入Beacon幀裏的MDIE），若是不一致會致使關聯失敗，關聯成功後，AP向STA發送assoc resp幀，並告知STA其R0KH_ID和R1KH_ID。爲之後生產三層密鑰（PMK_R0，PMK_R1，PTK）作準備；

802.1X認證過程：強AP與弱AC的形式，使AC在認證過程當中是做爲代理
802.11i協議定義了使用TLS鏈接生成的主密鑰MSK（Master Secret Key）來做爲PMK，所以只有採用了TLS方法的802.1X認證纔可以用於無線接入。最多見的一種用法是802.1X使用PEAP+MSCHAPv2的認證方法，PEAP負責創建TLS鏈接並對內層認證數據加密，MSCHAPv2用於內層驗證用戶名和密碼。
詳細認證過程TBD

四次握手：使用EAPOL幀
在四次握手開始前，Client須要先關聯到AP上，而且雙方都須要準備好PMK以後才能開始四次握手。在前面1.3.2章節中介紹過，WPA-Personal方式雙方能夠直接計算出PMK，因此不須要經歷圖1-15的認證階段，而WPA-Enterprise方式則須要經過802.1X認證來派生出PMK。
四次握手階段的4個消息寫做Message N(r, Nonce; GTK)，N用來表示是第幾個消息，r用來表示圖1-13中的Key Replay Counter，逗號以後是隨機數Nonce，若是是Authenticator產生的隨機數則寫做ANonce，若是是Supplicant產生的隨機數則寫做SNonce，若是沒有隨機數則不寫。分號以後的參數是保存在消息的Key Data字段的，GTK表示Data中的數據是組播密鑰。
消息1：四次握手的第一個消息是由AP首先發給Client，攜帶了AP產生的隨機數ANonce，由於Key Replay Counter關係到後續報文加密計算，因此須要初始化Key Replay Counter。在整個四次握手的4個消息中，消息1是惟一不帶Key MIC校驗參數的消息，前面講過Key Replay Counter須要在Key MIC校驗合法後才進行更新，所以Client在收到消息1後並不會更新本身的Key Replay Counter。由於消息1是可能出現重傳的，Client不能由於收到消息1就更新本身的Key Replay Counter致使該值被重置。
消息2： Client收到消息1以後會產生一個本身的隨機數SNonce，從前面1.3.3.1章節的公式能夠看出，Client已經知道本身和AP的無線MAC地址，也知道本身和AP的隨機數SNonce和ANonce，Client已經知足公式計算的全部輸入參數，所以Client能夠計算出單播密鑰PTK，但此時Client並未將PTK安裝到無線驅動中，由於AP還沒有確認該PTK。而後Client須要將SNonce發送給AP，這樣AP纔可以根據一樣的算法派生出PTK。
消息3：此時Client和AP雙方都派生出了PTK，可是PTK僅用於單播報文的通訊加解密，組播和廣播數據須要用到GTK密鑰。由於是廣播或組播通訊，通訊範圍是一個AP下關聯的全部Client，因此一個AP下的全部Client應該擁有一個共同的加解密密鑰GTK，這個密鑰由AP負責產生並按期更新，AP將密鑰告知新接入的Client，所以AP還須要向Client發送消息3，將GTK放在Key Data字段中，但GTK也必須以加密的方式發送，加密密鑰爲消息2派生的PTK中的KEK密鑰（圖1-12中的KEK字段）。消息3會將Key Information中Install標記位置1，通知Client能夠將密鑰安裝到無線驅動中。
消息4：該消息其實是對消息3的確認消息，表示Client確認收到了消息3，不然會引發消息3的重傳，所以消息4除了帶有Key MIC驗證消息完整性外，不包含任何其餘信息。Client發出消息4後，就會向無線驅動中安裝PTK和GTK密鑰；AP收到消息4後，也會向無線驅動中安裝該Client的PTK，AP上已經在使用GTK，因此GTK無需再次安裝到無線驅動中。
Client在與AP首次鏈接時，四次握手消息都是處於未加密的狀態，可是Client與AP成功鏈接後仍然能夠經過四次握手更新PTK和GTK，在更新的狀況下，四次握手消息會看成普通報文同樣來處理，EAPOL報文會被前一次協商的PTK加密。GTK能夠單獨進行更新，更新GTK時至關於只進行了消息3和消息4的步驟。GTK是由AP來定時更新，AP上的GTK一旦更新，就須要通知AP上全部的Client更新GTK，但此時封裝GTK的EAPOL報文仍然須要被每一個Client的PTK加密，所以GTK的更新雖然是批量更新，但仍然是AP與每一個Client單播通訊。
由於每一個PTK是Client與AP之間經過四次握手協商出來的，因此當Client在不一樣AP之間發生漫遊時，都須要從新經過四次握手協商新的PTK，同時獲取新AP的GTK。若是是WPA-Personal方式，PMK是提早準備好的，漫遊時Client與新AP之間能夠直接進行四次握手協商；若是是WPA-Enterprise方式，Client還須要從新進行一次802.1X認證來派生出新的PMK，才能與新AP之間進行四次握手協商，因此在WPA-Enterprise方式下漫遊效率會下降，致使漫遊發生時數據傳輸中斷時間更久。
爲了解決WPA-Enterprise方式下漫遊慢的問題，Client能夠與多個AP提早進行802.1X預認證，在漫遊還沒有發生時，Client就提早找掃描到的相同SSID的不一樣AP進行802.1X認證，Client本身緩存每一個AP的PMK，每一個AP也提早緩存該Client的PMK，當漫遊真正發生時，Client和AP都已經緩存了PMK，因此雙方能夠直接進行四次握手來協商出新的PTK，這樣就實現了與WPA-Enterprise方式相同的漫遊效率。可是802.1X預認證和緩存PMK須要Client和AP雙方都支持才行，雙方有任何一方不支持802.1X預認證，都不能進行WPA-Enterprise方式下的快速漫遊。
即便Client和AP雙方都支持802.1X預認證，要實現WPA-Enterprise方式下的快速漫遊還有一些須要注意的地方，那就是802.1X認證是Client首先發起第一個報文啓動認證流程，而四次握手是AP首先發起第一個報文啓動協商流程，兩個流程首個請求發起者不同。
從AP的角度來看，當一個Client關聯上來以後，AP若是緩存了該Client的PMK，但AP不知道該Client是否也緩存了PMK可否快速進入四次握手階段，所以AP會保持一小段靜默時間，靜默期間若是未收到Client發起802.1X認證，則AP進入四次握手階段發出消息1。若是AP不支持802.1X預認證，也就不能緩存Client的PMK，當Client漫遊過來後應該當即發送802.1X Identity來觸發Client儘快進入802.1X認證階段。
從Client的角度來看，當漫遊到新AP後，若是Client緩存了PMK，則不主動發起802.1X報文，靜靜等待AP發出四次握手的消息1，若是超過了AP靜默期仍然未收到四次握手的消息1，則須要放棄本地緩存的PMK，從新發起802.1X認證流程派生新的PMK。若是Client不能提早緩存PMK，則漫遊後應該當即主動發起802.1X認證，AP會放棄原來緩存的PMK，經過802.1X認證來派生出新的PMK後，再進行四次握手。

probe幀：在無線網絡中，probe幀是週期發送進行探測STA

Fast BSS Transmition：
快速漫遊過程相比於普通的STA上線過程主要區別在於：
1.在鏈路認證的時候使用的是FT認證
2.快速漫遊是創建在已經鏈接無線網絡的前提下，因此發生了從新關聯的過程
3.沒有802.1X認證過程(PMK已經存在)
4.沒有四次握手過程，密鑰協商發生在重關聯的過程

密鑰計算公式：

XXXKey指的是PMK
PMK_R0指的是root key在AC中存放，R0KH指的是AC，R0KH-ID指的是該AC的MAC地址
PMK_R1指的是由PMK_R0和R0KH-ID派生出來的密鑰在AP中存放，R1KH指的是AP，R1KH-ID指的是該AP的MAC地址
PMK_R0_Name指的是PMK_R0在AC的密鑰存儲表中的Index，生成方式見上圖
PMK_R1_Name指的是PMK_R1在AP的密鑰存儲表中的Index，生成方式見上圖
密鑰存儲表表現方式爲鍵值對，好比（PMK_R0_Name，PMK_R0）

密鑰結構：
1)PMK_R0爲第一層密鑰，它由MSK（PMK）或PSK推演出來，由PMK_R0密鑰持有者保存（即R0KH和S0KH）。
2)PMK_R1爲第二層密鑰，它由R0KH和S0KH共同推演而來，由PMK_R1密鑰持有者保存（即R1KH和S1KH）。
3)PTK爲第三層密鑰，它是由R1KH和S1KH共同推演而來。R0KH和R1KH爲認證者端的結構，與之對應的S0KH和S1KH爲客戶端的結構。
S0KH和S1KH都是指STA

FT認證：
Auth報文中的FTAA表明該驗證請求幀的驗證算法爲FT，而不是Open和shared key；幀中的MDIE必須和FAP自身的MDIE一致，不然會致使驗證失敗；一樣的，若是PMKR0name不可用或者R0KH（這裏的R0KH_ID必須是進行初始化關聯階段所得到的R0KH_ID）不可達，一樣會報錯（報錯結果參見 state code）。
目標AP的R1KH利用PMKR0Name和幀中的其它信息計算出PMKR1Name。若是AP沒有PMKR1Name標識的Key（PMK_R1），R1KH就會從STA指示的R0KH得到這個Key。目標AP收到一個新的PMK_R1後就會刪除之前的PMK_R1安全關聯以及它計算出的PTKSAs。STA和目標AP計算PTK和PTKName時須要用到PMK_R1，PMKR1Name，ANonce和SNonce。認證完成後，如果在TIE(Reassociate Deadline )時間或者重關聯時間[TIE(Reassociate Deadline )]到期前未收到重關聯幀，那麼目標AP就要將PTKSA刪除。
若是目標AP通過計算找不到PMK_R1，則向R0KH發送請求，R0KH計算出PMK_R1後，將PMK_R1SA發給R1KH。R1KH隨後計算隨機值Anonce，並經過3.7式計算出PTK，返回一個Auth response幀給工做站。

從新關聯： 此時雙方都已經計算出PTK了這裏的兩個幀是爲了校驗雙方的PTK計算的是否同樣。