Using OGRO and CertiVeR to Improve OCSP Validation for Grids

J Supercomput (2007) 42: 253–266DOI 10.1007/s11227-007-0120-x

Using OGRO and CertiVeR to improve OCSPvalidation for Grids

Jesus Luna · Manel Medina · Oscar Manso

Published online: 7 April 2007© Springer Science+Business Media, LLC 2007

Abstract Authentication and authorization in many distributed systems rely on theuse of cryptographic credentials that in most of the cases have a defined lifetime.This feature mandates the use of mechanisms able to determine whether a particularcredential can be trusted at a given moment. This process is commonly named val-idation. Among available validation mechanisms, the Online Certificate Status Pro-tocol (OCSP) stands out due to its ability to carry near real time certificate statusinformation. Despite its importance for security, OCSP faces considerable challengesin the computational Grid (i.e. Proxy Certificate’s validation) that are being studiedat the Global Grid Forum’s CA Operations Work Group (CAOPS-WG). As mem-bers of this group, we have implemented an OCSP validation infrastructure for theGlobus Toolkit 4, composed of the CertiVeR Validation Service and our Open GRidOcsp (OGRO) client library, which introduced the Grid Validation Policy. This pa-per summarizes our experiences on that work and the results obtained up to now.Furthermore we introduce the prevalidation concept, a mechanism analogous to theAuthorization Push-Model, capable of improving OCSP validation performance inGrids. This paper also reports the results obtained with OGRO’s prevalidation rulesfor Grid Services as a proof of concept.

Keywords CertiVeR · Grid validation · Grid validation policy · Online CertificateStatus Protocol · Open Grid OCSP · Prevalidation

J. Luna (�) · M. MedinaComputer Architecture Department, Polytechnic University of Catalonia, Jordi Girona 1-3,08034 Barcelona, Spaine-mail: [email protected]

M. Medinae-mail: [email protected]

O. MansoCertiVeR, Diputacion 238, 08007 Barcelona, Spaine-mail: [email protected]

254 J. Luna et al.

1 Introduction

Many distributed environments (i.e. the computational Grid, Web services, etc.) basetheir authentication and authorization mechanisms on the life cycle management ofcryptographic electronic credentials, making special emphasis on the issuing and re-vocation processes. Let us take for example the X.509 digital certificates [4] whichmay open the door to a distributed system for its owner only when he is authorizedto process the operation being requested. In order to do so, at a very basic securitylevel the system verifies the credential (i.e. issuer’s digital signature, validity period,etc.) and the purpose by which such credential was issued (i.e. roles and attributes).However, this mechanism is not enough to ensure complete security. If a higher levelof security has to be reached the system should also validate the credential. Throughthis paper we will use the term “validation” as the process in charge of verifying thatthe credential has not been reported by its owner as stolen, lost or compromised. Inmost cases the entity issuing the credentials—in a PKI such entity is named Certifi-cation Authority (CA)—is in charge of providing such validation information to anyrelying party requesting it. On top of that, it is also necessary to iteratively validatethe issuer’s credentials until a trust anchor has been found; this process is often calledCertificate Path Validation. The validation process is traditionally based on the useof Certificate Revocation Lists (CRL) (which are files digitally signed by a CA, con-taining the serial numbers of those certificates which have been revoked, cancelledor suspended in the PKI) which are placed on a public directory accessible throughprotocols like HTTP, LDAP and FTP. However, this solution tends to be cumbersomefor both the CA and the relying party. In terms of the CA, the solution is difficultto manage because it involves providing revocation information efficiently (in somescenarios near real time notification is a must). Also on the relying party’s side, thissolution penalizes efficiency, because it becomes forced to periodically download andparse the whole list of revoked certificates—which can be extremely large—in orderto perform the validation process. In consequence, more efficient mechanisms allow-ing the provision of real time certificate status information to relying parties havebegun to be adopted in some demanding environments requiring highly efficient andsecure solutions.

