}w!"#$%&'()+,-./012345<ya

Transcription

1 MASARYK UNIVERSITY FACULTY OF INFORMATICS }w!"#$%&'()+,-./012345<ya On PKI Usability in Grids A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY AT THE FACULTY OF INFORMATICS, MASARYK UNIVERSITY Daniel Kouřil Brno, 2015

2 Declaration Hereby I declare, that this thesis is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Advisor: prof. RNDr. Luděk Matyska, CSc. ii

3 Acknowledgement I would like to express my sincere gratitude to my adviser Prof. Luděk Matyska for the continuous support of my activities and study and the opportunity to work with him. I also appreciate the collaboration with my colleague RNDr. Michal Procházka, who is a very inspiring guy. And finally, but not least, big thanks go to my family. Abstract The concept of public key infrastructures (PKIs) was introduced to complement mechanisms based on asymmetric cryptography to provide scalable security protocols suitable for distributed systems. However, utilization of PKIs in really large-scale infrastructures like grids revealed various shortcomings of contemporary PKIs that complicate smooth utilization of the technology. This work focuses on the usability issues of PKI in grids since positive users experience with security precautions is crucial for overall security. The thesis emphasizes the need to introduce the notion of transparent security in grids, which help hide the complexity of security mechanism so that users do need to interact with them. Even though the principle brings increased load on the side of providers of grid systems, we argue that the overall security is improved. Improvements of usability of grid PKI are demonstrated on particular areas that relate to management of user credentials. In addition to that, other scenarios are shown, where PKI contributed to improved usability or security of applications in distributed systems. iii

4 Contents 1 Introduction Thesis goals Thesis contribution Thesis structure Security in Grids Information security Security in grids Public key cryptosystems User-centered authentication in grids Grid Credentials Management Obtaining credentials Management of credentials Using credentials Revocation of credentials Usability of Grid PKI Usability and security Usability of grid PKI Transparent security in grids Results Contribution to development of transparent security in grids Efficient distribution of revocation information Addressing short-lived credential dilemma Utilization of hardware tokens in grids Credential translations Isolation of services iv

5 5.2 Addressing Security Problems Using PKI PKI as a Generic Security Layer Credential delegation using PKI Remote signing Summary Conclusion 33 A A Credential Renewal Service for Long-Running Jobs 34 B A Robust and Efficient Mechanism to Distribute Certificate Revocation Information Using the Grid Monitoring Architecture 41 C Improving Security in Grids Using the Smart Card Technology 48 D Survey of Authentication Mechanisms for Grids 51 E Sealed Grid with Downloadable Services 62 F Transparent Security for Collaborative Environments 71 G Using PKI to Provide Credential Delegation in non Web-based Federations 78 H List of author s bibliography 87 Bibliography 94 v

6 Chapter 1 Introduction Distributed systems often need strong security mechanisms to protect the users, the service providers and the operators of the systems. The exact level of protection and security precautions depend on particular requirements of all the parties, however, basic authentication and communication protection are very common demands. A wide range of mechanisms exists nowadays, which are available to respond to demands from security domains. Owing to their unique attributes, solutions based on the concepts of asymmetric cryptography are often deemed as an appropriate solution addressing security-related requirements in architectures of distributed systems. However, the solutions are also subject to criticism for poor usability and complexity at the same time. These aspects are crucial security properties, which tend be to be often neglected, which in turn might decrease the security level. When users, being the weakest link in the security chain, are unsatisfied with the level of usability of a system, they try to circumvent the security precautions, which degrades the security mechanisms in place. The thesis discusses authentication mechanisms based on public key infrastructures and their usability in large distributed systems. A very good example of a massive distributed system is a grid, which provides a platform for collaboration and sharing resources among cooperating users. As such, it is a good candidate to study problems and discords between the notions of users, service providers and operators of the infrastructure. Even though the focus on authentication methods nowadays shifts to increased utilization of various identity federations, PKIs are still heavily used. Experiences obtained in the field of usability of grid PKI will also enable to build more usable environments 1

7 1. INTRODUCTION in other types of distributed systems. The author of this work has been involved in several projects and activities aimed at building and operations of distributed systems and builds on results published in peerreviewed papers presented in proceedings of conferences and journals [1 20], and also at series of local Czech conferences and workshops [21 26]. The author has also given a large number of presentations at various events focused on practical security aspects of distributed systems. Development of a large distributed system such as a grid requires activities on several different levels. In order to support its unique focus and characteristics, such a system often needs a custom middleware, which itself may have specific security needs [8, 15, 16]. Grids are oriented on user communities, so called virtual organizations that represent particular group of users. A virtual organization expresses security requirements imposed by the user on system utilization. Therefore, it is needed to understand how the groups are organized and requirements formed [11, 12, 14]. Security requirements stem also from operations of the infrastructure, which must be taken into account when an appropriate security design is made [17, 18]. Experiences from all these areas have constituted the basis for the work presented in this thesis. 1.1 Thesis goals The thesis focuses on aspects of PKI-based authentication in the domain of grids and specifically aims at usability properties of PKI in grids. The thesis discusses utilization of PKI by grid users and identifies the specific parts that make grid PKI unique. The areas are discussed in the context of a grid, which allows us to easily identify problems that are not always visible in the scope of smaller deployments. Grids therefore provided a good basis for such a discussion. After the areas that affect usability have been identified, it is possible to consider solutions to improve the level of their usability and perception of the users. These solution have to take into account basic requirements that the security level should be retained, yet usability improved. Since current systems are complex and have to address different security requirements, it is very often not possible to use a single security mechanism to cover all the requirements. The thesis therefore discusses ways how multiple security solutions can 2

8 1. INTRODUCTION be combined to provide a solution for a particular set of issues. When the proper level of usability of grid PKI is achieved, it is likely that the concepts would be usable in other environments, too. The thesis therefore demonstrates PKI based solutions also in environments other then grids. 1.2 Thesis contribution The author of this thesis made following contribution to the field of utilization of public key infrastructures and security in distributed systems. Concepts and techniques Usability analysis of PKI in grids based on discussion of a usability-security model. Introduction of a transparent security for PKI in grids, which provides better usability. Proof of concepts and artifacts Tools and technologies contributing to transparent security of grid PKI. Applying the notion of transparent security to improve usability and security of other distributed environments. The thesis is based on publications related to the area of usable PKI in grids, which the author of the thesis co-authored in the past. Contributions of the author to the attached papers can be summarized as follows: A design and implementation of a system for credential renewal service, published in [1]. The paper has two co-authors. The author of this thesis contributed by the main ideas of the renewal mechanism based on credential repositories and implemented the major part of the pilot solution. The other co-author contributed additional ideas about utilization of credential repositories. A design of framework for efficient distribution of revocation information in distributed systems, published in [2]. The paper has three co-authors. The author of 3

9 1. INTRODUCTION the this thesis contributed by the idea of using the push model and utilization of the grid monitoring infrastructure. The other co-authors contributed by performance testing and additional ideas to the design and usage of the monitoring service. A study to use hardware devices in distributed environment, published in [3]. The paper has three co-authors. The author of this thesis contributed the idea of evaluate possibilities of hardware tokens in Grid environment and basic technical implementation. The other co-authors contributed on the technical level and also by additional fields how to use smart-cards. A summary of provided authentication mechanism and translation methods, published in [4]. The paper has two authors. The author of this thesis contributed by the utilization of translation services. The other co-author contributed by utilization of identity federation mechanisms. A solution to use TPM for virtual machine security, published in [5]. The paper has three authors. The author of this thesis contributed the idea of using Trusted Platform techniques to check virtual machines and distribute sensitive data. The other co-authors contributed by the ideas of locking sensitive information inside virtual machines and their management. A design of a framework providing transparent security, published in [6]. The paper has five co-authors. The author of this thesis contributed the idea of using a public key infrastructure to secure dedicated channels and use it to convey additional authorization data. A framework for credential delegation, published in [7]. The paper has three authors. The author of this thesis contributed the idea of delegation layer that is decoupled from the authentication technology, and the idea to use PKI as the basis of the layer. 1.3 Thesis structure Chapter 2 introduces the environment of grid systems and corresponding security areas, emphasizing authentication and its specifics in the context of grids. Chapter 3 discusses areas of credential management in grids, summarizing available approaches and tools. 4

10 1. INTRODUCTION Chapter 4 discusses the gap between usability and security in the context of grids and suggests transparent PKI. Chapter 5 summarizes our contribution to establishment of transparent PKI in grids and also utilization of the principle in other domains. Chapter 6 concludes the thesis. The appendices contain selected papers [1], [2], [3], [4], [5], [6], [7] presented at international peer-reviewed conferences and published in their proceedings: Appendix A is paper [1] A Credential Renewal Service for Long-Running Jobs published by IEEE Computer Society as part of the proceedings of the 6th IEEE/ACM International Workshop on Grid Computing. Appendix B is paper [2] A Robust and Efficient Mechanism to Distribute Certificate Revocation Information Using the Grid Monitoring Architecture published by IEEE Computer Society as part of the proceedings of the international conference on Advanced Information Networking and Applications Workshops. Appendix C is paper [3] Improving Security in Grids Using the Smart Card Technology published in the IEEE Xplore Digital Library as part of the proceedings of the 7th IEEE/ACM international conference on Grid Computing. Appendix D is paper [4] Survey of Authentication Mechanisms for Grids published by CESNET in the proceedings of the international conference CESNET Appendix E is paper [5] Sealed Grid with Downloadable Services published by Springer in book Towards Next Generation Grids, which is the proceedings of the international CoreGRID Symposium Appendix F is paper [6] Transparent Security for Collaborative Environments published in in the IEEE Xplore Digital Library as part of the proceedings of the International Conference on Collaborative Computing: Networking, Applications and Worksharing, CollaborateCom Appendix G is paper [7] Using PKI to Provide Credential Delegation in non Web-based Federations published in the Lecture Notes in Electrical Engineering as the proceedings of the International Conference on Information Science and Applications, ICISA

11 Chapter 2 Security in Grids Sharing of resources is a crucial part of any cooperation as it allows people to efficiently share assets and develop them further. In order to facilitate sharing of computing resources, the notion of the computing Grid was introduced [27, 28]. The Grid concept enables to establish virtual computing systems composed of diverse components distributed across organizational boundaries. Having followed the successful adoption of the concept, other areas than computing adopted the Grid principles, yielding a set of grid technologies suitable for sharing data, knowledge and unique instruments. Further utilization of the technology led to even more general view on the concept, which brought the idea of federated arrangement of assets. Nowadays, we witness various types of federated environments, like federated cloud systems. What stays common is the focus on security aspects of federated environments. 2.1 Information security Different applications and services have different security demands. On the contemporary Internet we can find services that are freely available to any Internet user and do not provide a sound level of guarantee about the information they provide. These services are usually widely open and their security demands focus mainly on keeping the services in operations and preventing from damaging the good reputation of the provider which might be caused by breaching the integrity of the maintained information or other means. Other services, however, have more strict security requirements, so have their users and consumers. A typical example of services with higher security 6

12 2. SECURITY IN GRIDS requirements is on-line banking applications that are widely used by common Internet users nowadays. People also regularly use other types of services, social hubs, mail portals, cloud facilities, paid content, which manifest different security demands, which need to be taken into account when a system is being designed or evaluated. In order to express and evaluate requirements in the field of information security, it is customary to use three basic attributes, namely confidentiality, integrity and availability (the CIA triad). The attributes can be defined as [29]: confidentiality: the ability of a system to ensure that an asset is viewed only by authorized parties integrity: the ability of a system to ensure that an asset is modified only by authorized parties availability: the ability of a system to ensure that an asset can be used by any authorized parties The model expressed by the CIA triad is simple but can be applied to a wide range of applications and services. The concept and the attributes have been subject to discussions and enhancements in security research (e.g., [30 32]) and they are widely recognized as basic properties used to evaluate and measure information security. Requirements expressed by means ot the CIA properties are traditionally addressed by means of authentication, authorization and possibly audit [33]. Authentication is the process to establish the identity of a user or process. Authorization is the process to determine whether the end user or process should be granted the right to invoke the operation it is requesting. Audit is the process to monitor activities performed with the system and detect who is responsible for them. Proper AAA components have to be carefully selected to cover particular demands and requirements expressed by the system specification. 2.2 Security in grids Besides generic requirements, couple of additional demands have to be taken into account when designing or operating a grid infrastructure [34 36]. Those related to security, which supplement the generic security requirements can be summarized as follows: 7

