802.1X&EAP——一文学会802.1X框架

最新推荐文章于 2024-06-28 15:37:35 发布

Alamo14

最新推荐文章于 2024-06-28 15:37:35 发布

阅读量5.6k

点赞数 10

分类专栏： 802.11 WLAN Wi-Fi 文章标签：网络协议网络安全

本文链接：https://blog.csdn.net/weixin_44140376/article/details/124152214

版权

802.11 WLAN Wi-Fi 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

802.1X简介

0 简介

IEEE 802.1X 是一种对有线或无线以太网 LAN（以及 IEEE 802 系列中可能的其他网络方案）进行按用户或按设备进行身份验证的方法，全称为Port-Based Networks Access Control，即“基于端口的网络访问控制”。

它最初是为有线以太网网络设计和部署的，后来被 IEEE 802.11（无线 LAN）工作组采用，作为 802.11i 安全附录的一部分，用作按用户或按设备进行身份验证的方法用于 802.11 网络。

与 Wi-Fi 其他加密方式相比，使用 802.1X 的区别在于，不再使用网络范围的预共享密钥（PSK），使用 802.1X 时，身份验证过程中会产生类似 PSK 的密钥生成种子（seed），用于后续 PMK 的生成。因此避免了密钥在网络空间的传输，解决了密钥配送问题，从加密体制上提高了加密的安全性。

802.1X协议采用典型的客户端/服务器体系结构，包括三个主要的部分：客户端（Supplicant System）、认证系统（Authenticator System）以及认证服务器（Authentication Server System）。这三者之间的信息交互基于EAP协议（Extensible Authentication Protocol，可扩展认证协议）。

EAP 提供了一种通用机制，用于传输身份验证消息（身份验证请求，质询，响应，成功通知等），而 EAP 层不必知道所使用的特定身份验证方法的详细信息。有许多不同的“ EAP 类型”（不同种类的EAP 身份验证机制），用于通过用户名和密码，证书，令牌卡等进行身份验证。

为了使EAP报文可以直接承载于LAN环境中，802.1X定义了一种报文封装格式：EAPoL（EAP over LANs）。

由于 EAP 开发之处多用于 PPP 和 VPN ，因此很容易与 RADIUS认证服务器进行交互。因此，802.1X大都采用RADIUS作为认证服务器（在技术上不是唯一的），而支持 802.1X 的 802.11 AP广泛包含 RADIUS客户端。AP 通常不知道任何人的用户名或密码，甚至也不知道如何处理各种 EAP 身份验证类型，他们只知道如何从 802.1X 接收通用 EAP 消息，然后将其转换为 RADIUS 消息并将其转发到 RADIUS 服务器。因此，AP 只是身份验证的渠道，而不是它的参与方。身份验证的真正端点通常是无线客户端和 RADIUS 服务器（或 RADIUS 服务器网关连接到的某些上游身份验证服务器）。

注：802.1X是一个独立的规范（不是另一个规范的附录），因此在IEEE命名约定中，它使用大写字母。因此，它是802.1X，而不是802.1x。

1 802.1X体系结构&RADIUS服务器

1.1 802.1X体系结构

图1.1 802.1X体系结构

如图1.1 ，802.1X体系分为三个部分：

客户端（Supplicant System），对应我们常用场景即为STA，下文将客户端简称为STA。要求客户端中安装有支持802.1X协议的软件，用户通过启动这个软件发起802.1X协议的认证过程。为支持基于端口的接入控制，客户端系统必须支持EAPoL协议。
认证系统（Authenticator System），也称为NAS（Network Access System，即网络接入系统）。通常为支持802.1X的网络设备。为了便于理解，下文中所有的认证系统都用NAS代称。对应我们常用场景即为AP。在启动了802.1X认证的情况下，该设备上用于客户端接入的每个物理端口对应两个逻辑端口：受控端口（Controlled Port）和非受控端口（Uncontrolled Port）。
- 非受控端口始终处于双向连通状态，主要用来传递EAPoL协议帧，保证客户端始终可以发送或接受认证信息。
- 受控端口只有在认证通过的状态下才打开，用于传递业务信息帧。为适应不同的应用环境，受控端口可配置为单向受控和双向受控两种方式。双向受控时，禁止帧的发送和接收；单向受控时，禁止NAS从客户端接受帧，但允许NAS向客户端发送帧。
认证服务器（Authentication Server System），通常为RADIUS服务器，下文将认证服务器简称为RADIUS。详见1.2章节。

STA和NAS通过LAN或者WLAN进行通信，报文封装格式为EAPoL。NAS和RADIUS之间通过RADIUS协议承载的EAP/PAP/CHAP等格式的报文进行通信。应用RADIUS的802.1X协议实现过程如图 1.2：

图1.2 应用RADIUS的802.1X协议实现过程

1.2 RADIUS服务器

RADIUS（Remote Authentication Dial In User Service, 远程用户拨号认证系统）由RFC2865、RFC2866定义，是应用最广泛的AAA协议。

1.2.1 AAA协议

AAA协议是认证（Authentication）、授权（Authorization）和计费（Accounting）的简称，是网络安全中进行访问控制的一种安全管理机制，提供认证、授权和计费三种安全服务。

AAA协议一般采用C/S（即客户端/服务端）模式，这种模式结构简单、扩展性好，且便于集中管理用户信息，如图1.3为AAA协议的一般结构。

图1.3 AAA协议结构

远程接入用户通过ISDN（Integrated Services Digital Network，综合业务数字网）或PSTN（Public Switched Telephone Network，公共交换电话网络）与NAS建立连接，从而获得访问其他网络（如Internet）的权利或取得网络资源。
NAS（在RADIUS中作为客户端）负责把用户的认证、授权、计费信息透传给AAA服务器，NAS相当于中转站，不对用户数据做改动。
AAA服务器接收到用户的连接请求，对用户身份进行验证，返回用户配置信息给NAS，NAS再把该信息返回给用户。

