銳捷認證過程是怎樣的？
參考 ：RG-SAMEAP協議分析_百度文庫802.1x認證的EAP協議（總體流程）
|------------------------------&>| 主機向伺服器（多播或廣播地址）發送EAPOL-Start
|1. EAPOL-Start | | |
|&<------------------------------| 要求驗證身份的請求 | 2.
EAP-REQUEST-Identity | | |
|------------------------------&>| 回應(用戶名) | 3. EAP-RESPONSE-Identity
| | |
|&<------------------------------| 要求驗證密碼的MD5校驗值(隨機加密字Challenge)
| 4.
EAP-REQUEST-MD5_Challenge |
|------------------------------&>| 回應（使用Challenge加密口令） | 5.
EAP-RESPONSE-MD5_Challenge | | |
|&<------------------------------| EAP-Success（判斷正確性） | 6.
EAP-Success | | |
在任何時候伺服器發來EAP-Failure數據包，都表示整個認證過程終止。
在乙太網中，EAP協議當然也是通過乙太網幀的格式來傳送，幀類型為0x888e，在基於pcap的抓包程序中，可使用"ether proto
0x888e"來抓取。
Ethernet-Header： (802.3,區域網標準)
################################################
# 05 11 13 # #
+----------------+----------------+--------+ # # |DST--MAC |SRC--MAC
|0x888e | # # +----------------+----------------+--------+ #
################################################
EAP協議不僅可用於本文關注的乙太網環境中，還可在無線WLAN、令牌環網中應用，而這些鏈路幀是各不相同的，這就是為什麼有EAPOL類型的數據幀，用以抽象EAP協議報文。
EAPOL-報文結構
14 15 #
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #
# |Ethernet-Header |a|b| # #
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # # 17
# # +-+-+------------- # # |c |Packet
Body # # +-+-+------------- #
############################################ a:EAPOL 協議版本 b:EAPOL
報文類型
c:EAPOL 幀長度
a類型說明：通常為常量0x01 b類型取值：EAPOL-Packet : 0x00 //各種EAP協議的信息交互，封裝在EAPOL-Packet類型的EAPOL報文內EAPOL-Start:
0x01 EAPOL-Logoff: 0x02 EAP-報文結構
######################################### # 0
15 # # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #
# |
| #
17 18 19 21 22 # # +-+-+-+-+-+-+-+--------------
# # | |d|e|f |g|EAP Body # #
+-+-+-+-+-+-+-+-------------- #
######################################### d:EAP通信類型 e:EAP通信id
f:EAP數據長度
g:EAP協商類型
d類型取值：
EAP-Request: 0x01 EAP-Resopnse: 0x02
EAP-Success: 0x03 EAP-Failure: 0x04 e類型說明：
通常由伺服器發來的報文指定，在連續的報文內使用這個id來協商或者計算MD5值的數據之一。 g類型取值： Identity:
0x01MD5_Challenge: 0x04
注意EAPOL幀和EAP幀的兩處長度位置，前者的長度是不算EAPOL頭的4個位元組的，而後者則包含自身頭部的5個位元組，所以這兩個長度的值可能是一致的，但具體可能有擴展信息放在EAPOL幀尾部，則前者比後者大。
下面是需要程序構建的數據包的大概細節：
通常是比較簡單的數據包，只需填好相應的位，沒有其他附加消息，EAPOL-Start、EAPOL-Logoff兩種報文長度為0，通常建立起來兩個報文的長度就只有18位元組。
2.EAP-REQUEST-Identity
伺服器發來的這個報文也比較簡單，可能唯一有用的數據是「e:EAP通信id」位，需要給發送回去的報文中把相應位設置為該值，雖然這很可能是常數。
Identity格式
+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP Header | Username
+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.EAP-RESPONSE-Identity
只需要設置「d:EAP通信id」位，然後在EAP頭後緊接用戶名的ASCII碼信息。有些品牌的協議中，則順帶在此數據包開始校驗客戶端的IP、版本號等信息。
找到該用戶名對應的口令信息，用隨機生成的一個加密字Challenge對它進行加密處理（MD5）
伺服器請求MD5校驗的報文中包含了重要的信息，首先也是「e:EAP通信id」位，後一個報文也需要設置該位；
在EAP報頭後緊接一個一位的長度值L（常量0x10），表示緊跟其後的重要數據的長度，其後的16位值則需要用來計算下一個報文中的信息，我們稱之為attach-key。
MD5_Challenge格式
+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Header
|L|MD5-Key/Value +-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.EAP-RESPONSE-MD5_Challenge
首先需要設置「d:EAP通信id」位，然後構建一個這樣的位元組數組［(e:EAP通信id)(用戶密碼的ASCII)(attach-key)]，這個位元組的長度當然是(1+用戶密碼長度+16)，然後送入MD5計算函數中，獲得16位的計算結果，再把這16位計算結果填入報文。報文格式跟請求的類似，在包頭後緊接一位長度值，當然是0x10，然後是16位的計算結果。
用該加密字對口令部分進行加密處理（MD5) 來的加密後的口令信息和其自己經過加密運算後的口令信息進行對比，判斷用戶是否合法
一個客戶端程序所做的事情通常就是這麼多，而因為EAP協議的「Extensible」的特性，幾乎我們見到的每個品牌的協議都有所擴展，而且各不相同，所以各個品牌之間的客戶端甚至交換機等設備都可能完全不可兼容的，其協議很可能在上述的報文中都添加一個信息尾，用來校驗各種信息。
EAP-SIM學習
EAP-
Response/SIM/Challenge (AT_MAC)步驟說明：
據AT_RAND等Sres信息|NONCE_MT|Version|... 計算自己的AT_MAC和AT_MAC比較
然後生成一個序列，部分為四次握手MK(萬能鑰匙，這增加了後面的四次握手的安全性)
Response含Sres的AT_MAC，讓伺服器再認證。
GSM
subscribers身份標識：IMSI（International Mobile Subscriber
Identity）。IMSI組成：不多於15數字的String，MCC（Mobile Country Code）3位，MNC（Mobile Network
Code）2或3位，MSIN（Mobile Subscriber Identification Number）不多於10位.
Internet AAA protocols身份標識：NAI(Network Access Identifier)[RFC4282].
形式為：([email=username@realm]username@realm[/email]).對於永久用戶，可以使用IMSI生成用戶名（第一位加『１』）；pseudonym
usernames and fast re-authentication, identities由認證伺服器生成。
EAP-AKA學習
EAP-AKA用於第三代移動通訊網路(3G)的認證和密匙協商機制
(Authentication and Key Agreement). AKA基於對稱密碼學原理，通常運行在手機的SIM卡上,3G中稱為USIM.
Peer
Authenticator
|
|&<------------------------------------------------------| |
| |
EAP-Response/Identity | | (Includes
users NAI) |
|------------------------------------------------------&>| |
+------------------------------+ |
| Server runs AKA algorithms, | |
| generates RAND and AUTN. | |
+------------------------------+ |
EAP-Request/AKA-Challenge | | (AT_RAND,
AT_AUTN, AT_MAC) |
|&<------------------------------------------------------|
+-------------------------------------+ | | Peer
runs AKA algorithms, | | | verifies AUTN
and MAC, derives RES | | | and session key
| |
+-------------------------------------+ | |
EAP-Response/AKA-Challenge | | (AT_RES,
AT_MAC) |
|------------------------------------------------------&>| |
+--------------------------------+ |
| Server checks the given RES, | |
| and MAC and finds them correct.| |
+--------------------------------+ |
EAP-Success |
|&<------------------------------------------------------|
Figure 1: EAP-AKA full authentication
procedure?
AT_MAC(Message Authentication
?EAP-AKA支持利用已得到的KEY進行快速重新認證。
Code)用來保護EAP數據包的完整性。
?支持用戶身份的保密
交互記錄：Server不應該依賴EAP-Response/Identity中的Indentity信息，應該使用EAP-Request/AKA-Identity包主動請求（EAP-Response/AKA-Identity的AT_IDENTITY屬性指示）。
identity）在EAP-Response/AKA-Identity 包的AT_IDENTITY屬性。如果Peer只有permanent
identity，反饋EAP-Response/AKA-Identity（在AT_IDENTITY屬性中包含permanent
identity）；如果還有pseudonym identity，反饋可能是EAP-Response/AKA-Client-Error（code "unable
to process packet"），或者permanent identity。然後，如果Server發現不是合法的permanent
identity，發送EAP-Request/AKA-Notification（AT_NOTIFICATION code"General failure"
(16384)），終止EAP認證。否則EAP-Request/AKA-Challenge開始全認證過程。
2）AT_FULLAUTH_ID_REQ屬性：Server想讓Peer反饋全認證身份（full authentication identity
(pseudonym identity))。伺服器不支持快速重認證。首先反饋pseudonym
identity（如果有），否則反饋permanent identity。然後，如果Server發現不能把pseudonym identity映射到一個合法的permanent
identity，發送AT_PERMANENT_ID_REQ。
3）AT_ANY_ID_REQ屬性：Server想讓Peer反饋一個身份（an identity）。如果Peer維護了快速重連狀態信息，並且想使用快速重連，反饋re-authentication
identity屬性信息。其次，判斷pseudonym identity，最後判斷permanent identity。如果Server同意重認證，發送EAP-Request/AKA-Reauthentication，否則發送AT_FULLAUTH_ID_REQ或者AT_PERMANENT_ID_REQ。
EAP/AKA-Identity可能輪迴多次（最多3次），這種情況的順序：
-&> AT_FULLAUTH_ID_REQ -&> AT_PERMANENT_ID_REQ.
WLAN3G應用AKA:
WLAN-UE（User Equipment）：WLAN 用戶的移動終端設備
WLAN-AN（Access
Network）：WLAN接入網路3GPP AAA 伺服器: 3GPP 網路認證、授權、計費伺服器HSS/HLR: 家鄉用戶伺服器/
家鄉位置寄存器IMSI: 國際移動用戶標誌( International Mobile Station Identity)f1 ～f5。為3G
安全結構中定義的演算法, f1 演算法用於產生消息認證碼, f2 演算法用於消息認證中計算期望響應值, f3
演算法用於產生加密密鑰, f4 演算法用於產生完整性密鑰, f5
演算法用於產生匿名密鑰。
協議流程
① WLAN-UE→ WLAN-AN: NAI(身份標誌)
②
WLAN-AN→ 3GPP AAA: NAI③ 3GPP AAA→WLAN-AN: RAND, AUTH,
WLAN-UE 的臨時標誌, 消息鑒別碼④ WLAN-AN→ WLAN-UE: RAND, AUTH, WLAN-UE 的臨時標誌,
消息鑒別碼⑤ WLAN-UE→ WLAN-AN: RES, 消息鑒別碼⑥ WLAN-AN→
3GPP AAA: RES, 消息鑒別碼⑦ 3GPP AAA→ WLAN-AN: WLAN-UE 的認證結果,
WLAN-AN 與WLAN-UE的共享密鑰⑧ WLAN-AN→ WLAN-UE: WLAN-UE
的認證結果
說明：
③收到WLAN-UE 的身份標誌後, 3GPP AAA 伺服器首先詢問HSS,該用戶是否有使用WLAN提供的服務許可權。然後從HSS/HLR 中取得與該用戶相關的認證向量AV, 同時也獲得與該用戶IMSI 對應的新的臨時標誌。
其中, AV = RAND‖XRES‖ CK ‖ IK ‖ AUTN, RAND 為隨機數, XRES = f2k( RAND) , CK = f3k(
RAND) , IK = f4k ( RAND) , AUTN = SQN ‖AK‖AMF‖MAC; SQN為序列號, AK = f5k ( RAND) ,
AMF 為認證管理域, MAC = f1k ( SQN‖RAND‖AMF) 。 隨後, 從IK 和CK 中生成共享密鑰,
這些共享密鑰一方面可用於WLAN通信的機密性和一致性保護, 另一方面也用於保護WLAN-UE 的臨時標誌。 構造EAP 請求/AKA
挑戰消息, 消息包含RAND、AUTH、臨時標誌, 並計算消息鑒別碼。最後, 將EAP 請求/AKA 挑戰消息發送給WLAN-AN。
⑤WLAN-UE 首先驗證AUTH, 並確認接收的序列號SQN是否在有效範圍內, 如果都正確, 則實現了對3G 網路的認證。
計算IK和CK, 從IK和CK 中生成共享密鑰, 然後驗證消息鑒別碼是否正確, 並保存收到的臨時標誌。 計算RES = f2k( RAND)
, 構造EAP回應/AKA 挑戰消息, 消息包含RES, 並計算消息鑒別碼。最後, 將EAP 回應/AKA 挑戰消息發送給WLAN-AN。
⑦3GPP AAA 伺服器首先驗證消息鑒別碼, 然後計算XRES, 並與收到的RES 進行比較。如果正確, 則認證了WLAN-UE 的身份,
並向WLAN-AN發送EAP 成功的消息。同時一起發送的還有在WLAN通信中用於機密性和一致性保護的共享密鑰。
⑧WLAN-AN保存共享密鑰, 此共享密鑰將用於與WLANUE通信時的機密性和一致性保護, 同時將EAP
成功的消息發送給WLAN-UE。
安全性分析
EAP-AKA 協議基於WLAN-UE與HSS/HLR 之間共享的秘密密鑰K, 實現WLAN用戶與3G 網路的相互認證和密鑰分配。
( 1) WLAN用戶與3G 網路之間的雙向認證。
WLAN用戶對3G 網路的認證是在上述第⑤ 步實現的。WLAN-UE 收到3GPPAAA 伺服器發送過來的AUTN = SQNī AK‖ AMF‖MAC, 確認序列號SQN是否在有效範圍內, 並驗證AUTH
是否正確。因為只有使用正確的秘密密鑰K 才能生成正確的AUTN, 而只有合法的HSS/HLR 才有秘密密鑰K,
因此上述過程實現了對3G網路合法性認證。 3G網路對WLAN 用戶的認證是在上述第⑦ 步實現的。3GPP AAA 伺服器首先計算XRES =
f2k ( RAND) , 然後與收到的RES= f2k ( RAND) 進行比較。也因為只有合法的WLAN 用戶才有秘密密鑰K, 因此如果XRES =
RES, 就可以認證WLAN用戶的合法身份。
( 2) WLAN-UE 與WLAN-AN 之間的密鑰分配。
合法的WLAN-UE收到正確的隨機數RAND 後, 能正確生成CK = f3k( RAND) 和IK= f4k ( RAND) , 進而能正確生成用於WLAN
通信中機密性和一致性保護的會話密鑰。而WLAN-AN的會話密鑰是從3GPP AAA 伺服器得到的, 3GPP AAA 伺服器首先生成CK 和IK,
然後生成會話密鑰, 再傳送給WLAN-AN。因此, EAP-AKA 協議能確保WLAN-UE 與WLAN-AN 之間能共享會話密鑰, 並且會話密鑰沒有在無線介面中傳輸, 具有一定的安全性。
( 3) 密鑰的新鮮性。
在EAP-AKA 協議的每次認證過程中, WLAN-UE 與WLAN-AN 共享的會話密鑰通過CK 與IK 生成, 而CK與IK 是採用隨機數計算得到的,
從而確保了密鑰的新鮮性。
( 4) 防重放攻擊。
協議傳遞的消息使用了隨機數和不斷遞增的序列號SQN作為輸入,因而保證了消息的新鮮性。並且, 該隨機數包含在保證消息完整性的消息鑒別碼, 而響應方在響應消息的鑒別碼中也包含了該隨機數,
因此任何第三方都無法利用先前截獲的消息發起重放攻擊。
( 5) 潛在的漏洞。
與3G 的認證與密鑰分配協議AKA 一樣,EAP-AKA 協議也沒有WLAN 用戶與3G 網路之間共享的秘密密鑰K 的更新機制, 這可能會導致USIM克隆攻擊。另外, 當WLAN 用戶首次進行認證,
或3G 網路不認識WLAN用戶的臨時標誌時,WLAN用戶需傳送IMSI, 並且使用的是明文, 這會影響用戶身份的機密性。( 6)
可能的攻擊。 3G 網路的認證與密鑰分配協議AKA 存在MS( 移動站) 假冒攻擊的可能。事實上,同樣的攻擊也可能發生在EAP-AKA
協議上。並且, 由於WLAN的覆蓋範圍小,WLAN-AN與WLAN-UE 一樣, 都處在比較開放的環境中,
因而還有可能發生WLAN-AN假冒攻擊。具體描述如下: ①WLAN-AN 假冒攻擊。EAP-AKA 協議實現了WLAN用戶與3G 網路之間的相互認證,
但雙方都沒有對WLAN-AN 的身份進行認證。並且, 在協議第⑧ 步中, 3GPPAAA 伺服器將用於WLAN通信中機密性和完整性保護的會話密鑰,
直接以明文的形式發送給WLAN-AN。如果攻擊者首先利用某種方式( 如DoS 攻擊) 攻陷WLAN-AN, 然後假冒成WLAN-AN, 則可以獲取WLAN
中的會話密鑰, 這樣就使得WLAN的通信失去了保密性。②WLAN-UE 假冒攻擊。攻擊者A 還可利用截獲的合法用戶身份標誌進行攻擊。這樣, 攻擊者A
就可以假冒該用戶的身份入網。因為沒有會話密鑰, 因此攻擊者A 此時還不能進行正常的通信。而如果攻擊者A 同時對WLAN-AN 與3GPP AAA
伺服器之間的通信進行竊聽, 則可以獲取WLAN-UE 的會話密鑰。此時攻擊者A 就可以假冒該用戶, 在3G
與WLAN互聯網路中進行正常的通信。
推薦閱讀：
※手機是怎麼接收屬於自己的信號的？
※PE可執行文件格式詳解
※搶答環節沒有搶答器，有什麼能代替的方法，？
※CATIA二次開發交互設計原理