1 / 12

UW-Madison PKI Lab

UW-Madison PKI Lab. Keith Hazelton Principal Investigator, UW-Madison PKI Lab Senior IT Architect, UW-Madison PKI Summit, Snowmass, 9-Aug-01. UW-Madison PKI Lab. Computer Science & Central IT (Div. of Info Tech) collaborating (that’s news, thanks I2 and AT&T)

calvin
Télécharger la présentation

UW-Madison PKI Lab

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. UW-Madison PKI Lab Keith Hazelton Principal Investigator, UW-Madison PKI Lab Senior IT Architect, UW-Madison PKI Summit, Snowmass, 9-Aug-01

  2. UW-Madison PKI Lab • Computer Science & Central IT (Div. of Info Tech) collaborating (that’s news, thanks I2 and AT&T) • Advisory Board calls unlike anything else in my experience • Working with: • UW Hospital and Clinics • MACE-Shibboleth, HEPKI-TAG • Fed Bridge CA • “the other” PKI Lab at Dartmouth

  3. UW Hospital and Clinics • Secure email usability study for Dept. of Family Medicine beginning September • Provider to provider only • PKI Lite (not Ultra-Lite: we WANT to experience some of the admin and user headaches) • Lab staff will publish report on the study next spring

  4. MACE-Shibboleth & HEPKI-TAG • SAML-like assertions for attribute response messages in Shib • Positioning for a more sophisticated approach to policy management • PKI Ultra-Lite for HEPKI-TAG • Self-registration for cert generation controlled by shared secret • Once in users local store, the ultra-lite cert grants “log-on-less” access for HEPKI-TAG members to restricted web pages • Inter-institutional application with similarities to MIT approach

  5. Federal Bridge CA pilot • What Peter Alterman said (the completed thoughts) • MBridge evaluation (MitreTek’s trust broker approach)

  6. The PKI Labs joint DRM project • Enforceable Digital Rights Management (DRM) • Both provider and consumer rights, please • Content provider has valuable intellectual property • They want to provide agreement-based, limited access • They want to control conditions of use • Guess what, that’s how users feel about personal info • Symmetric problem, the tech that works for one should work for both • Dartmouth working on making rights management policies enforceable in possibly “hostile” environment

  7. The PKI Labs joint DRM project • UW-Madison working on policy language piece of this puzzle • How do parties express their policies about digital rights? • Today: • ACLs at the resource (web page, file system, application) • Resource-specific implementation of ACLs (.htaccess file, user accounts and groups, directory attributes) • The policy is expressed (explicitly or implicitly) in near natural language • As role-service mapping rules and people-role mapping rules • Then techies have to translate that into computerese via configuration files or administrative interfaces (gui or command line)

  8. The PKI Labs joint DRM project • Problems with today’s approach • Inflexible (lots of steps, lots of people, lots of inertia) • Asymmetric • Resource providers call the shots • Individuals have few effective ways to express preferences • The emerging alternative • Find flexible ways to express authorization data, access policies • SAML, XACML (eXtensible Access Control Markup Language) • XML, while not as “human readable” as advertised, is relatively easily mappable to natural language and back • XML instances (documents) are computationally accessible, too • Handle policy as a layer of its own • Pull the various bits and pieces out of the apps • Manipulate policy via a unified management tool

  9. The PKI Labs joint DRM project • Madison PKI Lab exploring ways to: • Allow the various parties (resource providers, end users & others) to create and maintain their policy in language they understand • Prototype and evolve a “Policy Editor:” • User constructs and edits near natural language policy clauses • These are translated into policy “assembly language” such as XACML • Stored in decentralized repositories: • user policy clauses close to user, • resource policy clauses closer to resource, • institutional policy clauses close to the policy authority

  10. The PKI Labs joint DRM project • Madison PKI Lab exploring ways to: • Put in place a run-time environment for policy evaluation • The various policy clauses have to be brought together and evaluated at the time of the request for access to resource/service • E.g. • First year med students from subscribing institutions can access this on-line NMR archive if they give us their email address (resource provider clause) • UW-Madison Med School is a subscriber (resource provider clause) • People who have been admitted to the med school, are currently enrolled and have a total of between 0 and 30 credit hours are first year medical students (institutional person-role mapping clause) • I will release my email address to resource providers to which med school subscribes if I actually use their product • Just one of the tricky bits: Who is authorized to make which assertions? Hint: That’s a policy question, isn’t it?

  11. The PKI Labs joint DRM project • A lab bench version of such a policy language-based DRM system is under development at Madison, Eric Norman is technical lead • Plan to present a paper on results at NIST-sponsored Security Conference • Work-in-progress reports will appear on UW-Madison PKI Lab web site: http://www.cs.wisc.edu/pkilab

  12. Your Turn • Q & A

More Related