Abstract— Nowadays the computational Grid uses X.509 digital certificates for a wide variety of security-related tasks, ranging from user authentication to job execution’s delegation. However to ensure a comprehensive security framework such credentials need to be validated so that revoked, suspended and any other compromised certificate will not be allowed to access Grid resources. To achieve such tasks great interest is being given to the Online Certificate Status Protocol (OCSP) in security workgroups from the Global Grid Forum. In order to better understand the special requirements related with its use in previous work we introduced the Open GRid Ocsp API (OGRO), which provides OCSP support to the Globus Toolkit 4. However that research concluded that the Grid introduces some special requisites for OCSP’s performance and security. As a follow-up to that work, this paper provides a comprehensive performance comparison between the novel Prevalidation and Caching mechanisms proposed by the authors to further improve Grid-OCSP. In addition, research about security compliance of both mechanisms around the newest Proxy Revocation concept is also presented in this work.

I. INTRODUCTION

Security in Grid environments is based on the distribution and use of electronic credentials – e.g. digital certificates. The presentation of a credential by a user grants access to the system only if the user is authorized to do the operation being requested. In order to do so, the system will verify the credential and also the purpose by which such credential was given. However, this mechanism is not enough to ensure complete security. If a higher level of security has to be reached, then the system should also validate the credential. Validation is the process of verifying that the credential (i.e. an X.509 digital certificate) has not been reported by a user as stolen, lost or compromised in any other way. Several mechanisms implementing certificate validation are available, and historically most distributed systems in general and the computational Grid in particular have been using Certificate Revocation Lists (CRLs) to manage such information since its beginnings. However CRL distribution and maintenance in the Grid has proven difficult for practical reasons mainly related with the need to maintain up-to-date sets of CRLs from a number of different certification authorities, at each

and evmechanenvironis the Osimple “relyinOCSP implemable toalong wand spdetailedWorkgRequirerecomm(OGROthe Glovalidati(GVP).an OCCertiVevalidatirelyingvalidatiGT4’s OCSP mechanclients CertiVejust bethe Proto perfavoidintime agthe lasWG, tfurther real Grsimilarview of

OCSP for Grids: Compaversus Cac

Jesus Luna1, Oscar Manso2, MComputer Architecture Department, Polytech

Jordi Girona 1-3, Building D6. 08031jluna@ac.upc.e2omanso@ac.upc.3medina@ac.upc.

11-4244-0344-8/06/$20.00 2006 IEEE

ery computer that is part of the Grid. Nowadays, a ism which is becoming quite popular in these ments due to its near-real time validation capabilities nline Certificate Status Protocol (OCSP) [1]. This is a query protocol that relieves its clients –also called

g parties”- of the burden of managing CRLs; also the protocol is flexible and extensible, allowing the entation of certificate validation services for Grids report more than just the CRL’s contents However, ith its advantages OCSP also conveys great challenges

ecial requirements, most of which are already being by the Global Grid Forum’s CA Operations

roup (CAOPS-WG) in the document “OCSP ments for Grids” [2]. Based on this set of endations, we developed the Open GRid Ocsp ) Java API [3], which implements OCSP support for bus Toolkit 4 –GT4- [4] with a customizable set of on rules through the so-called Grid Validation Policy OGRO was introduced in [5] as part of a proposal for SP validation infrastructure for GT4, based also in R’s OCSP Responder [6]. That paper showed that the on overhead introduced by OCSP was very high when parties were required to perform several concurrent on checks per Grid Service being invoked from the WSRF Container. Further research to optimize Grid performance took us to propose the prevalidation ism in [7], which consisted of OGRO-enabled Grid embedding the OCSP Response received from

R as a non-critical extension of the Proxy certificate fore its creation. In this way, at the time of validating xy Certificate Path, relying parties only were required orm some security checks on such prevalidation data g the need to execute the whole OCSP process on real ain. However according to the experience gained in

t few months from our participation in the CAOPS-he prevalidation mechanism was not only needing performance improvement before being introduced to

id environments, but also required to be compared with solutions and even to be analyzed under the point of new Grid-OCSP security requirements.

ring Prevalidation hing

anel Medina3

nical University of Catalonia 5. Barcelona, Spain. du

edu

edu

Grid Computing Conference 2006

This paper presents our research and results on comparing OGRO’s prevalidation mechanism with the OCSP Response’s caching solution, both implemented over the GT4’s WSRF container. Moreover, we introduce a security analysis of both solutions related with the Proxy Certificate Revocation and the Cautionary Period of the response, concepts which have raised a lot of controversy these last few months at the CAOPS-WG.

