This wiki service has now been shut down and archived

From ESIWiki

Trust and Security in Virtual Communities

Notes From The Second Workshop: Usability and Interoperability in AuthN/AuthZ

Oxford, May 8th and 9th 2008

Andrew Martin - Introduction and Report on First Workshop

File:Theme8Workshop2-intro.pdf slides.

Some of the points raised by the first workshop:

• More usability problems than attacks or vulnerabilities, although this may just be because attacks are relatively unknown
• The notion of "cultural security" where people from different places have different predefined notions of what the security values are. Comment that this difference is apparent within one organisation.

First workshop themes

• AuthN and AuthZ Usability, technical problems are relatively "solved" but they arent being implemented
• Usability of applications applied to SysAdmins and developers too, not just users.
• Surprisingly little guidance available for people undertaking projects involving medical data. For example, it would be useful to have guidelines on processing sensitive data, anonymisation, and how to build 70-year security. Targeted, but generalised advice would be useful.
• Grid/Cloud Computing
• PKI Systems have been something of a disaster. Takes too long to get credentials.
• Some systems have a "sandbox" tool which can mitigate some of the problems with slow registration.
• Lack of realistic, common threat models. Surely lots of grid situations have threats in common?
• Need to improve the trust in grid services. There is no possibility of using NGS with sensitive data? Lots of non-examples of people who wont use computing services outside of their own perimeter. For claiming experiment result - you need to trust that a service actually performed the calculation you expected it to.
• The idea of risk-based security approach seems to have sunk in.
• Need to identify new architectures for trusted services.

Commentary

• Complaints that only prototype versions get funded and nobody is paid to make the complete, "shrink-wrapped" solution. Also a shortage of accompanying material.
• Arguments about the need for security solutions to be customisable. They need to scale from small to big, and configurations need to be enforced so they are not left to default settings. Kerberos works well because it scales from the very small, right up to the very big.
• Security culture at businesses is always conservative - people are unwilling to try new solutions on the grounds that they will be blamed (perhaps unfairly) for problems. This is because higher-level manager don't understand security. Doing nothing is a more acceptable policy in terms of job security.
• Need to cope with the successful "Hero" users who get by despite problems, but also attract other people who won't work in the same way, and are put-off more easily.
• Important not to put-off smaller groups, such as the "tinkerers". We can't spend 2 years coming up with perfect solutions, only to find scientists have gone their own way.
• Shibboleth is a bit of a problem, because its a moving target, it really only provides glue, is quite complicated and needs to be "shrink-wrapped".
• Forget OpenID - various providers have broken it, such as AOL, by saying they will reassign identities.
• Accountability and Audit is increasingly important. From a SysAdmin standpoint, they would like to know what is running on their hardware. Sometimes they have a responsibility to make sure resources are being used for the right reasons, not just by the right people. If they could identify the purpose of a job, it would be very helpful.
• Its not always obvious whose responsibility it is to monitor grids and prevent misues of resources. Is it the SysAdmin? Is it the VO?
• Some people care very much about telling who is using too many resources.
• Diffusion of responsibility. At the moment there is not enough accountability for users of grid systems. As a result, they don't care too much if they overuse resources, as nobody can tell it was them. People need educating, so they know how irresponsible behaviour on a grid can affect colleagues. Partly because grids grew up being used by people who had no concerns about sharing resources.
• Some discussion on sharing credentials. The service provider (such as a bank) may want one credential per person, but the users (say a married couple) don't care. It shows a problem with how security is aligned to the person who pays for it.
• P3P is a good example - shrouded in legalese to protect the company, but this makes it useless for its main goal, to inform users.

More Events

• Trusted Computing tutorials and lectures
• There may be a third workshop. This will be discussed tomorrow.

Richard Sinnott

File:OxfordTrust8thMay2008.ppt slides.

Opening Comments

• There is a need for fine-grained security in several situations.
• Plenty of questions along the lines of "Who is allowed to access that clinical record"
• The aims are to provide access to large data sets and computation resources.
• Considerations: every new project has a new spin on security.
• We still don't have common ways to create secure grids systems.

What We Really Want From The Grid

• Easy for the end user
• Single Sign On
• Each site is autonomous and have their own protection
• Easy to manage for the local SysAdmins
• Systems that scale well.
• Fine-grained security as and when it is necessary
• The ability to be dynamic - to change credentials, access control, collaborations, and so on.

