Grid Security Infrastructure

1. Grid Security Infrastructure Adam Belloum Computer Architecture & Parallel Systems group University of Amsterdam adam@science.uva.nl

2. Security Network (local security policy Security Network (local security policy We have all The needed Resources!!! How can I make Satisfy all the different Security domains Security Network (local security policy Cross Organization Authentication Infrastructure Security Network (local security policy Security Network (local security policy)

3. User point of view “For users, the primary requirement is simplicity: Access to the virtual organization’s resources should not be significantly different from access to the local organization’s resources.” • There should be a single sign-on, where users need to log on only once to access all permitted resources. • Programs running on a user’s behalf should possess a subset of the user’s rights and have access to the permitted resources. Protected channel passwd Randy Butler et al. “A Natioanal-Scale Authentication Infrastructure”

4. Sites point of view The concerns of resource-providing sites constrain an authentication and authorization infrastructure in two ways: • Sites have there local (intra-domain) security policy • Sites typically cannot easily replace or modify their intra-domain security solution. How they see inter-domain security: • a distinct inter-domain solution that interoperates with local security solutions and is: at least as strong as local solutions (will not weaken site security), is easy to understand (administrators can trust it). • Site administrators must have tight control over policies governing access to their resources, including how users establish their identity and which users have access to which resources. Randy Butler et al. “A Natioanal-Scale Authentication Infrastructure”

5. What does security mean? • Authentication (at the source site) • Digital Signature (PKI, kerberos, etc.) • Secure connection (between the source the destination sites) • Authentication • Message protection • Confidentiality (Cryptography) • Encryption • Decryption • Integrity (Digital Signature) • Authorization (At the destination site) • Access restrictions (access control, content filtering, etc…

6. Digital Signature It is really X who Has sent this message I’m want to send IMPORTANT data to Y Internet Digital signature Impersonate X And send false news http://www-fp.mcs.anl.gov/~gregor/grid-iit/

7. Public Security Infrastructure It is really the public key Of X ? How can provide my Public key to Y? Internet Impersonate X Sending false news http://www-fp.mcs.anl.gov/~gregor/grid-iit/

8. Secure Socket layer It is really X who Has sent this message I’m want to send Confidential data to Y Internet Try to read confidential messages

9. A cross organizations Security infrastructure “Grid Security Infrastructure lets users access resources at any participating site without repeated authentication, while preserving a site’s ability to use site-specific security mechanisms and enforce local access control.” “Security requirements within the Grid environment are driven by the need to support scalable, dynamic, distributed virtual organizations (VOs)” Note: • A VO is collections of diverse and distributed individuals that seek to share and use diverse resources in a coordinated fashion. • From security perspective a key attribute of VOs is that participants and resources are governed by the rules and policies of the classical organizations of which they are members.

10. Fundamental Requirements of VO • Access to resources that exist within classical organizations and that have policies in place that speak only about local users. • This VO access must be established and coordinated only through binary trust relationships that exist between • (a) the local user and their organization and • (b) the VO and the user. Note: We cannot, in general, assume trust relationships between the classical organization and the VO or its external members.

11. Security cross Grid (V.O.) Global policy Local policy Local policy Certification Authority (signs the certificates) Global policy Resources providers can delegate Some of the authority for maintaining a fine-grained access Control Policies to communities While still maintaining ultimate Control over their resources Security Network Security Network Global policy Local policy Security Network Global policy Global policy Local policy Local policy Security Network Security Network

12. Key Functions in a Grid Security Model • Multiple security mechanisms. Organizations participating in a VO have significant investment in existing security mechanisms and infrastructure. Grid security must interoperate with, rather than replace, those mechanisms • Dynamic creation of services. Users must be able to create new services dynamically without administrator intervention. • Dynamic establishment of trust domains. In order to coordinate resources, VOs need to establish trust among not only users and resources in the VO but also among the VO’s resources, so that they can be coordinated.

13. Overview of Grid Security Infrastructure • The Grid Security Infrastructure (GSI) is a set of protocols, libraries, and tools that allow users and applications to securely access Grid resources. It is build on some standard security mechanisms such as: • Public Key Infrastructure • Secure Socket Layer And some Specific security mechanisms • Proxy Credentials • Delegation

14. Grid Security Infrastructure (GSI) • The GSI system is based on a Public Key Infrastructure (PKI). • In a PKI, all entities (users and resources) are identified by a globally unique name known as a • Distinguished Name (DN). • Authentication with the GSI is a matter of proving that a user or resource is the entity identified by a DN. • Resources then typically have local configuration for mapping the DN to a local identity

15. GSI uses the PKI • In order for entities to prove their identity, they possess of Grid credentials consisting of a certificate and a cryptographic key known as the private key. • The certificate, simple terms, is a binding of the entity’s DN to their private key. • This binding is done by means of a digital signature from a trusted party known as a Certificate Authority (CA). • This allows an entity to authenticate (using their credentials) by a process that involves presenting their certificate and proving possession of their private key.

16. GSI uses SSL • GSI uses Secure Socket Layer (SSL) to implement authentication, message integrity and message privacy. • SSL is a standard software tool used in web browsers, web servers, and other applications. It uses PKI credentials for authentication and is used in GSI without modification.

17. GSI introduces Proxy Credentials • A proxy credential is a short-term credential that is created by a user, which can be used in place of the long-term credential to authenticate that user. The proxy credential has its own private key and certificate, and is signed using the user’s long-term credential. • The proxy certificate, is a short-term binding of the user’s DN to an alternate private key. Proxy credentials are stored unencrypted on the local file system, protected only by file system permissions, and so can be used by the user repeatedly without inconvenience.

18. GSI introduces Delegation • Delegation is very similar to proxy credential creation as that an existing set of credentials is used to create a new set of proxy credentials that is identical in function. • The difference is that the creation occurs over a GSI-authenticated connection, with the result being the remote process acquiring proxy credentials for the user. Note: It is also worth noting that delegation can be chained. In other words one can delegate credentials to host A and then the process on host A can delegate credentials to host B and so forth.

19. Grid Security Architecture

20. Large Scale Distributed Computation Site B Site A Kerberos physicist Data Site C SSL ap Data Data 1. Request data analysis 2. Contact resource broker Site D SSL guest29 3. Initiate task farm 4. Access parameter values Plaintext ap6 Site G Data Plaintext bcollab Data Plaintext physicist Site F Site E Ian Foster et al. “A Security Architecture for Computational Grids”

21. Grid Security Requirements • Single sign-on • Protection of credentials: • Exportability • Uniform credentials/certification infrastructure • Support for secure group communication • Support for multiple implementations: Ian Foster et al. “A Security Architecture for Computational Grids”

22. Grid Security Policy: terminology • A subject is a participant in a security operation. • A credentialis a piece of information that is used to prove the identity of a subject. Passwords and certificates are examples of credentials. • Authenticationis the process by which a subject proves its identity to a requestor, typically through the use of a credential • An objectis a resource that is being protected by the security policy. • Authorizationis the process by which we determine whether a subject is allowed to access or use an object. • A trust domainis a logical, administrative structure within which a single, consistent local security policy holds. Ian Foster et al. “A Security Architecture for Computational Grids”

23. Grid Security Policy: definition of the security policy • The grid environment consists of multiple trust do mains. • Operations that are conned to a single trust domain are subject to local security policy only. • Both global and local subjects exist. For each trust domain, there exists a partial mapping from global to local subjects. • Operations between entities located in different trust domains require mutual authentication. • An authenticated global subject mapped into a local subject is assumed to be equivalent to being locally authenticated as that local subject. • All access control decisions are made locally on the basis of the local subject. • A program or process is allowed to act on behalf of a user and be delegated a subset of the user's rights. • Processes running on behalf of the same subject within, the same trust domain may share a single set of credentials. Ian Foster et al. “A Security Architecture for Computational Grids”

24. A Computational Grid Security Architecture Protocol 1: creation of a user Proxy Long-lived credential user user proxy CU Cup Temporary credential Protocol 4: creation of a local Global mapping Protocol 2: Allocation of a Remote resource Global to local Mapping table Global to local Mapping table Resource proxy process Resource proxy process Crp Cp Cp Protocol 3: resource Allocation From a process process Local policy And mechanisms Local policy And mechanisms Cp Cp Ian Foster et al. “A Security Architecture for Computational Grids”

25. Protocol 1: user proxy creation 2. The user produces the user proxy credential, CUP, by using their credential, CU, 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) 3. A user proxy process is created an 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. 1. The user gains access to the computer from which the user proxy is to be created, using the local authentication is placed on that computer. Protocol 1: creation of a user Proxy user user proxy CU Cup Ian Foster et al. “A Security Architecture for Computational Grids”

26. Protocol 2: Resource allocation 1. The user/resource proxy authenticate each other usng CUP and CRP . 2. The user proxy presents the resource proxy with a signed request in the form SigUP fallocationspecificationg. 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, the 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. (This is again possible due to step 1.) 8. The resource proxy allocates the resource and passes the new process(es) CP . user proxy Cup Resource proxy Resource proxy Crp Crp Local policy And mechanisms Local policy And mechanisms Ian Foster et al. “A Security Architecture for Computational Grids”

27. Protocol 3: Resource Allocation from a Process Protocol • The process and its user proxy authenticate each other using CP and CUP . • The process issues a signed request to its user proxy, with the form SigP f “allocate”, allocation request parameters g • If the user proxy decides to honor the request, it initiates a resource allocation request to the specified resource proxy using Protocol 2. • The resulting process handle is signed by the user proxy and returned to the requesting process Resource proxy Resource proxy Crp process process Crp Cp Cp Protocol 3: resource Allocation From a process Local policy And mechanisms Local policy And mechanisms Ian Foster et al. “A Security Architecture for Computational Grids”

28. Protocol 4: 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 re- source subject names 3. Resource proxy waits for MAP SUBJECT-UP and MAP SUBJECT-P Requests with matching arguments. 4. Resource proxy ensures that map registration process belongs to the resource subject specified in the map request 5. If a match is found, resource proxy sets up a mapping and sends acknowledgments to map registration process and user proxy. 6. If a match is not found within MAP- TIMEOUT, resource proxy purges the outstanding request and sends an acknowledgment to the waiting entity. 7. If acknowledgment is not received within MAP-TIMEOUT, request is considered to have failed user user proxy CU Cup Protocol 4: creation of a local Global mapping Ian Foster et al. “A Security Architecture for Computational Grids”

29. Security Network (local security policy Security Network (local security policy I Want to access Grid from my home ????????????????? ???????????? Security Network (local security policy Use Web Portals I Want to access The grid resource From every location There is an Internet Connection Security Network (local security policy Security Network (local security policy)

30. Web portals Security requirements • Discussions with the portal development community revealed a number of requirements that impact security. These included: • Users must be able to use any standard web browser to access the Grid portals. • Users must be able to use a web browser from locations where their Grid credentials would not normally be available to them. • Users must be able to do anything through a Grid portal that their credentials would entitle them to do. For example, a user should be able to access the Grid using a web browser at an airport kiosk in the same manner they could from a web browser installed on a system on their desktop in their office. Jason Novotny et al. “An online Credential Repository for Grid: MyProxy”

31. Goals of myProxy system • Allows users to access their credentials from anywhere on the Grid, even if they are on a system without Grid software and without secure access to their long-term credentials. • Allows them to delegate credentials to resources to which they normally would not be able to, since the applications involved do not support the GSI delegation mechanism (e.g. from a web browser to a portal). • Remove, as much as possible, any credentials from the portal except when they are actually needed, in order to lower the risk of compromise if the portal is compromised. • Multiple portals should be able to use a single system in the case of a domain having more than one portal, and a portal should be able to use multiple systems in the case of a portal that supports users from multiple domains. • Gives the user as much control of their credentials and proxy credentials as possible. Portals should only be able to get a user’s credentials if allowed to do so by a user. Jason Novotny et al. “An online Credential Repository for Grid: MyProxy”

32. Delegation to the proxy • A user starts by using the myproxy-init client program along with their permanent credentials to contact the repository and delegate a set of proxy credentials to the server along with authentication information and retrieval restrictions • The user identity is typically different from the user’s Distinguished Name (DN) in the Grid credentials, as it is actually hand-typed by the user at later times. • The credentials delegated to the repository normally have a lifetime of a week. The user can change this to any length of time desired. • The user can also, at any point, use the myproxy-destroy client program to destroy any credentials they previously delegated to the repository. Myproxy-init Myproxy Credential Repository Jason Novotny et al. “An online Credential Repository for Grid: MyProxy”

33. Retrieve Credential from the repository • The user, or a service acting on behalf of the user, uses the myproxy-get-delegation program to contact the server and request a delegation of the user’s credentials. • The user must supply the same user identity and pass phrase that they provided when initially delegating the credentials to the server. • After verifying this information and checking any restrictions that the user presented with the delegation , the repository will in turn delegate a proxy credential back to the user or service. • This delegated proxy from the repository may then be used as any other proxy credential generated by the user to initiate actions on the user’s behalf on the Grid. Myproxy-init Myproxy Credential Repository Jason Novotny et al. “An online Credential Repository for Grid: MyProxy”

34. Using the Myproxy Reposistory with a Grid Portal • 1. The first step to using MyProxy system • with a portal is to delegate a proxy • Credential to the repository. • 2. The portal would then connect to the • MyProxy repository using the myproxy- • get-delegation program, • - authenticates itself using it’s own • Grid credentials, • The repository then, after verifying all • the presented information, would delegate • a proxy credential for the user back to the • portal Step 2: Web portal authenticates to repository & sends requests, including user authentication data Myproxy Credential Repository Myproxy-init Step 3: Repository delegates user credential to portal Step 1: User sends authentication data to portal Web browser Jason Novotny et al. “An online Credential Repository for Grid: MyProxy”

35. Security as a Service With OGSA everything is defined as a Grid Service Why not security?

36. Security As Service • The OGSA security model casts security as OGSA services • This strategy allows well-defined protocols and interfaces which permits applications to outsource security functionality by using a security service to with a particular implementation to fit its current load Von Welch et al. “Security for Grid Services”

37. Secure operation in a Grid environment • Requires that applications and services be capable supporting a variety of security functionality, such as: • authentication, • authorization, • credential conversion, • auditing, • and delegation. • Grid applications need to interact with other applications and services that have a range of security mechanisms and requirements. • These mechanisms and requirements are likely to evolve over time as new mechanisms are developed or policies change. • Grid applications must avoid embedding security mechanisms statically in order to adapt to changing requirements.

38. Web Services Security Specifications • Emerging of Web services security specifications address the expression of Web service security policy • WSPolicy • XACML • Emerging of standard formats for security token exchange • WS-Security • SAML • Emerging of standard methods for authentication and establishment of security contexts and trust relationships • WSSecureConversation • WS-Trust.

39. A draft OGSA Security Roadmap Presented in 2002 to the Global Grid Forum itemizes numerous security services, including following. • Credential processing service • Authorization service. • Credential Conversion service • Identity Mapping service • Audit Von Welch et al. “Security for Grid Services”

40. OGSA security Component Layering Intrusion detection Secure conversation Credential And identity translation Access Control Audit Non-repudiation Anti-virus Management Trust Model Security logging Policy management Service/end Point policy Mapping rules Authorization Policy Privacy Policy User management Policy Expression and Exchange Key management Binding security (transport, protocol, message security) http://www.cs.virginia.edu/~humphrey/ogsa-sec-wg/ogsa-sec-roadmap-v13.pdf

41. Hosting Environment • Grid services, like the Web services they leverage, may be built on sophisticated container-based hosting environments • These hosting environments provide a high level of functionality and allow for much security implementation complexity to be pulled from applications. • Most security functionality will be placed in hosting environments, simplifying application development and allowing security functionality to be upgraded independently of applications. Von Welch et al. “Security for Grid Services”

42. Publishing of security policy • In order to establish trust, two entities need to able to find a common set of security mechanisms that both understand. • The use of hosting environments and security services, enables OGSA applications services to adapt dynamically and use different security mechanisms. • However, an application can select the proper security mechanisms and credentials only if it knows what mechanisms and credentials are acceptable to the service with which it wishes to interact. Von Welch et al. “Security for Grid Services”

43. Publishing of security policy • The WS-Policy specification and its related specifications define how a Web service can publish its security policy along with its interface specification as part of a WSDL document. • a published policy can express requirements for mechanisms, acceptable trust roots, token formats, and other security parameters. • An application wishing to interact with the service can examine this published policy and gather the needed credentials and functionality by contacting appropriate OGSA security services. Von Welch et al. “Security for Grid Services”

44. Specified Format for Security Tokens • The WS-Security, WSSecureConversation , and WS-Trust specifications contain conventions and formats for the communication of various mechanism specific tokens (e.g., Kerberos tickets and X.509 certificates) inside SOAP envelopes. • This enveloping standardizes the protocol for security mechanisms and allows mechanisms to be independent of any application protocol. • Hosting environments can recognize security-related messages and route them to an appropriate service for handling, and entities in the network can recognize whether and how an interaction is secured. Von Welch et al. “Security for Grid Services”

45. GT3 OGSA Security Model 1. The client’s hosting environment retrieves and inspects the security policy of the target service to determine what mechanisms and credentials are required to submit a request. Hosting Env. Hosting Env. 2. If the client’s hosting environment determines that the needed credentials are not already present, it contacts a credential conversion service to convert existing credentials to the needed format, mechanism, and/or trust root. Two examples of such services are - CAS, for translating the user’s personal credential to a VO credential, - and KCA, for converting between Kerberos and PKI mechanisms. 3. The client’s hosting environment uses a token processing and validation servicE (e.g., XKMS) to handle the formatting and processing of authentication tokens for exchange with the target service. This service relieves the application and its hosting environment from having to Understand the details of any particular mechanism. OGSA Client Published Security Policy OGSA server 4. On the server side, the hosting environment likewise uses a token processing service to process the authentication tokens presented by the client. In the example, both use the same service, but each could use a separate service. 5. After authentication and the determination of client identity and attributes, the target service’s hosting environment presents the details of the request and client information to an authorization service (e.g., PERMIS or Akenti) for a policy decision. 1 2 5 3 4 Credential Conversation Service Authorization Service token Processing Service Von Welch et al. “Security for Grid Services”

46. GT3 Security Implementation • The Grid Security Infrastructure version GSI3 of the Globus Toolkit version 3 is an initial implementation of key components of the OGSA security model. • This implementation has two key advantages over its GT2 predecessor: • Use of WS-Security protocols and standards. GT3 uses SOAP and the Web services security specifications for all of its communications. This allows it to leverage and use standard current and future Web service tools and software. • Tight least-privilege model. In contrast to GT2, the GT3 resource management implementation uses no privileged services. All privileged code is contained in two small, tightly constrained setuid programs. Von Welch et al. “Security for Grid Services”

47. GT3 Security Implementation(Use of Web Services Security and Protocol) • GT3 uses Web services specifications to be: • transported, • understood, • and manipulated by standard Web services tools and software. • GT3 offers both stateful and stateless forms of secured communication. Von Welch et al. “Security for Grid Services”

48. Stateful Secured Communication • GSI3 supports establishment of a security context that serves to authenticate two parties to each other and allows for the exchange of secured messages between the two parties. • The GT3 implementation achieves security context establishment by implementing WSSecureConversation and WS-Trust, which use SOAP messages to transport context establishment tokens between the two parties. • Once the security context is established, GSI3 implements message protection using the Web services standards for secured messages (XML-Signature and XML-Encryption ). Von Welch et al. “Security for Grid Services”

49. Stateless Secured Communication • To allow for communication without the initial establishment of a security context, GT3 offers the ability to sign messages independent of any established security context, by using the XML-Signature specification. • Thus, a message can be created and signed, allowing the recipient to verify the message’s origin and integrity, without establishing synchronous communication with the recipient. • A feature of this approach is that the identity of the recipient does not have to be known to the sender when the message is sent. This allows for messages to be created by clients and delivered to services whose creation is caused by the message itself Von Welch et al. “Security for Grid Services”

50. GT3 Security Implementation“Least-Privilege Model” • A well-known principle in computer security that states that each entity should only have the minimal privilege needed to accomplish its assigned role and no more. GT3 introduces two notable features that improve its security through the least privilege principle. • No privileged services. • Minimal privileged code. Von Welch et al. “Security for Grid Services”