认证方式分为本地认证——即在NAS端进行认证、授权和计费；和远程认证——通过协议进行远程的认证、授权和计费。

在AAA服务器上实现认证、授权和计费的协议主要包括RADIUS和TACACS+协议（华为称HWTACACS），以及Diameter等，其中RADIUS协议应用最为广泛。

1.2.2 RADIUS协议

RADIUS主要完成在NAS和认证服务器之间承载认证、授权、计费和配置信息的功能，是一种分布式的、客户机/服务器结构的信息交互协议，它能保护网络不受未授权访问的干扰。

RADIUS用来管理使用串口和调制解调器的大量分散用户。当用户想要通过某个网络(如电话网)与NAS建立连接从而获得访问其他网络的权利时，NAS可以选择在NAS上进行本地认证计费，或把用户信息传递给RADIUS服务器，由RADIUS进行认证计费；RADIUS 协议规定了NAS与RADIUS 服务器之间如何传递用户信息和计费信息，即两者之间的通信规则；RADIUS服务器负责接收用户的连接请求，完成认证，并把用户所需的配置信息返回给NAS。用户获得授权后，在其正常上线、在线和下线过程中，RADIUS服务器还完成对用户账号计费的功能。

RADIUS与AAA结合可以实现对远程接入用户身份、权限以及流量的严格控制。RADIUS为服务供应商和公司提供了一种灵活通用的协议,用来完成集中式的用户认证、口令加密、服务选择、过滤和帐目核对等工作。当进行PAP/CHAP连接或连接第三方认证服务器时,一个单独的RADIUS数据库服务器可以在多个复杂网络上同时管理多个安全系统,并可用于维护成千上万用户的信息安全。

图1.4 RADIUS协议

RADIUS不仅指运行于服务器上的软件,还包括网络访问服务器与RADIUS服务器之间的交互操作协议。RADIUS协议的典型流程如图1.4。基本交互过程如下：

用户输入用户名和口令；
RADIUS客户端根据获取的用户名和口令，向RADIUS服务器发送认证请求包（Access-Request）。
RADIUS服务器将该用户信息与Users数据库信息进行对比分析，如果认证成功，则将用户的权限信息以认证响应包（Access-Accept）发送给RADIUS客户端；如果认证失败，则返回Access-Reject响应包。
RADIUS客户端根据接收到的认证结果接入/拒绝用户。如果可以接入用户，则RADIUS客户端向RADIUS服务器发送计费开始请求包（Accounting-Request），Status-Type取值为start；
RADIUS服务器返回计费开始响应包（Accounting-Response）；
RADIUS客户端向RADIUS服务器发送计费停止请求包（Accounting-Request），Status-Type取值为stop；
RADIUS服务器返回计费结束响应包（Accounting-Response）

RADIU协议承载于UDP之上，官方指定端口号为认证授权端口1812、计费端口1813。其在协议栈的位置如图 1.5。

图1.5 RADIUS协议在协议栈中的位置

RADIUS服务器可使用H3C的iMC服务器，也可以使用CISCO的ACS服务器或其它第三方服务器。

1.2.3 RADIUS报文格式

RADIUS数据包的格式如图1.6：

图1.6 RADIUS数据包的格式

Code：1字节，指示RADIUS包的类型，支持的类型见表1.1

表1.1 Code指代的RADIUS包类型

Identifier：1字节，取值范围为0～255，用于匹配请求包和响应包。
Length：2字节，表示整个报文的有效长度。长度域范围之外的字节被认为是附加的，并在接受的时候超长部分将被忽略。如果包长比长度域给出的短，也必须丢弃，最小长度为20，最大长度为4096。
Authenticator：16字节认证字域，在不同报文中用法不一样。
- - 在Access-Request包中的认证字称为请求认证字，是16字节随机数,认证字的值要不能被预测,并且在一个共享密钥的生命期内唯一。
  - 在Access-Accept、Access-Reject和Access-Challenge包中的认证字称为访问回应认证字，访问回应认证字的值定义为MD5(Code+ID+Length+请求认证字+Attributes+Secret)
- Attributes：属性域，用来在请求和响应报文中携带详细的认证、授权、信息和配置细节，来实现认证、授权、计费等功能，一条RADIUS报文中可以携带多条属性域。每条属性域采用（Type、length、Value）三元组的形式提供。属性域的格式见图1.7

图1.7 属性域格式

Type：属性号，用来标识本条属性的类型，取值范围1～255,其中26号属性表示厂商私有属性。标准的属性号定义见表1.2

表1.2 标准属性号定义

注：表5中，属性号79和80是RADIUS为支持EAP认证增加的两个属性：

EAP-Message

这个属性用来封装EAP数据包，属性号为79，如果EAP数据包长度大于253字节，可以对其进行分片，依次封装在多个EAP-Message属性中。

Message-Authenticator

属性号为80，主要用于在EAP认证过程中验证携带了EAP-Message属性的Radius报文的完整性，避免接入请求包被窜改。在含有EAP-Message属性的数据包中，必须同时也包含Message-Authenticator，否则该数据包会被认为无效而被丢弃。此外,若接收端对接收到的Radius报文计算出的完整性校验值与报文中携带的Message-Authenticator属性的Value值不一致，该数据包也会被认为无效而丢弃。

Length：表示整条属性域的长度，最小值为3
Value：记录了这条属性的具体特性，有6中属性值：整数(INT)；枚举(ENUM)；IP地址(IPADDR)；文本(STRING)；日期(DATE)；二进制字符串（BINARY)。

1.2.4 RADIUS网络安全

RADIUS协议的加密是使用MD5加密算法进行的，在RADIUS的客户端（NAS）和服务器端（RADIUS Server）保存了一个密钥（key），RADIUS协议利用这个密钥使用MD5算法对RADIUS中的数据进行加密处理。密钥不会在网络上传送。