The rest of this paper is organized in the following way: section 2 provides an overview on CertiVeR and OGRO, the cornerstones of our Grid-OCSP architecture. Later in section 3 the prevalidation and caching mechanisms are explained in further detail, so section 4 may compare both approaches from the performance and security point of view. In section 5 the state of the art is presented, and finally section 6 summarizes our conclusions and future work.

II. A QUICK REVIEW ON CERTIVER AND OGROIn this section we will review an OCSP Service based in a

tailored version of the CertiVeR system which took into account the recommendations given the CAOPS-WG. Also will be summarized the basic concepts of our Open GRid Ocsp API –OGRO-, which is a cornerstone of the “Unified Authentication and Authorization Infrastructure” proposed in [5]. Both CertiVeR and OGRO provide the Grid-OCSP architecture upon which the research and results reported in this paper were based.

A. CertiVeRCertiVeR [6] is an EU funded project that offers a real time

X.509 certificate status service through OCSP; moreover it is also compliant with the GGF recommendation being documented in [2] in such a way that it can be be used in the computational Grid as a Trusted or Authorized OCSP Responder. CertiVeR implements a CRL Updater module, which is in charge of retrieving revocation information directly from the CA’s CRL through protocols like LDAP and HTTP. This information is stored in a local cache at the Responder. A DeltaCRL connector has also been developed, which is used by the CRL Updater modules to remotely push any new revocation information from the remote CA into the local cache, thus providing up-to-date data for Grid clients. Through a customizable set of extensions for the OCSP response, CertiVeR can report information at several levels -i.e. technological or commercial-,.dramatically increasing security and e-Trust for Grid relying parties.

B. OGRO: an open source OCSP client for the Globus Toolkit 4

In previous work [5] we introduced the idea of an enhanced OCSP client for the Globus Toolkit 4, able to use CertiVeR for End-Entity certificate’s OCSP path validation and also to request authorization information in OCSP extensions from such service. This client has evolved since then, taken several of the recommendation of the CAOPS-WG and now it has been published as open source with the name of OGRO -Open

GRid OOGROGrid KJava cOCSP providebeing m

OGRrules -wGVP, wconcordGVP, iexplainfeaturevalidaticustomCertificthat is,referenof confrepreseparties’configuthat pofits thepaper performProxy credentto job e

The OCSP implemand effthe cac

A. TheWhe

relyingoverall[11]) aDigitalcases vCRLs creatingrelyingauthorithe relvalidatiit (i.e. mechancan be prevaliRespon

2

CSP– [3]. By being Open Source and 100% Java, has been fully integrated into the Java Commodity it [8] and the WSRF Grid Services Container - GT4’s ore-. The OGRO API does not implement its own client classes, instead it relies upon well known JCE rs (current version uses Bouncy Castle [9], but it is odified to support also IAIK [10] in the next release). O’s main contribution for Grids is the use of a set of ritten in XML- called the Grid Validation Policy or hich customizes relying parties’ OCSP behavior in ance with the recommendations given in [2]. The

ts structure –DTD- and rules have been thoughtfully ed in [7] so we will only review some important s in the rest of this section. The GVP allows per issuer on rules (i.e. available revocation sources and a izable “Unknown” status meaning for Proxy ates) or even the option to configure a default issuer,

rules applying to any user with their issuer not being ced anywhere else in the policy. More than being a set iguration directives, OGRO’s Grid Validation Policy nts a mechanism that contributes to enhancing relying security level. Also in [7] we compared different rations of the Grid Validation Policy, in such a way tential users would be able to choose the one that best ir security needs. One important conclusion of that

was the strong need of improving OCSP validation ance at Grid relying parties (i.e. clients creating a Certificate and WSRF servers validating that

ial), so its utilization does not convey a high overhead xecution. next section presents two mechanisms related with the Response management, which have been already ented into OGRO to help achieving a secure, flexible icient OCSP validation solution: the prevalidation and hing.

III. PREVALIDATION AND CACHING

prevalidation mechanism n we first faced the challenge of improving Grid parties’ OCSP performance without affecting its security, the authorization push model (RFC2904 nd the validation data used in the XML Advanced Signature –XAdES- [12] came to our mind. In both alidation information (attributes in the push model and in XAdES) is included along the data itself, thus a self-contained package able to be validated by

parties without further contacting the source of ty (i.e. the Attribute repository). In most of the cases ying party only requires to extract the embedded on data, perform some cryptographic verification over authenticity and integrity) and finally parse it. With isms like these, important performance improvements obtained in the validation process. In the case of our

dation mechanism, what if we embed the OCSP se itself into the Proxy Certificate? The rationale

behind this is very simple given the fact that such a message is authenticated (digitally signed by the OCSP Responder which is a trusted third party), tamper protected (again thanks to the digital signature) and includes a validity period. OGRO and its Grid Validation Policy implement prevalidation support into both, the GT4’s WSRF Container and the Commodity Grid Kit. To validate an End Entity Certificate with the prevalidation mechanism, the following procedure is performed by OGRO:

1) When creating a Proxy Certificate, the OGRO-enabled Grid client requests OCSP Validation for its whole Certificate Path to CertiVeR using the one-message mechanism (only one OCSP Request is created for the complete chain). Note that even though this OCSP Request is digitally signed, it does not require including a nonce because in any case it will not be verified later by the relying party.

