802.1X認證簡介
定義
802.1X協(xié)議是一種基于端口的網絡接入控制協(xié)議（Port based networkaccess control protocol）?！盎诙丝诘木W絡接入控制”是指在局域網接入設備的端口這一級驗證用戶身份并控制其訪問權限。
優(yōu)點
- 802.1X協(xié)議為二層協(xié)議，不需要到達三層，對接入設備的整體性能要求不高，可以有效降低建網成本。
- 認證報文和數據報文通過邏輯接口分離，提高安全性。
802.1X認證系統(tǒng)
如圖1-1所示，802.1X系統(tǒng)為典型的Client/Server結構，包括三個實體：客戶端、接入設備和認證服務器。
- 客戶端一般為一個用戶終端設備，用戶可以通過啟動客戶端軟件發(fā)起802.1X認證?？蛻舳吮仨氈С志钟蚓W上的可擴展認證協(xié)議EAPoL（Extensible Authentication Protocol over LANs）。
- 接入設備通常為支持802.1X協(xié)議的網絡設備，它為客戶端提供接入局域網的端口，充當客戶端和認證服務器之間的中介，從客戶端請求身份信息，并與認證服務器驗證該信息。根據客戶端的身份驗證狀態(tài)控制其對網絡的訪問權限。
- 認證服務器用于實現對用戶進行認證、授權和計費，通常為RADIUS服務器。
802.1X認證協(xié)議
簡介
802.1X認證系統(tǒng)使用可擴展認證協(xié)議EAP（Extensible Authentication Protocol）來實現客戶端、設備端和認證服務器之間的信息交互。EAP協(xié)議可以運行在各種底層，包括數據鏈路層和上層協(xié)議（如UDP、TCP等），而不需要IP地址。因此使用EAP協(xié)議的802.1X認證具有良好的靈活性。
- 在客戶端與設備端之間，EAP協(xié)議報文使用EAPoL（EAP over LANs）封裝格式，直接承載于LAN環(huán)境中。
- 在設備端與認證服務器之間，用戶可以根據客戶端支持情況和網絡安全要求來決定采用的認證方式。
- EAP終結方式中，EAP報文在設備端終結并重新封裝到RADIUS報文中，利用標準RADIUS協(xié)議完成認證、授權和計費。
- EAP中繼方式中，EAP報文被直接封裝到RADIUS報文中（EAP over RADIUS，簡稱為EAPoR），以便穿越復雜的網絡到達認證服務器。
EAP報文
表1-1 EAP報文字段解釋
| 字段 | 字節(jié)數 | 含義 |
|---|---|---|
| Code | 1 | 表示EAP數據包的類型，共有以下幾種1（Request）：請求。2（Response）：響應。3（Success）：成功。4（Failure）：失敗。 |
| ID | 1 | 用于匹配Request和Response。 |
| Length | 2 | 表示EAP數據包的長度，包括Code、ID、Length以及Data各字段。超出Length域范圍的字節(jié)應該視為數據鏈路層填充，在接收時應該被忽略掉。 |
| Data | 0或多個字節(jié) | Data字段的格式由Code的值來決定。當Code取值為1或者2時，EAP為Request和Response報文，Data包含Type、Type Data兩個字段，如上圖所示。其中，Type為一個字節(jié)，表示Request或Response的類型。Type Data為多個字節(jié)，內容由Type字段的值決定。當Code取值為3或者4時，EAP為Success和Failure報文，沒有Data字段。 |
表1-2 Type常用取值
| Type字段值 | 類型 | 含義 |
|---|---|---|
| 1 | Identity | 要求客戶端發(fā)送用戶輸入的用戶名信息。 |
| 2 | Notification | 非必須的通知消息，傳送一些警告消息，例如密碼已過期、賬號被鎖等。 |
| 3 | NAK | 僅用于Response幀，表示否定確認。例如設備用了客戶端不支持的認證方法發(fā)起請求，客戶端可利用Response/NAK消息以告知設備其支持的認證方法。 |
| 4 | MD5-Challenge | 認證方法為MD5質詢法。 |
| 5 | OTP（One-Time Password） | 認證方法為一次性密碼，例如網銀付費時系統(tǒng)會通過短信發(fā)送一個一次性密碼。 |
| 6 | GTC（Generic Token Card） | 認證方法為通用令牌卡。跟OTP類似，只不過GTC往往對應一個實際的設備，例如許多國內銀行都會給申請網銀的用戶一個動態(tài)口令牌，這個令牌就是GTC。 |
| 13 | EAP-TLS | 認證方法為EAP-TLS。 |
| 21 | EAP-TTLS | 認證方法為EAP-TTLS。 |
| 25 | EAP-PEAP | 認證方法為EAP-PEAP。 |
| 254 | Expanded Types | 擴展類型，支持廠商自定義的類型。 |
| 255 | Experimental use | 實驗新的類型時做測試用的類型。 |
EAPoL
EAPoL是802.1X協(xié)議定義的一種報文封裝格式，主要用于在客戶端和設備之間傳送EAP協(xié)議報文，以允許EAP協(xié)議報文在LAN上傳送。其報文結構如下：
表1-3 EAPoL報文字段解釋
| 字段 | 字節(jié)數 | 含義 |
|---|---|---|
| PAE Ethernet Type | 2 | 表示協(xié)議類型，值為0x888E。 |
| Protocol Version | 1 | 表示EAPoL幀的發(fā)送方所支持的協(xié)議版本號。0x01：802.1X-2001。0x02：802.1X-2004。0x03：802.1X-2010。 |
| Type | 1 | 表示EAPoL數據幀類型，有四種取值：00：EAP-Packet，認證報文數據，用于承載認證信息。01：EAPoL-Start，認證開始報文，用于用戶主動發(fā)起認證過程。02：EAPoL-Logoff，下線請求報文，用于用戶主動發(fā)起下線請求。03：EAPoL-Key，密鑰信息報文。EAPoL-Start，EAPoL-Logoff和EAPoL-Key僅在客戶端和設備端之間存在。 |
| Length | 2 | 表示數據長度，也就是Packet Body字段的長度，單位為字節(jié)。如果為0，則表示沒有后面的Packet Body字段。EAPoL-Start和EAPoL-Logoff報文的Length值都為0。 |
| Packet Body | 2 | 表示數據內容。 |
EAPoR
為支持EAP中繼方式，RADIUS協(xié)議增加了兩個屬性：EAP-Message（EAP消息）和Message-Authenticator（消息認證碼）。其中，EAP-Message屬性用來封裝EAP報文，Message-Authenticator屬性用于對認證報文進行認證和校驗，防止非法報文欺騙。其報文結構如下：
表1-4 EAPoR報文字段解釋
| 字段 | 字節(jié)數 | 含義 |
|---|---|---|
| Code | 1 | 表示RADIUS報文的類型。 |
| Identifier | 1 | 用來匹配請求報文和響應報文，以及檢測在一段時間內重發(fā)的請求報文?？蛻舳税l(fā)送請求報文后，服務器返回的響應報文中的Identifier值應與請求報文中的Identifier值相同。 |
| Length | 2 | 指定RADIUS報文的長度。超過Length取值的字節(jié)將作為填充字符而忽略。如果接收到的報文的實際長度小于Length的取值，則該報文會被丟棄。 |
| Response Authenticator | 16 | 驗證RADIUS服務器的響應報文，同時還用于用戶密碼的加密。 |
| Attributes | 長度不確定 | Attribute為報文的內容主體，用來攜帶專門的認證、授權和計費信息，提供請求和響應報文的配置細節(jié)。Attribute可以包括多個屬性，每一個屬性都采用（Type、Length、Value）三元組的結構來表示。類型（Type），1個字節(jié)，取值為1～255，用于表示屬性的類型。長度（Length），表示該屬性（包括類型、長度和屬性值）的長度，單位為字節(jié)。屬性值（Value），表示該屬性的信息，其格式和內容由類型和長度決定，最大長度為253字節(jié)。 |
認證方式選擇
- EAP中繼方式的優(yōu)點是設備端處理更簡單，支持更多的認證方法，缺點則是認證服務器必須支持EAP，且處理能力要足夠強。對于常用的EAP-TLS、EAP-TTLS、EAP-PEAP三種認證方式，EAP-TLS需要在客戶端和服務器上加載證書，安全性最高，EAP-TTLS、EAP-PEAP需要在服務器上加載證書，但不需要在客戶端加載證書，部署相對靈活，安全性較EAP-TLS低。
- EAP終結方式的優(yōu)點是現有的RADIUS服務器基本均支持PAP和CHAP認證，無需升級服務器，但設備端的工作比較繁重，因為在這種認證方式中，設備端不僅要從來自客戶端的EAP報文中提取客戶端認證信息，還要通過標準的RAIUDS協(xié)議對這些信息進行封裝，且不能支持除MD5-Challenge之外的其它EAP認證方法。PAP與CHAP的主要區(qū)別是CHAP密碼通過密文方式傳輸，而PAP密碼通過明文的方式傳輸。因而PAP方式認證的安全性較低，實際應用通常采用CHAP方式認證。
802.1X認證流程
802.1X認證的觸發(fā)方式
802.1X認證有以下觸發(fā)方式：
- 客戶端發(fā)送EAPoL-Start報文觸發(fā)認證。
- 客戶端發(fā)送DHCP/ARP/DHCPv6/ND或任意報文觸發(fā)認證。
- 設備發(fā)送EAP-Request/Identity報文觸發(fā)認證。
EAP中繼和EAP終結的認證流程
802.1X系統(tǒng)支持EAP中繼方式和EAP終結方式與遠端RADIUS服務器交互完成認證。以客戶端發(fā)送EAPoL-Start報文觸發(fā)認證為例，EAP中繼方式和EAP終結方式的802.1X認證流程分別如圖1-5與圖1-6所示。
- 當用戶需要訪問外部網絡時打開802.1X客戶端程序，輸入已經申請、登記過的用戶名和密碼，發(fā)起連接請求。此時，客戶端程序將向設備端發(fā)出認證請求報文（EAPoL-Start），開始啟動一次認證過程。
- 設備端收到認證請求報文后，將發(fā)出一個Identity類型的請求報文（EAP-Request/Identity）要求用戶的客戶端程序發(fā)送輸入的用戶名。
- 客戶端程序響應設備端發(fā)出的請求，將用戶名信息通過Identity類型的響應報文（EAP-Response/Identity）發(fā)送給設備端。
- 設備端將客戶端發(fā)送的響應報文中的EAP報文封裝在RADIUS報文（RADIUS Access-Request）中發(fā)送給認證服務器進行處理。
- RADIUS服務器收到設備端轉發(fā)的用戶名信息后，將該信息與數據庫中的用戶名列表中對比，找到該用戶名對應的密碼信息，用隨機生成的一個MD5 Challenge對密碼進行加密處理，同時將此MD5 Challenge通過RADIUS Access-Challenge報文發(fā)送給設備端。
- 設備端將RADIUS服務器發(fā)送的MD5 Challenge轉發(fā)給客戶端。
- 客戶端收到由設備端傳來的MD5 Challenge后，用該Challenge對密碼部分進行加密處理，生成EAP-Response/MD5 Challenge報文，并發(fā)送給設備端。
- 設備端將此EAP-Response/MD5 Challenge報文封裝在RADIUS報文（RADIUS Access-Request）中發(fā)送給RADIUS服務器。
- RADIUS服務器將收到的已加密的密碼信息和本地經過加密運算后的密碼信息進行對比，如果相同，則認為該用戶為合法用戶，并向設備端發(fā)送認證通過報文（RADIUS Access-Accept）。
- 設備收到認證通過報文后向客戶端發(fā)送認證成功報文（EAP-Success），并將端口改為授權狀態(tài)，允許用戶通過該端口訪問網絡。
- 用戶在線期間，設備端會通過向客戶端定期發(fā)送握手報文的方法，對用戶的在線情況進行監(jiān)測。
- 客戶端收到握手報文后，向設備發(fā)送應答報文，表示用戶仍然在線。缺省情況下，若設備端發(fā)送的兩次握手請求報文都未得到客戶端應答，設備端就會讓用戶下線，防止用戶因為異常原因下線而設備無法感知。
- 客戶端可以發(fā)送EAPoL-Logoff報文給設備端，主動要求下線。
-
設備端把端口狀態(tài)從授權狀態(tài)改變成未授權狀態(tài)，并向客戶端發(fā)送EAP-Failure報文。
圖1-6 EAP終結認證流程
EAP終結方式與EAP中繼方式的認證流程相比，不同之處在于用來對用戶密碼信息進行加密處理的MD5 Challenge由設備端生成，之后設備端會把用戶名、MD5 Challenge和客戶端加密后的密碼信息一起送給RADIUS服務器，進行相關的認證處理。而在EAP中繼方式中，用來對用戶密碼進行加密處理的挑戰(zhàn)字由認證服務器生成，設備端只是負責將EAP報文封裝在RADIUS報文中透傳認證服務器，整個認證處理都由認證服務器來完成。
802.1X授權
認證用于確認嘗試接入網絡的用戶身份是否合法，而授權則用于指定身份合法的用戶所能擁有的網絡訪問權限，即用戶能夠訪問哪些資源。授權最基礎也是最常使用的授權參數是VLAN、ACL和UCL組，此處以RADIUS授權進行說明，其他授權方式的授權方法以及更多可授權的參數請參見AAA授權方案。
VLAN
為了將受限的網絡資源與未認證用戶隔離，通常將受限的網絡資源和未認證的用戶劃分到不同的VLAN。用戶認證成功后，認證服務器將指定VLAN授權給用戶。此時，設備會將用戶所屬的VLAN修改為授權的VLAN，授權的VLAN并不改變接口的配置。但是，授權的VLAN優(yōu)先級高于用戶配置的VLAN，即用戶認證成功后生效的VLAN是授權的VLAN，用戶配置的VLAN在用戶下線后生效。RADIUS服務器授權VLAN時，必須同時使用以下RADIUS標準屬性：
- Tunnel-Type：必須配置為“VLAN”或“13”
- Tunnel-Medium-Type：必須配置為“802”或“6”
- Tunnel-Private-Group-ID：可以是VLAN ID、VLAN描述
ACL
用戶認證成功后，認證服務器將指定ACL授權給用戶，則設備會根據該ACL對用戶報文進行控制。
- 如果用戶報文匹配到該ACL中動作為permit的規(guī)則，則允許其通過。
- 如果用戶報文匹配到該ACL中動作為deny的規(guī)則，則將其丟棄。
RADIUS服務器授權ACL有兩種方法：
- 授權靜態(tài)ACL：RADIUS服務器通過RADIUS標準屬性Filter-Id將ACL ID授權給用戶。為使授權的ACL生效，需要提前在設備上配置相應的ACL及規(guī)則。
- 授權動態(tài)ACL：RADIUS服務器通過華為RADIUS擴展屬性HW-Data-Filter將ACL ID及其ACL規(guī)則授權給用戶。ACL ID及其ACL規(guī)則需要在RADIUS服務器上配置，設備上不需要配置。
UCL
用戶控制列表UCL組（User Control List）是網絡成員的集合。UCL組里面的成員，可以是PC、手機等網絡終端設備。借助UCL組，管理員可以將具有相同網絡訪問策略的一類用戶劃分為同一個組，然后為其部署一組網絡訪問策略，滿足該類別所有用戶的網絡訪問需求。相對于為每個用戶部署網絡訪問策略，基于UCL組的網絡控制方案能夠極大的減少管理員的工作量。RADIUS服務器授權UCL組有兩種方式：
- 授權UCL組名稱：RADIUS服務器通過RADIUS標準屬性Filter-Id將UCL組名稱授權給指定用戶。
- 授權UCL組ID：RADIUS服務器通過華為RADIUS擴展屬性HW-UCL-Group將UCL組ID授權給指定用戶。
無論是哪一種授權UCL組方式，都必須提前在設備上配置相應的UCL組及UCL組的網絡訪問策略。
free-rule
用戶認證成功之前，為滿足用戶基本的網絡訪問需求，需要用戶認證成功前就能獲取部分網絡訪問權限?？稍趂ree-rule模板中配置free-rule規(guī)則，滿足用戶的認證成功前的網絡訪問需求。
用戶的free-rule可以通過普通的free-rule定義，也可以通過ACL定義。普通的free-rule由IP地址、MAC地址、接口、VLAN等參數確定；通過ACL定義的free-rule由ACL規(guī)則確定。兩種方式定義的free-rule都能夠指定用戶認證成功前就可以訪問的目的IP地址。除此之外，ACL定義的free-rule還能夠指定用戶認證成功前就可以訪問的目的域名。
基于域名定義用戶的free-rule有時要比基于IP地址簡單方便。例如，某些認證用戶由于沒有認證賬號，必須首先在運營商提供的官方網站上注冊申請會員賬號；或者通過微博、微信等第三方賬號進行登錄。這就要求用戶認證通過前，能夠訪問特定的網站。由于用戶記憶網站的域名要比記憶其IP地址容易的多，所以，此時可以通過ACL定義的free-rule，指定用戶認證成功前即可訪問以上網站域名。
802.1X重認證
802.1X認證成功用戶
若管理員在認證服務器上修改了某一用戶的訪問權限、授權屬性等參數，此時如果用戶已經在線，則需要及時對該用戶進行重認證以確保用戶的合法性。配置對在線802.1X用戶進行重認證功能后，設備會把保存的在線用戶的認證參數（用戶上線后，設備上會保存該用戶的認證信息）發(fā)送到認證服務器進行重認證，若認證服務器上用戶的認證信息沒有變化，則用戶正常在線；若用戶的認證信息已更改，則用戶將會被下線，此后用戶需要重新進行認證。802.1X認證成功用戶重認證方式如表1-5所示。
表1-5 802.1X認證成功用戶重認證方式
| 配置點 | 方式 | 配置命令 |
|---|---|---|
| 在接入設備側配置 | 對802.1X認證成功用戶進行周期性重認證。 | dot1x reauthenticate****dot1x timer reauthenticate-period reauthenticate-period-value |
| 手動對指定MAC地址進行單次重認證。 | dot1x reauthenticate mac-address mac-address | |
| 在RADIUS服務器側配置 | 對802.1X認證成功的用戶下發(fā)RADIUS標準屬性Session-Timeout和Termination-Action，其中，Session-Timeout屬性值為用戶在線時長定時器，Termination-Action屬性值為1表示對用戶進行重認證。當用戶在線時長達到Session-Timeout的屬性值時，設備會對用戶進行重認證。 | 無 |
異常認證狀態(tài)下的用戶
用戶在預連接階段或認證失敗階段，設備會記錄用戶表項信息，并能夠為用戶分配受限的網絡訪問權限。為使用戶能夠及時認證成功，獲取正常的網絡訪問權限，設備根據用戶表項對沒有認證成功的用戶進行重認證。
在用戶表項老化時間到達之前，如果用戶重認證沒有成功，設備將刪除對應的表項信息，并收回授予用戶的網絡訪問權限；如果用戶重認證成功，設備將用戶加入到認證成功的用戶表項，并授予認證成功后的網絡訪問權限。該部分用戶的重認證方式如表1-6所示。
表1-6 異常認證狀態(tài)下的用戶重認證方式
| 用戶狀態(tài) | 配置命令 |
|---|---|
| RADIUS服務器Down | authentication event authen-server-up action re-authen：配置當RADIUS服務器真正UP時對用戶進行重認證。 |
| 認證失敗 | authentication timer re-authen authen-fail re-authen-time：配置對認證失敗用戶進行周期性重認證。 |
| 預連接 | authentication timer re-authen pre-authen re-authen-time：配置對預連接用戶進行周期性重認證。 |
802.1X認證用戶下線
當用戶已下線，而接入設備和RADIUS服務器未感知到該用戶已下線時，會產生以下問題：
- RADIUS服務器仍會對該用戶進行計費，造成誤計費。
- 存在非法用戶仿冒合法用戶IP地址和MAC地址接入網絡的風險。
- 已下線用戶數量過多的情況下，還會占用設備用戶規(guī)格，可能會導致其他用戶無法接入網絡。
因此，接入設備要能夠及時感知到用戶已下線，刪除該用戶表項，并通知RADIUS服務器停止對該用戶進行計費。
用戶下線方式分為客戶端主動下線，接入設備控制用戶下線和服務器控制用戶下線。
客戶端主動下線
用戶通過客戶端軟件發(fā)送EAPoL-Logoff報文主動下線，設備端會向客戶端發(fā)一個EAP-Failure的報文，進而將端口狀態(tài)由授權狀態(tài)轉換為非授權狀態(tài)。
接入設備控制用戶下線
接入設備控制用戶下線有兩種方式：
- 在接入設備上執(zhí)行命令強制指定用戶下線。
- 在接入設備上配置用戶探測功能，用于探測用戶是否在線。當用戶在指定的時間內無響應，則認為用戶下線，刪除用戶表項。
當管理員發(fā)現非法用戶在線，或在測試中想讓某一用戶下線后重新上線，可以通過在設備上執(zhí)行命令強制該用戶下線。對于正常接入用戶，會通過ARP探測對用戶在線狀態(tài)進行確認，如果探測到用戶下線，則進行下線處理，刪除用戶表項。
假設用戶的握手周期為3T。通過命令authentication timer handshake-period handshake-period配置。T=handshake-period/3。
- 用戶發(fā)送任意報文觸發(fā)802.1X認證，同時啟動探測定時器。
- 在若干個T時間內，接入設備均能收到客戶端流量，用戶在線。
- 用戶最后一次發(fā)送報文。在這個T時間結束時，由于有客戶端流量，接入設備判斷用戶在線，并重啟定時器。
- 接入設備在T時間內未收到客戶端流量，發(fā)送第一次ARP請求，客戶端無響應。
- T時間后，接入設備仍未收到客戶端流量，發(fā)送第二次ARP請求，客戶端無響應。
- T時間后，接入設備仍未收到客戶端流量，探測失敗，刪除用戶表項。
服務器控制用戶下線
服務器控制用戶下線有以下方式：
- RADIUS服務器可通過DM報文（Disconnect Message）強制用戶下線。DM（Disconnect Message）是指用戶離線報文，即由RADIUS服務器端主動發(fā)起的強迫用戶下線的報文。
- RADIUS服務器通過授權RADIUS標準屬性Session-Timeout和Termination-Action。其中，Session-Timeout為用戶在線時長定時器，Termination-Action屬性值為0表示將用戶下線。當用戶在線的時長達到定時器指定的數值時，設備會將用戶下線。
802.1X定時器
802.1X認證中，通過定時器對認證過程進行控制，下面分別介紹一下這幾種定時器。
EAP-Request/Identity請求超時
在802.1X認證中，設備會向客戶端發(fā)送EAP-Request/Identity報文請求用戶名，請求報文的重傳次數和時間間隔由命令行控制。
如圖1-9 所示，設備發(fā)送EAP-Request/Identity請求報文超時后，向客戶端發(fā)送認證失敗報文。通常情況下，客戶端認證失敗時，為使得客戶端能夠繼續(xù)訪問網絡，會在設備上啟用備用機制（Portal認證或授權特定訪問權限）。
未配置MAC旁路認證時，定時器由命令dot1x timer tx-period tx-period配置，設備重傳請求報文的次數通過命令dot1x retry max-retry-value配置。EAP-Request/Identity請求超時計算公式為：Timeout = (max-retry-value +1) * tx-period-value
如圖1-10所示，當配置MAC旁路認證功能后，設備首先會對用戶進行802.1X認證，同時啟動命令dot1x timer mac-bypass-delay delay-time-value配置的定時器。如果定時器時間delay-time-value到達而802.1X認證仍未成功，則設備開始對用戶進行MAC認證?？梢酝ㄟ^命令dot1x retry max-retry-value配置設備向802.1X用戶發(fā)送認證請求的重傳次數max-retry-value，重傳時間間隔為delay-time-value/(max-retry-value+1)的整數部分。
EAP-Request/MD5 Challenge請求超時
當設備向802.1X客戶端發(fā)送了EAP-Request/MD5 Challenge請求報文后，設備啟動802.1X客戶端認證超時定時器。若在該定時器設置的時長內，設備沒有收到客戶端的響應，則設備將重發(fā)該報文。若設備重傳請求報文的次數達到配置的最大值（通過命令dot1x retry max-retry-value配置）后，仍然沒有得到用戶響應，則停止發(fā)送認證請求。這能夠避免不斷重復向用戶發(fā)送認證請求報文而占用大量的設備資源。
如圖1-11所示，設備發(fā)送EAP-Request/MD5 Challenge請求報文超時后，向客戶端發(fā)送認證失敗報文。通常情況下，客戶端認證失敗時，為使得客戶端能夠繼續(xù)訪問網絡，會在接入設備上啟用備用機制（MAC認證、Portal認證或授權特定的訪問權限）。EAP-Request/MD5 Challenge請求超時計算公式如下所示：
Timeout = (max-retry-value +1) * client-timeout-value
802.1X認證靜默定時器
使能靜默功能后，若某一用戶在60秒內認證失敗的次數超過命令dot1x quiet-times fail-times規(guī)定的值，則設備會將該用戶靜默一段時間，該時間由命令dot1x timer quiet-period quiet-period-value指定，在靜默時間內，設備會丟棄該用戶的802.1X認證請求，從而避免用戶在短時間內頻繁認證失敗。
