Administering the Mesh/s of Trust: Old Whine in New Battles

Agenda unified theory of trust global identity federated-enterprise P2P untangling the concepts (trust/risk/liability/security/privacy) update on current events (InCommon, InQueue, Usher, HEBCA) trust and authorization - the Stanford approach discussion

Trust fabrics Exists in almost every transaction between entities Works in complex fashion E.g. in an end-user-enterprise-target transaction, user trusts enterprise to release attributes according to user preferences Enterprise trusts user to protect their security credentials Enterprise trusts target to properly dispose of attributes once they are used Target trusts enterprise to faithfully provide attributes about the user Trust itself is personal and subjective, though laws and contracts affect that. One size didn’t fit all and proved intractable; several sizes seem more comfortable and may prove more tractable

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. Virtual organizations could leverage any of these fabrics

Federations and Classic PKI They are very similar Both imply trust models Federations are a enterprise-enterprise PKI Local authentication may well be end-entity certs Name-space control is a critical issue And they are very different End user authentication a local decision Flat set of relationships; little hierarchy Focus as much on privacy as security Web Services only right now: no other apps, no encryption We get to define…

Update on current activities Federations Federation basics and federating software systems InCommon and InQueue – Shibboleth-based federations Other Shibboleth-based federations USHER-C4 and USHER-Basic certificate services HEBCA

What are federations? Associations of enterprises that come together to exchange information about their users and resources in order to enable collaborations and transactions Built on the premise of Initially “Authenticate locally, act globally” Now, “Enroll and authenticate and attribute locally, act federally.” Federation provides only modest operational support and consistency in how members communicate with each other 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. Over time, this will all change…

The good Very flexible – easy to establish and operate; can work for 2 or 2000 members Very customizable – tailored to fit the precise membership Address the whole problem space – security, data schema, privacy, security, transport – of inter-realm collaborations Are relatively simple to install and operate, both for enterprises and for end-users

The bad They aren’t real, yet They don’t do everything Are web services based right now Will hit scaling walls in several dimensions; we don’t see clear answers yet…

The unknown The scaling walls How reality will unfold The convergence of the various federating software solutions Users’ willingness to manage their privacy and security

Three Types of federation Internal federations are occurring among the many subsidiaries of large companies, especially for those companies with more dynamic aggregations. Private federations occur among enterprises, typically within a market sector, that want to facilitate a specific set of transactions and interactions. Many will be bi-lateral, short-term or otherwise constrained. Public federations address more free-standing, long-term, general-purpose requirements, and need to be more open about rules of engagement. Public federations face significant scaling issues and may not be able to leverage contractual relationships that private federations can.

Requirements for federations Federation operations Federating software Exchange assertions Link and unlink identities Federation data schema Federation privacy and security requirements

Federating Software Liberty Alliance Shibboleth WS-* V 1.1 of their functional specs released; 2.0 under discussion Federation itself is out of scope (see PingID et al) Semi-open source under development Current work is linked identities Shibboleth V1.1 released; 2.0 under discussion Most standards-based (though Liberty has said that they will turn their enhancements into standards organizations) Pure open source Current work is attribute release focused. WS-*

WS-* Work by Microsoft, with participation from IBM and BEA et al Complex framework, consisting of 9 areas, which can form a whole cloth solution to the problem space, but which need to closely interact with each other to do so. Several of the specifications areas still unreleased Standards process very unclear; significant IPR issues exist No implementations yet; indeed a lofty set of abstractions that will need considerable convention and detail to resolve into a working instantiation Can Shibboleth/InCommon be a working instantiation within WS-*? Good question. Once MS has all the areas defined, if someone wants to see whether the existent Shib/InCommon (or Shib/someotherfed) fits into WS-*, we’d certainly be curious…

Interoperability among federations Or, more precisely, interoperability between two members of distinct federations Ability to pass each other assertions Protocols and architectures Ability to understand each other’s assertions Syntax and semantics of objectclasses and schema Ability to trust each other’s assertions Er……

Shibboleth-based federations InQueue InCommon Club Shib SWITCH NSDL ------------------------------------ State networks Medical networks Financial aid networks Life-long learning communities

The Research and Education Federation Space REF Cluster InQueue (a starting point) InCommon SWITCH The Shib Research Club Other national nets Other clusters Other potential US R+E feds State of Penn Fin Aid Assoc NSDL Indiana Slippery slope - Med Centers, etc

InQueue The “holding pond” Is a persistent federation with “passing-through” membership… Operational today. Can apply for membership via http://shibboleth.internet2.edu/ InQueue Federation guidelines Requires eduPerson attributes Operated by Internet2; open to almost anyone using Shibboleth in an R&E setting or not… Fees and service profile to be established shortly: cost-recovery basis

InCommon A persistent, multipurpose federation for US R&E Two stage set up process Direction setting group to establish InCommon Chaired by Greg Jackson, includes 5-6 campus CIO’s, 1-2 target CTO’s Decisions on organizational structure, membership, management InCommon going forward Management group Storefront and backend; fees Operations Operational date within a month or two

InCommon key issues Who is the membership? Origins? Targets? Univ? Application or Content Service Providers? How is membership packaged and priced? How are membership covenants enforced? How is InCommon operated? What kind of entity is InCommon?

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

The CA formerly known as CREN Lots of discussion for a looong time – HEPKI-TAG, HEBCA-BID, PKI Labs Plan is finally emerging A few related certificate services USHER-C4 - soon USHER Basic - start detailed planning for implementation USHER CP Others if warranted, eventually All operate on high levels of assurance in I/A of the institution, and in their internal operation Place varying degrees of pain, and power, to the institutions Helping on a packaging of open-source low-cost CA servers Work with EDUCAUSE on their related initiatives

Usher-C4 Modeled after Federal Citizen and Commerce CP/CPS (www.cio.gov/fpkipa/documents/citizen_commerce_cpv1.pdf) Issues only institutional certs Those certs can be used for any purposes CP will place few constraints on campus operations User identification and key management Campus CA/RA activities Will be operated itself at high levels of confidence Will recommend a profile for campus use Good for building local expertise, insuring some consistency in approaches among campuses, and may be suitable for many campus needs and some inter-campus uses Will not work for signing federal grants, etc… Operational soon

Usher-Basic Modeled after FBCA Basic level CP Issues only institutional certs Those certs can be used for most purposes CP will place more constraints on campus operations User identification and key management Campus CA/RA activities Will be operated itself at high levels of confidence Will recommend a profile for campus use Good for many campus needs, many inter-campus uses, and many workings with the federal government Will peer at the HEBCA Detailed planning now starting; stand up sometime mid-next year

HEBCA A higher education equivalent of the Federal Bridge Constructs policy mappings and cross-certificates among peers Peers are assumed to be commercial CA’s, the FBCA, higher ed hierarchies, campus CA’s… Operates at the highest level of confidence, can accommodate high assurance certs Developed by the HEBCA-BID Managed by the HEPKI Council, Jack McCredie Chair… EDUCAUSE project

Overall Trust Fabric

Early version HEBCA FBCA USHER-BASIC USHER -C4