Challenges and Problems

• Everyone dislikes using certificates
• Defining what we mean by "grid" is difficult, there are several systems which are not grids, just ad-hoc collections of web services.

• Usability problems at the moments. Many steps involved with getting certificates, installing revocation lists, converting certificates (some kind of command line task needed).
• These problems turn people away from grids before they have had a good chance to use them.
• Revocation is a challenge. What happens if someone is expelled from their university. Are the grid credentials automatically revoked to?
• Certificate sharing still happens
• No knowledge about the nature of a job running on a grid.

• Need to aim at the second type of user, not the tinkerer, but the less-knowledgeable user.
• Comment: It is important not to turn tinkerer's away, as they often produce important science.
• Comment: there is a need for flexibility even within relatively non-technical users. Biologists may have their own particular versions of SLAM, for example.
• Comment: We aren't providing enough support people for the job. We have done the core work, then not followed through on the usability and tools.
• Comment: Prinicple of Least Privilege versus Principle of Maximum Privilege. What works in practice? The more locked-down a machine, the more people look for work-arounds.

• Shibboleth can be very helpful in linking everyone to all their attributes. With such a system (see slides) if someone leaves the university, they automatically lose all rights to use grid systems.
• Need to agree on a common vocabulary for Shibboleth. There are a small set of agreed-upon attributes, but there will also be specific, per-location or per-person attributes.
• Ideally, we don't want to send the requesting portal more credential attributes than are actually necessary. We also don't want to send these credentials to untrusted services.
• Therefore, we need an attribute release policy in order to securely push attributes to collaborators.
• Attributes received at portals can be used to personalise the experience for the user. The resource can be presented differently and more appropriately. Access can be scoped by user role and institution.
• The resources themselves won't just trust the portal. Delegating services. Federated Access Control.
• Discussion on VOMS

Angela Sasse & Philip Inglesant - Usability in specification of authorization policies

File:ESI Theme workshop Sasse Inglesant.ppt slides.

Opening Comments

• Original idea - using natural language to describe policies should reduce the scope for errors.
• Both input and output are in natural language - the "virtuous circle". There was already a natural language output - but this also needs some improvements
• First steps: qualitative interviews with people working on the grid. This explored key words and phrases that they used, along with the key security issues and how they would like to mitigate them.
• Creation a controlled natural language interface, as a menu option from the existing GUI. This is aimed at users who are not specialists in security, but still want to use or manage part of a grid. System Administrators and users.

Considerations and Motivation

• Some data is sensitive and/or commercially valuable. This makes people hesitant to use the grid. This is not only in the most obvious areas - e.g. census data could be commercially valuable if processed in some way, even if the raw form is public and not necessarily sensitive.
• Data needs to be accessible at varying levels of granularity. Alternatively, anonymisation can be thought to overcome some security problems. However, this is tricky because some people have access to more parts of a data set, thus de-anonymising it.
• Question: Is traditional Unix style authN and authZ scalable to the future? Many people consider it to be sufficient at the moment. Should we be using a more Web2.0 style?
• System Administrators have said that they don't want to write policies for everyone - writing fine-grained policies could be too hard. For example, they might prefer just two levels, a "superuser" status and everyone else.
• There are many people who control access to resources - "resource owners" - but are not security experts. There is a range of training: some have system administration knowledge, others do not. Non-security expert resource owners understand their access control needs but struggle to express access control policies.
• People trying to control data have problems writing the rules, they then fail a few times and eventually throw it open to everyone.
• A continuing theme of opening up the grid from just the "expert tinkerers" and Grid pioneers to normal users. This is true for both academia and the business world, where non-technical managers need to express rules.
• Some concepts are particularly challenging - eg. delegation of authority is a difficult concept.
• Comment: Sparcle by IBM is an interesting approach

• PERMIS is an authorization infrastructure where access control policies are written in XML. A GUI helps people write the policies and reduces problems.
• The next step forward from a GUI is the more fundamental approach of using natural language.
• Using natural language for output makes it obvious when something is wrong - reduces scope for mistakes.
• An ontology is used in the background with common terms, such as "resource". Users are unaware of the ontology, but do need to know some of the terms in it. It is specific to e-science access control
• Controlled natural language is then used to extend this ontology with subtypes. E.g. "clusters are a type of resource" "students are a type of user" and "students can access clusters".
• Sentences that don't adhere to the controlled natural language will not compile.

