Middleware and Network Security Update:Progress, Problems, and Opportunities for Interaction

Agenda

•Middleware• Shibboleth and Federations• Video middleware• PKI• P2P• Opportunities for interactions

•Network Security• Security at Line Speed Workshop• SALSA• REN-ISAC interactions• Effective Practices• Opportunities for interactions

•Middleware and Network Security interactions• Network authn/z and its uses

Middleware Background

•Core Concepts•Maps•The Approach•The Results•The Upcoming Work

• Authority Systems• Virtual Organizations• Middleware Diagnostics

•Opportunities for Interactions

The Plan:Federated all the way down

•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 (mulitlateral) 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.

Internet2 Middleware:Key Concepts

•Use federated administration as the lever; have the enterprise broker most services (authentication, authorization, resource discovery, etc.) in inter-realm interactions•Develop a consistent directory infrastructure within R&E•Provide security while not degrading privacy.•Foster interrealm trust fabrics: federations and virtual organizations •Leverage campus expertise and build rough consensus•Influence the marketplace; develop where necessary•Support for heterogenity and open standards

Interrealm and intrarealm

•Intrarealm describes the services within an enterprise, such as a university or corporation. The services, such as authentication, authorization and directories, assume commonalities and trust.•Interrealm describes the relationships between autonomous systems or enterprises. No assumptions are made.•But of course, for most large universities, there are many pockets of semi-autonomy (colleges, medical schools and hospitals, athletic departments) and it may best be viewed as interrealm•And, of course, in large companies with many wholly-owned but acquired subsidiaries, the lack of a common infrastructure makes their architectures interrealm.

Upper and Core Middleware Land

Core Middleware Scope

•Identity and Identifiers – namespaces, identifier crosswalks, real world levels of assurance, etc.•Authentication – campus technologies and policies, interrealm interoperability via PKI, Kerberos, etc.•Directories – enterprise directory services architectures and tools, standard objectclasses, interrealm and registry services•Authorization – permissions and access controls, delegation, privacy management, etc.•Integration Activities – open management tools, use of virtual, federated and hierarchical organizations, enabling common applications with core middleware

Campus Core Middleware Architecture:(Origin perspective)

Federated administration

O

TO

T

T T

Apps CM CM Apps

VOVO

T

Campus 1Campus 2

Federation

Otherfeds

Landmark Work

•Convincing ourselves that we could do this and that it would make a difference…•Consensus standards – eduPerson, eduOrg, commObject•Best Practices and Deployment Strategies – LDAP Recipe, Group Management, Metadirectories•Tools – KX.509, LDAP Analyzer, LOOK•Software systems – OpenSAML, Shibboleth

The upcoming work

•Authorization• A group-oriented role based approach• Presumes enterprise has done some structuring of authorizations

and roles• Permits delegation, audit controls, etc.

– Implemented as attributes housed in directories– Anchored with registries for roles, policies, authorites, etc.

•Middleware Diagnostics

•Virtual Organization Support

The directory work

•Incent campuses to deploy directories, and to do so in a roughly consistent fashion: The LDAP Recipe and Middleware Business Plans•Create standards (syntax and semantics) for key inter-institutional attributes

• eduPerson• eduOrg• H.350 (nee commObj)

•Develop tools in support of those standards• LDAP Analyzer• Performance tools• Grouper

Shibboleth Milestones

•Project formation - Feb 2000 Stone Soup•Process - began late summer 2000 with bi-weekly calls to develop scenario, requirements and architecture.•Linkages to SAML established Dec 2000 •Architecture and protocol completion - Aug 2001 •Design - Oct 2001•Coding began - Nov 2001•Alpha-1 release – April 24, 2002•OpenSAML release – July 15, 2002•v1.0 April 2003•v1.1 July 2003•(V2.0 early 2004)

Personal Resource Manager

Privacy Management Systems

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…

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 and bad of federations

•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, transport, trust – of inter-realm collaborations•Are relatively simple to install and operate, both for enterprises and for end-users•-----------------------------------------------•Don’t address some trust needs – e.g. signing and encryption•Right now only web services•Interfederation issues•Convergence of federating software

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.•Standards process and IPR issues uncertain•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-*? Under active discussion with Microsoft

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 basics

• Permanent federation for the R&E US sector• Operated by Internet2, open to .edu-qualified sites and

business partners• Attributes passed: eduPerson• Privacy requirements:

• Initially, destroy received attributes immediatley upon use

• Security requirements:• Initially, enterprises post local I/A and basic business rules for

assignment of eduPersonAffiliation values• Likely to progress towards standardized levels of authn • Logout issues

InCommon

• Management – exec group of CIO’s and CTO’s• Operations

• Strong institutional I/A• High confidence WAYF operation• Low exposure if enterprise signing keys compromised• Indemnified project of Internet2 initially; coop or 501(c)3…

• Cost-recovery • Costs will depend on the level of InCommon work• Low risk level operations ~$1K/yr• Certifying operations potentially much higher

Trust pivot points in federations

•In response to real business drivers and feasible technologiesincrease the strengths of

Campus/enterprise identification, authentication practicesFederation operations, auditing thereofCampus middleware infrastructure in support of Shib (including

directories, attribute authorities and other Shib components) and auditing thereof

Relying party middleware infrastructure in support of ShibMoving in general from self-certification to external certification