Proposed in 1999 on RFC 2560 [5], the Online Certificate Status Protocol (OCSP)is one of those mechanisms. In this paper we will focus our analysis into one dis-tributed system, which special features create strong security and performance re-quirements on OCSP: the computational Grid. We analyzed in this paper the GlobusToolkit 4 (GT4) [12], which uses Proxy Certificates (defined in RFC 3820 [17]) asshort-lived cryptographic authentication credentials, acting on behalf of their issuer(typically the user itself) and implementing mechanisms that provide a secure frame-work for Grid’s relying parties. Integration of OCSP into GT4 requires not only thedevelopment of special mechanisms not available in other distributed systems (i.e.Proxy Certificate validation), but also implementation of customized and efficient so-lutions for other particular issues (i.e. OCSP Responder discovery, fault tolerance,high performance, etc.). This problem has been considered so important that commu-nities like the Global Grid Forum (GGF) are actively studying the adoption of OCSPinto the Grid very closely. In that direction, as members of the GGF’s CA Opera-tions Workgroup (CAOPS-WG) and co-authors of the draft “OCSP Requirements for

Using OGRO and CertiVeR to improve OCSP validation for Grids 255

Grids” [8] we have designed—based on the guidelines of such document—and de-veloped the Open GRid Ocsp (OGRO) Java API, which provides OCSP support forGrid relying parties through a set of customizable validation rules, named the GridValidation Policy.

Based in that work, this paper proposes a completely functional OCSP valida-tion infrastructure for Grids that uses OGRO and the CertiVeR OCSP service [3].Furthermore, we also introduce a new mechanism called prevalidation, consisting ofOGRO-enabled Grid clients embedding the OCSP Response received from CertiVeRinto a non-critical extension from the Proxy certificate, in such a way that while theOCSP security level is preserved, the overall validation performance is greatly im-proved.

This paper presents our proposal in the following manner: Sect. 2 explains andshows the results obtained with our first proposal on the use of CertiVeR and OGROto provide a validation infrastructure for the Grid. Section 3 presents the results ofa further OCSP validation improvement, by introducing OGRO’s prevalidation mech-anism. The related work can be seen in Sect. 4, and finally Sect. 5 contains our mainconclusions and planned future work with OGRO and CertiVeR.

2 Using CertiVeR and OGRO to provide an OCSP infrastructure for Grids

In this section we introduce an OCSP infrastructure for the Grid, founded on theadoption of CertiVeR as a Trusted Responder and the OGRO Java API as a validationmiddleware for the GT4-based relying party.

2.1 CertiVeR

CertiVeR is an EU funded project that offers a comprehensive validation service that,apart from providing validation information of a X.509 certificate in real time throughthe Online Certificate Status Protocol (OCSP) it also implements a CRL Updatermodule, which is in charge of retrieving revocation information directly from theCA’s CRL through protocols like LDAP and HTTP. This information is stored ina local cache.

A DeltaCRL connector has also been developed, which is used by the CRL Up-dater modules to remotely push any new revocation information from the remoteCA into the Cert Status DB. Support for proxy certificate validation was also im-plemented, allowing a Grid client to securely revoke this credential. Thanks to theadoption of a customizable set of extensions on the OCSP response, CertiVeR canreport information at several levels: technological—e.g. the reliability of the degreeof trust in the issuing authority of the certificate—and commercial—e.g. informationprovided by the Chambers of Commerce about a company. Such type of informationmay dramatically increase security and e-Trust.

For each organization member of the Grid’s VO, CertiVeR OCSP responder canbe configured in trusted or authorized mode as defined in [5]. Finally, fault tolerance(implemented through replication techniques, backup sites and load balancers) andhigh performance (based on the use of cryptographic hardware) are also provided forthose organizations requiring them.

256 J. Luna et al.

2.2 The Open GRid OCSP (OGRO): an open source OCSP library for GT4

In previous work [7] we introduced the foundation for a GT4-based OCSP middle-ware, which made use of CertiVeR to validate proxy certificates while requestingauthorization information in the form of OCSP extensions provided by the service it-self. This client has evolved since then and it is currently available as an open sourcetool under the name of OGRO (Open GRid OCSP) [9]. OGRO implements the one-message proxy certificate validation, a mechanism that is able to validate the wholeProxy Certificate Path with just one OCSP Request/Response pair. Furthermore bybeing Open Source and 100% Java, OGRO is suitable for integration into Grid ap-plications. It is also easily configurable through the so-called Grid Validation Policywhich has been defined as a flexible set of XML rules. The following section willcover in detail this feature.

2.2.1 Customizing OGRO: the Grid Validation Policy

OGRO is configured through a set of rules—written in XML—called the Grid Vali-dation Policy (GVP), which customizes relying parties’ validation behavior. Table 1shows the DTD defining the GVP’s structure.

