Middleware and Muddleware: A Progress Report

1
Middleware and MuddlewareA Progress Report

• Ken Klingenstein,
• Project Director, Internet2 Middleware Initiative
• Chief Technologist, University of Colorado at
  Boulder

2
Internet1 to Internet2 Challenges

• Video
• Sci apps
• Multimodia

• Telnet
• web
• email

• Directories
• Security
• Agents

• IP v4
• DNS

• QoS
• Multicast
• IPv6

3
Agenda

• Early Harvest results
• CIO study group and dissemination
• Next steps
• PKI - products and policies
• .eduorgperson
• tools

4
Early Harvest Workshop

• eh?
• NSF goals
• best practices accelerate campus progress
  inform NSF
• Sept 23-24 Denver Workshop
• Dissemination

5
Participants

• Daniel Arrasjid SUNY, Buffalo
• Bob Brentrup Dartmouth
• Keith Brown Duke
• Mark Bruhn Indiana
• Steve Carmody Brown
• Alan Crosswell Columbia
• Bill Doster Michigan
• Michael Gettes Georgetown
• Frank Grewe Minnesota
• Annette Haworth Reading, England
• Keith Hazelton Wisconsin
• Paul Hill MIT
• Steve Kellogg Penn State
• Bob Morgan Washington
• Mark Poepping Carnegie-Mellon
• David Wasley California President's Office
• Norm Wiseman JISC
• Steve Worona Cornell

6
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

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

8
Major campus identifiers

• UUID
• Person registry id
• Account login/ Netid
• Email address
• Library/deptl id
• Publicly visible id (and pseudossn)
• Pseudononmyous id

9
Identifier Space
Person Registry
UUID
Pseudononymous
PVI
Acct Login
Email address
Departmental ids
10
UUID

• Purpose - primary internal identifier, used for
  file access, group membership
• Characteristics - machine readable, centrally
  provided, eternal, large capacity

11
Person registry id

• Purpose - resolve ambiguities on identity
  critical to distributed and outreaching
  activities
• Characteristics - opaque, centrally provided but
  locally administered, eternal, very large
  capacity,
• Very labor intensive resolver is human
• Stored in a database, not a directory
• Keyed off of UUID where possible

12
Account login/Net

• Purpose - login to campus resources (email, net)
• Characteristics - human readable, centrally
  provided, resolved via authentication process,
  not necessarily eternal, limited capacity,
  extensible to groups

13
Email Address

• Purpose - email, human-friendly global identifier
• Characteristics - human-readable, centrally
  provided, resolved via sendmail or LDAP,
• Less agreement - persistence

14
Departmental Id

• Purpose
• Characteristics

15
Publicly visible identifier

• Purpose - post grades publicly, resolve directory
  inquiries
• Characteristics - human readable but dumb,
  resolved through directory, centrally afforded,
  need not be eternal,

16
Pseudononymous identifier

• Purpose - access academic resources such as
  Libraries
• Characteristics - centrally provided, machine
  readable,
• Uncertain - persistence, capacity

17
Cuttings Authentication

• user password management - crack, change,
  compromise
• central password management - change, audit,
• first password assignment - secure delivery
• policies and practices - scope of use

18
User password management

• Good practices
• Precrack new passwords
• 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

19
First password assignment

• Good practices
• USmail a one-time password
• 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.
• Uncommon approaches

20
Beyond Passwords

• Shared secrets
• Challenge-response (S/Key, Smart Card) - for
  certain secure accounts
• X.509 - no one using yet
• Biometrics - no one using yet

21
Cuttings Directories

• Overall campus directory services model
• Enterprise directory design and implementation
• Departmental directories
• Security and directories

22
Overall Campus Directory Structure
Border directory
Metadirectory
Enterprise directory
Departmental directories
OS directories (MS, Novell, etc)
Dir DB
23
Key directory issues

• legacies -DCE, NDS, NT, etc.
• applications - Peoplesoft, SAP
• future application development platforms
• authority and data ownership

24
Enterprise directory issues

• Schema, referrals and redundancy
• Naming
• Attributes
• Replication and synchronization
• Groups

25
Schema Issues

• Overall logical design
• Inheritance of policy and attributes
• Referral to other parts of the tree
• Delegation, replication, synchronization

26
Schema Best Practices

• People, machines, services
• Be very flat in people space
• Create a campus person
• Keep accounts as attributes, not as an ou
• Replication not a primary driver in schema
• Group policies not a primary driver in schema
• New DNS hack to serve directory locations
• No trolling permitted more search than read

27
Naming Issues

• RDN
• Other keys
• Preserving name space

28
Naming Best Practices

• dc as a name versus c, ou
• RDN may well be UUID

29
Attribute Best Practices

• 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 dns no better.

30
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, Y2K
  coords) centrally
• Performance issues need to be watched

31
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

32
CIO Study Group

• Not the usual suspects
• Commitment to move implementation forward
• Provided some training and facilitated support
• RFP this month

33
Dissemination

• Web Site
• Educause articles
• Presentation at I2 Fall meeting, Educause Conf,
  CNI
• Regional workshops

34
Next steps

• PKI
• .eduorgperson
• killer glue
• viable products

35
PKI Components

• X.509 certificates, PKCS
• CAs and CRLS
• profiles, policies and practices
• trust models
• viable products

36
X.509 and PKCS

• X.509 defines certificates, trust models, and
  uses
• PKCS defines critical implementation details - eg
  specific encryption algorithm choices, key
  formats for portability, etc.
• PKCS is RSA-oriented patent burning party next
  year.

37
Higher Ed PKI Open Issues

• profiles - common certificate templates for
  standard academic uses
• policies - stating eligibilities, roles and
  responsibilities
• practices - standard specific operating
  conventions
• trust models - hierarchy, bridge, none on and
  off-campus
• viable products - cost, flexible, mobility,
  integration with embedded bases, public
  domain/open source alternatives
• research opportunities - apps that use policies

38
PKI process issues

• how should planning and direction be done?
• How can the research opportunities be realized?

39
.eduorgperson

• Is there a need for a multicampus subschema
• What is the right granularity - BigN, CSG, I2,
  edu
• How to define and populate to minimize
  redundancies
• Is there an oid arc for education/research

40
Killer Glue

• Interoperable web page authentication - an Apache
  module
• Interoperable secure directories bindings
• Retooling apps to use _at_ identifiers
• Enable interinstitutional resource sharing
• Encourage transition from htaccess protection to
  LDAP protection
• Corporate help?

41
Vendor discounts/ public domain

• Directory and metadirectory software
• DCE
• PKI
• fPKI work -
• http//csrc.nist.gov/pki/twg/welcome.html
• Van Dyke and Associates Cygnacom public domain
  pieces
• Jonah from IBM