Federated Applications

•Personal Privacy and Resource Managers•Digital rights management•Role-based access controls•Desktop videoconferencing•Interrealm calendaring•Authenticated instant messaging•P2P •Shibbed *

The Upcoming Work

•Generalizing the Stanford authority system•Middleware diagnostics•Virtual organizations

Stanford Authz Model

Stanford Authz Goals

•Simplification of authority policy, management and interpretation. We should be able to summarize the full rights and privileges of an individual "at a glance" or let departmental administrators view and manage together all authority in their department or division. •Consistent application of authority rules via infrastructure services and synchronization of administrative authority data across systems. •Integration of authority data with enterprise reference data to provide extended services such as delegation and automatic revocation of authority based on status and affiliation changes. •Role-based authority, that is, management of privileges based on job function and assignments rather than attached to individuals.

Deliverables

•The deliverables consist of •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.

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

Goals

• Create an event collection and dissemination infrastructure that uses existing system, network and application data (Unix/WIN logs, SNMP, Netflow©, etc.)

• Establish a standardized event record that normalizes all system, network and application events into a common data format

• Build a rich tool platform to collect, distribute, access, filter, aggregate, tag, trace, probe, anonymize, query, archive, report, notify, perform forensic and performance analysis

Cisco NetFlow Events

RMON Events

Event Record Standard

• Normalization of each diagnostic data feed type (SHIB, HTTP, Syslog, RMON, etc.) into a common event record

• The tagging of specific events to help downstream correlation processes

DB Access Log

SHIB log

HTTP Access log

GRID Application Log

NormalizationAnd EventTagging

NETFLOW:TIME:SRC:DST:…RMON:HOST:TIME:DSTPORT..DB:TIME:HOST:REQ:ASTRONSHIB:TIME:HOST:UID…HTTP:TIME:HOST:URL…GRIDAPP:TIME:HOST:UID:…

Variable Star Catalog DBApplication

Enterprise Federation

Alerting apps, filteringdata to federationand API to NMS

Reporting,Performance, and Forensic apps

Application Host Diagnostic Host

Federation specific reporting, performanceand Forensic apps

Massive collection,normalization,filtering or tagging

Archive, querying

Topological Architecture

Collection

Management

TLS

App (Shibboleth) Log Unix/WIN Log

Http Log

FilterAnonymizerAggregationNormalization

Data to diagnostic host

Instructions fromDiagnostic host

• Lightweight module that exists on application host or diagnostic host• Four data operators, each optional for a given stream• Normalization operator is specific to each input stream

Network (SNMP,NetFlow)

Operators

Input Stream Examples

DB

ArchiveQuery

TLS

• Dedicated to data collection, management, manipulation and installed on diagnostic host

• Hosts can be pipelined to disseminate processing load and enforce privacy policies

• Same data operators as Application Module, plus query and archive

Event collectionfrom application

hosts

Control andDiagnostic Application

Platform

Data Management andInternal Housekeeping

SHIBHTTPS

Shell

TLS Diagnostic hostcommunication

Diagnostic Toolsand NMS

Diagnostic Module

NMS API

Diagnostic Applications

• Rich tool platform and API that enables rapid development of diagnostic applications

Control andDiagnostic Application

PlatformSecurity Risk Analysis

Alerting and Notification

Historical Analysis

Reporting

Tracing

Forensic

SHIB

HTTPS

Shell

.

.

.

Diagnostic Host Remote or Local Applications

Involved Groups And Organizations

• Internet2• End-to-End Performance Initiative• Specific Middleware and GRIDS working groups

• SHIB, P2P, I2IM, etc.

• IETF working groups• SYSLOG• RMOMMIB

• Efforts in academic and research

Issues and Vision

• Privacy• Rich and diverse sets of event data can be used to infer

user behavior• Limiting access to this data and using data

anonymization methods is essential to insure the privacy of the end user, or an enterprise as a whole

• Intenet2 Diagnostic Infrastructure Initiative• Create a secure highly distributed set of services and

tools to aid in end-to-end problem, security, and performance analysis

• Establish an standard event record to be used as the basis for describing all network, system and application level anomalies and behavior

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 a continuum from interrealm groups (no real resource management, few defined roles) to real organizations (primary identity/authentication providers)•A required cross-stitch on the enterprise trust fabric

Leveraging V.O.s

VO

Target Resource

User

Enterprise

Leveraging V.O.s Today

VO

Target Resource

User

Enterprise

Federation

Leveraging V.O.s Today

VO

Target Resource

User

Enterprise

Federation

AuthoritySystem

Some Raging Successes

•Neutral, clueful ground in the federated identity management storm•Significant effect on the technical approaches of directory, XML, PKI and other standards•ITU and vendor adoption of H.350•Vendor-specific implementations of community standards•Interactions around Shibboleth with content and service vendors•Nth generation problems (deep linking, diagnostics)

Continuing Conundrums

•Need to work with corporate partners who are not members• Elsevier, Jabber

•Companies that take the clue and then split•Scalable ways to involve more companies•Consultants who take the clue

Opportunities and Issues

•Corporations joining InQueue and InCommon•Technology transfer

• If we’re to be believed, products can be built• Marketplaces need to be created

•Scalable ways of interaction• FOO• Telebriefings?

– To whom– About what– Packaging