Share this page : facebooktwitterlinkedinmailfacebooktwitterlinkedinmail

Security principle includes human interaction with a computer(Authentication); a computer’s interaction with a network(Authorization); even an application’s interaction with data (Accounting).

Before allowing and entity to perform certain actions, you must ensure you know who that entity actually is (Authentication) and if the entity is authorized to perform that action (Authorization). Additionally, you need to ensure that accurate records are maintained showing that the action has occurred, so you keep a security log of the events (Accounting).

two main AAA protocols commonly used in enterprise networks today: TACACS+ and RADIUS. Note: there is a third common AAA protocol known as DIAMETER, but that is typically only used in service-provider environments.

TACACS+

Terminal Access Controller Access-Control System (TACACS) [takas]is a protocol set created and intended for controlling access to UNIX terminals. Cisco created a new protocol called TACACS+, which was released as an open standard in the early 1990’s. TACACS+ may be derived from TACACS, but it is a completely separate and non-backward-compatible protocol designed for AAA. While TACACS+ is mainly used for Device Administration AAA, it is possible to use it for some types of network access AAA.

TACACS+ uses Transmission Control Protocol (TCP) port 49 to communicate between the TACACS+ client and the TACACS+ server. An example is a Cisco switch authenticating and authorizing administrative access to the switch’s IOS CLI. The switch is the TACACS+ client, and Cisco Secure ACS is the server.

One of the key differentiators of TACACS+ is its ability to separate authentication, authorization and accounting as separate and independent functions. This is why TACACS+ is so commonly used for device administration, even though RADIUS is still certainly capable of providing device administration AAA.

Device administration can be very interactive in nature, with the need to authenticate once, but authorize many times during a single administrative session in the command-line of a device. A router or switch may need to authorize a user’s activity on a per-command basis. TACACS+ is designed to accommodate that type of authorization need. As the name describes, TACACS+ was designed for device administration AAA, to authenticate and authorize users into mainframe and Unix terminals, and other terminals or consoles.

TACACS+ communication between the client and server uses different message types depending on the function. In other words, different messages may be used for authentication than are used for authorization and accounting. Another very interesting point to know is that TACACS+ communication will encrypt the entire packet.

 

RADIUS

Remote Access Dial-In User Service (RADIUS) is an IETF standard for AAA. As with TACACS+, it follows a client / server model where the client initiates the requests to the server. RADIUS is the protocol of choice for network access AAA, and it’s time to get very familiar with RADIUS. If you connect to a secure wireless network regularly, RADIUS is most likely being used between the wireless device and the AAA server. Why? This is the case because RADIUS is the transport protocol for Extensible Authentication Protocol (EAP), along with many other authentication protocols.

Originally, RADIUS was used to extend the authentications from the layer-2 Point-to-Point Protocol (PPP) used between the end-user and the Network Access Server (NAS), and carry that authentication traffic from the NAS to the AAA server performing the authentication. This allowed a Layer-2 authentication protocol to be extended across layer-3 boundaries to a centralized authentication server.

RADIUS has evolved far beyond just the dial up networking use-cases it was originally created for. Today it is still used in the same way, carrying the authentication traffic from the network device to the authentication server. With IEEE 802.1X, RADIUS is used to extend the layer-2 Extensible Authentication Protocol (EAP) from the end-user to the authentication server.

There are many differences between RADIUS and TACACS+. One such difference is that authentication and authorization are not separated in a RADIUS transaction. When the authentication request is sent to a AAA server, the AAA client expects to have the authorization result sent back in reply.

EAP

Extensible Authentication Protocol (EAP) [RFC 3748] is just the transport protocol optimized for authentication, not the authentication method itself:

” EAP is an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this.” — RFC 3748, page 3

Some of the most-used EAP authentication mechanism are listed below:

* EAP-MD5: MD5-Challenge requires username/password, and is equivalent to the PPP CHAP protocol [RFC1994]. This method does not provide dictionary attack resistance, mutual authentication, or key derivation, and has therefore little use in a wireless authentication enviroment.
* Lightweight EAP (LEAP): A username/password combination is sent to a Authentication Server (RADIUS) for authentication. Leap is a proprietary protocol developed by Cisco, and is not considered secure. Cisco is phasing out LEAP in favor of PEAP.
* EAP-TLS: Creates a TLS session within EAP, between the Supplicant and the Authentication Server. Both the server and the client(s) need a valid (x509) certificate, and therefore a PKI. This method provides authentication both ways.
* EAP-TTLS: Sets up a encrypted TLS-tunnel for safe transport of authentication data. Within the TLS tunnel, (any) other authentication methods may be used. Developed by Funk Software and Meetinghouse, and is currently an IETF draft.
*EAP-FAST: Provides a way to ensure the same level of security as EAP-TLS, but without the need to manage certificates on the client or server side. To achieve this, the same AAA server on which the authentication will occur generates the client credential, called the Protected Access Credential (PAC).
* Protected EAP (PEAP): Uses, as EAP-TTLS, an encrypted TLS-tunnel. Supplicant certificates for both EAP-TTLS and EAP-PEAP are optional, but server (AS) certificates are required. Developed by Microsoft, Cisco, and RSA Security, and is currently an IETF draft.
* EAP-MSCHAPv2: Requires username/password, and is basically an EAP encapsulation of MS-CHAP-v2 [RFC2759]. Usually used inside of a PEAP-encrypted tunnel. Developed by Microsoft, and is currently an IETF draft.