Identity Technology Guidelines

Beginning with AAA deployment guidelines, this section outlines best practices for some common identity deployments. In addition to AAA deployment guidelines, this section covers 802.1x/EAP infrastructure, gateway network authentication, and basic PKI guidelines.

AAA Server Design Guidelines

In very small networks, a AAA server is probably not necessary. Local users can be configured on each device and synchronized as necessary. For a moderately sized network, particularly one with disparate access methods, a AAA server is a requirement. Numerous AAA servers are on the market, with most running RADIUS and some offering TACACS+ as well. There are many decisions a designer must make when deploying AAA. These are discussed in the following sections.

Basic AAA Requirements

The first step in designing your AAA solution is determining which network access servers (NASs) will utilize this service. This should include not only your network infrastructure devices but also applications and network file services. Although almost any device that has user authentication can be made to query a AAA system, the following are the most common clients:

Although it is theoretically possible to run your entire organization through a single large AAA deployment, in practice very few organizations do this. If an organization has very basic identity requirements it might be possible, but generally such organizations choose not to deploy a dedicated AAA server at all. As the identity requirements increase, the complexity of the AAA deployment increases as well. Each new application or NAS adds another wrinkle to the integration requirements for the AAA solution.

Root Server Versus Middleware

For larger AAA deployments, you first must determine where the AAA server sits in the identity hierarchy. There are three options: root server, middleware server, or a mixed deployment. These are discussed in the following sections.

Root Server

In this deployment, the AAA server is the master repository for all user identity credentials (hence, the name root server). All systems in need of AAA services act as clients to the AAA system. This concept is shown in Figure 9-1.

Figure 9-1. Root AAA Topology

As mentioned previously, the resulting complexity of having each and every system access a single AAA sever is prohibitive; such a design is unrealistic because of the differing needs and capabilities of the various entities accessing the AAA system. It is a deployment option in theory rather than practice. Future identity approaches can make this simpler by offering tighter integration and automation of the entityAAA server conversation, but it is not likely to happen in the short term.

NOTE

This root server deployment option for any kind of identity system is necessary for single sign-on (SSO) to deliver on the goals its name implies. After centralizing your AAA infrastructure, you would then require a method of caching the authentication information such that authentication at, say, the LAN level can be passed to an application. This, among other challenges, requires that the SSO system somehow know when a user leaves the keyboard. SSO, despite the very real benefit to the user in terms of convenience, is not a realistic goal in today's networks and, as such, is not covered in this book.

 

Middleware Server

This second approach starts with the base assumption that the core identity information is stored somewhere other than on the AAA server. AAA clients access this identity store directly when applicable and interface through the AAA server when some interpretation or action on this data is necessary. For example, if the user repository is in the NOS (which is fairly common), clients can access the data directly over the protocols native to the NOS, and the same repository can be used by dial-up users when translating through the AAA server. This topology is shown in Figure 9-2.

Figure 9-2. Middleware AAA Topology

This option is more likely than the root AAA server but is still hard to implement because of integration issues between the applications, AAA server, and user repository. Both the middleware deployment and the root server deployment appear identical to the user because, in both cases, there is a single user store.

Mixed Deployment

The most likely option given today's AAA technology constraints is a mixed deployment. Some services house their own user repositories, others are able to leverage the root user-repository directly, and still others interface through a AAA system. In this deployment, there can be more than one AAA system, depending on the various applications.

For example, you might use one AAA system for TACACS+ administrative access and another for user network access. Figure 9-3 shows this topology.

Figure 9-3. Mixed AAA Deployment

In this topology, you can see several differences from the middleware design. First, there is a dedicated AAA system for administrators. Second, some applications have their own user repositories and do not interface directly with the root user-repository.

The main design problem results from the fact that users and administrators must deal with identity data stored on a number of different systems. For example, when users wish to change their passwords, several different systems must be accessed. Deploying an identity synchronization application can help and is listed as optional in the upper-left corner of Figure 9-3. These applications can be either purchased commercially or developed in-house.

Identity synchronization applications are designed to automate the propagation or modification of usernames, passwords, and other attributes on disparate systems. Think of this as the workaround for the lack of integration some applications have with your core identity infrastructure. These applications could, for example, extract the employee names out of an HR database and propagate them into a calendaring application. Default passwords could then be generated for users. Helping users change their passwords is another feature of such a system. By going to a web interface, users could identify the systems on which they want to change their password, and this could be executed automatically on behalf of the user.

WARNING

