最新8021X原理及测试.docx

最新8021X原理及测试.docx

《最新8021X原理及测试.docx》由会员分享，可在线阅读，更多相关《最新8021X原理及测试.docx（40页珍藏版）》请在冰点文库上搜索。

最新8021X原理及测试

8021X原理及测试

802.1X原理及测试

第一章802.1X简介

1.1引言

802.1X协议起源于802.11协议，后者是IEEE的无线局域网协议，制订802.1X协议的初衷是为了解决无线局域网用户的接入认证问题。

IEEE802LAN协议定义的局域网并不提供接入认证，只要用户能接入局域网控制设备（如LANSwitch），就可以访问局域网中的设备或资源。

这在早期企业网有线LAN应用环境下并不存在明显的安全隐患。

随着移动办公及驻地网运营等应用的大规模发展，服务提供者需要对用户的接入进行控制和配置。

尤其是WLAN的应用和LAN接入在电信网上大规模开展，有必要对端口加以控制以实现用户级的接入控制，802.1X就是IEEE为了解决基于端口的接入控制（Port-BasedNetworkAccessControl）而定义的一个标准。

1.2802.1X认证体系

802.1X是一种基于端口的认证协议，是一种对用户进行认证的方法和策略。

端口可以是一个物理端口，也可以是一个逻辑端口（如VLAN）。

对于无线局域网来说，一个端口就是一个信道。

802.1X认证的最终目的就是确定一个端口是否可用。

对于一个端口，如果认证成功那么就“打开”这个端口，允许所有的报文通过；如果认证不成功就使这个端口保持“关闭”，即只允许802.1X的认证协议报文通过。

802.1X的体系结构如图1所示。

它的体系结构中包括三个部分，即请求者系统、认证系统和认证服务器系统三部分：

图1802.1X认证的体系结构

1.请求者系统

请求者是位于局域网链路一端的实体，由连接到该链路另一端的认证系统对其进行认证。

请求者通常是支持802.1X认证的用户终端设备，用户通过启动客户端软件发起802.1X认证，后文的认证请求者和客户端二者表达相同含义。

2.认证系统

认证系统对连接到链路对端的认证请求者进行认证。

认证系统通常为支持802.1X协议的网络设备，它为请求者提供服务端口，该端口可以是物理端口也可以是逻辑端口，一般在用户接入设备（如LANSwitch和AP）上实现802.1X认证。

后文的认证系统、认证点和接入设备三者表达相同含义。

3.认证服务器系统

认证服务器是为认证系统提供认证服务的实体，建议使用RADIUS服务器来实现认证服务器的认证和授权功能。

请求者和认证系统之间运行802.1X定义的EAPOL（ExtensibleAuthenticationProtocoloverLAN）协议。

当认证系统工作于中继方式时，认证系统与认证服务器之间也运行EAP协议，EAP帧中封装认证数据，将该协议承载在其它高层次协议中（如RADIUS），以便穿越复杂的网络到达认证服务器；当认证系统工作于终结方式时，认证系统终结EAPOL消息，并转换为其它认证协议（如RADIUS），传递用户认证信息给认证服务器系统。

认证系统每个物理端口内部包含有受控端口和非受控端口。

非受控端口始终处于双向连通状态，主要用来传递EAPOL协议帧，可随时保证接收认证请求者发出的EAPOL认证报文；受控端口只有在认证通过的状态下才打开，用于传递网络资源和服务。

1.3802.1X认证流程

基于802.1X的认证系统在客户端和认证系统之间使用EAPOL格式封装EAP协议传送认证信息，认证系统与认证服务器之间通过RADIUS协议传送认证信息。

由于EAP协议的可扩展性，基于EAP协议的认证系统可以使用多种不同的认证算法，如EAP-MD5，EAP-TLS，EAP-SIM，EAP-TTLS以及EAP-AKA等认证方法。

以EAP-MD5为例，描述802.1X的认证流程。

EAP-MD5是一种单向认证机制，可以完成网络对用户的认证，但认证过程不支持加密密钥的生成。

基于EAP-MD5的802.1X认证流程如图2所示，认证流程包括以下步骤：

（1）客户端向接入设备发送一个EAPOL-Start报文，开始802.1X认证接入；

（2）接入设备向客户端发送EAP-Request/Identity报文，要求客户端将用户名送上来；