RADIUS的加密主要体现在以下两方面：

1.包加密

在RADIUS包中，有16字节的验证字（authenticator）用于对包进行签名，收到RADIUS包的一方要查看该签名的正确性。如果包的签名不正确，那么该包将被丢弃，对包进行签名时使用的也是MD5算法（利用密钥），没有密钥的人是不能构造出该签名的。

2. 口令加密

在认证用户时，用户的口令在NAS和RADIUS Server之间不会以明文方式传送，而是使用了MD5算法对口令进行加密。没有密钥的人是无法正确加密口令的，也无法正确地对加密过的口令进行解密。

3. 口令加密与口令验证过程

当用户上网时，NAS将决定对用户采用何种认证方法。可以使用RADIUS认证的情况下PPP用户与NAS之间的PAP和CHAP认证等方法，详见第2章。

2 拓展——PPP协议族

（参考：PPP协议 - 菜鸟也有高飞的时候 - 博客园）

2.1 PPP简介

点到点协议（Point to Point Protocol，PPP）包含以下两个层次的协议：

链路控制协议（LCP）：负责建立、配置和测试数据链路连接
网络控制协议（NCP）：负责建立和配置各种网络层协议（IP/IPX/AppleTalk)

PPP的连接过程大致如下：

为建立通信，PPP链路的每一端首先都必须发送LCP包，以配置数据链路。
在链路建立后，PPP链路的两端还必须发送NCP包，以选择和配置一个或多个网络层协议。
在网络层协议配置完成之后，网络层的流量就可以传输了。
链路继续保持配置好的通信状态，直至有显示的LCP或NCP包关闭该链路为止。

运行在PPP之上的每一种三层协议都有一个开放的NCP，比如说，对IP来说，为了在PPP链路上传输IP，就必须建立IPCP（IP控制协议）

PPP提供全双工操作，并按照顺序传递数据包。设计目的主要是用来通过拨号或专线方式建立点对点连接发送数据，使其成为各种主机、网桥和路由器之间简单连接的一种共通的解决方案。

图 2.1 PPP的应用

PPP具有以下功能：

PPP具有动态分配IP地址的能力，允许在连接时刻协商IP地址；
PPP支持多种网络协议，比如TCP/IP、NetBEUI、NWLINK等；
PPP具有错误检测能力，但不具备纠错能力，所以ppp是不可靠传输协议；
无重传的机制，网络开销小，速度快。
PPP具有身份验证功能。
PPP可以用于多种类型的物理介质上，包括串口线、电话线、移动电话和光纤（例如SDH），PPP也用于Internet接入。

图2.2 PPP协议的层次模型

PPP协议包括三个部分：

一个将IP数据报封到串行链路的方法。PPP既支持异步链路（无奇偶校验的8比特数据），也支持面向比特的同步链路。PPP帧格式如图 2.3：
一套网络控制协议NCP（Network Control Protocol），支持不同的网络层协议，如IP、OSI的网络层、DECnet、AppleTalk等。
一个用来建立、配置和测试数据链路的链路控制协议LCP（Link Control Protocol）。通信的双方可协商一些选项。在[RFC 1661]中定义了11种类型的LCP分组。

图2.3 PPP帧格式

标志字段F=0x7E（01111110），定界符

如果0x7E出现在帧内部的话，需要出现问题，所以有两种解决方案：
- 在异步链路上使用字符填充，即把0x7E用0x7D5E替换
- 在同步链路上使用位填充，即在连续的5个1之后填充一个0
地址字段A：用于指定那个站正在处理，但是PPP只关心一个站，所以设置了0xFF（所有站）
控制字段C：用于帧序列和重传行为，PPP中没有用，设为固定值0x03
协议（指示在信息字段中封装的数据类型）：
- 0x0021时，数据部分是IP数据报。
- 0xC021时,数据部分是LCP数据（链路控制协议）。
- 0x8021时，数据部分是NCP（网络控制协议）数据。
- 0xC023 时，数据部分是PAP数据。
- 0xC025时： LCP中链路质量报告LQR
- 0xC223 时，数据部分是CHAP数据

数据部分最大长度不能超过1500字节，1500字节大小等于PPP协议中配置参数选项MRU
FCS（校验）: 用于差错检测的冗余循环校验码

2.2 认证方式

2.2.1 PPP会话建立过程

图2.4 PPP会话建立过程

PPP会话建立过程包括三步，如图2.4：链路的建立和配置协调阶段，如图2.5：

图2.5 PPP链路的建立和配置协调阶段

可选的验证阶段，如PAP或者CHAP等，详见2.2.2、2.2.3
网络层协议配置协商阶段。

2.2.2 PAP认证过程

PAP（ Password Authentication Protocol，密码认证协议）是PPP协议集中的一种链路控制协议，主要是通过使用两次握手提供一种对等结点的建立认证的简单方法，这是建立在初始链路确定的基础上的。完成链路建立阶段之后，对等结点持续重复发送 ID/ 密码给验证者，直至认证得到响应或连接终止。

两次握手流程如图2.6：

图2.6 PAP两次握手

被认证方发送明文给认证方，包括用户名、密码等信息；
认证方认证，回送接受/拒绝数据包。

PAP包结构如图2.7：

图2.7 PAP包结构

由于PAP使用明文发送，因此不具有密码学上的安全性。

2.2.3 CHAP

CHAP（Challenge Handshake Authentication Protocol，挑战握手认证协议），通过三次握手周期性的校验对端的身份，在初始链路建立时完成，可以在链路建立之后的任何时候重复进行。

三次握手流程如图2.8：

图2.8 CHAP三次握手流程

