------------------------------------------------------------------------


Globus System Security Policy and Requirements : v0.2


------------------------------------------------------------------------


Status of this Specification



This document is a draft for discussion.



Introduction: Security and Globus



Globus security mechanisms are intended for an environment in which "users" initiate "computations" that acquire, use and release multiple, geographically distributed "resources". Some properties of these entities are:



•The user population may be large and dynamic. •The resource population may be large and dynamic. •A computation may acquire, start processes on, and release resources dynamically during its execution. •The processes comprising a computation will communicate by using a variety of mechanisms, including unicast and multicast. While these processes form a single fully-connected logical entity, low-level communication connections (e.g., TCP/IP sockets) may be created and deleted dynamically during program execution. •Resources may support different authentication and authorization mechanisms and policies and we will have limited ability to change these. •Users will have different user ids on different resources. •Resources and users may be located in multiple countries. 



In general, applications running under Globus will have requirements for all standard security requirements: 



•authentication: parties can prove their identity, •authorization: a subject is given access only to resources to which they are entitled to use, •integrity: the contents of a communication between two or more parties have not been altered, •privacy: the contents of a communication are not disclosed to unauthorized parties, and •non-repudiation: the sender of a communication cannot deny that they were the sender, and the receiver cannot deny receipt. 



Not all Globus applications will require all of these security services. Furthermore, clear definition and implementation of all these services is difficult and in some cases represents research topics in computer network security. For these reasons, Globus must carefully define the security requirement and restrict what security services will be provided. The purpose of this document is to clearly state these restrictions in terms of a well defined security policy and a set of security requirements. The security services provided will be expanded as Globus develops. However, this specification focuses on the security characteristics of the initial release of Globus. 



Initial Requirements and Security Policy for Globus



A security policy defines what it means for a system to be secure: essentially stating who can do what and to whom. We define the security policy for Globus in terms of an abstract system model which consists of five basic components:

TermDefinitionUser (U)The person or agent on whose behalf the Globus computation is being run.UserProxy (UP)A process (i.e. session manager) given permission to act on behalf of the user for a limited duration of time.Process (P)A logical entity, created via the process management API which performs computation on a particular resource on behalf of a particular user.Resource (R)A computer, file system, network or other other object that can be used as part of a computation.ResourceProxy (RP)An agent (i.e. process or resource) that has permission to act on behalf of the resource. Examples of resource proxies include process managers and resource managers.


We will also use the following terms from the security literature:



•Credential. A credential is a piece of information that is used to prove the identity of a subject. Examples of a credential include passwords and private keys. We distinguish between credentials that are introduced by Globus, Globus credential, and credentials that are used only on a specific resource, resource credential, •Subject. Authorization is the process by which we determine if a subject is allowed to access or use and object. In Globus, a subject is generally a user, or a process operating on behalf of a user. A Globus subject is a subject that is recognized by components in the Globus system. A resource subject is a subject that is only recognized by a specific resource. •Trust. We say that A trusts B if A assumes that any information sighed by B is believed by B to be "correct". •Trust Domain. A trust domain is an administrative structure within which local security policy holds. For example, authentication may not be required between subjects within a trust domain. 



The security policy for the initial release of Globus is defined by identifying how these components interact with one-another. The initial security policy for Globus focuses exclusively on authentication. With this criteria in mind, we define the following security policy:



•Authentication is required on all interactions between a user proxy and a resource proxy. A process may authenticate itself to another process. No other authentication is required. •All authentication is mutual. •A user proxy can interact with resource proxies on behalf of a user, and with the same privileges; but this power is granted only for a limited time. In other words, if a resource proxy trusts a user, it will also trust a user proxy for that user. •Mutual trust exists between resource proxies associated with the same resource. •A process trusts the process manager that created it. A process manager is a resource proxy that is responsible for process creation. •A process manager and the processes it creates are assumed to execute within a single trust domain. •There is a mutual trust relationship between all processes created by the same user proxy/resource proxy pair. •Access control for a resource is specified by local policy and implemented via local mechanisms. •Any Globus specific subject can be mapped into resource specific subjects (e.g. user ids) for local access control mechanisms. 



In addition to the above security policy, we require that the Globus system meet the following security related functional requirements:



•Single sign-on: A user should be able to authenticate once to "Globus" (e.g., when starting a computation); a computation should then be able to acquire, use, and release resources, and communicate internally, without additional authentication from the user. •Protection of credentials: User credentials (passwords, private keys, etc) must be protected. •Interaction with local policies: Globus security policy must interface with locally enforced security policies, mechanisms and implementations, such as firewalls, Kerberos authentication, one-time passwords, etc. •Support for multiple implementations: The security policy should not dictate a specific implementation technology. Rather, it should be possible to implement the security policy with a range of security technologies, for example, X.500 based public key, PGP public key, Kerberos shared secret and SESAME. •Portability: We require the security policy be portable in two senses. We must support different security mechanisms, such as those built around X.509 certificates and Kerberos. •Exportability: Code can be (a) exported and (b) run in multinational testbeds. In short, the exportability issues mean that Globus security policy cannot directly or indirectly require the use of privacy. •Robustness. The security algorithms must be designed in such a way that if a component is not being used, that component can be restarted without requiring any other component to be restarted. That is, security algorithms must localize their user of system state. 