Evaluation

• Evaluated with 17 people, mostly system admins and database admins - the kinds of users who we expect to have to set access control policies as Grid moves into wider use.
• Two scenarios, basic and advanced.
• Findings:
• The participants understood the language building blocks.
• The lack of explicit deny rules (polices are "deny all except") turned out to be intuitive in natural language - eg. "Owners cannot change any data but can read it all" was a task in the scenario but hardly any participants attempted to express "cannot change ..."
• Delegation of roles by "administrators" (a special kind of role, with the special action "assign") is somewhat less intuitive.
• One problem identified was that the users forgot that the natural language was controlled. They then made mistakes, being "linguistically cued" to express sentences in a certain, more natural, way. Typical example - needing to put prepositions in places where natural English does not require them. Perhaps typing into tables, rather than one free-form text editing box, would have been better?
• Users understand concrete terms much better than they do abstract ones - translating the example text into the scenario (in abstract terms) is cognitively difficult, because it requires concepts which are outside users' concrete experience.
• Expressing things in abstract terms has a 60% performance hit as opposed to using a domain that people already understand.
• Comment: could we deal with ambiguous language by letting the computer guess?
• Feedback is useful, as it builds user confidence. It also helps people to understand how the rules they are writing actually affect the domain they are dealing with. So, rather than getting it right first time, users learn by experience how to express policies, even if they do not understand the underlying RBAC and ontology structures.
• Concept of "push and prod" to overcome misconceptions. - the metaphor is of how people examine real-world objects to build up a knowledge of how they work. The enhanced design for the interface should allow users to do this - with GUI, drop-down boxes, tables, controlled natural language all working together.
• People often made mistakes, but couldn't identify where they had made them. This led them to make (sometimes incorrect) rational explanations about the mistake.
• An idea from social networking - using photos of users to demonstrate who has access to a resource immediately shows an incorrect policy.
• Comment: differences between the intent of a user regarding privacy and the actual behaviour. People will always claim that they would never reveal a password, but will under certain circumstances.
• The system should spot when not enough information has been provided by users. Often users know what the rules are, but need prompting to express them.
• The ontology was an intermediate stage between controlled natural language and XML. But using an ontology also opens up some new possibilities - you can use an ontology viewer/editor such as Protege to "push and prod" an ontology.
• There is already translation from XML to natural language - currently an XSLT script - and this could do with some improvements.

Comments

• Does natural language scale large enough for a complex scenario? In such a situation, is it any more readable than XML?
• Discussion: This language is probably not appropriate for real-world sized policies. Experience in testing the language would appear to confirm this, unfortunately. But with our suggested enhanced design - immediate feedback, working better with other parts of PERMIS Editor, etc - it should still have a part to play, perhaps as saved scripts for longer policies.
• Is this just another language to learn? Most technology people can already write XML.
• Discussion: However, E-science is hopefully developing beyond technologists, and as such people will want something as easy as this to express themselves.
• Can we make many different domains, each with their own ontology, interoperate? There will be mismatches and conflicts - can we spot them?
• Discussion: After the natural language input, the policies are augmented with URIs/URLs or, for example, LDAP directory entries chosen from a drop-down box, in order to disambiguate.

David Chadwick

File:TrustWshopOxfordDWC.ppt slides.

Diagram of an Authorization System.

• Interesting point - this diagram features policies specifying whether _outgoing_ requests may be made. This met with lots of interest from the group. Such a feature is good if you want to prevent your users from over-utilising expensive grid resources.
• All requests must go through the PDP. There is an implicit assumption that no back doors exist.
• there is an alternative model, where policy decisions are moved away to a validation service. This is the CAS model?
• Question on on scalability: if everyone has their own PDP, is there a problem with policy consistency? No, the policies control the site resource, not the VO.
• PDPs are, in theory, application independent.

Linking Service

• Only the user knows the location of all the different attributes and authorities involved. The user may have lots of persona's, each with different attributes.
• Each application gateway needs to know your VO user name, which may be different to your university login. These need to be linked.
• There is a need for a linking service - a trusted third party - who can link the information together.
• It essentially lets you log in to two attribute authority, gain permanent random identifiers for each, and then link them together.
• Service providers can request this link information from the linking service.
• Levels of Authentication has been added
• IdPs are likely to be strongly coupled with the linking service. But it might not, if IdP is untrusted.
• There is an SP written in C for Apache, and there is an LS in Java
• Cardspace is a promising application, but limited. It can only send one card at a time.
• Problem spotted: you can't have multiple accounts at the same linking service. This is because it wont know which PID to return in the protocol. Slide on the Linking Service, first line, shows this problem.

