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

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

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

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

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

Model

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

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

Certificates Advantages Standard Interoperable Scalable Disadvantages Need tools Needs infrastructure

Delegation id of identity

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?

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

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

Example User Agent Credentials Store

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

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

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

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

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

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

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

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

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

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

Central AuZ VOMS IdP1IdP2IdP3IdP4

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

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

RBAC A. UserRoleAdmission

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)

…Usability? Security… …a necessary evil? Technophobes

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

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

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

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

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

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

MyProxy for CC Grids (NGS, gLite/GridPP, SRB) Kerberos or Active Directory

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

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

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

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

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