1. Security and Delegation The Certificate Perspective Jens Jensen Rutherford Appleton Laboratory Workshop at NIKHEF, 27 April 2010

2. Why Security? Protect our infrastructure (and users’ data) Enforce allocations Accounting for resource use Track resource misuse Peering – across UK, Europe, World

3. Security – site requirements Let the good guys in Keep the bad guys out Minimal support requirements

4. Security – user requirements “No security” “It only gets in the way” “Add it later”

5. Security – user requirements Should be like a duck Who moves across the pond Paddling of feet unseen (enlightened version)

6. Model

7. Certificates: The Executive Summary Combine A name – globally unique A public key Assertions (“extensions”), lifetime into a signed envelope

8. Certificates Validity asserted by authority Timeliness of information Revocable Secrets managed by user Single identity (credential)

9. Certificates Advantages Standard Interoperable Scalable Disadvantages Need tools Needs infrastructure

10. Delegation id of identity

11. Delegation of ID Agent acts on behalf of user Acts as the user SHOULD NOT be delegated to other user (really!) Restrictions? Can delegations be delegated?

12. Delegation of ID Protect original credentials Create delegated credentials Cf Kerberos tgt  session ticket Cf SAML authentication assertions Cf OAuth What has the credential done

13. Example Credential Conversion Scientist wishes to do work Logs in Uses resource

14. Example User Agent Credentials Store

15. GSI proxies GSI = Globus Security Infrastructure RFC 3820 Sort of extending cert chain Extends existing trust infrastructure Keeps (orig) secret with users

16. GSI 1. Proxy credential format Limitating redelegation 2. Delegation-“extended” TLS Secrets never cross the wire

17. GSI proxies Advantages Work with the grid In std OpenSSL Can limit proxy, eg policy Client keeps secret secret Disadvantages Not common outside Off by default Somewhat coarsegrained Delegatee has unprotected working secret

18. Delegation Step (simplified) 1.Recipient generates key pair, CSR 2.Recipient sends CSR to Sender 3.Sender signs CSR into (proxy) cert 4.Sender sends proxy cert to Recipient

19. Personal Certificate Private Key Personal certificate Issued by a CA (chain)

20. Private Key Personal Certificate MyProxy Proxy Certificate “uploaded” to a MyProxy server Private key is stored in MyProxy server Principle: private key doesn’t cross the wire Uploader Proxy

21. UI Proxy Private Key Personal Certificate Uploader Proxy I get a delegated proxy to work with MyProxy Proxy

22. UI Proxy Private Key Personal Certificate Uploader Proxy MyProxy Proxy VOMSified proxy

23. Things to Note Only the most recent private key is present in the proxy The other keys are not needed!! Lifetime of “parent” proxy must (should) span all children

24. Things to Note Rights of a proxy can be inherited from parent And restricted by policy And granted by (attribute) authority AA different from IdP

25. Central AuZ VOMS IdP1IdP2IdP3IdP4

26. Issues Tracking proxies once issued Where it is What it has done What it is doing Usefully restricting proxies Expressiveness and granularity Enforceable and enforced Stopping naughty proxies

27. Delegation of Authority More like roles Or other attributes Or specific actions on objects

28. RBAC A. UserRoleAdmission

29. Delegation of Authority Roles are harder to scale Unless they are few and coarse grained Need translations between role providers Unless you have only one role provider Or there is a standard and people actually follow it (This never happens)

30. …Usability? Security… …a necessary evil? Technophobes

31. Improve tools With MyProxy, VOMS Improving client tools Browsers don’t work so well for PKI

32. Experiences Usable security …satisfying user and site requirements… …makes happy(er) and productiver users

33. Credential Stores Manage long term credential centrally Create short term credential when needed Credential conversion  create GSI proxies  download MyProxy, SLAC VSC, …

34. Aspects To centralise or not to centralise Mapping to roles and local ids Flavours of Proxy certificates Pre-RFC, RFC, …

35. Getting certificates International Grid Trust Federation Global, with ~80 countries Creating them yourselves Credential conversion based on local IdPs Advice: use IGTF if you can

36. Shib for CC PasswordShibboleth Resource access Create certificates instead (portal)

37. MyProxy for CC http://grid.ncsa.uiuc.edu/myproxy/ Grids (NGS, gLite/GridPP, SRB) Kerberos or Active Directory

38. Interoperation and standards Standards improve standardisation Not just a tautology More and better implementations Standards improve interoperability Interoperability improves reusability Reusable means more versatile Improves usability

39. Ponder What we learn from other communities? Components for reuse Experiences Deploy services for other communities –Try to adapt what they already have

40. Dimensions Time (user’s) Time (ours) Space (geo) Financial and resources Ease of use Assurance Trust End to end (user to system)

41. Don’t reinvent the But did they want this? or this?

42. Final words (promise) Aim to meet user and site requirements Build on stuff that works (or build stuff that works…) Users don’t always know what they want Don’t forget, it’s an experimental science – across all dimensions