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.
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.
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.
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:
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
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.
blog comments powered by Disqus