（3）客户端回应一个EAP-Response/Identity给接入设备的请求，其中包括用户名；

（4）接入设备将EAP-Response/Identity报文封装到RADIUSAccess-Request报文中，发送给认证服务器；

（5）认证服务器产生一个Challenge，通过接入设备将RADIUSAccess-Challenge报文发送给客户端，其中包含有EAP-Request/MD5-Challenge；

（6）接入设备通过EAP-Request/MD5-Challenge发送给客户端，要求客户端进行认证；

（7）客户端收到EAP-Request/MD5-Challenge报文后，将密码和Challenge做MD5算法后的Challenged-Pass-word，在EAP-Response/MD5-Challenge回应给接入设备；

（8）接入设备将Challenge，ChallengedPassword和用户名一起送到RADIUS服务器，由RADIUS服务器进行认证；

（9）RADIUS服务器根据用户信息，做MD5算法，判断用户是否合法，然后回应认证成功/失败报文到接入设备。

如果成功，携带协商参数，以及用户的相关业务属性给用户授权。

如果认证失败，则流程到此结束；

（10）如果认证通过，用户通过标准的DHCP协议（可以是DHCPRelay），通过接入设备获取规划的IP地址；

（11）如果认证通过，接入设备发起计费开始请求给RADIUS用户认证服务器；

（12）RADIUS用户认证服务器回应计费开始请求报文。

用户上线完毕。

图2基于EAP-MD5的802.1X认证流程

第二章802.1X协议介绍

802.1X定义了基于端口的网络接入控制协议，需要注意的是该协议仅适用于接入设备与接入端口间点到点的连接方式。

为了在点到点链路上建立通信，在链路建立阶段PPP链路的每一端都必须首先发送LCP数据包来对该数据链路进行配置。

在链路已经建立起来后，在进入网络层协议之前PPP提供一个可选的认证阶段，而EAPOL就是PPP的一个可扩展的认证协议。

2.1802.1X协议的工作机制

802.1X作为一个认证协议，在实现的过程中有很多重要的工作机制。

图3802.1X协议的工作机制

2.1.1认证发起

认证的发起可以由用户主动发起，也可以由认证系统发起。

当认证系统探测到未经过认证的用户使用网络，就会主动发起认证；用户端则可以通过客户端软件向认证系统发送EAPOL-Start报文发起认证。

1）由认证系统发起的认证

当认证系统检测到有未经认证的用户使用网络时，就会发起认证。

在认证开始之前，端口的状态被强制为未认证状态。

如果客户端的身份标识不可知，则认证系统会发送EAP-Request/Identity报文，请求客户端发送身份标识。

这样，就开始了典型的认证过程。

客户端在收到来自认证系统的EAP-Request报文后，将发送EAP-Response报文响应认证系统的请求。

认证系统支持定期的重新认证，可以随时对一个端口发起重新认证的过程。

如果端口状态为已认证状态，则当认证系统发起重新认证时，该端口通过认证，那么状态保持不便；如果未通过认证，则端口的状态改变为未认证状态

2）由客户端发起认证

如果用户要上网，则可以通过客户端软件主动发起认证。

客户端软件会向认证系统发送EAPOL-Start报文主动发起认证。

认证系统在收到客户端发送的EAPOL-Start报文后，会发送EAP-Request/Identity报文响应用户请求，要求用户发送身份标识，这样就启动了一个认证过程。

2.1.2退出认证状态

有几种方式可以造成认证系统把端口状态从已认证状态改变成未认证状态：

a）客户端未通过认证服务器的认证；

b）由于管理性的控制端口始终处于未认证状态，而不管是否通过认证；

c）与端口对应的MAC地址出现故障（管理性禁止或硬件故障）；

d）客户端与认证系统之间的连接失败，造成认证超时；

e）重新认证超时；

f）客户端未响应认证系统发起的认证请求；

g）客户端发送EAPOL-Logoff报文，主动下线；

退出已认证状态的直接结果就是导致用户下线，如果用户要继续上网则要再发起一个认证过程。

为什么要专门提供一个EAPOL-Logoff机制，是处于如下安全的考虑：

当一个用户从一台终端退出后，很可能其他用户不通过发起一个新的登录请求，就可以利用该设备访问网络。

提供专门的退出机制，以确保用户与认证系统专有的会话进程被中止，可以防止用户的访问权限被他人盗用。

