Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

PKI Architecture in Windows Server 2003

The certificate services provided by Windows Server 2003 are the fourth implementation of certificate services in Windows. Certificate services in Windows are implemented in

NT 4.0 via the option pack.

Microsoft Exchange prior to Exchange 2000 via implementation of the Key Management Service (KMS). (Microsoft Exchange 2000 uses KMS and Windows 2000 certificate services.)

Windows 2000.

Windows Server 2003.

Each implementation has offered increasing flexibility and security. New in Windows Server 2003 is

An RA via implementation of the certificate enrollment pages on a separate web server

The ability to customize templates

The ability to archive private keys

Development of trust between two or more CA hierarchies using cross-certification and qualified subordination

PKI is implemented in Windows Server 2003 via the following components:

Certificate store

Certificate templates

Certificates, both self-signed and issued by a CA

Practice policy and practice policy files

CAs

CA hierarchy

Certificate Store

Even if no PKI is established, each Windows computer has several certificate stores. Certificate store types are described in Table 12-1.

The certificate store can be examined by doing one of the following:

Clicking the Certificates button from the Content Property page of IE.

Opening the Certificates snap-in in an MMC console.

Examine Certificates Stores Using Internet Explorer

The certificates stores can be viewed from the Internet Explorer Properties, Content pages. To examine the stores and look at certificates in one of them, follow these steps:

Examine Certificates Stores in the Certificates Console

The advantage of creating the Certificates console is that a user may manage personal certificates, and an administrator may manage computer certificates. The console can be saved and easily opened to manage certificates at a later time. To create the console follow these steps:

Certificate Templates

Windows 2000 introduced certificate templates to make certificate enrollment and usage more flexible. Also, setting permissions on the templates can restrict certificate usage. A user without the Enroll permission on a template cannot obtain a certificate of its type.

Windows Server 2003 introduces version 2 (V2) templates. V2 templates can be customized to provide additional flexibility. V2 customizable templates are only available if the CA is integrated with Active Directory and is Windows Server 2003 Enterprise Edition. When the CA is integrated with Active Directory, the combination of the V1 or V2 template definition and the information available in Active Directory makes enrollment quick and easy because the requestor is not required to enter much information. If the CA is not integrated with Active Directory, the enrollee must add more information during enrollment. For more information on CA types, see the section "Certification Authorities."

To examine certificate templates, open the Certificate Templates snap-in in an MMC console, as shown in Figure 12-5.

Restricting Certificate Enrollment

Certificate enrollment can be restricted in the following ways:

Changing permissions on the certificate templates
Changing permissions on the certificate template can restrict certificate enrollment. The Enroll permission, as shown in Figure 12-6, is necessary to successfully obtain a certificate. By creating special Windows groups and giving only these groups the Enroll permission on a certificate template, enrollment is restricted to members of the groups. Permissions can be set on templates in the Certificate Template Console by right-clicking the template and selecting Properties and then Security.

Setting the CA enrollment policy to require approval
The Public Key Policy of the default domain policy specifies the CA enrollment policy for CAs integrated with Active Directory. The policy is listed as the Autoenrollment Setting Properties and is shown in Figure 12-7. By default, CAs that are integrated with Active Directory are set to automatically issue certificates required by authenticated identities. This means that a user with an account in Active Directory can request and be issued any certificate for which he has the enrollment permission on the template. The default can be changed in Windows Server 2003. If you do this, every certificate request must be approved. This process may prove unwieldy.

Using custom templates and requiring some certificates to be manually approved
Others can be automatically enrolled, as shown in Figure 12-8.

Standard Template Types

CAs integrated with Active Directory provide the types of templates described in Table 12-2. In this table, those identified as V1 templates are available on all versions of Windows Server 2003 and on Windows 2000 CAs. V2 templates are only available on Windows Server 2003 Enterprise Edition Enterprise CAs. V1 certificate template types on a Windows Server 2003 Enterprise Edition Enterprise CA are V2 versions and can be customized.

Custom Templates

When certificate services are installed on a Windows Server 2003 Enterprise Edition server, the certificate templates can be modified. Saving a copy of a standard template to a new file and then making changes produces a customized template. Custom template choices include items such as key archival and enrollment approval. More information on custom templates and how to implement them is provided in Chapter 13. Figure 12-9 displays the General page of a new custom template file.

Self-Signed Certificates

