1.概述
802.1X起源於無線網絡標準802.11協議，802.11協議是標準的無線局域網協議，802.1X協議設計的最初的目的是爲了解決無線局域網用戶的接入認證問題，但由於其原理對於所有符合IEEE802標準的局域網具有普適性，因此在有線局域網中也得到了廣泛的應用。
802.1X,全稱爲Port-BasedNetworks AccessControl，即基於端口的網絡訪問控制。“基於端口的網絡接入控制”是指在局域網接入設備的端口這一級對所接入的用戶設備進行認證和控制（這裏的端口可以是一個實實在在的物理端口，也可以是一個類似VLAN的邏輯端口，而對於無線局域網來說一個“端口”就是一條信道）。連接在端口上的用戶設備如果能通過認證，就可以訪問局域網中的資源；如果不能通過認證，則無法訪問局域網中的資源。
2.體系結構
IEEE802.1X協議採用典型的客戶端/服務器體系結構,包括三個主要的部分:客戶端(SupplicantSystem)、認證系統(AuthenticatorSystem)以及認證服務器(AuthenticationServer
System)。圖1描述了三者之間的關係以及互相之間的通信。
圖1.802.1X協議的體系結構
客戶端：是需要接入LAN/WLAN，享受switch提供服務的終端設備（比如PC、網絡打印機），該終端設備通常需要安裝一個客戶端軟件，用戶通過啓動這個客戶端軟件發起802.1X認證，同時客戶端必須支持EAPOL協議。
認證系統：通常爲支持802.1X協議的網絡設備,它爲客戶端提供接入局域網的端口。認證系統在客戶端和認證服務器之間充當代理角色，它跟客戶端之間通過EAPOL協議進行通信，跟認證服務器之間通過EAPOver Radius報文或者標準的Radius報文進行通信。
認證服務器：通常爲Radius服務器，用於實現對用戶進行認證、授權和計費。認證服務器通過檢驗客戶端發送來的身份標識，來判斷該用戶是否有權使用認證系統所提供的網絡服務。當用戶通過認證後，認證服務器會把用戶的相關信息傳遞給認證系統，由認證系統構建動態的訪問控制列表，用戶的後續流量就將接受上述參數的監管。
以上三個部分,除客戶端系統外，認證系統和認證服務器之間既可以分佈在兩個不同的物理實體上，也可以是集中在一個物理實體上，後者指的是由認證系統獨立完成用戶的認證授權，即本地認證。
3.涉及協議
3.1EAPOL協議
EAPOL(EAPoverLANs)是802.1X協議定義的一種報文封裝格式，主要用於在客戶端和設備端之間傳送EAP協議報文，以允許EAP協議報文在LAN上傳送。EAPOL數據包的格式如圖2所示：
圖3.EAPOL的幀結構
PAEEthernet Type：2字節，該值表示以太網協議類型，802.1X爲其分配的協議類型爲0x888E。
ProtocolVersion：1字節，表示EAPOL幀的發送方所使用的協議版本號，表1爲目前存在的版本號
-
版本號
含義
0x01
支持IEEEStd 802.1X-2001
0x02
支持IEEEStd 802.1X-2004
0x03
支持IEEEStd 802.1X-2010
表1. EAPOL幀使用的版本號
PacketType：1字節，表示EAPOL數據幀類型，目前支持的數據類型見表2
-
類型
說明
EAP-Packet(值爲0x00)：認證信息幀
表示該EAPOL幀承載了一個EAP數據包
EAPOL-Start(值爲0x01)：認證發起幀
這兩種類型的幀僅在客戶端和設備端之間存在
EAPOL-Logoff(值爲0x02)：退出請求幀
EAPOL-Key(值爲0x03)：密鑰信息幀
支持對EAP報文的加密（無線接入專用）
EAPOL-Encapsulated-ASF-Alert(值爲0x04)
用於支持ASF（AlertingStandards Forum）的Alerting消息
表2.EAPOL幀類型
PacketBody Length：2字節，表示數據域的長度，也就是PacketBody字段的長度，單位爲字節。當EAPOL數據幀的類型爲EAPOL-Start或EAPOL-Logoff時，該字段值爲0，表示後面沒有PacketBody字段。
PacketBody：表示數據內容，該部分內容由PacketType決定，長度有PacketBody Length決定。
3.2EAP協議
802.1X協議採用EAP(ExtensibleAuthenticationProtocol，可擴展認證協議)來實現客戶端、認證系統和認證服務器之間認證信息的交互。通過支持EAP協議，可以使用認證服務器來實現各種認證機制，認證系統僅僅需要傳送認證信息，並根據認證返回的結果控制受控端口的狀態。EAP數據包的格式如圖4所示：
圖4.EAP的幀結構
Code：1字節，該值表示EAP幀類型,共有4種：Request、Response、Success、Failure。
Identifier：1字節，該值用於匹配Request消息和Response消息。
Length：2字節，該值表示EAP幀的總長度，包含Code、Identifier、Length和Data域，單位爲字節。
Data：EAP包的內容,由Code類型決定：
Success和Failure類型的包沒有Data域，相應的Length域的值爲4；
Request和Response類型數據包的Data域的格式如圖5所示
圖5.Request和Response類型數據包的Data域的格式
Type字段目前支持的類型見表3，前3種表示特殊含義，其餘的值表示EAP支持的認證方式
-
Type值
含義
1
Identity（用戶名信息）
2
Notification（警告信息）
3
Nak(客戶端對Request中的認證方式不支持時回覆用)
4
MD5-Challenge
5
OneTime Password (OTP)
6
GenericToken Card (GTC)
13
EAP-TLS
17
EAP-LEAP
18
EAP-SIM21
EAP-TTLS
23
EAP-AKA
25
EAP-PEAP
26
EAP-MSCHAPV2
33
EAP-TLV
38
EAP-TNC
43
EAP-FAST
46
EAP-PAX
47
EAP-PSK
48
EAP-SAKE
49
EAP-IKEV2
50
EAP-AKA-PRIME
51
EAP-GPSK
254
ExpandedTypes
255
Experimentaluse
表3.EAP數據包中Type字段含義
Typedata的內容由Type決定。
與其說EAP是一個認證協議不如說EAP是一個認證框架，因爲EAP本身不是認證協議，它自己不支持認證功能，它是爲了承載多種認證協議而生的，EAP爲擴展和協商認證協議提供了一個標準，讓客戶端和RADIUS服務器之間直接協商認證數據，將NAS（網絡介入系統）網絡設備從中解脫出來。
3.3RADIUS協議
RADIUS（RemoteAuthentication Dial In UserService用戶遠程撥入認證服務）是一種AAA的應用協議，意思就是同時兼顧驗證（authentication）、授權（authorization）及計費（accounting）三種服務的一種網絡傳輸協議。RADIUS數據包的格式如圖6所示：
圖6.RADIUS的幀結構
Code：1字節，指示RADIUS包的類型，支持的類型見表4
-
Code
報文類型
報文說明
1
Access-Request
方向Client->Server，Client將用戶信息傳輸到Server以判斷是否接入該用戶。該報文中必須包含User-Name屬性，可選包含NAS-IP-Address、User-Password、NAS-Port等屬性。
2
Access-Accept
方向Server->Client，如果Access-Request報文中所有Attribute值都是可以接受（即認證通過），則傳輸該類型報文。
3
Access-Reject
方向Server->Client，如果Access-Request報文中存在任何Attribute值無法被接受（即認證失敗），則傳輸該類型報文。
4
Accounting-Request
方向Client->Server，Client將用戶信息傳輸到Server，請求Server開始計費，由該報文中的Acct-Status-Type屬性區分計費開始請求和計費結束請求。該報文包含屬性和Access-Request報文大致相同。
5
Accounting-Response
方向Server->Client，Server通知Client側已經收到Accounting-Request報文並且已經正確記錄計費信息。該報文包含端口上輸入/輸出字節數、輸入/輸出包數、會話時長等信息。
11
Access-Challenge
方向Server->Client，Server收到Client上報上來的用戶信息後，如果通過，就發送訪問質詢給Client，讓用戶提供更多的附加信息以完成認證。
表4.RADIUS數據包中Code字段含義
Identifier：1字節，取值範圍爲0～255，用於匹配請求包和響應包。
Length：2字節，表示整個報文的有效長度。長度域範圍之外的字節被認爲是附加的，並在接受的時候超長部分將被忽略。如果包長比長度域給出的短，也必須丟棄，最小長度爲20，最大長度爲4096。
Authenticator：16字節認證字域，在不同報文中用法不一樣。
a).在Access-Request包中的認證字稱爲請求認證字，是16字節隨機數,認證字的值要不能被預測,並且在一個共享密鑰的生命期內唯一。
b).在Access-Accept、Access-Reject和Access-Challenge包中的認證字稱爲訪問迴應認證字，訪問迴應認證字的值定義爲MD5(Code+ID+Length+請求認證字+Attributes+Secret)
Attributes：屬性域，用來在請求和響應報文中攜帶詳細的認證、授權、信息和配置細節，來實現認證、授權、計費等功能，一條RADIUS報文中可以攜帶多條屬性域。每條屬性域採用（Type、length、Value）三元組的形式提供。屬性域的格式見圖7
圖7.Attributes格式
Type：屬性號，用來標識本條屬性的類型，取值範圍1～255,其中26號屬性表示廠商私有屬性。標準的屬性號定義見表5
|
屬性號 |
屬性名 |
屬性號 |
屬性名 |
|
1 |
User-Name |
30 |
Called-Station-ID |
|
2 |
User-Password |
31 |
Calling-Station-ID |
|
3 |
CHAP-Password |
32 |
NAS-Identifier |
|
4 |
NAS-IP-Address |
40 |
Acct-Status-Type |
|
5 |
NAS-Port |
41 |
Acct-Delay-Time |
|
6 |
Service-Type |
43 |
Acct-Output-Octets |
|
7 |
Framed-Protocol |
44 |
Acct-Session-ID |
|
8 |
Framed-IP-Address |
45 |
Acct-Authentic |
|
9 |
Framed-IP-Netmask |
46 |
Acct-Session-Time |
|
10 |
Framed-Routing |
48 |
Acct-Output-Packets |
|
11 |
Filter-ID |
49 |
Acct-Terminate-Cause |
|
12 |
Framed-MTU |
53 |
Acct-Output-Gigaword |
|
13 |
Framed-Compression |
55 |
Event-Timestamp |
|
14 |
login-IP-Host |
60 |
CHAP-Challenge |
|
15 |
login-Service |
61 |
NAS-Port-Type |
|
16 |
login-TCP-Port |
64 |
Tunnel-Type |
|
18 |
Reply_Message |
65 |
Tunnel-Medium-Type |
|
19 |
Callback-Number |
79 |
EAP-Message |
|
20 |
Callback-ID |
80 |
Message-Authenticator |
|
24 |
State |
81 |
Tunnel-Private-Group-ID |
|
25 |
Class |
87 |
NAS-Port-ID |
|
26 |
Vendor-Specific |
95 |
NAS-IPV6-Address |
|
27 |
Session-Timeout |
96 |
Framed-Interface-ID |
|
28 |
Idle-Timeout |
97 |
Framed-IPV6-Prefix |
|
29 |
Termination-Action |
|
|
表5.Attributes中的Type字段含義
Length：表示整條屬性域的長度，最小值爲3
Value：記錄了這條屬性的具體特性，有6中屬性值：整數(INT)；枚舉(ENUM)；IP地址(IPADDR)；文本(STRING)；日期(DATE)；二進制字符串（BINARY)。
表5中，屬性號79和80是RADIUS爲支持EAP認證增加的兩個屬性：
a). EAP-Message
這個屬性用來封裝EAP數據包，屬性號爲79，如果EAP數據包長度大於253字節，可以對其進行分片，依次封裝在多個EAP-Message屬性中。
b).Message-Authenticator
屬性號爲80，主要用於在EAP認證過程中驗證攜帶了EAP-Message屬性的Radius報文的完整性，避免接入請求包被竄改。在含有EAP-Message屬性的數據包中，必須同時也包含
Message-Authenticator，否則該數據包會被認爲無效而被丟棄。此外,若接收端對接收到的Radius報文計算出的完整性校驗值與報文中攜帶的Message-Authenticator屬性的Value值不一致，該數據包也會被認爲無效而丟棄。
4.認證的基本過程
802.1X系統支持EAP中繼方式和EAP終結方式與遠端RADIUS服務器交互完成認證。以下關於兩種認證方式的過程描述，都以客戶端主動發起認證爲例。
4.1EAP中繼方式
這種方式是IEEE802.1X標準規定的，將EAP(可擴展認證協議)承載在其它高層協議中，如EAPover
RADIUS，以便擴展認證協議報文穿越複雜的網絡到達認證服務器。一般來說，EAP中繼方式需要RADIUS服務器支持EAP屬性：EAP-Message和Message-Authenticator，分別用來封裝EAP報文及對攜帶EAP-Message的RADIUS報文進行保護。下面以EAP-MD5方式爲例介紹基本認證流程，如圖8所示
圖8.IEEE 802.1X認證系統的EAP中繼方式交互流程
a).當用戶有網絡連接需求時打開802.1X客戶端程序,輸入已經申請、登記過的用戶名和密碼,發起連接請求(EAPOL-Start報文)。此時，客戶端程序將發出請求認證的報文給NAS,開始啓動一次認證過程。
b).認證系統收到開始認證的請求後，將發出一個請求幀(EAP-Request/Identity報文)要求用戶的客戶端程序發送輸入的用戶名。
c).客戶端程序響應認證系統發出的請求,將用戶名信息通過應答幀(EAP-Response/Identity報文)發送給認證系統。
d).認證系統則將客戶端送上來的數據幀經過封包處理後(RADIUSAccess-Request報文)轉發給認證服務器進行處理。
e).認證服務器收到認證系統轉發上來的用戶名信息後,將該信息與數據庫中的用戶名錶相比對,找到該用戶名對應的密碼信息，用隨機生成的一個加密字對它進行加密處理，同時也將此加密字通過RADIUSAccess-Challenge報文傳送給認證系統，再由認證系統解封包處理後（EAP-Request/MD5Challenge報文）傳給客戶端程序。
f).客戶端程序收到由認證系統傳來的加密字後，用該加密字對口令部分進行加密處理，生成
EAP-Response/MD5Challenge報文，並通過認證系統封裝爲RADIUSAccess-Request報文傳給認證服務器。
g).認證服務器將收到的已加密的密碼信息(RADIUSAccess-Request報文)和本地經過加密運算後的密碼信息進行對比，如果相同，則認爲該用戶爲合法用戶，反饋認證通過的消息(RADIUSAccess-Accept報文和EAP-Success報文)，並向認證系統發出打開端口的指令，允許用戶的業務流通過端口訪問網絡。否則，反饋認證失敗的消息(EAP-Failure報文)，並保持認證系統端口的關閉狀態，只允許認證信息數據通過而不允許業務數據通過。
h).客戶端也可以發送EAPOL-Logoff報文給認證系統，主動要求下線。設備端把端口狀態從授權狀態改變成未授權狀態，並向客戶端發送EAP-Failure報文。
4.2EAP終結方式
EAP終結方式將EAP報文在認證系統上終結，並轉換成標準的Radius協議完成認證、授權和計費。設備端與Radius服務器之間可以採用PAP(PasswordAuthentication Protocol,密碼驗證協議)或者CHAP(ChallengeHandshake AuthenticationProtocol,質詢握手驗證協議)認證方法。以下以CHAP認證方式爲例介紹認證流程,如圖9所示
圖9.IEEE 802.1X認證系統的EAP終結方式交互流程
a～c).認證過程的前3步與EAP中繼方式完全相同。
d).認證系統收到客戶端送上來的數據幀(EAP-Response/Identity報文)後，沒有上傳至認證服務器，而是本地隨機生成一個加密字，並將將此加密字的通過數據幀(EAP-Request/MD5Challenge報文)交給客戶端程序。
e).客戶端程序收到加密字(EAP-Request/MD5Challenge報文)後，用該加密字對口令部分進行加密處理，生成EAP-Response/MD5Challenge報文發送給認證系統。
f).認證系統收到加密密碼(EAP-Response/MD5Challenge)後，用CHAP協議對用戶名、加密口令、加密字等認證信息重新封裝成標準的Radius報文(RADIUSAccess-Requeset報文)，送給認證服務器進行處理。
g).認證服務器收到的認證信息(RADIUSAccess-Requeset報文)後，根據收到的用戶名信息在數據庫中查找對應的密碼信息，用收到的加密字對密碼信息進行加密處理得到自己的加密密碼。然後和收到的加密密碼信息進行對比，如果相同，則認爲該用戶爲合法用戶，反饋認證通過的消息(RADIUSAccess-Accept報文)給認證系統。
h).認證系統向客戶端程序反饋認證通過消息(EAP-Success報文)，將端口狀態改爲授權狀態，允許用戶通過該端口訪問網絡。
i).客戶端也可以發送EAPOL-Logoff報文給認證系統，主動要求下線。設備端把端口狀態從授權狀態改變成未授權狀態，並向客戶端發送EAP-Failure報文。
4.3兩種方式的對比
EAP中繼方式與EAP終結方式的認證流程十分類似，不同之處主要在於加密字的生成處理及傳遞方式。在EAP中繼方式中，用來對用戶口令信息進行加密處理的隨機加密字由認證服務器生成，認證系統只是負責將EAP報文透傳認證服務器，整個認證處理都由認證服務器來完成。而在EAP終結方式中，用來對用戶密碼信息進行加密處理的隨機加密字由認證系統生成，認證系統會把用戶名、隨機加密字和客戶端加密後的密碼信息一起送給認證服務器,進行相關的認證處理。
從上面可以看出,由於認證流程中對於加密字的生成處理及傳遞方式不同，因此EAP中繼與EAP終結兩種認證方式其優缺點也很明顯:
EAP中繼方式優點是認證系統處理更簡單，EAP上面承載的認證協議對認證系統是透明的，NAS設備不需要了解，也不需要支持，它只需要支持EAP即可，所以可以支持更多的認證方式，缺點則是認證服務器必須支持EAP；而EAP終結方式的優點是認證服務器無需升級，現有的Radius服務器可以繼續使用，缺點是NAS設備處理更復雜。
5.具體實現原理
圖10就是採用分層的方法爲802.1X的實現劃分出來的總框架圖，交換機作爲認證者角色，要實現的就是右邊半張，很明顯它被劃分爲上下兩層：HigherLayer和LowerLayer。
LowerLayer層就是圖中的802.1X模塊，我們更習慣稱爲EAPOL層；相對應的，HigherLayer層我們通常也統稱爲EAP層。這樣，實現802.1X認證者，實際上就變成了實現EAP層和EAPOL層，以及兩者的交互。
圖10.基於EAPOL層和EAP層的802.1X實現框架
802.1X認證EAPOL層的實現被定義在IEEE802.1X文檔裏（該標準到目前一共經歷了3版，IEEE802.1X-2001、IEEE802.1X-2004、IEEE802.1X-2010，這裏準備基於2004版本進行開發），而EAP層的實現被定義在RFC4137裏（StateMachines for EAP Peer and Authenticator）。
IEEE802.1X-2004標準爲EAPOL層總共定義了10個狀態機，見表6
|
|
是否需要支持（Y–需要；N–不需要；O-可選） |
|
|
狀態機名 |
認證者 |
請求者 |
|
PortTimers |
Y |
Y |
|
AuthenticatorPAE |
Y |
N |
|
TheAuthenticator Key Transmit |
O |
N |
|
TheSupplicant Key Transmit |
N |
O |
|
ReauthenticationTimer |
Y |
N |
|
BackendAuthentication |
Y |
N |
|
ControlledDirections |
Y |
N |
|
SupplicantPAE |
N |
Y |
|
SupplicantBackend |
N |
Y |
|
TheKey Receive |
O |
O |
表6.EAPOL層狀態機彙總
對於交換機來說，就是認證者角色，上表中標記了“O”的狀態機一般不用於LAN環境下也不用考慮，所以作爲認證者，實際需要實現的狀態機一共5個。
5.1Port Timers state machine（Port定時器狀態機，以下都簡稱PTSM）
圖11. Authenticator Port Timers state machine
PTSM功能比較簡單，就是每秒鐘觸發一次以從ONE_SECOND狀態進入TICK狀態。TICK狀態的EA中，它將遞減定時器變量的值，這些變量都是被其他狀態機初始化和使用的。這些定時器變量的定義見表7
-
定時器變量名
含義
aWhile
和BEAUTH SM直接相關，用於計時EAPOL層傳遞eap-resp報文給EAP層，然後等待EAP層回覆的時間，超時值爲serverTimeout
quietWhile
和AUTHPAE SM直接相關，在quietWhile時間裏，認證者不接受任何來自請求者的認證消息，超時值爲reAuthPeriod
reAuthWhen
和RTSM直接相關，定義了認證者發起重認證的間隔，超時值爲reAuthPeriod
表7.Authenticator PT SM定時器變量
5.2Authenticator PAE state machine（認證者PAE狀態機，以下都簡稱AUTHPAE SM）
圖 12.Authenticator PAE state machine
AUTHPAESM是802.1X在EAPOL層最核心的狀態機之一，它主要負責處理接收到的EAPOL報文，這其實也表示它的工作是面向請求者的；同時它又負責執行認證的結果，歸根到底也就是對PORT的管理。AUTHPAE SM整個運轉過程基本如下：
a).首先受控端口被觸發802.1X認證進入INITIALIZE，這裏的主要EA是：portMode設置爲Auto
b).從INITIALIZE無條件進入DISCONNECTED狀態，這裏的主要EA是：
authPortStatus設置爲Unauthorized;
reAuthCount清0;
清除eapolLogoff標誌
c).從DISCONNECTED會繼續無條件進入RESTART狀態，這裏的主要EA是：
eapRestart設置爲TRUE，用於通知EAP層狀態機進入INITIALIZE
d).AUTH PAESM會一直處於RESTART狀態，直到EAP層清除了eapRestart標誌，這時候就會進入CONNECTING狀態，主要的EA是：
清除reAuthenticate標誌；
累加reAuthCount計數器
e).AUTH PAESM會一直處於CONNECTING狀態，直到EAP層設置了eapReq標誌，意味着需要發送一個eapol-request-identifier，這時候就會進入AUTHENTICATING狀態，主要的EA是：
authStart設置爲TRUE，用於通知BEAUTH SM
f).