目录

  • 1 概论
    • 1.1 课程简介
    • 1.2 导入
    • 1.3 计算机安全概念
    • 1.4 OSI安全体系结构
    • 1.5 安全攻击
    • 1.6 安全服务
    • 1.7 安全机制
    • 1.8 网络安全模型
    • 1.9 讨论和作业
  • 2 对称加密和消息机密性
    • 2.1 对称加密原理
    • 2.2 对称分组加密算法
    • 2.3 随机数和伪随机数
    • 2.4 流密码和RC4
    • 2.5 分组密码工作模式
    • 2.6 讨论和作业
  • 3 公钥密码和消息认证
    • 3.1 消息认证方法
    • 3.2 安全散列函数
    • 3.3 消息认证码
    • 3.4 公钥密码原理
    • 3.5 公钥密码算法
    • 3.6 数字签名
    • 3.7 讨论和作业
  • 4 密钥分配和用户认证
    • 4.1 基于对称加密的密钥分配
    • 4.2 Kerberos
    • 4.3 基于非对称加密的密钥分配
    • 4.4 X.509证书
    • 4.5 公钥基础设施
    • 4.6 联合身份管理
    • 4.7 讨论和作业
  • 5 网络访问控制和云安全
    • 5.1 网络访问控制
    • 5.2 可扩展认证协议
    • 5.3 IEEE 802.1X基于端口的网络访问控制
    • 5.4 云计算
    • 5.5 云安全风险和对策
    • 5.6 云端数据保护
    • 5.7 云安全即服务
    • 5.8 讨论和作业
  • 6 传输层安全
    • 6.1 Web安全需求
    • 6.2 安全套接字层和传输层安全
    • 6.3 传输层安全
    • 6.4 HTTPS
    • 6.5 SSH
    • 6.6 讨论和作业
  • 7 无线网络安全
    • 7.1 无线安全
    • 7.2 移动设备安全
    • 7.3 IEEE 802.11无线局域网概述
    • 7.4 IEEE 802.11i无线局域网安全
    • 7.5 讨论和作业
  • 8 电子邮件安全
    • 8.1 引言
    • 8.2 PGP
    • 8.3 S/MIME
    • 8.4 DKIM
    • 8.5 讨论和作业
  • 9 IP安全
    • 9.1 IP安全概述
    • 9.2 IP安全策略
    • 9.3 IPSec通信协议
    • 9.4 安全关联组合
    • 9.5 因特网密钥交换
    • 9.6 密码套件
    • 9.7 讨论和作业
  • 10 恶意软件
    • 10.1 恶意软件类型
    • 10.2 传播-感染内容-病毒
    • 10.3 传播-漏洞利用-蠕虫
    • 10.4 传播-社会工程-垃圾邮件与特洛伊木马
    • 10.5 载荷-系统破坏
    • 10.6 载荷-攻击代理-僵尸病毒与机器人
    • 10.7 载荷-信息窃取-键盘监测器、网络钓鱼与间谍软件
    • 10.8 载荷-隐身-后门与隐匿程序
    • 10.9 防护措施
    • 10.10 分布式拒绝服务攻击
    • 10.11 讨论和作业
  • 11 入侵者
    • 11.1 入侵者
    • 11.2 入侵检测
    • 11.3 口令管理
    • 11.4 讨论和作业
  • 12 防火墙
    • 12.1 防火墙的必要性
    • 12.2 防火墙特征
    • 12.3 防火墙类型
    • 12.4 防火墙载体
    • 12.5 防火墙的位置和配置
    • 12.6 讨论和作业
  • 13 总结
    • 13.1 信息安全
    • 13.2 网络安全
    • 13.3 系统安全
    • 13.4 思维导图
IEEE 802.1X基于端口的网络访问控制




扩展阅读

802.1X技术介绍

转载 最后发布于2018-08-16 10:54:01 阅读数 7529 

https://blog.csdn.net/zally_1994/article/details/81736631