挑战（Challenge）：认证方发送给被认证方，要求被认证方提供认证信息；
应答（Response）：被认证方发送给认证方，数据包含有三个参数：ID、random、MD5值。其中分别为：
- ID：创建多组用户名时每个用户都有对应的唯一ID；
- random：被认证方产生的随机数；
- key：认证方与被认证方事先预共享的密钥；
- MD5值即由上面三个参数经过单向散列函数计算后得出。

注意，传输的数据包中不包含key，MD5中却包含了key的信息。因此，避免了key在传输中出现，阻断了被窃取key的风险。

接受（Ack）/拒绝（Nak）：认证方回送给被认证方。认证方接收到应答之后，取出其中random、ID，结合本机中预存的key，计算出MD5与应答包中的MD5对比，若对比成功则认证成功，回复Ack；否则回复Nak。

至此，CHAP认证结束，保障了认证的安全性。

3 EAPoL&EAP

3.1 EAPoL报文格式

EAPOL（EAP over LANs）是802.1X协议定义的一种报文封装格式，主要用于在客户端和NAS之间承载用户信息，也就是说允许EAP协议报文直接承载于LAN环境中。后来被802.11i借鉴，因此也可用于WLAN中。

EAPoL消息封装格式如图3.1：

图3.1 EAPoL封装格式

PAE Ethernet Type（以太网类型）：2字节，该值表示以太网协议类型，802.1X为其分配的协议类型为0x888E。
Protocol Version：1字节，表示EAPoL帧的发送方所使用的协议版本号。图3.2为目前存在的版本号：

图3.2 EAPoL版本号

Packet Type：1字节，表示EAPOL数据帧类型，有如下四种帧类型，如图3.3所示。

图3.3 Packet Type

Packet Body Length：2字节，表示数据域的长度，也就是Packet Body字段的长度，单位为字节。当EAPOL数据帧的类型为EAPOL-Start或EAPOL-Logoff时，该字段值为0，表示后面没有Packet Body字段。
Packet Body：表示数据内容，根据不同的Type有不同的格式，长度由Packet Body Length决定。

3.2 EAP报文格式

802.1X协议采用EAP（Extensible Authentication Protocol，可扩展认证协议）来实现客户端、NAS和认证服务器之间认证信息的交互。

EAP属于一种框架协议，最初规范于RFC2284，后来经RFC3748更新。EAP是一种简单的封装方式，可以运行于任何的链路层，大都应用于802.3/802.11，在PPP链路上并未广泛使用。

通过支持EAP协议，NAS只需控制其受控端口的状态，但是并不干涉通过非受控端口在客户端和认证服务器之间传递的认证信息。这样，就实现了认证流和业务流的完全分离。可以使用认证服务器来实现各种认证机制，NAS仅仅需要传送认证信息，并根据认证返回的结果控制受控端口的状态。

当 EAPOL 报文的Packet Type字段值为0000 0000时，表明Packet Body字段封装的是一个EAP 数据包，EAP 协议报文格式在 RFC2284 中有详细描述。下面来看一下EAP报文封装格式，如图3.4所示。

图3.4 EAP的帧结构

Code：1字节，该值表示EAP帧类型，共有4种：Request、Response、Success、Failure。
Identifier：1字节，该值用于匹配Request消息和Response消息。Identifier字段和系统端口一起唯一标识一个认证过程。
Length：2字节，该值表示EAP帧的总长度，包含Code、Identifier、Length和Data域，单位为字节。
Data：0或更多字节，表示EAP包的内容，由Code字段决定。

对于Code字段所携带的不同EAP帧类型，其对应Data域的格式也略有不同，这里可分为两类：

一类是指，若Code字段的EAP帧类型为Request或Response的数据包的Data域格式如图3.5所示。

图3.5 Type报文类型

此时，Type报文类型见图3.6，其中前三种为特殊含义，其余的值表示EAP支持的认证方式：

图3.6 EAP支持的认证方式

- - 另外一类，若Code类型为标准的Success或Failure的数据包，则没有Data域，相应的Length域的值为4。

此外，Radius为支持EAP认证增加了两个属性：EAP-Message（EAP消息）和Message-Authenticator（消息认证码）。

如图3.7所示，EAP-Message属性用来封装EAP数据包，类型代码为79，Value域最长253字节，如果EAP数据包长度大于253字节，可以对其进行分片，依次封装在多个EAP-Message属性中。该属性必须配合Message-Authenticator属性使用。

图3.7 EAP-Message属性

而上面提到的Message-Authenticator属性，如图3.8所示，类型代码为80，主要用于在EAP认证过程中验证携带了EAP-Message属性的Radius报文的完整性，避免接入请求包被窜改。在含有EAP-Message属性的数据包中，必须同时也包含Message-Authenticator，否则该数据包会被认为无效而被丢弃。此外，若接收端对接收到的Radius报文计算出的完整性校验值与报文中携带的Message-Authenticator属性的Value值不一致，该数据包也会被认为无效而丢弃。

图3.8 Message-Authenticator属性

4 802.1X认证

4.1 认证发起

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

NAS主动触发认证方式

当NAS检测到有未经认证的用户使用网络时，会每隔N秒（系统默认30秒）主动向客户端以组播报文来触发认证。在认证开始之前，端口的状态被强制为未认证状态。

如果客户端的身份标识不可知，则NAS会发送EAP-Request/Identity报文，请求客户端发送身份标识。这样，就开始了典型的认证过程。客户端在收到来自NAS的EAP-Request报文后，将发送EAP-Response报文响应NAS的请求。

这种触发方式用于支持不能主动发送EAPOL-Start报文的客户端，例如Windows XP自带的802.1X客户端。

客户端主动触发认证方式

如果用户要上网，则可以通过客户端软件主动发起认证。客户端软件会向NAS发送EAPOL-Start报文主动发起认证。该报文目的地址为IEEE 802.1X协议分配的一个组播MAC地址：01-80-C2-00-00-03。

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

此外，由于网络中有些设备不支持上述的组播报文，使得NAS无法收到客户端的认证请求，因此NAS还支持广播触发方式，即可以接收客户端发送的目的地址为广播MAC地址的EAPOL-Start报文。

