HSPD-12 Logical Access Authentication and … · Web viewHSPD-12 Logical Access Authentication and...

HSPD-12 Logical Access Authentication and Active Directory Domains

Microsoft Corporation

Published: December 2009Authors: Paul Fox, Vernon L. Lee, Kelvin Yiu & Yogesh Mehta

AbstractThis document explains the interdependencies between Active Directory Domain Services (AD DS) and Public Key Infrastructure (PKI) related to Homeland Security Presidential Directive 12 (HSPD-12) smart card logon. Topics concerning the Federal PKI Common Policy Root certificate, Extended Key Usage (EKU) requirements and validation of Personal Identity Verification (PIV) authentication certificates for smart card logon will be addressed.

Microsoft Confidential. © 2009 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.© 2009 Microsoft Corporation. All rights reserved.Microsoft, Windows 7, Windows 2008 Server, Windows Vista, Windows Server 2003, Windows XP, Windows ME, and Windows 98 are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.The names of actual companies and products mentioned herein may be the trademarks of their respective owners.


ContentsAUDIENCE....................................................................................................................1TERMINOLOGY..........................................................................................2

PUBLIC KEY INFRASTRUCTURE (PKI).............................................................................................2OBJECT IDENTIFIER (OID).............................................................................................................2X.509.......................................................................................................................................... 2X.509 CERTIFICATE EXTENSIONS..................................................................................................2X.509 KEY USAGE....................................................................................................................... 2X.509 EXTENDED KEY USAGE......................................................................................................2X.509 CERTIFICATE POLICIES.......................................................................................................2X.509 SUBJECT ALTERNATIVE NAME.............................................................................................3USER PRINCIPAL NAME................................................................................................................. 3TRUSTED ROOT STORE................................................................................................................3HOMELAND SECURITY PRESIDENTIAL DIRECTIVE 12 (HSPD-12)....................................................3FEDERAL INFORMATION PROCESSING STANDARD 201 (FIPS 201)..................................................3PERSONAL IDENTITY VERIFICATION (PIV).......................................................................................3PUBLIC KEY CRYPTOGRAPHY FOR INITIAL AUTHENTICATION IN KERBEROS (RFC 4556, PKINIT).....3FEDERAL DESKTOP CORE CONFIGURATION (FDCC)......................................................................3FEDERAL COMMON POLICY FRAMEWORK CERTIFICATION AUTHORITY (FCPFCA)............................4

REQUIREMENTS........................................................................................5WINDOWS SMART CARD LOGON...................................................................................................5

X.509 Key Usage and Enhanced Key Usage Fields..............................................................5Certificate Policies.................................................................................................................. 5Subject Alternative Name.......................................................................................................6Domain Controller Trusted Root Certification Authority Store................................................6Domain Controller Certificate.................................................................................................6Active Directory NTAuth Store...............................................................................................7

FEDERAL PKI COMMON POLICY....................................................................................................7Common Policy Certificates...................................................................................................7Common Policy Issuance Policies.........................................................................................7PIV-II Authentication Certificate.............................................................................................9FIPS SHA2 Requirement.....................................................................................................11

DEPLOYMENT.........................................................................................13MICROSOFT WINDOWS UPDATE DISTRIBUTION OF COMMON POLICY CERTIFICATE.........................13

Federal Desktop Core Configuration....................................................................................13ENTERPRISE DEPLOYMENT OF ROOT CERTIFICATES.....................................................................14

Group Policy.........................................................................................................................14Directory Publish – DSPublish.............................................................................................15

CERTIFICATE PRECEDENCE.........................................................................................................15

HSPD-12 SMART CARD LOGON PROCESS..................................................16CERTIFICATE CHAIN AND CRL VALIDATION PROCESS...................................................................16HSPD-12 SMART CARD LOGON SEQUENCE OF EVENTS..............................................................17

Step 1: Smart Card Insertion and PIN..................................................................................18Step 2: Domain Controller HSPD-12 PIV Authentication Certificate Validation....................19Step 3: Construct and Return Ticket Granting Ticket to Client.............................................19


APPENDIX A...........................................................................................21COMMON POLICY CERTIFICATES.................................................................................................21

Common Policy (new)..........................................................................................................21Common Policy (old)............................................................................................................23

References.................................................................................................................25


AudienceIt is assumed that the audience for this document has basic knowledge of Public Key Infrastructure and Smart Card concepts. For more information about these topics, see http://technet.microsoft.com/en-us/library/dd277362.aspx

This document is written for enterprise information technology professionals who are planning or implementing PIV-II smart card logon in accordance with the HSPD-12 directive.

http://technet.microsoft.com/en-us/library/dd277362.aspx

Terminology

Public Key Infrastructure (PKI)The laws, policies, standards, and software that regulate or manipulate certificates and public and private keys. In practice, it is a system of digital certificates, certification authorities (CAs), and other registration authorities that verify and authenticate the validity of each party involved in an electronic transaction.

Object Identifier (OID)(1) In the context of an object server, a 64-bit number that uniquely identifies an object. (2) In the context of a directory service, a number identifying an object class or attribute. Object identifiers are issued by the ITU and form a hierarchy. An OID is represented as a dotted decimal string (for example, "1.2.3.4"). OIDs are used to uniquely identify certificate templates available to the certificate authority (CA). Within a certificate, OIDs are used to identify standard extensions as covered in [RFC3280] section 4.2.1.x, as well as non-standard extensions. (3) In the Lightweight Directory Access Protocol (LDAP), a sequence of numbers in a format specified by [RFC1778]. In many LDAP directory implementations, an OID is the standard internal representation of an attribute. In the directory model used in [MS-ADTS], the more familiar ldapDisplayName represents an attribute. (4) In the context of Abstract Syntax Notation One (ASN.1), an object identifier, as specified in [ITUX680]. (5) A variable-length identifier from a namespace administered by the ITU. Objects, protocols, and so on that make use of ASN.1 or Basic Encoding Rules (BER), Distinguished Encoding Rules (DER), or Canonical Encoding Rules (CER) encoding format leverage identities from the ITU.