802.1X

        IEEE802 LAN/WAN委员会为解决无线局域网网络安全问题,提出了802.1X协议。后来,802.1X协议作为局域网端口的一个普通接入控制机制在以太网中被广泛应用,主要解决以太网内认证和安全方面的问题。

        802.1X协议是一种基于端口的网络接入控制协议(port based network access control protocol)。“基于端口的网络接入控制”是指在局域网接入设备的端口这一级对所接入的用户设备进行认证和控制。连接在端口上的用户设备如果能通过认证,就可以访问局域网中的资源;如果不能通过认证,则无法访问局域网中的资源。

802.1X的体系结构

802.1X系统为典型的Client/Server结构,如图 1所示,包括三个实体:客户端(Client)、设备端(Device)和认证服务器(Server)。

图 1 802.1X认证系统的体系结构

  • 客户端是位于局域网段一端的一个实体,由该链路另一端的设备端对其进行认证。客户端一般为一个用户终端设备,用户可以通过启动客户端软件发起802.1X认证。客户端必须支持EAPOL(Extensible Authentication Protocol over LAN,局域网上的可扩展认证协议)。

  • 设备端是位于局域网段一端的另一个实体,对所连接的客户端进行认证。设备端通常为支持802.1X协议的网络设备,它为客户端提供接入局域网的端口,该端口可以是物理端口,也可以是逻辑端口。

  • 认证服务器是为设备端提供认证服务的实体。认证服务器用于实现对用户进行认证、授权和计费,通常为RADIUS(Remote Authentication Dial-In User Service,远程认证拨号用户服务)服务器。

802.1X的认证方式

802.1X认证系统使用EAP(Extensible Authentication Protocol,可扩展认证协议),来实现客户端、设备端和认证服务器之间认证信息的交换。

  • 在客户端与设备端之间,EAP协议报文使用EAPOL封装格式,直接承载于LAN环境中。

  • 在设备端与RADIUS服务器之间,可以使用两种方式来交换信息。一种是EAP协议报文由设备端进行中继,使用EAPOR(EAP over RADIUS)封装格式承载于RADIUS协议中;另一种是EAP协议报文由设备端进行终结,采用包含PAP(Password Authentication Protocol,密码验证协议)或CHAP(Challenge Handshake Authentication Protocal,质询握手验证协议)属性的报文与RADIUS服务器进行认证交互。

802.1X的基本概念

1. 受控/非受控端口

设备端为客户端提供接入局域网的端口,这个端口被划分为两个逻辑端口:受控端口和非受控端口。任何到达该端口的帧,在受控端口与非受控端口上均可见。

  • 非受控端口始终处于双向连通状态,主要用来传递EAPOL协议帧,保证客户端始终能够发出或接收认证报文。

  • 受控端口在授权状态下处于双向连通状态,用于传递业务报文;在非授权状态下禁止从客户端接收任何报文。

2. 授权/非授权状态

设备端利用认证服务器对需要接入局域网的客户端执行认证,并根据认证结果(Accept或Reject)对受控端口的授权/非授权状态进行相应地控制。

图 2显示了受控端口上不同的授权状态对通过该端口报文的影响。图中对比了两个802.1X认证系统的端口状态。系统1的受控端口处于非授权状态(相当于端口开关打开),系统2的受控端口处于授权状态(相当于端口开关关闭)。

图 2 受控端口上授权状态的影响

用户可以通过在端口下配置的接入控制的模式来控制端口的授权状态。端口支持以下三种接入控制模式:

  • 强制授权模式(authorized-force):表示端口始终处于授权状态,允许用户不经认证授权即可访问网络资源。

  • 强制非授权模式(unauthorized-force):表示端口始终处于非授权状态,不允许用户进行认证。设备端不对通过该端口接入的客户端提供认证服务。

  • 自动识别模式(auto):表示端口初始状态为非授权状态,仅允许EAPOL报文收发,不允许用户访问网络资源;如果认证通过,则端口切换到授权状态,允许用户访问网络资源。这也是最常见的情况。

3. 受控方向

在非授权状态下,受控端口可以被设置成单向受控和双向受控。

  • 实行双向受控时,禁止帧的发送和接收;

  • 实行单向受控时,禁止从客户端接收帧,但允许向客户端发送帧。

