Authentication

AAA is basically authentication, and part of authentication is authorization & accounting. But it has become the catch-all phrase for high-end authentication services to point out that they include authorization & accounting. Now, every commercial authentication suite of protocols boasts about its AAA capabilities.

Cisco Secure Access Control Server (ACS) for Windows and UNIX provides a centralized identity networking solution and simplified user management across all Cisco devices and security management applications, allowing network administrators to control:

• Who can log into the network.
• The privileges each user has in the network.
• Recorded security audit or account billing information.
• Access and command controls that are enabled for each configuration’s administrator.

With Cisco Secure ACS, you can manage and administer user access for Cisco IOS® routers, VPNs, firewalls, dialup and DSL connections, cable access solutions, storage, content, voice over IP (VoIP), Cisco wireless solutions, and Cisco Catalyst® switches using IEEE 802.1x access control.

Advanced features include:

• Automatic service monitoring, database synchronization, and importing of tools for large-scale deployments.
• Lightweight Directory Access Protocol (LDAP) and Open Database Connectivity (ODBC) user authentication support.
• Flexible 802.1X authentication type support, including Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), Protected EAP (PEAP), Cisco LEAP, EAP-Flexible Authentication via Secure Tunneling (EAP-FAST), and EAP-Message Digest Algorithm 5 (EAP-MD5).
• Downloadable access control lists for any Layer 3 device, including Cisco routers, Cisco PIX® firewalls, and Cisco VPNs.
• Device command set authorization.
• Network access restrictions
• User and administrative access reporting.
• Dynamic quota generation
• Restrictions such as time of day and day of week.
• User and device group profiles.

TACACS is an older remote authentication protocol that is used to communicate with an authentication server.TACACS is defined in RFC 1492: http://www.ietf.org/rfc/rfc1492.txt.

RADIUS became much more popular than TACACS. However, in response, Cicso developed TACACS+, which was a much-improved version, and has many advantages over RADIUS. Nevertheless, RADIUS is still the predominant authentication protocol.

RADIUS is much more popular and has a huge installed base in the U. S.RADIUS is more popular than TACACS+, but not as strong on AAA.

• RADIUS uses UDP, while TACACS+ uses TCP. TCP offers several advantages over UDP. TCP offers connection-oriented transport, while UDP offers best-effort delivery. RADIUS requires additional programmable variables such as re-transmit attempts and time-outs to compensate for best-effort transport. Still, it lacks the level of built-in support that a TCP transport offers.
• RADIUS encrypts only the password in the access-request packet from the client to the server. The remainder of the packet is unencrypted. Other information, such as username, authorized services, and accounting, could be captured by a third party.
• TACACS+ encrypts the entire body of the packet but leaves a standard TACACS+ header. Within the header is a field that indicates whether the body is encrypted or not.
• For debugging purposes, it is helpful to have the body of the packets unencrypted. However, during normal operation, the body of the packet is fully encrypted for more secure communications.

RADIUS combines authentication and authorization. The access-accept packets sent by the RADIUS server to the client contain authorization information. This makes it difficult to decouple authentication and authorization.

• TACACS+ uses the AAA architecture, which separates authentication, authorization, and accounting. This allows different authentication solutions that can still use TACACS+ for authorization and accounting.
• For example, with TACACS+, it is possible to use Kerberos authentication and TACACS+ authorization and accounting. After a NAS authenticates on a Kerberos server, it requests authorization information from a TACACS+ server without re-authenticating.
• The NAS informs the TACACS+ server that it has successfully authenticated on a Kerberos server. The server then provides authorization information.

RADIUS does not support the following protocols – but TACACS+ does:

• AppleTalk Remote Access (ARA) protocol.
• NetBIOS Frame Protocol Control protocol.
• Novell Asynchronous Services Interface (NASI).
• X.25 PAD connection

RADIUS does not allow users to control which commands can be executed on a router and which cannot. Therefore, RADIUS is not as useful for router management or as flexible for terminal services.

• TACACS+ provides two methods to control the authorization of router commands on a per-user or per-group basis.
• The first method is to assign privilege levels to commands and have the router verify with the TACACS+ server whether or not the user is authorized at the specified privilege level.
• The second method is explicitly specified in the TACACS+ server, on a per-user or per-group basis, the allowed commands.

