x编程之协议解析.doc

x编程之协议解析.doc

《x编程之协议解析.doc》由会员分享，可在线阅读，更多相关《x编程之协议解析.doc（5页珍藏版）》请在冰点文库上搜索。

有不少人问吵吵802.1x的客户端要怎么才能写，我想要想完成这个工作先得把802.1x编程技术中的协议给弄清楚吧。

就像要完成一些网页应用的话，至少要明白http协议吧，虽然，http协议很简单，事实上802.1x协议也不难，但是如果在这之上部分公司进行扩充了话，就另当别论了。

但是掌握了基本协议，再分析扩充的应该容易多了。

这里用到的sniffer其实并不好用，吵吵推荐大家抓包用etheral的解决方案，linux下还有wireshark，这些都能帮助你分析协议的，开源的软件就是哈用多了。

这是以前在csdn下载的协议分析：

缩略语

802.1x本文指IEEE802.1x标准

RADIUS远程用户拨入认证服务（RemoteAuthenticationDialInUserService）

PAP密码验证协议（PasswordAuthenticationProtocol）

CHAP质询握手验证协议（ChallengeHandshakeAuthenticationProtocol）

EAP扩展验证协议（ExtensibleAuthenticationProtocol）

EAPOL基于局域网的EAP（EAPoverLAN）

MD5消息摘要算法5版本（Message-DigestAlgorithm5）

PAE端口认证实体（PortAuthenticationEntity）

一802.1x认证起源

802.1x协议起源于802.11协议，后者是标准的无线局域网协议，802.1x协议的主要目

的是为了解决无线局域网用户的接入认证问题。

现在已经开始被应用于一般的有线LAN的

接入（微软的WindowsXP，以及Cisco，华为3com，北电，港湾等厂商的设备已经开始支

持802.1x协议）。

在802.1x出现之前，企业网上有线LAN应用都没有直接控制到端口的方法。

也不需要

控制到端口。

但是随着无线LAN的应用以及LAN接入在电信网上大规模开展，有必要对

端口加以控制，以实现用户级的接入控制。

802.1x就是IEEE为了解决基于端口的接入控制

（Port-BasedAccessControl）而定义的一个标准。

二802.1x认证的作用

802.1x首先是一个认证协议，是一种对用户进行认证的方法和策略。

802.1x是基于端口的认证策略（这里的端口可以是一个实实在在的物理端口也可以是

一个就像VLAN一样的逻辑端口，对于无线局域网来说这个“端口”就是一条信道）

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

对于一个端口，如果认证成功

那么就“打开”这个端口，允许所有的报文通过；如果认证不成功就使这个端口保持“关闭”，

此时只允许802.1x的认证报文EAPOL（ExtensibleAuthenticationProtocoloverLAN）通过。

三802.1x认证体系的结构

图1客户端、认证系统、认证服务器所担任的角色802.1x的认证体系分为三部分结构：

（1）SupplicantSystem，客户端（PC/网络设备）

（2）AuthenticatorSystem，认证系统

（3）AuthenticationServerSystem，认证服务器系统

SupplicantSystem，客户端（PC/网络设备）

SupplicantSystem——Client（客户端）是一个需要接入LAN及享受switch提供服务的设

备（如PC机），客户端需要支持EAPOL协议，客户端必须运行802.1x客户端软件，如：

802.1x-complain，MicrosoftWindowsXP，H3C802.1x。

AuthenticatorSystem，认证系统

AuthenticatorSystem——Switch（边缘交换机或无线接入设备）是—根据客户的认证状态

控制物理接入的设备，switch在客户和认证服务器间充当代理角色（proxy）。

switch与client

间通过EAPOL协议进行通讯，switch与认证服务器间通过EAPoRadius或EAP承载在其他

高层协议上，以便穿越复杂的网络到达AuthenticationServer（EAPRelay）；switch要求客

户端提供identity，接收到后将EAP报文承载在Radius格式的报文中，再发送到认证服务器，

返回等同；switch根据认证结果控制端口是否可用；

需要指出的是：

我们的802.1x协议在设备内终结并转换成标准的RADIUS协议报文，加密

算法采用PPP的CHAP认证算法，所有支持PPPCHAP认证算法的认证计费服务器都可以

与我们对接成功。

AuthenticationSeverSystem，认证服务器系统

Authenticationserver——（认证服务器）对客户进行实际认证，认证服务器核实客户的

identity，通知swtich是否允许客户端访问LAN和交换机提供的服务。

AuthenticationSever接

受Authenticator传递过来的认证需求，认证完成后将认证结果下发给Authenticator，完成

对端口的管理。

由于EAP协议较为灵活，除了IEEE802.1x定义的端口状态外，

AuthenticationServer实际上也可以用于认证和下发更多用户相关的信息，如VLAN、QOS、

加密认证密钥、DHCP响应等。

四802.1x的认证过程

802.1x的认证中，端口的状态决定了客户端是否能接入网络，在启用802.1x认证时端

