Grid Computing Security Lê Thị Minh Châu Huỳnh Thị Khánh Duyên Trần Thị Thanh Thủy May 11, 2010

Outline Security Fundamentals Security Implications of Typical Grid Usage Scenarios Challenges & Requirements Grid Security Grid Security In Practice 2

Outline Security Fundamentals Security Implications of Typical Grid Usage Scenarios Challenges & Requirements Grid Security Grid Security In Practice 3

What is secured communication? 4

Fundamental Concepts Privacy: only sender and receiver should be able to understand the conversation Integrity: ensure that the content of receiving message is exactly the same as what sender transmitted, not modified by the malicious user 5

Fundamental Concepts Authentication: parties should ensure each other is the right user they want to communicate Authorization: users do only their own right things based on system policies 6

Cryptography overview Symmetric key Asymmetric key Digital signature Certificates 7 Clear text message Encrypted text Clear text message Encryption Decryption Key A Key B

Symmetric key 8

Asymmetric ciphers 9

Digital signature 10

Digital signature 11

Certificate Is an electronic document which incorporates a digital signature to bind together a public key with an identity Includes:  Public key signed  A name – a person, a computer or an organization  A validity period  Location (URL) of a revocation center  Digital signature of the certificate, produced by the CA's private key 12

Certificate Authority (CA) CA is an entity that issues digital certificates for use by other parties. A CA issues digital certificates that contain a public key and the identity of the owner. 13

CA hierarchies 14

Outline Security Fundamentals Security Implications of Typical Grid Computing Usage Scenarios Challenges & Requirements Grid Security Grid Security In Practice 15

Security Implications of Typical Grid Usage Scenarios Terms Preconditions to user Grid sessions Steps to establish a Grid Session Usage scenarios 16

Terms Grid user Principal Skateholder Grid gateway Grid resource gateway Grid administrator Grid session 17

Preconditions to user Grid sessions Grid-wide unique IDs Some resources will required local IDs  Map from Grid IDs to local user IDs. Multiple authentication sources  All IDs will be issued and verified from single source.  Applications must judge the credibility of authentication servers with regard to the service they provide. 18

Steps to establish a Grid Session Allocation Requests on Per-Resource Basis  Permissions and allocations on a resource depends on the resource owner’s policy Short-lived Credentials  Use short-term proxy certificates in place of the long term Grid ID. Per-Session Security Parameters  EX: person may specify administrator role for particular resource for the life of the session. 19

Usage scenarios Immediate job execution Accessing grid information services Auditing use of Grid resources 20

Immediate job execution User wants to upload a large amount of data to a large data store then it can be accessed and analyzed The specific resource sites may be selected by an agent acting on behalf of the user. The choice is made by a third-party service - “super schedulers” 21

Security requirements The super scheduler interact with the Information Services component(s) of the Grid to identify possible hosts If the user is allowed to execute on the target Grid machines, the super scheduler must remain allocations of the user. A controlling agent or each remote job needs to request resources on behalf of the user through calls to a super scheduler 22

Security requirements Mutual authentication of user and Grid gateway needs to be done before a piece of the job is run The grid gateway must map the Grid ID to a local ID and submit the request to the resource gateway so that the job will run as the authorized local user. 23

Security requirements The executing jobs may need to be given authorization to read and write remote files on behalf of the user If the remote job writes output to files on an AFS or DFS file server, it needs the user’s Kerberos ticket (which may or may not be the same as the credentials used to authenticate to the Grid gateway) 24

Accessing grid information services Information Services is a centralized repository which allows locating services and determining the status and availability of those services Many services requires carefully controlled access to information regarding the services they provide, their current status, and who can use them 25

Security requirements Authentication should take place between the user and the information services The information services should implement the access control policy as desired by the service When publishing information, confidentiality or message integrity on the communication from the publisher to the information services could be required by the publisher 26

Auditing use of Grid resources The site system administrator, the Grid administrator may need to monitor all accesses to the resources at a site The stakeholder may want to monitor the use of just his resource 27

