Deploying Secure 802.11 Wireless Networks with Microsoft Windows

Public Key Infrastructure

A public key infrastructure (PKI) is a system of digital certificates and CAs that verifies and authenticates the validity of each entity that is participating in secure communications through the use of public key cryptography.

Certification Authorities

When a certificate is presented to an entity as a means of identifying the certificate holder (the subject of the certificate), it is useful only if the entity being presented the certificate trusts the issuing CA. When you trust an issuing CA, it means you have confidence that the CA has the proper policies in place when evaluating certificate requests and will deny certificates to any entity that does not meet those policies. In addition, you trust that the issuing CA will revoke certificates that should no longer be considered valid by publishing an up-to-date certificate revocation list (CRL). For more information about CRLs, see the Certificate Revocation section of this chapter.

For Windows users, computers, and services, trust in a CA is established when you have a copy of the self-signed certificate of the root CA of the issuing CA locally installed, as well as having a valid certification path meaning that none of the certificates in the certification path has been revoked or has had its validity period expire. The certification path includes every certificate issued to each CA in the certification hierarchy from a subordinate CA to the root CA. For example, for a root CA, the certification path is one certificate: its own self-signed certificate. For a subordinate CA, just below the root CA in the hierarchy, its certification path is two certificates: its own certificate and the root CA certificate.

If your organization is using the Active Directory directory service, trust in your organization s certification authorities will typically be established automatically, based on decisions and settings made by the system administrator.

Certification Hierarchies

A certification hierarchy provides scalability, ease of administration, and consistency with a growing number of commercial and other CA products. In its simplest form, a certification hierarchy consists of a single CA. However, in general, a hierarchy will contain multiple CAs with clearly defined parent-child relationships. In this model, the subordinate certification authorities are certified by their parent CA-issued certificates, which bind a CA s public key to its identity. The CA at the top of a hierarchy is referred to as the root authority, or root CA. The child CAs of the root CAs are called subordinate CAs.

In Windows 2000 Server, Windows XP, and Windows Server 2003, if you trust a root CA (by having its certificate in your Trusted Root Certification Authorities certificate store), you trust every subordinate CA in the hierarchy, unless a subordinate CA has had its certificate revoked by the issuing CA or has an expired certificate. Thus, any root CA is a very important point of trust in an organization and should be secured and maintained accordingly.

Verification of certificates thus requires trust in only a small number of root CAs. At the same time, it provides flexibility in the number of certificate-issuing subordinate CAs. There are several practical reasons for supporting multiple subordinate CAs, including the following:

• Usage

  Certificates may be issued for a number of purposes, such as secure e-mail and network authentication. The issuing policy for these uses may be distinct, and separation provides a basis for administering these policies.

• Organizational divisions

  There may be different policies for issuing certificates, depending upon an entity s role in the organization. You can create subordinate CAs to separate and administer these policies.

• Geographic divisions

  Organizations may have entities at multiple physical sites. Network connectivity between these sites may dictate a requirement for multiple subordinate CAs to meet usability requirements.

• Load balancing

  If your PKI will support the issuing of a large number of certificates, having only one CA issue and manage all these certificates can result in considerable network load for that single CA. Using multiple subordinate certification authorities to issue the same kind of certificates divides the network load between certification authorities.

• Backup and fault tolerance

  Multiple certification authorities increase the possibility that your network will always have operational certification authorities available to service users.

Such a certificate hierarchy also provides administrative benefits, including the following:

• Flexible configuration of the CA security environment to tailor the balance between security and usability, such as key strength, physical protection, and protection against network attacks.

  For example, you might choose to employ special-purpose cryptographic hardware on a root CA, operate it in a physically secure area, or operate it offline. These security measures may be unacceptable for subordinate CAs because of cost or usability considerations.

• The ability to turn off a specific portion of the CA hierarchy without affecting the established trust relationships.

  For example, you can easily shut down and revoke an issuing CA certificate that is associated with a specific geographic site without affecting other parts of the organization.

The certification path for a certificate can be viewed from the Certification Path tab of the properties of a certificate, as shown in Figure 6-2.

Figure 6-2. The Certification Path tab when viewing the properties of a certificate.

For a small business environment, a certificate hierarchy consisting of a single root CA that is also the issuing CA is adequate. For a medium-sized organization, a single root CA with a single level of issuing CAs is adequate. For an enterprise network, you should deploy at least a three-level CA hierarchy, consisting of the following:

• A root CA that is offline (not available on the network)

• A layer of intermediate CAs that are offline

• A layer of issuing CAs that are online

This CA hierarchy provides flexibility and insulates the root CA from attempts to compromise its private key by malicious users. The offline root and intermediate CAs do not have to be Windows Server 2003 or Windows 2000 Server CAs. Issuing CAs can be subordinates of a third-party intermediate CA. This hierarchy is shown in Figure 6-3.

Figure 6-3. Recommended certificate hierarchy for enterprise networks.