Planning Your SMIME Encryption Infrastructure


Planning Your S/MIME Encryption Infrastructure

Overall, the PKI adoption rate for a secure messaging infrastructure has been limited for a few reasons:

  • PKI technology and components have been expensive and hard to manage.

  • Enrollment and life-cycle management have been cumbersome or difficult.

  • Enabling signed and encrypted mail in an organization has been difficult at best.

Microsoft has made significant progress in reducing the difficulty and expense of deploying a PKI; an IT professional can build a complete PKI with as little as a Windows 2000 server and an Exchange 2000 server combined with a Microsoft Outlook 2000 client. A more sophisticated organization can deploy a fully managed PKI solution with a robust messaging infrastructure with Windows Server 2003, Exchange Server 2003, and Outlook 2003. With Microsoft Windows XP clients and Windows Server 2003, a complete PKI infrastructure can be planned, deployed, and managed in as little as a few hours. For more information, see the Certificate Autoenrollment in Windows Server 2003 white paper at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/plan/autoenro.asp . However, different organizational requirements might dictate a different PKI configuration and therefore some up-front planning is often prudent in advance of deploying a secure messaging infrastructure.

Detailing Your Specific PKI Goals

The first step in planning and executing a successful PKI is defining your application requirements and business goals for the PKI. This step of the process generally involves answering some simple questions:

  • What do you want to use certificates for: encryption, authentication, nonrepudiation, or all of these? Do you want to provide other PKI-based services like smart card logon, secure Web services, or encrypted files, or are you only securing e-mail?

  • Who will administer the PKI, and do you need to delegate management?

  • How will users request and manage their certificates?

  • Will certificates be used only to secure internal traffic, or will they be used to establish trust and communicate securely outside of the organization?

As with any complex technology, you have to look at the big PKI picture and the higher level organizational goals before you begin the design phase. In this book, our primary focus is on protecting messaging systems, but digital certificates can be used for many other purposes, including access control for users and Web sites, IP Security (IPSec), and Institute of Electrical and Electronics Engineers (IEEE) 802.1x wireless authentication. There might already be projects (or at least efforts) within your organization that use, or will need to use, digital certificates. Accordingly, you should spend some time researching existing PKI deployment, particularly whether you already have any existing CAs or relationships with external CAs. For more information on PKI planning, refer to the Designing a Public Key Infrastructure chapter of the Windows Server 2003 Deployment Kit at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/deployguide/DSSCH_PKI_OVERVIEW.asp .

Choosing Certificate Usage

One important step in the planning process is figuring out what certificate purposes you want to enable in your organization. The CA-signed portion of a certificate includes a set of flags (known as the extended key usage extension in the certificate) that indicate for what purposes the certificate can be used. Windows 2000 and later versions support a broad set of purpose flags, including flags that allow certificates to be used for the following:

  • Message and document encryption S/MIME encryption works as described in Chapter 2: the sender s computer generates a random session key, uses it to encrypt the message with a symmetric algorithm, then encrypts the session key using the recipient s public key. Some organizations don t want their users to be able to encrypt mail, hence the existence of this flag.

  • Message and document digital signatures S/MIME signatures also work as described in Chapter 2: the sender computes a message hash and encrypts it with his or her private key, so that anyone with his or her certificate (which, as you recall, contains his or her public key) can independently recompute and verify the hash.

  • Smart card logon Windows 2000 and Windows XP come with built-in support for smart card authentication. Using PKI, a small credit-card- sized device can be associated with a user s certificate. The card and associated personal identification number (PIN) code or password can then be used instead of a logon name and password to gain access to the network. A smart card can be inserted into a smart card reader to sign a message, log onto a workstation with a domain account, or even gain access from a remote or wireless device. In general, Exchange and Outlook can use smart cards anywhere they would use a regular certificate.

  • Software code signing Authenticode is a digital signature process that instructs Microsoft clients to examine the publisher of ActiveX, Java, and other active content before installation. Security settings can (and should) be applied so that only known and trusted publishers can be installed on systems. By signing the active content that your company makes, you can ensure that your active content is installed on desktops without user intervention. Normally you wouldn t use end-user certificates for this; instead, you d have a special CA certificate for code signing.

  • Internet server and client authentication When establishing a Secure Sockets Layer (SSL) connection with a server, it is important to have a guarantee that the server that responds to your Hypertext Transfer Protocol (HTTP) request is the right server. For example, most online commerce sites use SSL to allow customers to verify that they re really talking to the company s server and not to some interloper. In other cases, it might be important for the server to verify the client s identity before a secured connection is established. In these cases, certificates must be provided by the client machines for inspection.

  • IPSec As you learned in Chapter 11, Securing Internet Communications, IPSec doesn t require PKI, but it can leverage certificates to make the network more secure. In non-Kerberos environments, the two devices would use a preshared key to encrypt and decrypt the communications. However, a more secure alternative is to use Kerberos authentication with machine certificates for authentication; once authenticated, the two ends can complete an Internet Key Exchange (IKE) exchange to generate a managed asymmetrical key. This process reduces the chance that the secret key will become compromised, along with providing a better guarantee that each station is authentic .

    Tip  

    Microsoft Office XP and later versions include tools for digitally signing and encrypting Microsoft Word, PowerPoint, and Excel documents, completely independent of whether or not you re using S/MIME.

Management Requirements

