Planning%20a%20Public%20Key%20Infrastructure

1
Planning a Public Key Infrastructure

• Planning a Certification Authority Hierarchy
• Managing Certification Authorities
• Using Certificates for Authentication

2
Planning a Certification Authority Hierarchy

• Public Key Infrastructure (PKI) Deployment Steps
• Reviewing PKI components
• Determining whether to use a private or public
  Certification Authority (CA)
• Determining the CA structure
• Planning the scope of a CA
• Planning offline CAs
• Designing the Certification Authority hierarchy
• Planning disaster recovery of CAs

3
PKI Deployment Steps

• Determine whether a public CA or a private CA
  meets the business needs.
• Design a CA hierarchy that allows clients to
  recognize and verify all issued certificates.
• Determine whether to deploy an Enterprise or
  Standalone scope for private CAs.
• Plan security for the root CA.
• Develop a disaster recovery plan for the
  potential failure of a CA.

4
Reviewing PKI Components
5
Public Key-Enabled Applications and Services
6
Choosing a Public CA
7
Choosing a Private CA
8
Making the DecisionImplementing Public and
Private CAs

• Use a public CA when
• An application requires verification from a
  trusted third party
• The resources necessary to deploy an internal PKI
  are not available
• Time is limited
• A project requires certificate interoperability
  between organizations
• An application requires liability protection

9
Making the Decision Implementing Public and
Private CAs (Cont.)

• Use a private CA when
• The organization needs to maintain management
  control of all client-associated certificates
• The certificates will be used only for internal
  projects, applications, and services
• The costs associated with issuing certificates
  must be minimized
• An organization has the expertise to manage and
  maintain Certificate Services

10
Applying the Decision Implementing Public and
Private CAs for Blue Yonder Airlines

• Public CAs
• The online booking Web server must have a public
  CA-issued certificate.
• Ensures customer confidence in the security of
  sensitive data.
• Configure the Web server to require 128-bit
  encryption.
• Private CAs
• Make it possible to issue smart cards to
  customers while maintaining the ability to revoke
  certificates quickly
• Provide internal employees with smart card logon
  and Extensible Authentication Protocol (EAP)
  authentication for remote access

11
A Rooted CA Hierarchy
12
A Cross-Certification CA Hierarchy
13
Making the Decision Designing Certificate
Hierarchies

• Provide maximum security for the root CA.
• Limit trusted CAs to an organizations CAs.
• Provide interoperability between organizations.
• Limit which CAs will be trusted from a partner
  organization.

14
Applying the Decision Designing Certificate
Hierarchies for Blue Yonder Airlines

• Blue Yonder Airlines requires only a rooted CA
  hierarchy for the internal network and for Web
  site customers.
• This allows for increased security by removing
  the root CA from the network.
• Blue Yonder Airlines will acquire a certificate
  for their Web server from a public CA such as
  Entrust.
• There is no business reason to create
  cross-certification between the companys CA
  hierarchy and the Entrust CA hierarchy.
• The Entrust certificate will be trusted.
• The root certificate from Entrust CA will be
  included in the Trusted Root Certification
  Authorities container by default.

15
Planning the Scope of a CA
16
Enterprise CA Considerations

• Certificate templates
• Integration with Microsoft Windows 2000 security
• Storage of data in Active Directory
• Applications and services that require an
  Enterprise CA
• Reduction in management for certificate issuance

17
Deploying a Standalone CA

• Standalone CAs can be members of a domain or
  standalone servers in a workgroup.
• All data is stored in a local database.
• Standalone CAs do not use certificate templates.

18
Considerations for Deploying a Standalone CA

• If an offline root CA is established
• If integration of Windows 2000 Certificate
  Services with an Exchange 5.5 Key Management
  Server (KMS) is desirable
• If the CA is required to run in the Demilitarized
  Zone (DMZ)

19
Making the Decision Implementing Enterprise CAs

• Deploy Certificate Services for an internal
  deployment where the users will be providing
  their network credentials for authentication.
