一、前言

在介绍AAA之前，先举一个生活的例子：

一天，某个人来到一个公司的门岗，他想进入这家公司，门岗在查验此人的身份之前，不允许他进入公司。门岗通过后台系统，查询此人的身份，有以下几种情况：

1、公司领导层

立即放行，并且无条件无阻碍的访问公司的所有区域-生活区、生产区、实验区、仓储区、研发区等等。

2、中层干部

立即放行，只能访问公司的部分区域-关键性、核心、保密性区域之外的区域

3、普通员工

立即放行，只能访问公司的指定区域-生活区、生产区(研发人员只能进入研发区等)

4、合作伙伴-供应商、经销商等

立即放行，只能访问公司的会客区域。

5、以上4种之外的其他人员

禁止进入本公司。

本例中，门岗查验来访者身份，其实就是进行身份验证Authentication（认证），验证来访者身份的合法性。

验证通过的用户即为合法用户，同时给合法用户授予不同的权限-Authorization（授权），合法用户可以访问不同的区域、资源或者指定的区域、资源。

验证没有通过的用户即为非法用户，禁止进入任何区域。

合法用户在授权区域内的行动轨迹的记录或者对授权资源的访问记录即为Accounting（审计）。

AAA=Authentication+Authorization+Accounting

在网络世界里，通过部署AAA，可以防止非法用户进入网络或者非法访问网络资源。合法用户可以访问所有或者指定的资源，并且记录访问行为。

AAA除了提供网络接入服务外，还能提供设备管理服务。

很多网络设备，都配置了远程管理功能(不可能每次有配置变动就跑到现场)。

部署AAA，只有合法用户才能远程登录网络设备。在管理设备上，被授权的合法用户，只能执行授权范围之类的命令；审计系统记录授权用户在管理设备上的所有操作行为。

应用1：通过AAA为上网用户提供认证、授权和计费

应用2、通过AAA对管理用户进行认证、授权和审计

AAA总结：

1、一种安全机制，身份验证、授予权限、记录行为

A、认证：验证用户是否可以获得访问权限——“你是谁？”

B、授权：授权用户可以使用哪些资源——“你能干什么？”

C、审计：记录用户使用网络资源的情况——“你干了些什么？”

2、提供两种服务(应用)：

A、网络接入服务-认证通过的用户可以使用网络

B、设备管理服务-认证通过的用户可以管理网络设备

二、基本原理

AAA 通常采用“客户端—服务器”结构。这种结构既具有良好的可扩展性，又便于集中管理用户信息。

在AAA的具体实现过程中，通过AAA方案来定义一套AAA配置策略。AAA方案是设备上制定的一套认证、授权、计费方法，可根据用户的接入特征以及不同的安全需求组合使用。

1、认证方案

A、不认证：对用户非常信任，不对其进行合法检查，一般情况下不采用这种方式。

B、本地认证：将用户信息配置在网络接入服务器上(AAA客户端)。本地认证的优点是速度快，可以为运营降低成本，缺点是存储信息量受设备硬件条件限制。

C、远端认证：将用户信息配置在认证服务器上(AAA服务器)。支持通过 RADIUS（Remote Authentication Dial In User Service）协议、TACACS+协议或HWTACACS（HuaWei Terminal Access Controller Access Control System）协议进行远端认证。

如果在一个认证方案中采用多种认证模式，将按照配置的顺序进行认证。当配置的认证方式是先远端认证后本地认证时，如果登录的帐号在远端服务器上没有创建，但是在本地是存在的，经过远端认证时，将被认为认证失败，不再转入本地认证。只有在远端认证服务器无响应时，才会转入本地认证。如果选用了不认证（ none ）或本地认证（ local ），它必须作为最后一种认证模式。

2.授权方案

A、不授权：不对用户进行授权处理。

B、本地授权：根据网络接入服务器(AAA客户端)为本地用户账号配置的相关属性进行授权。

C、远端授权：由TACACS+或者HWTACACS 服务器对用户进行授权。

注：RADIUS认证与授权结合，不能分离，认证成功授权也成功。采用RADIUS认证时，不需要配置授权方案。

如果在一个授权方案中使用多次授权，授权模式的执行顺序按照配置的先后，只有在当前授权模式没有响应时，才会尝试下一个授权模式，如果授权失败则将不会再进行授权。

3.计费方案

A、不计费：不对用户计费。

B、远端计费：支持通过 RADIUS 服务器、TACACS+或 HWTACACS 服务器进行远端计费。

注：网络接入服务器(AAA客户端)不支持本地计费。

AAA实现方式主要有以下三种：

1、Radius协议-（Remote Authentication Dial-In User Service，远程认证拨号用户服务）

RADIUS 最初仅是针对拨号用户的 AAA 协议，后来随着用户接入方式的多样化发展，RADIUS也适应多种用户接入方式，如以太网接入、ADSL 接入。它通过认证授权来提供接入服务，通过计费来收集、记录用户对网络资源的使用。

RADIUS 服务器一般运行在中心计算机或工作站上，维护相关的用户认证和网络服务访问信息，负责接收用户连接请求并认证用户，然后给客户端返回所有需要的信息（如接受/拒绝认证请求）。RADIUS 客户端一般位于网络接入服务器 NAS（Network Access Server）设备上，可以遍布整个网络，负责传输用户信息到指定的RADIUS 服务器，然后根据从服务器返回的信息进行相应处理（如接受/拒绝用户接入）。

RADIUS 客户端和RADIUS 服务器之间认证消息的交互是通过共享密钥的参与来完成的，并且共享密钥不能通过网络来传输，增强了信息交互的安全性。另外，为防止用户密码在不安全的网络上传递时被窃取，在传输过程中对密码进行了加密。

802.1x属于以太网接入方式的一种。

RADIUS协议通过UDP协议进行通信，RADIUS服务器的1812端口负责认证，1813端口负责计费工作。

2、Tacacs+协议- Terminal Access Controller Access Control System终端访问控制器访问控制系统

TACACS是作为一个单独的第三方身份验证服务器运行的，该服务器提供身份验证服务。当用户尝试接入到一个安全系统时，该安全系统首先会提示用户输入名字和密码，然后该系统将此信息传递给TACACS服务器并请求身份验证服务。

TACACS最初是由美国国防部和BBN Planet Corp.开发的，后来又由Cisco对其进行了进一步开发。该协议有三个版本：原始的TACACS，XTACACS（扩展的TACACS）和TACACS+。

第一个是普通的TACACS，在思科设备中第一次提供，并已使用多年。

第二个是对第一个的扩展，通常称为扩展（Extended）的TACACS或XTACACS，是在1990年引入的。两者都是基于UDP的服务。

前两个版本在RFC1492(An Access Control Protocol,Sometimes Called TACACS,July 1993)中描述。

第三个版本是TACACS+或tac_plus，这是现在所有人都在用的版本。TACACS+基于TCP，因此不兼容任何以前版本的TACACS。

TACACS+是最新版本，只要是在需要TACACS时都应该使用它。目前通常已不再维护TACACS和XTACACS。

原始的TACACS是非常简单的，而Cisco对其进行了扩展，从而创建了TACACS+，后者在设计上是模块化的，在TACACS和XTACACS的基础上分离了认证、授权和记账功能。

TACACS+和RADIUS的异同点：

TACACS+和RADIUS是用来控制接入网络的两种安全协议。他们是提供AAA服务（认证、授权、统计）最主要的两个协议。

RADIUS协议主要设计用于认证和记录远程用户接入到网络的功能，而TACACS+则主要用于管理员接入到网络设备，如交换机、路由器、防火墙等设备。

TACACS+与RADIUS的最主要的不同点在于TACACS+分离了认证、授权和统计功能，而RADIUS则将认证和授权糅合在一起，RADIUS将授权的信息下发到认证回应报文里。

3、 HWTACACS协议

HW 终端访问控制器控制系统协议 HWTACACS（Huawei Terminal Access Controller Access Control System）是在 TACACS（RFC 1492）基础上进行了功能增强的安全协议。该协议与 RADIUS 协议类似，采用客户端/服务器模式实现 NAS 与 HWTACACS 服务器之间的通信。

HWTACACS 协议主要用于点对点协议 PPP（Point-to-Point Protocol）和虚拟私有拨号网络 VPDN （Virtual Private Dial-up Network）接入用户及终端用户的认证、授权和计费。

其典型应用是对需要登录到设备上进行操作的终端用户进行认证、授权、计费。设备作为HWTACACS 的客户端，将用户名和密码发给 HWTACACS 服务器进行验证。用户验证通过并得到授权之后可以登录到设备上进行操作。

AAA实现方式总结：

场景	概述	具体操作
本地认证和授权	如果需要对用户进行认证或授权，但是在网络中没有部署RADIUS服务器和HWTACACS服务器，那么可以采用本地方式进行认证和授权。本地方式进行认证和授权的优点是速度快，可以降低运营成本；缺点是存储信息量受设备硬件条件限制。管理用户常采用本地认证和授权方式。	AAA客户端上配置采用本地方式进行认证和授权注：不支持本地计费
RADIUS认证、授权和计费	采用RADIUS方式进行认证、授权、计费可以防止非法用户对网络的攻击，常应用在既要求较高安全性又要求控制远程用户访问权限的网络环境中。	AAA客户端配置采用RADIUS方式进行认证、授权和计费
TACACS+认证、授权和计费	采用TACACS+方式进行认证、授权、计费可以防止非法用户对网络的攻击，还支持对命令行进行授权。与RADIUS相比，TACACS+具有更加可靠的传输和加密特性，更加适合于安全控制。	AAA客户端配置采用TACACS+方式进行认证、授权和计费
HWTACACS认证、授权和计费	采用HWTACACS方式进行认证、授权、计费可以防止非法用户对网络的攻击，还支持对命令行进行授权。与RADIUS相比，HWTACACS具有更加可靠的传输和加密特性，更加适合于安全控制。	AAA客户端配置采用HWTACACS方式进行认证、授权和计费

附：

TACACS:原始协议。起源于二十世纪八十年代的AAA（认证、授权、计费）协议，用于与UNIX网络中的身份验证服务器进行通信、决定用户是否有权限访问网络。（RFC 927）

XTACACS:也称为Extended TACACS，cisco对TACACS进行扩展（RFC 1492）

XTACACS还实现了认证、授权和计费流程的相互独立，并且认证和授权可以在不同的服务器上进行，这无疑有助于管理员对用户进行精细管理和控制

TACACS+:在TACACS和XTACACS的基础上，cisco再次进行扩展开发而成

HWTACACS:在TACACS和XTACACS的基础上，华为扩展开发而成

TACACS和XTACACS使用UDP协议传输，而HWTACACS和TACACS+使用TCP协议传输，因此HWTACACS和TACACS+都无法与TACACS或XTACACS兼容。

HWTACACS和TACACS+的认证流程与实现方式是一致的，因此设备使用HWTACACS协议时支持与TACACS+服务器对接。

tacacs+协议和hwtacacs协议定义的报文结构和报文类型一致。两种协议的主要区别在于授权和计费报文中携带的属性含义或类型不完全一致。基本的认证功能、授权用户级别功能、命令行授权功能等都能正常实现，如有其它额外需求，可分别查询tacacs+属性信息和hwtacacs属性信息，两者都支持时，需求就能正常实现。

协议	HWTACACS/TACACS+	RADIUS
数据传输	通过TCP传输，网络传输更可靠。	通过UDP传输，传输效率更高。
加密方式	除了标准的HWTACACS/TACACS+报文头，对报文主体全部进行加密，有利于通信安全。	只是对认证报文中的密码字段进行加密，无法加密用户名、授权和计费等信息。
认证和授权	认证与授权分离。认证、授权服务可以在不同的安全服务器上实现。授权时无需重复进行认证的过程，仅需通知授权服务器，用户已在认证服务器上成功认证。	认证与授权结合，不能分离。
命令行授权	支持对设备上的配置命令进行授权使用。用户可使用的命令行受到命令级别和AAA授权的双重限制。便于管理员进行设备管理。	不支持对设备上的配置命令进行授权使用。用户可使用的命令行由用户级别决定。
事件记录	支持将命令行操作、连接事件和系统级事件发送到服务器存档。	不支持事件记录功能。
协议通用性	属于私有协议，有局限性。	属于标准协议，大部分主流厂商都支持。因此实际网络中应用最多。

三、Radius协议

1、RADIUS协议的主要特征如下：

客户端/服务器模式
安全的消息交互机制
良好的扩展性

A、客户端/服务器模式

RADIUS客户端

一般位于网络接入服务器NAS（Network Access Server）上，可以遍布整个网络，负责传输用户信息到指定的RADIUS服务器，然后根据从服务器返回的信息进行相应处理（如接受/拒绝用户接入）。

网络设备作为RADIUS协议的客户端，实现以下功能：

支持标准RADIUS协议及扩充属性，包括RFC2865、RFC2866。
对RADIUS服务器状态探测功能。
计费结束请求报文的本地缓存重传功能。
RADIUS服务器主备或负载分担功能。

RADIUS服务器

一般运行在中心计算机或工作站上，维护相关的用户认证和网络服务访问信息，负责接收用户连接请求并认证用户，然后给客户端返回所有需要的信息（如接受/拒绝认证请求）。

B、安全的消息交互机制

RADIUS客户端和RADIUS服务器之间认证消息的交互是通过共享密钥的参与来完成的。共享密钥是一个带外传输的、客户端和服务器都知道的字符串，不需要单独进行网络传输。RADIUS报文中有一个16字节的验证字字段，它包含了对整个报文的数字签名数据，该签名数据是在共享密钥的参与下利用MD5算法计算得出。收到RADIUS报文的一方要验证该签名的正确性，如果报文的签名不正确，则丢弃它。通过这种机制，保证了RADIUS客户端和RADIUS服务器之间信息交互的安全性。另外，为防止用户密码在不安全的网络上传递时被窃取，在RADIUS报文传输过程中还利用共享密钥对用户密码进行了加密。

C、良好的扩展性

RADIUS报文是由报文头和一定数目的属性（Attribute）构成，新属性的加入不会破坏协议的原有实现。

2、RADIUS报文介绍

RADIUS报文头格式

一个字节	一个字节	两个字节
Code	Identifier	Length
Authenticator(16个字节)
Attribute(长度不固定)

