Planning and Designing a Public Key Infrastructure : Identifying PKI Requirements

After you assess the needs of your organization in this way, you can design the PKI as a means to enforce your organization’s security policies and to ensure that the new PKI remains aligned with the company’s business and IT strategy.

Reviewing PKI Concepts

A PKI refers to the set of technologies that enable an organization to use public key cryptography. In public key cryptography, a mathematically related key pair consisting of a public key and a private key is used in the encryption and decryption processes. If the public key is used for encryption, the private key is used for decryption. If the private key is used for encryption, the public key is used for decryption.

More specifically, a PKI is a system of digital certificates, CAs, and other registration authorities (RAs) that provides cryptographic keys for, and authenticates the validity of, each party involved in an electronic transaction.

A PKI consists of the following basic components:

• Digital certificates Electronic credentials that include a public key and that are used to sign and encrypt data. Digital certificates are the foundation of a PKI.

• One or more CAs Trusted entities or services that issue digital certificates. When multiple CAs are used, they are typically arranged in a carefully prescribed order and perform specialized tasks, such as issuing certificates to subordinate CAs or issuing certificates to users.

• Certificate policy and practice statements The two documents that outline how the CA and its certificates are to be used, the degree of trust that can be placed in these certificates, legal liabilities if the trust is broken, and so on.

• Certificate repositories A directory service or other location where certificates are stored and published. In a domain environment, Active Directory is the most likely publication point for certificates issued by Windows-based CAs.

• Certificate revocation lists (CRLs) Lists of certificates that have been revoked before reaching the scheduled expiration date.

Identifying PKI-Enabled Applications

Typically, an organization decides to deploy a PKI only when that organization introduces one or more applications that depend on a PKI. After the need for a PKI arises, you can begin to define the PKI in a way that best supports these applications.

The following list describes the most common applications and technologies that can lead an organization to consider deploying a PKI:

• 802.1x port-based authentication 802.1x authentication allows only authenticated users or computers to access either an 802.11 wireless network or a wired Ethernet network. A PKI is required to support 802.1x when the Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), Extensible Authentication Protocol-Tunneled Transport Layer Security (EAP-TTLS), or Protected Extensible Authentication Protocol (PEAP) authentication protocol is used.

• Digital signatures A PKI is used for digital signing. Digital signatures secure Internet transactions by providing a method for verifying who sent the data and that content was not modified in transit. Depending on how a certificate is issued, digital signatures also provide nonrepudiation. In other words, data signers cannot deny that they are the data senders because they are the only users with access to the certificate’s private key.

• Encrypting File System (EFS) EFS provides a confidentiality service to NTFS. It employs user key pairs to encrypt and decrypt files and recovery agent key pairs for file recovery purposes. Certificates used for EFS are available from enterprise CAs. In an environment with no Microsoft enterprise CAs, all EFS certificates are self-signed.

• Internet Protocol security Certificates can be used to authenticate the two endpoints in an Internet Protocol Security (IPsec) association. After authentication, IPsec can be used to encrypt and digitally sign all communications between the two endpoints. Certificates do not play a part in the actual encryption and signing of IPsec-protected data—they are used only to authenticate the two endpoints. Note also that in AD DS domains, Kerberos, not certificates, is typically used for authentication.

• Secure e-mail (S/MIME) Secure e-mail, the industry standard for which is Secure/Multipurpose Internet Mail Extensions (S/MIME), provides confidential communication, data integrity, and nonrepudiation for e-mail messages. S/MIME uses certificates to verify a sender’s digital identity, the message’s point of origin, and message authenticity. It also protects the confidentiality of messages by encrypting their content.

• Smart card logon Smart cards are credit card–sized cards that contain a user certificate. You can use smart cards to provide strong authentication for interactive logons.

• Code signing Code signing protects computers from installation of unauthorized controls, drivers, or applications. Applications that support code signing, such as Microsoft Internet Explorer, can be configured to prevent execution of unsigned controls.

• Virtual private networks (VPNs) VPNs allow remote users to connect to a private network by using tunneling protocols, such as Point-to-Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP), or Secure Socket Tunneling Protocol (SSTP). Not all VPN types use certificates. However, certificates increase the strength of user authentication and can provide authentication for IPsec if using L2TP with IPsec encryption.

• Web authentication and encryption Distributing Secure Sockets Layer (SSL) certificates to a Web server on either an intranet or the Internet allows a Web client to validate the Web server’s identity and encrypt all data sent to and from the Web server. All Web servers offering SSL connections require a server certificate, typically issued by a third-party CA. Optionally, SSL connections can also use client certificates (although this is rarely implemented).

Identifying Certificate Requirements

After you have determined which PKI-enabled applications your organization plans to deploy, you must determine who must acquire the certificates and the types of certificates that are required. Typically, certificates are deployed to the following subjects:

• Users A digital certificate uniquely identifies a user to a PKI-enabled application. A user can be assigned a single certificate that enables all applications or can receive application-specific certificates, such as an EFS encryption certificate that can be used for one purpose only. The certificates issued to the user are stored in the Current User certificate store.