• Deploy Windows 2000 services that require
  certificate templates provided only by Enterprise
  CAs.
• Leverage the standard Windows 2000 security model
  to determine who can acquire specific certificate
  templates.

20
Making the Decision Implementing Standalone CAs

• Deploy offline CAs that must operate without
  communicating with the rest of the network.
• Configure the Exchange 5.5 KMS to use x.509 v3
  certificates rather than the default x.509 v1
  certificates.
• Place the CA in a location where it cannot
  connect to Active Directory.

21
Applying the Decision Deploying Enterprise CAs
or Standalone CAs at Blue Yonder Airlines

• Blue Yonder Airlines requires the issuance of
  smart cards for both customers and internal user
  accounts.
• Requires deployment of an Enterprise CA.
• Only an Enterprise CA supports certificates for
  smart cards
• Each CA hierarchy should have an offline root CA
  to increase the security of the CA hierarchy.
• Requires configuration of a Standalone scope for
  the CA.

22
Offline CA Considerations

• Storage location of the offline CA
• Use of a strong Cryptographic Service Provider
  (CSP)
• Publication of the Certificate Revocation List
  (CRL)
• Publication of the Authority Information Access
  (AIA)
• Definition of certificate renewal period

23
Configuring an Offline Root CA

• The primary configuration is performed in the
  Capolicy.inf file.
• Place the Capolicy.inf file in the Systemroot
  folder before installing Windows 2000 Certificate
  Services.

24
Capolicy.inf Configuration File
25
Capolicy.inf File for Nonroot CAs

• Only use a Capolicy.inf configuration file for a
  nonroot CA to define a Certificate Practice
  Statement (CPS) for an issuing CA.
• The Capolicy.inf text file is the only way to
  enter information into a CPS for Windows 2000
  Certificate Services.
• A nonroot CA processes only the CAPolicy and
  PolicyName sections of the Capolicy.inf
  configuration file.
• All other sections are ignored.

26
Configuring the CDPs

• Configure Certification Distribution Points
  (CDPs) for the CRL and Authority Information
  Access (AIA) associated with the CA.
• Configure CDPs in the properties of the
  Certification Authority.
• Define the X.509 extensions for the CA's policy
  module.
• The URLs defined for the CRL and AIA distribution
  points are included in the properties of any
  newly issued certificate by the CA.

27
Making the Decision Securing Offline Root CAs

• Allow the CA to be removed from the network for
  long periods of time.
• Provide the strongest form of encryption at the
  offline root CA.
• Make the CRL and AIA available to network users.
• Define a CPS.
• Provide the most security for your CA hierarchy.

28
Applying the Decision Securing Offline Root CAs
for Blue Yonder Airlines

• A Standalone CA must be used for the offline root
  CA.
• A second layer of subordinate CAs can also be
  removed.
• A Capolicy.inf configuration file must be
  configured to issue a CPS that defines usage
  policy for all customers with airline smart
  cards.
• Attributes for the CA must be set before removing
  the CA from the network.
• CRL publication interval
• CRL and AIA distribution points
• The default lifetime for issued certificates

29
Certification Authority Hierarchy Structure
Based on Usage
30
Certification Authority HierarchyStructure
Based on Administration
31
Certification Authority Hierarchy Structure
Based on Location
32
Required CA Levels

• Create a CA hierarchy that is three to four
  levels deep.
• Hierarchies with fewer than three levels are more
  vulnerable.
• With two levels, if the root level is
  compromised, all certificates are also
  compromised.
• Hierarchies with more than four levels introduce
  unnecessary complexity.

33
Making the DecisionChoosing CA Hierarchy
Structures

• Usage structure
• Administrative structure
• Location structure

34
Applying the Decision Implementing CA Hierarchy
Structures for Blue Yonder Airlines
35
Preventing CA Failure

• Implement hardware solutions for fault tolerance.
  
• Back up the Certificate Services data regularly.
• Back up an offline CA server with disk imaging
  software.

36
Making the Decision Disaster Recovery Plan for
CAs

