The New Problem Space:Issues for the Future

Ken Klingenstein

Director, Internet2 Middleware and Security

Topics

Shib• Coordination of Shib development process

• Integration of InCommon into applications

Institutional use• Identity management systems: 0, 1, more…

• The closing of open shelves

• Impact of transparency on help desks

Interinstitutional use• Realizing federations

• Boundary uses of Shib

• Virtual organizations

• Federated security services

• Peering of federations

Coordination of Shib development

Development now taking place in several countries, with significant investments outside the original development crew.

A reasonable re-layering of architecture and code might be helpful

Management role models:• Likely: OpenLDAP, Apache• Less likely: GGF

Alignment of licensing and copyright could be challenging

Integration of InCommon into applications

Rethinking the architecture versus slapping on Shib

Moving campus-oriented systems into an inter-institutional model (authn is not in a desktop file…)

Providing authn/z for outsourced services

Campus identity management

Identity management systems are the key origin component

Many campuses still don’t have one; many have just one; some campuses have more than one

Can introduce significant user confusion• Which one do I select from the WAYF• What attributes get released from which origin

Closing of open shelves

Attribute based access control is a fine granularity, allowing campuses to perhaps reduce licenses costs by reducing eligible members

Is that desirable? Is that understandable by students? Are the management costs worth the license savings?

Do the content providers want this?

Do we need a policy on persistent targetID release standards?

Transparency and problems

Fine grain transparent access controls are going to be difficult to diagnose.

Right now, at least four different failure points result in the same Shib error message

• The target host is down• Network performance caused time out of the Shib protocols• Firewall blocked the ARP communications• Shib itself is misconfigured

And that error message sucks… (Shire not found)

Worst, fine grain access controls will be harder for coarse users…

Realizing federations

Concluding policy frameworks

Creating a widely endorsed and useful level of initial trust

Being able to grow that trust (in scale and in levels of assurance)

Limiting the complexity

Boundary uses of Shib

The Canoe Club wants to control access of some of its web content to other canoe clubs. Who decides what attributes they can get and vouch for the privacy handling?

Associated health clinics want to access Medline through the medical school contract. Who vouches for their authentication services?

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; builds on NSF NMI • see http://www.jisc.ac.uk/index.cfm?name=c01_04

Tool set likely to include seamless listproc, web sharing, shared calendaring, real-time video, privilege management system, etc.

Leveraging V.O.s Today

VO

Target Resource

User

Enterprise

Federation

Leveraged V.O.s Tomorrow

VO

Target Resource

User

Enterprise

Federation

Collaborative Tools Authority Systemetc

Federated Security Services

Federated networks• Share a common network substrate• Share a common trust fabric• Together they could permit…

Collaborative incident analysis and response• Network-wide views• Leveraged diagnostic help• Ability for automated tools to use distributed monitors• Protect privacy at several layers

Security-aware capabilities• Trust-moderated transparency• Integrated security/performance diagnostics

Moving it into the broader Internet

Collaborative Incident Analysis

Moving beyond the “border” to see network-wide views• I’m seeing activity X? Are others seeing it? What variants are they seeing?

Real-time attack recognition

• From the central observatory, let me see the full address of the attacking node at site Y in the federation

• I’m seeing an attack ostensibly from source address z at enterprise Y. Let me look at logging within site Y to verify

• Correlate signatures and traffic among sites A-Z to provide an early warning system of DDOS

• Let external experts from site Z examine our forensic information to assist our diagnostics

Requires federated backbone (meters, log files, etc) and federated trust fabric (for scaling, role-based access control, contact info, etc.)

Collaborative incident analysis

Scaling requires managing large data sets• Centralized – the Abilene Observatory, perhaps others• Distributed – on a per enterprise level

Which in turn requires a clear data model• Common event records, likely distilled and reformatted from native

logs• Is enterprise-level security sufficient

And also pluggable modules for harvesting records by tools

Tools that permit analysis and yet preserve privacyAnd also a trust fabric that permits multiple levels of

authentication and fine-grain authorization

Federated Security-aware Capabilities

Federated user network authentication for on-the-road science

Control spam through federated verification of sending enterprises

Tell me which firewall is dropping which service request

Permit end-end videoconferencing through firewalls and NATs

Allow enterprise-specific patching paradigms to coexist

Create end-end transparency for use of Grids

Personal firewall configuration based on authorization

Inter-federation issues

Managing the complexity

Nested federations – UT and InCommon

Overlapping federations - IHETS and InCommon

Peering federations

Touch points for federation peering

Cross map attributes

Correlate LOA’s

FOP <-> FOP Trust

Apps/trust matrix

Federations that could peer

Intra-campus federations

System federations (UT, SUNY, UC, UNC, etc.)

National federation (InCommon)

Other national federations (UK, Switch, Finland, Australia, Netherlands, FEIDE, etc.)

Federal federations

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

Upper Slaughter, England

International federation peering

Shibboleth-based federations being established in the UK, Netherlands, Finland, Switzerland, Australia, Spain, and others

International peering meeting slated for October 14-15 in Upper Slaughter, England

Issues include agreeing on policy framework, comparing policies, correlating app usage to trust level, aligning privacy needs, working with multinational service providers, scaling the WAYF function

Leading trust to Slaughter…