Basic Foundation Identity Concepts

Almost all network-connected applications support some basic form of identity. Most often this takes the form of a username and a password. By proactively checking for bad passwords, educating users about choosing good passwords, and giving preference to applications with some form of secure transport (for example, Secure Shell [SSH]), you can achieve reasonable security for most systems. This chapter discusses more advanced identity systems that usually benefit very specific applications or policy requirements. For example, using one-time passwords (OTP) instead of reusable passwords in a Telnet application provides a strong benefit because passwords are sent in the clear. These advanced identity options should not be used everywhere for two main reasons.

First, the security benefit of these technologies over usernames and passwords is real but often does not eclipse the security benefit of other nonidentity security technologies with lower costs. For example, although no one will argue that public key authentication can be more secure than a username and password, the benefit isn't as pronounced as the move from a network filled with default operating system (OS) installs and one with all patched devices. This isn't to say that you can't do both, but often security resources are limited and trade-offs must be made.

This is compounded by the second concern with advanced identity technologies. That is, to get the marginal security benefit stronger authentication offers, you often need additional technologies to deal with the problems that the stronger authentication creates. For example, public key cryptography allows two devices to strongly authenticate one another. However, with 1000 users and dozens of servers, you need some way to manage the keysenter a certificate authority (CA). The CA now becomes another security resource in your network with its own security issues, deployment considerations, and management challenges.

As discussed in Chapter 4, OTP does the best job of providing the security benefit without creating a huge management problem. The rest of this section discusses some foundation concepts in identity that will help you make design decisions in your own network.

NOTE

When comparing identity technologies, it is important to understand what you are comparing. For example, the previous few paragraphs don't hold that much weight if you are defining an identity system for an application such as Telnet. Because Telnet sends usernames and passwords in the clear, a technology such as OTP provides a more significant benefit over basic usernames and passwords. In this case, however, you are using identity controls to augment poor security on the application.

 

Device Versus User Identity

Central to any design discussion on identity is an understanding of the differences between device and user identity. Device identity is the identity of a network entity. The Media Access Control (MAC) address on an Ethernet card is a form of device identity, albeit a weak one, for the host in which it is installed. Device identity controls can assert the validity of a given device but generally not the individual who is accessing it. That is left to the realm of user identity. User identity is often divorced from device identity but not always. A simple username and password is a form of user identity. Throughout this chapter, you will learn how different identity capabilities can be used to validate these two identity models. Oftentimes, a network security control will call for one or the other or perhaps both.

Network Versus Application Identity

Either of the preceding types of identity information (device or user) can be applied toward one of two ends: network identity or application identity. Network identity refers to the capability of the network to validate a device or user identity. IEEE 802.1x/Extensible Authentication Protocol (EAP), as discussed later, is a method for determining network identity through the validation of user identity credentials. IP address is a form of network identity that identifies a particular device. Application identity is a given application validating a device or user identity. Application identity is often a separate function from network identity. Likewise, one application's identity functions are often separate from another's. This lack of integration and information sharing is one of the reasons identity is a hard problem to solve in secure networking.

Whom Do You Trust?

The integration problem mentioned in the previous section is compounded by the issue of intraorganization and interorganization trust. As discussed in the Public Key Infrastructure (PKI) section of Chapter 4, the global Internet community is not likely to trust a single identity provider to the degree necessary to execute critical transactions without some form of additional authentication. Similarly, internal organizations often have the same inability to fully trust a single source. For example, network identity has its own user repository, application identity has another, and both are usually managed by different groups.

NOTE

The Domain Name System (DNS) is an interesting example of a cooperative public system of identity checking and validation. If all 13 root name servers decided to dupe the world at the same time, serious harm could be done. Likewise, if the .com root operator wanted to change the owner of Amazon.com to another party with some malicious end in mind, it could. So, to a certain extent, the global Internet community trusts the DNS providers enough that we all use DNS as opposed to each having our own /etc/hosts file.

However, this trust has limits. Without any form of additional authentication, many potential customers would not purchase from an online retailer. Today, once you get to Amazon.com, you can use its Secure Sockets Layer (SSL) certificate to validate whether you are at the right site. Even with a maliciously configured DNS server, the customer can spot the problem when the certificate validation fails on the rogue site. This unfortunately says nothing regarding the user's desire or willingness to have the purchase experience interrupted by the certificate failure. Many users will still click the "continue anyway" button when notification of the failure is presented.

To a certain extent, this limited trust model is the foundation of organizations' internal networks as well. Simply being on an organization's network affords users privileges not provided to users connecting over the public Internet.

The key goal of any identity strategy within an organization is to reduce the number of locations in which identity information is stored and the number of times users are queried for their identity informationall while ensuring that the security of the network and the identity controls remain high. This requires cooperation between application, physical, and network security operations. This identity strategy must be defined alongside and integrated with your security policies.