13 2. SECURITY IN GRIDS Single sign-on Users must be able to authenticate to the system once per a session without further re-authenticating with each service that they are accessing during the session. Furthermore, users are able to set long-running operations without remaining logged. Delegation Users must be able to delegate their access rights to other entities within the grid. Delegation chaining must be supported as well as restricted delegation. Revocation Revocation is a vital function that must be provided by authentication and authorization mechanisms so that access rights or identity assurance can be revoked. Some applications require instant revocation. Distributed trust Grid systems are inherently open and users are authorized to perform a wide range of operations on the systems connected to a grid. Constrained delegations and determining necessary trust relationships should be supported. Freshness The notion of different time frames (computing jobs lasting from minutes to weeks) must be taken into account and the AAA systems must be able to determine credential freshness. The requirements stated above can be fulfilled by various security mechanisms and protocols. There are a small number of projects that use the Kerberos system [37], like MetaCentrum, the Czech National Grid Infrastructure 1. The traditional form of the Kerberos protocol is not suited for dynamic environment of grids and even though attempts have been done to overcome the issues [38 40], Kerberos-based grid infrastructures are rare. Recently other attempts have tried to interface the grid system using identity federations [41] but the dominant mechanisms used to provide security functions to grids are based on public key cryptosystems Public key cryptosystems Unlike symmetric cryptosystems, public key cryptography [42] uses a pair of keys. The private part of a pair is used solely by the owner of the pair and the public part is widely distributed in the community. Private keys can be used to generate a digital signature that can be verified by anyone who is in possession of the corresponding public key

14 2. SECURITY IN GRIDS Public keys can be used to encrypt messages that can only be decrypted by the bearer of the private key. Public key cryptography simplifies the distribution of keys but also requires that public keys are distributed in a trusted manner. In order to provide a solution, the concept of a public key certificate has been introduced. A certificate is a data structure containing a public key and possibly additional information, which is signed by the certification entity that verifies the binding between the public key and its owner. The idea of public key certificates relies on a Public Key Infrastructure (PKI), which manages all aspect of the distribution of certificate and controlling their lifetime. There are several models to establish a PKI. The certification authority model employs a central entity that is trusted by all entities that consume its certificates (relying parties). The certification authority (CA) issues certificates and also revocation information if a certificate is to be revoked before it expires. The CA signing certificate has to be distributed to the relying parties in a controlled way. Certificates issued by CAs quite often follow the X.509 format, which has been profiled by the IETF [43]. Public key infrastructures based on the X.509 format and the set of IETF standards (sometimes referred to as PKIX) are used in a large number of deployments. A different model is utilized by PGP, which is based on the web of trust [44]. The web of trust is a decentralized model without any central entity. Every user can sign the public key of another user, adding their signature to the signatures appended to the keys. Users may specify various weights when evaluating trust in the particular key and its owner. Another approach to certificate public keys is represented by the concepts of Simple Public Key Infrastructure [45] (SPKI) and Simple Distributed Security Infrastructure [46] (SDSI). SPKI/SDSI certificates use as identifiers the values of signed public keys and do not rely on global namespaces. They also bind authorization information to public keys, which enables to provide the access control without the need to know the user identity. The verification mechanism is similar to the web of trust model and each user can issue certificates. Out of the listed solutions, the concepts based SPKI/SDSI have not been adopted are not used by contemporary infrastructures. PGP is implemented in several software products and is used to protect mail communication and often verifies the integrity 9

15 2. SECURITY IN GRIDS of files available on the Internet (e.g. distributions of open-source products). X.509 is key format utilized by widespread standards TLS [47] and S/MIME [48], which makes PKIX dominant technology to protect common services on the Internet. The technology is used the most by grid systems, too. However, utilization of PKI in grids has several significant specifics User-centered authentication in grids Grid infrastructures are usually very large in many aspects, which makes them a unique environment to study and evaluate impacts of various actions. The results may then be applicable in other environment that has not grown up to the size yet. In terms of authentication and utilization of PKI, grid infrastructures are unique in many aspects, which are summarized in this section. A large number of CAs The Grid PKI is controlled by the Interoperable Global Trust Federation (IGTF) 2, which coordinates development of policies and operations of profiles governing CAs that have been accredited under IGTF profiles. At the time of writing, there are 99 CAs available from the IGTF repository, which cover countries from the majority of the globe. Massive deployment of certificates Grid systems has strong demands on traceability so that misbehaving user can be uniquely identified [49]. Users (and services) therefore are usually requested to pose unique set of credentials issued solely for them. For instance, the European Grid Infrastructure (EGI) is used by cca 20 thousands of users, each possessing a personal X.509 certificate. In addition to that it operates thousands services that also use their service certificates. Independent PKI The PKI provided by the IGTF certification authorities is not bound to any particular application. User can use a single certificate to access all systems and grid infrastructures that accepts IGTF certificates. Focus on authentication Public keys are used particularly for online authentication of users to services (and vice versa). The utilization of PKI to provide message-level security for interactive usage (e.g, encryption) is quite limited

16 2. SECURITY IN GRIDS Utilization of specific technologies The need to address specific grid requirements stated in the introduction of the section provoked development and utilization of specific technologies for Single Sign-On, credential delegation, specific utilization of certificates for services. Support of alternative authentication Recent advances in the technology have elicited demands to integrate support for additional authentication methods. Several possibilities have been explored and provided, which make it possible for users to combine several authentication mechanism when accessing grid facilities. Technology maintained by the provider Grids are based on the concept of a Virtual organization, which interconnects users working on the same goal, even from different organizations. If the VO or corresponding grid operator provides software for the users, they cannot rely on local user support, which is not familiar with the technology. Therefore, addressing end-user issues is more difficult. These aspects circle massively around the end user who has to cope with the technology. Therefore, we pose the question whether the technology solutions are usable for the users and if it is possible to improve the usability and find the proper balance between usability and security of grid systems. Before we delve into the discussion, we have to start with an analysis of users activities required to interact with the security component of grids. As visible from the key aspects summarized above, users are exposed mainly to management of authentication credentials used to access grid systems. 11

17 Chapter 3 Grid Credentials Management Users of grid systems are required to posses a set of credentials that are bound to their identities and provide unique identifiers of the user throughout the grid. In public key infrastructures based on X.509 certificates (PKIX) the credentials are composed of a keypair and an X.509 certificate for the public key. The user acquires their credentials before their first utilization of a grid system and has to maintain the credentials over its lifetime. This section summarizes the management of grid credentials and emphasize the differences against other solutions implied by the traditional PKIX model [50]. 3.1 Obtaining credentials In order to acquire a set of grid credentials, several steps have to be followed: 1. Generate a key-pair and certification request. Credentials are generally supposed to be unique and are hence based on unique cryptographic material. A brand new key-pair is generated at beginning and used to construct a certificate signing request [51]. A CSR contains the public along with additional auxiliary information, e.g. requested naming. 2. Deliver the CSR to Registration authority (RA). An RA is an entity providing an interface between its Certification authority and users. 3. Identity vetting by the RA. In the course of acquiring credentials the RA is responsible for vetting the identity of the requester. IGTF certification authorities have 12

18 3. GRID CREDENTIALS MANAGEMENT strict requirements on the level of verification of requester identity, which must be established before the certificate is issued [52]. 4. Obtaining the certificate from the CA. After the requester identity is vetted, the CA signs the certificate and makes it available to the requester. 5. Secure storage of the credentials. The credentials owner usually needs to store the private key and corresponding certificate so that they are available for later use. The steps outlined above provide a generic description of the process whose particular implementations depends on the CA and its mode of operations. The traditional CA model described by the Classic IGTF profile [53]. From the standpoint of the end user, the most important requirement is that users requesting a certificate from an IGTF classic CA have to visit the RA in person to validate their identity using an official document. In order to streamline the process, other CA modes have been introduced, which remove the need of personal visit of the RA. The profile for Short Lived X.509 Credential Services (SLCS) [54] stipulates requirements for a CA that issue certificates as an on-line service and rely on authentication provided by an already existing mechanism. It only issues short-lived certificates with lifetime not exceeding twelve days (one million of seconds). The idea behind SLCS builds on principles explored in other environments [55, 56] and makes it possible to integrate a CA service with an existing AAA infrastructure (e.g., Kerberos which is a common single-domain mechanism). Similar to SLCS is the profile for Member Integrated X.509 PKI Credential Services (MICS) [57]. It is also meant for on-line services and is connected to an existing identity management system. The profile allows the CA to issue long-lived certificates valid for a year but also has stronger demands on the identity verification in the identity management systems it is connected to. A known example of the service is the TERENA Certificate Service [58], which provides a mechanism that enables European researchers to obtain PKI credentials using purely their web browsers. For the sake of completeness we also mention profile Identifier-Only Trust Assurance with Secured Infrastructure (IOTA) [59] that has been introduced recently. Compared to the profiles listed above, the IOTA profile has modest requirements on identity vetting, which implies that sufficient traceability and accountability is not guaranteed from IOTA certificates. 13

19 3.2 Management of credentials 3. GRID CREDENTIALS MANAGEMENT One of the most important factors of PKI with direct influence on the overall is proper protection of the private key [60]. Anyone who knows a private key can produce digital signatures verifiable with the corresponding private key. In the context of grids such a compromise leads to identity theft. Keys used for asymmetric cryptography in PKI are very long strings of bytes and users must maintain and use them properly. Unlike common passwords, private keys cannot be remembered in human memory and have to be kept in digital form. Over the years of evolution of PKI and grid systems several possible solutions have emerged to store the private key. The simplest solution is to store the private key on the filesystem of the users computer. There are various possibilities how such a storage can be provided. Some operating systems (MS Windows) provide dedicated service to store sensitive data. Some applications maintain their own repositories for sensitive data (e.g., the Mozilla Firefox web browser). Private keys can also be stored in a plain file, this is the most common way how grid credentials are stored. In all cases the files with the sensitive data are usually protected with access control mechanisms provided by the operating system (proper file permissions, dedicated protection applied by the kernel, etc.). There are several weaknesses linked with sensitive data stored in files. The protection of the file is entirely under control of the user, which is hard to check. There is only little influence on enforcing a common password policy or even monitor if the file is protected with any password. If the users machine is compromised during a cyberattack, the attacker is able to collect the files and try to overcome the protection to get the key and obtain the user s rights on the grid. Malware trying to steal sensitive data from users desktop is quite common nowadays [61], which only complicates the situation. Too many users see their private key as just another file they can freely copy and distribute among machines. The files containing private keys are encrypted with a passphrase but the users often select too weak passwords that can be broken using a brute-force or directory attack. Also the file system access protection does not often provide sufficient level of security. Private keys stored is such files can be captured by a malicious administrator or sometimes even ordinary users and can be further misused to perform an attack or unauthorized access to private data. The private key owner may not even notice the key compromise for very long time. 14

20 3. GRID CREDENTIALS MANAGEMENT Current efforts to address these private key hygiene issues focus on removal of the long-term private keys from the user s desktop. One possibility is to use a specialized credential store service online credential repositories which maintain the long-term private keys and provide access only to short-term credentials (e.g., proxy certificates) derived from these long-lived ones. For instance, the MyProxy [62, 63] service is very widely used for such a purpose. A MyProxy server provides a secure storage where the users can load their credentials assigning them a password that can be used later to download a proxy certificate generated from the credential stored in the repository. MyProxy servers are used in multiple scenarios ranging from access to grid portals to support of long-running jobs. Another option is to use a specialized hardware device which is able to maintain the private key and perform basic operations a hardware token (or smart card). Such a device ensures that the private key never leaves the token and prevents the key to be ever exposed to unauthorized users. The smart card technology allows to mount twofactor authentication where the user must prove to the end system something that they have (i.e., the smart card) and also something that they know (i.e., the password opening access to the private keys on the smartcard). These two factors must be presented at the same time. The biggest challenge tied with the use of smart cards lies in the user support, mainly if the PKI (and smart cards) are operated by providers different from the users home institutes. In this scenario, the users local support staff do not have either experience or mandate to solve problems caused by third-party devices, while the staff at the PKI provider do not know the users local environment. A combination of a repository and hardware device is a type of virtual smart-card. Such a service registers private keys of users and exposes an interface to perform cryptographic operations using them. 3.3 Using credentials Grid credentials are used by the user to authenticate with the services that the infrastructure makes available for use (and vice versa). Particular authentication protocol depends on the grid application and middleware that the user is using, however the number of authentication requests is usually high. For instance, users of a computing grid needs to prepare their job, input data, submit the job and monitor results. All these operations have to be authenticated using the user s credentials. 15