X.509 An ITU-T standard for public key infrastructure subsequently adapted by the IETF, as specified in [RFC3280].

X.509 Certificate ExtensionsX.509 version 3 certificate fields that provides the means to associate additional attributes used in determining the validity of an identity. Each extension has an associated OID and can be marked as critical or non-critical. If an extension is marked critical the system validating the certificate must understand the extension or else reject the certificate.

X.509 Key UsageDefines the allow usage of the associated key within the certificate. OID 2.5.29.15

X.509 Extended Key UsageFurther defines the intended purpose / application a certificate can be used for. This is synonymous with the Microsoft Enhanced Key Usage. OID 2.5.29.37


1

X.509 Certificate PoliciesDescribes how an organization manages their PKI infrastructure (e.g. validation requirements when a certificate is requested). OID 2.5.29.32

X.509 Subject Alternative Name Extends a certificate’s ability to identify an entity beyond the Subject field. This field is used to map a smart cards user’s certificate to their Active Directory user object. An HSPD-12 PIV Authentication certificate’s Subject Alternate Name field will contain the user’s organizational user principal name. OID 2.5.29.17

User Principal NameA user account name (sometimes referred to as the user logon name) and a domain name identifying the domain in which the user account is located. This is the standard usage for logging on to a Windows domain. The format is: [email protected] (in the form of an e-mail address). In Active Directory, the UPN is the userPrincipalName attribute of the account object, as specified in [MS-ADTS].

Trusted Root StoreA store within the computer of a relying party that is protected from tampering and in which the root keys of all root CAs are held. Those root keys are typically encoded within self-signed certificates, and the contents of a trust root are therefore sometimes called root certificates.

Homeland Security Presidential Directive 12 (HSPD-12)Presidential policy signed on August 27, 2004 requiring a common identity standard for federal employees and contractors for the use of gaining physical access to controlled facilities and logical access to controlled information systems.

Federal Information Processing Standard 201 (FIPS 201)This standard specifies the architecture and technical requirements for a common identification standard for the HSPD-12 directive.

Personal Identity Verification (PIV)As defined in FIPS 201, PIV-I identifies the control objectives in vetting an applicant’s identity. PIV-II addresses the technical interoperability requirements of HSPD 12.

Public Key Cryptography for Initial Authentication in Kerberos (RFC 4556, PKINIT)Kerberos protocol extensions used to integrate PKI into the Kerberos authentication exchange. Microsoft Windows operating systems use the Kerberos PKINIT protocol extension to establish a secure method in the exchange of the initial Kerberos Authentication Request / Reply (KRB_AS_REQ / KRB_AS_REP).

Federal Desktop Core Configuration (FDCC)The Federal Desktop Core Configuration is an OMB mandated security configuration. FDCC settings exist for the Microsoft Windows Vista and XP operating systems.


2

Federal Common Policy Framework Certification Authority (FCPFCA)The FCPFCA, referred to as the Common Policy, is the root trust point for all HSPD-12 certificates as defined in FIPS 201. It is commonly and incorrectly refered to as the “Federal Bridge.” The Common Policy and the Federal Bridge are two distinctly different certification authorities. More information can be found at the Federal Public Key Infrastructure Authority’s web site http://www.idmanagement.gov/fpkia/.


3

http://www.idmanagement.gov/fpkia/

Requirements The following sections outline the various X.509, infrastructure and FIPS 201 requirements needed to enable an HSPD-12 PIV-II Authentication certificate to perform smart card logon within an Active Directory domain. A detailed explanation on how smart card logon works within the Vista operating system can be found at http://msdn.microsoft.com/en-us/library/bb905527.aspx

Windows Smart Card Logon

X.509 Key Usage and Enhanced Key Usage FieldsThe X.509 certificate profile, as defined in RFC 5280, contains the Key and Extended Key Usage fields. Microsoft operating systems name the Extended Key Usage field the Enhanced Key Usage field. The Extended and Enhanced Key Usage fields are synonymous.

The Key Usage (OID 2.5.29.15) field defines the purpose of the key contained within the certificate. For a certificate to support smart card logon the Key Usage field must contain “Digital Signature.” HSPD-12 certificates mark the Key Usage extension critical as defined in the X.509 Certificate and Certificate Revocation List (CRL) Extensions Profile for the Shared Service Providers (SSP) Program, PIV Authentication Certificate Profile (http://www.idmanagement.gov/fpkipa/documents/CertCRLprofileForCP.pdf).

The Enhanced Key Usage field defines one or more purposes for which the public key may be used. RFC 5280 states “in general, [sic] the EKU extension will appear only in end entity certificates.” Certification authorities’ certificates may contain EKU entries. To allow smart card logon within an Active Directory domain the smart card’s chain of trust must support the Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2) application policies. Active Directory smart card logon is supported with the following EKU configurations:

All certificates in the chain of trust do not assert Enhanced Key Usage (except for the end entity certificate) the anyExtendedKeyUsage EKU is implied.

All certificates in the chain of trust do not assert Enhanced Key Usage except for the root trust point certificate Enhanced Key Usage field assert Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2).

All certificates in the chain of trust Enhanced Key Usage field assert Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2).

Best practice is for the root trust point certificate not to include an Enhanced Key Usage extension as is the case with the Common Policy root certificate.

Certificate PoliciesCertificate policies, also referred to as issuance policies, define the measures that are used to identify the subject of the certificate and thereby define the level of assurance for an issued certificate. By definition, the root CA declares issuance policy. A subordinate CA can have one or more additional policies defined. After a CA certificate is encountered with defined policy OIDs, all certificates below that CA in the hierarchy must also have a subset of those policy Microsoft Confidential. © 2009 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.