The next step in planning for a PKI is to determine your management requirements. These have an impact on the number, type, and location of your CAs. Do you need to delegate CA administration or certificate issuance to other departments or divisions, or will a central team manage your certificates? Do you wish to allow users to request their own certificates, or will some other entity handle that? Who will decide which other organizations CAs you trust? For more information on how a CA can be managed and the roles that can be configured, see the Windows Server 2003 PKI Operations Guide at http://www.microsoft.com/technet/ prodtechnol/windowsserver2003/maintain/ operate /ws03pkog.asp.

Cross-Certification or Public Hierarchy?

Probably the most important question you need to ask is whether the certificates will be used for intracompany or intercompany purposes. More specifically , will you need to send encrypted messages, sign code, or publish servers on the Internet to people who do not belong to your company? The answer to this question will likely have the biggest financial impact on your design. If you want to communicate between organizations, you will have to make a decision on whether to establish your PKI beneath a public root CA or whether you will establish individual trust relationships with other organizations directly. There are no hard rules about which method is better, but in general, if you define very few trust relationships with external partners , cross-certification is a more cost-effective choice for deployment. Cross-certification is a rich method of establishing trust with another organization through the use of X.509 certificates and constraints to limit the trust to specific purposes and entities. For more information on the scenarios and use of cross-certification, refer to the Windows Server 2003 Qualified Subordination white paper at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/plan/ws03qswp.asp .

Designing Your CA Infrastructure

A PKI has to be planned and designed if you want to provide good security, manageability, and usability. Accordingly, you need to carefully design the CA infrastructure to reflect your current and future needs, budget, and security requirements. The first major CA infrastructure decision you must make is whether to outsource the PKI to a third party, build your own internal PKI, or do a little of both. Let s go over the options.

Outsourcing Your PKI

One solution to the difficulties of PKI design and deployment is to make it someone else s problem by outsourcing your PKI. Creating and maintaining an internal CA will add administrative overhead and in most cases additional server equipment. Some training will be required to bring the administrators up to speed with maintaining the certificates and the CA servers. Moreover, your internal CA will not automatically be trusted by other companies or Internet users; specific relationships must be established with the CAs from partners, customers, and others. In addition, client settings might need to be tweaked to establish a relationship with those divisions, partners, and companies so that your internal certificates can be used. There are other reasons why you might want to consider outsourcing your PKI environment, including the following:

  • The outsourced PKI will be managed by people who are trained in PKI. Your administrators will not need to become experts on the design aspect, as the outsourcing vendor will assist with testing and implementation.

  • The experience and guarantees offered by external CAs should provide a stable, secure, and legal environment. Your company will not need to understand the legal implications of running a PKI, although you should review your chosen CA s standards and practices very carefully and should always have access to PKI experts.

  • An outsourced solution can be implemented on short notice because you don t have to deploy any hardware or software. You might consider outsourcing while your internal PKI project builds an internal infrastructure.

  • An outsourced solution might be willing to accept liability for transactions that are fraudulently performed using digital certificates. Often when financial transactions are performed using digital certificates, the subscribing party must accept liability for the issuance and usage of the certificates.

There are several choices for outsourcing PKI depending on your needs and budget. VeriSign, Geotrust, RSA, Entrust, and Thawte are some of the most popular. These companies offer outsourcing, and some support mixed environments that allow you to bring some management and distribution tasks in-house.

Building Your Own PKI with Windows Certificate Services

Although outsourcing seems like an ideal way to get a PKI s benefits without any hassle, there are several drawbacks to outsourcing. First and foremost, it can be extremely expensive. Most PKI vendors charge a setup fee, plus a separate charge for each block of certificates. Because certificates expire, most PKI outsourcing companies sell only multiyear contracts, and many require a maintenance fee on top of everything else. It is not uncommon for a company that needs 1000 certificates to spend more than $50,000 per year, plus management and setup fees, to outsource its PKI. Many organizations see this cost as prohibitive, and Microsoft is trying to exploit that by bundling its own robust PKI tools with Windows. Self-built PKIs are becoming increasingly popular for a variety of reasons:

  • By implementing your own PKI infrastructure, your company can control the security levels you need to use for your environment. You can choose the length of your users keys, the validity period of their certificates, the revocation policy, and other security practices that you might not have control of with an outsourced solution.

  • To provide smart card logon, you must publish your users certificates in Active Directory so that user accounts are tied to specific certificates. The easiest way to do this is to use Windows 2000 Server or Windows Server 2003 Certificate Services. More generally, internal Windows CAs can be leveraged for all of the purposes described earlier ”the CA publishes the certificates in Active Directory so they can be used by other Active Directory “aware services and applications.

  • Windows 2000 Server and Windows Server 2003 environments support automated enrollment and management of certificates. For example, Windows 2000 workstations can automatically enroll for machine certificates; with Windows XP clients and Windows Server 2003 CAs, you can choose to automatically issue, renew, and manage user certificates as well.

  • Integrating Active Directory with a PKI gives you some very nice management features: easy use of certificates for messaging, automatic enrollment, automatic or manual certificate approval, full replication of certificate revocation lists (CRLs) and certificate trust lists (CTLs), and management using the familiar Microsoft Management Console (MMC).

The cost advantage is pretty compelling, too. The CA is included with the Windows Server product family; there are no per-user, per-certificate, or time-based fees. Moreover, hardware requirements for Windows Certificate Services are minimal, so existing equipment could be used to host the stores and CA services.

Note  