EAPOL消息的封装

1. EAPOL数据包的格式

EAPOL是802.1X协议定义的一种报文封装格式,主要用于在客户端和设备端之间传送EAP协议报文,以允许EAP协议报文在LAN上传送。EAPOL数据包的格式如图 3所示。

图 3 EAPOL数据包格式

PAE Ethernet Type:表示协议类型,为0x888E。

Protocol Version:表示EAPOL帧的发送方所支持的协议版本号。

Type:表示EAPOL数据帧类型,目前设备上支持的数据类型见表 1。

表 1 EAPOL数据类型

Length:表示数据长度,也就是“Packet Body”字段的长度,单位为字节。如果为0,则表示没有后面的数据域。

Packet Body:表示数据内容,根据不同的Type有不同的格式。

2. EAP数据包的格式

当EAPOL数据包格式Type域为EAP-Packet时,Packet Body为EAP数据包结构,如图 4所示。

图 4 EAP数据包格式

Code:指明EAP包的类型,共有4种:Request、Response、Success、Failure。

  • Success和Failure类型的包没有Data域,相应的Length域的值为4。

  • Request和Response类型数据包的Data域的格式如图 5所示。Type为EAP的认证类型,Type data的内容由类型决定。例如,Type值为1时代表Identity,用来查询对方的身份;Type值为4时,代表MD5-Challenge,类似于PPP CHAP协议,包含质询消息。

图 5 Request和Response类型数据包的Data域的格式

Identifier:用于匹配Request消息和Response消息。

Length:EAP包的长度,包含Code、Identifier、Length和Data域,单位为字节。

Data:EAP包的内容,由Code类型决定。

EAP属性的封装

RADIUS为支持EAP认证增加了两个属性:EAP-Message(EAP消息)和Message-Authenticator(消息认证码)。

1. EAP-Message

如图 6所示,这个属性用来封装EAP数据包,类型代码为79,String域最长253字节,如果EAP数据包长度大于253字节,可以对其进行分片,依次封装在多个EAP-Message属性中。

图 6 EAP-Message属性封装

2. Message-Authenticator

如图 7所示,这个属性用于在使用EAP、CHAP等认证方法的过程中,避免接入请求包被窃听。在含有EAP-Message属性的数据包中,必须同时也包含Message-Authenticator,否则该数据包会被认为无效而被丢弃。

图 7 Message-Authenticator属性

802.1X的认证触发方式

802.1X的认证过程可以由客户端主动发起,也可以由设备端发起。设备支持的认证触发方式包括以下两种:

1. 客户端主动触发方式

客户端主动向设备端发送EAPOL-Start报文来触发认证,该报文目的地址为IEEE 802.1X协议分配的一个组播MAC地址:01-80-C2-00-00-03。

另外,由于网络中有些设备不支持上述的组播报文,使得认证设备无法收到客户端的认证请求,因此设备端还支持广播触发方式,即,可以接收客户端发送的目的地址为广播MAC地址的EAPOL-Start报文。这种触发方式需要H3C iNode的802.1X客户端的配合。

2. 设备端主动触发方式

设备会每隔N秒(例如30秒)主动向客户端发送EAP-Request/Identity报文来触发认证,这种触发方式用于支持不能主动发送EAPOL-Start报文的客户端,例如Windows XP自带的802.1X客户端。

802.1X的认证过程

802.1X系统支持EAP中继方式和EAP终结方式与远端RADIUS服务器交互完成认证。以下关于两种认证方式的过程描述,都以客户端主动发起认证为例。

1. EAP中继方式

这种方式是IEEE 802.1X标准规定的,将EAP(可扩展认证协议)承载在其它高层协议中,如EAP over RADIUS,以便扩展认证协议报文穿越复杂的网络到达认证服务器。一般来说,EAP中继方式需要RADIUS服务器支持EAP属性:EAP-Message和Message-Authenticator,分别用来封装EAP报文及对携带EAP-Message的RADIUS报文进行保护。

下面以EAP-MD5方式为例介绍基本业务流程,如图 8所示。

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