4

http://www.idmanagement.gov/fpkipa/documents/CertCRLprofileForCP.pdf

http://msdn.microsoft.com/en-us/library/bb905527.aspx

OIDs. The absence of the certificate policies extension in a CA other than the root CA implies that there is no issuance policy.

Subject Alternative NameThe X.509 Subject Alternative Name extension (OID 2.5.29.17) allows additional identity information to be bound to a certificate. Microsoft uses the ‘Principal Name’ value to contain the user’s Active Directory UserPrincipalName attribute (e.g. [email protected]). This field is used during the Kerberos v5 PKINIT process to perform the Kerberos Authentication Service’s Ticket Granting Ticket request. Active Directory domain controllers perform the Kerberos Key Distribution Center (KDC) role within an Active Directory domain. The client’s workstation and authenticating domain controller must be within the same Kerberos Realm.

Domain Controller Trusted Root Certification Authority StoreA smart card user’s domain controller’s Trusted Root Certification Authorities store must contain the smart card’s root trust point certificate (i.e. Common Policy) and have one of the EKU settings as described in the X.509 Key Usage and Enhanced Key Usage Fields section of this document.

Domain Controller CertificateEvery Active Directory domain controller must have a “Domain Controller Certificate” in its Computer Personal Certificate Store. This certificate can be issued from any Certificate Authority (e.g. third party or an organization’s internal PKI). This certificate enables the PKINIT process and the certificate’s root trust point certificate must be in the domain controller’s and authenticating workstation’s Trusted Root Certification Authorities store. The following are the requirements for the domain controller certificate:

Key Usage = Digital Signature and Key Encipherment

Enhanced Key Usage = Client Authentication and Server Authentication

Subject Alternate Name = Fully qualified DNS name of the domain controller

Windows Server 2008 Active Directory Certificate Services (AD CS) issue Kerberos Authentication Certificates to domain controllers. The purpose of the Kerberos Authentication template is to issue certificates to domain controllers. Certificates issued via this template contain two specific attributes. Rather than relying on the DNS name of the computer, applications can verify the following:

The enhanced key usage extension of the certificate contains Key Distribution Center (KDC) authentication.

The domain name is in the subject alternative name extension of the certificate.

This new template is recommended for domain controllers running Windows Server 2008. For domain controllers running Windows Server 2003, the Domain Controller Authentication template should be used.


5

mailto:[email protected]

Active Directory NTAuth StoreThe Active Directory NTAuth certificate store is used to ensure only certificates issued from a known Issuing Certification Authority can perform smart card logon within the domain. This prevents the ability of a fraudulent user’s smart card, containing a valid UserPrincipalName within the Subject Alternative Name field, issued from a non-trusted Issuing CA logging onto the domain.

Trusted Issuing Certification Authorities must be published to the Forest Domain’s NTAuth store using the certutil –dspublish –f <issuing_ca_certificate>.cer NTAuth command or using the Enterprise PKI MMC Snap-In.

Federal PKI Common Policy

Common Policy CertificatesSmart cards issued in accordance to the HSPD-12 / FIPS 201 PIV-II specification have the Federal PKI Common Policy certificate as the trusted root point. The original Common Policy certificate expires on 10/6/2010 and the Federal PKI Management Authority has ’rolled-over’ the Common Policy certificate to one expiring on 10/15/2027.

Certificate Attribute

Common Policy (old) Common Policy (new)

x500 CN Common Policy Common PolicyNot Before 10/6/2004 10/15/2007Not After 10/6/2010 10/15/2027Serial Number 39e3815404c50ab247effef336cfc6

98293647aae38aac864a2356f2cab761af

Subject Key Identifier

1e 2c 4b f9 ec 66 a6 1e 92 5f 87 79 03 ed d5 c2 95 b7 95 83

2f 58 97 d8 a9 05 98 a5 56 1f fb d9 ab 75 ef 02 3c 36 34 c7

Issuance Policy Not defined Not definedApplication Policy Not defined Not definedThumbprint (sha1) 76 b7 60 96 dd 14 56 29 ac 75 85

d3 70 63 c1 bc 47 86 1c 8bcb 44 a0 97 85 7c 45 fa 18 7e d9 52 08 6c b9 84 1f 2d 51 b5

Table 1: Common Policy Certificate Attributes

Common Policy Issuance PoliciesThe Common Policy certificates listed in the Table 1 do not have defined Issuance Policies; therefore the ‘any issuance policy’ is applied. The certification authorities subordinate to the Common Policy Root must declare their Issuance Policies. For example the GSA MSO HSPD-12 certificate chain is managed by Entrust. The Entrust CA subordinate to Common Policy is:

OU=Entrust Managed Services Root CA OU=Certification Authorities O=Entrust C=US

Serial Number: 489073b7000100000032


6

Figure 1: GSA MSO HSPD-12 PKI Chain (prior to May 9th, 2009 key update)

Issuance Policy OID Name Description2.16.840.1.101.3.2.1.3.6 id-fpki-common-policy The Federal PKI Common

Policy for certificates issued to users, other than devices, to support digitally signed documents or key management. Meets the requirements for Level 3 authentication as defined by OMB E-Authentication Guidance

2.16.840.1.101.3.2.1.3.7 id-fpki-common-hardware The Federal PKI Common Policy for certificates issued to users, other than devices, to support digitally signed documents or key management. Meets the requirements for Level 4 authentication as defined by OMB E-Authentication Guidance.


7

2.16.840.1.101.3.2.1.3.8 id-fpki-common-devices The Federal PKI Common Policy for certificates issued to devices

2.16.840.1.101.3.2.1.3.13 id-fpki-common-authentication The Federal PKI Common Policy for certificates issued to users supporting authentication but not digital signatures. Meets the requirements for Level 4 authentication as defined by OMB E-Authentication Guidance.

