1. 1 1 Interoperating: MIT’s Fusion Center Prototype & JHU/APL’s Back End Attribute Exchange (Identity Management Testbed) January 2013

2. 2 Agenda What is the MIT prototype? – Accountable Systems concept – Prototype mechanism – Scenario #1 Integrating with JHU/APL IdM Testbed – Goals – Achievements – Observations 2

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

4. 4 Accountable Systems 4 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.

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

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

7. 7 Prototype Concept 7 Internet Sender Organization Recipient’s Organization User Profiles User Docs SENDER Reasoner Data Policies User Profiles User Docs Data Policies RECIPIENT

8. 8 Transitioning from Prototype to Pilot The Prototype mechanism had limited decentralization of data – Directories on the same server were used to model different servers 8

9. 9 Prototype First Implementation 9 Internet Sender Organization SENDER Reasoner Data Policies User Profiles User Docs Recipient Organization Data Policies User Profiles User Docs RECIPIENT

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

11. 11 Web Sender’s Organization (MIT) Sender’s Organization (MIT) 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) BAE

12. 12 Project Implementation 12 Web Sender Organization SENDER Reasoner Data Policies User Docs Recipient Organization Data Policies User Docs RECIPIENT User Profiles (JHU/APL) BAE User SSL Certificates (MIT)

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

14. 14 Step #1: Prototype URL 14 Mia types in the URL for the IdM version of the MIT Prototype and presses “Enter”

15. 15 Step #1 - Under the Hood: User SSL Certificate The tool finds Mia’s SSL certificate …. 15

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

17. 17 Step #2 – Under the Hood: URI is a cgi Script to Fetch Attributes 17 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 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 http://dig.csail.mit.edu/2010/DHS-fusion/MA/profiles/MiaAnalysa#me

18. 18 Step #2 – Under the Hood: Attributes Served 18 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 http://dice.csail.mit.edu/idm/idm_query.cgi?c=US&st=Massachusetts&o=Massachusetts%20State% 20Police&cn=Mia%20Analysa#me c (Country) = US st (State) = Massachusetts o (organization) = Massachusetts State Police cn (Common Name) = Mia Analysa

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

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

21. 21 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). 21

22. 22 Step #4: Request for Information (RFI) Mia chooses the document she wishes to send. 22

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

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

25. 25 Step #5 – Under the Hood: Recipient’s Attributes JHU’s server returns Feddy’s attributes for use. 25

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

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

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

29. 29 Lalana Kagal: lkagal “at” csail.mit.edu K. Krasnow Waterman: kkw “at” mit.edu Questions? 29