认证过程如下:

(1) 当用户有访问网络需求时打开802.1X客户端程序,输入已经申请、登记过的用户名和密码,发起连接请求(EAPOL-Start报文)。此时,客户端程序将发出请求认证的报文给设备端,开始启动一次认证过程。

(2)设备端收到请求认证的数据帧后,将发出一个请求帧(EAP-Request/Identity报文)要求用户的客户端程序发送输入的用户名。

(3)客户端程序响应设备端发出的请求,将用户名信息通过数据帧(EAP-Response/Identity报文)发送给设备端。设备端将客户端发送的数据帧经过封包处理后(RADIUS Access-Request报文)送给认证服务器进行处理。

(4)RADIUS服务器收到设备端转发的用户名信息后,将该信息与数据库中的用户名表对比,找到该用户名对应的密码信息,用随机生成的一个加密字对它进行加密处理,同时也将此加密字通过RADIUS Access-Challenge报文发送给设备端,由设备端转发给客户端程序。

(5)客户端程序收到由设备端传来的加密字(EAP-Request/MD5 Challenge报文)后,用该加密字对密码部分进行加密处理(此种加密算法通常是不可逆的),生成EAP-Response/MD5 Challenge报文,并通过设备端传给认证服务器。

(6)RADIUS服务器将收到的已加密的密码信息(RADIUS Access-Request报文)和本地经过加密运算后的密码信息进行对比,如果相同,则认为该用户为合法用户,反馈认证通过的消息(RADIUS Access-Accept报文和EAP-Success报文)。

(7)设备收到认证通过消息后将端口改为授权状态,允许用户通过端口访问网络。在此期间,设备端会通过向客户端定期发送握手报文的方法,对用户的在线情况进行监测。缺省情况下,两次握手请求报文都得不到客户端应答,设备端就会让用户下线,防止用户因为异常原因下线而设备无法感知。

(8)客户端也可以发送EAPOL-Logoff报文给设备端,主动要求下线。设备端把端口状态从授权状态改变成未授权状态,并向客户端发送EAP-Failure报文。

2. EAP终结方式

这种方式将EAP报文在设备端终结并映射到RADIUS报文中,利用标准RADIUS协议完成认证、授权和计费。设备端与RADIUS服务器之间可以采用PAP或者CHAP认证方法。以下以CHAP认证方法为例介绍基本业务流程,如图 9所示。

图 9 IEEE 802.1X认证系统的EAP终结方式业务流程

EAP终结方式与EAP中继方式的认证流程相比,不同之处在于用来对用户密码信息进行加密处理的随机加密字由设备端生成,之后设备端会把用户名、随机加密字和客户端加密后的密码信息一起送给RADIUS服务器,进行相关的认证处理。

802.1X的接入控制方式

设备不仅支持协议所规定的基于端口的接入认证方式,还对其进行了扩展、优化,支持基于MAC的接入控制方式。

  • 当采用基于端口的接入控制方式时,只要该端口下的第一个用户认证成功后,其它接入用户无须认证就可使用网络资源,但是当第一个用户下线后,其它用户也会被拒绝使用网络。

  • 采用基于MAC的接入控制方式时,该端口下的所有接入用户均需要单独认证,当某个用户下线时,也只有该用户无法使用网络。

802.1X的定时器