2) As soon as the OCSP Response is received from CertiVeR, it is validated and embedded as a Proxy Certificate’s X.509 extension (identified under a specific OID).

3) The OGRO-enabled Grid client invokes a Grid Service from the WSRF Container using the Secure Messaging mechanism, in such a way that an XML message -digitally signed by the prevalidated Proxy- is created.

4) The OGRO-enabled Grid Services WSRF Container extracts the prevalidation information from the Proxy Certificate, then performs the OCSP Response’s security checks defined in RFC2560 (digital signature, trust level, etc.) and finally validates the Proxy Certificate Path according to the statuses already included into such OCSP Response.

B. Caching OCSP Responses One of the recommendations given in [2] refers to caching

the OCSP Responses for enhancing validation performance. Such a cache can be extended to several levels of the Grid infrastructure to achieve this goal: a first-level cache at the Grid client, at second-level cache at the Grid server (i.e. the WSRF container) and a third-level cache at the local OCSP Server. Using such a cache hierarchy it is possible to reduce not only the cryptographic and communications overhead caused by the interaction with the global OCSP Responder, but also the total number of queries made to the server – this last aspect can also result in economic advantages considering that some OCSP providers sell their service on a per-request basis. When further considering the idea behind the OCSP cache hierarchy, we expected that second-level caching would provide the best cost-benefit and secure solution for Grids. This is due to the fact that in most Grids installations it is reasonable to think that first-level caches 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 create not only bottlenecks with all the Grid servers contacting them (local Responders are not expected to be

highly Responsensiblcaches.validatisteps:

1) The way (it

2) Cachthe OGMessagResponEnd Ereceivelocal ca

3) Cachimplyincachingwill usOne ofOGROavoid ostatus fmiss, ththe newfrom th

4) The so stale2560’s Responi.e. thperman

Nextobtainealong wCertific

IV

A. PerWith

secondTrustedGHz, http://gOracle neitherResponof 5 dimodifiecredentcapabil

3

scalable or fault-tolerant in contraposition to a Trusted der serving several domains), but also might be more e to network failures than first- and second-level The latest version of OGRO implements OCSP on with second-level caches through the following

Grid client creates its Proxy Certificate in the usual does not require OGRO).

e initialization: When a Grid Service is requested from RO-enabled WSRF container (also through the Secure ing mechanism as with prevalidation), the OCSP der is contacted to request validation for the whole ntity certificate chain. As soon as the Grid server s the OCSP Response, it is verified and stored into a che.

e searching: Client connections to the Grid server g a cache-search (OGRO can be configured to enable only for certain Certification Authorities hierarchies)

e the native lookup methods from such data structure. the following will occur i) In case of a cache hit, then retrieves the stored OCSP Response, verifies it (to utdated entries) and finally obtains the correspondent or the whole certificate chain or ii) In case of a cache e appropriate OCSP Responder will be contacted and Response stored into the cache, so subsequent calls

e same user will result in a cache hit.

cache is being frequently purged by a separate thread, entries (outdated OCSP Responses according to RFC verification method) are removed when detected.

ses reporting an invalid End-Entity Certificate Chain –ose with at least one revoked certificate- are ently stored. , this paper will provide a comparison of the results d with the prevalidation and the caching mechanisms, ith a security analysis of both related with the Proxy ate Revocation problem.

. A COMPARISON ON PERFORMANCE AND PROXYCERTIFICATE REVOCATION