21 3. GRID CREDENTIALS MANAGEMENT Requiring the user to perform authentication actions on every single access to the system would be very impractical for the user who would most likely refuse to use the system soon. A solution to the problem is to introduce a mechanism to single sign-on (SSO). SSO allows users to perform one explicit authentication to the system so that all subsequent steps of the users need not explicit authentication be done by them. For each large system it is important to provide a single sign-on (SSO) mechanism, which makes the life of users easier yet retains a sufficient level of security. The common way of providing support for SSO is to introduce a notion of authentication token that is generated as the outcome of the explicit authentication of the user. The exact format of the tokens depends on the underlying mechanisms. However, it is important that it provides two basic functions. First, it is necessary that the SSO token can be used independently on the user the token belongs to, which means that authentication performed using the tokens must not require any explicit actions from the user. Second, since the tokens are independent on the user and can be used without their consent or even knowledge, it is neccessary to limit the scope in which the token can be used. This requirement is crucial since it confines misuse of potentialy stolen tokens. If a token did not limit its possible utilization, every attacker who would obtain access to the token could initiate operations on the systems as if they were done by the legitimate user. The limits of the token utilization can be specified either in terms of time validity or space where the token is allowed to be used. The latter possibility requires the user to specify a set of services the SSO token will be used for. The grid environment introduced a special type of public-key certificates the proxy certificate [64, 65]. A proxy certificate is made by the user themselves, with the users private key acting as a CA signing key. The proxy certificate model is primarily used for delegation of user s identity into the grid world, to support batch job submissions and other operations that the user cannot directly interact with. Grid services use clients proxy certificates to be able to contact other services on behalf of the clients. Grid credentials formed by the proxy certificates and associated private key are usually stored on a filesystem secured by proper filesystem permissions but without any additional protection by a passphrase. To reduce the potential damage caused by a stolen proxy credential proxies are usu- 16

22 3. GRID CREDENTIALS MANAGEMENT ally short-lived with the lifetime set to couple of hours. Proxy certificates also make it possible to build a Single Sign-On system, where user creates a proxy certificate only once a day and using the proxy certificate they can then access grid services for the whole day without providing any other explicit authentication or creating a new proxy certificate. The second possibility to provide a SSO mechanism in the PKI world is to use standard X.509 certificates with limited lifetime. Such certificates can be used in similar way how proxy certificates are. In order to get the short-lived certificates accepted by the end users, it is inevitable to provide mechanisms how they can be easily created, either by integration with the desktop or using a credential translation service. In that way, the use of such certificates can be entirely transparent for the users, which is much more comfortable for ordinary users. Whatever approach to SSO is used with these systems, the user will end up with a short-lived credential in practice. Having a time-limited authentication token reduces the possibility of its misuse but also presents a new kind of problems. Especially people utilizing the infrastructure through other services acting as proxy of the users need to provide the services with sufficient rights. Delegated credentials do not suffice since their validity expires and other mechanisms are needed. A typical use-case is support for long-running jobs processed by batch systems. Such jobs are submitted to the system by the user who retrieves the result later on. Since this kind of jobs usually runs very long and can be re-submitted due to errors in the infrastructure, it is not possible for the job owner to watch all their jobs interactively and delegates this responsibility to a dedicated service. The service has to be able to act on the users behalf, which gets complicated once the credential provided by the user during job submission has expired. Therefore, the limited lifetime of SSO tokens confines not only the potential damage caused by unauthorized use of the token but also the way how a system is used by legitimate users. This contradiction introduces a short-lived credential dilemma placed between the system operators and users. While the operator wishes to keep SSO tokens very limited to decrease the impact of misusing stolen credentials, typical users consider any limits posed at their system utilization disruptive. 17

23 3. GRID CREDENTIALS MANAGEMENT 3.4 Revocation of credentials Certificates used in PKIs provides assertions of binding between a digital identity and the public key. Depending on particular format of the certificate, it can also carry additional attributes bound to the identity by certificate issuer. These attributes can be used by the recipient of the certificate for additional operations. For instance, public-key certificates often contain address of the certificate bearer, which allows them to use the certificate for digital protection of mail communication [66]. Signatures on certificates are done using asymmetric cryptography, which allows the parties to verify the signatures without asynchronously, without the need to contact the issuer. Such an feature is very desirable, especially in large-scale environment where possible single points-of-failure should be avoided as much as possible. On the other hand, in the real life it is possible that attributes included in the certificate become invalid and the fact should be taken into account by all the relying parties. There are a lot of reasons why information in a certificate can cease to be valid and also the severity differs. If the corresponding is compromised, the certificate becomes useless since the attacker with access to private key can generate messages that cannot be distinguished from messages produced by the legitimate certificate bearer. It is crucial therefore to provide mechanism to invalidate the whole certificate whenever it is needed. The process is called certificate revocation and allows the relying parties to get information about whether the certificate they are checking is still valid or not. Obviously paying sufficient attention to certificate revocation is very crucial. A usage of a certificate that has been revoked pose much higher risk than a certificate that has just expired, simply because there is a risk of an unauthorized access by the user or even misuse of the private key. While verifying a digital certificate it is inevitable to also consult the CA to check that the certificate has not been revoked. Many environments based on PKI do not pay attention to perform proper checks of revocation information. Also several applications do not effectively support revocation checks, which decrease the security level of the whole system. For example, popular browser Mozilla Firefox used to expose a severe bug preventing from automatic CRL updates that was not fixed for a very long time. Neglecting checks of revocation status may lead to severe violation of security since it is the only automated way of detecting that a certificate has been compromised. 18

24 3. GRID CREDENTIALS MANAGEMENT In PKIX revocation information is maintained and publish by the issuing CA. There are two basic mechanisms available for distribution this information to relying parties. The first one utilizes a list of revoked certificates (Certificate Revocation List CRL [67]) that is periodically issued by each CA. The second way enables to perform on-line checks by direct contacting the issuing CA. As the latter approach the Online Certificate Status Protocol (OCSP) [68] is widely used. The use of CRL is simple and supported by multiple contemporary applications. CRLs are fetched by the relying party at regular interval (several times a day), which introduces a delay to the distribution of revocation information. Therefore, when a certificate is being verified, the relying party may not have the most current information available, even though the CA has already published an updated CRL. 19

25 Chapter 4 Usability of Grid PKI The grid security has been criticized and effort has been spent on studying and improving usability of the security layers [69 71]. However, there are still many activities and projects ongoing in the fields, which suggests that the grid security, including grid PKI is still not addressed properly. While the principles of PKI offer many features that make the technology suitable for the needs of grid systems, the PKIs are also infamous of pure usability and bad acceptance by common users. In this section we provide an overview of usability of PKI in the context of grid systems. 4.1 Usability and security The term usability refers to methods to define and measure the ease of use of a object [72]. Usability of computer systems by human users is studied by the Human Computer Interaction (HCI) research domain, which focuses on improvements of how users perceive computer system. Usability is usually determined by usability factors (e.g., efficiency, effectiveness, satisfaction) [73,74], which can also be affected by security requirements. Usability is sometimes considered contradictory to security due to conflicting goals of the concept. An example of the conflict is often illustrated on password management. Security officers tend to stipulate very rigid password policy, requiring long passwords that are often changed on regular basis, which provides a strong answer to typical threats, like password cracking or misuse of compromised credentials. Such a policy could presents a big obstacle damaging the system s usability [75]. 20

26 4. USABILITY OF GRID PKI However distinct the goals are, there is a significant need to bridge the gap and address conflicts to align security and usability. Studies have shown that when users find a security precaution to be difficult to work with, they tend to circumvent it [76]. It is also recognized that security software requires different techniques than standard HCI techniques [77]. The relationships of usability and security is studied in the domain of Human Computer Interaction and Security (HCISec), where seeming and real conflicts are researched. HCISec discusses various approaches to tackle the alleged competing goals of security and usability. One attribute that is discussed is the notion of transparency of security [78 80]. Systems providing transparent security hide security-related functions They are designed so that these actions are secure by default and users do not need to deal with them. Given the attributes of grid PKIs, this concept seem to a viable solution for a sustain security level in grid systems. 4.2 Usability of grid PKI The PKI technology has been subject to previous usability studies, e.g. [81,82]. A classical study of PKI based on PGP can be found in [83], which defined five properties that should be taken into account when developing security applications: Unmotivated user property Users want to focus on their job and are not concerned about security, which is a secondary goal for them. Abstraction property Security mechanisms and policies tend to be very complex and may be hard to comprehend by the wider user population. Lack of feedback property Systems must provide good feedback to the user about potential errors. However, the correct security configuration depends on particular needs of the user, which may not be clear for the developer. Barn door property Once secret has leaked the system for whatever reason, it is considered compromised. Therefore, systems should make sure that the user understands security enough in order to prevent from making high-cost mistakes. Weakest link property The security of a system is only as strong as its weakest link. 21

27 4. USABILITY OF GRID PKI Users, generally seen as the weakest link, have to be motivated and guided properly to avoid being mislead. The main security-related activities that grid users have to explicitly perform concern with credential management (see 2.2.2) and users are much less exposed to security functions than in other systems (like secure mail exchange provided by PGP or S/MIME). Taking into account the properties above, we see another incentive for introduction of transparent security. 4.3 Transparent security in grids Based on previous discussion we try to design an approach to achieve the demanded functionality in grids. There is no one-size-fits-all solution and transparency must be tailored to a system based on its particular functions. In order to ease the process we provide a framework that enables the discussion and identify spots desiring attention. The idea is based on the principles of a framework to measure the usability and utility of PKI applications [84]. The framework consists of 15 evaluation categories, which are organized within three groups, deployment issues, ergonomics, and security features. While the first two groups refer to generic aspects of configuration and HCI, respectively, the last group specifically addresses security aspects of the evaluated system. Focusing on these aspects we provide a list of the categories specific for a grid PKI that require users interaction and therefore determines parts to be considered for transparent utilization. In accord with the cited framework we state exemplary questions to lead the evaluation process. The list of categorizes reflects the areas of management of grid credentials, enumerated in Chapter 3. Obtaining credentials This category is about how credentials are obtained from the issuing CA. There are many ways to carry out the steps outlined in sec. 3, depending on the mode of CA operations, particular client tools, etc. Where and how is the key-pair generated? Is there any existing authentication mechanism that the CA is supposed to interface? Is the certificate meant for long-term authentication or as a derivate based on other short-lived credential issued as bridge mechanism? 22

28 4. USABILITY OF GRID PKI Is it necessary to export the key material after the certificate has been issued? How is the certificate delivered from the CA to the owner? Management of credentials This category is about how users credentials are maintained. The most significant problem is the proper protection of the private key so that it cannot be used by unauthorized user/service. How is the private key stored in the system? Does it use a repository (SW, HW)? Do the applications require to keep the private on multiple places? What protocols are used to access the private key? Is it necessary to back up the private key (e.g., is the key used to decrypt mail messages from other users)? Using credentials This category refers to using the credentials for the users authentication in the grid. The category presumes that the grid system in question does have a Single Sign-On (SSO) mechanism in place. How do users perform the initial login to the system? Is the long-term private kept available in the system thorough the session? Is there a need to perform long-term activities exceeding the lifetime of the SSO credentials? Revocation of credentials This category refers to how revocation information is produced, distributed and consumed by the entities in a grid infrastructure. Is a revocation mechanism employed by the CA? (for instance, CAs issuing only short-lived certificate may not issue revocation information at all). Is revocation information consulted during every credential verification? Is the revocation information current? What kind of distribution of revocation information is involved? The listed categories help detect areas where users interaction is involved and therefore desire attention when transparent security is implemented. Examples of particular improvements of usability are described in the next chapter. 23

29 Chapter 5 Results Previous chapters summarized the characteristics of public key infrastructures (PKI), especially those involved in building grids. The problem of usable security of the technology has also been discussed. The discussion concluded by the proposal to make security technology transparent, which is a feasible approach in grid systems. In this chapter we describe particular solutions and achievements that have been done in the area of transparent security in grids. The section is split into two parts. The first part summarizes our contribution made to the development of grids. The second parts summarizes our results that verify the concepts of transparent security in other distributed environments. 5.1 Contribution to development of transparent security in grids Efficient distribution of revocation information As articulated 3.4, revocation checks are a crucial part of PKI utilization, with a difficult problem being efficient distribution of revocation information. Basically there are two modes to retrieve information, sometimes referred to as push and pull models. Even though there are many variants of these principles, the main difference lies in the way how data is sent and who initiates the data transfer. In the pull model, the consumer contacts the producer and asks for new data, if it is available. The mode is simple to implement and does not require any complex logic on the side of the producer. 24