Code：长度为1个字节，用来说明RADIUS报文的类型。不同RADIUS报文的Code值不相同。例如，Code为1时表示Access-Request报文，Code为2时表示Access-Accept报文。
Identifier：长度为1个字节，用来匹配请求报文和响应报文，以及检测在一段时间内重发的请求报文。RADIUS客户端发送请求报文后，RADIUS服务器返回的响应报文中的Identifier值应与请求报文中的Identifier值相同。
Length：长度为2个字节，用来指定RADIUS报文的长度。超过Length取值的字节将作为填充字符而忽略。如果接收到的报文的实际长度小于Length的取值，则该报文会被丢弃。
Authenticator：长度为16个字节，用来验证RADIUS服务器的响应报文，同时还用于用户密码的加密。
Attribute：即RADIUS属性字段，长度不定，为报文的内容主体，用来携带专门的认证、授权和计费信息，提供请求和响应报文的配置细节。Attribute可以包括多个RADIUS属性，每一个RADIUS属性都采用（Type、Length、Value）三元组的结构来表示
类型（Type）：长度为1个字节，取值为1～255，用于表示RADIUS属性的编号。
长度（Length）：长度为1个字节，表示该RADIUS属性（包括类型、长度和属性值）的长度，单位为字节。
属性值（Value）：最大长度为253字节，表示该RADIUS属性的信息，其格式和内容由类型和长度决定

RADIUS报文类型

RADIUS认证报文
报文名称	说明
Access-Request	认证请求报文，是RADIUS报文交互过程中的第一个报文，用来携带用户的认证信息（例如：用户名、密码等）。认证请求报文由RADIUS客户端发送给RADIUS服务器，RADIUS服务器根据该报文中携带的用户信息判断是否允许接入。
Access-Accept	认证接受报文，是RADIUS服务器对RADIUS客户端发送的Access-Request报文的接受响应报文。如果Access-Request报文中的所有属性都可以接受（即认证通过），则发送该类型报文。RADIUS客户端收到此报文后，用户才能认证通过并被赋予相应的权限。
Access-Reject	认证拒绝报文，是RADIUS服务器对RADIUS客户端的Access-Request报文的拒绝响应报文。如果Access-Request报文中的任何一个属性不可接受（即认证失败），则RADIUS服务器返回Access-Reject报文，用户认证失败。
Access-Challenge	认证挑战报文。EAP中继认证时，RADIUS服务器接收到Access-Request报文中携带的用户名信息后，会随机生成一个MD5挑战字，同时将此挑战字通过Access-Challenge报文发送给用户。用户使用该挑战字对用户密码进行加密处理后，将新的用户密码信息通过Access-Request报文发送给RADIUS服务器。 RADIUS服务器将收到的已加密的密码信息和本地经过加密运算后的密码信息进行对比，如果相同，则该用户为合法用户。

RADIUS计费报文
报文名称	说明
Accounting-Request(Start)	计费开始请求报文。如果RADIUS客户端使用RADIUS模式进行计费，RADIUS客户端会在用户开始访问网络资源时，向RADIUS服务器发送计费开始请求报文。
Accounting-Response(Start)	计费开始响应报文。RADIUS服务器接收并成功记录计费开始请求报文后，需要回应一个计费开始响应报文。
Accounting-Request(Interim-update)	实时计费请求报文。为避免RADIUS服务器无法收到计费结束请求报文而继续对该用户计费，可以在RADIUS客户端上配置实时计费功能。RADIUS客户端定时向RADIUS服务器发送实时计费请求报文，减少计费误差。
Accounting-Response(Interim-update)	实时计费响应报文。RADIUS服务器接收并成功记录实时计费请求报文后，需要回应一个实时计费响应报文。
Accounting-Request(Stop)	计费结束请求报文。当用户断开连接时（连接也可以由NAS断开），RADIUS客户端向RADIUS服务器发送计费结束请求报文，其中包括用户上网所使用的网络资源的统计信息（上网时长、进/出的字节数等），请求RADIUS服务器停止计费。
Accounting-Response(Stop)	计费结束响应报文。RADIUS服务器接收计费停止请求报文后，需要回应一个计费停止响应报文。

RADIUS动态授权和强制下线报文
报文名称	说明
CoA-Request	动态授权请求报文。当管理员需要更改某个在线用户的权限时（例如，管理员不希望用户访问某个网站），可以通过RADIUS服务器发送一个动态授权请求报文给RADIUS客户端，使RADIUS客户端修改在线用户的权限。
CoA-ACK	动态授权请求接受报文。如果RADIUS客户端成功更改了用户的权限，则RADIUS客户端回应动态授权请求接受报文给RADIUS服务器。
CoA-NAK	动态授权请求拒绝报文。如果RADIUS客户端未成功更改用户的权限，则RADIUS客户端回应动态授权请求拒绝报文给RADIUS服务器。
DM-Request	用户离线请求报文。当管理员需要让某个在线的用户下线时，可以通过RADIUS服务器发送一个用户离线请求报文给RADIUS客户端，使RADIUS客户端终结用户的连接。
DM-ACK	用户离线请求接受报文。如果RADIUS客户端已经切断了用户的连接，则RADIUS客户端回应用户离线请求接受报文给RADIUS服务器。
DM-NAK	用户离线请求拒绝报文。如果RADIUS客户端无法切断用户的连接，则RADIUS客户端回应用户离线请求拒绝报文给RADIUS服务器。

CoA（Change of Authorization）是指用户认证成功后，管理员可以通过RADIUS协议来修改在线用户的权限或对其进行重认证。

DM（Disconnect Message）是指用户下线报文，即由RADIUS服务器主动发起的强制用户下线的报文。

3、 RADIUS认证、授权、计费流程

设备作为RADIUS客户端，负责收集用户信息（例如：用户名、密码等），并将这些信息发送到RADIUS服务器。RADIUS服务器则根据这些信息完成用户身份认证以及认证通过后的用户授权和计费。

1、当用户接入网络时，用户发起连接请求，向RADIUS客户端（即设备）发送用户名和密码。

2、RADIUS客户端向RADIUS服务器发送包含用户名和密码信息的认证请求报文。

3、RADIUS服务器对用户身份的合法性进行检验：

如果用户身份合法，RADIUS服务器向RADIUS客户端返回认证接受报文，允许用户进行下一步动作。由于RADIUS协议合并了认证和授权的过程，因此认证接受报文中也包含了用户的授权信息。
如果用户身份不合法，RADIUS服务器向RADIUS客户端返回认证拒绝报文，拒绝用户访问接入网络。

4.RADIUS客户端通知用户认证是否成功。

5.RADIUS客户端根据接收到的认证结果接入/拒绝用户。如果允许用户接入，则RADIUS客户端向RADIUS服务器发送计费开始请求报文。

6.RADIUS服务器返回计费开始响应报文，并开始计费。

7.用户开始访问网络资源。

8.（可选）在使能实时计费功能的情况下，RADIUS客户端会定时向RADIUS服务器发送实时计费请求报文，以避免因付费用户异常下线导致的不合理计费。

9.（可选）RADIUS服务器返回实时计费响应报文，并实时计费。

10.用户发起下线请求，请求停止访问网络资源。

11.RADIUS客户端向RADIUS服务器提交计费结束请求报文。

12.RADIUS服务器返回计费结束响应报文，并停止计费。

13.RADUS客户端通知用户访问结束，用户结束访问网络资源

4、RADIUS报文重传机制

用户认证过程中，设备会发送认证请求报文到RADIUS服务器。为避免由于网络故障、时延等原因导致设备无法收到服务器的回应报文，设备在发送认证请求报文到服务器时具有超时重传超时机制，重传次数和重传间隔通过定时器进行控制。

满足以下任意一个条件，设备停止重传：

RADIUS报文重传是针对一个服务器而言的，如果RADIUS服务器模板或者组中配置有多个服务器，整体重传时间取决于重传间隔、重传次数、RADIUS服务器的状态、服务器的个数以及选择服务器的算法。

5、RADIUS服务器选择机制

大型企业网络中通常会部署多台RADIUS服务器，这样做的目的一是为了在一台服务器故障的情况下，不会影响用户接入；二是为了在大量用户接入时，多个服务器之间能够负载均衡，单个服务器的资源不会被耗尽。当RADIUS服务器模板中配置了多个服务器，设备在向服务器发送报文时，根据命令行的配置通过以下其中一种机制选择RADIUS服务器：

RADIUS服务器主备算法（缺省配置）
RADIUS服务器负载均衡算法

另外，RADIUS服务器的运算法则可以配置为基于单个用户的也可以配置为基于报文的。如果配置为基于单个用户的运算法则，认证阶段会保存认证服务器的信息，如果认证服务器同时也是计费服务器，则计费阶段优先向该服务器发送计费请求；如果配置为基于报文的运算法则，认证阶段不会保存认证服务器的信息，在计费阶段会重新选择计费服务器，可能存在同一个用户的认证和计费不在同一个服务器上的问题。

RADIUS服务器主备算法

主备顺序根据配置RADIUS认证服务器或RADIUS计费服务器时的权重决定，权重值较大者为主，如果权重值相同，则先配置的服务器为主。

在所有状态为Up的服务器中，优先向主服务器发送认证或计费报文，如果主服务器没有回应，则向备服务器发送。

RADIUS服务器负载均衡算法

选择负载均衡算法后，设备在向服务器发送认证或计费报文时，会根据配置RADIUS认证服务器或RADIUS计费服务器时的权重来分配报文发送的服务器。

RADIUS服务器1的状态为Up、权重为80，RADIUS服务器2的状态为Up、权重为20。则设备向RADIUS服务器1发送报文的概率为80/（80+20）=80%，设备向RADIUS服务器2发送报文的概率20/（80+20）=20%。

如果设备在发送报文的过程中，所有状态为Up的服务器均没有回应，此后，设备在原先为Down状态的服务器（此前没有向这部分服务器发送认证或计费报文）中，按照权重值，再发送一次报文。如果设备没有收到任何服务器的回应报文，则跳转到备份认证方式，比如本地认证。备份方式需要在认证方案中配置，如果未配置，则本次认证流程结束。

6、RADIUS服务器状态探测

RADIUS服务器的可用性和可维护性是用户接入认证的基本条件，当设备与RADIUS服务器之间无法通信时，RADIUS服务器不能对用户进行认证和授权。为了解决该问题，设备支持在RADIUS服务器Down时的用户逃生功能，即RADIUS服务器Down后，用户无法获取服务器授权时，仍能够具有一定的网络访问权限。

但是，RADIUS服务器Down时的用户逃生功能必须在设备将RADIUS服务器的状态标记为Down后才能启用。如果RADIUS服务器的状态没有标记为Down、设备又不能与RADIUS服务器正常通信，这会导致用户既获取不到服务器授权也不能进行逃生，进而造成用户没有任何网络访问权限。所以，设备必须及时感知到RADIUS服务器的状态，在RADIUS服务器状态为Down时，使用户能够获取逃生权限；在RADIUS服务器状态恢复Up后，用户退出逃生权限，进行重认证。

RADIUS服务器的状态

状态	RADIUS服务器是否可用	出现该状态的场景
Up	RADIUS服务器可用	RADIUS服务器的初始状态设备收到RADIUS服务器的报文
Down	RADIUS服务器不可用	满足将RADIUS服务器的状态标记为Down的条件
Force-up(强制Up)	在没有可用的RADIUS服务器时，会选择Force-up状态的服务器	dead-time定时器超时

RADIUS服务器的初始状态被标记为Up。

将RADIUS服务器的状态标记为Down的条件:

能否将一个RADIUS服务器的状态标记为Down，与以下因素有关：

RADIUS服务器最大无响应时长（max-unresponsive-interval的取值）
RADIUS请求报文发送的次数
RADIUS请求报文发送的时间间隔
RADIUS服务器的探测周期
RADIUS服务器探测周期循环次数
RADIUS服务器在每个探测周期内连续无响应最大次数

将RADIUS服务器的状态标记为Down的条件分为两种，只要满足其中一种，RADIUS服务器的状态就会被标记为Down。

1、在RADIUS服务器状态探测过程中，将RADIUS服务器标记为Down状态。

系统启动后，RADIUS服务器状态探测定时器开始运行。从设备发送第一个RADIUS认证请求报文开始计算，如果设备一直没有收到RADIUS服务器的报文，并且在一个探测周期内满足条件：未收到RADIUS服务器报文的次数（n）大于或等于连续无响应的最大次数（dead-count），则记录一次通讯中断。在持续没有收到RADIUS服务器报文的情况下，探测周期循环几次，就在第几次记录通讯中断时将RADIUS服务器标记为Down。

2、将长时间无响应的RADIUS服务器标记为Down状态。

在用户接入频率较低、设备收到用户认证请求报文较少、RADIUS服务器状态探测过程中将RADIUS服务器标记为Down的条件无法满足的情况下，连续两个无响应的认证请求报文的时间间隔大于max-unresponsive-interval时，RADIUS服务器被标记为Down，此机制能够确保用户获取逃生授权。

自动探测

RADIUS服务器的状态被标记为Down后，通过自动探测功能可以检测RADIUS服务器的可达性。

自动探测功能需要手动开启。开启自动状态探测功能只需在设备的RADIUS服务器模板视图下配置自动探测用户名和密码，在RADIUS服务器上不需要配置此自动探测用户名和密码。认证无需成功，设备能收到认证失败响应报文就能证明RADIUS服务器是正常工作的。

服务器的状态	是否支持自动探	何时发送自动探测报文	服务器状态切换的条件
down状态	缺省支持	自动探测周期过后发送	在探测报文的超时等待时间内，如果设备收到了RADIUS服务器的报文，会将RADIUS服务器的状态标记为Up；反之，则保持RADIUS服务器的状态为Down。
Up状态	通过命令行 radius-server detect-server up-server interval开启	自动探测周期过后发送	满足将RADIUS服务器的状态标记为Down的条件，则将RADIUS服务器的状态标记为Down；反之，则保持RADIUS服务器的状态为Up。
Force-up状态	缺省支持	立即发送	在超时等待时间内，如果收到RADIUS服务器的报文，设备会将RADIUS服务器的状态标记为Up；反之，则将RADIUS服务器的状态标记为Down.

7、RADIUS CoA/DM-动态修改在线用户权限/强制用户下线

RADIUS服务器根据业务信息，向设备发送CoA-Request报文，请求更改用户的授权信息。该报文中可以包括ACL规则等授权。

1、设备收到CoA-Request报文后，与设备上的用户信息匹配来识别用户。如果匹配成功，则更改用户的授权信息；如果匹配失败，则保持用户原有授权信息。

2、设备回应CoA-ACK/NAK报文。

如果更改成功，则设备向RADIUS服务器回应CoA-ACK报文。
如果更改失败，则设备向RADIUS服务器回应CoA-NAK报文。

1、管理员在RADIUS服务器上强制用户下线，RADIUS服务器向设备发送DM-Request报文，请求用户下线。

2、设备收到DM-Request报文后，与设备上的用户信息匹配来识别用户。如果匹配成功，则通知用户下线；如果匹配失败，则用户保持在线。

3、设备回应DM-ACK/NAK报文。

如果用户成功下线，设备给RADIUS服务器回应DM-ACK报文。
如果用户未下线，设备给RADIUS服务器回应DM-NAK报文。

与用户上线授权或用户主动下线过程相比，CoA/DM的特点是请求报文是由服务器发送的，回应报文是由设备发送的，成功则回应ACK报文、失败则回应NAK报文。

8、会话识别