802.1X认证过程中会启动多个定时器以控制接入用户、设备以及RADIUS服务器之间进行合理、有序的交互。802.1X的定时器主要有以下几种:

  • 用户名请求超时定时器(tx-period):该定时器定义了两个时间间隔。其一,当设备端向客户端发送EAP-Request/Identity请求报文后,设备端启动该定时器,若在tx-period设置的时间间隔内,设备端没有收到客户端的响应,则设备端将重发认证请求报文;其二,为了兼容不主动发送EAPOL-Start连接请求报文的客户端,设备会定期组播EAP-Request/Identity请求报文来检测客户端。tx-period定义了该组播报文的发送时间间隔。

  • 客户端认证超时定时器(supp-timeout):当设备端向客户端发送了EAP-Request/MD5 Challenge请求报文后,设备端启动此定时器,若在该定时器设置的时长内,设备端没有收到客户端的响应,设备端将重发该报文。

  • 认证服务器超时定时器(server-timeout):当设备端向认证服务器发送了RADIUS Access-Request请求报文后,设备端启动server-timeout定时器,若在该定时器设置的时长内,设备端没有收到认证服务器的响应,设备端将重发认证请求报文。

  • 握手定时器(handshake-period):此定时器是在用户认证成功后启动的,设备端以此间隔为周期发送握手请求报文,以定期检测用户的在线情况。如果配置发送次数为N,则当设备端连续N次没有收到客户端的响应报文,就认为用户已经下线。

  •  静默定时器(quiet-period):对用户认证失败以后,设备端需要静默一段时间(该时间由静默定时器设置),在静默期间,设备端不处理该用户的认证请求。

  • 周期性重认证定时器(reauth-period):如果端口下开启了周期性重认证功能,设备端以此定时器设置的时间间隔为周期对该端口在线用户发起重认证。

和802.1X配合使用的特性

1. VLAN下发

802.1X用户在服务器上通过认证时,服务器会把授权信息传送给设备端。如果服务器上配置了下发VLAN功能,则授权信息中含有授权下发的VLAN信息,设备根据用户认证上线的端口链路类型,按以下三种情况将端口加入下发VLAN中。

  • 端口的链路类型为Access,当前Access端口离开用户配置的VLAN并加入授权下发的VLAN中。

  • 端口的链路类型为Trunk,设备允许授权下发的VLAN通过当前Trunk端口,并且端口的缺省VLAN ID为下发VLAN的VLAN ID。

  • 端口的链路类型为Hybrid,设备允许授权下发的VLAN以不携带Tag的方式通过当前Hybrid端口,并且端口的缺省VLAN ID为下发VLAN的VLAN ID。需要注意的是,若当前Hybrid端口上配置了基于MAC的VLAN,则设备将根据认证服务器下发的授权VLAN动态地创建基于用户MAC的VLAN,而端口的缺省VLAN ID并不改变。

授权下发的VLAN并不改变端口的配置,也不影响端口的配置。但是,授权下发的VLAN的优先级高于用户配置的VLAN,即通过认证后起作用的VLAN是授权下发的VLAN,用户配置的VLAN在用户下线后生效。

2. Guest VLAN

Guest VLAN功能允许用户在未认证的情况下,可以访问某一特定VLAN中的资源,比如获取客户端软件,升级客户端或执行其他一些用户升级程序。这个VLAN称之为Guest VLAN。

根据端口的接入控制方式不同,可以将Guest VLAN划分基于端口的Guest VLAN和基于MAC的Guest VLAN。

(1) PGV(Port-based Guest VLAN)

在接入控制方式为portbased的端口上配置的Guest VLAN称为PGV。若在一定的时间内(默认90秒),配置了PGV的端口上无客户端进行认证,则该端口将被加入Guest VLAN,所有在该端口接入的用户将被授权访问Guest VLAN里的资源。端口加入Guest VLAN的情况与加入授权下发VLAN相同,与端口链路类型有关。

当端口上处于Guest VLAN中的用户发起认证且失败时:如果端口配置了Auth-Fail VLAN,则该端口会被加入Auth-Fail VLAN;如果端口未配置Auth-Fail VLAN,则该端口仍然处于Guest VLAN内。关于Auth-Fail VLAN的具体介绍请参见“3. Auth-Fail VLAN”。

当端口上处于Guest VLAN中的用户发起认证且成功时,端口会离开Guest VLAN,之后端口加入VLAN情况与认证服务器是否下发VLAN有关,具体如下:

  • 若认证服务器下发VLAN,则端口加入下发的VLAN中。用户下线后,端口离开下发的VLAN回到初始VLAN中,该初始VLAN为端口加入Guest VLAN之前所在的VLAN。

  • 若认证服务器未下发VLAN,则端口回到初始VLAN中。用户下线后,端口仍在该初始VLAN中。

(2)MGV(MAC-based Guest VLAN)