30 5. RESULTS In the push model, the producer activate the transmission of new data to the consumers immediately once new data has become available. This mode is more complex and requires additional logic implemented by the producer that must be able to detect new data and also initiate its transfer. It also requires that an infrastructure exists between the producer and the consumers, which allows the consumers to subscribe for delivery of new data. While trying to design a solution for efficient distribution of revocation data, we wanted to combine a variant providing the speed of OCSP and suppressing its drawbacks, in particular the communication overheads. The final design of the solution uses heavily the push model, which is realized by a new service introduced to a PKI. The service was called CRL distribution service and it is responsible for delivering of revocation information to all subscribed parties. In addition to the CRL Distribution service, the designed framework is based on revocation consumers and messaging layer used to deliver the data. The results were published in [2] (Appendix B) and provides a scalable mechanism to distribute and handle revocation data Addressing short-lived credential dilemma In order to address the dilemma introduced in 3.3, we prepared a design of a service providing a controlled renewal of SSO tokens. The service builds on the concept of credential repositories and provides a means how a short-lived SSO token can renewed and delivered to the places where it is in use. Introducing the controlled renewal of SSO tokens allows users to disregard limits that the system imposes on lifetime of the tokens. Therefore, the users obtain a new view on the utilization of the systems since they are not limited by the time constraints enforced by the SSO tokens. At the same time, the service does not break the principle of the SSO tokens that prevents from misusing of stolen credentials, since all tokens delivered to the end-service keep the same characteristics, including the limited lifetime. The system was implemented for the environment of the European Grid Infrastructure (EGI), where it was successfully deployed a few years ago. Since then it has been in full production used by hundreds of users every day. The results were published in [1] (Appendix A) and in [8]. 25

31 5. RESULTS Utilization of hardware tokens in grids One possibility to provide proper protection of private keys in PKIs is utilization of specialized devices that keep the sensitive data locked and unavailable to the users, see Chapter 3. Striving to reduce the threat of abusing private keys, the Czech National Grid Infrastructure made an effort to distribute the smart card technology among the users. We ran a project 1 focused on a pilot utilization of smart cards by common grid users, where we received experience with the deployment and usability. This project and adjacent activities focused not only on technical aspects and possibilities how the technology could be integrated with existing infrastructures but also on user experience with smart cards. Results and technical achievements are summarized in [3] (Appendix C). Based on the results achieved, we kept working with the technology, which yielded e.g. input to a design of a new type of token [23]. However, after getting more experience with the deployment and evaluating the feedback received from the user community, it became evident that the technology is not well suited for large-scale deployment in heterogeneous infrastructures. Having evaluated the experience and identifying the issues, we could draw the conclusion about utilization of the technology of smart cards in large heterogeneous environments. Basically, it is suitable for smaller, focused group of user, ideally with specific knowledge (like system administrators). The perception of common users of distributed infrastructures, however, was less positive. These results lead us to move the attention to other approaches to address the private key protection, like credential repositories and wallets Credential translations Section 3.3 identified several issues related to the management of authentication credentials from the users standpoint. The issues were exposed to users of the Czech national grid infrastructure Meta- Centrum, who either demanded access to additional services requiring different types of authentication, or were requested to use different authentication types to access a dedicated set of MetaCentrum services, typically to obtain privileged access

32 5. RESULTS To address the particular needs of the users we provided several mechanisms to translate various types of authentication credentials. Some of them (e.g., support of onetime passwords in Kerberos) were prototyped so we could get more experiences with the mechanism, others were given to the community and became part of an open-source solution (PKI support in the Heimdal Kerberos implementation). The results were published in [4] (Appendix D) and in [21] and formed the principle of a credential wallet, which can be used by users for simplified yet secure management of their credentials. Credential wallets contribute to address the described issues, since they facilitate access to infrastructures requiring multiple credentials as well as utilization of multiple different infrastructures Isolation of services A grid is naturally an open environment, which provides a large amount of users with access to services operated by various providers. However, the openness is not always an advantage. There are areas that requires a more strict environment. A typical example of such an area is the medical domain where personal data of patients is processed. An usual approach to meet privacy requirements is to process the whole set of medical data at facilities owned and operated by the institution who manages the data. Obviously, that approach does not allow people to utilize facilities provided by grids. However, while we were working with medical experts in project MediGrid [85], they expressed their interest to be able to use grid services even for processing of sensitive data. Based on this requirement we designed a concept of a sealed grid, published in [5] (Appendix E). The concept allows the researchers to develop a set of grid services to solve a particular workflow, and then to download them to the institution local facilities. After the services have been instantiated locally, they can process sensitive data without the need to release the data outside the institution. The sealed grid concept enables to process data and yet leverage services provided by the grid. However, the approach cannot be used for all cases because services cannot be moved to a local facility, larger computing capacity is needed than what can be provided by the institution, etc. In such cases it is appropriate for the grid to try and provide similar functionality to a sealed environment. One possibility to achieve a sealed environment is to make sure that operating system and applications running there are in a well-defined state and that they have not 27

33 5. RESULTS been tampered with. If users can check the state of the machines, they are more willing to consign the data to the infrastructure. A possible solution involves using specialized devices available as Trusted Platform Modules. Using TPMs and their PKI support it is possible to check remotely the state of a machine, which is important to verify that the machine and its software has not been modified. TPMs also facilitate the initialization of virtual machines running from images that are not controlled by the machine owner. The utilization of cloud technology is becoming part of normal grid operations today. It is common practice in clouds that machines are instantiated from images that are used by multiple users. Therefore, it is not possible for the images to contain any sensitive data because it would be available to any user who is granted access to the image. The limitation also holds for any host credential needed for the machine to actually run. In order to provide a way how credentials can be safely populated on the machines, we suggested to also use TPMs and their support to transfer keys between different modules. 5.2 Addressing Security Problems Using PKI The idea of transparent security contributes to better usability in grids. There are also other domains that could benefit from the principles, though. This chapter builds on some results that we produced and demonstrated how PKI can enhance security of various scenarios PKI as a Generic Security Layer The domain of applications used in distributed environments is vast and reflects the needs and expectations of miscellaneous user communities. It is not rare that security is neglected by designers of applications for many reasons, which complicates the utilization of the application in environments where security aspects have to be considered. A straightforward possibility to bring the advantages of current systems to the existing applications is an attempt to fix the flaws in the applications. This is usually the best solution but in practice it may not be possible to achieve or may be too expensive. Instead of modifying the application it is often more appropriate to consider other improvements that might help increase the security level. A viable alternative is to pro- 28

34 5. RESULTS vide an additional layer facilitating security enhancements. Various services of various complexity can be provided by the layer, which is injected in the architecture as a security enabler providing security functions. The new layer may be independent of the application but still provides significant security services to it. The suggested approach utilized by a generic layer based on PKI that was published in [6] (Appendix F) and in [13]. The framework designed brings crucial security functions that are made available transparently to the application that is embedded in the framework. The framework was designed to enhance distributed applications that do not themselves implement support for security features. In particular, it enables support for mutual authentication, integrity protection or encryption of the communication channels and authorization based on common attributes. The authentication utilizes a PKI that is provided by the framework. Following the principles of transparent security, all aspects of credential management are hidden and provided as part of the services. Credentials are issued using a SLCS certification authority, based on identities verified by an existing identity federation. The framework described was used to implement transparent security to a set of collaborating systems, which do not implement any security functions. The generic character of the framework allows for its utilization in other application domains, too Credential delegation using PKI Both SSO and delegation are usually expected to be provided as part of an authentication mechanism. However, not all mechanisms provide support for SSO and credential delegation. There are two basic ways how support of SSO and credential delegation can be enabled in existing authentication mechanisms. A straightforward solution is to extend the particular protocol to support the requested functionality. Another option is to plug in a solution that can be easily integrated with existing security mechanisms without the need to change them. Focusing on the area of identity federations, we designed a solution for support of delegation and SSO using a PKI that we defined for that purpose. The solution forms a middleware layer providing delegation and SSO, which can be reused with multiple federation frameworks. Upon the first authentication with its authentication service (Identity Provider IdP) the client obtains a set of PKI credentials issued by the IdP. The credentials are used 29

35 5. RESULTS further on to authenticate the user and serve as a replacement of standard, long-lived credentials of users. If credential delegation is requested, the IdP will issue dedicated credentials and sends the certificate to the remote service as part of standard protocol exchange. Delegated credentials are limited by time and optionally by additional restrictions that specify their valid purpose. Obtaining and utilization of the credentials is completely transparent for users who do not need to be aware of the credentials at all and are not exposed to usual certificate and key management issues. Compared to general-purpose PKIs, our PKI is simpler, which streamlines its deployment and does not increase operations cost. For instance, because of the short lifetimes, the CA do not run any revocation service. The relying party is only the IdP, which also eases operations. The PKI does not constitute a new trusted service. From the operations standpoint the CA is a module of the IdP that transforms assertions to the X.509 format. That fact is important to comprehend since the introduction of the CA does not change the main trust relationships in the federated arrangement as the certificate are only consumed by the IdP itself. The viability of the solution is demonstrated on integration with the Moonshot federated framework [86, 87], which provides a mechanism to provide non-web identity federations. The complete solution was published in [7] (Appendix G) Remote signing Trying to examine an alternative approach to the private key management we authored a system providing the functionality of a virtual smart-card. The system is built on two basic concepts, key repositories and specialized hardware tokens, which are tied together. In accordance with the concept of key repositories, the service deliberately offloads the management of private keys from their users, who are only allowed to perform certain cryptographic operations using them. In the case of this particular implementation the authentication of the users is based on a combination of a password and a PIN. The service somewhat breaks the general rule about management of private keys, which says that private keys are solely owned and managed by their owners. This was a deliberate design decision based on an analysis of threats and consideration of 30

36 5. RESULTS security usability balance, similar to the security threat model [88]. We considered the threat of private key compromise or misuse caused by a user mistake (probably due to wrong perception of the PKI system) more serious than leaking the private keys from the repository. The system has been integrated with the information systems of Masaryk University and it is used to create digital signatures by staff of various departments. It has been in production for cca a year. 5.3 Summary Chapter 4 proposed to make security in grids transparent to improve usability of the system. Implementing the concept requires certain changes to be done to the infrastructure. In order to make a function transparent it is necessary to understand its purpose, define correct default behavior and provide a solution that can be easily integrated with the existing environment. PKI services used in grids evolve over the time and we do not foresee a single solution that would cover all kinds of services and demands. Instead, we evaluate the existing components to identify spots that expose potential usability issues and needs to hidden. Chapter 4 gave a basic framework for the evaluation, which is based on the fact that the most frequent interactions of grid security with security components are related to credential management. When the functions to hide have been identified, it is necessary to design a solution how they can be made transparent. In order to achieve that it may be necessary to introduce a new service in the infrastructure or change workflow of actions. This chapter has shown that various solutions exist to support transparent security in grids. We did not endeavor to address all possible issues, though. Rather we demonstrated concepts that form building blocks of infrastructures with transparent security. The proxy renewal service presented in Sec fixes the problems with utilization of short-lived credentials for long-lasting activities. The idea of controlled renewal of credentials was adapted by other grid middlewares is in continual use and has enabled to balance security requirements and usability. The mechanism to distribute revocation information described in Sec is a concept that allows for timely distribution of revocation lists to relying parties. Unlike other solutions, our mechanism supports the most common data format used to store revo- 31

37 5. RESULTS cation information. Therefore, it can easily be integrated with existing infrastructures without the need to change either the certification authority or end applications. In terms of improving the protection of private keys we focused on the possibilities to use dedicate hardware devices (Sec ). As part of the evaluation we deployed hardware tokens to a few dozens users of the Czech grid infrastructure and also prepared set of tools to ease the work with the tokens. Despite the effort to make the technology usable, we found out that it is not suitable to be used in distributed grid environment, mainly due to the low comprehensibility among common users. One issue frequently met by users who utilize multiple infrastructures with different authentication mechanism, is how to easily cross the boundaries of the systems in a way that does not break security rules yet is usable enough. We demonstrated (Sec 5.1.4) the viability of credential translations mechanisms that provide a transparent way how users can obtain credentials for different infrastructures. The list of concepts and solutions was concluded by a mechanism utilizing the methods of Trusted Computing to provide a way of distributing keys and attesting cloud machines (Sec ). The concept becomes more and more attractive today when cloud solutions are commonly used and the techniques come to users desktops. The results describes explain different principles how security mechanisms may be made transparent, which yields improved usability and hence security. The rest of the chapter discusses how the PKI technology can contribute to address security problems and again help improve the usability of the systems. In Sec PKI is used as a piece of new middleware that makes it possible to enhance security of existing applications by adding support for basic security functions, like authentication and communication protection. Sec discusses how PKI can form an underlying layer to provide a possibility to delegate authentication credentials in an authentication system that does not inherently allow for such a function. The last area mentioned (Sec ) describes a mechanism for remote signing, which demonstrates how comparing actual threats and usability issues can yield a shift in handling of sensitive information. The purpose of the chapter was to demonstrate the viability of ideas of transparent security and its applicability to PKI components. 32

