轉自：https://blog.csdn.net/u012503786/article/details/79296522
IEEE 802.1X-PEAP認證過程分析（抓包）
本文介紹IEEE802.1X認證的PEAP認證方式，是帶有radius服務器的EAP中繼認證。
IEEE802.1X認證是使用EAP報文格式在申請者和認證者之間交換信息。帶有radius服務器，即認證者不對申請者發送的數據進行解析處理，而是封裝后直接轉發給radius服務器。由radius服務器進行處理。
PEAP認證方式，是在此基礎上，首先建立一個申請者到認證服務器的傳輸隧道。然后在隧道中進行認證挑戰等操作。隧道保證了挑戰等數據的安全性
下面將根據把整個802.1X認證過程分為三部分
1、認證初始化：radius服務器獲取申請者的身份信息，並回應認證開始
2、建立TLS隧道：為了保證認證數據的安全性
3、認證過程：由於在安全的TLS隧道內傳輸，我們並不知道進行的是什么挑戰方式。只有申請者和認證服務器才能知道。
1、過程報文介紹
1.1、認證初始化
1、申請者向認證者發送EAPOL-start報文，開始802.1X接入的開始
2、認證者向申請者發送EAPOL-request/identity報文，要求申請者將用戶信息送上來
EAP-request/identity
1、 申請者回應認證者發送EAPOL-response/identity報文。其中包含用戶名
EAP-response/identity
2、 認證者以EAP overRADIUS 的報文格式將EAP-response/identity發送給認證服務器，並帶上相關的RADIUS屬性
Access-request/identity
字段含義：
Authenticator域占用16個字節，用於RadiusClient 和Server之間消息認證的有效性，和密碼隱藏算法。訪問請求Access-Request報文中的認證字的值是16字節隨機數，認證字的值要不能被預測並且在一個共享密鑰的生命期內唯一。
1.訪問請求認證字
在Access-Request包中認證字的值是16字節隨機數,認證字的值要不能被預測,並且在一個共享密鑰的生命期內唯一；
2.訪問回應認證字
Access-Accept Access-Reject 和Access-Challenge包中的認證字稱為訪問回應認證字，訪問回應認證字的值定義為MD5(Code+ID+Length+RequestAuth+Attributes+Secret)；
Attributevalue pairs：
service-type：2：為接入用戶
NAS-IP-address：網絡接入服務器IP地址
called-station-ID：認證者的MAC地址
NAS-port-type：NAS的端口類型，總是802.11
NAS-port：NAS的端口
calling-station-ID：申請者的MAC地址
acct-session-ID：計費連接號
framedMTU：最大傳輸單元
EAP-message：EAP報文
message-authenticator：（RFC3579）客戶端發送一個access-request，或者是服務器發送access-challenge時，添加的一個標識。接收方可以根據相同的操作進行驗證。計算方法：
Message-Authenticator = HMAC-MD5(Type, Identifier, Length, Request Authenticator,
Attributes)
每一個EAP報文都可以使用該屬性。
3、 認證服務器收到認證者發來的EAP-response/identity，根據配置確定使用EAP-peap認證，向認證者發送RADIUS-access-challenge報文，里面含有radius發送給申請者的EAP-request/peap/start報文，希望開始進行EAP-PEAP認證
Access-challenge/EAP-peap-start
字段含義：state：如果RADIUS服務器發送給設備的接入質詢報文中包含該值，則設備在后續的接入請求報文中必須包含相同的值
4、 認證者向申請者發送EAP-request/peap/start報文
EAP-request/protected EAP(EAP-PEAP)-start
3.1.2、建立TLS通道
5、 申請者收到EAP-request/peap/start報文，產生一個隨機數、客戶端支持的加密算法列表、TLS協議版本、會話ID、以及壓縮方法（目前均為NULL），封裝在EAP-response/TLS/clienthello報文中發送給認證者
TLSv1-client hello
字段含義：
version：客戶端支持的最高版本號
random：客戶端生成的隨機值
session ID：唯一標識一個session
cipher suite：每個ciphersuite 包含一個密鑰交換算法，一個大量數據加密算法，一個MAC算法和一個PRF（TLS的 PRF 就是把 P_hash 應用在secret上）構成
Compression methods：包含壓縮算法的列表
客戶端發送client hello后，服務器必須回復server hello。
6、 認證者以EAP overRADIUS 的報文格式將EAP-response/TLS/client hello發送給認證服務器，並帶上RADIUS的屬性
Access-request/client hello
7、 認證服務器收到clienthello報文后，會生成server hello、certificate、server key change、server hello done報文封裝在EAP消息中，使用access-challenge報文發給認證者
Access-challenge/server hello
總共發送server hello，certificate，server key exchange，server hello done四組數據。由於數據太長，所以進行分段處理
使用EAP-response/protected EAP報文進行響應，直到接收最后一片。
Server hello字段：
version：服務器選擇客戶端client hello報文中version和服務器支持的版本號的最小值
random：服務器生成的random，與client hello中的random沒有任何關系
session ID：服務器為本鏈接分配的session ID
cipher suite：服務器從client hello的cipher suite 字段選擇的一個。
Compression method：壓縮方法
certificate字段：
certificate：服務器證書
server key exchange字段：
EC Diffie-Hellman server params：
Curve type：支持3中曲線類型，可以自行制定橢圓曲線的多項式系數，基點等參數。但是現在基本不使用，而是使用named curve
Named curve：參數已經預先選定，各種密碼學庫普遍支持的一組曲線，最常見的是secp256r1
pubkey：公鑰
signature：簽名
server hello done：在serverhello和相關信息已經處理完畢之后，服務器發送server hello done。發送完server hello done后服務器開始等待客戶端的響應
8、 認證者將認證服務器的報文中的EAP-request消息發送給申請者
TLSv1-server hello
11、申請者收到報文后，進行驗證server的證書是否合法（使用剛從CA證書頒發機構獲得的根證書進行驗證，主要驗證證書時間是否合法，名稱是否合法），即對網絡進行認證，從而可以保證server的合法。
如果合法，提取server證書中的公鑰，同時產生一個隨機密碼串pre-master-secret，並使用服務器的公鑰對其進行加密，最后將加密的信息clientkeyexchange + 客戶端的證書（如果沒有證書，可以把屬性置為0） + TLS finished屬性封裝成EAP-response/TLS clientkeyexchange報文發送給認證者，
如果申請者沒有安裝證書，則不會對server證書的合法性進行認證，即不能對網絡進行認證
TLSv1-client keyexchange
Client key exchange字段：客戶端必須在serverhello done 到達后發送client key exchange消息。
ec_diffie_hellman：pubkey：公鑰
change cipther spec字段：客戶端切換成密文模式
encrypted handshake message字段：（finished）這個包表示握手已經完成，並且對之前發過的數據進行加密發送給對方做校驗，防止被篡改。同時也驗證加密算法和密鑰是否正常工作
12、認證者以EAP over RADIUS 的報文格式將EAP-response/TLSclientkeyexchang發送給認證服務器，並帶上相關的RADIUS屬性
Access-request/client key exchange
13、認證服務器收到報文后，用自己的證書對應的私鑰對clientkeyexchange進行解密，從而獲得pre-master-secret，然后對pre-master-secret進行運算處理，加上申請者和server產生的隨機數，生成加密密鑰、加密初始化向量和hmac的密鑰，這時雙方已經安全的協商出一套加密辦法了。認證服務器將協商出的加密方法 + TLS finished消息封裝在EAP over RADIUS 的報文access-challenge中,發送給認證者
Access-challenge/change cipher spec
changecipherspec：服務器切換到密文模式
14、認證者將認證服務器發送的報文，以EAP-request消息發送給申請者
TLSv1-change cipher spec
15、申請者回復認證者EAP-response/TLSOK
EAP-response/protected EAP(EAP-PEAP)
16、認證者將EAP-response/TLSOK消息封裝在radius報文中，發送給認證服務器，告知服務器申請者和認證服務器之間的TLS隧道建立成功
Access-request/protected EAP(EAP-PEAP)
至此，隧道建立完畢，申請者和認證服務器之間使用協商的密鑰進行加密傳輸，然后進行驗證
3.1.3、認證過程
17、認證者將radius報文中的EAP域提取，封裝成EAP-request報文發送給申請者
Access-challenge/application
TLSv1-request/application
18、申請者受到報文后，用服務器相同的方法生成加密密鑰。加密初始化向量和hmac的密鑰，並用相應的密鑰及其方法對報文進行解密和校驗，然后產生認證回應報文，用密鑰進行
加密和校驗，最后封裝成EAP-response報文發送給認證者，認證者轉發給認證服務器，並帶上相關的RADIUS的屬性，這樣反復進行交互，直到認證完成。在認證過程中，認證服務器會下發認證后用於生成空口數據加密密鑰PMK給申請者
TLSv1-response/application
Access-request/application
以上application data 的交換過程可能執行多次，直至成功。
19、服務器認證客戶端成功后，會發送一個RADIUS-access-accept給認證者，並包含認證服務器提供的MPPE屬性（vendor specific）。
Access-accept
20、認證者收到RADIUS-access-accept報文，會提取MPPE屬性中的密鑰作為WPA加密用的PMK，並且會發送EAP-SUCCESS報文給申請者
EAP-success
2、問題
（1）為什么server hello 要進行很多次？
數據太長了，需要分段，每次只發一小段。
（2）802.1X和PSK認證方式在RSN信息中，那么PEAP還是其他認證方式，在哪里體現？
申請者連接時，輸入用戶名和密碼的同時要選擇認證類型PEAP、TTLS或其他。表明申請者並不知道radius服務器能支持什么認證 。挑戰方式等是由申請者決定的，而radius服務器會發送一個默認的方式，如果與申請者想要的挑戰方式不同，可以經過協商解決。如果服務器不支持這種認證方式，那么認證就會失敗。
如果在用戶名傳遞之后（EAP-response/identity）之后，回復的挑戰並不是申請者要進行的挑戰，申請者可以發送EAP報文進行協商
（3）外層認證方式是PEAP，內層認證方式是什么？
在報文中內層認證方式不能確定。因為在TLS隧道內傳輸。無法被破解。
內層認證方式由申請者連接時選擇的。