802.1x协议是基于Client/Server的访问控制和认证协议。 它可以限制未经授权的用户/设备通过接入端口(access port)访问LAN/WLAN。在获得交换机或LAN提供的各种业务之前，802.1x对连接到交换机端口上的用户/设备进行认证。在认证通过之前，802.1x只允许EAPOL（基于局域网的扩展认证协议）数据通过设备连接的交换机端口；认证通过以后，正常的数据可以顺利地通过以太网端口。

客户端：局域网用户终端设备，但必须是支持EAPOL（Extensible Authentication Protocol over LAN，局域网可扩展认证协议）的设备（如PC机），可通过启动客户端设备上安装的802.1x客户端软件发起802.1x认证。

设备端：支持802.1x协议的网络设备（如交换机），对所连接的客户端进行认证。它为客户端提供接入局域网的端口，可以是物理端口，也可以是逻辑端口（如Eth-Trunk口）。

认证服务器：为设备端802.1x协议提供认证服务的设备，是真正进行认证的设备，实现对用户进行认证、授权和计费，通常为RADIUS服务器。

EAP中继模式： EAP终结模式

Code：EAP报文的类型，包括Request（1）、Response（2）、Success（3）和Failure（4）。 Identifier：用于匹配Request消息和Response消息的标识符。 Length：EAP报文的长度，包含Code、Identifier、Length和Data域，单位为字节。 Data：EAP报文的内容，该字段仅在EAP报文的类型为Request和Response时存在，它由类型域和类型数据两部分组成，例如，类型域为1表示Identity类型，类型域为4表示MD5 challenge类型。 Type：指出EAP的认证类型。其中，值为1时，代表ldentity，用来查询对方的身份；值为4时，代表MD5-Challenge，类似于PPP CHAP协议，包含质询消息；值为18时，代表eap-sim认证；值为25时，代表PEAP认证。

EAP-Packet（值为00），认证报文数据，用于承载认证信息； EAPOL-Start（值为01），认证开始报文，用于主动发起认证过程； EAPOL-Logoff（值为02），下线请求报文，用于用户主动发起下线请求； EAPOL-Key（值为03），密钥信息报文； EAPOL-Encapsulated-ASF-Alert（值为04），用于支持ASF（Alerting Standards Forum）的Alerting消息。

其中，EAPOL-Start，EAPOL-Logoff和EAPOL-Key仅在客户端和设备端之间存在；在设备端和认证服务器之间，EAP-Packet报文会被重新封装承载于RADIUS协议上，我们称之为EAPoR，以便穿越复杂的网络到达认证服务器；EAPOL-Encapsulated-ASF-Alert封装与网管相关的信息，例如各种警告信息，由设备端终结。 注意，当是EAPOL-Start或EAPOL-Logoff类型报文时，并不需要PacketBody有具体的内容。

1.当用户有上网需求时打开802.1X客户端程序，输入用户名和口令，发起连接请求。此时客户端程序将发出请求认证的报文给交换机，启动一次认证过程。

2.交换机在收到请求认证的数据帧后，将发出一个EAP-Request/Identitybaowe 请求帧要求客户端程序发送用户输入的用户名。

3.客户端程序响应交换机的请求，将包含用户名信息的一个EAP-Response/Identity 送给交换机，

在含有EAP-Message 属性的数据包中，必须同时也包含Message-Authenticator，否则该数据包会被认为无效而被丢弃

4.认证服务器收到交换机转发上来的用户名信息后，将该信息与数据库中的用户名表相比对，找到该用户名对应的口令信息，用随机生成的一个加密字Challenge对它进行加密处理（MD5），

通过接入设备将 RADIUS Access-Challenge报文发送给客户端，其中包含有EAP-Request/MD5-Challenge。

5.客户端收到EAP-Request/MD5-Challenge 报文后，用该加密字对口令部分进行加密处理（MD5）给交换机发送在EAP-Response/MD5-Challenge 回应

交换机将Challenge，Challenged Password 和用户名一起送到RADIUS 服务器进行认证。 Authenticator，访问请求认证字，用于确认radius client和radius server之间消息认证的有效性和密码隐藏算法，也被用于访问回应认证字的MD5计算。

6.认证服务器将送上来的加密后的口令信息和其自己经过加密运算后的口令信息进行对比，判断用户是否合法，然后回应认证成功/失败报文到接入设备。如果认证成功，则向交换机发出打开端囗的指令，允许用户的业务流通过端口访问网络。否则，保持交换机端口的关闭状态，只允许认证信息数据通过。