Security requirements The resource gateway server must keep an nonforgeable log of all access by unique user identification and time of access The format of the entries to this log must be negotiated between the system administrator and the resource gateway Access to this log should be carefully restricted, but stakeholders need to be able to see the entries for their resources. 28

Security requirements There is a need to identify a stakeholder with a resource To accomplish real-time intrusion detection, the resource gateway needs recognize and signal especially troublesome resource access requests in additions to logging 29

Outline Security Fundamentals Security Implications of Typical Grid Usage Scenarios Challenges & Requirements Grid Security Grid Security In Practice 30

New challenges 31 The user population and resource pool is large and dynamic A computation (or processes created by a computation) may acquire, start processes on, and release resources dynamically during its execution The processes constituting a computation may communicate by using a variety of mechanisms, including unicast and multicast An individual user will be associated with difference local name spaces, credentials, or accounts, at different sites, for the purposes of accounting and access control Resources and users may be located in different countries.

Requirements 32 Grid systems and applications may require any or all of the standard security functions, including authentication, access control, integrity, privacy, and nonrepudiation  Single sign-on : An entity is allowed to have continuous access rights for some reasonable period with single authentication

Requirements 33  Protections of credentials: User credentials (passwords, private keys, etc.) must be protected  Authentication: Entities are provided with plug points for multiple authentication mechanisms  Delegation: Users can delegate their access rights to services Delegation policies also can be specified

Requirements  Exportability : exportable and executable in multinational test beds  Support for secure group communication : A computation can comprise a number of processes that will need to coordinate their activities as a group  Support for multiple implementations : It should be possible to implement the security policy with a range of security technologies, based on both public and shared key cryptography

Outline Security Fundamentals Security Implications of Typical Grid Usage Scenarios Challenges & Requirements Grid Security Grid Security In Practice 35

Grid Security 1.Current Status of Grid Security A. Authentication and Delegation – The use of X.509 Certificates : Authentication by a distinguished name in a certificate under shared common CAs Delegation and single sign-on through the use of X.509 proxy certificates – Username and Password Authentication supported in GT4 36

Grid Security Supporting WS-Security standard as opposed to X.509 credentials – Delegation of proxy certificates Remote generation of user proxy Generation of a new private key & certificate using the original key Password or private key are not sent on network.

B. Authorization - Pull Model. Granting a user’s rights only on the specific conditions. Delegating rights which a user specifies. Managing rights with a user and resource providers Grid Security

Example : Akenti

Grid Security Push Model – Granting a user’s rights according to his or her role – Managing rights with a central administrator – Example : CAS, PERMIS, VOMS

Grid Security 2.Grid Security Architecture Concepts : - A user proxy is a session manager process given permission to act on behalf of a user for a limited period of time. - Resource proxy: an agent used to translate between inter-domain security operations and local intra-domain mechanisms.

Grid Security U, R, PUser, resource, process UP, RPUser proxy, resource proxy CxCredential of subject X SigX{text}“text” signed by subject X

Grid Security User Proxy Creation Protocol 1. The user gains access to the computer from which the user proxy is to be created, using whatever form of local authentication is placed on that computer. 2. The user produces the user proxy credential, Cup, by using their credential, Cup, to sign a tuple containing the user’s id, the name of the local host, the validity interval for Cup, and any other information that will be required by the authentication protocol used to implement the architecture (such as a public key if certificate-based authentication is used): Cup = Sigu {user-id, host, start-time, end-time, auth-info,...}. 3. A user proxy process is created and provided with Cup. It is up to the local security policy to protect the integrity of Cup on the computer on which the user proxy is located. Protocol 1: User Proxy creation