The security implications of an identity sync application are significant. Because this system needs hooks into any system it synchronizes with, it likely has privileged access to several user repositories. Make sure you consider the security requirements of such a system very carefully before deploying it. Such a system should be carefully hardened, protected by an IDS, provide access control, and be diligently maintained and monitored.

 

Remote User-Store Access

In the previous section, you learned that most larger AAA systems access user databases external to the AAA server. There are two main mechanisms to do this: direct query and database synchronization.

Direct Query

In the direct query model, AAA requests received by the AAA server are sent directly to the external user-repository for the identity check. The external repository responds, and the AAA server acts on that received data. In this form, external stores can be NOS user repositories such as Microsoft Windows NT or external databases. These user repositories can be accessed either by the AAA system directly or through generic open database connectivity (ODBC) calls or Lightweight Directory Access Protocol (LDAP).

The types of user repositories supported by your AAA server vary from vendor to vendor. The level of integration required to access these remote databases also varies. It isn't uncommon for a AAA system to require someone with database administrator (DBA) skills to manage the connectivity.

Some considerations when using direct query are as follows:

Database Synchronization

In this method, an ODBC relational database pushes its user repository to the AAA server on a regular basis. This option requires more work on the front end but eliminates some of the concerns with the direct query method while adding a few of its own. The main benefit is that the user data is local to the AAA system, and the AAA clients can access the full range of AAA controls as opposed to being limited to what the upstream user repository can support. Also, since synchronization can occur at administrator-defined times, much of the delay issues can be eliminated because the AAA system need not access any other device at the time of authentication.

Some considerations when using database synchronization are as follows:

AAA Server Scalability

Each AAA vendor has different guidelines and builds in different capabilities for how many NASs and users can be configured on a single AAA server. Your specific deployment will deviate from those guidelines based on the AAA features you use, your own network topology, and any interfaces with external systems (user repository or OTP). The Cisco AAA offering is called the Cisco Secure Access Control Server (ACS). If this is the AAA vendor you have elected to use, the following two documents will be of interest:

AAA Server Network Resiliency Considerations

Even if your user count and NAS count don't justify more than one AAA server, you might need more than one for network topology reasons. Consider the topology in Figure 9-4.

Figure 9-4. Multisite Network

Here you can see a large central office with a smaller regional office and two satellite sales offices. The central office and the regional office operate dial-up and WLAN services, and the sales offices have local WLAN access (using AAA for key distribution as discussed in Chapter 11). As shown, there is only one AAA server located at the headquarters.

Assuming the authentication delay is acceptable, this solution will work fine so long as the WAN links are functional. If these links were to go down, however, WLAN and dial-up would stop functioning everywhere but at headquarters. This can be a problem. For example, if the sales offices lose WLAN access, does this stop them from getting on the network? It doesn't if WLAN is used as a secondary access method (common in many organizations). The core question to ask is: are business functions affected enough to warrant a technical solution to this problem? This decision must be based on the business needs as outlined in Chapter 2, "Security Policy and Operations Life Cycle." If it is determined to be a problem, it can be solved in one of two ways; however, most organizations do some combination of both.

Distributed AAA Server Synchronization Considerations

Vendors differ in their approach to AAA server synchronization. Some offer a peer-to-peer system, while others operate a master-slave relationship similar to DNS. In either case, the replication of the data on multiple AAA servers is critical. The three factors that impact this replication are as follows:

Distributed WAN Considerations

Your network might include international WAN links. If this is the case, you likely have one or two main connections between, for example, the United States and Europe and several WAN connections within these locations to interconnect sites. Assuming the master AAA server is in the United States, the recommended synchronization method for Europe would be to first synchronize from the United States to a primary location in Europe and then from that European server to all other local servers. This allows for a more efficient use of WAN bandwidthjust make sure that the two main servers are highly available to one another. This is shown in Figure 9-5.

Figure 9-5. Global AAA Deployment

 

AAA Server Requirements

Many vendors offer AAA solutions to the market. In addition to all the standard vendor selection criteria you might use, the following considerations will help you select the AAA vendor that is right for you:

AAA Server Summary

AAA servers offer a great method of simplifying user and administrator access to network resources. Even with all the administrative headaches AAA can have, these headaches usually pale in comparison to not having a AAA deployment at all.

