Scaling Interoperable Trust through a Trustmark Marketplace

Transcription

1 Scaling Interoperable Trust through a Marketplace John Wandelt Georgia Tech Research Institute This work was performed under the following financial assistance award 70NANB13H189 from the U.S. Department of Commerce, National Institute of Standards and Technology

2 NASCIO Survey on ID Management CIOs say that the most significant barriers to adoption of an enterprise IAM strategy are: The decentralized environment of the state The cost of doing so The complexity of legacy systems The lack of governance

3 Persons Non-Persons Logical Access Physical Access Scope of FICAM & SICAM

4 Need to Defy Gravity

5 Id&AM Frameworks Need to Evolve

6 Past, Present, and Future Legacy State of Practice State of Technology State of Need Application Enterprise Federation Ecosystem Application Application Specific Access Control Lists Scale Organization and Governance of Interest Enabling VPN, Virtual Technology PKI, SAML, Trust Directories, etc. Authorization Role Based Access Control Community Frameworks, etc. Attribute Based Access Control Cross Sector Marketplace? Framework Policy Based Access Control

7 NSTIC Pilot Team

8 In the Beginning Lots of Application-Specific Identity Silos

9 Along Came Federated Identity Decouple Identities from Applications! Attribute Provider Identity Provider Standard Protocols Application Application (Service Application Provider) (Service Application Provider) (Service Application Provider) (Service Provider) (Service Provider) User So what about Trust, Liability, Security?

10 And Today Lots of Federated Identity Silos

11 Current State of the Identity Ecosystem AP Many Each Trust There Frameworks exist requires many are Trust agreement monolithic Frameworks. across and many opaque. dimensions. AP ISE A ID Trust Framework A ID Trust Framework C Community of Interest C AP Federation B ID Trust Framework B

12 Achieving Cross-Framework Trust Suppose this user needs access to this. AP AP ISE A ID Trust Framework A ID Trust Framework C Community of Interest C AP In today s ID Ecosystem, there are at least five ways to do it Federation B ID Trust Framework B and all of them face challenges.

13 Challenges with Inter-federation Federation Federation Why? 1. No two TFs are the same, so mapping trust and interop requirements between them is hard. Think protocols, attributes, policies, etc. 2. TFs are moving targets, which further complicates the mapping process. 3. Transitive trust is diluted trust, so inter-federation trust cannot be as strong as intra-federation trust. 4. Contractual obligations usually cannot be transferred or assigned to 3 rd parties, which makes inter-federation legal agreements difficult or impossible to execute. (Many other issues exist.)

14 The Perspective from the LE Community Law Enforcement COI has over 1 million people in the US alone Over 10,000 US LE agencies Required to share data across jurisdictions But must obey applicable access controls when sharing Trust between agencies is a fundamental requirement LE agencies are autonomous (NOT centrally funded) 3 rd party trust is required due to COI size and complexity Most users must have high-assurance credentials Federal Agencies LE agencies are highly heterogeneous State Agencies Local Agencies Legitimate business need to interact with many other COIs Tribal Agencies Task Forces Fusion Centers

15 The Perspective from the LE Community

16 The Perspective from the LE Community State ISE SICAM Critical Infrastructure Health ISE AP AP AP AP AP AP

17 Many Other Relevant Initiatives FICAM Federal Identity, Credential, and Access Management NIEF Technical specs and policies are aligned with FICAM NIEF has submitted formal application to be approved as a FICAM Trust Framework LOA 2 and non-pki LOA 3 SICAM State Identity, Credential, and Access Management SICAM currently only provides high-level guidance Leverages FICAM and FICAM TFP initiatives NIEF working with NASCIO to further mature SICAM through NIEF Quick Start program and NIEF NSTIC pilots BAE Backend Attribute Exchange NIEF one of first operational BAE pilots in partnership with GSA, PM-ISE, TX DPS, RISS, IIR NIEF has adopted BAE profile for Attribute Providers PIV/PIV-I Personal Identity Verification Under the sponsorship of DHS S&T and in partnership with JHAPL, GTRI developed a proof of concept Gateway between the PIV-I community and NIEF. Also Leverages the BAE to collect additional attributes not on the PIV-I card NSTIC National Strategy for Trusted Identities in Cyberspace NIEF selected by NIST to be a NSTIC pilot to demonstrate Scalable Trust and Interoperability through a Marketplace Scope is broader than FICAM but leverages FICAM