口初始状态一般为非授权（unauthorized），在该状态下，除802.1x报文和广播报文外不允

许任何业务输入、输出通讯。

当客户通过认证后，则端口状态切换到授权状态（authorized），

允许客户端通过端口进行正常通讯。

基于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所示。

基于EAP-MD5的802.1x认证流程如图3所示，认证

流程包括以下步骤：

图2基于EAP-MD5的802.1x认证系统功能实体协议栈

（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-Password，在EAP-Response/MD5-Challenge回应给接入设备；

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

RADIUS服务器进行认证；

（9）RADIUS服务器根据用户信息，做MD5算法，判断用户是否合法，然后回应认证成

功／失败报文到接入设备。

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

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

（10）如果认证通过，用户通过标准的DHCP协议（可以是DHCPRelay），通过接入设备获

取规划的IP地址；

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

用户上线完毕。

认证通过之后的保持：

认证端Authenticator可以定时要求Client重新认证，时间可设。

重新认证的过程对User是透明的（应该是User不需要重新输入密码）。

下线方式：

物理端口Down；重新认证不通过或者超时；客户端发起EAP_Logoff帧；

网管控制导致下线；

现在的设备（switch）端口有三种认证方式：

（1）ForceAuthorized：

端口一直维持授权状态，switch的Authenticator不主动发起认证；

（2）ForceUnauthorized：

端口一直维持非授权状态，忽略所有客户端发起的认证请求；

（3）Auto：

激活802.1x，设置端口为非授权状态，同时通知设备管理模块要求进行端口

认证控制，使端口仅允许EAPOL报文收发，当发生UP事件或接收到EAPOL-start报文，

开始认证流程，请求客户端Identify，并中继客户和认证服务器间的报文。

认证通过后端口

切换到授权状态，在退出前可以进行重认证。

802.1x协议的认证端口

受控端口：

在通过认证前，只允许认证报文EAPOL报文和广播报文（DHCP、ARP）

通过端口，不允许任何其他业务数据流通过；

逻辑受控端口：

多个Supplicant共用一个物理端口，当某个Supplicant没有通过认证前，

只允许认证报文通过该物理端口，不允许业务数据，但其他已通过认证的Supplicant业务不

受影响。

现在在使用中有下面三种情况：

（1）仅对使用同一物理端口的任何一个用户进行认证（仅对一个用户进行认证，认证过

程中忽略其他用户的认证请求），认证通过后其他用户也就可以利用该物理端口访问网络服

务

（2）对共用同一个物理端口的多个用户分别进行认证控制，限制同时使用同一个物理端

口的用户数目（限制MAC地址数目），但不指定MAC地址，让系统根据先到先得原则进

行MAC地址学习，系统将拒绝超过限制数目的请求，若有用户退出，则可以覆盖已退出的

MAC地址。

（3）对利用不同物理端口的用户进行VLAN认证控制，即只允许访问指定VLAN，限制

用户访问非授权VLAN；用户可以利用受控端口，访问指定VLAN，同一用户可以在不同

的端口访问相同的VLAN。

五EAPOL协议的介绍

IEEE802.1x定义了基于端口的网络接入控制协议，需要注意的是该协议仅适用于接入

设备与接入端口间点到点的连接方式。

为了在点到点链路上建立通信，在链路建立阶段PPP

链路的每一端都必须首先发送LCP数据包来对该数据链路进行配置。

在链路已经建立起来

后，在进入网络层协议之前，PPP提供一个可选的认证阶段。

而EAPOL就是PPP的一个可

扩展的认证协议。

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

FlagAddressControlProtocolInformation

当PPP帧中的protocol域表明协议类型为C227（PPPEAP）时，在PPP数据链路层帧的

Information域中封装且仅封装PPPEAP数据包，此时表明将应用PPP的扩展认证协议EAP。

这个时候这个封装着EAP报文的information域就担负起了下一步认证的全部任务，下一步

的EAP认证都将通过它来进行。

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

request、response、success或者failure阶段，每一个

阶段的报文传送都由Information域所携带的EAP报文来承担。

EAP报文的格式为：

CodeIdentifierLengthData

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的值来决定。

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

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

CodeIdentifierLengthTypeTypeData

（1）当Code为1的时候是request报文，当Code为2的时候是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时，它可以暗示它所希望使用并且支持的认证类型。

Type

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

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＝4——→GenericTokenCard

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

式为：

CodeIdentifierLength

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

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

Identifier域必须与其正在应答的Response

域中的Identifier域相匹配。

六总结

1．IEEE802.1x定义了基于端口的网络接入控制协议，其中端口可以是物理端口，也可以是

逻辑端口。

2．802.1x关心的只是一个端口（物理的或者逻辑的）是否打开，而不关心打开之后上来的

是什么样的报文。

3．802.1x协议只是提供了一种用户接入认证的手段，它也只是对用户的认证进行控制，而

接入网络设备必须具备的其他的一些安全和管理特性，由各厂家设备自行来提供的。