• Prevent loss of data in the Certificate Services
  database.
• Ensure that a rebuilt CA is still valid for all
  issued certificates.
• Allow a CA to be recovered.
• Ensure recoverability.

37
Applying the Decision Disaster Recovery Plan for
CAs at Blue Yonder Airlines

• Include a backup and restore strategy for all
  CAs.
• Schedule regular backups that include the system
  state backups.
• Export the existing private and public keys
  associated with the CAs certificate to files and
  include those files in the regular backup set.
• Create an image of the root CA for the hierarchy
  on a CD.

38
Managing Certification Authorities

• Planning certificate issuance
• Planning certificate revocation
• Planning certificate renewal

39
Planning Certificate Issuance

• Certificates must be issued to the necessary
  users, computers, and network devices.
• Issuing certificates involves either
• Configuring permissions to establish which
  security principals have Enroll permissions for
  specific templates
• Appointing a certificate administrator who will
  review each certificate request and issue or deny
  the request

40
Designing Automatic Issuance

• Define which certificate templates will be
  requested by computer accounts within the site,
  domain, or OU where the Group Policy object is
  defined.
• Assign the correct permissions to the required
  computers to acquire the certificate templates.
• Configure at least one Enterprise CA in the
  forest to issue the required certificate
  templates.

41
Designing Manual Issuance

• All user certificates and some computer
  certificates must be requested manually from a
  CA.
• User certificates cannot automatically be
  assigned.
• Set permissions for each certificate template.
• Designate a CA to issue the required certificate
  templates.

42
Making the Decision Planning Certificate
Issuance

• Restrict access to specific templates.
• Restrict which CA issues a specific certificate
  template.
• Automate the deployment of computer certificates.
  
• Issue certificates to users.
• Require a certificate administrator to approve or
  reject each certificate request.

43
Applying the Decision Planning Certificate
Issuance for Blue Yonder Airlines

• Computer certificates
• Require IPSec-specific certificates or
  multipurpose Computer certificates for IPSec
  authentication
• Configure the Default Domain Policy to issue both
  IPSec and Computer certificates
• User certificates
• Cannot automatically issue certificates to
  internal users
• Jenny Sax will make all certificate requests for
  external customers

44
Planning Certificate Revocation

• Reasons for revoking a certificate before its
  expiration date
• Verifying a revoked certificate
• When frequent certificate revocations occur
• The CRL's availability

45
Making the Decision Planning CRL Availability
for CAs

• Create a central location for offline CA CRLs.
• Determine the optimal publication schedule for
  the CRL associated with a CA.
• Ensure availability of the CRL.
• Ensure that CRL's are available to external
  clients if they receive certificates from the
  internal network.
• Ensure that all CRL's in the CA chain are
  available.

46
Applying the Decision Planning CRL Availability
for CAs at Blue Yonder Airlines
47
Planning Certificate Renewal

• Registry values define the lifetime for all
  issued certificates
• Renewing User certificates or Computer
  certificates
• Renewing the CA certificate using the
  Certification Authority console
• Setting the lifetime for CA and SubCA
  certificates

48
Making the Decision Designing a Renewal Policy
for Certificates

• Define certificate lifetimes based on renewal
  requirements.
• Define a process that users and computers will
  use to renew their certificates.
• Ensure that the CA certificate's remaining
  lifetime is never shorter than the lifetime for
  issued certificates.
• Plan for renewal dates far in the future.

49
Applying the Decision Designing a Renewal Policy
for Certificates at Blue Yonder Airlines

• Install the root CA with the longest lifetime.
• Renew the root CA's certificate before the SubCAs
  expire.
• The Smartcards CA requires the shortest validity
  period.
• Develop a plan for renewing the internal network
  certificates.

50
Using Certificates for Authentication

• Planning smart card logon
• Planning certificate-based Web authentication

51
Smart Card Logon Process
52
Planning Smart Card Deployment

• Define which users can enroll for the required
  types of certificates.
• Define a CA to issue the required certificates.
• Configure a computer and user account to function
  as the smart card enrollment station and smart
  card enrollment agent.