在接入控制方式为macbased的端口上配置的Guest VLAN称为MGV。配置了MGV的端口上未认证的用户被授权访问Guest VLAN里的资源。

当端口上处于Guest VLAN中的用户发起认证且失败时:如果端口配置了Auth-Fail VLAN,则认证失败的用户将被加入Auth-Fail VLAN;如果端口未配置Auth-Fail VLAN,则该用户将仍然处于Guest VLAN内。

当端口上处于Guest VLAN中的用户发起认证且成功时,设备会根据认证服务器是否下发VLAN决定将该用户加入到下发的VLAN中,或回到加入Guest VLAN之前端口所在的初始VLAN。

3. Auth-Fail VLAN

Auth-Fail VLAN功能允许用户在认证失败的情况下可以访问某一特定VLAN中的资源,这个VLAN称之为Auth-Fail VLAN。需要注意的是,这里的认证失败是认证服务器因某种原因明确拒绝用户认证通过,比如用户密码错误,而不是认证超时或网络连接等原因造成的认证失败。

与Guest VLAN类似,根据端口的接入控制方式不同,可以将Auth-Fail VLAN划分为基于端口的Auth-Fail VLAN和基于MAC的Auth-Fail VLAN。

(1)PAFV(Port-based Auth-Fail VLAN)

在接入控制方式为portbased的端口上配置的Auth-Fail VLAN称为PAFV。在配置了PAFV的端口上,若有用户认证失败,则该端口会被加入到Auth-Fail VLAN,所有在该端口接入的用户将被授权访问Auth-Fail VLAN里的资源。端口加入Auth-Fail VLAN的情况与加入授权下发VLAN相同,与端口链路类型有关。

当端口上处于Auth-Fail VLAN中的用户再次发起认证时:如果认证失败,则该端口将会仍然处于Auth-Fail VLAN内;如果认证成功,则该端口会离开Auth-Fail VLAN,之后端口加入VLAN情况与认证服务器是否下发VLAN有关,具体如下:

  • 若认证服务器下发VLAN,则端口加入下发的VLAN中。用户下线后,端口会离开下发的VLAN回到初始VLAN中,该初始VLAN为端口加入任何授权VLAN之前所在的VLAN。

  • 若认证服务器未下发VLAN,则端口回到初始VLAN中。用户下线后,端口仍在该初始VLAN中。

  • MAFV(MAC-based Auth-Fail VLAN)

在接入控制方式为macbased的端口上配置的Auth-Fail VLAN称为MAFV。在配置了MAFV的端口上,认证失败的用户将被授权访问Auth-Fail VLAN里的资源。

当Auth-Fail VLAN中的用户再次发起认证时,如果认证成功,则设备会根据认证服务器是否下发VLAN决定将该用户加入到下发的VLAN中,或回到加入Auth-Fail VLAN之前端口所在的初始VLAN。

4. ACL下发

ACL(Access Control List,访问控制列表)提供了控制用户访问网络资源和限制用户访问权限的功能。当用户上线时,如果RADIUS服务器上配置了授权ACL,则设备会根据服务器下发的授权ACL对用户所在端口的数据流进行控制;在服务器上配置授权ACL之前,需要在设备上配置相应的规则。管理员可以通过改变服务器的授权ACL设置或设备上对应的ACL规则来改变用户的访问权限。

5. 指定端口的强制认证域

指定端口的强制认证域(mandatory domain)为802.1X接入提供了一种安全控制策略。所有从该端口接入的802.1X用户将被强制使用该认证域来进行认证、授权和计费,可以防止用户通过恶意假冒其它域账号来接入网络。

另外,对于采用证书的EAP中继方式的802.1X认证来说,接入用户的客户端证书决定了用户的域名。因此,即使所有端口上客户端的用户证书隶属于同一证书颁发机构,即输入的用户域名相同,管理员也可以通过配置强制认证域对不同端口指定不同的认证域,从而增加了管理员部署802.1X接入策略的灵活性。

802.1X支持EAD快速部署配置

1. 概述

