本站使用了 Pjax 等基于 JavaScript 的开发技术,但您的浏览器已禁用 JavaScript,请开启 JavaScript 以保证网站正常显示!

802.1x配置与原理-802.1x协议简介

<!--index-menu-->

802.1X协议是一种基于端口的网络接入控制协议,即在局域网接入设备的端口上对所接入的用户和设备进行认证,以便控制用户设备对网络资源的访问。


1.1 802.1X的体系结构

802.1X系统中包括三个实体:客户端(Client)、设备端(Device)和认证服务器(Authentication server),如图1-1所示。
<center>
图1-1 802.1X体系结构图

</center>

  • 客户端是请求接入局域网的用户终端,由局域网中的设备端对其进行认证。客户端上必须安装支持802.1X认证的客户端软件。
  • 设备端是局域网中控制客户端接入的网络设备,位于客户端和认证服务器之间,为客户端提供接入局域网的端口(物理端口或逻辑端口),并通过与认证服务器的交互来对所连接的客户端进行认证。
  • 认证服务器用于对客户端进行认证、授权和计费,通常为RADIUS(Remote Authentication Dial-In User Service,远程认证拨号用户服务)服务器。认证服务器根据设备端发送来的客户端认证信息来验证客户端的合法性,并将验证结果通知给设备端,由设备端决定是否允许客户端接入。在一些规模较小的网络环境中,认证服务器的角色也可以由设备端来代替,即由设备端对客户端进行本地认证、授权和计费。

小结:802.1x的认证控制需要三个角色,Client--Device--Authentication server,即客户端--设备端--服务器端。
服务器端在小型网络中可被设备端代替。即设备端可用来做认证服务器,代替认证服务器对客户端进行认证管理。


1.2 802.1X对端口的控制

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

  1. 非受控端口:可看成为EAP(可扩展认证协议)端口,不进行认证控制,始终处于双向连通状态,主要用来传递在通过认证前必需的EAPOL协议帧,保证客户端始终能够发出或接收认证报文。
    <center>

图为EAPOL报文格式:

</center>

  1. 受控端口:可以看作为普通业务端口,是需要进行认证控制的。它有“授权”和“非授权”两种状态(相当于在该端口上有一个控制开关):在授权状态下处于 双向连通状态(控制开关闭合),可进行正常的业务报文传递;在非授权状态下处于打开状态(控制开关打开),禁止任何业务报文的传递。设备端利用认证服务器 对客户端进行认证的结果(Accept或Reject)来实现对受控端口的授权/非授权状态进行控制。

    • 客户端认证成功,受控端口处于授权状态。该状态下端口双向连通,用于传递业务报文。
    • 客户端认证失败,受控端口处于非授权状态。该状态下,又可以分为两种情况:

      本文转自咬定面包不放松。

      • 双向受控状态:禁止帧的发送和接收;
      • 单向受控状态时:禁止从客户端接收帧,但允许向客户端发送帧。目前,设备上的受控端口只能处于单向受控状态。

<center>
图1-2 受控端口上授权状态的影响

</center>

小结:
<center>

</center>


1.3 802.1X认证报文的交互机制

802.1X系统使用EAP(Extensible Authentication Protocol,可扩展认证协议)来实现客户端、设备端和认证服务器之间认证信息的交互。EAP是一种C/S模式的认证框架,它可以支持多种认证方法,例如MD5-Challenge、EAP-TLS(Extensible Authentication Protocol -Transport Layer Security,可扩展认证协议-传输层安全)、PEAP(Protected Extensible Authentication Protocol,受保护的扩展认证协议)等。

  • 客户端与设备端之间,EAP报文使用EAPOL(Extensible Authentication Protocol over LAN,局域网上的可扩展认证协议)封装格式承载于数据帧中传递。
  • 在设备端与RADIUS服务器之间,EAP报文的交互有EAP中继和EAP终结两种处理机制。

1. EAP中继

  • 设备端对收到的EAP报文进行中继,使用EAPOR(EAP over RADIUS)封装格式将其承载于RADIUS报文中发送给RADIUS服务器。
    <center>

图1-3 EAP中继原理示意图

</center>
该处理机制下,EAP认证过程在客户端和RADIUS服务器之间进行。RADIUS服务器作为EAP服务器来处理客户端的EAP认证请求,设备相当于一个中继,仅对EAP报文做中转。

2. EAP终结

  • 设备对EAP认证过程进行终结,将收到的EAP报文中的客户端认证信息封装在标准的RADIUS报文中,与服务器之间采用PAP(Password Authentication Protocol,密码认证协议)或CHAP(Challenge Handshake Authentication Protocol,质询握手认证协议)方法进行认证。
    <center>

