novel security approach on Open Grid Service to validate certificate based on ..... rity delegates signature checking in its entirety to a Digital Signature Service.
Certificate Validation Scheme of Open Grid Service Usage XKMS Namje Park, Kiyoung Moon, Sungwon Sohn, and Cheehang Park Information Security Research Division Electronics and Telecommunications Research Institute (ETRI) 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, Korea {namjepark, kymoon, swsohn, chpark}@etri.re.kr
Abstract. Current Grid Security Infrastructure using PKI based on SSO. Trust is hard to establish in a service-oriented grid architecture because of the need to support end user SSO and dynamic transient service. Open Grid Service (OGS) Security Infrastructure in Global Grid Forum will extend use of Grid system or services up to business area using XML Web Service security technology. This paper describes a novel security approach on Open Grid Service to validate certificate based on current Globus Toolkit environment using XKMS and SAML, XACML in XML Security. Our security model is based on XKMS, an implementation of the Java component and international standard specification.
1. Introduction Grid technologies are increasingly becoming the platform of choice for developing and deploying distributed computation and data intensive application across large virtual organizations. A computational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive and inexpensive access to high-end computational capabilities. Typically the grid resources are provided by various organizations and are used by people from diverse sets of organizations. A Grid is a collection of distributed computing resources available over a local or wide area network that appear to an end user or application as one large virtual computing system. The vision is to create virtual dynamic organizations through secure, coordinated resource sharing among individuals, institutions, and resources. Grid computing is an approach to distributed computing that spans not only locations but also organizations, machine architectures and software boundaries to provide unlimited power, collaboration and information access to everyone connected to a Grid [3]. The different resources in a Grid may have different access policies, including how they authenticate and authorize users. However, if there are no common or overlapping authorizations among the resources, they do not form a usable grid. And in order to access shared resources, security is an essential component. Users, hosts and services need to be
able to authenticate themselves in the Grid environment. Experience in using grids for remote computations has demonstrated the need for unattended user authentication in addition to interactive authentication. Grid service requests can span multiple security domains. Trust relationships among these domains play an important role in the outcome of such end-to-end traversals. A service needs to make its access requirements available to interested client entities, so that they understand how to securely request access to it. Trust between end points can be presumed, based on topological assumptions or explicit, specified as policies and enforced through exchange of some trust-forming credentials. In a Grid environment, presumed trust is rarely feasible due to the dynamic and distributed nature of virtual organizations relationships. Trust establishment may be a one-time activity per session or it may be evaluated dynamically on every request. The dynamic nature of the Grid in some cases can make it impossible to establish trust relationships among sites prior to application execution [3]. Given that the participating domains may have different security infrastructures it is necessary to realize the required trust relationships through some form of federation among the security mechanisms. Furthermore, Open Grid Service Infrastructure (OGSI) in Global Grid Forum (GGF) will extend use of the Grid technology or services up to business area using Web Service technology [4]. Therefore differential resource access is a necessary operation for users to share their resources securely and willingly. Therefore, this paper describes a novel security approach on Open Grid Service to validate certificate based on current Globus Toolkit environment using XKMS (XML Key Management Specification) [1] and SAML (Security Assertion Markup Language) [5], XACML (eXtensible Access Control Markup Language) in XML Security [4]. This paper is organized as follows. First, we propose a design of security system platform for open grid service and explain experimented XKMS model for certificate validation service. Finally, we explain function of system and then we conclude this paper.
2. Secure OGS Framework based on XML Security In this section, we define secure Open Grid Service framework based on XML Security and describe its components. We also discuss XKMS system platform in framework. 2.1 XKMS Architecture in Secure OGS Framework The Open Grid Services Architecture (OGSA) aims to define a new common and standard architecture for grid-based applications. OGSA defines what Grid Services are, what they should be capable of, what types of technologies they should be based on, but doesn't give a technical and detailed specification (which would be needed to implement a Grid service) [4]. OGSA is based on XML Web Service.
Figure 1 illustrates the layering of existing security technologies and standards and shows how these fit into the Open Grid Security model. Moving from the machine and OS security on the bottom to the applications and server environment at the top, one can identify different layers that either are built and depend on their lower neighbors, or are a level up in abstraction. The same or similar functions can be implemented at different levels, with different characteristics and tradeoffs. For example, security can be an inherent part of a network and binding layer. In the case of the network layer, it can be provided via IPSec or SSL/TLS. In the case of the binding layer, it can be provided by HTTPS and in the case of IIOP, by CSIv2 [4]. In a messaging environment, the message provider (e.g., MQ) can provide end-to-end message security. Given the increasing use of XML, the security standards in the XML space play an important role here: XML Signature, XML Encryption, XML Key Management Service (XKMS), and Assertion Languages (e.g., SAML). Built on top of XML standards are the Web services standards, including WSDL.
Fig. 1. Security Layer blocks for OGSA based on XML Web Security
This framework supports extensibility because it has been developed based on international standards such as WS-Security, XKMS, XML Encryption, and XML Signature specification. XKMS service platform is a framework for the approaches about function of XKMS system and work for development based on Java platform. XML Security API is expressed by structure of java crypto library and XML parser, XSLT processor [9]. And It includes service provide mechanism. SOAP security API supplies XML Web Service security. And XML Security API and SOAP security API supports key exchange and encryption. It supports XML Signature and XML Encryption function. Based on this, XKMS service platform is composed. So, XKMS service application program are achieved by component of service
platform that is constructed by each function. Other than system application, many XML web application security can be provided using the XML Security API and Library that is provided from the XKMS service platform. Figure 2 illustrates the architecture of XKMS service system platform. Major components of XKMS service platform are java crypto library, XML Security API, SOAP security API, XML Signature API, XML Encryption API.
Fig. 2. Architecture of XKMS Service Platform
2.2 Certificate Validation Service for OGS Certificate Validation Module (CVM) is a service component that offloads certificate validation process from the client. CVM consists of six components such as three components for the validating certificate, two components for upgrading efficiency and a component for managing certificate policies and policy mapping information. Figure 3 show that CVM architecture and protocols used by CVM and show the structure of Certificate Validation Service Model. CVM in XKMS system perform path validation on a certificate chain according to the local policy and with local PKI (Public Key Infrastructure) facilities, such as certificate revocation (CRLs) or through an Online Certificate Status Protocol (OCSP) [2]. In the CVM, a number of protocols (OCSP, SCVP, and LDAP) are used for the service of certificate validation. For processing the XML client request, certificate validation service from OCSP, LDAP, SCVP protocols in XKMS based on PKI are used.
Fig. 3. Certificate Validation Service Model for OGS
The XKMS client generates an ‘XKMS Validate’ request. This is essentially asking the XKMS server to go and find out the status of the Server’s certificate. The XKMS server receives this request and performs a series of validation tasks e.g. X.509 certificate path validation. Certificate status is determined. An XKMS server replies to client application with status of the server’s certificate and application acts accordingly. Using the OCSP protocol, the CVM obtained certificate status information from other OCSP responders or other CVMs. Using the LDAP protocol, the CVM fetched CRL (Certificates Revocation Lists) from the repository. And CA DB connection protocol (CVMP;CVM Protocol) is used for the purpose of that the server obtains real-time certificate status information from CAs. The client uses OCSP and SCVP. With XKMS, all of these functions are performed by the XKMS server component. Thus, there is no need for LDAP, OCSP and other registration functionality in the client application itself.
3. Flow of CVM for OGS based on XKMS 3.1 Process of XKMS Service Components XKMS supports two services. Locate service resolves a element but does not require the service to make an assertion concerning the validity of the binding between the data in the element. The Validate service provides all the functions of locate but returns a trusted key binding that has been validated in accordance with the policy of validate service [1]. Locate service retrieves and provides information concerning keys. In Locate service of figure 4 begins with an incoming XML Signature. The element is parsed for the element that contains a element including the odd key identifier. We are assuming the signature processing application doesn’t understand this identifier and must delegate the processing to a key Location service. This key locate
service processes the key identifier and makes a database query that matches it to an X.509 certificate. This certificate is then formatted as a element and passed back to the signature processing application. At this point the signature processing application has enough information to perform cryptographic validation of the signature processing application [8]. At this point the signature processing application has enough information to perform cryptographic validation of the signature. It now has a public key, whereas before it only had a single key identifier. The signature processing application may now choose to perform path validation on its own, or it may decide to delegate this action to a service as well. The key Location service is the first tier of XKMS, which is called the locate service. In addition to passing off element, the signature processing application may also pass off a element if the signature processing application doesn’t have access to the necessary network or server location.
Fig. 4. Locate and Validate service of XKMS
The second tier is called the Validate service and is responsible for asserting trust over the binding of a name and a public key. The Validate service is a superset of the Locate service. This means that in addition to providing name key assertions, it can also locate public key values. In Validate service of figure 4 we have a situation similar to the one presented in Locate service of figure 4. In Validate service of figure 4 we are passing a element to the Validate service with the expectation of a status result and an indication of the key binding. Validate service gives us the name and public key from the queried certificate as well as make en assertion regarding the binding between the name in the certificate and the public key. In current Globus middleware Toolkit, there is no mechanism of differential resource access. To establish such a security system we are seeking, a standardized policy mechanism is required. Fortunately, Globus Toolkit 3.0 is implemented using the XML Web Service technology, which uses XML formatted documents for interfacing among middleware services. We employ the XACML specification to establish the resource policy mechanism that assigns differential policy to each resource (or service). SAML also has the pol-
icy mechanism but it is very limited to use for Grid, while XACML provides very flexible policy mechanism enough to apply to any resource type [8]. For our implementing model, SAML provides a standardized method to exchange the authentication and authorization information securely by creating assertions from output of XKMS (e.g. Assertion Validation Service in XKMS). XACML replaces the policy part of SAML as shown in Figure 5. Once the three assertions are created and sent to the protected resource, there is no more verification of the authentication and authorization at the visiting site [6]. This, Single-Sign-On (SSO), is a main contribution of SAML in distributed security systems.
Fig. 5. SAML/XACML Message Flow using XKMS
Figure 5 shows the flow of SAML and XACML integration for differential resource access. Once assertions are done from secure identification of the PKI trusted service, send the access request to the policy enforcement point (PEP) server (or agent) and send to the context handler. Context handler parses the attribute query and sends it to PIP (policy information point) agent. The PIP gathers subject, resource and environment attributes from local policy file, and the context handler gives the required target resource value, attribute and resource value to PDP (policy decision point) agent. Finally, the PDP decides access possibility and send context handler so that PEP agent allow or deny the request. 3.2 Flow of Certificate Validation Service Certification path validation verifies the binding among the subject identity, the subject public key, and subject attributes that may be present in the certification path. Constraints in certification path limit the possible identity values and the possible attribute values. And certification path validation determines whether certificates in chain are revoked or not revoked [7]. The algorithm of the validation is as follows.
Fig. 6. Certification Path Validation Sequence First, client generates the certification path validation request. The request may optionally include the client’s trust anchor or certification policy. This information is used for validating chain. And, The server builds certification paths using certification path construction module. If the trust anchor in the request is present, the server must build the certification path that start from the trust anchor certificate. Second, certification paths and optional certification policy. If building certification path succeeded and certification policy is present, the server verifies certification path using certification policy constrains and also performs checking certificate status. If building certification path succeeded and certification policy is not present, the validating process is performed by only checking certificate status. Because the current certification path was already verified in first step. If the previous step succeeded and the verified path was obtained, the verified path is saved in certification path DB table for next request. If the previous step failed or the verified path was not obtained, the server processes an exception handling and makes a fail response. Also the fail reason is recorded in the log file. Finally, Verified certification path.
4. Experiment XKMS has been implemented based on the design described in previous section. The figure for representing Testbed Architecture of XKMS component is as follows Figure 7.
Fig. 7. Testbed Architecture of XKMS Component for Open Grid
Components of the XKMS are XML Security platform library, service components API, application program. Although XKMS service component is intended to support XML applications, it can also be used in order environments where the same management and deployment benefits are achievable. Testbed has been implemented in Java and it runs on JDK ver 1.3 or more. We use Testbed system of windows PC environment to simulate the processing of various service protocols. And the message format is based on specification of W3C. The manner in which the various XKMS service builds upon each other and consumes each other’s services is shown in the following diagram.
Fig. 8. Interrelation of XKMS Service in Open Grid environment
The arrow reflects the primary relationship between the security services. The first (Alphabet) path shows alternative ways of checking the security of a SOAP message secured using Web Security service. Second (Number) path is the same except Web Service security delegates signature checking in its entirety to a Digital Signature Service. Table 1 summarizes function of XKMS service system component for CVM. Table 1. Function of XKMS System Component for CVM Service & Protocol Register Service Locate / Validate Service Recovery / Revoke Service Compound Request Protocol Synchronous Processing Asynchronous Processing Two-Phase Request Protocol Payload Authentication HTTP / SOAP 1.1 Transport Cert Path Validation Cert Status Check
Tier 0 * M * O * * * * M * *
XKMS System Tier 1 Tier 2 Tier 3 * * * M */M O * * * O O M M * O O * O O * O O * M M M * M * * M *
Tier 4 * O * * * * * M * *
KRSS KISS KRSS -
(M:Mandatory, O:Optional, *:No Recommendation)
5. Conclusion The Grid technology extends its use from meta-computing for researchers to business areas for companies by employing XML Web Service technology. The current GSI needs to apply the current mechanism to OGSI. We propose a novel security approach on open grid service to validate certificate based on current Grid security environment using XKMS and SAML, XACML in XML Security. This service model allows a client to offload certificate handling to the server and enable to provide central administration of XKMS polices. In order to obtain timely certificate status information, the server uses several methods such as CRL, OCSP etc. Our approach will be a model for the future security system that offers security of Open Grid Security.
References 1. XML Key Management Specification Version 2.0 (W3C Working Draft), April-2003 2. Certificate Management Protocol, RFC2510, March-1999 3. Global Grid Forum: http://www.globalgridforum.org/ 4. GWD-1: OGSA Security Roadmap: GGF OGSA Security WorkingGroup, July-2002 5. Assertions and Protocol for the OASIS SAML: OASIS Standard (2002) 6. Euinam Huh, Jihye Kim, Hyeju Kim, Kiyoung Moon: Policy based on grid security infrastructure implementation for differential resource access: ISOC 2003 (2003) 7. Jonghyuk Roh, et al.: A model of Certification Validation Server: ICOIN 2003 (2003) 8. Blake Dournaee: XML Security: RSA Press (2002) 9. Namje Park, Kiyoung Moon, Sungwon Sohn: A Study on Key Information Service Protocol for Secure XML Web Service: The KIPS Transaction, Part C, V(10-C) No 6 (2003)
