80211无线网络权威指南(六)之用户身份验证

• 可扩展身份验证协议EAP

802.1X的基础是EAP，它是一种简单的封装方式，可适用于任何链路层。有两种EAP：一种用于无线网络，另一种用于LAN连接，通常称为 EAP over LAN(EAPOL)。EAP的基本架构如下图所示，这样的设计就是为了能够运行在各种链路层中以及使用各种身份验证方式。

EAP的封包格式

在PPP（点对点）链路上使用时，是通过PPP帧来承载，协议编号为0xC227，两种EAP在结构上只有头部不一样，具体结构如图：

Code：代表EAP封包的类型，长度1字节，封包的Data必须通过该字段解析

Identifier：标识符，长度1个字节重传会使用相同identifier编号，新的传送使用新的编号

Length：记载封包总字节数，包括Code、Identifier、Length、Data四个字段，长度2个字节，

Data：最后一个是Data（数据）字段，其长度不定，取决于封包的类型，Data字段也可能不占用任何字节。Data字段如何解析完全取决于Code字段的值。

EAP的交换操作由request（请求）和response（响应）构成，在发出认证请求之后需要根据响应内容决定是否被允许访问，不容许发送多余的封包来请求身份认证，请求与响应封包的格式如下：

Code字段的值为1代表请求，2代表响应。Identifier 与Length字段的用法，如上文的基本格式所述。Data字段用来携带请求与响应所使用的数据。每个Data字段会携带一种数据，可再细分为type identifier code(类型标识符）以及associated data(关联数据):

Type(类型)：长度为1个字节，代表请求或响应类型。每个封包只能使用一种类型。唯一的例外是，响应的Type字段与其对应的请求一致。即当无法接受某个请求时，对方可以送出一个NAK来提议使用不同的类型。大于或等于4的Type字段值代表身份验证方式。

Type-Data(类型–数据)：字段长度不定，必须根据每种类型的规则加以诠释。

类型代码1—Identity（身份）：认证者通常会以该类型代码作为最初请求，一般以Request/Identity表示，表示认证者正在试图通过建立某种用户名称来进行身份验证。

类型代码2—Notification（通知）：认证者可以使用Notification(通知)类型传送消息给用户。用户的系统随后可将Request/Notification中的消息显示给用户看。Notification消息是由认证系统提供消息给例如密码即将过期或者账号被锁定的原因。Notification消息在802.1X中并不常用。Notification请求的回复中必须有送出的响应。不过，Request/Notification属于简单的确认(acknowledgment)，而Type-Data字段的长度为0。

类型代码3—NAK（否定确认）：null acknowledgment(否定确认，简称NAK)主要用来建议使用新的身份验证方式。认证者会在送出的质询(challenge)消息中指定身份验证所使用的类型代码(type code)。身份验证类型的代码为4及以上的数字。如果用户的系统不支持质询所使用的身份验证类型，可以回复NAK。

二、常用EAP认证方式的类型（EAP method）

EAP method认证方式的选择取决于客户端所使用的的身份认证系统，在认证者（Authenticator）和客户端（Supplicant）之间，二者需要商定好使用的验证方式，下图就是常用的几种EAP认证方式：

类型代码	身份验证协议名称	特点
4	MD5-Challenge	类似三次握手的验证方式
6	GTC	原本打算与RSA SecureID之类的令牌卡一起使用
13	EAP-TLS	以数字证书（digital certificate）相互认证
21	TTLS	隧道式TLS，以TLS加密保护较弱的身份验证方式
25	PEAP	防护型EAP，以TLS加密保护较弱的EAP验证方式
18	EAP-SIM	以移动电话的SIM卡进行身份验证
29	MS-CHAP-V2	MicroSoft的经加密的密码身份验证，兼容Windows系统

在选择好认证方式之后，双方开始交换信息，大致流程如图：

1、认证者（authenticator）发出一个Request/Identity(请求/身份证明）封包以识别用户身份。Request/Identity封包有两个目的，除了启动交换过程外，也用来告诉客户端在身份验证完成之前网络将会丢弃任何传输数据。

2、客户端要求用户输入标识符，随后将所搜集到的用户标识符以Response/Identify

(响应/身份证明)消息送出。

3、一旦认出该用户，认证者随即会送出认证质询。在图6-5的第三个步骤中，认证者以一个Request/MD-5 Challenge（请求/MD-5质询)封包送出MD-5 Challenge(MD-5质询）给用户。

4、客户端在设定上是以token card (令牌卡）进行身份验证，因此它会送出一个Response/NAK（响应/否定确认）消息，提议以Generic Token Card （一般令牌卡）作为认证机制。

5、认证者会送出一个Request/Generic Token Card(请求/一般令牌卡)的质询，要求取得卡号( numerical sequence on the card)。

6、用户输入卡号，通过Response/Generic Token Card（响应l一般令牌卡）送回

7、用户的响应并不正确，因此认证失败。不过，这个认证者在EAP的实现中允许多次认证，因此会送出第二个Request/Generic Token Card（请求/-般令牌卡）的质询。

8、用户再度响应，依然通过Response/Generic Token Card（响应/一般令牌卡)传递。9.此次的响应正确，因此认证者发出一个 Success（成功）消息。

在交换过后，要么认证成功，要么认证失败，一旦认证者判断出整个交换过程已经完成，就会发出一个EAP-Success帧或EAP-Failure帧，以结束整个EAP交换过程。实现时，在送出认证失败信息之前，允许用户送出多个请求信息，好让用户有机会获得正确的认证数据。成功和失败的帧结构如下：

三、802.11X用户身份验证

802.1X为认证会话过程定义了三个组件，如下图所示。申请者（supplicant)是寻求访问网络资源的用户机器。网络访问由认证者（authenticator）控制，它扮演着传统拨号网络中访问服务器的角色。申请者与认证者在规范说明书中称为端口认证实体(Port Authentication Entity，简称PAE)。认证者只负责链路层的认证交换过程，并不维护任何用户信息。任何认证请求均会被转送至认证服务器（例如RADIUS）进行实际的处理。

           

支持802.1X的设备上，各个连接端口若非处于授权状态（即可以使用该连接端口)，就是处于未授权状态（即无法使用该连接端口）。不过即使处于未授权状态，如果网络管理人员允许的话，规范说明书中还是允许使用DHCP以及其他初始化信息。

