OCSP for Grids: Comparing Prevalidation versus Caching Jesus Luna1, Oscar Manso2, Manel Medina3 Computer Architecture Department, Polytechnical University of Catalonia Jordi Girona 1-3, Building D6. 08035. Barcelona, Spain. 1
[email protected] [email protected] 3
[email protected] 2
and every computer that is part of the Grid. Nowadays, a mechanism which is becoming quite popular in these environments due to its near-real time validation capabilities is the Online Certificate Status Protocol (OCSP) [1]. This is a simple query protocol that relieves its clients –also called “relying parties”- of the burden of managing CRLs; also the OCSP protocol is flexible and extensible, allowing the implementation of certificate validation services for Grids able to report more than just the CRL’s contents However, along with its advantages OCSP also conveys great challenges and special requirements, most of which are already being detailed by the Global Grid Forum’s CA Operations Workgroup (CAOPS-WG) in the document “OCSP Requirements for Grids” [2]. Based on this set of recommendations, we developed the Open GRid Ocsp (OGRO) Java API [3], which implements OCSP support for the Globus Toolkit 4 –GT4- [4] with a customizable set of validation rules through the so-called Grid Validation Policy (GVP). OGRO was introduced in [5] as part of a proposal for an OCSP validation infrastructure for GT4, based also in CertiVeR’s OCSP Responder [6]. That paper showed that the validation overhead introduced by OCSP was very high when relying parties were required to perform several concurrent validation checks per Grid Service being invoked from the GT4’s WSRF Container. Further research to optimize Grid OCSP performance took us to propose the prevalidation mechanism in [7], which consisted of OGRO-enabled Grid clients embedding the OCSP Response received from CertiVeR as a non-critical extension of the Proxy certificate just before its creation. In this way, at the time of validating the Proxy Certificate Path, relying parties only were required to perform some security checks on such prevalidation data avoiding the need to execute the whole OCSP process on real time again. However according to the experience gained in the last few months from our participation in the CAOPSWG, the prevalidation mechanism was not only needing further performance improvement before being introduced to real Grid environments, but also required to be compared with similar solutions and even to be analyzed under the point of view of new Grid-OCSP security requirements.
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 GridOCSP. 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
1-4244-0344-8/06/$20.00 2006 IEEE
1
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.
GRid OCSP– [3]. By being Open Source and 100% Java, OGRO has been fully integrated into the Java Commodity Grid Kit [8] and the WSRF Grid Services Container - GT4’s Java core-. The OGRO API does not implement its own OCSP client classes, instead it relies upon well known JCE providers (current version uses Bouncy Castle [9], but it is being modified to support also IAIK [10] in the next release). OGRO’s main contribution for Grids is the use of a set of rules -written in XML- called the Grid Validation Policy or GVP, which customizes relying parties’ OCSP behavior in concordance with the recommendations given in [2]. The GVP, its structure –DTD- and rules have been thoughtfully explained in [7] so we will only review some important features in the rest of this section. The GVP allows per issuer validation rules (i.e. available revocation sources and a customizable “Unknown” status meaning for Proxy Certificates) or even the option to configure a default issuer, that is, rules applying to any user with their issuer not being referenced anywhere else in the policy. More than being a set of configuration directives, OGRO’s Grid Validation Policy represents a mechanism that contributes to enhancing relying parties’ security level. Also in [7] we compared different configurations of the Grid Validation Policy, in such a way that potential users would be able to choose the one that best fits their security needs. One important conclusion of that paper was the strong need of improving OCSP validation performance at Grid relying parties (i.e. clients creating a Proxy Certificate and WSRF servers validating that credential), so its utilization does not convey a high overhead to job execution. The next section presents two mechanisms related with the OCSP Response management, which have been already implemented into OGRO to help achieving a secure, flexible and efficient OCSP validation solution: the prevalidation and the caching.
II. A QUICK REVIEW ON CERTIVER AND OGRO In 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. CertiVeR CertiVeR [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.
III. PREVALIDATION AND CACHING A. The prevalidation mechanism When we first faced the challenge of improving Grid relying parties’ OCSP performance without affecting its overall security, the authorization push model (RFC2904 [11]) and the validation data used in the XML Advanced Digital Signature –XAdES- [12] came to our mind. In both cases validation information (attributes in the push model and CRLs in XAdES) is included along the data itself, thus creating a self-contained package able to be validated by relying parties without further contacting the source of authority (i.e. the Attribute repository). In most of the cases the relying party only requires to extract the embedded validation data, perform some cryptographic verification over it (i.e. authenticity and integrity) and finally parse it. With mechanisms like these, important performance improvements can be obtained in the validation process. In the case of our prevalidation mechanism, what if we embed the OCSP Response itself into the Proxy Certificate? The rationale
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
2
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:
highly scalable or fault-tolerant in contraposition to a Trusted Responder serving several domains), but also might be more sensible to network failures than first- and second-level caches. The latest version of OGRO implements OCSP validation with second-level caches through the following steps: 1) The Grid client creates its Proxy Certificate in the usual way (it does not require 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) Cache initialization: When a Grid Service is requested from the OGRO-enabled WSRF container (also through the Secure Messaging mechanism as with prevalidation), 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.
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) Cache searching: Client connections to the Grid server implying a cache-search (OGRO can be configured to enable caching only for certain Certification Authorities hierarchies) will use the native lookup methods from such data structure. One of the following will occur i) In case of a cache hit, then OGRO retrieves the stored OCSP Response, verifies it (to avoid outdated entries) and finally obtains the correspondent 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 stored into the cache, so subsequent calls from the same user will result in a cache hit.
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.
4) The cache is being frequently purged by a separate thread, so stale entries (outdated OCSP Responses according to RFC 2560’s verification method) are removed when detected. Responses reporting an invalid End-Entity Certificate Chain – i.e. those with at least one revoked certificate- are permanently stored. Next, this paper will provide a comparison of the results obtained with the prevalidation and the caching mechanisms, along with a security analysis of both related with the Proxy Certificate Revocation problem.
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 clientwhen 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
IV. A COMPARISON ON PERFORMANCE AND PROXY CERTIFICATE REVOCATION A. Performance results With the purpose of comparing OGRO’s prevalidation and second-level caching mechanisms, a CertiVeR’s OCSP Trusted Responder (server with one Xeon processor @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 the revocation information, but neither cryptographic hardware nor precomputed OCSP Responses were utilized. For the Grid clients we created a set of 5 different End-Entity Certificates and set up 50 OGROmodified Commodity Grid Kit installations with such credentials (same certificate for each 10 clients to test caching capabilities). The underlying hardware was composed of a 4-
3
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).
will be the time required to extract and verify the OCSP data from the Proxy certificate).. As we can see from figure 1, the use of plain OCSP -“Total OCSP” graph- conveys the highest overhead for the validation process, something already concluded in previous work [5]. In fact the peaks observed during this test are due to bottlenecks created at the OCSP Responder when several instances from the WSRF’s OGRO API are concurrently requesting validation, and afterwards when the container itself performs the cryptographic verification and parsing over each one of the received OCSP Responses. The observed performance peaks are repeated in almost regular intervals comprehending from 5 to 7 WSRF requests. This behaviour is only dependent on the service 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 it behaves almost like the “Total OCSP” graph, something that even though was expected -because the inmemory cache is still being filled- also corresponded with the performance peak observed in the first test. However once such cache contains the statuses for all the EECs, then the overall performance greatly improves as the OCSP Server is no longer required to retrieve the status from the in-memory cache. The latter operation requires a few tenths of microseconds due to the performance and concurrencycontrol mechanisms of the underlying OGRO API; a future enhancement may provide a more scalable database approach for implementing the OCSP cache. Finally, the results obtained with the prevalidation mechanism (the “Total prevalidated” graph) do not involve the high peaks from the two previous tests, because it never required to contact the OCSP Server. On the other hand, we found some others peaks in the graph and, maybe more
TABLE I THE GRID VALIDATION POLICIES BEING TESTED
Grid Validation Policy OCSP Cache
Prevalidated
Explanation
WSRF Container uses OCSP to validate every Grid client request. Second-level caching enabled at the WSRF Container. OCSP validation will be invoked only if a call to the cache is missed. 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
G r id O C S P : P r e v a lid a tio n v s C a c h in g
Time (ms)
2000
1000
0 1
3
5
7
9
11
13
15
17
19
21
23
25
27
29
31
33
35
37
G T4 W SRF Request T o ta l O C S P
T o ta l c a c h e
T o ta l p re v a lid a te d
Fig. 1. Grid-OCSP performance comparison: Prevalidation versus Caching.
4
39
41
43
45
47
49
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.
Grid client with such prevalidation data, but keeping the same X.509 information already present in P (i.e. public key, subject DN, etc.). Afterwards the Grid client only has to “register” P’ so the OCSP Responder may be able to provide its status to interested parties afterwards. A critical security issue here is that P’ must be registered before the embedded prevalidation data’s expiration. A further discussion on this topic will be presented in the next section, where the notion of a cautionary period is introduced. Therefore it is feasible to think that when querying Proxy Certificate’s status, the Prevalidation mechanism offers a similar security level than traditional OCSP. Obviously the same holds true for the second-level cache mechanism, which will request and store the OCSP Response exactly “as is” on the Grid server. There is, however, an advantage of the prevalidation mechanism over the traditional OCSP and the second-level cache solutions: prevalidated data allows for the retrieval of a Proxy Certificate status even in situations where the OCSP Responder is not accessible from the WSRF Container domain (i.e. due to network failures).
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]: x 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. x 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. x 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. x 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 secondlevel 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.
2) Revoking the Proxy Certificate: When a Proxy Certificate is revoked there are several issues to solve, mainly related with the entity authorized to perform such process and the means by which this revocation information is propagated through the Grid. For our purposes only the propagation problem will be considered, as OCSP by itself is not related with the mechanisms to authorize and perform the Proxy revocation. If the revocation information is not propagated to other domains in a promptly way, then there is the latent risk of keeping jobs running under the compromised Proxy control for quite a time. The prevalidation mechanism is unable to alleviate this problem, because the prevalidated data is embedded into the revoked Proxy itself. As for the secondlevel cache, a pretty similar problem may arise if and only if it is not being refreshed or purged constantly. Stale cache entries will represent always a security risk. The “traditional OCSP” approach answers the last Proxy Certificate status known by the OCSP Responder, however there is no guarantee that such status is the very last, as there is obviously a time required to propagate any update through the whole OCSP infrastructure. The “traditional OCSP” currently can provide three timestamps characterizing the revocation response [1]. These are thisUpdate (the time at which the status being indicated is known to be correct), nextUpdate (the time at or before which, newer information will be available about the status of the certificate) and producedAt (the time at which the OCSP responder signed this response). If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time. Whenever this field is set, it is an indicator that the revocation information has been retrieved from a CRL being released only at certain intervals of time. In certain cases, this interval may be quite large -even in the order of days-. Both thisUpdate and nextUpdate are from the underlying CRL timestamps.
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
5
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.
take when accepting the result status coming from an OCSP Response as is..Relying party’s validation middleware should discard OCSP Responses conveying a cautionary period greater than the one specified in the validation policy. V. RELATED WORK Support for OCSP in relying parties’ software has been implemented in several flavors, ranging from programming libraries like OpenSSL [13], SUN’s J2SE5 [14], BouncyCastle [9] and IAIK [10] to embedded features in commercial browsers and fully functional stand-alone clients [15]. OGRO was built upon publicly available Java APIs to provide a set of particular features required by the computational Grid, which were not offered “as is” by such implementations. Table II shows a comparison -relative to the requirements introduced in [2]- between OGRO, three well known JCEs implemented into SUN’s J2SE, BouncyCastle and IAIK- and two client implementations (OpenSSL and Ascertia’s OCSP Client), which according to our research integrate a set of comprehensive OCSP features pretty close to Grid requirements. Notice that also all the implementations compared in table II do not support caching or prevalidation. From such table it is also easy to conclude that OGRO’s main contribution to the computational Grid is to be the first publicly available API, which implements the full set of OCSP relying party requirements identified by the GGF’s CAOPS-WG. Thanks to the flexibility added with the Grid Validation Policy, we think that OGRO is prepared to implement future Grid-OCSP requirements (i.e. Proxy Certificate Revocation).
.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: x For prevalidation receivedAtWSRF, which denotes the time at which the Grid client’s (service invoker) Proxy Certificate is being validated. x 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
TABLE II COMPARING OGRO WITH OTHER OCSP APIS AND CLIENTS
Grid-OCSP Requirement Transport HTTP/HTTPS Revocation Source Requirements
Use of nonce Error Handlers
Unknown Status Management OCSP Request Signing Flexible Configuration
Prevalidation/Caching
J2SE5
Bouncy Castle Both No
IAIK
Not specified First AIA, if not present OCSP. Fallback to CRL. No
Yes No
Yes No
Yes Cautionary Period-like mechanism
No
No
No
No
Not specified Some default parameters configured into JCE. No
Yes No
Yes No
Yes GUI configurator for default parameters.
Yes Flexible ruleset with GVP.
No
No
Yes Configuration File for default params. No
No
Prevalidation; first- and secondlevel caches
Both AIA, OCSP, CRL
Both No
6
OpenSSL client Both CRL/OCSP
Ascertia OCSP Client Both AIA, OCSP. Keeps list of Trusted Responders Yes No
OGRO Both AIA, OCSP, CRL. Query order in Grid Val Policy (GVP). Yes Query whole GVP’s Rev. source list Ntimes. Set final status if failed. Yes
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 R0 . The Responder creates afterwards a hash chain by applying d+1 subsequent hash functions, h over R0 . The final value R h d 1 ( R0 ) is signed by the Responder and sent to the client together with the OCSP Response. At time ti , to sign a Response, the OCSP Responder send to the client an intermediate value, Ri ( 0 d i d ), which is calculated by applying d+1-i times the hash function h over R0 : Ri h d 1 i ( R0 ) . The relying party can verify Ri by applying i times the hash function h over Ri 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: x I: Size of the target certificate identifier (serial number). x S: OCSP Responder Signature size. x D : Percentage of CPC-OCSP Responses with the update parameter Ri .
consider that CPC-OCSP is suitable to extend the lifetime of a cached OCSP Response beyond NextUpdate, but preserving the cautionary period defined in the validation policy. An interesting idea about combining any of the prevalidation or caching mechanisms with CPC-OCSP is introduced as future research in the following section. TABLE III COMPARING PREVALIDATION, SECOND-LEVEL CACHING AND CPC-OCSP
Revocatio n system
OCSP Response size
Traditional OCSP
I+S
Prevalidation Secondlevel cache CPCOCSP
I S iif Prevalidation ° ® data invalid °¯ 0 any other case I S iif cached ° ® data invalid °¯ 0 any other case (1 D )( I S 2 H ) DH
Computational cost (relying party) t k _ public t k _ public iif
Prevalidation data invalid t k _ public iif
cached data invalid
(1 D )t k _ public t hash
VI. FUTURE WORK AND CONCLUSIONS In this paper we have compared prevalidation and caching, two mechanisms capable of improving OCSP validation performance in Grid environments. When using the novel prevalidation, the OCSP Request is embedded into the Proxy Certificate as an X.509 extension in such a way that the overhead introduced by traditional OCSP is relieved from the server. Despite its advantages, the prevalidation mechanism should be avoided when using a high-quality OCSP Service able to produce responses with a cautionary period short enough to require several validations during a Proxy’s lifetime- in order to not reduce the quality of the overall system. Caching OCSP Responses is another useful mechanism and in this paper we have contributed with a new concept for the computational Grid: “second-level OCSP caches” implemented into the Grid server itself, where optimal performances can be achieved according to our research. A series of tests has been undertaken to compare the performance of both, prevalidation and second-level caches when integrated into the Globus Toolkit 4’s WSRF Container. The results have shown that a sustained validation throughput can be obtained with the prevalidation mechanism, however second-level caching behaves better once it has been filled with enough OCSP data so cache misses are infrequent. Future enhancements in OGRO will be focused not only into optimizing both implementations for production Grids according to the experience obtained from large scale tests to come-, but also in exploring new “hybrid” mechanisms able to
x H: Size of the hash value. x t hash : processing time needed by the relying party to perform a hash function. x t k _ public : 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 D =1). We
7
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 revocationA 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 secondlevel 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].
[6] [7]
[8]
[9] [10]
[11] [12]
[13] [14]
[15] [16]
[17]
[18]
REFERENCES [1] [2]
[3] [4] [5]
“RFC 2560: X.509 Internet Public Key Infrastructure, Online Certificate Status Protocol”. Myers M, et. al. June 1999. “OCSP Requirements for Grids”. Global Grid Forum, CA Operations Work Group. Working Document. May 2005. https://forge.gridforum.org/projects/caops-wg “OGRO - The Open GRid Ocsp client API”. June 2006. http://globusgrid.certiver.com/info/ogro “The Globus Toolkit 4”. June 2006. http://www.globus.org “Towards a Unified Authentication and Authorization Infrastructure for Grid Services: Implementing an enhanced OCSP Service Provider into
8
GT4”. Luna J., Manso O., Manel M. 2nd EuroPKI 2005 Workshop. Proceedings by Springer in Lecture Notes in Computer Science series. July 2005. http://sec.cs.kent.ac.uk/europki2005/ “CertiVeR: Certificate Revocation and Validation Service”. June 2006. http://www.certiver.com/ “Using OGRO and CertiVeR to improve OCSP validation for Grids”. Luna J., Manso O., Manel M. Accepted for the 1st Grid and Pervasive Conference (GPC2006). Proceedings by Springer in Lecture Notes in Computer Science series. May 2006. http://hpc.csie.thu.edu.tw/gpc2006/ "A Java Commodity Grid Kit" Gregor von Laszewski, Ian Foster, Jarek Gawor, and Peter Lane, Concurrency and Computation: Practice and Experience, vol. 13, no. 8-9, pp. 643-662, 2001, http:/www.cogkit.org/ “The Legion of Bouncy Castle”. June 2006. http://www.bouncycastle.org/ “The IAIK Java Cryptography Extensions”. Stiftung Secure Information and Communication Technologies SIC. June 2006. http://jce.iaik.tugraz.at/sic/products/core_crypto_toolkits/jca_jce “RFC 2904: AAA Authorization Framework”. Vollbrecht J, et. al. August 2000. “ETSI TS 101 733: Electronic Signatures and Infrastructures (ESI); Electronic Signature Formats”. ETSI ESI group. Version 1.5.1, December 2003. http://portal.etsi.org/esi/el-sign.asp “The OpenSSL software”. June 2006. http://www.openssl.org “Public Key Infrastructure (PKI) Enhancements for J2SE 5”. SUN Microsystems. June 2006. http://java.sun.com/j2se/1.5.0/docs/guide/security/pki-tiger.html “Ascertia’s OCSP Client Tool”. June 2006. http://www.ascertia.com/products/ocsptool/ “CPC-OCSP: an adaption of OCSP for m-Commerce”. Munoz-Tapia, JL. Forne-Munoz, J. Upgrade Magazine, vol III, no. 6, pp: 22-26, December 2002. “Authorisation in Grids” Chadwick, David. OGSA-AUTHZ Meeting at GGF16. February 2006. http://wwwunix.gridforum.org/mail_archive/ogsa-authz/2006/02/ppt00000.ppt “An Innovative Policy-Based Cross Certification Methodology for Public Key Infrastructures”. Casola V, et. al. 2nd EuroPKI 2005 Workshop. Proceedings by Springer in Lecture Notes in Computer Science series. July 2005. http://sec.cs.kent.ac.uk/europki2005/