Grid Security Resource Allocation Protocol 1. The user proxy and resource proxy authenticate each other using Cup and Crp. As part of this process, the resource proxy checks to ensure that the user proxy’s credentials have not expired. 2. The user proxy presents the resource proxy with a signed request in the form Sigup{allocationspecification}. 3. The resource proxy checks to see whether the user who signed the proxy’s credentials is authorized by local policy to make the allocation request. 4. If the request can be honored, the resource proxy creates a RESOURCE-CREDENTIALS tuple containing the name of the user for whom the resource is being allocated, tbe resource name, etc. 5. The resource proxy securely passes the RESOURCE-CREDENTIALS to the user proxy. 6. The user proxy examines the RESOURCE-CREDENTIALS request, and, if it wishes to approve it, signs the tuple to produce Cp, a credential for the requesting resource. 7. The user proxy securely passes Cp to the resource proxy. 8. The resource proxy allocations the resource and passes the new process(es) Cp. (The latter transfer relies on fact that the resource proxy and process are in the same trust domain.) Protocol 2: Resource allocation (and proccess creation)

Grid Security Resource Allocation from a Process Protocol 1. The process and its user proxy authenticate each other using Cp and Cup. 2. The process issues a signed request to its user proxy, with the form Sigp { “allocate”, allocation request parameters } 3. If the user proxy decides to horror the request, it initiates a resource allocation request to the specified resource proxy using Protocol The resulting proccess handle is signed by the user proxy and returned to the requesting process. Protocol 3: Resource allocation from a user process

Grid Security Mapping Registration Protocol 1.a User proxy authenticates with the resource proxy. 1.b User proxy issues a signed MAP-SUBJECT-UP request to resource proxy, providing as arguments both global and resource subject names. 2.a User logs on to the resource using the resource’s authentication method and starts a map registration process. 2.b MAP registration process issues MAP-SUBJECT-P request to resource proxy, providing as arguments both global and resource subject names. 1. Resource proxy waits for MAP-SUBJECT-UP and MAP-SUBJECT-P requests with matching arguments. 2. Resource proxy ensures that map registration process belongs to the resource subject specified in the map request. 3. If a match is found, resource proxy sets up a mapping and sends acknowledgments to map registration process and user proxy. 4. If a match is not found within MAP-TIMEOUT, resource proxy purges the outstanding request and sends an acknowledgment to the waiting entity. 5. If acknowledgment is not received within MAP-TIMEOUT, request is considered to have failed. Protocol 4: Mapping global to local identifier.

Outline Security Fundamentals Typical Grid Usage Scenarios Challenges & Requirements Grid Security Grid Security In Practice 47

Globus Grid Security Infrastructure GSI GSI Introduction GSI Functional Layers Message Protection Authentication and Delegation Authorization 48

GSI Introduction 49 Use GSI as a standard mechanism for bridging disparate security mechanisms  Doesn’t solve trust problem, but now things talk same protocol and understand each other’s identity credentials  Basic support for delegation, policy distribution Translate from other mechanisms to/from GSI as needed Convert from GSI identity to local identity for authorization

GSI Introduction (2) 50 Based on standard PKI technologies  CAs allow one-way, light-weight trust relationships (not just site-to-site) SSL protocol or WS-Security for authentication, message protection X.509 Certificates for asserting identity  for users, services, hosts, etc. Proxy Certificates  GSI extension to X.509 certificates for delegation, single sign-on

GSI Introduction (3) Control access to shared services  Address autonomous management, e.g., different policy in different work-groups Support multi-user collaborations Federate through mutually trusted services  Local policy authorities rule Allow users and application communities to set up dynamic trust domains  Personal/VO collection of resources working together based on trust of user/VO 51

Local Identity, Grid Identity, Local Policy 52

GSI’s Use of Security Standards Supported, Supported, Fastest, but slow but insecure so default 53

GSI Implementation 54

GSI Implementation 55

Message Protection Transport-level security  Entail SOAP messages via TLS  Conjunction with/without X.509 credentials with/without authentication Message-level security  Support for WS-Security standard and WS- SecureConversation specification  Allow to comply with WS-Interoperability Basic Security Profile 56