4.2 认证退出

通过以下几种方式NAS设备可以将端口状态从已认证状态改变成未认证状态：

与端口对应的MAC地址出现故障（管理性禁止或硬件故障）；
客户端发送EAPOL-Logoff报文，主动下线。
客户端未响应NAS发起的认证请求；
客户端与NAS之间的连接失败，造成认证超时；

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

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

当一个用户从一台终端登录后，很可能其他用户不通过发起一个新的认证请求，就可以利用该设备访问网络。因此提供专门的退出机制，以确保用户与NAS专有的会话进程被中止，可以防止用户的访问权限被他人盗用。通过发送EAPOL-Logoff报文，可以使NAS将对应的端口状态改变为未认证状态。

4.3 认证过程

当用户通过认证后，认证服务器会把用户的相关信息传递给NAS，而NAS会根据认证服务器的指示，如Accept或Reject，来决定受控端口的授权/非授权状态。

当前802.1X系统支持两种方式与远端认证服务器交互完成认证，即EAP中继方式和EAP终结方式。

4.3.1 EAP中继方式

EAP中继方式是IEEE 802.1X标准规定的，其将EAP承载在其它高层协议中，如EAPOR(EAP over Radius)，以便EAP报文穿越复杂的网络到达认证服务器。一般来说，EAP中继方式需要Radius服务器支持EAP属性：EAP-Message（值为79）和Message-Authenticator（值为80），以上两个属性分别用来封装EAP报文及对携带EAP-Message的Radius报文进行保护。

在具有802.1X认证功能的以太网络系统中，当一个用户需要对网络资源进行访问之前必须先要完成以下的认证过程。下面就以EAP-MD5方式为例，介绍802.1X基本认证流程，如图4.1所示。其中EAP-MD5是一种单向认证机制，可以完成网络对用户的认证，但认证过程不支持加密密钥的生成。

图4.1 IEEE 802.1X认证系统的EAP中继方式交互流程

注：图中左侧的“EAP”帧都是封装在EAPoL中的，此时EAPoL中的“Packet Type”值为0x00。

当用户有网络连接需求时打开802.1X客户端程序，输入已经申请、登记过的用户名和密码，发起连接请求（EAPOL-Start报文）。此时，客户端程序将发出请求认证的报文给NAS，开始启动一次认证过程。
NAS收到请求认证的数据帧后，将发出一个请求帧（EAP-Request/Identity报文）要求用户的客户端程序发送输入的用户名。
客户端程序响应NAS发出的请求，将用户名信息通过数据帧（EAP-Response/Identity报文）发送给NAS。
而后，NAS则将客户端送上来的数据帧经过封包处理后（RADIUS Access-Request报文）送给认证服务器进行处理。
认证服务器收到NAS转发上来的用户名信息后，将该信息与数据库中的用户名表相比对，找到该用户名对应的密码信息，用随机生成的一个加密字对它进行加密处理，同时也将此加密字通过RADIUS Access-Challenge报文传送给NAS，由NAS传给客户端程序。
客户端程序收到由NAS传来的加密字（EAP-Request/MD5 Challenge报文）后，用该加密字对口令部分进行加密处理（此种加密算法通常是不可逆的），生成EAP-Response/MD5 Challenge报文，并通过NAS封装为RADIUS Access-Request报文传给认证服务器。
认证服务器将收到的已加密的密码信息（RADIUS Access-Request报文）和本地经过加密运算后的密码信息进行对比，如果相同，则认为该用户为合法用户，反馈认证通过的消息（RADIUS Access-Accept报文和EAP-Success报文），并向NAS发出打开端口的指令，允许用户的业务流通过端口访问网络。否则，反馈认证失败的消息（EAP-Failure报文），并保持NAS端口的关闭状态，只允许认证信息数据通过而不允许业务数据通过。
客户端也可以发送EAPOL-Logoff报文给NAS，主动要求下线。设备端把端口状态从授权状态改变成未授权状态，并向客户端发送EAP-Failure报文。

这里要提出的一个值得注意的地方：在客户端与认证服务器交换口令信息的时候，没有将口令以明文直接送到网络上进行传输，而是对口令信息进行了不可逆的加密算法处理，使在网络上传输的敏感信息有了更高的安全保障，杜绝了由于下级接入设备所具有的广播特性而导致敏感信息泄漏的问题。

4.3.2 EAP终结方式

EAP终结方式将EAP报文在设备端（即客户端和NAS）终结并映射到Radius报文中，通过标准的Radius协议完成认证、授权和计费。设备端与Radius服务器之间可以采用PAP（Password Authentication Protocol，密码验证协议）或者CHAP（Challenge Handshake Authentication Protocol，质询握手验证协议）认证方法。二者主要区别是CHAP密码通过密文方式在客户端和NAS之间传输，而PAP密码通过明文的方式传输。以下以CHAP认证方式为例介绍认证流程，如图4.2所示。

图4.2 IEEE 802.1X认证系统的EAP终结方式交互流程

