Choosing an Overall Directory Design and Deployment Approach

Understanding and Deploying LDAP Directory Services > 11. Privacy and Security Design > Designing for Security

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053054012006213221083157216061117

Designing for Security

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 pretty 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've got 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 that 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 really useful only in the context of access control. First, you authenticate a client, and then, based on 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. There are circumstances, however, in which you may want to make data available to any user of the directory whether they have authenticated or not. Users who do not authenticate, or users who authenticate without providing any credentials, are called anonymous users. Such a user is treated by the LDAP server as if he did not authenticate at all and is 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. This choice might be appropriate for low-security environments in which the set of users is restricted and relatively trusted (e.g., 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 of choosing a password-based solution.

  • Simple passwords over SSL.   This option involves using SSL (or TLS) to protect the connection over which a simple password is transmitted. The simplicity and ease of use 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 much more complex than a password-based solution. You have to 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 involves a fairly 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 when choosing passwords over SSL is the implication it will have on the performance of your system. Using SSL to authenticate a directory session takes 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 is nearing completion that will allow SSL protections 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 you should 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 is the only one we are aware of that does).

Government Restrictions on Encryption Technology

A separate but important consideration is the effect, if any, that United States 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 on the world and the United States in particular. France actually has laws banning virtually all encryption technology. That is an extreme case, but other countries may have applicable laws you should be aware of. The remainder of this sidebar focuses on U.S. encryption policy.

The United States restricts the export of strong encryption technology (you can interpret "strong" in the sense of "hard to crack"). In encryption-speak, this means that the United States restricts the size of the keys that can be used to encrypt data. The longer the key, the more secure the encryption; the shorter the key, the easier it is for an attacker to break the encryption.

Today the U.S. government allows free export of 40-bit encryption technology. Occasionally, technology with keys as long as 56 bits have been approved for export. These key lengths are enough to stop the casual or even moderately determined attacker, but not enough to stop anybody really knowledgeable and serious about getting to your data. In today's world, the preferred key length for very secure encryption is 128 bits. 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 lots of 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 organization is outside the United States, 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 (and reasonable!) encryption export policy.



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

    Protect the privacy of data

    Ensure the integrity of data

    Authenticate clients

    You end up with a much stronger level of assurance as to the identity of the client based on public key cryptographic algorithms. The components of an SSL-based system supporting certificate-based client authentication are shown in Figure 11.3. 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. Sufficient ease of use of certificates and their management has not been achieved historically.

    Figure 11.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 cycles are 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? When authenticating, 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 likely 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, only Netscape Directory Server 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 the Netscape Directory Server, 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 11.4.

    Figure 11.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.

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

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

  • One or more clients (users or applications) accessing the resources.   Clients, also called subjects , you grant or deny are the entities you grant or deny access to. 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 from within your organization's DNS domain.

  • 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 "read and search," meaning that the given clients can search for and read attributes from the entry.

As we discussed in Chapter 3, "An Introduction to LDAP," there is no standard LDAP access control model today. The IETF is working on defining one, but it will likely 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.

As we advised earlier in the chapter, the first step in determining your access control needs is to understand your data and the users that 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 SSL connection. Try to group attributes that have related access characteristics. Table 11.3 shows an example of such a table, with attributes and access control information for a directory intended to contain some white pages data.

Table  11.3. sample data access showing groups of attributes and associated access and authentication required
Attribute(s) User(s) or Application(s) Access Level Authentication and/or Connection Protection Required
cn , sn , 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 certificate-based over SSL Administrator Read/write Password- or
mail certificate-basedover SSL 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 , telephone- Number Admin. Read/write Password- or certificate- based over SSL
salary Self Read Password
salary User's manager Read/write Password- or certificate-based over SSL

This table shows some examples of attributes that 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.