Identity and Authentication, Authorization, and Accounting

Identity is a primary technology when implementing authentication, authorization, and accounting (AAA). AAA is an important concept in network security. Authentication is who you are, authorization is what you are allowed to do, and accounting is a record of what you did. Linking them in the moniker AAA often implies that the three are inseparable and that they are provided only through a dedicated AAA server. In fact, just the opposite is true. Within today's modern network, AAA is potentially enforced throughout a system in many different locations. Consider the following chain of events:

• User boots portable computer Authentication can first occur with a basic input/output system (BIOS) boot password. Authorization is not a discrete event because no differentiated user access is possible at the BIOS boot level. If you provide the BIOS password, the system will initialize. After the OS boots, modern OSs again prompt the user for authentication information. Authorization occurs here as well. A user with only a guest login is able to do far less on a system than a user who has the root password. These access rights can be manipulated within the operating system. Here, accounting also occurs: a modern OS logs when a given user accesses the system and often makes additional accounting entries when that user attempts to do critical operations on the system.
• User establishes VPN connection to corporate office Here the user authenticates again to the VPN gateway. Based on the user's group membership, the VPN gateway can authorize some network activities and block others. In some cases, this is accomplished by still another device at a firewall. Accounting occurs here again.
• User downloads e-mail This is another point of user AAA as the user logs in, is granted certain file permissions based on user ID, and has access logged by the mail server. When sending mail, the user's IP address most likely is used as a form of identity before the mail server accepts the mail message.
• User moves a project file to a network-based storage device Again, there is user AAA, this time at the file server.
• User browses the Internet Assuming there are no proxy servers, AAA occurs exclusively at the IP layer, with access to the Internet controlled by access control lists (ACLs) and activity logged by the firewall.

In this simple example, six different forms of authentication occurred. A key element in designing your identity systems is to look for places where you can make these systems work together rather than just working randomly without coordination. It is possible to link some of these six events into a single shared identity system. For example, a central user repository could ensure that mail and file server access uses the same credentials. Others, such as the local PC authentication, have no integration capability. Still others could be merged, but you wouldn't necessarily want to. For example, VPN authentication could use the same identity credentials as e-mail and file server access, but you wouldn't necessarily want to implement this because the security reliance on identity in the VPN is greater than for local server access. In a VPN, identity is responsible for authenticating any IP address anywhere in the world and associating it with a valid user of the organization's network. For access to local file servers, you already know that the user has access to the local network, affording the "limited trust" discussed earlier.

Shared Identity

Oftentimes, identity information is shared among multiple users. Any time this happens, the strength of the identity mechanism is weakened. This is particularly true in network management where administrative passwords must be shared among multiple users. In this case, without taking additional measures, it is hard to determine which user executed a certain function by using the administrative account.

Although this uniqueness is beneficial to the authentication event, it is detrimental to authorization. Within your organization, you likely have several different roles and responsibilities for your users. These roles can be anything from guest user to administrator. By organizing these roles into groups, you can assign authorization rights to those groups. User rights can then be inherited based on the groups they are a member of. In this way, the authentication event can be unique (and thus can provide unique accounting), while the authorization rights can be shared among members of the group.

There are always exceptions to this rule when you must grant certain rights to an individual rather than a group, but these can be kept to a minimum. For example, for file system identity, there are always some user-specific rights granted in the case of home directories.

Cryptographic Identity Considerations

The decision to deploy a cryptographic identity mechanism rather than a cleartext mechanism should be based on a number of factors:

• Do you need encryption? If the application or device must encrypt data (because you are using an insecure transport or for any other reason), you must use a cryptographic mechanism to exchange identity. Internet Key Exchange (IKE) for Internet Protocol Security (IPsec) is a good example. You don't want to exchange encryption keys for data transmission over a link authenticated with a password sent in the clear.
• Is session hijacking likely for this communication? If so, a cryptographic identity mechanism is necessary. Such a mechanism includes integrity checking on the transmission such that a modification made to the data in transit will be seen and rejected by the receiver. Integrity checking doesn't necessarily mean the data is encrypted, although that is often the case.
• Do you have a method to manage the keys? If you answered yes to either of the previous questions, how do you plan to manage the crypto keys? Even for protocols such as SSH that can use client-side usernames and passwords, the client machine still requires assurance that the key provided by the server is authentic. SSH version 2 provides an optional certificate infrastructure to do this, and other protocols have their own techniques. Key management is a less significant issue in smaller organizations but can quickly become impossible without prior planning as the organization grows.

WARNING

Don't assume that every communications medium with an encryption option solves key management. As you will learn in Chapter 11, Wired Equivalent Privacy (WEP) for WLANs is not deployable because it has been proven breakable. Even if it were secure, WEP requires the static configuration of shared keys on each client. This means that if one user's laptop is stolen, all the keys must be changed.