图1-4 EAP终结原理示意图

</center>

3. EAP中继与EAP终结的对比
<center>
表1-1 EAP中继与EAP终结的对比

</center>

小结:
802.1x认证报文交互:

  1. 客户端与设备端之间使用的是基于以太局域网的EAPOL格式封装EAP报文,承载于以太网帧中进行交换。
  2. 设备端与RADIUS服务器之间的EAP报文可以使用以下两种方式交互:

    • EAP中继:
      来自客户端的EAP报文到达设备端后,直接使用EAPOR(EAP over RADIUS)格式封装在RADIUS报文中,再发送给RADIUS服务器,则RADIUS服务器来从封装的EAP报文中获取客户端确认信息,然后再对客户端进行认证。

    特点:

    - 该种认证方式的优点是设备端的EAP报文进行任何处理,只需要用EAPOR对EAP报文进行封装即可,根本不管客户端的认证信息。同时在这种认证方式中,**设备端与RADIUS服务器之间可支持多种EAP认证方式,例如MD5-Challenge/EAP-TLS/PEAP等,但要求服务器端也支持相应的认证方法。**
    
    • EAP终结:
      来自客户端的EAP报文在设备端进行终结,然后由设备端将从EAP报文中提取的客户端认证信息封装在标准的RADIUS报文(不再是EAPOR格式) 中,与RADIUS服务器之间采用PAP(Password Authentication Protocol,密码验证协议)或CHAP(Challenge Handshake Authentication Protocal,质询握手验证协议)方式对客户端进行认证(当然在RAIUDS服务器端必须配置合法用户的用户名和密码信息)。

    特点:

    - 这种认证方式的优点是现有的RADIUS服务器基本均可支持PAP和CHAP认证,无需升级服务器,但**设备端的工作比较繁重**,因为在这种认证方式中, **设备端不仅要从来自客户端的EAP报文中提取客户端认证信息,还要通过标准的RADIUS协议对这些信息进行封装,且不能支持除MD5- Challenge之外的其它EAP认证方法。**
    

<center>

</center>


1.4 报文格式

1. EAP
EAP报文格式如图1-5所示。
<center>
图1-5 EAP报文格式

</center>

  • 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类型。

2. EAPOL
EAPOL是802.1X协议定义的一种承载EAP报文的封装技术,主要用于在局域网中传送客户端和设备端之间的EAP协议报文。EAPOL数据包的格式如图1-6所示。
<center>
图1-6 EAPOL数据包格式

</center>

  • PAE Ethernet Type:表示协议类型。EAPOL的协议类型为0x888E。
  • Protocol Version:表示EAPOL数据帧的发送方所支持的EAPOL协议版本号。
  • Type:表示EAPOL数据帧类型。目前设备上支持的EAPOL数据帧类型见表1-2。
    <center>

表1-2 EAPOL数据帧类型

</center>

  • Length:表示数据域的长度,也就是Packet Body字段的长度,单位为字节。当EAPOL数据帧的类型为EAPOL-Start或EAPOL-Logoff时,该字段值为0,表示后面没有Packet Body字段。
  • Packet Body:数据域的内容。

3. EAP报文在RADIUS中的封装
RADIUS为支持EAP认证增加了两个属性:EAP-Message(EAP消息)和Message-Authenticator(消息认证码)。在含有EAP-Message属性的数据包中,必须同时包含Message-Authenticator属性。

  • EAP-Message
    如图1-7所示,EAP-Message属性用来封装EAP报文,Value域最长253字节,如果EAP报文长度大于253字节,可以对其进行分片,依次封装在多个EAP-Message属性中。

<center>
图1-7 EAP-Message属性封装

</center>

  • Message-Authenticator
    如图1-8所示,Message-Authenticator属性用于在EAP认证过程中验证携带了EAP-Message属性的RADIUS报文的完整性,避免报文被窜改。如果接收端对接收到的RADIUS报文计算出的完整性校验值与报文中携带的Message-Authenticator属性的Value值不一致,该报文会被认为无效而丢弃。

<center>
图1-8 Message-Authenticator属性封装

</center>


1.5 802.1X的认证过程

设备端支持采用EAP中继方式或EAP终结方式与远端RADIUS服务器交互。以下关于802.1X认证过程的描述,都以客户端主动发起认证为例。

1. EAP中继方式
这种方式是IEEE 802.1X标准规定的,将EAP承载在其它高层协议中,如EAP over RADIUS,以便EAP报文穿越复杂的网络到达认证服务器。一般来说,需要RADIUS服务器支持EAP属性:EAP-Message和Message-Authenticator。
如图1-9所示,以MD5-Challenge类型的EAP认证为例,具体认证过程如下。
<center>
图1-9 IEEE 802.1X认证系统的EAP中继方式认证流程