整个认证交换过程在逻辑上是通过申请者与认证服务器来完成的,认证者只是扮演中介的角色。图 b所示为逻辑上的协议结构。申请者与认证者之间(即前端)使用由802.X所定义的EAPover LAN（简称EAPOL）协议，在后端则是通过RADIUS封包来传递EAP。有些文献称之为“EAP over RADIUS”。就算连接端口尚未得到授权，也尚未取得IP地址，申请者还是能够持续与RADIUS服务器进行EAP交换。

802.1X的帧过滤

802.1X利用允许任何数据通过之前必须先经过认证，来防范网络被未经授权的用户访问。处于未授权状态的连接端口通常限定只能传送认证帧，其他数据都会被丢弃。一旦工作站成功验证，就可以将数据帧送至适当的网络。

EAPOL的封装格式

EAPOL的基本帧格式如下图：

MAC标头：Ethernet和802.11所使用的MAC标头是不一样的

Packet Type（封包类型）：EAPOL是EAP的扩展

Packet Body Length（封包主体长度）：长度2个字节，用来计算Packet Body的长度，如果没有封包内容，则记为0

Packet Body（封包主体）：字段长度不定。除EAPOL-Start和EAPOL-Logoff消息外，此字段会出现在所有的EAPOL帧中

EAPOL的消息类型

封包类型	消息名称	消息特点
0000 0000	EAP-Packet	包含了一个经过封装的EAP帧，大部分的帧均属于EAP-Packet
0000 0001	EAPOL-Start	申请者可以主动发出EAPOL-Start，不必等候认证者的质询信息，Authenticator会发送出一个EAP-Request/Identity帧作为响应
0000 0010	EAPOL-Logoff	当某个系统不再需要网络时，便可发出该消息，让连接端口重新回到未授权的位置
0000 0011	EAPOL-Key	EAPOL可用来交换加密秘钥信息
0000 0100	EAPOL-Encapsulate-ASF-Alert	警告标准讨论，可让警告信息通过该类型的消息传给未经授权的连接端口

下图表示在802.11网络中802.1X的实际交换范例：

            

1、申请者关联至802.11网络。关联只用到两个帧，这种简单的交换过程几乎都会成功。

2、申请者发出一个EAPOL-Start消息，开始进行802.1X交换过程。这个步骤并非必要，并非所有申请者都会送出EAPOL-Start消息，因此可能没有这个步骤。

3、“正式的”EAP交换过程开始。认证者（接入点）发出一个EAP-Request/Identity帧。如果接入点只为已经认证成功的关联转送帧，在发送Request/Identity帧之前可能就没有EAPOL-Start。主动发出的 Request/Identity帧用来指示申请者必须进行802.1X认证。

4、申请者以EAP-Response/Identity帧进行回复，此帧随后被转换为Radius-Access-Request封包送给RADIUS服务器。

5、RADIUS服务器判断需要使用哪种认证类型﹐并且在送出的EAP-Request信息中指定认证方式的类型。EAP-Request被封装于Radius-Access-Challenge封包中送给接入点。接入点收到封包后即将EAP-Request传递给申请者。EAP-Request信息通常会被表示为EAP-Request/Method，其中的“Method”代表所使用的EAP认证方式。如果目前使用的是PEAP，则返回的封包将以EAP-Request/PEAP来表示。

6、申请者从用户方面取得响应，然后返回EAP-Response。认证者会将此响应转换为送给RADIUS的Radius-Access-Request封包，针对质询信息所作的响应则存放于数据字段中。第5步和第6步可能会重复很多次，如果采用交换EAP证书的方式更是不可避免多次重复。

7、既然RADIUS服务器送出一个Radius-Access-Accept封包允许对方访问网络，因

此认证者会发出一个EAP-Success帧并且授权使用连接端口。访问权限也可以由RADIUS服务器所返回的参数来决定。

8、收到Access-Accept封包后，接入点会立即使用EAPOL-Key消息将密钥分配给申请者。

9、一旦申请者安装好密钥，就可以开始传送数据帧来访问网络。DHCP配置设定通常会在此刻进行。

10.、当申请者不再需要访问网络，就会送出一个EAPOL-Logoff消息，使连接端口恢复成未授权状态。