"Break the Glass" Policies

• If the policy that controls access to a resource doesn't allow certain people to have access (either policy was wrong OR the policy was right, but its an emergency) you need a "break the glass" policy.
• A PDP will have special "break the glass" rules, complete with obligations upon granting a "glass-break". A manager might be contacted and an audit trail left.
• The challenge is to build an obligations service.
• Comment: What about private users without managers? how do you prevent abuse?
• Comment: Does breaking the glass have a lifetime?
• Comment: what about granularity? Which permission (not resource) can you break? just write, just read, etc?
• Comment: Related to the "sealed envelopes" concept within the NHS.
• Comment: Should there be policies involving what happens when you break the glass - is there an advantage to unbreaking the glass again in a timely manner?

Jens Jensen - Usability from the service provider's perspective.

Presentation (4.3MiB)

• A wide range of data being dealt with. Sometimes confidential or sensitive. Particularly biological and medical data appears to be most important.
• Why security? Service Providers want to protect hardware, also want to meet service contracts - e.g. file quotas.
• Sometimes it is all about accounting. Over use of resources on the grid is acceptable, the users just get charged more.
• Sometimes, however, funding bodies are involved. In such situations the service provider needs to track resource misuse.

• There is a need to work globally and be compliant with laws in other countries.

Practical Aspects: What usability means to the Service Provider

• Most technology is experimental, and must be tested before you know its capabilities. Some things dont work well on the grid, despite conforming to standards
• The service provider may have to impose constraints that may seem unusual to users, but are there to overcome technology limitations
• Standards are a good thing, but need to be interoperable.
• Paper standards are useless - need a software library that works in the language you care about. C is therefore good, as everything works with it.
• Need > 2 independent implementations
• Need usable licenses which can safely be linked with other code
• On the grid you can never trust the standard - implementations never meet them!

Authentication

• People have different numbers of credentials - site passed, X509, Active Directory listing.
• Most credentials are not joined together, and this can be good or bad.
• Be careful not to rely on email addresses, they get reassigned.
• Any type of security needs to be looked at from dozens of different perspectives due to the range of users.

Usability for the System Administrator

• Needs to be able to maintain and deploy the system easily.
• Needs access to the knowledge base
• The workflow for managing users is huge.
• It would be useful to be able to show the end user a clean view of the system and what it can do.
• Problem: The person who decides what credentials to give a user is often not knowledgeable of the user's needs.

Comments about the registration process and the strength of the token.

• Inital authentication is just an email address, but then the registration authority has a face-to-face meeting.
• There is no point having any stronger authentication than the initial registration process.

Removing Duplicate Users

• Problem: People move institutions, how do you prevent duplicate users appearing on the system?
• How do you update access control for a user who has moved institution. The universities own the data, not the user. Very complicated IP rules.
• Things break when users have multiple accounts.
• Currently about 15000 users, several facility user offices. But each user office needs to have consistent unified user databases.
• There needs to be a unified account management system.

Service Provider Usability

• Problem: Real usability issue with the federal id, people complain about it. Users would prefer to keep the nice, user-friendly email address identity - "joe.user@institution" but instead are given a federal id "ju4y2378@xyz" because of Linux system limitations

Service Providers want usability in the form of

• A minimum amount of support they need to provide
• The ability to let the good guys in and the bad guys out.

Problem: Have to make sure that the commercial libraries, on academic licenses, aren't used for commercial purposes. which means commercial users cant access them!

Account management and AuthZ

• Single sign-on is very desirable.
• Therefore, set up a DB to associate all credentials with the user
• Single Account Management service
• SCARF cluster
• External users access resource with certificates.
• Internal users have single sign-on, with credentials thrown away immediately after logout. This lets the internal users play, then they can register for permanent accounts.

Avoiding Certificates

• Certificates are difficult to use.
• On-site use Kerberos/Active Directory. This goes to a MyProxy Service, and then goes to grid resources.
• MyProxy can hide all the certificates from the users, so all they need to do is log in to a proxy.
• It is necessary to build security into the grid, as many applications that run on it do not have any.
• Not possible to hide everything from the user - certificates sometimes need to be renewed or revoked.
• E-science CA, the bar is set intentionally high - certificates have to be accepted internationally on many grids.

