802.1X认证原理描述

定义

802.1X协议是一种基于端口的网络接入控制协议（Port based networkaccess control protocol）。“基于端口的网络接入控制”是指在局域网接入设备的端口这一级验证用户身份并控制其访问权限。

优点

• 802.1X协议为二层协议，不需要到达三层，对接入设备的整体性能要求不高，可以有效降低建网成本。
• 认证报文和数据报文通过逻辑接口分离，提高安全性。

802.1X认证系统

如图2-1所示，802.1X系统为典型的Client/Server结构，包括三个实体：客户端、接入设备和认证服务器。

图2-1 802.1X认证系统

简介

EAP报文

图2-2 EAP报文

EAPoL

EAPoL是802.1X协议定义的一种报文封装格式，主要用于在客户端和设备之间传送EAP协议报文，以允许EAP协议报文在LAN上传送。其报文结构如下：

图2-3 EAPoL报文

EAPoR

为支持EAP中继方式，RADIUS协议增加了两个属性：EAP-Message（EAP消息）和Message-Authenticator（消息认证码）。其中，EAP-Message属性用来封装EAP报文，Message-Authenticator属性用于对认证报文进行认证和校验，防止非法报文欺骗。其报文结构如下：

图2-4 EAPoR报文

认证方式选择

• EAP中继方式的优点是设备端处理更简单，支持更多的认证方法，缺点则是认证服务器必须支持EAP，且处理能力要足够强。对于常用的EAP-TLS、EAP-TTLS、EAP-PEAP三种认证方式，EAP-TLS需要在客户端和服务器上加载证书，安全性最高，EAP-TTLS、EAP-PEAP需要在服务器上加载证书，但不需要在客户端加载证书，部署相对灵活，安全性较EAP-TLS低。
• EAP终结方式的优点是现有的RADIUS服务器基本均支持PAP和CHAP认证，无需升级服务器，但设备端的工作比较繁重，因为在这种认证方式中，设备端不仅要从来自客户端的EAP报文中提取客户端认证信息，还要通过标准的RADIUS协议对这些信息进行封装，且不能支持除MD5-Challenge之外的其它EAP认证方法。PAP与CHAP的主要区别是CHAP密码通过密文方式传输，而PAP密码通过明文的方式传输。因而PAP方式认证的安全性较低，实际应用通常采用CHAP方式认证。

802.1X认证的触发方式

EAP中继和EAP终结的认证流程

802.1X系统支持EAP中继方式和EAP终结方式与远端RADIUS服务器交互完成认证。以客户端发送EAPoL-Start报文触发认证为例，EAP中继方式和EAP终结方式的802.1X认证流程分别如图2-5与图2-6所示。

图2-5 EAP中继认证流程

1. 客户端发送EAPoL-Start报文触发认证。

2. 设备端发出一个Identity类型的请求报文（EAP-Request/Identity）请求客户端的身份信息。

3. 客户端程序响应设备端发出的请求，将身份信息通过Identity类型的响应报文（EAP-Response/Identity）发送给设备端。

4. 设备端响应报文中的EAP报文封装在RADIUS报文（RADIUS Access-Request）中，发送给认证服务器进行处理。

5. RADIUS服务器收到设备端转发的身份信息后，启动和客户端EAP认证方法的协商。RADIUS服务器选择一个EAP认证方法，将认证方法封装在RADIUS Access-Challenge报文中，发送给设备端。

6. 设备端收到RADIUS服务器发送的RADIUS Access-Challenge报文后，将其中的EAP信息转发给客户端。

7. 客户端收到由设备端传来的EAP信息后，解析其中的EAP认证方法，如果支持该认证方法，客户端发送EAP-Response报文给设备端；如果不支持，客户端选择一个支持的EAP认证方法封装到EAP-Response报文中发送给设备端。

8. 设备将报文中的EAP信息封装到RADIUS报文中发给RADIUS服务器。
9. RADIUS服务器收到后，如果客户端与服务器选择的认证方法一致，EAP认证方法协商成功，开始认证。以EAP-PEAP认证方法为例，服务器将自己的证书封装到RADIUS报文中发送给设备端。设备收到后将证书转发给客户端。客户端校验服务器证书（可选），与RADIUS服务器协商TLS参数，建立TLS隧道。TLS隧道建立完成后，用户信息将通过TLS加密在客户端、设备端和RADIUS服务器之间传输。如果客户端与服务器的EAP认证方法协商失败，则终止认证流程，通知设备认证失败，设备去关联客户端。
10. RADIUS服务器完成对客户端身份验证之后，通知设备认证成功。
11. 设备收到认证通过报文后向客户端发送认证成功报文（EAP-Success），并将端口改为授权状态，允许用户通过该端口访问网络。
12. 用户在线期间，设备端会通过向客户端定期发送握手报文的方法，对用户的在线情况进行监测。具体实现参见authentication handshake命令。
13. 客户端收到握手报文后，向设备发送应答报文，表示用户仍然在线。缺省情况下，若设备端发送的两次握手请求报文都未得到客户端应答，设备端就会让用户下线，防止用户因为异常原因下线而设备无法感知。具体实现参见authentication handshake命令。
14. 客户端可以发送EAPoL-Logoff报文给设备端，主动要求下线。
15. 设备端把端口状态从授权状态改变成未授权状态，并向客户端发送EAP-Failure报文。