2.16.840.1.101.3.2.1.3.17 Id-fpki-common-cardAuth The Federal PKI Common Policy for certificates issued to users supporting authentication where the private key can be used without user authentication. This certificate authenticates the card or token, and not the individual in possession of the card or token.

Table 2: Entrust Managed Services Root CA Issuance PoliciesThe certification authority subordinate to Entrust Managed Services Root CA is Entrust Managed Services SSP CA which includes the Issuance Policy OID 2.16.840.1.114027.200.3.10.1 which is an Entrust registered OID.

PIV-II Authentication CertificateThe Federal PKI Policy Authority Shared Service Provider Working Group, X.509 Certificate and Certificate Revocation List (CRL) Extensions Profile for the Shared Service Providers (SSP) Program, January 7, 2008, (http://www.idmanagement.gov/fpkipa/documents/CertCRLprofileForCP.pdf) specifies the required structure of HSPD-12 compliant certificates. The PIV Authentication certificate is used for smart card logon and is outlined in Worksheet #9 ‘PIV Authentication Certificate Profile.’

Key Usage FieldThe Key Usage field of an HSPD-12 smart card is:

2.5.29.15: Flags = 1(Critical), Length = 4 Key Usage Digital Signature (80)


8

http://www.idmanagement.gov/fpkipa/documents/CertCRLprofileForCP.pdf

Figure 2: HSPD-12 Client Authentication Certificate Key Usage

Enhanced Key Usage FieldThe Enhanced Key Usage field of an HSPD-12 smart card is:

Enhanced Key Usage clientAuth (1.3.6.1.5.5.7.3.2) Smart Card Logon (1.3.6.1.4.1.311.20.2.2) anyExtendedKeyUsage (2.5.29.37.0)


9

Figure 3: HSPD-12 Client Authentication Certificate EKU

Subject Alternative Name FieldThe Subject Alternative Name field of an HSPD-12 smart card is:

2.5.29.17: Flags = 0, Length = 54 Subject Alternative Name Other Name: Principal [email protected] Other Name: 2.16.840.1.101.3.6.6=<pivFASC-N>

FIPS SHA2 RequirementNIST Special Publication 800-78-1, Cryptographic Algorithms and Key Sizes for Personal Identity Verification (SP 800-78-1) outlines the approved digital signature algorithms used by HSPD-12 smart cards and associated validity periods. The following table is from SP 800-78-1 Table 3.3 Signature Algorithm and Key Size Requirements for PIV Information:


10

Table 3: SP 800-78-1 Table 3.3 Signature Algorithm and Key Size Requirements

The SHA-1 algorithm will retire on December 31st, 2010, and all valid HSPD-12 smart card must use the SHA-256 algorithm.

Windows XP SP3 and Windows Server 2003 with KB938397 can only perform certificate validation of SHA-256 certificates. This functionality was added to the crypto module rsaenh.dll. The Windows Vista and higher operating systems can generate and validate SHA-256+ algorithms.

For more information concerning Microsoft FIPS 140 evaluations go to http://technet.microsoft.com/en-us/library/cc750357.aspx


11

http://technet.microsoft.com/en-us/library/cc750357.aspx

Deployment

Microsoft Windows Update Distribution of Common Policy CertificateThe Common Policy certificates listed in Table 1 are distributed to Microsoft Windows XP and higher operating systems via the Microsoft Root Certificate Program.

The Microsoft Root Certificate Program is a mechanism Microsoft provides to distribute root certificates via the Windows Update program. The intent of the Program is to enable PKI scenarios for the mass consumer market such as e-commerce, secure e-mail, and code signing. It is not intended to enable enterprise-only scenarios (e.g. smart card logon). The Program attaches a certificate’s EKU as metadata in the Windows certificate store. More information about the Microsoft Root Certificate Program can be found at http://support.microsoft.com/kb/931125 .

Common Policy certificates deployed via the Windows Update Root Certificate Program will not contain the smart card logon OID required to enable HSPD-12 smart card logon within an enterprise environment. The smart card logon purpose must be added to the Common Policy certificate contained within the authenticating domain controller’s Trusted Root Certification Authorities store. The domain controller is the Kerberos Key Distribution Center and performs the certificate path / policy validation and certificate revocation checks. In large scale environments modifying every domain controller’s Common Policy certificate EKU can become an arduous task.

The Common Policy certificate can be directly downloaded from the Federal PKI Authority web site. http://fpkia.gsa.gov/CommonPolicy/CommonPolicyRoot.p7c

Federal Desktop Core Configuration The Federal Desktop Core Configuration (FDCC) does not allow the Windows Update Root Certificate Updates on FDCC compliant systems. Therefore the Common Policy root certificate will not be populated via the Windows Update method.

FDCC Policy Path Computer Configuration\Administrative Templates\System\Internet Communication Management\Internet Communication settings

FDCC Policy Setting Name

Turn off Automatic Root Certificates Update

FDCC Windows Vista

Enabled

FDCC Windows XP EnabledCCE Reference CCE-858Registry Setting HKLM\Software\Policies\Microsoft\SystemCertificates\AuthRoot!

DisableRootAutoUpdateDescription Specifies whether to automatically update root certificates using the

Windows Update Web site. Typically, a certificate is used when you use a secure Web site or when you send and receive secure e-mail. Anyone


12

http://fpkia.gsa.gov/CommonPolicy/CommonPolicyRoot.p7c

http://support.microsoft.com/kb/931125

can issue certificates, but to have transactions that are as secure as possible, certificates must be issued by a trusted certificate authority (CA). Microsoft has included a list in Windows XP and other products of companies and organizations that it considers trusted authorities. If you enable this setting, when you are presented with a certificate issued by an untrusted root authority your computer will not contact the Windows Update web site to see if Microsoft has added the CA to its list of trusted authorities. If you disable or do not configure this setting, your computer will contact the Windows Update Web site.

Table 4: FDCC Automatic Root Certificates Update Setting

Enterprise Deployment of Root CertificatesThere are two methods (Group Policy and Enterprise Trusted Root Certification Authorities store) available to enterprise administrators to distribute the Common Policy certificate to all systems within an Active Directory domain. Both deployment methods use the auto-enrollment mechanism which is traditionally controlled within the Default Domain and Default Domain Controllers Policies (Computer Configuration -> Policies -> Windows Settings -> Public Key Policies -> Certificate Services Client: Auto-Enrollment).

Group Policy Group Policy publication of certificates to domain computers’ Trusted Root Certification Authorities certificate store provides the ability to manipulate a certificate Enhanced Key Usage field. This method of deployment must be used if the root trust point certificate does not contain the EKU OIDs necessary for smart card logon.


13

Figure 4: Group Policy Public Key Policies

Directory Publish – DSPublishSince the Common Policy certificate does not have an Enhanced Key Usage extension ‘any policy’ is implied. This certificate can be published to the Active Directory forest’s Trusted Root Certification Authorities store. The Common Policy certificate will then be pushed to all domain joined computers.

To publish a certificate to the Active Directory forest’s Trusted Root Certification Authorities store type the following command with Enterprise Administrator rights certutil –f –dspublish CommonPolicy.cer RootCA. To view the contents of the Enterprise Trusted Root Certification Authorities store type certutil –viewstore –enterprise root.


14

Figure 5: Enterprise Trust Root Certification Authorities Store

Certificate PrecedenceOf the three methods to deploy the Common Policy root certificate to Windows operating systems the Windows Update distributed certificate’s associate policies will have precedence. It is most likely that the majority of Domain Controllers received the Common Policy root certificate prior to adhering to the FDCC policy. Therefore most Domain Controllers Trusted Root Certification Authorities Common Policy certificate’s purposes will need to be modified.


15

HSPD-12 Smart Card Logon Process

Certificate Chain and CRL Validation ProcessBefore trust can be established, Windows performs a validation check to ensure that certificates are valid and that they have a valid certification path.

The status of a public key certificate is determined through three distinct, but interrelated, processes implemented in CryptoAPI:

Certificate discovery - the process of collecting CA certificates from Group Policy, Enterprise Policy, and Authority Information Access (AIA) pointers in issued certificates.

Path validation - the process by which public key certificates and their issuer certificates are processed in a hierarchical fashion until the certificate chain terminates at a trusted, self-signed certificate (e.g. root CA).

Revocation checking - each certificate in the certificate chain is verified to ensure that none of the certificates are revoked. The revocation checking can take place either in conjunction with the chain building process or after the chain is built.

The trust chain-building process will validate the certification path by checking each certificate in the certification path from the end certificate to the root CA’s certificate. The certificates are retrieved from the Intermediate Certification Authorities store, the Trusted Root Certification Authorities store or a URL specified in the AIA attribute of the certificate. If CryptoAPI discovers a problem with one of the certificates in the path, or if it cannot find a certificate, the certification path is discarded as a non-trusted certification path.

To improve performance, CryptoAPI will store successfully chained subordinate CA certificates in the Intermediate Certification Authorities store so that future requests for the certificate can be satisfied from the store, rather than accessing the certificate through a URL.

The certificate chain engine builds all possible certificate chains. The entire graph of certificate chain is constructed and then ordered by the “quality” of the chain. The best-quality chain for a given end certificate is returned to the calling application as the default chain. Each chain is built by using a combination of the certificates available in the certificate stores and certificates available from published URL locations. Each certificate in the chain is assigned a status code. The status code indicates whether the individual certificate is:

Signature-valid - is the signature valid?

Time-valid - are the certificate start and expiration dates properly configured, has the start date not occurred yet, or has the certificate expired?

Expired - has the certificate expired?

Revoked - has the certificate been revoked?

Time-nested - have any of the certificates that are higher in the PKI hierarchy expired?Microsoft Confidential. © 2009 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.

16

Is the certificate being used for a purpose other than has been intended?

Each status code has a precedence assigned to it. For example, an expired certificate has a higher precedence than a revoked certificate. This is because an expired certificate should not be checked for revocation status. If different status codes are assigned to the certificates in a certificate chain, the status code with the highest precedence is applied to the certificate chain and propagated into the certificate chain status.

HSPD-12 compliant smart cards use the Common Policy as their root trust point. Certificates that contain only the KeyID in the Authority Key Identifier (AKI) extension, as is the case with all certificates subordinate to the Common Policy, identify their valid issuer (i.e. parent CA) when the KeyID in the AKI match the parent certificate’s KeyID in the Subject Key Identifier (SKI) extension. This selection method is known as a “key match.” HSPD-12 compliant smart card certificates chain to the Common Policy via a key match.

Every certificate, with the sole exception of the root CA certificate, has a pointer to one or more Certificate Revocation List (CRL) Distribution Points (CDPs). Any entity that needs to verify a certificate’s validity can contact one of the distribution points and obtain a CRL. The CRL is essential for ensuring the quality (status) of the certificates that are published by the CA. The Online Certificate Status Protocol (OCSP) is another method used to determine the validity of a certificate. The OCSP client requests the status of a specific certificate to an OCSP Responder. The OCSP protocol provides faster validation checks and conserves network bandwidth. Windows Vista and Windows 7 support OCSP client checks. The Windows Server 2008 can be configured as an OCSP Responder. A third party OCSP client is required for the Windows XP and Windows Server 2003 operating systems.

More information concerning Certificate Chain and CRL Validation Process can be found at the following web sites:

http://technet.microsoft.com/en-us/library/ee619730(WS.10).aspx

http://technet.microsoft.com/en-us/library/bb457027.aspx

HSPD-12 Smart Card Logon Sequence of Events

The following sequence of events depicts the steps taken to successfully logon to an Active Directory domain with an HSPD-12 Smart Card. The PIV Authentication certificate was issued by the GSA HSPD-12 MSO prior to the May 9th, 2009 key update ceremony.


17

http://technet.microsoft.com/en-us/library/bb457027.aspx

http://technet.microsoft.com/en-us/library/ee619730(WS.10).aspx

Step 1: Smart Card Insertion and PINThe HSPD-12 smart card is inserted into the workstation’s smart card reader, the MSGINA (Windows XP) or Winlogon (Windows Vista) prompts the user for the private key’s pin (step 1.1). This process creates the pre-authentication data which consists of the user’s public certificate, and the certificate is digitally signed with the corresponding private key. A Kerberos Authentication Service request (KRB_AS_REQ) is generated containing the PKINIT pre-authentication data structure with the identifying Object Identifier (OID) 1.3.6.1.5.2.3.1 (step 1.2). The packet is sent to the workstation’s associated Domain Controller to request a Ticket Granting Ticket (TGT) (step 1.3).

Figure 6: Smart Card Logon Pre-Authentication


18

Step 2: Domain Controller HSPD-12 PIV Authentication Certificate ValidationThe Domain Controller (KDC) determines if the “Principal Name” contained in the certificate’s Subject Alternate Name extension matches an Active Directory user object’s userPrincipalName. The KDC validates the user’s certificate, as described in the Certificate Chain and CRL Validation Process section, to ensure that the certificate’s trust point is the Common Policy certificate in the local system’s Trusted Root Certification Authorities store. The KDC then verifies the digital signature of the signed data in the pre-authentication data in the packet and uses the public key from the user’s certificate to prove that the request originated from the owner of the private key that corresponds to the public key. The KDC also verifies that the issuing certification authorities’ (Entrust Managed Services SSP CA) certificate is trusted by being contained in the domain’s NTAUTH certificate store.

Figure 7: Smart Card Logon Certificate Validation and Active Directory Account Mapping

Step 3: Construct and Return Ticket Granting Ticket to ClientThe KDC service retrieves user account information from Active Directory. The KDC constructs a TGT based on the user’s Active Directory account information. The TGT includes the user's security identifier (SID). TGT is encrypted with the master key of the KDC, and the session key is encrypted with a temporary key. The KDC public key certificate is the Domain Controller certificate and this certificate must be trusted by the client’s workstation. The domain controller


19

certificate can come from the organization’s PKI or a third party PKI and does not have to chain to the Common Policy certificate.

Figure 8: Smart Card Logon Ticket Granting Ticket Issued

When the client receives the KRB_AS_REP packet containing the PKINIT reply data, the client decrypts the TGT data, verifies the validity of the KDC certificate and inspects the domain controller’s certificate to ensure it supports PKINIT. At this point the client has received the TGT, but the user has not been granted access to any resources including the local computer. The client computer then uses the session key to request a Ticket Granting Service ticket for local system logon from the TGS server. Once received the user is logged onto the workstation.

For more detailed information about the smart card logon process download the Windows Vista Smart Card Infrastructure white paper at http://www.microsoft.com/downloads/details.aspx?FamilyID=ac201438-3317-44d3-9638-07625fe397b9&displaylang=en

Information about the Microsoft implementation of the PKINIT protocol can be found at http://msdn.microsoft.com/en-us/library/cc238455.aspx


20

http://msdn.microsoft.com/en-us/library/cc238455.aspx

http://www.microsoft.com/downloads/details.aspx?FamilyID=ac201438-3317-44d3-9638-07625fe397b9&displaylang=en


Appendix A

Common Policy Certificates

Common Policy (new)X509 Certificate:Version: 3Serial Number: 293647aae38aac864a2356f2cab761afSignature Algorithm: Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA Algorithm Parameters: 05 00Issuer: CN=Common Policy OU=FBCA O=U.S. Government C=us

NotBefore: 10/15/2007 11:58 AM NotAfter: 10/15/2027 12:08 PM

Subject: CN=Common Policy OU=FBCA O=U.S. Government C=us

Public Key Algorithm: Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA (RSA_SIGN) Algorithm Parameters: 05 00Public Key Length: 2048 bitsPublic Key: UnusedBits = 0 0000 30 82 01 0a 02 82 01 01 00 97 8d bd 33 27 e4 ad 0010 5b fb 78 bd 2f 47 47 6e c7 78 e9 93 9c a4 de c9 0020 1c fd 2f 1b 39 38 ac 47 17 c0 7e 77 29 00 3b 03 0030 1f 68 0f cd 4d a5 ee 77 b8 2c 62 6b 31 f6 fa 72 0040 09 7d 30 29 06 7c e7 7c a3 3d 84 18 8a 1d ae 2c 0050 92 a8 1f e8 5e 4f 8d 8e eb 3f 1a f8 9c 0a 67 9d 0060 b0 67 4d f0 2e d0 30 de c3 94 b0 a0 cf 2e 0a 34 0070 7f 54 09 d3 36 bd a4 49 57 52 73 e9 9d fe e4 48 0080 79 46 1b 5b 8d 32 e4 a5 48 64 f3 22 0d 92 9d 08 0090 15 bf 60 3c 83 f7 47 22 25 22 ad 29 71 b7 77 ef 00a0 17 c9 a2 b6 94 5e c8 30 90 a4 14 48 5c 56 57 0b 00b0 41 4c 05 d4 2a 4c 3f ae 12 9b 59 11 75 70 07 22 00c0 69 2d 2c d3 31 cc 92 7e cc cd a4 7e 94 47 aa 9c 00d0 09 08 f6 4b af 52 e8 6a 40 91 c5 55 bd 40 b1 c8 00e0 6d 57 86 95 17 e6 1f 73 be 47 2e 3e 8b 4c 17 b9 00f0 b9 25 1c a5 52 17 36 08 59 c0 42 be 0a 2b b4 56

Microsoft Confidential. © 2009 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement. 21

0100 51 3c 1b 55 c9 8c 90 77 eb 02 03 01 00 01Certificate Extensions: 5 2.5.29.15: Flags = 1(Critical), Length = 4 Key Usage Certificate Signing, Off-line CRL Signing, CRL Signing (06)

2.5.29.19: Flags = 1(Critical), Length = 5 Basic Constraints Subject Type=CA Path Length Constraint=None

2.5.29.14: Flags = 0, Length = 16 Subject Key Identifier 2f 58 97 d8 a9 05 98 a5 56 1f fb d9 ab 75 ef 02 3c 36 34 c7

1.3.6.1.4.1.311.21.1: Flags = 0, Length = 5 CA Version V1.1

1.3.6.1.4.1.311.21.2: Flags = 0, Length = 16 Previous CA Certificate Hash 76 b7 60 96 dd 14 56 29 ac 75 85 d3 70 63 c1 bc 47 86 1c 8b

Signature Algorithm: Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA Algorithm Parameters: 05 00Signature: UnusedBits=0 0000 5e 84 e2 11 06 e0 e7 fc 48 c9 17 ff 5b ec 8b 11 0010 89 1c 8d 80 4b ea 11 74 92 76 61 c3 d1 b4 0c 6f 0020 46 2c 1b cc 76 35 88 a3 54 c4 f2 bc cf fa 9b 71 0030 d2 99 1a fa cd c0 1a bc b3 4a ce dd 8e bf b6 c4 0040 8a 41 36 e1 58 06 11 e9 37 fe 48 9a a7 2f 3c 52 0050 09 0f 3f e1 7c ec be c3 29 0b b1 4c 85 cb 01 7e 0060 03 a1 54 fd dc 67 30 8a 1c 97 87 89 83 ef 0b cd 0070 4f 7f a0 38 1b f4 06 83 0b b8 46 46 ad 81 42 0b 0080 8f 09 37 48 f7 3f 70 6b 6c 3c 7c ee fb 6c 98 37 0090 6c 36 fd 56 a5 26 de 68 a3 10 b8 dd 11 6c 67 69 00a0 51 fc 99 cd e1 62 f7 30 6e 40 78 8a 2b 38 73 14 00b0 d5 c0 9a 1e 9f 0d 1c bf 4f b1 ad a4 7d da 6a c9 00c0 b2 45 5c fd 88 ea 88 87 5d aa e2 fe 60 48 e0 41 00d0 9e 7e f9 38 09 34 1f 77 c5 83 df 67 99 f9 2a b6 00e0 ad 0a bf a5 7a 90 67 f0 90 78 65 ed 73 91 a0 5d 00f0 4b 24 2c 47 bc c9 88 08 a6 72 40 16 48 f3 ae 60Signature matches Public KeyRoot Certificate: Subject matches IssuerKey Id Hash(rfc-sha1): e7 b7 09 75 da 3b 49 a9 af 8f 06 fa 1f 79 0a 35 6d 40 bf 0dKey Id Hash(sha1): 2f 58 97 d8 a9 05 98 a5 56 1f fb d9 ab 75 ef 02 3c 36 34 c7Cert Hash(md5): f0 58 c5 03 82 67 17 ab 8f da 03 10 27 8e 19 c2Cert Hash(sha1): cb 44 a0 97 85 7c 45 fa 18 7e d9 52 08 6c b9 84 1f 2d 51 b5


22

Common Policy (old)X509 Certificate:Version: 3Serial Number: 39e3815404c50ab247effef336cfc698Signature Algorithm: Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA Algorithm Parameters: 05 00Issuer: CN=Common Policy OU=FBCA O=U.S. Government C=us

NotBefore: 10/6/2004 2:45 PM NotAfter: 10/6/2010 2:53 PM

Subject: CN=Common Policy OU=FBCA O=U.S. Government C=us

Public Key Algorithm: Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA (RSA_SIGN) Algorithm Parameters: 05 00Public Key Length: 2048 bitsPublic Key: UnusedBits = 0 0000 30 82 01 0a 02 82 01 01 00 cf 26 7c b0 69 4c 77 0010 00 ca f4 e3 74 19 94 fb 5a 61 af 62 e4 bd c3 00 0020 e5 24 a3 01 26 a0 d4 d6 e3 d1 f9 a6 78 ef eb f4 0030 01 92 a8 30 90 2f ca 33 a3 68 82 20 25 d4 37 b2 0040 ed 19 20 b7 29 16 b3 0b 59 38 07 44 41 61 08 91 0050 5f 71 42 c5 64 2a 29 2e 46 ba 0c 32 a5 13 25 e3 0060 d9 de bd f8 c9 13 90 8a 57 11 b5 57 48 78 38 b5 0070 27 d1 ac 85 ca 2a f8 40 f8 25 7f 9d 42 20 e1 73 0080 db 45 fd d3 5a 9a bf dd 47 ee 3e 3e 49 18 00 e4 0090 f6 be 5c 88 2d 78 28 07 ae 5e d2 d6 9b e6 bd fc 00a0 2c ba 27 f3 96 be 30 fe 20 f8 f7 d9 a8 0f 78 71 00b0 c7 53 23 cd b0 ac 7f 47 8c cf 71 26 c1 1a c3 30 00c0 24 9e 08 d3 58 74 25 f2 16 df b0 d0 82 37 35 68 00d0 99 89 e1 bd 04 a0 4e 96 62 9e c1 63 b4 1a 51 52 00e0 fc c9 de 2f f8 5e f5 7d 8c 6f 1b 41 81 4d bb 28 00f0 53 ae 9b 61 3f 29 ea dc d0 b7 a9 53 1d ae f5 aa 0100 96 d6 5c 77 93 56 2a 49 53 02 03 01 00 01Certificate Extensions: 4 2.5.29.15: Flags = 1(Critical), Length = 4 Key Usage Certificate Signing, Off-line CRL Signing, CRL Signing (06)Microsoft Confidential. © 2009 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.

23

2.5.29.19: Flags = 1(Critical), Length = 5 Basic Constraints Subject Type=CA Path Length Constraint=None

2.5.29.14: Flags = 0, Length = 16 Subject Key Identifier 1e 2c 4b f9 ec 66 a6 1e 92 5f 87 79 03 ed d5 c2 95 b7 95 83

1.3.6.1.4.1.311.21.1: Flags = 0, Length = 3 CA Version V0.0

Signature Algorithm: Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA Algorithm Parameters: 05 00Signature: UnusedBits=0 0000 07 ad 7a 08 ba 58 e2 bd c9 02 e9 a5 43 ce 06 6d 0010 cc 77 ee 3a fb ac 11 60 08 7b 25 2d 31 08 8e 4a 0020 7a 94 46 3d 5c 77 a1 0f 8f 00 c5 49 a5 b9 e9 3a 0030 4c 3d 41 62 3c d2 9a e0 79 11 59 b4 89 6e 31 06 0040 bb 74 58 44 8d 9a 29 2c 7c 5b 19 5c fa ea 33 87 0050 91 37 3c 97 ba 84 54 18 90 20 34 e9 ed 6b 0a d5 0060 d5 83 00 52 46 e2 a3 30 04 9f 2d 4c ca ed 67 c7 0070 69 b2 b6 1e c3 bc 2c 63 1a 56 eb 1b 0f bb d3 7e 0080 6c d2 97 ff 2e 10 c2 49 c6 39 7c c6 a3 a3 87 e6 0090 79 e0 a3 ca 1e 35 1b c5 8a 24 a0 7f ec e9 a1 79 00a0 40 f3 e7 ad a6 f2 e4 c2 a1 d7 21 e8 e1 49 7b b0 00b0 f9 cb f7 a3 08 c7 87 94 7f 34 8a 63 37 41 31 15 00c0 e1 4e ce b4 cd 19 3a ee 6b 05 7a 84 63 6c f6 19 00d0 e6 3e db de ea 13 6b 3b 4d f9 77 fe 60 58 84 2c 00e0 e9 a2 39 72 c7 5c 12 fa 1d 8c 5d c8 10 d1 1a 17 00f0 7e a9 cc 07 be 59 96 ce 37 e0 82 72 a1 cb 35 66Signature matches Public KeyRoot Certificate: Subject matches IssuerKey Id Hash(rfc-sha1): f1 f1 ac 39 d7 f1 b5 dc e0 5f 13 84 8b 39 fe 7d 90 eb 93 f3Key Id Hash(sha1): 1e 2c 4b f9 ec 66 a6 1e 92 5f 87 79 03 ed d5 c2 95 b7 95 83Cert Hash(md5): c1 d4 3e 07 ae eb ec fd 75 89 e6 7e a8 4c eb cdCert Hash(sha1): 76 b7 60 96 dd 14 56 29 ac 75 85 d3 70 63 c1 bc 47 86 1c 8b


24

References

HSPD-12 – Homeland Security Presidential Directive 12 , http://www.dhs.gov/xabout/laws/gc_1217616624097.shtm

FIPS 201 – Federal Information Processing Standard 201 , http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf

SP 800-78-1 - Cryptographic Algorithms and Key Sizes for Personal Identity Verification, http://csrc.nist.gov/publications/nistpubs/800-78-1/SP-800-78-1_final2.pdf

Smart Cards , http://technet.microsoft.com/en-us/library/dd277362.aspx

Microsoft Root Certificate Program , http://technet.microsoft.com/en-us/library/cc751157.aspx

Federal Desktop Core Configuration , http://nvd.nist.gov/fdcc/index.cfm

Guidelines for enabling smart card logon with third-party certification authorities , http://support.microsoft.com/default.aspx?scid=kb;en-us;Q281245

Federal Public Key Infrastructure Policy Authority , http://www.idmanagement.gov/fpkipa/

OID Repository , http://www.oid-info.com/

How Certificates Work , http://technet.microsoft.com/en-us/library/cc776447(WS.10).aspx

RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, http://tools.ietf.org/html/rfc5280

How the Kerberos Version 5 Authentication Protocol Works , http://technet.microsoft.com/en-us/library/cc772815.aspx

RFC 4556 - Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) , http://www.ietf.org/rfc/rfc4556.txt

