Microsoft Press windows server 2008 Policies and PKI and certificate security phần 4 pot

Chapter 9: Securing a CA Hierarchy 203 ■ Online CAs must audit all security events at the CA except the starting and stopping of Certificate Services. For offline CAs, all security events must be audited at the CA. ■ To allow ongoing issuance of certificates in the event of component failure, issuing CAs must not have a single point of failure. Figure 9-10 The City Power and Light CA hierarchy Case Study Questions 1. If you were to script the configuration of auditing settings for the offline CAs, what command would you include in the script to meet the auditing requirements? 2. What command is required to meet the audit setting requirements for the online CAs? CA Name: City Power and Light Eastern Infrastructure CA CA Validity Period: 5 Years CA Name: City Power and Light Western Employee CA CA Validity Period: 5 Years CA Name: City Power and Light Western Infrastructure CA CA Validity Period: 5 Years CA Name: City Power and Light Eastern Employee CA CA Validity Period: 5 Years CA Name: City Power and Light Policy CA CA Validity Period: 10 Years CA Name: City Power and Light Root CA CA Validity Period: 20 Years 204 Part II: Establishing a PKI 3. Can you meet the security requirements for the CA hierarchy by implementing either a software-based CSP or a smart-card CSP? Why or why not? 4. Can you use dedicated HSMs at each CA in the hierarchy and meet the design requirements? What are the drawbacks to this approach if it is possible? 5. Can you use network-attached HSMs at each CA in the CA hierarchy and meet the design requirements? What are the drawbacks to this approach if it is possible? 6. If you wanted to implement network-attached HSMs for the issuing CAs in the CA hierarchy, how many network-attached HSMs would you recommend to City Power and Light? Additional Information ■ Microsoft Official Curriculum, Course 2821: “Designing and Managing a Windows Public Key Infrastructure” (http://www.microsoft.com/traincert/syllabi/2821afinal.asp) ■ “Microsoft Windows Security Resource Kit” (http://www.microsoft.com/mspress/books/ 6418.asp) ■ “Deploying Certificate Services on Windows 2000 and Windows Server 2003 with the Chrysalis-ITS Luna CA3 Hardware Security Module” (http://www.microsoft.com/ windows2000/techinfo/planning/chrysalis.asp) ■ “Microsoft Windows Server 2003 PKI and Deploying the nCipher nShield Hardware Security Module” (http://www.ncipher.com/resources/downloads/files/white_papers/ win2003_nshield_wp.pdf) ■ “Security Configuration Wizard Deployment Guide” (http://go.microsoft.com/fwlink/ ?LinkID=45185) ■ “Windows Server 2003 PKI Operations Guide” (http://www.microsoft.com/technet/ prodtechnol/windowsserver2003/technologies/security/ws03pkog.mspx ) ■ BitLocker Home Page (http://www.microsoft.com/technet/windowsvista/security/ bitlockr.mspx) ■ BitLocker Blog (http ://blogs.technet.com/bitlocker) ■ “Security Requirements for Cryptographic Modules” (http://csrc.nist.gov/publications/ fips/fips140-2/fips1402.pdf) ■ nCipher nShield Hardware Security Module (http://www.ncipher.com/uploads/ resources/nshield0806.pdf) ■ nCipher netHSM (http://www.ncipher.com/uploads/resources/nethsm.pdf) ■ SafeNet Luna CA 3 (http://www.safenet-inc.com/Library/3/Luna_C A3_PB.pdf) ■ SafeNet Luna SA (http://www.safenet-inc.com/library/3/Luna_SA.pdf) Chapter 9: Securing a CA Hierarchy 205 ■ Utimaco SafeGuard CryptoServer CS10 (http://americas.utimaco.com/ safeguard_cryptoserver/CS10.html) ■ Utimaco SafeGuard CryptoServer CS50 (http://americas.utimaco.com/ safeguard_cryptoserver/CS50.html) ■ Algorithmic Research PrivateServer (http://www.arx.com/documents/ PrivateServer-Brochure.pdf) ■ AEP Keyper (http://ww w.alt tec h.com/files/pro ducts/aep/DataSheets/Keyper_Datasheet.pdf) 207 Chapter 10 Certificate Revocation Certificate revocation is necessary when you must terminate a certificate’s usage before the validity period expires. When a certificate is revoked, a certificate manager must select the certificate to revoke in the Certification Microsoft Management Console (MMC) console as well as provide a reason for revocation. The serial number of the certificate is then stored in the CA’s database with a reason code specifying why the certificate was revoked, which can then be used to publish a certificate revocation list (CRL). Note To revoke a certificate, a user must be assigned the Issue and Manage Certificates per- mission at the certification authority (CA) that issued the certificate. In addition, if certificate manager restrictions are implemented, the certificate manager must be allowed to manage the target user or a group containing the user, and the certificate must be based on a certificate template the certificate manager is allowed to revoke for that target user or group. When Do You Revoke Certificates? A certificate is revoked when a certificate’s use must be terminated before its validity period expires. The choice to revoke involves knowing the available revocation reasons, mapping the revocation reasons to your organization’s revocation policy, and then performing the revocation. Revocation Reasons The following revocation reasons are available when you revoke a certificate: ■ AffiliationChanged An individual is terminated, resigns, or dies, or the computer account to which the certificate was issued is no longer in use. This revocation reason can also be used if a person changes roles within an organization and no longer requires the use of the certificate associated with that person’s previous role. For example, an employee could move from the purchasing department and no longer require a certifi- cate used to authorize purchase requests. ■ CACompromise You suspect that a CA’s private key is compromised and potentially in the possession of an unauthorized individual. If a CA’s private key is revoked, all certificates below that CA in the CA hierarchy are considered revoked. ■ CertificateHold A temporary revocation that indicates a CA will not validate a certificate at that specific time. 208 Part II: Establishing a PKI Tip Although CertificateHold allows a certificate to be unrevoked, use of the CertificateHold reason code is not recommended, because it becomes difficult to determine whether a certificate was valid at a specific time. ■ CessationOfOperation A server or workstation is decommissioned, and all certificates issued to the server are no longer required. This revocation reason can also be used when you decommission a CA. Tip You cannot decommission a CA if any of the certificates issued by the CA are still in use. Even if you do not plan to issue any additional certificates, the CA must still publish CRL information at regular intervals for revocation checking purposes if you plan to use the existing certificates. ■ KeyCompromise You suspect that the private key associated with a certificate is compromised. For example, if a laptop belonging to a user in your organization is stolen, it is quite possible that any private keys stored on the laptop are compromised. ■ RemoveFromCRL If you revoke a certificate by using CertificateHold, you can unrevoke the certificate. The unrevoking process still lists the certificate in the CRL, but the certificate also appears in a delta CRL with the revocation code set to RemoveFromCRL. When the next base CRL is published, the CA removes the certificate from all forms of the CRL. If delta CRLs are not implemented, the certificate is simply removed from the next base CRL. ■ Superseded A new certificate must be issued if an issued certificate is replaced for any reason with a new updated certificate. For example, if you update a certificate template and reissue certificates, you could revoke the previous certificate with this reason code. ■ Unspecified You can revoke a certificate without providing a specific revocation code. Using Unspecified is not recommended, however, because it does not provide an audit trail identifying the reason a certificate was revoked. Revocation Policy A certificate manager should not arbitrarily revoke certificates based on whims. Instead, the best practice is to define the organization’s revocation policy. Table 10-1 describes the sections of an RFC-3647–based Certification Practice Statement that define an organization’s revoca- tion policy. Chapter 10: Certificate Revocation 209 Table 10-1 Defining a Revocation Policy Section Section title Description 4.9.1 Circumstances for Revocation Describes the circumstances under which a certificate issued by the managed CA must be revoked. The section should also detail the revocation reason that is applied under the specific circumstance. 4.9.2 Who Can Request Revocation Identifies the individuals who request the revocation processing and who perform the actual revocation request. 4.9.3 Procedure for Revocation Request Defines the workflow that must be followed during revocation request processing. 4.9.4 Revocation Request Grace Period States whether a lag can occur between the trigger for the revocation event and the request for revocation. 4.9.5 Time Within Which CA Must Process the Revocation Request Specifies how much time is allowed between receipt of the revocation request and processing the revocation request. 4.9.6 Revocation Checking Requirement for Relying Parties States whether an application must enforce strong CRL checking in cases in which certificate revocation checking is enforced each time the relying party evaluates a certificate. 4.9.7 CRL Issuance Frequency Defines the update schedule for both base CRLs and delta CRLs. 4.9.8 Maximum Latency for CRLs Specifies the maximum time allowed between CRL update and availability of the CRL at the specified CRL Distribution Points. 4.9.9 Online Revocation/Status Checking Availability If Online Certificate Status Protocol (OCSP) checking is available, specifies the Uniform Resource Locators that will host the OCSP responder. 4.9.10 Online Revocation Checking Requirements Defines requirements for configuring the OCSP responder. 4.9.11 Other Forms of Revocation Advertisements Available States whether revocation information is available in formats other than base CRLs, delta CRLs, or OCSP responders. 4.9.12 Special Requirements re Key Compromise Provides details on the actions that must take place when a certificate is revoked because of a key compromise. 4.9.13 Circumstances for Suspension Specifies the circumstances under which a certificate is revoked with the Certificate Hold revocation reason code. 4.9.14 Who Can Request Suspension Specifies who can submit a request for suspending a certificate. 4.9.15 Procedure for Suspension Request Provides details on the workflow requirements for performing a suspension request. 4.9.16 Limits on Suspension Period Provides details on how long a certificate can remain in a suspended state before the certificate is reinstated or permanently revoked. 210 Part II: Establishing a PKI Performing Revocation To revoke a certificate, a user must be designated as a certificate manager. You designate a user as a certificate manager by assigning the user or a group containing the user the Issue and Manage Certificates permission at the issuing CA. The permission assignment is performed by a CA Administrator, which is a user assigned the Manage CA permissions. You can verify the permissions assignment by using the following process: 1. Log on to the CA computer. 2. From Administrative Tools, open the Certification Authority console. 3. In the console tree, right-click CAName (where CAName is the logical name of the CA), and then click Properties. 4. In the CAName Properties dialog box, select the Security tab to ensure that the user account or a group that the user is a member of is assigned the Issue and Manage Certificates permission. Note If you want to assign a new user or security group the certif icate manager role to allow them to revoke certificates, assign the user or security group the Issue and Manage Certificates permission. Once you assign the necessary permissions, the following procedure revokes a certificate: 1. From Administrative Tools, open the Certification Authority console. 2. In the console tree, expand CAName, and then click Issued Certificates. 3. In the details pane, find the certificate that you need to revoke, right-click the certificate, point to All Tasks, and then click Revoke Certificate. 4. In the Certificate Revocation dialog box, in the Reason Code drop-down list, select the appropriate reason code, and then click Yes. Methods of Identifying Revoked Certificates The Windows Server 2008 public key infrastructure (PKI) provides three ways to determine if a certificate has been revoked: ■ Base CRL Contains the serial numbers of certificates revoked by the CA that are signed with the CA’s private key. If you renew a CA’s certificate with a new key pair, the CA maintains two separate CRLs—one for each key pair maintained by the CA. Base CRLs are recognized by all versions of the Microsoft Windows operating system. ■ Delta CRL Contains only the serial numbers of certificates revoked by the CA since the last base CRL publication. Again, if the CA’s certificate is renewed with a new key Chapter 10: Certificate Revocation 211 pair, separate delta CRLS are maintained for each CA key pair. Delta CRLs allow you to publish revocation information quicker and allow smaller updates to be downloaded by client computers. ■ Online Certificate Status Protocol (OCSP) Provides a responder service that can either connect directly to a CA database or inspect the base and delta CRLs published by the CA to determine revocation status of a specific certificate. Problems with CRLs CRLs have historically been the primary method for determining the revocation status of a specific certificate. Although widely supported, there are some known issues with using only CRLs to determine a certificate’s revocation status. Latency The primary issue with CRLs is that there is latency in identifying that a certificate has been revoked. Once you have revoked a certificate, the revocation is not recognized by relying parties until the next publication of a CRL. The availability is determined by the CRL publica- tion schedule. For example, if you publish an updated base CRL at 07:00 daily, a certificate revoked at 08:00 will not be recognized as a revoked certificate until the next day’s publication takes place. Caching of CRLs When a client computer checks the revocation status of a certificate, it first checks for the desired base CRL or delta CRL in the CryptoAPI cache. If the base CRL or delta CRL is found, the CRL is checked to determine if the CRL is time-valid. Like certificates, a CRL has a validity period specified by the CRL publication interval. If a time-valid CRL is found in the CryptoAPI cache, that version of the CRL is used for revocation checking, even if an updated version of the CRL has been published manually. The use of the cached version of the CRL is done for performance reasons, to prevent excess network traffic. In addition, the use of a cached CRL follows the recommendations in RFC 3280 to acquire an updated CRL only when the previous CRL expires. Warning Microsoft does not support designs that manually delete the cached version of a CRL from the CryptoAPI cache. Warning The process described here follows the definition of CRL usage described in RFC 3280, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” available at http://www.ietf.org/rfc/rfc3280.txt. 212 Part II: Establishing a PKI Support for Delta CRLs Delta CRLs provide timelier recognition of revocation by publishing a limited revocation list. Only certificates that have been revoked since the last base CRL was published are included in the delta CRL. Delta CRLs are not supported by all versions of Windows operating systems. Initially, only Windows XP and Windows Server 2003 supported delta CRLs when the Windows Server 2003 PKI shipped. In 2004, the patch MS04-11 changed the chaining engine for Windows 2000 clients, enabling them to support the use of delta CRLs. Delta CRLs are now supported on Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. Note It is safe to assume that delta CRLs will be supported by future versions of the Windows operating system as well. For non-Windows systems, you must read the documentation provided with the operating systems to determine whether they or applications running on those operating systems support delta CRLs. Important If you implement delta CRLs, both the associated base CRL and a time-valid delta CRL must be available to the client to perform a valid revocation check. If the base CRL is not available, the delta CRL alone cannot provide the required revocation information, and revocation checking will fail. Online Certificate Status Protocol (OCSP) OCSP allows more timely and structured determination of revocation status for a specific certificate. Rather than having the client download a CRL that contains all certificates revoked by the CA, the client sends a revocation status request to a responder service. The responder service provides revocation status for just that certificate, allowing the client to make a revoca- tion decision based on the response. The advantages of OCSP include: ■ More timely revocation information An OCSP responder can be configured to either directly query the CA database to determine or download CRLs at prescribed intervals rather than the normal publication schedule. Both methods provide a more timely determination of when a certificate is revoked by the CA. ■ Known traffic patterns and sizes The OCSP request and response packets are HTTP packets of known size. The actual number of certificates revoked by the CA is irrelevant [...]... “Installing, Configuring, and Troubleshooting Microsoft Online Responder” (http://go .microsoft. com/fwlink/?LinkId=101269) ■ “AD CS: Online Certificate Status Protocol Support” (http://technet2 .microsoft. com/ windowsserver2008/en/library/99d1f392-6bcd-4ccf-94ee- 640 fc100ba5f1033.mspx?mfr=true) ■ “Active Directory Certificate Server Enhancements in Windows Server Code Name ‘Longhorn’” (http://www .microsoft. com/downloads/details.aspx?FamilyID=9bf17231d832-4ff9-8fb8-0539ba21ab95&displaylang=en)... applied) and Windows XP or later check revocation as the chain is built Windows 2000, Windows XP, and Windows Server 2003 can perform revocation checking only by inspecting certificate revocation lists (CRLs) Windows Vista and Windows Server 2008 clients can also check revocation status by querying an Online Certificate Status Protocol (OCSP) responder Note If a certificate contains both OCSP and CRL... 11 Certificate Validation Certificate validation ensures that the certificate s information is authentic, the certificate can be used only for its intended purposes, and the certificate is trusted The certificate is also verified to be time-valid and not revoked The Windows operating system automatically performs certificate validation and repeats the validation process for each certificate in a certificate. .. that certificates are revoked with incorrect revocation reasons or certificates are not being revoked when they should be ■ Northwind Traders implements an AD DS forest with a single domain named corp.nwtraders.com on the production network ■ The client computers run Windows Vista Enterprise ■ All servers run Windows Server 2003 and Windows Server 2008 ■ Both issuing CAs are running Windows Server 2008. .. populated incorrectly, the certificate is considered invalid Note An invalid certificate will not be used by the certificate chaining engine when building certificate chains The certificate chaining engine excludes all invalid certificates found during the certificate discovery process ■ Certificate format A certificate must conform to a valid X.509 standard for digital certificates The certificate chaining... 238 Part II: Establishing a PKI Note Windows XP and Windows 2000 can support OCSP if a third-party OCSP client is installed For example, the Tumbleweed client enables OCSP revocation checking on Windows 2000 and Windows XP clients The catch is that you must purchase a license for every client computer that is enabled for OCSP checking The Windows Vista and Windows Server 2008 OCSP client is built into... both OCSP and CRL checking extensions, Windows Vista and Windows Server 2008 clients will use OCSP by default to determine revocation status Certificate Validity Checks When a certificate is presented to an application, the certificate chaining engine tests the following components: ■ Certificate contents A certificate must have information in all required X.509 standard fields If any required fields... certification authority (CA) The certificate chaining engine within Windows performs the validation testing More Info For more information on certificate revocation list (CRL) checking and certificate validation, see Certificate Revocation and Status Checking,” available at http://technet .microsoft. com/en-us/library/bb457027.aspx Certificate Validation Process When a certificate is presented to an application,... revocation status of the certificate ■ Of the available Microsoft operating systems, only Windows Vista and Windows Server 2008 support OCSP revocation checking natively If a certificate contains revocation information for both OCSP and CRLs, a prior operating system client will resort to CRLs for revocation checking If a certificate contains only an OCSP responder URL in the AIA extension, and a client does... Infrastructure Certificate and Certificate Revocation List (CRL) Profile” (http://www.ietf.org/rfc/rfc3280.txt) ■ RFC 3 546 —“Transport Layer Security (TLS) Extensions” (http://www.ietf.org/rfc/ rfc3 546 .txt) ■ RFC 3 647 —“Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework” (http://www.ietf.org/rfc/rfc3 647 .txt) ■ RFC 5019—“The Lightweight Online Certificate Status . (http://www .microsoft. com/traincert/syllabi/2821afinal.asp) ■ Microsoft Windows Security Resource Kit” (http://www .microsoft. com/mspress/books/ 641 8.asp) ■ “Deploying Certificate Services on Windows 2000 and Windows Server 2003 with the. Initially, only Windows XP and Windows Server 2003 supported delta CRLs when the Windows Server 2003 PKI shipped. In 20 04, the patch MS 04- 11 changed the chaining engine for Windows 2000 clients,. supported on Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. Note It is safe to assume that delta CRLs will be supported by future versions of the Windows