图2-6 EAP终结认证流程

EAP终结方式与EAP中继方式的认证流程相比，不同之处在于EAP认证方法协商由客户端和设备端完成，之后设备端会把用户信息送给RADIUS服务器，进行相关的认证处理。而在EAP中继方式中，EAP认证方法协商由客户端和服务器完成，设备端只是负责将EAP报文封装在RADIUS报文中透传认证服务器，整个认证处理都由认证服务器来完成。

VLAN

ACL

用户认证成功后，认证服务器将指定ACL授权给用户，则设备会根据该ACL对用户报文进行控制。

• 如果用户报文匹配到该ACL中动作为permit的规则，则允许其通过。
• 如果用户报文匹配到该ACL中动作为deny的规则，则将其丢弃。

RADIUS服务器授权ACL有两种方法：

• 授权静态ACL：RADIUS服务器通过RADIUS标准属性Filter-Id将ACL ID授权给用户。为使授权的ACL生效，需要提前在设备上配置相应的ACL及规则。
• 授权动态ACL：RADIUS服务器通过华为RADIUS扩展属性HW-Data-Filter将ACL ID及其ACL规则授权给用户。ACL ID及其ACL规则需要在RADIUS服务器上配置，设备上不需要配置。

UCL

free-rule

用户认证成功之前，为满足用户基本的网络访问需求，需要用户认证成功前就能获取部分网络访问权限。可在free-rule模板中配置free-rule规则，满足用户的认证成功前的网络访问需求。

用户的free-rule可以通过普通的free-rule定义，也可以通过ACL定义。普通的free-rule由IP地址、MAC地址、接口、VLAN等参数确定；通过ACL定义的free-rule由ACL规则确定。两种方式定义的free-rule都能够指定用户无需认证就可以访问的目的IP地址。除此之外，ACL定义的free-rule还能够指定用户认证成功前就可以访问的目的域名。

基于域名定义用户的free-rule有时要比基于IP地址简单方便。例如，某些认证用户由于没有认证账号，必须首先在运营商提供的官方网站上注册申请会员账号；或者通过微博、微信等第三方账号进行登录。这就要求用户认证通过前，能够访问特定的网站。由于用户记忆网站的域名要比记忆其IP地址容易的多，所以，此时可以通过ACL定义的free-rule，指定用户认证成功前即可访问以上网站域名。

802.1X认证成功用户

若管理员在认证服务器上修改了某一用户的访问权限、授权属性等参数，此时如果用户已经在线，则需要及时对该用户进行重认证以确保用户的合法性。配置对在线802.1X用户进行重认证功能后，设备会把保存的在线用户的认证参数（用户上线后，设备上会保存该用户的认证信息）发送到认证服务器进行重认证，若认证服务器上用户的认证信息没有变化，则用户正常在线；若用户的认证信息已更改，则用户将会被下线，此后用户需要重新进行认证。802.1X认证成功用户重认证方式如表2-6所示。

异常认证状态下的用户

用户在预连接阶段或认证失败阶段，设备会记录用户表项信息，并能够为用户分配受限的网络访问权限。为使用户能够及时认证成功，获取正常的网络访问权限，设备根据用户表项对没有认证成功的用户进行重认证。

在用户表项老化时间到达之前，如果用户重认证没有成功，设备将删除对应的表项信息，并收回授予用户的网络访问权限；如果用户重认证成功，设备将用户加入到认证成功的用户表项，并授予认证成功后的网络访问权限。该部分用户的重认证方式如表2-7所示。

客户端主动下线

用户通过客户端软件发送EAPoL-Logoff报文主动下线，设备端会向客户端发一个EAP-Failure的报文，进而将端口状态由授权状态转换为非授权状态。

图2-7 客户端主动下线的交互流程

接入设备控制用户下线

接入设备控制用户下线有两种方式：

• 在接入设备上执行命令强制指定用户下线。
• 在接入设备上配置用户探测功能，用于探测用户是否在线。当用户在指定的时间内无响应，则认为用户下线，删除用户表项。

当管理员发现非法用户在线，或在测试中想让某一用户下线后重新上线，可以通过在设备上执行命令强制该用户下线。对于正常接入用户，会通过ARP探测对用户在线状态进行确认，如果探测到用户下线，则进行下线处理，删除用户表项。

