Planning a public key infrastructure l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 67

Planning a Public Key Infrastructure PowerPoint PPT Presentation


Planning a Public Key Infrastructure . Planning a Certification Authority Hierarchy Managing Certification Authorities Using Certificates for Authentication. Planning a Certification Authority Hierarchy. Public Key Infrastructure (PKI) Deployment Steps Reviewing PKI components

Download Presentation

Planning a Public Key Infrastructure

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Planning a Public Key Infrastructure

  • Planning a Certification Authority Hierarchy

  • Managing Certification Authorities

  • Using Certificates for Authentication


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


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.


Reviewing PKI Components


Public Key-Enabled Applications and Services


Choosing a Public CA


Choosing a Private CA


Making the Decision:Implementing 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


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


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


A Rooted CA Hierarchy


A Cross-Certification CA Hierarchy


Making the Decision: Designing Certificate Hierarchies

  • Provide maximum security for the root CA.

  • Limit trusted CAs to an organization’s CAs.

  • Provide interoperability between organizations.

  • Limit which CAs will be trusted from a partner organization.


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 company’s 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.


Planning the Scope of a CA


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


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.


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)


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.


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.


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.


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


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.


Capolicy.inf Configuration File


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.


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.


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.


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


Certification Authority Hierarchy: Structure Based on Usage


Certification Authority Hierarchy:Structure Based on Administration


Certification Authority Hierarchy: Structure Based on Location


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.


Making the Decision:Choosing CA Hierarchy Structures

  • Usage structure

  • Administrative structure

  • Location structure


Applying the Decision: Implementing CA Hierarchy Structures for Blue Yonder Airlines


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.


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.


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 CA’s 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.


Managing Certification Authorities

  • Planning certificate issuance

  • Planning certificate revocation

  • Planning certificate renewal


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


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.


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.


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.


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


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


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.


Applying the Decision: Planning CRL Availability for CAs at Blue Yonder Airlines


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


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.


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.


Using Certificates for Authentication

  • Planning smart card logon

  • Planning certificate-based Web authentication


Smart Card Logon Process


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.


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.


Required Certificates

  • EnrollmentAgent

  • MachineEnrollmentAgent

  • SmartcardUser

  • SmartcardLogon


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.


Acquiring the Required Certificates

  • The enrollment agent must acquire an EnrollmentAgent certificate.

  • The smart card enrollment station computer requires a MachineEnrollmentAgent certificate.


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.


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.


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.


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.


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.


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.


Making the Decision: Implementing Account Mapping

  • Mapping certificates to user accounts

    • One-to-one mapping strategy

    • Many-to-one mapping strategy


Making the Decision: Implementing Account Mapping (Cont.)

  • Planning where to configure account mapping

    • Active Directory mapping

    • IIS mapping


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.


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


Chapter Summary (Cont.)

  • Planning certificate issuance

  • Planning certificate revocation

  • Planning certificate renewal

  • Planning smart card logon

  • Planning certificate-based Web authentication


  • Login