TACACS+ AAA
TACACS+ (Terminal Access Controller Access Control System Plus) is a protocol originally developed by Cisco Systems, and made available to the user community by a draft RFC, TACACS+ Protocol, Version 1.78 (draft-grant-tacacs-02.txt). TACACS+ provides AAA (Authentication, Authorization, and Accounting) services over a secure TCP connection using Port 49.
TACACS+ Overview
Like DIAMETER and RADIUS, TACACS+ uses a client/server model in which a Network Access Server (NAS) acts in the client role and a TACACS+ equipped device (a daemon in TACACS+ nomenclature) assumes the server role. For purposes of the current implementation, the Oracle® Enterprise Session Border Controller functions as the TACACS+ client. Unlike RADIUS, which combines authentication and authorization, TACACS+ provides three distinct applications to provide finer grade access control.
Authentication is the process that confirms a user’s purported identity. Authentication is most often based on a simple username/password association, but other, and more secure methods, are becoming more common. The following authentication methods are support by the current implementation: simple password, PAP (Protocol Authentication Protocol), and CHAP (Challenge Handshake Authentication Protocol).
Authorization is the process that confirms user privileges. TACACS+ can provide extremely precise control over access to system resources. In the current implementation, TACACS+ controls access to system administrative functions.
TACACS+ provides secure communication between the client and daemon by encrypting all packets. Encryption is based on a shared-secret, a string value known only to the client and daemon. Packets are encrypted in their entirety, save for a common TACACS+ header.
The cleartext header contains, among other fields, a version number, a sequence number. and a session ID. Using a methodology described in Section 5 of the TACACS+ draft RFC, the sender encrypts outbound cleartext messages by repetitively running the MD5 hash algorithm over the concatenation of the session ID, shared-secret, version number, and sequence number values, eventually deriving a virtual one-time-pad of the same length as the message body. The sender encrypts the cleartext message with an XOR (Exclusive OR) operation, using the cleartext message and virtual one-time-pad as inputs.
The message recipient, who possesses the shared-secret, can readily obtain the version number, sequence number, session ID, and message length from the cleartext header. Consequently, the recipient employs the same methodology to derive a virtual one-time-pad identical to that derived by the sender. The recipient decrypts the encrypted message with an XOR operation, using the encrypted message and virtual one-time-pad as inputs.
Details on the TACACS+ functions and configuration can be found in the Oracle Communications Session Border Controller ACLI Configuration Guide.
The TACACS+ implementation is based upon the following internet draft.
draft-grant-tacacs-02.txt, The TACACS+ Protocol Version 1.78
Other relevant documents include
RFC 1321, The MD-5 Message Digest Algorithm
RFC 1334, PPP Authentication Protocols .
RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP)
Note:
TACACs documentation in this guide excludes per-message definitions that duplicate IETF standards documentation.TACACS+ Administrative Security
Oracle® Enterprise Session Border Controllers use either the RADIUS (Remote Authentication Dial-In User Service) or the TACACS+ (Terminal Access Control Access Control System Plus) protocol for centralized access control administration; however, prior to this release, you could connect to the TACACS+ server only from the system's media interfaces. This feature implements TACACS+ authorization (user permissions management on a command basis), authentication (user management), and accounting on management interfaces.
TACACS+ Authentication
The Oracle® Enterprise Session Border Controller uses TACACS+ authentication services solely for the authentication of user accounts. Administrative users must be authenticated locally by the Oracle® Enterprise Session Border Controller.
The current TACACS+ implementation supports three types of user authentication: simple password (referred to as ascii by TACACS+), PAP, and CHAP.
ascii Login
ascii login is analogous to logging into a standard PC. The initiating peer is prompted for a username, and, after responding, is then prompted for a password.
PAP Login
PAP is defined in RFC 1334, PPP Authentication Protocols. This protocol offers minimal security in that passwords are transmitted as unprotected cleartext. PAP login differs from ascii login in that the username and password are transmitted to the authenticating peer in a single authentication packet, as opposed to the two-step prompting process used in ascii login.
CHAP Login
CHAP is defined in RFC 1994, PPP Challenge Handshake Authentication Protocol. CHAP is a more secure than PAP in that it is based on a shared-secret (known only to the communicating peers), and therefore avoids the transmission of cleartext authentication credentials. CHAP operations can be summarized as follows.
After a login attempt, the initiator is tested by the authenticator who responds with a packet containing a challenge value — an octet stream with a recommended length of 16 octets or more. Receiving the challenge, the initiator concatenates an 8-bit identifier (carried within the challenge packet header), the shared-secret, and the challenge value, and uses the shared-secret to compute an MD-5 hash over the concatenated string. The initiator returns the hash value to the authenticator, who performs the same hash calculation, and compares results. If the hash values match, authentication succeeds; if hash values differ, authentication fails.
Authentication Message Exchange
All TACACS+ authentication packets consist of a common header and a message body. Authentication packets are of three types: START, CONTINUE, and REPLY.
START and CONTINUE packets are always sent by the Oracle® Enterprise Session Border Controller, the TACACS+ client. START packets initiate an authentication session, while CONTINUE packets provide authentication data requested by the TACACS+ daemon. In response to every client-originated START or CONTINUE, the daemon must respond with a REPLY packet. The REPLY packet contains either a decision (pass or fail), which terminates the authentication session, or a request for additional information needed by the authenticator.
TACACS+ Authorization
The Oracle® Enterprise Session Border Controller uses TACACS+ services to provide administrative authorization. With TACACS+ authorization enabled, each individual ACLI command issued by an admin user is authorized by the TACACS+ authorization service. The Oracle® Enterprise Session Border Controller replicates each ACLI command in its entirety, sends the command string to the authorization service, and suspends command execution until it receives an authorization response. If TACACS+ grants authorization, the pending command is executed; if authorization is not granted, the Oracle® Enterprise Session Border Controller does not execute the ACLI command, and displays an appropriate error message.
The daemon’s authorization decisions are based on a database lookup. Data base records use regular expressions to associate specific command string with specific users. The construction of such records is beyond the scope of this document.
TACACS+ Authorization Command & Arguments Boundary
Each TACACS+ authorization entry on an ACLI command line comprises the command and its arguments. Currently everything typed as a TACACS+ authorization command by an authenticated admin user, including the arguments, is sent to the TACACS+ server in the command field of the TACACS+ message; the argument field in the TACACS+ message contains no arguments and is set to “cmd-arg=<CR>”. This feature adds the new parameter tacacs-authorization-arg-mode to the authentication configuration element, which enables the TACACS+ authorization command and its arguments to be sent to the TACACS+ server separately.
Authorization Message Exchange
All TACACS+ authorization packets consist of a common header and a message body. Authorization packets are of two types: REQUEST and RESPONSE.
The REQUEST packet, which initiates an authorization session, is always sent by the Oracle® Enterprise Session Border Controller. Upon receipt of every REQUEST, the daemon must answer with a RESPONSE packet. In the current TACACS+ implementation, the RESPONSE packet must contain an authorization decision (pass or fail). The exchange of a single REQUEST and the corresponding RESPONSE completes the authorization session.
TACACS+ Accounting
The Oracle® Enterprise Session Border Controller uses TACACS+ accounting to log administrative actions. With accounting enabled, each individual ACLI command executed by an admin user is logged by the accounting service.
Accounting Message Exchange
All TACACS+ accounting packets consist of a common header and a message body. Accounting packets are of two types: REQUEST and REPLY.
The REQUEST packet has three variant forms. The START variant initiates an accounting session; the STOP variant terminates an accounting session; the WATCHDOG variant updates the current accounting session. REQUEST packets are always sent by the Oracle® Enterprise Session Border Controller. Upon receipt of every REQUEST, the daemon must answer with a REPLY packet.
A TACACS+ accounting session proceeds as follows.
- Immediately following successful authorization of an admin user, the Oracle® Enterprise Session Border Controller sends an accounting REQUEST START packet.
- The daemon responds with an accounting REPLY packet, indicating that accounting has started.
- For each ACLI command executed by an admin user, the Oracle® Enterprise Session Border Controller sends an accounting REQUEST WATCHDOG packet requesting accounting of the ACLI command. As the Oracle® Enterprise Session Border Controller sends the WATCHDOG only after an admin user’s access to the ACLI command is authorized, the accounting function records only those commands executed by the user, not those commands for which authorization was not granted.
- The daemon responds with an accounting REPLY packet, indicating that the ACLI operation has been recorded by the accounting function.
- Steps 3 and 4 are repeated for each authorized ACLI operation.
- Immediately following logout (or timeout) of an admin user, the Oracle® Enterprise Session Border Controller sends an accounting REQUEST STOP packet.
- The daemon responds with an accounting REPLY packet, indicating that accounting has stopped.
TACACS+ Configuration
Configuration of TACACS+ consists of the following steps.
- Enable TACACS+ client services
- Specify one or more TACACS+ servers (daemons)
Enable TACACS+ Client Services
Use the following procedure to enable specific TACACS+ client AAA services.
Specify TACACS+ Servers
Use the following procedure to specify one or more TACACS+ servers (daemons).
TACACS+ MIB
An Oracle proprietary MIB provides external access to TACACS+ statistics.
MIB counters are contained in the apSecurityTacacsPlusStatsTable that is defined as follows.
SEQUENCE {
apSecurityTacacsPlusCliCommands Counter32
apSecurityTacacsPlusSuccess Authentications Counter32
apSecurityTacacsPlusFailureAuthentications Counter32
apSecurityTacacsPlusSuccess Authorizations Counter32
apSecurityTacacsPlusFailureAuthorizations Counter32
}
apSecuritysTacacsPlusStats Table (1.3.6.1.4.1.9148.3.9.9.4)
| Object Name | Object OID | Description |
|---|---|---|
| apSecurityTacacsCliCommands | 1.3.6.1.4.1.9148.3.9.1.4.3 | Global counter for ACLI commands sent to TACACS+ Accounting |
| apSecurityTacacsSuccess Authentications | 1.3.6.1.4.1.9148.3.9.1.4.4 | Global counter for the number of successful TACACS+ authentications |
| apSecurityTacacsFailureAuthentications | 1.3.6.1.4.1.9148.3.9.1.4.5 | Global counter for the number of unsuccessful TACACS+ authentications |
| apSecurityTacacsSuccess Authorizations | 1.3.6.1.4.1.9148.3.9.1.4.6 | Global counter for the number of successful TACACS+ authorizations |
| apSecurityTacacsFailure Authorizations | 1.3.6.1.4.1.9148.3.9.1.4.7 | Global counter for the number of unsuccessful TACACS+ authorizations |
SNMP Trap
SNMP traps are issued when
- a TACACS+ daemon becomes unreachable
- an unreachable TACACS+ daemon becomes reachable
- an authentication error occurs
- an authorization error occurs
TACACS+ Faults
The Oracle® Enterprise Session Border Controller supports two TACACS+ traps, apSysMgmtTacacsDownTrap and apSysMgmtTacacsDownClearTrap.
The apSysMgmtTacacsDownTrap is generated when a TACACS+ server becomes unreachable.
The apSysMgmtTacacsDownClearTrap is generated when a TACACS+ server that was unreachable becomes reachable.
The E-SBC searches for a TACACS+ server until it finds an available one and then stops searching. However, in the TACACS+ SNMP implementation, SNMP expects the E-SBC to make connection attempts to all servers. When there is only one TACACS+ server and that server goes down, the E-SBC behaves normally, sending a apSysMgmtTacacsDownTrap trap when the server goes down, and a apSysMgmtTacacsDownClearTrap trap when the server comes back up. When there is more than one TACACS+ server and the active server goes down, an apSysMgmtTacacsDownTrap trap is sent, indicating that some servers are down and the next server is tried. If all servers fail, an apSysMgmtTacacsDownTrap is sent indicating that all servers are down. If one of the servers comes back up while the rest are still down, an apSysMgmtTacacsDownTrap is sent indicating that some servers are still down.
ACLI show Command
The show tacacs stats command displays the following statistics.
- number of ACLI commands sent for TACACS+ accounting
- number of successful TACACS+ authentications
- number of failed TACACS+ authentications
- number of successful TACACS+ authorizations
- number of failed TACACS+ authentications
- the IP address of the TACACS+ daemon used for the last transaction
