May 30 – 31 , 2006 Sheraton Ottawa th st

May 30 – 31 , 2006 Sheraton Ottawa th st

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

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

HSPD-12

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

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

Pick one? Identification Authentication Authorization

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 Unblocking Renewal Revocation Roles Trust Model Need to leverage existing infrastructure like Active Directory as the backbone

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

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 VPN Wireless

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

Components FIPS 201 Solution Certifica te Authorit y The root of trust Can be in-house or out-sourced Integrates with the directory for certificate publishing Should be cross certified Directory

Components FIPS 201 Solution Certifica te Authorit y Hardwar e Security Module Directory Adds FIPS 140-2 Level 3 Certification Provides secure foundation to protect certificate issuance and enhance key management policies Includes multilayered authentication capabilities

Components FIPS 201 Solution Certifica te Authorit y Hardwar e Security Module Managemen t System Directory 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

Components FIPS 201 Solution Certifica te Authorit y Hardwar e Security Module Managemen t System Directory Smart Card Provides standards compliant smart card Provides FIPS compliant middleware Provides both logical and physical access features

FIPS 201 Solution Implementation Options - Hybrid PKI 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

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

Leveraging MS Platform Value from Agency EA’s Windows Server 2003 Certificate Authority part of the platform MIIS Exchange BizTalk Visual Studio

Leveraging MS Platform How Microsoft PKI Works 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 Infrastructure PKI uses Domain Controller Certificates IPSec Wireless 802.1x VPN Internal SSL Machine Authentication NAP Network (Router, Firewall.) Code Signing

Internal – Infrastructure PKI

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

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

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

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

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

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

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

Track Govt. Stds NIST – FIPS 201 http://csrc.nist.gov/piv-program/fips201-supportdocs.html User identity [email protected] Issuance process Cross Certification

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

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

Policy / Process Legacy Integration HR systems New Hire Inter-agency transfer Agency transfer Temporary work force Contractor Retirement

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

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

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?

What happens @ 10K feet Smart Card Logon SC Reader Reader 4 LSA accesses smart card and retrieves cert from card Card insertion causes Winlogon to display GINA 8 Smart card decrypts the TGT using private key allowing LSA to log user on User inputs PIN 3 GINA passes PIN to LSA 7.5 verifies DC certificate 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 Kerberos Kerberos LSA 6 KDC verifies certificate then looks up principal in DS KDC

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 !

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

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

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

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

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?

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

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

Smartcard Lifecycle Deployment Stages Initial Issuance PIN unblock Renewal Retirement Revocation Forgotten Smart Card

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?

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

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

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?

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!

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!

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

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

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

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