• Computers A digital certificate uniquely identifies the computer when a user or computer connects to the computer where the certificate is installed. The certificate becomes the computer’s identifier and is stored in the Local Machine certificate store. If the Client Authentication object identifier (OID) is included in the certificate in either the Enhanced Key Usage (EKU) extension or the Application Policies extension, an application can use the computer certificate to initiate connections. If the Server Authentication OID is included in the certificate in the EKU or Application Policies extension, the certificate can be used to authenticate the computer’s identity when a client application connects.

• Network devices Several devices on a network allow the installation of certificates for client/server authentication. These devices include, but are not limited to, VPN appliances, firewalls, and routers. The actual process used to install a certificate on a network device is subject to the type of operating system and interfaces of the actual network device.

  Exam Tip

  Network device enrollment is a new feature offered by Windows Server 2008, and, therefore, you are likely to see a general question about it on the 70-647 exam. Network device enrollment relies on the Network Device Enrollment Service (NDES). This service is the Microsoft implementation of the Simple Certificate Enrollment Protocol (SCEP), a communication protocol that enables software running on network devices (such as routers and switches, which cannot otherwise be authenticated on the network) to enroll for X.509 certificates from a CA.

  
  

• Services Some services require computer certificates for either authentication or encryption. Certificates are not actually issued to a service. Instead, the service certificate is stored either on the Local Machine store or in the user’s profile of the associated service account. For example, if a certificate is installed for the World Wide Web (WWW) service of a Web server, the certificate is stored in the Local Machine store. However, the EFS recovery agent certificate for the EFS service is stored in the user profile of the designated EFS recovery agent.

  Note: Where should you install a certificate for a service?

  The easiest way to determine where to install a certificate for a service is to investigate what credentials the service uses to authenticate. If the service uses Local System, then the certificate must be stored in the Local Machine store. If the service uses a user account and password, then the certificate must be stored in that specific user’s profile.

  
  

Identifying Certificate Security Requirements

Certificate requirements are driven by the PKI-enabled applications your organization plans to use. Identifying these requirements will let you determine the properties of the certificates needed. For each set of certificates, you should identify the following security requirements:

• Length of the private key In a typical deployment, the length of private keys are nested so that each level in the PKI hierarchy has a key whose length is half that of the level above it. For example, in a PKI, issued user certificates might have 1024-bit keys, issuing CAs might have 2048-bit keys, and root CAs might have 4096-bit keys. Note that, because longer keys are harder to mathematically attack, they support proportionately longer lifetimes.

  
  
  In choosing a length for each CA in the CA hierarchy, the biggest restriction is the set of applications that will use the CA hierarchy for certificates. Some applications are known not to support keys larger than a certain value.

  Note: Which technologies limit private key length?

  Technologies known to have issues with CA certificates with key lengths greater than 2048 bits include Cisco VPN 3000 series appliances, Nortel Contivity devices, and some older Java applications.

  
  

• Cryptographic algorithms that are used with certificates The standard settings for certificates issued by a Windows Server 2008 CA can meet typical security needs. However, you might want to specify stronger security settings for certificates that are used by certain user groups. For example, you can specify longer private key lengths and shorter certificate lifetimes for certificates used to provide security for very valuable information. You can also specify the use of smart cards for private key storage to provide additional security.

• Lifetime of certificates and private keys and the renewal cycle A certificate has a predefined validity period that comprises a start date and time and an end date and time. You cannot change an issued certificate’s validity period after it has been issued. Certificate lifetimes are determined by the type of certificate, your security requirements, standard practices in your industry, and government regulations.

  Note: Certificate lifetimes

  When determining certificate lifetimes for a PKI, a good rule of thumb is to make the validity period of the certificate for a parent CA at least twice as long as the certificate for a subordinate CA. In addition, the validity period of the certificate for an issuing CA should be at least twice as long as the maximum validity period of any certificates issued by that same CA. For example, you might give issued user certificates a lifetime of 1 year, the certificate for the issuing CA a lifetime of 5 years, and the certificate for the root CA of the PKI a lifetime of 10 years.

  
  

• Special private key storage and management requirements An organization’s security policy can require specific security measures for a CA’s private key. For example, an organization might have to implement Federal Information Processing Standards (FIPS) 140-2 protection of the CA’s private key to meet industry or organizational security requirements.

Measures you can take to protect the CA’s private key include using a cryptographic software provider (CSP), which stores the CA’s private key material on the computer’s local hard disk; a smart card CSP, which stores the CA’s private key material on a smart card associated with a PIN; and a hardware security module (HSM), which provides the highest security for private keys in dedicated hardware devices.

Reviewing the Company Security Policy

After the need for a PKI is established and the required certificates are identified, you should review the organization’s security policy. A security policy is a document, created by members of an organization’s legal, human resources, and IT departments, that defines an organization’s security standards. The policy usually includes the assets an organization considers valuable, the potential threats to those assets, and, in general terms, the measures that must be taken to protect these assets.

The security policy should be updated to answer high-level PKI questions, such as:

In general, when planning and designing a PKI, it is essential to remember that a PKI should enforce your organization’s security policy. A PKI, after all, is only as secure as the policies and procedures that the organization implements.

Assessing Business Requirements

Business requirements define an organization’s goals. Business requirements affect the design of the PKI by allowing the PKI to enhance business goals and processes. For example, the following business requirements can affect a CA hierarchy design.

• Minimizing PKI-associated costs When reviewing CA hierarchy designs, you might have to choose a CA hierarchy that deploys the fewest CAs. For example, some organizations combine the roles of policy CAs and issuing CAs into a single CA in the hierarchy, deploying a two-tier hierarchy rather than a three-tier hierarchy.

• High availability of certificate issuance An organization can require that a CA be consistently available to ensure that no certificate requests fail due to a CA being down for any reason. To ensure that a CA is always available, you should implement clustering on the issuing CA that issues certificates based on the defined certificate template. If your up-time requirements are not as stringent, you might consider publishing the certificate template at more than one CA in the CA hierarchy, protecting against the failure of a single CA.

• Liability of PKI participants A CA hierarchy includes policy CAs that define the liability of the CA. The liability should provide sufficient coverage for transactions that use CA-issued certificates. Your organization’s legal department must review this liability definition to ensure that the definitions are legally correct and binding upon all participants in the PKI.

Assessing External Requirements

In some cases, an organization might have to meet external requirements, such as those defined by other organizations or by the governments of countries in which the organization conducts business.

Examples of external requirements include the following:

• Enabling external organizations to recognize employee-used certificates If you need other organizations to recognize the certificates assigned to entities in your organization, you can choose not to deploy an internal PKI and simply obtain certificates from commercial CAs, such as VeriSign or RSA. Alternatively, you can use cross-certification or qualified subordination to define which external certificates you trust.

• Using your organization’s certificate at partner organizations Your employees might use the certificates issued by your CA hierarchy for encryption or signing purposes at another organization. In this case, you might have to create custom certificates to meet the requirements of the other organization.

• Industry or government legislation Several countries have legislation that affects the design of a CA hierarchy. For example, Canada enforces the Personal Information Protection and Electronic Documents Act, which regulates the management of a customer’s personal information when held by a private-sector company. The act requires that someone be accountable for compliance and that this person be involved in the deployment and design of the CA hierarchy to ensure that all requirements of the act are enforced in the design.

• Certificates for nonemployees If you issue certificates to nonemployees, you can use a CA hierarchy to deploy a separate certificate policy that includes greater detail for external clients.

Assessing Active Directory Requirements

You should make several preparations before you install a Windows Server 2008 enterprise CA in a Windows 2000 or 2003 Active Directory environment. These preparations include the following:

• Determining the number of forests in the environment The number of forests will affect the number of enterprise CAs that you require in your AD CS deployment. An enterprise CA can issue certificates only to users and computers with accounts in the same forest. If multiple forests must consume certificates from the PKI, you must deploy at least one enterprise CA per forest.

• Determining the number of domains in the forest If more than one domain is in the forest, one of the major design decisions is which domain will host the CAs. The selection of which domain will host the computer accounts of the CA computers will depend largely on whether your organization uses centralized or decentralized management. In a centralized model, the CAs will typically be placed in the same domain. In a decentralized environment, you might end up deploying CAs in multiple domains.

• Determining the membership of the local Administrators groups for a member server If you use CSPs to protect a CA’s private key, all members of the CA’s local Administrators group will be able to export the CA’s private key. You should start identifying which domain or organizational unit in a domain will best limit the number of local administrators. For example, an organization that has deployed an empty forest root might choose to deploy all enterprise CAs as members of the forest root domain to limit the number of local administrators on the CA.

• Determining the schema version of the domain To implement Windows Server 2008 CAs and take advantage of all the new features introduced for AD CS, you must implement the latest version of the Active Directory Domain Services schema. The Windows Servers 2008 schema can be deployed in forests that contain Windows 2000 Server, Windows Server 2003, and Windows Server 2008 domain controllers.

Assessing Certificate Template Requirements

Certificate templates provide a practical way to implement certificate enrollment in a managed Active Directory environment. Because of the different versions of certificate templates released with each version of Windows Server, compatibility issues must be identified as part of your PKI planning.

Historically, static V1 certificate templates were introduced with Windows 2000. With Windows Server 2003, customization was introduced with V2 certificate templates. With Windows Server 2008, more certificate templates and certificate template properties compared with the Windows Server 2003 templates became available (including properties related to CNG). The new template types in Windows Server 2008 are called V3 templates.

Because of dependencies to the underlying operating system, Windows Server 2008 templates can be assigned only to CAs that are running on a Windows Server 2008. Only Windows Vista client computers and Windows Server 2008 computers can enroll for V3 certificate templates.

If you have installed only V2 certificates in your AD DS forest, you should upgrade the existing templates and add the new V3 certificate templates. If you do not have any certificate templates, all V1, V2, and V3 certificate templates are simply added to the configuration container of your AD DS forest.