We can observe from this table that in line 2 the GVP allows configuring per-issuervalidation rules. There is also the option to configure a default issuer, that is, rulesapplying to any certificate whose issuer is not referenced anywhere else into the GVP.

A set of revocation sources (lines 8–13) can also be defined. This allows the re-lying party to query several OCSP Responders, resulting on the provision of faulttolerance and high availability features at the middleware. Moreover, the meaning ofthe “Unknown” OCSP status (line 15) can be customized for any credential on thecertificate path (Proxy or non-Proxy).

On the other hand, lines 16–19 provide for the definition of error handling mecha-nisms which may be declared to take a certain action in case of unexpected problems,i.e. when an OCSP Responder could not be contacted. The current set of error han-dlers can be extended to fulfill special requirements of VOs.

Customization of OCSP Requests (i.e. use of signatures and nonces) is also pro-vided by the OGRO Validation Policy in lines 22 to 32.

It is important to note the existence of Proxy Certificate’s prevalidation rules (lines34–36), which will be explained in the next section.

More than being a set of configuration directives, OGRO’s Grid Validation Pol-icy represents a mechanism to tailor validation process’ security level. For example,a VO may decide to use only a defined set of internal OCSP Trusted Respondersbenefiting performance (i.e. not using digital signatures, nonces nor HTTPS), whileother VO may use external OCSP Authorized Responders but compelling its clientsto use strong OCSP Requests (i.e. digitally signed, using a nonce and HTTPS).

The following section compares several Grid Validation Policies for an OCSPinfrastructure based in CertiVeR and OGRO, with the purpose to help potential usersin deciding which policy best fits their security requirements.

Before the tests we were expecting to identify a policy with the best performance(presumably the NoNonce-NoSign-HTTP which generates OCSP Requests withoutnonce, not being signed and using HTTP) and also the most secure policy (in theory


Table 1 DTD for OGRO’s Grid Validation Policy

1 <?xml version=“1.0” encoding=“UTF-8” ?>

2 <!ELEMENT ocsppolicy ( issuerdn+ ) >

3 <!ELEMENT issuerdn ( source?,unknownstatus?,

errorhandler?,request?,proxycert? ) >

4 <!ATTLIST issuerdn dn CDATA #REQUIRED>

5 <!ATTLIST issuerdn name CDATA #REQUIRED >

6 <!ATTLIST issuerdn hash CDATA #REQUIRED >

7 <!ELEMENT revsources ( source+ ) >

8 <!ELEMENT source EMPTY >

9 <!ATTLIST source order CDATA #REQUIRED >

10 <!ATTLIST source signingcert CDATA #IMPLIED >

11 <!ATTLIST source location CDATA #REQUIRED >

12 <!ATTLIST source type (trusted|authorized) “trusted” >

13 <!ATTLIST source timeout CDATA #IMPLIED >

14 <!ELEMENT unknownstatus EMPTY >

15 <!ATTLIST unknownstatus action (good|revoked) “revoked”>

16 <!ELEMENT errorhandler ( action+ ) >

17 <!ELEMENT action EMPTY >

18 <!ATTLIST action order CDATA #REQUIRED >

19 <!ATTLIST action type (tryLater|setFinalRes)“setFinalRes”>

20 <!ATTLIST action value (good|revoked) “revoked” >

21 <!ATTLIST action maxRetries CDATA #IMPLIED >

22 <!ELEMENT request ( signreq?, usenonce?, prot?, ext* ) >

23 <!ELEMENT signreq EMPTY >

24 <!ATTLIST signreq value (true|false) “false” >

25 <!ELEMENT usenonce EMPTY >

26 <!ATTLIST usenonce value (true|false) “true” >

27 <!ELEMENT prot EMPTY >

28 <!ATTLIST prot value (http|https) “http” >

29 <!ELEMENT ext EMPTY >

30 <!ATTLIST ext order CDATA #REQUIRED >

31 <!ATTLIST ext oid CDATA #REQUIRED >

32 <!ATTLIST ext value CDATA #REQUIRED >

33 <!ELEMENT proxycert ( unknownstatus, prevalidation ) >

34 <!ELEMENT prevalidation EMPTY>

35 <!ATTLIST prevalidation value (true|false) “false” >

36 <!ATTLIST prevalidation noprevalinfo (ocsp|ommit) “ocsp” >

the Nonce-Signed-HTTPS generating OCSP Requests with nonce, digitally signedand using HTTPS). However from the results obtained, we found that on the client-side there is no big difference among any of them (between 2% and 6% was ob-served). It is also interesting to note that the use of HTTPS did not imply a visibleoverhead neither in OGRO nor CertiVeR. A policy commonly used by relying par-

