Ken Klingenstein

Director, Internet2 Middleware and Security

Middleware and Security Update

Since we last talked…

Middleware• Unified field theory of trust• Shibboleth and InCommon• Signet – an authority system• Diagnostics• Corporate dimensions

– Tech transfer– Trust relationships– Government interactions

Security• Strategic emphasis for Internet2, within the context of STF• Formation of Salsa and its working groups• Federated Security Services• Corporate dimensions

– R&D in federated services– Is there a business model?

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.• Distinguishing P2P apps arch from P2P trust

Virtual organizations cross-stitch across one of the above

Shibboleth Status

Open source, privacy preserving federating software, developed by an I2 wg and implemented by I2 universities

Being very widely deployed in US and international universities Work underway on intuitive graphical interfaces for the powerful

underlying Attribute Authority and resource protection Likely to coexist well with Liberty Alliance and may work within the

WS framework from Microsoft. Growing use and development interest in several countries,

providing collaboration tools V1.0 released april 03; v1.2 release next week; v2.0 likely top of the

line… http://shibboleth.internet2.edu/

Federations Associations of enterprises that come together to exchange

information about their users and resources in order to enable collaborations and transactions

Enroll and authenticate and attribute locally, act federally.

Uses federating software (e.g. Liberty Alliance, Shibboleth, WS-*) common attributes (e.g. eduPerson), and a security and privacy set of understandings

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.

Several federations now in construction or deployment

InCommon federation

Federation operations – Internet2

Federating software – Shibboleth 1.1 and above

Federation data schema - eduPerson200210 or later and eduOrg200210 or later

Becomes operational April 5, with several early entrants to help shape the policy issues.

Precursor federation, InQueue, has been in operation for about six months and will feed into InCommon

http://incommon.internet2.edu

InQueue Origins2.12.04

Rutgers University

University of Wisconsin

New York University

Georgia State University

University of Washington

University of California Shibboleth Pilot

University at Buffalo

Dartmouth College

Michigan State University

Georgetown

Duke

The Ohio State University

UCLA

Internet2

Carnegie Mellon University

National Research Council of CanadaColumbia UniversityUniversity of VirginiaUniversity of California, San DiegoBrown UniversityUniversity of MinnesotaPenn State UniversityCal Poly PomonaLondon School of EconomicsUniversity of North Carolina at Chapel HillUniversity of Colorado at BoulderUT ArlingtonUTHSC-HoustonUniversity of MichiganUniversity of RochesterUniversity of Southern California

InCommon Management

Operational services by I2• Member services • Backroom (CA, WAYF service, etc.)

Governance • Executive Committee - Carrie Regenstein - chair (Wisconsin), Jerry

Campbell, (USC), Lev Gonick (CWRU), Clair Goldsmith (Texas System), Mark Luker (EDUCAUSE),Tracy Mitrano (Cornell), Susan Perry (Mellon), Mike Teetz, (OCLC), David Yakimischak (JSTOR).

• Project manager – Renee Frost (Internet2)

Membership open to .edu and affiliated business partners (Elsevier, OCLC, Napster, Diebold, etc…)

Contractual and policy issues being defined now… Likely to take 501(c)3 status

The potential for InCommon

The federation as a networked trust facilitator

Needs to scale in two fundamental ways• Policy underpinnings need to move to normative levels among the

members; “post and read” is a starting place…• Inter-federation issues need to be engineered; we are trying to align

structurally with emerging federal recommendations

Needs to link with PKI and with federal and international activities

If it does scale and grow, it could become a most significant component of cyberinfrastructure…

Beyond web services…

Federated security services• Collaborative incident correlation and analysis • Trust-mediated transparency and other security-aware capabilities

Federated extensions to other architectures• Lionshare project for P2P file sharing• IM• Federated Grids

P2P arch over federated trust -Lionshare

P2P file sharing application that is:Enterprise-based – uses authentication and campus directory and

resource discovery

Federated – works between institutions, using local authentication and authorization

Learning object oriented – meta-data based; linked to digital repositories, courseware, etc.

Developed at Penn State University, now being extended with assistance from Mellon Foundation, Internet2, OKI, Edusource

