CHAPTER 9: Security Standards and Services 436 party’s hands, it can be used to falsely authenticate and identify someone as a valid party, forging false communications or using the user’s access to gain permissions to the available resources. Original digital authentication systems shared a secret key across the net- work with the entity with which they wanted to authenticate. Applications such as Telnet and FTP are examples of programs that simply transmit the user- name and password in cleartext to the party they are authenticating. Another area of concern is POP3 e-mail, which, in its default state, sends the complete username and password information in cleartext, with no protection. The problem with this method of authentication is that anyone who monitors a network can possibly capture a secret key and use it to gain access to the services or to attempt to gain higher privileged access with your stolen authentication information. What methods can be used to provide a stronger defense? As discussed previously, sharing a handshake or secret key does not provide long lasting and secure communication or the secure exchange of authentication infor- mation. This has led to more secure methods of protection of authentica- tion mechanisms. The following sections examine a number of methods that provide a better and more reliable authentication process. NOTES FROM THE FIELD … Cleartext Authentication Cleartext (nonencrypted) authentication is still widely used by many people who receive their e-mail through POP3. By default, POP3 client applications send the username and password unprotected in cleartext from the e-mail client to the server. There are several ways of protecting e-mail account passwords, including con- nection encryption. Encrypting connections between e-mail clients and servers is the only way of truly protecting your e-mail authentication password. This prevents anyone from capturing your password or any e-mail you transfer to your client. SSL is the general method used to encrypt the connection stream from the e-mail client to a server. Authentication POP (APOP) is used to provide password-only encryption for e-mail authentication. It employs a challenge/response method (defined in RFC 1725) that uses a shared time stamp provided by the authenticating server. The time stamp is hashed with the username and the shared secret key through the MD5 algorithm. There are still some problems with this process. The first is that all values are known in advance except the shared secret key. Because of this, there is nothing provided to protect against a brute force attack on the shared key. Another problem is that this security method attempts to protect a password but does nothing to pre- vent anyone from viewing e-mail as it is downloaded to an e-mail client. Some brute-force crackers, including POP, Telnet, FTP, and HTTP, can be found at http://packetstormse- curity.nl/Crackers/ and can be used as examples for this technique. Network Access Security 437 Two-Factor Two-factor authentication can be implemented with a combination of some- thing you have (for example, Automatic Teller Machine (ATM) cards) and something you know (a PIN). To misuse your authentication credentials in a two-factor authentication scheme, an attacker must acquire both your ATM card and the PIN number. This type of authentication may be implemented in a simple form such as magnetic strip cards as currently used in many bank ATMs or more sophisticated token cards (available in the form of key fobs with constantly changing numbers). Token technology is a method that can be used in networks and facilities to authenticate users. These tokens are not the access tokens that are granted during a logon session by the NOS. Rather, they are physical devices used for the randomization of a code that can be used to assure the identity of the individual or service, which has control of them. Tokens provide an extremely high level of authentication because of the multiple parts they use to verify the identity of the user. Token technology is currently regarded as more secure than many forms of biometrics. This is due to the fact that impersonation and falsification of the token values is extremely difficult. Token authentication can be provided by way of either hardware- or software-based tokens. Let’s take a look at the multiple pieces that make up the process for authentication using token technology. To start with, you must have a process to create and track random token access values. To do this, you normally use at least two components. They are as follows: A hardware device that is coded to generate token values at specific intervals. A software or server-based component that tracks and verifies that these codes are valid. To use this process, the token code is entered into the server/software monitoring system during setup of the system. This begins a process of tracking the token values, which must be coordinated. A user wishing to be authenticated visits the machine or resource they wish to access, and enters a PIN number in place of the usual user logon password. They are then asked for the randomly generated number currently present on their token. When entered, this value is checked against the server/software system’s calculation of the token value. If they are the same, the authentication is complete and the user can access the machine or resource. Some vendors have also implemented a software component that can be installed on portable devices, such as handhelds and laptops, which emulate the token CHAPTER 9: Security Standards and Services 438 device and are installed locally. The authentication process is the same; however, the user enters the token value into the appropriate field in the software, which is compared to the required value. If correct, the user may log on and access the resource. Vendors such as RSA Security offer products and solutions such as SecurID to use these functions. Others implemented processes that involved the use of One Time Password Technology, which often uses a pregenerated list of secured password combinations that may be used for authentication, with a one-time use of each. This provides for a level of randomization, but its basic implementation is not as random as other token methods. Multifactor Three-factor authentication or commonly known as Multifactor authenti- cation is the process in which we expand on the traditional requirements that exist in a single-factor authentication like a password. To accomplish this, multifactor authentication will use another item for authentication in addition to or in place of the traditional password. The use of similar authentication mechanisms repetitively may not be classified as multifactor authentication. A three-factor implementation should use three indepen- dent authentication mechanisms available. The following are four possible types of factors that can be used in a multifactor authentication implementation: A password or a PIN can be defined as a something you know factor. A token or Smart Card can be defined as a something you have factor. A thumbprint, retina, hand, or other biometrically identifiable item can be defined as a something you are factor. Voice or handwriting analysis can be used as a something you do factor. For example, most password-based single authentication methods use a password. In multifactor authentication methods, you might enhance the “something you know” factor by adding a “something you have” factor or a “something you are” factor. A Smart Card or token device can be a “something you have” factor. Mul- tifactor authentication can be extended, if desired, to include such things as handwriting recognition or voice recognition. The benefit of multifactor authentication is that it requires more steps for the process to occur, thus adding another checkpoint to the process, and therefore stronger security. For instance, when withdrawing money from the bank with a debit card (“some- thing you have”), you also have to have the PIN number (“something you know”). This can be a disadvantage if the number of steps required to achieve Network Access Security 439 authentication becomes onerous to the users and they no longer use the pro- cess or they attempt to bypass the necessary steps for authentication. To summarize, multifactor authentication is more secure than other methods because it adds steps that increase the layers of security. However, this must be balanced against the degree to which it inconveniences the user because this may lead to improper use of the process. Single Sign-On Single Sign-On (SSO) is a process in which we simplify the access to different systems by authenticating the user once. Many SSO products exist in the marketplace today and typically SSO implementations will deploy with stringent policies regarding access control and authorization mechanisms. Group policies can also be used to ensure that simplification does not result in compromise in security. In a corporate scenario, a user may have to logon to the local direc- tory services for authentication, a mail service may require another pass- word, client-server applications such as customer relationship management (CRM) or enterprise resource planning (ERP) may need authentication and several other software applications that might have incorporated different authentication procedures. By deploying a SSO solution, the user would be able to logon a single time and gain access to all these services, instead of having to retain usernames and passwords for each. There are many benefits from deploying a SSO solution. One of the main benefits is the direct reduction in password fatigue that users experience by hav- ing to logon to and keep track of so many different authentication credentials. By lessening the burden places on users to retain disparate credentials, there may be a resulting increase in productivity. Simplified management is another apparent benefit gained when the disparate software systems can work with a centralized authentication service for a one-time authentication of the users. SSO can be implemented through various NOS including Microsoft Win- dows 2003 (Internet Authentication Services [IAS]), Microsoft Windows 2008 (Network Policy Server [NPS]), and Linux systems using Kerberos or through non-OS implementations such as RSA Enterprise SSO (ESSO) solutions. Authentication Systems From a simple user authentication to the local domain services to that of sophisticated online banking system, various authentication systems are adopted by the organizations. As the need for complex security arises, addi- tional layers of security are added to the rudimentary system of username and password. Operating systems and applications develop vulnerabilities and hackers come up with innovative methods to circumvent a security design. CHAPTER 9: Security Standards and Services 440 Introducing a hardware element into the authentication process is some- times considered a higher level of security since an attacker must gain con- trol of both the hardware (such as token card) and exploit the vulnerabilities of the system to gain unauthorized access. In this section, we’ll discuss about RADIUS, Kerberos, and LDAP authentication services, authentication protocols including PAP, Challenge Handshake Authentication Protocol (CHAP), 802.1x methods and imple- mentations that offer powerful accounting tools such as TACACS+. To begin with, we’ll discuss authentication policies that are used to granularly control the access methods and review the type of authentication protocols that remote users need to comply with to access resources. Remote Access Policies and Authentication Remote users may connect to the network through dial-in services using a modem and analog line by dialing in to the organization’s modem pool con- nected to a dial-in server or through VPN client software configured on their laptops or remote desktops to connect to the corporate VPN server (often a Firewall with VPN component as in Case of Check Point, Watchguard, Juniper SSG or Cisco ASA appliances or dedicated VPN concentrators). Even wireless clients connecting through the WAPs can be defined as a remote user and restrictions can be applied on them. In summary, any user outside the physi- cal LAN can be defined as a remote user and access policies can be applied. Authentication servers refer to the directory services before the users are authenticated. However, remote access policies go beyond just authen- ticating the user. These policies define how the users can connect to the network. You may also grant or deny the permission to dial-in, based on the credentials presented by the remote users. A remote access policy defines the conditions and remote access permissions and creates a profile for every remote connection made to the corporate network. Through remote access policies, you can define the following: Grant or deny dial-in based on connection parameters such as type and time of the day Authentication protocols (PAP, CHAP, EAP, MS-CHAP) Validation of the caller ID Call back Apply connection restrictions upon successful authorization Create remote user/connection profile Assign a static IP or dynamic IP from the address pool defined for remote users Network Access Security 441 Assign the user to a group to apply group policies Configure remote access permission parameters Define encryption parameters (for a remote access VPN client) Control the duration of the session including maximum time allowed and idle time before the connection is reset Remote Access Policies can be configured in Microsoft Windows 2003 through IAS, in Windows 2008 through NPS, and in Linux variants through FreeRADIUS. Biometrics Biometric devices can provide a higher level of authentication than, for example, a username/password combination. However, although they tend to be relatively secure, they are not impervious to attack. For instance, in the case of fingerprint usage for biometric identification, the device must be able to interpret the actual presence of the print. Early devices that used optical scans of fingerprints were fooled by fogging device lenses, which provided a raised impression of the previous user’s print as it highlighted the oils left by a human finger. Some devices are also subject to silicon impressions or fingerprinting powders that raise the image. Current devices may require a temperature or pulse sense as well as the fingerprint to verify the presence of the user, or another sensor that is used in conjunction with the print scanner, such as a scale. Biometrics used in conjunction with Smart Cards or other authentication methods lead to the highest level of security. RADIUS Users need a centralized entity to handle authentication. Initially, RADIUS was created by Livingston Enterprises to handle dial-in authentication. Then its usage broadened into wireless authentication and VPN authentication. RADIUS is the most popular of all the authentication, authorization, and accounting (AAA) servers, including TACACS, TACACS+, and DIAMETER. A RAS must be able to authenticate a user, authorize the authenticated user to perform specified functions, and log (that is, account for) the actions of users for the duration of the connection. When users dial into a network, RADIUS is used to authenticate user- names and passwords. A RADIUS server can either work alone or in a distributed environment (known as distributed RADIUS), where RADIUS servers are configured in a tiered (hierarchical) structure. In a distributed RADIUS environment, a RADIUS server forwards the authentication request to an enterprise RADIUS server using a protocol CHAPTER 9: Security Standards and Services 442 called proxy RADIUS. The enterprise RADIUS server handles verification of user credentials and responds back to the service provider’s RADIUS server. One of the reasons that RADIUS is so popular is that it supports a num- ber of protocols including the following: PPP Password Authentication Protocol (PAP) CHAP Authentication Process RADIUS authentication consists of five steps (Figure 9.10) as follows: 1. Users initiate a connection with an ISP RAS or corporate RAS. Once a connection is established, users are prompted for a user- name and password. 2. The RAS encrypts the username and password using a shared secret, and passes the encrypted packet to the RADIUS server. 3. The RADIUS server attempts to verify the user’s credentials against a centralized database. 4. If the credentials match those found in the database, the server responds with an access-accept message. If the username does not exist or the password is incorrect, the server responds with an access-reject message. 5. The RAS then accepts or rejects the message and grants the appro- priate rights. RADIUS Implementation Various options are available for the organizations planning to implement RADIUS. Some commercial software for enterprises and ISPs, bundled RADIUS appliances, or open source products such as FreeRADIUS FIGURE 9.10 RADIUS Authentication Process. Network Access Security 443 (www.freeradius.org) may be considered for deployment. Figure 9.11 shows a Juniper Networks Steel-Belted RADIUS implementation for server. Figure 9.12 shows Odyssey Access Client at the client side. A standard Juniper Networks Steel-Belted RADIUS deployment includes the following: Installation of the RADIUS server on a chosen software platform (available for SBR EE for Windows XP/2003, Sun Solaris 9/10 [SPARC] and 32-bit versions of Red Hat Enterprise Linux ES 4.0/5). Configure RADIUS clients (routers, switches, or WAPs) providing the RADIUS server details (normally the server IP and a shared secret). Install Odyssey Access clients on the client laptop (available for Micro- soft Windows 2000, Windows XP, and Windows Vista OSs, Microsoft Windows Mobile 5, Windows Mobile 3, Windows CE 4.2 and CE 5, and Windows 2003 for Pocket PC, Red Hat Enterprise Linux (RHEL) 3 and 4, and Apple Mac OS X version 10.4x OS. Configure Authentication Protocols and Policies on the RADIUS server (Figure 9.11). Configure authentication parameters on the client side (see Figures 9.12 and 9.13). FIGURE 9.11 Configur- ing Authentication Policies on Steel-Belted Radius Server. CHAPTER 9: Security Standards and Services 444 Vulnerabilities Certain “flavors” of RADIUS servers and Web servers can be compromised by buffer-overflow attacks. A buffer-overflow attack occurs when a buffer is flooded with more information than it can hold. The extra data overflows into other buffers and areas of program memory. The code injected through a buffer overflow attack may then be executed by the system and can result in exploitation of the target system. FIGURE 9.12 Configuring Odyssey Access Clients. FIGURE 9.13 Configuring Authentication Protocol on an Odyssey Access Client. HEAD OF THE CLASS… Sometimes You Just Get Lucky… Once we lock a door, curiosity leads someone to try and see what is behind it. This is the “cat-and-mouse game”; that is, network security. Many vulnerabilities found in network security are discovered by hackers trying to access systems they are not authorized to use. Sometimes, “white-hat” hackers – security con- sultants hired to test system vulnerabilities – discover vulnerabilities in their testing. Unlike “black-hat” hack- ers, whose intentions are malicious, and “gray-hat” hackers, whose intentions are not malicious, white-hat hackers generally work with companies to fix issues before they become to public knowledge. In 2001, RADIUS buffer-overflow attacks were discovered by ISSs while testing the vulnerabilities of the wireless networks. Network Access Security 445 Kerberos Kerberos (currently Kerberos v5-1.6.3) is used as the preferred network authentication protocol in many medium and large environments to authen- ticate users and services requesting access to resources. Kerberos is a net- work protocol designed to centralize the authentication information for the user or service requesting the resource. This allows authentication of the entity requesting access (user, machine, service, or process) by the host of the resource being accessed through the use of secure and encrypted keys and tickets (authentication tokens) from the authenticating key distribution center (KDC). It allows for cross-platform authentication and is available in many implementations of various NOSs. Kerberos is very useful in the distrib- uted computing environments currently used because it centralizes the processing of credentials for authentication. Kerberos uses timestamping of its tickets, to help ensure they are not compromised by other entities, and an overall structure of control that is called a realm. Some platforms use the defined terminology, whereas others such as Windows 2003 or Windows 2008 use their domain architecture to implement the Kerberos concepts. Kerberos is described in RFC 1510, which is available on the Web site www.ietf.org/rfc/rfc1510.txt?number=1510. Developed and owned by the Massachusetts Institute of Technology (MIT), information about the most current and previous releases of Kerberos is available on the Web at http:// web.mit.edu/Kerberos. Let’s look at how the Kerberos process works and how it helps secure authentication activities in a network. First, let’s look at Figure 9.14, which shows the default components of a Kerberos v5 realm: As can be seen in Figure 9.14, there is an authentication server requirement (the KDC). In a Kerberos realm, whether in a UNIX-based or Windows-based OS, the authentication process is the same. For this purpose, imagine that a client needs to access a resource on the resource server. Look at Figure 9.15 as we proceed, to follow the path for the authentication, first for logon, then at Figure 9.16 for the resource access path. FIGURE 9.14 Kerberos Required Components. . CHAPTER 9: Security Standards and Services 436 party’s hands, it can be used to falsely authenticate and identify someone as a valid party, forging false communications or using the user’s. FTP are examples of programs that simply transmit the user- name and password in cleartext to the party they are authenticating. Another area of concern is POP3 e-mail, which, in its default state,. control of them. Tokens provide an extremely high level of authentication because of the multiple parts they use to verify the identity of the user. Token technology is currently regarded as more