258 J. Luna et al.

Fig. 1 Proxy Cert initialization with CertiVeR and different OGRO policies over HTTP

ties in environments like Web Services is the Nonce-NoSign-HTTP (which protectsagainst replay attacks, does not identify the client to the OCSP Responder and goesover clear-text HTTP), which resulted in a fair balance between security and perfor-mance. Figure 1 shows obtained results over HTTP, even though the use of HTTPSproduced similar conclusions.

From a performance point of view, the use of nonces in the OCSP Request isalmost irrelevant and it would be advisable only if the OCSP Responder uses pre-computed Responses. Otherwise, for security reasons, it should be enabled.

Similar to the above observation is the use of digital signatures on the OCSP Re-quest: its use is only advisable if a special reason to justify it exists (i.e. for serviceaccountability or access control purposes).

On the OCSP service-side we observe that CertiVeR kept sustained response timesfor all the clients. In other words, no bottlenecks were evident even though all OCSPRequests were launched in parallel.

We have to notice that the use of OCSP is time-expensive for Grid clients, becauseobviously more processing is required (i.e. Grid Validation Policy parsing, crypto-graphic operations for the OCSP message, disk access and response validation just toname a few). Further research in OCSP validation performance took us to find thatimportant improvements could be done through a mechanism named prevalidation,which is explained next.

3 Improving OCSP validation: pre-validating with OGRO

3.1 The problem

As mentioned in the previous section, Grid Validation Policies created with differ-ent Request rules (in particular combining the digital signature, nonce and protocolparameters) kept similar performances in OGRO and GT4.

Although the OCSP validation overhead on the server-side represents approxi-mately 30% (i.e. when the CounterService Grid Service is invoked) it becomesfar more critical for overall performance. Such conclusion raised the following ques-tion: are we able to sacrifice client’s performance prior to invoking a Grid Service


to benefit WSRF Container’s overall performance? Our novel prevalidation mecha-nism in OGRO took this direction to provide a secure and high-performance OCSPvalidation solution for Grid environments.

3.2 Introducing OCSP prevalidation

When we faced the challenge of improving the performance of OCSP validation inGrids without affecting its overall security, a concept from the authorization area[19] came to our mind: the push model. Here we use the OCSP Response itself asa validation ticket to be exchanged between the user and the service. The rationalebehind this is very simple when taking into account the fact that such message is au-thenticated (digitally signed by the OCSP Responder which is a trusted third party),tamper protected (again thanks to the digital signature) and includes a validity pe-riod. In other words, the OCSP Response can be presented by the user as a proofof prevalidation to any other Grid relying party. The other challenge in designingthe prevalidation mechanism involved deciding how to transport the OCSP Responsealong with the user identity. We solved this problem by implementing a solution usedby the CAS [10], VOMS [1] and PRIMA [6] authorization systems, where the at-tributes assertions are embedded as Proxy Certificate’s extensions.

The results obtained with OGRO’s prevalidation mechanism, under the same con-ditions described in Sect. 2.2.1, are shown in Fig. 2.

Just as expected in the client side, the time consumed by OGRO’s validation andprevalidation processes, was almost 100% above the time that elapsed when suchmechanisms were not used. However it is interesting to note that embedding theOCSP Response into the Proxy Certificate did not result in a visible overhead. Onthe other hand, the results obtained with the Grid WSRF container—server side—(Fig. 3) showed that the prevalidation process reduced in little more than 30% the timerequired to validate with OCSP a Proxy Certificate. More noticeable is the fact thatthe prevalidation check at the server side did not introduce a visible overhead (in factless than 1%). On the other hand, even though a bottleneck at the WSRF Containeritself was noticeable as the number of concurrent invocations increased (around the9th invocation in Fig. 3), again it does not deny the fact that pre-validating improves

Fig. 2 Results obtained with the Grid client when creating the Proxy Certificate

260 J. Luna et al.