We will not go through the design of actual ACLs for the entire table, but we will do so for three interesting parts of it using the ACL syntax understood by the Netscape Directory Server. ACLs are usually, but not always, expressed as directory attributes. 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 item (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.

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. Using LDAP Data Interchange Format (LDIF) to represent the Netscape syntax for ACLs, the following aci attribute does the job:

 aci: (target ="ldap:///dc=airius, dc=com")    (targetattr="cnsngivennamemiddleinitialname")    (version 3.0;acl "Anonymous read-search access";    allow (read, search, compare)    (userdn = "ldap:///anyone");)   aci: (target ="ldap:///dc=airius, 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=airius, 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 they are authenticated or not. The second value of the aci attribute grants write privileges to the directory manager. If you were going to use this ACI in your directory, you would change the dc=airius, 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.

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 way to accomplish this 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 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 is to make ACL changes go through some 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 the Netscape Directory Server, 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 allows you to specify the possible access control rules once 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 ACIs, shown in LDIF format:

 aci: (target="ldap:///dc=airius, 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=airius, 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 the ACI should apply to. 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 very 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 domain name 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 based on 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.

The final ACL example we will investigate in detail is represented by the salary rows in Table 11.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, only allowing 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. 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. The Netscape Directory Server implements a powerful feature specifically aimed at reducing this management overhead and the number of ACIs you need to store in your directory. Consider the following ACI:

 aci: (target="ldap:///dc=airius, 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 11.5, the salary attribute in the entry is readable and writable by the entry mentioned in the manager field, namely cn=manager babs, dc=airius, dc=com :

Figure 11.5 ACL placement in a directory, allowing separation of ACLs and namespace.
 dn: cn=worker babs, dc=airius, dc=com     cn: worker babs     sn: babs     manager: cn=manager babs, dc=airius, dc=com     objectclass: top     objectclass: person  other attributes 

The power of this capability should be getting clear to you. It has the ability to 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 has the ability to 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 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 minimizing the number of ACLs involved and the administrative effort required.

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 lots of access control information in your directory for the better, you can also change it for the worse . For example, if you are 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 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.

Tree placement of your ACLs 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 the Netscape Directory Server, you can separate ACL placement from namespace; your ACL placement might look something like what was shown in Figure 11.5. If you use software that does not allow such placement, you might end up with an arrangement like that shown in Figure 11.6.

Figure 11.6 ACL placement in a directory that does not allow separation of ACLs and namespace.

If you choose to place an ACL in each entry, your tree might look something like the one depicted in Figure 11.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. All in all, fewer ACLs are better, and anything you can do to reduce the number of ACLs in your tree will make your life easier.

Figure 11.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, 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've now 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 the 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 con sequences 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 the one shown in Table 11.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 the one shown in Table 11.3. We've separated them here for clarity of discussion.

Table  11.4. An example of an 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 ”email addresses are public information Must be guaranteed to avoid misrouting email
salary Must be protected ”salary information is private to an employee and the employee's manager No need for protection ”attribute is ready-only in the directory

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 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 that no users have access to (see Figure 11.8). In this environment, there is little 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 some compelling reason not to.

Figure 11.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 very reliable network connectivity. This could require wide d irectory replication onto each LAN so that the directory is always available even if the WAN link goes down. Consider also an application that has very high performance requirements. This could require that directory replicas be widely dispersed onto each LAN to reduce latency of directory queries (see Figure 11.9). In this environment, protecting replication connections may be as important as protecting client/server connections.

Figure 11.9 A replication configuration that requires privacy protection.

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 very 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 it is beyond the scope of this book to explain this technology in detail (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 get significantly more complicated than this, but the principle remains the same: A centrally trusted administrator is in charge of all parts of the process 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 the user in the authentication database. If a user forgets her password, the administrator simply resets it for her. When a user leaves the company, the administrator removes him from the database. Credentials can be temporarily suspended , usable only during 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 what you might call 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 do indeed 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, it is often not so great in terms of deployability and manageability issues. 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 the credentials are lost? How are new ones 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 about 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. So 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, it would be very hard to do so without the matching key). One key is called the private key and the other is called the public key , for reasons that will be clear later. 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. As you probably see by now, 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 (e.g., 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 it 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 in fact 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 hands of evildoers ? 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, introduces the central bottleneck that we thought we got rid of by moving to PKI!

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

Figure 11.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 work is ongoing in this area to improve the deployability and manageability of PKI by a quantum leap. Netscape's next-generation security solution (still in development at the time of this writing) is a good example. By using the directory as a central hub for managing the PKI life cycle, you can achieve the best of both worlds . The more scalable advantages of PKI can be 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, there are administrative and performance costs involved too. Administrative costs can be reduced by choosing a complete solution that includes a significant manageability component. Performance costs can be reduced by using special hardware to help speed up expensive cryptographic operations. Be sure to include PKI deployment and manage- ability, 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 very 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 passcode to defeat the system is not written on a note stuck to the wall near the system's keypad. Computer and directory security is 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 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:

  • Educate your users.

  • Enforce a password policy.

  • Run password crackers.

First, you can educate your users on how to choose a good password, the consequences of losing a password, and the minimum precautions they should take in daily password management. Often users simply don't know what separates a good password from a bad one, or they might not realize the consequences of their password being compromised. If a user is aware of these things, she still might not think of the non-technology-oriented ways in which her password can be compromised (for example, by reading 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. Such software lets 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 other things. This helps enforce the policy when user education has failed either because 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 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 may be to crack passwords before they are entered by users and disallow the ones you can crack. 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 making your users upset and distrustful of you and the directory service.

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 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 " insecure ," 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. In our experience, 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 himself published in the directory at all. This user is often very angry when information about him is published ” angry not just with you, but with the maintainers of 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 removal 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 at all possible. But in many situations, this is simply not possible. Company policy usually wins 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 information about her 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 email; or we could convert her entry into an anonymous entry in which all identifying information had been removed but email 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 you consider to be bizarre at first. After talking to the user you can usually understand his or her perspective, and the request no longer seems quite so kooky.

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 very 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 in deploying your directory service; security seems only to be a roadblock in the way of achieving that goal. This 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 gets 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 one of two places. One possibility is that you get bogged down trying to make the perfect security system, and meanwhile your project gets canceled or taken away from you. Another possibility is that you actually 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.



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

access
         types
                    security
access control 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
         ACLs
                    placement 2nd 3rd
          ACLs (access control lists) 2nd
                    clients
                    objects
                    rights
access control lists, see ACLs
ACLs
         placement
                    access control 2nd 3rd
administration
          PKI
          SSL (Secure Sockets Layer) 2nd
administrative security
          data-gathering procedures
          passwords
                    crackers
                    educating users
          polices
          weak links
anonymous authentication
attributes
         types
                    security 2nd
authentication 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
          anonymous
          certificates over SSL 2nd 3rd
          SASL schemes 2nd 3rd 4th
          simple passwords 2nd 3rd 4th 5th
                    over SSL
         SSL
                    PKI-based
certificates
         authentication
                    over SSL 2nd 3rd
client-server acces
          security
clients
          ACLs (access control lists)
clients, zsee also subjects
crackers
         password
                    administrative security 2nd
deployability
          security 2nd 3rd
design
          security
                    access control 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th
                    authentication 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
                    deployability 2nd 3rd
                    information privacy and integrity 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
                    user privacy 2nd 3rd
directories
          security
                    access control 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th
                    authentication 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
                    deployability 2nd 3rd
                    information privacy and integrity 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
                    user privacy 2nd 3rd
encryption
          government restrictions
end users
          privacy 2nd 3rd
entries
          ACL placement
information
          privacy and integrity 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
                    access types
                    administrative 2nd 3rd 4th 5th 6th 7th
                    attribute types 2nd
                    PKI administration
                    replication 2nd
                    SSL (Secure Sockets Layer)
                    SSL administration 2nd
objects
          ACLs (access control lists)
objects, zsee also resources
passwords
          administrative security
                    crackers 2nd 3rd
                    educating users
                    policies
         authentication
                    simple 2nd 3rd 4th 5th
                    simple over SSL
PKI
         security
                    administration
PKI (public key infrastructure)
policies
          password
privacy
          replication configurations
public key infrastructure, see PKI
replication
          security
                    privacy protection
resources
          ACLs (access control lists)
resources, zsee also objects
rights
          ACLs (access control lists)
SASL
         schemes
                    authentication 2nd 3rd 4th
schemes
         SASL
                    authentication 2nd 3rd 4th
security
          access control 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
                    ACL placement 2nd 3rd
          ACLs (access control lists) 2nd
                    clients
                    objects
                    rights
          authentication 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
                    anonymous
                    certificates over SSL 2nd 3rd
                    PKI-based SSL system
                    SASL schemes 2nd 3rd 4th
                    simple passwords 2nd 3rd 4th 5th
                    simple passwords over SSL
          deployability 2nd 3rd
         encryption
                    government restrictions
          information privacy and integrity 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
                    access types
                    administrative 2nd 3rd 4th 5th 6th 7th
                    attribute types 2nd
                    PKI administration
                    replication 2nd
                    SSL (Secure Sockets Layer)
                    SSL administration 2nd
          user privacy 2nd 3rd
server-server access
          security
simple passwords
          authentication 2nd 3rd 4th 5th
                    over SSL
software
         passords
                    policies
SSL
         authentication
                    certificates 2nd 3rd
                    simple passwords
         PKI-based systems
                    authentication
         security
                    administration 2nd
subjects
          ACLs (access control lists)
subjects, zsee also clients
users
         passwords
                    administrative security 2nd
          privacy 2nd 3rd
weak links
          total system security

2002, O'Reilly & Associates, Inc.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net