38 Chapter 6 Conclusion Grid computing became popular since its introduction and grid infrastructures are used on regular basis by thousands users. Despite the broad utilization of security mechanisms in grids, especially those based on public key infrastructures (PKI) has been subjected to discussions and even critics for poor usability. Inadequate level of usability not only decreases users perception but it can also weaken the overall security of grids. The utilization of PKI in contemporary grids is user-centric, leaving the user in a situation where they are exposed to situations where specifics of PKI have to be dealt with. This thesis focuses on improving usability of PKI in grid systems, especially those parts that are most encountered by common users. In particular the thesis addresses the area of credentials management. Having analyzed the current approaches and mechanisms used, we suggested to put focus on the notion of transparent security in grids. Introduction of transparent security brings higher demands on the underlying infrastructure. The infrastructure and corresponding middleware has to cover new services, integrate and operate them properly. Increased load on infrastructure providers is balanced by improved usability of the whole system. It also contributes to a decent level of security because the system is more resistant to common threats that aim at the open grid environments. The thesis demonstrates how transparent security can be supported by introducing services to address particular users needs. The viability of the concept of transparent security in distributed systems is showed on applying the principles in other environment which leads to better usability of these systems. 33

39 Paper A A Credential Renewal Service for Long- Running Jobs The paper [1] published as: Daniel Kouřil and Jim Basney. A Credential Renewal Service for Long-Running Jobs. In Proceedings of the 6th IEEE/ACM International Workshop on Grid Computing (GRID 05), pages 63 68, Seattle, USA, IEEE Computer Society Contribution of the thesis author: 75% Conference rank: A Number of citations in Google Scholar: 34 Number of citations in Scopus: 7 Indexed in Scopus, Web of Science

40 A Credential Renewal Service for Long-Running Jobs Daniel Kouřil CESNET z.s.p.o., Zikova 4, Praha 6, Czech Republic Jim Basney National Center for Supercomputing Applications University of Illinois at Urbana-Champaign USA Abstract Jobs on the Grid require security credentials throughout their run for accessing secure Grid resources, such as GridFTP data repositories. However, delegating long-lived credentials to long-running jobs brings an increased risk that a credential will be compromised and misused. Additionally, it is often difficult to predict the run-time of jobs on the Grid, due to changes in application performance and resource load, making it difficult to set the lifetime of the delegated credential in advance. We have developed a solution to this problem for the EU DataGrid project using the MyProxy online credential repository and have further evolved it during the EGEE project. Users store their long-lived credentials in a dedicated MyProxy server and delegate short-lived credentials to their jobs. When a job s credential nears expiration, the Workload Management System retrieves a new short-lived credential from the MyProxy server on the user s behalf and uses it to refresh the job s credential. The MyProxy server s policy specifies which services may obtain credentials on the user s behalf, and all operations are logged at the MyProxy server, where access to credentials may be restricted if a compromise is detected or suspected. This system has been used for credential renewal in Grids in Europe for over three years. In this paper, we present the system design, describe our experiences, and discuss the security implications of this approach. I. INTRODUCTION From 2001 to 2003, the European DataGrid (EDG) project [1] developed a Grid computing infrastructure for data intensive applications in the areas of high energy physics, biology and medical image processing, and earth observations. In high energy physics, EDG developed solutions for managing the large amount of data to be produced by CERN s Large Hadron Collider starting in The EDG testbed included over 1,000 computers sharing more than 15 Terabytes of data at 25 sites across Europe, Russia, and Taiwan, serving over 500 scientists. Many of the products of the EU DataGrid project are now being carried over to the two year Enabling Grids for E-sciencE (EGEE) project [2] in Europe to build a production Grid facility. One of the challenges addressed in the EDG project was credential management for long-running jobs. It is good practice to limit credential lifetimes, to minimize the vulnerability of stolen credentials. However, jobs require valid credentials for the duration of their run, so they can access authenticated services, such as metadata catalogs and GridFTP servers [3]. Additionally, the Workload Management System requires credentials for submitting jobs to compute elements and resubmitting jobs when failures occur. Providing longlived credentials to long-running jobs is a simple solution, but given the difficulty of predicting job run-times in practice, this leads to over-estimation of required credential lifetime and increased vulnerability. Thus, EDG identified the need for a credential renewal service to enable long-running jobs to use short-lived credentials. This paper describes the credential renewal service, which has been in use now for over three years. We first give an overview of Grid security in Section II followed by an overview of EGEE job management services in Section III. We then describe the design of the renewal service in Section IV, discuss related work in Section V and security implications in Section VI, and document experiences with the renewal service in Section VII. We end the paper with a discussion of future work and conclusions. II. GRID SECURITY OVERVIEW The X.509 Public Key Infrastructure (PKI) is the basis for Grid security, chosen for its support of cross-domain, decentralized trust establishment. The EDG PKI, now the EGEE PKI, includes multiple Certification Authorities (CAs), typically one per country, for issuing certificates, typically valid for one year, to Grid users in that country. The user s private key, associated with the certificate, must be wellprotected to prevent unauthorized use of the certificate. A. Proxy Certificates To minimize exposure of their long-lived private key, users can create session credentials using X.509 proxy certificates [4]. At the start of a session, the user runs a program to create a new private key and proxy certificate, signed by the long-lived key. The user can then authenticate with the proxy certificate and key during the session, without requiring further use of the long-lived private key. The need to limit the lifetime of proxy certificates to reduce exposure to potential compromise is an important principal of the Grid Security Infrastructure [5], [6]. This technique of limited-lifetime session credentials is also used by Kerberos [7] to limit the usefulness of stolen tickets. Organization /05/$ IEEE 63 Grid Computing Workshop 2005

41 policies typically limit proxy certificate lifetime to one day or less [8]. Grid security protocols support delegating credentials to jobs and services running on the user s behalf using proxy certificates [9]. The job or service creates a new private key and proxy certificate, and the user signs the proxy certificate with his or her current proxy key. The job or service can then use the new private key and certificate to authenticate as the user, because of the user s valid signature on the proxy certificate. Delegating a proxy credential over the network requires the delegatee to send the proxy certificate to the delegator for signature, but no private keys are exchanged. A Grid credential is a private key with multiple certificates, which form a chain of signatures back to the signature of a trusted Certification Authority. The credential is valid only if all of the certificates are valid, so the lifetime of the credential is the intersection of the lifetimes of each certificate. Thus, a job on the Grid will typically have a credential with lifetime of one day or less. B. MyProxy Online Credential Repository MyProxy [10], [11] allows users to store their credentials in an online repository for later retrieval. A MyProxy server is typically run by Grid administrators on a well-secured machine, to provide maximum protection for the stored credentials. Management of proxy credentials in the repository is entirely under the user s control. Users may store, update, and remove their credentials in the repository at will, after first authenticating to prove ownership of the credentials. Users also specify the access control policies that protect the credentials. MyProxy supports a variety of authentication methods, including password, certificate, and Kerberos. Authenticated clients retrieve proxy credentials from MyProxy using proxy delegation, so it is not necessary to transfer any keys over the network. In developing the credential renewal service, EDG extended the functionality of the MyProxy software to support the certificate-based authentication described later in Section IV. The EDG extensions to MyProxy maintained backward compatibility in the MyProxy protocol and have been included in the baseline MyProxy software distribution since C. Authorization Assertions It is also common to include authorization assertions, signed by trusted servers, in the proxy certificate, to grant additional rights to users. For example, the Virtual Organization Management Service (VOMS) [12], used in the EGEE project, issues signed attributes indicating group membership roles or capabilities, to enable fine-grained authorization for Grid resources, removing the burden of managing accounts for every user across all resources in the Grid. Like proxy certificates, VOMS attributes have limited lifetimes and so must be managed by the credential renewal service. III. EGEE JOB MANAGEMENT Efficient management of resources in a dynamic Grid environment is a crucial factor for satisfying utilization of the UI submit Fabric Management WM Service node Workload Manager MatchMaker Batch System Job Adapter Fig. 1. CondorG Gatekeeper submit/monitor WMS Architecture Logging & Bookkeeping Information System Data Management Grid. The EGEE project uses a Workload Management System (WMS) [13], which is based on a solution developed within EDG [14] that was further enhanced with new features. The overall architecture of the Workload Management System and how it fits into the rest of Grid environment is given in Figure 1. The WMS system is composed of multiple components that are responsible for job management and also communicate with other services on the Grid. The User Interface (UI) provides users with an interface to access the WMS, to submit a new job or possibly cancel running jobs and also to retrieve the result data produced by the job after the job finishes. In order to submit a job to the WMS the user has to specify the description of the job, along with its needs. The EGEE architecture uses the Job Description Language (JDL) [15], which provides a very general means of expressing the requirements. The JDL allows users to specify a broad range of parameters, both characterizing the job (executable name, parameters, etc.) and specifying requested resource parameters (CPUs, network, storage, etc.). The user sends the JDL to the WMS as part of the job submission protocol. Upon receiving the JDL, the WMS processes it and tries to find the computing resource that best fits the requirements specified. Choosing the most appropriate resource is the goal of the matchmaking process. In order to be able to make its decision, the WMS must interact with external components (the Information System and Data Management services) that provide the current status of the resources and the Grid environment. The WMS can use different scheduling strategies, which can be added easily to the WMS in the form of dynamic plug-ins. Once the resource is chosen, the WMS prepares the job for submission and then submits it. In order to submit and monitor jobs on Compute Elements (CEs), the WMS uses the Condor-G [16] system. Condor-G contacts the remote resource using the Globus GRAM protocol [17] and sends the specification of the job to the Globus gatekeeper. After authenticating and authorizing the request, the gatekeeper ensures via the standard Globus mechanism that the job is 64

42 put into a queue of the local batch system. When the job starts computing, a special wrapper added by the WMS retrieves an input sandbox from the WMS that contains input data for the job. The input sandbox is defined by the user in the job s JDL and specifies files to be copied from the UI to the end computing resource, such as the job s binary or input data. Upon completion of the job the output sandbox with results is saved on the WMS. The contents of the output sandbox is also defined by the JDL and contains the output produced by the job, such as the standard output and standard error output streams. Sandboxes are transfered using the GridFTP protocol [3]. When the user finds out that her jobs have finished, she uses the UI to retrieve the output sandbox from the WMS to her local machine to analyze the result data. The WMS has access to a lot of information and manages jobs of many users and often processes sensitive data. Therefore the WMS was designed and implemented with special care to possible security issues. All network connections to the WMS are authenticated using TLS [18], and users must always prove possession of a valid credential during each job submission. During the job submission the user s proxy is also delegated to the WMS. The WMS will subsequently use this proxy when acting on behalf of the job owner, e.g., when submitting the job to the compute resource Even though each submitted job must have a valid proxy certificate delegated to the WMS, the overall job lifetime may easily exceed the lifetime of the credential. Proxy certificates are usually valid for a few hours, which may not be sufficient for a job to complete. Even if this lifetime is sufficient for the job s computation, the overall job lifetime may be much longer and unpredictable. For example if the resource where the job is being processed stops working, the job must be rescheduled and resubmitted by the WMS, possibly restarting the computation from the beginning. The jobs can also spend some time in queues waiting for required resources. It is not possible to estimate these times in advance. A simple solution for providing jobs with valid certificates would be submissions with long-lifetime proxy certificates. However, this would certainly lead to overestimation of the lifetime of certificates, which would break the meaning of short-lifetime proxy certificates. The Proxy renewal service is designed to address problems concerning support for longrunning jobs. The initial version of the service was designed and implemented in the EDG project, and further modification and development has been done in EGEE. IV. A PROXY RENEWAL SERVICE The proxy renewal service utilizes the functionality offered by MyProxy and extends its possibilities to support long-lived jobs. From a logical point of view, the service can be seen as a module of the WMS, which registers and manages the proxy certificates of all submitted jobs that request proxy renewal. All jobs maintained by the service are kept valid by periodically retrieving newer proxies from the MyProxy UI submit Fabric Management WM Service node Job Manager PUT proxy proxy Fig. 2. renew Renewal Service CondorG submit Gatekeeper Renewal Architecture GET proxy MyProxy Service VOMS repository and replacing proxies near expiration with the new ones. Besides the renewal of the proxy certificate itself, the service also supports renewal of VOMS certificates, which are embedded in the proxy as X.509 extensions and also have a limited lifetime. Details on how the VOMS certificates are handled are given in Subsection IV-C. Renewed certificates are detected by Condor-G [16], which ensures that the proxy is transfered to the CE, if needed. The architecture of the renewal service is illustrated in Figure 2. The proxy renewal service is a separate application executing on the same host as the WMS using the same account. It communicates with its clients via a local Unix socket using a simple text protocol. The renewal service does not listen on any network interface so it is not exposed directly to any kind of remote attacks. Access to the socket (and hence to the renewal service) is only allowed from the local system and is secured by the local operating system. However, being part of the whole WMS system, the renewal service (and proxies maintained by the service) can be compromised if an attacker gains control over the WMS. Thus, the WMS should always be installed on a well protected and monitored machine. A. Registering a Proxy with the Renewal Service During the submission of a job to the WMS, the job owner s proxy is delegated to the WMS as part of the submission protocol. The proxy is stored in a file on a local filesystem and is used by the WMS to act on the user s behalf, especially to submit the job to the chosen computing resource. When the users expect the job submitted will last longer than the proxy lifetime, they can specify a special option (called MyProxy) in the job description (JDL) containing a hostname of the MyProxy server containing long-lived credentials for the user. If the WMS encounters this option in the JDL, it contacts the renewal service to register the job proxy certificate for the renewal mechanism. In the registration request the WMS includes the filename of the file containing the proxy to register. Upon receiving the 65

