Upload
naomi-shelton
View
219
Download
0
Tags:
Embed Size (px)
Citation preview
Identity in the Virtual World:
Creating Virtual CertaintyCreating Virtual Certainty
David L. WasleyInformation Resources & Communications
UC Office of the President
4
Overview
What are we trying to accomplish?“Network Identity”Authentication is not AuthorizationThe Need for AnonymityWhat’s missing?The UC Common Authentication Project
5
The Problem
On the network, traditional “clues” to identityof an individual are not available
6
The Problem
On the network, traditional “clues” to identityof an individual are not available
Appropriate control of access to information resources and services is necessary possibly for cost allocation
7
The Problem
On the network, traditional “clues” to identity of an individual are not available
Appropriate control of access to information resources and services is necessary possibly for cost allocation
We need digital credentials that associate an individual with eligibilities can assert ‘class’, perhaps anonymously
e.g. “dog”
4
What are we trying to accomplish?
We must create a set of credentials and supporting infrastructure so that we can recreate in the digital world an analog of the control and management procedures with which we are familiar.
This includes a basis for “trust”To accomplish this requires fundamental
understanding of the problems
10
What is “Identity” ?
The essence depends on context Identity is based on attributes associated with
an individual or thing Not all attributes are important for all uses “Given Name” is seldom useful
It is the individual’s relationship with the world that is (most) important
10
Different types of Identity
Specific association with an individual is required for many purposes
Association with a class of individuals may be adequate for some things
Correlation of sequential activities may be the important function e.g. application for admission User Profile
11
Electronic Identity
Essential elements include: A basic credential that is not easily forged Attributes associated with that credential
e.g. name, campus position, campus role(s), etc. Safe means to offer that credential to a service A means for services to verify that credential
May be assigned to individuals, servers, etc. “public workstations” can have an identity
An individual may hold several credentials
12
How we use Identity
Eligibility to do something Based on one or more attributes, etc.
“Signing” transactions or documents for validation and/or non-repudiation
Associating resource use with cost allocation i.e. charging
As part of “trust”
8
Who creates Identity?
Whoever assigns the attributes!Dozens of different “authorities”Inherently a distributed modelAcceptance is based on mutual trustBroad access creates a new set of
challenges
9
Authentication is not Authorization
Authentic credentials merely help to relate an individual to attributes
The application or service determines “authorization” based on attributes possibly other heuristics
Credentials may assert eligibility
9
Example - internal service
An application may be used by any faculty member The user offers a basic ID credential The appliction looks up the “faculty” attribute
should require authentication of the attribute service may use a campus “attribute proxy”
The application authorizes the user (or not)An application may be used by any graduate student
in Physics after 5PM or on weekends
9
Example - external service
A provider of site licensed content needs to know that a potential user belongs to the class of individuals eligible to gain access The license holder determines eligibility
Based on the relationship of the individual to the institution and the Ts & Cs of the contract
The content provider is given a credential that is issued by the contract holder asserts eligibility
The content provider authorizes the user (or not)
8
Conflicts can arise because ...
Intellectual freedom demands privacyThe institution has occasional need to circumvent
privacyService providers need assurance that access is
granted appropriatelyWho decides what is appropriate?
Application or service requirements University policy Faculty vs. “other”
14
Public Key Certificates
Electronic documentsIssued by a registered Certificate AuthorityIssued to a known entityAttributes can be associated with the entity
perhaps indirectly via “attribute databases”
Any receiver can validate the credentialThe “private key” can be used for “signing”Public keys are used for secure transactions
15
Using Public Key Certificates
The basic personal certificate should have minimal content (NetID) Minimal impact if it is compromised
Attributes should be retrieved from databases With appropriate access control
Applications use the PKC and attributes A common Attribute Server can help
Anonymity may require “on demand” secondary certificates
16
The Need for Anonymity
Intellectual freedomCompetitive advantageProtect appropriate privacy (e.g. marketing)Electronic voting (very hard)True anonymity means it isn’t possible to
trace the credential to any association with a particular individual Libraries now go to some length to ensure this
17
Multiple Certificates
It is inevitable that individuals will have more than one certificate Perhaps many more than one Perhaps issued by different authorities
We need to make this work Automatic generation and selection Certificate templates
17
Multiple Certificate Types
Personal certificates are associated with known individuals Owner must protect the “private key”
“Anonymous certificates” only assert certain attributes associated with the holder E.g. registered student, UC employee, etc. Eligible to access on-line information under the
terms of publisher’s contract with UC
13
Trust Models
Traditional (institutional) trust is hierarchical Driver’s licenses, passports, SSNs, credit cards Transitive Trust:
A & B trust; B & C trust; do A & C trust? In “real life” A asks B about C; C asks B about A
We can do the same digitally Credentialing services must be registered with one or
more trust brokers The trust broker must enforce standard practices
17
What’s missing in PKI today?
Lots! The CA is the easy part
User interface to the use of certificatesPortabilityManagement of certificates
E.g. revocation, escrow
Attribute definitions and servicesHeirarchical trust
17
A Common Solution?
Can we articulate a common framework and strategy for the use of PK certificates?
Can we define the missing pieces? E.g. Attribute definitions and services
Can we develope hierarchical trust? E.g. CREN’s CA
Can we work with vendors to “fix” browsers?Can we demonstrate proof of concept
18
UC Common Authentication Project
Uses Public Key Certificates CA may be outsourced . . .
Will provide electronic credentials for all members of the UC community a lifetime NetID
Flexible association of attributes the University Directory Campus attribute directories
Anonymous Certificates also will be issued
20
Certificate Management Issues
Initial issuance “Strength” of the ID required Who is the “notary”? What are the implications of being a notary?
User interface must be simple, intuitivePortabilityRevocationPublic Workstations
21
UCCAP Initial Applications
MELWEBBenefits enrollmentOther ESS functionsAccess to licensed electronic publicationsElectronic commerceEtc.
22
UCCAP Status
Limited Production System initiallyPrototype Root CA operational at OP
uses Netscape CA server
Prototype Campus CA’s under developmentMELWEB certificate interface in test modeUniversity Directory in prototype stage
NetID’s defined All UC employees are entered Students will be entered during Spring term
24
More information
David L. Wasley
Vance Vaughan
See alsohttp://www.ucop.edu/irc/wp/wp_Reports/wpr001
http://www.ucop.edu/~authuser/cap