The rest of this document presents the algorithms required to implement the Globus security policy and security requirements. These algorithms are presented in an abstract form. A companion document discusses specific implementation issues.



Security Relationship Between a User and Their Proxy



Globus is not a "machine" into which one logs on. Globus computations grow and shrink dynamically. Each time a computation obtains a resource, it does so on behalf of a particular user. However, in a Globus computation, it is often not possible for a "user" to directly interact with all the resources that are part of the computation. To resolve this issue, we introduce the concept of a user proxy which can act on a users behalf without requiring user intervention. The Globus security policy states that for a well defined time period, the user proxy can operate as place of the user. 



The most direct way for a user to enable a proxy to act in their behalf is to give the proxy the user's credentials, such as a password or private key. The proxy can then use those credentials directly. However, this approach has the possibility of compromising the users credentials, which is something that must be avoided at all costs. Furthermore, this approach does not allow the user to restrict the time duration for which a proxy can act on the users behalf.



We address these problem by generating a temporary credential for the user proxy and indicating the users permission to use this credential on their behalf for a specific time period by signing the credential with a digital signature. In detail, the process of creating a user proxy is the following:



1.The user gains access to the computer from which the user proxy is to be created. 2.A temporary credential is created for the user proxy. We denote this credential as C'UP. 3.C'UP is signed by the user using their credentials. We denote the signed credential by 