Proxy Certificates 57

X.509 Proxy Certificates 58 GT4-GSI support 3 forms of Proxy Certificates  Old  GT4 default  Fully RFC 3820 compliant Enables single sign-on Allow user to dynamically assign identity and rights to service  Can name services created on the fly and give them rights (i.e. set policy) What is effectively happening is the user is creating their own trust domain of services  Services trust each other with user acting as the trust root

Delegation Service 59 Exposes delegated credentials as first class resource Allows for resource across multiple services  E.g. multiple jobs, RFT requests Allows for explicit destruction and renewal

Community Authorization Service 60 Community Authorization Service (CAS)  Outsource policy admin to VO sub-domain  Enables fine-grained policy Resource owner sets course-grained policy rules for foreign domain on “CAS-identity” CAS sets policy rules for its local users Requestors obtain capabilities from their local CAS that get enforced at the resource

CAS 61

Portal-based Grid Interface: PURSE Portal extensions (CGI scripts) that automate user registration requests  Solicits basic data from user  Generates cert request from CA (implemented with “simple CA” from GT)  Admin interface allows CA admin to accept/reject request  Generates a certificate and stores in MyProxy service  Gives user ID/password for MyProxy Benefits  Users never have to deal with certificates  Portal can get user cert from MyProxy when needed  Database is populated with user data 62

OGSA Security Services 63

Authorization Processing Model 64 Use of a Policy Decision Point (PDP) abstraction that conceptually resembles the one defined for XACML  Normalized request context and decision format  Modeled PDP as black box authorization decision oracle After validation, map all attribute assertions to XACML Request Context Attribute format Create mechanism-specific PDP instances for each authorization assertion and call-out service The end result is a set of PDP instances where the different mechanisms are abstracted behind the common PDP interface

Authorization Processing Model (2) 65 The Master-PDP orchestrates the querying of each applicable PDP instance for authorization decisions Pre-defined combination rules determine how the different results from the PDP instances are to be combined to yield a single decision The Master-PDP is to find delegation decision chains by asking the individual PDP instances whether the issuer has delegated administrative rights to other subjects the Master-PDP can determine authorization decisions based on delegated rights without explicit support from the native policy language evaluators

Authorization Framework 66

Authorization Framework (2) 67

Globus Grid Security Infrastructure GSI GSI Introduction GSI Functional Layers Message Protection Authentication and Delegation Authorization 68

Summary

Why Grid Security is Hard… Resources being used may be valuable & the problems being solved sensitive  Both users and resources need to be careful Dynamic formation and management of virtual organizations (Vos)  Large, dynamic, unpredictable… VO Resources and users are often located in distinct administrative domains  Can’t assume cross-organizational trust agreements  Different mechanisms & credentials X.509 vs Kerberos, SSL vs GSSAPI, X.509 vs. X.509 (different domains) X.509 attribute certs vs SAML assertions 70

Why Grid Security is Hard… Interactions are not just client/server, but service-to-service on behalf of the user  Requires delegation of rights by user to service  Services may be dynamically instantiated Standardization of interfaces to allow for discovery, negotiation and use Implementation must be broadly available & applicable  Standard, well-tested, well-understood protocols; integrated with wide variety of tools Policy from sites, VO, users need to be combined  Varying formats Want to hide as much as possible from applications! 71

Thank for your attentions

References F. Siebenlist, V. Welch, Grid Security: The Globus Perspective, GlobusWOLRD 2005 Globus Security Team, Globus Toolkit Version 4 Grid Security Infrastructure: A Standards Perspective R. Ananthakrishnan, Grid Security: Principles and Practice Marty Humphrey, Mary R. Thompson: Security Implications of Typical Grid Computing Usage Scenarios Jong Kim: Grid Security Authentication and Authorization, IFIP-Workshop 2/7/05 Ian Foster, Carl Kessekan, Gene Tsudik, Steven Tueckel : A Security Architecture for Computational Grids. Internet 73