18 Where to from here?

19 ID Ecosystem Vision Is it OK if the Trust Frameworks in the ID Ecosystem are mostly non-interoperable and non-trusting identity silos?

20 ID Ecosystem Vision Or is there a viable strategy and framework for trust and interoperability between various COIs, ISEs, and Federations?

21 What about a Framework? If the frameworks were modular ID Trust Framework A ID Trust Framework B ID Trust Framework C FICAM FIPPs NIST OAuth OpenID SAML SSO LOA 3 then we get: FIPS 200 Greater transparency of trust framework requirements Greater ease of comparability between frameworks Greater potential for reusability of framework components And, most importantly: Greater potential for participation in multiple trust frameworks by ID Ecosystem members with incremental effort and cost

22 What about a Framework? ID Trust Framework A ID Trust Framework B ID Trust Framework C FICAM FIPPs NIST OAuth OpenID FIPS 200 SAML SSO LOA 3 These modular components are called s.

23 Scope of s FICAM SAML SSO Profile NIST / FICAM LOA 3 Identity Fair Information Practice Principles (FIPPs) FIPS 200 Security Practices GFIPM Metadata Registry (User Attributes) Policies & Agreements

24 A -Based ID Ecosystem AP AP AP ID Trust Framework A Trust Interoperability Profile A ID Trust Framework B Trust Interoperability Profile B ID Trust Framework C Trust Interoperability Profile C Rather than requiring each a community monolithic, can formalized define a Trust TIP. Framework

25 A -Based ID Ecosystem TIP A TIP B TIP C AP AP AP Provider Provider Then each Some There member s can of be the can many community Providers be acquired may can acquire the necessary Providers through specialize s a in the in issuing ID based Ecosystem. Provider. one the TIP. particular. Others may offer many s. Provider Provider Provider Provider Provider Provider Provider Provider Provider Provider

26 A -Based ID Ecosystem TIP A TIP B TIP C AP AP AP Members of the ID Ecosystem Provider can query a Registry to answer questions such as: Provider What other members This of s collection the ID Ecosystem of can actors be stored have and the entities in a necessary s to meet is searchable the MY trust requirements? Marketplace. Registry. Provider What s must I acquire to meet the trust requirements of <MEMBER>? Provider Provider Provider X: Y: Etc. Registry

27 What is a trustmark framework? Stakeholder Community Is Used By Provider Issues Is Represented By Trust Interop Profile Defining Organization Recipient A B C Is Trusted By Defines Is Required By Definition Is Required By Org. 1 Relying Parties Org. 2 End User

28 Parallels between s and PKI Framework Concept Provider Recipient Relying Party Policy Agreement Defining Organization Definition Trust Interoperability Profile Analogous Concept from PKI Certificate Certificate Authority Subscriber Certificate Relying Party / Audience Certificate Policy Subscriber Agreement ITU (Agency that defined X.509) IETF RFC 5280 (X.509 Spec) List of Trusted Certificate Authorities

29 Defines basic structure of Conforms to Defines structure of Conforms to Defines structure of Conforms to The Framework in More Detail Spec Is used by Definition Spec Trust Interoperability Profile Spec Instance Defines assessment criteria for Definition Instance Is used by Trust Interoperability Profile Instance

30 Definitions Conformance Criteria: Conformance to the Identity Provider Organization (O) conformance target of this TD requires the following. 1. The O MUST 2. The O MUST 3. The O MAY 4. Assessment Process: XML Metadata: Publisher: U.S. General Services Administration Name: NIST/FICAM LOA 2 O TD URL: <URL> Description and Intended Purpose: Target Stakeholder Audience: Date of Publication: 15 Apr 2014 Version: 1.0 Visual Icon: Before issuing a trustmark subject to this TD, a Provider MUST complete the following assessment steps. 1. The TP MUST 2. The TP MUST 3. The TP MUST Extension Schema: s issued subject to this TD MUST conform to the Base Schema, and MUST also conform to the following Extension Schema. XSD XML Certification as a Provider: Before an entity may issue trustmarks subject to this TD, it MUST complete the following certification process. 1. The entity MUST 2. The entity MUST 3. The entity MUST? XML XML

