Internet 2 Middleware Initiatives Early Harvest to Early

Internet 2 Middleware Initiatives: Early Harvest to Early Adopters and Beyond Renee Woodten Frost Project Manager, Middleware Early Adopters, Internet 2 Project Liaison, University of Michigan May 15, 2000

Topics Internet 2 Overview Middleware Application requirements - Digital libraries, Grids, IMS, Portals Early Harvest best practices Early Adopters Mace (Middleware Architectural Committee for Education) Experiments: the Directory of Directories, Eduperson, and Shibboleth PKI Medical middleware International Efforts Middleware Initiatives

Internet 2 Overview Mission: Develop and deploy advanced network applications and technologies, accelerating the creation of tomorrow’s Internet. Goals: • Enable new generation of applications • Re-create leading edge R&E network capability • Transfer technology and experience to the global production Internet Middleware Initiatives

Core Middleware A layer of software between the network and the applications • Authentication - how you prove or establish that you are that identity each time you connect • Identification - the first characteristics of who you (person, machine, service, group) are • Directories - where the rest of an identity’s characteristics are kept • Authorization - what an identity is permitted to do • Security - ie, PKI - emerging tools for security services Middleware Initiatives

Application Requirements Digital libraries need scalable, interoperable authentication and authorization. The Grid as the new paradigm for a computational resource, with Globus the middleware, including security, location and allocation of resources, scheduling, etc. built on top of campus infrastructures. Instructional Management Systems (IMS) need authentication and directories Next-generation portals want common authentication and storage Middleware Initiatives

Partnerships EDUCAUSE CREN Globus, Legion, etc. Campuses Professional associations - AACRAO, NACUA, etc. Middleware Initiatives

The Early Harvest experiences Identifiers for people, objects, groups Authentication for people, objects and groups Directories to store common information Authorization services Applications that use all of the above Complex design and implementation tradeoffs at technical and policy levels Middleware Initiatives

Early Harvest Outputs Identifier mapping Good practice documents on middleware web site, to guide campus IT organizations Informational RFC in June May form part of the basis for an assurance model for higher ed PKI Middleware Initiatives

Identifier Mapping Map campus identifiers against a canonical set of functional needs For each identifier, establish its key characteristics, including revocation, reassignment, privileges, and opacity Shine a light on some of the shadowy underpinnings of middleware Middleware Initiatives

Major campus identifiers UUID Netid Student and/or emplid Email address Person registry id Library/deptl id Account login id Publicly visible id (and pseudossn) Enterprise-lan id Pseudonymous id Middleware Initiatives

Identifier Characteristics Revocation - can the subject ever be given a different value for the identifier Reassignment - can the identifier ever be given to another subject Privileges - what accesses does the authenticated identifier have Opacity - is the real world subject easily deduced from the identifier - privacy and use issues Middleware Initiatives

Identifier relationships Library ID Enterprise-LAN ID Pub. Vis ID ISO card ID Student ID Email address Empl ID UUID Pseudo ID Acct login Departmental IDs Person registry ID Middleware Initiatives

Authentication Options Password based • Clear text • LDAP • Kerberos Certificate based Others - challenge-response, biometrics Middleware Initiatives

Typical Good Practices Have a UUID that is non-revocable, non-reassignable, opaque No clear text passwords Precrack new passwords using foreign dictionaries as well as US Confirm new passwords are different than old Require password change if possibly compromised Use shared secrets or positive photo-id to reset forgotten passwords Middleware Initiatives

Typical Interoperability Standards Use of dc (domain component) instead of X. 500 for naming of directory suffixes, certificate subjects, etc. Use of certain object class Future standardization of certificate profiles Middleware Initiatives

Directories: Core of the Core Overall campus directory services model Enterprise directory design and implementation Departmental directories Security and directories Middleware Initiatives

Enterprise directory issues Schema, referrals and redundancy Naming Attributes Replication and synchronization Groups Middleware Initiatives

Early Adopters: The Campus Testbed Phase A variety of roles and missions Commitment to move implementation forward Provided some training and facilitated support Develop national models of deployment alternatives Address policy standards Middleware Initiatives

Early Adopter Participants Dartmouth Michigan Tech Univ of Hawaii Univ of Pittsburgh Johns Hopkins Univ of Southern California Univ of Maryland, BC Tufts Univ of Memphis Univ of Tennessee, Memphis Univ of Michigan Middleware Initiatives

Primary Goals To facilitate the campus deployments of core middleware technologies To identify reasonable approaches - both technical and policy and design issues and factors that influence institutional selection of a particular approach To enrich the technical contents of Early Harvest To inform larger community (NSF, Education, NIH, etc) of requirements for deployment and interoperability Middleware Initiatives

Secondary Goals Explore medical middleware issues • Generic - how is this expressed in the core deployment • Specific - what medical data structures need integration into campus environment Outreach to encourage other institutions Research into options for authorization services Evaluate new tools and technologies Middleware Initiatives

