• 文章搜索:
  • 目录

        • 分享到...

        • 新浪微博
        • 腾讯微博
        • 推荐到豆瓣 豆瓣空间
        • 分享到搜狐微博 搜狐微博
        • 分享到QQ空间 QQ空间
        • 分享到腾讯朋友 腾讯朋友
        • 网易微博分享 网易微博
        • 添加到百度搜藏 百度搜藏
        • 转贴到开心网 开心网
        • 转发好友 告诉聊友
    • 推荐
    • 打印
    • 收藏

    TACACS+技术

    作者:  |  上传时间:2013-09-16  |  关键字: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种类型的消息:

    1、Authentication_START

    2、Authentication_CONTIUNE

    3、Authentication_REPLY

    4、Authorization_REQUEST

    5、Authorization_RESPONSE

    6、Accounting_REQUEST

    7、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+支持除包头之外所有信息的加密,加密方法如下:

    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,窃听者无法根据报文的内容来猜测网络的配置和用户的身份。

    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+实现都包括下面的内容:

    1、计费停止报文的缓存和重传机制;

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

    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

    #