In Chapter 6, the use of self-signed certificates and their problems were outlined for the Encrypting File System. Self-signed certificates are used in other places as well. The root CA, the first CA in a hierarchy, creates and signs its own certificate. This use of a self-signed certificate is necessary. (The root of trust must start somewhere.) Another use of a self-signed certificate is the production by Small Business Server 2003 of a self-signed SSL certificate for use by the IIS server that is part of its configuration. Small Business Server 2003 IIS can also utilize an SSL certificate produced by a CA, either public or private. A primary use for the self-signed certificate is to protect Outlook Web Access. Although the use of privately produced SSL certificates is not advised for public web sites, especially commercial web sites, the use of privately produced SSL certificates makes good sense when the usage is for employees only. This is the case here: The users of SSL will all be employees of the small business.

In any case where self-signed certificates are used by Windows OSs, no key management is provided. To ensure the availability of the keys, and therefore the ability to recover the root CA, keys should be backed up and secured in a safe place.

Practice Policy and Practice Policy Files

The practice policy is the most important part of the CA implementation. One of the major issues with any PKI is that if it's not correctly planned, deployed, managed, and protected, it provides a false sense of security. When the CA is not protected, it may be easy to compromise. When certificate enrollment is not carefully controlled, the wrong individuals may obtain valid certificates and use them for unauthorized purposes. If the CA certificate and private key are not archived, it may be impossible to recover the CA after a disaster. If private keys are not protected, sensitive information may be exposed. If the CA activity and administration is not audited, mistakes and improper activity may never be uncovered and thus cannot be rectified. In short, a poorly designed, poorly implemented, and unprotected PKI is worse than no PKI at all. This is true no matter whose implementation of PKI is used. For many PKIs, a large barrier of cost and implementation knowledge currently tends to inhibit casual and possibly improper implementation. Cost and complexity may serve to assist in the development of a strong PKI model because many of these PKI products also require a large amount of consulting services to successfully implement them. If consulting services provide sound advice, and the product provides the tools necessary, a strong, properly implemented PKI can be the result.

TIP: Use Face-to-Face Registration

The most secure form of enrollment is to insist on face-to-face authentication at a RA and to store user certificates on hardware token. However, doing so is cost-prohibitive. In a large organization, doing so may also be impractical because of the large number of people, locations, and the mobility of many of the people.

There is no similar barrier to PKI in Windows Server 2003. PKI can easily be installed and comes as part of the operating system. To install a Windows Server 2003 CA that is integrated with Active Directory, you must be a domain admin. To install a CA that is not integrated with AD, you only need to be a member of the local administrators group on that server. There is no requirement for understanding PKI. The GUI interface makes it possible to install and use certificate services in Windows Server 2003 with little to no use of the extensive help files. Therefore, the security of the PKI and the processes it controls through certificate issuance is directly related to the quality of the PKI design and its implementation and management. This information should be part of the practice policy. Management should prepare this document with input from those qualified to assess the technical, legal, and security implications of the choices.

The technical decisions made in the CA practice policy must then be implemented in the configuration and management of the CA. Many elements of the policy can be configured in the interface. These items are as follows:

The security policy is a high-level document created by corporate IT management, security management, or some combination of the two. Its purpose is to define the use of security services and the security posture of the organization, as well as to establish the rules that must be followed to ensure the security of the organization's assets. An organization's security policy is usually composed of specific, individual security policies that pertain to different areas. For example, security policy that creates the security infrastructure for PKI might include answers to questions such as which application will use certificates, how they will use certificates, and whether role separation will be enforced.

The certificate policy is a set of rules that details the certificate purposes that are provided by the CA and how usage, enrollment, and issuance will occur. The policy authority is a group of members of the organization from many areas who are selected to define the policy. Because the policy should be inline with the security policy, those who develop the security policy are typically also part of the policy authority. The policy defines

Purpose of the certificate, such as EFS, IPSec, or authentication.

Legal issues. For example, if the CA is compromised or used for a purpose outside its defined scope, are there liability issues?

Minimum length of the public and private key pairs.

Requirements for enrollment and renewal.

User authentication for certificate enrollment.

Private key management requirements, such as hardware-based storage.

Whether or not the private key can be exported.

Responsibilities of the users, such as what they should do if the private key is lost or compromised.

The certificate practice statement (CPS) defines the CA policy. It is a statement about the way the CA issues certificates. Legal staff, especially those who worked on the certificate policy, IT staff, and those that administer IT infrastructure should define the CPS. Some of the elements in the CPS can be implemented in an .inf file. Although it is not always necessary to implement an .inf file, the file may be necessary in some circumstances. One use of such a file is the management of the location for the CRL publication and the location of an accessible copy of the CA certificate. The capolicy.inf file is used for this purpose for the Windows CA. The CPS should include

CA name, server name, and DNS address

Certificate policies

Certificate types

Policies, procedures, and process for certificate issuance, renewal, and recovery

Policies for CRLs, including CDP and publication schedule