43 request, the renewal service reads the proxy to verify that it contains a valid credential. It then creates a new file in its repository directory and copies the contents of the file to the new location. At the same time the renewal service updates its local database to add information about the new registration. In particular, it computes the time when the proxy should be renewed and stores this information in the database. Both the database and the registered proxy certificates are stored on disk so the service can recover easily from sudden reboots or crashes of the machine. To finish the registration, the service returns to the caller (WMS) the filename in the repository containing the registered proxy. This filename is used by the WMS instead of the original one, and the renewal service ensures that it always contain a valid credential. Since the WMS does not modify the proxy certificates, and the renewal service ensures that all updates to proxy files are atomic, the proxy file does not get corrupted and can be used by multiple processes or threads. The proxy registered with the service is identified by the jobid, a unique identifier which is generated for each job submitted to the WMS. In order to ease management of proxies owned by a single user and minimize network communications during renewal, the proxy renewal service avoids managing duplicate proxies when possible. If a registration request arrives and the proxy renewal service already has an equivalent proxy for the same user, the jobid is added to the list and no new file is created. However, if the new proxy is not equivalent to any stored proxy, (for example, it may contain different VOMS attributes), then the new proxy will also be stored for the user. B. Renewing a Proxy Credential The renewal service checks its database and list of registered proxies and if a proxy is nearing expiration (1/4 of lifetime remaining), it attempts to contact the MyProxy server asking for a new credential. The connection to the MyProxy server is secured using TLS with mutual authentication, and the renewal service uses its service certificate to authenticate. During the communication the service also has to prove it is in possession of the appropriate proxy certificate that is still valid before retrieving a new proxy. If the renewal service successfully retrieves a new proxy, it updates the registered proxy file with the new proxy. Otherwise, it computes a new time to attempt renewal again, using the method of bisecting intervals of remaining lifetime, with a minimum interval of five minutes. If all the renewal attempts fail and the proxy expires, it is removed from the repository and Condor-G stops the job. When a proxy is renewed and the file is updated, in some cases the proxy must be distributed further to update proxy certificates currently in use. If the job has not yet been submitted to a computing resource, there is no need to distribute any file, since the newer proxy will be used automatically by the WMS when the renewal service updates the file. However, if the job was already submitted to a computing resource, the proxy must be transported to that resource to allow the job to continue to perform authenticated actions. The renewal service does not contact the resources itself but utilizes the ability of the Condor-G service, used for job control by the WMS. Condor-G components running on the WMS maintain a list of submitted jobs and their proxy files. Whenever any of the files changes and the corresponding proxy is renewed, Condor-G contacts the corresponding job running on the resource and delegates a renewed credential there. Condor-G uses the GRAM protocol [17], which supports a special command for credential renewal. Using this command it is possible to delegate a new proxy to the GRAM jobmanager that manages the running job on the resource. EDG and Condor developers designed and implemented initial support for this command, and the modification was accepted to the standard Globus toolkit. After a job finishes, the WMS sends to the renewal service an unregistration request containing the jobid of the finished job. If the jobid is the last one in the list for a proxy file, the renewal service removes the file from the repository. Certificates may be revoked any time during their lifetime by the issuing CA, for example, if the credentials have been compromised. The renewal service does not itself perform revocation checks on registered certificates, but when they are used to authenticate to the MyProxy server or the CE, those services will verify that the user s certificate has not been revoked, to ensure that invalid credentials cannot be misused. C. Renewing VOMS Attributes The authorization framework of EGEE is based on VOMS [12], which issues attribute certificates to users that also have lifetime limited to a few hours. Since many EGEE services use VOMS attributes for making access control decisions, the job must also posses a valid VOMS certificate in addition to the proxy certificate. Therefore, it is not sufficient to renew only the proxy certificate, but VOMS attributes must be renewed as well. We contemplated two possible approaches to enable renewal of the VOMS attributes. The first possibility is to store the VOMS attributes in the proxy certificate on the MyProxy server. This possibility would ensure that valid VOMS attributes are part of each credential retrieved from the MyProxy server. Though simple, this approach has several limitations. The lifetime of VOMS attributes should not be set to very long values, since there is no means to revoke issued VOMS certificates. The credentials stored in the MyProxy server would have to either be too short or contain different proxy certificate and VOMS lifetimes. Both these scenarios would cause problems for long-running jobs. Also, the proxy renewal service uses the user s certificate name (X.509 subject name) as the identifier of the proxy requested from the repository, so the users could only use a single set of VOMS attributes, which also would not suit the users. In order to support VOMS credentials we chose to adapt the proxy renewal service so it is able to contact the VOMS servers. Whenever the proxy renewal service renews a proxy that contains VOMS attributes, it parses the VOMS data to find out which VOMS server issued it. Then it contacts the 66

44 VOMS server asking for the same set of VOMS attributes as was present in the proxy to be renewed. As the result of this process a new proxy certificate is created that contains the same set of VOMS attributes. V. RELATED WORK The problem of credential expiration for long-running jobs motivated the development of renewable tickets in Kerberos version 5 [7]. Users can request tickets from the Key Distribution Center (KDC) with a renewable lifetime greater than the ticket lifetime. Before the ticket lifetime is reached, the ticket holder can contact the KDC to renew the ticket. This process can be repeated until the renewable lifetime is reached. Policies at the KDC set the maximum ticket lifetime and who can request a renewable ticket. The Kerberized version of the Grid Engine scheduler supports automatic renewal of Kerberos tickets for long-running jobs. Unlike proxy renewal, Kerberos renewable tickets require users to specify the maximum renewable lifetime of the ticket in advance, which can be difficult to predict. Also, though it is possible in the Kerberos protocol for a user to tell the KDC to stop renewing a ticket, this functionality is not provided in standard Kerberos implementations. Since the development of the EDG renewal service, Condor-G [16] has also added support for credential renewal using MyProxy. Users can include MyProxy information in the job description file when submitting jobs to Condor-G, and Condor-G will contact MyProxy to retrieve new credentials for jobs before they expire. Condor-G will then delegate the new credentials to the jobs via GRAM proxy refresh, as described in Section IV. VI. SECURITY IMPLICATIONS MyProxy server policies control access to credentials in the repository. To renew a credential, the WMS must have a credential with distinguished name matching the renewal policy in the MyProxy server. The renewal policy is the combination of a server-wide policy set by the MyProxy administrator and a per-credential policy set by the credential owner. Both policies, written as regular expressions, must be met for the MyProxy server to grant credential access. Additionally, the WMS must have a valid proxy credential to be renewed. This provides an additional level of protection, so the WMS can only obtain new credentials if the user has already submitted a job to it with a delegated credential. Thus, the MyProxy server requires the WMS to authenticate twice: first with its service credential and then with the credential it wants to renew. The first authentication using the service credential is performed during the initial TLS handshake in the MyProxy protocol. Then, the MyProxy server sends an Authorization message to the client, containing a random challenge that the client must sign with the proxy key to prove possession of the proxy. The MyProxy server s credential repository, holding a large number of keys, is an attractive target for attack and must be well-protected, similar to a Kerberos KDC. It should be noted, however, that a professionally administered MyProxy server can provide a more secure storage location for user credentials than typical desktop systems, and all operations on the MyProxy server are logged to the system log for monitoring to help detect possible misuse. VII. EXPERIENCES The EDG infrastructure has enabled a wide range of computational science activities in Europe. The WMS, including the proxy renewal service, was adapted and deployed in many development and production environments. The widest deployment is the LCG Grid that currently comprises about 140 sites and CPUs. During various data challenges performed during the first half of 2004, it was shown that the WMS can process a vast number of jobs [14]. The execution time of these jobs often exceed the default proxy lifetime, requiring use of the proxy renewal service. After starting the EGEE project, the WMS was also used as the main cornerstone for job management. The current EGEE environment where the WMS is deployed contains 28 instances of the WMS and serves 12 virtual organizations. Current data received from the Quality Assurance JRA2 group [19] of EGEE which also monitors the usage of the resources shows that since January to the beginning of May, 1,090,849 successful jobs have been computed in this environment. 104,218 of these jobs took more than 12 hours (which is the default proxy lifetime), requiring the use of the proxy renewal service. When we initially deployed the proxy renewal service, we experienced problems with the sudden reboot of WMS machines, since for performance and security reasons the service kept all data in memory. Subsequently we redesigned and reimplemented the service to store all data on disk for persistence, and we have not experienced performance problems. We also divided the services into two separate processes. One of the processes (the master) serves the client requests for registration and unregistration of proxies, while the second one (the slave) performs the renewal process. This separation allows us to accumulate all calls to the Globus and MyProxy libraries in the slave. The slave is completely stateless and can be restarted at any time; it is automatically restarted after finishing 1,000 renewals. Such a change allows us to deal with multiple memory leaks that were present in the external libraries. VIII. FUTURE WORK The area of job management is not the only one dealing with limited lifetimes of proxy certificates. Similar issues were also encountered by the Data Management activity group in EGEE, which is responsible for providing and supporting the data management related middleware of EGEE. One of the corner stones of the data management infrastructure is Transfer Scheduling [20]. This service allows clients to specify requested data operations and submits them to a specialized service which is responsible for scheduling the requests and executing the file transfers. Since the data to transfer are 67