用户有上网需求时打开802.1x客户端，输入已经登记过的用户名和密码，发起连接请求（EAPOL-Start报文）。此时，客户端程序将发出请求认证的报文给NAS，开始启动一次认证过程。
NAS收到请求认证的数据帧（EAPOL-Start）后，将发出一个请求帧（EAP-Request/Identity报文）要求用户的客户端程序发送输入的用户名。
客户端程序将用户名信息通过数据帧（EAP-Response/Identity报文）送给NAS。直到这里，认证过程中的前三步和EVP中继方式完全相同。
接下来， NAS收到客户端送上来的数据帧（EAP-Response/Identity报文）后，没有上传至认证服务器，而是本地随机生成一个加密字，并将将此加密字的通过数据帧（EAP-Request/MD5 Challenge报文）交给客户端程序。
客户端程序收到加密字（EAP-Request/MD5 Challenge报文）后，用该加密字对密码部分进行加密处理，生成EAP-Response/MD5 Challenge报文发送给NAS。
NAS收到加密密码（EAP-Response/MD5 Challenge）后，用CHAP协议对用户名、加密密码、加密字等认证信息重新封装成标准的Radius报文（RADIUS Access-Requeset报文），送给认证服务器进行处理。
认证服务器收到的认证信息（RADIUS Access-Requeset报文）后，根据收到的用户名信息在数据库中查找对应的密码信息，用收到的加密字对密码信息进行加密处理得到自己的加密密码。然后和收到的加密密码信息进行对比，如果相同，则认为该用户为合法用户，反馈认证通过的消息（RADIUS Access-Accept报文）给NAS。
NAS向客户端程序反馈认证通过消息（ EAP-Success报文），将端口状态改为授权状态，允许用户通过该端口访问网络。
客户端可以发送EAPOL-Logoff报文给NAS，主动终止已认证状态，交换机将端口状态从授权状态改变成未授权状态。

4.3.3 两种方式对比

EAP中继方式与EAP终结方式的认证流程十分类似，不同之处主要在于加密字的生成处理及传递方式。在EAP中继方式中，用来对用户口令信息进行加密处理的随机加密字由认证服务器生成，NAS只是负责将EAP报文透传认证服务器，整个认证处理都由认证服务器来完成。而在EAP终结方式中，用来对用户密码信息进行加密处理的随机加密字由NAS生成，NAS会把用户名、随机加密字和客户端加密后的密码信息一起送给认证服务器，进行相关的认证处理。

从上面可以看出，由于认证流程中对于加密字的生成处理及传递方式不同，因此EAP中继与EAP终结两种认证方式其优缺点也很明显：

EAP中继方式优点是NAS设备处理更简单，支持更多的认证方式，缺点则是认证服务器必须支持EAP；
而EAP终结方式的优点是认证服务器无需升级，现有的Radius服务器可以继续使用，缺点是NAS设备处理更复杂。

两种方式各有优缺点，企业可根据实际情况自行选择。若为了兼容Radius服务器，节省用户投资，建议NAS选择EAP终结方式。

5 EAP认证方式（EAP Method）

（参考：EAP-PEAP&EAP-TLS认证具体流程分析）

5.1 EAP Method简介

图5.1 EAP-Method及配置方式

上图EAP认证配置表，我们常用，但不是每个人都清楚这些参数的含义，将在下文中进行阐述。

EAP认证过程中，会把证明使用者身份的过程，授权给一个成EAP Method的附属协议，该协议是一组验证使用者身份的规则。

使用EAP Method的优点是，EAP从此可以不用去管验证使用者的细节。当新的需求出现，就可以设计出新的认证方式，就算要用于WLAN也不成问题。事实上，EAP Method最初就是为LAN而设计的，后来802.11i制定了802.1X框架，而802.1X框架采用EAP作为身份验证协议，便出现了更多的EAP Method。

当前常用的EAP认证方法以及认证框架如图5.2 ：

图5.2 常用的EAP认证方法

根据所需的信息分类，EAP Method可以分为四类：

基于用户名/密码：LEAP（Light EAP，轻量级EAP），PSK（预共享密钥）。特点是只需要用户名和密码，不需要证书；优点是结构接单，缺点是无法验证认证服务器的合法身份（注意，是密码学上的合法，不代表无法验证通过）。
基于证书：TLS（Transport Layer Security，传输层安全）。特点是只需要证书，不需要其他信息；优点是可以通过数字证书对服务器和客户端进行双向验证，缺点是配置复杂，部署成本高，对处理器要求较高。TLS是EAP Method中安全性最高的方式。
基于证书+用户名/密码：可视为TLS的扩展，包括PEAP（Protecten EAP,受保护的EAP）、TTLS（Tunneled TLS）等；特点是不仅使用TLS认证（其中一部分）建立了隧道，还需要验证身份和密码，增强了安全性。优点是一定程度上简化了TLS的配置，缺点是不对双方采用数字证书进行验证，无法防范中间人攻击。

需要注意的是，FAST（Flexible Authentication via Secure Tunneling）不必使用数字证书，可以通过受保护的访问凭证（PAC）方式创建加密的TLS隧道。TLS隧道依赖于PAC，PAC由证书服务器动态配置并管理。

基于SIM卡认证：包括SIM和AKA，SIM卡内置证书，不必额外输入信息。

此外，最初的EAP Method采用MD5-Challenge方式进行认证，如今已被弃用，原因是存在固有漏洞，如MD5散列函数安全性较差，已被证明可以通过离线词典进行攻击。

本文选取具有代表性的两种EAP Method进行详细介绍，TLS和PEAP。

5.2 TLS&EAP-TLS

5.2.1 TLS

在SSL/TLS出现之前，很多应用层协议（http、ftp、smtp等）都存在着网络安全问题，例如大家所熟知的http协议，在传输过程中使用的是明文信息，传输报文一旦被截获便会泄露传输内容；传输过程中报文如果被篡改，无法轻易发现；无法保证消息交换的对端身份的可靠性。为了解决此类问题，人们在应用层和传输层之间加入了SSL/TLS协议。

后来SSL（Secure Socket Layer，安全套接字层）不断被发现漏洞，渐渐被更安全的TLS取代。TLS的目的就是在不可信赖的网络中建立一条可信赖的通信管道（Channel）。TLS通过证书交换来相互认证，客户端和服务器端必须提供由可信赖证书发行机构（CA）颁发的证书。证书提供了可靠的双向认证，防止“欺骗（Rouge）接入点”，防止中间人攻击。

在802.1X-EAP-TLS中，此模式虽然可以进行双向认证，但需要强调的是，认证双方是STA和RADIUS服务器，始终无法对AP的合法身份进行认证。