For the remainder of this chapter, I m going to assume that you ve chosen to build your own internal PKI environment. If you re outsourcing, your PKI provider will have its own design process, which you might better understand by reviewing the following material. However, the majority of Exchange sites will probably be better off with their own internally managed PKI, so that s what I focus on.

Designing a Hierarchy

If you already understand the way Active Directory separates items into hierarchies (the forest contains one or more trees; each tree contains one or more domains, and so forth), the relationships used by PKIs will seem very natural. Objects within Active Directory are identified by their containers; the X.509 PKI standard, which Windows 2000 Server, Windows Server 2003, Exchange 2000 Server, and Exchange Server 2003 implement, uses a similar scheme for naming objects using a hierarchy of components.

The certificate hierarchy begins with a root CA. Like every other CA, the root is responsible for issuing certificates to subordinate entities; however, the root CA normally issues certificates only to other subordinate CAs . The subordinate CAs issue certificates to end users and computers. When an application needs to verify a certificate s authenticity, it can verify the signature on the certificate, then on the issuing CA, then on that CA s parent CA, and so forth, up to the root, as shown in Figure 12-1.

When you create the first CA in your organization, it might or might not have a root. If you re building a hybrid PKI using an outside root, then your root s certificate request will go to the third party, which will issue your CA s certificate. If you re building a purely internal PKI, your CA will have to sign its own certificate ” there s no parent CA to do so. This self-signed certificate contains the identity of your company, the name of the CA server, its unique public key, and some additional attributes. As you add subordinate CAs, each one generates its own key pair and uses it to request a certificate from your root CA. When a subordinate CA issues certificates, the entire line or hierarchy is published within the certificate.

click to expand
Figure 12-1: A hierarchy is possible with just two entries. Your hierarchy begins when you bring up the first CA, which becomes the root for your hierarchy.

When the root CA issues certificates to child CAs, this process establishes a trust relationship between the CAs, similar to that within an Active Directory forest. If this subordinate CA is used to issue certificates to end entities, it is usually referred to as an issuing CA . However if the subordinate CA is used to parent additional child CAs, it is referred to as an intermediate CA . This distinction is important because you will need to manually apply settings to individual child CAs to control whether they act as issuing or intermediate CAs.

Ultimately, there is no one correct hierarchy design for all users. Designing your certificate hierarchy is often based on several key technical factors that can be used as inputs in your decision tree. The number of CAs and the hierarchy design can usually be determined by asking and answering the following questions:

  • The size and the distribution of the organization over geographical boundaries

  • Business processes and user provisioning requirements

  • The required trust relationship between end users and the CAs

  • Requirements for different certificate policies or security practices

  • Application and compatibility requirements

  • Partner relationships and trust model requirements

  • Security requirements, availability targets, and service level agreements

Stand-Alone Versus Enterprise CAs

Before you can begin installing and configuring Certificate Services, there are a few more decisions to make. One of the first choices you need to make during the installation process is what kind of CA you need to establish. The Windows Certificate Services package can operate in two modes:

  • In stand-alone mode, the CA does not integrate with Active Directory for security validation, certificate publishing, or certificate templates. It is often used as a root or offline CA where a high security process is required by the organization through administrative and human processes.

  • In enterprise mode, the CA issues certificates and publishes them (along with CRLs and CTLs) in Active Directory based on user accounts and certificate template policies also stored in Active Directory. An enterprise CA running Windows 2000 Server or Windows Server 2003 can support Exchange 2000 KMS and certificate templates. Only enterprise CAs support key archival and auto-enrollment functionality.

In both Windows 2000 Server and Windows Server 2003, the simplest and most functional way to deploy a PKI, with or without Exchange KMS, is to deploy an enterprise CA. If you are using Exchange 2000 Server or Exchange Server 2003, you already have Active Directory deployed; the next logical step is to install an integrated enterprise CA for PKI functionality. A Windows Server 2003 enterprise root CA is simple to set up and uninstall in a pilot environment and easily integrates with Exchange KMS, which is explained later in this chapter. Some of the additional reasons for choosing a Windows Server 2003 enterprise CA over a stand-alone CA are as follows :

  • Most of the advanced PKI management features such as auto-enrollment, certificate templates, automatic request approval, key archival, and policy enforcement require the enterprise CA.

  • In enterprise mode, you can use Active Directory group policies and security permissions to control elements of the organizational PKI behavior. For example, you can assign certificate templates to computers based on Group Policy; the ability to manage several management functions can be granted based on security groups or placement in Active Directory. You can also assign key usage policies and CTLs using Group Policy.

  • With an enterprise CA, your CRL can be published in Active Directory. This is an important functionality because clients and applications need access to the CRL to determine if a particular certificate has been revoked . The redundancy and reliability built into Active Directory makes it much easier for clients to get the current CRL on demand.

  • Smart card logon functionality requires that user certificates be based on accounts and CAs in Active Directory. The easiest way to support integrated enrollment is through an enterprise CA.

Further information regarding certificate hierarchy design and choosing the appropriate CA type can be found in the Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure white paper at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/maintain/operate/ws3pkibp.asp .

start sidebar
Protecting the Root CA

