Wall SSW 2006

Two Factor Authentication: Planning considerations and best practices Or The other half of Identification / Authentication and Authorization: 

Two Factor Authentication: Planning considerations and best practices Or The other half of Identification / Authentication and Authorization Jon R. Wall (JWall@microsoft.com) Security IA USPS Federal Microsoft Corporation

eID – More Cards / Tokens to Carry? : 

eID – More Cards / Tokens to Carry?

Key Trends in Digital Identity…: 

Key Trends in Digital Identity… Number of Passwords Growing New Threats Emerging Mobile Identities On the Rise Applications Increasingly Connected

What is a eID?: 

What is a eID? A set of claims someone makes about me Many identities for many uses Required for transactions in real world and online Useful to distinguish from profiles

What is Government eID?: 

What is Government eID? Strong authentication tokens Large scale PKI deployments Public sector: eGovt, eHealth, Defense

eID Scenarios: 

eID Scenarios Woodgrove Bank Nicholas Smartcard + Reader / PIN pad Web Banking Windows Domain Logon Dial Corp Government eID MSN Smartcard Bank Smartcard … Government Tax Agency Abby Email, IM, … Issuance Name Address Submit/sign form …

Identity is Matched to Context: 

Identity is Matched to Context In Context Bank card at ATM Gov’t ID at border check Coffee / Tea card at stand MSN Passport at HotMail Out of Context? Gov’t ID at ATM SSN as Student ID MSN Passport at eBay Out of Context Coffee / Tea card at border check

Pick one? : 

Pick one? Identification Authentication Authorization

Key Lessons From the Past: 

Key Lessons From the Past Single technology, single provider solutions not broadly accepted Single technologies with multiple provider have not been universally deployed Multiple providers with multiple technologies has meant very little interoperability Is there no great answer?

Agenda part two : 

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

US Govt.: 

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.: 

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.: 

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 : 

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

Sample Deployed Architecture: 

Sample Deployed Architecture 3rd party Root issuing to human end entities MS CA issuing to infrastructure DC IPsec Machine Auth EFS Mobile Devices Remember NAP ---

Questions I Get : 

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

HSPD-12/FIPS 201: 

HSPD-12/FIPS 201

Goal: 

Goal Single Card for: Physical access Logical network access control S/MIME Now adding EFS Other Code signing Digital Signature

Track Govt. Stds: 

Track Govt. Stds NIST – FIPS 201 User identity 123456788@US.GOV Issuance process Cross Certification

User Certificate structure: 

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: 

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

Policy / ProcessLegacy Integration: 

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

CA Key roll over: 

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

Policy / ProcessPhysical Access: 

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

What happens @ 10K feetSmart Card Logon: 

User inputs PIN What happens @ 10K feet Smart Card Logon Card insertion causes Winlogon to display GINA 7.5 verifies DC certificate

What is Required The Basics: 

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: 

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

Policy / ProcessDeployment Considerations: 

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?

Use Case for testing: 

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: 

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: 

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

Exception Planning: 

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 : 

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: 

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 Limitations Current Challenges: 

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: 

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!

Smartcard Lifecycle Deployment Stages: 

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

PIN Unblock Planning Considerations: 

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: 

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: 

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: 

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?

eID Big Picture: 

eID Big Picture Smart Cards are a part but?

Identity Metasystem: 

Identity Metasystem An identity metasystem is framework that unifies the world of multiple identity technologies multiple operators and multiple implementations An identity metasystem enables users to manage identity in a heterogeneous world

The Laws of IdentityEstablished Through Industry Dialogue: 

The Laws of Identity Established Through Industry Dialogue User control and consent Minimal disclosure for a defined use Justifiable parties Directional identity Pluralism of operators and technologies Human integration Consistent experience across contexts Join the discussion at www.identityblog.com

Vision - Connected: 

Vision - Connected Take quantum step in interoperability Beyond hand-wired LDAP and Kerberos Identity is key service in SOA Align with industry movement Laws of Identity and Identity Metasystem Web services industry momentum WS-* Web services for identity and access Holistic connected systems architecture Claims-based identity and access model

Benefits of Metasystem: 

Benefits of Metasystem Use identity technology already deployed today Not an identity technology, but a way to negotiate and encapsulate identity technology Reuse existing Kerberos, SAML, X.509, and more Through claims transformation, add support for future identity technologies Transform from one format to another Transform from one set of semantics to another Do so without need to rip and replace Actively involve the end user Good privacy characteristics

Empowers the User…: 

Empowers the User…

Brings Technologies Together…: 

Brings Technologies Together… Smartcards Self-issued identities Corporate identities Government identities Passport identities Liberty identities Client applications Operating systems Network access systems Governments Organizations Companies Individuals Mobile phones Computers Hard ID tokens … and everything else

Identity Metasystem: 

Identity Metasystem Provides customer with freedom of choice Technology choice (x509, Kerberos, SAML, …) Provider choice (Self-issued, private, government…) Customers can use what works best for them Current systems and technologies (Kerberos, x509) New systems and technologies (e.g. Liberty, …) Enables simple movement from past to future Works with existing infrastructures and technologies Embraces new infrastructures and technologies

Metasystem CharacteristicsRequirements for an identity metasystem: 

Metasystem Characteristics Requirements for an identity metasystem Enable relying party, subject, and identity provider to negotiate technical policy requirements Technology-agnostic way to exchange policies and claims between identity provider and relying party Trusted way to change one set of claims regardless of token format into another Consistent user interface across multiple systems and technologies