URL is http://lionshare.its.psu.edu/main/

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; solicitation is on the streets (see (http://www.jisc.ac.uk/c01_04.html); builds on NSF NMI

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

Signet - an authority system

As the number and complexity of applications grow, so does the burden of administering permissions within them

A key juncture of end-user, system owner and auditor interests; a big win if done with business process reengineering

Applicable to enterprise applications as diverse as SIS, Financials, Calendaring, Course Management, Electronic Key Access, etc.

Potentially of value to virtual organizations as diverse as Grids and museum curator associations.

Based on pioneering work now in production at Stanford, being generalized and upgraded with NSF NMI grant funds; pilots later this spring

Stanford Authz Model

Signet Deliverables

The deliverables consist of A recipe, with accompanying case studies, of how to take a role-based organization and develop apprpriate groups, policies, attributes etc to operate an authority serviceTemplates and tools for registries and group managementa 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.

Home

Grant Authority Wizard

Diagnostics

The job no one wants to do, but is critical to successful and scalable enterprise and federated deployments of almost all technologies.

Hard to sell until too late, after the pain has set in…

There is a need for an integrated approach to performance, security and middleware diagnostics.

Internet2 is working hard right now to figure out how:• To integrate efforts• To get traction in areas that are too busy inventing to work on

diagnostics

Steps to Enable Diagnostic Applications

Establish the common event record

Enable the collection of events from a wide array of event sources

• Network: NetFlow, SNMP, RMON, etc• Security: IDS, Snort, firewalls, etc• Applications: Shib, Dir, IM, P2P, smtpd, named, httpd, Kerberos,

etc• Hosts: /var/log/*, Syslog, etc

Steps to Enable Diagnostic Applications (2)

Build tools to create dissemination infrastructures that,• Allows access to the diagnostic data• Provides operators to filter, anonymize, aggregate, tag, store and

archive the data• Enables pipelining of data operators to organize and manipulate

diagnostic data based on an organization or federations policies• Provide a common API so applications can access the diagnostic

data

Enabling Diagnostic ApplicationsWith a Common Event Descriptor

Security Related Events

Middleware Related Events

Network Related Events

Collection and Normalization of Events

Dissemination Network

Diagnostic applications (Middleware, Network, Security) can extract event data form multiple data sets

Diagnostic Data Pipelining

Data flows can be constructed to provide the desired function and policy within a enterprise or federation

Filter

C-4

Network Events

ArchiveDBAnonimizationTagging AggregationNormalization

C-3

C-1

P-1C-2

P-2

P-3

P-4

P-5

C-* Collection Module HostP-* Processing Module Host

Host or Security Events

Event Record

Event Descriptor Meta Field

Event Descriptor

• Version Number• Observation Description Pointer• ID – unique event identifier• Time - start/stop• IP Address(es) – source/(destination)• Source Class – application, network, system, compound, bulk, management• Event Name Tag – Native language ID, user defined• Status – normal, informational, warning, measurement, critical, error, etc. • Major Source Name – filename, Netflow, Syslogd, SNMP, shell program, etc.• Minor Source Name – logging process name (named), SNMP variable name, etc.• Raw Data Encoding Mechanism – Binary, ASN1, ASCII, XML, etc.• Raw Event Data Description Pointer

Raw Event Data

Event Record

Event Descriptor Meta Field

Event Descriptor

• Observation Description Pointer• Address type of observer (IPV4, IPV6, MAC, etc.)• Address of observer• Address type of collection agent (IPV4, IPV6, MAC, etc.)• Address of collection agent• Source Type (file, stream, polled, interrupt)• Collection agent name (Netflow.1.0, named.2.3, etc.)

Raw Event Data

Event Record

Event Descriptor Meta Field

Event Descriptor

• Raw Event Data Description Pointer• Schema of raw event data• Parsing expression pointer

Raw Event Data

Event Record

Event Descriptor Meta Field

Event Descriptor

• Event Name Tag – (null), user defined (can be multiple tags)• Examples:

• “astronomy-app”• “ShibUserHandle=foo”• “DormTraffic”• “Worm-W32B”• “AMP”• “MS-UPDATE-34333”• “IE-Patch-2343”

Raw Event Data

Event Record Overhead

Event Descriptor Meta-Field

Event Descriptor Raw Event Data

• Version Number – 1 byte • Observation Description Pointer – 4 bytes• ID – 10 bytes• Time – 24 or 12 bytes• IP Address(es) – (8 or 16 bytes) * 2 for IPV6• Source Class – 1 byte• Event Name Tag – 0 to 16 bytes typical (can be as large as 256) • Status – 1 byte • Major Source Name – 0 to 32 bytes typical (can be as large as 256) • Minor Source Name – 0 to 16 bytes typical (can be as large as 256)• Raw Data Encoding Language - 1 byte• Raw Event Data Description Pointer – 4 Bytes

Security Policy Discovery

Probing the Destination

Firewall

Pros• Actively tests a configuration of a device or path

Cons• Cannot discover past the first device that is blocking• Destination being probed may think it is under attack

Probe

Security Policy Discovery

Publishing Policy

Pros• Fast and simple method for discovering policy• Can look beyond the first blocking device

Cons• Policy may not be up-to-date• Publishing policy may be looked at as an exposure

Policy Publisher

Security Policy Discovery

Using Diagnostic Event Records

Org 2 Records

Pros• Provides a audit trail of actions• Enables repudiation by letting two organizations,

• share data through a common event record• can anonomize sensitive data

Cons• Organizations must be willing to share data• Passive auditing enough, active methods can augment

Org 1Records

Example – Shib failure

Get a Shib failure message due to• Network performance problem• Firewall settings• Host down• Misconfigured Shib installation

“Shire failure”

Where are diagnostics done and remedies applied?

MW Corporate Dimensions

Tech transfer

Trust business relationships

Government interactions

Security

Designated as a strategic direction for Internet2 last fall

Intended to complement and augment other activities within the EDUCAUSE/Internet2 Security Task Force

Build on the success of the NSF-sponsored Security at Line Speed workshop

A thread as much as a workgroup; staffing is reallocated I2 personnel, corporate fellows, and a clone

Created Salsa as member-driven steering group

http://security.internet2.edu

Salsa Membership

Mark Poepping - Carnegie Mellon University (chair)

Chris Cramer - Duke UniversityGary Dobbins - University of Notre DameTerry Gray - University of WashingtonChris Misra - University of MassachusettsDoug Pearson - Indiana UniversityJim Pepin - University of Southern CaliforniaJames Sankar (European liaison) - UKERNAJeff Schiller - Massachusetts Institute of TechnologyJoe St. Sauver - University of OregonSteve Wallace - Indiana University

Salsa Work Groups

Security Architecture – Marty Schulman (Juniper), Chair• Establish a common reference model and nomenclature• Frame the tradeoffs• As part of the early activities, create a body of discussion and

practice around “DNS-based, application oriented new networking ideas”

Network Authn/z – Chris Misra (UMass), Chair• First task is to create a set of effective practices around “campus

network registration” • Seond task likely to begin work responsive to the “visiting scientist

problem” and the Terena JRA5 activities

Federated Security Services and Capabilities

A potentially significant addition to our security portfolio, but like everything else already there, not a magic bullet.

Couples shared backbones (Abilene, NLR, Terragrid, etc.) with a common trust fabric (InCommon); leverages Abilene Observatory and REN-ISAC

Two goals• Collaborative security tools and analyses• Security aware capabilities that permit science and innovation to

continue despite security barriers

Developed as a response to an NSF CyberTrust solicitation, but ready to be marketed elsewhere (DHS, industry)

Corporate dimension

R&D possibilities

Is there a business model (internal or external) for federated security services?

Ken Klingenstein

Director, Internet2 Middleware and Security

Internet2 Webinars

Internet2 Webinars

New seminar program

Designed for corporate member audience

“Low-tech” – phone, web browser

Security and Middleware topics

Pilot series of 3 monthly webinars

Launch May 19, 2004

Internet2 Webinars

“Securing Advanced Corporate Networks”

May 19, 2004 at 2:00 p.m. EDT

Eric Metalla, McAfee Research• New security technologies for advanced networks

TBA, Ford Motor Company• Network architectures for advanced security

Ken Klingenstein, Internet2• Internet2-led security activities

Internet2 Webinars

“Deploying and Supporting Federations”-- June

“Privilege Management”-- July

Internet2 Webinars

http://webinar.internet2.edu