The root CA is the foundation of your entire PKI. If its private key is compromised or lost, the entire PKI becomes essentially worthless because the compromised private key can be maliciously used to issue or revoke certificates or even change trust relationships at will. When a root CA is compromised, a new CA will have to be created and all previously issued certificates will have to be reissued under a new root CA. For this reason, the recommended best practice is to keep your root CA offline except when you re actually using it. However, this introduces an extra challenge: only stand-alone CAs can be kept functionally offline. The best way to accomplish this is to create a stand-alone root CA on a Windows Server 2003 in a workgroup with no network access, then lock it in a secure area. Keep this server disconnected from the network unless specifically needed. Use the root to issue certificates for one or more enterprise subordinate CAs, which can either be intermediate or issuing CAs. Putting the server in a workgroup eliminates any problem with domain account synchronization, and prevents a domain compromise from allowing an attacker access to the root.

If possible, keep your intermediate CAs disconnected from the network as well. However, to process any pending requests for subordinate CAs and to generate CRLs from the root, the root or intermediate CA must be online. For these reasons, in addition to disaster recovery planning and awareness, it is good practice to create a procedure where the root and intermediate servers are brought online at regular intervals for maintenance and normal change control procedures.

end sidebar
 
How Many CAs Should You Have?

Depending on who you ask about hierarchy design, you ll hear a wide range of answers to this question. In keeping with the keep it simple, stupid mantra that all administrators learn early on, let s begin with the simplest possible configuration: a single CA that acts as root and issuer. Why might you want to add more subordinate issuing or intermediate CAs? Here are some of the reasons:

  • You want to be able to take the root CA offline. The root can generate CRLs only when it s online. Likewise, an offline root can t receive online certificate requests. If you only have one root or issuing CA, you have to leave it online all the time, which provides very limited security options. Adding a subordinate issuing CA beneath your root allows you to leave the root off and have the subordinate issuing CA provide end-entity issuing and revocation services.

  • You need to provide fault tolerance for your PKI environment. Depending on your network connections, number of potential requests, and overall redundancy requirements, one CA might not be enough. Exchange is robust enough to handle multiple KMS servers in an organization, and Windows doesn t impose any restriction on how many CAs can be in a hierarchy (or an Active Directory forest, for that matter).

  • Your administrative model requires segregated administration. Perhaps you have different divisions that require specific certificates to be issued. It could be your administrative teams are located in a different division or they might be outsourced. In these cases, you ll need multiple CAs to adequately delegate the administrative responsibilities of your PKI. This is especially true if you plan to have CA servers provide specific CAs; for example some companies configure one CA for external certificates and a separate server for internal certificates.

If you need to have different standards, algorithms, hardware types, key lengths, or directories, you ll be forced to add extra CAs. Once you install a root CA, you cannot change the key length and algorithms you ve chosen for its certificate; these settings apply to all the keys used by that particular CA. If you need two different types or maximum lengths of keys for application or vendor compatibility, you need to install more than one CA.

Some More Exotic Hierarchies

There s no single correct PKI hierarchy. Fortunately, though, there are a few basic designs that can be adapted to meet the needs of most organizations:

  • Offline root with multiple issuing CAs Assuming that you plan to provide certificates for external users (partners, vendors, customers) and internal users, it s common to use three CAs: a stand-alone root that is taken offline with two subordinate issuing CAs. One of the issuing CAs issues certificates for internal users; the other issues certificates for external users.

  • Offline root with a trusted hierarchy This design is similar to the three- server approach just mentioned, but the subordinate CAs don t issue certificates to the users. Instead, they become intermediate CAs, with another layer of issuing CAs beneath. This might seem like an unnecessary complication, but separating the intermediate and issuing CAs in this manner allows you to distribute certificate issuance across business units, divisions, or geographical regions . The root and intermediate CAs can be controlled by the IT or security organization, with certificate issuance pushed out to a lower level. Because this design is both scalable and flexible, it works well in most environments. It easily accommodates geographical (network) and policy (administrative) boundaries, while maintaining a single company-wide CA structure. Moreover, because trust relationships with external CAs happen at the root level, this design works well during an acquisition, merger, partnership, or cross- certification; the root can make a single trust for the entire company.

  • Cross-certification hierarchy Depending on the administrative and political model in your organization, it might be difficult to establish a single root CA. Perhaps you recently merged with other companies that have existing PKIs, where collapsing one environment into the other would not be a simple weekend task, or perhaps you need to communicate with outside organizations with whom you do not have a common root. In the cross- certification hierarchy model, your root CA establishes a cross-certificate to one or more external CAs. This type of trust establishes a full or one-way hierarchy similar to that of the root “subordinate relationship. If each organization issues a cross-certificate to the other, then the trust becomes bidirectional and the two are considered peers. Although this design is very flexible, it is not as scalable as the trusted hierarchy model: each outside root has to have its own cross- certificate trust, and managing these trusts can become complicated.

Working with Trusts and Cross-Certification

Within a certificate hierarchy, each new CA added to the environment trusts the root and the child CAs subordinate to it. All trusts are automatic and built in to the hierarchy and certificate path . In a network hierarchy or cross-certification model, external trusts are established, often with constraints or restrictions. These trusts are used to establish organizational relationships between CAs with different roots, and the trusts are not necessarily reflected in the certificate paths of issued certificates.

Just as the name implies, a CTL identifies other trusted CAs and certificates that are external to your root CA. Windows 2000 Server and earlier operating systems allows for each client to establish its own trust list. In fact, if you open Microsoft Internet Explorer and select Tools Internet Options from the menu, then click the Content tab, you will find the Certificates button. Clicking Certificates displays the existing trusts contained in your local CTL. To add a trust to the CTL, you must add an entry to this list. This is normally done by clicking Yes on a warning screen when presented with a certificate that is not trusted. In Windows XP and later operating systems, this was deprecated in favor of the Trusted People store of the user profile.

