Designing for Security

Up to this point we've covered the basics of security threats, the tools you have in the directory world to combat them, and the effects that your environment and other directory design decisions have on your security design. By now, you should have a good idea of your overall security needs. For example, you should know the level of authentication required, whether you need access control, and whether you need to protect the privacy of client/server or server/server connections. You also should have thought about the relative consequences of various kinds of security breaches.

In short, you should have a good idea what your security policy should be. Now it's time to turn our attention to some more concrete steps you can take to implement your policy.

Authentication

LDAP provides several choices for authentication, which are explained in the following list. Your task is not only to choose the method or methods best suited for your directory, but also to make sure that other unsuitable authentication methods are not used. Recall that authentication is useful only in the context of access control. First you authenticate a client, and then, on the basis of the identity established, you interpret access control information to grant or deny access to certain resources.

Here are the choices for authentication in an LDAP environment:

• Anonymous authentication . This term may seem like a bit of an oxymoron. After all, authentication is all about establishing identity, and anonymous means no identity. In some circumstances, however, you may want to make data available to any user of the directory, authenticated or not. Users who do not authenticate, or users who authenticate without providing any credentials, are called anonymous users . Such users are treated by the LDAP server as if they did not authenticate at all and are given corresponding privileges. You can set access control on information in your directory, permitting it to be read by anonymous users.

• Simple passwords . With this option a client authenticates to an LDAP server by sending the server a simple, reusable password. No effort is made to protect the password while in transit. This choice might be appropriate for low-security environments in which the set of users is restricted and relatively trusted (for example, behind a firewall). It may also be appropriate for certain secure networking environments in which eavesdropping is not a concern or in which the information being protected is of little value.

  The advantage of passwords is their simplicity, of course. Most people know and understand passwords, how to use them, and the administrative costs associated with them. Password security is also simple to implement, so there are few, if any, performance implications inherent in choosing a password-based solution.

• Digest MD5 authentication via SASL . With this option a client authenticates to an LDAP server without sending the password over the network in the clear. Instead, the server constructs a challenge that is sent to the client. The client must respond to this challenge in a way that proves the client knows the password. Even if an attacker is able to observe the authentication exchange, the information learned is of no use. Digest MD5 authentication offers the ease of simple passwords while preventing theft of credentials or replay attacks.

• Simple passwords over SSL . With this option, SSL (or TLS) is used to encrypt the connection over which a simple password is transmitted. The simplicity and convenience of passwords can be preserved, but the added security of SSL means that this option can be used in relatively high-security environments in which networks are open to eavesdropping attacks and the information protected is of relatively high value.

  There are several downsides to this choice. SSL is more complex than a password-based solution. You must obtain certificates for your servers (but not for your clients) and renew them when necessary. Both clients and servers have to include SSL implementations , which involve a substantial amount of code, increasing the cost and size of software. Not all clients and servers support SSL, which means that choosing this solution restricts your choice of software. SSL may not be much of a problem on the server side; after all, you are in charge of this choice, and if you can live with it there should be no problem. The corresponding client choice may be more problematic because users may want to use a variety of clients that do not support SSL to access your service. Think about whether supporting such clients is important for your directory. Also think about the kinds of operations for which you want to require SSL.

  One more important consideration is the impact your choice will have on the performance of your system. Using SSL to authenticate a directory session consumes a substantial amount of extra computing power; encryption also requires extra cycles. Whereas the client side of this burden is distributed across the many client machines on your network, the server side is more centralized and therefore more of a concern. At the time of this writing, an LDAPv3 extension named StartTLS is nearing completion that will allow encryption and other TLS features to be turned on and off during a session. This feature will allow your password to be protected during authentication before an update operation without degrading the performance of the rest of the system. It is likely that not all servers and clients will support this extension, however, so check with your vendor.

  Be sure to perform benchmarks during the piloting phase of your service to ensure that performance is not degraded too much. If it is, consider adding hardware acceleration to the server. A cryptographic hardware accelerator is usually a special board or other device you can add to your computer. It has processing hardware that performs cryptographic operations much faster than your computer's general-purpose processor can. Keep in mind that not all LDAP servers support hardware acceleration (Netscape Directory Server 6 is one that does support it).

