Confidentiality The contents or data are not revealedSecurity + is a security fundamentals and concepts exam. No security concepts exam would be complete without questions on access control, authentication, and auditing (AAA). AAA comprises the most basic fundamentals of work in the Information Technology (IT) security field, and AAA is critical to understand for any IT security practitioner. In this chapter, you will study CompTIA’s test objectives for Section 1, “General Security Concepts.” You will be introduced to network authentication and its finer details, as well as the concepts and terminology that will be explored and developed in later chapters.
AAA is a set of primary concepts that aid in understanding computer and network security as well as access control. These concepts are used daily to protect property, data, and systems from intentional or even unintentional damage. AAA is used to support the confidentiality, integrity, and availability (CIA) security concept, in addition to providing the framework for access to networks and equipment using Remote Authentication Dial-in User Service (RADIUS) and Terminal Access Controller Access Control System (TACACS/TACACS+).
A more detailed description of AAA is discussed in Request for Comments (RFC) 3127, which can be found at http://tools.ietf.org/html/rfc3127. This RFC contains an evaluation of various existing protocols against the AAA requirements and can help you understand the specific details of these protocols. The AAA requirements themselves can be found in RFC 2989 located at http://tools.ietf.org/html/rfc2989.
Clarification of Two Key Acronyms
It is important to understand the acronyms used in the Security+ exam. For purposes of the Security+ exam, two specific abbreviations need to be explained to avoid confusion. For general security study and the Security+ exam, AAA is defined as access control, authentication, and auditing. Do not confuse this with Cisco’s implementation and description of AAA, which is authentication, auditing, and accounting. Although similar in function and usage, the Security+ exam uses the first definition.
The second abbreviation requiring clarification is CIA. For purposes of the Security+ exam, CIA is defined as confidentiality, integrity, and availability. Other literature and resources such as the Sarbanes-Oxley Act and the Health Insurance Portability and Accountability Act of 1996 (HIPAA) guidelines may refer to CIA as confidentiality, integrity, and authentication.
AAA is a group of processes used to protect the data, equipment, and confidentiality of property and information. As mentioned earlier, one of the goals of AAA is to provide CIA. CIA can be briefly described as follows:
Confidentiality The contents or data are not revealed
Integrity The contents or data are intact and have not been modified
Availability The contents or data are accessible if allowed
AAA consists of three separate areas that work together. These areas provide a level of basic security in controlling access to resources and equipment in networks. This control allows users to provide services that assist in the CIA process for further protection of systems and assets.
Notes from the Field
Access and Authentication
The difference between access control and authentication is a very important distinction, which you must understand to pass the Security+ exam. Access control is used to control the access to a resource through some means. This could be thought of as a lock on a door or a guard in a building. Authentication, on the other hand, is the process of verifying that the person trying to access whatever resource is being controlled is authorized to access the resource. In our analogy, this would be the equivalent of trying the key or having the guard check your name against a list of authorized people. So in summary, access control is the lock and authentication is the key.
Access control can be defined as a policy, software component, or hardware component that is used to grant or deny access to a resource. This can be an advanced component such as a Smart Card, a biometric device, or network access hardware such as routers, remote access points such as remote access service (RAS), and virtual private networks (VPNs), or the use of wireless access points (WAPs). It can also be file or shared resource permissions assigned through the use of a network operating system (NOS) such as Microsoft Windows with Active Directory or UNIX systems using Lightweight Directory Access Protocol (LDAP), Kerberos, or Sun Microsystem’s Network Information System (NIS) and Network Information System Plus (NIS+). Finally, it can be a rule set that defines the operation of a software component limiting entrance to a system or network.
Authentication can be defined as the process used to verify that a machine or user attempting access to the networks or resources is, in fact, the entity being presented. For this chapter, nonrepudiation is the method used (time stamps, particular protocols, or authentication methods) to ensure that the presenter of the authentication request cannot later deny they were the originator of the request. In the following sections, authentication methods include presentation of credentials (such as a user-name and password, Smart Card, or personal identification number [PIN]) to a NOS (logging on to a machine or network), remote access authentication, and a discussion of certificate services and digital certificates. The authentication process uses the information presented to the NOS (such as username and password) to allow the NOS to verify the identity based on those credentials.
Auditing is the process of tracking and reviewing events, errors, access, and authentication attempts on a system. Much like an accountant’s procedure for keeping track of the flow of funds, you need to be able to follow a trail of access attempts, access grants or denials, machine problems or errors, and other events that are important to the systems being monitored and controlled. In the case of security auditing, you will learn about the policies and procedures that allow administrators to track access (authorized or unauthorized) to the network, local machine, or resources. Auditing is not enabled by default in many NOSes, and administrators must often specify the events or objects to be tracked. This becomes one of the basic lines of defense in the security and monitoring of network systems. Tracking is used along with regular reading and analysis of the log files generated by the auditing process to better understand if the access controls are working.
Authentication, when looked at in its most basic form, is simply the process used to prove the identity of someone or something that wants access. This can involve highly complex and secure methods, which may involve higher costs and more time, or can be very simple. For example, if someone you personally know comes to your door, you visually recognize them, and if you want them to enter, you open the door. In this case, you have performed the authentication process through your visual recognition of the individual. All authentication processes follow this same basic premise; that we need to prove who we are or who the individual, service, or process is before we allow them to use our resources.
Authentication allows a sender and receiver of information to validate each other as the appropriate entities with which they want to work. If entities wishing to communicate cannot properly authenticate each other, there can be no trust in the activities or information provided by either party. Only through a trusted and secure method of authentication can administrators provide for a trusted and secure communication or activity.
One-factor authentication methods as simple methods as username and password combinations have been used for authenticating purposes for many years. Most OSes have had some form of local authentication that could be used if the OS was designed to be used by multiple users. Windows, Novell Netware, UNIX, and Linux have all had local authentication paths early in their development. Although this is the most common authentication method, it is not without its problems. From a security standpoint, it is important to understand that the first line of defense of a system is the creation and maintenance of a password policy that is enforced and workable. You need to both implement and enforce the policy to ensure that this rudimentary protection is in place in your network. Most OSes have methods of utilizing username/password policies.
Password policies that require a user-created password that is less than 6 characters long are generally regarded as having a low (or no) security level. Password policies that require between 8 and 13 characters are regarded as a medium security level. Policies requiring 14 or more characters are regarded as a high security level. These security levels are based on the difficulty of discovering the password through the use of dictionary and brute force attacks. Additionally, all password policies, regardless of password length, should require that an acceptable password contain a combination of the following:
Uppercase and lowercase alphabetic characters
Numbers
Special characters
No dictionary words
No portion of the username in the password
No personal identifiers should be used including birthdays, social security number, pet’s name, and so on
To achieve the medium security level, implement the use of eight characters, including uppercase and lowercase, numbers, and special characters. For high security, implement the medium security settings, and enforce the previous settings plus no dictionary words and no use of the username in the password. Be aware that the higher the number of characters or letters in a password, the more chance exists that the user will record the password and leave it where it can be found. Most policies work at about the eight-character range, and require periodic changes of the password as well as the use of special characters or numbers.
The simplest form of authentication is the transmission of a shared password between entities wishing to authenticate each other. This can be as simple as a secret handshake or a key. As with all simple forms of protection, once knowledge of the secret key or handshake is disclosed to nontrusted parties, there can no longer be trust in who is using the secrets.
Many methods can be used by an unauthorized person to acquire a secret key, from tricking someone into disclosing it, to high-tech monitoring of communications between parties to intercept the key as it is passed between parties. However the code is acquired, once it is in a nontrusted party’s hands, it can be used to falsely authenticate and identify someone as a valid party, forging false communications, or utilizing the user’s access to gain permissions to the available resources.
Original digital authentication systems shared a secret key across the network with the entity with which they wanted to authenticate. Applications such as Telnet and File Transfer Protocol (FTP) are examples of programs that simply transmit the username and password in cleartext to the party they are authenticating. Another area of concern is Post Office Protocol 3 (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 earlier, sharing a handshake or secret key does not provide long lasting and secure communication or the secure exchange of authentication information. This has led to more secure methods of protection of authentication 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 (non-encrypted) 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 connection 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. Secure Sockets Layer (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 prevent anyone from viewing e-mail as it is downloaded to an e-mail client.
Some brute force crackers, including POP, Telnet, FTP, and Hypertext Transfer Protocol (HTTP), can be found at http://packetstormsecurity.nl/Crackers/ and can be used as examples for this technique.
Two-factor authentication can be implemented with a combination of something 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 like an ATM, they must acquire your ATM card and the PIN number. The authentication could 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 that has control of them. Tokens provide an extremely high level of authentication because of the multiple parts they employ to verify the identity of the user. Token technology is currently regarded as more secure than most forms of biometrics, because 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 utilize at least two components. They are:
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 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 utilize these functions. Others implement processes that involve 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 in its basic implementation is not as random as other token methods.
Three-factor authentication—commonly known as multifactor authentication—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. Use of similar authentication mechanisms repetitively may not be classified as multifactor authentication. The implementation should utilize three independent authentication mechanisms available.
Following are the four possible types of factors that can be used for multifactor authentication.
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. Multifactor 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 (“something 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 authentication becomes onerous to the users and they no longer use the process 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 (SSO) is a process in which we simplify the access to different systems by authenticating the user once. SSO needs to be implemented with stringent policies with access control and authorization mechanisms and group policies to ensure simplification does not result in compromise in security. In a corporate scenario, a user may have to log on to the local directory services for authentication, a mail service may require another password, client-server applications such as CRM or ERP may need authentication, and several other software applications may incorporate different authentication procedures.
Apart from reducing the password fatigue it may result in increased productivity and simplified management 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 Windows 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 Single Sign-On (ESSO) solutions.
From a simple user authentication to the local domain services to that of sophisticated online banking systems, various authentication systems are adopted by the organizations. As the need for complex security arises, additional 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 the design of the security. Introducing a hardware element sometimes is considered a higher level of security as one has to get hold of both the hardware (such as token card) and exploit the vulnerabilities of the system to break-in. In this section, we’ll discuss about RADIUS, Kerberos, and LDAP authentication services, authentication protocols including Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), 802.1x methods and implementations that offer powerful accounting tools such as TACACS+. To begin with, we’ll discuss about authentication policies that are used to granularly control the access methods and type of authentication protocols remote users need to comply with to access the resources.
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 connected 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 physical LAN can be defined as a remote user and access policies can be applied.
Authentication servers refer to the directory services (discussed later in this chapter) before the users are authenticated. However, remote access policies go beyond just authenticating 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, 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
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.
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 employed optical scans of fingerprints were fooled by fogging of the 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.
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 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 usernames 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 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 number of protocols including:
Point-to-Point Protocol (PPP)
Password Authentication Protocol (PAP)
Challenge Handshake Authentication Protocol (CHAP)
RADIUS authentication consists of five steps (Figure 9.1):
1. Users initiate a connection with an Internet service provider (ISP) RAS or corporate RAS. Once a connection is established, users are prompted for a username and password.
2. The RAS encrypts the username and password using a shared secret, and passes the encrypted packet to the RADIUS server.
FIGURE 9.1
The RADIUS Authentication Process
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 appropriate rights.
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 (www.freeradius.org) may be considered for deployment. Figure 9.2 shows a Juniper Networks Steel-Belted RADIUS implementation for server. Figure 9.3 shows Odyssey Access Client at the client side.
A standard Juniper Networks Steel-Belted RADIUS deployment includes:
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 Microsoft Windows 2000, Windows XP, and Windows Vista operating systems, 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.4.x operating system).
Configure Authentication Protocols and Policies on the RADIUS server (Figure 9.2).
Configure authentication parameters on the client side (Figures 9.3 and 9.4).
FIGURE 9.2
Configuring Authentication Policies on a Steel-Belted RADIUS Server
FIGURE 9.3
Configuring Odyssey Access Clients
FIGURE 9.4
Configuring Authentication Protocol on an Odyssey Access Client
Note The Security+ exam does not have product specific questions. However, it’s a good practice to download evaluation versions of commercially available RADIUS products or open source tools to practice the concepts.
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.
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 consultants hired to test system vulnerabilities—discover vulnerabilities in their testing. Unlike “black-hat” hackers, 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 public knowledge. In 2001, RADIUS buffer-overflow attacks were discovered by Internet Security Systems while testing the vulnerabilities of the wireless networks.
Kerberos (currently Kerberos v5-1.6.3) is used as the preferred Network Authentication Protocol in many medium and large environments, to authenticate users and services requesting access to resources. Kerberos is a network 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 NOS. Kerberos is very useful in the distributed computing environments currently used, because it centralizes the processing of credentials for authentication. Kerberos utilizes time stamping 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, while others such as Windows 2003 or Windows 2008 use their domain structure to implement the Kerberos concepts.
Kerberos is described in RFC 1510, which is available on the Web at 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.5, which shows the default components of a Kerberos v5 realm:
As can be seen in Figure 9.5, 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.6 as we proceed, to follow the path for the authentication, first for logon, then at Figure 9.7 for the resource access path.
As seen in Figure 9.6, two events are occurring as credentials are presented (password, Smart Card, biometrics) to the KDC for authentication. This is due to the dual role of the KDC. It acts as both an Authentication Server and as a Ticket Granting Server. First, the authentication credential is presented to the KDC where it is authenticated using the Authentication Server mechanism. Second, the KDC issues a Ticket Granting Ticket (TGT) through the Ticket Granting Server mechanism that is associated with the access token while you are actively logged in and authenticated. This TGT expires when you (or the service) disconnect or log off the network, or after it times out. The Kerberos administrator can alter the expiry timeout as needed to fit the organizational needs, but the default is 1 day (86,400 s). This TGT is cached locally for use during the active session.
FIGURE 9.5
Kerberos Required Components
FIGURE 9.6
Authentication Path for Logon Access in a Kerberos Realm
FIGURE 9.7
Resource Access in a Kerberos Realm
Figure 9.7 shows the process for resource access in a Kerberos realm. It starts by presenting the previously granted TGT to the authenticating KDC. The authenticating KDC returns a session ticket to the entity wishing access to the resource. This session ticket is then presented to the remote resource server. The remote resource server, after accepting the session ticket, allows the session to be established to the resource.
Kerberos uses a time stamp and we need to understand where and when the time stamp is used. The time stamp is used to limit the possibility of replay or spoofing of credentials. Replay is the capture of information, modification of the captured information, and retransmission of the modified information to the entity waiting to receive the communication. If unchecked, this allows for impersonation of credentials when seeking access. Spoofing is the substitution of addressing or authentication information to try to attain access to a resource based on information acceptable to the receiving host, but not truly owned by the sender. The initial time stamp refers to any communication between the entity requesting authentication and the KDC. Normally, this initial time period will not be allowed to exceed 10 min if based on the MIT Kerberos software default. Microsoft’s Kerberos implementation has a 5-min time delta. If clocks are not synchronized between the systems, the credentials (tickets) will not be granted if the time differential exceeds the established limits. Session tickets from the KDC to a resource must be presented within this time period or they will be discarded. The session established between the resource server and the requesting entity is also time-stamped, but generally lasts as long as the entities’ logon credential is valid. This can be affected by system policies such as logon hour restrictions, which are defined in the original access token. TGT tickets are not part of the default 5-min period, rather they are cached locally on the machine and are valid for the duration of the logged-on session.
Directory services are used to store and retrieve information about objects, which are managed by the service. On a network, these objects can include user accounts, computer accounts, mail accounts, and information on resources available on the network. Because these objects are organized in a directory structure, you can manage them by accessing various properties associated with them. For example, a person’s account to use the network would be managed through such attributes as the user’s username, password, times the user is allowed to log on, and other properties of the user’s account. By using a directory service to organize and access this information, the objects maintained by the service can be effectively managed.
The concept of a directory service can be somewhat confusing, until you realize that you’ve been using them for most of your life. A type of directory that’s been around longer than computers is a telephone directory, which organizes the account information of telephone company customers. These account objects are organized to allow people to retrieve properties like the customer’s name, phone number, and address.
Directory services shouldn’t be confused with the directory itself. The directory is a database that stores data on the objects managed through directory services. To use our telephone directory example again, consider that the information on customer accounts can be stored in a phonebook or electronically in a database. Regardless of whether the information is accessed through an operator or viewed online using a 411 service, the directory service is the process of how the data is accessed. The directory service is the interface or process of accessing information, while the directory itself is the repository for that data.
Directory services are used by many different network OSes to organize and manage the users, computers, printers, and other objects making up the network. Some of the directory services that are produced by vendors include:
Active Directory , which was developed by Microsoft for networks running Windows 2000 Server, Windows 2003 Server, or Windows 2008.
eDirectory , which was developed by Novell for Novell NetWare networks. Previous versions for Novell NetWare 4.x and 5.x were called Novell Directory Services (NDS).
OpenLDAP , which was developed by Apple for networks running Mac OS X Servers.
To query and modify the directory on Transmission Control Protocol/Internet Protocol (TCP/IP) networks, the LDAP can be used. LDAP is a protocol that enables clients to access information within a directory service, allowing the directory to be searched and objects to be added, modified, and deleted. LDAP was created after the X.500 directory specification that uses the Directory Access Protocol (DAP). Although DAP is a directory service standard protocol, it is slow and somewhat complex. LDAP was developed as an alternative protocol for TCP/IP networks because of the high overhead and subsequent slow response of heavy X.500 clients, hence the name lightweight. Because of the popularity of TCP/IP and the speed of LDAP, the LDAP has become a standard protocol used in directory services.
LDAP services are used to access a wide variety of information that’s stored in a directory. On a network, consider that the directory catalogs the name and information on every user, computer, printer, and other resource on the network. The information on a user alone may include their username, password, first name, last name, department, phone number and extension, e-mail address, and a slew of other attributes that are related to the person’s identity. The sheer volume of this data requires that LDAP directories are effectively organized, so that the data can be easily located and identified in the directory structure.
Because LDAP is a lightweight version of DAP, the directories used by LDAP are based on the same conventions as X.500. LDAP directories follow a hierarchy, much in the same way that the directories on your hard drive are organized in a hierarchy. Each uses a tree-like structure, branching off of a root with containers (called organizational units [OUs] in LDAP; analogous to folders on a hard drive) and objects (also called entries in LDAP’s directory; analogous to files on a hard drive). Each of the objects has attributes or properties that provide additional information. Just as a directory structure on a hard disk may be organized in different ways, so can the hierarchy of an LDAP directory. On a network, the hierarchy may be organized in a number of ways, following the organizational structure, geographical location, or any other logical structure that makes it easy to manage the objects representing users, computers, and other resources.
Because LDAP directories are organized as tree structures (sometimes called the Directory Information Tree [DIT]), the top of the hierarchy is called the root. The root server is used to create the structure of the directory, with OUs and objects branching out from the root. Because the directory is a distributed database, parts of the directory structure may exist on different servers. Segmenting the tree based on organization or division and storing each branch on separate directory servers increases the security of the LDAP information. By following this structure, even if one directory server is compromised, only a branch of the tree (rather than the entire tree) is compromised.
The hierarchy of an LDAP directory is possible because of the various objects that make up its structure. These objects represent elements of the network, which are organized using containers called OUs. Each OU can be nested in other OUs, similar to having subfolders nested in folders on your hard disk. In the same way the placement of folders on your hard disk makes a directory structure, the same occurs with OUs and objects in an LDAP directory.
The topmost level of the hierarchy generally uses the Domain name system (DNS) to identify the tree. For example, a company named Syngress might use syngress.com at the topmost level. Below this, OUs are used to identify different branches of the organization or network. For example, you might have the tree branch off into geographical locations, like Paris, London, and Toronto, or use them to mimic the organizational chart of the company, and create OUs with names like Administration, Research, Technology, and so forth. Many companies will even use a combination of these methods, and use the OUs to branch out by geographical location, and then create OUs for divisions of the company within the OUs representing locations.
To identify the OUs, each has a name that must be unique in its place in the hierarchy. For example, you can’t have two OUs named printers in a container named sales. As with many elements of the directory it is analogous to the directory structure of a hard disk where you can’t have two subfolders with the same name in the same folder. You can however have OUs with the same name in different areas of the hierarchy, such as having an OU named printers in the sales container and another OU named printers in an OU named service.
The structure of the LDAP directory is not without its own security risks, as it can be a great source of information for intruders. Viewing the placement of OUs can provide a great deal of information about the network structure, showing which resources are located in which areas of the organization. If an administrator followed a particular scheme of designing the hierarchy too closely, a hacker could determine its structure using information about the organization. For example, companies often provide their organizational charts on the Internet, allowing people to see how the company is structured. If an administrator closely followed this chart in designing a hierarchy, a hacker could speculate how the LDAP directory is laid out. If the hacker can gain access to the directory using LDAP queries, he or she could then use this information to access objects contained in different OUs named after departments on the chart. Using naming conventions internal to the company (such as calling a London base of operations district1) or using some creativity in naming schemes (such as calling an OU containing computer accounts WK instead of workstations) will make the hierarchy’s structure less obvious to outsiders. Although using the organizational chart of a company and geographical locations can be used as a basis for designing the hierarchy, it should not be an easy-to-guess blueprint of the directory and network infrastructure.
As mentioned earlier, entries in the directory are used to represent user accounts, computers, printers, services, shared resources, and other elements of the network. These objects are named, and as we discussed with OUs, each object must have a name that’s unique to its place in the namespace of the hierarchy. Just as you can’t have two files with the same name in a folder on your hard disk, you can’t have two objects with the same name in an OU. The name given to each of these objects is referred to as a common name, which identifies the object but doesn’t show where it resides in the hierarchy.
The commo ame is part of the LDAP naming convention. Just as a filename identifies a file, and a full pathname identifies its place in a directory structure, the same can be seen in the LDAP naming scheme. The commo ame identifies the object, but a distinguished name can be used to identify the object’s place in the hierarchy. An example of a distinguished name is the following, which identifies a computer named DellDude that resides in an OU called marketing in the tacteam. net domain:
DN: CN = DellDude, OU = Marketing, DC = tacteam, DC = net
The distinguished name is a unique identifier for the object and is made up of several attributes of the object. It consists of the relative distinguished name, which is constructed from some attribute(s) of the object, followed by the distinguished name of the parent object.
Each of the attributes associated with an object is defined in the schema. The schema defines the object classes and attribute types, and allows administrators to create new attributes and object classes specific to the needs of their network or company. For example, a “supervisor” attribute in a user account might contain the name of the user’s manager, whereas a “mail” attribute would contain the user’s e-mail address. Object classes define what the object represents (that is, user, computer, and so forth), and a list of what attributes are associated with the object.
Because LDAP is binary, to view the attributes of an object, the information can be represented in LDAP data interchange format (LDIF). LDIF is used to show directory entries in an easy-to-follow format, and used when requests are made to add, modify, or delete entries in the directory. The following is an LDAP directory entry with several attributes represented in LDIF:
dn: cn = John Abraham, dc = syngress, dc = com
cn: John Abraham
givenName: John
sn: Abraham
telephoneNumber: 905 555 1212
ext: 1234
employeeID: 4321
mail:jabraham@ssyngress.com
manager: Gary Byrne
objectClass: organizationalPerson
As you can see by this entry, the attributes provide a wide degree of information related to the person represented by the object. By looking at this information, we can see contact information, employee identification numbers, the person’s manager, and other data. Other attributes could include the person’s social security number or social insurance number, home address, photo, expense account numbers, credit card numbers issued to the person, or anything else the company wished to include. Although this example reflects a user account, a similar wealth of information can be found in objects representing computers and printers (which would include IP addresses) and other resources on the network. As stated earlier, although useful to authorized users, it is also useful for unauthorized intruders who could use the information for identity theft, hacking specific computers, or any number of other attacks.
LDAP is vulnerable to various security threats, including spoofing of directory services, attacks against the databases that provide the directory services, and many of the other attack types discussed in this book (for example, viruses, OS and protocol exploits, excessive use of resources and denial of service, and so forth). This isn’t to say that LDAP is completely vulnerable. LDAP supports a number of different security mechanisms, beginning from when clients initially connect to an LDAP server.
LDAP clients must authenticate to the server before being allowed access to the directory. Clients (users, computers, or applications) connect to the LDAP server using a distinguished name and authentication credentials (usually a password). Authentication information is sent from the client to the server as part of a “bind” operation, and the connection is later closed using an “unbind” operation. Unfortunately, it is possible for users to make the connection with limited or no authentication, using either anonymous or simple authentication. LDAP allows for anonymous clients to send LDAP requests to the server without first performing the bind operation. Although anonymous connections don’t require a password, simple authentication will send a person’s password over the network unencrypted. To secure LDAP, anonymous clients should be limited or not used, ensuring that only those with proper credentials are allowed access to the information. Optionally, the connection can use transport layer security (TLS) to secure the connection and protect any data transmitted between the client and server.
LDAP can also be used over SSL, which extends security into the Internet. LDAPS is secure LDAP, which encrypts LDAP connections using SSL or TLS. Some of these types of services integrate as objects, such as PKI certificates, in the authentication process using Smart Card technologies, and in the extended properties of account objects so that they can support extra security requirements. To use SSL with LDAP, the LDAP server must have an X.509 server certificate. Additionally, SSL/TLS must be enabled on the server.
Another issue that can impact the security of LDAP is packet sniffing. Packet sniffers are software that can capture packets of data from a network and allow a person to view its contents. If the information traveling over LDAP is unencrypted, the packets of data could be captured, and analysis of the packets could provide considerable information about the network. In addition to using encryption, ports can be blocked to prevent access from the Internet. LDAP uses TCP/UDP port 389 and LDAPS uses port 636. By blocking these ports from the Internet, it will prevent those outside of the internal network from listening or making connections to these ports.
The challenge with using a protocol such as LDAP is that the connectivity must be facilitated through a script or program. These types of scripts must indicate the location of the objects within the directory service to access them. If the administrator wants to write a quick, simple script, this means that the name of the directory service and the names and locations of the objects that are being accessed must each be placed in the script and known prior to the script being written. If they need to access a different object, they usually need to rewrite the script or develop a much more complex program to integrate the directory services. Even so, compare scripting to native access with queries and interactive responses, and the value of a homogenous network with a single directory service is revealed. In a homogenous network, there is no need to logically connect two directory services with a script. This greatly reduces the time and effort involved in administering the network.
Homogenous networks are unusual at best. With multiple types of network OSes, desktop OSes, and infrastructure OSes available today, it is likely that there will be multiple systems around. It follows that they all must be managed in different ways.
LDAP-enabled Web servers can handle authentication centrally, using the LDAP directory. This means the users will only need a single login name and password for accessing all resources that use the directory. Users benefit from SSO to allow access to any Web server using the directory, or any password-protected Web page or site that uses the directory. The LDAP server constitutes a security realm, which is used to authenticate users.
Another advantage of LDAP security for Web-based services is that access control can be enforced based on rules that are defined in the LDAP directory instead of the administrator having to individually configure the OS on each Web server.
There are security programs available, such as PortalXpert Security, which can be used with LDAP to extend enforcement of the security policies that are defined by the LDAP directory to Web servers that are not LDAP enabled, and provide role-based management of access controls.
NOTE For more detailed information about LDAP security issues, see the white paper titled “Introduction to Security of LDAP Directory Services” by Wenling Bao at the SANS Institute Web site at www.giac.org/certified_professionals/practicals/gsec/0824.php.
PAP is the simplest form of authentication for a remote access. This method was used earlier to authenticate users using username and passwords. The user provides username and passwords for authentication that is received by the access server and upon successful validation the server sends an ack for acknowledgment or a nack for failed authentication. This method is also known as a two-way handshake.
PAP transmits the username and password in ASCII without any encryption. PAP was replaced with CHAP to provide more security.
One of the methods that can be used to protect information when using remote access to a resource is the CHAP. CHAP is a remote access authentication protocol used in conjunction with PPP to provide security and authentication to users of remote resources. You will recall that PPP replaced the older Serial Line Internet Protocol (SLIP). PPP not only allows for more security than SLIP, but also does not require static addressing to be defined for communication. PPP allows users to use dynamic addressing and multiple protocols during communication with a remote host. CHAP is described in RFC 1994, available at www.ietf.org/rfc/rfc1994.txt?number=1994. The RFC describes a process of authentication that works in the following manner:
CHAP is used to periodically verify the identity of the peer using a three-way handshake. This is done upon initial link establishment and may be repeated anytime after the link has been established.
1. After the link establishment phase is complete, the authenticator sends a “challenge” message to the peer.
2. The peer responds with a value calculated based on an ID value, a random value, and the password using a “one-way hash” function such as MD5.
3. The authenticator checks the response against its own calculation of the expected hash value. If the values match, the authentication is acknowledged; otherwise the connection should be terminated.
4. At random intervals, the authenticator sends a new challenge to the peer, and repeats steps 1 to 3.
CHAP operates in conjunction with PPP to provide protection of the credentials presented for authentication, and to verify connection to a valid resource. It does not operate with encrypted password databases, and therefore is not as strong a protection as other levels of authentication. The shared secrets may be stored on both ends as a cleartext item, making the secret vulnerable to compromise or detection. CHAP may also be configured to store a password using one-way reversible encryption, which uses the one-way hash noted earlier. This provides protection to the password, because the hash must match the client wishing to authenticate with the server that has stored the password with the hash value. CHAP is better than PAP, however, because PAP sends passwords across the network in cleartext.
RADIUS is not the only centralized RAS. TACACS is also used in authenticating remote users. TACACS has gone through three major “generations,” TACACS, XTACACS, and TACACS+. For the Security+ exam, you need to know about TACACS and TACACS+.
As stated previously, TACACS is the “old man” of centralized remote access authentication. TACACS was first developed during the days of ARPANET, which was the basis for the Internet. TACACS is detailed in RFC 1492, which can be found at http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1492.html. Although TACACS offers authentication and authorization, it does not offer any accounting tools. As mentioned earlier, a good RAS must fit all the criteria of the AAA model. Similar to RADIUS, a dial-up user connects to a RAS that prompts the user for their credentials. The credentials are then passed to the TACACS server, which either permits or denies access to the network.
Cisco decided to develop a proprietary version of TACACS known as TACACS+.
The driving factor behind TACACS+ was to offer networking professionals the ability to manage all remote access components from a centralized location. TACACS+ is also credited with separating the AAA functions. TACACS+ is considered proprietary because its packet formats are completely different from those in TACACS or XTACACS, making TACACS+ incompatible with previous versions. Unlike previous versions of TACACS that used one database for all AAA, TACACS+ uses individual databases for each. TACACS+ was the first revision to offer secure communications between the TACACS+ client and the TACACS+ server. TACACS+ uses TCP as its transport and continues to gain popularity because it is easy to implement and reasonably priced.
Exam Warning Make sure that you understand the difference between TACACS and TACACS+. The most important thing to remember is that TACACS uses UDP as its transport protocol while TACACS+ uses TCP. Also, TACACS+ is a proprietary version owned by Cisco.
The largest vulnerability in TACACS+ is the comparative weakness of the encryption mechanism. It’s possible for someone with physical network access to capture an authentication request from a client and manipulate it. This request would be accepted by the server; the encrypted reply would be sent but because the cleartext of that reply would be known, breaking the encryption would be a fairly simple task. Even worse, the encryption used in TACACS+ is based on a shared secret that is rarely changed, so a compromise at any point would ultimately expose future compromises. It is, therefore, a very good idea to regularly change the shared secrets used by TACACS+ clients.
One of the biggest complaints regarding TACACS+ is that it does not offer protection against replay attacks. Replay attacks occur when a hacker intercepts an encrypted packet and impersonates the client using the information obtained from the decrypted packet. When files are sent over a network using TCP/IP, they are split into segments suitable for routing. This is known as packet sequencing. At the receiving end, the TCP/IP organizes the file into its original format before it was sent. Packet sequencing (along with time stamping) is the general method of preventing replay attacks; however, TACACS+ sessions always start with a sequence number of 1. If a packet cannot be reorganized in the proper sequence at the receiving end, the entire message (or file) is unusable. Other common weaknesses of TACACS+ include:
Birthday Attacks The pool of TACACS+ session IDs is not very large, therefore, it is reasonable that two users could have the same session ID.
Buffer Overflow Such as RADIUS and TACACS+ can fall victim to buffer-overflow attacks.
Packet Sniffing The length of passwords can be easily determined by “sniffing” a network.
Lack of Integrity Checking An attacker can alter accounting records during transmission because the accounting data is not encrypted during transport.
Decisions to be Made: RADIUS Versus TACACS+
Both RADIUS and TACACS+ get the job done. Both provide exceptional user authentication, both are transparent to the end user, and both have their share of problems. Specifically, the two issues that differentiate them are separation of duties and the need for reliable transport protocols.
In terms of separation of duties, RADIUS lumps all of the AAA functions into one user profile, whereas TACACS+ separates them.
We know that TACACS+ uses TCP for its transport protocol. Both RADIUS and TACACS, on the other hand, use UDP. If reliable transport and sensitivity to packet disruption is important, TACACS+ is the better fit.
Mutual authentication is a process where both the requestor and the target entity must fully identify themselves before communication or access is allowed. This can be accomplished in a number of ways. You can share a secret or you can use a Diffie-Hellman key exchange that provides a more secure method of exchange that protects the secret being used for the verification and authentication process. Another method that can be used for mutual authentication is the use of certificates. To verify the identities, the certificate authority (CA) must be known to both parties, and the public keys for both must be available from the trusted CA. This is occasionally used with SSL, where both the server and the client have certificates and each is used to confirm the identity of the other host.
One area that uses the mutual authentication process is access of a user to a network via remote access or authentication via a RADIUS server. This case requires the presence of a valid certificate to verify that the machine is the entity that is allowed access to the network. For instance, early implementations of Windows-based RAS servers had the ability to request or verify a particular telephone number to try to verify the machine location. With the development of call forwarding technologies, however, it became apparent that this was no longer satisfactory. Mutual authentication allows you to set secure parameters and be more confident that communication is not being intercepted by a man-in-the-middle (MITM) attacker or being redirected in any way.
Mutual authentication provides more secure communications by positively identifying both sides of a communication channel. However, it is often difficult or costly to implement. An example of this is in the online banking industry. Online banks use SSL certificates to confirm that the site the customer is communicating with is indeed the site they are expecting. With mutual authentication, this confirmation would be expanded so that the online banking site is certain that the user accessing an account is actually who they say they are. Setting up mutual authentication in this manner would involve requiring each user to obtain a certificate from a CA trusted by the online bank. Instructing the user on how to accomplish this would be a daunting task. And what if they need to access their account from a different system? If the certificate is based on their home computer, they may need to obtain another certificate for use on a second system. Additional complexities such as lost certificates and the use of shared systems would also apply.
With these complexities, mutual authentication is not implemented as frequently as it probably should be to ensure secure communications. Many security implementations such as IPsec or 802.1x as well as others provide the option of using mutual authentication, but it is up to the entities implementing the security to choose whether or not they will use that option.
802.1x and Extensible Authentication Protocol (EAP) provide for a mutual authentication capability. This makes the clients and the authentication servers mutually authenticating end points and assists in the mitigation of attacks from MITM types of devices. Any of the following EAP methods provide for mutual authentication:
TLS requires that the server supply a certificate and establish that it has possession of the private key.
Internet Key Exchange (IKE) requires that the server show possession of a preshared key or private key (this can be considered certificate authentication).
GSS_API (Kerberos) requires that the server can demonstrate knowledge of the session key.
The IEEE 802.1x standard was created for the purpose of providing a security framework for port-based access control that resides in the upper layers of the protocol stack. The most common method for port-based access control is to enable new authentication and key management methods without changing current network devices. The benefits that are the end result of this work include the following:
There is a significant decrease in hardware cost and complexity.
There are more options, allowing administrators to pick and choose their security solutions.
The latest and greatest security technology can be installed and should still work with the existing infrastructure.
You can respond quickly to security issues as they arise.
EXAM WARNING 802.1x typically is covered in the AAA sections of the Security+ exam, but is relevant to wireless networks because of the fact that it is quickly becoming the standard method of securely authenticating on a wireless network. Also, do not confuse 802.1x with 802.11x.
When a client device connects to a port on an 802.1x-capable AP, the AP port determines the authenticity of the devices. Figure 9.8 shows a typical 802.1x authentication process.
FIGURE 9.8
802.1x Authentication Process
Before discussing the workings of the 802.1x standard, the following terminology must be defined:
Port A single point of connection to a network.
Port Access Entity (PAE) controls the algorithms and protocols that are associated with the authentication mechanisms for a port.
Authenticator PAE enforces authentication before allowing access to resources located off of that port.
Supplicant PAE tries to access the services that are allowed by the authenticator.
Authentication Server is used to verify the supplicant PAE. It decides whether or not the supplicant is authorized to access the authenticator.
Extensible Authentication Protocol Over LAN (EAPoL) 802.1x defines a standard for encapsulating EAP messages so that they can be handled directly by a LAN MAC service. 802.1x tries to make authentication more encompassing, rather than enforcing specific mechanisms on the devices. Because of this, 802.1x uses EAP to receive authentication information.
Extensible Authentication Protocol Over Wireless (EAPoW) When EAPoL messages are encapsulated over 802.11 wireless frames, they are known as EAPoW.
The 802.1x standard works in a similar fashion for both EAPoL and EAPoW. As shown in Figure 9.9, the EAP supplicant (in this case, the wireless client) communicates with the AP over an “uncontrolled port.” The AP sends an EAP Request/Identity to the supplicant and a RADIUS-Access-Request to the RADIUS access server. The supplicant then responds with an identity packet and the RADIUS server sends a challenge based on the identity packets sent from the supplicant. The supplicant provides its credentials in the EAP-Response that the AP forwards to the RADIUS server. If the response is valid and the credentials validated, the RADIUS server sends a RADIUS-Access-Accept to the AP, which then allows the supplicant to communicate over a “controlled” port. This is communicated by the AP to the supplicant in the EAP-Success packet.
FIGURE 9.9
EAP Over LAN (EAPoL) Traffic Flow
Head of the Class
So What Exactly Are 802.1x and 802.11x ?
Wireless provides convenience and mobility, but also poses massive security challenges for network administrators, engineers, and security administrators. Security for 802.11 networks can be broken down into three distinct components:
The authentication mechanism
The authentication algorithm
Data frame encryption
With the addition of the 802.1x standard, clients are identified by username, not by the MAC addresses of the devices. This design not only enhances security, but also streamlines the process of authentication, authorization, and accountability (AAA) for the network. 802.1x was designed to support extended forms of authentication using password methods (such as one-time passwords, or GSS_API mechanisms such as Kerberos) and nonpassword methods (such as biometrics, IKE, and Smart Cards).
The IEEE 802.1x standard allows for the creation of per-user session keys. Wireless Encryption Protocol (WEP) keys do not have to be kept at the client device or at the AP when using 802.1x. These WEP keys are dynamically created at the client for every session, thus making it more secure. The Global key, similar to a broadcast WEP key, can be encrypted using a Unicast session key, and then sent from the AP to the client in a much more secure manner.
The IEEE 802.11b standard is severely limited because it is available only for the open and shared-key authentication scheme which is nonextensible. To address the weaknesses in the authentication mechanisms, several vendors (including Cisco and Microsoft) adopted the IEEE 802.1x authentication mechanism for wireless networks. The IEEE 802.11 standard is focused more on wireless LAN connectivity than on verifying user or station identity. Because wireless can potentially scale very high in the sheer number of possible users, it is important to consider a centralized way to have user authentication. However, as the management frames are unprotected malicious attacks are still a possibility. The IEEE 802.11w is a proposed amendment to the existing 802.11 standards to increase the security. This project is known as Protected Management Frames addressing the security of management frames. The 802.11w defines enhancements for integrity, authenticity, and confidentiality of the data and ensure protection from replay attacks.
EAP was originally defined under RFC 2284 and then redefined under the Internet Engineering Task Force (IETF) Internet draft dated September 13, 2002. EAP is an authentication protocol designed to support several different authentication mechanisms. It runs directly over the data link layer and does not require the use of Internet Protocol (IP).
NOTE You can read more on the IETF Internet draft on EAP at www.potaroo.net/ietf/ids/draft-ietf-pppext-rfc2284bis-06.txt.
EAP comes in several different forms:
EAP over IP (EAPoIP)
Message Digest Algorithm/Challenge-Handshake Authentication Protocol (EAPMD5-CHAP)
EAP-TLS
RADIUS
Cisco EAP-FAST
Each form of EAP has its own characteristics, but for the purpose of the Security+ exam you will only need to know what it is and its different formats.
EAP can support per-packet authentication and integrity protection, but it is not extended to all types of EAP messages. For example, negative acknowledgment (NACK) and notification messages cannot use per-packet authentication and integrity. Per-packet authentication and integrity protection works for the following (packet is encrypted unless otherwise noted):
TLS and IKE derive session key
TLS ciphersuite negotiations (not encrypted)
IKE ciphersuite negotiations
Kerberos tickets
Success and failure messages that use a derived session key (through WEP)
NOTE EAP was designed to support extended authentication. When implementing EAP, dictionary attacks can be avoided by using non-password-based schemes such as biometrics, certificates, OTP, Smart Cards, and token cards. Using a password-based scheme should require the use of some form of mutual authentication so that the authentication process is protected against dictionary attacks.
TEST DAY TIP It is helpful to write out a table showing the various authentication methods used in 802.11 networks (for example, open authentication, shared-key authentication, and 802.1x authentication) with the various properties each of these authentication methods require. This will help to keep them straight in your mind when taking the test.
Notes from the Field
Vulnerabilities
802.1x is not without its share of vulnerabilities. The WEP uses a stream cipher known as the RC4 encryption algorithm. A stream cipher operates by expanding a short key into a key stream. The sender combines the key stream with the original message (known as the plaintext message) to produce ciphertext. The receiver has a copy of the same key and uses it to generate an identical key stream. The receiver then applies the key to the ciphertext and views the plaintext message.
This mode of operation makes stream ciphers vulnerable to attacks. If an eavesdropper intercepts two ciphertexts encrypted with the same key stream, they can obtain the eXclusive OR (XOR) of the two plaintexts. Knowledge of this XOR can enable statistical attacks to recover the plaintexts.
One such vulnerability was discovered by the Fluhrer, Mantin, and Shamir group. The attack (known as the Fluhrer, Mantin, and Shamir attack) is exploited because of the key scheduling algorithm of RC4. There are certain weak keys that allow for statistical determination of the keys when those keys are used. The Fluhrer, Mantin, and Shamir attack involves guesswork and creativity, because you have to guess the first byte of plaintext data being transmitted. When data is encrypted before transmission, a piece of data called the initialization vector (IV) is added to the secret key. Fluhrer, Mantin, and Shamir discovered that the IV was transmitted in the clear, and they recovered the 128-bit secret key used in a production network.
There are also tools available for download on the Internet, which can be used to exploit the vulnerabilities of WEP. Two of the most common tools are AirSnort and WEPCrack.
Protected Extensible Authentication Protocol (PEAP) is a member of the family of EAP. PEAP uses TLS to create an encrypted channel between the client supplicant and the RADIUS server. PEAP provides additional security for the client-side EAP authentication protocols, such as EAP-MS-CHAPV2, that can operate through the TLS encrypted channel. PEAP is used as an authentication method for 802.11 wireless and wired client computers, but is not supported for VPN or other remote access clients.
Security and ease of deployment make PEAP a popular choice for authentication. The advantages of PEAP are as follows:
Windows 2008, Windows Server 2003, Windows 2000, Windows XP, and Pocket PC 2002 offer support for PEAP (either natively or with a system update), so there is no need for you to install third-party client software.
NPS in Windows 2008 and IAS in Windows 2003 is the Microsoft implementation of the RADIUS Protocol. Windows 2000 Server and Windows Server 2003 support PEAP, so there is no need to install third-party RADIUS software.
PEAP uses a TLS channel to protect the user credentials. Other password-based methods (such as LEAP and EAP-MD5) do not create a TLS-channel and are exposed to offline dictionary attacks on the user credentials.
Using the TLS channel from the client to the authentication server, PEAP offers end-to-end protection, not just over the wireless data link. This is particularly important when a mobile user is using a public network to access a private network. For non-TLS schemes (LEAP and EAP-MD5), the password is exposed to attack on the wireless link and across the public network.
PEAP supports any EAP compatible methods. PEAP is also defined as an extensible authentication method that can embrace new EAP authentication schemes as they become ratified. Microsoft Windows PEAP supports passwords and certificate authentication and allows any EAP-based method provided by partners to be used within PEAP.
Within the TLS channel, PEAP hides the EAP type that is negotiated for mutual client/server authentication. This helps to prevent an attacker from injecting packets between the client and the network AP. Also, because each packet sent in the TLS channel is encrypted, the integrity of the authentication data can be trusted by the PEAP client and server.
PEAP offers strong protection against the deployment of unauthorized wireless APs because the client verifies the RADIUS server’s identity before proceeding ahead with further authentication or connectivity. The wireless AP is unable to decrypt the authentication messages protected by PEAP.
PEAP offers highly secure keys that are used to encrypt the data communications between the clients and wireless AP. New encryption keys are derived for each connection and are shared with authorized wireless APs accepting the connection. Unauthorized wireless APs are not provided with the encryption keys.
PEAP does not require the deployment of certificates to wireless clients. Only the PEAP server (authentication server) needs to be assigned a certificate. The PEAP server certificate can be managed using an internal certification authority (CA) product, or acquired from a certificate management company, such as VeriSign and Thawte.
Password-based schemes rely on strong passwords to help defend against brute-force hacking. With PEAP, although you should still follow best practices for strong passwords and management, users’ credentials are not exposed to the same attack, because their credentials are protected by TLS.
Microsoft offers native support for PEAP so that a user can use the same logon credentials for all network connections and applications. PEAP integrates seamlessly with Microsoft Windows domain policy, Group Policy, and logon scripts. This means that PEAP by default transparently uses the same logon credentials you type when you first log into your network. Alternatively, you can specify that PEAP authentication should use different logon credentials, if you are not concerned about preserving the “single logon” experience for your users. Non-TLS schemes (EAP-FAST and EAP-MD5) do not support single logon, logon scripts, or Group Policy.
Authentication schemes for which there are no standards or publicly available specifications will not receive rigorous peer security review. PEAP is an open standard supported under the security framework of the IEEE 802.1x specification.
PEAP offers security and efficiency when used with roaming wireless devices. Authentication latency is frequently a concern with wireless networks, because users may need to reconnect to a network through a number of AP devices as they roam. As a result, it is valuable to be able to quickly perform re-authentication. PEAP supports this capability through the TLS session resumption facility, and any EAP method running under PEAP can take advantage of it.
PEAP provides support for EAP authentication methods such as EAP-TLS and EAP-MS-CHAPV2 that can perform computer authentication.
The PEAP protocol specifies an option of hiding a user’s name known as identity privacy.
In this chapter, you worked on concepts tested in the Security+ exam relating to general security concepts security domain. According to the latest CompTIA Security+ exam objectives, about 30 percent of exam objectives are from the abovementioned concepts including various methods of authentication. You should be able to identify and differentiate various authentication methods based on the features presented. We started with discussion on remote access policies. Remote access policies define the clients’ access methods, protocols before authentication, and access permissions upon successful authentication.
We reviewed the concepts of authentication factors such as one-factor, two-factor, and multifactor. We also viewed the concept of using third-party authentication tools such as multifactor authentication, which can be provided by the use of a PIN and identification card, token technologies, and the use of biometrics.
Authentication protocols are chosen based on the applications, complexity, and level of security needs. Kerberos provides access through secure encrypted keys and issuance of tickets. CHAP validates the identity of the clients through three-way handshake (challenge, response, success or failure).
RADIUS is the most popular of all the AAA servers, which include RADIUS, TACACS, and TACACS+. Although TACACS offers authentication and authorization, it does not offer any accounting tools. TACACS+ is credited with separating the AAA functions. We learned the differences between RADIUS, TACACS, and TACACS+. TACACS+ uses TCP as its transport instead of UDP.
Mutual authentication is a process where both the requestor and the target entity must fully identify themselves before communication or access is allowed. The IEEE 802.1x methods are also covered by the communications security domain of Security+ exam objectives. We also reviewed Extension Authentication Protocol and Protected EAP. This, in addition to the topics covered by Chapter 7, covers Security+ exam objectives on wireless network technology and concepts.
One-factor authentication is the simplest form of authentication through user-names and passwords.
Two-factor authentication involves token cards and PIN as in the case of bank ATM cards.
Three-factor or multifactor authentication involves additional authentication mechanisms such as biometrics.
SSO is the process of authenticating the user once and allowing access to multiple independent software applications.
Remote access policies define the clients’ access methods, protocols before authentication, and access permissions upon successful authentication.
Biometrics is used with devices that have the ability to authenticate something you already have, such as a fingerprint or retinal image.
RADIUS is an acronym of Remote Access Dial-In User Service.
RADIUS is the most popular of all the authentication, authorization, and accounting (AAA) servers.
RADIUS supports a number of protocols including PPP, PAP, and CHAP.
Kerberos is a multiplatform authentication method that requires tickets (tokens) and a KDC. It exists as a realm in most platforms and is utilized in the domain environment in Windows Active Directory structures.
Directory services are used to store and retrieve information about objects, which are managed by the service.
LDAP services are used to access a wide variety of information that’s stored in a directory.
All popular NOS implement directory services similar to LDAP.
CHAP offers a three-way handshake mechanism (challenge, response, and accept/reject).
CHAP can utilize a shared secret, and uses a one-way hash to protect the secret. CHAP is more secure than PAP, as PAP transmits the password in cleartext.
RADIUS and TACACS use UDP, and TACACS+ uses TCP
Mutual authentication consists of using various methods to verify both parties to the transaction to the other.
802.1x uses EAP for passing messages between the supplicant and the authenticator.
Q: What is the difference between access controls and authentication? They seem to be the same.
A: Access controls set the condition for opening the resource. This could be the time of day, where the connection originates, or any number of conditions. Authentication verifies that the entity requesting the access is verifiable and who the entity is claiming to be.
Q: How do I choose a suitable authentication factor from various authentication factors available?
A: Based on the applications you use and the level of security you want to provide you should choose the authentication factor. One-factor is simple and less secure. It uses passwords only. Two-factor introduces a further level of security by token cards and PIN. Multifactor authentication involves biometrics, voice recognition, or such higher levels of security. Cost implication and ease of roll-out in large scale need to be considered in addition to security concerns while choosing multifactor authentication mechanisms.
Q: What are the devices that can be configured as RADIUS clients?
A: Various network devices including routers, switches, and WAPs can be configured as RADIUS clients.
Q: TACACS or TACACS+? Please advise
A: TACACS+ is a proprietary Cisco protocol. It uses TCP. TACACS uses UDP and does not offer accounting tools. When your network is predominantly Cisco you may consider TACACS+. All aspects of AAA are offered by TACACS+.
Q: What are the factors that influence PEAP deployment?
A: PEAP uses TLS to create an encrypted channel between the client supplicant and the RADIUS server. PEAP provides additional security for the client-side EAP authentication protocols, such as EAP-MS-CHAPV2, that can operate through the TLS encrypted channel. When you need to implement a higher level of security and are looking for a wide range of NOS platforms for deployment you may want to consider PEAP.
1. You are acting as a security consultant for a company wanting to decrease their security risks. As part of your role, they have asked that you develop a security policy that they can publish to their employees. This security policy is intended to explain the new security rules and define what is and is not acceptable from a security standpoint as well as defining the method by which users can gain access to IT resources. What element of AAA is this policy a part of?
A. Authentication
B. Authorization
C. Access control
D. Auditing
2. One of the goals of AAA is to provide CIA. A valid user has entered their ID and password and has been authenticated to access network resources. When they attempt to access a resource on the network, the attempt returns a message stating, “The server you are attempting to access has reached its maximum number of connections.” Which part of CIA is being violated in this situation?
A. Confidentiality
B. Integrity
C. Availability
D. Authentication
3. You are performing a security audit for a company to determine their risk from various attack methods. As part of your audit, you work with one of the company’s employees to see what activities he or she performs during the day that could be at risk. As you work with the employee, you see him or her perform the following activities:
Log in to the corporate network using Kerberos
Access files on a remote system through a Web browser using SSL
Log into a remote UNIX system using SSH
Connect to a POP3 server and retrieve e-mail
Which of these activities is most vulnerable to a sniffing attack?
A. Logging in to the corporate network using Kerberos
B. Accessing files on a remote system through a Web browser using SSL
C. Logging into a remote UNIX system using SSH
D. Connecting to a POP3 server and retrieving e-mail
4. You are reading a security article regarding penetration testing of various authentication methods. One of the methods being described uses a time-stamped ticket as part of its methodology. Which authentication method would match this description?
A. Certificates
B. CHAP
C. Kerberos
D. Tokens
5. You are a security consultant for a large company that wants to make its intranet available to its employees via the Internet. They want to ensure that the site is as secure as possible. To do this, they want to use multifactor authentication. The site uses an ID and password already but they want to add security features that ensure that the site is indeed their site, not a spoofed site, and that the user is an authorized user. Which authentication technology supports this?
A. Certificates
B. CHAP
C. Kerberos
D. Tokens
6. You are developing a password policy for a company. As part of the password policy, you define the required strength of the password. Because of the security requirements for the company, you have required a minimum length of 14 characters, the use of uppercase and lowercase alphabetic characters, the use of numbers, and the use of special characters. What else should you require?
A. No dictionary words allowed in the password
B. No portion of the username allowed in the password
C. No personal identifiers allowed in the password
D. All of the above
7. You have been asked to help a company implement multifactor authentication. They want to make sure that the environment is as secure as possible through the use of biometrics. Based on your knowledge of authentication, you understand that biometrics falls under the “something you are” category. Which other category should be used with the biometric device to provide the highest level of security?
A. Something you know
B. Something you have
C. Something you do
D. All of the above
8. You are attempting to query an object in an LDAP directory using the distinguished name of the object. The object has the following attributes:
cn: 4321
givenName: John
sn: Doe
telephoneNumber: 905 555 1212
employeeID: 4321
mail: jdoe@nonexist.com
objectClass: organizationalPerson
Based on this information, which of the following would be the distinguished name of the object?
A. dc=nonexist, dc=com
B. cn=4321
C. dn: cn=4321, dc=nonexist, dc=com
D. jdoe@nonexist.com
9. You are creating a new LDAP directory, in which you will need to develop a hierarchy of OUs and objects. To perform these tasks, on which of the following servers will you create the directory structure?
A. DIT
B. Tree server
C. Root server
D. Branch server
10. When you are using LDAP for authentication in an internetworking environment, what is the best way to ensure that the authentication data is secure from packet sniffing?
A. Use LDAP to keep all passwords encrypted when transmitted to the server
B. Use LDAP over SSL/TLS to encrypt the authentication data
C. Require that the clients use strong passwords so that they cannot easily be guessed
D. Use LDAP over HTTP/S to encrypt the authentication data
11. Which password attack will take the longest to crack a password?
A. Password guessing
B. Brute force attack
C. Dictionary attack
D. All attacks are equally fast
12. The company you are working for has decided to do something to make their workstations more secure. They have decided to give all users a Smart Card for use with system logins. Which factor of authentication is utilized with this new requirement?
A. Something you know
B. Something you have
C. Something you are
D. Something you do
13. Choose the correct set of terms: When a wireless user, also known as the ___________ wants to access a wireless network, 802.1x forces them to authenticate to a centralized authority called the ____________.
A. Authenticator; supplicant
B. Supplicant; authenticator
C. Supplicant; negotiator
D. Contact; authenticator
14. One of the biggest differences between TACACS and TACACS+ is that TACACS uses _________ as its transport protocol and TACACS+ uses _________ as its transport protocol.
A. TCP; UDP
B. UDP; TCP
C. IP; TCP
D. IP; UDP
15. EAP is available in various forms including:
A. EAPoIP, EAP-TLS, EAP-TTLS, RADIUS, Cisco LEAPEAP-FAST
B. EAPoIP, EAP-TLS, EAP-MPLS, RADIUS, EAP-FAST
C. EAPoIP, EAP-TLS, EAP-TTLS, RADIUS, Cisco PEAP
D. EAPoIP, EAP-TLS, EAP-TTLS, Kerberos, EAP-FAST
1. C
2. C
3. D
4. C
5. A
6. D
7. D
8. C
9. C
10. B
11. B
12. B
13. B
14. B
15. A