45 usually very large and also due to the dynamic character of the Grid environment, it is difficult to predict the duration of the file transfers, so this environment has similar credential management issues as the area of job management. To address these issues we are working with the data management group on augmenting the proxy renewal service to also support long-lived file transfers. IX. CONCLUSION The proxy renewal mechanism ensures that jobs submitted to EGEE have valid certificates throughout their lifetime without violating the meaning of short-time proxy certificates. All the proxy renewal process is performed in a controlled way, with only a small set of trusted services allowed to renew proxies. All transactions concerning proxy renewal are logged and can be analyzed for possible misuse. Users may choose which trusted proxy repository server to use for proxy renewal. Since management of proxy certificates in the repository is completely under the user s control, they may stop renewal at any time by removing their proxy from the repository. The proxy renewal capability has proven useful in European Grids over the past few years. While credential expiration has been long recognized as a problem for long-running jobs on the Grid, the EDG proxy renewal service is the first example of a solution that has seen widespread use. ACKNOWLEDGMENT EGEE is a project funded by the European Union under contract INFSO-RI We also acknowledge the national funding agencies participating in EGEE for their support of this work. The MyProxy project is supported by the U.S. National Science Foundation Middleware Initiative under contract ANI REFERENCES [1] Home page of the EU DataGrid project. [Online]. Available: [2] Home page of the EGEE project. [Online]. Available: [3] GridFTP Protocol Specification, Global Grid Forum GFD.20, March [4] S. Tuecke, V. Welch, D. Engert, L. Pearlman, and M. Thompson, Internet X.509 Public Key Infrastructure (PKI) proxy certificate profile, IETF RFC 3820, June [5] I. Foster, C. Kesselman, G. Tsudik, and S. Tuecke, A Security Architecture for Computational Grids, in Proceedings of the 5th ACM Conference on Computer and Communications Security Conference, 1998, pp [6] M. Humphrey and M. Thompson, Security Implications of Typical Grid Computing Usage Scenarios, in Proceedings of the 10th International Symposium on High Performance Distributed Computing (HPDC), August [7] B. C. Neuman and T. Ts o, Kerberos: An Authentication Service for Computer Networks, IEEE Communications, vol. 32, no. 9, pp , September [8] S. Mullen, M. Crawford, M. Lorch, and D. Skow, Site Requirements for Grid Authentication, Authorization and Accounting, Global Grid Forum GFD.32, [Online]. Available: [9] V. Welch, I. Foster, C. Kesselman, O. Mulmo, L. Pearlman, S. Tuecke, J. Gawor, S. Meder, and F. Siebenlist, X.509 proxy certificates for dynamic delegation, in Proceedings of the 3rd Annual PKI R&D Workshop, April [10] J. Novotny, S. Tuecke, and V. Welch, An Online Credential Repository for the Grid: MyProxy, in Proceedings of the Tenth IEEE Symposium on High Performance Distributed Computing (HPDC10), August [11] J. Basney, M. Humphrey, and V. Welch, The MyProxy Online Credential Repository, Software: Practice and Experience, [12] R. Alfieri, R. Cecchini, V. Ciaschini, L. dell Agnello, A. Frohner, A. Gianoli, K. Lőrentey, and F. Spataro, VOMS, an Authorization System for Virtual Organizations, in Grid Computing: First European Across Grids Conference, [13] P. Andreetto, S. Borgia, A. Dorigo, A. Gianelle, M. Mordacchini, M. Sgaravatto, L. Zangrando, S. Andreozzi, V. Ciaschini, C. D. Giusto, F. Giacomini, V. Medici, E. Ronchieri, V. Venturi, G. Avellino, S. Beco, A. Maraschini, F. Pacini, A. Guarise, G. Patania, D. Kouřil, A. Křenek, L. Matyska, M. Mulač, J. Pospíšil, M. Ruda, Z. Salvet, J. Sitera, J. Škrabal, M. Voců, V. Martelli, M. Mezzadri, F. Prelz, D. R. S. Monforte, and M. Pappalardo, Pratical approaches to Grid workload and resource management in the EGEE project, Computing in High Energy and Nuclear Physics (CHEP04), [14] G. Avellino, S. Beco, B. Cantalupo, A. Maraschini, F. Pacini, M. Sottilaro, A. Terracina, D. Colling, F. Giacomini, E. Ronchieri, A. Gianelle, M. Mazzucato, R. Peluso, M. Sgaravatto, A. Guarise, R. Piro, A. Werbrouck, D. Kouřil, A. Křenek, L. Matyska, M. Mulač, J. Pospíšil, M. Ruda, Z. Salvet, J. Sitera, J.Škrabal, M. Voců, M. Mezzadri, F. Prelz, S. Monforte, and M. Pappalardo, The DataGrid Workload Management System: Challenges and Results, Journal of Grid Computing, [15] F. Pacini, JDL Attributes, DataGrid-01-TEN-0142, 2003, [16] J. Frey, T. Tannenbaum, I. Foster, M. Livny, and S. Tuecke, Condor- G: A Computation Management Agent for Multi-Institutional Grids, in Proceedings of the Tenth IEEE Symposium on High Performance Distributed Computing (HPDC10), August [17] K. Czajkowski, I. Foster, N. Karonis, C. Kesselman, S. Martin, W. Smith, and S. Tuecke, A Resource Management Architecture for Metacomputing Systems, in Proceedings of the IPPS/SPDP 98 Workshop on Job Scheduling Strategies for Parallel Processing, 1998, pp [18] T. Dierks and C. Allen, The TLS Protocol Version 1.0, IETF RFC 2246 (Standards Track), January [19] Home page of the EGEE QA group. [Online]. Available: [20] EGEE glite User Guide Overview of glite Data Management, EGEE-TECH v1.0, March [Online]. Available: 68

46 Paper B A Robust and Efficient Mechanism to Distribute Certificate Revocation Information Using the Grid Monitoring Architecture The paper [2] published as: Daniel Kouřil, Luděk Matyska, and Michal Procházka. A Robust and Efficient Mechanism to Distribute Certificate Revocation Information Using the Grid Monitoring Architecture. In Proceedings of the 21st International Conference on Advanced Information Networking and Applications Workshops/Symposia, AINAW 07, volume 2, pages , Niagara Falls, Canada, IEEE Computer Society Contribution of the thesis author: 50% Number of citations in Google Scholar: 3 Number of citations in Scopus: 3 Indexed in Scopus

