【文章內(nèi)容簡介】 Request/Identity 報文。在 認證發(fā)起階段，客戶端首先發(fā)送 EAPOLStar 報文到 協(xié)議組申請的組播 MAC地址，以查詢網(wǎng)絡(luò)上可以處理 的設(shè)備（即認證系統(tǒng)） ，由于網(wǎng)絡(luò)中沒有設(shè)備充當(dāng)認證系統(tǒng)，所以客戶端是得不到響應(yīng)的。因此客戶端在發(fā)起多次連接請求無響應(yīng)后，自動認為已經(jīng)通過認證。如果客戶端不支持 協(xié)議，而網(wǎng)絡(luò)中存在 協(xié)議的認證系統(tǒng)，則客戶端是不會響應(yīng)認證系統(tǒng)發(fā)送的 EAPRequest/Identity 報文，因此端口會始終14 / 44處于未認證狀態(tài)。在這種情況下，客戶端只能根據(jù)協(xié)議參數(shù)OperControlledDirections 設(shè)定的值通過受控端口訪問認證系統(tǒng)，通過未受控端口訪問某些通過設(shè)置可以訪問的服務(wù)。 EAP 幀的中繼轉(zhuǎn)發(fā)（ Relay）由于認證系統(tǒng)與客戶端之間是采用 EAPOL 協(xié)議進行通信，而認證系統(tǒng)與認證服務(wù)器之間則是采用 EAP 協(xié)議進行通信，可以看出認證系統(tǒng)充當(dāng)了把客戶端的 EAPOL 協(xié)議幀轉(zhuǎn)變?yōu)?EAP 協(xié)議幀的中繼功能。客戶端將 EAPOLStart 和 EAPOLLogoff 幀發(fā)送給認證系統(tǒng)，而認證系統(tǒng)把EAPOLKey 幀發(fā)送給客戶端。認證系統(tǒng)不能把這些幀中繼給認證服務(wù)器。EAPRequest/Identity 幀只能由認證系統(tǒng)發(fā)送給客戶端，而不會發(fā)送給認證服務(wù)器。除了以上的這些特殊幀外，客戶端和認證系統(tǒng)之間通信的其他的幀都可以轉(zhuǎn)發(fā)給認證服務(wù)器，不過幀格式要從 EAPOL 格式轉(zhuǎn)變?yōu)?EAP 格式。相反，認證系統(tǒng)會把所有從認證服務(wù)器收到的 EAP 格式的幀轉(zhuǎn)變?yōu)?EAPOL 格式發(fā)送給客戶端。 加密 EAPOL 認證報文的傳送EAPOL 協(xié)議支持在客戶端和認證系統(tǒng)之間加密傳送認證報文?？梢酝ㄟ^協(xié)議參數(shù) KeyTransmissionEnabled 控制是否加密。如果該值為 TRUE，表示對認證報文進行加密；如果值為 FALSE，則表示不對認證報文加密。如果客戶端或認證系統(tǒng)不支持加密，則 KeyTransmissionEnabled 參數(shù)設(shè)置為 FALSE。 協(xié)議實現(xiàn)內(nèi)容 協(xié)議在實現(xiàn)整個安全認證的過程中，其三個關(guān)鍵部分（客戶端、認證系統(tǒng)、認證服務(wù)器）之間是通過通信協(xié)議進行交互的，因此有必要對其相關(guān)的通信協(xié)議做個介紹。15 / 44 EAP 協(xié)議 協(xié)議采用 EAP 協(xié)議在客戶端、認證系統(tǒng)和認證服務(wù)器之間進行通信。EAP（Extensible Authentication Protocol 擴展的認證協(xié)議，RFC 2284）是PPP 認證的一個通用協(xié)議，支持多種認證機制，例如 smart cards, Kerberos, Public Key Encryption, One Time Passwords 等。EAP 在鏈路控制（LCP）階段并不選擇好一種認證機制，而把這一步推遲到認證階段。這樣就允許認證系統(tǒng)在確定某種特定認證機制之前請求更多的信息。通過支持 EAP 協(xié)議，認證系統(tǒng)只需控制其受控端口的狀態(tài)，但是并不干涉通過非受控端口在客戶端和認證服務(wù)器之間傳遞的認證信息。這樣，就實現(xiàn)了認證流和業(yè)務(wù)流的完全分離。可以使用一個“后端”服務(wù)器（認證服務(wù)器）來實際實現(xiàn)各種認證機制，認證系統(tǒng)僅僅需要傳送認證信息，并根據(jù)認證返回的結(jié)果控制受控端口的狀態(tài)。 EAP 的簡單認證過程在鏈路建立階段完成后，認證系統(tǒng)發(fā)送一個或多個 Request 來對對方進行認證。Request 中有一個 type 域表明請求的類型。Request 中 type 的實例包括，Identity, MD5challenge, OneTime Passwords, Generic Token Card 等等。MD5challenge 類型與 CHAP 認證協(xié)議緊緊對應(yīng)。典型情況下，認證系統(tǒng)將發(fā)送一個最初的 Identity 請求，然后是一個或多個請求認證信息的 Request。但是，最初的 Identity Request 并不是必需的，在 identity 能被事先假定（如租用的鏈路，專用撥號線路等等）的情況下可以跳過（bypass） ；客戶端發(fā)送一個 Response 數(shù)據(jù)包對每一個 Request 做出應(yīng)答。對應(yīng)于每一個 Request 數(shù)據(jù)包，Response 數(shù)據(jù)包包含一個 type 域，與 Request 中的 type 域?qū)?yīng)；C）認證系統(tǒng)發(fā)送一個 Success 或 Failure 數(shù)據(jù)包結(jié)束認證階段；16 / 44 EAP 幀結(jié)構(gòu)Code：1 個字節(jié)，表示 EAP 幀類型。EAP 代碼分配如下：1 Request2 Response3 Success4 FailureIdentifier：1 個字節(jié)，該值用于匹配 requests 的請求。Identifier 區(qū)域和系統(tǒng)端口一起單獨標(biāo)識一個認證過程。Length：2 個字節(jié)，該值表示 EAP 幀的總長度Data： 0 或更多字節(jié)，表示數(shù)據(jù) EAPOL 協(xié)議在 協(xié)議中定義了一種封裝技術(shù)稱為 EAPOL（EAP over LANs），主要在客戶端和認證系統(tǒng)之間傳送 EAP 協(xié)議報文，可以允許 EAP 協(xié)議報文在LAN 上傳送。圖 3—7 EAP 的幀結(jié)構(gòu)17 / 44 EAPOL 幀結(jié)構(gòu)PAE Ether Type：2 個字節(jié)，表示協(xié)議類型， 分配的協(xié)議類型為 888EProtocol Version：1 個字節(jié)，表示 EAPOL 幀的發(fā)送方所支持的協(xié)議版本號。本規(guī)范使用值為 0000 0001Packet Type：1 個字節(jié)，表示傳送的幀類型。有如下幾種幀類型。a) EAPPacket. 值為 0000 0000 ，表示為 EAP 幀b) 0000 0001 ，表示為 EAPOLStart 幀c) EAPOLLogoff. 值為 0000 0010，表示為 EAPOLLogoff 請求幀 d) EAPOLKey. 值為 0000 0011 ，表示為 EAPOLKey 幀.e) EAPOLEncapsulatedASFAlert. 值為 0000 0100Packet Body Length：2 個字節(jié)，表示 Packet Body 的長度Packet Body：如果 Packet Type 為 EAPPacket, EAPOLKey, 或EAPOLEncapsulatedASFAlert 的值，則 Packet Body 對應(yīng)相應(yīng)的值；對于其他幀類型，則該值為空。 EAPOL 幀的標(biāo)記在 EAPOL 幀傳送過程中，不帶 的 VLAN 標(biāo)記，但是可以帶 的優(yōu)先級標(biāo)記。所有的 PAE 都能夠接收帶或不帶優(yōu)先級標(biāo)記的 EAPOL 幀。圖 3—8 EAPOL 的幀結(jié)構(gòu)18 / 44 EAPOL 幀發(fā)送的目標(biāo)地址當(dāng)一個二層幀發(fā)送時，必須要有目標(biāo) MAC 地址。EAPOL 幀在發(fā)送時也不例外，當(dāng)客戶端和認證系統(tǒng)互相之間不知道發(fā)送的目標(biāo)時，其目標(biāo) MAC 地址為 協(xié)議中分配的組播地址 0180c2000003。 基本的認證過程 如圖 3—9 認證的步驟如下：? 用戶開機后，通過 客戶端軟件發(fā)起請求，查詢網(wǎng)絡(luò)上能處理EAPOL（EAP Over LAN）數(shù)據(jù)包的設(shè)備。如果某臺驗證設(shè)備能處理EAPOL 數(shù)據(jù)包，就會向客戶端發(fā)送響應(yīng)包并要求用戶提供合法的身份標(biāo)識，如用戶名/密碼；? 客戶端收到驗證設(shè)備的響應(yīng)后，會提供身份標(biāo)識給驗證設(shè)備。由于此時客戶端還未經(jīng)過驗證，因此認證流只能從驗證設(shè)備的未受控的邏輯端口經(jīng)過。驗證設(shè)備通過 EAP 協(xié)議將認證流轉(zhuǎn)發(fā)到 AAA 服務(wù)器，進圖 3—9 認證過程GE/F中IP中uHamer106FlexHamer FE FEDHCP Serv 求○DHCP Relay○ 5○3○ 4 Radius返 回認 證 結(jié) 果○ 2建 立 動 態(tài) ACL帶 寬優(yōu) 先 級向 Radius發(fā) 送 計 費 信 息 ○ 6 送 logf 請 求 下 線用 戶 死 機 或 異 常利 用 協(xié) 議 進 行 異 常 下 線 的 檢 測并 終 止 計 費○ 7認 證 通 過 ， 受 控 端 口 打 開 客 戶 端 軟 件 發(fā) 送 dhcp請 求 中中請 求○○ ○○○○ ○○ 返 回認 證 結(jié) 果○○建 立 動 態(tài)帶 寬優(yōu) 先 級向 發(fā) 送 計 費 信 息 ○○發(fā) 送請 求 下 線用 戶 死 機 或 異 常利 用 的 協(xié) 議 進 行 異 常 下 線 的 檢 測并 終 止 計 費○○認 證 通 過 ， 受 控 端 口 打 開 客 戶 端 軟 件 發(fā) 送 請 求19 / 44行認證；? 如果認證通過，則認證系統(tǒng)的受控邏輯端口打開；? 客戶端軟件發(fā)起 DHCP 請求，經(jīng)認證設(shè)備轉(zhuǎn)發(fā)到 DHCP Server；? DHCP Server 為用戶分配 IP 地址；? DHCP Server 分配的地址信息返回給認證系統(tǒng)，認證系統(tǒng)記錄用戶的相關(guān)信息，如 MAC，IP 地址等信息，并建立動態(tài)的 ACL 訪問列表，以限制用戶的權(quán)限；? 當(dāng)認證設(shè)備檢測到用戶的上網(wǎng)流量，就會向認證服務(wù)器發(fā)送計費信息，開始對用戶計費；? 如果用戶要下網(wǎng)，可以通過客戶端軟件發(fā)起 LogOff 過程，認證設(shè)備檢測到該該數(shù)據(jù)包后，會通知 AAA 服務(wù)器停止計費，并刪除用戶的相關(guān)信息（MAC/IP） ，受控邏輯端口關(guān)閉。用戶進入再認證狀態(tài)；? 驗證設(shè)備會通過定期的檢測來保證鏈路的激活，如果用戶異常死機，則驗證設(shè)備在發(fā)起多次檢測后,自動認為用戶已經(jīng)下線,于是向認證服務(wù)器發(fā)送終止計費的信息； 幾個注意的問題基于端口的網(wǎng)絡(luò)接入控制是在 LAN 設(shè)備的物理接入級對接入設(shè)備進行認證和控制，此處的物理接入級指的是 LAN 設(shè)備的端口，如 LanSwitch 的端口。連接在該類端口上的用戶設(shè)備如果能通過認證，就可以訪問 LAN 內(nèi)的資源；如果不能通過認證，則無法訪問 LAN 內(nèi)的資源，相當(dāng)于物理上斷開連接。IEEE 定義了基于端口的網(wǎng)絡(luò)接入控制協(xié)議，需要注意的是該協(xié)議僅適用于接入設(shè)備與接入端口間點到點的連接方式，其中端口可以是物理端口，也可以是邏輯端口。典型的應(yīng)用方式有：LanSwitch 的一個物理端口僅連接一個 End Station（基于物理端口） ； IEEE 定義的無線 LAN 接入方式（基于邏輯端口）等。連接有多個設(shè)備的共享式 LAN 網(wǎng)段如果想要提供每個設(shè)備的接入控制，可以使用兩種方法：1） 使用任何保護方法，為每一個接入設(shè)備建立單獨的接入控制，此時20 / 44相當(dāng)于每個 MAC 地址構(gòu)成了一個邏輯端口。由于共享式網(wǎng)段缺乏保護，每個 MAC 地址的認證過程都可能被其他設(shè)備監(jiān)聽、截獲、偽造，安全性比較低。2） 仍然使用每個 MAC 地址構(gòu)成邏輯端口，但在認證過程中對認證數(shù)據(jù)幀進行加密（IEEE 提供了與加密協(xié)議的接口） ，從而避免其他設(shè)備的監(jiān)聽、截獲、偽造，提高安全性。需要說明的，由于 MAC 地址比較容易偽造，這種方式并不能提供完善的安全機制。因而，IEEE 推薦的使用環(huán)境為點對點的物理或邏輯端口。4 幾種認證方式的比較目前業(yè)界有幾種認證方式：PPPOE、WEB 和 。以下做一個比較： PPPOE 認證 簡介1998 年后期問世的以太網(wǎng)上點對點協(xié)議（PPP over Ether）技術(shù)是由Redback 網(wǎng)絡(luò)公司、客戶端軟件開發(fā)商 RouterWare 公司以及 World 子公司UUNET Technologies 公司在 IETF RFC 制的基礎(chǔ)上聯(lián)合開發(fā)的。主要目的是把最經(jīng)濟的局域網(wǎng)技術(shù)、以太網(wǎng)和點對點協(xié)議的可擴展性及管理控制功能結(jié)合在一起。它使服務(wù)提供商在通過數(shù)字用戶線、電纜調(diào)制解調(diào)器或無線連接等方