CmpE 208 – Presentation Report
Prof. Richard Sinn
TACACS+
(Terminal Access Controller Access-Control System Plus)
Submitted by
GROUP NAME: MARVEL
Libing Wang 005166110
Bhavana Kudipudi 005166890
MingMei Xu 005329507
Ramya Shayini 005252079
Nitin Khatri 005176835
Content
1 Introduction of TACACS+ - 2 -
2 Format and Header Values - 2 -
3 TACACS+ Communication Architecture - 2 -
4 TACACS+ Operations - 3 -
4.1 TACACS+ Authentication - 3 -
4.1.1 TACACS+ Authentication Packet - 3 -
4.1.2 TACACS+ Authentication Process - 4 -
4.2 TACACS+ Authorization - 4 -
4.2.1 TACACS+ Authorization Packet - 4 -
4.2.2 TACACS+ Authorization Process - 5 -
4.3 TACACS+ Accounting - 5 -
4.3.1 TACACS+ Accounting Packet - 5 -
4.3.2 TACACS+ Accounting Process - 6 -
5 Vulnerabilities of TACACS+ - 6 -
5.1 List of Vulnerabilities - 6 -
5.2 Fixes - 7 -
6 Conclusion - 8 -
7 Reference - 8 -
8 Appendix - 8 -
1 Introduction of TACACS+
TACACS+ is called as Terminal Access Controller Access-Control System Plus. It is an authentication protocol developed by DDN community. It uses TCP (Transmission Control Protocol) because TCP is more reliable protocol and use TCP port # 49. TACACS+ provides authentication, authorization and accounting services (AAA) separately. It is third and latest version of TACACS. The other two versions are TACACS and XTACACS respectively. TACACS+ is incompatible with other versions.
Through centralized servers, it provides control access for network access servers, routers and other network computing devices. It encrypts the traffic between NAS and daemon. It also provides remote access authentication and other services like event logging. TACACS+ offers central database that organizes and administered user passwords which provides scalability in network security solution. It also provides multi-protocol support such as Apple talk and IP. [1]
2 Format and Header Values
Every TACACS+ packet has the 12 byte header as defined below [1]:
4 / 8 / 16 / 24 / 32Major version / Minor version / Packet Type / Seq no. / Flags
Session ID
Length
¨ Major version: It is a major TACACS+ version number. MAJOR VERSION := 0xc
¨ Minor version: This is a minor TACACS+ version number. It maintains backwards compatibility and allows revisions to the TACACS+ protocol. TACACS+ MINOR VERSION := 0x0 (Default)
¨ Packet type: This is the TACACS+ packet type having following values:
TACACS+ AUTHEN := 0x01 (Authentication); TACACS+ AUTHOR :=0x02 (Authorization)
TACACS+ ACCT:=0x03 (Accounting);
¨ Seq no: This is a TACACS+ sequence number of the current packet for the current session. .
¨ Flags: The TACACS+ flags include various bitmapped flags. The flag value will tell whether the packet is encrypted or not.
¨ Session ID: The TACACS+ session id should be randomly chosen and its value will remain same throughout the TACACS+ session.
¨ Length: This is the total length of TACACS+ packet body, which means no padding beyond this limit. It does not include the header and its value must be in network byte order.
3 TACACS+ Communication Architecture
TACACS+ allows a client to accept a username and password and it will send a query to a TACACS+ authentication server which should be a program running on a host determining whether to accept or to deny the request. The server will then send back a response. The TIP will then admit access or not based upon the response from the server. So whoever is running the TACACS+ daemon controls the algorithms and data used to make the decision that is "opened up". The extension of the protocol provides more types of authentication requests and more types of response codes than were in the original specification.
TACACS+ allows a separate access server to provide the services of authentication, authorization, and accounting respectively; each of them links with its own database or uses other available services on that server or the network.
The TACACS+ communication between the network access server which is called NAS and AAA client is based on the TCP protocol. It provides a reliable method of delivery to the AAA messaging structure. TCP port 49 is utilized by TACACS+ to create a session to facilitate the messaging in an AAA exchange. The using of TCP for session control in TACACS+ provides many benefits. The first one of them is TCP provides an ACK (acknowledgement) of request which is made by NAS or an AAA client. In addition, TACACS+ has the ability, to adapt to congestion and bandwidth through TCP protocol. TACACS+ can also immediately determine to alert the AAA client of server communication issues when an AAA server is not available by using TCP resets [3].
4 TACACS+ Operations
Three possible activities can be performed during TACACS+ operation. The first is authentication operation which is used to identify the user clearly. The second one is authorization operation once a user has been identified. So the authenticate process should be prior to authorizing. The third operation is accounting that keeps track of actions that are performed. Each of the three processes is independent of the other two.
4.1 TACACS+ Authentication
The process of determining something as genuine, or making a valid & conclusive recognition of a user; is authentication. There are various types of authentication available. The traditional way of authentication requires a user name & a pre-determined password. But in many instances, fixed passwords have disadvantages. This normally arises in the field of security. Hence most modern authentication mechanisms work on the principle of either “one-time” passwords or a challenge-response query. TACACS+ is designed to operate with ease in regards to both the traditional system of authentication & the more advanced versions of it. It is also capable of integrating with any future mechanisms. Authentication is not mandatory for every site & its use is at the discretion of the site. If an individual intends to harness information that is either privileged or exclusive, then he must use the process of authentication to retrieve it.
4.1.1 TACACS+ Authentication Packet
The authentication pack works on three packets: START, CONTINUE & REPLY. The process begins when the user sends a START message to the daemon and the daemon in turn sends the REPLY message. The Continue message is also sent by the user. The START message generally contains the username & the type of authentication that needs to be performed.
TACACS+ Authentication provides the following packet:
¨ The authentication START packet body
¨ The authentication REPLY packet body
¨ The authentication CONTINUE packet body
Note: the detailed structure and description of those packet bodies are attached at the Appendix.
4.1.2 TACACS+ Authentication Process
4.2 TACACS+ Authorization
Authorization & authentication are two different concepts. While authentication verifies the validity of a user, authorization decides whether a user is allowed to perform a certain operation. While in most cases authentication is done before authorization, this need not be set in stone. TACACS+ not only provides authorization but also can customize the available services for every user individually.
Examples of when authorization would be performed are: When a user first logs in and wants to start a shell, or when a user starts PPP and wants to use IP over PPP with a particular IP address. The TACACS+ daemon might respond to these requests by allowing the service, but placing a time restriction on the login shell, or by requiring IP access lists on the PPP connection. [2]
4.2.1 TACACS+ Authorization Packet
Authorization process contains an inter-linked pair of messages, namely a REQUST & RESPONSE. TACACS+ can be used for authorization services which are remote in nature. The REQUEST message contains a fixed set of instructions that define the authenticity of the user & the variable set of arguments of the message specifies the parameters of the area he can access. This is followed by the appropriate RESPONSE.
TACACS+ Authorization provides the following packet:
¨ The authorization REQUEST packet body
¨ The authorization RESPONSE packet body
Note: the detailed structure and description of those packet bodies are attached at the Appendix.
4.2.2 TACACS+ Authorization Process
4.3 TACACS+ Accounting
Accounting follows the processes of authentication & authorization. Accounting does not require either but it begins when a user has started performing a certain action. TACACS+ maintains complete accounting information such as start, stop & intermediate usage time. This can be used either for billing purposes of the services or for security reasons. Hence TACACS+ supports all three facets of accounting. When an authentic user starts using the service provided, then the start record indicates it & similarly the stop record notifies when a service has been ended. The intermediate information is also provided periodically.
4.3.1 TACACS+ Accounting Packet
The packet format is similar to the above. It contains a fixed & an extensible portion. Similar to authorization, the extensible portion uses the same attribute-value pairs & adds several more.
TACACS+ Accounting provides the following packet:
¨ The accounting REQUEST packet body
¨ The accounting REPLY packet body
Note: the detailed structure and description of those packet bodies are attached at the Appendix.
4.3.2 TACACS+ Accounting Process
5 Vulnerabilities of TACACS+
5.1 List of Vulnerabilities
1. Lack of integrity checking
There is almost no integrity checking in TACACS+. The only check is to make sure the sum of component lengths matches the total size of the packet. Due to the nature of its encryption mechanism it allows an attacker to access the wire and flip most of the bits in the packet. The changes that can be made might include modifying the elapsed time from 8000 to 7000 with flip on one bit. The impact is that the accounting records can be altered while in transmission.
2. Vulnerability to replay attacks:
TACACS has no protection against replay attacks. As all TACACS+ sessions start with a sequence number of 1 and the server would always process a packet with the sequence number set to 1. Therefore when there are sessions which consist of only one packet sent to the server it is possible to replay the packets with certain bits flipped. The examples for such sessions are accounting sessions which have only one packet. The impact is that the duplicate accounting records can be produced, possibly with forged task_id fields to avoid detection.
3. Session ID collision:
The strength of the encryption mechanism in TACACS+ mainly depends on the session IDs. The more unique the IDs are the stronger the encryption is. But, there is a possibility that multiple sessions get the same session ID and sequence number; and this scenario is vulnerable to a simple frequency analysis attack. When there is known plaintext in one of the packets then the corresponding parts of the other session with the same sequence and session ID can be decrypted.
The TACACS+ server can encrypt a reply packet using a session ID of its own choice and due to this the encryption of most of the reply packets is compromised. This is more seen when the packets have a sequence number of 2 which are the first reply packets. We can flip a few bits in the request packet in order to make the second reply packet different from the original one and change anything in the clear text header before replay.
4. The Birthday Paradox and Session IDs:
The session IDs are too small that it is difficult to have unique session IDs when randomly chosen. Due to this reason, when there are about 100, 000 TACACS+ sessions we can see two different sessions with the same session ID. The impact is that for given enough sessions, encryption of many may be compromised.
When there are multiple accounting records sent via the TACACS+ at different stages of a user’s session there may be only 20,000 dial up sessions. With the amount of luck and the known plaintext that can be expected that and among with we would be able to get 1000 matches in a month. This can give us a few hundred user passwords!
5. Lack of padding.
One of the requirements that the implementation of the TACACS+ is that there should be no padding. This makes the attacker’s job easy as the length of the variable size data fields can be easily determined from the packet sizes. The attacker’s job would be to only find out which packets contain the information. This reveals the lengths of the user passwords.
6. MD5 context leak.
This is a theoretical vulnerability in TACACS+. Due to the presence of certain bytes in the packet, part of the packet can be decrypted. The reason for this vulnerability is the way MD5-like hashes are used.
7. Packet body length DoS and/or overflow:
This is an implementation defect unlike the others. Both the unsupported TAC_PLUS Developer's Kit vF4.0.3.alpha and Cisco IOS 11.3(9)T) turned out to be vulnerable. A trivial DoS attack on a TACACS+ server is to make it run out of memory by sending it a packet with a huge value in the length field. The impact is that TACACS+ server DoS, TACACS+ client DoS, potential break-in.
5.2 Fixes
1. Apply packet filtering where possible: It is better to have the servers and clients running in the same network and that the server can be accessed only by the IP addresses of the clients. This would need some filters on the server side and some anti-spoofing filters on the border routers.
2. Choose strong encryption keys: An encryption key is strong when it is longer than the user password as there can be an offline attack by collecting only one packet off the wire; and can be faster than similar attacks against UNIX passwords.
3. Avoid running tac_plus as root: Although not running from has some problems, it still supports the tac_plus user ID and group ID during compile time.
6 Conclusion
TACACS+ is a Cisco proprietary protocol implemented for facilitating the AAA model in Cisco devices [3]. Based on TCP, it provides the AAA communication between AAA client and AAA server. TACACS+ improves on TACACS and XTACACS by separating the functions of Authentication, Authorization and Accounting and by encrypting all traffic between the NAS and the daemon. Also, TACACS+ is more preferred compared to other protocols such as RADIUS as it uses TCP and TCP is a more reliable protocol.