CUP = CU{C'UP, start-time, end-time}



That is the credential for the user proxy consists of the temporary credential, and the time period for which that credential is valid, all signed by the user.

4.A user proxy is created. It is provided with the signed temporary credential. 



The key to this algorithm is that the temporary credential can be used to authenticate the user proxy with resource proxies, and the fact that it is signed by the user indicated the user's approval of the user proxy's actions. 



Resource Proxies



In Globus, operations on resources are mediated by a resource proxy. Currently the only defined resource proxies is the Globus resource allocation manager (GRAM). The resource manager is responsible for scheduling access to a resource and mapping a computation onto that resource. In brief, the resource manager is used as follows. A user (or, more precisely, a user proxy acting on behalf of the user) requiring access to a resource first determines the identify of the resource manager for that resource. The user then issues a request to the appropriate resource manager. If the request is successful, a resource allocation token is returned to the user; this token grants the user the right to request the process manager to create a process on the resource.



The resource manager are not required to be located on the resource being scheduled. However, the security policy does require that the process manager and the resource being managed be located with the same trust domain. 



In the following discussion, we present the algorithms used by the resource manager. It will simplify the discussion to initially assume that all requests to resource proxies are initiated by the user proxy. We will then show how to extend the presented algorithms to enable resource management requests to be initiated from an arbitrary user process.



Resource Allocation



A resource allocation requests maps a resource allocation specification into a PROCESS-HANDLE. A PROCESS-HANDLE is defined by:





PROCESS-HANDLE = CRM{host-identifier,process-identifier}





where host identifier and process identifier are defined by the process manager and they are both signed by the resource manager.



A resource allocation request can fail for one of three reasons:



•The requested resource is not available (allocation failure). •The user is not a recognized user of the resource (authentication failure). •The user is not entitled to use the resource in the requested mode (authorization failure). 



Authorization is not within the scope of the Globus security policy. It is up to the resource manager to enforce any local authorization requirements. Depending on the nature of the resource and local policy, authorization may be checked at resource allocation time, process creation time, or be implicit in authentication and not be checked at all.



The general algorithm used for resource allocation is:



1.The user proxy and resource manager authenticate themselves to one another using CUP and CRM. As part of this process, the resource proxy checks to ensure that the user proxies credentials have not expired. 2.The user proxy presents the resource manager with a signed request in the form

CUP{allocation specification}

3.The resource manager checks to see of the user who signed the proxy's credentials is authorized by local policy to make the allocation request. This may require mapping the users credentials into a local user id or account name if the policy of the resource manager is to check for authorization at resource allocation time. Alternatively, authorization checks can be delayed until process creation time. The mechanism by which this mapping is performed is discussed shortly. 4.If the request can be honored, a PROCESS-HANDLE is constructed and returned to the user proxy. 



Process to Process Authentication



Globus provides a mechanism by which a process can authenticate to its user proxy or another process. This authentication identifies the Globus user that created the process. Note that the ability to authenticate one process to another or a process to its user proxy does not imply a delegation of trust from one process to another. 



To enable process to process authentication, each process created in Globus is issued a temporary credential CP. This credential is signed by the user proxy that created the process (the credentials of the user proxy are in turn signed by the user). The following algorithm is used to create credentials for a process:



1.The process creates an unsigned set of credentials: UCP. 2.The credentials are passed to the process manager that created the user process. 3.The process manager sends a PROCESS-CREDENTIALS request along with UCP to the user proxy. The PROCESS-CREDENTIALS request is signed by the process manager. 4.The user proxy examines the PROCESS-CREDENTIALS request, and if is wishes to approve it, the user proxy signs the UCP to produce CP, a fully functional set of credentials for the requesting process. 5.The signed credentials are returned to the process. 



Note that this algorithm relies on a process and its process manager executing in the same domain of trust.



Issuing Resource Management Requests from User Processes



The preceding algorithms allow a user proxy to request allocation of a resource and then the creation of processes on that resource. We also require that processes created in this way be able to acquire additional resources and create additional processes. We provide this functionality by the simple expedient of passing such requests from the process in question to the user proxy, which then issues the request on behalf of the process. This technique lacks scalability, but has the advantage of simplicity.



This technique requires that we be able to pass a request securely from a process to a user proxy. We use the following algorithm:



1.The process and its user proxy authenticate to one another.

2.The process issues a request to its user proxy. The request is of the form: 



CP{operation, operation args}



where operation is either allocate or create.

3.The user proxy executes the request using one of the above algorithms.

4.The result signed by the user proxy and returned to the requesting process.





Mapping Between Globus and Resource Subjects



The ability to perform local access control requires that the resource proxy be able to map a Globus subject into a subject that is known by the resource. That is, we need to convert a global name (e.g. a ticket or certificate) into a local name (i.e. login name or user ID). In order to construct this mapping, we must have access to the Globus credentials, Globus subject, resource credentials and the resource subject (to make this concrete, the resource credentials are a local password while the resource subject is a user name). 



The basic idea behind the mapping algorithm is for a user to prove that they hold both a Globus credential and a resource credential. This is accomplished by authenticating both to Globus and directly to the resource using the local authentication method. The user then asserts a mapping between Global and local credentials. The assertion is coordinated through the process manager since it is in a possition to accept both Globus and local credentials. Specifically, the mapping algorithm is:



1.The user proxy authenticates with the process manager. 2.The user proxy issues a signed MAP-SUBJECT-UP request to the process manager providing the Globus subject and resource subject as arguments. 



1.The user logs on to the resource using the resource's authentication method and starts a map registration process. 2.The map registration process issues a MAP-SUBJECT-P request to the process manager, providing a Globus subject and resource subject as arguments. 



3.The process manage waits for a MAP-SUBJECT-UP and MAP-SUBJECT-P request with matching arguments. 4.The process manager ensures that the map registration process belongs to the resource subject specified in the map request. 5.If a match is found, the process manager sets up a mapping and sends acknowledgments to the map registration process and the user proxy. 6.If a match is not found within MAP-TIMEOUT, the process manager purges the outstanding request and sends an acknowledgement to the waiting entity. 7.If an acknowledgement is not receive within MAP-TIMEOUT, the request is considered to have failed 




Note that a matching MAP-SUBJECT-P request must be issued from both the user proxy and mapping process. This ensures that the same user is in possession of both Globus and local credentials. If the results of the mapping algorithm are stored in a database accessible to the resource proxy, then the mapping algorithm only needs to be performed once per resource. The duration of time for which a mapping remains valid is determined by local system administration policy. However, we would hope that a mapping will remain in place for the lifetime of either the Globus credentials or the users local account.



Part of the mapping algorithm requires that the user log into the resource for which the mapping is being created. This requires that a user authenticate themselves to the local system. Consequently, the mapping algorithm is only as secure as the local authentication method. Clearly, resources with strong authentication (for example based on Kerberos, S/KEY or Secure Shell) will result in a more secure mapping. 



Attacks Globus Protects Against



To be specified.



Open Issues



The security policy defined in this specification addresses a significant security concern, that of user/resource authentication. However there are a number of other security concerns that are not addressed. Of these, the most pressing is the protection of a process from unauthorized incoming communication operations. As Globus supports one-sided communication, this protection is of particular concern.



We can address this security concern by adding the following to our security policy



•A process may control access to incoming communication operations on a per subject basis. 



The existence of process credentials enables a range of algorithms that will implement this policy. For example, one can use the process credentials to:



1.Authenticate a sending process to a destination process 2.Sign all point-to-point communication, guaranteeing the identity of the sender. 


------------------------------------------------------------------------
The Globus project. 
For questions or comments, contact webmaster@globus.org 
Last modified on June 02, 1997