Fig. 3 Results obtained with the WSRF Container when validating the Proxy Certificate

OCSP performance and in the best of the cases (if no bottleneck was generated atthe WSRF Container) the gap between the OCSP No Prevalidated and OCSPPrevalidated series (Fig. 3) could be reduced, but would always be noticeable.

3.3 Comparing prevalidation versus caching

One of the recommendations being provided in the draft [8] refers to caching theOCSP Responses for enhancing validation performance. Caching can be extended toseveral levels of the Grid infrastructure to achieve this goal: a first-level cache at theGrid client, a second-level cache at the Grid server (i.e. the WSRF container) anda third-level cache at the local OCSP Server. Using this cache hierarchy it is pos-sible to reduce not only the cryptographic and communications overhead caused bythe interaction with the global OCSP Responder, but also the total number of queriesmade to the server—this last aspect can also result in economic advantages consider-ing that some OCSP providers sell their service on a per-request basis. When furtherconsidering the idea behind the OCSP cache hierarchy, we expected that second-levelcaching would provide the best cost-benefit and secure solution for Grids. This is dueto the fact that in most Grids installations it is reasonable to think that first-levelcaches will serve too few clients—in the worst of the cases a cache per Grid client—when compared with a second-level cache. On the other hand, third-level caches—installed at the local OCSP Responders—may cause some bottlenecks to the Gridservers contacting them (local Responders are not expected to be highly scalable orfault-tolerant in contraposition to a Trusted Responder serving several domains), andon top of that, they also might be more sensitive to network failures than first- andsecond-level caches.

The latest version of OGRO implements OCSP validation with second-levelcaches following the next steps:

1. The Grid client creates its Proxy Certificate in the usual way (it does not requireOGRO).

2. Cache initialization: When a Grid Service is requested from the OGRO-enabledWSRF container (through the Secure Messaging mechanism as done with prevali-dation), the OCSP Responder is contacted to request validation for the whole End


Entity certificate chain. As soon as the Grid server receives the OCSP Response,it is verified and stored into a local cache.

3. Cache searching: Client connections to the Grid server implying a cache-search(OGRO can be configured to enable caching only for certain Certification Author-ities hierarchies) use the native lookup methods to access this cache. Thereforeone of the following will occur (i) In case of a cache hit, then OGRO retrievesthe stored OCSP Response, verifies it (to avoid outdated entries) and extracts thecorrespondent status for the whole certificate chain or (ii) In case of a cache miss,the appropriate OCSP Responder will be contacted and the new Response storedinto the cache, so subsequent calls from the same user shall result in a cache hit(if the entry has not been purged).

4. The cache is being frequently purged by a separate thread, so stale entries (out-dated OCSP Responses according to RFC 2560’s verification method) are re-moved when detected. Responses reporting an invalid End-Entity CertificateChain, i.e. those with at least one revoked certificate- are permanently stored.

With the purpose of comparing OGRO’s prevalidation and second-level cachingmechanisms, a CertiVeR’s OCSP Trusted Responder (service based on a Xeonprocessor @2.9 GHz, 1.5 Gb RAM and Windows 2000) was set up at http://globus-grid.certiver.com. The Responder was using an Oracle database to store therevocation information, but neither cryptographic hardware nor precomputed OCSPResponses were utilized. For the Grid clients we created a set of 5 different End-Entity Certificates and did set up 50 OGRO-modified Commodity Grid Kit [18] in-stallations with credentials consisting of the same certificate for each 10 clients, inorder to test caching capabilities. The hardware used for the relying parties was com-posed of a 4-Xeon processors server running over RedHat Linux 7.2. Finally a GT4WSRF Container was also integrated with OGRO and installed on a 2-Xeon proces-sors server running over RedHat Linux 7.2.

Each one of the three tests reported in this section consisted of concurrently run-ning 50 clients requesting the same Grid Service from the WSRF Container throughthe Secure Messaging mechanism. The OCSP Validation mechanism was triggeredaccording to the applicable Grid Validation Policy (GVP) shown in Table 2.