Now, because certificates are not validated or accepted by applications unless the hierarchy is fully trusted by the platform, the user also needs to install a copy of the root CA certificate, and then explicitly trust it. By having this certificate, the trust can be consummated and certificates from that authority can be used. A root CA certificate can be explicitly trusted or it can be added as an entry in the user s CTL. This manual procedure sounds easy enough if you are running a small network with just a few machines, but if you are in charge of a larger environment, or if you don t want users making their own, perhaps ill-informed, choices about whom to trust, you need a way to make these changes company-wide or department-wide. Using Group Policy in Windows 2000 Server or later, the administrator can deploy a CTL that contains a signed list of root CA certificates. This CTL can automatically be applied to clients, which cannot override the CTL by adding or removing external roots. An administrator can also add trusted roots and cross-certificates directly to the forest in Windows Server 2003 using command-line tools without deploying a CTL on a per-domain basis. For more information about cross-certification and scenarios, refer to the Windows Server 2003 Qualified Subordination white paper at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/plan/ws03qswp.asp .

Issuing Digital Certificates

Once you ve designed a hierarchy that meets your organizational, application, security, and trust requirements, it s time to select the type, number, and capability of certificates that you want to issue. Ideally, an organization should issue no more than three certificates for a given user: authentication, digital signature/nonrepudiation, and encryption. Some organizations might be able to use only one certificate depending on the application and security requirements. There are several issues to consider before issuing digital certificates to users and machines.

Key Length and Complexity

The Windows CryptoAPI supports RSA algorithm key lengths ranging from a mere 384 bits to a whopping 16,384 bits. However, the cryptographic service provider (CSP) you use to actually generate the key is what determines the maximum size and characteristics. For example, the Microsoft base CSP that comes with Windows supports RSA key lengths of 384 to 16,384 bits, but the Digital Signature Algorithm (DSA) provider in the same CSP supports only 512- and 1024-bit length keys. For most uses, 1024-bit keys are adequate; however, within the same algorithm (remember the work factor), longer keys are more secure because they are harder to break.

Using a larger key size can potentially give your certificates a longer lifetime because certificate lifetime is tied to growth in available computing power. Processing power becomes less expensive over time, and as years pass, it will take less time for a certificate of a given length to be broken using brute force methods . A shorter key might be sufficiently difficult to break using today s computing power, but might not meet your organization s security requirements when matched against a malicious attacker s computer 10 years from now.

Longer keys have other implications, too; they affect the size of the key store and performance (for the server, during key generation; for the client, during encryption and decryption). You should document a standard for issuing certificates and identify any requirements for key length. It is perfectly acceptable and expected that you will choose a different key length depending on the type of certificate required. Longer keys should be used for certificates that need a longer lifetime and more security. For example, because the root CA certificate is very valuable, trusted for a long period of time, and rekeying it frequently would be a hassle, root CA certificates are often 4096 bits long. Subordinate CAs, which are proportionally less valuable and valid for a shorter lifetime, are then configured to use 2048-bit keys, with user and machine certificates typically having 1024-bit keys. These key lengths are adequate for the foreseeable future, but if your company has identified more stringent security requirements, you might elect to use longer keys as appropriate to counter organizational security threats. Figure 12-2 summarizes these considerations.

click to expand
Figure 12-2: Longer keys are used when additional security is needed. These longer certificates can also have a longer lifetime or validity period because the keys are harder to break.

Choosing a Certificate Lifetime

Certificates are not designed to be eternal. In fact, they are designed to expire after a certain interval, known as the validity period , has passed. To facilitate this, PKIs are designed with specific renewal procedures and limits that are set by the CA. Although possessing a digital certificate might allow for the encryption and signing of messages, the certificate is only as secure as the policies that control its access and use. For example, if someone has been terminated from your company and revocation procedures are lax or nonexistent, that person could continue to sign messages as if he or she still belongs to the company. Worse still, if the certificate never gets revoked, the person can continue to pose as an employee until the certificate expires at the end of its validity period. In addition, given enough time, every key can be broken. By renewing certificates with new key pairs on a scheduled basis, you can mitigate the risk of compromise for your certificates. Accordingly, you should keep the validity period of your certificates fairly short, and when renewing certificates you ll need to periodically regenerate new keys (a process known as rekeying ) instead of automatic renewal of old key pairs.

To determine the appropriate validity periods for your certificates, you must first determine your particular security requirements; specifically, how much do you trust your environment? Let s say that your company uses a large number of temporary employees. Because turnover in these positions is high, you should probably assign certificates with shorter life spans to those employees . A shorter lifetime means that the certificates expire more frequently; because the renewal process requires administrative or policy approval, this gives you more control over the active certificates in your environments. There are a couple of other factors to consider in determining the appropriate lifetime for your certificate key pairs. For example, a longer key takes longer to break and thus can live longer than shorter keys. Also, keys that are kept on hardware tokens or smart cards can live longer, as these keys are much more difficult to access or compromise. Limited space on a smart card might also dictate that a validity period be matched with the expected physical lifetime of the token or smart card.