WS-* ArchitectureAn architecture for an identity metasystem: 

WS-* Architecture An architecture for an identity metasystem Composable Architecture for Web Services Broad participation across the industry Open, published, standards-track architecture Available royalty free Security token format neutral OASIS WS-Security specification is the basis x509, Kerberos, SAML 1.1, 1.2, 2.0, XrML … Dynamic system for exchanging claims WS-MetadataExchange, WS-SecurityPolicy, … Token and claim translation WS-Trust defines Security Token Services (STS)

Some Key WS-* Supporters: 

ANL Apache Project Arjuna BEA Blue Titan Software Boeing Canon Choreology CommerceOne Computer Associates Content Guard Cornell University Epson Feature Software Fujitsu Grand Central Hewlett-Packard IBM iDesign Intel Iona IPO Group KnowNow Layer 7 Lexmark Lockheed Martin Microsoft NEC Nokia OPC Foundation Oracle Ping Identity Quovadx (RogueWave) Reactivity Ricoh Roxio RSA Security SAP SeeBeyond Siebel Sonic Software Sun Systinet Tibco Univ of Sydney VeriSign Visa International Westbridge WRQ webMethods … Some Key WS-* Supporters

WS-* Architecture: 

WS-* Architecture Anyone can play Broad industry participation Published, royalty free specifications All major specs to be standards track in OASIS Protocol framework for connected systems Not just a point solution for a specific problem Composable framework for security, reliable messaging, transactions, and more Designed to scale from small devices to Internet scale services Designed for federation Claims-based identity model Designed with network boundaries in mind

WS-* Architecture: 

WS-* Architecture Designed to satisfy the requirements of the identity metasystem Security token format neutral OASIS WS-Security specification is the basis x509, Kerberos, SAML 1.1, 1.2, 2.0, XrML … Dynamic system for exchanging claims WS-MetadataExchange, WS-SecurityPolicy, … Token and claim translation WS-Trust defines Security Token Services (STS) Only technology we know of specifically designed to satisfy requirements of an identity metasystem

Identity Metasystem Support from Microsoft: 

Identity Metasystem Support from Microsoft WS-* Web Services Architecture Concrete architecture to build an identity metasystem “Indigo” Runtime for building distributed applications supporting an identity metasystem “InfoCards” Identity selector for Windows – safeguards users digital identity Active Directory Infrastructure for identity and access “InfoCards” “Indigo” Active Directory WS-* End-Users Developers IT Organizations

WS-* Metasystem Architecture: 

WS-* Metasystem Architecture Security Token Server WS-SecurityPolicy Security Token Server WS-SecurityPolicy ID Provider ID Provider Relying Party Relying Party Identity Selector

InfoCard Overview: 

InfoCard Overview Simple user abstraction For managing collections of claims: identity claims, membership claims, possession claims, … For managing keys for sign-in: strong computer generated keys instead of human generated passwords Grounded in real-world metaphor of physical cards Gov’t ID card, driver’s license, credit card, membership card, … Support both self-issued and managed cards Self-issued cards signed by user Example scenarios: EBay, Groove, … Managed cards signed by external authority Example authorities: AD, Visa, Government, AAA, … Implemented as secure subsystem Protected UI, anti-spoofing techniques, encrypted storage

InfoCard Benefits: 

InfoCard Benefits Consistent user experience Across self-issued and managed cards Across home and work scenarios (domain and non-domain) Establishes mutual trust between users and services Enhances privacy by putting user in control of disclosure of PII and mitigating against tracking interactions Mitigates phishing and identity theft Easy to use – including roaming and provisioning Leverages existing (e.g AD) managed deployments * PII = Personally Identifiable Information

Preview – “InfoCard”: 

Preview – “InfoCard”

Preview – “InfoCard”: 

Preview – “InfoCard”

Microsoft’s Implementation: 

Microsoft’s Implementation Data stored for each card in card collection Name, logo, names of claims available (not values) Address of identity provider, required credential Data stored in simple identity provider Name, address, email, telephone, age, gender User must opt-in InfoCard data not visible to applications Stored in files encrypted under system key User interface runs on separate desktop Managed identity provider may store information needed to generate claims

Microsoft’s Implementation: 

Microsoft’s Implementation Fully interoperable via published protocols With other identity selector implementations With other relying party implementations With other identity provider implementations Detailed implementation guide available

Slide65: 

The Identity Metasystem in Action

Summary: 

Summary Growing need for an electronic identity metasystem Patchwork of identity technologies Existing installations unlikely to change New technologies likely to be developed Emergence of a metasystem benefits all Customer choice of technology and operators Embraces existing and new technologies Seamless migration to new technologies WS-* enables an identity metasystem Microsoft metasystem infrastructure “Indigo” “InfoCard” Active Directory

Crypto Next Generation (CNG): 

Crypto Next Generation (CNG) In kernel or user mode, allows you to: Implement proprietary crypto algorithms Replace standard crypto algorithms Create Key Storage Providers (KSP) Meets Common Criteria and FIPS for strong isolation and auditing Certificate Server support for CNG: Issuing ECC Certificates (ECDSA, ECDH), support P-256, P-384 and P-521 curves Hashes: SHA-2 (256, 384, 512) PKI enrollment API support for CNG: Requesting ECC based certificates Smart Card support for CNG: ECC-only or ECC/RSA dual-mode cards

Protocols: OCSP Responder: 

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

Smart Card Certification Center: 

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

Slide70: 

© 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. 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 provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.