• Certificate authentication over SSL . With this option you are using the full power of SSL. This power allows you to do three things:

  1. Protect the privacy of data

  2. Ensure the integrity of data

  3. Authenticate clients

  Government Restrictions on Encryption Technology

  A separate but important consideration is the effect, if any, that U.S. or other national laws may place on the strength of your security solution. The U.S. government considers encryption technology to be like a weapon potentially useful to foreign countries , international terrorists, and other nasty people intent on wreaking havoc. Restrictions on the use and export of cryptographic systems vary widely from country to country and are likely to be in a state of flux following the terrorist acts perpetrated on the United States on September 11, 2001. Before using any cryptographic system, be sure you understand the laws that apply to you. The remainder of this sidebar focuses on U.S. encryption policy as it was before September 2001.

  The United States restricts the export of strong encryption technology (you can interpret "strong" as "hard to crack"). Products with strong encryption capabilities can be exported only to selected countries in the European Union and several other industrial democracies. Export to other countries is possible only after technical review by the federal government.

  In today's world, the preferred key length for very secure encryption is 128 bits, which is classified as strong encryption by the U.S. government. However, with processors getting faster all the time and, more importantly, with people getting more clever in their methods of attack, the bar is continually being raised. For example, recent well-publicized cracking "challenges" (in which Internet users are challenged to decrypt a secret message as a test of security) have been met with many clever people harnessing the power of thousands of computers on the network to work in parallel on cracking the code.

  What does this mean to you? Well, if your country is not on the approved list, it may mean that you cannot get very secure encryption technology from a U.S. vendor. Your choices are to live with less secure technology, pursue a more secure solution with a non-U.S. vendor (not bound by U.S. export laws), or wait for the U.S. government to adopt a more liberal encryption export policy.

  You end up with a much stronger level of assurance as to the identity of the client based on public key cryptographic algorithms. Figure 12.3 shows the components of an SSL-based system supporting certificate-based client authentication. The downside is that instead of distributing the plain old passwords that we all know and understand, your clients must generate private “public key pairs and be issued certificates. Those certificates and keys must be protected and managed throughout their life cycle. You must deploy and maintain a public key infrastructure (PKI) to provide this life cycle management. Historically, certificates have not been sufficiently easy to use or manage.

  Figure 12.3. Components of a PKI-Based SSL System

  

  Another disadvantage of this approach is the generally higher processing cost of public key security. As discussed earlier, more computing power is required than with other approaches. You may need hardware acceleration to make a public key solution feasible for a system with any kind of scale. The upside, of course, is that you get a high level of security.

  If you decide you need this level of security, be sure the software you choose supports it and that the support is flexible enough to serve your other needs. For example, what kind of solution does the software provide for certificate life cycle management? During authentication, how is the association between a subject in a certificate and an entry in the directory made? You probably want this mapping to be as flexible as possible to prevent too tight a link between your certificate authority and your directory service.

• Another scheme via SASL . This is really a whole set of options because SASL is a generic mechanism for hooking in just about any authentication and security mechanism you can think of. You might want to use this mechanism if, for example, you have an existing Kerberos authentication database that you want to leverage. By obtaining or writing SASL modules for Kerberos on your server and all clients that will be accessing the directory, you can continue to use your current authentication database, administration procedures, and so on.

  Realize that by choosing this option you are probably putting your fate in your own hands, unless the vendor you choose supports a SASL module for your particular authentication scheme. At the time of this writing, Netscape Directory Server 6 supports a SASL interface that allows you to write your own plug-in modules, but Netscape does not provide any prewritten modules. The Netscape server also does not yet support security-layer plug-ins, only authentication plug-ins.

  Another concern with writing your own SASL plug-in is that each client that accesses the directory must have a similar plug-in that understands the security mechanism you've chosen . Also you should check with your server vendor to see how well a new SASL mechanism you define can be integrated with the directory's access control scheme. As with Netscape Directory Server 6, you can often explicitly reference the type of authentication used when creating an access control list, but only for predefined authentication mechanisms. The pieces fit together as shown in Figure 12.4.

  Figure 12.4. Components of a SASL-Based Security Scheme

  

Access Control

When you've decided on one or more authentication schemes to establish the identity of clients, you need to decide how to use them to protect information contained in your directory. This protection is usually provided in the form of access control, allowing you to specify that certain identities have access to certain information, whereas certain other identities or groups of identities do not.

Overview of Access Control Models

As we discussed in Chapter 2, Introduction to LDAP, there is no standard LDAP access control model today. The IETF is working on defining one, but it will probably take a while for the design to be finished, and even longer for the standard to be implemented in products and become available for you to use. In the meantime, you have to examine each directory server vendor's access control capabilities independently in the context of your needs.

Even though there is no standard access control model, most vendors ' implementations of access control have these common characteristics:

• Access can be controlled down to the attribute level. For example, it's possible to allow read access to one attribute type and write access to a different attribute type.

• Access control rules can be specified for an entire subtree at once. Generally, an access control rule included in an entry applies to that entry and all entries subordinate to it.

