EAP（Extensible Authentication Protocol），可擴展認證協議，是一種普遍使用的支持多種認證方法的認證框架協議，主要用於網絡接入認證。
該協議一般運行在數據鏈路層上，即可以直接運行於PPP或者IEEE 802之上，不必依賴於IP。EAP可應用於無線、有線網絡中。
EAP的架構非常靈活，在Authenticator（認證方）和Supplicant（客戶端）交互足夠多的信息之后，才會決定選擇一種具體的認證方法，即允許協商所希望的認證方法。認證方不用支持所有的認證方法，因為EAP架構允許使用一個后端的認證服務器（也就是AAA服務器），此時認證方將在客戶端和認證服務器之間透傳消息。
Radius是Remote Authentication Dial In User Service的簡稱，即遠程驗證撥入用戶服務。當用戶想要通過某個網絡(如電話網)與網絡接入服務器NAS(Network Access Server)建立連接從而獲得訪問其它網絡的權力時，NAS可以選擇在NAS上進行本地認證計費，或把用戶信息傳遞給Radius服務器，由Radius進行認證計費。Radius協議規定了NAS與Radius服務器之間如何傳遞用戶信息和記賬信息，Radius服務器負責接收用戶的連接請求，完成驗證，並把傳遞服務給用戶所需的配置信息返回給NAS。
圖1 EAP典型使用組網（Ethernet）
該協議支持重傳機制，但這需要依賴於底層保證報文的有序傳輸，EAP不支持亂序報文的接收。協議本身不支持分片與重組，當一些EAP認證方法生成大於MTU（Maximum Transmission Unit，最大傳輸單元）的數據時，需要認證方法自身支持分片與重組。
EAP認證方法目前大約有40種，IETF的RFC中定義的方法包括：EAP-MD5、 EAP-OTP、EAP-GTC、EAP-TLS、EAP-SIM和EAP-AKA, 還包括一些廠商提供的方法和新的建議。
1 EAP報文的封裝格式
1.1 PPP鏈路：
當PPP幀的協議字段是0xC227的時候，表示PPP幀的信息字段里封裝了一個完整的EAP報文，其數據包的格式如圖2所示。
圖2 EAP報文在PPP鏈路的封裝
Type：一個字節，取值為3
Length：一個字節，取值為4
Authentication Protocol：兩個字節，C227 (Hex) for Extensible Authentication Protocol (EAP)
1.2 IEEE 802/Ethernet：
EAP在LAN的報文（簡稱EAPOL）封裝格式在IEEE-802.1X協議中定義，其數據包的格式如圖3所示。
圖3 EAP在LAN中的封裝
PAE（Port Access Entity）Ethernet Type：2字節，表示協議類型，為0x888E。
Protocol Version：1字節，表示EAPOL幀的發送方所支持的協議版本號。
Type：1字節，表示EAPOL數據幀類型，具體類型如表1所示。
| 類型 |
說明 |
| EAP-Packet（值為0x00）：認證信息幀，用於承載認證信息 |
該類型的幀在認證方重新封裝並承載於RADIUS等協議上，便於穿越復雜的網絡到達認證服務器 |
| EAPOL-Start（值為0x01）：認證發起幀 |
這兩種類型的幀僅在客戶端和認證方之間存在 |
| EAPOL-Logoff（值為0x02）：退出請求幀 |
表1 EAPOL數據類型
Length：2字節，表示數據長度，也就是“Packet Body”字段的長度，單位為字節。如果為0，則表示沒有后面的數據域。
EAPOL-Start和EAPOL-Logoff報文的Length值都為0。
Packet Body：表示數據內容，根據不同的Type有不同的格式。
2 EAP報文格式
當EAPOL數據幀格式Type域為EAP-Packet時，Packet Body為EAP數據報文，結構如圖4所示。
圖4 EAP報文格式
Code：一個字節，指明EAP包的類型，共有4種，域值定義如下：
1--------Request
2--------Response
3--------Success
4--------Failure
由於該字段值只定義了1到4，如果EAP報文的該字段為其他值，則應被Authenticator和Supplicant丟棄。
Identifier：一個字節，用於應答報文和請求報文之間進行匹配。
Length：兩個字節，EAP包的長度，包含Code、Identifier、Length和Data域，單位為字節。
Data：零個或多個字節，EAP包的內容，由Code類型決定
RFC 3748中定義的Success和Failure類型的包沒有Data域，相應的Length域的值為4。但是某些軟件的實現中，為了說明認證失敗的原因，在Length域后面增加了字段用於說明下線的原因，故Length域的值可能為其他值。
Request和Response類型報文的Data域格式如圖5所示。
圖5 Data域的格式
Type：一個字節，標識EAP的認證類型。
Type Data：該字段的內容由Type字段的值決定。
Type字段目前定義的值及其簡要說明如下：
Type＝1 ----Identifier（用來詢問對端的身份）
Type＝2 ----Notification（非必須的一個消息，傳送一些警告消息，比如提示密碼將要超期、OTP的順序號碼接近零以及認證失敗的警告等）。
Type＝3 ----Nak (Response Only)（Request報文中的認證類型不可接受時回復該類型的報文）
Type＝4 ----MD5-Challenge（類似於CHAP中的MD5-Challenge，使用MD5算法）
Type＝5 ----One-Time Password (OTP)（一種密碼交互的方式）
Type＝6 ----Generic Token Card（通用令牌卡類型，適用於各種需要用戶輸入信息的令牌卡的實現）
Type＝254 ----Expanded Types（供廠商支持自己的擴展類型）
Type＝255 ----Experimental use（在實驗新的類型時使用）
每種Type對應的Type Data字段這里不作詳細描述，有興趣的讀者請查閱RFC 3748相關章節。
3 EAP過程
EAP過程由認證方發起，而認證協議一般都是由客戶端發起，為了在特定的認證協議上支持EAP過程，認證協議需要增加一個或多個的附加報文來滿足條件。如以太網上的認證通常情況下是以客戶端發送EAPOL報文開始的。
EAP的典型過程如下：
1、Authenticator發送請求報文EAP-Request給Supplicant（客戶端），表明EAP認證開始。該請求由一個字段標明需要請求的數據是什么。這個字段包含Identity（詢問對端的身份）, MD5-challenge（MD5挑戰字）等。上述發送EAP-Request的步驟在某些情況下也可省去，比如在有線網絡中，Authenticator（有時也稱為NAS）已經根據客戶端連接的端口識別用戶身份，或者通過MAC地址，IMSI卡等識別用戶身份的情況下。
2、Supplicant針對Authenticator發過來的請求回應一個響應消息EAP-Response，該消息包含了請求消息中請求的字段信息，如身份識別信息。
3、Authenticator繼續發送EAP-Request消息，消息中包含具體EAP Type及其協議數據，Supplicant對此做出響應。根據EAP Method的不同，此步驟可能會交互多次。
EAP交互過程是Supplicant與Authenticator一來一往的過程，每次只能處理一個EAP報文，在收到響應之前不能發送新的請求，即鎖步機制（Lockstep）。因此Authenticator要負責請求消息的重傳。如果重傳一定次數后都沒有收到應答消息，這次的EAP過程就要被終結。重傳后收到應答消息或者一直沒有收到應答消息，Authenticator都不發送成功或者失敗消息。
4、交互多次之后，會出現兩種情形：Authenticator不能確認Supplicant的接入權限，此時必須發送EAP-Failure，終結此次的EAP過程；或者確認接入權限，此時必須發送EAP-Success消息。
Authenticator也可以作為Pass Through設備，透傳EAP報文。這種情形下Authenticator檢查EAP的Code，Id及Length並將報文轉發出去。Authenticator需要將EAP Code為2（Response）的報文轉給后端的認證服務器，將EAP Code=1（Request），3（Success），4（Failure）的報文轉給Supplicant。在這個處理過程中除非Pass Through Authenticator實現了某種EAP Methods，一般是只將消息轉發，並不去檢查EAP Methods Layer的的消息頭（即EAP Type）。