通过发送EAPOL-Logoff报文，可以使认证系统将对应的端口状态改变为未认证状态。

2.1.3重新认证

为了保证用户和认证系统之间的链路处于激活状态，而不因为用户端设备发生故障造成异常死机，从而影响对用户计费的准确性，认证系统可以定期发起重新认证过程，该过程对于用户是透明的，也即用户无需再次输入用户名/密码。

重新认证由认证系统发起，时间是从最近一次成功认证后算起。

重新认证可以激活或关闭。

重新认证的时间由重认证超时参数控制，默认值为3600秒（一个小时）而且默认重新认证是关闭的。

注意——重新认证的时间设定需要认真的规划，认证系统对端口进入的MAC地址的检测能力会影响到该时间的设定。

如果对MAC地址的检测比较可靠，则重新认证时间可以设长一些。

2.1.4认证报文丢失重传

对于认证系统和客户端之间通信的EAP报文，如果发生丢失，由认证系统负责进行报文的重传。

在设定重传的时间时，考虑网络的实际环境，通常会认为认证系统和客户端之间报文丢失的几率比较低以及传送延迟低，因此一般通过一个超时计数器来设定，默认重传时间为30秒钟。

对于有些报文的丢失重传比较特殊，如EAPOL-Star报文的丢失，由客户端负责重传；而对于EAP-Failure和EAP-Success报文，由于客户端无法识别，认证系统不会重传。

由于对用户身份合法性的认证最终由认证服务器执行，认证系统和认证服务器之间的报文丢失重传也很重要。

另外注意，对于用户的认证，在执行802.1X认证时，只有认证通过后，才有DHCP发起（如果配置为DHCP的自动获取）和IP分配的过程。

由于客户终端配置了DHCP自动获取，则可能在未启动802.1X客户端之前，就发起了DHCP的请求，而此时认证系统处于禁止通行状态，这样认证系统会丢掉初始化的DHCP帧，同时会触发认证系统发起对用户的认证。

2.1.5与不支持802.1X的设备的兼容

对于从一个没有认证的系统过渡到认证系统，最理想的状态是希望能够平滑的进行过渡。

由于802.1X协议是一个比较新的协议，如果应用在原有的旧网络中，则可能会存在与不支持设备的兼容性问题。

如果客户端支持802.1X协议，而网络设备不支持（也就是没有认证系统），则客户端是不会收到认证系统响应的EAP-Request/Identity报文。

在802.1X认证发起阶段，客户端首先发送EAPOL-Star报文到802.1X协议组申请的组播MAC地址，以查询网络上可以处理802.1X的设备（即认证系统），由于网络中没有设备充当认证系统，所以客户端是得不到响应的。

因此客户端在发起多次连接请求无响应后，自动认为已经通过认证。

如果客户端不支持802.1X协议，而网络中存在802.1X协议的认证系统，则客户端是不会响应认证系统发送的EAP-Request/Identity报文，因此端口会始终处于未认证状态。

2.2协议实现内容

802.1X协议在实现整个安全认证的过程中，其三个关键部分（客户端、认证系统、认证服务器）之间是通过通信协议进行交互的，因此有必要对其相关的通信协议EAPOL做个介绍。

下面是一个典型的PPP协议的帧格式：

当PPP帧中的protocol域表明协议类型为C227（PPPEAP）时，在PPP数据链路层帧的Information域中封装且仅封装PPPEAP数据包，此时表明将应用PPP的扩展认证协议EAP。

这个时候这个封装着EAP报文的Information域就担负起了下一步认证的全部任务，下一步的EAP认证都将通过它来进行。

一个典型的EAP认证的过程分为：

request、response、success或者failure阶段，每一个阶段的报文传送都由Information域所携带的EAP报文来承担。

EAP报文的格式为：

Code域为一个字节，表示了EAP数据包的类型，EAP的Code的值指定和意义如下：

Code＝1——Request

Code＝2——Response

Code＝3——Success

Code＝4——Failure

Identifier域为一个字节，辅助进行request和response的匹配——每一个request都应该有一个response相对应，这样的一个Identifier域就建立了这样的一个对应关系——相同的Identifier相匹配。

Length域为两个字节，表明了EAP数据包的长度，包括Code、Identifier、Length以及Data等各域。

超出Length域范围的字节应该视为数据链路层填充（padding），在接收时应该被忽略掉。

Data域为0个或者多个字节，Data域的格式由Code的值来决定。