设备接收到RADIUS服务器的CoA-Request报文或者DM-Request报文后，根据报文中的某些RADIUS属性来识别用户。用来识别用户的RADIUS属性包括：

RADIUS标准属性：User-Name（1）
RADIUS标准属性：Acct-Session-ID（44）
RADIUS标准属性：Framed-IP-Address（8）
RADIUS标准属性：Calling-Station-Id（31）

RADIUS服务器的CoA-Request报文或DM-Request报文与设备上的用户信息匹配失败时，设备会在回应的CoA-NAK报文或DM-NAK报文中通过错误码描述失败的原因。

四、TACACS+协议

1、TACACS+报文头：

Tacscs+报文头字端解释：

major_version: TACACS协议主版本号，当前版本号为0xc

TAC_PLUS_MAJOR_VER := 0xc

minor_version: Tacscs协议次版本号，当前版本号为0x0.

TAC_PLUS_MINOR_VER_DEFAULT := 0x0;
TAC_PLUS_MINOR_VER_ONE := 0x1

type：Tacacs协议报文类型，包括认证（0x01）、授权（0x02）和计费（0x03）。

TAC_PLUS_AUTHEN := 0x01 (Authentication)
TAC_PLUS_AUTHOR := 0x02 (Authorization)
TAC_PLUS_ACCT := 0x03 (Accounting)

seq_no: 这是当前数据包的序列号。会话中的第一个包必须具有序列号1，随后的每个包将增加序列号1。TACACS+客户端只发送包含奇数序列号的数据包，而TACACS+服务器只发送包含偶数序列号的数据包。

序列号永远不能换行，也就是说，如果达到序列号2^8-1，该会话必须终止并以序列号1重新启动

flags : 此字段包含各种位图标志。

TAC_PLUS_UNENCRYPTED_FLAG := 0x01

报文主体加密标记，0表示对报文主体加密，1表示不对报文主体加密。

The single-connection flag:

TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04

此标志用于允许客户端和服务器协商单一连接模式。

读取时必须忽略所有其他位，写入时应设置为零。

session_id: 会话ID，当前会话的唯一标识。

此TACACS+会话的Id。此字段在TACACS+会议期间不会更改。此数字必须由加密的强随机数生成方法生成。如果不这样做，将危及会话的安全性。

length: TACACS报文主体的长度，不包括报文头。

2、 Tacscs+加密处理：

TACACS+支持除包头之外所有信息的加密，加密方法如下：

1、将session_id、secret key, 版本号和sequence number一起进行MD5运算（其中secret key 为TACACS客户端和服务器之间的共享秘密），计算结果为MD5_1

2、后续的MD5运算将上次MD5运算的结果也纳入运算范围，如下：

MD5_1 = MD5{session_id, key, version, seq_no}

MD5_2 = MD5{session_id, key, version, seq_no, MD5_1}

....

MD5_n = MD5{session_id, key, version, seq_no, MD5_n-1}

3、将所有的运算结果连接起来，直到总长度大于需要加密的数据的长度，然后截断到实际数据的长度，得到pseudo_pad：

pseudo_pad = {MD5_1 [,MD5_2 [ ... ,MD5_n]]} truncated to len(data)

4、随后将需要加密的数据和上面的pseudo_pad进行XOR运算，得到密文：

ENCRYPTED {data} == data ^ pseudo_pad

由于TACACS+对整个数据包进行加密，私密性要好于RADIUS，窃听者无法根据报文的内容来猜测网络的配置和用户的身份。

3、TACACS+报文的类型：

TACACS+共有7种类型的消息报文：

1、Authentication_START-认证开始报文

认证开始时，客户端发送START消息，START消息中包括认证类型，同时可能包括用户名和一些认证数据。

START消息一般来说是认证过程的第一个数据包，其seq_no总是1。

如果收到RESTART消息，客户端需要发送START消息重新开始认证（使用一个新的会话）。

Server发送REPLY消息来回应START消息，表示认证结束或者仍需要继续。

报文头type字段：TAC_PLUS_AUTHEN := 0x01 (Authentication)

字段解释：

Action字段表示具体的认证操作，如认证请求、上传密码等等。

priv_lvl字段表示用户的权限级别。

authen_type字段表示认证的类型，如PAP、CHAP等。

Service字段表示服务类型。

user字段表示用户名，该字段不一定在START消息中存在。

port字段表示客户端上发生认证行为的端口，具体取值客户端可以自行定义，没有明确的要求。

rem_addr字段表示用户的地址信息，属于可选字段，一般使用客户端IP地址、ISDN Caller ID等填充。

data字段用于针对action和authen_type字段的值来传递一些信息。

action : 具体的认证动作:

TAC PLUS AUTHEN LOGIN := 0x01
TAC_PLUS_AUTHEN_CHPASS := 0x02
TAC PLUS AUTHEN SENDAUTH := 0x04

priv_lvl: 用户的权限级别。

authen_type: 认证的类型:

TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01
TAC_PLUS_AUTHEN_TYPE_PAP := 0x02
TAC_PLUS_AUTHEN_TYPE_CHAP := 0x03
TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0X05
TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0X06

authen_service: 请求认证的服务类型

#TAC_PLUS_AUTHEN_SVC_NONE选项用于该字段的授权应用程序,它表示设备没有执行任何认证。

TAC_PLUS_AUTHEN_SVC_NONE := 0x00

#TAC_PLUS_AUTHEN_SVC_LOGIN选项表示客户端设备的常规登录(而不是ENABLE)。

TAC_PLUS_AUTHEN_SVC_LOGIN := 0x01

#TAC_PLUS_AUTHEN_SVC_ENABLE选项标识ENABLE authen_service,这是指请求身份验证以授予用户不同权限的服务

TAC_PLUS_AUTHEN_SVC_ENABLE := 0x02

#其他选项还包括了1egacy/backwards兼容性。

TAC_PLUS_AUTHEN_SVC_PPP := 0x03
TAC_PLUS_AUTHEN_SVC_PT := 0X05
TAC_PLUS_AUTHEN_SVC_RCMD := 0x06
TAC_PLUS_AUTHEN_SVC_X25 := 0x07
TAC_PLUS_AUTHEN_SVC_NASI := 0x08
TAC_PLUS_AUTHEN_SVC_FWPROXY := 0x09

user, user_len: 用户名在此数据包中是可选的，具体取决于认证方式。如果不存在，则客户端必须将user_len设置为0。如果存在用户名，user_len以字节表示user字段的长度。

port, port_len: 请求认证的用户接口名，最大长度为47。对于管理员用户，该字段是指用户终端接口（例如“console0”、“vty1”等）。例如，Telnet用户的authen_type为ASCII，service为LOGIN，port为vtyx。对于其他用户，该字段是指用户接入的接口名称。

rem_addr, rem_addr_len :登录用户的IP地址。 rem_addr字段的长度.字节为单位。

当TACACS+用于拨号（dial-up）服务时，该值包含调用者ID。

当TACACS+用于设备管理时，用户通常通过网络连接，在这种情况下，该值用于保存网络地址，IPv4或IPv6。

data, data_len: 认证数据区，根据action和authen_type的不同封装不同的数据。例如PAP认证时，该字段内容为PAP显示密码。

data_len,以字节表示认证数据区的长度。

2、Authentication_CONTIUNE-认证持续报文

客户端收到REPLY消息后，如果确认认证过程没有结束，使用CONTINUE消息应答。

报文头type字段：TAC_PLUS_AUTHEN := 0x01 (Authentication)

字段解释：

user_msg字段用于回应REPLY消息中的server_msg字段，向服务器提供客户端或用户的一些信息

flags字段用于中断认证过程

在收到服务器的应答包后，此报文从客户机发送到服务器。

user_msg, user_msg_len :

登录用户输入的字符串，用于回应认证回应报文中的server_msg字段，向服务器提供用户登录时输入的密码。

user_len表示用户字段的长度，以字节为单位。

data, data_len: 认证数据区，根据action和authen_type的不同封装不同的数据。例如PAP认证时，该字段内容为PAP显示密码。它不是一种可打印的文本编码。data_len表示数据字段的长度，以字节为单位。

flags: 认证持续标记，0表示认证过程持续，1表示认证过程终止。

TAC_PLUS_CONTINUE_FLAG_ABORT := 0X01

3、Authentication_REPLY-认证回应报文

REPLY消息是TACACS+服务器向客户端发送的唯一一种Authentication 消息，用于向客户端反馈当前认证的状态。

报文头type字段：TAC_PLUS_AUTHEN := 0x01 (Authentication)

字段解释：

Status字段表示认证的状态。

flags字段用于控制客户端是否将用户输入的密码回显，如果该标志位置1，用户输入的密码不会回显。

server_msg字段为可选字段，用于服务器将一些附加信息带给用户。

data字段用于向客户端（NAS）提供一些信息。

TACACS+服务器只向客户端发送一种类型的认证包(REPLY包)。

status : 认证的状态

TAC_PLUS_AUTHEN_STATUS_PASS:= 0x01#认证成功PASS(0x01)
TAC_PLUS_AUTHEN_STATUS_FAIL:=0x02 #认证失败FAIL(0x02)
TAC_PLUS_AUTHEN_STATUS_GETDATA：=0X03#请求用户信息GETDATA(0x03)
TAC_PLUS_AUTHEN_STATUS_GETUSER:=0x04#请求用户名GETUSER(0x04)
TAC_PLUS_AUTHEN_STATUS_GETPASS:=0x05 #请求密码GETPASS(0x05)
TAC_PLUS_AUTHEN_STATUS_RESTART :=0X06 #请求重新发起认证开始RESTART(0X06)
TAC_PLUS_AUTHEN_STATUS_ERROR:=0x07#服务器收到认证报文有误ERROR(0x07)
TAC_PLUS_AUTHEN_STATUS_FOLLOW:=0X21#服务器要求重新进行认证过程FOLLOW(0X21)

flags: 位图标志，用于修改要执行的操作。

#空制客户端是否将用户输入的密码回显。如果该标志位置1，则用户输入的密码不会回显。

TAC PLUS REPLY FLAG NOECHO := 0x01

server_msg, server_msg_len : 要显示给用户的消息。该字段是可选的。server_msg_len表示server_msg字段的长度，以字节为单位。

data, data_len : 认证数据区，用于向客户端提供一些信息。此字段保存身份验证交换的一部分数据，用于客户端处理，而不是用户。它不是一种可打印的文本编码。

data_len表示数据字段的长度，以字节为单位

认证过程：

The action、authen_type和authen_service字段(如上所述)组合起来表示要执行的认证类型。每个认证START, REPLY and CONTIUNE都包含一个数据字段。该字段的使用取决于认证的类型。

minor_version=0的情形：

1、所有授权和计费都使用minor_version数字0。

2、type：认证（0x01）且authen_type: 认证的类型=ASCII。

TAC_PLUS_AUTHEN_TYPE_ASCII := 0x01

minor_version=1的情形：

type：认证（0x01）且

authen_type: 认证的类型。
TAC_PLUS_AUTHEN_TYPE_PAP := 0x02
TAC_PLUS_AUTHEN_TYPE_CHAP :=0x03
TAC_PLUS_AUTHEN_TYPE_MSCHAP := 0x05
TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 := 0x06

eg:

1. ASCII Login：

action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII
minor version = 0x0

2. PAP Login：

action = TAC PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_PAP
minor_version = 0x1

3. CHAP login:

action = TAC PLUS AUTHEN_LOGIN
authen_type =TAC_PLUS_AUTHEN_TYPE_CHAP
minor_version =0x1

4. MS-CHAP v1 login：

action = TAC PLUS_ AUTHEN LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAP
minor_version = 0x1

5. MS-CHAP v2 login：

action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_MSCHAPV2
minor version = 0x1

6. Enable Requests:

action = TAC_PLUS_AUTHEN_LOGIN
priv_lvl = implementation dependent
authen_type = not used
service = TAC_PLUS_AUTHEN_SVC_ENABLE

7. ASCII change passwrod requests:

action = TAC_PLUS_AUTHEN_CHPASS
authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII

4、Authorization_REQUEST-授权请求报文

在TACACS+协议中，授权始终是一对消息:来自客户机的REQUEST和来自服务器的REPLY。

Authorization Request消息的结构比较复杂

字段解释：

Authorization Request消息中包括了授权所需的一切信息，这些信息分为两类，一类是必选的，另一类是可选的。

其中，authen_method字段表示授权的方式，TACACS+的认证和授权是分离的，用户可以使用TACACS+认证而使用其它协议进行授权。

priv_lvl字段、authen_type字段、authen_service字段、port字段、rem_addr字段的含义和authentication消息中的相应字段一样。

user字段表示用户名。

arg_cnt字段表示REQUEST消息中携带的argument的数量， argument是一个AVP的结构，其中attribute和value之间使用等号（=）或星号（*）连接，当使用等号连接时表示该AVP是必选的，使用星号连接时表示该AVP是可选的。

authen_method : 该字段允许客户端指定获取用户信息所使用的认证方式。

TAC_PLUS_AUTHEN_METH_NOT_SET:=0x00 #没有设置认证方式
TAC_PLUS_AUTHEN_METH_NONE:=0x01 #不认证
TAC_PLUS_AUTHEN_METH_KRB5 := 0x02 #KRB5认证
TAC_PLUS_AUTHEN_METH_LINE:=0x03#固定密码认证
TAC_PLUS_AUTHEN_METH_ENABLE :=0x04 #通过认证来授予特权命令
TAC_PLUS_AUTHEN_METH_LOCAL:=0x05 #客户端本地认证
TAC_PLUS_AUTHEN_METH_TACACSPLUS:=0x06#Tacacs+服务器认证
TAC_PLUS_AUTHEN_METH_GUEST:=0x08 #访客认证
TAC_PLUS_AUTHEN_METH_RADIUS:=0x10 #Radius服务器认证
TAC_PLUS_AUTHEN_METH_KRB4 := 0x11 # Kerberos 4认证
TAC_PLUS_AUTHEN_METH_RCMD := 0x20

priv_lvl : 此字段的使用方式与认证请求中的priv_lvl字段相同，它表示用户当前的特权级别。

authen_type : 这个字段对应于上面的认证部分中的authen_type字段。它指示所执行的身份验证类型。如果此信息不可用，那么客户端将把authen_type设置为:TAC_PLUS_AUTHEN_TYPE_NOT_SET:= 0x00。此值仅在授权和计费请求中有效。

authen_service: 认证服务类型。
arg_cnt : 授权请求报文中携带的属性数。
arg_1 … argN : 指定授权请求报文的属性。

5、Authorization_RESPONSE-授权回应报文

字段解释：

Response消息中包括了授权的结果和一些其它的参数

status字段表示授权的结果和权限的操作方式

server_msg字段是服务器给用户的提示信息。

data字段是服务器提供给管理员的信息。

arg_cnt字段表示RESPONSE消息中携带的argument的数量，argument的格式和REQUEST消息中相同

status : 指定用户的授权状态，包括：

