Middleware and Security Update
Ken Klingenstein
Director, Internet2 Middleware and Security
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 Origins
2.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 Canada
Columbia University
University of Virginia
University of California, San Diego
Brown University
University of Minnesota
Penn State University
Cal Poly Pomona
London School of Economics
University of North Carolina at Chapel Hill
University of Colorado at Boulder
UT Arlington
UTHSC-Houston
University of Michigan
University of Rochester
University 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 service
Templates and tools for registries and group management
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.
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 Applications
With a Common Event Descriptor
Diagnostic applications (Middleware, Network, Security) can extract event
data form multiple data sets
Dissemination Network
Collection and Normalization of Events
Middleware
Related Events
Network
Related Events
Security
Related Events
Diagnostic Data Pipelining
Data flows can be constructed to provide the desired
function and policy within a enterprise or federation
Host or
Security
Events
C-1
C-2
P-1
P-2
P-4
P-3
P-5
C-3
Network
Events
C-4
Filter
Tagging
Normalization
Aggregation
Anonimization
DB
Archive
C-* Collection Module Host
P-* Processing Module Host
Event Record
Event Descriptor Meta Field
Event Descriptor
Raw Event Data
• 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
Event Record
Event Descriptor Meta Field
Event Descriptor
Raw Event Data
• 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.)
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
Raw Event Data
• 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”
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
Probe
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
Security Policy Discovery
Publishing Policy
Policy
Publisher
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
Security Policy Discovery
Using Diagnostic Event Records
Org 1
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
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 University
Gary Dobbins - University of Notre Dame
Terry Gray - University of Washington
Chris Misra - University of Massachusetts
Doug Pearson - Indiana University
Jim Pepin - University of Southern California
James Sankar (European liaison) - UKERNA
Jeff Schiller - Massachusetts Institute of Technology
Joe St. Sauver - University of Oregon
Steve 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?
Internet2 Webinars
Ken Klingenstein
Director, Internet2 Middleware and Security
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