1 1 Interoperating: MIT’s Fusion Center Prototype & JHU/APL’s Back End Attribute Exchange...

11

Interoperating: MIT’s Fusion Center Prototype &

JHU/APL’s Back End Attribute Exchange(Identity Management Testbed)

January 2013

2

Agenda

• What is the MIT prototype?– Accountable Systems concept– Prototype mechanism– Scenario #1

• Integrating with JHU/APL IdM Testbed– Goals– Achievements– Observations

2

33

MIT

• Massachusetts Institute of Technology• Computer Science & Artificial Intelligence Lab• Decentralized Information Group

The Decentralized Information Group explores the consequences of information on the Web: where it comes from, what happens to it, and what are the rules for using it. We build tools to help people control the policies governing information, and we build automated reasoning systems to help determine

whether information use complies with policy.

44

Accountable Systems

Ability for systems to:

• Determine whether each use of data is/was permitted • by the relevant rules• for the particular data, party, and

circumstance

• Make that decision available to access control, audit, and other technology • for real-time enforcement, retrospective

reporting, redress, and risk modeling.

55

Prototype

• Prior project built a working prototype of an accountable system technology

• Funded by DHS• Use cases were “fusion centers”

– Attempting to retrieve or send information protected by privacy statutes

66

Prototype: Principles• Real rules (e.g., statutes & regulations) require more information

to reach a decision than traditional access control mechanisms provide

• An accountable system must be able to access all decision-relevant information• Since decision-relevance varies by rule and situation, it would be unreasonable

to work towards placing all such data in a centralized repository• Therefore, an accountable system must be able to reach data in its pre-existing

decentralized locations

• Real rules require more complex reasoning than traditional access control mechanisms provide

• Rules are expressed in terms of conditions, exceptions, and context• Rules are not limited to access, but express many restrictions and permissions

in the context of use• Therefore, an accountable system must be able to express, manipulate, and

reason across a broad range of concepts

77

Prototype Concept

InternetInternet

Sender Organization

Sender Organization

Recipient’s Organization

Recipient’s Organization

User Profiles

User Docs

SENDER

Reasoner

Data Policies

User Profiles

User Docs Data Policies

RECIPIENT

88

Transitioning from Prototype to Pilot

• The Prototype mechanism had limited decentralization of data – Directories on the same server were used to

model different servers

99

Prototype First Implementation

InternetInternet

Sender Organization Sender Organization

SENDER

Reasoner

Data Policies

User Profiles

User Docs

Recipient Organization Recipient Organization

Data Policies

User Profiles

User Docs

RECIPIENT

1010

Transitioning from Prototype to Pilot

More closely modeling the “real world”:– Implementing a level of decentralization – Interoperating with and external security mechanism

to more closely model the “real world”

• Reasoner and Sender organization data on the MIT server

• Back end Attribute Exchange (BAE) authenticating and serving user profiles on the JHU/APL server

1111

WebWeb

Sender’s Organization(MIT)

Sender’s Organization(MIT)

Recipient’s Organization

Recipient’s Organization

User SSL Certificates

User Docs

SENDER

Reasoner

Data Policies

User Docs Data Policies

Project Concept

RECIPIENT

User Profiles

User SSL Certificates

(JHU/APL)(JHU/APL)

BAE

1212

Project Implementation

Web Web

Sender Organization Sender Organization

SENDER

Reasoner

Data Policies

User Docs

Recipient Organization Recipient Organization

Data PoliciesUser Docs

RECIPIENT

User Profiles

(JHU/APL)(JHU/APL)

BAE

User SSL Certificates

(MIT)(MIT)

1313

Demonstration Use Case

Mia (Massachusetts Fusion Center analyst) wants to send a Request for Information (containing protected Criminal Record Information) to Feddy Agenti (DHS).

1414

Step #1: Prototype URL

Mia types in the URL for the IdM version of the MIT Prototype and presses “Enter”

1515

Step #1 - Under the Hood:User SSL Certificate

The tool finds Mia’s SSL certificate ….

1616

Step #2: The UI….and uses it to auto-populate the UI

1717

Step #2 – Under the Hood:URI is a cgi Script to Fetch Attributes

• The URI for Mia is a cgi script which will cause her attributes to be fetched from JHU:

– The link “location” is http://dice.csail.mit.edu/idm/idm_query.cgi?c=US&st=Massachusetts&o=Massachusetts%20State%20Police&cn=Mia%20Analysa#me

• In the prior demo, the link was a literal: – http://dig.csail.mit.edu/2010/DHS-fusion/MA/profiles/MiaAnalysa#me

1818

Step #2 – Under the Hood:Attributes Served

• The URI for Mia is a cgi script which will cause her attributes to be fetched from JHU:

– The link “location” is http://dice.csail.mit.edu/idm/idm_query.cgi?c=US&st=Massachusetts&o=Massachusetts%20State%20Police&cn=Mia%20Analysa#me

c (Country) = USst (State) = Massachusettso (organization) = Massachusetts State Policecn (Common Name) = Mia Analysa

1919

Step #3: Sender’s AttributesJHU authenticates the “Massachusetts State Police” certificate it previously issued to MIT, and provides Mia’s attributes.

2020

Step #3: Sender’s AttributesFor reference, this is a quite different profile from the one in the MIT prototype:

2121

Step #3 - Under the Hood:SSL & XML SOAP -> RDF

• The cgi script calls a python script that serves the SSL key, issues an encrypted SOAP query and retrieves the “Distinguished Name” (DN) from the JHU/APL store, and converts from XML SOAP (the JHU format) to RDF (the MIT format).

2222

Step #4: Request for Information (RFI)

• Mia chooses the document she wishes to send.

2323

Step #4 – Under the Hood:Data - Request for Information (RFI)

• As in the original prototype, Mia identifies a pdf document that she wishes to send (the document was embedded with tags in xmp), and the UI populates the URL for the document.

2424

Step #5: Recipient’s Attributes• Mia identifies the person to whom she wishes to send the RFI, and the UI

populates URI for the cgi script again, this time seeking Feddy’s DN.

2525

Step #5 – Under the Hood:Recipient’s Attributes

JHU’s server returns Feddy’s attributes for use.

2626

Step #6: Compliance Result• The reasoner is able to process all of the input, and return its compliance result.

2727

Achievements

• MIT Prototype able to Interoperate with JHU Back End Attribute Exchange

– Able to serve appropriate certificates, create appropriate signatures

– Able to fetch the Distinguished Name from JHU– Able to convert RDF -> SOAP and SOAP -> RDF– MIT able to use the JHU served sender and receiver

attributes in the reasoning to achieve decisions

28

Observations

• JHU does not appear to control access to individual profiles– Access to the Policy Information Point (PIP) is restricted on what appears to

be an organizational/server-basis through the use of client certificates granted to the organization

– Once access to the PIP is achieved, there appear to be no restrictions on access to the information contained within (e.g., all profiles are accessible)

• MIT prototype looking for enhanced functionality from the BAE– Pattern matching for the authenticator– Ability to serve URIs for attribute names or values – Elimination of requirement to populate the attributes

in canonical order

2929

Lalana Kagal: lkagal “at” csail.mit.eduK. Krasnow Waterman: kkw “at” mit.edu

Questions?