TAC_PLUS_AUTHOR_STATUS_PASS_ADD:=0x01 #授权通过
TAC_PLUS_AUTHOR_STATUS_PASS_REPL:=0X02#授权请求报文中的属性被TACACS服务器修改
TAC_PLUS_AUTHOR_STATUS_FAIL:=0x10#授权失败
TAC_PLUS_AUTHOR_STATUS_ERROR :=0x11#授权服务器上出现了错误
TAC_PLUS_AUTHOR_STATUS_FOLLOW:=0x21#重新指定授权服务器

arg_cnt: 授权回应报文中携带的授权属性数。

argN : 这些属性描述了所请求的授权的细节。

6、Accounting_REQUEST-计费请求报文

字段解释：

Accounting Request消息中包括了计费所需的信息。

flags字段表示计费报文的类型，包括计费开始。计费停止和实时计费。

其它字段的含义和与authorization和authentication中对应字段的含义一致，这里不再赘述。

Accounting REQUEST消息中也可以携带很多AVP形式的参数，参数的数量很多，这里就不一一列举了。

data字段是服务器提供给管理员的信息。

flags: 计费类型。

TAC_PLUS_ACCT_FLAG_START:=0x02 #开始计费
TAC_PLUS_ACCT_FLAG_STOP:=0x04#结束计费
TAC_PLUS_ACCT_FLAG_WATCHDOG:=0x08 #实时计费

7、Accounting_REPLY-计费回应报文

字段解释：

其中status字段表示计费的状态，标志计费是否成功。

server_msg字段表示服务器发给用户的信息，由客户端来决定是否显示给用户。

Status: 指定计费状态：

TAC_PLUS_ACCT_STATUS_SUCCESS:=0x01 #计费成功
TAC_PLUS_ACCT_STATUS_ERROR:=0x02 #计费失败
TAC_PLUS_ACCT_STATUS_FOLLOW:=0x21#重新进行计费过程

TACACS+认证过程

ACACS+认证的工作过程取决于START消息中的action和authen_type字段的取值。

不同的action和authen_type字段的组合需要配合不同的priv_lvl、service、port和rem_addr字段，实现不同的业务。

TACACS+协议中目前描述了13个action和authen_type字段的组合，这里列出几个比较常见的组合：

1、Enable Requests:通常用于提升当前用户的级别的场合，比如Linux系统的su命令

Action = TAC_PLUS_AUTHEN_LOGIN
priv_lvl = implementation dependent
authen_type = not used
service = TAC_PLUS_AUTHEN_SVC_ENABLE

2、Inbound ASCII Login:管理用户login的场景

action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII

3、Inbound CHAP login :CHAP认证，最常见的是PPP认证的场景，整个交互过程包括一个START和一个REPLY消息，START消息中必须包含用户名。

Action = TAC_PLUS_AUTHEN_LOGIN
authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP
minor_version = 0x1

具体认证过程:

认证过程的中止

客户端可以通过在CONTINUE消息中携带一个TAC_PLUS_CONTINUE_FLAG_ABORT标志位来中止正在进行的认证过程，同时可以在data字段携带中止认证的原因。该CONTINUE消息不需要REPLY消息的回应。

具体授权过程:

具体计费过程:

报文类型总结：

3种认证报文：

认证开始报文（Authentication Start）认证开始时，客户端向服务器发送认证开始报文，该报文中包括认证类型，同时可能包括用户名和一些认证数据。

认证持续报文（Authentication Continue）：客户端接收到服务器回应的认证回应报文后，如果确认认证过程没有结束，则使用认证持续报文响应

认证回应报文（Authentication Reply）：服务器接收到客户端发送的认证开始报文或认证持续报文后，向客户端发送的唯一一种认证报文，用于向客户端反馈当前认证的状态。

2种授权报文：

授权请求报文（Authorization Request）：TACACS的认证和授权是分离的，用户可以使用TACACS认证而使用其他协议进行授权。如果需要通过TACACS进行授权，则客户端向服务器发送授权请求报文，该报文中包括了授权所需的一切信息。

授权回应报文（Authorization Response）服务器接收到授权请求报文后，向客户端发送授权回应报文，该报文中包括了授权的结果

2种计费报文：

计费请求报文(Accounting Request）：该报文中包括了计费所需的信息。

计费回应报文(Accounting Response）：服务器接收并成功记录计费请求报文后，需要回应一个计费响应报文。

TACACS+认证、授权、计费流程

五、HWTACACS协议

华为终端访问控制器控制系统协议HWTACACS是在TACACS（RFC 1492）基础上进行了功能增强的安全协议。

HWTACACS是一种集中式的、客户端/服务器结构的信息交互协议，使用TCP协议传输，TCP端口号为49。

HWTACACS提供的认证、授权和计费服务相互独立，能够在不同的服务器上实现。

HWTACACS兼容Cisco的TACACS+协议，华为交换机作为HWTACACS客户端可以和TACACS+服务器对接实现AAA功能。

HWTACACS协议主要用于采用点对点协议PPP（Point-to-Point Protocol）或虚拟私有拨号网络VPDN（Virtual Private Dial-up Network）方式接入Internet的接入用户以及对设备进行操作的管理用户的认证、授权和计费。

项目	HWTACACS	RADIUS
数据传输	通过TCP传输，网络传输更可靠。	通过UDP传输，网络传输效率更高。
加密方式	除了标准的HWTACACS报文头，对报文主体全部进行加密。	只是对认证报文中的密码字段进行加密。
认证和授权	认证与授权分离，使得认证、授权服务可以在不同的安全服务器上实现。例如，可以用一台HWTACACS服务器进行认证，另外一台HWTACACS服务器进行授权。	认证与授权结合，不能分离。
命令行授权	支持对设备上的配置命令进行授权使用。即用户可使用的命令行受到命令级别和AAA授权的双重限制，某一级别的用户输入的每一条命令都需要通过HWTACACS服务器授权，如果授权通过，命令才可以被执行。	不支持对设备上的配置命令进行授权使用。用户登录设备后可以使用的命令行由用户级别决定，用户只能使用级别等于或低于用户级别的命令行。
应用场景	适于进行安全控制。	适用于计费

1、 HWTACACS报文介绍

HWTACACS报文与RADIUS报文的格式不同。所有RADIUS报文均采用相同的报文格式，而HWTACACS报文除了具有相同的报文头之外，认证、授权和计费报文的格式均不同。

HWTACACS报文头

字段解释：

字段	含义
major version	HWTACACS协议主版本号，当前版本号为0xc。
minor version	HWTACACS协议次版本号，当前版本号为0x0。
type	HWTACACS协议报文类型，包括认证（0x01）、授权（0x02）和计费（0x03）。
seq_no	对于同一个会话，当前报文的序列号，取值范围为1～254
flags	报文主体加密标记，目前只支持8位中的第1位，0表示对报文主体加密，1表示不对报文主体加密。
session_id	会话ID，当前会话的唯一标识。
length	HWTACACS报文主体的长度，不包括报文头。

HWTACACS认证报文

HWTACACS认证报文包括三种类型：

认证开始报文Authentication Start：认证开始时，客户端向服务器发送认证开始报文，该报文中包括认证类型、用户名和一些认证数据。
认证持续报文authentication Continue：客户端接收到服务器回应的认证回应报文后，如果确认认证过程没有结束，则使用认证持续报文响应。
认证响应报文Authentication Reply：服务器接收到客户端发送的认证开始报文或认证持续报文后，向客户端发送的唯一一种认证报文，用于向客户端反馈当前认证的状态。

HWTACACS认证开始报文

字段解释：

字段	含义
action	具体的认证操作，目前只支持“认证登录（0x01）”。
priv_lvl	用户级别，取值范围是0～15。
authen_type	认证的类型，目前设备仅支持： CHAP（0x03） PAP（0x02） ASCII（0x01）
ervice	请求认证的服务类型，当前版本支持PPP（0x03）、LOGIN（0x01）、ENABLE（0x02）、NONE（0x00）四种服务类型，分别对应PPP用户、管理员用户、管理员用户级别提升认证和其他用户。
user len	登录用户输入的用户名长度。
port len	port字段的长度。
rem_addr len	rem_addr字段的长度。
data len	认证数据区的长度。
user	请求认证的用户名，最大长度为129。
port	请求认证的用户接口名，最大长度为47。对于管理员用户，该字段是指用户终端接口（例如“console0”、“vty1”等）。例如，Telnet用户的authen_type为ASCII，service为LOGIN，port为vtyx。对于其他用户，该字段是指用户接入的接口名称。
rem_addr	登录用户的IP地址。
data	认证数据区，根据action和authen_type的不同封装不同的数据。例如PAP认证时，该字段内容为PAP显式密码。

HWTACACS认证持续报文

字段解释：

字段	含义
user_msg len	登录用户输入的字符串长度。
data len	认证数据区的长度。
flags	认证持续标记，0表示认证过程持续，1表示认证过程终止。
user_msg	登录用户输入的字符串，用于回应认证回应报文中的server_msg字段，向服务器提供用户登录时输入的密码。
data	认证数据区，根据action和authen_type的不同封装不同的数据。例如PAP认证时，该字段内容为PAP显式密码。

HWTACACS认证回应报文

字段解释：

字段	含义
status	认证的状态，包括：认证成功PASS（0x01）认证失败FAIL（0x02）请求用户信息GETDATA（0x03）请求用户名GETUSER（0x04）请求密码GETPASS（0x05）请求重新发起认证开始RESTART（0x06）服务器收到认证报文有误ERROR（0x07）服务器要求重新进行认证过程FOLLOW（0x21）
flags	控制客户端是否将用户输入的密码回显。如果该标志位置1，则用户输入的密码不会回显。
server_msg len	server_msg字段的长度。
data len	认证数据区的长度。
server_msg	可选字段，用于服务器将一些附加信息带给用户。
data	认证数据区，用于向客户端提供一些信息。

HWTACACS授权报文

HWTACACS授权报文包括两种类型：

授权请求报文Authorization Request：HWTACACS的认证和授权是分离的，用户可以使用HWTACACS认证而使用其他协议进行授权。如果需要通过HWTACACS进行授权，则客户端向服务器发送授权请求报文，该报文中包括了授权所需的一切信息。
授权响应报文authorization Response：服务器接收到授权请求报文后，向客户端发送授权回应报文，该报文中包括了授权的结果。

HWTACACS授权请求报文

字段解释：

字段	含义
authen_method	指定用户的认证方式，包括：没有设置认证方式（0x00）不认证（0x01）本地认证（0x05） HWTACACS认证（0x06） RADIUS认证（0x10）
authen_service	请求认证的服务类型，当前版本支持PPP（0x03）、LOGIN（0x01）和NONE（0x00）三种服务类型，分别对应PPP用户、管理员用户和其他用户。
arg_cnt	授权请求报文中携带的属性数。
argN	指定授权请求报文的属性。包括： cmd：请求授权的命令行的第一个参数。 cmd-arg：请求授权的命令行参数。固定格式为“cmd-arg=命令行参数”，最后一个命令行参数后需要再封装一个“cmd-arg=<cr>”结尾。“cmd-arg=命令行参数”的总长度不能超过255个字节，每个命令行参数不能超过247个字节。
priv_lvl字段、authen_type字段、authen_service字段、user len字段、port len字段、rem_addr len字段、port字段、rem_addr字段的含义和HWTACACS认证开始报文一致

HWTACACS授权回应报文

字段解释：

字段	含义
status	指定用户的授权状态，包括：授权通过（0x01）授权请求报文中的属性被TACACS服务器修改（0x02）授权失败（0x10）授权服务器上出现了错误（0x11）重新指定授权服务器（0x21）
arg_cnt	授权回应报文中携带的授权属性数。
argN	指定HWTACACS授权服务器下发的授权属性。
server_msg len字段、data len字段和server_msg字段的含义和HWTACACS认证回应报文一致

HWTACACS计费报文

HWTACACS计费报文包括两种类型：

计费请求报文Accounting Request：该报文中包括了计费所需的信息。
计费响应报文Accounting Response：服务器接收并成功记录计费请求报文后，需要回应一个计费响应报文。

HWTACACS计费请求报文

字段解释：

字段	含义
flags	计费类型：开始计费（0x02）结束计费（0x04）实时计费（0x08）
authen_service	请求认证的服务类型，当前版本支持PPP（0x03）、LOGIN（0x01）和NONE（0x00）三种服务类型，分别对应PPP用户、管理员用户和其他用户。
arg_cnt	计费请求报文中携带的属性数。
argN	指定计费请求报文的属性。
authen_method字段、priv_lvl字段、authen_type字段、user len字段、port len字段、rem_addr len字段、port字段、rem_addr字段的含义和HWTACACS授权请求报文一致

HWTACACS计费回应报文

字段解释：

字段	含义
server_msg len	server_msg字段的长度。
data len	data字段的长度。
status	指定计费状态：计费成功（0x01）计费失败（0x02）计费无回应（0x03）服务器要求重新进行计费过程（0x21）
server_msg	指定计费服务器带给客户端的信息。
data	服务器提供给管理员的信息。

2、HWTACACS认证、授权、计费流程

在整个过程中的基本消息交互流程如下：用户telnet登录hwtacacs客户端

1.Telnet用户请求登录设备。

2.HWTACACS客户端收到请求之后，向HWTACACS服务器发送认证开始报文。

3.HWTACACS服务器发送认证回应报文，请求用户名。

4.HWTACACS客户端收到回应报文后，向用户询问用户名。

5.用户输入用户名。

6.HWTACACS客户端收到用户名后，向HWTACACS服务器发送认证持续报文，其中包括了用户名。

7.HWTACACS服务器发送认证回应报文，请求密码。

8.HWTACACS客户端收到认证回应报文，向用户询问密码。

9.用户输入密码。

10.HWTACACS客户端收到密码后，向HWTACACS服务器发送认证持续报文，其中包括了密码信息。

11.HWTACACS服务器发送认证回应报文，指示用户通过认证。

12.HWTACACS客户端向HWTACACS服务器发送授权请求报文。

13.HWTACACS服务器发送授权回应报文，指示用户通过授权。

14.HWTACACS客户端收到授权回应报文，向用户输出设备的配置界面。

15.HWTACACS客户端向HWTACACS服务器发送计费开始请求报文。

16.HWTACACS服务器发送计费开始回应报文，指示计费开始请求报文已经收到。

17.用户请求断开连接。

18.HWTACACS客户端向HWTACACS服务器发送计费结束请求报文。

19.HWTACACS服务器发送计费结束回应报文，指示计费结束请求报文已经收到。

六、802.1x协议

NAC（Network Access Control）称为网络接入控制，通过对接入网络的客户端和用户的认证保证网络的安全，是一种“端到端”的安全技术。

NAC包括三种认证方式：802.1X认证、MAC认证和Portal认证。由于三种认证方式认证原理不同，各自适合的场景也有所差异，实际应用中，可以根据场景部署某一种合适的认证方式，也可以部署几种认证方式组成的混合认证。

对比项	802.1X认证	MAC认证	Portal认证
适合场景	新建网络、用户集中、信息安全要求严格的场景	打印机、传真机等哑终端接入认证的场景	用户分散、用户流动性大的场景
客户端需求	需要	不需要	不需要
优点	安全性高	无需安装客户端	部署灵活
缺点	部署不灵活	需登记MAC地址，管理复杂	安全性不高

NAC与AAA互相配合，共同完成接入认证功能。

NAC：用于用户和接入设备之间的交互。NAC负责控制用户的接入方式，即用户采用802.1X，MAC或Portal中的哪一种方式接入，接入过程中的各类参数和定时器。确保合法用户和接入设备建立安全稳定的连接。
AAA：用于接入设备与认证服务器之间的交互。AAA服务器通过对接入用户进行认证、授权和计费实现对接入用户访问权限的控制。

802.1X协议是一种基于端口的网络接入控制协议（Port based networkaccess control protocol）。

“基于端口的网络接入控制”是指在局域网接入设备的端口这一级验证用户身份并控制其访问权限。

1、802.1X认证系统

802.1X系统为典型的Client/Server结构，包括三个实体：客户端、接入设备和认证服务器。

客户端一般为一个用户终端设备，用户可以通过启动客户端软件发起802.1X认证。客户端必须支持局域网上的可扩展认证协议EAPoL（Extensible Authentication Protocol over LANs）。
接入设备通常为支持802.1X协议的网络设备，它为客户端提供接入局域网的端口，充当客户端和认证服务器之间的中介，从客户端请求身份信息，并与认证服务器验证该信息。根据客户端的身份验证状态控制其对网络的访问权限。
认证服务器用于实现对用户进行认证、授权和计费，通常为RADIUS服务器。

2、802.1X认证协议

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

EAP协议可以运行在各种底层，包括数据链路层和上层协议（如UDP、TCP等），而不需要IP地址。因此使用EAP协议的802.1X认证具有良好的灵活性。

在客户端与设备端之间，EAP协议报文使用EAPoL（EAP over LANs）封装格式，直接承载于LAN环境中。
EAP over LAN (EAPoL)—An encapsulation defined by 802.1X for the transport of the EAP from the supplicant to the switch over IEEE 802 networks.
在设备端与认证服务器之间，用户可以根据客户端支持情况和网络安全要求来决定采用的认证方式。

EAP终结方式中，EAP报文在设备端终结并重新封装到RADIUS报文中，利用标准RADIUS协议完成认证、授权和计费。
EAP中继方式中，EAP报文被直接封装到RADIUS报文中（EAP over RADIUS，简称为EAPoR），以便穿越复杂的网络到达认证服务器。

The switch extracts the EAP payload from the Layer 2 EAPoL frame and encapsulates the payload inside a Layer 7 RADIUS packet.

3、EAP报文

字段解释：

字段	字节数	含义
Code	1	表示EAP数据包的类型，共有以下几种 1(Request)：请求。 2(Response）：响应。 3(Success)：成功。 4(Failure)：失败。
ID	1	用于匹配Request和Response。
Length	2	表示EAP数据包的长度，包括Code、ID、 Length以及Data各字段。超出Length域范围的字节应该视为数据链路层填充，在接收时应该被忽略掉。
Data	0或多个字节	Data字段的格式由Code的值来决定。当Code取值为1或者2时，EAP为Request和Response报文,Data包含Type、Type Data两个字段，如上图所示。其中，Type为一个字节，表示Request或Response的类型。Type Data为多个字节,内容由Type字段的值决定。当Code取值为3或者4时，EAP为Success和Failure报文，没有Data字段

当code=1或者code=2时，type的类型有：

Type字段值	类型	含义
1	Identity	要求客户端发送用户输入的用户名信息。
2	Notification	非必须的通知消息，传送一些警告消息，例如密码已过期、账号被锁等。
3	NAK	仅用于Response帧，表示否定确认。例如设备用了客户端不支持的认证方法发起请求，客户端可利用Response/NAK消息以告知设备其支持的认证方法。
4	MD5-Challenge	认证方法为MD5质询法。
5	OTP ( One-Time Password)	认证方法为一次性密码，例如网银付费时系统会通过短信发送一个一次性密码。
6	GTC (Generic Token Card )	认证方法为通用令牌卡。跟OTP类似，只不过GTC往往对应一个实际的设备，例如许多国内银行都会给申请网银的用户一个动态口令牌，这个令牌就是GTC。
13	EAP-TLS	认证方法为EAP-TLS。
21	EAP-TTLS	认证方法为EAP-TTLS。
25	EAP-PEAP	认证方法为EAP-PEAP。
254	Expanded Types	扩展类型，支持厂商自定义的类型。
255	Experimental use	实验新的类型时做测试用的类型。

4、EAPoL

EAPoL是802.1X协议定义的一种报文封装格式，主要用于在客户端和设备之间传送EAP协议报文，以允许EAP协议报文在LAN上传送。

EAPoL报文格式：

字段解释：

字段	字节数	含义
PAE Ethernet Type	2	表示协议类型，值为0x888E。
Protocol Version	1	表示EAPoL帧的发送方所支持的协议版本号。 0x01: 802.1X-2001。 0×02: 802.1X-2004。 0×03: 802.1X-2010。
Type	1	表示EAPoL数据帧类型，有四种取值： 00：EAP-Packet,认证报文数据，用于承载认证信息。 01：EAPoL-Start,认证开始报文，用于用户主动发起认证过程。 02：EAPoL-Logoff，下线请求报文，用于用户主动发起下线请求。 03：EAPoL-Key,密钥信息报文。 EAPoL-Start,EAPoL-LogoffI,EAPoL-Key仅在客户端和设备端之间存在。
Length	2	表示数据长度，也就是Packet Body字段的长度，单位为字节。如果为0，则表示没有后面的Packet Body字段。 EAPoL-Start和EAPoL-Logoff报文的Length值都为0。
Packet Body	取决于报文内容	表示数据内容。

5、EAPoR

为支持EAP中继方式，RADIUS协议增加了两个属性：EAP-Message（EAP消息）和Message-Authenticator（消息认证码）。其中，EAP-Message属性用来封装EAP报文，Message-Authenticator属性用于对认证报文进行认证和校验，防止非法报文欺骗

EAPoR报文格式:

字段解释：

字段	字节数	含义
Code	1	表示RADIUS报文的类型。
Identifier	1	用来匹配请求报文和响应报文，以及检测在一段时间内重发的请求报文。客户端发送请求报文后，服务器返回的响应报文中的ldentifier值应与请求报文中的Identifier值相同。
Length	2	指定RADIUS报文的长度。超过Length取值的字节将作为填充字符而忽略。如果接收到的报文的实际长度小于Length的取值，则该报文会被丢弃。
Response Authenticator	16	验证RADIUS服务器的响应报文，同时还用于用户密码的加密。
Attributes	长度不确定	Attribute为报文的内容主体，用来携带专门的认证、授权和计费信息，提供请求和响应报文的配置细节。Attribute可以包括多个属性，每一个属性都采用(Type、Length、Value)三元组的结构来表示。类型（Type），1个字节，取值为1~255，用于表示属性的类型。长度（Length），表示该属性（包括类型、长度和属性值）的长度，单位为字节。属性值（Value），表示该属性的信息，其格式和内容由类型和长度决定，最大长度为253字节。

EAP-Message（EAP消息）:

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

Message-Authenticator（消息认证码）:

类型代码为80，在含有EAP-Message属性的radius数据包中，必须同时也包含Message-Authenticator，否则该数据包会被认为无效而被丢弃，而且服务器或用户收到报文后，还将使用EAP消息和共享密钥作为输入计算该值，如果与传过来的属性值不一致，也将丢弃这个报文。

对于Access-Request消息，需要使用共享密钥，Message-Authenticator计算方法为：

Message-Authenticator＝MD5(Code+Type+Identifier+Length+16 Zero Octets+Attributes+Secret)

对于Access-Challenge、Access-Accept、Access-Reject消息，Message-Authenticator计算方法为：

Message-Authenticator＝MD5(Code+Type+Identifier+Length+Request Authenticator+Attributes+Secret)

6、认证方式选择

EAP中继方式的优点是设备端处理更简单，支持更多的认证方法，缺点则是认证服务器必须支持EAP，且处理能力要足够强。对于常用的EAP-TLS、EAP-TTLS、EAP-PEAP三种认证方式，EAP-TLS需要在客户端和服务器上加载证书，安全性最高，EAP-TTLS、EAP-PEAP需要在服务器上加载证书，但不需要在客户端加载证书，部署相对灵活，安全性较EAP-TLS低。
EAP终结方式的优点是现有的RADIUS服务器基本均支持PAP和CHAP认证，无需升级服务器，但设备端的工作比较繁重，因为在这种认证方式中，设备端不仅要从来自客户端的EAP报文中提取客户端认证信息，还要通过标准的RAIUDS协议对这些信息进行封装，且不能支持除MD5-Challenge之外的其它EAP认证方法。PAP与CHAP的主要区别是CHAP密码通过密文方式传输，而PAP密码通过明文的方式传输。因而PAP方式认证的安全性较低，实际应用通常采用CHAP方式认证

802.1X认证流程

1、802.1X认证的触发方式

802.1X认证有以下触发方式：

客户端发送EAPoL-Start报文触发认证。
客户端发送DHCP/ARP/DHCPv6/ND或任意报文触发认证。
设备以组播形式发送EAP-Request/Identity报文触发认证。

2、EAP中继和EAP终结的认证流程

802.1X系统支持EAP中继方式和EAP终结方式与远端RADIUS服务器交互完成认证。

EAP中继方式认证流程:

1.客户端发送EAPoL-Start报文触发认证。

2.设备端发出一个ldentity类型的请求报文（EAP-Request/ldentity)请求客户端的身份信息。

3.客户端程序响应设备端发出的请求，将身份信息通过Identity类型的响应报文（EAP-response/ldentity)发送给设备端。

4.设备端响应报文中的EAP报文封装在RADIUS报文（RADIUS Access-Reguest)中，发送给认证服务器进行处理。

