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

#