formance results the purpose of comparing OGRO’s prevalidation and -level caching mechanisms, a CertiVeR’s OCSP Responder (server with one Xeon processor @2.9

1.5 Gb RAM and Windows 2000) was set up at lobus-grid.certiver.com. The Responder was using an database to store the revocation information, but

cryptographic hardware nor precomputed OCSP ses were utilized. For the Grid clients we created a set fferent End-Entity Certificates and set up 50 OGRO-d Commodity Grid Kit installations with such ials (same certificate for each 10 clients to test caching ities). The underlying hardware was composed of a 4-

Xeon processors server running over RedHat Linux 7.2. Finally a GT4 WSRF Container was also integrated with OGRO and installed on a 2-Xeon processors server running over RedHat Linux 7.2.

Each one of the three tests reported in this section consisted of concurrently run 50 clients to request the same Grid Service from the WSRF Container through the Secure Messaging mechanism, in such a way that OCSP Validation could be triggered according to the applicable Grid Validation Policy –GVP- shown in. table I (see [7] for a further explanation on GVPs creation).

TABLE ITHE GRID VALIDATION POLICIES BEING TESTED

GridValidation

Policy

Explanation

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

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

Prevalidated Prevalidation support enabled so the WSRF Container never has to contact the OCSP Responder.

The results obtained from our tests are shown in figure 1, where the total GVP performance is computed as the addition of i) the time required by the WSRF Container to perform the OCSP call (when applicable) and ii) the time to cryptographically verify and parse the OCSP Response (for second-level caching it is the time to read the certificate’s status from the in-memory cache, while for the prevalidation

will befrom th

As wOCSP”processfact thecreatedthe Wvalidatithe crythe recpeaks afrom 5 on the paper.

On tthe 8th somethmemorperformsuch caoverallno longcache. microsecontrolenhancfor imp

Finamechanthe higrequirefound

G rid O C S P : P re v a lid a tio n v

0

1 0 0 0

2 0 0 0

1 3 5 7 9 1 1 1 3 1 5 1 7 1 9 2 1 2 3 2 5 2

G T 4 W S R F R e

Tim

e (m

s)

T o ta l O C S P T o ta l c a ch

Fig. 1. Grid-OCSP performance comparison: P

4

the time required to extract and verify the OCSP data e Proxy certificate).. e can see from figure 1, the use of plain OCSP -“Total graph- conveys the highest overhead for the validation , something already concluded in previous work [5]. In peaks observed during this test are due to bottlenecks at the OCSP Responder when several instances from SRF’s OGRO API are concurrently requesting on, and afterwards when the container itself performs ptographic verification and parsing over each one of eived OCSP Responses. The observed performance re repeated in almost regular intervals comprehending to 7 WSRF requests. This behaviour is only dependent service and therefore, it is not a subject of study for this

he other hand, the “Total Cache” test shows that before call it behaves almost like the “Total OCSP” graph, ing that even though was expected -because the in-y cache is still being filled- also corresponded with the ance peak observed in the first test. However once che contains the statuses for all the EECs, then the

performance greatly improves as the OCSP Server is er required to retrieve the status from the in-memory The latter operation requires a few tenths of conds due to the performance and concurrency-

mechanisms of the underlying OGRO API; a future ement may provide a more scalable database approach lementing the OCSP cache. lly, the results obtained with the prevalidation ism (the “Total prevalidated” graph) do not involve h peaks from the two previous tests, because it never d to contact the OCSP Server. On the other hand, we some others peaks in the graph and, maybe more

s C a c h in g

7 2 9 3 1 3 3 3 5 3 7 3 9 4 1 4 3 4 5 4 7 4 9

q u e s t

e T o ta l p re va lid a te d

revalidation versus Caching.

surprisingly, a slightly worse performance than with the second-level cache mechanism–once it has been filled-. This behaviour is due to the fact that cached EEC’s statuses are directly accessed from an in-memory data structure, while prevalidation data must be extracted from Proxy Certificates read from network sockets -thus requiring more system calls to the underlying system- while also requirying cryptographic validation.

B. Proxy Certificate revocation support Proxy Certificates were intended to be short term

cryptographic credentials. This is the case in most situations. However, as noted in the CAOPS-WG, there are some particular situations where Proxy certificates can have long lifetimes or they are created for future use in batch queues. Security and system administrators have discussed a number of scenarios where revoking a Proxy Certificates might be useful [2]:

A long-running job, that in turn creates many jobs in other domains needs to be cancelled because maybe its results are not good, it exceeds resource limits, or other problems identified by the job owner or the resource manager warrant termination. Part of the job clean-up and recovery would include revoking Proxy Certificates in use to prevent orphaned processes from running across domain boundaries. A system that is used as one component of a complex

job is compromised. Instead of aborting the whole job and losing all the results, only the components affected by the compromised system are stopped. A resource owner who does not want a particular

process to be run at a certain moment. Rather than blacklisting the user, assigning a low-level priority to such a process or damaging the application, the resource owner can temporally blacklist (“suspend” in OCSP language) the delegated Proxy Certificate. A compromised system holding a large number of

proxy certificates that could have been captured by an attacker need to be revoked to avoid its malicious use anywhere in the system.

Based on the above arguments, we want to discuss in this section both approaches (the prevalidation and the second-level caches) to study how these alternatives can fulfill and even relieve the security and functional requirements of such a complex topic. This study will be developed at two different phases: the request of a Proxy Certificate status through OCSP and the revocation of a Proxy Certificate.

1) Requesting the Proxy Certificate Path status: In first place let us suppose a scenario where the prevalidation process is performed, but with a subtle modification from the original version explained in section 3.1: when the Proxy Certificate is being created (let us call it P), then it is sent along with its full Certificate Path to the OCSP Responder -which is able to register P status- for prevalidation. In this case we must notice that a “new” Proxy Certificate P’ will be created back at the

Grid clX.509 subject“registeits statissue hprevalitopic wa cautio

TherCertificsimilarsame hwill reqthe Grprevalisecondretrievathe OCContain

2) Revois revowith thmeans throughproblemwith threvocatother dof keepfor quialleviatembeddlevel cais not entries OCSP”known guaranta time OCSP provideresponsstatus (the timavailab(the timIf nextUrevocatfield ishas beeintervalarge -nextUp

5

ient with such prevalidation data, but keeping the same information already present in P (i.e. public key,

DN, etc.). Afterwards the Grid client only has to r” P’ so the OCSP Responder may be able to provide

us to interested parties afterwards. A critical security ere is that P’ must be registered before the embedded dation data’s expiration. A further discussion on this ill be presented in the next section, where the notion of nary period is introduced. efore it is feasible to think that when querying Proxy ate’s status, the Prevalidation mechanism offers a

security level than traditional OCSP. Obviously the olds true for the second-level cache mechanism, which uest and store the OCSP Response exactly “as is” on

id server. There is, however, an advantage of the dation mechanism over the traditional OCSP and the -level cache solutions: prevalidated data allows for the l of a Proxy Certificate status even in situations where SP Responder is not accessible from the WSRF er domain (i.e. due to network failures).

king the Proxy Certificate: When a Proxy Certificate ked there are several issues to solve, mainly related e entity authorized to perform such process and the by which this revocation information is propagated the Grid. For our purposes only the propagation will be considered, as OCSP by itself is not related e mechanisms to authorize and perform the Proxy ion. If the revocation information is not propagated to omains in a promptly way, then there is the latent risk ing jobs running under the compromised Proxy control te a time. The prevalidation mechanism is unable to e this problem, because the prevalidated data is ed into the revoked Proxy itself. As for the second-che, a pretty similar problem may arise if and only if it being refreshed or purged constantly. Stale cache will represent always a security risk. The “traditional approach answers the last Proxy Certificate status

by the OCSP Responder, however there is no ee that such status is the very last, as there is obviously required to propagate any update through the whole infrastructure. The “traditional OCSP” currently can three timestamps characterizing the revocation e [1]. These are thisUpdate (the time at which the

being indicated is known to be correct), nextUpdate e at or before which, newer information will be

le about the status of the certificate) and producedAt e at which the OCSP responder signed this response). pdate is not set, the responder is indicating that newer

ion information is available all the time. Whenever this set, it is an indicator that the revocation information n retrieved from a CRL being released only at certain

ls of time. In certain cases, this interval may be quite even in the order of days-. Both thisUpdate and date are from the underlying CRL timestamps.

Taking into account these parameters, we propose the use of a “cautionary period” able to alleviate the uncertainty introduced by the time to propagate revocation information: Definition 1. We denote as “cautionary period” the interval

of time during which relying parties assume a degree of uncertainly about the Proxy Certificate’s status being reported by the OCSP Responder.