Basic Approaches Technology sharing and workshops Policy sharing • champions • data owners • professional associations - EDUCAUSE, CUMREC, CNI, NACUA, NACUBO, AACRAO, ALA External experts Vendor interactions Middleware Initiatives

MACE (Middleware Architecture Committee for Education) Purpose - to provide advice, create experiments, foster standards, etc. on key technical issues for core middleware within higher ed Membership - Bob Morgan (UW) Chair, Steven Carmody (Brown), Michael Gettes (Georgetown), Keith Hazelton (Wisconsin), Paul Hill (MIT), Mark Mara (Cornell), Mark Poepping (CMU) Current working Groups • DIR - eduperson, the Uber-directory experiment • PKI - campus operational issues, trust models, f. PKI involvement • Shibboleth - inter-institutional resource sharing Middleware Initiatives

A Directory of Directories An experiment, now encompassing 10 schools, to build a combined directory search service • to show the power of coordination • to show the existing barriers to cooperation – standard object classes - standard display formats - standard meta-data • to investigate load and scaling issues - on the clients and the servers • to suggest the service to follow Middleware Initiatives

Edu-person An objectclass for higher education Contains suggested attributes for instructional, research and administrative inter-institutional use Presumes campuses to add local person objectclass. A joint effort of EDUCAUSE and I 2 Middleware Initiatives

Edu-person 0. 9 a Parent objectclass=inetorgperson Intends to integrate with Grid, IMS, and other upper-middleware Includes: • • primary affiliation (fac/stu/staff) enrolledcurrentterm (binary true/false) withdrawnpreviousterm (binary) schoolcollegename, (multivalued case ignore strings) Middleware Initiatives

Shibboleth Inter-institutional web authentication and perhaps authorization Use local credentials for remote services; enable user@ logins; fosters best practices; encourage transition from simple ht controls to LDAP-based Uses records in DNS and several forms of authentication; authorization via directories IBM to analyze, several schools to participate in pilot Middleware Initiatives

Authorization How an individual’s attributes are carried from an individual or a central store to an application Move from a per-application basis to an infrastructural service Options include • • • Kerberos tickets LDAP calls RPC’s long-term certificates attribute certificates Middleware Initiatives

PKI Public Key Certificates are a remarkably simple and powerful tool for • signing documents, authentication, encrypting email, building secure channels across the Internet, non-repudiation, conveying authorizations, and more Infrastructure to support this is little understood • mobility, user interface, internal formats, trust chains, revocation, policy expression Middleware Initiatives

Uses for Certificates Authentication and pseudo-authentication Signing docs Encrypting docs and mail Non-repudiation Secure channels across a network Authorization and attributes and more. . . Middleware Initiatives

Certificate Profiles Per field description of certificate contents - both standard and extension fields, including criticality flags Syntax of values permitted per field Semantics specified Spreadsheet format by R. Moskowitz, XML and ANS alternatives for machine use Centralized repository for higher ed being set up Middleware Initiatives

Certificate Policies Legal responsibilities and liabilities (indemnification issues) Operations of Certificate Management systems Best practices for core middleware Assurance levels - varies according to I/A processes and other operational factors Middleware Initiatives

Certificate Practice Statements Operational aspects that allow lawyers to decide who to trust must cover I/A, Cert Management, underlying operations Middleware Initiatives

PKI Activities DLF: UCOP, Columbia, soon Minnesota FPKI (http: //csrc. nist. gov/pki/twg/welcome. html) PKI for NGI, Globus net@edu within EDUCAUSE CREN CA In-sources - MIT, Michigan Out-sources - Pittsburgh, Texas PKIforum W 2 K Middleware Initiatives

Next Steps PKI Labs • long-term research agenda, includes path math, open standards and reference implementations • ATT catalyst funding with other investments expected • a national advisory board • RFP next month Net@edu • Fed-ed meetings • workshops Middleware Initiatives

Next Steps HEPKI - Technical Activities Group • universities actively working on technical issues • topics include kerberos-PKI integration, public domain CA, profiles • will sponsor regular conference calls, email archives HEPKI - Policy Activities Group • universities actively deploying PKI topics include certificate policies, RFP sharing, interactions with state governments • will sponsor regular conference calls, email archives Middleware Initiatives

Medical Middleware The intersection of higher ed and health care services Worst case requirements in I/A HIPAA - new privacy and security requirements Must integrate with higher level objects - CORBA Med Work will consist of problem structuring, technologies, and policy/process issues Middleware Initiatives

International Aspects Identifier agreements International trust models Shared expertise Workshop this summer in Europe Middleware Initiatives

Where to watch www. internet 2. edu/middleware net@edu www. cren. org f. PKI work www. Globus. org Middleware Initiatives