Robot Certificates

• Have been designed and need acceptance for use internationally.
• Its a certificate that you want to be able to leave unattended, so jobs can run without monitoring.

How important is usability?

• VERY
• More for some than others
• Not for technical users, they arent afraid of certificates
• Yes for health workers, who seem to have problems understanding parts of it
• Not some much for some groups - physicists have less trouble.

Usability and Interoperability

• Interoperability improves re-usability
• Improve security by improving usability.

Final thoughts

• Aim to build stuff that works
• Build ON stuff that works
• Grid computing is an experimental science

Bruce Beckles - User Friendly Grid Security

Opening Comments

Definition of a "grid"

• distributed
• transparent to users
• across multiple administrative boundaries.

• No true grids in experience - perhaps the internet? - but that's the aim.
• RealityGrid project is an example. It is an e-science pilot project that will be maintained for the next 5 years. It is used for the modelling of complex condensed matter systems. It had HPC requirements, and therefore has to run on a grid across multiple administrative domains. It uses TerraGrid and NGS
• Current primary focus is to minimize end-user interaction with X509 Certs.

Contextual Interview

Contextual interviews were used in order to find out how users would like to work and how they would like grid computing to fit in.

• Biggest hurdle for users was authentication, never mind authorization.
• Remote sites want to know who you are, where you're from and what project you're associated with.
• The user wants to know who they are talking to.
• The challenge is that every node needs to know these things.

Current infrastructure is PKI.

• Each user gets a digital cert.
• Users must go to a registration authority to prove your own identity.
• However, small institutions don't have an RA.
• It is also quite difficult to prove yourself to your RA.
• Users must acquire proxy certificate, then send it to grid middleware. in theory this is fine.
• difficult to use security systems are inherently insecure, as end-users now try to subvert your system.

Investigations with users:

• There is rampant certificate sharing amongst users. This is because of difficulties obtaining certificates and problems in getting certificates to work.
• Users found it ridiculous that a resource they consider not-very-important, the grid, required serious pain and set up whereas online banking just works.
• No evidence to suggest that new users, the current situation, has changed. Usability is still bad.
• Comment: Banks are doing something similar with the new card readers.
• Users store private keys in multiple locations
• Comment: MyProxy solves the private-key storage problems. This should be set up automatically.
• Comment: PKI is fine so long as it is transparent. For example, its used by Shibboleth, but users don't know anything about it. Need to add a layer of abstraction between user and a PKI system.
• Comment: If you don't need to work on a compliant international standard, you can do much more. Perhaps you could have an easier interface for NGS, so users can get their feet wet? Some people don't need international grids.
• Although less common now, users sometimes reuse certificates in the wrong context. This is because it was too difficult to get new ones.
• Certificates SHOULD be reusable, but the end service providers were not being sensible with certificate management.
• Comment: Misconception that the certificates bind you to the institution. Not true - they just say that at the time of signing, the institution was somehow related. They should be just proof of identity, not a link.

Remedy: Hide the certificates from users

Sharing Keys

• Some users refuse to use the grid environment with digital certificates.
• BRIDGES did refuse to use the service if they had to have a digital certificate. Now they use one where the portal has the certificate, they just log into that.
• There is an accountability and audit trade-off.
• Shared certificates result in a loss of accountability. Very difficult to know how many people are sharing a cert/private key.
• It is hard to prosecute a user for sharing keys, as they claim the system is unusable
• There are examples of users for 5+ years sharing keys.
• There are no case examples of how you solve problems of key sharing.
• Comment: Even if you hide the certificates, give people user names and passwords, they will still share the passwords and make mistakes.
• This is not a technical problem, but a social one, and there need to be social consequences. Users neeed to be brought to account for sharing credentials.

Solutions

• Education about certificates - takes the form of documents or manuals or agreements. This doesn't seem to be taken on board.
• Change the economics of certificate sharing. Attach the certificate to another token that they use for something else. E.g. if you use a complete "shibbolethised" system, then sharing a certificate suddenly means a lot more. Sharing a credential makes them much more vulnerable to other problems.
• Comment: Privacy concerns? Shibboleth can give pseudonymous IDs. Privacy problems can be minimized. Comment that IDs become used for systems beyond normal intentions.
• Jens Comment: They use a similar system - the only way you can share grid credentials is to physically log someone in as yourself. In which case they can access your email and entire account, so users have an interest in not doing it.
• Need to make it easier to obey the rules than to break them.