The results obtained from our tests are shown in Fig. 4, where the total GVP per-formance is computed as the addition of (i) the time required by the WSRF Containerto perform the OCSP call (when applicable) and (ii) the time to cryptographicallyverify and parse the OCSP Response (for second-level caching this is the time takento read the certificate’s status from the in-memory cache, while in the prevalidation

Table 2 Grid Validation Policies for comparing prevalidation and caching

Grid validation policy Explanation

OCSP WSRF Container uses OCSP to validate every Grid client request.

Cache Second-level caching enabled at the WSRF Container. OCSP validationwill be invoked only if a call to the cache is missed.

Prevalidated Prevalidation support enabled so the WSRF Container never has to con-tact the OCSP Responder.

262 J. Luna et al.

Fig. 4 Grid-OCSP performance comparison: prevalidation versus caching

case it will correspond to the time required to extract and verify the OCSP data fromthe Proxy certificate).

As we can see from Fig. 4, the use of plain OCSP “Total OCSP” graph—conveysthe highest overhead for the validation process, something already concluded in pre-vious work [7]. In fact the peaks observed during this test are due to bottlenecks cre-ated at the OCSP Responder when several instances from the WSRF’s OGRO APIare concurrently requesting validation, and when afterwards the container itself per-forms the cryptographic verification and parsing over each one of the received OCSPResponses. The observed performance peaks are repeated in almost regular intervalscomprehending from 5 to 7 WSRF requests. This behavior is only dependent on theservice and therefore, it is not a subject of study for this paper.

On the other hand, the “Total Cache” test shows that before the 8th call, thegraph behaves almost like the “Total OCSP” test. Even though this result could beexpected—because the in-memory cache is still being filled—it is remarkable to no-tice that it corresponded with the performance peak observed during the first test.However, once the cache is filled with the responses corresponding to all the EECs,then the overall performance greatly improves as the OCSP Server is no longer re-quired to retrieve the status from the in-memory cache anymore. The latter opera-tion requires a few tenths of microseconds due to the performance and concurrency-control mechanisms of the underlying OGRO API; a future enhancement may pro-vide a more scalable database approach for implementing the OCSP cache.

On the other hand, the results obtained with the prevalidation mechanism (the “To-tal prevalidated” graph) do not involve the high peaks from the two previous tests.This is because the WSRF Container never required contacting the OCSP Server.Apart from this, we found some others peaks in the graph and, maybe more surpris-ingly, a slightly worse performance than with the second-level cache mechanism—once this one is full. This behavior is due to the fact that cached EEC’s statuses aredirectly accessed from an in-memory data structure, while prevalidation data must beextracted from Proxy Certificates read from network sockets—thus requiring moresystem calls to the underlying system—while also involving cryptographic valida-tion.


4 Related work

There are several standalone OCSP clients currently available (maybe one of themost commonly used is the OpenSSL [15], which also includes a set of C libraries).Support for OCSP in relying parties’ software has been implemented also in otherprogramming libraries like SUN’s J2SE5 [11], BouncyCastle [14] and IAIK [13].Stand-alone and fully functional OCSP clients have been also implemented like inthe case of Ascertia’s software [2] (See Table 3).

As far as we know, OGRO is the first OCSP client adapted for the GlobusToolkit—and very likely for any other Grid software—thus, the only client providinga prevalidation mechanism for Grids as the one presented in this paper. OGRO wasbuilt upon publicly available Java APIs to provide a set of particular features requiredby the computational Grid, which were not offered “as is” by such implementations.

Table 3 shows a comparison—relative to the requirements introduced in thedraft [8]—between OGRO, three well known JCEs—implemented into SUN’s J2SE,BouncyCastle and IAIK—and two client implementations (OpenSSL and Ascertia’sOCSP Client) which, according to our research, integrate a set of comprehensiveOCSP features pretty close to Grid requirements. From Table 3 it is easy to concludethat OGRO’s main contribution to the computational Grid is to be the first publiclyavailable API, which implements the full set of OCSP relying party requirementsidentified by the GGF’s CAOPS-WG.

Table 3 Comparing OGRO with other OCSP APIs and clients

Grid OCSPrequirement

J2SE5 Bouncycastle

IAIK OpenSSLclient

AscertiaOCSP client

OGRO

HTTP/ Both Both Both Both Both Both

HTTPS

RevocationSources

AIA,OCSP,CRL

No No CRL/OCSP

AIA,OCSP.List withTrustedResp.

AIA, OCSP,CRL. Queryorder in GridVal Policy(GVP).

Nonces Notspecified

Yes Yes Yes Yes Yes

Error Handling AIA orOCSP.Fallback toCRL.