5.RADIUS服务器收到设备端转发的身份信息后，启动和客户端EAP认证方法的协商。RADIUS服务器选择一个EAP认证方法，将认证方法封装在RADIUS Access-Challenge报文中，发送给设备端。

6.设备端收到RADIUS服务器发送的RADIUS Access-Challenge报文后，将其中的EAP信息转发给客户端。

7.客户端收到由设备端传来的EAP信息后，解析其中的EAP认证方法，如果支持该认证方法，客户端发送EAP-Response报文给设备端；如果不支持，客户端选择一个支持的EAP认证方法封装到EAP-Response报文中发送给设备端。

8.设备将报文中的EAP信息封装到RADIUS报文中发给RADIUS服务器。

9.RADIUS服务器收到后，如果客户端与服务器选择的认证方法一致，EAP认证方法协商成功，开始认证。以EAP-PEAP认证方法为例，服务器将自己的证书封装到RADIUS报文中发送给设备端。设备收到后将证书转发给客户端。客户端校验服务器证书（可选），与RADIUS服务器协商TLS参数，建立TLS隧道。TLS隧道建立完成后，用户信息将通过TLS加密在客户端、设备端和RADIUS服务器之间传输。如果客户端与服务器的EAP认证方法协商失败，则终止认证流程，通知设备认证失败，设备去关联客户端。

10.RADIUS服务器完成对客户端身份验证之后，通知设备认证成功。

11.设备收到认证通过报文后向客户端发送认证成功报文（EAP-Success），并将端口改为授权状态，允许用户通过该端口访问网络。

12.用户在线期间，设备端会通过向客户端定期发送握手报文的方法，对用户的在线情况进行监测。

13.客户端收到握手报文后，向设备发送应答报文，表示用户仍然在线。缺省情况下，若设备端发送的两次握手请求报文都未得到客户端应答，设备端就会让用户下线，防止用户因为异常原因下线而设备无法感知。

14.客户端可以发送EAPoL-Logoff报文给设备端，主动要求下线。

15.设备端把端口状态从授权状态改变成未授权状态，并向客户端发送EAP-Failure报文。

EAP终结方式认证流程:

EAP终结方式与EAP中继方式的认证流程相比，不同之处在于用来对用户密码信息进行加密处理的MD5 Challenge由设备端生成，之后设备端会把用户名、MD5 Challenge和客户端加密后的密码信息一起送给RADIUS服务器，进行相关的认证处理。而在EAP中继方式中，用来对用户密码进行加密处理的挑战字由认证服务器生成，设备端只是负责将EAP报文封装在RADIUS报文中透传认证服务器，整个认证处理都由认证服务器来完成。

附cisco 802.1x认证流程:

1、Session Initiation

An 802.1X authentication can be initiated by either the switch or the supplicant

❶The switch initiates authentication by sending an EAP-Request-Identity message to the supplicant.

. If the switch does not receive a response, the switch retransmits the request at periodic intervals.

❷The supplicant can initiate authentication by sending an EAPoL-Start frame.

The EAPoL-Start message enables supplicants to speed up the authenticate process without waiting for the next periodic EAP-Request-Identity from the switch.

2、Session Authentication

During this stage, the switch relays EAP messages between the supplicant and the authentication server, copying the EAP message in the EAPoL frame to an AV-pair inside a RADIUS packet and vice versa.

In the first part of the exchange, the supplicant and the authentication server agree on an EAP method.

The rest of the exchange is defined by the specific EAP method.

The EAP method defines the type of credential to be used to validate the identity of the supplicant and how the credential is submitted.

❶Depending on the method, the supplicant may submit a password, certificate, token, or other credential.

❷That credential can then be passed inside a TLS-encrypted tunnel, as a hash or in some other protected form.

3、Session Authorization

If the supplicant submits a valid credential, the authentication server returns a RADIUS Access-Accept message with an encapsulated EAP-Success message. This indicates to the switch that the supplicant should be allowed access to the port.

❶Optionally, the authentication server may include dynamic network access policy instructions (for example, a dynamic VLAN or ACL) in the Access-Accept message.

❷In the absence of dynamic policy instructions, the switch simply opens the port.

If the supplicant submits an invalid credential or is not allowed to access the network for policy reasons, the authentication server returns a RADIUS Access-Reject message with an encapsulated EAP-Failure message. This indicates to the switch that the supplicant should not be allowed access to the port.

Depending on how the switch is configured, it may retry authentication, deploy the port into the Auth-Fail VLAN, or try an alternative authentication method.

4、Session Accounting

If the switch is able to successfully apply the authorization policy, the switch can send a RADIUS Accounting-Request message to the authentication server with details about the authorized session.

5、Session Termination

To ensure the integrity of the authenticated session, sessions must be cleared when the authenticated endpoint disconnects from the network.

Sessions that are not terminated immediately can lead to security violations and security holes.

A、 Link down