图2-8 用户下线探测流程

用户发送任意报文触发802.1X认证，同时启动探测定时器。假如握手周期为3T（通过命令authentication timer handshake-period handshake-period配置。T=handshake-period/3），则设备会在T、2T时刻进行用户探测，探测方式为ARP报文探测。以0～T时间段为例，T～2T与之类似，不再赘述。（该流程仅适用于从S5720-EI、S5720-HI、S5730-HI、S5731-H-K、S5731-H、S5731S-H、S5731-S、S5731S-S、S6720-HI、S5732-H-K、S5732-H、S6730-H、S6730-H-K、S6730S-H、S6730-S、S6730S-S、S6720-EI和S6720S-EI认证上线的用户。其他款型设备不对用户流量进行检测，在T、2T时刻立即发送探测报文。）

• 如果在0～T时间段内，有用户流量经过设备，则在T时刻，设备认为用户在线，该时刻设备不会再发送探测报文，并重置探测定时器（即3T）周期。
• 如果在0～T时间段内，没有用户流量经过设备，则在T时刻，设备无法感知到用户是否在线，该时刻设备会发送探测报文。如果设备收到用户的回应报文，则认为用户在线，并重置探测定时器；如果未收到，则认为用户已下线。
• 如果在2T～3T时间段内，有用户流量经过设备，则在3T时刻，设备认为用户在线，该时刻设备重置探测定时器。

• 如果在2T～3T时间段内，没有用户流量经过设备，则在3T时刻，设备无法感知到用户是否在线，认为用户已下线。

如果在T、2T、3T时刻，设备均认为用户已下线，则设备会删除该用户的所有相关表项。为防止用户PC闲置时被异常下线，请不要将握手周期设置的过小，推荐使用默认值。

服务器控制用户下线

服务器控制用户下线有以下方式：

• RADIUS服务器可通过DM报文（Disconnect Message）强制用户下线。DM（Disconnect Message）是指用户离线报文，即由RADIUS服务器端主动发起的强制用户下线的报文。
• RADIUS服务器通过授权RADIUS标准属性Session-Timeout和Termination-Action。其中，Session-Timeout为用户在线时长定时器，Termination-Action属性值为0表示将用户下线。当用户在线的时长达到定时器指定的数值时，设备会将用户下线。

EAP-Request/Identity请求超时

在802.1X认证中，设备会向客户端发送EAP-Request/Identity报文请求用户名，请求报文的重传次数和时间间隔由命令行控制。

如图2-9所示，设备发送EAP-Request/Identity请求报文超时后，向客户端发送认证失败报文。通常情况下，客户端认证失败时，为使得客户端能够继续访问网络，会在设备上启用备用机制（Portal认证或授权特定访问权限）。

未配置MAC旁路认证时，定时器由命令dot1x timer tx-period tx-period配置，设备重传请求报文的次数通过命令dot1x retry max-retry-value配置。EAP-Request/Identity请求超时计算公式为：Timeout = (max-retry-value +1) * tx-period-value

图2-9 802.1X认证EAP-Request/Identity请求超时

如图2-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用户发送认证请求的重传次数max-retry-value，重传时间间隔为delay-time-value/(max-retry-value+1)的整数部分。

图2-10 MAC旁路认证请求超时

EAP-Request/MD5 Challenge请求超时

当设备向802.1X客户端发送了EAP-Request/MD5 Challenge请求报文后，设备启动802.1X客户端认证超时定时器。若在该定时器设置的时长内，设备没有收到客户端的响应，则设备将重发该报文。若设备重传请求报文的次数达到配置的最大值（通过命令dot1x retry max-retry-value配置）后，仍然没有得到用户响应，则停止发送认证请求。这能够避免不断重复向用户发送认证请求报文而占用大量的设备资源。

如图2-11所示，设备发送EAP-Request/MD5 Challenge请求报文超时后，向客户端发送认证失败报文。通常情况下，客户端认证失败时，为使得客户端能够继续访问网络，会在接入设备上启用备用机制（MAC认证、Portal认证或授权特定的访问权限）。EAP-Request/MD5 Challenge请求超时计算公式如下所示：

Timeout = (max-retry-value +1) * client-timeout-value

图2-11 802.1X认证EAP-Request/MD5 Challenge请求超时

802.1X认证静默定时器

使能静默功能后，若某一用户在60秒内认证失败的次数超过命令dot1x quiet-times fail-times规定的值，则设备会将该用户静默一段时间，该时间由命令dot1x timer quiet-period quiet-period-value指定，在静默时间内，设备会丢弃该用户的802.1X认证请求，从而避免用户在短时间内频繁认证失败。

图2-12 802.1X认证静默定时器