No No Timeoutmechanism

No Iterativequery. Setfinal status iffailed.

UnknownStatus Man-agement

No No No No No Yes

Request Signing Notspecified

Yes Yes Yes Yes Yes

Configuration Configuredinto JCE.

No No Configura-tionFile.

GUI con-figurator.

Flexibleruleset withGVP.

Prevalidation/Caching

No No No No No Prevalidationand caches.

264 J. Luna et al.

Thanks to the flexibility added with the Grid Validation Policy, OGRO is preparedto implement future Grid-OCSP requirements (i.e. Proxy Certificate Revocation).

Regarding prevalidation we have to mention that the idea of embedding informa-tion into Proxy Certificate’s extensions is not new, and in fact it has been used by so-lutions implemented in the Authorization field in systems like CAS [10], VOMS [1]and PRIMA [6].

In the OCSP service-side it is worth to mention Sytrust’s OpenValidation [16]which implements several of the functionalities also presented in CertiVeR. However,this last system does not support the Authorized Responder mode with the samecryptographic key-pair nor the Proxy Certificate’s revocation service.

5 Future work and conclusions

This paper has introduced the Open GRid Ocsp (OGRO) client API which imple-ments the requirements of OCSP infrastructures in order to be suitable for Grid envi-ronments, just as proposed by the GGF’s CA Operations Workgroup (CAOPS-WG).OGRO’s functionality can be easily customized by a set of XML rules in the formof a Grid Validation Policy. To provide some insight into the security and perfor-mance effects of different Grid Validation Policies, an OCSP infrastructure based inthe CertiVeR Validation Service, OGRO and the Globus Toolkit 4 was setup. Weobserved that in general the policies’ response time was almost the same, thereforefrom the client’s performance point of view there is no big difference if nonces, dig-ital signatures or secure channels are used when connecting to a service like the onewe have tested (which does not preprocess OCSP responses). Our tests also haveshown that the architecture OGRO-CertiVeR greatly improves Grid security. How-ever, it also overloads such environments with the delay generated by the OCSPvalidation mechanism. For this reason the prevalidation concept was introduced asa mechanism capable of improving OCSP validation performance in Grid environ-ments. This has been done by embedding the OCSP Request in a Proxy Certificateextension in such a way that the overhead introduced by traditional OCSP has beenmoved from the server to the client. In doing so, the overall system security is notaffected, because the Grid server is enforced to perform a series of security verifi-cations over the pre-validated data contained in the Proxy Certificate to ensure itscorrectness (verification of Responder’s digital signature, OCSP Response’s validityperiod, etc.). As a proof concept we have modified the Open GRid Ocsp (OGRO)client to support prevalidation through a new rule introduced in the client’s Grid Val-idation Policy being defined. This API was then tested with the Globus Toolkit 4 ina way that prevalidation was performed by the Grid user when creating a Proxy Cer-tificate, and then enforced at the WSRF Container when a Grid Service was beinginvoked through the secure messaging mechanism. Results showed that importantimprovements could be obtained at the Grid server without any extra overhead in-troduced at the client’s OCSP validation process. Even though obtained results wereaffected by external factors (the throughput of the OCSP validation service beingaccessed, the WSRF Container, and OGRO itself—policy parsing) we believe thatgeneral conclusions about the overall advantages of the prevalidation mechanismwere not influenced by them and moreover future work will be aimed to enhance


performance by using new algorithms (i.e. use of precomputed OCSP Responsesin CertiVeR and inclusion of an OCSP cache in OGRO) and cryptographic hard-ware.

We expect that the use of OCSP in Grids will be very common in the near fu-ture. In consequence, the practical experience that the Grid community will ac-quire with software like OGRO and services like CertiVeR may prove very use-ful in building OCSP architectures fully optimized for such environments. Currentresearch on Grid OCSP in general and the CertiVeR-OGRO-GT4 architecture inparticular, will continue over topics like future uses of OCSP extensions as wehave also begun a new research line using the concepts of prevalidation and theOGRO API to build the Unified AAI introduced in [7], by conveying not only theOCSP Response but also Authorization information into the Proxy Certificate’s ex-tensions.

Finally it is worth to highlight that OGRO is in the process of being integratedinto the next release of the Globus Toolkit, which may bring further improvements asa result of the Grid community’s testing and comments.

References

