If the query Service-Type = Exec-User, is presented it will be in the character mode and if the requests Service-Type = Framed-User and Framed-Type = PPP, are presented they are in the packet mode. The primary characteristic that differs character mode from the packet mode is the fact that character mode allows a network administrator with a large number of routers in a network to authenticate one time as the user, and then access all routers configured in this method.


AAA Protocols: RADIUS and TACACS+

TACAS+ and RADIUS are the two best know types of AAA protocols. TACAS+ is a newer version of TACAS and XTACAS. There are inherent difference between TACAS+ and RADIUS which make them suitable for particular type of different situations. To exemplify, TACAS+ is  a proprietary of Cisco Sstems Technology and RADIUS is of Internet Engineering Task Force (IETF). Another difference is that TACAS+ operates in TCP environment while RADIUS operates in UDP environment.

TACAS+ being a proprietary of Cisco has many benefits which fare it better over RADIUS when it comes to management and terminal services. TACAS+ can control the authorization level of users, while RADIUS cannot. TACAS+ can also be used for authorization and accounting using a different method like Kerberos for authentication. This is possible because TACAS+ separates authentication and authorization.


Understanding RADIUS

This is a client or a server system securing network against unauthorized access and run on supported Cisco devices. It works by sending authentication requests to a central RADIUS server. This central server contains all information regarding user authentication and network access.  It is most suitable in the network environments which have

  • Multiple-vendor access servers, with a pre requisite that they all support RADIUS;
  • Networks that need resource accounting. The RADIUS accounting can be used independently of authorization and authentication;
  • Turnkey network security environments, in which applications support the RADIUS protocol.

This system is not suitable for networks with:

  • Multiprotocol access environments;
  • Router to router or switch to switch situations as it does not support two way authentication.


Operation of RADIUS

RADIUS is an access server that using the AAA protocol. It is a system following a pattern of distributed security, securing remote access to networks and network services against unauthorized access. It comprises of three components:

  • A protocol with a frame format that utilizes User Datagram Protocol (UDP)/IP.
  • A server.
  • A client.

The server is a central computer running at the customer’s site. The clients are in the dialup access servers. They are distributed through the entire network. Cisco has incorporated the RADIUS Client into Cisco IOS Software Release 11.1 and later and other device software. The steps that are undertaken when a wireless user attempts to log in and authenticate are shown in the figure below.

  • Client/Server Model: NAS (Network Access Server) serves as a client of RADIUS. The client passes the information of the user to a RADIUS server that has been designated. It acts on the response that it receives back. The servers primarily perform the following function – receive user connection requests, authenticate the user, send back configuration information. They can also act as proxy clients.    
  • Network Security: The client and the RADIUS server authenticate the information by use of shared information which is secret in nature as it is never sent over the network. All the user passwords between the two are sent in an encrypted form. This enables keeping the chances of password leakage to the minimum. 
  • Flexible Authentication Mechanisms: The server supports multiple methods to authenticate a user. It can support PPP, PAP (Password Authentication Protocol), Unix login as authentication mechanisms. 

Server Code Availability: There are multiple distributions of server codes available. Some of these are Cisco Secure ACS for Windows, Cisco Secure ACS for UNIX, and Cisco Access Registrar.


Features of Radius and Tacacs Fig 1 
Figure 1: Sequence for EAP Authentication

RADIUS Messages

There are four types of RADIUS message :

  • Access-Request: This contains AV pairs for the username, password and additional information such as NAS port. The username and the password is the information that will be encrypted by RADIUS.
  • Access-Challenge: These messages become necessary for challenge-based authentication methods. An examples of such method is and Extensible Authentication Protocol-Message Digest 5 (EAP-MD5)
  • Access-Accept: This is the positive answer. It is sent if the user information is valid
  • Access-Reject: This is a negative reply which is sent if the user information is invalid


RADIUS Attributes and Features

  • RADIUS messages contain zero or more AV-pairs, for example: User-Name, User-Password,  CHAP-Password etc;
  • Approximately 50 standard-based attributes (RFC 2865) are there in RADIUS;
  • Proprietary attributes are allowed by RADIUS;
  • For the purposes of authentication basic attributes are used;
  • For the purposes of authorization most other attributes are used.

The most notable limitations of RADIUS are:

  • Security features are limited;
  • Authentication and authorization are combined in one function

TACAS+ offered by Cisco claims along with dealing with the limitations of RADIUS also provides additional features.


Understanding TACAS+

TACAS+ like RADIUS is a security application providing centralized validation of users. It differs from RADIUS in its scope as it does not authenticate client devices which are associated to the access point. Separate authentication, authorization and accounting facilities are provided by TACAS+ allowing for a single access control server for each of the services independently. Each service can be tied to its own database. It is a primary protocol for Cisco AAA implementations and is supported on IOS routers, switches, and the Cisco PIX Firewall.

TACAS+ through AAA provides the following:

  • Authentication: It ensures complete control of authentication of administrators. This is done through the password dialog, challenge and response.
  • Authorization: It provides control over the administrator capabilities for the entire duration of the administration session. Along with that restrictions can be imposed on the commands that can be executed by the administrator.
  • Accounting: Information is collected and used for the purposes of billing, auditing and reporting. This can also be used for conducting a security audit.

A TACACS+ daemon software is a prerequisite for using TACACS+ on your access point.