RADIUS (all caps) is a user authentication protocol that runs on a Radius (upper & lower case) server.

• The system performs user ID and password lookups against a central database to authenticate or reject a user requesting access to a network or network services. It is handy for large, distributed dialup systems because it is a centralized system where all requests are sent.
• The RADIUS specification is described in RFC 2865, which obsoletes RFC 2138.

There are four basic components of the Radius service (the Radius service serves the end-user but does not include the end-user):

• Radius client (A) (e.g., IVPN device – not the dialup user).
• Radius server (B)
• LDAP directory server (C).
• X.500 database (D)

How it Works – the Radius client sends authentication requests to the Radius server and receives responses from it.

• The Radius server receives authentication requests, passes information requests to the directory server, compares user passwords and groups, and responds to the IVPN device or firewall.
• The LDAP directory server receives user and group ID queries from the Radius server, performs lookups on the X.500 database, and returns database information to the Radius server.
• The X.500 database serves as the repository for user ID, password, and group ID information. (Users with similar privileges and profiles can be placed in the same user group, identified by a group ID.
• This allows the same information to be applied to users multiple times while only entering it into the database once).
• The LDAP directory server looks in the database for user passwords and group information corresponding to a given user ID or group ID. The drawing below shows these components and their interactions.
• When dialup users request access to a resource, they are prompted for their identity (Please enter user name and password. ).The information will be passed to a Radius server, comparing the user’s name and password against a central database and approving or denying access to the resource.
• Transactions between the client servers (NAS) and RADIUS server are authenticated through a shared secret, never sent over the network.

Also, any user passwords are sent encryptedbetween the client and the RADIUS server to eliminate the possibility that someone snooping on an unsecured network could determine a user’s password.

An IVPN (Internet VPN) device is configured to point to two Radius servers for user authentication in the above diagram.

• The IVPN device is the Radius client to the Radius server. The IVPN device is configured with both primary and secondary server IP addresses for redundancy.
• When a remote user attempts to connect to the IVPN site, the IVPN device will send an authentication request to a Radius server with the user’s ID and password information.
• The Radius server will respond with either a pass or fail response indicating whether or not the user should be allowed to establish the connection.

Referencing the diagram above – the Radius server, directory server, and X.500 database communicate in the following way (steps below match the steps shown in the diagram).

1. The Radius server receives (1) an encrypted authentication request (containing the user ID and password) from the IVPN device (not shown).
2. The Radius server then queries the directory for any information associated with that specific user ID.
3. If the user ID exists in the directory, the X.500 database is queried.
4. all user information (password and Group ID) associated with that user ID will be sent to the LDAP Directory server.
5. the LDAP server sends then forwards the user info to the RADIUS serverNote:All user ID and password information are kept in the X.500 database. The user passwords are not kept in the database in clear text format. Instead, they are first hashed. Hashing the password is similar to encrypting it, except that the hash cannot be unencrypted or un-hashed. Every unique password produces a unique hash. With this method, the clear text passwords cannot be stolen or looked at while in the directory server database. An additional security level is reached by restricting LDAP queries to only the Radius servers – firewalls block all other LDAP queries to these directory servers.
6. The Radius server then performs its own hash of the user’s password that was received from the IVPN device. This hash value is compared to the hashed password retrieved from the directory server. If they match, the password is confirmed, and the Radius server sends the user ID to the LDAP directory server and queries it for the group name NOTE:If they do not match, a failure response is returned to the IVPN device.
7. To find the Group Name (the group name is associated with the group ID that was associated with the user ID) – the LDAP server first takes the received User ID. It looks in its own lookup table for that user’s Group ID. If the Group ID is found, the LDAP directory server queries the database for the Group Name.
8. The LDAP server receives the Group Name from the X.500 database.
9. The LDAP server sends the Group name to the Radius server.

The Radius server compares the returned group name to a local file of group definitions. If there is a match, it returns a pass response to the IVPN device along with the proper class attribute, which is really just the user’s group name. If there is no group match, a pass response is returned with a default class attribute (NoGroup). (This will mean to use the default group. )

RADIUS, LDAP, and X.500 Backups – the following diagram outlines a redundant RADIUS solution’s basic topology.