.Given the fact that OCSP servers producing pre-computed responses (which fix a producedAt value for that response very close to thisUpdate and with not relation to the time at which the Request is being done by the OCSP client) have the potential to confuse relying parties when evaluating the cautionary period, a new timestamp called receivedAt is introduced to specify the moment when relying parties are receiving the OCSP Response. In terms of the mechanisms introduced in this paper, receivedAt is given by:

For prevalidation receivedAtWSRF, which denotes the time at which the Grid client’s (service invoker) Proxy Certificate is being validated.

For the second-level caching mechanism cacheHit, denoting the time at which the cached OCSP Response is being found and retrieved.

In this way, the cautionary period is given by the following interval:

[ thisUpdate , receivedAt,] (1)

The longer such cautionary period is, the less precision resulted in the OCSP response being provided. This factor is a measure of the risk level that the relying party is willing to

take wRespondiscardgreater

SuppimplemlibrarieBouncycomme[15]. Oprovidecomputimplem

Tablintroduimplemtwo cliClient)comprerequirecomparFrom scontribpubliclOCSP CAOPSValidatimplemCertific

TABLE IICOMPARING OGRO WITH OTHER OCSP

Grid-OCSPRequirement

J2SE5 Bouncy Castle

IAIK

Transport HTTP/HTTPS Both Both Both Revocation Source Requirements

AIA, OCSP, CRL

No No C

Use of nonce Not specified Yes Yes Error Handlers First AIA, if

not present OCSP.

Fallback to CRL.

No No

Unknown Status Management

No No No

OCSP Request Signing Not specified Yes Yes Flexible Configuration

Some default parameters configured into JCE.

No No

Prevalidation/Caching No No No

6

hen accepting the result status coming from an OCSP se as is..Relying party’s validation middleware should OCSP Responses conveying a cautionary period than the one specified in the validation policy.

V. RELATED WORK

