1. May 30 th – 31 st, 2006 Sheraton Ottawa

2. HSPD – 12 / FIPS 201 Jon R. Wall Security / IA US Public Sector Microsoft Corporation

3. Agenda HSPD – 12 / FIPS 201 Overview Technology – Things in the design to consider Policy / Process – Considerations beyond network login Policy / Process – Card life cycle management

4. HSPD-12…

5. HSPD-12… Secure and reliable forms of identification issued based on sound criteria for verifying an individual employee's identity; strongly resistant to identity fraud, tampering, counterfeiting, and terrorist exploitation; can be rapidly authenticated electronically; and issued only by providers whose reliability has been established by an official accreditation process

6. HSPD-12 Summary View Create a trusted, interoperable and secure credential for logical and physical access One of the biggest challenges facing Government and Business today Must be addressed by commercial software products designed to meet the challenges and remove technology risk for the customer

7. Pick one? IdentificationAuthenticationAuthorization

8. PIV-1 Setting the Foundation All about issuing a credential in a trusted fashion Workflow is the foundation of a successful implementation Not only enrollment Recovery / Replacement UnblockingRenewalRevocationRoles Trust Model Need to leverage existing infrastructure like Active Directory as the backbone

9. PIV-2 Bringing Everything Together Brings standards and technologies together Smart card applets (card edge) Smart card middleware Biometrics Need to keep the technology componentized All of these moving pieces will have their own release schedules and issues Need to implement the solution in layers with vendors committed to working together

10. FIPS 201 Use commercially available products with roadmaps that will support FIPS 201 Today and tomorrow Separate the solution into well defined component areas Don’t build monoliths Derive additional value Smart card logon Secure email VPNWireless

11. Components FIPS 201 Solution Central repository for all user information Available group information Available permission information Should be the ‘backbone’ of the system Existing investments Directory

12. Components FIPS 201 Solution CertificateAuthority The root of trust Can be in-house or out-sourced Integrates with the directory for certificate publishing Should be cross certified Directory

13. Components FIPS 201 Solution CertificateAuthority HardwareSecurityModule Adds FIPS 140-2 Level 3 Certification Provides secure foundation to protect certificate issuance and enhance key management policies Includes multi-layered authentication capabilities Directory

14. ManagementSystem Components FIPS 201 Solution CertificateAuthority HardwareSecurityModule Provides management workflows for all tasks Leverages the directory for user, group and permission information Abstracts the complexity associated with card management, digital certificate management, biometrics and others Directory

15. Components FIPS 201 Solution CertificateAuthority HardwareSecurityModule Provides standards compliant smart card Provides FIPS compliant middleware Provides both logical and physical access features ManagementSystem Directory Smart Card

16. Outsource PKI / smart card processes - SSP In compliance with EOP guidance in OMB memo M-05-05 High assurance/availability services for end-user login Requires use of a certified Shared Service Provider (SSP) Run internal PKI for infrastructure use Domain controller certificates issued internally Leverage auto-enrollment/renewal of MS CA Use SSL certificates for internal web services from internal CA No need for external root for internal services Best option to meet FIPS requirements Best leverages existing investments Provides optimal infrastructure management control Follows OMB guidance FIPS 201 Solution Implementation Options - Hybrid PKI

17. Shared Service Provider Program General Services Administration launched program in 03/04 Enables Federal agencies to leverage outsourced PKI services Supports objectives of HSPD-12 Facilitates issuance of credentials to Agency employees and contractors Federal Agencies’ Use of SSPs mandated by OMB memo M-05-05

18. Windows Server 2003 Certificate Authority part of the platform MIISExchangeBizTalk Visual Studio Leveraging MS Platform Value from Agency EA’s