</center>

  1. 当用户需要访问外部网络时打开802.1X客户端程序,输入用户名和密码,发起连接请求。此时,客户端程序将向设备端发出认证请求帧(EAPOL-Start),开始启动一次认证过程。
  2. 设备端收到认证请求帧后,将发出一个Identity类型的请求帧(EAP-Request/Identity)要求用户的客户端程序发送输入的用户名。
  3. 客户端程序响应设备端发出的请求,将用户名信息通过Identity类型的响应帧(EAP-Response/Identity)发送给设备端。
  4. 设备端将客户端发送的响应帧中的EAP报文封装在RADIUS报文(RADIUS Access-Request)中发送给认证服务器进行处理。
  5. RADIUS服务器收到设备端转发的用户名信息后,将该信息与数据库中的用户名列表对比,找到该用户名对应的密码信息,用随机生成的一个MD5 Challenge对密码进行加密处理,同时将此MD5 Challenge通过RADIUS Access-Challenge报文发送给设备端。
  6. 设备端将RADIUS服务器发送的MD5 Challenge转发给客户端。
  7. 客户端收到由设备端传来的MD5 Challenge后,用该Challenge对密码进行加密处理,生成EAP-Response/MD5 Challenge报文,并发送给设备端。
  8. 设备端将此EAP-Response/MD5 Challenge报文封装在RADIUS报文(RADIUS Access-Request)中发送给RADIUS服务器。
  9. RADIUS服务器将收到的已加密的密码信息和本地经过加密运算后的密码信息进行对比,如果相同,则认为该用户为合法用户,并向设备端发送认证通过报文(RADIUS Access-Accept)。
  10. 设备收到认证通过报文后向客户端发送认证成功帧(EAP-Success),并将端口改为授权状态,允许用户通过端口访问网络。
  11. 用户在线期间,设备端会通过向客户端定期发送握手报文的方法,对用户的在线情况进行监测。
  12. 客户端收到握手报文后,向设备发送应答报文,表示用户仍然在线。缺省情况下,若设备端发送的两次握手请求报文都未得到客户端应答,设备端就会让用户下线,防止用户因为异常原因下线而设备无法感知。
  13. 客户端可以发送EAPOL-Logoff帧给设备端,主动要求下线。
  14. 设备端把端口状态从授权状态改变成未授权状态,并向客户端发送EAP-Failure报文。

说明

EAP中继方式下,需要保证在客户端和RADIUS服务器上选择一致的EAP认证方法,而在设备上,只需要通过dot1x authentication-method eap命令启动EAP中继方式即可。

本文来源:咬定面包不放松

2. EAP终结方式
这种方式将EAP报文在设备端终结并映射到RADIUS报文中,利用标准RADIUS协议完成认证、授权和计费。设备端与RADIUS服务器之间可以采用PAP或者CHAP认证方法。如图1-10所示,以CHAP认证为例,具体的认证流程如下。
<center>
图1-10 IEEE 802.1X认证系统的EAP终结方式认证流程

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

1.6 802.1X的认证触发方式

802.1X的认证过程可以由客户端主动发起,也可以由设备端发起。
一. 客户端主动触发方式

  • 组播触发:客户端主动向设备端发送EAPOL-Start报文来触发认证,该报文目的地址为组播MAC地址01-80-C2-00-00-03。
  • 广播触发:客户端主动向设备端发送EAPOL-Start报文来触发认证,该报文的目的地址为广播MAC地址。该方式可解决由于网络中有些设备不支持上述的组播报文,而造成设备端无法收到客户端认证请求的问题。

说明:

本文来源:咬定面包不放松

目前,iNode的802.1X客户端可支持广播触发方式。

二. 设备端主动触发方式
设备端主动触发方式用于支持不能主动发送EAPOL-Start报文的客户端,例如Windows XP自带的802.1X客户端。设备主动触发认证的方式分为以下两种:

  • 组播触发:设备每隔一定时间(缺省为30秒)主动向客户端组播发送Identity类型的EAP-Request帧来触发认证。
  • 单播触发:当设备收到源MAC地址未知的报文时,主动向该MAC地址单播发送Identity类型的EAP-Request帧来触发认证。若设备端在设置的时长内没有收到客户端的响应,则重发该报文。

 继续浏览关于 的文章

 本文最后更新于 2019/04/29 11:48:08,可能因经年累月而与现状有所差异

 引用转载请注明:咬定面包不放松 > 数据通信 > 802.1x配置与原理-802.1x协议简介

您直接访问了本站,莫非记住了域名?