Maintaining local user repositories on every network resource is no fun, nor is doing the same for administrative users. When I was doing IT for a company several jobs ago, I deployed the identity infrastructure for the organization. This consisted mainly of an X.500-based Novell Directory Services (NDS) tree and several identity silos for individual applications. As the administrator, I had root access to most of these systems. Because we didn't have a centralized identity system, when I finally left the company after 5 years, the remaining IT staff had a lot of work to do to remove all my access rights. I'll never forget what one of my coworkers told me: "You just went from valued employee to prime security risk." I've often wondered if they got rid of my passwords from every system or if they forgot a few. I've heard stories of ex-employees connecting to old jobs after years gone by and still having some kind of access. By using AAA, you can delete an administrator from one place, and most of that user's access will be gone immediately.

 

802.1x/EAP Identity Design Guidelines

In most networks, if you connect to an Ethernet port on a switch, by connecting to that port you are on the network. DHCP hands you an address and you are off and running. This is great from a convenience and mobility standpoint, but it might not be desirable in a security-sensitive network. 802.1x is an IEEE standard approved in 2001 that defines a method for port-based network access control. You can download the standard at the following URL:http://standards.ieee.org/getieee802/. Using 802.1x in the previous example allows each station to be authenticated before accessing the Ethernet switch or WLAN. (WLANs are covered in Chapter 11.) Because it is an L2 protocol, it is not dependent on IP in any way. When the PC powers down or the link is disconnected, the port can be placed back in unauthenticated state with no access.

802.1x/EAP Protocol Details

The protocol works in conjunction with a proposed standard defined in RFC 2284, "PPP Extensible Authentication Protocol (EAP)." EAP provides a framework for multiple authentication types to occur using the same message format. The three main components in an 802.1x exchange are as follows:

In 2003, supplicant client software became available for most versions of the Microsoft Windows operating system, UNIX, and Macintosh OS X. The open source implementation of 802.1x (used for UNIX and Macintosh) can be downloaded at http://www.open1x.org.

One of the interesting characteristics of EAP is that only the supplicant and the authentication server need to know the details of the EAP authentication method. The authenticator is able to package the EAP message in a format it understands (RADIUS, for example) and send it off to the authentication server. A reply will come back informing the authenticator whether to grant access to the supplicant. These EAP messages can take a number of different forms, such as the following:

In the future, additional authentication mechanisms can be defined without modifying the underlying EAP or 802.1x protocols. Figure 9-6 shows an 802.1x deployment for a wired LAN using EAP-MD5 for authentication. EAP-MD5 is not particularly secure, but it is shown here because it is the simplest of the EAP types.

Figure 9-6. 802.1x/EAP-MD5 Connection Establishment

NOTE

IEEE 802.1x is not the end of the IEEE's work in this space: having recognized some issues with the current standard, the IEEE is modifying 802.1x in the 802.1aa subgroup. Some of the vulnerabilities in 802.1x can be found in a University of Maryland research paper titled "An Initial Security Analysis of the IEEE 802.1x Standard." It can be found at http://www.cs.umd.edu/~waa/1x.pdf.

NOTE

EAP was originally written to be used with Point-to-Point Protocol (PPP) and is now being used for port authentication as defined in 802.1x. Several weaknesses have been discovered with EAP as currently deployed. A new protocol, Protected EAP (PEAP), is being run through the IETF process. PEAP addresses many of the concerns with EAP, including user identity protections and key exchange standards. Basically, you can think of PEAP as EAP tunneled inside Transport Layer Security (TLS). PEAP and the enhancements in 802.1aa should dramatically improve the security of 802.1x.

 

802.1x/EAP Case Study

To better understand how 802.1x/EAP works, this section outlines the basic configuration necessary to authenticate LAN users with EAP before granting them network access. The EAP type you use is only of interest to the supplicant and the authentication server, so the authenticator configuration should not change. The topology shown in Figure 9-6 is used.

Supplicant Configuration (Client)

Supplicant configuration for 802.1x is fairly straightforward. You only need software for the supplicant that understands 802.1x and the desired EAP type. For most EAP types, no special configuration is required once the software is installed. Just enable it and the client PC will use it when connected to a network requiring 802.1x authentication. Some EAP types require additional security configuration. EAP-TLS, for example, requires certificates on each supplicant.

Authenticator Configuration (Switch)

Configuration for the authenticator is a matter of enabling the 802.1x functionality for the desired ports and defining the communications channel to the authentication server. The following configuration shows a Cisco IOS configuration for the Ethernet switch connecting to a RADIUS AAA server as the authentication server:

!Enable AAA switch-IOS(config)#aaa new-model !Set RADIUS as the authentication server for dot1x switch-IOS(config)#aaa authentication dot1x default group radius !Define the radius server parameters (use more than one for critical networks) switch-IOS(config)#radius-server host authentication-svr-ip auth-port 1812 acct-port 1813 key key !Specify dot1x to re-authenticate the host at regular intervals, the ! interval is configurable switch-IOS(config)#dot1x re-authentication !Enable dot1x for ports 0/1 0/24 switch-IOS(config)#interface range FastEthernet0/1 24 switch-IOS(config-if-range)#dot1x port-control auto

NOTE

There are several more options with 802.1x configuration on switches. For a more detailed discussion of the various deployment options, refer to the following site, which discusses the Cisco Catalyst 3550 802.1x options: http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12112cea/3550scg/sw8021x.htm. Similar guides are available for other switch models.

 

Authentication Server Configuration (AAA Server)

Configuration on the authentication server is straightforward. Users who will be allowed to authenticate using 802.1x must be defined, and the systems they are permitted to authenticate to should be identified. The procedures for these steps will vary based on your choice of AAA server and EAP type. Ideally, you should use the same AAA user-repository for 802.1x as you would use for VPN, dial-up, or other network access methods.

802.1x/EAP Design Considerations

Now that you have a basic understanding of 802.1x/EAP, this section will highlight some design considerations for the technology. One of the first questions you should ask is: should I deploy 802.1x on my LAN?

First, see the following caution regarding 802.1x/EAP stability. Before any other decision to deploy 802.1x is made, you should evaluate this issue.

x EAP in Early 2003

While testing 802.1x/EAP in the lab for this book, I found that the technology is not mature enough for me to endorse for large-scale deployment (as of this writing in 2003). I fully expect the technology to mature over the next 18 months, particularly with the release of 802.1aa and PEAP. Depending on when you read this, some of these issues might have already been addressed.

During my testing, I found a lack of integration between the 802.1x client and the DHCP client in Microsoft Windows 2000, for example. By the time authentication by 802.1x occurred, the PC had already timed out its DHCP request and opted instead for a link local address (169.254.0.0/16). Though the user could manually go in and restart the DHCP process, for most users this will be infuriating.

If you combine this with the vulnerabilities of EAP and 802.1x identified in the University of Maryland paper, this should raise a yellow flag in your mind.

While testing 802.1x, I was reminded of the issues with IPsec around 1999. The technology was very promising but needed a bit of work before people would deploy it in production environments.

I also would imagine, like IPsec, the technology will first work well in mostly single-vendor deployments for the supplicant and authentication server (for example, Microsoft clients talking to a Microsoft authentication server or Cisco WLAN clients talking to a Cisco AAA server).

The rest of this section assumes that any issues with 802.1x have been sufficiently mitigated to warrant serious consideration of the technology. This includes not just stability but also adequately addressing any security concerns.

802.1x/EAP Benefits

It is important to consider the security benefits your network receives through 802.1x/EAP deployment, such as the following:

If we think back to the threats defined in Chapter 3, "Secure Networking Threats," 802.1x primarily provides protection against direct access. Several other attacks are also indirectly stopped because the attacker can't get on the network in the first place. Sniffing, for example, can be stopped for individuals without appropriate credentials to access the LAN.

802.1x/EAP Concerns

Besides the protocol deficiencies that are being addressed through the standards process, one concept is important to understand with 802.1x: 802.1x applies access rights at the user level but enforces them at the MAC level. This means that after a user authenticates, it is the user's MAC address, not the user credentials, that is validated when the host communicates through a particular LAN switch port. 802.1x is providing initial authentication, but once complete, the end result is really like a MAC access list inbound on the LAN switch port. That ACL says if you are coming from the source MAC of the station that authenticated, you are allowed in.

This means an attacker could get access to the network by spoofing the MAC address of the host that has completed authentication. This could be done by inserting a hub or switch in between the authenticated host and the Ethernet switch. The attacker could then sniff all packets from the device or send out packets as though they came from the device. (Sniffing could be done even without MAC spoofing.) As discussed in Chapter 11, this is even easier on a WLAN by spoofing disassociate messages from the access point (AP).

NOTE

It is worth noting that if an attacker is able to insert a hub between an authenticated host and the LAN switch, the attacker can also do many other things with this physical access, not the least of which is installing keystroke loggers, as discussed in Chapter 6.

