Chapter 10. Multifactor Authentication
Electronic data networks are becoming ubiquitous and demanding stronger secure access control and protection from unauthorized access. The changing network dynamics and increased security levels have driven new requirements in access control management solutions. Stronger forms of authentication, such as two-factor, three-factor authentication systems, and other public key infrastructure solutions are now being used to manage users who are accessing networks and controlling access to network resources.
Secure access through strong user authentication is becoming increasingly essential. Strong user authentication is typically achieved by implementing multifactor authentication technology. Examples include one-time password (OTP) solutions, hardware tokens, s/key, and smart cards.
Cisco Secure Access Control Server (ACS) provides support for two-factor authentication in a centralized access management solution for managing users and network infrastructure resources with OTP solutions.
Identification and Authentication
Identification and authentication (I&A) is a two-step process that governs user access to a network or a resource in the network.
Identification, which is the first step of the process, determines the identity of the user. The identification component of an access control system can be based on one of the following attributes:
• Username or user ID
• Computer or system name
• MAC address (Layer 2)
• IP address (Layer 3)
• Process name or process ID (PID)
Authentication is the second step in the process of verifying the identification provided earlier. The authentication component can be based on one of the following attributes:
• Simple password (one-factor)
• Multiple passwords (two-factor)
• Personal identification number (PIN)
• Shared secret key
• Certificate
• Token
• Pass-phrase
• Biometric
Two-Factor Authentication System
More often than not, static or single password (one-factor) authentication mechanisms are susceptible to brute-force attacks resulting in unauthorized access, given enough attempts and time. Authentication based on one factor does not provide adequate security, because the static password does not change between subsequent logons or is rarely altered. This risk can be greatly reduced by continually altering the password, as offered by the one-time password (two-factor) authentication mechanism.
Two-factor authentication solutions are primarily based on technologies that generate one-time passwords (OTP).
One-Time Password (OTP)
OTP technology is a system based on S/KEY but it was renamed because of trademark issues associated with the S/KEY name. S/KEY is a seminal OTP system that was developed at Bell Communications Research, Inc. or Bellcore.
The basic principle of an OTP solution is that it requires a new password every time a user authenticates. This effectively protects against replay attacks or any attack that attempts to use an intercepted password. The OTP system makes unauthorized access attempts more difficult.
There are three basic types of OTP technologies:
• Mathematical algorithm: This system uses a one-way hash function to generate a new password based on the previous password. This type of system requires an initial seed (pass phrase or PIN), which then generates subsequent passwords based on the previous password.
• Challenge/response: This type also uses a mathematical algorithm, but with a challenge function. The user receives a challenge (a random number or secret key) at the time of login, which needs to be entered into the password-generating token/software to generate a one-time password. This system is very strong because it computes the new password based on a challenge mechanism instead of being based on the previous password.
• Time-synchronized: This system is tightly controlled by the system clock generating the password. Usually this is available on a physical hardware token, which is used to generate the password. The token has an accurate clock that is synchronized with the clock on the authentication server.
The OTP system is documented in IETF RFC 2289.
S/KEY
As mentioned earlier, S/KEY is a seminal OTP system developed for authentication at Bellcore. Using this system, the real password is never transmitted across the network. Instead, the real password is combined with a short set of characters and a decrementing counter to form a new single-use, one-time password. The S/KEY OTP system generates a password based on a seed secret pass phrase with a secure hash function such as MD5. The S/KEY server verifies the one-time password by making a pass through the secure hash algorithm and comparing the result with the previous password.
Inverting the hash function that produced the one-time single-use password is extremely difficult. However, S/KEY is sensitive to man-in-the-middle attacks. A secure transport layer protocol (SSL/TLS) can be used to counteract this.
S/KEY one-time password is documented in IETF RFC 1760.
Countering Replay Attacks Using the OTP Solution
One of the most common attacks on the network is a replay attack in which an intruder can be sniffing and eavesdropping network transmission to obtain usernames and passwords of legitimate connections. The illegitimately captured usernames and passwords can be used at a later time to gain unauthorized network access.
The OTP solution can be used to counter this type of attack because OTP generates a new password for every new user request. The captured credentials are not valid for subsequent attempts. Note that OTP does not provide confidentiality or privacy of data. After network access is granted, information is readily available to the authenticated user (legitimate or illegitimate).
Note
OTP does not provide nonrepudiation, because the authentication mechanism is valid only for a certain period.
Attributes of a Two-Factor Authentication System
To provide a strong authentication mechanism, the two-factor authentication system requires two elements: establishing the user identity and granting appropriate network access. The first piece consists of something you know, such as a password, and the second piece consists of something you have, such as a token or smart card. Some solutions also offer three-factor authentication, which requires an additional third piece that consists of something you are—that is, a biometric scan such as a fingerprint or an iris scan.
Authentication factors can be based on the following three most commonly recognized input attributes:
• Something a user knows: A password, a personal identification number (PIN), or a pass phrase.
• Something a user has: A smart card or token (hardware or software).
• Something a user is: A biometric pattern such as a fingerprint, voice, retina or iris scan, or DNA sequence.
Combinations of any two of the three methods can provide a strong, secure authentication mechanism—hence the term two-factor authentication solution.
Smart Cards and Tokens
Smart cards and tokens are the most common forms of the “something a user has” factor in authentication systems.
Tokens can be in the form of hardware or software. Software tokens are a weaker form of two-factor authentication, because they store tokens on a PC and are therefore vulnerable to malicious attacks and software break-ins. Another common form is USB-based tokens. The USB token has a different form factor that is not in the form of a card, but in a standard USB key type. Using a USB token is a much easier and more scalable approach because USB ports are widely available in standard equipment used today. Another advantage of using a USB token is that it has a larger storage capacity and can be used to store more numerous logon credentials than a regular smart card. Another advantage of the USB token is that it can have built-in OTP hardware. Vendors such as Booleansoft, RSA Security, VASCO, and Aladdin Knowledge Systems offer USB-based tokens as part of their two-factor authentication solution. See Figure 10-1 for samples.
A smart card resembles a normal credit card, but inside it has an embedded microprocessor and a memory chip or, in some cases, only a memory chip with nonprogrammable logic. Many vendors offer smart card technology, some of which include RSA Security, Secure Technologies, VASCO, and ActivIdentity. Some vendors, such as ActivIdentity, HID, and RSA Security, also offer smart cards that perform the function of a proximity card in addition to network authentication. This offers proximity detection, and users can only use the cards after they enter the building or are close to the device; users then insert the card into their PC to be able to access network logon credentials. These types of solutions can also serve as employee ID badges. The downside is that these types of smart cards are bigger in size, and the card reader is an extra expense.
Figure 10-1 shows samples of various smart cards and tokens (regular and USB).
Figure 10-1. Sample Smart Cards and Tokens
RSA SecurID
RSA SecurID is a two-factor authentication solution developed by the vendor RSA Security. RSA stands for the founders’ last names: Ron Rivest, Adi Shamir, and Len Adleman, who are also the co-inventors of the RSA public key cryptography algorithm.
The RSA SecurID authentication mechanism combines multiple components to provide a two-factor authentication platform. The platform consists of a token—a piece of hardware (a USB token or other type of token)—or software (“soft token” for a PC, PDA, or mobile phone) that is assigned to a user. The platform generates an authentication code by using a built-in clock and the card’s factory-encoded random key (the “seed”). The mechanism works on time-synchronized OTP technology, as discussed earlier.
Cisco Secure ACS server supports the RSA SecurID authentication solution.
Cisco Secure ACS Support for Two-Factor Authentication Systems
Cisco Secure ACS server supports the use of token servers to provide a strong security authentication mechanism using the OTP technology.
Cisco Secure ACS provides support for ASCII, Password Authentication Protocol (PAP), and Protected Extensible Authentication Protocol (PEAP)/Extensible Authentication Protocol Generic Token Card (EAP-GTC) authentication by using token servers. No other authentication protocols are supported with token server databases.
Note
For more information about authentication protocols and the Cisco Secure ACS external database types that support token servers, refer to the Authentication Protocol-Database Compatibility: http://tinyurl.com/2fb4nq.
Cisco Secure ACS supports two types of token server implementations:
• RADIUS token server: Support for token servers that provide a standard RADIUS interface built in to the token server. This feature enables Cisco Secure ACS to support a RADIUS token server database using any token server that provides an Internet Engineering Task Force (IETF) RFC 2865-compliant RADIUS interface.
• Non-RADIUS token server: Support for RSA SecurID token servers only. RSA SecurID does not support the RADIUS interface. ACS uses RSA proprietary client software to talk to the token server. ACS supports Point-to-Point Protocol (PPP); that is, ISDN and Async, and Telnet, for RSA SecurID token servers by acting as a token-client to the RSA SecurID token server. RSA-provided application programming interface (API) client software is installed on the computer that is running Cisco Secure ACS to communicate authentication requests with RSA token server.
How Cisco Secure ACS Works
Cisco Secure ACS acts as a client to the token server using the RADIUS-enabled interface of the token server, except in the case of RSA SecurID implementation. For RSA SecurID, Cisco Secure ACS uses RSA proprietary API client software.
When Cisco Secure ACS receives an authentication request from the AAA client (NAS), ACS forwards the authentication request to the token server. This process assumes that ACS is configured to authenticate against a token server, as configured in the external database configuration for “unknown user policy.”
Figure 10-2 shows a menu option for the Cisco Secure ACS external database configuration, in which both RADIUS-enabled and non-RADIUS (RSA SecurID) token servers can be configured.
Figure 10-2. Configuring a Cisco Secure ACS Token Server
Before configuring the Cisco Secure ACS, it is important that the RADIUS-enabled token server and/or the RSA SecurID token server are installed and configured. In the case of RSA SecurID, ensure that the applicable RSA SecurID API client software is installed on the Cisco Secure ACS server.
Configuring Cisco Secure ACS for RADIUS-Enabled Token Server
Perform the following steps to configure Cisco Secure ACS for a RADIUS-enabled token server:
Step 1. Before configuring Cisco Secure ACS, ensure that the RADIUS-enabled token server is installed and configured.
Step 2. From the ACS external database configuration menu, select RADIUS token server, and create a new token server as shown in Figures 10-3, 10-4, and 10-5.
Step 3. After the token server instance is created, select Configure to add the RADIUS parameters for the token server, as shown in Figures 10-6 and 10-7.
Step 4. Configure the external database Unknown User Policy to select the RADIUS token server instance to handle authentication requests, as shown in Figures 10-8 and 10-9.
Figure 10-3. Configuring ACS for RADIUS-Enabled Token Server (Step 2)
Figure 10-4. Configuring ACS for RADIUS-Enabled Token Server (Step 2 cont)
Figure 10-5. Configuring ACS for RADIUS-Enabled Token Server (Step 2 cont)
Figure 10-6. Configuring ACS for RADIUS-Enabled Token Server (Step 3)
Figure 10-7. Configuring ACS for RADIUS-Enabled Token Server (Step 3 cont)
Figure 10-8. Configuring ACS for Unknown User Policy (Step 4)
Figure 10-9. Configuring ACS for Unknown User Policy (Step 4 cont)
Tip
For more information on configuring a RADIUS-enabled token server on Cisco Secure ACS, refer to http://tinyurl.com/yu26nj.
Configuring Cisco Secure ACS for RSA SecurID Token Server
You can find a sample configuration available at Cisco.com to configure Cisco Secure ACS with RSA SecurID (ACE Server) implementation:
The following options are available to install Cisco Secure ACS with RSA SecurID token server in these combinations:
• The RSA SecurID server, RSA SecurID client, and ACS can be on the same server.
• The RSA SecurID server can be on one server, and the RSA SecurID client with ACS can be on another server.
Tip
For more information on configuring the RSA SecurID Token Server on Cisco Secure ACS, refer to http://tinyurl.com/yu26nj.
Summary
The ever-expanding global networks today are demanding stronger access control methods to protect from unauthorized access. Multifactor authentication mechanisms and other PKI solutions are becoming increasing essential and popular in providing stronger and more secure access control solutions.
Cisco Secure ACS software supports the two-factor authentication mechanism using OTP technology, thereby providing stronger security to safeguard the network infrastructure from unauthorized access.
The chapter illustrated the identification and authentication (I&A) process and explained the various attributes entailed in the authentication mechanism.
The chapter provided a comprehensive overview of the two-factor authentication mechanism and details of OTP technology and how it works, including details of smart cards and tokens.
The chapter also provided an overview of Cisco Secure ACS server support for two-factor authentication mechanisms and how to implement the various types of OTP technologies in ACS.
The chapter concluded with a basic example of configuring Cisco Secure ACS for a RADIUS-enabled token server, with sample screenshots from ACS.
References
User Guide for Cisco Secure ACS for Windows 4.0: http://tinyurl.com/2xq9sg
http://en.wikipedia.org/wiki/Two-factor_authentication