Crypto algorithms, CSPs, and the key length of the CA certificate

Security for the CA

Certificate lifetime for each certificate issued by the CA

CA certificate renewal process

Certification Authorities

Four types of certification authorities can be installed as part of a Windows Server 2003 PKI:

Enterprise Root Certification Authority
The first server in a CA hierarchy and also one that is integrated with Active Directory. The root issues its own self-signed certificate.

Enterprise Subordinate Certification Authority
A server that is given its authority by a root CA. The root CA can either be enterprise or standalone. The keys are generated at the subordinate CA, but a CA above it in its hierarchy issues the subordinate CA certificate.

Standalone Root Certificate Authority
The first server in a CA hierarchy and one that is not integrated with Active Directory. The standalone root can be a parent to both enterprise and subordinate CAs.

Standalone Subordinate Certification Authority
A server that is given its authority by a root CA.

CA Hierarchy

Windows Server 2003 CAs can be implemented as part of a CA hierarchy. The top-most CA in a hierarchy is a root CA. In theory, any number of layers of CAs can be implemented, each with its own complement of CAs. In practice, a three-layer CA hierarchy appears to be the best application of the model. In the three-layer hierarchy, only the bottom or third layer issues end-use certificates, such as those for smart cards, IPSec, EFS, and so on. The top layer is the root CA, and the middle layer is composed of intermediary CAs. Technically, every CA can issue any type of certificate that its administrator has assigned. Best practices recommend that intermediary CAs and root CAs issue only CA certificates. Such a hierarchy is illustrated in Figure 12-10.

Cross-Certification and Qualified Subordination."

The depth in layers and the use of each CA in the hierarchy is dictated by the purpose for which they will be used. The intermediary layer is typically used to divide the management and distribution of CA processing to different geographic or organizational purposes. For example, as shown in Figure 12-11, an international organization might create a hierarchy with an intermediary CA at each of its major locations. In this case, Tailspin Toys has three major locations (Paris, Sydney, and New York), each with its own intermediary CA. By placing intermediary CAs at geographical points, the CA management can be localized, and redundancy is provided. It is also possible that fewer WAN enrollment and CRL requests may be needed, but there is no way to restrict enrollment and CRL download requests to the nearest CA. The use of an organizational model, as shown in Figure 12-12, may be due to the use of a distributed management model.

An additional mechanism used in a CA hierarchy is to use CA hierarchy level for certificate-specific CAs. This allows management by function. For example, as shown in Figure 12-13, each CA issues one type of certificate. One issues smart card certificates, another issues EFS certificates, and a third issues all others. In this figure, these CAs are in the second level of the hierarchy. It is common to find a CA hierarchy that combines geographical and organizational CA hierarchy models and the functional model, as shown in Figure 12-13.

Certificate Revocation List (CRL)

Certificates are revoked at the CA where they were issued. When a certificate is revoked, a reason for its revocation is selected. Possible reasons for revocation are as follows:

KeyCompromise

CACompromise

AffiliationChanged

Superceded

Cessationofoperations (ca)

CertificateHold

RemovefromCRL

Unspecified

Only the certificates revoked for the CertificateHold reason can be removed; in other words, certificates revoked using this purpose can be made valid again. (The certificate is removed from hold status. It is still listed in the CRL but is given the RemovefromCRL status.) After certificates are revoked, they are added to the CA's Certificate Revocation List (CRL), which is made available to users of the certificates. The Windows Server CRL is published according to a schedule configured at the CA and published to locations set within the CA CRL Distribution Point (CDP). Figure 12-14 shows the Extension Property page of the CA where CDP locations are recorded. The CRL publishing schedule is configured in the Revoked Certificates Properties, as shown in Figure 12-15.

Applications must be written and may sometimes need to be configured to work with CRLs. For example, computer certificates are used with IPSec for authentication. Certificate revocation checking is on by default, and a revoked certificate cannot be used. The process of certificate revocation checking can be turned off in order to implement the use of third-party certificates that may not provide the location of a CRL. If these third-party certificates are used and CRL checking is not turned off, the IPSec authentication will fail.

Delta CRLs

Several problems may be created because of the latency introduced by Active Directory and CRL processing. If a CRL must be retrieved from the Active Directory, the list must replicate from the domain controller on which it is originally published to all DCs in the domain. This may require that the time between the publishing of CRLs be set longer than desired. It also means that the availability of new CRLs will vary with the replication latency of Active Directory. In addition, if a client has a copy of a valid CRL in its cache, it will not download another CRL until the one it has is about to expire. This may mean that a revoked certificate is not invalidated but is accepted when it should not be. This means that even a manually published CRL that does not require AD replication to be available will not be used until the current CRL expires.