TLS主要解决三个网络安全问题：

保密(message privacy)，保密通过加密encryption实现，所有信息都加密传输，第三方无法嗅探；
完整性(message integrity)，通过MAC校验机制，一旦被篡改，通信双方会立刻发现；
认证(mutual authentication)，双方认证，双方都可以配备证书，防止身份被冒充；

TLS分为认证协商和通信加密两个步骤，其中握手协议（Handshake Protocol）用于客户端和服务端进行协商，确定一组用于数据传输加密的密钥串；记录协议（Record Protocol）通过使用客户端和服务端协商后的密钥进行数据加密传输。

本文只关注认证过程，因此详细介绍TLS握手过程，其流程如图5.3：

图5.3 TLS握手协议

步骤 1. ClientHello – 客户端发送所支持的 SSL/TLS 最高协议版本号和所支持的加密算法集合及压缩方法集合等信息给服务器端。

步骤 2. ServerHello – 服务器端收到客户端信息后，选定双方都能够支持的 SSL/TLS 协议版本和加密方法及压缩方法，返回给客户端。

（可选）步骤 3. SendCertificate – 服务器端发送服务端证书给客户端。

（可选）步骤 4. RequestCertificate – 如果选择双向验证，服务器端向客户端请求客户端证书。

步骤 5. ServerHelloDone – 服务器端通知客户端初始协商结束。

（可选）步骤 6. ResponseCertificate – 如果选择双向验证，客户端向服务器端发送客户端证书。

步骤 7. ClientKeyExchange – 客户端使用服务器端的公钥，对客户端公钥和密钥种子进行加密，再发送给服务器端。

（可选）步骤 8. CertificateVerify – 如果选择双向验证，客户端用本地私钥生成数字签名，并发送给服务器端，让其通过收到的客户端公钥进行身份验证。

步骤 9. CreateSecretKey – 通讯双方基于密钥种子等信息生成通讯密钥。

步骤 10. ChangeCipherSpec – 客户端通知服务器端已将通讯方式切换到加密模式。

步骤 11. Finished – 客户端做好加密通讯的准备。

步骤 12. ChangeCipherSpec – 服务器端通知客户端已将通讯方式切换到加密模式。

步骤 13. Finished – 服务器做好加密通讯的准备。

步骤 14. Encrypted/DecryptedData – 双方使用客户端密钥，通过对称加密算法对通讯内容进行加密。

步骤 15. ClosedConnection – 通讯结束后，任何一方发出断开 SSL 连接的消息。

5.2.2 EAP-TLS

TLS握手协议与EAP相结合，可以进行EAP-TLS认证，流程如图5.4 ：

图5.4 EAP-TLS认证流程

注：TADIUS客户端和RADIUS服务器之间所有的帧，都是用RADIUS的格式把EAP包封装，使其可以在RADIUS客户端和服务器之间传输。

（1）用户向RADIUS客户端发起EAPoL-Start，开始802.1X接入。

（2）RADIUS客户端向用户发送EAP-Request/Identity，要求提供身份标识。

（3）/（4）用户回送RADIUS客户端EAP-Response/Identity，提供身份标识，RADIUS客户端将EAP-Response/Identity封装成RADIUS Access-Request帧发送给RADIUS服务器。

（5）/（6）RADIUS服务器通过用户身份标识检索数据库，获知采用TLS认证机制。通过向用户发送封装有EAP-Request/EAP-TLS/TLS-Start的Access-Challenge消息，启动TLS认证过程，等待进行TLS认证。

（7）/（8）用户收到EAP-Request/EAP-TLS/TLS-Start后，发送EAP-Request/EAP-TLS/Client-Hello消息，包含了自己可实现的算法列表、Client-Random-Value和其他一些需要的信息。

（9）/（10）服务器收到用户的Client-Hello后，确定TLS认证已建立，通过封装包含多个TLS记录的EAP-Response/EAP-TLS的Access-Challenge消息回送用户。TLS记录中包含服务器的证书Server-Cert、请求验证用户证书Client Cert-Request，以及Server-Hello（确定Server-Random-Value）和Server KeyExchange（用于交换密钥过程）。

（11）/（12）用户校验服务器的证书，若合法，回送由EAP-Response/EAP-TLS封装的Client-Cert（用户证书）、Client KeyExchange（使用服务器的公钥加密的定长随机串，也叫Pre Master Secert）,Change CipherSpec（用户支持的加密类型）和Finished消息。

（13）/（14）服务器校验申请者的证书，若合法，回复Change CipherSpec，包含服务器指定使用的加密类型，以及Finished。

（15）/（16）用户收到服务器的Finished，响应EAP-Response/EAP-TLS/TLS-ACK, Finished.

（17）RADIUS服务器和用户都推导出主密钥PMK。服务器收到TLS-ACK，回送Access-Accept，包括PMK并指示成功的认证。

（18）RADIUS客户端向用户发送EAP-Success，完成EAP-TLS认证。

至此，认证成功，用户和RADIUS服务器之间动态协商生成PMK，相当于PMK，用于四次握手生成会话密钥。每一个用户与AP之间通讯的加密密钥都不同，而且定期更新，保证了通讯的安全。

注：连接过程中需要输入“域名”，即图5.1中的“wi-fi.org”，此域名为Wi-Fi产业联盟的官方域名，如图5.5。输入域名的目的是为了验证证书的合法性。

图5.5 Wi-Fi产业联盟官网

5.3 PEAP

EAP-TLS是迄今为止安全性最高的EAP Method，然而TLS要求系统支持PKI（Public Key Infrastructure，公钥基础架构），这是TLS的缺点，PKI太庞大，太复杂了，如果企业中没有部署PKI系统，那么为了这个认证方法而部署PKI有些复杂。为了使配置简单，又满足安全性要求，PEAP（Protected EAP）被提出。

简单来说，PEAP分为两个阶段：