ort for OCSP in relying parties’ software has been ented in several flavors, ranging from programming s like OpenSSL [13], SUN’s J2SE5 [14], Castle [9] and IAIK [10] to embedded features in rcial browsers and fully functional stand-alone clients GRO was built upon publicly available Java APIs to a set of particular features required by the ational Grid, which were not offered “as is” by such entations. e II shows a comparison -relative to the requirements ced in [2]- between OGRO, three well known JCEs -ented into SUN’s J2SE, BouncyCastle and IAIK- and ent implementations (OpenSSL and Ascertia’s OCSP , which according to our research integrate a set of hensive OCSP features pretty close to Grid ments. Notice that also all the implementations ed in table II do not support caching or prevalidation. uch table it is also easy to conclude that OGRO’s main ution to the computational Grid is to be the first y available API, which implements the full set of relying party requirements identified by the GGF’s -WG. Thanks to the flexibility added with the Grid

ion Policy, we think that OGRO is prepared to ent future Grid-OCSP requirements (i.e. Proxy ate Revocation).

APIS AND CLIENTS

OpenSSL client

Ascertia OCSP Client

OGRO

Both Both Both RL/OCSP AIA, OCSP.

Keeps list of Trusted

Responders

AIA, OCSP, CRL. Query order in Grid Val Policy

(GVP).Yes Yes Yes

Cautionary Period-like mechanism

No Query whole GVP’s Rev.

source list N-times. Set final status if failed.

No No Yes

Yes Yes Yes Configura-

tion File for default

params.

GUI configurator for default parameters.

Flexible ruleset with GVP.

No No Prevalidation; first- and second-

level caches

Related to the prevalidation and caching mechanisms is the Client Partially Cached OCSP (CPC-OCSP), introduced in [16] as a method to improve client-side OCSP. CPC-OCSP is a way to improve system’s OCSP efficiency by means of a small cache in the client (initially developed for wireless devices). The cache stores some of the responses the device has previously received, so that these can be later updated at low cost. In this way it is possible to save resources in the validation process, something critical for wireless environments and the computational Grid, as we have explained before. The basic idea behind CPC-OCSP is to first generate a secret nonce number 0R . The Responder creates afterwards a hash chain by applying d+1 subsequent hash functions, h over 0R . The final value )( 0

1 RhR d is signed by the Responder and sent to the client together with the OCSP Response. At time it , to sign a Response, the OCSP Responder send to the client an intermediate value, iR( di0 ), which is calculated by applying d+1-i times the hash function h over 0R : )( 0

1 RhR idi . The relying party

can verify iR by applying i times the hash function h over

iR and compare if the value of R calculated is the same as the value made public initially. In this way, the client caches some of the signed responses the device has previously received and that contains the parameter R, so that the responses can be updated later at a lower cost.

The following evaluation parameters were introduced in [16] by the authors:

I: Size of the target certificate identifier (serial number). S: OCSP Responder Signature size.

: Percentage of CPC-OCSP Responses with the update parameter iR .H: Size of the hash value.

hasht : processing time needed by the relying party to perform a hash function.

publickt _ : processing time needed by the relying party to verify the OCSP Response’s signature.

Using these parameters, table III compares the OCSP Response size and the relying party’s computational cost for the traditional OCSP, prevalidation, second-level caching and the CPC-OCSP mechanisms.

From table III it is possible to deduce several important issues. In first place the “traditional OCSP” conveys always the biggest OCSP Response and computational cost for the Grid Server. On the other hand, both the prevalidation and second-level caching mechanisms behave like traditional OCSP when prevalidated or cached validation data is determined to be invalid. This was expected as in those cases the relying party must contact again the OCSP Responder to validate the Grid client’s credentials. We have to highlight that CPC-OCSP in general implies smaller OCSP Responses and computational costs, in particular when the cached Response is never updated (an ideal case where =1). We

considecachedthe cauinterestcachingresearc

COMP

Revon sys

TraditOCSP

Prevation

Seconlevel c

CPC-OCSP

In this two mperformprevaliCertificoverheaserver. should able toenoughlifetimesystem

Cachin this computimplemperformseries performwhen inThe rescan be secondwith en

Futuinto opaccordicome-,

7

r that CPC-OCSP is suitable to extend the lifetime of a OCSP Response beyond NextUpdate, but preserving tionary period defined in the validation policy. An ing idea about combining any of the prevalidation or mechanisms with CPC-OCSP is introduced as future

h in the following section.

TABLE IIIARING PREVALIDATION, SECOND-LEVEL CACHING AND CPC-OCSPcatiotem

OCSP Response size Computa-tional cost

(relyingparty)

ional I+S publickt _

lida-caseotherany0

invaliddataionPrevalidatiifSI publickt _ iif

Prevalidation data invalid

d-ache caseotherany0

invaliddatacachediifSI publickt _ iif

cached data invalid

HHSI )2)(1(hash

publick

t

t _)1(

VI. FUTURE WORK AND CONCLUSIONS

paper we have compared prevalidation and caching, echanisms capable of improving OCSP validation ance in Grid environments. When using the novel

dation, the OCSP Request is embedded into the Proxy ate as an X.509 extension in such a way that the d introduced by traditional OCSP is relieved from the Despite its advantages, the prevalidation mechanism be avoided when using a high-quality OCSP Service - produce responses with a cautionary period short to require several validations during a Proxy’s - in order to not reduce the quality of the overall

. ing OCSP Responses is another useful mechanism and

paper we have contributed with a new concept for the ational Grid: “second-level OCSP caches” ented into the Grid server itself, where optimal ances can be achieved according to our research. A of tests has been undertaken to compare the ance of both, prevalidation and second-level caches tegrated into the Globus Toolkit 4’s WSRF Container. ults have shown that a sustained validation throughput obtained with the prevalidation mechanism, however

-level caching behaves better once it has been filled ough OCSP data so cache misses are infrequent. re enhancements in OGRO will be focused not only timizing both implementations for production Grids -ng to the experience obtained from large scale tests to but also in exploring new “hybrid” mechanisms able to

combine the best of both worlds: prevalidation and caching. In the meantime a definite factor in choosing prevalidation or caching in relying parties will be introduced by the security needs of new Grid-OCSP requirements -in particular Proxy Certificate revocation-

A first security analysis has been summarized in this paper and we conclude that referring to Proxy Certificate status’ retrieval, even though the prevalidation and caching offer similar security features, the prevalidated Proxy data transverses domains where OCSP Responses can not. On the other hand, when propagating a Proxy Certificate revocation through the OCSP network it is very likely that even “traditional OCSP” may fail to obtain the current status, thus provoking a sensible security risk. To alleviate this problem, another contribution of this paper refers to introducing the notion of a “cautionary period“ into both prevalidation and second-level caches, which may be implemented into OGRO’s Grid Validation Policy thus enabling relying parties to take validation decisions based on a risk level previously defined. In other words, for the three OCSP mechanisms compared in this paper, the use of a cautionary period may provide a consistent way to deal with the security issues associated with the delays introduced when propagating the revocation information through the VOs.

We have also presented a comparison with the CPC-OCSP mechanism. We conclude that if CPC-OCSP’s ability to “extend” OCSP Response’s lifetime is combined with our cautionary period notion from the prevalidation and second-level caching mechanisms, then up-to-date validation information can be used into the Grid at a low computational cost. Important advantages may be expected for the relying parties, especially when Proxy Revocation becomes a reality in the computational Grid. Upcoming research about this topic can be expected in the following months.

Additional future work with OGRO will provide performance issues related with Proxy Certificate revocation, a topic widely discussed at the GGF’s CAOPS-WG and even though there is a general agreement about its usefulness, it is true that the lack of real-world experience may delay related Grid middleware implementations in the short-term. We expect to contribute with new research around this topic at both GGF’s Authentication and Authorization workgroups for upcoming projects like the “Grid Credential Validation System” [17], also by implementing a “trust evaluation” on the Proxy Certificate according to the methodology introduced in [18].

REFERENCES

[1] “RFC 2560: X.509 Internet Public Key Infrastructure, Online Certificate Status Protocol”. Myers M, et. al. June 1999.

[2] “OCSP Requirements for Grids”. Global Grid Forum, CA Operations Work Group. Working Document. May 2005. https://forge.gridforum.org/projects/caops-wg

[3] “OGRO - The Open GRid Ocsp client API”. June 2006. http://globus-grid.certiver.com/info/ogro

[4] “The Globus Toolkit 4”. June 2006. http://www.globus.org [5] “Towards a Unified Authentication and Authorization Infrastructure for

Grid Services: Implementing an enhanced OCSP Service Provider into

GTProJuly

[6] “Cehttp

[7] “UsLunConCom

[8] "A GawExp

[9] “Thhttp

[10] “Thandhttp

[11] “RFAu

[12] “ETEleDec

[13] “Th[14] “Pu

Michttp

[15] “Ashttp

[16] “CPJL.Dec

[17] “AGGuni

[18] “AnPubWoSci

8

4”. Luna J., Manso O., Manel M. 2nd EuroPKI 2005 Workshop. ceedings by Springer in Lecture Notes in Computer Science series. 2005. http://sec.cs.kent.ac.uk/europki2005/ rtiVeR: Certificate Revocation and Validation Service”. June 2006. ://www.certiver.com/ ing OGRO and CertiVeR to improve OCSP validation for Grids”. a J., Manso O., Manel M. Accepted for the 1st Grid and Pervasive ference (GPC2006). Proceedings by Springer in Lecture Notes in puter Science series. May 2006. http://hpc.csie.thu.edu.tw/gpc2006/

Java Commodity Grid Kit" Gregor von Laszewski, Ian Foster, Jarek or, and Peter Lane, Concurrency and Computation: Practice and

erience, vol. 13, no. 8-9, pp. 643-662, 2001, http:/www.cogkit.org/e Legion of Bouncy Castle”. June 2006. ://www.bouncycastle.org/ e IAIK Java Cryptography Extensions”. Stiftung Secure Information Communication Technologies SIC. June 2006. ://jce.iaik.tugraz.at/sic/products/core_crypto_toolkits/jca_jce C 2904: AAA Authorization Framework”. Vollbrecht J, et. al.

gust 2000. SI TS 101 733: Electronic Signatures and Infrastructures (ESI);

ctronic Signature Formats”. ETSI ESI group. Version 1.5.1, ember 2003. http://portal.etsi.org/esi/el-sign.aspe OpenSSL software”. June 2006. http://www.openssl.org blic Key Infrastructure (PKI) Enhancements for J2SE 5”. SUN rosystems. June 2006. ://java.sun.com/j2se/1.5.0/docs/guide/security/pki-tiger.html certia’s OCSP Client Tool”. June 2006. ://www.ascertia.com/products/ocsptool/ C-OCSP: an adaption of OCSP for m-Commerce”. Munoz-Tapia,

Forne-Munoz, J. Upgrade Magazine, vol III, no. 6, pp: 22-26, ember 2002. uthorisation in Grids” Chadwick, David. OGSA-AUTHZ Meeting at F16. February 2006. http://www-x.gridforum.org/mail_archive/ogsa-authz/2006/02/ppt00000.ppt Innovative Policy-Based Cross Certification Methodology for lic Key Infrastructures”. Casola V, et. al. 2nd EuroPKI 2005 rkshop. Proceedings by Springer in Lecture Notes in Computer ence series. July 2005. http://sec.cs.kent.ac.uk/europki2005/