The most direct way to terminate an 802.1X session is to unplug the endpoint.

When the link state of the port goes down, the switch completely clears the session.

If the original endpoint or a new endpoint plugs in, the switch restarts authentication from the beginning.

B、EAPoL Logoff/proxy EAPoL Logoff

The EAPoL-Logoff message was designed to allow the supplicant to tell the switch to terminate the existing session.

On receipt of an EAPoL-Logoff message, the switch terminates the existing session.

However, there are not many practical applications of this message and many supplicants do not send EAPoL-Logoff messages.

Although EAPoL-Logoff itself does not have many applications, a proxy EAPoL-Logoff message can be very useful.

To support this feature, your phone must be capable of sending proxy EAPoL-Logoff messages.

C、CDP Enhancement for Second Port Disconnect

For IP telephony deployments with Cisco IP phones, the best way to ensure that all 802.1X sessions are properly terminated is using Cisco Discovery Protocol (CDP).

Cisco IP phones can send a CDP message to the switch indicating that the link state for the port of the data endpoint is down, which allows the switch to immediately clear the authenticated session of the data endpoint.

D、 Inactivity Timer

When the inactivity timer is enabled, the switch monitors the activity from authenticated endpoints.

When the inactivity timer expires, the switch removes the authenticated session.

The inactivity timer for 802.1X can be statically configured on the switch port or it can be dynamically assigned using the RADIUS Idle-Timeout Attribute [28].

Cisco recommends setting the timer via the RADIUS attribute

802.1X授权

认证用于确认尝试接入网络的用户身份是否合法，而授权则用于指定身份合法的用户所能拥有的网络访问权限，即用户能够访问哪些资源。

授权VLAN

用户认证成功后，认证服务器将指定VLAN授权给用户。此时，设备会将用户所属的VLAN修改为授权的VLAN，授权的VLAN并不改变接口的配置。但是，授权的VLAN优先级高于用户配置的VLAN，即用户认证成功后生效的VLAN是授权的VLAN，用户配置的VLAN在用户下线后生效。

RADIUS服务器授权VLAN时，必须同时使用以下RADIUS标准属性：

Tunnel-Type：必须配置为“VLAN”或“13”
Tunnel-Medium-Type：必须配置为“802”或“6”
Tunnel-Private-Group-ID：可以是VLAN ID、VLAN描述、VLAN名称和VLAN pool

802.1X认证支持动态VLAN授权功能

1、Guest VLAN

Guest VLAN功能开启后，当用户不响应802.1X认证请求时，譬如未安装客户端软件，设备端会将用户所在端口加入到Guest VLAN中，这样用户就可以访问Guest VLAN中的资源，从而满足了未认证的用户获取客户端软件，升级客户端或执行其他一些用户升级程序等操作。

2、Restrict VLAN

Restrict VLAN功能开启后，当用户认证失败时，譬如输入了错误的用户名和密码，设备端会将用户所在端口加入到Restrict VLAN中。Restrict VLAN和Guest VLAN的功能相似，都是满足用户在通过认证前可以访问有限的网络资源。通常在Restrict VLAN中部署的网络资源比Guest VLAN中更少，从而更严格的限制未通过认证的用户对网络资源的访问。

3、Critical VLAN

Critical VLAN功能开启后，当认证服务器无响应时，譬如设备端与认证服务器之间的网络断开或者认证服务器出现故障，设备端会将用户所在端口加入到Critical VLAN中进而能够访问Critical VLAN中的资源。

授权ACL

用户认证成功后，认证服务器将指定ACL授权给用户，则设备会根据该ACL对用户报文进行控制。

如果用户报文匹配到该ACL中动作为permit的规则，则允许其通过。
如果用户报文匹配到该ACL中动作为deny的规则，则将其丢弃。

RADIUS服务器授权ACL有两种方法：

授权静态ACL：RADIUS服务器通过RADIUS标准属性Filter-Id将ACL ID授权给用户。为使授权的ACL生效，需要提前在设备上配置相应的ACL及规则。
授权动态ACL：RADIUS服务器通过华为RADIUS扩展属性HW-Data-Filter将ACL ID及其ACL规则授权给用户。ACL ID及其ACL规则需要在RADIUS服务器上配置，设备上不需要配置

free-rule

用户认证成功之前，为满足用户基本的网络访问需求，需要用户认证成功前就能获取部分网络访问权限。

用户的free-rule可以通过普通的free-rule定义，也可以通过ACL定义。

普通的free-rule由IP地址、MAC地址、接口、VLAN等参数确定；

ACL定义的free-rule由ACL规则确定

两种方式定义的free-rule都能够指定用户认证成功前就可以访问的目的IP地址。除此之外，ACL定义的free-rule还能够指定用户认证成功前就可以访问的目的域名。

802.1X重认证

若管理员在认证服务器上修改了某一用户的访问权限、授权属性等参数，此时如果用户已经在线，则需要及时对该用户进行重认证以确保用户的合法性。

配置对在线802.1X用户进行重认证功能后，设备会把保存的在线用户的认证参数（用户上线后，设备上会保存该用户的认证信息）发送到认证服务器进行重认证，若认证服务器上用户的认证信息没有变化，则用户正常在线；若用户的认证信息已更改，则用户将会被下线，此后用户需要重新进行认证。

配置点	方式	配置命令
在接入设备侧配置	对802.1X认证成功用户进行周期性重认证。	dot1x reauthenticate dot1x timer reauthenticate-period reauthenticate-period-value
在接入设备侧配置	手动对指定MAC地址进行单次重认证。	dot1x reauthenticate mac-address mac-address
在RADIUS服务器侧配置	对802.1X认证成功的用户下发RADIUS标准属性Session-Timeout和Termination-Action,其中，Session-Timeout属性值为用户在线时长定时器，Termination-Action属性值为1表示对用户进行重认证。当用户在线时长达到Session-Timeout的属性值时，设备会对用户进行重认证。	无

异常认证状态下的用户

用户在预连接阶段或认证失败阶段，设备会记录用户表项信息，并能够为用户分配受限的网络访问权限。为使用户能够及时认证成功，获取正常的网络访问权限，设备根据用户表项对没有认证成功的用户进行重认证。

在用户表项老化时间到达之前，如果用户重认证没有成功，设备将删除对应的表项信息，并收回授予用户的网络访问权限；如果用户重认证成功，设备将用户加入到认证成功的用户表项，并授予认证成功后的网络访问权限。

用户状态	配置命令
RADIUS服务器Down	authentication event authen-server-up action re-authen:配置当RADIUS服务器真正UP时对用户进行重认证。
认证失败	authentication timer re-authen authen-fail re-authen-time: 配置对认证失败用户进行周期性重认证。
预连接	authentication timer re-authen pre-authen re-authen-time:配置对预连接用户进行周期性重认证。

 802.1X认证用户下线

当用户已下线，而接入设备和RADIUS服务器未感知到该用户已下线时，会产生以下问题：

RADIUS服务器仍会对该用户进行计费，造成误计费。
存在非法用户仿冒合法用户IP地址和MAC地址接入网络的风险。
已下线用户数量过多的情况下，还会占用设备用户规格，可能会导致其他用户无法接入网络。

用户下线方式分为❶客户端主动下线，❷接入设备控制用户下线和❸服务器控制用户下线。

1、客户端主动下线

用户通过客户端软件发送EAPoL-Logoff报文主动下线，设备端会向客户端发一个EAP-Failure的报文，进而将端口状态由授权状态转换为非授权状态。

2、接入设备控制用户下线

接入设备控制用户下线有两种方式：

在接入设备上执行命令强制指定用户下线。
在接入设备上配置用户探测功能，用于探测用户是否在线。当用户在指定的时间内无响应，则认为用户下线，删除用户表项。

当管理员发现非法用户在线，或在测试中想让某一用户下线后重新上线，可以通过在设备上执行命令强制该用户下线。

对于正常接入用户，会通过ARP探测对用户在线状态进行确认，如果探测到用户下线，则进行下线处理，删除用户表项。

1、用户发送任意报文触发802.1X认证，同时启动探测定时器。

2、在若干个T时间内，接入设备均能收到客户端流量，用户在线。

3、用户最后一次发送报文。在这个T时间结束时，由于有客户端流量，接入设备判断用户在线，并重启定时器。

4、接入设备在T时间内未收到客户端流量，发送第一次ARP请求，客户端无响应。

5、T时间后，接入设备仍未收到客户端流量，发送第二次ARP请求，客户端无响应。

6、T时间后，接入设备仍未收到客户端流量，探测失败，删除用户表项。

3、服务器控制用户下线

服务器控制用户下线有以下方式：

RADIUS服务器可通过DM报文（Disconnect Message）强制用户下线。DM（Disconnect Message）是指用户离线报文，即由RADIUS服务器端主动发起的强迫用户下线的报文。
RADIUS服务器通过授权RADIUS标准属性Session-Timeout和Termination-Action。其中，Session-Timeout为用户在线时长定时器，Termination-Action属性值为0表示将用户下线。当用户在线的时长达到定时器指定的数值时，设备会将用户下线。

802.1X定时器

1、EAP-Request/Identity请求超时

在802.1X认证中，设备会向客户端发送EAP-Request/Identity报文请求用户名，请求报文的重传次数和时间间隔由命令行控制。

设备发送EAP-Request/Identity请求报文超时后，向客户端发送认证失败报文。

定时器由命令dot1x timer tx-period tx-period配置

设备重传请求报文的次数通过命令dot1x retry max-retry-value配置。

2、EAP-Request/MD5 Challenge请求超时

当设备向802.1X客户端发送了EAP-Request/MD5 Challenge请求报文后，设备启动802.1X客户端认证超时定时器。

若在该定时器设置的时长内，设备没有收到客户端的响应，则设备将重发该报文。

若设备重传请求报文的次数达到配置的最大值（通过命令dot1x retry max-retry-value配置）后，仍然没有得到用户响应，则停止发送认证请求。

设备发送EAP-Request/MD5 Challenge请求报文超时后，向客户端发送认证失败报文。

3、802.1X认证静默定时器

使能静默功能后，若某一用户在60秒内认证失败的次数超过命令dot1x quiet-times fail-times规定的值，则设备会将该用户静默一段时间，该时间由命令dot1x timer quiet-period quiet-period-value指定，在静默时间内，设备会丢弃该用户的802.1X认证请求，从而避免用户在短时间内频繁认证失败。

七、EAP认证方法

Extensible Authentication Protocol (EAP) is an authentication framework for wireless networks and point-to-point connections.

EAP supports multiple authentication methods, and provides common functions and rules for negotiation of the desired authentication method

EAP是一种认证框架，主要有两种功能：

1、支持多种EAP认证方法

The EAP method determines the type of credential that is used and how that credential is submitted.

2、通信双方协商使用何种EAP认证方法

分类：

非EAP类:

1、RADIUS-based protocols that do not include EAP:

- PAP(Password Authentication Protocol)

The Password Authentication Protocol (PAP) provides a simple method for a user to establish its identity by using a two-way handshake. The PAP password is encrypted with the shared secret and is the least sophisticated authentication protocol.

- CHAP(Challenge Handshake Authentication Protocol)
- MSCHAPv1(Microsoft Challenge Handshake Authentication Protocol version 1)
- MSCHAPv2(Microsoft Challenge Handshake Authentication Protocol version 2)

For all without EAP authentications:

Step 1 A host connects to a network device.

Step 2 The network device sends a RADIUS Access-Request to ACS, containing RADIUS attributes appropriate to the specific protocol that is being used (PAP, CHAP, MSCHAPv1, or MSCHAPv2).

Step 3 ACS uses an identity store to validate the user's credentials.

Step 4 The RADIUS response (Access-Accept or Access-Reject) is sent to the network device that will apply the decision.

EAP类:

2、EAP family of protocols transported over RADIUS, which can be further classified as:

EAP类又分为：

A、Simple EAP protocols that do not use certificates:不使用证书类

-EAP-MD5(Message Digest 5 Protocol)---单向认证

EAP Message Digest 5-(EAP-MD5) provides one-way client authentication. The server sends the clienta random challenge. The client proves its identity by hashing the challenge and its password with MD5.

-LEAP(Lightweight Extensible Authentication Protocol)

ACS currently uses LEAP only for Cisco Aironet wireless networking.

B、EAP protocols that involve a TLS handshake and in which the client uses the ACS server certificate to perform server authentication: 只有服务器使用证书类

-PEAP(Protected Extensible Authentication Protocol)

EAP-MSCHAPV2
EAP-GTC(EAP Generic Token Card)

-EAP-FAST(EAP Flexible Authentication via Secured Tunnel)

EAP-MSCHAPV2
EAP-GTC(EAP Generic Token Card)

C、EAP protocols that are fully certificate-based, in which the TLS handshake uses certificates for both server and client authentication: 双方都使用证书类

-EAP-TLS(Extensible Authentication Protocol-Transport Layer Security)

The EAP protocol carries initial authentication information, specifically the encapsulation of EAP over LANs (EAPOL) as established by IEEE 802.1x. TLS uses certificates for user authentication and dynamic ephemeral session key generation.

-PEAP with inner method EAP-TLS

For all EAP authentications:

Step 1 A host connects to a network device.

Step 2 The network device sends an EAP Request to the host.

Step 3 The host replies with an EAP Response to the network device.

Step 4 The network device encapsulates the EAP Response that it received from the host into a RADIUS Access-Request (using the EAP-Message RADIUS attribute) and sends the RADIUS Access-Request to ACS.

Step 5 ACS extracts the EAP Response from the RADIUS packet and creates a new EAP Request, encapsulates it into a RADIUS Access-Challenge (again, using the EAP-Message RADIUS attribute), and sends it to the network device.

Step 6 The network device extracts the EAP Request and sends it to the host.

the host and ACS indirectly exchange EAP messages, negotiate the specific EAP method that will subsequently be used to perform the authentication.

ACS negotiates the EAP method for authentication. The client can acknowledge the EAP method that the EAP server suggests or, it can respond with a negative acknowledgment (NAK) and suggest a list of alternative EAP methods. The server and client must reach agreement about the EAP method to use to instantiate authentication.

❶EAP-TLS(EAP-Transport Layer Security )-------相互使用证书认证

EAP-TLS is an IETF standard defined in RFC 2716.

EAP-TLS requires client-side and server-side certificates for mutual authentication.

Within 802.1X, the EAP-TLS exchange of messages provides mutual authentication, negotiation of the encryption method, and encrypted key determination between a supplicant and an authentication server.

图2，错误，应该是client验证服务器证书

图3，错误，应该是client提交client的证书

After the server and supplicant agree to perform authentication using EAP-TLS, the server submits its certificate to the supplicant in Step 1.

In Step 2, the supplicant validates the certificate of the server.

After the identity of the server has been authenticated, the supplicant submits its certificate to the server in Step 3.

The server validates the certificate of the supplicant, thus completing the process of mutual authentication in Step 4.