RFC 4120 - The Kerberos Network Authentication Service (V5) , http://www.ietf.org/rfc/rfc4120.txt


25

http://www.ietf.org/rfc/rfc4120.txt

http://www.ietf.org/rfc/rfc4556.txt


http://tools.ietf.org/html/rfc5280

http://technet.microsoft.com/en-us/library/cc776447(WS.10).aspx

http://www.oid-info.com/

http://www.idmanagement.gov/fpkipa/

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q281245

http://nvd.nist.gov/fdcc/index.cfm


http://technet.microsoft.com/en-us/library/dd277362.aspx

http://csrc.nist.gov/publications/nistpubs/800-78-1/SP-800-78-1_final2.pdf

http://csrc.nist.gov/publications/nistpubs/800-78-1/SP-800-78-1_final2.pdf

http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf

http://www.dhs.gov/xabout/laws/gc_1217616624097.shtm

[MS-PKCA]: Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol Specification, http://msdn.microsoft.com/en-us/library/cc238455.aspx

Windows Vista Smart Card Infrastructure , http://www.microsoft.com/downloads/details.aspx?FamilyID=ac201438-3317-44d3-9638-07625fe397b9&displaylang=en


26



http://msdn.microsoft.com/en-us/library/cc238455.aspx

HSPD-12 Logical Access Authentication and … · Web viewHSPD-12 Logical Access Authentication and...

Documents

Transcript of HSPD-12 Logical Access Authentication and … · Web viewHSPD-12 Logical Access Authentication and...