Current Show Stoppers

• Users having to acquire digital certificates.
• A trial started with 7 or 8 undergraduates. They were made to go through the whole system. It took between 1 and 4 weeks to acquire a certificate.
• Despite seeing all the advantages, users said the process took too long and said they wouldn't do it.
• Comment: Most people say it takes only a few days to get a certificate. New Roaming RAs reduces time. It is now possible to get a certificate in 5 days.
• Comment: Put time delay in context, it often takes several days to get access to university network when you first arrive.
• Many other hurdles to jump over after getting the certificate.

Two approaches to handle the certificates problems

• Translate local authentication mechanism to global grid authentication. Log into your machine and you are automatically on the grid. The issues go away. However, middleware would need to be modified, in order to connect local authentication to global.
• Jens comment: actually quite easy to do this.
• Secondary issue is that we were trying to avoid users having to go and fetch their own certificate. Certificates could be auto-generated, but it might be a bit of a problem getting the grid to accept them,
• Designated user gets a certificate. This is given to a credential authority. The users uses a local authentication service to authenticate to a gateway service. a gateway service "hosts" the application the user wishes to run, obtaining a proxy certificate from the credential repository as necessary. This is effectively issuing proxy certificates to the user.
• Comment: This might be considered certificate sharing and violates the terms of grid use.
• There needs to be some identification of the user here.
• Robot certificates sound like the answer

Final Comments

• Usability implies that security credentials should be interoperable with all credentials out there on the grid. Users should not need to have new credentials, they should be able to use local security tokens.

• Collaborate working spaces on the web work because you have complete audit and logging, which means that you know who did what. E.g. wikis, source code repositories. Grids, on the other hand, dont tell you this.

Howard Chivers - Industrial Requirements For Grid Security (Project CRISP)

• This talk is different to those already discussed, as there is a focus on general security requirements.
• The purpose of the project is to involve industry in grid technologies.
• Industrial and academic partners.
• No solutions here! Just problems.

Back Testing

• Postulate a position - sell at 50p - then take historical period and see how well you did. You can then apply this to today's portfolios.
• This is done today, behind closed doors, in a confidential environment.
• There is an incredible amount of data and a need for serious precision.
• This is therefore a good job for a grid, as it would let you scale up.
• Customer is an investment bank - users are Quants.

Back Testing Security Requirements

• Confidentiality of trading intentions - algorithms AND data.
• Confidentiality of trading positions
• Traceability - only willing to run proved-sensible algorithms.
• Record provenance of results
• There is a need to match the grid resources with the industrial confidentiality requirements. The businesses care about the whole picture, not just technical details. E.g. who has access to the backup tapes, are there any system administrators in the room when a job is running?
• How can we deal with the overall security issues when the grid only makes promises about certain aspects of it?

CFD Software

• Customer might be designing a new ship, and need to calculate its infra-red signature. It takes a large number of computations to work this out, and therefore this is a classic grid opportunity.
• They would like to see a market for cpu cycles.
• In-house resources are either ludicrously over used or underused. They want to buy cycles, and they want it to be a competitive market, so to push down the prices.
• Lots of working data that is discarded afterwards.

CFD Security Requirements

• Compliance with export restrictions.
• Software can't move to the wrong place, or through the wrong territories.
• Export restrictions don't just cover the software, but services and training associated with the software.
• Accountability. Software provider wants to be paid - licensing agreements are needed.

Dynamic Workflow

• Want to deal with workflows that deal with incidents, e.g. a search and rescue operation.
• Might want to request satellite imagery. But CIA wont let you.
• Want to be able to use classified information in a non-classified way.
• Require short periods of extremely high computing resource usage.
• Grid jobs needs to know if it is dealing with confidential data.
• Careful policing of all the entry and exit points, in terms of access control and physical security.

Observations

• Security objectives go beyond the system. The activities of people, SysAdmins, backup, etc.
• Require constraints on outgoing calls,not just incoming ones.
• If you want to export jobs, you can only send them to places where you know the security situation.
• Need to create contracts - "green services" that require certain job attributes, so that jobs are only passed on to the right places.
• Need symbols for "export restricted" or "thats private"