The ACS EAP-TLS server produces 128-bit MPPE send and receive keys that are used for encrypted communication between the client and server.

The ACS EAP-TLS server sends MPPE keys to the client in vendor-specific RADIUS attribute (26) byusing vendor code Microsoft (311), and attributes MS-MPPE-Send-Key (16) and MS-MPPE-Recv-Key(17).

Every end user and computer, including the authentication server, that participates in EAP-TLS must possess at least two certificates:

A client certificate signed by the certificate authority (CA)
A copy of the CA root certificate

TLS协议由TLS记录协议(TLS Record)和TLS握手协议(TLS Handshake)两个协议组成

TLS握手过程实际上就是通信双方协商交换一个用于对称加密的密钥的过程，这个过程实际上产生三个随机数：client random, server random,pre-master secret。前两个随机数都是明文传送的，只有pre-master secret是加密的（RSA或DHP）。

TLS记录协议的作用是对数据进行处理，包括加密，压缩和重组等，而且会将处理后的数据传递给高层用户。

EAP-TLS使用TLS握手协议作为认证方式，TLS有很多优点，所以EAP选用了TLS作为基本的安全认证协议，并为TTLS和PEAP建立安全隧道，TLS已经标准化，并且进过了长期应用和分析，都没有发现明显的缺点。

TLS认证是基于Client和Server双方互相验证数字证书的，是双向验证方法，首先Server提供自己的证书给Client,Client验证Server证书通过后提交自己的数字证书给Server,客户端的证书可以放到本地、放到key中等等TLS有一个缺点就是TLS传送用户名的时候是明文的，也就是说抓包能看到EAP-ldentity的明文用户名。

TLS是基于PKI证书体系的，这是TLS的安全基础，也是TLS的缺点，PKI太庞大，太复杂了，如果企业中没有部署PKI系统，那么为了这个认证方法而部署PKI有些复杂，当然，如果企业已经部署了PKI，那么使用EAP-TLS还是不错的选择。

EAP-TLS的认证过程，具体流程如下：

1、首先客户端给接入用户发送Identity报文，要求客户端提供身份标识；

2、接入用户给客户端回应Identity报文，内容是用户的身份标识，客户端将这个报文封装成Radius访问请求报文传给服务器；

3、服务器在获取到接入用户的接入标识后，会给客户端发送Radius访问挑战报文，客户端在收到这个报文后，对报文进行解封装，将TLS-Start报文传给接入用户；

4、接入用户发送TLS Client Hello报文给客户端，Client Hello报文中包括支持的TLS协议版本，支持的的加密算法，支持的压缩方法以及客户端随机数等，客户端收到后，将该报文封装到Access-Request中传给服务器；

5、客户端在收到服务器发来的Radius访问质询报文后，将TLS Server Hello报文传给接入用户，这个报文中包括server_hello，certificate，certificate_request，server_hello_done，其中server_hello报文中包括确认使用的TLS协议版本，服务器生成的服务器随机数（server random），session ID，确认使用的加密算法等，certificate代表的是服务器证书，certificate_request代表的是请求客户端提供证书，server_hello_done代表的是整个server hello过程的结束。

6、接入用户给客户端发送TLS change cipher spec报文，这个报文将被客户端封装成Access-Request报文传给服务器，change cipher spec报文包括以下内容，其中certificate指的是客户端证书，client_key_exchange包含pre-master secret，客户端生成的第三个随机数，pre-master secret首先采用RSA算法，生成一个48字节随机数，然后用server的公钥加密之后再放入报文中，certificate_verify中的内容是到这一步为止收到和发送的所有握手消息签名结果，change_cipher_spec的作用是客户端通知服务器开始使用加密方式发送报文，客户端使用上面的３个随机数client random, server random,pre-master secret，计算出48字节的master secret，这个就是对称加密算法的密钥，finished为发送的第一个加密报文，它使用HMAC算法计算收到和发送的所有握手消息的摘要，然后通过RFC5269中定义的一个伪函数PRF计算出结果，加密后发送；

7、服务器给客户端发送Access-Challenge报文，接入用户将收到TLS change cipher spec报文，到这儿握手结束；

8、客户端在收到接入用户发送的EAP-TLS报文后，将这个报文封装成Access-Request报文传给服务器；

9、服务器给客户端发送Access-Accept报文，接入用户将收到EAP-Success。

❷EAP-TTLS(Tunneled Transport Layer Security)

EAP_TTLS协议的规范文档是RFC5281，EAP_TTLS是EAP_TLS的一种扩展，与EAP_TLS的区别是对证书的要求没有那么严格，只需要提供服务器端证书，而客户端证书不是必须的。

EAP_TTLS是一个复合的认证方法，主要包括两个阶段：

第一个阶段是在用户和认证服务器之间建立TLS隧道

第二阶段是在已经建立的隧道内使用其他的认证方法进行认证。该认证通过在TLS通道内嵌套其他的认证方法来完成对客户端的认证，也具有很高的安全性。TTLS的扩展性很好，几乎支持所有的认证方法，包括MSCHAPv2。

❸EAP-PEAP(Protected EAP)

EAP_PEAP是一个复合的认证方法，主要包括两个阶段：

第一个阶段是在用户和认证服务器之间建立TLS隧道，

In phasel, the end-user client authenticates ACS. This action requires a server certificate and authenticates ACS to the end-user client, ensuring that the user or machine credentials sent in phase two are sent to a AAA server that has a certificate issued by a trusted CA. The first phase uses a TLS handshake to establish an SSL tunnel between the end-user client and the AAA server.

第二阶段是在已经建立的隧道内使用其他的EAP方法进行认证，如EAP-MSCHAPv2。

In the second phase, ACS authenticates the user or machine credentials by using an EAP authentication protocol. The SSL tunnel that was created in phasel protects the EAP authentication.

The inner-method authentication type that is negotiated during phase 2 can be either EAP-MSCHAPv2. EAP-GTC or EAP-TLS.

正因为TLS需要PKI的缺点，所以设计出现了TTLS和PEAP，这两个协议不用建立PKI系统，而在TLS隧道内部直接使用原有老的认证方法，这保证了安全性，也减小了复杂度。

把TTLS和PEAP放到一起介绍的原因是他们俩很像，两个都是典型的两段式认证，在第一阶段建立TLS安全隧道，通过Server发送证书给Client实现Client对Server的认证（这里TTLS和PEAP仍然使用证书，但是这里的证书都是服务器证书，管理起来比TLS客户端证书要简单那的多）；当安全隧道一旦建立，第二阶段就是协商认证方法，对Client进行认证；

TTLS利用TLS安全隧道交换类似RADIUS的AVPs(Attribute-Value-Pairs)，实际上这些AVPs的封装和RADIUS都十分相似，TTLS这种AVPs有很好的扩展性，所以它几乎支持任何认证方法，这包括了所有EAP的认证方法，以及一些老的认证方法，比如PAP、CHAP、MS-CHAP、MS-CHAPv2等，TTLS的扩展性很好，通过新属性定义新的认证方法。

PEAP之所以叫Protected EAP,就是它在建立好的TLS隧道之上支持EAP协商，并且只能使用EAP认证方法，这里为什么要保护EAP，是因为EAP本身没有安全机制，比如EAP-ldentity明文显示，EAP-Success、EAP-Failed容易仿冒等，所以EAP需要进行保护，EAP协商就在安全隧道内部来做，保证所有通信的数据安全性。其实PEAP最大的优点就是微软支持开发，微软在Windows系统内集成了客户端，微软和Cisco都支持PEAP，但是他们的实现有所区别。

EAP-TTLS与EAP-PEAP的区别相当小，最大的不同就是EAP-TTLS支持更多的内层认证协议。EAP-TTLS支持传统的认证方法PAP、 CHAP、MS-CHAP和MS-CHAPv2，也支持使用EAP协议作为内层认证方法，支持使用客户端证书作为身份凭证，而EAP-PEAP只支持EAP协议作为内层认证方法。

EAP_TTLS和EAP_PEAP还可以支持快速恢复TLS会话。在认证的第二阶段成功的情况下，无须执行认证第一阶段或第二阶段就能够恢复该会话，可以通过发送一条EAP-Success消息来进行重新身份验证尝试，这称为快速重连。这可以减少域间切换的延迟。

PEAP包括三个主要版本：

EAP-PEAPv0(EAP-MSCHAPv2)

微软的EAP-PEAPv0 （EAP-MSCHAPv2）是最常用的一种PEAP类型，使用EAP-MSCHAPv2协议作为隧道内部的认证方法，其使用用户名和密码作为用户凭证。

EAP-PEAPv0(EAP-TLS)

EAP-PEAPv0（EAP-TLS）是微软的另一种类型的PEAP，使用EAP-TLS协议作为隧道内部的认证方法，其使用客户端证书作为用户凭证。EAP-TLS也可以作为一个单独的EAP认证协议使用。

EAP-PEAPv1(EAP-GTC)

EAP-PEAPv1（EAP-GTC）是Cisco版本的一种PEAP类型，使用EAP-GTC（EAP-GenericToken Card，通用令牌卡）协议作为隧道内部的认证方法。EAP-GTC定义在RFC3748中，然后被发展成与现有的安全令牌系统提供互操作性，如RSA的SecurID解决方案的OTP。EAP-GTC方法建议使用安全令牌设备，但是其身份凭证也可以为明文的用户名和密码。因此，当EAP-GTC被用于PEAPv1的隧道中，通常其身份凭证是一个简单的明文用户名和密码。

附：

TLS：transport level security，安全传输层协议，用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议（TLS Record)和TLS握手协议（TLS Handshake)。

目前基于TLS的EAP认证方法主要有三种：

(1) EAP-TLS

使用TLS握手协议作为认证方法。

(2)EAP-TTLS

(3)EAP-PEAP

EAP_PEAP的认证过程，具体流程如下：

1、握手阶段和EAP_TLS相似，与之不同的是，只需要服务器发送证书给客户端，实现客户端对服务器的认证，客户端不再需要发送自身的证书给服务器；

2、服务器给客户端发送Access-Challenge报文，客户端收到报文之后，解封装该报文，将其中的Identity报文传给接入用户；

3、客户端在收到接入用户发来的回应报文Identity后，将读报文封装在Access-Request中传给服务器；

4、服务器根据用户的Identity査找该接入用户的认证方法，在获取认证方法之后，向接入用户发送嵌套的认证方法的Challenge报文；

5、根据嵌套的认证方法的类型，接入用户和服务器进行相应的认证过程，直到服务器对接入用户认证成功；

6、服务器对接入用户认证成功后，给客户端发送访问质询报文，客户端将其中的Result=Success报文传给接入用户；

7、同样的，接入用户在收到报文后，给客户端发送EAP回应报文，客户端将EAP报文封装成访问请求的格式传给服务器；

8、服务器给接入用户发送Access-Accept报文，接入用户将收到EAP-Success。

❹PEAP-MSCHAPv2

PEAP was developed by Cisco Systems, Microsoft Corporation, and RSA Security, Inc.

Furthermore, because PEAP requires a certificate only on the authentication server, it is possible to securely authenticate LAN clients without requiring every client to have its own certificate.

MSCHAPv2 is commonly used as the second EAP type inside a PEAP tunnel.

MS-CHAPv2 is a password-based, challenge-response, mutual authentication protocol that uses Message-Digest Algorithm (MD4) and Data Encryption Standard (DES) to encrypt responses.

The authenticator challenges a supplicant and the supplicant can challenge the authentication server. If either challenge is not correctly answered, the connection can be rejected.

A malicious user can capture a successful MSCHAPv2 exchange and guess passwords until the correct one is determined.

Used in the combination with PEAP, however, the MSCHAPv2 exchange is protected with the strong security of the TLS channel.

图2，错误，应该是client验证服务器证书

After the server and supplicant agree to perform authentication using PEAP-MSCHAPv2, the server submits its certificate to the supplicant in Step 1.

The supplicant validates the certificate of the server in Step 2.

. After the identity of the server has been authenticated, the supplicant builds a TLS-encrypted tunnel. Inside that tunnel, the supplicant submits a username and password using MSCHAPv2 in Step 3.

The server validates the password of the supplicant, thus completing the process of mutual authentication in Step 4.

相同点：

Like EAP-TLS, PEAP-MSCHAPv2 requires that the authentication server present a certificate to the supplicant.

不同点：

Unlike EAP-TLS, PEAP-MSCHAPv2 does not require that the supplicant have a certificate.

This is because supplicant establishes its identity inside the tunnel via MSCHAPv2.

MSCHAPv2 authentication relies on a password, not a certificate.

Every endpoint and user that participates in PEAP-MSCHAPv2 must possess the following credentials:

Root CA certificate for the CA that signed the certificate of the authentication server
MSCHAPv2 username and password

The authentication server must possess the following credentials:

Server certificate signed by the root CA
MSCHAPv2 password for every user and computer

PEAP-MSCHAPv2的认证过程，具体流程如下：

1、首先客户端给接入用户发送Identity报文，要求客户端提供身份标识；

2、接入用户给客户端回应Identity报文，内容是用户的身份标识，客户端对这个报文的处理是将之封装成Radius访问请求报文传给服务器；

3、服务器在获取到接入用户的接入标识后，会给客户端发送Radius访问挑战报文，客户端在收到这个报文后，对报文进行解封装，将报文中的EAP-Request/EAP-MSCHAPv2(Challenge)发送给接入用户，Challenge报文中包含有服务器端产生的Server-Challenge；

4、接入用户进行计算，发送Response报文给客户端，客户端在接收到该报文后，将该报文封装到Access-Request中传给服务器，Response报文中包含用户产生的Peer-Challenge和根据用户密码，用户名，Peer-Challenge和Server-Challenge为输入通过MD4和DES算法生成的NT-Response；

5、服务器对接入用户进行验证，具体验证的方法是服务器端使用同样的算法以用户密码，用户名，Peer-Challenge和Server-Challenge为输入计算出NT-Response，如果和Response报文中NT-Response匹配，则认证成功。在认证成功的基础下，会给客户端发Success-Request报文，Success-Request报文中含有以用户密码，用户名，Peer-Challenge，Server-Challenge以及NT-Response为输入使用MD4算法和DES算法计算出来的Message，客户端收到报文后，进行解封装，将报文中的Success-Request发送给接入用户，请求用户对服务器进行验证；

6、接入用户对服务器进行验证，具体验证的方法是用同样算法以用户密码，用户名，Peer-Challenge，Server-Challenge以及NT-Response为输入计算出Message，然后与Success-Request中的Message做匹配，如果匹配失败，则不再向服务器发送报文，如果匹配成功，则向客户端发送EAP-Request/EAP-MSCHAPv2(Success-Response)报文，客户端收到后，将报文封装成Access-Request报文传给服务器；

7、服务器如果接收到Success-Response报文，则说明验证成功，接入用户收到的报文将是EAP成功报文，到此整个认证流程结束。

❺EAP-FAST