• Subjects may be individuals (named by distinguished name , or DN) or groups (named by the group's DN). Thus it is possible to specify access control policy for a group in your organization rather than for each individual. This capability reduces the number of access control policies you must manage, increasing security and decreasing management time.

Access control is usually specified as one or more access control lists (ACLs). Each ACL specifies three things:

1. One or more resources in the directory . Resources, also called objects , are the things to which you control access. They are typically entries, attributes, or values. An example might be the cn attribute in all the people entries in your directory.

2. One or more clients (users or applications) accessing the resources . Clients, also called subjects , are the entities to which you grant or deny access. A client may be specified as the name of a directory entry or other descriptive information. For example, a client might be specified as any authenticated directory user with a connection originating within your organization's Domain Name System (DNS) domain.

3. One or more access rights . Access rights determine what the subject can do to or with the object. For example, an access right might be "search read," meaning that the given clients can search for and read attributes from the entry.

Implementing an Access Control Policy

As we advised earlier in this chapter, the first step in determining your access control needs is to understand your data and the users who will access it. Make a table that shows who can access each data element or attribute, the level of access that should be given, and any other relevant restrictions, such as the authentication level required, time of day the access is to be allowed, and whether the attribute can be retrieved only over an encrypted connection. Try to group attributes that have related access characteristics.

Table 12.3 shows an example of such a table, with attributes and access control information for a directory intended to contain some white pages data. These attributes apply to people entries. Keep in mind that you should make similar tables for each kind of entry in your directory. If your directory stores entries for people, groups, printers, and projects, you should construct four tables.

Table 12.3. A Sample Data Access Policy

Attribute(s)	User(s) or Application(s)	Access Level	Authentication and/or Connection Protection Required
cn , sn , givenName , middleInitial , name	All	Read	None
cn , sn , givenName , middleInitial , name	Administrator	Read/write	Password- or certificate-based over SSL
mail	All authenticated	Read	Password
mail	Administrator	Read/write	Password- or certificate-based over SSL
mail	Self	Read/write	Password- or certificate-based over SSL
homeAddress , homePhone	All	Read or none, depending on user's choice	Password
homeAddress , homePhone	Self	Read/write	Password
postalAddress , telephoneNumber	All	Read	Password
postalAddress , telephoneNumber	Administrator	Read/write	Password- or certificate-based over SSL
salary	Self	Read	Password
salary	User's manager	Read/write	Password- or certificate-based over SSL

We will not discuss the design of ACLs for the entire table, but we will do so for three interesting parts of it using the ACL syntax understood by Netscape Directory Server 6. The Netscape approach to representing ACLs is typical, although with some interesting capabilities not found in other approaches. An ACL is represented by an attribute called aci , which stands for access control instruction ( ACI ). An ACI can be placed anywhere in the directory tree. Depending on the ACI, it can apply to the entry in which it is placed and any of that entry's descendants.

ACL Example 1

The first access control rule we will codify is the one for the various name attributes ( cn , sn , and so on). The intention of this generic rule is to make the naming attributes readable by anyone , authenticated or not. The attributes are to be updated only by the administrator. With LDAP Data Interchange Format (LDIF) to represent the Netscape syntax for ACLs, the following aci attribute does the job:

 aci: (target ="ldap:///dc=example, dc=com")  (targetattr="cnsngivenNamemiddleinitialname")  (version 3.0;acl "Anonymous read-search access";  allow (read, search, compare)  userdn = "ldap:///anyone";) aci: (target ="ldap:///dc=example, dc=com")  (targetattr="cnsngivenNamemiddleinitialname")  (version 3.0;acl "Admin write access";  allow (write)  userdn = "ldap:///cn=directory manager";) 

We are assuming that this ACI is placed in a directory subtree rooted at the entry dc=example,dc=com . It applies to that entry and every entry below it in the tree, and only those attributes listed in the targetattr line of the ACI. The first value of aci grants read, search, and compare access rights to anyone accessing the directory, whether authenticated or not. The second value grants write privileges to the directory manager. If you were going to use this ACI in your directory, you would change the dc=example, dc=com part to point to the base of your tree. You would also change the cn=directory manager part to reference your directory manager's entry.

ACL Example 2

The next access control rule we will examine is for home address and phone information. The interesting thing about this rule is that users have a choice of which access applies to their information. You might want to do this because some of your users won't want their home address and phone information published. One approach would be to allow users to write their own access control lists. This approach is fraught with peril ”from users accidentally denying themselves access to things they should be able to access, to users accidentally granting access to things they should not, to various kinds of malicious behavior. Allowing users to modify their own ACLs is almost never acceptable.

A way around this problem is to make ACL changes go through a mediator. The mediator might be a Web application that you develop specifically for the purpose of allowing users to make changes to the access control information in their entry. The mediator has access to make changes but also has the knowledge of what should and should not be allowed. This approach may be acceptable to you, and it is supported by most ACL schemes. The downside is that users have to go to a special application (that you must maintain) to make ACL changes.

Another approach, supported by Netscape Directory Server 6, solves this problem in a more elegant way. The Netscape server allows you to predefine access rules that apply only to entries satisfying some arbitrary criteria expressed as an LDAP search filter. These entries can live anywhere in the directory. This arrangement allows you to specify the access control rules in a single location, and then allow your users to update a different attribute in their entries, causing a new set of access control rules to apply. For example, consider the following pair of aci attributes, shown in LDIF format:

 aci: (target="ldap:///dc=example, dc=com")  (targetfilter="(homeaccess=private)")  (targetattr = "homeAddresshomePhone")  (version 3.0; acl "keeps users' home information private";  allow (none)  userdn = "ldap:///anyone";) aci: (target="ldap:///dc=example, dc=com")  (targetfilter="(homeaccess=public)")  (targetattr = "homeAddresshomePhone")  (version 3.0; acl "publishes users' home information";  allow (read)  userdn = "ldap:///anyone";) 

Notice the additional targetfilter construct in the second line of each ACI. This is a search filter used to select the entries to which the ACI should apply. In the case of the first ACI, we've chosen a filter that selects entries with the hypothetical homeaccess attribute set to the value private . Entries that satisfy this filter will have their home address and phone information attributes protected by this ACL.

The second ACL contains a similar filter, but this one tests for entries with the homeaccess attribute set to the value public . In this case the attributes can be read by anyone. Strictly speaking, the first aci value is not needed. By default, no access is granted unless specifically granted in an ACI. In this case we assumed there could be other, more general ACIs granting access to attributes by default.

With this access control scheme, a user has only to change the content of an attribute in her entry from public to private to enable a new access control policy. This kind of ACL manipulation ” essentially flipping a switch in an entry ”makes maintaining multiple access control policies convenient . This capability is powerful; it allows a compact specification of complex access control policies to be made independently of directory tree structure. Use of this feature inevitably results in access control rules that are easier to understand. You can use this feature for many other policies, some examples of which are outlined here:

• Apply different access control to various types of entries by using a filter to test for different values of the objectclass attribute. For example, you could have one set of ACIs that applies only to entries satisfying an (objectclass=person) filter. Another set of rules could apply to (objectclass=group) entries.

• Apply policies based on attribute values entered by your users. For example, you could apply an access control to all entries with mail addresses not ending in the DN of your organization by using a filter such as (!(mail=*@your.domain.com)) . Thus you could automatically prevent the routing of mail to entries that leave your domain.

• Apply policies based on reporting structures. For example, you could have an ACI that applies only to entries with (manager=<supervisor's DN>) .

• Apply policies that quickly and easily grant and revoke access to users on the basis of the content of their entries. For example, you could effectively rotate a particular role among users simply by changing a value in their entry. Any entry satisfying (role=boss-for-a-day) could be given special privileges.

As you can see, the applications of the target filter access control feature are many, and the power and flexibility are great.

ACL Example 3

The final ACL example we will investigate in detail is represented by the salary rows in Table 12.3. Our goal is to allow only an employee's manager the right to update the employee's salary. The employee should have only read access to the salary, and no one else should have any access. The latter two conditions are not much different from the simple naming attribute examples we discussed earlier. The first goal, allowing only the manager to update something, is more interesting, and we will focus our attention on that.

You could easily come up with an ACI to satisfy this goal, assuming that you know the DN of the manager in question. The problem is one of management. Taking this approach, you would need to create a separate ACI for each manager in the company, and you would need a way to apply that ACI to only those entries managed by that manager. The target filter feature mentioned previously is helpful here, but it does not help solve a basic management problem: If a user changes managers, or if a manager changes roles, you need to update the corresponding ACIs. You could use ACIs that refer to group entries for this, but then you would have to update these groups all the time.

It is also a problem that the number of ACIs required by this approach is proportional to the number of managers in your company ”potentially a large list! More ACIs means more maintenance, more chance for error, and more things to change in the event of reconfiguration or reorganization. The existence of many ACIs can also adversely affect the performance of your directory. Because all these ACIs are essentially identical, except for the value listed in one field, there must be a better way.

Fortunately, there is. Netscape Directory Server 6 implements a powerful feature aimed specifically at reducing this management overhead and the number of ACIs you need to store in your directory. Consider the following aci attribute:

 aci: (target="ldap:///dc=example, dc=com ")  (targetattr = "salary")  (version 3.0; acl "allow manager access to salary";  allow (read, write)  userdnattr = "manager";) 

The interesting part of this ACI is the userdnattr construct in the last line. This means that the access is granted to the entry or entries listed in the manager attribute of the entry to which the ACI applies. So, for example, if the ACI applies to the entry shown in Figure 12.5, the salary attribute in the entry is readable and writable by the entry mentioned in the manager field ”namely, uid=managerjoe,dc=example,dc=com :

 dn: uid=workerbabs, dc=example, dc=com uid: workerbabs cn: Worker Babs sn: babs manager: uid=managerjoe, dc=example, dc=com salary: 9000 ... other attributes ... 

Figure 12.5. ACL Placement in a Directory That Allows Separation of ACLs and Namespace

The power of this capability should be clear now. It can reduce the number of ACIs you need to maintain in your directory and reduce management costs by avoiding the requirement to maintain duplicate information. Furthermore, it can transfer ACL decisions to directory users in a safe, efficient, and error-free way, freeing up directory administrators for more important tasks . Consider these additional applications of the userdnattr ACL construct:

• Maintain an owner attribute for groups. A single ACI can be used to allow the users listed in the owner attribute the ability to update the group. This approach avoids the need for a separate ACI for each group that must be changed each time the owner of a group changes.

• Maintain a proxy attribute for entries. A single ACI can be used to allow the users listed in the proxy attribute the ability to update the entry. Such a capability might be used, for example, to give an administrative assistant temporary access to an entry that the assistant will update on behalf of his boss. Again, this functionality is provided while the number of ACLs involved and the administrative effort required are minimized.

No doubt, you can think of other interesting applications for this feature as well.

As with any powerful scheme, this one comes with some risks. Just as you can easily change much access control information in your directory for the better, you can also change it for the worse . For example, if you were not careful, you could remove access to public attributes with a simple change. More seriously, you could grant access to information that should remain private. Always be careful and triple-check your work when modifying access control information.

ACL Placement

Finally, you must consider where in the directory to place the ACLs you have designed. This placement depends on the design approach you take and the capabilities of your software. These two things are related. If your design takes advantage of some of the features we've been discussing, and one of your goals is to limit the number of ACLs in your directory, you need directory software that supports this. If, on the other hand, your design approach is to put an ACL in each entry, your choice of software is probably expanded. You should be sure to determine the scale and performance implications of this approach. For example, some directory server implementations do not handle large numbers of ACLs well.

Where you place ACLs in a tree also depends on the organization of your namespace and the capability of your directory software to separate ACL placement from the namespace. If you use software such as Netscape Directory Server 6, you can separate ACL placement from namespace; your ACL placement might look something like Figure 12.5. If you use software that does not allow such placement, you might end up with an arrangement like that in Figure 12.6.

Figure 12.6. ACL Placement in a Directory That Does Not Allow Separation of ACLs and Namespace

If you place an ACL in each entry, your tree might look something like the one depicted in Figure 12.7. We discourage you from taking this approach. In our experience, the number of ACLs in your tree is directly proportional to the administrative burden to maintain them. When things go wrong, it's much more difficult to find the offending ACL when there are many ACLs. Overall, fewer ACLs are better, and anything you can do to reduce the number of ACLs in your tree will make your life easier.

Figure 12.7. ACLs Placed in Each Entry

A final consideration is the relationship between ACL placement and replication. If you place ACLs at some point in the tree but replicate only a subtree below the entry containing the ACLs, some directory server software, such as Netscape Directory Server 6, will not replicate the ACLs (because they are not within the subtree selected for replication). If this is the case, you can either place the ACL within the replicated subtree so that it is replicated along with the data, or you can create an ACL on the consumer server in the same entry that contains the ACL on the supplier server.

Information Privacy and Integrity

You have designed your authentication scheme for identifying users and your access control scheme for protecting information in your directory. Now it's time to design a way to protect the privacy and integrity of the information as it is passed among servers and between clients and servers. Recall that earlier in this chapter we discussed the various threats to data privacy and integrity and how the threats you face and other aspects of your environment affect your design choices. In this section we detail these effects and lay out your design options in this area.

If your environment is such that you need to ensure the privacy and integrity of connections at a directory software level, your only real choice is SSL. Not every vendor supports SSL, and not every vendor that supports SSL for client/server connections supports it for server/server replication connections. Be sure to check the capabilities of your software, and make SSL support part of your evaluation criteria if this kind of protection is important to you.

When deciding whether you need this kind of protection, think about the different kinds of information you'll be keeping in your directory. Think about the consequences of each piece of information having its privacy or integrity compromised. You will find different answers for different attributes, of course. Consider making a table, like Table 12.4, listing categories of attributes in your directory and how their privacy and integrity need to be protected. In practice, you might want to combine this table with Table 12.3. We've separated them here for clarity in this discussion.

After you create a table like this, you also need to decide whether to protect privacy and integrity for client/server access, for server/server access such as replication, or for both. Protecting client/server access is usually a higher priority than protecting server/server access.

When making the decision whether to protect server/server connections, consider the topology of your replication solution. If you use replication in a tightly controlled manner, all within your authority to protect, you may not need to protect the privacy of replication connections. For example, this kind of environment might be found in a centrally administered information services (IS) department with good network connectivity throughout the organization. The directory might be replicated among three servers, all located within close proximity and on networks to which no users have access (see Figure 12.8). In this environment there is less risk that anyone will eavesdrop on a replication exchange, so SSL may not be required. On the other hand, you might want to take a more secure approach and use SSL everywhere by default, unless there is a compelling reason not to.

Figure 12.8. A Replication Configuration That Does Not Require Privacy Protection

In environments without this kind of control, or with networks that are not protected from eavesdropping, SSL may be an important component of the replication solution. For example, consider an organization without reliable network connectivity. Such a situation could require wide directory replication onto each LAN so that the directory is always available even if the WAN link goes down. Consider also an application that has high performance requirements. This case could require directory replicas to be widely dispersed onto each LAN to reduce latency of directory queries (see Figure 12.9). In this environment, protecting replication connections may be as important as protecting client/server connections.

Figure 12.9. A Replication Configuration That Requires Privacy Protection

Table 12.4. A Sample Attribute Privacy and Integrity Table

Attribute	Privacy	Integrity
cn , sn , givenName , name	No need for protection	No need for protection
mail	No need for protection; e-mail addresses are public information	Must be guaranteed to avoid misrouting e-mail
salary	Must be protected; salary information is private to an employee and the employee's manager	No need for protection; attribute is read-only in the directory

The design decisions concerning SSL include how you will address the performance issues discussed earlier and how you will handle the components of the certificate life cycle: certificate creation, distribution, renewal, and revocation. Performance is one of the most important issues to be addressed. Making your directory secure at the expense of performance is not a good solution. Performance with security can be expensive; it takes a lot of CPU power to encrypt and decrypt data that traverses the network. Public key operations involved in initial authentication exchanges are even more expensive.

One solution is simply to buy bigger, more powerful servers. A better and often more cost-effective solution is to use hardware acceleration specifically targeted at cryptographic operations. Such solutions are readily available today, but many directory providers do not support them. If performance is important to you, be sure to make hardware cryptographic acceleration part of your selection criteria.

SSL is based on public key technology. Although a detailed explanation of this technology is beyond the scope of this book (there are some excellent references listed at the end of this chapter), we do want to cover some of the administrative implications of choosing SSL or any solution based on a PKI. The important thing to know is that maintaining the PKI is different from maintaining other kinds of shared-secret or private key infrastructures . With the latter, an administrator maintains a centralized database of passwords (or the equivalent). This database exports an authentication service used by both clients and servers. The idea is that both clients and servers trust the authentication database and therefore can use it as a trusted third party during authentication exchanges.

The details can be significantly more complicated than this, but the principle remains the same: A centrally trusted administrator is in charge of all aspects of issuing identities and credentials, verifying trust, revoking credentials, imposing password and other policies related to authentication, and so on. When a user shows up for work the first day, the administrator creates an entry for that user in the authentication database. If a user forgets her password, the administrator simply resets it for her. When an employee leaves the company, the administrator removes her from the database. Credentials can be temporarily suspended , defined as usable during only certain hours of the day, or placed under other restrictions ”all under the control of the administrator.

With a PKI, things are a little trickier. The basic difference is that clients and servers do not need to consult a trusted third party to perform authentication. Instead, the credentials used to authenticate are self-verifying . A user is in charge of generating his own credentials. A trusted third party is used just once, after the credentials are generated, to verify that they belong to the user in question. Subsequent authentication exchanges need not involve the third party.

PKI is helpful in terms of scale and performance because otherwise the trusted third party can often become a bottleneck in a shared-secret system. However, PKI is often not so great in terms of deployability and manageability. For example, how does a user create his credentials? What happens when a user leaves the company and his credentials should be revoked ? What happens when the user's credentials expire? What happens when credentials are lost? How are new credentials issued? These questions about the key and certificate management life cycle have made PKI much more difficult to administer than private key schemes.

A Look at PKI

Full coverage of public key technology is beyond the scope of this book. The purpose of this sidebar is to give you a 50,000- foot view of this important and complex technology.

The basic principle of public key technology is a mathematical concept that can be used to relate certain pairs of large numbers (called keys ) in a special way. If one of the keys is used to encrypt a message, the other key can be used to decrypt the message, and vice versa. Fundamental to this scheme is another property: Only these two keys (called a key pair ) are related in this way. In other words, if a message is encrypted with one key, it can be decrypted only by the matching key in the pair (or at least, decrypting would be very difficult without the matching key). One key is called the private key , and the other is called the public key . The idea is that you are the only one who knows your private key, and you publish your public key only as widely as you want.

Given this background, you can see how I might send a private message to you: I use your public key to encrypt the message, which I then send to you, and you use your private key to decrypt it. I know that only you can read the message because to decrypt it requires your private key, which nobody else has. There is only one flaw in this scheme: How do I know that it's really your public key I'm using to encrypt this message? This is the purpose of a certificate.

A certificate binds a public key to an identity (and possibly other information about that identity). The idea is simple: You and I share a trusted third party (for example, a mutual friend, an organizational administrator, a government agency). If you go to that trusted third party and prove your identity and present your public key, that third party wraps up and signs your public key along with your identity and any other appropriate information. This neat little package of information is called a certificate , and the process of getting one is called certificate issuance .

A certificate has two interesting properties. First, it is signed by the trusted third party (called a certificate authority , or CA ). This means that if the certificate is tampered with, I'll be able to tell. Second, it is possible for me to look at the certificate and verify that it was signed by the party we both trust. This is the mechanism by which I can be assured that your public key really belongs to you, at least to the level that I trust the certificate authority.

Just as in real life, you can imagine building chains of trust between certificate authorities. For example, you and I might not share a trusted third party, but the entity I trust and the entity you trust might share a trusted third party. Depending on the level of trust we both have in our trusted entities, this might be enough for us to trust each other. The area of trust management is an important and often complicated aspect of PKI.

Another important concept in PKI is revocation. What happens if I lose my private key or if it falls into the wrong hands? If your credit card is stolen, the thief can rack up charges on your account. Similarly, but with potentially more serious consequences, if your private key is stolen, the thief can read messages intended only for you and ”perhaps even worse ”send messages that look like they came from you. What makes this situation more serious than losing your credit card is that you might not be able to tell that your key has been compromised; you don't get a monthly statement detailing its use. Nor do you typically have any protection from the malicious things someone might do with it, whereas your liability for a stolen credit card is limited.

In this situation the solution is to revoke your certificate. This means that the CA that signed your public key wants essentially to "unsign" it. Because that's not possible, the CA might resort to publishing a list of revoked certificates ”a certificate revocation list ” that should be consulted by security-conscious applications. Another approach is to have applications ask the CA (or its agent) each time the certificate is used whether it is still good. This solution, although attractive in many ways, reintroduces the central bottleneck that we thought we got rid of by moving to PKI!

Figure 12.10 depicts the major components of a typical PKI solution.

Figure 12.10. Components of a PKI Solution

Lest you be scared away from PKI by this bleak presentation of the management challenges it poses, we should quickly add that products exist that improve the deployability and manageability of PKI by a quantum leap. The Netscape Certificate Management System (CMS) is a good example. By using the directory as a central hub for managing the PKI life cycle, CMS achieves the best of both worlds . The more scalable advantages of PKI are retained and combined with the centralized administration model of private key schemes.

The point is simply this: Although SSL comes with many benefits that often make it worth deploying, administrative and performance costs are involved too. You can reduce administrative costs by choosing a complete solution that includes a significant manageability component. You can reduce performance costs by using special hardware to help speed up expensive cryptographic operations. Be sure to include PKI deployment and manageability, as well as performance requirements, in your design and evaluation criteria if you choose to deploy SSL.

Administrative Security

All the security technology in the world is not worth much if it is improperly applied and administered. The most elaborate home security system in the world, for example, does little or no good unless it is properly installed and activated, sensible precautions are followed in its operation, and the alarm passcode to defeat the system is not written on a note stuck to the wall near the system's keypad. Computer security and directory security are similar. This section examines some of the more common administrative directory service pitfalls that can contribute to security problems.

Enforcing a password policy is important for password-based security to be effective. If you have ever run a password-cracking program on your users' passwords, you will know that people tend to choose horrible passwords that are easy for an attacker to guess using either a little knowledge of the person or a brute-force attack. There are three things you can do to mitigate these problems:

1. Educate your users.

2. Enforce a password policy.

3. Run password crackers.

First, you can educate your users on how to choose a good password. Users should follow these rules when choosing passwords:

• Passwords should not be related to the user's name or login ID.

• Passwords should not be words that can be found in the dictionary.

• Passwords should be at least eight characters long. The longer the password, the better.

• Passwords should contain a combination of letters , numerals, and punctuation.

Also teach your users the consequences of losing a password, and the minimum precautions they should take in daily password management. Often users simply don't realize the consequences of their password being compromised. If a user is aware of these things, she still might not think of the nontechnology-oriented ways in which her password can be compromised (for example, the sticky note she has stuck to her computer monitor screen). Education can go a long way toward raising awareness in your user community ”and therefore reducing problems.

Second, you can select software that comes with some kind of password policy capability. For example, Netscape Directory Server 6 and Microsoft Active Directory let you specify things such as the minimum length of a password, the mix of characters it must contain, how often it must be changed, and whether it's acceptable for users to choose passwords that they have used in the past. Having such guidelines in place helps enforce the policy when user education has failed because either you didn't reach users with your education campaign or because users willfully ignored all the fine advice you gave them.

Third, you can ferret out bad passwords by regularly running a password-cracking program such as Crack on your directory. The reason for doing this is simple: If you can do it, you can bet that people attacking your system will do it also. Your goal is to crack and change bad passwords before an attacker does. An even more effective approach is to enforce minimum password quality criteria and reject passwords that are easily crackable before they are entered by users. Keep in mind that password cracking can be a controversial subject; it often takes careful reasoning to explain its usefulness to management. And you should be careful with the results of your cracking activities to avoid upsetting your users and making them distrust you and the directory service. For more information on Crack, see http://www.users.dircon.co.uk/~crypto/download/c50-faq.html.

Administrative data-gathering procedures are another area in which security mistakes are commonly made. Think about the path your data takes from start to finish. If you are bulk-loading data from a corporate human resources relational database, consider the total path the data takes from the time it leaves the database to when it arrives in your directory. Is the data transferred via File Transfer Protocol (FTP)? If so, how is the data protected on the way? Who has access to the data at the relational database source? Do they follow the same level of security procedures that you have instituted for your directory?

Ideally, the security of your whole system would be equal at each component. For example, if your data is protected via certificate-based authentication and encryption via SSL in your directory, you would like it to be protected in the same way in the source as it is when transferred to your directory. But be careful not to fall into the trap of viewing your solution as either secure or not secure, with nothing in between. In evaluating the total security of your system, you must consider not only the possible weak links, but also how difficult and probable it is for an attacker to exploit them.

Respecting Your Users' Privacy

We've talked about privacy as it relates to the overall security design problem. In this section we talk about privacy from the perspective of the directory user. It's important to keep this perspective in mind as you design and deploy your system. Failure to do so can create irate users, headaches for you, and, ultimately, a directory service that fails to win the hearts and minds of your user community.

If your directory is used solely as a store of configuration and preference data for your users, the intention probably is that one user should never be able to see information about another user. In this case protecting the privacy of user information involves primarily protecting the data from unauthorized access. In addition, your users may have concerns about how you will use the data. Many organizations that collect data about their users publish a detailed privacy policy that describes what will and will not be done with the data, with whom it will be shared, and how to opt out of that sharing if possible.

If your directory data is intended to be shared and viewed more widely than this, more planning is required. Our experience suggests that you will come across different kinds of users with different kinds of privacy expectations and requirements.

On one extreme is the user who does not want any information about him published in the directory at all. This user is often angry when information about him is published ” angry not just with you, but with those who maintain other information sources on the network, including Web-based phone books, credit reporting services, telemarketing databases, and others. This user feels these information sources are an invasion of his privacy, and he may not settle for anything less than being removed from the service.

Think carefully about how important it is to your service to have complete coverage within your organization. If it's not critical, perhaps the best approach is simply to remove such users from the directory. You can often head off such problems by requiring users to sign up for service in your directory rather than publishing information about them without their permission. This latter approach is clearly to be avoided if possible, but often it is simply not possible. Company policy usually wins out over the desire of your users. Regardless of which approach you choose, be aware of the consequences and have an answer ready for complaints like this.

Another type of user might have a specific concern about having personal information published in the directory. For example, she might have been the victim of a stalking incident and might be trying to keep as low a profile as possible. This was a real example we encountered while running the directory service at the University of Michigan. We felt we had two choices to address the situation: We could remove the user entirely, cutting off her access to computing services she wanted to use, such as e-mail; or we could convert her entry into an anonymous entry in which all identifying information had been removed but e-mail, and other nonidentifying information remained. We chose the latter approach, and the result was a happy user.

Pay particular attention to cases like this. Users in this category have legitimate concerns about their privacy, and you should respond swiftly to remedy the situation. Do not be surprised if you receive requests that seem bizarre at first. After talking to the user, you will usually understand his perspective, and the request will no longer seem so odd.

Security versus Deployability

We end this chapter by discussing the important topic of security versus deployability. Many security schemes have failed because they were not deployable . You would do well to keep in mind that the most secure service in the world is the one that is never deployed and used. Unfortunately, this is also not a useful service. Similarly, a solution that is deployed but provides no real security will soon become useless because the information it provides cannot be trusted.

Your job when designing your directory's security infrastructure is to find the balance between these two extremes. Where that balance lies depends on the needs of your users, the security threats your system is likely to face, and the consequences that will result from a security breach. A related factor is the amount of time and money you are willing to spend to deploy and maintain your system.

It's easy to get caught in one of the two extremes of the security spectrum. At one extreme, your only interest is deploying your directory service; security seems to be only a roadblock in the way of achieving that goal. Such thinking leads to a directory that will probably not be useful or trusted for long. Worse consequences are possible if the directory contains sensitive information that is compromised.

At the other extreme, you can become wrapped up in security for its own sake; you forget that security is only a means to an end. This extreme can lead to one of two places: One possibility is that you get bogged down trying to make the perfect security system, and meanwhile your project is canceled or taken away from you. Another possibility is that you design and deploy such a system, but none of your users show up to get their fingerprints taken so they're able to use the system, and the system fails. Either way, you end up without a directory service.

You would do well to keep the security versus deployability trade-offs firmly in mind throughout your design process. This advice may seem obvious, but we have seen many directory projects go astray in this area.