+ All Categories
Home > Documents > E-Authentication: The Need for Public and Private Sector Trust David Temoshok Director, Identity...

E-Authentication: The Need for Public and Private Sector Trust David Temoshok Director, Identity...

Date post: 31-Dec-2015
Category:
Upload: luke-armstrong
View: 222 times
Download: 1 times
Share this document with a friend
21
E-Authentication: The Need for Public and Private Sector Trust David Temoshok Director, Identity Policy and Management GSA Office of Governmentwide Policy The E-Authentication Initiative 3 rd Annual Conference on Technology & Standards May 3, 2006
Transcript

E-Authentication:The Need for Public and Private Sector Trust

David Temoshok Director, Identity Policy and Management

GSA Office of Governmentwide Policy

The E-Authentication Initiative

3rd Annual Conference on Technology & StandardsMay 3, 2006

2

Prioritize E-Government

• President’s Management Agenda:

1. Strategic Management of Human Capital

2. Competitive Sourcing

3. Improved Financial performance

4. Expanded Electronic Government

5. Budget and Performance Integration

• E-Government Act of 2002

• OMB Office of E-Government and Technology

3

Government to Govt. Internal Effectiveness and Efficiency Lead

1. e-Vital (business case) 2. Grants.gov3. Disaster Assistance and Crisis Response4. Geospatial Information One Stop 5. Wireless Networks

1. e-Training 2. Recruitment One Stop3. Enterprise HR Integration 4. e-Travel 5. e-Clearance6. e-Payroll7. Integrated Acquisition8. e-Records Management

President’s E-Gov Agenda

OPMOPMOPMGSAOPMOPMGSANARA

LeadSSAHHSFEMA

DOI

FEMA

Lead

GSATreasuryDoEDDOILabor

Government to Business1. Federal Asset Sales2. Online Rulemaking Management 3. Simplified and Unified Tax and Wage Reporting4. Consolidated Health Informatics 5. Business Gateway6. Int’l Trade Process Streamlining

Lead GSAEPA

Treasury

HHS

SBADOC

Cross-cutting Infrastructure: E-Authentication GSA

Government to Citizen1. USA Service 2. EZ Tax Filing 3. Online Access for Loans 4. Recreation One Stop5. Eligibility Assistance Online

4

E-Authentication Key Policy Considerations

For Government-wide deployment: No National ID No National unique identifier No central registry of personal information, attributes, or

authorization privileges Different authentication assurance levels are needed for different

types of transactions Authentication – not authorization

For E-Authentication technical approach: No single proprietary solution Deploy multiple COTS products – user’s choice Products must interoperate together Controls must protect privacy of personal information

5

Factor Token

Very High

High

Medium

Low

Employee Screening for a High Risk Job

Obtaining Govt. Benefits

Applying for a Loan

Online

Access to Protected

Website

PIN/User ID-

Knowledge

Strong Password

-Based

PKI/ Digital Signature

Multi-

Incre

ase

d $

Cost

Increased Need for Identity Assurance

Four Authentication Assurance Levelsto meet multiple risk levels -

6

FBCA PKI Trust List

FBCA PKI Trust List

Levels 1 &2 CSPs

Levels 3 &4 CSPs

FBCA

X-Certificatio

n

Levels 1 &2 OnlineApps & Services

Levels 3 &4 OnlineApps &Services

SDT

A VERY Simplified View of the Federal EAI Architecture

EAI SAMLTrust List

EAI SAMLTrust List

BanksFinancial Inst.UniversitiesAgency AppsCommercial CSPs

CAF

Digital Certificates

Digital Certificates

SAML Assertions

Federal Agency PKIsOther Gov PKIsCommercial PKIsPKI Bridges

(HSPD-12)

One-Time PasswordsMulti-Factor Authentication

PIN, PasswordsUser ID

7

GovernmentsFederal

States/LocalInternational

Higher EducationUniversities

Higher EducationPKI Bridge

HealthcareRHIOsNHIN

Healthcare providers

Travel Industry AirlinesHotels

Car RentalTrusted Traveler Programs

Central Issue with Federated Identity – Who do you Trust?

E-Commerce Industry ISPs

Internet AccountsCredit Bureaus

eBay

Trust Network

Financial Services IndustryHome Banking

Credit/Debit Cards

Absent a National ID and unique National Identifier, the e-Authentication initiative will establish trusted credentials/providers at determined assurance levels.

280 Million AmericansMillions of BusinessesState/local/global Govts

8

Federation Infrastructure

• Interoperable Technology (Communications) Determine intra-Federation communication architecture Administer common interface specifications, use cases, profiles Conduct interoperability testing ( as needed) according to the specifications Provide a common portal service (I.e., discovery and interaction services)

• Trust Establish common trust model Administer common identity management/authentication policies for

Federation members• Business Relationships

Establish and administer common business rules Manage relations among relying parties and CSPs Manage compliance/dispute resolution

9

Government Adoption of Federated IDM

Necessary in order to meet President’s E-Gov mandates GSA is directed to provide common authentication infrastructure for all

Federal E-Gov business applications and E-access control.

In 2004 GSA established the EAI Federation EAI Federation allows identity federation between multiple industry and

government entities and the Federal Government Technical architecture supports multiple authentication technologies,

protocols, and IDM software products and components

In 2004 GSA partnered with industry to establish the Electronic Authentication Partnership

Incorporated non-profit public/private sector forum to advance and accelerate IDM federation