The EAP Flexible Authentication via Secured Tunnel (EAP-FAST) protocol is a new, publicly accessible IEEE 802.1x EAP type that Cisco developed to support customers that cannot enforce a strong password policy and want to deploy an 802.1x EAP type that does not require digital certificates.

EAP-FAST is a client-server security architecture that encrypts EAP transactions with a TLS tunnel.While similar to PEAP in this respect, it differs significantly in that EAP-FAST tunnel establishment is based on strong secrets that are unique to users.

These secrets are called Protected Access Credentials (PACs), which ACS generates by using a master key known only to ACS. Because handshakes based on shared secrets are intrinsically faster than handshakes based on PKI, EAP-FAST is the fastest of the advanced EAP protocols (including EAP-TLS and PEAP) that establish a TLS connection to encrypt the traffic between the supplicant and ACS. No certificate management is required to implement EAP-FAST.

EAP-FAST occurs in three phases:

Phase zero —Unique to EAP-FAST, phase zero is a tunnel-secured means of providing an

EAP-FAST end-user client with a PAC for the user requesting network access.

Providing a PAC to the end-user client is the sole purpose of phase zero.

Phase one—In phase one, ACS and the end-user client establish a TLS tunnel based on the PAC that the end-user client presents. This phase requires that the end-user client has been provided a PAC for the user who is attempting to gain network access and that the PAC is not expired.The means by which PAC provisioning has occurred is irrelevant; you can use automatic or manual provisioning.

Phase two—In phase two, ACS authenticates the user's credentials from within the protected TLS tunnel that was constructed in phase one, using EAP-MSCHAPv2 or EAP-GTC as the inner EAP method

EAP-FAST master-keys are strong secrets that ACS automatically generates and of which only ACS isaware. Master-keys are never sent to an end-user client. EAP-FAST requires master-keys for two purposes:

PAC generation—ACS generates PACs by using the active master-key.
EAP-FAST phase one—ACS determines whether the PAC that the end-user client presents was generated by one of the master-keys it is aware of.

PACs are strong shared secrets that enable ACS and an EAP-FAST end-user client to authenticate each other and establish a TLS tunnel for use in EAP-FAST phase two. ACS generates PACs by using the active master-key and a username.

PAC comprises:

PAC-Key —Shared secret bound to a client (and client device) and server identity.
PAC Opaque—Opaque field that the client caches and passes to the server. The server recovers thePAC-Key and the client identity to mutually authenticate with the client.
PAC-Info—At a minimum, includes the Authority ID to enable the client to cache different PACs.Optionally, it includes other information such as the PACs expiration time.

EAP-FAST（EAP-Flexible Authentication via Secure Tunneling，基本安全隧道的灵活认证）由Cisco所开发设计，用于取代易破解的LEAP。

EAP-FAST与EAP-PEAP和EAP-TTLS一样，提供双向认证和隧道化认证。

但是EAP-FAST并不使用基于X.509标准的数字证书去建立TLS隧道，而是使用PAC（Protected Authentication Credential，受保护的接入凭证）。

PAC是一种类数字证书，实际上是一个共享密钥，主要包含以下三部分：

• Shared Secret—The PAC-Key：客户端与认证服务器之间的一个预共享密钥，是一个强32字节的密钥,由认证服务器随机产生,是建立TLS隧道的先期主密钥；

• Opaque Element—The PAC-Opaque：在隧道建立时发送给认证服务的一个可变长度的数据元素，这样认证服务器就可以解码所需的信息来验证客户端的身份；

• Other Information—PAC-Info：是一个可变长度的数据元素，,能够以最简洁方式的提供认证服务器或PAC发布者的身份(A-ID)。为了避免混绕,各个认证服务器的A-ID是不同的。PAC-Info还可能包括其他的有用但非强制的信息,例如,PAC-Key生存时间,也可能在PAC分发或更新时被服务器传递到申请者。

• EAP-FAST 阶段0 —— 此阶段用于自动分发部署PAC，是一个可选的阶段，所有的PAC可以通过手动方式安装在每个客户端上。

• EAP-FAST 阶段1 —— 客户端请求方发送外层伪装的身份ID给认证服务器，让认证服务器知道有客户端尝试认证。客户端和认证服务器之间使用对称密钥加密进行协商，建立起一个加密的TLS隧道；

• EAP-FAST阶段2 —— 在加密隧道内进行客户端请求方的身份验证。EAP-FAST支持多种内层认证方法，但通常使用的内层认证协议为EAP-GTC，使用用户名和密码进行验证。

阶段0执行的自动分发部署PAC文件是使用一个匿名的Diffie-Hellman交换，客户端仅是简单的信任提供PAC文件的。因此，EAP-FAST如果是使用自动分发部署PAC文件，很容易遭受到中间人攻击。如果不经过阶段0，则手动安装PAC文件到每个客户端上则是一件很繁重的任务，还不如使用已经被广泛部署过的EAP-TLS和EAP-PEAP。

八、实验

1、设备管理

win7:ip=DHCP

SW:

enable password cisco
!
username admin password 0 admin

aaa new-model
!
aaa authentication login cty none
aaa authentication login test1 local none
aaa authentication login test2 local-case none
aaa authentication login test3 local enable
aaa authentication login test4 local-case enable
aaa authentication login test5 local enable none
aaa authentication login test6 local-case enable none

#
ip dhcp excluded-address 10.1.1.1 10.1.1.99
ip dhcp excluded-address 10.1.1.254
!
ip dhcp pool test
network 10.1.1.0 255.255.255.0
default-router 10.1.1.254
dns-server 8.8.8.8 114.114.114.114

interface Vlan1
ip address 10.1.1.254 255.255.255.0

line con 0
login authentication cty

A、AAA本地认证和授权

aaa authentication login test1 local none

line vty 0 4

本地有用户名和密码的，local认证
本地没有的用户名和密码，无需认证，随便输入什么都可登录。
进入特权模式需要enable密码

使用本地用户名和密码admin/admin,enable密码：cisco

使用不存在的用户名sss即可登录成功，无需登录密码。

进入特权模式需要enable密码:cisco

使用本地用户名和密码Admin/admin,enable密码：cisco(用户名不区分大小写)

aaa authentication login test2 local-case none

line vty 0 4

本地有用户名和密码的，local认证，用户名区分大小写
本地没有的用户名和密码，无需认证，随便输入什么都可登录
进入特权模式需要enable密码

Admin非本地用户名，所以跳过local认证，使用none认证。

aaa authentication login test3 local enable

line vty 0 4

本地有用户名和密码的，local认证(进入特权需要enable密码)
本地没有的用户名和密码，随便输入什么用户名，需要enable密码登录(没有设置enable密码，认证不了)。

非本地用户test，密码必须输入enable密码。

aaa authentication login test4 local-case enable

line vty 0 4

本地有用户名和密码的，local认证，用户名区分大小写(进入特权需要enable密码)
本地没有的用户名和密码，随便输入什么用户名，需要enable密码登录(没有设置enable密码，认证不了;进入特权需要enable密码)。

Admin/admin登录失败，Admin/cisco登录成功(Admin非本地用户，区分大小写)

aaa authentication login test5 local enable none

line vty 0 4

本地有用户名和密码的，local认证(进入特权需要enable密码)
本地没有的用户名和密码，随便输入什么用户名，需要enable密码登录(没有设置enable密码，可以登录)
本地没有enable密码的，无需认证((无法进入特权)。

非本地用户test使用enable密码cisco登录

no enable password去掉enable密码

非本地用户test无需用户密码即可登录，但是不能进入特权模式。

aaa authentication login test6 local-case enable none

line vty 0 4

本地有用户名和密码的，local认证，用户名区分大小写
本地没有的用户名和密码，随便输入什么用户名，需要enable密码登录
本地没有enable密码的，无需认证(无法进入特权模式)。

Admin/admin登录失败，Admin/cisco登录成功。

no enable password去掉enable密码

非本地用户Admin直接登录成功，但是无法进入特权模式。

还有一种本地认证，使用相对较少。

aaa authentication login test7 local line

line vty 0 4

password 123456

非本地用户test使用123456密码登录成功。

总结，本地认证的方式有： local(local-case) 、 enable 、line、 none

B、远端认证和授权(使用radius服务器)

enable password cisco
!
username admin password 0 admin

aaa authentication login test10 group radius local line enable

!
radius server RS
address ipv4 10.1.1.1 auth-port 1645 acct-port 1646
key cisco
!

line vty 0 4
login authentication test10

新建test/test123用户。

添加管理设备，选择radius，设置共享密钥为cisco

添加授权策略

test/test123用户登录成功。

关闭radius服务器的接口。

aaa authentication login test10 group radius local line enable

test/test123无法登录-radius认证无效。

test非本地用户-local认证无效。

line vty 0 4没有设置密码-line认证无效。

最后test/cisco登录成功。

C、远端认证授权计费(使用tacacs+服务器)

后续文章详细介绍。

2、网络访问-802.1x

添加Nas设备，设置共享密钥(NAS与Radius之间的密钥)

添加要接入网络的用户，非管理网络设备的用户

自定义授权配置文件-网络访问

创建访问策略，指定用户使用指定的授权配置文件

交换机配置：

enable password cisco
!
username admin password 0 admin

aaa new-model

aaa authentication login cty none

aaa authentication login vty group radius local

aaa authentication dot1x default group radius

aaa authorization network default group radius

aaa accounting dot1x default start-stop group radius

radius server RS

address ipv4 10.1.1.1 auth-port 1645 acct-port 1646

key cisco

dot1x system-auth-control

interface GigabitEthernet0/0

switchport mode access

media-type rj45

negotiation auto

authentication event fail retry 3 action next-method

authentication host-mode multi-host

authentication port-control auto

dot1x pae authenticator

spanning-tree portfast edge

ip dhcp excluded-address 10.1.1.1 10.1.1.99

ip dhcp excluded-address 10.1.1.254

ip dhcp pool test

network 10.1.1.0 255.255.255.0

default-router 10.1.1.254

dns-server 8.8.8.8 114.114.114.114

line con 0

line aux 0

line vty 0 4

pc终端设置:

验证与分析：

1、shutdown int g0/0

2、抓包g0/0和g0/1

3、no shutdown int g0/0

4、分析包

EAPoL

1. EAPoL-Start

2、 EAP-Request/ldentity

3. EAP-Response/ldentity

6. EAP-Request/PEAP

10. EAP-Success

EAPoR

EAP中继方式：

对应包❹

802.1x客户端与NAS设备之间的EAP报文，被封装在radius报文中，作为radius报文的属性。

对应包❺

EAP中继方式认证流程:

1.客户端发送EAPoL-Start报文触发认证。

2.设备端发出一个ldentity类型的请求报文（EAP-Request/ldentity)请求客户端的身份信息。

3.客户端程序响应设备端发出的请求，将身份信息-用户名cisco(上图中是alice，实际试验中是cisco)通过Identity类型的响应报文（EAP-response/ldentity)发送给设备端。

4.设备端将响应报文中的EAP报文封装在RADIUS报文（RADIUS Access-Reguest)中，发送给认证服务器进行处理。

5.RADIUS服务器收到设备端转发的身份信息后，启动和客户端EAP认证方法的协商。RADIUS服务器选择一个EAP认证方法，将认证方法封装在RADIUS Access-Challenge报文中，发送给设备端。

6.设备端收到RADIUS服务器发送的RADIUS Access-Challenge报文后，将其中的EAP信息转发给客户端。

8.设备将报文中的EAP信息封装到RADIUS报文中发给RADIUS服务器。

客户端无需验证服务器证书

10.RADIUS服务器完成对客户端身份验证之后，通知设备认证成功。

11.设备收到认证通过报文后向客户端发送认证成功报文（EAP-Success），并将端口改为授权状态，允许用户通过该端口访问网络。

后面会重新详细介绍802.1x的认证过程-使用不同的人在方法。

参考资料：cisco AAA RADIUS TACACS+ ACS /华为AAA RADIUS HWTACACS

AAA、RADIUS、TACACS+、HWTACACS、802.1X相关推荐

无线802.1x认证服务器,TP-Link无线路由器+Radius认证服务器实现无线终端802.1X认证...
本文档详细介绍了如何在windows 2008上安装CA.NPS并配置NPS为radius服务器,实现无线客户端基于802.1X认证的步骤,其中还介绍了家用无线路由器Radius相关一些配置方法. 实 ...
H3CSE园区-AAA、RADIUS和TACACS+
PS:本篇仅挑选作者认为重要的模块,并不全面仅供复习参考,具体请自行查阅相关书籍.设有H3CNE-H3CTE学习博客专栏,敬请关注. AAA是认证.授权.计费的简称 AAA是一个综合的安全架构与其他 ...
Cisco 利用 802.1X、动态VLAN和DHCP技术实现方案
Cisco 利用 802.1X.动态VLAN和DHCP技术实现方案一.前言各行各业网络的快速发展,尤其是企业局域网的建设发生了日新月异的变化.金融业电子商务.网上办公.业务系统处理已应用工作中的 ...
五、(H3C)基于802.1x+AD+DHCP+NPS动态下发vlan 华三交换机配置
一.配置网络设备以下为拓扑图 1.配置核心交换机(华为S7712) sysname Core-Switch 更改主机名 vlan batch 31 3 ...
AAA及Radius
一.AAA(Authentication.Authorization.Accounting) 验证.授权和记费验证 Authentication :验证用户身份授权 Authorization : ...
802.1X Radius 服务器搭建
802.1X Radius 服务器搭建设备需求: l 安装Microsoft Windows 2003 Enterprise Edition Service Pack 1的PC一台 l Wirel ...
Windows Server 2008 R2Cisco2960 配置Radius服务实现802.1x认证实战
实战配置Windows Server 2008 R2 Radius服务与Cisco 2960 实现 802.1x认证实验拓扑 1.Radius服务器安装 dc 域名 wjl.com ,和ca ...
HCIE-Security Day44：AC产品概述、功能、架构组成、AC准入主要技术、RADIUS协议
什么是AC Agile Controller:敏健控制器.基于用户与应用的网络资源自动化控制系统,作为园区网络的集中化控制核心,全局控制园区网络的用户.业务与安全等策略. Agile Controll ...
定义一个圆类Circle，成员变量：半径 radius；成员方法：构造方法、get和set半径的方法、计算面积和周长的方法。
(1)定义一个圆类Circle,成员变量:半径 radius:成员方法:构造方法.get和set半径的方法. 计算面积和周长的方法.定义圆柱和圆锥类,定义相应的变量成员和成员方法.使用以 ...

AAA、RADIUS、TACACS+、HWTACACS、802.1X

一、前言

二、基本原理

三、Radius协议

四、TACACS+协议

3、TACACS+报文的类型：

认证过程：

五、HWTACACS协议

六、802.1x协议

七、EAP认证方法

八、实验

1、设备管理

AAA、RADIUS、TACACS+、HWTACACS、802.1X相关推荐

最新文章

热门文章