How AAA Works - Security

AAA is the security infrastructure of IOS devices. AAA commands are located in the IOS privileged EXEC mode. Each client device is configured for security using the AAA commands from global configuration mode. Properly configured, the device can then make use of the CiscoSecure server via either the TACACS+ or RADIUS security protocols— or both.

In fact, AAA commands can be used stand-alone to secure a device. In other words, the device can use a local user database stored in NVRAM on the device itself, instead of one on a RADIUS or TACACS+ server. However, this is rarely done because it entails maintaining and monitoring user security data in hundreds, or even thousands, of device config files instead of in a single database.

TACACS+ and RADIUS are client-server network protocols used to implement client-server security over the network. In that sense, they are the equivalent of what SNMP is to network management.

 A user database changes every time users are added or deleted, passwords are changed, or authorizations are modified. Separating the user database from device config files reduces the number of places updates must be made. Most internetworks use a primary server and one or two alternate security servers, leaving only a few places in which user profile databases need to be updated.

Ensuring that the user databases contain identical data is called database synchronization. This can be done automatically by using Replication Partners in CiscoSecure. In the scenario with three security servers, the three user databases would be configured as replication partners, and the CiscoSecure ACS would automatically synchronize user profile records between the three on a daily basis.

The AAA Approval Process

AAA works by compiling attributes that specify a user’s permissions. In the AAA context, an attribute is an entity (or object) to which the person may have access. For example, an authentication attribute might be a specific LAN segment to which the person is permitted access. An authorization attribute might be the limit on concurrent connections the person may have open at one time.

When a user attempts to connect to a secured service, the access device checks to see if the user has clearance per the security policy. It does so by sending a query to the server database to look for a match. The secured access device knows what to query for based on its config file parameter settings, and the query is to verify that the user has permission to do whatever is being attempted.

Attribute-Value Pairs The query contains the attributes that are mandatory for the requested service, as defined in the access device’s config file. The server processes the query by searching for the same attributes in the user’s profile in the user database. The search is for so-called attribute-values. An attribute, called an attribute-value pair (or AV pair) in TACACS+ terminology, is a fancy term for a network entity that is secured.

For example, in someone’s user profile, the password is an attribute, and the person’s actual password, imreallyme, is the value paired with it. When the user enters the password, the access device handling the login first knows to check for a password because to do so is set as a parameter in the device’s config file. By checking the person’s user profile, it looks for a match between the value entered into the password prompt and what’s on file in the user database for the username the person entered. Figure 8-7 shows the AAA procedure for handling a user’s request for a connection.

How AAA Handles Authentication Transactions When the connection is established, the access device contacts the security server to obtain a user prompt and displays it to the user. The user enters the information (usually just a username and password), and the protocol (RADIUS or TACACS+) encrypts the packet and sends it to the server. The server decrypts the information, checks the user’s profile, forms and encrypts the response, and returns the response to the access device.

The rules of AAA approval are fairly simple: If an ACCEPT is returned, the requested connection is made. If a REJECT is returned, the user’s request-for-connection session is terminated, but if an ERROR is returned and the access device is configured for multiple security servers, the query is then forwarded to an alternate server. If that server also fails to return a response, the process continues until the query runs out of servers. At that point, if the access device has been configured with a second method, it will iterate through the process again, first trying for approval with a query to the primary security server, and so on. If the access device exhausts authentication methods, it terminates the user’s request-for-connection session.

The CONTINUE response is another optional configuration parameter that prompts the user for additional information. The prompts can be anything the network administrator arbitrarily defines. For example, prompting users for their mother’s maiden name is a common challenge.

Figure 8-7.  User access requests are granted if attribute-values are matched in the user profile.

---

NOTE: A daemon (pronounced either with long e or long a) is a process that runs on a server to perform a predefined task, usually in response to some event. The term comes from Greek mythology, in which daemons were guardian spirits. Daemons are called system agents in Windows parlance. A TACACS+ daemon sits on the security server and fields authentication or authorization queries from client access devices. It does so by searching the user database for required AV pairs and returning the results to the client in TACACS+ packets.

---

Authorization Transactions If the user is authenticated, the daemon is contacted to check for authorization attributes on a case-by-case basis. Figure 8-8 depicts how authentication and authorization work together.

Authorization attributes can be issued for such services as connection type (login, PPP, and so on), IOS command modes (User EXEC or Privileged EXEC), and various connection parameters, including host IP addresses, user timeouts, access lists, and so on.

Figure 8-8.  Once authenticated, a user's authorizations are cleared as needed.

Authorization is, by nature, more sophisticated than authentication. More information than just username and password is involved, and the attributes have a state. For example, the Maximum-Time attribute requires the server to keep tabs on how long the user has been connected and to terminate the session when the value (number of seconds) for the user has been exceeded.

Authentication Protocols

CiscoSecure supports a number of authentication mechanisms. Also called password configurations or password protocols, authentication protocols make sure you are who you say you are when logging into a system. Here are four major authentication mechanisms supported by AAA:

• ASCII American Standard Code for Information Interchange is the oldest authentication protocol. ASCII is a machine-independent technique for representing English characters and has many other uses besides authentication. ASCII authentication requires the user to type in a username and password to be sent in clear text (that is, unencrypted) and matched with those in the user database stored in ASCII format.
• PAP Password Authentication Protocol is used to authenticate PPP connections. PAP passes passwords and other user information in clear text. You know PAP as a protocol that lets you store your username and password in the dialog box so you don’t have to type it during each login.
• CHAP Challenge Handshake Authentication Protocol provides the same functionality of PAP, but it is much more secure since it avoids sending the password and other user information over the network to the security server. Figure 8-9 depicts how challenge-response works.
• Token-Card This authentication technique uses one-time passwords. A token-card is an electronic device that’s a bit larger than a credit card. The card is used to generate an encrypted password that must match one filed for the user in the token-card database residing on the security server. The encrypted password is good for only one use; thus the name token. Token-card authentication systems provide the best access security.

AAA also supports NASI (NetWare Asynchronous Services Interface), an authentication protocol built into Novell LANs. Another vendor-specific password protocol is ARAP (AppleTalk Remote Access Protocol), with a double challenge-response authentication mechanism that goes CHAP one better by making the security server authenticate itself to the client as well. In addition, there are subtle variations in how the PAP protocol works with Windows NT/2000/2003.

Security comes at a cost—mostly in the form of increased inconvenience to users, but there’s also additional expense to deploy and administer security measures. For example, CHAP requires some extra hardware and expertise, and token-cards are cumbersome to deploy. Can you imagine the giant Internet service provider AOL mailing token-cards to 

Figure 8-9.  CHAP authentication doesn't send the password over the network.

every new user and administering a token database of one-time passwords? The added expense and logistical complexity of advanced authentication protocols have discouraged their adoption.

PAP is by far the most widely used authentication protocol because it’s simple for users and inexpensive for network operators. When you log into the Internet from home, you’re almost certainly going through a PAP mechanism. Corporate internetworks are more likely to use CHAP, while token-cards are mainly used to protect high-security networks in the military, R&D, or banking. From an ISP’s standpoint, preventing a hacker from gaining free Web access isn’t worth the trouble and expense of replacing PAP with a better authentication technology.

>>> More Security Articles          >>> More By McGraw-Hill/Osborne

blog comments powered by Disqus