TACACS+简单说明

1 TACACS+概述

1.1 什么是TACACS+

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

1.2 TACACS+的用途

TACACS+协议主要用于PPP和VPDN（Virtual Private Dial-up Network，虚拟私有拨号网络）接入用户及终端用户的AAA。

AAA是Authentication、Authorization、Accounting（认证、受权、计费）的简称，是网络安全的一种管理机制，提供了认证、受权、计费三种安全功能。

认证：确认访问网络的远程用户的身份，判断访问者是否为合法的网络用户。

受权：对不一样用户赋予不一样的权限，限制用户可使用的服务。例如用户成功登陆服务器后，管理员能够受权用户对服务器中的文件进行访问和打印操做。

计费：记录用户使用网络服务中的全部操做，包括使用的服务类型、起始时间、数据流量等，它不只是一种计费手段，也对网络安全起到了监视做用。

AAA通常采用客户机/服务器结构，客户端运行于NAS（Network Access Server，网络接入服务器）上，服务器上则集中管理用户信息。NAS对于用户来说是服务器端，对于服务器来讲是客户端。AAA的基本组网结构以下图：

当用户想要经过某网络与NAS创建链接，从而得到访问其它网络的权利或取得某些网络资源的权利时，NAS起到了验证用户的做用。NAS负责把用户的认证、受权、计费信息透传给服务器（RADIUS服务器或HWTACACS服务器），RADIUS协议或HWTACACS协议规定了NAS与服务器之间如何传递用户信息。

图1-1的AAA基本组网结构中有两台服务器，用户能够根据实际组网需求来决定认证、受权、计费功能分别由使用哪一种协议类型的服务器来承担。例如，能够选择HWTACACS服务器实现认证和受权，RADIUS服务器实现计费。

固然，用户也能够只使用AAA提供的一种或两种安全服务。例如，公司仅仅想让员工在访问某些特定资源的时候进行身份认证，那么网络管理员只要配置认证服务器就能够了。可是若但愿对员工使用网络的状况进行记录，那么还须要配置计费服务器。

TACACS+的典型应用是对须要登陆到设备上进行操做的终端用户进行认证、受权、计费。设备做为TACACS+的客户端，将用户名和密码发给TACACS+服务器进行验证。用户验证经过并获得受权以后能够登陆到设备上进行操做。

2 TACACS+和RADIUS的比较

从上面的描述来看，TACACS+和目前被普遍使用的RADIUS很类似，那么他们有什么区别和联系呢？下面这个表格能够说明这个问题：

TACACS+协议

RADIUS协议

使用TCP，网络传输更可靠

使用UDP，网络传输效率更高

除了TACACS+报文头，对报文主体所有进行加密

只对验证报文中的密码字段进行加密

协议报文较为复杂，认证和受权分离，使得认证、受权服务能够分离在不一样的安全服务器上实现。例如，能够用一个TACACS+服务器进行认证，另一个TACACS+服务器进行受权

协议报文比较简单，认证和受权结合，难以分离

支持对设备的配置命令进行受权使用。用户可以使用的命令行受到用户级别和AAA受权的双重限制，某一级别的用户输入的每一条命令都须要经过TACACS+服务器受权，若是受权经过，命令就能够被执行

不支持对设备的配置命令进行受权使用

用户登陆设备后可使用的命令行由用户级别决定，用户只能使用缺省级别等于/低于用户级别的命令行

3 TACACS+的基本原理

3.1 TACACS+的基本消息交互流程

下图是TACACS+协议的基本信息交互流程：

以Telnet用户认证过程为例，基本消息交互流程以下：

(1) Telnet用户请求登陆设备。

(2) TACACS+客户端收到请求以后，向TACACS+服务器发送认证开始报文。

(3) TACACS+服务器发送认证回应报文，请求用户名。

(4) TACACS+客户端收到回应报文后，向用户询问用户名。

(5) 用户输入用户名。

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

(7) TACACS+服务器发送认证回应报文，请求登陆密码。

(8) TACACS+客户端收到回应报文，向用户询问登陆密码。

(9) 用户输入密码。

(10) TACACS+客户端收到登陆密码后，向TACACS+服务器发送认证持续报文，其中包括了登陆密码。

(11) TACACS+服务器发送认证回应报文，指示用户经过认证。

(12) TACACS+客户端向TACACS+服务器发送受权请求报文。

(13) TACACS+服务器发送受权回应报文，指示用户经过受权。

(14) TACACS+客户端收到受权回应成功报文，向用户输出设备的配置界面。

(15) TACACS+客户端向TACACS+服务器发送计费开始报文。

(16) TACACS+服务器发送计费回应报文，指示计费开始报文已经收到。

(17) 用户请求断开链接。

(18) TACACS+客户端向TACACS+服务器发送计费结束报文。

(19) TACACS+服务器发送计费结束报文，指示计费结束报文已经收到。

4 TACACS+的报文结构和具体工做过程

4.1 TACACS+的报文类型

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

一、Authentication_START

二、Authentication_CONTIUNE

三、Authentication_REPLY

四、Authorization_REQUEST

五、Authorization_RESPONSE

六、Accounting_REQUEST

七、Accounting_REPLY

4.2 TACACS+包头

全部的TACACS+数据包都使用12字节长的包头，结构以下：

图1 TACACS+包头

图2 TACACS+包头（实例）

下面对各个字段分别进行说明：

Major version的取值为0x0C

Minor version通常为0，一些特殊场景取值为1，本文后面会有说明

Type为1表示认证，2表示受权，3表示计费

Seq_no，序列号，从1开始，随报文交互递增

