Mware 101 Ken Klingenstein Project Director Internet 2

Mware 101 Ken Klingenstein, Project Director, Internet 2 Middleware Initiative Chief Technologist, University of Colorado at Boulder

Syllabus Other courses, acks The larger picture The Basic Technologies • Identifiers • Authentication • Directories PKI Current Activities to watch

Other middleware sessions Mware 101 - big picture, identifier basics, authn, directory concepts, PKI overview Mware 202 - identifiers+, directory deployments PKI 101 - apps, certs, profiles, policies, trust models Middleware 301 metadirectories, registries, authorization HEPKI- PAG current policy activities HEPKI- TAG current technical activities LDAP Recipe Multicampus Bo. F Early Academic Medical Adopters Middleware technology --- policy Labs: Eduperson Shibboleth Do. D, apps Middleware and the Grid Metadirectories Bo. F International Issues in Middleware

Acknowledgements Mace and the working groups Early Harvest - NSF catalytic grant and meeting Early Adopters Higher Ed partners -campuses, EDUCAUSE, CREN, AACRAO, NACUA, etc Corporate partners - IBM, ATT, the Burton Group, Avaya, et al. . . Gov’t partners - including NSF and the f. PKI TWG

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), Jim Jokl (Virginia), Mark Poepping (CMU), David Wasley (California) Current working Groups • Mace-Dir Mace-med • Shibboleth - inter-institutional resource sharing

Early Harvest NSF funded workshop in Fall 99 and subsequent activities Defined the territory and established a work plan Best practices in identifiers, authentication, and directories (http: //middleware. internet 2. edu/best-practices. html) http: //middleware. internet 2. edu/earlyharvest/

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 Profiles and plans are on I 2 middleware site.

Early Adopter Participants Dartmouth Michigan Tech Univ U Hawaii Univ of Pittsburgh Johns Hopkins Univ of Southern Cal Univ of Maryland, BC Tufts Univ of Memphis Univ of Tennessee, Memphis Univ of Michigan

Remedial IT architecture The proliferation of customizable applications requires a centralization of “customizations” The increase in power and complexity of the network requires access to user profiles Electronic personal security services is now an impediment to the next-generation computing grids Inter-institutional applications require interoperational deployments of institutional directories and authentication

What is Middleware? specialized networked services that are shared by applications and users a set of core software components that permit scaling of applications and networks tools that take the complexity out of application integration sits above the network as the second layer of the IT infrastructure the intersection of what networks designers and applications developers each do not want to do

Specifically, 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. Relies on campus-based services and inter-institutional standards Instructional Management Systems (IMS) need authentication and directories Next-generation portals want common authentication and storage

A Map of Middlewareland Academic Computing Upperware Research Oriented Upperware Business Upperware Core middleware Network-layer middleware

The Grid a model for a distributed computing environment, addressing diverse computational resources, distributed databases, network bandwidth, object brokering, security, etc. Globus (www. globus. org) is the software that implements most of these components Needs to integrate with campus infrastructure Gridforum (ww. gridforum. org) umbrella activity of agencies and academics Look for grids to occur locally and nationally

Core Middleware Identity - the first characteristics of who you (person, machine, service, group) are Authentication - how you prove or establish that you are that identity each time you connect Directories - where the rest of an identity’s characteristics are kept Authorization - what an identity is permitted to do PKI - emerging tools for security services

OIDs numeric coding to uniquely define many middleware elements, such as directory attributes and certificate policies. Numbering is only for identification (are two oids equal? If so, the associated objects are the same); no ordering, search, hierarchy, etc. Distributed management; each campus typically obtains an “arc”, e. g. 1. 3. 4. 1. 16. 602. 1, and then creates oids by extending the arc, e. g 1. 3. 4. 1. 16. 602. 1. 0, 1. 3. 4. 1. 16. 602. 1. 1. 1)

