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 OTOT OTOT TT Apps CM CM Apps VO T Campus 1 Campus 2 Federation Other feds

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-*

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 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 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 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 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

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 Diagnostics Problem 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 Normalization And Event Tagging NETFLOW:TIME:SRC:DST:… RMON:HOST:TIME:DSTPORT.. DB:TIME:HOST:REQ:ASTRON SHIB:TIME:HOST:UID… GRIDAPP:TIME:HOST:UID:… Variable Star Catalog DB Application

EnterpriseFederation Alerting apps, filtering data to federation and API to NMS Reporting, Performance, and Forensic apps Application Host Diagnostic Host Federation specific reporting, performance and Forensic apps Massive collection, normalization, filtering or tagging Archive, querying Topological Architecture

Collection Management TLS App (Shibboleth) Log Unix/WIN Log Http Log Filter Anonymizer Aggregation Normalization Data to diagnostic host Instructions from Diagnostic 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 Archive Query 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 collection from application hosts Control and Diagnostic Application Platform Data Management and Internal Housekeeping SHIB HTTPS Shell TLS Diagnostic host communication Diagnostic Tools and NMS Diagnostic Module

NMS API Diagnostic Applications Rich tool platform and API that enables rapid development of diagnostic applications Control and Diagnostic Application Platform Security Risk Analysis Alerting and Notification Historical Analysis Reporting Tracing Forensic SHIB HTTPS Shell Diagnostic HostRemote 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 Authority System

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