31 A Sample TIP Instance Trust and Interoperability Criteria: Identity Provider Organization (O) Requirements: Requirement Approved Providers FICAM SAML SSO MUST HAVE NIEF NIEF/FICAM LOA 2 O NIEF Attribute Profile O MUST HAVE MUST HAVE NIEF or Deloitte (ANY) XML XYZ Privacy Policy O SHOULD HAVE (ANY) Service Provider Organization (SPO) Requirements: Requirement Approved Providers FICAM SAML SSO SP NIEF Attribute Profile SPO XYZ Privacy Policy SPO MUST HAVE MUST HAVE MUST HAVE NIEF (ANY) (ANY) Metadata: Publisher: U.S. Dept. of Justice URL: <URL> Name: U.S. Law Enforcement Community Info Sharing TIP Description and Intended Purpose: Date of Publication: 15 Jun 2014 Version: 1.0 Digital Signature of Issuer: <SIGNATURE>

32 s What? Where? TDO

33 Sources of Components

34 FICAM InCommon NIEF GFIPM CSDII Others Creating Modular Common Components Step 1: Gather trust and interop requirements from many frameworks Step 2: Break down and reassemble requirements into modular, reusable components Transformation Process Step 3: Express modularized requirements in a standard format to encourage broad reuse Definition Definition Definition

35 GTRI NSTIC Pilot Analysis 94 distinct trustmarks identified (so far) Covers FICAM, NIEF, and Other NSTIC Pilots Also covers FIPPs (privacy) topics

36 s By Category Identity Assurance Policy Security Policy Privacy Policy Attribute Assurance Policy Technical Interoperability Organizational Integrity / Bona Fides Technical Trust Usability

37 Scope of the NSTIC Pilot Concept Maturation Concept Presentation Pilot Concept Website Outreach to IDESG Outreach to NIEF Membership Outreach to SICAM Stakeholders Outreach to Other Stakeholders Framework Normative Spec Normative TD Spec Normative TIP Spec Policy Template Agreement Template Sample TDs, TIPs, and s Comm. Protocol TDs & s Identity LOA TDs & s End-User Privacy TDs & s Security Policy TDs & s Other TDs & s Sample TIPs for NIEF Community Sample Tools Assessment Tool for Providers Generating & Publishing Tool for Providers Registry Query Tool NIEF Pilot 5 6 Issue s to Current NIEF Members Modify Tech Framework, Specs, TDs, TIPs, Policies, Agreements, and Tools as Needed Expanded Pilot via NASCIO/SICAM Identify SICAM Use Cases Issue s to More s, APs, and s via a New Provider Demonstrate SICAM Use Cases in a Multiple--Provider Marketplace

38 NIEF Moving Forward Legacy State of Practice State of Technology State of Need Application Enterprise Federation NIEF Ecosystem Application Application Specific Access Control Lists Scale Organization and Governance of Interest Enabling VPN, Virtual Technology PKI, SAML, OpenID, Directories, etc. Authorization Role Based Access Control Community etc. Attribute Based Access Control Cross Sector Marketplace Framework Policy Based Access Control

39 The NIEF QuickStart Program Drive broader adoption and implementation GFIPM, FICAM, and NIEF standards among state agencies. Streamline the onboarding process to lower cost and barriers to adoption. Demonstrate the NIEF Framework as a viable approach to cross sector interoperable security, privacy, and trust.

40 Learn More Here

41 Some NIEF Members

42 High-Level Project Plan & Timeline Q Q Q Q Q Q Q Q Develop Concept Refine Concept as Needed Develop Framework Develop Sample TDs, s, and TIPs Refine Framework as Needed Refine TDs, s, and TIPs as Needed Develop and Refine Sample Software Tools Develop SICAM Use Cases & Scenarios Refine Use Cases & Scenarios Pilot in NIEF Outreach/Prep for Expanded Pilot Community Outreach Project Oversight & Reporting Expanded Pilot SICAM Demo