Operation of TACAS+
The process occurs in three stages:
1.       Establishment of connection: The access point contacts the TACAS+ daemon to obtain a user name prompt, which is then displayed to the administrator. The username is entered by the administrator and the access point contacts the TACAS+ daemon for the password prompt.  The prompt is displayed to the administrator and once the password is punched in the same is sent to the daemon.

2.       Responding to Authentication: The access point then receives a responses from the TACAS+ daemon. The response could convey ACCEPT (meaning authentication done, service can begin), REJECT (administrator not authenticated) ERROR (an error occurred during authentication) CONTINUE (the administrator is prompted for additional information)

3.      Authorization: In case TACAS+ authorization is required, the daemon is once again contacted. At this stage the response could be ACCEPT or REJECT. In case the response is ACCEPT, the response contains data in the form of attributes, directing the EXEC or NETWORK session for that administrator. It determines which services the administrator can access.

·         Connection parameters;
·         Telnet, rlogin or privileged EXEC services.


TACACS+ Attributes and Features

TACAS+ attributes are used for authentication and authorization. Some of the examples for which it is used are:

  • ACL (EXEC Authorization): In this it contains an access-class number which is applied to a line.
  • ADDR (SLIP, PPP/IP Authorization): In this type of authorization, the IP address of the remote host is specified. It is the address that should be assigned when using a SLIP or PPP/IP connection.
  • CMD (EXEC): For this type of authorization, the AV pair is used. It is used for starting an authorization request for an EXEC command.
  • Priv-lvl (EXEC Authorization): In Priv-lvl authorization, it specifies the current privilege level for command authorizations, which is a number from 0 to 15.
  • Route (PPP/IP, SLIP Authorization): In this authorization a route that has to be applied to an interface is specified.
  • InACL (PPP/IP, SLIP Authorization): Contains an inbound IP ACL for SLIP or PPP/IP connections.
  • OutACL: This category of authorization contains an outbound IP ACL for SLIP or PPP/IP.
  • Addr-pool: In this form of authorization, a name of a local address pool is specified. The address pool supplies the destination from where to get the address of the remote host.
  • Autocmd: This specifies a command to be automatically executed at EXEC startup.

Many other attributes exist for most network applications, such as dial-in solutions, proxy-authentication on firewalls, or command authorization for Cisco devices.

UDP and TCP 

The major difference between the two is that User Datagram Protocol is used by RADIUS, whilst Transmission Control Protocol is used by TACACS+. UDP has several drawbacks as compared to TCP. Whereas UDP offers best effort delivery, TCP is a connection oriented transport. Additional variables which are programmable are required by RADIUS. These variables include time-outs which are required to account for in lieu of the best-effort transport. However the TCP transport provides much better built in support which is not the case in UDP

  • TCP provides for a separate acknowledgment conveying that a request has been received. The timeframe of receipt of this acknowledgement usually coincides with RTT, the network round trip time. It is independent of the load or slow speed of backend authentication mechanism
  • TCP is capable of providing immediate indication of crashed servers or servers by reset. In case long lived TCP connections are used determination of crashes and return to service of the servers can be easily done. Whereas a UDP is unable to differentiate between a server that is down, a non existent server or a slow server.
  • It supports multiple connections simultaneously.
  • Scalability of TCP is more and it can easily be adapted to expanding or even congested networks.

Packet Encryption 

When it comes to packet encryption, RADIUS has a drawback that it only encrypts the password in the access request packet being transported from the client to the server. The rest of the packet is left as it is. This puts information like the username, services that a user is allowed to use, accounting in a vulnerable state.

TACAS+ encrypts the entire packet leaving only the standard TACAS+ header in an unencrypted state. This ensures a greater amount of security in communications. The header contains field which indicates towards the fact whether or not the body is encrypted. It serves its purpose well at the time of debugging.

Authentication and Authorization 

The functions of authentication and authorization are combined in RADIUS. The packets sent by the RADIUS server to the client contain authorization information. Decoupling authentication and authorization are not possible in this.

TACAS+ uses the AAA architecture for the same. This permits separate authentication. The use of Kerberos authentication is possible for authentication along with TACACS+ authorization and accounting.

In case additional authorization checks are required, the access server checks with a TACACS+ server. It checks if the user is granted permission to use particular commands. This ensures greater control over the commands that can be executed.

Multiprotocol Support 

RADIUS does not support protocols like AppleTalk Remote Access, NetBIOS FPC, Novell Asynchronous Services. TACACS+ on the other hand offers support for multiple protocols.

Router Management 

The choice of commands that can be executed or not executed on a router is not available in the case of RADIUS. As a result RADIUS is not efficient when it comes for router management or flexible terminal services. 

Two methods of controlling the authorization of router commands on a per user or per group basis are possible in the case of TACAS+. The first method is by assigning privilege levels to commands. After that the router verifies by communicating with the server and checks for the authorization of the user at that specific level. The second method involves explicitly specifying in the TACAS+ server, the commands that are allowed.


RADIUS does not ensure interoperability for the reason that various interpretations are available for RADIUS Request for Comments (RFC’s). Even though several vendors implement RADIUS clients, this does not mean they are interoperable. Cisco continuously upgrades the attributes available on RADIUS. If only the standard attributes are used clients can interoperate between several vendors if these vendors too have the same attributes.


The amount of traffic that is generated between the client and the server differs to a great extent.