下面分别介绍Code为不同值的时候报文的格式和各个域的定义。

1）当Code域为1或者2的时候，这个时候为EAP的request和response报文，报文的格式为：

Identifier域为一个字节。

在等待Response时根据timeout而重发的Request的Identifier域必须相同。

任何新的（非重发的）Request必须修改Identifier域。

如果对方收到了重复的Request，并且已经发送了对该Request的Response，则对方必须重发该Response。

如果对方在给最初的Request发送Response之前收到重复的Request（也就是说，它在等待用户输入），它必须悄悄的丢弃重复的Request。

Length域为两个字节，表明EAP数据包的长度，包括Code、Identifier、Length、Type以及Type-Data等各域。

超出Length域的字节应视为数据链路层填充（padding），在接收时应该被忽略掉。

Type域为一个字节,该域表明了Request或Response的类型。

在EAP的Request或Response中必须出现且仅出现一个Type。

通常Response中的Type域和Request中的Type域相同。

但是，Response可以有个Nak类型，表明Request中的Type不能被对方接受。

当对方发送Nak来响应一个Request时，它可以暗示它所希望使用并且支持的认证类型。

TypeData域随Request和相对应的Response的Type的不同而不同。

Type域总共分为6个值域，其中头3种Type被认为特殊情形的Type，其余的Type定义了认证的交换流量。

Nak类型仅对Response数据包有效，不允许把它放在Request中发送。

Type＝1——Identifier

Type＝2——Notification

Type＝3——Nak（ResponseOnly）

Type＝4——MD5-Challenge

Type＝5——One-TimePassword（OTP）

Type＝6——GenericTokenCard

2）当Code域为3或者4的时候，这个时候为EAP的Success和Failure报文，报文的格式为：

当Code为3的时候是Success报文，当Code为4的时候是Failure报文。

Identifier域为一个字节，辅助匹配Response应答。

Identifier域必须与其正在应答的Response域中的Identifier域相匹配。

2.3典型应用的拓扑结构

在实际的网络拓扑结构中，有两种典型的应用：

带802.1X的设备作为接入层设备、带802.1X的设备作为汇接层设备。

带802.1X的设备作为接入层设备，拓扑图如图4所示，该拓扑的主要特点如下：

1）每台支持802.1X的交换机所负责的客户端少，认证速度快。

各台交换机之间相互独立，交换机的重起等操作不会影响到其它交换机所连接的用户；

2）用户的管理集中于RadiusServer上，管理员不必考虑用户连接在哪台交换机上，便于管理员的管理；

3）管理员可以通过网络管理到接入层的设备。

带802.1X的设备作为汇接层设备，拓扑图如图5所示，该拓扑的主要特点如下：

1）由于是汇接层设备，网络规模大，下接用户数多，对设备的要求高，因为若该层设备发生故障，将导致大量用户不能正常访问网络；

2）用户的管理集中于RadiusServer上，管理员不比考虑用户连接在哪台交换机上，便于管理员的管理；

3）接入层设备可以使用较廉价的非网管型交换机（只要支持EAPOL帧透传）；

4）管理员不能通过网络直接管理到接入层设备。

图4认证系统作接入层设备

图5认证系统作汇接层设备

第三章实验拓扑及抓包

本章的实验拓扑及抓包分析都是基于认证体系的三个部分：

请求者系统、认证系统和认证服务器系统。

3.1TL-SL3226P实验拓扑及认证软件

实验拓扑如图6所示，请求者系统即普通工作站PC，上面安装了认证客户端软件TpSupplicant，认证系统即支持802.1X的交换机，拓扑实验中是我司的TL-SL3226P，认证服务器系统即RadiusServer，实验中是运行WinRadius软件的普通PC。

图6TL-SL3226P实验拓扑图

TL-SL3226P页面认证设置如图7、图8所示，认证配置分为交换机配置和端口配置，交换机配置中各参数要与服务器的IP、端口、密钥对应，端口配置是与认证客户机所连接的端口是否打开认证功能。

图7TL-SL3226P认证配置

图8TL-SL3226P认证端口配置

3.2TL-SL3226P认证过程抓包分析

3.2.1认证发起抓包分析

点击客户端软件TpSupplicant的连接请求时，一个完整的认证过程如图9所示。

图9802.1X认证过程（MD5-Challenge）