The advantage of a longer lifetime is obvious: less administration is required. The less often an administrator needs to renew or reassign key pairs to the user community, the less time it takes to manage the PKI environment. A lifetime that is too short can add tremendous burden to the support infrastructure and a lifetime that is too long can compromise security. In general, user intervention and frequent enrollment and renewal processes will generate additional support costs and operational downtime; this should always be balanced with the security requirements of the organization. Just as there are general guidelines for key lengths, there are general practices for certificate life spans. Most organizations choose a 1- to 3-year life span for end user certificates, with a 3- to 5-year lifetime for issuing CAs and a 10- to 20-year lifetime for offline and root CAs.

Certificate Renewal

When the lifetime expires on a certificate, it must be renewed to remain trusted and usable. The renewal process follows the same procedures as certificate enrollment; you can utilize auto-enrollment features of the platform or a user- initialized process. In either event, it is up to the administrator to determine whether the certificate should use a new key in addition to renewal. When the certificate is renewed or reissued, the validity period and attributes are updated before the new certificate is signed. Simple renewal uses the existing key pair, but it can also use a new key if required by an administrator.

For server keys, a new key pair should be created at the same frequency as the lifetime for the certificate. In other words, a 5-year root CA certificate should be issued a new key pair at least once every 5 years. The reasons for this are clear when you consider the importance of the CA certificates and the risk associated with a break of these very important keys. On the other hand, user certificates are often rekeyed at twice the frequency of their lifetimes, so a user certificate that is good for 2 years could be renewed once using the same keys, then 2 years later the certificate could be rekeyed when it s renewed.

Protecting the Private Key

If you lose control of your private key, either because you lose access to it or because someone guesses, steals, or ferrets out the password that protects it, you re in trouble: that person can impersonate you with impunity. As bad as this is for you, it s much worse if the private key in question belongs to one of your CAs. The attacker can then generate legitimate certificates for anyone he or she wants to. This pretty much negates the whole point behind using PKIs in the first place, so you want to prevent this from happening wherever possible.

By default, storage of certificates is handled by the certificate server and the client machine. Lax server or workstation protection mechanisms can put the integrity of your security plan at risk. In addition, mobility can create problems for PKI environments because users might need to gain access to their private certificates from other workstations or devices. Although increasing the complexity and length of keys can help mitigate some of the risks associated with key security, it does not address key mobility or access.

Windows supports several software CSPs by default, but it also supports the addition of third-party hardware CSPs. A hardware CSP can provide any number of advanced security options that cannot be realized with software keys. Hardware random number generation, hardware-assisted key generation, key archive and recovery, acceleration of cryptographic operations, and hardware-secured key storage are some of the possibilities when hardware solutions are added to your PKI design.

There are many options available for hardware-assisted PKIs. These options range from software keys stored on tokens or smart cards to hardware CSPs that help offload cryptography processes and, not incidentally, provide hardware-secured storage for the private key. These solutions come in several varieties:

  • Smart cards such as Gemplus, Schlumberger, and Infineon allow you to store one or more certificates (along with their associated private keys) in a small, secure device that users can carry from place to place. Because smart cards are mobile, they can be used for multiple applications. For example, Microsoft has deployed smart cards to employees, and they can be used for secure e-mail, remote access, and buying meals in the corporate cafeterias. You might consider the use of smart cards for the entire population, or just for security-sensitive users such as administrators and executives. Using Active Directory account policies, you can require that certain accounts use a smart card for domain logon.

  • Hardware security modules (HSMs) such as nCipher and Chrysalis offer a range of hardware devices, including some that are validated to Federal Information Processing Standard (FIPS) 140-1 Level 2 or Level 3 specifications. Their units generate keys based on hardware random-number generation, and they support multiple sets of smart card “based hardware tokens and additional scalability and administrative tools. These devices are really only useful for CAs, not individual workstations. Microsoft has documented their use at http://www.microsoft.com/technet/security/prodtech/windows/windows2000/ncipher.asp and http://www.microsoft.com/windows2000/techinfo/planning/chrysalis.asp , respectively.

Understanding Enrollment

Before you can sign or encrypt your first message, you must first obtain a certificate. In the case of RM, you must first activate your machine and enroll for a publisher license. That raises the question of how you obtain the certificate in the first place. The term enrollment covers the process, from the initial generation of the asymmetric key pair to creation of a certificate request, all the way through installation of the issued certificate. Your enrollment options depend largely on the type of certificate services you re using. For example, had your company chosen an external CA, you would likely perform a manual enrollment through the Web browser. There are several ways a client, server, or workstation can become enrolled into the PKI environment, as follows:

  • By default, Certificate Services installs with Web enrollment support. This process requires that a user connect with a browser to the \Certsrv virtual directory on the CA to request a specific type of certificate. The request must then be accepted by the CA, optionally approved by the administrator, and processed after approval. This process is available on stand-alone and enterprise CAs.

  • Group Policy auto-enrollment is available with enterprise CAs. There are two separate policies that allow auto-enrollment: the Computer policy allows the automatic enrollment of servers and workstations in a domain, and the User policy enables Windows XP client workstations to automatically enroll user accounts in the Active Directory domain at user logon.

  • Exchange KMS can proxy enrollment requests for Outlook users through the version 1 Enrollment Agent (Computer) template and a Windows 2000 Server or Windows Server 2003 enterprise CA. The KMS server in this scenario acts as a registration authority on behalf of the users.

  • The Certificate Request Wizard and Certificate Renewal Wizard are both found in the Certificates MMC snap-in. Windows 2000, Windows XP, and Windows Server 2003 users can use this snap-in to request certificates from a Windows 2000 Server or Windows Server 2003 enterprise CA.

  • A smart card enrollment station is used to enroll smart card devices into the environment. An administrator uses this terminal to perform smart card certificate enrollment on behalf of other users. The smart card enrollment station requires Web enrollment support with an enterprise CA.

