TACACS+
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 Remote Authentication Dial-In User Service (RADIUS), ESBC 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 ESBC 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 (ESBC) uses Terminal Access Controller Access-Control System Plus (TACACS+) authentication services solely for the authentication of user accounts. Administrative users must be authenticated locally by the ESBC.
The current TACACS+ implementation supports three types of user authentication: simple password (referred to as ascii by TACACS+), PAP, and CHAP.
ASCII Log In
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 Log In
Password Authentication Protocol (PAP) is defined in RFC 1334, PPP Authentication Protocols. PAP offers minimal security because passwords are transmitted as unprotected clear text. PAP log in differs from ASCII log in because 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 log in.
CHAP Log In
- After a login attempt, the authenticator tests the initiator by responding 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 Terminal Access Controller Access-Control System Plus (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
When sending the Authorization query to the TACACS+ server, by default the ESBC sends everything typed at the ACLI in the
cmd
parameter. For commands, this includes the command plus all of its
arguments (for example, cmd=show interfaces brief
). For configurations, this
includes the full path of the configuration element plus its attributes and values (for
example, cmd=configure terminal security authentication type tacacs
). In the
TACACS+ query, the cmd-arg
parameter is set to <cr>
.
The parameter tacacs-authorization-arg-mode changes this default behavior. Parameter values, and their behavior with respect to splitting the entry values include:
- disabled—Retain default behavior.
- enabled—Applies the fully split cmd and cmd-arg
behavior to all ACLI input through TACACS+, with the exception of the
show command. Behavior includes:
- All show commands follow the pattern:
cmd=show <required-word>
,cmd-arg=<optional-word1>
,cmd-arg=<optional-word2>
, and so on. If no optional words are used, thecmd-arg
parameter is set to<cr>
.For example:
cmd=show uptime, cmd-arg=<cr> cmd=show tacacs, cmd-arg=stats cmd=show running-config, cmd-arg=authentication, cmd-arg=to-file, cmd-arg=auth.conf
- All other commands follow the pattern:
cmd=<first-word>
,cmd-arg=<second-word>
,cmd-arg=<third-word>
, and so on. If the command is a single-word command, thecmd-arg
parameter is set to<cr>
.For example:
cmd=verify-config, cmd-arg=<cr> cmd=configure, cmd-arg=terminal cmd=ssh-key, cmd-arg=authorized-key, cmd-arg=import, cmd-arg=admin, cmd-arg=admin
- All configurations follow one of two patterns:
- For navigating the ACLI:
cmd=<full-path>
,cmd-arg=<cr>
. - For setting an attribute to a value:
cmd=<full-path> <attribute>
,cmd-arg=<value>
For example, the following ACLI interaction produces this sequence of TACACS+ queries.
ORACLE# conf term ORACLE(configure)# security ORACLE(security)# authentication ORACLE(authentication)# select ORACLE(authentication)# type tacacs
cmd=configure, cmd-arg=terminal cmd=configure terminal security, cmd-arg=<cr> cmd=configure terminal security authentication, cmd-arg=<cr> cmd=configure terminal security authentication select, cmd-arg=<cr> cmd=configure terminal security authentication select type, cmd-arg=tacacs
- For navigating the ACLI:
- All show commands follow the pattern:
- enabled-for-show—Applies the fully split cmd and cmd-arg behavior
to all ACLI input through TACACS+, including the show command.
- All show commands follow the pattern:
cmd=show
,cmd-arg=<required-word>
,cmd-arg=<optional-word1>
,cmd-arg=<optional-word2>
, and so on. If no optional words are used, thecmd-arg
parameter is set to<cr>
.For example:
cmd=show, cmd-arg=uptime cmd=show, cmd-arg=tacacs, cmd-arg=stats cmd=show, cmd-arg=running-config, cmd-arg=authentication, cmd-arg=to-file, cmd-arg=auth.conf
- All configurations follow one of two patterns presented above in the explanation of the enabled value.
- All show commands follow the pattern:
Authorization Message Exchange
All Terminal Access Controller Access-Control System Plus (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 Terminal Access Controller Access-Control System Plus (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 Terminal Access Controller Access-Control System Plus (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 (ESBC). 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 ESBC 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 ESBC sends an accounting REQUEST WATCHDOG packet requesting accounting of the ACLI command. As the ESBC 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 ESBC sends an accounting REQUEST STOP packet.
- The daemon responds with an accounting REPLY packet, indicating that accounting stopped.
TACACS+ Configuration
Configuration of Terminal Access Controller Access-Control System Plus (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).
Managing TACACS+ Operations
Terminal Access Controller Access-Control System Plus (TACACS+) management is supported by the following utilities.
TACACS+ MIB
An Oracle proprietary MIB provides external access to Terminal Access Controller Access-Control System Plus (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 Terminal Access Controller Access-Control System Plus (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 (ESBC) supports (TACACS+) traps to notify you of operational status. Traps from the apSysMgmt tree include:
- apSysMgmtTacacsDownTrap (1.3.6.1.4.1.9148.3.2.6.0.78) - Generated when a TACACS+ server becomes unreachable.
- apSysMgmtTacacsDownClearTrap (1.3.6.1.4.1.9148.3.2.6.0.79) - Generated when a TACACS+ server that was unreachable becomes reachable.
The ESBC searches for a TACACS+ server until it finds an available one and then stops searching. However, in the TACACS+ SNMP implementation, SNMP expects the ESBC to make connection attempts to all servers.
- When there is only one TACACS+ server and that server goes down, the ESBC 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.
Traps from the apSecurity tree include:
- apSecurityTacacsFailureNotification (1.3.6.1.4.1.9148.3.9.3.1.0.4) - Generated when the system detects TACACS daemon reachability changes as well as TACACS authentication and authorization errors.
- apSecurityTacacsDownLocalAuthUsedTrap (1.3.6.1.4.1.9148.3.9.3.9.0.1) - Generated when a user remotely logs into a system configured for TACACS+ authentication and is authenticated locally by the system because all of the configured and enabled TACACS+ servers have become unreachable or unresponsive
- apSecurityTacacsDownLocalAuthUsedClearTrap (1.3.6.1.4.1.9148.3.9.3.9.0.2) - Generated when a user remotely logs into a system configured for TACACS+ authentication and is successfully authenticated (i.e., access accepted or denied) remotely by a configured and enabled TACACS+ server.
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