下面重点分析一下整个认证过程。

1）客户端向接入设备发送一个EAPOL-Start报文，开始802.1X认证接入，见图9报文11；

2）接入设备向客户端发送EAP-Request/Identity报文，要求客户端将用户名送上来，见图9报文12；

3）客户端回应一个EAP-Response/Identity给接入设备的请求，见图9报文13，其中包括用户名hgs（在WinRadius软件中自己添加的用户名），如下图红色区域所示；

4）接入设备将EAP-Response/Identity报文封装到RADIUSAccess-Request报文中，发送给认证服务器，见图9报文14；

3）认证服务器产生一个Challenge，通过接入设备将RADIUSAccess-Challenge报文发送给客户端，其中包含有EAP-Request/MD5-Challenge，见图9报文15；

4）接入设备把EAP-Request/MD5-Challenge发送给客户端，要求客户端进行认证，见图9报文16；

5）客户端收到EAP-Request/MD5-Challenge报文后，将密码和Challenge做MD5算法后的Challenged-Pass-word，在EAP-Response/MD5-Challenge回应给接入设备，见图9报文17；

6）接入设备将Challenge，ChallengedPassword和用户名一起送到RADIUS服务器，由RADIUS服务器进行认证，见图9报文18；

7）RADIUS服务器根据用户信息，做MD5算法，判断用户是否合法，然后回应认证成功/失败报文到接入设备。

如果成功，携带协商参数，以及用户的相关业务属性给用户授权，见图9报文19。

如果认证失败，则流程到此结束；

8）接入设备将Challenge，ChallengedPassword和用户名一起送到RADIUS服务器，由RADIUS服务器进行认证，见图9报文20；

9）如果认证通过，接入设备发起计费开始请求给RADIUS用户认证服务器，见图9报文21；

10）RADIUS用户认证服务器回应计费开始请求报文，认证成功，见图9报文22、23。

如果用户名或者密码错误，则认证只会到第九步就会结束，过程如图10所示。

图10输入错误的密码后的认证过程

下图为认证失败后EAP-Failure报文结构。

图11是使用TP-LINK扩展认证算法的一个完整认证过程。

图11802.1X认证过程（TP-LINK扩展认证算法）

3.2.2退出认证抓包分析

图12为客户端主动点击断开时抓包过程。

图13是把交换机和客户端连接的端口2改为Disable后断开的过程，由图12、图13可以看出，客户端主动断开连接时它会主动发出一个EAPOL-Logoff报文给交换机通知它已断开，而交换机端口状态改变时交换机会主动向客户端发一个EAP-Failure的报文。

图12客户端断开连接

图13交换机端口状态改变

3.2.3认证成功后抓包分析

当客户端认证成功后，客户端与交换机每隔一定的时间有一个报文信息的交互，如图14所示。

图14认证成功后

3.2.4多客户端认证

当TL-SL3226P一个端口连接有多台客户机时，拓扑图如图15所示。

图15多客户端认证

上图中，Switch1为TL-SL3226P，Switch2为TL-SG1005D，Client1和Client2都认证成功后，TL-SL3226P页面上有如下信息显示：

端口2的用户数目为2，并且受控端口下正确显示出已通过认证的客户端MAC地址。

某一时刻Client1或Client2主动断开连接或者链接物理断开时，不会影响另一台Client的正常应用。

3.3H3CS5100认证实验

3.3.1认证过程

H3CS5100交换机支持EAP终结方式和EAP中继方式进行认证。

1.EAP中继方式

这种方式是IEEE802.1X标准规定的，将EAP协议承载在其他高层协议中，如EAPoverRADIUS，以便扩展认证协议报文穿越复杂的网络到达认证服务器。

一般来说，EAP中继方式需要RADIUS服务器支持EAP属性：

EAP-Message（值为79）和Message-Authenticator（值为80）。

EAP中继方式有四种认证方法：

EAP-MD5、EAP-TLS（TransportLayerSecurity，传输层安全）、EAP-TTLS和PEAP（ProtectedExtensibleAuthenticationProtocol，受保护的扩展认证协议）。

以下以EAP-MD5方式为例介绍基本业务流程，如图16所示：

图16802.1X认证系统的EAP中继方式业务流程

2.EAP终结方式

这种方式将EAP报文在设备端终结并映射到RADIUS报文中，利用标准RADIUS协议完成认证和计费。

对于EA