A New and Improved Unified Field Theory of Trust

1. A New and Improved Unified Field Theory of Trust

2. Topics • PKI Conference 03: REthinking Trust Flashback • New and improved unified field theory of trust • Looking at the data • Federation • P2P • Virtual organizations and authorizations • Next year’s talk… • Interfederation Issues • Federated PKI • Progressive PKI • Diagnostic hell

3. Unified field theory of Trust • Bridged, global hierarchies of identification-oriented, often government based trust – laws, identity tokens, etc. • Passports, drivers licenses • Future is typically PKI oriented • Federated enterprise-based; leverages one’s security domain; often role-based • Enterprise does authentication and attributes • Federations of enterprises exchange assertions (identity and attributes • Peer to peer trust; ad hoc, small locus personal trust • A large part of our non-networked lives • New technology approaches to bring this into the electronic world. • Distinguishing P2P apps arch from P2P trust • Virtual organizations cross-stitch across one of the above

4. Federated administration • Given the strong collaborations within the academic community, there is an urgent need to create inter-realm tools, so • Build consistent campus middleware infrastructure deployments, with outward facing objectclasses, service points, etc. and then • Federate (multilateral) those enterprise deployments with interrealm attribute transports, trust services, etc. and then • Leverage that federation to enable a variety of applications from network authentication to instant messaging, from video to web services, from p2p to virtual organizations, etc. while we • Be cautious about the limits of federations and look for alternative fabrics where appropriate.

5. Federated administration VO VO O T A CM O T CM A Campus 1 Campus 2 T T T Federation

6. Peer to peer trust • A bedrock of human existence • Completely intuitive, sometimes contradictory and soft around the edges • Translation into technology is difficult • PGP and webs of trust most successful • X.509 Proxy Certs a new, odd option • Issues over transitivity, integration into applications, user management are hard • Some new technologies, embedded within MS Longhorn, present an option that will have a large embedded base…

7. Virtual Organizations • Geographically distributed, enterprise distributed community that shares real resources as an organization. • Examples include team science (NEESGrid, HEP, BIRN, NEON), digital content managers (library cataloguers, curators, etc), life-long learning consortia, etc. • On the continuum from interrealm groups (no real resource management, few defined roles) to real organizations (primary identity/authentication providers) • Want to leverage enterprise middleware and external trust fabrics

8. Leveraging V.O.s Today VO User Federation Enterprise Target Resource

9. Leveraged V.O.s Tomorrow VO User Collaborative Tools Authority System etc Federation Enterprise Target Resource

10. Looking at the data • Federation update • Federating software • Types of federations • InCommon • Other federations • P2P • V.O.’s • Authority Systems

11. Shibboleth Status • Open source, privacy preserving federating software • Being very widely deployed in US and international universities • Target - works with Apache(1.3 and 2.0) and IIS targets; Java origins for a variety of Unix platforms. • V2.0 likely to include portal support, identity linking, non web services (plumbing to GSSAPI,P2P, IM, video) etc. • Work underway on intuitive graphical interfaces for the powerful underlying Attribute Authority and resource protection • Likely to coexist well with Liberty Alliance and may work within the WS framework from Microsoft. • Growing development interest in several countries, providing resource manager tools, digital rights management, listprocs, etc. • Used by several federations today – NSDL, InQueue, SWITCH and several more soon (JISC, Australia, etc.) • http://shibboleth.internet2.edu/

12. Federations • Associations of enterprises that come together to exchange information about their users and resources in order to enable collaborations and transactions • Enroll and authenticate and attribute locally, act federally. • Uses federating software (e.g. Liberty Alliance, Shibboleth, WS-*) common attributes (e.g. eduPerson), and a security and privacy set of understandings • Enterprises (and users) retain control over what attributes are released to a resource; the resources retain control (though they may delegate) over the authorization decision. • Several federations now in construction or deployment

13. InCommon federation • Federation operations – Internet2 • Federating software – Shibboleth 1.1 and above • Federation data schema - eduPerson200210 or later and eduOrg200210 or later • Becomes operational mid-April, with several early entrants to help shape the policy issues. • Precursor federation, InQueue, has been in operation for about six months and will feed into InCommon • http://incommon.internet2.edu

14. Rutgers University University of Wisconsin New York University Georgia State University University of Washington University of California Shibboleth Pilot University at Buffalo Dartmouth College Michigan State University Georgetown Duke The Ohio State University UCLA Internet2 Carnegie Mellon University National Research Council of Canada Columbia University University of Virginia University of California, San Diego Brown University University of Minnesota Penn State University Cal Poly Pomona London School of Economics University of North Carolina at Chapel Hill University of Colorado at Boulder UT Arlington UTHSC-Houston University of Michigan University of Rochester University of Southern California InQueue Origins2.12.04

15. InCommon Management • Operational services by I2 • Member services • Backroom (CA, WAYF service, etc.) • Governance • Executive Committee - Carrie Regenstein - chair (Wisconsin), Jerry Campbell, (USC), Lev Gonick (CWRU), Clair Goldsmith (Texas System), Mark Luker (EDUCAUSE),Tracy Mitrano (Cornell), Susan Perry (Mellon), Mike Teetz, (OCLC), David Yakimischak (JSTOR). • Project manager – Renee Frost (Internet2) • Membership open to .edu and affiliated business partners (Elsevier, OCLC, Napster, Diebold, etc…) • Contractual and policy issues being defined now… • Likely to take 501(c)3 status

16. Trust in InCommon - initial • Members trust the federated operators to perform its activities well • The operator (Internet2) posts its procedures, attempts to execute them faithfully, and makes no warranties • Enterprises read the procedures and decide if they want to become members • Origins and targets trust each other bilaterally in out-of-band or no-band arrangements • Origins trust targets dispose of attributes properly • Targets trust origins to provide attributes accurately • Risks and liabilities managed by end enterprises, in separate ways

17. InCommon Trust - ongoing • Use trust  Build trust cycle • Clearly need consensus levels of I/A • Multiple levels of I/A for different needs • Two factor for high-risk • Distinctive requirements (campus in Bejing or France, distance ed, mobility) • Standardized data definitions unclear • Audits unclear • International issues

18. Trust pivot points in federations • In response to real business drivers and feasible technologies increase the strengths of Campus/enterprise identification, authentication practices Federation operations, auditing thereof Campus middleware infrastructure in support of Shib (including directories, attribute authorities and other Shib components) and auditing thereof Relying party middleware infrastructure in support of Shib Moving in general from self-certification to external certification

19. Balancing the operator’s trust load • InCommon CA • Identity proofing the enterprise • Issuing the enterprise signing keys (primary and spare) • Signing the metadata • InCommon Federation • Aggregating the metadata • Supporting campuses in posting their policies

20. InCommon Federation Operations • InCommon_Federation_Disaster_Recovery_Procedures_ver_0.1 • An outline of the procedures to be used if there is a disaster with the InCommon Federation. • Internet2_InCommon_Federation_Infrastructure_Technical_Reference_ver_0.2 • Document describing the federation infrastructure. • Internet2_InCommon_secure_physical_storage_ver_0.2 • List of the physical objects and logs that will be securely stored. • Internet2_InCommon_Technical_Operations_steps_ver_0.35 • This document lists the steps taken from the point of submitting CSR, Metadata, and CRL to issuing a signed cert, generation of signed metadata, and publishing the CRL. • Internet2_InCommon_Technical_Operation_Hours_ver_0.12 • Documentation of the proposed hours of operations.

21. InCommon CA Ops • CA_Disaster_Recovery_Procedure_ver_0.14 • An outline of the procedures to be used if there is a disaster with the CA. • cspguide • Manual of the CA software planning to use. • InCommon_CA_Audit_Log_ver_0.31 • Proposed details for logging related to the CA. • Internet2_InCommon_CA_Disaster_Recovery_from_root_key_compromise_ver_0.2 • An outline of the procedures to be used if there is a root key compromise with the CA. • Internet2_InCommon_CA_PKI-Lite_CPS_ver_0.61 • Draft of the PKI-Lite CPS. • Internet2_InCommon_CA_PKI-Lite_CP_ver_0.21 • Draft of the PKI-Lite CP. • Internet2_InCommon_Certificate_Authority_for_the_InCommon_Federation_System_Technical_Reference_ver_0.41 • Document describing the CA.

22. InCommon Key Signing Process • 2. Hardware descriptions         a. Hardware will be laptop and spare laptop with no network capabilities, thumb drive, CDRW drive, media for necessary software 3. Software descriptions         a. OS, OpenSSL, CSP, Java tools for meta data 4. Log into computer 5. Generation of the CA Private Root key and self-signing 6. Generation of the Metadata signing key 7. Generate CSR for Internet2 origin 8. Signing of new metadata sites and trusts files 9. Backup copies of all private keys and other operational backup data are generated. 10. Verify CD's and MD5 checksum 11. Write down passphrase and put in envelopes and sign envelopes 12. Securely store CA hardware and contents of local safe in safe 13. Log that these actions occurred on the log in safe and then close and lock the safe 14. Put thumb drive into secure db and copy data onto secure db 15. Take private key password archive and other contents to Private Key Password safe deposit box and record in log that this was done. 16. Take operational data archive to Operation Data safe deposit box and record in log that this was done.

23. InCommon Process Tech Review • As a technical review group, we, the undersigned, reviewed the processes and the following components documenting the operations of InCommon, and discussed them with the Internet2 Technical and Member Activities staff. To the best of our knowledge and experience, with no warranty implied, we believe the operational processes and procedures Internet2 provided are acceptable to begin the operations of InCommon. • Scott Cantor, OSU • Jim Jokl, UVa • RL Bob Morgan, UW • Jeff Schiller, MIT

24. The potential for InCommon • The federation as a networked trust facilitator • Needs to scale in two fundamental ways • Policy underpinnings need to move to normative levels among the members; “post and read” is a starting place… • Inter-federation issues need to be engineered; we are trying to align structurally with emerging federal recommendations • Needs to link with PKI and with federal and international activities • If it does scale and grow, it could become a most significant component of cyberinfrastructure…

25. Beyond web services… • Federated security services • Collaborative incident correlation and analysis • Trust-mediated transparency and other security-aware capabilities • Federated extensions to other architectures • Lionshare project for P2P file sharing • IM • Federated Grids

26. P2P arch over federated trust -Lionshare • P2P file sharing application that is: Enterprise-based – uses authentication and campus directory and resource discovery Federated – works between institutions, using local authentication and authorization Learning object oriented – meta-data based; linked to digital repositories, courseware, etc. • Developed at Penn State University, now being extended with assistance from Mellon Foundation, Internet2, OKI, Edusource • URL is http://lionshare.its.psu.edu/main/

27. Virtual organizations • Need a model to support a wide variety of use cases • Native v.o. infrastructure capabilities, differences in enterprise readiness, etc. • Variations in collaboration modalities • Requirements of v.o.’s for authz, range of disciplines, etc • JISC in the UK has lead; solicitation is on the streets (see (http://www.jisc.ac.uk/c01_04.html); builds on NSF NMI • Tool set likely to include seamless listproc, web sharing, shared calendaring, real-time video, privilege management system, etc.

28. Stanford Authz Model

29. Signet Deliverables The deliverables consist of • A recipe, with accompanying case studies, of how to take a role-based organization and develop apprpriate groups, policies, attributes etc to operate an authority service • Templates and tools for registries and group management • a Web interface and program APIs to provide distributed management (to the departments, to external programs) of access rights and privileges, and • delivery of authority information through the infrastructure as directory data and authority events.

30. Home

31. Grant Authority Wizard

32. Person

33. Next year’s talk • Lots of if’s even in the premise… • Interfederation issues • V.O.’s over P2P trust • Federated and progressive PKI • Diagnostic Hell

34. Inter-federation Issues • Clearly in the cards • Some reduction of complexity can be done up front • Using standard technology assessment methodologies • Using standard policy frameworks • Some is not problematic • Different objectclasses are fine • Different transport (Shib, WS-*, Liberty, SAML) technologies may be fine • Much appears hard • Different assessment values for authn approaches • Different authn requirements for similar resources • Different privacy policies

35. V.O.’s over P2P trust • P2P trust is ubiquitous (e.g. file sharing, IRC) and unraveling (viruses, abuses) • We’ll be working on V.O.’s over federated trust • If new P2P trust tools work (controlled, integrated with apps, etc.) then V.O.’s over P2P trust represent a huge win in scaling.

36. Federated and progressive PKI • Federated • Thin USHER – heavy id proofing of enterprises; tight operations, little policy assertion • Local PKI and SAML/InCommon interrealm • Progressive PKI • How can we build a PKI that allows, even facilitates, growth in trust levels? • N-tuples of LOA’s? Stochiastic LOA’s?

37. Middleware DiagnosticsProblem Statement • The number and complexity of distributed application initiatives and products has exploded within the last 5 years • Each must create its own framework for providing diagnostic tools and performance metrics • Distributed applications have become increasingly dependent not only on the system and network infrastructure that they are built upon, but also each other • When what you’re selling is integration and transparency, and it doesn’t work…