Flags，用来表示一些特殊条件，好比不加密（0x01），支持单链接多会话（0x04）等

Session_id为TACACS+会话的ID，是个随机数。

Length为TACACS+报文除头部以外的长度

4.3 TACACS+数据包的加密

TACACS+支持除包头以外全部信息的加密，加密方法以下：

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

二、后续的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}

三、将全部的运算结果链接起来，直到总长度大于须要加密的数据的长度，而后截断到实际数据的长度，获得pseudo_pad：

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

四、随后将须要加密的数据和上面的pseudo_pad进行XOR运算，获得密文：

ENCRYPTED {data} == data ^ pseudo_pad

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

4.4 Authentication 消息

Authentication 消息包括三种类型：START、CONTINUE和REPLY。

4.4.1 Authentication Start

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

START消息通常来讲是认证过程的第一个数据包，其seq_no老是1。

若是收到RESTART消息，客户端须要发送START消息从新开始认证（使用一个新的会话）。

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

图3 Authentication Start消息

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

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

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

Service字段表示服务类型。

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

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

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

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

4.4.2 Authentication Reply

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

图4 Authentication Reply消息

Status字段表示认证的状态。

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

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

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

4.4.3 Authentication Continue

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

图5 Authentication Continue消息

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

flags字段用于中断认证过程

4.5 TACACS+认证过程

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

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

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

4.5.1 Enable Requests

Enable Requests一般用于提高当前用户的级别的场合，好比Linux系统的su命令，Comware的super命令等，认证过程和后面立刻要讲到的Inbound ASCII Login很类似

Action = TAC_PLUS_AUTHEN_LOGIN

priv_lvl = implementation dependent

authen_type = not used

service = TAC_PLUS_AUTHEN_SVC_ENABLE

4.5.2 Inbound ASCII Login

管理用户login的场景，很是常见，该场景下START消息能够携带用户名，整个交互过程包括一个START，中间可能存在一对或多对CONTINUE/REPLY，最后以一个REPLY结束

action = TAC_PLUS_AUTHEN_LOGIN

authen_type = TAC_PLUS_AUTHEN_TYPE_ASCII

4.5.3 Inbound CHAP login

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

Action = TAC_PLUS_AUTHEN_LOGIN

authen_type = TAC_PLUS_AUTHEN_TYPE_CHAP

minor_version = 0x1

4.5.4 具体认证过程

以下是Comwarev5平台Telnet用户使用HWTACACS认证过程：

AUTHEN_REQUEST ------------->

<------------- AUTHEN_REPLY（status:AUTHEN_STATUS_GETPASS）

AUTHEN_CONTINUE（with password） ------------->

<------------- AUTHEN_REPLY（status:AUTHEN_STATUS_PASS）

4.5.5 认证过程的停止

客户端能够经过在CONTINUE消息中携带一个TAC_PLUS_CONTINUE_FLAG_ABORT标志位来停止正在进行的认证过程，同时能够在data字段携带停止认证的缘由。该CONTINUE消息不须要REPLY消息的回应。

4.6 Authorization消息

Authorization 消息包括两种类型：REQUEST和RESPONSE。

4.6.1 Authorization Request

Authorization Request消息的机构比较复杂，以下：

图6 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是可选的。

AVP的类型不少，这里就不一一列举了。

4.6.2 Authorization Response

Authorization Response消息的结构以下：

图7 Authorization Response消息

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

status字段表示受权的结果和权限的操做方式

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

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

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

4.7 具体受权过程

4.7.1 Comwarev5设备使用HWTACACS认证/受权

AUTHOR_REQUEST ------------->

<------------- AUTHOR_REPLY（status:AUTHOR_STATUS_PASS_ADD）

4.8 Accounting消息

Accounting消息包括两种类型：REQUEST和REPLY。

4.8.1 Accounting Request

Accounting Request消息的结构以下：

图8 Accounting Request消息

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

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

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

Accounting REQUEST消息中也能够携带不少AVP形式的参数，参数的数量不少，这里就不一一列举了。

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

4.8.2 Accounting Reply

Accounting Reply消息的结构以下：

图9 Accounting Reply消息

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

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

4.9 具体计费过程

4.9.1 Comwarev5设备使用HWTACACS进行PPP用户计费

下面是Comwarev5设备使用HWTACACS进行PPP用户计费的过程，包括计费开始，计费持续和计费中止的全过程。

ACCOUNTING_REQUEST（flag:ACCT_FLAG_START ------------->

<------------- ACCOUNTING_REPLY（status:ACCT_STATUS_SUCCESS）

ACCOUNTING_REQUEST（flag:ACCT_FLAG_WATCHDOG） ------------->

<------------- ACCOUNTING_REPLY（status:ACCT_STATUS_SUCCESS）

ACCOUNTING_REQUEST（flag:ACCT_FLAG_STOP） ------------->

<------------- ACCOUNTING_REPLY（status:ACCT_STATUS_SUCCESS）

4.10 TACACS+的附加功能

除了正常的AAA功能外，为确保功能实现的冗余和实时计费准确性等等，不少TACACS+实现都包括下面的内容：

一、计费中止报文的缓存和重传机制；

二、认证、受权、计费服务器的主备切换功能。

4.11 Tacacs in Comware（以V5为例）

Comware v5的HWTACACS功能基本上实现了TACACS+所规定的功能：

#

hwtacacs scheme tacacs

primary authentication 101.3.201.1

primary authorization 101.3.201.1

primary accounting 101.3.201.1

key authentication h3c

key authorization h3c

key accounting h3c

timer realtime-accounting 3

user-name-format without-domain

#