47 A Robust and Efficient Mechanism to Distribute Certificate Revocation Information Using the Grid Monitoring Architecture Daniel Kouřil, Luděk Matyska, Michal Procházka Masaryk University, Botanická 68a, Brno, and CESNET z.s.p.o., Zikova 4, Praha 6, Czech Republic Abstract Checking revocation information is necessary to prevent from using digital certificates whose contents become invalid. In current system either periodical retrieval of Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP) are the most common mechanisms to access revocation information issued by the certification authorities. As both these approaches pose problems we propose a new method based on a Push model, which is based on the Grid Monitoring Architecture. Using this approach we guarantee the revocation information is distributed in a robust and timely manner. We also describe a pilot implementation of the service based on the proposed design. 1 Introduction Reliable use of the PKI is based on credible certificates and trust in their authenticity. A revocation mechanism has been developed to inform interested parties about stolen, invalid, or compromisedcertificatesknown totheissuingcertification authorities (CA). A list of canceled certificates is published by each CA using a specific information channel as the only way how the information can reach the interested parties (end users and services) that rely on credibility of certificates. Such an approach obviously requires to check the latest revocation information as part of the standard verification of the certificate because accepting a revoked certificate could potentially lead to unauthorized access or information leakage. CAs usually pay attention to proper management of revocation information and make sure it is updated promptly and made available to the relying parties. The most usual mechanism for distribution of revocation information nowadays is using a certificate revocation list (CRL)[?] that the CA publishes regularly for the relying parties to download. While the certificate validity check is made local (using the downloaded copy of the revocation list), there may be too long delay between the time when a new CRL is published and when it is retrieved by all relying parties. This limitation was dealt with the Online Certificate Status Protocol (OCSP)[?], which allows to make a direct connection to the CA during certificate verification to check if the certificate is still valid. However, the OCSP also suffers from few drawbacks, notably the dependency on a network connectivity to an OCSP responder, which makes the certificate verification last longer and be more fragile. Also, the OCSP server may become a bottleneck if too many requests are issued simultaneously. Both the OCSP and standard way of CRL retrieval represent a Pull model of revocation information distribution, where the relying parties are responsible for checking if it is valid or if a new piece of revocation information has been issued. In this paper we present a new way of distributing CRLs, based on a push model, which ensures that they are delivered to the end systems almost immediately after their publishing by the CA. The relying parties thus do not need to contact the CA directly to consult the revocation information since the locally stored CRL is current. 2 Revocations handling in PKI Consulting revocation information is very often neglected in current deployments of PKI, as they need additional tools to be installed and maintained. However, revocation checks are inevitable in large distributed environments where PKI is widely used, such as contemporary Grids. For example, utilizing the PKI, the EU EGEE project[?] joins together thousands users from all the world and provides them with access to grid facilities. Obviously, performing revocation checks is a must within such an environment. Presently, CRLs are used to distribute revocation 21st International Conference on Advanced Information Networking and Applications Workshops (AINAW'07) /07 $

48 information inside EGEE and they are the only means generally supported by the EGEE middleware glite[?]. A retrieval script is shipped as a standard part of the glite distribution, which is used for automatic download of the CRLs for all CAs installed on a given system. The script is quite simple and can be used in other PKI installations as well. It is usually started four times a day, which leaves quite a long window in distribution of revocation information. Moreover, given the huge number of relying parties, the CA servers are often overloaded and the CRL retrieval attempts often fail, making the CRL distribution significantly delayed. For example, according to the information published by the Italian INFN CA, their CRL server handled a huge number of CRL retrieval request, ranging from 800 thousand in May 2005 to 1.5 million requests in April Curiously number of certificates revoked by the INFN CA in this period by was quite small, totaling just 67 certificates. In order to ease the maintenance of the revocation information and make its distribution flexible, the Online Certificate Status Protocol (OCSP) was developed, which brings the ability to the end services to ask for validity of the certificate online. OCSP is a request/response protocol based on binary ASN.1 encoded messages usually transferred over HTTP. An OCSP service consists of a responder and a client, with the responder holding a list of certificate status information and the client querying the current status for a given certificate. The OCSP responder is either operated by the CA or a third-party provider, its location can be either embedded directly in the certificate or specified by configuration of the end service (acting as the OCSP client). It is clear that end services have to ask the responder for every certificates they handle. Such requests may easily overload the responder therefore caching of responses on the end services was proposed. When the end service obtains a response from the responder it saves it and for a defined time it can use it for other validation. This time should be set up on the basis of information from the response. The OCSP is not a perfect solution to the revocation management problem as it faces possible huge traffic of OCSP requests. Also, OCSP adds another point of failure into the already complex infrastructure. And the last but not least problem is substantial increase of the delay of requests to the end services with the certificates due to the necessity to contact responder. In the next section we discuss this problem in more detail. 2.1 Comparison of OCSP and CRL We set up a testbed to study the difference in latency when validating the certificate with OCSP and with CRL distribution. The testbed consisted of an Apache server acting as an end service performing certificate validation, two OpenCA OCSP responders providing revocation information about certificates, and an wget client application. Every service ran on a separate machine. For testing purposes 100 CAs and 500 client certificates per CA were generated and also 100 randomly chosen certificates from each CA were revoked and corresponding CRLs generated. The certificates contained a standard X.509 extension that points to appropriate OCSP responder. All the CRLs were copied to the Apache web server, CRLs from the first 45 CAs were copied to the first OCSP responder and CRLs from the last 55 CAs were copied to the second OCSP responder. Time (seconds) OCSP CRL Without validation Number of requests Figure 1. OCSP vs. CRL The goal of the test was to measure differences in time that were needed to serve an HTTP GET request sent over an SSL connection. We studied performance of three different scenarios: checking using CRLs stored in local files, checking using OCSP and disabled checking at all. Using the wget client we initiated several connections to the web server, each using a randomly selected certificate of a CA for client authentication. The test represented sequential access of 10, 50, 100, 200, 400 and 800 users from 100 different CAs. We choose sequential access to avoid parallel optimization of Apache web server. The results of the test can be seen in Figure 1. The time in graph represents total run time of the script. Each number is a mean value of ten repeated tests. The graph shows big difference between the OCSP and CRL validation time. Difference between CRL and without validation is negligible. This simple test thus demonstrated the huge overhead associated with the use on on-line service for each certificate validation, confirming the hypothesis that the tests must be done on a locally available data. 21st International Conference on Advanced Information Networking and Applications Workshops (AINAW'07) /07 $

49 3 Using the Push model for CRL distribution As explained in the previous section, the OCSP introduces a significant performance penalty while the current concept of CRL does not ensure timely distribution. We present an alternative schema for revocation data distribution based on the Push model, where the relaying parties do not actively poll the CA seeking fresh CRLs but instead subscribe for this information and rely on the messaging infrastructure to deliver to them a new CRL immediately after it has been published by the CA. Using the Push model is a novel approach to the CRL distribution and is not supported by current CAs, therefore we propose a CRL distribution service (CRL DS) that collects revocation data from one or more CAs and distributes it to the clients. The schema of the service is depicted in Figure 2. CRL DP Relying Party Notification Relying Party CRL DP CRL Distribution Service OCSP Responder Relying Party Notification Query Relying Party CRL DP Relying Party Figure 2. Schema of the CRL Distribution service The service will be responsible for maintaining current CRLs, which are collected from the CA CRL distributed points. The CRLs have to be retrieved by a regular polling of the CAs, which is a standard and supported way for the operation. As only few instances of the CRL DS are expected to operate compared with the number of relying parties, the interval between the downloads can be very short. After retrieving a new CRL, the CRL DS will store it in its database and trigger sending a notification message containing the new CRL to the subscribed clients. The message will be put into a notification infrastructure which ensures its delivery to the relying parties. The infrastructure must be scalable enough to serve all the clients and also robust to cope with various errors that may occur during transmissions. For example, if a a particular client is temporarily unavailable the messaging infrastructure must ensure it will be contacted immediately after it re-connects again. After receiving the notification message, the client will decode it and store the obtained CRL in a local system replacing the old one. While the notification messages are the primary way of distribution, the CRL DS will also provide an interface to fetch a current list of all CRLs as maintained by the service. The interface should allow the clients to specify a subset of the CAs they are interested in or additional criterion to be used for selection of the CRLs. This interface is expected to be used by clients without a permanent network connectivity, e. g. mobile users. Such users are very often forced to use a slow or unreliable network so the messages exchanged with the CRL DS should be as small as possible. The CRLs returned by the service should be always sent in a single message. CRLs are always signed with the CA private key, which ensures their reliability and also provides integrity protection. If they were tampered with during the transmission, the end system would immediately detects the change and refuse to install the received CRL. The notification infrastructure therefore need not to provide any additional protection of the messages. Once the CRL is delivered to the local system (regardless if notifications or queries were used) it replaces the current CRL stored locally and can be immediately used by the application running on the system. Thus the mechanisms does not require any change in the application code or configuration provided the applications are ready to work with locally stored CRLs. The CRL DS can even be combined with additional components, e. g. it can be used as a source of CRL data for an OCSP responder serving OCSP enabled applications. The design and requirements outlined above are very similar to the concepts used by the Grid monitoring architecture (GMA)[?], which defines a general framework for monitoring in highly distributed environment. Having gained a lot of experience with monitoring in Grids we decided to base the CRL Distribution Service on an implementation of a GMA and to utilize the results we achieved in this area. 4 CRL Distribution using the Logging and Bookkeeping service This section describes our pilot implementation of the proposed schema for CRL distribution. The implementation is based upon the L&B architecture that provides a GMA and which has proven to be flexible enough to provide all necessary functionality. 4.1 Logging and Bookkeeping Service The Logging and Bookkeeping (L&B) service[?,?] is developed within the EU EGEE project as a real time mon- 21st International Conference on Advanced Information Networking and Applications Workshops (AINAW'07) /07 $

50 itoring system for tracking jobs on large Grids. It is a standard part of the glite software stack produced by the project and has been in production for many years now. The L&B architecture consists of two parts: the L&B server processing data about the jobs, and the L&B messaging infrastructure which is responsible for reliable and fault-tolerant delivery of monitoring information from the Grid components to the L&B server. The L&B approach requires that each grid component that processes a job moving through the grid environment is instrumented to send to the L&B server a message about all important events in the job lifetime. In this way various internal components of the Grid scheduler, and eventually the end computing resource are instructed to send L&B messages about the jobs they process. The messages are carried as L&B events using a dedicated L&B messaging infrastructure allowing the L&B server to collect effectively all events for the jobs. The infrastructure is based upon mediators that provide entry points to easy insert a message and ensure the message is delivered to the proper L&B server. The mediators are installed closely to the components generating the L&B messages and use their disk as a persistent storage of events that cannot be temporarily delivered. After receiving an L&B event, the L&B server stores it in the database and updates the job information including current state of the job. The state is computed by the L&B state machine based on the received events. The state machine reflects a life of the job in the grid environment, corresponding state diagram can be seen in Figure 3. A classical sequence of states for a job starts with a SUBMIT- TED state, meaning that the Grid scheduler accepted the job to process. This state is followed by WAITING meaning the job is waiting to be scheduler for a particular computing resource, then READY (job can be sent to the selected resource), SCHEDULED (job was accepted by the computing resource and is waiting in a local queue), RUN- NING (job was actually started), DONE(OK) (job finished successfully), CLEARED (the output was retrieved by the user). Apart from the standard events generated by the middleware, the user may also append additional information to their jobs using a special event delivering a UserTag. This way jobs can be marked with an arbitrary label, which can be used to distinguish one group of jobs from another. The L&B server exposes a powerful consumer interface that can be used by the clients to query for state of their active jobs as maintained by the server. The queries may specify a number of additional condition, such as various time constraints or appended user tags. In additions to the the query interface, the L&B server also allows the users to subscribe for notifications that are sent by the server on changes, according to the criterion specified by the client. In this way the users can wait for an asynchronous message CANCELLED DONE(failed) SUBMITTED WAITING READY SCHEDULED RUNNING CLEARED DONE(ok) Figure 3. L&B job state diagram ABORTED instead of periodically polling the L&B service to check if the state of their job(s) changes. The notification messages are also sent via the L&B infrastructure ensuring a reliable delivery even when the client is temporarily inaccessible at the time the notification is being generated and sent. An overall schema of accessing the L&B server data is given in Figure 4. Figure 4. L&B queries and notifications The L&B architecture was designed with security in mind, thus all communication channels are protected using the TLS protocol and all components must have X.509 certificates to authenticate. Access to the job information is only allowed by the job owner by default. However, the L&B server allows the users to specify access control lists for individual jobs to allow other users to share the job data. 4.2 Using L&B to distribute CRLs Having examined the revocation information flow, we noticed the life cycle of a CRL can be represented using a simple state diagram, which reflects important points in its lifetime. Based on this observation we decided to treat the revocation information issuance as a single job, which can be handled by the L&B service and its state machine. Sub- 21st International Conference on Advanced Information Networking and Applications Workshops (AINAW'07) /07 $

51 sequently, the L&B s implementation of the GMA makes it possible to distribute the CRLs across the community in a fast and robust manner. Especially, using the notification functionality the relying parties are notified immediately upon updating the CRL without any additional overhead. Also, the powerful query interface can be used by clients to ease the CRL maintenance and the bootstrapping process. With all these features grouped together, the L&B server could act as an instance of the CRL Distribution Service as described in Section Storing CRLs to the L&B The CRL lifetime can be described using three basic states, starting with an initial state (REGISTERED), which refers to establishment of the CA before the very first CRL is issued or entered to the L&B database. After that, the (PUB- LISHED) state is entered repetitively in a loop, marking each publication of a new version of the CRL. If the CA ceases operation and stops issuing the CRL, the lifetime of CRL concludes in a final state (TERMINATED). To better use the potential of the L&B job state machine we added a new state (UPDATING) to split the loop over the (PUB- LISHED) state into two steps. The state diagram can is presented in Figure 5. REGISTERED UPDATING PUBLISHED TERMINATED Figure 5. CRL life state diagram This CRL life cycle can be simply mapped to a subgraph of the standard L&B job state diagram and thus can be handled by the standard L&B processing. We model each CRL as a standard L&B job record in the L&B database. In order to register a new CA and a corresponding CRL, a new job entry is established, which will carry all the necessary information. Namely, the job record contains the CRL (if available) and also additional information, such as timestamps referring to transitions between states etc. Each job entry is assigned a globally unique identifier, which is usually generated by the L&B server on registering the job with L&B. However, when a new CA is being registered, a specially crafted job identifier is requested by the registration client, which consists of a network identification of the L&B server (triplet of the protocol, hostname, and port), common prefix labeling the CRL jobs, and a hash value computed from the public key certificate of the CA. This way the job identifier can be constructed by any client solely using the CA certificate (provided the L&B machine is known). After a new CRL job is registered with L&B, it is necessary to ensure it is updated properly upon each change of the CRL. In order to update the job record in L&B few events must be generated and sent to the L&B. This causes the CRL job to switch to the state UPDATING, assign the new CRL, and finally switch back to the PUBLISHED state. Each such transition between states can trigger a notification to be send if any client subscribed to receive it. The contents of the CRL is stored along with the job as a custom UserTag attribute. Thus it is available later if the job information is queried from the L&B server. Timestamps of each state change are automatically added to the L&B record, which allows users to query e. g. only for CRLs that changed from a given point in time. We want the service to be as general as possible handling multiple independent CAs. Therefore we do not use any direct link to the CA served, but utilize the standard CRL monitoring tools instead. We adapted the EGEE default retrieval script to use the L&B command-line tools and send appropriate events to the L&B server whenever it detects a new CRL. We configuredthe scriptto be invoked every five minutes to aggregate CRLs of all supported CAs and check for changes in them. Such a short interval allows to detect a new CRL very quickly Retrieving CRLs As described before the users have two ways of getting the CRLs notifications and queries (see also Figure 4. Notifications provides the most convenient way as they do not require any special activity on the client side and ensure the new CRL is delivered to the clients almost immediately after its issuance. On the other hand queries provide complementary functionality and are useful when notifications cannot be used by the client or if additional operations with the CRLs are needed. In order to receive the notification messages the clients must subscribe first to their receiving and start a client on the local machine, which is able to handle the notification messages. In the subscription request the client specifies CAs whose CRL they want to be notified about. Job identifiers used to specify the CAs are derived from the CA public key certificate as described in previous section. The notification messages are generated by the L&B server upon each state change of a registered CA. After such a change, a notification message is sent to all subscribed clients, which contain the full state information, included the new CRL. Notification messages are delivered using the L&B messaging infrastructure, which guarantees their reliable delivery. It is able to cope with clients temporarily unavailable and finish the delivery as soon as the clients connect again. It is even possible for the clients to change their location without having to unsubscribe the notification and subscribe a new one. It is sufficient if the client reconnects to the L&B server after change and announce its new address. This 21st International Conference on Advanced Information Networking and Applications Workshops (AINAW'07) /07 $

52 functionality is targeted to mobile users who can roam between different networks and still keep their CRLs current. Each notification registration is assigned a lifetime and must be renewed before it expires. Length of the lifetime is configurable on the server side and is usually couple of days, in our pilot installation we configured the notification lifetime to one year. The notification must be renewed by the clients before it expires. An issue concerning the notification mechanism may be the necessity for the client application to be reachable from outside. This requirement cannot be met if the client machine is behind a firewall or NAT. Users limited with such an environment can still use the queries to keep the CRL refreshed. This approach represents a roll back to the classical CRLs download, as the client must periodically poll the L&B server. Advantage of the L&B based solution is that all the CRLs can be queried and downloaded in a single step. The queries can ask either for a full set of current CRLs or only for those CRLs that changed since a particular point of time (incremental updates). As the L&B queries can contain several conditions that specify the set of CRLs, the clients can ask queries such as: Give me CRLs by CAs A,B,C that changed since last Monday. The resulting set of CRLs is returned in a single message, which significantly decreases demands on network communication compared with the standard way of retrieving CRLs. A couple of ways is available to query the L&B server. Simple query for a particular CRL can be performed using the standard glite commands, for more complex queries a specialized client implementation must be used. The L&B provides a C/C++ API, which can be used to create queries and getting responses. The L&B server also offers a Web Service interface that can be easily accessed by a range of various clients. We developed a pilot implementation of a client that is able to use both notifications and queries. In the former case it is run as a daemon on the client system, which subscribe to notifications for a locally installed CAs and waits for the messages from the L&B. The later mode can be used e. g. by mobile clients to fast update their CRLs, supporting both incremental and full updates. Regardless the way of retrieving CRL from the DS, the CRLs delivered to the client machine are stored on a disk and made available to the middleware and applications in the same way as if they were retrieved directly from the CAs. The L&B messaging is secured using TLS, which provides general security but also generates a chicken and egg problem in the deployment described in this paper. Since the CRLs are consulted whenever a new TLS connection is being initialized, the L&B based DS will fail to deliver a new CRL to a client whose CRL for the L&B certificate already expired. This applies for both notification and synchronous queries. There are a few workarounds to cope with the problem. One can use a specialized CA used only to issue a single certificate (for the L&B DS). In the future the L&B infrastructure could also be adopted not to use the TLS protocol. Such a change would not open any serious problem since the CRL are already signed. 5 Conclusion We presented a novel way of distributing revocation information using the grid monitoring architecture and its messaging features. The mechanism described ensures a fast and reliable delivery of CRLs to end services, which need not to contact any other network services to get current revocation information. We proposed a concept of the CRL Distribution Service that utilizes the GMA functionality and presented a pilot implementation of the service. The implementation is based on the glite L&B service, which was primarily designed to job monitoring, however we demonstrated the service can be used even for more general tasks. The pilot implementation primarily supports sending notification messages that contain new CRLs. In addition to this Push model, a query interface can be used, which offers an easy way of aggregating current CRLs, allowing for both full and incremental updates. Acknowledgment The work has been supported by the research intent Optical Network of National Research and Its New Applications (MŠM ). References [1] F. Dvořák, D. Kouřil, A. Křenek, L. Matyska, M. Mulač, J.Pospíšil, M. Ruda, Z. Salvet, J. Sitera, J. Škrabal, and M. Voců. Services for tracking and archival of grid job information. In Proceeding of Cracow Grid Workshop, [2] EGEE. Enabling Grids for E-sciencE (EGEE) Project. [3] R. Housley, W. Polk, W. Ford, and D. Solo. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF RFC 3280, April [4] D. Kouřil et al. Distributed tracking, storage, and re-use of job state information on the grid. In Computing in High Energy and Nuclear Physics (CHEP04), [5] E. Laure et al. Middleware for the next generation grid infrastructure. In Computing in High Energy Physics and Nuclear Physics (CHEP 2004), [6] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. X.509 Internet Public Key Infrastructure Online Certificate Status Protocol OCSP. IETF RFC 2560, June [7] B. Tierney, R. Aydt, D. Gunter, W. Smith, V. Taylor, R. Wolski, and M. Swany. A grid monitoring service architecture. Global Grid Forum Performance Working Group, st International Conference on Advanced Information Networking and Applications Workshops (AINAW'07) /07 $