EAD(Endpoint Admission Defense,端点准入防御)作为一个网络端点接入控制方案,它通过安全客户端、安全策略服务器、接入设备以及第三方服务器的联动,加强了对用户的集中管理,提升了网络的整体防御能力。但是在实际的应用过程中EAD客户端的部署工作量很大,例如,需要网络管理员手动为每一个EAD客户端下载、升级客户端软件,这在EAD客户端数目较多的情况下给管理员带来了操作上的不便。

802.1X认证支持的EAD快速部署就可以解决以上问题,可为所有接入网络的终端用户提供自动下载并安装EAD客户端的方便途径。

2. 实现机制

802.1X支持的EAD快速部署是通过以下两个功能的配合工作实现的:

(1)用户受限访问

802.1X认证成功之前(包括认证失败),终端用户只能访问一个特定的IP地址段。该IP地址段中可以配置一个或多个特定服务器,用于提供EAD客户端的下载升级或者动态地址分配等服务。

(2)用户HTTP访问URL重定向

终端用户在802.1X认证成功之前(包括认证失败),如果使用浏览器访问网络,设备会将用户访问的URL重定向到已配置的URL(例如,重定向到EAD客户端下载界面),这样只要用户打开浏览器,就必须进入管理员预设的界面。提供重定向URL的服务器必须位于用户受限访问的特定网段内。



EAPOL

转载 最后发布于2014-02-18 17:43:19 阅读数 5583

https://blog.csdn.net/printfmylife20140214/article/details/19419159


          EAP(Extensible Authentication Protocol),可扩展认证协议,是一种普遍使用的支持多种认证方法的认证框架协议,主要用于网络接入认证。该协议一般运行在数据链路层上,即可以直接运行于PPP或者IEEE 802之上,不必依赖于IP。EAP可应用于无线、有线网络中。

         EAP的架构非常灵活,在Authenticator(认证方)和Supplicant(客户端)交互足够多的信息之后,才会决定选择一种具体的认证方法,即允许协商所希望的认证方法。认证方不用支持所有的认证方法,因为EAP架构允许使用一个后端的认证服务器(也就是AAA服务器),此时认证方将在客户端和认证服务器之间透传消息。

图1 EAP典型使用组网(Ethernet)

       该协议支持重传机制,但这需要依赖于底层保证报文的有序传输,EAP不支持乱序报文的接收。协议本身不支持分片与重组,当一些EAP认证方法生成大于MTU(Maximum Transmission Unit,最大传输单元)的数据时,需要认证方法自身支持分片与重组。

EAP认证方法目前大约有40种,IETF的RFC中定义的方法包括:EAP-MD5、 EAP-OTP、EAP-GTC、EAP-TLS、EAP-SIM和EAP-AKA, 还包括一些厂商提供的方法和新的建议。

EAPOL报文的封装格式

EAP在LAN的报文(简称EAPOL)封装格式在IEEE-802.1X协议中定义,其数据包的格式如下所示。

PAE(Port Access Entity)Ethernet Type:2字节,表示协议类型,为0x888E。

Protocol Version:1字节,表示EAPOL帧的发送方所支持的协议版本号。

Type:1字节,表示EAPOL数据帧类型,具体类型如表1所示。

类型

说明

EAP-Packet(值为0x00):认证信息帧,用于承载认证信息

该类型的帧在认证方重新封装并承载于RADIUS等协议上,便于穿越复杂的网络到达认证服务器

EAPOL-Start(值为0x01):认证发起帧

这两种类型的帧仅在客户端和认证方之间存在

EAPOL-Logoff(值为0x02):退出请求帧

表1 EAPOL数据类型

Length:2字节,表示数据长度,也就是“Packet Body”字段的长度,单位为字节。如果为0,则表示没有后面的数据域。

EAPOL-Start和EAPOL-Logoff报文的Length值都为0。

Packet Body:表示数据内容,根据不同的Type有不同的格式。

eap报文格式

当EAPOL数据帧格式Type域为EAP-Packet时,Packet Body为EAP数据报文,结构如图4所示。

图4 EAP报文格式

Code:一个字节,指明EAP包的类型,共有4种,域值定义如下:

1--------Request

2--------Response

3--------Success

4--------Failure

由于该字段值只定义了1到4,如果EAP报文的该字段为其他值,则应被Authenticator和Supplicant丢弃。

Identifier:一个字节,用于应答报文和请求报文之间进行匹配。

Length:两个字节,EAP包的长度,包含Code、Identifier、Length和Data域,单位为字节。

Data:零个或多个字节,EAP包的内容,由Code类型决定

RFC 3748中定义的Success和Failure类型的包没有Data域,相应的Length域的值为4。但是某些软件的实现中,为了说明认证失败的原因,在Length域后面增加了字段用于说明下线的原因,故Length域的值可能为其他值。

Request和Response类型报文的Data域格式如图所示。

Type:一个字节,标识EAP的认证类型。

Type Data:该字段的内容由Type字段的值决定。

Type字段目前定义的值及其简要说明如下:

Type=1 ----Identifier(用来询问对端的身份)

Type=2 ----Notification(非必须的一个消息,传送一些警告消息,比如提示密码将要超期、OTP的顺序号码接近零以及认证失败的警告等)。

Type=3 ----Nak (Response Only)(Request报文中的认证类型不可接受时回复该类型的报文)

Type=4 ----MD5-Challenge(类似于CHAP中的MD5-Challenge,使用MD5算法)

Type=5 ----One-Time Password (OTP)(一种密码交互的方式)

Type=6 ----Generic Token Card(通用令牌卡类型,适用于各种需要用户输入信息的令牌卡的实现)

Type=254 ----Expanded Types(供厂商支持自己的扩展类型)

Type=255 ----Experimental use(在实验新的类型时使用)

每种Type对应的Type Data字段这里不作详细描述,有兴趣的读者请查阅RFC 3748相关章节。

 EAP认证过程

EAP过程由认证方发起,而认证协议一般都是由客户端发起,为了在特定的认证协议上支持EAP过程,认证协议需要增加一个或多个的附加报文来满足条件。如以太网上的认证通常情况下是以客户端发送EAPOL报文开始的。

EAP的典型过程如下:

1、Authenticator发送请求报文EAP-Request给Supplicant(客户端),表明EAP认证开始。该请求由一个字段标明需要请求的数据是什么。这个字段包含Identity(询问对端的身份), MD5-challenge(MD5挑战字)等。上述发送EAP-Request的步骤在某些情况下也可省去,比如在有线网络中,Authenticator(有时也称为NAS)已经根据客户端连接的端口识别用户身份,或者通过MAC地址,IMSI卡等识别用户身份的情况下。

2、Supplicant针对Authenticator发过来的请求回应一个响应消息EAP-Response,该消息包含了请求消息中请求的字段信息,如身份识别信息。

3、Authenticator继续发送EAP-Request消息,消息中包含具体EAP Type及其协议数据,Supplicant对此做出响应。根据EAP Method的不同,此步骤可能会交互多次。

EAP交互过程是Supplicant与Authenticator一来一往的过程,每次只能处理一个EAP报文,在收到响应之前不能发送新的请求,即锁步机制(Lockstep)。因此Authenticator要负责请求消息的重传。如果重传一定次数后都没有收到应答消息,这次的EAP过程就要被终结。重传后收到应答消息或者一直没有收到应答消息,Authenticator都不发送成功或者失败消息。

4、交互多次之后,会出现两种情形:Authenticator不能确认Supplicant的接入权限,此时必须发送EAP-Failure,终结此次的EAP过程;或者确认接入权限,此时必须发送EAP-Success消息。

Authenticator也可以作为Pass Through设备,透传EAP报文。这种情形下Authenticator检查EAP的Code,Id及Length并将报文转发出去。Authenticator需要将EAP Code为2(Response)的报文转给后端的认证服务器,将EAP Code=1(Request),3(Success),4(Failure)的报文转给Supplicant。在这个处理过程中除非Pass Through Authenticator实现了某种EAP Methods,一般是只将消息转发,并不去检查EAP Methods Layer的的消息头(即EAP Type)。