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 • 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 EducationFederation Space

REFCluster

InQueue(a starting point)

InCommon

SWITCH

The ShibResearch Club

Other national nets

Other clustersOther

potential USR+E feds

State of Penn Fin Aid Assoc

NSDL

Slippery slope- Med Centers, etc

Indiana

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