1. Alfieri R, et al (2004) VOMS: an authorization system for virtual organizations. In: 1st Europeanacross grids conference, ISBN 978-3-540-21048-1. LNCS, vol 2970. Springer, New York, pp 33–40

2. Ascertia’s OCSP Client Tool (2006) http://www.ascertia.com/products/ocsptool/3. CertiVeR: Certificate Revocation and Validation Service (2006) http://www.certiver.com4. Housley R, et al (2002) Internet X.509 public key infrastructure, certificate and certificate revocation

list (CRL) profile. Request for Comments 3280. RSA Laboratories, USA, April 2002.5. Myers M, et al (1999) X.509 Internet public key infrastructure, online certificate status protocol

(OCSP). Request for comments 2560. VeriSign, USA, June 19996. Lorch M, Kafura D (2003) The PRIMA grid authorization system. In: 4th International workshop on

grid computing. IEEE Computer Society Press, Los Alamitos7. Luna J, Manso O, Medina M (2005) Towards a unified authentication and authorization infrastructure

for Grid services: implementing an enhanced OCSP Service Provider into GT4. In: Chadwick D,Zhao G (eds) Proceedings of 2nd EuroPKI 2005 workshop, ISBN 978-3-540-28062-0. LNCS, vol3545. Springer, New York, pp 36–54

8. Luna J, et al (2006) OCSP Requirements for Grids. https://forge.gridforum.org/sf/go/doc4852?nav=19. OGRO: The Open GRid Ocsp client API (2006) http://grid-globus.certiver.com/info/ogro

10. Pearlman L, et al (2002) A community authorization service for group collaboration. In: IEEE 3rdinternational workshop on policies for distributed systems and networks. IEEE Computer SocietyPress, Los Alamitos

11. Public Key Infrastructure (PKI) Enhancements for J2SE 5 (2006) http://java.sun.com/j2se/1.5.0/docs/guide/security/pki-tiger.htmlSun JCE

12. The Globus Toolkit 4 (2006) http://www.globus.org13. The IAIK Java Cryptography Extensions (2006) http://jce.iaik.tugraz.at/sic/products/core_crypto_

toolkits/jca_jce14. The Legion of Bouncy Castle (2006) http://www.bouncycastle.org/15. The OpenSSL software (2006) http://www.openssl.org16. The Openvalidation service (2006) http://www.openvalidation.org17. Tuecke S, et al (2004) Internet X.509 Public Key Infrastructure, Proxy Certificate Profile. Request for

Comments 382018. Von Laszewski G, et al (2001) A Java Commodity Grid Kit. Concurr Comput Pract Exp 13(8–9):643–

66219. Vollbrecht J, et al (2000) AAA authorization framework. Request for comments 2904. InterLink Net-

works, USA

266 J. Luna et al.

Jesus Luna México, 1972. MSc in Computer Science, Instituto Tecnológico yde Estudios Superiores de Monterrey, Mexico City, 2001. Currently he is study-ing a PhD in Computer Architecture at the Universitat Politècnica de Catalunya(Barcelona, Spain). Mr. Luna actively participates with the GGF’s CAOPS-WG,and his research interests are PKI, Grid security and applied cryptography.

Manel Medina Barcelona, 1952. PhD in Computer Architecture, UniversitatPolitècnica de Catalunya, Barcelona, 1981. He was co-editor of the EuropeanElectronic Signature Standarization Initiative (EESSI) and has participated innumerous security related projects (i.e. DEDICA-IST, CertiVeR-TEN Telecom,PERMIS-IST. ICE-ESPRIT and VINo-e CPPC). Currently is full time professorat the Universitat Politècnica de Catalunya, esCERT CTO and SafeLayer CTO,Barcelona, Spain.

Oscar Manso Barcelona, 1968. PhD in Computer Science, Dublin City Univer-sity, Republic of Ireland, 1999. Technical Director of CertiVeR S.L., Barcelona,Spain. Part-time lecturer at the Dept. of Computer Architecture of UniversitatPolitècnica de Catalunya. Collaborates with the GGF’s CAOPS-WG and TF-EMC2 from TERENA. His current research interests are focused on the devel-opment of new applications for e-signature and PKI infrastructures.

Using OGRO and CertiVeR to Improve OCSP Validation for Grids

Documents

Transcript of Using OGRO and CertiVeR to Improve OCSP Validation for Grids