Panayiotis Periorellis - SecPAL: Security Policy Assertion Language=

• SecPAL is Microsoft's response to XACML
• Developed along side the GOLD project, along with verification tools for XACML policies using VDM

SecPAL

• Similar to a combination of XACML and SAML
• Has a formal model
• Is more expressive than XACML
• Is extensible in theory
• Has a free academic license
• Comment: Some resistance to using a Microsoft tool due to licensing issues
• Has Java APIs
• Clear, readable and close to natural language. It uses English sentences with a restricted grammar.
• Supports delegation (and easy to do, too)
• Declarative
• Serializes as XML
• Has Facts, Claims and Assertions. E.g. "Alice says Bob can say X can read foo.txt"
• Can express constraints and conditions, for example time constraints.
• Supports assertion revocation
• A token is a signed collection of claims made by a single issuer.
• Need to avoid "unsafe" assertions where too few of the terms are ground.
• SecPAL evaluates policies using Datalog, a subset of Prolog.

Advantages over XACML

• Can create proof graphs of why decisions are made
• Audit logs are easy to build in, you can have audit rules attached to certain actions. E.g. every read of a file.
• "not proven" statements
• "canActAs" rules

Software Demo

• Available 19th/20th may on MSDN website
• SecPAL is still in evaluation, feedback appreciated.

Questions

• You can't make negative assertions, but you can revoke assertions. The revocation is an assertion in itself.
• PERMIS and LDAP has an exceptional condition where you can allow a big group, then deny individual exception cases. Does SecPAL support this?
• Is it intuitive? Answer: planning on releasing and finding out.

• Are there advantages and disadvantage to mixing AuthZ and AuthN? Interoperability between a PERMIS system and this system might be difficult because SecPAL just gives a decision, not tokens or statements.
• SecPAL is admittedly less flexible in this way.
• Integration would not work. Translation from XACML to this does work, but not the other way around.
• On the other hand, SecPAL is more expressive.
• There are some very complicated examples which work well.

• Discussion about whether an example policy creation environment is needed? Who is the target audience? Is releasing the API enough? Is an editor needed?
• A C++ Version is needed.
• A policy editor might demonstrate bigger, more persuasive examples
• Verbs are conformant with the Microsoft published policy language specifications
• Questions about policy intersections. Can you intersect what a resource provides and what a user requires? Some languages offer this facility.

Andrew Martin - Questions and Discussion Points

Key Themes

• Quality of implementations is a problem. There needs to be more "shrink-wrapped" software available, along with better support.
• The grid seems to have a fairly "old fashioned" security architecture, in that should anyone break in, all resources are open to them. A need for defence in depth.
• "Power users" versus everyone else. Trying not to alienate one group over the other. One interesting point: power users tend to be more concerned with physical resources, whereas normal users are more interested in the services provided.
• Credential interoperability. This requires substantial interoperability in terms of infrastructure, semantics and more. There are technological solutions, but some may not preserve the meaning of a credential.
• A lack of engineering. There are many approaches, but no guidelines, advice or best-practice guides. Much of this is due to how context-sensitive grid security is. However, there should be common themes. E.g. in E-Health you should use product XYZ.
• "Robot Certificates"
• There needs to be a way of monitoring tasks running within one VO, so that one member cannot inadvertantly use all the VO's resources.
• Account systems and resource usage monitoring software does not exist
• International consequences to engineering decision made in the UK.
• Resource provider wants to be able to find out when a credential has been revoked _during_ a transaction.

Discussion

• Comment that grids will never be acceptable for top-level security problems, due to the lack of end-to-end security. Considering the amount of physical access to the nodes. However, there is a balance to maintain between risk and reward.
• The value of robust authZ and authN is dependent on the rest of the security of the system.
• Should grids even worry about authentication? Is it easier to just throw everything open?
• Have grids suffered from trying to be all things to all people? Should the requirements at NGS be specific for low-security systems?
• People are paranoid about grid security and do not estimate the risk properly.
• At the moment we're in the science phase, we haven't got the engineering to make best practice guides.
• Bruce Beckles comment: the authN and authZ current grid situation is broken at the moment; certificates don't work. Are robot certificate the answer?
• International consequences. There is a gap in international consensus. Should we focus primarily on UK E-Science?
• Some people wanted to push Shibboleth as the approved system, others disagreed.