• Define the physical process for smart card
  enrollment.

53
Defining Permissions for Certificate Templates

• Smart card logon requires several certificate
  templates.
• Use SmartcardUser for e-mail purposes.
• Use SmartcardLogon for network authentication.
• Define security so that only the security groups
  have the permission to enroll for the required
  certificate.
• Permissions are defined in Active Directory Sites
  And Services by exposing the Services node.
• Find the certificate templates in Active
  Directory Sites And Services\Services\Public Key
  Services\Certificate Templates.

54
Required Certificates

• EnrollmentAgent
• MachineEnrollmentAgent
• SmartcardUser
• SmartcardLogon

55
Configuring CAs to Issue the Required
Certificates

• By default, CAs do not issue any of the required
  certificate templates for smart card logon.
• Only Enterprise CAs can issue certificate
  templates.
• Select an Enterprise CA that is located near the
  smart card enrollment station.

56
Acquiring the Required Certificates

• The enrollment agent must acquire an
  EnrollmentAgent certificate.
• The smart card enrollment station computer
  requires a MachineEnrollmentAgent certificate.

57
Defining the Enrollment Process

• Security can be built into the smart card
  certificate distribution process.
• Mandate that the user must be face-to-face with
  the enrollment agent to obtain a smart card.
• Ensure that only the smart card's user knows the
  associated PIN.

58
Making the Decision Smart Card Deployment

• Ensure that only authorized personnel can request
  certificates required for smart card
  authentication.
• Restrict the smart card enrollment process to
  specific workstations.
• Require smart card users to log on with smart
  cards.
• Ensure that only authorized users obtain a smart
  card.
• Define what happens when a smart card is removed
  from the smart card reader.

59
Applying the Decision Smart Card Deployment at
Blue Yonder Airlines

• External requests
• Face-to-face interviews will not be possible.
• Customers must request the cards by filling out
  an extensive form.
• Jenny Sax will determine whether to issue a smart
  card to the customer.
• Safeguard the card if it is issued by sending the
  card, the smart card reader, and the PIN in
  separate packages.
• Internal requests
• Jenny Sax can require face-to-face interviews.
• Safeguard the process by requiring a form of
  photo ID to prove identity.

60
Certificate Mapping Overview

• A Web site can be configured to require
  certificates for user authentication.
• Only the certificate is transmitted to the Web
  server.
• Certificate mapping allows certificates with
  similar properties to be mapped to a single user
  account.

61
Designing Certificate Mapping

• Determine where to perform the mapping.
• Determine the type of mapping to implement.
• Ensure that all certificates are issued from
  trusted root CA hierarchies.

62
Configuring Authentication

• The Web site's authentication configuration can
  be changed to allow only certificate-based
  authentication.
• Configure the supported authentication methods to
  prevent Internet Information Server (IIS) from
  presenting the user with an Authentication dialog
  box if certificate-based authentication fails.
• Only certificates can be used to authenticate
  users.

63
Making the Decision Implementing Account Mapping

• Mapping certificates to user accounts
• One-to-one mapping strategy
• Many-to-one mapping strategy

64
Making the Decision Implementing Account Mapping
(Cont.)

• Planning where to configure account mapping
• Active Directory mapping
• IIS mapping

65
Applying the Decision Implementing Account
Mapping at Blue Yonder Airlines

• Blue Yonder Airlines requires one-to-one
  mappings.
• The easiest place to perform the mapping is in
  Active Directory.
• The certificates are mapped only to a single
  smart card.

66
Chapter Summary

• PKI deployment steps
• Reviewing PKI components
• Determining whether to use a private or public CA
  
• Determining the Certification Authority structure
  
• Planning the scope of a CA
• Planning offline CAs
• Designing the Certification Authority hierarchy
• Planning disaster recovery of CAs

67
Chapter Summary (Cont.)

• Planning certificate issuance
• Planning certificate revocation
• Planning certificate renewal
• Planning smart card logon
• Planning certificate-based Web authentication