19. The Microsoft PKI including certificates, certificate templates, certificate services, certificate enrollment, Web enrollment pages, smart card support, and public key policies.[ [ Because the Microsoft PKI relies on Active Directory administrators can use Group Policie Objects (GPO) to effect the CA’s operation. For Example a certificate template can be configured for machine authentication that supports auto-enrollment and renewal. Once this is configure using GPO and CA templates every machine in the Forest can request, receive and install a certificate that identifies the machine without needing any actions by the Adminsitrators or end-users. One example that can provide a significant cost avoidance in the area of internal SSL certificates Leveraging MS Platform How Microsoft PKI Works

20. Leveraging MS Platform Infrastructure PKI uses Domain Controller Certificates IPSec Wireless 802.1x VPN Internal SSL Machine Authentication NAP Network (Router, Firewall..) Code Signing

21. Internal – Infrastructure PKI

22. MS Case Study Internal PKI to support Corporate wide 802.1x Wireless network Improved employee productivity Two Factor VPN Using Machine Authentication Certificates Using Smart Cards Administrator Smart Card use for High Value resource Management Separate Smart Card – 6 Month validity period

23. Agenda part two Technology – Things in the design to consider Policy / Process – Considerations beyond network login Policy / Process – Card life cycle management

24. US Govt. No Single Root Strong single focus on humans FBCA – Federal Bridge Certificate Authority SSP – Shared Services Provider Properly qualified provider of PKI services for the government Governed by Authentication and Identity Policy Framework Federal Common Certificate Policy Federal Smart Card Policy Federal Identity Assurance Policy

25. US Govt. Each federal government entity that desires to stand up a PKI required to do so under the Federal.gov root CA Certain existing systems exempt, most existing systems have sunset date after which they must transition to SSP Migration to smart card based Identification Cards – token solution already in place Repeatable “approved” solution approach

26. US Govt. GSA will establish the.gov root CA SSPs will operate as subordinate CAs under the.gov root CA The.gov root CA will be cross certified with FBCA – interoperability Operate under Common Certificate Policy Certificate Practice Statement (CPS) /Registration Practice Statement (RPS) approved by PA

28. DoD Separate PKI Separate Program for Contractors Issues with Coalition partners Cross Certification with rest of US Govt. No Cross Certification with Industry

29. Questions I Get (insert agency name) can we have our root published in Windows Root Certificate list (insert System Integrator name) can we cross certify with the DoD / US Govt. Higher Education cross certification Will MS cross certify with X What about bridge of bridges Path Processing Your CA is not certified

30. Track Govt. Stds NIST – FIPS 201 http://csrc.nist.gov/piv-program/fips201-support-docs.html User identity 123456788@US.GOV Issuance process Cross Certification

31. User Certificate structure What systems initiates eID establishment HR Physical Access PayrollSecurityOther User identity Cross Forest impact S/MIME – Suppress name check CRL – Http – LDAP RFC 822 – email Encryption Key Escrow

32. Smart Card Design Card Layout Contact / Contract less Location of Chip Mag Strip Card Size 64K? Biometric data? Card Life time Card use -

33. Policy / Process Legacy Integration HR systems New Hire Inter-agency transfer Agency transfer Temporary work force ContractorRetirement

34. CA Key roll over Root life time Policy life time Issuing life time 3 - 2 – 1 Actual Certs? DC User Auth IPSecAdmin

35. Policy / Process Physical Access Number / Type of systems Govt. Buildings Leased Space Ability to integrate with network systems Guard Desk Training Visit request

36. Policy / Process Deployment Considerations End User training Support Desk training Policy Impact Smart Card login allowed / required Machine GPO User Account Smart Card removal Administrator use Contractor use?

37. User inputs PIN 5 Kerberos sends certificate in a PKINIT login request to the KDC 7 KDC returns TGT, encrypted with a session key which is in turn encrypted using user’s public key 8 Smart card decrypts the TGT using private key allowing LSA to log user on 6 KDC verifies certificate then looks up principal in DS ReaderReader 3 GINA passes PIN to LSA SC 4 LSA accesses smart card and retrieves cert from card LSAKerberos KerberosKDC What happens @ 10K feet Smart Card Logon Card insertion causes Winlogon to display GINA 7.5 7.5 verifies DC certificate

38. What is Required The Basics End User Card – and knows what Pin is PC / Laptop needs SC Reader PC / Laptop needs Middle Ware PC / Laptop needs to trust User issued Root Domain Controller needs Certifcate Domain Controller needs to trust both Roots User account mapping to Card identity !

39. What is Required Not so Basics Customer CRL size 40+Meg Published to LDAP only – no HTTP points Various Cards in use Various Middle Ware in use OCSP Client OCSP Server OCSP on DC ? DC Certificate management

40. Use Case for testing User Scenario Group 1 Road Warriors with inoperative smart card or smart card reader and no direct network access Road Warriors with PIN locked on Smart Card User Scenario Group 2 – Regular PC users Forgotten card or bad card at work Reversed forgotten card (left in office) and no card at home Pin Reset

41. Use Case for testing User Scenario Group 3 – Mobile Device Users Mobile Device Users User Scenario Group 4 – Service/Test Account Users Personal Service Account (both system and applications) Test Account Users can’t use smart card User Scenario Group 5 – System Administration No reader sharing device at data center/lab Remote Administration

42. Use Case for testing Scenario Group 6 – Application Intranet Web Applications Extranet Web Applications Extranet Web Applications Non Web Apps 3rd Party Products Legacy Applications

43. Exception Planning Some accounts can not use SC … Functional accounts (training, watch stander, etc) Accounts for Temp and volunteers Development Lab SW testing lab ‘Exception’ accounts must be identified by organization What is the Exception process How long is an Exception valid What moves an account from one state to other? What about others on network?

44. Business Process Impact Track and analyze impact to business processes. In processing TDY Out processing Joint – business partners COOP / CONOP – planning Disconnected networks Local Services Non MS CA DC certificate lifetime

45. Other planning areas Organize and update Reference paper to address: Known Issues and status Implementation options KB articles / references Best Practices for implementation, exception handling and roll back Communication Plan: Who to report issues to (MS and other vendors) How to track issues and status How to distribute knowledge within Service, across Services, Contractors, others Resolutions

46. Smartcard Lifecycle Deployment Stages Initial Issuance PIN unblock RenewalRetirementRevocation Forgotten Smart Card

47. PIN Unblock Planning Considerations Users do forget their PINs Questions to consider Can a user initiate the unblock process? What software is required at the client? Does the client have to be connected to the network or to the Internet for the unblock process? Does the smart card’s SDK provide tools? How does the user prove who they say they are before initiating the unblock process?

48. Smartcard Renewal Lifecycle planning How does the renewal process differ from the enrollment process? Does the user have to go through the identity validation process Every year At regular intervals (every three, five, or seven years) Never, ever again Will the user have to connect to a portal or can the process be performed through autoenrollment

49. Revocation Disaster and recovery planning Who is responsible for reporting a smart card lost? Who performs the actual revocation of the smart card? Will the user be allowed to log on with a password in the interim? What revocation reason is provided for the lost smart card What about data encrypted with card? What if the smart card is just misplaced…

50. Temporary Smartcards Lost and Forgotten cards Can you deploy temporary smart cards Limited lifetime Does not replace the original smart card Only if the location of the smart card is known! Determine what issuance process is required Does it match the initial issuance process? What identification must be shown, especially if the smart card is also the employee badge? Who issues the temporary smart cards?

51. Smartcard Limitations Current Challenges Connecting to Windows 2000 Terminal Services Connecting to Dial-up and VPN connections hosted by an ISP Performing cross-forest authentication in Windows 2000 Adding a new computer to the domain Authenticating against Outlook Web Access with basic or form-based authentication Windows Vista Reduces the list!

52. Smartcard Limitations Current Challenges Authenticating applications that are non- Kerberized Storing EFS encryption certificates Storing EFS recovery certificates Hosting multiple user credentials for authentication on a single smart card (eg Your user and administrative account) Windows Vista Reduces the list!

53. Vista Feature Summary Smart Card Logon Enabled – insert reader, enable card @ logon Improved Logon Performance Integrated Pin Change & Unblock components in Logon screen Smart Card KSP for Windows Vista and beyond ECC Card Module support built-in Support for Multiple Certificates per Card User Access Control Support

54. Protocols: OCSP Responder OCSP Client (CAPI 2) Web Proxy Online Responder Management Online Certificate Status Protocol Responder RFC 2560 compliant Focus on performance, scalability and manageability HTTP DCOM DCOM CRL MSFT CA Other

55. Smart Card Certification Center New certification and logo program for smart card modules Ensures quality and interoperability Enables online distribution of card modules Expands card ecosystem on Windows Planned start of operation: Q1/2006

56. © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.