There are two other concerns with 802.1x. First, by deploying 802.1x, you are adding another password for the user to enter at logon. In some cases, this logon can be tied to the network logon (for example, with homogeneous Windows deployments). Second, if your authentication infrastructure is taken out of service, users on your local network will be unable to get basic connectivity. This means your authentication servers must be considered critical network assets requiring round-the-clock availability. This might already be the case if you have other critical systems using AAA, such as VPN remote access or WLANs.

802.1x Deployment Models

This section highlights two potential deployment models for 802.1x/EAP. The primary variable for each design is the security of the location in which Ethernet connections are provided to users.

Shared Access

Places where you cannot ensure the security of the Ethernet ports should be the prime reason for deploying 802.1x. A lobby at your organization could use 802.1x to allow legitimate users access to the organization's network, while unauthorized users are given no access or are put on a VLAN that provides basic Internet access only. This design is shown in Figure 9-7. Until such issues as MAC spoofing attacks are addressed in the standard, you still must require crypto of some kind before allowing users to connect internally.

Figure 9-7. 802.1x/EAP Shared Access Deployment

 

Mobile Access Rights

In environments where you have reasonable assurances that the physical LAN ports are in secure locations, 802.1x might still be appropriate. By using the capability to assign VLAN based on 802.1x authentication, you can enable mobile rights at the network level. By ensuring that each user is always on his own group's VLAN, you can more easily make network access control decisions such as per-group ACLs. Additionally, as discussed in the previous section, user trace back is another beneficial result of this kind of deployment. However, don't rely on 802.1x in this deployment to provide protection against outside attackers. If an attacker is willing to go through the risk of gaining unauthorized access to your facility, 802.1x isn't going to stop further exploits from inside.

802.1x/EAP Summary

Although the two previous deployment models provide clear benefits, each in their specific network environment, broad 802.1x deployment should not be pursued by every network. This is because the pain involved for the IT staff is often not justified by the security benefit 802.1x affords. Since 802.1x requires client-side software, you must deal with constant requests for exceptions in 802.1x access. Network printers, video-conferencing gear, and other non-PC network equipment will likely not support 802.1x in the near future. In addition, you are requiring an additional login for the user and a fairly robust authentication server deployment to deal with all the authentication requests. If your authentication infrastructure goes down, so does the bulk of your network.

If you examine all of these downsides, the benefit that 802.1x provides to wired LANs might not be significant enough. Many other best practices often not deployed in networks can provide greater security benefit than 802.1x. Remember, 802.1x provides a dynamic ACL permitting a specific MAC address into the network. There is no per-packet encryption, integrity, or authentication.

NOTE

In the future, I think you will see 802.1x used as a foundation technology to enable many other security services. If 802.1x were deployed with strong authentication (such as what PEAP might provide) and combined with per-packet authentication, encryption, and integrity for each subsequent frame, an organization could fairly easily deploy a campus crypto solution that could thwart many attacks at L2 and higher layers. As discussed in Chapter 11, 802.1x/EAP is being used as a basis for just this sort of capability with WLANs.

 

Gateway-Based Network Authentication

Gateway-based network authentication refers to the ability of a network device to dynamically authenticate an IP or MAC address to the network and then apply access rights. If you've ever used broadband connectivity in an airport or a hotel, you have probably used this kind of service. In a hotel, for example, the gateway device intercepts incoming web requests and redirects the user to a page offering various connection plans. After the user decides on a plan (say, unlimited access for 24 hours), the gateway device adds the user's address to the table of authorized addresses and grants access.

In an enterprise network, this kind of authentication is on the decline. The most commonly used example of this kind of authentication is proxy servers, as discussed in Chapter 7, "Network Security Platform Options and Best Deployment Practices." In the past, Cisco IOS features such as "lock-and-key" ACLs were used to dynamically open connections to a more secure location of the network for a specific user. Although still used today in specific situations, technologies including lock and key are being replaced by VPNs, as discussed in Chapter 10. Among other things, VPNs provide encryption that makes their use much more secure than basic gateway authentication.

One possible deployment of gateway authentication is to provide differentiated Internet access rights. Although most enable this function on a proxy server, providing gateway authentication on your firewall can provide a low-cost alternative if the number of users requiring special rights is small. These users establish a Telnet or HTTP connection to the firewall, and after entering their user credentials, additional rights are granted to their IP address.

PKI Usage Basics

PKI is a difficult technology, as you learned in Chapter 4. Closed PKIs within your organization have the greatest chance of success. Though PKI/CA deployment information is outside the scope of this book, this section highlights some of the main locations where PKI is used. These uses must be considered as part of your overall security design strategy. You might require PKI in three main areas:

Related

Категории