• The two networks on either side of the diagram represent two separate geographical locations, Kansas City and Reston. The two locations will be connected by an Internet VPN to encrypt directory information passing between the sites (such as LDAP lookups for failover and shadowing information that keeps the directories synchronized).
• The diagram indicates how each Radius server will be configured to perform lookups at a primary directory server and a redundant secondary directory server.
• Although the diagram shows two sites, additional sites may be added later to increase the geographical coverage and keep up with the general authentication demands.
• One of the directory servers will be called the “supplier” directory to feed information to all other “consumer” directory servers.
• There can be any number of consumer directories, but only one supplier. No matter what “role” a directory has (supplier or consumer), any of the directories will respond to LDAP queries.
• Load distribution among all servers is handled through each Radius client device (i. e., firewalls and IVPN devices “pointing to” the Radius servers).

RADIUS Centralized Architecture – Network trends are to get away from centralized and go to distributed – NOT SO with RADIUS.

• Placing an authentication server at every network access point (which would number into the hundreds for a large ISP) would duplicate the authentication information for every network user at every location.
• Instead, the authentication request could be passed from each NAS to a central RADIUS authentication server.

RADIUS and VPN’s – the most common use for RADIUS services is to provide authentication of users to a VPN device such as the Nortel Contivity 4700, which manages dialup access to a company’s network and network resources.

• VPN devices can pass authentication requests to a central Radius server to perform the user ID and password lookup, removing ID/password database lookups from the VPN device itself.
• Additionally, if multiple firewalls or IVPN devices are deployed across a single customer network, authentication requests from all locations and devices can be forwarded to a single, centrally managed Radius server.
• This eliminates the need to maintain multiple authentication servers at multiple network access locations.

Note that the RADIUS Database of User info is often an X.500 database with LDAP access

You can think of LDAP as Lightweight X.500.LDAP is a directory that provides a structured format for storing information that will later be retrieved.

• One example of a directory service is the phone book used to associate a person’s name with a corresponding phone number. The names and phone numbers are stored in the phone directory that is accessed to resolve a name into a number.
• Another example might be a company’s e-mail address book, which links names with e-mail addresses (and maybe other information like a physical address or phone number).
• The X.500 standard defines both database and directory access methods. But it has a very complex DAP (Directory Access Protocol). The protocols used by X.500 were deemed too complex for general use. So the Lightweight Directory Access Protocol (LDAP) was designed.
• ISP often maintains an X.500 database of customer user names, user IDs, and passwords based on an initial customer-provided spreadsheet and then uses LDAP to access the X.500 database.
• LDAP-compliant VPN devices and corporate directories can be integrated to provide a flexible policy-based management system for an organization. Policy-based management enables a very granular level of control within a network.
• A policy defines how users (or user traffic) are treated within a network. For instance, a security policy may be defined to encrypt all traffic destined for a human resources server or require some users’ authentication.
• An organization’s corporate directory can include policy information for users or groups of users that defines how network devices treat their traffic. For example, a directory may contain a member’s name along with systems he may access, IDs and passwords for those systems, addresses, groups he belongs to (e. g., Business Services Group, Long Distance Division), and a public key certificate.
• For example, an LDAP-compliant VPN device could use an ID and password to look into a central directory and access a user’s public key certificate to assist in the authentication.
• A policy may state that all Long Distance Division members’ traffic is encrypted between two sites. LDAP access to a directory can identify these users and assist a VPN device in applying this policy.
• The use of directories to define and apply network policy is known as DENS or Directory-Enabled Network Services. As the name implies, the directory information enables network services or policies to be defined at group or user levels.

Kerberos is yet another authentication protocol that runs on servers.

• For some time, Kerberos was classed as a munition within the United States. It could not be exported because it used the DES encryption algorithm (with 56-bit keys).
• A non-US implementation was developed in Sweden, making the system available outside the US before the US export regulations were changed (by 2000 – more or less).
• Kerberos has become commercially crucial since Microsoft introduced a version of Kerberos in the Windows 2000 version of the Microsoft Windows operating system.
• However, you probably will not see much Kerberos since RADIUS is so common these days.

Kerberos, like BSO, is freely available – open-source – from MIT.