start sidebar
Why We Still Love the KMS

The need to secure messaging is not new. In fact, the original X.509 specification, ISO/IEC/ITU 9594-8, was first published in 1988. This original specification is often referred to as X.509 version 1 (or just X.509v1) and was supported in the very first version of Microsoft Exchange Server. Since then, the X.509 standards have evolved; currently, X.509v3 is the standard definition for certificate functionality. Exchange s KMS has evolved in parallel. With Exchange 4 and Exchange 5, the Windows operating system didn t include a CA. Accordingly, the Exchange KMS had to handle enrollment, management, storage, and revocation ”essentially every aspect of PKI for Exchange.

Before I continue talking about the KMS, though, let me explain why you care. In Exchange 5.5, the KMS was a required component that added a great deal of needed functionality to the (relatively primitive) Windows certificate authority code. In Exchange 4.0 and 5.0, there was no Windows CA, so the KMS had to do all the work. The Exchange 2000 KMS still performs some of those functions, but it is reliant on Windows 2000 Server or Windows Server 2003 Certificate Services for most of its functionality. The biggest fundamental change to the Exchange 2000 KMS compared to previous versions is that it now leverages an existing PKI environment instead of providing one.

With Exchange Server 2003, all mail- related PKI functionality is handled by the Windows CA, so there isn t an Exchange Server 2003 KMS. However, it s perfectly possible to use the Exchange 2000 KMS with Exchange Server 2003 servers, which is why I m talking about the KMS in what is ostensibly an Exchange Server 2003 book.

Whether you have a legacy Exchange KMS in place with X.509v1 certificates or a new Windows 2003 Certificate Services environment established, KMS augments the environment and provides additional management and support. Because KMS uses Active Directory, you must have an enterprise CA configured with the Enrollment Agent (Computer), Exchange Signature Only, and Exchange User certificate templates before KMS can be installed. The installation process inspects Active Directory during KMS installation to verify the configuration of the CA. After the installation, the Exchange management tools reflect the existence of the KMS. Within Exchange System Manager, a new node named Advanced Security appears under the administrative group; this is the tool that must be used to start KMS should the service stop because of a reboot or other unplanned event.

The primary purpose of KMS is to augment the existing enrollment and management functions with additional, Exchange-specific tools and services. When KMS is installed and configured, administrators will be able to take advantage of additional enrollment options. For example, once the KMS is present, you can use the E-Mail Security item on the Exchange Features tab of the user Properties dialog box in Active Directory Users And Computers, shown in Figure 12-3.

click to expand
Figure 12-3: The KMS administrator can edit the properties of this entry to enroll, recover, and revoke the e-mail certificate of the selected user.

Not only are the enrollment procedures enhanced, but additional features such as Key Recovery are enabled. This feature allows lost keys to be recovered and it also permits the use of older keys in addition to new ones when a user moves companies or if the entire organization goes through a rekeying process. In addition, Exchange users are able to renew their certificates over e-mail. This option, as well as the new enrollment options, are well suited for distributed networks or cases in which the user population consists primarily of remote users. Management of user certificates is distributed between the KMS administrator and the end users.

end sidebar
 

Understanding Revocation

At some point, you might need to terminate or revoke a valid certificate before its natural expiration date. If an employee has left the company, or you learn that a private key has been compromised, you should revoke those corresponding certificates and mark them as invalid. The X.509 and RFC 3280 standard specifies a process for this: the CA can generate a signed list of revoked certificates, known as a CRL. Each entry on the CRL contains the serial number of a certificate issued by that CA, along with a time stamp and a reason for revocation.

An enterprise CA, by default, stores the CRL in Active Directory using Lightweight Directory Access Protocol (LDAP); the Windows platform also allows the CRL to be retrieved over File Transfer Protocol (FTP), HTTP, or through a Server Message Block (SMB) file share. There s a specific X.509 certificate attribute that the CA populates (known as the CRL Distribution Point) to specify where that CA s CRL can be downloaded. To set the locations of your CRL in Windows Server 2003, open the Certification Authority MMC snap-in, view the CA server s Properties dialog box, and then click the Extensions tab. In Windows 2000 Server, click the Policy Module tab, click Configuration, then click the X.509 Extensions tab in the Properties dialog box.

Revocation List Policies

Before you can decide if the default revocation settings on the CA are appropriate, you need to make some business decisions about handling revoked certificates. For one, you need to determine and document the reasons why your company would revoke a certificate. Next, you need to decide the frequency for updating the CRL. In other words, if you revoke a certificate right now, how many hours or days should it take for the CRL to reflect the revoked certificate company-wide? Be careful when making this decision; the more often you issue CRL updates, the more frequently the CA has to be online, and the more replication traffic the CRL generates. More important, the more frequently a CRL is published, the more often a client workstation must download the CRL to check revocation before accepting a signed message as valid. Finally, we need to decide for how long each CRL should be valid. If the lifetime of the CRL is, say, three weeks, then it could take at least that long for a client to know that a given certificate has been revoked because clients do not collect a new CRL if the lifetime of a cached list is still valid.

