EAP

EAP 是根基於 PPP（Point To Point Protocol）的一個擴充，因為無 線網路的存取也可以被看成是點對點的存取，無線存取點對無線使用 者，就好像是用 ADSL Modem 撥接上 Internet 一樣，ISP（Internet Service Provider）也必須對撥接上線的使用者做身份認證一樣。當 PPP 連線開始到認證成功，資料可以傳輸之前，必須要能先建立連線，然後

2.認證伺服器（Authentication Server），RADIUS Server

3.被認證者（Supplicant），無線使用者（Wireless Client）

在 EAP 所支援的多種認證方法中，本系統選擇性的挑選 EAP-TLS

（Transport Level Security）與 EAP-MD5（EAP-Message Digest 5）做 為首要支援的對象。原因無他，在無線接取端的 Hostapd 有支援這兩項 功能。

3.2.1 EAP Over LAN（EAPOL）

EAPOL 定義了 EAP 的封包在無線使用者端與無線存取點之間的無

PAE Ethernet 種類：PAE(Port Access Entity) Ethernet Type，它佔 了兩個 Byte 長，固定值是 88-8E（十六進位）。

協定版本：Protocol Version，它只佔了 1 個 Byte，這個值表示了傳 送者所支援的 EAPOL 的版本號碼，目前它的值只有 01（十六進位）。

封包種類：Packet Type，它只佔了 1 個 Byte，這個值表示了傳送的 這個封包的種類。封包種類共有以下五種：

1）EAP-Packet，其值為 00（十六進位），單純的 EAP 封包。

2）EAPOL-Start，其值為 01（十六進位），表示這個封包是啟始 EAP 協定的啟始封包。

3）EAPOL-Logoff，其值為 02（十六進位），表示這個封包是提 出 Logoff 需求的封包。

4）EAPOL-Key，其值為 03（十六進位），表示這個封包是

EAPOL-Key 的封包。

5）EAPOL-Encapsulated-ASF-Alert，其值為 04（十六進位），

表示這個封包，在資料封包的部份，包含了一個被 ASF

（Alerting Standards Forum）所定義的 Alert 必須要送出。

資料封包長度：Packet Body Length，資料封包內容的長度，以 Byte 為單位。若其值為 0，表示沒有資料封包。

資 料 封 包 ： Packet Body ， 資 料 封 包 內 容 。 只 有 EAP-Packet 、 EAPOL-Key 和 EAPOL-Encapsulated-ASF-Alert 這三種型式的封包會有 資料封包這個部份。而且一次只能有單筆的資訊會存在，不允許複數筆 的資料存在。例如一次只能允許一把 Key 的傳遞。另外，EAP 封包的最 大長度取決於 MAC 層（Media Access Control）所能支援的長度。

3.2.2 EAP-TLS 與認證過程

EAP-TLS［1］，透過憑證的使用與 CA 的參與，提供了一個讓 Server 與 Client 來互相做認證的一個機制。只有當雙方的憑證同時都為合法的 (a)Server Hello

(b)Client 端的憑證要求 (c)Server finished

6. 無線使用者端送回包含 TLS 訊息的封包。例如 (a)Client’s Certificate.

(b)Pre-master cecret in key exchange message.

(c)Client Certificate verification information (d)Change ciphter

(e)TLS finished

7.Server 送回其他 TLS 訊息的封包。例如 (a)Change Cipher

(b)TLS finished

8.Client 送回空的回傳封包

9.Server 送回 EAP Success 封包結束 EAP 交握過程

圖 6、EAP-TLS 憑證認證過程 資料來源：參考 RFC2716

3.2.3 EAP-MD5（Message Digest 5）

EAP-MD5 有一個最大的缺點，那就是它只讓 Authenticator 對

Supplicant 做認證，但是反過來，Supplicant 卻沒有對 Authenticator 認 證。這對 WLAN 的安全來講，其實是一個漏洞。

EAP-MD5 雖然採用的是密碼檢驗的方式，可是它並不是在網路上傳 輸密碼，它採用的是“證明＂持有正確密碼的方式。

步驟如下：

1. Authenticator 送出一個 Challenge 給 Supplicant，這個 Challenge 包含了一個字串與流水號。

2. 而 Supplicant 要證明它持有密碼的方法就是對 Challenge 與 密碼做 HASH，然後將 128bits 的 HASH 結果送回給

Authenticator。

3. Authenticator 在收到 Response 之後，也做相同的運算，當 然在做運算之前，Authenticator 必須已知正確的 Supplicant 的密碼。

4. Authenticator 在算出相同得 HASH 結果之後，告知 Supplicant 通過了使用者的認證。

除了剛剛所講的缺點以外，它還有其他的缺點，例如：它必須要有 地方來保存每一個需要認證的 Supplicant 的密碼，還有它並沒有產生 WEP session key 以及讓 session key 可以動態更換（Rekey）的功能。

只是就一般的使用者操作而言，它可算是在不使用憑證下的一個替 代方案。