Getting an OID apply at IANA at http: //www. iana. org/cgi-bin/enterprise. pl apply at ANSI at http: //web. ansi. org/public/services/reg_org. html more info at http: //middleware. internet 2. edu/a-brief-guide-to. OIDs. doc

Cuttings: Identifiers “Any problem in Computer Science can be solved with another level of indirection” • Butler Lampson “Except the problem of indirection complexity” • Bob Morgan

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 Student ID card

General Identifier Characteristics Uniqueness (within a given context) Dumb vs intelligent (i. e. whether subfields have meaning) Readability (machine vs human vs device) Affordance (centrally versus locally provided) Resolver approach (how identifier is mapped to its associated object) Metadata (both associated with the assignment and resolution of an identifier) Persistence (permanence of relationship between identifier and specific object) Granularity (degree to which an identifier denotes a collection or component) Format (checkdigits) Versions (can the defining characteristics of an identifier change over time) Capacity (size limitations imposed on the domain or object range) Extensibility (the capability to intelligently extend one identifier to be the basis for another identifier).

Important 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

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

Identifier data flows SIS Personnel Others Central IT Acct login Student ID Email address Person reg Pseudo ID

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

Examples Email related identifiers • • Email outward rewrite address Published email address Aliases Actual in-box location User@securitydomain. edu

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

Cuttings: Authentication user side management - crack, change, compromise central side password management - change management, OS security, first password assignment - secure delivery policies - restrictions or requirements on use

User side password management Precrack new passwords Precrack 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 Password aging seems to do more harm than good

Central side password management Lockout access after successive failed login attempts • insert a time delay before unlocking • require a human contact before unlocking No clear test storage or capture; use shadow password files Maintain audit trails Proper su and change management processes

First password assignment USmail a one-time password (time-bomb) In-person with a photo id (some require two) For remote faculty or staff, , an authorized departmental rep in person coupled with a faxed photo-id. Initial identification/authentication will emerge as a critical component of PKI

Policies Some institutions restrict the use of an identifier/authentication pair to secure environment Some require the use of certain identifier/authentication services for particular applications Some suggest the use of distinct passwords for internal and external accounts Some strongly suggest that users change their passwords after use from external, unsecured environments

Beyond Passwords Shared secrets Challenge-response (S/Key, Smart Card) - for certain secure accounts X. 509 - still has some distance to go; might want separate functionalities Biometrics - no one using yet

Directory Issues Applications Overall architecture • • Chaining and referrals Redundancy and Load Balancing Replication, synchronization Directory discovery The Schema and the DIT • attributes, ou’s, naming, objectclasses, groups Use - searching, indexing Management • clients, delegation of access control, data feeds

Directory-enabled applications Email Account management Web access controls Portal support Calendaring Grids

A Campus Directory Architecture Border directory Metadirectory Enterprise directory Departmental directories Dir DB Registries OS directories (MS, Novell, etc) Source systems

Key Architectural Issues Interfaces and relationships with legacy systems Performance in searching Access control Load balancing and backups are emerging but proprietary Discovery - New DNS hack to serve directory locations

Schema Best Practices People, machines, services Be very flat in people space Keep accounts as attributes, not as an ou Replication not a primary driver in schema Group policies not a primary driver in schema

Naming Issues RDN Other keys to index Creating and preserving unified name spaces dc= as a name versus c=, ou= the root name RDN may well be UUID

Attribute Best Practices Inetorgperson, Eduperson, localperson Never repurpose an RFC defined field; add new attributes Adding attributes is easier than thought Keep schema checking on, unless it is done in the underlying database; watch performance Most LDAP clients do not treat multi-valued attributes well, but doing multiple fields and separate dn’s no better.

Groups Best Practices Limit size and use (e. g. no email) but allow user creation Web access to group lists avoids multivalue problems Supply key institutional groups (class lists, Y 2 K coords) centrally Performance issues need to be watched