1、EOPAL start 该数据包的前14字节是MAC帧的头部信息，1-6 字节内容为目标的 MAC 地址， 7-12 字节为源 MAC地址，13-14字节为该数据帧类型。从第15字节开始为 MAC层封装的实际通信内容。从MAC帧的头部信息可以看出，EAPOL-Start消息发向了FF-FF-FF-FF-FF-FF 这个广播（broadcast）地址，源地址则将请求者的位置告诉验证者。MAC帧头的Type字段的值为0x888e，表示了该帧封装了802 .1X Authentication数据，以下各包的Type字段均是 0x888e。从第15字节开始是802 .1X Authentication内容。第15字节为Version字段，值为1；第16字节为Type字段，表示了该 802.1X Authentication 的类型，这个包值为1 ，表示 Start（开始认证过程）；第17- 18字节为 Length字段，它表示的是802.1X Authentication 封装的 EA P消息的长度，由于EAPOL-Start没有包含EAP消息，所以此处为 0。以下各包的802.1X Authentication 格式和这个包是一样的，Type和Length值有变化。 2、EAP-Request Identity 当认证者接收到刚才的请求者发送的 EA POL-Start 消息后， 将开始整个认证流程。认证者向请求者发送 EAP-Request Identity消息，请求其身份。从第19 字节开始是EAP消息。第19字节为Code字段，值为1表示Request ，值为2表示Response，显然这个包的Code值为1 ；第20字节为Id字段，表示EAP消息序号，该消息的Id为1；第21-22字节为Length字段，它表示EAP消息的长度，和802.1X Authentication的Length字段代表相同的语意。这个消息长度为 5 字节，所以此处值为5；第23字节为Type字段，表示EAP消息的类型，该消息Type值为0，表示 Identity。在802.1X Authentication部分，Type字段为0，表示EAP Packet； Length字段值为5 ，表示EAP消息长度为5。 3、EAP-Response Identity 我们主要看EAP消息部分。第19字节的Code字段值为2表示Response；第20字节为Id字段值为1，对应EAP-Request Identity的Id，表示对Id为1的 Request的回应；第21-22字节的Length字段值为10；第23字节的Type字段值仍为1， 表示Identity；第24字节开始是Identity的内容，长度为5字节。也就是用户名。 4、EAP-Request MD5-Challenge 认证者收到了EAP- Response Identity消息后，得到了请求者的身份信息，接着向请求者发出EAP-Request MD5-Challenge，质询密码之类的认证信息。第20字节为Id字段值为2；第21-22字节的Length字段值为22 ；第23字节的 Type字段值为4，表示MD5-Challenge；第24字节是Value -Size字段，表示Val ue字段的长度。此处值为16 ，Value也是使用MD5生成；第25-40字节为 Value 字段内容，提供给请求者在后面的MD5计算中使用 0387c01542dec1444322fc9626a6c56d。 5、EAP-Response MD5-Challenge 请求者收到了 EAP-Request MD5-Challenge 消息后，将消息的 Id 、自己的密码和消息的Value组合成16进制串，计算MD5值 ，填入EAP-Response MD5-Challenge，发送给认证者。 第20字节为Id字段值为2，对应Request；第21-22字节的Length字段值为27 ；第23字节的Type字段值仍为4；第24字节的Value-Size字段值仍为16，因为MD5算法得到的结果长度为 16个字节；第25-40字节为Value字段内容。这个串是由Request的Id+密码的16进制ASCII码+Request的Value组合成的16进制串经过MD5算法计算而成；第41-53字节为Extradata，长度为5字节，内容仍为16进制ASCII码表示的用户身份，也就是用户名。 6、EAP-Success 验证者收到请求者回应的EAP-Response MD5-Challenge消息后， 将该消息重新封装如RADIUS数据包，发送给后面的认证服务器。认证服务器确认用户名/密码正确后，发送EAP -Success，认证者再将该消息重新封装发送给请求者，表明认证已经通过，进入授权状态。EAP-Success消息很简单。第19字节的Code字段值为3表示Success；第20字节为Id字段值仍然为2，表明是之前Id为2的Challenge的结果 ；第21-22字节的Length字段值为4。

CHAP（Challenge Handshake Authentication Protocol）验证协议为三次握手(交互)验证协议 chap并不会直接在认证过程传递用户密码，而是传递 md5 ( chapID + 密码 + challenge )， 服务端通过比较md5值判断用户密码是否在正确， client 和 server 之前存在一个 challenge “协商”过程

但在radius 协议中， NAS（交换机）与radius服务器的交互，并不需要三次交互， NAS会将认证信息 “打包”给radius 服务器校验

radius服务器 chap 用户名/密码 校验原理 （1）radius 服务器通过用户名（明文）， 找出对应的密码，此时密码为pass （2）计算 md5 ( chapID + 密码 + challenge ) ， 并判断 是否与 chap-password （从第2字节开始比较） 一致，如果一致， 则认为密码正确

截图中， md5 ( chapID + 密码 + challenge ) 与 chap string 一致， 由此可知，用户密码正确

0x0a 是chapID 0x70 0x61 0x73 0x73 是密码，转换便是：pass 剩下的十六字节便是MD5-challenge，组成后进行 md5 ( chapID + 密码 + challenge ) 得到的值与CHAP String相等。

以下示例说明如何手动计数值，以确保其计算正确。

已选择数据包编号30（访问请求）。它处于EAP会话中，且数据包包含Message-Authenticator字段。目的是验证消息验证器是否正确： 右键单击Radius Protocol并选择Export Selected packet bytes。

将该RADIUS负载写入文件（二进制数据）。

要计算消息验证器字段，必须将零置于此处并计算HMAC-MD5。

例如，当您使用十六进制/二进制编辑器（如vim）时，在键入“：%!xxd”后，它会切换到十六进制模式，从“5012”后开始为16个字节(50hex是80，其中是消息验证器类型，12是18，包括属性值对(AVP)报头):

修改后，负载就绪。必须返回十六进制/二进制模式(类型：“:%!xxd -r”)并保存文件(“:wq”)。

使用OpenSSL计算HMAC-MD5:

HMAD-MD5函数采用两个参数：第一个来自标准输入(stdin)是消息本身，第二个是共享密钥（本例中为思科）。 结果与附加到RADIUS Access-Request数据包的消息验证器的值完全相同。

使用Python脚本可以计算相同值：

802.1x认证基础 802.1X协议及Radius协议 RADIUS无效身份验证器和消息身份验证器故障排除指南