1 / 24

Developing a National PKI for a National Grid

Developing a National PKI for a National Grid. 6 th PKI Workshop, NIST, Apr 07 Jens Jensen, David Spence, Matt Viljoen STFC Rutherford Appleton Laboratory. Background National Grid Service. The “Grid for the United Kingdom” Other national Grid is GridPP, the Grid for particle physics

winfield
Download Presentation

Developing a National PKI for a National Grid

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. Developing a National PKI for a National Grid 6th PKI Workshop, NIST, Apr 07 Jens Jensen, David Spence, Matt Viljoen STFC Rutherford Appleton Laboratory

  2. BackgroundNational Grid Service • The “Grid for the United Kingdom” • Other national Grid is GridPP, the Grid for particle physics • Consists of four core sites • Universities of Oxford, Leeds, Manchester • Rutherford Appleton Laboratory • And a large number of “partner” sites • Currently ~500 users (who all have Grid certificates from the global Grid PKI)

  3. The UK e-Science CA • Second largest Grid CA in the world • The DoE Grids CA is larger • Currently ~1200 valid users and 2200 hosts • About 60 RAs distributed throughout UK • In production for 4.5 years • Certs for people, hosts, services, robots

  4. Works with the Grid Works with other stuff Web and browsers Good for hosts Grid does have single X.500 namespace Standardised Mostly Some special Grid issues Using proxies for “single sign-on” Why X.509

  5. Security vs Usability • People perceive certificates as difficult • PKCS#12 <-> PKCS#8 • Passphrases • Goal: improve usability • without compromising security • can even improve security

  6. Scalability • Medium assurance • Each renewal requires RA approval (~1yr) • Re-check identity after N renewals (~5 yr) • For 106 certs (and 200 working days) • 5000 renewals/day • 1000 re-checks/day

  7. What is single sign-on anyway • Account management: each user has a single registration • Single password: a single password is used to unlock all resource accounts • Single authentication – each user must type the password only once • Per day, per week, per login

  8. What is single sign-on anyway • Credential gymnastics • Credential conversion • GT2 delegated proxies • Delegation • (beyond scope of this talk)

  9. Using Institution IdP • Puts identity management in institution • That’s good – they do it anyway • That’s bad – the CA has no control • Associate DN with identity • Institute does not (usually) release information • Institute does not describe vetting policy • So lower assurance

  10. Using Institution IdP • Solves scalability problem • Shibboleth does this too! • Why not use Shibboleth then?

  11. Comparing to Shibboleth • Complementary – coexist with Shib • Simpler – no need for attributes (at this level) • Simpler – used only to access Grid • Simpler – no WAYF but on site only • Joining is infinitely cheaper • Driven by the NGS Grid, not institution • Some similar data protection issues

  12. Two Models Institute A Institute C Central CA Institute B Institute D The Grid

  13. Two Models Institute A Institute C Local CA Local CA The Grid Local CA Institute B Local CA Institute D

  14. Institute A Institute C Central CA Institute B Institute D The Grid Institute A Institute C Local CA Local CA The Grid Local CA Institute B Local CA Institute D Two Models The SWITCHaai model This one (NGS)

  15. Two Models • Institution using local SSO to local CA • Institutional goodies not leaving institution • Can use SSO: single login • But need to build for each institution • But many institutions have much the same • Active Directory / Kerberos V

  16. Overview InstitutionalCA (MyProxy based) User Institution DB

  17. It’s the apps, stupid • Thin ones (browser), applet or portal • Thick ones – user client • Portal – calls directly to MyProxy • Killer app: Java GSISSH terminal • Modified from upstream • Tie with SSO: users don’t know they have certs

  18. Killer App SSO Terminal (on desktop) User Head Node or User Interface InstitutionalCA

  19. Technology • MyProxy based contributed modifications • …to use keys on tokens (increase seucirty) • …to integrate with portal • Potential to use Microsoft Server 2003 • Built-in CA, used by CERN • We haven’t tried this

  20. Technology • Compare to KCA (Kerberos CA) • KCA converts Kerberos ticket to short-lived cert • So does this • MyProxy can proxy off existing cert

  21. Technology • GSISSHTerm can run stand-alone or as applet • With Java 1.6, can automatically pick up ActiveDirectory/Kerberos ticket

  22. Trusted CA (Explicit Trust) e-Science ROOT Accredited CA e-Science CA Credential conversion top level NGS Training and Monitoring Institutional CC CA Institutional CC CA Institutional CC CA

  23. Splitting • Different CAs can have different assurance levels – or not • Conversely, users may have more than one identity (two different certs)

  24. Conclusions • “Grid Interoperability Now” • Or, “It’s the glue, stupid” • Convert existing tokens – SSO • To something the Grid uses • Constrained to institutions on a specific Grid via CA hierarchy • Generate short-lived certs or proxy existing cert • Complementary to Grid PKI and Shib • http://www.ngs.ac.uk/ -> Grid Utilities

More Related