Groups Uncertainties no consensus on where to store • as a schema attribute for individuals • as a separate entry within overall hierarchy some variations on naming • within user name space • may augment with group or owner indicator

Management Issues No trolling permitted; more search than read LDAP client access versus web access How and when to update LDIF likely to be replaced by XML as exchange format Delegation of control “See also”, referrals, replication, synchronization in practice Replication should not be done tree-based but should be filtered by rules and attributes

Further information

PKI Components Identifiers and authentication X. 509 v 3 certs Certificate Revocation Lists and OCSP Cert management - generating certs, using keys, archiving and escrow, etc. Directories - to store certs, and public keys and maybe private keys Trust models and I/A Cert-enabled apps

PKI : A few observations Think of it as wall jack connectivity, except it’s connectivity for individuals, not for machines, and there’s no wall or jack…But it is that ubiquitous and important Does it need to be a single infrastructure? What are the costs of multiple solutions? Subnets and ITP’s. . . Options breed complexity; managing complexity is essential

A few more. . . IP connectivity was a field of dreams. We built it and then the applications came. . Unfortunately, here the applications have arrived before the infrastructure, making its development much harder. Noone seems to be working on the solutions for the agora.

Uses for PKI and Certificates authentication and pseudo-authentication signing docs encrypting docs and mail non-repudiation secure channels across a network authorization and attributes and more. . .

PKI Contexts for Usage Intracampus Within the Higher Ed community of interest In the Broader World

Cert-enabled applications Browsers Authentication S/MIME email IPsec and VPN Globus

X. 509 certs purpose - bind a public key to a subject standard fields extended fields profiles client and server cert distinctions

Standard fields in certs cert serial number the subject, as x. 500 DN or … the subject’s public key the validity field the issuer, as id and common name signing algorithm signature info for the cert, in the issuer’s private key

Extension fields Examples - auth/subject subcodes, key usage, LDAP URL, CRL distribution points, etc Key usage is very important - for digsig, non-rep, key or data encipherment, etc. Certain extensions can be marked critical - if an app can’t understand it, then don’t use the cert Requires profiles to document, and great care. . .

Cert Management Certificate Management Protocol - for the creation and management of certs OCSP - on-line CRL plus…. Storage - where (device, directory, private cache, etc. ) and how - format escrow and archive - when, how, and what else needs to be kept Cert Authority Software or outsource options Authority and policies

Directories to store certs to store CRL to store private keys, for the time being to store attributes implement with border directories, or acls within the enterprise directory, or proprietary directories

Trust model components Certificate Policy Statements - uses of particular certs, assurance levels for I/A, audit and archival requirements Certificate Practices - the nitty gritty operational issues Hierarchies vs Bridges • • a philosopy and an implementation issue the concerns are transitivity and delegation hierarchies assert a common trust model bridges pairwise agree on trust models and policy mappings

Current Activities Eduperson the Directory of Directories Shibboleth PKI - HEPKI-TAG, PAG and research labs Others - medical, international, authorization

Edu-person An objectclass for higher education Contain 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

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)

A Directory of Directories an experiment, now encompassing 8 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

Shibboleth interinstitutional 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 SRV records in DNS and several forms of authn; authz via directories IBM to analyze, several schools to participate in pilot

HEPKI Joint efforts of Higher Ed - Internet 2, EDUCAUSE, CREN Bi-weekly conference calls (minutes at www. educause. edu/hepki) Technical Activities Group (TAG) • profiles • open source reference implementations • mobility solutions Policy Activities Group (PAG) • working with f. PKI • Certificate Policies

Internet 2 PKI Research Labs Dartmouth and the University of Wisconsin at Madison Contributions by ATT, Baltimore, etc. 2 -5 years Research agenda includes revocation, human interface, policy languages, authorization, trust path math, etc.

Mware 201 typical issues Access control lists for directories - how to construct, how to manage Integration of LAN and enterprise accounts and passwords Enterprise and LAN directories - schema, replication and synchronization Working with legacy and source systems

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