之前工作笔记都在有道，最近又调试了一下这个协议巩固了一波，感觉还是发到CSDN来给大家分享更有意义点。
802.1x基本概念简介
802.1x的背景
1.802.1x协议起源于802.11协议，后者是标准的无线局域网协议，802.1x协议的主要目的是为了解决无线局域网用户的接入认证问题，但由于它的原理对于所有符合IEEE 802标准的局域网具有普适性，因此后来它在有线局域网中也得到了广泛的应用。 该协议是IEEE在2001.6通过的正式标准，标准的起草者包括Microsoft，Cisco，Extreme，Nortel等。
2.IEEE 802.1x定义了基于端口的网络接入控制协议（port based network access control），其中端口可以是物理端口，也可以是逻辑端口，对于无线局域网来说 “端口”就是一条信道。
3.802.1x认证的最终目的就是确定一个端口是否可用。对于一个端口，如果认证成功那么就“打开”这个端口，允许所有的报文通过；如果认证不成功就使这个端口保持“关闭”，此时只允许802.1X的认证报文EAPOL（Extensible Authentication Protocol over LANs）通过。
802.1x和其它认证的比较
| 802.1x | PPPOE | WEB认证 | |
| 是否需要安装客户端软件 | 是 XP不需要 | 是 | 否 |
| 业务报文效率 | 高 | 低，有封装开销 | 高 |
| 组播支持能力 | 好 | 低，对设备要求高 | 好 |
| 有线网上的安全性 | 扩展后可用 | 可用 | 可用 |
| 设备端的要求 | 低 | 高 | 较高 |
| 增值应用支持 | 简单 | 复杂 | 复杂 |
801.1x优势较为明显，是理想的低成本运营解决方案。适用于接入设备与接入端口间点到点的连接方式，实现对局域网用户接入的认证与服务管理，常用于运营管理相对简单，业务复杂度较低的企业以及园区。
核心概念
受控端口是802.1x系统的核心概念
1、 认证系统Autheticator内部有受控端口（Controlled Port）和非受控端口（Uncontrolled Port）
1）非受控端口始终处于双向连通状态，不必经过任何授权就可以访问或传递网络资源和服务；受控端口则反之，必须经过授权才能访问或传递网络资源和服务。启动802.1X的端口就是受控端口，用户通过认证获得授权。
2）受控端口可配置为双向受控、仅输入受控两种方式，以适应不同的应用环境。双向受控对受控端口的输入流和输出流都进行控制，在端口未授权前，两个方向的流量都不能通过受控端口。输入受控仅对端口的输入流进行控制，不管端口是否授权，出端口流量不受限制。
3) 目前我们的交换机上的实现仅支持输入受控。
图1 认证前
图2 认证后
2.端口接入控制的模式（目前我司设备有以下三种）：
Authorized-force：常开模式
端口一直维持控制模式，下挂用户无需认证过程就可访问网络资源
Auto：协议控制模式
初始状态为非授权状态，仅允许EAPOL报文收发。802.1X认证通过后，将此端口状态切换到授权状态，这时用户才可访问网络资源，开启认证功能时候应该设置端口为auto模式；
Unauthorized-force：常关模式
端口一直维持非授权状态，忽略所有客户端发起的认证请求，用户不能访问网络资源。
3.端口接入控制方式（目前我司设备支持以下两种） ：
Macbased ：基于MAC地址的认证方式
对共用同一个物理端口的多个用户分别进行认证控制，限制同时使用同一个物理端口的用户数目（限制MAC地址数目），但不指定MAC地址，让系统根据先到先得原则进行MAC地址学习，系统将拒绝超过限制数目的请求，若有用户退出，则可以覆盖已退出的MAC地址。 只有认证通过的用户可以访问网络资源。
Portbased：基于PORT的认证方式
仅对使用同一物理端口的任何一个用户进行认证（仅对一个用户进行认证，认证过程中忽略其他用户的认证请求），认证通过后其他用户也就可以利用该物理端口访问网络资源。
802.1x的体系结构
使用802.1x的系统为典型的C/S（Client/Server）体系结构，包括三个实体，如下图所示分别为：
1）Supplicant System-接入系统（即认证客户端）
用户侧的设备如计算机等需要安装802.1x的客户端（Supplicant）软件，如Windows XP自带的802.1x客户端；
2）Authenticator System-认证系统（即NAS(Network Access Server）
局域网接入控制设备需要提供802.1x的认证系统（Authenticator System）部分；
3）Authentication Server System-认证服务器系统
802.1x的认证服务器系统（Authentication Server System）则一般驻留在运营商的AAA中心。
Authenticator与Authentication Server间通过EAP（Extensible Authentication Protocol，可扩展认证协议）帧交换信息。
Supplicant与Authenticator间则以IEEE 802.1x所定义的EAPoL（EAP over LANs，局域网上的EAP）帧交换信息，EAP帧中封装了认证数据，该认证数据将被封装在其它AAA上层协议（如RADIUS）的报文中以穿越复杂的网络到达Authentication Server，这一过程被称为EAP Relay。
Authenticator的端口又分为两种：
1）非受控端口（Uncontrolled Port）
非受控端口始终处于双向连通状态，用户接入设备可以随时通过这些端口访问网络资源以获得服务；
2）受控端口（Controlled Port）
受控端口只有在用户接入设备通过认证后才处于连通状态，才允许用户通过其进一步访问网络资源。
图3 802.1x 3大实体
802.1x体系与设备软件对应关系
1）接入系统（如PC）需要安装802.1x客户端软件，例如Windows XP的802.1x客户端,我司提供的802.1x客户端；
2）NAS(如交换机)需要实现 802.1x的认证系统功能
3）认证服务器系统一般驻留在运营商的AAA中心，典型的是传统的Radius服务器。如windows2k/2003自带的Radius服务器。
PAE: 端口认证实体(port access entity)
认证机制中负责处理算法和协议的实体。
802.1x的认证方式
1.认证方式种类：
PAP、CHAP、EAP(MD5-Challenge、EAP_TLS、PEAP等)
2.对认证服务器的兼容支持
1）第一种是802.1x标准规定的，将EAP承载在其他高层协议中，如ERPOR(EAP over Radius)，以便EAP报文穿越复杂的网络到达认证服务器 ，,这种方式称为EAP Relay或中继方式。优点是LANSWITCH设备处理更简单，支持更多的认证方式；缺点是认证服务器必须支持EAP。 （ MD5-Challenge，EAP_TLS，PEAP ）
2）第二种是VRP平台802.1x子系统扩展的，将EAP在LANSWITCH设备终结并映射到Radius报文，利用Radius协议完成认证和计费，这种方式称为EAP终结方式。优点是认证服务器无需升级，现有的Radius Server可以继续使用；缺点是LANSWITCH设备处理更复杂。（我司使用EAP)
3.认证机制
1）认证过程可以由用户主动发起，也可以由认证系统发起。一方面当认证系统探测到有未经过认证的用户使用网络时，就会主动向客户端发送EAP-Request/Identity报文，发起认证；另一方面客户端可以通过客户端软件向认证系统发送EAPOL-Start报文，发起认证。
802.1x系统支持EAP中继方式和EAP终结方式与RADIUS对接，从而利用远端的RADIUS服务器完成认证。以下关于两种认证方式的过程描述，都以客户端主动发起认证为例。
2)认证服务器通常为RADIUS服务器，该服务器可以存储有关用户的信息。例如，用户名、密码以及用户所属的VLAN、CAR参数、优先级、用户的访问控制列表等。
3)当用户通过认证后，认证服务器会把用户的相关信息传递给设备端，设备端PAE根据RADIUS服务器的指示（Accept或Reject）决定受控端口的授权/非授权状态。
4.EAP验证原理
1）EAP即扩展验证协议（Extensible Authentication Protocol），见RFC2284定义
2）这种认证方式的质询和计算过程交由服务器完成，从一定程度上减轻了设备的负担。至于具体采用的质询和算法视认证机制而定， EAP 支持多种认证机制：Eap-Md5、 Eap-TLS、Eap-TTLS、 PEAP等。
3）我司设备UT系列目前支持Eap-Md5、 Eap-TLS、 PEAP等。
图4 EAP-MD5中继方式业务流程
认证过程如下：
(1) 当用户有访问网络需求时打开802.1x客户端程序，输入已经申请、登记过的用户名和密码，发起连接请求（EAPOL-Start报文）。此时，客户端程序将发出请求认证的报文给设备端，开始启动一次认证过程。
(2) 设备端收到请求认证的数据帧后，将发出一个请求帧（EAP-Request/Identity报文）要求用户的客户端程序将输入的用户名发送过来。
(3) 客户端程序响应设备端发出的请求，将用户名信息通过数据帧（EAP-Response/Identity报文）发送给设备端。设备端将客户端发送的数据帧经过封包处理后（RADIUS Access-Request报文）送给认证服务器进行处理。
(4) 认证服务器收到设备端发送来的用户名信息后，将该信息与数据库中的用户名表对比，找到该用户名对应的密码信息，用随机生成的一个加密字对它进行加密处理，同时也将此加密字通过RADIUS Access-Challenge报文发送给设备端，由设备端转发客户端程序。
(5) 客户端程序收到由设备端传来的加密字（EAP-Request/MD5 Challenge报文）后，用该加密字对密码部分进行加密处理（此种加密算法通常是不可逆的，生成EAP-Response/MD5 Challenge报文），并通过设备端传给认证服务器。
(6) 认证服务器将收到的已加密的密码信息（RADIUS Access-Request报文）和本地经过加密运算后的密码信息进行对比，如果相同，则认为该用户为合法用户，反馈认证通过的消息（RADIUS Access-Accept报文和EAP-Success报文），设备收到认证通过的消息后触发打开端口的动作，允许用户的业务流通过端口访问网络。
(7) 认证通过后，设备端会定期监测用户的在线情况，方法是设备端向客户端发送握手报文。缺省情况下，两次握手请求报文都得不到客户端应答，设备端就会让用户下线，防止用户因为异常原因下线而设备无法感知。
(8) 客户端也可以发送EAPOL-Logoff报文给设备端，主动终止已认证状态，设备端把端口状态从授权状态改变成未授权状态。
5.CHAP验证原理
1)CHAP即质询握手验证协议（Challenge Handshake Authentication Protocol）
2) 密码是通过密文方式
当用户请求上网时，NAS产生一个16字节的随机码给用户（同时还有一个ID号，本地路由器的 hostname）。用户端得到这个包后使用自己独用的设备或软件对传来的各域进行加密，生成一个response传给NAS。如果使用本地验证，NAS根据用户名在NAS端查找本地数据库，得到和用户端进行加密所用的一样的密码，然后根据原来的16字节的随机码进行加密，将其结果与Response作比较，如果相同表明验证通过，如果不相同表明验证失败。如果使用远程认证，则信息送到server上进行验证。
CHAP认证过程
图4 EAP-MD5终结方式业务流程
EAP和Radius协议介绍
1.协议运用
802.1x通过EAP帧承载认证信息进行认证
客户端PAE与设备端PAE之间
–利用EAP协议交换认证信息，EAP报文使用EAPOL封装格式，直接承载于LAN环境中.
在设备端PAE与RADIUS服务器之间
–EAP中继方式 （EAP透传, eap认证方式）
设备端PAE负责客户端和RADIUS服务器之间EAP报文的中继转发
将EAPOR报文重新封装成EAPOL报文客户端
将EAPOL报文重新封装成EAPOR报文RADIUS服务器
中继转发过程中报文中的信息禁止被修改。(eap属性) ；
–EAP终结方式：由设备端PAE进行终结，而在设备端PAE与RADIUS服务器之间传送包含PAP协议或CHAP协议属性的报文
2.EAPOL消息的封装
1) EAPOL数据包的格式
EAPOL是802.1x协议定义的一种报文封装格式，主要用于在客户端和设备端之间传送EAP协议报文，以允许EAP协议报文在LAN上传送。
EAPOL数据包格式
PAE Ethernet Type：表示协议类型，为0x888E。
Protocol Version：表示EAPOL帧的发送方所支持的协议版本号。
Type：
EAP-Packet（值为0x00），认证信息帧，用于承载认证信息；
EAPOL-Start（值为0x01），认证发起帧；
EAPOL-Logoff（值为0x02），退出请求帧；
EAPOL-Key（值为0x03），密钥信息帧；
EAPOL-Encapsulated-ASF-Alert（值为0x04），用于支持ASF（Alert Standard Forum）的Alerting消息。
Length：表示数据长度，也就是“Packet Body”字段的长度，单位为字节。如果为0，则表示没有后面的数据域。
Packet Body：根据不同的Type有不同的格式。
其中，EAPOL-Start，EAPOL-Logoff和EAPOL-Key仅在客户端和设备端之间存在；在设备端和认证服务器之间，EAP-Packet报文重新封装承载于RADIUS协议上，以便穿越复杂的网络到达认证服务器；EAPOL-Encapsulated-ASF-Alert封装与网管相关信息，例如各种警告信息，由设备端终结。
2)EAP数据包的格式
当EAPOL数据包格式Type域为EAP-Packet时，Packet Body为EAP数据包结构。
EAP数据包格式
Code：指明EAP包的类型，一共有4种：Request，Response，Success，Failure。
Identifier：辅助进行Request和Response消息的匹配。
Length：EAP包的长度，包含Code、Identifier、Length和Data的全部内容，单位为字节。
Data：由Code决定。
Success和Failure类型的包没有Data域，相应的Length域的值为4。Request和Response类型数据包的Data域的格式
Request和Response类型数据包的Data域的格式
Type：指出EAP的认证类型。
Type＝1————Identifier
Type＝2————Notification
Type＝3————Nak（Response Only）
Type＝4————MD5-Challenge
Type＝5————One-Time Password (OTP)
Type＝6————Generic Token Card
EAP属性的封装
RADIUS为支持EAP认证增加了两个属性：EAP-Message（EAP消息）和Message-Authenticator（消息认证码）。
1）EAP-Message
这个属性用来封装EAP数据包，如图6所示，类型代码为79，String域最长253字节，如果EAP数据包长度大于253字节，可以对其进行分片，依次封装在多个EAP-Message属性中。
EAP-Message属性封装
2）Message-Authenticator
这个属性用于在使用EAP等认证方法的过程中，避免接入请求包被窃听。在含有EAP-Message属性的数据包中，必须同时也包含Message-Authenticator，否则该数据包被认为无效而被丢弃。类型代码为80，长度为18字节。
Message-Authenticator属性
3. RADIUS协议
RADIUS定义
RADIUS 是Remote Authentication Dial In User Service （远程认证拨号用户服务）的简称。它是一种分布式的c/s系统，能提供AAA功能。RADIUS技术可以保护网络不受未授权访问的干扰，常被用在既要求较高性能，又要求维持远程用户访问的各种网络环境中。
RADIUS使用的协议
RADIUS基于标准RFC2865，2866协议在UDP/IP层定义了其帧格式及消息传输机制，并定义1812为认证端口，1813为计费端口。（我司交换作服务器常用的是1645和1646）
RADIUS协议的报文结构
Code
1 Access- request
2 Access- accept
3 Access- reject
4 Accounting-request
5 Accounting-response
11 Access-challenge
Identifier
用于匹配请求包和回应包。
Length
所有域（code、 Identifier Length、 Authenticator）的长度。
Authenticator
16 字节长。用于验证RADIUS服务器传回来的请求以及密码隐藏算法上。
RADIUS报文的Attribut域
目前我们交换机所支持的RADIUS属性有两种：标准的RADIUS属性，以及HUAWEI的扩展属性。（属性定义依据的协议有RFC2865,RFC2866,RFC2869,华为公司宽带产品 RADIUS协议标准，RADIUS+1.1协议说明书、RADIUS+1.0协议说明书）
4.EAPOR封装
1）实现方式
EAPOR即 EAP over RADIUS，是通过为RADIUS添加两个新属性EAP-Message和Message-Authenticator来实现对EAP的支持。以便EAP报文穿越复杂的网络到达认证服务器。
Type：与EAP相关的属性值分配
–79 EAP-Message
–80 Message-Authenticator
Length：指明三元组的总长度
Value：格式和长度由Type域和Length域的取值决定对认证服务器的兼容支持
2）EAP-Message属性
–设备端PAE（RADIUS Clinet)从客户端接收到EAP报文后，将它封装在一个或多个EAP-Message属性中，作为Access-Request的一部分转发给RADIUS服务器。RADIUS服务器可以在Access-Challenge，Access-Accept或Access-Reject报文中返回EAP-Message属性
–Access-Accept或Access-Reject报文中包含且只包含一个EAP-Message属性，此属性中包含EAP-Success或EAP-Failure （注意：Accept或Reject报文可以不包含EAP packet或者含有的不是success或failure，因为设备端是根据Radius的Accept或Reject报文来决定端口授权状态，因此，这种情况允许，但是，设备端必须要向客户端发一个EAP Success或EAP Failure报文以通知认证的授权状态）
3）Message-Authenticator属性
–用于保护所有携带EAP-Message属性的Access-Request、Access-Challenge、Access-Accept和Access-Reject报文
–如果带有EAP-Message属性的报文中不包含Message-Authenticator 属性，该报文必须被丢弃。
802.1x的定时器
802.1x认证过程中会启动多个定时器以控制接入用户、设备以及RADIUS服务器之间进行合理、有序的交互。802.1x的定时器主要有以下几种：
用户名请求超时定时器：当设备端向客户端发送EAP-Request/Identity请求报文后，设备端启动该定时器，若在该定时器设置的时长内，设备端没有收到客户端的响应，则设备端将重发认证请求报文。另外，为了兼容不主动发送EAPOL-Start连接请求报文的客户端，设备会定期组播EAP-Request/Identity请求报文来检测客户端。用户名请求超时定时器定义了该组播报文的发送时间间隔。
客户端认证超时定时器：当设备端向客户端发送了EAP-Request/MD5 Challenge请求报文后，设备端启动此定时器，若在该定时器设置的时长内，设备端没有收到客户端的响应，设备端将重发该报文。
认证服务器超时定时器：当设备端向认证服务器发送了RADIUS Access-Request请求报文后，设备端启动认证服务器超时定时器，若在该定时器设置的时长内，设备端没有收到认证服务器的响应，设备端将重发认证请求报文。
握手定时器：此定时器是在用户认证成功后启动的，设备端以此间隔为周期发送握手请求报文，以定期检测用户的在线情况。如果配置发送次数为N，则当设备端连续N次没有收到客户端的响应报文，就认为用户已经下线。
静默定时器：对用户认证失败以后，设备端需要静默一段时间（该时间由静默定时器设置），在静默期间，设备端不处理该用户的认证功能。
GuestVlan
GuestVlan是指用户认证端口在认证之前应该属于一个缺省VLAN，用户访问该VLAN内的资源不需要认证，但此时不能够访问其他网络资源；用户经过802.1x认证成功后，离开GuestVlan，可以访问其他的网络资源。用户在GuestVlan中可以获取802.1x客户端软件，升级客户端，或执行其他一些用户升级程序。如果因为没有专用的认证客户端或者客户端版本过低等原因，导致客户端认证失败，接入设备都会把认证端口加入到GuestVlan。
开启802.1x特性、正确配置GuestVlan后，当设备从某一端口发送触发认证报文（EAP-Request/Identity）超过设定的最大次数而没有收到客户端的任何回应报文后，该端口会被加入到GuestVlan内。此时GuestVlan内的端口下的用户发起认证，如果认证失败，该端口将会仍然处在GuestVlan内；如果认证成功，分为以下两种情况：
l 认证服务器下发一个VLAN，这时端口离开GuestVlan，加入下发的VLAN中。用户下线后，端口会回到配置的VLAN中（加入GuestVlan之前所在的VLAN，即“初始VLAN”）。
l 认证服务器不下发VLAN，这时端口离开GuestVlan，加入配置的VLAN中。用户下线后，端口仍在配置的VLAN
扫一扫
2452
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