Tip  

The Troubleshooting Certificate Status and Revocation white paper (see http://www.microsoft.com/technet/prodtechnol/WinXPPro/support/tshtcrl.asp ) also contains a terrific explanation of CRLs and revocation policy.

start sidebar
Integrating Smart Cards

Although smart cards seem to have little to do with encrypting or signing messages, they re a powerful technology that can add security and flexibility while simplifying your PKI administration. A smart card is an ISO 7816- standard circuit card (with or without small metal contacts) that can be used to store information. Some smart cards have fairly sophisticated cryptographic processing capabilities, whereas others are merely data storage units with some hardware tamper-resistance built in.

In a PKI environment, smart cards provide a way to create, distribute, and protect private keys in a tamper-resistant storage medium. Windows 2000, Windows XP, and Windows Server 2003 support smart cards through vendor- specific CSPs that link specific types of smart cards or cryptographic tokens to CryptoAPI (along with drivers for PC/SC compliant universal serial bus [USB], serial-port, or keyboard-port smart card readers). Microsoft Outlook needs no additional configuration to use or enable smart cards. Just insert the card into the reader and Outlook does the rest. The most valuable aspect of smart cards in a secure e-mail environment is the portability of the private keys and certificates, enabling a user to perform secure e-mail operations virtually anywhere. With Exchange Server 2003 and Outlook Web Access, a user can sign messages and decrypt mail from a machine running Windows 2000 or greater and the Internet Explorer 6.0 browser. This is a very powerful combination indeed.

For less than $50 (how much less depends on volume) you can purchase a card and reader that can be used for logon, network access, e-mail, and virtually any other instance where a user certificate needs to be presented for encryption or authentication purposes. When you install a compatible reader in Windows 2000 Server or later versions, it can immediately be used for logon to Active Directory; there are several Group Policy settings that allow you to control what happens when the smart card is inserted or removed (a favorite is to lock the workstation automatically any time the card is withdrawn).

To use smart cards productively, you ll need Active Directory and an enterprise CA. Enrollment of a smart card can be performed in one of three ways, depending on your security policy:

  • Windows XP user auto-enrollment with a Windows Server 2003 Enterprise Edition running as an enterprise CA. Users only need a blank smart card and logon to Active Directory to enable this scenario.

  • An administrator with the smart card enrollment station that is equipped with a smart card reader and writer. This is the most secure method for smart card deployment, but it is a manual process that requires users to visit an administrator to receive their smart cards.

  • Microsoft has published a smart card deployment cookbook ( http://www.microsoft.com/technet/security/prodtech/smrtcard/smrtcdcb/ ) that describes in detail how to set up smart cards, including specific information required to configure a CA environment and smart card enrollment station to support the devices.

    However, there are several twists to using smart cards that might degrade their advantages in your organization:

  • The Exchange 2000 KMS does not support them directly, because Exchange 2000 is hard-coded to use the Exchange CSP and not a smart card CSP. Users must enroll through smart cards using the certificate s MMC, Windows XP auto-enrollment, or the smart card enrollment station provided with Windows Certificate Services (being sure to specify that the smart card certificate can be used for S/MIME encryption and signing).

  • Most smart card CSPs currently do not support archival of the encryption private key. Although Windows Server 2003 enterprise CAs and KMS support this functionality, most smart card CSPs do not. This means if a user loses his or her smart card, they might not be able to decrypt any of their previously sent or received mail that was encrypted.

end sidebar
 

Server Performance Guidelines

If you think about how a certificate service functions, you will soon realize that the CA doesn t have all that much to do at any point in time ”its workload is quite low. Enrollment typically happens in small batches, and revocation lists are usually published once a day or once a week. Unless you are performing bulk import and revocation processes, you can run Microsoft Certificate Services on relatively small servers.

A Windows 2000 Server or Windows Server 2003 certificate server can support literally millions of certificates per physical CA. A fairly minimal dual-processor computer can issue more than a million certificates a day, which should suffice for most uses. To determine what size of CA server you need, you ll have to understand the disk space requirements for certificates of differing key lengths. Microsoft uses the familiar Jet (Blue) database engine (known as the Extensible Storage Engine) for the certificate stores, meaning that (just like Exchange) the CA will have an EDB file, transaction log files, and a database checkpoint file. Be sure to install these on separate physical disks, for both recoverability and optimum performance.

For planning purposes, we can assume that each certificate occupies about 32 KB of disk space on the certificate server (remember, the server has to keep copies of the issued certificates and requests). If you use key archival with a Windows Server 2003 CA, plan on doubling the disk space requirement. If you were planning on issuing a million certificates, you would need roughly 32 GB of space to hold the certificate files, plus extra space for transaction logs and the checkpoints. You would certainly want to protect the data against loss by using a Redundant Array of Independent Disks (RAID) configuration. This configuration will also increase the performance of your system.

Administration and redundancy requirements will probably dictate the need for multiple issuing CAs in several locations. In short, your performance requirements are likely to be low because multiple CAs are usually the best idea in most environments. Although older equipment will generally work quite well for your CAs, bear in mind that these are still production servers with important data, so they need to be as fault tolerant as your requirements and budget allow.




Secure Messaging with Microsoft Exchange Server 2003
Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)
ISBN: 0735619905
EAN: 2147483647
Year: 2004
Pages: 189

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