A user-friendly approach to grid security Could Would Can’t use it, Won’t use it! Bruce Beckles University of Cambridge Computing Service

“State of the Grid” Authentication: Authorisation: Auditing: Digital certificates (X.509-based PKI) Crosses institutional boundaries Authorisation: Either simplistic “allow” lists in text files (the grid-mapfile), or… Complex, heavyweight, “general purpose” authorisation frameworks (e.g. CAS, VOMS, PERMIS, Shibboleth) Auditing: Auditing? What auditing? The “missing link” – Siebenlist, Globus Alliance

Problems for End-Users Digital certificates difficult to obtain and use… so (shock!) users hate them So difficult that users share certificates (and not just within a single institution) Experience so painful some users refuse to use grid technology if it will involve certificates (e.g. BRIDGES project) Most users don’t understand digital certificates, so they behave inappropriately… Multiple copies of certificates (and proxy certificates) scattered across the grid (not always protected)

Problems for Administrators Users’ desperate attempts to cope with certificates mean that soon no one knows who is actually using which certificates and for what… …and when does a certificate get revoked anyway?: When a user leaves the institution? When they leave the project? How does the Certificate Authority know? Confusion between “identity” and “membership” ( authorisation)

Authorisation Issues Authorisation mechanisms: choice? what choice?… Either just an “allow” list: Too simplistic …or complex, heavyweight framework: Difficult to understand, deploy, maintain and administer May require centralised co-ordination or infrastructure In all cases, dependent on the integrity of the authentication mechanism, so, currently… …it’s doomed…

Auditing Issues Who did what? From where?: Who: dependent on integrity of authentication mechanism… uh-oh… What: executable name often “lost in transit” (data, condor_exec.exe), and executable normally deleted on job completion… oh, good... Where: IP address of host submitting job… but IP addresses can be spoofed…! …And what else should we be recording…? Audit data usually stored locally, so… Successful attacker can modify it(!)

Why is it like this? Current solutions: Heavyweight: Poor Usability: Difficult to deploy and administer Often require inappropriately centralised infrastructure Complex (so difficult to understand) Poor Usability: Difficult for end-users to use Difficult to configure and administer Poor/Inappropriate Design: “One size fails all” Designed to developer’s agenda, not users’

User-friendly security… Lightweight: Easy to deploy and administer Easy to understand Restricted to a sensible-sized problem domain User-centred design: Design for the user, not in spite of them Understand and satisfy stakeholder requirements Continuous user involvement Ongoing usability testing Formal security methods: Formal analysis and modelling …so we understand what’s going on Formal security verification …so we know we’ve got it right

…in a grid context Handle local issues locally (“localise, don’t centralise”): Authentication: authenticate against local authentication service VO membership: use local identity to determine membership/authorisation (parameterised RBAC?) Distribute information across resources as necessary Certificates appalling, passwords better: Use local authentication to obtain or create certificates on behalf of the user to interact with existing grids User never sees a certificate! Conform to best practice: Audit data stored remotely Don’t rely on IP addresses

So who’s doing this? “User-Friendly Authentication and Authorisation for Grid Environments” project: UCL, Manchester, Cambridge, Newcastle, London South Bank University Planned start date: October 2006 EPSRC funded For our proposed authentication mechanism (wraps existing GSI mechanism), see: Removing digital certificates from the end-user’s experience of grid environments (2004): http://www.allhands.org.uk/proceedings/papers/250.pdf Mechanisms for increasing the usability of grid security (2005): http://dx.doi.org/10.1016/j.ijhcs.2005.04.017

Questions?