Delta CRLs can make newly revoked certificates available between CRL downloads. Windows Server 2003 CAs can be configured to issue delta CRLs. A delta CRL does not include revoked certificates previously published to the CRL. Instead, a delta CRL includes only those certificates revoked since the CRL was published. Only Windows XP and Windows Server 2003 clients can use delta CRLs. The use of delta CRLs will not interfere with the normal processing of CRLs in other OSs. These OSs will download the regular CRL and, when it is about to expire, will download the next CRL. The use of delta CRLs is configured in the Properties pages of the Revoked Certificates folder, as shown previously in Figure 12-15.

NOTE: OCSP Support

Support for Online Certificate Status Protocol (OCSP) is not provided by default but can be added by installing a revocation provider in CryptoAPI or by using a third-party OCSP responder that can communicate with the CA.

CA Roles

Another new feature of Windows Server 2003 CAs is the use and enforcement of role separation. The role separation model follows the separation of privileges security principle, which states that, wherever possible, critical and sensitive functions should be split so that no one individual has the power to steal or damage assets or otherwise cause harm to the organization. This principle has been implemented in manual processing for a long time. In accounting, for example, the accounts payable clerk may approve or even issue checks to vendors but cannot issue purchase orders. Purchasing clerks issue POs but have no authority to issue checks or approve them. In a completely manual system, this separation of duties is defined not only by policy and job description but also by management of the business forms used. Both purchase orders and checks are carefully controlled and restricted to use by the appropriate groups.

By default, Windows Server 2003 CAs can be administered by members of the local administrators group. If the CA is installed on a member server, members of the Domain Admins and Enterprise Admins groups may also be able to administer the CA. Most CA administration should be removed from the responsibilities of the operating system administrator and split by function. This allows for separation of duties and, in addition to following sound security principles, follows the standard specified by Common Criteria. Common Criteria is an international standard that seeks to define security standards by which security products can be evaluated. If a product is evaluated against the standard, purchasers can avoid extended testing of their own. They must only find a Protection profile (a specific definition for a specific purpose) and then select from among the products that have been evaluated against the standard. Windows 2000, for example, was evaluated and received EAL4 certification in October 2002.

NOTE: Common Criteria

For more information on Common Criteria, read the article "Windows 2000 and Common Criteria" at http://mcpmag.com/backissues/columns/article.asp?EditorialsID=521, and visit the Common Criteria web site at www.commoncriteria.org.

The Common Criteria PKI roles are defined in Table 12-3, along with the equivalent Windows Server 2003 roles.

The two new roles, CA Administrator and Certificate Manager, are implemented by giving two custom Windows groups Issue and Manage Certificates or Manage CA permissions on the CA object and then adding members to the group. The Administrators group has both of these permissions by default, as shown in Figure 12-16. Common Criteria also recommendsand requires, depending on evaluation levelthe ability to enforce role separation. That is, if a user is given the ability to perform the duties of two roles, technical controls prevent them from doing the duties assigned to either. For example, if you were to enforce role separation in Windows Server 2003 by implementing the groups CA Administrator and Certificate Manager and giving them the appropriate permissions, if you were to place the user John Doe in both groups, John would not be able to perform either function.

In addition to administration roles, three other unique certificate services roles exist:

Certificate holder or enrollee
Has the Read and Enroll permissions on a certificate template. They have the right to request, be issued, and use the certificates issued to them using templates that they have Enroll permission on. (If they do not have Enroll permission on a template, they cannot be issued the template. If the certificate must be manually approved, they might not be issued the certificate.)

Enrollment agent
Can obtain certificates on behalf of another user. The user must have Read and Enroll permission on the template. An example of an enrollment agent is the smart card.

Recovery agent
Has the ability to recover EFS encrypted files.

Another benefit of implementing role separation is that when role separation is enforced, the members of the local Administrators group no longer have the ability to administer the CA. (They retain the ability to back up and restore CA keys.) Until you assign members to the new administrative groups, no one will be able to manage the CA. In addition, if the administrator is a member of both CA administrative groups, she will not be able to administer the CA because of role separation. In fact, a common mistake is to make the local Administrator account the only member of both groups and then enforce role separation. The result is that the administrator must first disable role separation, remove the Administrator account, and then properly define membership in these groups.

In spite of the ability to provide and enforce role separation, if administrators are not trustworthy, the benefits of role separation can be removed. A rogue administrator could, for example, establish fake user accounts and assign each one to only one of the important CA administration roles. He then could log on as one and then the other using runas, or log off and then back on again using different accounts, and thereby gain full control of the CA. As in any security process, audit of activity on the CA should be required, and someone who is not an administrator on the system should independently review audit records.