第一阶段，引入TLS握手协议建立TLS隧道，保护隧道中的信息不被攻击者窃取；
第二阶段，通过传统的身份认证方式对用户和服务器进行身份认证。
PEAP（Protected EAP）共有两个版本：
v0由Microsoft开发，第二阶段身份认证使用MS-CHAP，类似PPP中的CHAP；
v1由Cisco创建，第二阶段身份认证采用GTC方法，通过受保护的通道提供与现有令牌卡和基于目录的身份验证系统的互操作性。然而由于Microsoft从未提供对GTC的支持，因此使用较少。

本文以PEAPv0为例，介绍PEAP的认证流程，如图5.6 ：

图5.6 EAP-PEAPv0认证流程

大体分为如下阶段：

关联阶段，为802.11通用模式；
EAP-PEAP-Start
应用TLS握手协议建立TLS通道
应用MS-CHAP进行双向身份认证，协商PMK
四次握手进行密钥协商

其中需要注意的关键如下：

第3步中，遵循传统TLS握手协议，不必对用户证书进行验证；
第4步中，MS-CHAP有多个版本，现在常用v2版本，完整的MS-CHAP流程如图5.7：

图5.7 MS-CHAPv2流程

- 第（3）步EAP-Response/Identity中的Identity表示“网络标识”，即我们连接过程中输入的“身份”，此标识的格式为username@domain，其中username是运营商提供给用户的身份ID，domain是运营商的域名（如“cmcc.com”）。
- 第（7）步与第（9）步用于回应质询、验证质询所用的HMAC算法中的密码即为我们连接过程中的“密钥”（如图5.1中的“test%11”）

5.4 TLS与PEAP的差异对比

5.2与5.3分别介绍了TLS与PEAP两种EAP Method，前文中提到，TLS的安全强度是所有EAP Method中最高的。但了解了PEAP之后或许有人会有疑惑：PEAP相比TLS，不仅有TLS隧道，还“多”了第二阶段验证，难道不应该是“双重安全”，怎么还比TLS的安全强度低呢？

经过广泛的调研，我认为有如下几个原因：

原始TLS握手协议中，不要求对服务器的证书进行验证，因此服务器的合法身份无法保证。我们平时使用PEAP的场景中，为了简化流程大多数没有对用户证书进行验证，以我们实验室的连接流程来看即使如此。可以简单理解为，虽然EAP-PEAP使用了TLS隧道，但是其安全性不如EAP-TLS高。引用维基百科的解释：“客户端证书的要求，不管它可能不受欢迎，是赋予 EAP-TLS 其身份验证强度的原因，并说明了经典的便利性与安全性的权衡。使用客户端证书，泄露的密码不足以闯入启用 EAP-TLS 的系统，因为入侵者仍然需要拥有客户端证书；实际上，甚至不需要密码，因为它仅用于加密客户端证书以进行存储。可用的最高安全性是客户端证书的“私钥”存放在智能卡中。这是因为如果不窃取智能卡本身，就无法从智能卡中窃取客户端证书的相应私钥。与（典型的）密码盗窃相比，智能卡的物理盗窃更可能会被注意到（并且智能卡会立即被撤销）。此外，智能卡上的私钥通常使用只有智能卡所有者知道的 PIN 加密，即使在卡被报告被盗和撤销之前，它对小偷的效用也最小化。”
EAP-TLS的安全性保障在于系统内部的PKI结构，只要存在有效的PKI，所有参与方都默认无条件相信它。EAP-TLS连接过程中不需要输入密码，只靠证书的合法性产生PMK；而EAP-PEAP需要认证双方提前共享密钥，密钥配送本身就存在致命缺陷；而共享密钥一般较长时间才会更换（甚至不更换），这给攻击者提供了较长的时间进行攻击。
从易用性角度来讲，若是少量用户进行认证，EAP-TLS与EAP-PEAP感受不到多大差别；但若网络规模较大，接入用户多，PEAP密钥管理和配送的难度会加大。若密钥更改，所有的终端设备都需要重置；而证书由CA统一管理，认证过程便简化很多。

讲到这里，再回头看图5.1，只剩一个“在线证书验证状态”没有解释了。在我们的实验室环境中认证时，无论哪一种EAP Method，都选择“不验证”。事实上，这是不正确的。

诚然，选择“不验证”也可以认证成功，因为我们的设备有两种证书认证方式：

在线CA认证，即联网去CA网站进行认证；
默认方式认证，就是我们选择的“不认证”。这种模式下，设备默认用户所选择的证书是合法的。

由于证书是我们自己配置的，所以可以信任；然而若在公共环境中进行认证，最好还是选择“在线验证”，可以防范欺骗。

至此，关于802.1X的简介基本全面了。最后总结以下几点：

802.1X是一种网络访问控制机制，不是“加密方式”，要注意与WEP/WPA/WPA2/WPA3的区别。
802.1X是“基于端口的网络访问控制”，这是它的精髓所在。简单理解为，有两个端口，非受控端口时刻畅通，但是只允许特定的认证协议通过（如EAP）；受控端口只有在认证成功之后才能打开，而且可以选择双工或半双工。
802.1X“借用”EAP进行身份认证，EAP早于802.1X出现（EAP由RFC2284定义，1998年；802.1X由802.11i定义，2004年）。而为了使EAP协议可以在LAN/WLAN中传输，出现了EAPoL，这是由802.1X发展来的。
802.1X中的认证服务器大都使用RADIUS服务器（没查到用别的类型，但没有规定只能使用RADIUS），为了能让EAP数据包在RADIUS客户端和服务端传输，产生了EAPoR，这也是802.1X发展来的。
随着新需求的出现，EAP发展出许多商用EAP Method，这些方法大都是不同通信公司制定的，而非802.11标准规定。其中安全强度最高的是EAP-TLS，常用的Method还有PEAP、SIM等。