Focuses on interoperability and trust EAP Trust Framework issued 12/04

10

Industry and EAI ID Federation/Authentication Alignment

The Federal Government is seeking to align with industry in the following ways in order to meet the mandates for government-wide e-Authentication services:

Common trust framework for reciprocal trust

Common business & operating rules for business interoperability

Common technical infrastructure (i.e., architecture, protocols, data models, testing) for technical interoperability

Common business models for ID federation adoption/interoperability.

11

EAI/EAP Common Trust Framework

1. Establish & define authentication risk and assurance levels

• EAI: OMB M-04-04 - Established and defined 4 authentication assurance levels as Governmentwide policy• EAP: Adopted OMB M-04-04 authentication assurance levels

2. Establish technical standards & requirements for e-Authentication systems at each assurance level

• EAI: NIST Special Pub 800-63 Authentication Technical Guidance – Established authentication technical standards at 4 established assurance levels• EAP: Adopted NIST SP 800-63 standards

3. Establish methodology for evaluating authentication systems at each assurance level

• EAI: Credential Assessment Framework – Standard methodology for assessing authentication systems of credential service providers• EAP: Service Assessment Criteria – Standard methodology for assessing authentication systems of credential service providers

5. Perform assessments and maintain trust list of trusted CSPs

• EAP: Trusted CSP List• EAI: Trusted CSP List (pending)

6. Establish common business rules for approved CSPs

• EAI: EAI Federation Business Rules and Service Agreements• EAP: EAP Business Rules and Agreements

12

Key Architecture Design Considerations

No central registry of personal information, attributes, or authorization privileges – decentralized approach means federation.

Different authentication assurance levels are needed for different types of transactions.

Architecture must support multiple authentication technologies.

Architecture must support multiple protocols.

Federal Government will not mandate a single proprietary solution, therefore, Architecture must support multiple COTS products.

Federal Government will adopt prevailing industry standards that best meet the Government’s needs.

All architecture components must interoperate with ALL other components.

Controls must protect privacy of personal information.

13

Standards Convergence

SAML 1.X - Framework for exchanging security information about a principal: authentication, attributes, authorization information

Liberty ID-FF 1.X – Extend SAML 1.0, 1.1 for federation, SSO, web services

ShibbolethSpecification

LibertySpecifications

OASIS SAML 1.0, 1.1

OASIS Standard SAML 2.0

14

Federal Interoperability Lab

Tests interoperability of products for participation in e-Authentication architecture. Conformance testing to Fed e-Authentication Interface Specification Interoperability testing among all approved products

Currently 11 SAML 1.0 products on Approved Product List. See URL: http://cio.gov/eauthentication

Multiple protocol interoperability testing will be very complex

4 Products approved for PKI certificate path discovery & validation

GSA intends to continue to test architecture components for interoperability and capability to meet governmentwide use requirements

15

The Approach to a U.S. Federal PKI

Allow Agencies to implement their own PKIs

Create a Federal Bridge CA using COTS products to bind Agency PKIs together

Establish a Federal PKI Policy Authority to oversee policy and operation of the Federal Bridge CA

Ensure directory compatibility

Use ACES for transactions with the public

Use PKI Shared Service Providers for internal Federal Government provisioning

Approve commercial products for certificate validation (local, hosted)

16

University PKI

A Snapshot of the U.S. Federal PKI

Treas.PKI Higher Education Bridge CA

NASA PKIWF PKI Illinois PKI

CANADA PKI

Federal Bridge CA

ACES PKI

DOD PKI

DOE PKI

DOS PKI

University PKIUniversity

PKI

GPO PKI

PTO PKI

USDA PKI

17

IDP

IDP IDP IDP

IDP

IDP

SP/RP

SP/RP SP/RP

SP/RP

SP/RP SP/RP

SP/RPSP/RP

EAP Vision: Multiple, Interoperable Federations

Federation 1 Federation 2

EAP

Common Governance

Common Trust Framework & Rules

Common Architecture & Interoperable Products

18

EAI/EAP Alignment

EAI EAPCommon Assurance Levels

Common Authentication Standards

Reciprocal CSP Trust CertificationsCommon Designated Assessors

Common Business Rules

Common ArchitectureCommon Protocols

Common Data Models

2004

2005

2006

2007 Joint Pilots And Projects

CSP AssessmentsCSP Trust Lists

2008

Common Business Model

EAI Projects EAP Projects

19

Cross-Federation Trust Certifications FiXs trust certifications will be made at assurance level 4+, as FiXs will be certifying against FIPS 201/HSPD-12

standards/requirements.

EAP may determine to accept FiXs certifications as meeting EAP SAC level 4 authentication assurance

Federal EAI may determine to accept FiXs and/or EAP certifications as meeting EAI CAF level 4 authentication assurance

FiXs TrustCertifications

EAP TrustCertifications

EAI TrustCertifications

20

And then there’s HSPD-12 …

Homeland Security Presidential Directive 12 (HSPD-12):

“Policy for a Common Identification Standard for Federal Employees and Contractors”

Dated: August 27, 2004

21

For More Information

● Visit our Websites: http://www.cio.gov/eauthentication http://www.cio.gov/ficc http://www.cio.gov/fbca http://www.cio.gov/fpkipa http://csrc.nist.gov/piv-project/ http://www.cio.gov/fpkisc http://www.eapartnership.org http://www.smart.gov/

● Or contact:David TemoshokDirector, Identity Policy and Management [email protected]


Recommended